#launchpad-dev 2009-10-05
<lifeless> jml: testtools is in debian testing now
<lifeless> jml: and you might like lp:~lifeless/subunit/protocol
<mwhudson> oh oh for someone to have a pre-imp call with
<mwhudson> preferably jml
<lifeless> mwhudson: I cn do a quick one if you are desperate
<mwhudson> lifeless: it's ok, i think
<mwhudson> thanks though
<mwhudson> lifeless: i don't guess you know if there's a method already to find all official source package branches for a distroseries?
<mwhudson> easy enough to add, and i've looked in the obvious places so...
<lifeless> I don't know, no
<mwhudson> soyuz is the mind killer
<mwhudson> bug 217644
<mup> Bug #217644: ResultSet aggregates do not respect distinct option <Launchpad Foundations:Invalid> <Storm:Fix Released by jamesh> <https://launchpad.net/bugs/217644>
<jamesh> mwhudson: that bug should be fixed in the version of Storm you're using.
<mwhudson> jamesh: i can probably delete a bodge then, that's good
<jamesh> It now applies the aggregate to a subselect, so distinct, offset and limit all work.
<adeuring> good morning
<noodles775_> hi adeuring
<adeuring> hi noodles775_!
<al-maisan> Good morning!
<mrevell> Morning
<Fly-Man-> morning
<Ursinha-sprint> hey bigjools, what version of kde are you running?
<bigjools> Ursinha-sprint: 4.3 in Karmic
<Ursinha-sprint> hm
<bigjools> 4.3.1 in fact
<Ursinha-sprint> bigjools, I'm using 4.3 in jaunty, and almost no icons are showing in the system tray applet
<Ursinha-sprint> 4.3.1 as well
<Ursinha-sprint> do you have the same problem?
<bigjools> Ursinha-sprint: are you using intel gfx?  (no I don't)(
<Ursinha-sprint> hmm, don't think so, why?
<bigjools> it's buggy as hell in jaunty
<Ursinha-sprint> oh
<bigjools> and I had some issues like that
<bigjools> Ursinha-sprint: check #kubuntu for help I guess
<Ursinha-sprint> thanks bigjools
<bigjools> Ursinha-sprint: no prob - I do have other issues though, since 4.3 it hangs when logging out/shutdown etc :(
<Ursinha-sprint> oh :(
<Ursinha-sprint> bigjools, the only problem I have is with amarok vs. all the other stuff that needs sound
<Ursinha-sprint> besides this one with the tray
<bigjools> Ursinha-sprint: oh yeah, I used to have that.  apt-get purge pulseaudio fixes that ;)
<Ursinha-sprint> bigjools, lol
<Ursinha-sprint> everybody hates pulseaudio
 * wgrant thwacks bigjools with the "there is no problem unless you have filed a bug" bat
<Ursinha-sprint> yes, it's a pita most of the time
<bigjools> I can file bugs until I am blue in the face
* mrevell changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 0 of 3.1.10 | PQM is OPEN | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/
<deryck> Morning, all.
<bigjools> howdy deryck
<allenap> Hi jml, I'm having problems with devscripts.autoland. It's stopping utilities/ec2 from working because it requires a couple of libs that are not installed, launchpadlib and lazr.uri.
<jml> allenap, wow
<jml> allenap, I thought they were developer dependencies?
<allenap> jml: I don't think so... I'll look...
<jml> allenap, karmic or jaunty?
<allenap> jml: Jaunty.
<mrevell> allenap: If I pastebin you my short traceback from ec2, can you tell me if it's the same thing you're getting?
<allenap> jml: No, they're not in any of the deps afaict. lazr.uri does not seem to be available for installation on my machine, without sorting out some PPAs.
<allenap> mrevell: Sure.
<mrevell> allenap: http://pastebin.ubuntu.com/286108/
<jml> allenap, lazr.uri is in download-cache
<mrevell> allenap: from what you've said, I assume it is
<allenap> mrevell: Yes, I think that's related.
<mrevell> allenap: cool, I'll hang onto your coat-tails...
<allenap> jml: Yeah, but utilities/ec2 runs with the system python, not the buildout managed one.
<jml> allenap, oh right.
<jml> ffs.
<jml> allenap, I guess the right thing to do is make the imports conditional then.
<allenap> jml: Yeah, I had some grief with a similar thing last week.
<jml> allenap, I'm 90% sure that when we switch to Python 2.5 this problem will go away.
<allenap> jml: Yeah. I can so that if you're busy.
<jml> allenap, thanks.
<jml> allenap, I've actually got today off, so I'd much prefer it if you do it :)
<allenap> jml: Yes, we can run everything with the buildout bin/py.
<jml> allenap, I can review the patch if you'd like though.
<allenap> jml: Sure, no worries. Thanks for being around on your day off :)
<jml> allenap, np.
<jml> allenap, you should install launchpadlib & lazr.uri btw
<jml> 'ec2 land' is sweet as.
<allenap> jml: I'll try to make it so the command appears with a note that it won't work until those packages are installed.
<allenap> jml: I look forward to trying it :)
<jml> good idea
<maxb> The problem with recommending that people install the system package of lazr.uri is that it breaks launchpad dev
<allenap> maxb: Ah, that's troubling.
<maxb> It's the namespace package / setuptools / aaargh situation
<allenap> maxb: I think I'm going to have a painful day today.
<maxb> uhoh :-/
<allenap> But first, lunch. Never hack setuptools on an empty stomach.
<maxb> good policy!
<wgrant> I would generalise that statement.
<gmb> wgrant: Indeed. s/hack setuptools/.*/
 * gmb -> lunch
<wgrant> gmb: Not quite.
<gmb> wgrant: Well, I suppose eating on an empty stomach is acceptable.
<mrevell> allenap: When you're back from your lunch, and the you've resolved the pain in your day, could you please share the analgesic with me? :)
<allenap> mrevell: I'm working on it now :)
<allenap> mrevell: I'll see if I can get a quick fix for you.
<mrevell> allenap: Hey, no rush beyond what you're doing already :)
<allenap> maxb: You said that installing lazr.uri causes launchpad dev to break. Can you elaborate on that?
<maxb> allenap: Hi
<allenap> maxb: Hello again.
<maxb> So the problem is that setuptools installs a *-nspkg.pth file which registers the toplevel lazr package with a __path__ pointing to the system directory
<maxb> This defeats attempts to add any other lazr.* via PYTHONPATH
<maxb> And then you have a bit of a conundrum. I haven't figured out how to solve it, or if it is soluble
<allenap> maxb: Ah, that's grizzly. If it's installed via a deb then this won't be a problem, will it? Not that there's a lazr.uri deb easily available.
<maxb> Yes, it is a problem, and there's lazr.something debs available in karmic, hence me noticing the problem
<maxb> python-lazr-uri | 1.0-0ubuntu1 |        karmic | all
<ybenitezf> hello
<allenap> maxb: Thanks.
<ybenitezf> i from Cuba and need help with getting LP as explained in https://dev.launchpad.net/Getting, may can some of you helpme
<ybenitezf> ?
<maxb> What do you need help with?
<ybenitezf> my internet connection is so poor that running rocketfuel-setup is not an option forme, i get the tar.gz from the page, but none wiki page explain what to do from there, also the tar.gz is a little outdate
<ybenitezf> can you give me links or something for getting LP running ?
<allenap> jml: Can I call in that review please? https://code.edge.launchpad.net/~allenap/launchpad/packages-for-autoload-bug-443061/+merge/12867
<intellectronica> ybenitezf: i think you can use both. download the tarball (though i think it's pretty old) and use rocketfuel-setup to do the rest (bzr will be smart and not try to download revisions it already has)
<maxb> ybenitezf: You should read https://dev.launchpad.net/Getting and the source of rocketfuel-setup
<intellectronica> ybenitezf: anyway, you don't have any way of doing LP development without getting the complete branch, regardless of whether you do it with bzr or by getting a tarball. the first download will be quite bug, but after that you'll only need to update a few revisions every time, which is not so terrible even with a slow connection
<ybenitezf> i have tried that, but rocketfuel-setup (from tarball) complains about bzr version even when i have instaled version 2.0.x.x, i have been reading https://dev.launchpad.net/Getting all the weeked
<maxb> You'll need to get a newer rocketfuel-setup.
<ybenitezf> yep
<maxb> https://dev.launchpad.net/Getting tells you how
<ybenitezf> but when executed it fails downloading
<maxb> You're not giving us enough detail about your problems to enable us to hep
<maxb> *help
<ybenitezf> sorry
<ybenitezf> mine school use a proxy server, i have not direct internet connection, all that i need is an updated tar.gz like the one in https://dev.launchpad.net/Getting
<ybenitezf> can you help me  with that
<ybenitezf> ?
<maxb> No, because that's not actually what you need.
<maxb> The size of the download should not actually be that different whether it's by tarball or bzr.
<ybenitezf> ahh
<ybenitezf> there is a problem with that, with the tar.gz i can use a download manager, running rocketfuel-setup can fail and i have to start all over again
<ybenitezf> i'm a poor connection man, ;-)
<maxb> Do you have the tar.gz already?
<ybenitezf> yes the old one
<maxb> Then just run "bzr pull" in it, and let it download all the updates
<ybenitezf> ok
<ybenitezf> i will try again
<ybenitezf> see you later maxb, thanks for your help
<maxb> I think we should remove herb's tarball (and possibly replace it)
<maxb> For one, it's of db-devel not devel. For another, it's layed out as a standalone branch, not a shared repository
<maxb> And if we're optimizing for download size, there's no need for it to contain a working tree either
<leonardr> bigjools, can i ask you a question about ppas?
<bigjools> leonardr: go for it
<leonardr> bigjools: is it possible to delete one of your ppas?
<leonardr> i'm working on https://answers.launchpad.net/soyuz/+question/84542 as part of chr
<bigjools> leonardr: no, the best we can do is to disable them
<bigjools> leonardr: assign to LOSAs
<leonardr> ok, thanks
<bigjools> np
<ybenitezf> maxb, i have untar the tar.gz and run "bzr pull" from ~/launchpad/lp-branches/db-devel but fails with an error: bzr: ERROR: Not a branch: "/home/archives/rocketfuel/wiki/db-devel/"
<maxb> oh
<ybenitezf> just for asking, anyone can facilitate launchpad.tag.gz update
<maxb> leonardr: There's a slight edge case. If a PPA has had no uploads ever, it can be deleted
<maxb> leonardr: https://answers.edge.launchpad.net/soyuz/+question/79720 <-- question where I asked for one of my PPAs to be deleted and cprov explained things
<leonardr> maxb, thanks
<maxb> ybenitezf: bzr pull --remember lp:~launchpad-pqm/launchpad/devel
<maxb> Also, rename the db-devel directory to devel
<ybenitezf> maxb: ok
<ybenitezf> maxb: run that from devel it self or from parent dir ?
<maxb> From inside devel
<ybenitezf> maxb: I'm at it, seems to be taking time
<maxb> Hrm, we *really* need to remove or update that tarball. A modern bzr version packs the repository down from 219MB to 150MB
<maxb> Hmm. he left. Anyway, it downloaded 25484KB for me
<Ursinha-sprint> hi barry :)
<barry> Ursinha-sprint: hi!
<Ursinha-sprint> barry, you are running karmic, right?
<barry> Ursinha-sprint: nothin' but! :)
<Ursinha-sprint> barry, brave man!
<Ursinha-sprint> I'm trying to have one instance of lp running on karmic but no success
<barry> Ursinha-sprint: or... crazy! :)
<Ursinha-sprint> it complains the lack of something.loom
<Ursinha-sprint> lol
<barry> Ursinha-sprint: hmm.  i haven't seen that.  do you have the full traceback or error?  note that this karmic was not an upgrade, it was a fresh install
<Ursinha-sprint> barry, hmm, I don't have it here now, only in my eeepc
<Ursinha-sprint> that was a fresh install with alpha 5 and I've been updating that since then
<barry> Ursinha-sprint: dang.  yes, that's basically what i did too.  it definitely works (though i haven't tried building anything today yet)
<henninge> abentley: ping
<abentley> henninge: pong
<henninge> abentley: Hi, there still seems to be a problem with the job system.
<abentley> henninge: What is the problem?
<henninge> abentley: Even with thumper's latest patch, we still have jobs stuck in "running".
<henninge> abentley: https://pastebin.canonical.com/22916/
<henninge> abentley: I can relate the rosetta-branches cases (job_type=3) to OOPSes in the script.
<abentley> henninge: Is the database reaper tearing down the DB connection in those cases?
<henninge> abentley: I don't know. How would I be able to tell?
<abentley> henninge: It would show in the oops and the log.
<abentley> henninge: Can you point me at an example oops?
<mrevell> night all!
<rockstar> abentley, hi
<abentley> rockstar: hi
<rockstar> abentley, chat?
<abentley> sure
<sinzui> barry: ping
<barry> sinzui: pong
<sinzui> barry: I am hacking on announcement headings and titles. Look at https://edge.launchpad.net/launchpad-project/+announcement/3450
<sinzui> barry: ^ Do I need to add a Heirarcy to set the traversed objects for the page title? There are no breadcrumbs
<barry> sinzui: if there are no breadcrumbs, then i don't think you need a hierarchy just for the page title.
<barry> sinzui: but in this case why is there not breadcrumbs?
<sinzui> barry: I do not think a breadcrumb is need (yet) because I want to see
<sinzui> Launchpad Registry >> Annoucement: I did something cool
<sinzui> barry: That is what I am asking you. I do not know why there ar no breadcrumbs in any context
<barry> sinzui: right, that's what i think i'd like to see too
<barry> sinzui: ah
<barry> sinzui: so the default hierarchy probably should work for you.  i wonder why it's not
<barry> sinzui: isn't launchpad-project the root context?
<sinzui> It is
<sinzui> hmm
<sinzui> barry: is canonical url used in hierarchy? I ask because series and milestone do not have a hierarchy, but their canonical URL define the parent object
<barry> sinzui: not directly.  Hierarchy looks for an IBreadcrumb for each object that has been traversed in the request.  it's built from those
<barry> sinzui: perhaps put a break point in Hierarchy lib/canonical/launchpad/browser/launchpad.py and see if def items() gets hit?
<sinzui> Thus we have no traversed objects...because launchpad-suite is not in being shown
<barry> sinzui: it could be a problem with the template, or perhaps there's a custom +hierarchy adapter?
<sinzui> ahh
 * sinzui looks
<sinzui> no
 * barry is not sure what "no" means
<sinzui> I do not see anything suppressing the breadcrumbs
<sinzui> There is no Hierarchy or Breadcrumb adapter.
<barry> sinzui: you said above there are no traversed objects.  do you mean that request.traversed_objects is empty when you hit Hierarchy.objects() ?
<sinzui> barry: I assume there are not because I cannot explain why there are no breadcrumbs
<barry> sinzui: best thing to do is put a breakpoint in Hierarchy.items() and see what happens
<sinzui> barry: I started looking at this when I saw the team membership pages were also missing breadcrumbs. That bug mentions both Hierarchy and Breadcrumb, but if neither of these are the case, we have a much harder problem to fix these.
<barry> sinzui: bug number?
<sinzui> barry: bug 429663, you filed it
<mup> Bug #429663: ~team/+invitation/team does not have breadcrumbs <post-3-ui-cleanup> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/429663>
<barry> ah yes, looks like you have the same problem.  this is a more general problem for which we do not yet have a fix
<sinzui> hmm
<sinzui> Well Hierarchy is seeing the Project, Announcement, and View in the correct order
<sinzui> When I solve this, I think I will take the team bug too
<barry> sinzui: hopefully there will be a generic fix for this
<sinzui> barry: I see I misunderstood the direction the breadcrumbs are made
<sinzui> barry: project has one, announcement does not. Since there is only one, we are not showing any
<barry> sinzui: right
 * barry -> otp
 * rockstar lunches
<dobey> hrmm
<dobey> what does "Nominated for Trunk by <$user> (approve/decline)" mean on a bug?
<sinzui> barry: Answer is simple, though the rule is not clear. We need to register TitleBreadcrumb for every object that uses .title.
<sinzui> dobey: It means you are asking a series driver/release manager to commit to fixing a bug during the development of that series
<dobey> sinzui: so in other words, it makes absolutely no sense at all, since "trunk" should always be in development :)
<sinzui> dobey: Yep! If you use milestones to target bugs, the bug will wrong be associated to a series. I never use this feature. I would like to remove it
<sinzui> s/wrong/wrongly/
<dobey> sinzui: yeah, i've never even seen it before until today, when someone who hasn't ever even commented on the bug, decided to nominate it for trunk
<barry> bac: sorry about that, ready to continue?
<barry> sinzui: can we do a generic fallback for TitleBreadcrumb?
<sinzui> no. I think the fallback is to DisplayNameBreadcrumb. I saw thast everything that has a .title also has TitleBreadcrumb in zcml
<barry> sinzui: i'm just worried that if we have a lot of views using title, that's a lot of extra zcml hacking too
<sinzui> title is rare compared to displayname.
<barry> sinzui: right
<sinzui> Title is arguably bogus because in most cases we construct it
<barry> sinzui: agreed.  sounds like a plan
<sinzui> for announcement, headline is actually title
<sinzui> hmm
<sinzui> oh
<sinzui> barry: maybe announcement is wrong because it does not have a displayname. just a headline presented as a title
<barry> sinzui: what if you added a @property for displayname that returned the title?  or is that too ugly of a hack? :)
<sinzui> I am doing that now :)
<bac> barry: yes
<barry> sinzui: excellent :)
<barry> bac: calling
<sinzui> EdwinGrubbs: ping
<sinzui> EdwinGrubbs: unping
<rockstar> mwhudson, when you're around, ping.
<mwhudson> rockstar: hello
<rockstar> mwhudson, morning.
<rockstar> mwhudson, so I'm working on getting the branch upgrade job stuff working with the upgrade-out-of-the-way concept.
<mwhudson> rockstar: oh right
<rockstar> mwhudson, abentley says that we'll be doing the upgrades on crowberry, which is fine.  However, I'm not sure how where to sprout the branch that needs to be updated.
<rockstar> mwhudson, I'm wondering if we have a helper function to figure that out yet.
<mwhudson> rockstar: tempfile.mkdtemp() ?
<abentley> rockstar: I'd be inclined to mkdtemp.
<mwhudson> rockstar: or am i misunderstanding?
<rockstar> mwhudson, abentley, I thought we saw something where it was leaking file references in a reviewers meeting recently.
<abentley> mwhudson, rockstar: I suppose a confounding factor is that we'd like to do it on the same partition.
<mwhudson> abentley: yeah, that's true
<abentley> rockstar: Not mkdtemp.
<rockstar> abentley, after looking at the docs, I must have been confusing temp dirs and temp files.
<rockstar> abentley, does it really need to be done on the same partition?
<abentley> rockstar: It doesn't have to be done on the same partition, but if it's not, it's more expensive to rename into place because the rename is actually copy & delete.
<rockstar> abentley, yeah, I guess you're right.
<abentley> rockstar: And that also leaves a larger window for race conditions.
<abentley> rockstar: If you create it in .bzr/new, nothing bad will happen.
<EdwinGrubbs> beuno: Here is an example of a custom scrollbar that the yui slider could be styled to look like: http://wave.google.com/help/wave/images/ss2.gif
<beuno> EdwinGrubbs, that may work better
<Ursinha> rockstar, sure :)
<rockstar> Ursinha, hm, it looks like I can branch that url.
<Ursinha> rockstar, stupid doubt: if I change something in the lp branch, by pushing code to it, will it be mirrored to the original place?
<rockstar> Ursinha, no, in fact, I don't think you can push to a mirrored branch.
<Ursinha> rockstar, well, I'm not able to branch his branch, get:
<Ursinha> bzr: ERROR: Server sent an unexpected error: ('error', "An attempt to access a url outside the server jail was made: 'chroot-182925242704:///'.")
<rockstar> mwhudson, ^^
<mwhudson> rockstar: ah :)
<rockstar> Ursinha, are you branching from lp?
<mwhudson> <mwhudson> rockstar, Ursinha: i think that error means a badly configured bzr+http server
<rockstar> mwhudson, :)
<Ursinha> :)
<mwhudson> rockstar: bzr info nosmart+http://bzr.malept.com/bazaar-overlay/ works
<Ursinha> rockstar, nope, I'm trying to branch from the original branch
<Ursinha> of course :)
<rockstar> Ursinha, ah, okay.  So not-our-problem problem.  Those are my favorite kind.
<Ursinha> rockstar, bad boy
<rockstar> Ursinha, so my initial assumption was correct, and it's a problem with the source.
<Ursinha> but what mwhudson, being able to do a bzr info shows what?
<Ursinha> *what mwhudson said
<mwhudson> Ursinha: it's a problem with the smart server on their end
<Ursinha> mwhudson, is that a way to workaround it, besides asking the user to fix his server?
<mwhudson> Ursinha: well i guess bzr could fall back to the dumb protocol, but basically no
<Ursinha> hm
<Ursinha> maybe we need a better error message in the branch page?
<mwhudson> it's not formatted very nicely i guess
<Ursinha> this message makes everyone think that the problem will be fixed for itself
<Ursinha> or that nothing needs to be done
<mwhudson> well, unless you're the one running the server, there isn't much that can be done
<Ursinha> mwhudson, I mean, the message says that
<Ursinha> maybe we should show the error just like it's done with the imports?
<mwhudson> that would be better, yes
<Ursinha> mwhudson, well, I'll file a bug then
<rsalveti> because there's no error saying that the main server is off or with problems
<rsalveti> it's just "updating" hehe :-)
<Ursinha> rsalveti, I think it should be better if displayed like when we have import errors
<rsalveti> Ursinha: cool :-)
<Ursinha> it has a message saying that it failed and the log
<Ursinha> s
<rsalveti> Ursinha: yep, because the current message let me think that this was a problem with launchpad itself
<Ursinha> rsalveti, maybe you should contact the owner and ask him to fix that
<Ursinha> or host it in lp itself
<rsalveti> I just noticed that it's using a mirror now that rockstar showed the external link
<Ursinha> because it's bzr, no need to do that :)
<rsalveti> Ursinha: yep, to fix the branch, yes
<Ursinha> in fact there's already a bug, it seems
<Ursinha> bug 376229
<mup> Bug #376229: broken mirrored branches display "  Launchpad is processing new changes to this branch and will be available in a few minutes. Reload to see the changes." message <branch-puller> <ui> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/376229>
<mwhudson> Ursinha: oh, i had't scrolled down that far
<mwhudson> :)
<Ursinha> :)
<Ursinha> thanks mwhudson and rockstar
<Ursinha> much appreciated :)
<gary_poster> mwhudson: well, good news, though it makes me a bit nervous :-P .  My bin/py script (a faux interpreter that can do most of the important interpreter tricks), generated from my zc.buildout branch, runs ``time ./bin/py -c ''``, um, about twice as fast as python24 on my system.  So, assuming it does everything we need, that may help a lot.
<mwhudson> gary_poster: ah, cool
<mwhudson> gary_poster: twice as fast as python2.4 -c pass or bin/py from trunk?
<gary_poster> mwhudson: how important is this?  If I'm right that this works fine, and this puts codehosting back to the previous level of performance is this CP-worthy, for instance?
<gary_poster> twice as fast as python 2.4
<maxb> site.py sure does do an awful lot of weird stuff :-)
<gary_poster> heh, true
<mwhudson> gary_poster: i'm slightly inclined against the cherrypick
<mwhudson> noone has actually complained, we've just looked a bit bad :)
<gary_poster> mwhudson: ok.  that means it's more easy going for me. :-)
<gary_poster> mwhudson: but I'll get this in and ping you in case you want to run some tests
<mwhudson> gary_poster: yeah, very interested to see this land
<gary_poster> cool
<gary_poster> barry: hey, just so you know, I'm in the process of changing bin/py from a shell script with PYTHONPATH hack to a Python script (with its own fun ;-) ).  So if you have not landed the mailman buildman change, then we should coordinate, in case my change messes up your plans.
<gary_poster> ...this reminds me that I may need to change _pythonpath.py ...
<gary_poster> but anyway, feel free to talk
<barry> gary_poster: it should be landed now.  sounds interesting though :)  why do you think you'll need to change _pythonpath.py?
<gary_poster> barry: ok, cool.  If make builds and tests pass then I'll be happy. :-)  I'll maybe want to change _pythonpath to make it more careful, the way I had to change the buildout-generated scripts, to handle namespace packages and so on.
<gary_poster> Handling dist-installation-style namespace packages and normal-installation packages in the same namespace require some excessively careful dances. :-/
<gary_poster> requires
<barry> :/
<gary_poster> barry: I was reading about Py 2.6.3 fun.  :-(
<barry> gary_poster: you probably want to run bin/test --layer=MailmanLayer even though the tests are not entirely stable
<gary_poster> and setuptools
<barry> gary_poster: it's what makes open source so rewarding :)
<gary_poster> barry: ah!  ok will do thank you
<gary_poster> barry: lol :-) :-/
<sinzui> This is new. The test suite just opened up the help manual for  gnome terminal when the test failed.
 * sinzui hopes this is not a karmic freature
<barry> sinzui: ouch.  which test?
<sinzui> xx-announcements
<barry> sinzui: of course it doesn't fail for me, but i've never seen that (and i've seen lots of test failures on karmic :)
<sinzui> barry: My change to remove an ancient page_title broke more than I anticipated. I suspect a view was shared by several templates.
<gary_poster> mwhudson: oh, bah.  :-/  I had clunked my change.  I was testing an earlier version that didn't do all the necessary dances.  With the completely new mechanism, doing the proper dance as I currently understand the steps, we're back to one-order-of-magnitude-ish slower. So, my change will fix some problems, but it is not faster.
<gary_poster> OTOH, it also is not (even) slower, so that's at least something, from my perspective.  If the codehosting could use a significantly smaller subset of packages than the whole thing Launchpad needs, we could experiment with a callable just for that purpose...but a pre-forking process would be the better solution long-term anyway I suspect.
 * gary_poster runs to dinner
<gary_poster> good night all
<mwhudson> gary_poster: ah well
<mwhudson> gary_poster: bye for now
<gary_poster> bye
<barry> sinzui: :(
#launchpad-dev 2009-10-06
 * mwhudson lunches
 * mwhudson EODs
<adeuring> good morning
<jml> good morning
<jml> I would like inline commenting on merge proposals please.
<noodles775> :)
<mrevell> Morning!
 * jml frowns
<jml> I had somehow removed launchpad-developer-dependencies.
<wgrant> bigjools: So, since cprov disappeared rather unexpectedly, I guess I should talk to you about the ddeb stuff at some point.
<bigjools> wgrant: yeah, I guess.   how are you doing?
 * jml out grabbing food.
<wgrant> bigjools: I haven't done anything on it lately. The next step is to link the ddebs to their debs at upload time. I recall we last time got into a bit of a war about nullable references vs. link tables... But I think the actual implementation should be pretty easy, now I know how most of nascentupload works.
<bigjools> okay
<bigjools> nullable FK is fine here
<bigjools> my main concern is making sure we don't miss any code that does stuff with binaries
<wgrant> Right.
<bigjools> I hope most of it can be encapsulated in the bpph class
<wgrant> I imagine it will have a property that gives a list of publications to drag along.
<wgrant> But ISTM that it would be a bit evil to have BPPH.remove() (or whatever it is) silently drag along a ddeb.
<bigjools> well more than that, I want to make sure the operations themselves are all done in the model class
<bigjools> why?
<wgrant> Removing and deleting packages would then operate on some binaries without telling anybody.
<bigjools> that's precisely what we want
<wgrant> But I guess that's reasonable if you consider the DDEB to really be part of the DEB.
<bigjools> yes, they're joined at the hip
<wgrant> I was thinking that they would at least have to be exposed in NBS, but I guess that's not the case if we in fact have the new DEB also supersede the DDEB.
<wgrant> (otherwise an orphaned DDEB would be left around in the case that a binary ceased to have a DDEB)
<bigjools> yep
<bigjools> this is why I think it should be all done in the publishing class
<wgrant> Now that I realise they needn't even be seen in NBS, it seems reasonable to hide them entirely.
<bigjools> but we'll need to audit the code to check for anything that is cheating and not using methods on the class to change things
<wgrant> Right.
<wgrant> I hope and presume it's reasonable to reject an upload if it contains an orphaned DDEB, but I must check that with distro folks...
<jml> hey
<jml> wasn't there a patch a few days ago to make merge proposal status editable in the same way as every other editable thing in Launchpad?
<jml> allenap, hello
<allenap> jml: Hello
<jml> allenap, would you like to have a chat today about ec2 & what-not.
<allenap> jml: Yes, that would be great. After lunch, say 1330?
<deryck> Morning, all.
<jml> allenap, perfect.
<allenap> jml: Great :)
<allenap> Morning deryck :)
<mwhudson> jml: i think rockstar said it failed tests
<mwhudson> jml: good morning btw
<jml> mwhudson, hello.
<jml> mwhudson, you were right about codeimport pagetests failing, btw :)
<mwhudson> jml: i'm glad my crystal ball is still operational
<mwhudson> (not that it required much clairvoyance to see that one coming)
<jml> heh
<jml> mwhudson, I'll look at the branching ubuntu diff now while you're online
<allenap> mwhudson: I've done the paperwork for jscheck-maturity (https://code.edge.launchpad.net/~mwhudson/lpbuildbot/jscheck-maturity/+merge/12914) - is it worth trying this out in the staging buildbot? And are the LOSAs the people to talk to about it?
<jml> IBranchNamespaceSet's API needs to be cleaned up.
<allenap> mwhudson: Also, did you shepherd the buildbot upgrade last week, or should I look into that?
<mrevell> allenap: Hi
<allenap> mrevell: Hello.
<wgrant> bigjools: Any preferences for the BPR column name?
<bigjools> wgrant: ddeb_package ?
<wgrant> bigjools: I was going to go the other way, but OK.
<mwhudson> allenap: i did not
<allenap> mwhudson: Do you plan to? If not, should it be reasonably straightforward?
<allenap> For me to do.
<mwhudson> allenap: it would be good for you to do it
<mwhudson> allenap: particularly as spm isn't around this week
<allenap> mwhudson: So, if I understand correctly, spm has context for this, so I should do it next week with him?
<jml> kiko, good morning.
<kiko> morning jml
<kiko> how are you doing?
<jml> kiko, well thanks :)
<jml> I still can't get your phone to work though, because everyone in the world is ganging up on me to prevent me from having a phone of any kind.
<jml> it's fate.
<kiko> jml, what happened to it? that's sad.
 * bigjools reboots after update
<jml> kiko, the phone is physically ok. but O2 won't take my money, or my bank won't give it to them, or something.
<kiko> jml, you should have taken my prepaid
<jml> kiko, I should have.
<kiko> it even had credit!!!
<jml> allenap, ping
<allenap> jml: pong
<allenap> jml: Just getting skyped up
<allenap> jml: I'm gavinpanella on Skype.
<jml> allenap, added.
<gary_poster> BjornT: hey.  we missed our call
<BjornT> gary_poster: indeed. when are you free today?
<gary_poster> BjornT: mm, could make a 10 minute call in 15 or 20 minutes.  Would that work for you?  I'm booked after that till your EOD, I think.
<BjornT> gary_poster: yes, that would work for me. ping me when you're ready
<gary_poster> BjornT: cool, will do
 * jml gets food.
<gary_poster> BjornT: ping
<BjornT> gary_poster: hi
<BjornT> gary_poster: https://dev.launchpad.net/TechnicalArchitect
<allenap> abentley: Have you taken the "Approved" status away from merge proposals? I can't set https://code.edge.launchpad.net/~allenap/lpbuildbot/avoid-deadlock/+merge/12921 to approved, nor can gmb.
<abentley> allenap: No.  Are you on the reivew team?
<abentley> allenap: It says "community" beside gmb, so he's definitely not.
<allenap> abentley: I don't know. I did look earlier to see if I was able to set the review team, but I guess I don't have the evil to do it. The reviewer defaults to ~launchpad-pqm.
<abentley> allenap: The review team for ~launchpad-pqm/lpbuildbot/trunk is launchpad-pqm.
<jml> maybe the page should say "Members of ~FOO can approve this merge proposal for landing." even with an edit link.
<allenap> abentley: Is that a per-branch or per-project property?
<abentley> allenap: it is a per-branch property, on the target of the merge proposal.
<abentley> jml: Yes, now that review team is more than a default, it should be indicated.
<abentley> jml: I'd worry that an edit link would not make it clear that all merge proposals for ~launchpad-pqm/lpbuildbot/trunk would be affected by the change.
<allenap> abentley: Are you able to set it for lp:~launchpad-pqm/lpbuildbot/trunk and .../staging? If so, please could you set it to ~launchpad? I can't edit those branches.
<jml> abentley, good thought. perhaps the edit dialog could make that clear.
<abentley> allenap: done.
<allenap> abentley: Thank you :)
<jml> how do I call a python function from a template?
<allenap> jml: "python: function()" <-- is that what you're looking for?
<jml> allenap, yeah, that's it :)
<allenap> jml: Cool. Btw, no-arg functions will be called in TAL expressions too.
<jml> allenap, yeah. I discovered that to my chagrin.
 * jml dislikes that feature.
 * jml sneaks in a bit of naughty hacking.
 * jml afk.
<jml> how do I interrupt a page test and start that version of Launchpad in my browser
<jml> any clues?
<bac> jml: is that barry's 'stop' trick?  or is that for doctests?
<jml> bac, it might be...
<jml> bac, what's barry's stop trick?
<bac> jml: https://dev.launchpad.net/Debugging
<jml> bac, thanks.
<bac> i thought barry might come around and discuss it if we mentioned barry enough times.
<jml> that's ok. I think I can figure it out from here.
<barry> whuh?
<jml> barry barry.
<barry> jml: https://dev.launchpad.net/Debugging
<jml> barry, thanks. :)
<barry> np :)
<jml> should I keep saying "barry"?
<barry> jml: please!  i don't hear that boing! sound enough
<jml> heh :)
<barry> jml: of course, getting kicked and reconnected generates about a dozen of them, so i try to do that often
<jml> :D
 * jml frowns.
<gary_poster> abentley: I'm writing a quick email to the Zope group about bzr 2.0.  do I understand correctly that we don't yet have a release with Ian's work on the cross-platform line ending normalization?
<abentley> gary_poster: I don't think that's correct.  I think it's implemented, but still a work-in-progress.
<gary_poster> abentley: oh, ok, so it works in 2.0 with quirks? (no need to specify said quirks if I get the gist, unless you have them on-hand)
<abentley> gary_poster: I think so, but I haven't been following closely enough to be certain.
<gary_poster> abentley: cool  thank you.  I'll try to find the pertinent bug and go from there.
 * rockstar lunches
<jml> mwhudson, I'm guessing you aren't awake yet.
<jml> g'night all.
<jml> mwhudson, fwiw, the question is about code import authorization & branch ownership & how they interact.
<lifeless> jml: gnight
<gary_poster> barry: Is much Python run before mm_cfg.py?  Specifically, will sys.modules be populated with any imports?
<barry> gary_poster: in a way it depends.  mm_cfg.py will almost always be the first Mailman package that gets loaded.  when mailmanctl is used though, sys, os, time, getopt, signal, errno, pwd, grp, socket are all loaded first
<gary_poster> barry: hm.  do you have a second to talk on Skype, so I can get your opinion on _pythonpath change?  Will try to be fast
 * gary_poster wants barry to have time to switch us to Mailman 3
 * barry wants that too!
 * gary_poster figgered :-)
<jamalta> is it ok if i update the url to the rocketfuel-setup script in the "Get the source code page" to  ?
<jamalta> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head%3A/utilities/rocketfuel-setup
<jamalta> the current url doesn't work..
 * jamalta isn't even sure if he can update the wiki
<beuno> jamalta, it does work
<beuno> codebrowse is a bit flaky at the moment
<jamalta> beuno: really? odd.. it's not working for me
<jamalta> ah ok! understood
<beuno> so that URL may fail sometones
<beuno> sometimes
<beuno> wow, that was an interesting typo
<jamalta> lol
<jamalta> also just realized that the url i pasted wouldn't be correct either
<beuno> I clicked on that URL, and it works just dine
<jamalta> yeah, but that's more than just the rocketfuel-setup
<rockstar> Do we have any documentation on what each testing layer provides?  I'm wondering if I'm really using the best layer for my test.
<kfogel> leonardr: ping
<leonardr> kfogel, hi
<kfogel> leonardr: https://code.edge.launchpad.net/~kfogel/launchpadlib/426323-apidoc-html-title-attrs/+merge/12442 -- barry asks a question that you might be able to answer, in his review.
<kfogel> leonardr: I'm basically ready to merge, depending on whether tests are needed for this sort of change.
 * barry is otp
<leonardr> kfogel, i'm looking
<kfogel> leonardr: thx
<kfogel> barry: (no need to chime in, I just mentioned your name in passing)
<leonardr> kfogel, comment added
<kfogel> leonardr: if my primary goal is to just land the thing, would you say that's okay to do?  (I think your suggestions about tests are very sane, but at the same time... this isn't code, and I don't want to spend a lot of time writing tests if they're not really needed.)
<leonardr> kfogel: yeah, just land it
<kfogel> leonardr: that's what I think too :-)
 * mwhudson hadn't edited a page test for a while ....
<mwhudson> gosh, the ate
<mwhudson> ^h
<kfogel> leonardr: can I put you down in "[r=barry, leonardr]" in this?
<leonardr> kfogel, sure
<kfogel> leonardr: thx.  Landed.
<jml> ec2 land!!!1!
<kfogel> jml: ?
<jml> oh wait, it's not launchpad.
<jml> never mind.
<kfogel> jml: did you just use ec2land to land a change to ec2land?
<jml> kfogel, no, although I used it to land itself.
<kfogel> jml: btw, that open merge proposal on launchpadlib you asked me about earlier?  It's landed now.  (https://code.edge.launchpad.net/~kfogel/launchpadlib/426323-apidoc-html-title-attrs/+merge/12442)
<jml> kfogel, cool.
<mwhudson> heh heh
<mwhudson> doing bzr diff -r 3 when you meant diff -r -3 is a bit surprising
<wgrant> Particularly when you're on a slow remote SSH session.
<mwhudson> it actually was quite quick, considering
<mwhudson> a million lines of diff in 8 seconds
<wgrant> Not bad.
<mwhudson> yeah
<mwhudson> wouldn't get that from packs, i bet
<mwhudson> what's the fix for TypeError: a float is required with python2.6 and httplib2 ?
<wgrant> mwhudson: Use the packaged one.
<mwhudson> wgrant: i think i am
<wgrant> mwhudson: That was patched mid-Jaunty.
<mwhudson> hm
<mwhudson> wgrant: i have 2.6.2-0ubuntu1
<wgrant> Anyway, http://launchpadlibrarian.net/23324641/python-httplib2_0.4.0-0ubuntu1_0.4.0-0ubuntu2.diff.gz
<wgrant> mwhudson: It's a seperate package. python-httplib2
<wgrant> 0.4.0-0ubuntu2 is fixed.
<mwhudson> oh
<wgrant> But you might be using an egg.
<mwhudson> not in this case
<mwhudson> hm i have 0.4.0-1
<mwhudson> where did that come from, i wonder
<wgrant> apt-cache policy python-httplib2
<mwhudson> wgrant: http://pastebin.ubuntu.com/287375/ ?
<wgrant> If that doesn't show anything useful, I guess check /usr/share/doc/python-httplib2/changelog.Debian.gz
<wgrant> Hmm.
<wgrant> What does the changelog say?
<mwhudson> wgrant: 0.4.0-1 seems to be from hardy
<mwhudson> python-httplib2 (0.4.0-1) hardy; urgency=low
<mwhudson>   * Build a single package for all architectures as it's arch-indep.
<mwhudson>  -- Launchpad package maintainers <launchpad@lists.canonical.com>  Wed, 11 Jun 2008 10:33:49 -0300
<wgrant> Gnargh.
<matsubara-afk> after updating to karmic, I'm getting a ImportError: No module named tickcount when I try to make run. is this known?
<wgrant> ~launchpad's PPA for Hardy has a broken version string.
<wgrant> Too late now.
<wgrant> mwhudson: apt-get install python-httplib2/karmic
<mwhudson> wgrant: ah
<mwhudson> wgrant: i'm still on jaunty, but i can figure out the change :)
<wgrant> matsubara-afk: `apt-cache policy python-tickcount`
<matsubara-afk> wgrant, http://pastebin.ubuntu.com/287377/
<wgrant> matsubara-afk: You don't have the ~launchpad PPA in your sources.list?
<wgrant> The dist-upgrader could well have disabled it.
<matsubara-afk> wgrant, oh! you're right! let me check and thanks!
<wgrant> matsubara-afk: Might not fix it (Karmic seems to have the same version as Jaunty), but we'll see.
<matsubara-afk> wgrant, btw, is there a easy way to renable everything I have in /etc/apt/sources.list.d/?
<mwhudson> wgrant: thanks
<wgrant> matsubara-afk: Not really. The "easiest" way might be to check lots of checkboxes in System Â» Administration Â» Software Sources.
<matsubara-afk> wgrant, ok, re-enabled the ppas and now am running a sudo apt-get update && sudo apt-get upgrade. that should do it, right?
<wgrant> matsubara-afk: As long as you also s/jaunty/karmic/ in each PPA line.
<matsubara-afk> wgrant, yes, they were already updated to karmic by the dist upgrade but kept commented out
<wgrant> matsubara-afk: Ah, right.
<wgrant> matsubara-afk: You should be fine, then.
<matsubara-afk> ok, bunch of python packages coming from ppa.launchpad.net, so let's wait and see :-)
<matsubara-afk> thanks wgrant
<wgrant> np
#launchpad-dev 2009-10-07
 * mwhudson lunches
<rockstar> mwhudson, yo
<mwhudson> rockstar: hi
<rockstar> mwhudson, https://code.edge.launchpad.net/~vcs-imports/libvdpau/master WTF?
<mwhudson> rockstar: i don't know
<mwhudson> often that means there's whitespace at the end of the url, but that doesn't seem to be the case here
<mwhudson> rockstar: it's also possible that it's a ~ vs %7E thing...
<rockstar> mwhudson, *groan*
<rockstar> mwhudson, that would seem to me that it would be the git server's issue.
<mwhudson> rockstar: well just guesswork at this stage
<mwhudson> i'll try it i guess
<mwhudson> rockstar: nope, no difference
<mwhudson> amusing
<mwhudson> open thunderbird, 'select all' in a large email, switch to terminal, run xsel -o
<mwhudson> --> thunderbird exits
<mwhudson> gmb: i'm sure you shouldn't be on facebook right now
 * mwhudson eods
<al-maisan> Good morning!
<mrevell> Hi!
<adeuring> good mornin
<jml> good morning
<deryck> Morning, all.
<jml> good morning deryck
<jml> I just saw bug 445302
<mup> Bug #445302: dashed names wrapped in the tag cloud <Launchpad Bugs:New> <https://launchpad.net/bugs/445302>
<jml> and I'm wondering whether there is a way for us to make sure that we never ever ever wrap on dashes in links.
<jml> BjornT, ^^^ ?
<bigjools> jml: use a nowrap style?
<bigjools> james_w: would you be interested in going to a sprint to help us design BFB?
<james_w> sure
<bigjools> james_w: would December 7-11 work for you?
<james_w> indeed it would
<bigjools> cool - it might be a bit too late to do it then but UDS and other things get in the way :/
<bigjools> I suppose we could have a session at UDS as well
<james_w> yeah
<james_w> we can certainly spend some time discussing it there
<jml> Dec 7-11?
<jml> hmm.
<jml> bigjools, are you thinking NZ?
<bigjools> jml: no
<henninge-sprint> mrevell: Hi! ;) Please assign questions for translations to "rosetta-admins" instead of a single member of the team.
<bigjools> Europe, prob London again
<mrevell> henninge-sprint: will do
<jml> bigjools, hmmm.
<henninge-sprint> mrevell: cheers
<bigjools> jml: wassup?
<jml> bigjools, I'm in .au that week.
 * bigjools facepalms
<jml> bigjools, I can reschedule the flights though.
<jml> actually, no I can't. Got to be at a wedding on the 12th.
<bigjools> jml: it's a real headache organising this because of other sprints
<jml> bigjools, yeah, I'll bet.
<bigjools> the other options is to do it before 3.1.10 finishes
<bigjools> flacoste was against that, but if it's easier then we have little choice
<jml> bigjools, I think I agree with you.
<bigjools> jml: we should have kept tim here for another week...oh well
<bigjools> jml: so, fancy approving my MP? ;)
<thumper> bigjools: that would not have happened  :)
<jml> bigjools, I'll take a look at it :)
 * thumper is configuring quassel
<thumper> and not working
<bigjools> ah thumper!
<thumper> new laptop :)
<bigjools> I don't think we're heading to NZ
<bigjools> how is it?
<thumper> fast
<thumper> but webcam isn't working in karmic
<jml> bigjools, if the sprint were in NZ, I could attend on the Dec dates :)
<bigjools> it would make it more awkward for others though
<bigjools> but I will bear it in mind
<jml> bigjools, do you want to talk about this DB patch?
<bigjools> jml: yes
<jml> bigjools, would you prefer phone, email or IRC?
<bigjools> jml: call me again if you like
<jml> ok.
<gary_poster> allenap: ping?
<allenap> gary_poster: pong
<gary_poster> allenap: hi!  It looks like I was the one missing a crucial detail in the MP, sorry about that.  That said, if you want to change the script to use Python 2.5 and be run with buildout, I think we could pretty easily.
<gary_poster> But anyway, would you like to have a build engineer coordination call sometime today?  I'm not sure when your EOD is, but I could talk at 15:30 UTC or sometime between 18:00 and 19:00 UTC
<allenap> gary_poster: 1530 UTC would be grand.
<gary_poster> allenap: cool!  I'll put it on the calendar
<BjornT> jml: i'm sure there's a way not to wrap on dashes (for web pages); we've spent a lot of effort trying to get things to actually wrap :)
<jml> BjornT, yeah. I'm mostly anxious for us to solve this problem exactly once :)
<intellectronica> BjornT, jml: i think `a {whitespace: nowrap}` might be the fix for all links (haven't tried it yet, though)
<intellectronica> jml: what about branch paths, though? do you really want to avoid wrapping them? sometimes wrapping links is useful
<BjornT> jml: it's not that simple, since we actually want some links to wrap, i think
<jml> intellectronica, that would work if we never want to wrap links, which is a different thing from not wanting to wrap on '-' in links.
<BjornT> jml: i.e., we've tried to solve this problem once already, but in the opposite direction!
<intellectronica> jml: right. i don't know if there's a way to solve that. i somehow suspect there isn't. we should ask martin - he knows more about css
<jml> BjornT, heh
<jml> BjornT, so it's a matter of tweaking our solution?
<BjornT> jml: yeah, i think so
<sinzui> barry: bug 246564
<mup> Bug #246564: Roles and status should have an "Edit" icon in the project homepage <javascript> <post-3-ui-cleanup> <ui> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/246564>
<barry> reviewers -> #launchpad-meeting in 3m
<barry> beuno: ping
<beuno> barry, hi
<barry> beuno: hi.  was just wondering if you wanted to come over to #launchpad-meeting and say a few things about ui?  intellectronica is giving a good summary right now.  if not, that's cool
<beuno> barry, I'm there, but on a call
<Fly-Man-> Morning all
<Fly-Man-> When is the next cleaning of the staging server planned ?
<beuno> Fly-Man-, it happens every 24hs, AFAIK
<Fly-Man-> beuno: so the next redoing will be tomorrow 9 AM UTC ?
<beuno> Fly-Man-, I don't know the time
<sinzui> bac; ready?
<bac> yes
<intellectronica> leonardr: hi. deryck and i are wondering what it would take to start using the latest version of restful in LP
<leonardr> intellectronica: we'd need to upgrade to python 2.5
<intellectronica> leonardr: in particular we're interested in getting r27
<deryck> ouch
<leonardr> because the new version uses the wsgi standard library
<intellectronica> leonardr: oh ok. so is the pragmatic solution to backport this change?
<leonardr> intellectronica: do you really mean r27 of lazr.restful? that's very old and not very interesting
<intellectronica> do you know what's the eta on py2.5?
<deryck> leonardr, it is interesting for bug 423924.
<mup> Bug #423924: Entity-body was not a well-formed JSON document when updating bug description <inline-description> <post-3-ui-cleanup> <Launchpad Bugs:In Progress by deryck> <https://launchpad.net/bugs/423924>
<deryck> which is causing a lot of pain for people
<intellectronica> leonardr: no, i'm talking nonsense
<intellectronica> leonardr: i mean http://bazaar.launchpad.net/~intellectronica/lazr.restful/unicode-errors-bug-331990/revision/27?start_revid=27
<leonardr> intellectronica: this is a branch you haven't landed yet?
<deryck> isn't this r27 of lazr.restful trunk?
<intellectronica> leonardr: i'm pretty sure i have. i'm trying to locate the landing
<intellectronica> deryck: no, that's my own branch
<leonardr> intellectronica, maybe you landed it on launchpad-pqm's branch instead of the lazr.restful trunk?
<deryck> bzr log -r 27 bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/lazr.restful/trunk/
<leonardr> aaargh
<deryck> that would be the case then, right?  Wrong branch?
<intellectronica> deryck: no, you're right, it is r27 of trunk too
<intellectronica> and the timing looks correct. so the question is, is this revision not used in LP yet? it's quite old
<intellectronica> and if it is, then obviously the fix doesn't work
<leonardr> intellectronica: when you say "it is r27 of trunk", what is the url of "trunk"?
<leonardr> r27 if lp:lazr.restful is this:
<leonardr> timestamp: Fri 2009-04-17 10:23:45 -0400
<leonardr> [r=gary] Add some features to the example web service necessary to test lazr.restfulclient.
<intellectronica> leonardr: the one owned by launchpad-pqm
<intellectronica> bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/lazr.restful/trunk
<leonardr> ok, i would say you already backported it
<leonardr> but didn't put it in the main release
<intellectronica> leonardr: but isn't the pqm-owned branch the one we're using in LP?
<leonardr> there's a chance that lazr.restful is now an external dependency and that we install it from an egg rather than using a pqm-managed branch
<deryck> intellectronica, leonardr -- yes, it's an egg.  eggs/lazr.restful-0.9.5-py2.4.egg/lazr/restful/_resource.py doesn't have this change.
<leonardr> we should get rid of the pqm-managed branch, it is confusing a lot of people
<intellectronica> ah ok, so we need to port this change to the new branch
<intellectronica> leonardr: yes, if it's no longer in use lets get it out of the way
<leonardr> it looks like revisions 27-30 were all applied to this branch
<leonardr> flacoste or gary_poster, can you confirm this? that ~launchpad-pqm/lazr.restful/trunk is not in use and should be destroyed so it stops confusing people?
<deryck> leonardr, by "applied to this branch" you mean the one in use by LP, or the one you want deleted?
<leonardr> deryck: revisions 27-30 of the pqm-managed branch were not landed on lp:lazr.restful
<intellectronica> right, so we need to forward-port those, and then get a new egg for LP?
<leonardr> yeah
<deryck> leonardr, right.  So is this just a matter of merging in those revisions and we'll be good?
<leonardr> yes, but 'get a new egg' is easier said than done due to the 2.5 thing
<deryck> ah, right.  crap.
<leonardr> the branches i have in review right now were meant to remove the 2.5 dependencies, but i couldn't remove all of them
<deryck> leonardr, at the least, can we get r27 from the pqm branch.
<intellectronica> i guess we could backport this into a branch right before the 2.5 deps are introduced. but that already gets quite complicated
<leonardr> gary will also know when the 2.5 work will be done. i think he's going to pair with someone next week to do it
<flacoste> leonardr: it's not in use and can be dropped
<leonardr> ok
<leonardr> i'll forward-port those 3 revisions, make sure there are no lost revisions, and then delete that branch
<leonardr> then we can figure out how to get it into launchpad
<intellectronica> leonardr: so can you take over the foundations task of bug #331990 ?
<mup> Bug #331990: The inline editor widget reports a JSON error when saving non-ASCII characters <javascript> <Launchpad Foundations:Triaged> <lazr.restful:Fix Released by intellectronica> <https://launchpad.net/bugs/331990>
<leonardr> well, i can take over the lazr.restful task
<leonardr> then we'll deal with the foundations task. but there's no reason why you should have to worry about it, you're just the person who happened to notice the problem
<intellectronica> leonardr: i'm not worried at all :) but i guess deryck wants to have the fix for this cycle. it now causes several bugs, not just the one we fixed before
<deryck> intellectronica, leonardr --exactly, but I can close bug 423924 as a dupe of 331990.  But I would like to see it this cycle, since the description field has cause for non-ascii frequently.
<mup> Bug #423924: Entity-body was not a well-formed JSON document when updating bug description <inline-description> <post-3-ui-cleanup> <Launchpad Bugs:In Progress by deryck> <https://launchpad.net/bugs/423924>
<kfogel> deryck: I saw you milestoned bug #397188 -- thanks!
<deryck> kfogel, np!  thanks for the poke about it.
<abentley> rockstar: http://ubuntuforums.org/showthread.php?t=973830
<gary_poster> leonardr: sorry it took so long to reply.  Is everything dealt with already?
<leonardr> gary: no, i'm still not clear on how to make a custom egg for launchpad
<gary_poster> leonardr: doc/buildout.txt in Launchpad has instructions on how to do this.  I'm also happy to answer questions.
<leonardr> all right, i'll work on it once i land all the stuff i've already got in the air
<gary_poster> leonardr: cool
<BjornT> gary_poster: speaking of buildout, can you take a look at https://code.edge.launchpad.net/~bjornt/lazr-js/buildoutification/+merge/13003 when you have time?
<BjornT> flacoste: you might be interested to take a look as well ^^^
<gary_poster> BjornT: will do.  I'll take lunch and then take a look.
<jml> hmmm.
<sinzui> bac: I sent my sketch of the captcha
<jml> sinzui, can you please forward to me also?
<sinzui> jml: sent
<leonardr> intellectronica, it looks like yours was the only fix that wasn't already in the main lazr.restful trunk
<intellectronica> leonardr: interesting. would you like me to prepare a branch, or have you already got one?
<leonardr> i've got one
<intellectronica> leonardr: cool, thanks
<leonardr> intellectronica: your test passes for me even when i don't make the change to _resource.py
<intellectronica> leonardr: oh
<mrevell> Night nurse!
<intellectronica> oh dear
<intellectronica> leonardr: so, do you think this was fixed independently, and the bug deryck was talking about it different? or is the test not good enough?
<leonardr> my gut feeling is the test isn't good enough
<leonardr> do you remember the test failing and then succeeding once you made that change?
<intellectronica> leonardr: tbh, no i don't remember, since i worked on it quite some time ago. i assume that was the case
<leonardr> if that's the error you're getting, you've correctly identified the problem
<leonardr> (ie. if "entity-body was not a well-formed json document" was the error)
<leonardr> can you reproduce the problem on the website and give me the string you used?
<intellectronica> leonardr: i'm trying to reproduce this with the old branch
<leonardr> actually maybe i ported the test wrong
<leonardr> yes, that was the problem
<leonardr> never mind
 * intellectronica sighs with relief
<beuno> deryck, ping
<deryck> beuno, hi
<beuno> deryck, hi. I'd like to have a quick chat about the activity link
<deryck> beuno, ok.  Skype?
<beuno> can we bring it back somewhere on the page, untul we have a conrete plan to show all the info?
<beuno> deryck, I think IRC will do, but we can jump to skype if it doesn't  :)
<deryck> beuno, sure, I'm not opposed to bringing it back.  Just didn't want to have to think about where to bring it back. :)  And honestly, I thought we'd have more time to do activity work, but having said that....
<deryck> beuno, I wanted to talk to you about the bug page anyway.  Should we just work on a proper design rather than worrying too much about the link now, and include the link as part of the new design work?
<beuno> deryck, how about at the end of the last comment?
<deryck> beuno, that's fine by me.
<beuno> well, mdz was very worried about this, so if we can make him happy very cheaply, it may be worth doing
<beuno> deryck, I'd love to talk about the bug page, I started a mockup on the plane  :)
<deryck> beuno, yes, it's cheap and trivial, we can do it this week.  But also, I would love to start thinking about the larger bug page design this week if we can.
<beuno> deryck, lets do both
<deryck> beuno, right, sounds good.
<deryck> beuno, can you comment on the bug for the activity link with your thoughts about positioning?  Then, I'll assign to this milestone.
<beuno> deryck, sure. Do you have the # handy?
<deryck> beuno, Bug #436818
<mup> Bug #436818: Bug Activity Log no longer linked in 3.0 UI <Launchpad Bugs:Confirmed> <https://launchpad.net/bugs/436818>
<beuno> deryck, thanks. And lets schedule a call as well
<deryck> beuno, ok.  what day/time works for you?  Or do you want to just schedule me via the Google calendars, and I'll confirm? :)
<beuno> deryck, I'll try the google calendar dance
<deryck> beuno, cool, thanks!
<leonardr> gary, when you have a minute, can you look at allenap's comment on one of my branches? he suggests a patch that i don't think is necessary, but i'm also not sure why it didn't work for him
<leonardr> it's at the beginning: https://code.edge.launchpad.net/~leonardr/lazr.authentication/initial-implementation/+merge/12989/comments/33576/+reply
<gary_poster> k looking
<leonardr> 1. if this is necessary, why doesn't lazr.restful have it? should lazr.restful have it?
<leonardr> 2. shouldn't it be in the dependencies in setup.py rather than in buildout.cfg?
<sinzui> I am feeling particularly dense today. I haver spent several minutes trying to get a 'smudge' of my screen. Meanwhile, the test I was running says it cannot decode a byte at position 22. Counting the line, I discover I types an acgraved 'Ã¹'
<gary_poster> 1. van.testing in lazr.restful depends on wsgi_intercept.  That said, if lazr.restful imports wsgi_intercept itself, then yes, lazr.restful should have a direct dependency as well, for style purposes.  But practically, the connection is an indirect one for lazr.resfful
<gary_poster> 2. yes, setup.py
<gary_poster> leonardr: ^^^
<leonardr> gary, thanks
<gary_poster> np
<bigjools> sinzui: lol
<leonardr> flacoste, i don't have permission to delete or move-out-of-the-way https://code.edge.launchpad.net/~launchpad-pqm/lazr.restful/trunk . can you do it or tell me who to talk to?
<leonardr> i'm gonna talk to herb in the meantime
<flacoste> leonardr: herb isn't a LOSA anymore, talk to Chex or mbarnett
<leonardr> ah, thanks
<bac> sinzui:  my gpg-agent problem was the use of pinentry-gtk-2.  when i hacked to use pinentry-x11 all is well.
<sinzui> hmm
<sinzui> bac: Thanks. I'll see if I can apply this knowledge to my calendar problem
<shrike_> anyone install launchpad on sheevaplug (arm cpu)?
<leonardr> gary: here's an idea. http://pypi.python.org/pypi/wsgiref
<leonardr> if wsgiref is the only thing stopping lazr.restful from working with 2.4, let's make it an external dependency
<gary_poster> leonardr: ah-ha!  there you go then.
<gary_poster> +1
<leonardr> i'll try to get it to work
 * rockstar lunches
<gary_poster> maxb: so you know, we are going to have a two week "sprint" (in quotes because it is virtual) of me and a couple of other Canonical people to get Launchpad on Python 2.5 (must have) and hopefully Python 2.6 (I have an extra person to help because of that goal).  It will be the next two weeks (week of Oct 12 and Oct 19).
<gary_poster> Let me know if/how you'd like to participate.  Even if you don't participate this time, your name will go in the halls of glory for the effort you've already made in this regard, but if you want to join in that would be fantastic.  I'll be doing some preparation the end of this week.
<maxb> gary_poster: Ah, thanks. I have been meaning to try to push on with some more of the Python 2.5 stuff, this is a good reason to stop getting distracted :-)
<gary_poster> maxb: cool :-)
<bac> hi barry
<barry> bac: hi
<mwhudson> goor morning
<kfogel> jml: ping
<kfogel> jml: (5 min or less question)
<barry> thumper, mwhudson, wgrant and any others -> #launchpad-meeting in 1m
<mwhudson> barry: thumper isn't around
<barry> mwhudson: ah.  do you still want to meet today?
<mwhudson> barry: um, i guess, though we're still standing up
<barry> mwhudson: oh, and rockstar
<barry> mwhudson: ping me when you're done
<barry> mwhudson: actually, give me 15m
<mwhudson> barry: cool
<rockstar> barry, we're done.
<barry> rockstar: ok.  now's a good time after all
<barry> mwhudson, rockstar, wgrant, anyone else -> #launchpad-meeting
<maxb> "Max, I think it's not daunting for you because, well, you're Max.  And Graham is also Max, or vice versa." --kfogel
 * maxb lols
<barry> bac ping
#launchpad-dev 2009-10-08
<bac> hi barry
<barry> bac hi
<barry> bac: i cleaned up the +review-license page.  wanna take a look?
<bac> barry: um, maybe tomorrow?
<barry> bac: sure thing
<bac> thx
<mwhudson> wow, email mountain digested, time for lunch then actual work!
<x-warrior> how can i help to develop launchpad? and how can i propose some ideas?
<rockstar> x-warrior, there's the launchpad developer's mailing list.
<x-warrior> rockstar, thank u I'm seeing the help page of launchpad now, reading it, and downloading the launchpad sourcecode ;)
<rockstar> mwhudson, how do you tell a branch not to stack?
<mwhudson> rockstar: complicatedly
<mwhudson> rockstar: basically, you can't on push
<rockstar> mwhudson, I just found bzr push --no-stacked
<mwhudson> rockstar: oh, i'm out of date then :)
<rockstar> :)
 * mwhudson EODs
<adeuring> good morning
<mrevell> Good morning
<allenap> Morning everyone!
<deryck> Morning, all.
<jml> hi
<jml> anyone know what's going on with the buildbot failure?
<jml> https://lpbuildbot.canonical.com/builders/lp/builds/217/steps/shell_7/logs/summary
<jml> oh, I see. It's a deployment fail.
<jml> mwhudson, sorry I wasn't able to catch up with you this morning.
<mrevell> beuno: around yet?
<mrevell> noodles775: got two mins?
<mrevell> beuno: unping
<noodles775> mrevell: sure ... in 1 min.
<noodles775> mrevell: skype?
<mrevell> noodles775: Nah, was just requesting a *very* quick UI review
<mwhudson> jml: no worries
<beuno> noodles775, good morning
<noodles775> hi beuno
<beuno> noodles775, looking at the captcha review
<beuno> it's a great point about telling people why we ask that
<beuno> I wonder if we could have a (?) icon, that is clickable, and mrevell's help popup comes up
<beuno> so we don't have so much text on the page
<noodles775> Yeah, that'd be a good way to keep it minimal :)
<beuno> the other thing that came to mind was, maybe the field shouldn't be that length
<beuno> to make it distincctivly different than password
<beuno> if you don't read labels, it's easy to be fooled
<noodles775> yeah, true - I hadn't thought of that - mistaking it for a password field simply because it's following the email field.
<noodles775> I had a quick look at a few other sites (gmail signup and ubuntu forums) and both define a label like "Random question" or "Word verification", and are visually quite different...
<beuno> right, you may also be able to get away with a very short description
<beuno> I think the key here is that it look visually different enough
<beuno> this is where "don't read the merge proposal" comes in useful   :)
<noodles775> So, laying it out like the gmail signup:
<noodles775> hmm... not sure what we'd use for a label, but having the actual simple math question in the right section (ie. aligned with the inputs) and the input below it could do that.
<beuno> yeap, that would work
<noodles775> perhaps the label could simply be 'Random question'.
<beuno> yeah, or "spam test"
<beuno> something that gets the message across
<noodles775> I'll play with it and do a diff.
<beuno> it's a great point that the label is not a good place to put the question
<kfogel> noodles775, beuno: in https://lists.launchpad.net/launchpad-dev/msg01264.html, Michael Biena asks a simple question that I don't know the answer to -- but one of you might.  ("What needs to be done for it to happen (if it didn't already happen)?")
<beuno> kfogel, is that the API one?
<noodles775> yep
<kfogel> beuno: yeah -- he added a TOC to our API doc page.
<kfogel> beuno: it's a great change, but it didn't get deployed with 3.0 (he and I both thought somehow it would).
<kfogel> beuno: I guess because there wasn't a new launchpadlib _release_ corresponding to the launchpad deployment.  So his change (and some similar changes from me) are still sitting in launchpadlib trunk, I guess.
<beuno> kfogel, I have no idea how those bits work
<kfogel> or maybe there's been a release since then... Anyway, I think what we're looking for is "The Person Who Knows Everything About Upgrading Launchpadlib In Launchpad", who can probably solve this in ten minutes.
<kfogel> beuno: np
<kfogel> beuno: oh, my bad, geser wrote that patch, not Michael Bienia -- Michael's just asking about it.
<beuno> :)
<james_w> kfogel: they are one and the same :-)
<kfogel> james_w: oh, dnig!
<kfogel> james_w: I was confusing geser with micah_g, for no good reason (I've met micah_g, but not geser).
<kfogel> james_w: thanks for the reminder.
<kfogel> james_w: Some other time, maybe I'll rant about the local tendency to have IRC nicks that are totally unrelated to one's real name and/or email name. :-(
<james_w> :-)
<beuno> gary_poster, any ideas what this could be about?  https://pastebin.canonical.com/23096/
<gary_poster> beuno: no.  more context?
<beuno> gary_poster, that's on "make run"
<beuno> all I get
<beuno> gary_poster, https://pastebin.canonical.com/23097/
<beuno> full paste
<gary_poster> beuno: never seen that before :-(
<gary_poster> beuno: thinking about how to diagnose...maybe try turning off SHHH?
<beuno> gary_poster, sure, want to teach my how?
<gary_poster> SHHH= make
<gary_poster> beuno: ^^^
<beuno> gary_poster, https://pastebin.canonical.com/23098/
<gary_poster> flacoste, kfogel https://bugs.edge.launchpad.net/bzr/+bug/442934
<mup> Bug #442934: unknown url type 'bzr+ssh://bazaar.launchpad.net/$user/$project/$branch;revno=$int' <Bazaar:New> <PQM:New> <https://launchpad.net/bugs/442934>
<kfogel> gary_poster: thanks!
<gary_poster> welcome :-)
<gary_poster> beuno: I see better what is failing, but I have no idea of the specifics yet, and certainly not why.  Is this on a recently updated karmic?
<beuno> gary_poster, yes, fresh install, fully up to date
<matsubara> stub, Chex, gary_poster, rockstar, bigjools, sinzui, allenap: LP production meeting in 25 min at #launchpad-meeting
<gary_poster> beuno: just updated everything, still can't dupe, still trying
<gary_poster> beuno, that's SHHH= make not SSSH= make
<beuno> ah
<gary_poster> it may not make a diff for this :-/
<beuno> gary_poster, exacgtly the same output
<gary_poster> but for future reference at least
<barry> so, here's an interesting question.  let's say you're on a page and you want to click an icon that has no label (such as a bare, edit icon).  how do you get zope.testbrowser to find that icon?  fmt:icon leaves no traces that i can find; i.e. no label or name
<barry> best i can figure is to get something close and then follow the dom to the icon
<jml> beuno, let's arrange a time for a call.
<bigjools> gary_poster, beuno: you need make SHHH= <target> I think
<gary_poster> bigjools: yeah sorry, beuno.  And beuno, I am in another meeting and trying to help losas.  will be back with you asap
<beuno> jml, sure, when's good?
<jml> beuno, now?
<beuno> jml, sure, let me get liquids and I'll skype you
<jml> beuno, ok. I'll also grab a drink.
<sinzui> kfogel: ping
<kfogel> sinzui: pong
<sinzui> kfogel: A user has a branch for a bug I want to land. https://bugs.edge.launchpad.net/launchpad-registry/+bug/420515
<sinzui> I have tried contacting him via the bug, and direct email, but I have not had a reply :(
<mup> Bug #420515: Distribution Series status field is not initialized correctly in edit form <Launchpad Registry:In Progress by jmglogow> <https://launchpad.net/bugs/420515>
<kfogel> sinzui: ah -- and we can't land until copyright submission is done?
<sinzui> correct
<kfogel> sinzui: hmrmrm.  let me look for a sec
<sinzui> kfogel: It needs a test that I can add. I just loath writing code that someone already has
<kfogel> sinzui: he's jmux
<kfogel> in IRC I mean
<sinzui> right
<kfogel> sinzui: not logged in right now apparently
<kfogel> sinzui: how long has he not responded for?
<sinzui> 3 weeks
<sinzui> I sent my last two request this week
<kfogel> oy
<kfogel> sinzui: I totally know how you feel about not wanting to do duplicated work.  Let's google him and see if he has a blog or some other means of contact.
<kfogel> one sec
<kfogel> sinzui: frustrating, nothing much.
<kfogel> sinzui: so, let's do this:
<kfogel> I'll send him a mail too -- sometimes it's a spam filter issue.  If no luck, then ... I guess we're out of luck.  We should also watch for jmux here today and tomorrow.
<sinzui> kfogel: thanks for sensible suggestion. I added a rule to tell me when he comes online
<kfogel> sinzui: what IRC client do you use?
<sinzui> pidgin
<kfogel> *nod*
<kfogel> I don't know how to do that in XChat, but should learn.
<simon-o> kfogel: XChat has a nice Python Scripting Interface, I think you can use that
<simon-o> :)
<kfogel> simon-o: thank you!
<simon-o> kfogel: your welcome, here are some sample scripts: http://wiki.linuxquestions.org/wiki/XchatPyScriptSamples
<kfogel> simon-o: even better, that's great -- thanks.
<gary_poster> beuno: ok, got other things handled, moving back to you.
<kfogel> sinzui: sent
<matsubara> kfogel, you can use /notify <nickname> on xchat to accomplish that. /help notify will give you the options
<kfogel> matsubara: awesome
<gary_poster> beuno: apply this http://pastebin.ubuntu.com/288709/ (really the print line is the only interesting one) and then run ``make SHHH= bin/buildout`` and pastebin the output to me, please
<beuno> gary_poster, sure, one sec
<beuno> gary_poster, https://pastebin.canonical.com/23110/
<gary_poster> beuno ack thanks looking
<gary_poster> beuno-lunch: just for giggles, try ``mv /home/beuno/canonical/lp-sourcedeps/eggs/setuptools-0.6c9-py2.4.egg bad_egg`` and then rerun .  Also note command I gave was different than the one you ran, though the only effective difference for now is that stderr and stdout would be interleaved correctly.
<beuno-lunch> /bin/sh: ./bin/buildout: not found
<beuno-lunch> make: *** [/home/beuno/canonical/lp-branches/devel/bin/py] Error 127
<beuno-lunch> [A[A[A[A[A
<beuno-lunch> gary_poster, ^
<gary_poster> beuno-lunch: whoa.  try a make clean.
<gary_poster> then rretry
<beuno-lunch> gary_poster, this can't be good, it seems to go into an infinit loop:  https://pastebin.canonical.com/23112/
<gary_poster> beuno-lunch: hm.  To state the obvious, something is seriously screwed up for you, and that takes it out of the realm of buildout.
<beuno-lunch> gary_poster, *sigh*
<beuno-lunch> gary_poster, suggestions to get it back on track?
<gary_poster> beuno-lunch: I have no idea what happened to your branch, but without sending me an image of your harddrive, I'm not sure how to diagnose the underlying problem.  What I would try next myself is moving devel off to the side and rebranching/rebuilding devel.
<beuno-lunch> gary_poster, thanks, I'll look into it
<gary_poster> beuno-lunch: ok let me know
<mrevell> night all
<leonardr> gary, is there any kind of review process for updating the download-cache or do i just go ahead now that the tests passed?
<gary_poster> leonardr: just go ahead.  As long as you are not deleting or overriding anything, the risk should be extremely small.
<leonardr> ok
<maxb> Question about download-cache.... why are a few things in there as prebuilt eggs?
<gary_poster> maxb: I know of two reasons. (1) pytz source distributions do not correctly generate eggs with easy_install.  Stuart and I have looked at it and are mystified so far. (2) Some distributions have build dependencies in their setup.py.  Buildout (and maybe setuptools?) does not keep them from going over the network to get those dependencies, and that's not acceptable in production.
<maxb> hmm
<gary_poster> We've fixed all f the second examples that I know of
<gary_poster> leonardr: ping me when you are comfortable with your webservice-out-of-beta list and then we can talk.
<leonardr> gary: sure, how about this
<leonardr> i'm finishing up one section now
<leonardr> there's some stuff at the end i haven't written
<leonardr> i'll finish this section, give it to you to look over while i have lunch, and we'll talk when i come back
<gary_poster> leonardr: +1 thanks
<leonardr> gary: https://pastebin.canonical.com/23125/
<gary_poster> leonardr: ok thanks
<leonardr> gary, hold on, i put some text in the wrong place which makes it make no sense
<gary_poster> leonardr: ok, on call, let me know
<leonardr> gary: updated: https://pastebin.canonical.com/23126/
<gary_poster> leonardr: got it thanks
<gary_poster> barry: lp:~gary/launchpad/py25
<gary_poster> barry: https://bugs.launchpad.net/launchpad-foundations/+bugs?field.tag=python-upgrade
<jml> g'night all
<mwhudson> good morning
 * mwhudson afk for a few minutes
<kfogel> leonardr-lunch: did you see Gervase's mail about Bugzilla RESTful API here?  https://lists.launchpad.net/launchpad-dev/msg01266.html
<rockstar> abentley, mwhudson, it's that time again.
<abentley> rockstar: feel free to host again.
 * mwhudson is back
<kfogel> well gary, looks like abentley gave you the answer you were looking for re RabbitMQ :-).
<kfogel> s/gary/gary_poster/
<gary_poster> yes indeed!
<BjornT> kfogel, gary_poster: fwiw, i'm not convinced yet; see my reply :)
<leonardr> gary, readyo to talk when you are
<gary_poster> BjornT: yes, cool, thanks for stepping in.
<gary_poster> leonardr: cool thank you.  still marking up the document with my thoughts and questions.  should be ready in about 10
<kfogel> leonardr: (see my msg to leonardr-lunch above)
<leonardr> kfogel: i see it
<kfogel> leonardr: Well, quick!  Do something!  Don't just stand there, man!
<kfogel> People are risking their lives to keep us free, the least we can...
<kfogel> Oh.  Sorry.  Wrong channel.
<rockstar> abentley, https://dev.launchpad.net/Windmill
<mwhudson> allenap: still here?
<BjornT> rockstar, abentley: fwiw, the instructions at https://dev.launchpad.net/Windmill about running the tests are outdated. it only applies to running tests that haven't been converted yet. i'll update that page tomorrow.
<rockstar> BjornT, yes, I know.  We were discussing that at the time.
<sinzui> EdwinGrubbs: will bug-399554-timeline-improvements land today?
<EdwinGrubbs> sinzui: I've made the ui review changes, so it's all approved. I just need to rerun the tests.
<sinzui> okay
<sinzui> EdwinGrubbs: are you preparing a branch for Bug #430708
<mup> Bug #430708: Move Registry windmill tests to RegistryWindmillLayer <story-windmill-layer> <test-system> <Launchpad Registry:In Progress by edwin-grubbs> <https://launchpad.net/bugs/430708>
<EdwinGrubbs> sinzui: there is a branch for that. it just wasn't linked to the bug.
<x-warrior> If i want to fix a bug, i read that should i start of trivial bugs. But trivial is a category? What STATUS should I take? Status: Triaged and Importance: Low?
<wgrant> x-warrior: 'trivial' is a tag. I'd take a Triaged bug with whatever importance.
#launchpad-dev 2009-10-09
<x-warrior> wgrant, thanks I will take a look
 * mwhudson lunches
<sinzui> x-warrior: triaged means we gave it a priority. Low means it will be fix opportunistically, not scheduled. trivial means it should be easy to fix, about 1 hour for a experienced engineer
<mwhudson> beuno: hello
<mwhudson> beuno: have you seen https://code.edge.launchpad.net/~mnordhoff/loggerhead/yui-3.0.0?
<mwhudson> beuno: it doesn't work
 * mwhudson --> beer!
 * wgrant directs a few torrents of hate at sampledata conflicts.
<mrevell> Morning!
<bigjools> eyup
<jml> good morning
* mrevell changed the topic of #launchpad-dev to: Code hosting offline 10.00-10.30 UTC | This is Launchpad Development Channel | Week 0 of 3.1.10 | PQM is OPEN | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/
<deryck> Morning, all.
 * wgrant just successfully ec2tested a branch with the new official image. Yay.
<mrevell> allenap: Can you help me with a bit of ajaxy stuff? it's really easy (for you), honest :)
<jml> wgrant, grats :)
<allenap> mrevell: Hi, yes, sure.
<mrevell> thanks allenap. Bug 406394 deals with a rather annoying bug in the pop-up help. The "Continue" button doesn't show the word "Continue".
<mup> Bug #406394: The "Continue" button on help pop-ups has lost its text and is now tiny <javascript> <ui> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/406394>
 * allenap looks
<mrevell> allenap: Someone's posted a comment pointing out what's wrong but I'm struggling to see where to fix that in the code.
<mrevell> allenap: I have lib/canonical/launchpad/icing/build/inlinehelp/inlinehelp.js open
<allenap> mrevell: Line 35.
<mrevell> allenap: function findHelpLinks() { ?
<allenap> mrevell: And lib/canonical/launchpad/icing/build/inlinehelp/inlinehelp.js is a symlink to lib/lp/services/inlinehelp/javascript/inlinehelp.js
<allenap> mrevell: Doh, sorry, line 30.
<wgrant> When adding new attributes to a model class, do I stick with the class' existing completelyandutterlyunreadable style, or do I use_underscores like new stuff?
* mrevell changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 0 of 3.1.10 | PQM is OPEN | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/
<allenap> mrevell: This'll do it: http://pastebin.ubuntu.com/289212/
<mrevell> allenap: Ahhhhhhhhhhhhhhhhh, right. I feel a cheat landing your work. heh.
<allenap> mrevell: Well, it was the work of Anders JÃ¸rgensen really :)
<mrevell> allenap: :) I'll get it through review and testsuite. Cheers.
<wgrant> Anybody know the answer to my question?
<jml> wgrant, use_underscores
<wgrant> jml: thanks
<jml> wgrant, the policy is that we're in favour of incremental cleanup of our code.
<jml> wgrant, and a key part of that is not adding to things that need to be cleaned up, even if it means local stylistic inconsistency.
 * wgrant begs PEP 8 for forgiveness.
<jml> MTecknology, ping
<mrevell> allenap: Do you have any thoughts as to why I'd be seeing the autoland problem again?
<allenap> mrevell: Exactly the same problem? Can you paste it?
<mrevell> allenap: I think so. Lemme grab it
<wgrant> bigjools: Did anything end up happening with my branch?
<bigjools> wgrant: I submitted it, but it seems to have disappeared
<bigjools> ah pqm stopped for a CP
<gary_poster> barry: I didn't know about http://www.python.org/dev/peps/pep-0382/ .  yay.  hope it happens.
<barry> gary_poster: i actually didn't know about it either, but i didn't think pep 381 was right so i went spelunking :).  it seems like a good pep so i hope it gets implemented too
<barry> btw gary_poster, i totally failed yesterday to run anything we talked about.  bzr pipelines roadblocked me (though i now have a much better understanding of it - something we should definitely look at).  i'm still going to try to run some things today in the background while i ocr/chr
<jml> sinzui, ping
<sinzui> EdwinGrubbs: skype?
<sinzui> hi jml
<jml> sinzui, hi.
<jml> sinzui, I guess you're busy right now, but sometime today I'd like to have a chat with you about ISD's experience with privacy -- I was talking to Nigel yesterday & he said that you were the person to speak with.
<sinzui> indeed I am the teller of the sad tale
<sinzui> jml: I'll be available in 15 minutes
<jml> sinzui, cool. whenever you're ready.
<MTecknology> jml: pong
<jml> MTecknology, hi
<MTecknology> jml: how's it going?
<jml> MTecknology, good.
<MTecknology> about that project..
<jml> MTecknology, I've recently moved to London, slowly adjusting to a faster, greyer pace of life :)
<jml> MTecknology, yeah, I was going to ask :)
<MTecknology> extremely busy this week and next week; but then open to start working on it
<MTecknology> I'd like to play with the source this weekend though
<jml> MTecknology, cool.
<MTecknology> I'd like to find a spelling mistake and fix it
<jml> MTecknology, heh.
<jml> MTecknology, if you search things tagged 'trivial' and 'ui', you'll probably find something like that.
<MTecknology> jml: just something simple to learn the process
<MTecknology> ok :)
<jml> MTecknology, not everything tagged 'trivial' is actually trivial, sadly.
 * bigjools wonders how many bugs tagged trivial really are trivial
<bigjools> heh snap
<bigjools> jml: I saw you tag something "easy" once, I had a chuckle
<jml> bigjools, :D
<jml> bigjools, a lot of the time the change is easy and the hard thing is finding the 20 page tests that assumed the old behaviour but weren't actually devoted to testing it.
 * bigjools cooks up a "nightmare" tag
<jml> bigjools, heh heh
<bigjools> it would apply to most soyuz bugs :/
<jml> since we've open sourced, I've made a habit of adding a short howto to any bug I tag as trivial
<bigjools> yeah I try and add more info on how to fix as well
<bigjools> it's worth an email to the -dev list
<jml> bigjools, I think there actually was a thread about this a couple of months ago :)
<sinzui> jml: I am free. Do you want me to call?
<bigjools> my memory sucks
<jml> sinzui, yeah sure.
<MTecknology> bigjools: "bug to assign to random person(me)" -> nightmare :P
<bigjools> :)
<barry> rockstar: ping
<rockstar> barry, pong
<barry> rockstar: hi.  was wondering if you were going to finish that review from yesterday.  if not, i'll ping abel about it
<rockstar> barry, I JUST saw it come in.  The new greylisting seems to be working, but I didn't get the email when I EOD'd last night.  I'll do it now.
<barry> rockstar: thanks.  greylisting == fun!
<rockstar> barry, yea, once it gets trained it's okay, but I moved around some infrastructure here, which meant a new mail server, so there are some hiccups to work out.
 * barry nods
<barry> rockstar: i especially love the mail servers that don't know the difference between 4xx and 5xx :)
<rockstar> barry, eep.
<MTecknology> deryck: hi
 * rockstar reboots
<sinzui> bigjools: ping
<bigjools> hello citrus
<sinzui>  bigjools I am starting a fix for bug 352374
<mup> Bug #352374: IntegrityError: duplicate key value violates unique constraint "packaging_uniqueness" <Launchpad Registry:Triaged> <https://launchpad.net/bugs/352374>
<sinzui> bigjools: The simple way to avoid that error is to use PackagingUtil.packagingEntryExists() but that does not help the user accomplish his goal of getting rid of the insane link
<deryck> MTecknology, hi
<MTecknology> deryck: so.. you get the last email?
<deryck> MTecknology, just about to lunch break, but we could chat briefly.  Or I can reply to your mail when I'm back from eats.
<MTecknology> either way - I'm in class now so a short chat is good
<bigjools> sinzui: my knowledge of packaging linkage is extremely limited
<MTecknology> after this I'll follow you to food
<sinzui> bigjools: After some though, it occurred to me that we do not check because we assume that having the distroseries and sp, we can safely change the productseries. Then it occurred to me that the real issue here is that the distroseries+sourcepackage has multiple upstream packaging links, and that we are only showing one of them. Is that possible?
<bigjools> sinzui: the dsp page shows direct_packaging
<bigjools> but allows you to edit each series individually
<sinzui> bigjools:  this is an SP link in this case: https://edge.launchpad.net/ubuntu/karmic/+source/metacity/+edit-packaging <- That should be trunk, but apparently that packaging link already exists...we get a db error
<bigjools> this is where my lack of knowledge about this stuff makes my eyes glaze :)
<sinzui> bigjools: In this very example, it pointed the wrong project and series, I decided that point it to another matacity series to get part of the link right
<sinzui> bigjools: okay. I'll try a query on staging to see if there is more objects then being shown in the ui
<bigjools> sorry, I feel useless
<sinzui> np. My goal is to learn this
<sinzui> There are a few bugs with linking that cannot be fixed until someone really know how they should work
<sinzui> bigjools: My assumption was correct: bug 196774. <- I think I need to fix that to prevent the madness. In the cases documented, the user would be happy if we deleted the crack duplication
<mup> Bug #196774: It shouldn't be possible to link multiple productseries to a sourcepackage in a given distroseries <package-link> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/196774>
 * jml is slowly learning that there a lot of interesting Launchpad emails that are no longer my business
<jml> sinzui, oh cool, I independently rediscovered that bug recently while exploring the schema to figure out source package branches.
<jml> sinzui, but never got around to actually finding the bug report in Launchpad :)
<bigjools> ok how do I run person.txt without running the other million tests that end in person.txt?
<MTecknology> bigjools: be a man - run them all
<sinzui> bigjools: -t lp.soyuz.*doc/person.txt
<jml> bigjools, ./bin/test -1cvvt parent/of/person.txt
<bigjools> MTecknology: my office is already warm enough :)
<bigjools> jml: that's just too bleedin' obvious :)
<jml> the -1 is extremely useful.
<bigjools> yes
<bigjools> but not as groovy as -c
<jml> trial has better colours.
<bigjools> jml: you suck, it doesn't work! :)
<jml> it totally works.
<jml> you're doing it wrong.
<jml> oh.
<bigjools> lol
<jml> the answer is that zope sucks.
<jml> do you want the longer answer?
<bigjools> I considered using a regex for a moment, and then I came to my senses
<jml> '-t' does a regular expression search on the name of the test
<jml> where 'name of the test' is defined as str(test)
<sinzui> bigjools: you need .* because the doctest path is appended to the executor
<jml> for unit tests, this defaults to "test_foo (lp.foo.bar.BazTestCase)"
<jml> but a lot of our tests have custom __str__ methods that produce "lp.foo.bar.BazTestCase.test_foo" instead
<jml> for doctests, the str() is the path to the doctest
<sinzui> bigjools: -t lp.soyuz.*doc/person.txt <- only match the start and end of the test name
<bigjools> sinzui get's the prize
<bigjools> gets
<bigjools> jeez
<jml> for most such doctests, zope generates a path like "./lp/foo/tests/../doc/bar.txt"
<bigjools> lib/lp/registry/tests/../doc/person.txt
<jml> so -t matches that path, rather than "lp/foo/doc/bar.txt", which would be more sensible.
<jml> I tried to fix this bug once, and then learned again that zope.testing's code has a great face for radio.
<sinzui> :)
 * bigjools chortles
<jml> on a different topic
<jml> I've just got around to reading the thread where sidnei talks about template performance
<jml> I'd really appreciate a three sentence summary :)
<abentley> rockstar: chat?
<rockstar> abentley, sure.
<rockstar> abentley, I wonder if we might try chatting through Empathy today.
 * bigjools wonders how relatively recently added model class methods are totally untested
<abentley> rockstar: As an experiment, sure.  But I prefer Pidgin.
<rockstar> abentley, well, yeah, I mean audio chatting through Google Talk, whatever client works.
<abentley> rockstar: I am calling you.
<rockstar> abentley, I can't hear you, can you hear me?
<abentley> No, I couldn't even see you pick up.
<abentley> rockstar: Try calling me.
<rockstar> abentley, calling.
<abentley> Apparently the call is in progress.
<rockstar> abentley, I still see "Connecting..."
<abentley> rockstar: Well, maybe Empathy will do better than Pidgin.
<rockstar> abentley, let's go back to skype.  I'm not sure that my USB headset us going to play nice with Empathy either.
<rockstar> Also, I don't really want to spend much time futzing with it...  :)
<rockstar> abentley, I can hear you, but I don't think it likes my USB headset.
<rockstar> abentley, one sec.
<rockstar> abentley, did you have to configure your headset?
<rockstar> abentley, it's using your laptop mic I bet.
<abentley> No, it turns out to be configured correctly already.
<abentley> rockstar: It insists it's using "Logitech_USB_Headset Analog Mono".
<rockstar> abentley, I think you and I have the same headset.
<abentley> rockstar: Yeah, same or similar.
<rockstar> abentley, let's just skype...  :(
<rockstar> jml, sorry for the noise...
<jml> np.
<jml> rockstar, it doesn't look like anyone was interested in answering the question anyway
<jml> rockstar, which sadly means I'll have to think for myself :\
<rockstar> jml, what question?
<rockstar> jml, I was talking about just calling you through Empathy to see if we could have conference calls with it.
<rockstar> (which it doesn't look like we can)
<jml> rockstar, oh, I'm not on empathy
<rockstar> jml, well, GTalk.
<jml> rockstar, what were you calling?
<jml> rockstar, pidgin merrily discarded any noise you generated :)
<rockstar> jml, your GTalk account.  abentley and I were trying.
<jml>  I've just got around to reading the thread where sidnei talks about template performance
<jml>  I'd really appreciate a three sentence summary :)
<jml> that was my question, fwiw.
<sidnei> i guess the summary is, chameleon is faster but can be made even faster if we spend some time either cleaning up the templates to do less traversal or improving the code in z3c.pt that does the tales namespace function traversal to have some kind of fastpath.
<mrevell> Have a great weekend folks
<jml> sidnei, that's good, thanks.
<jml> sidnei, do we know how much work either of those two options would be, roughly?
<sidnei> jml: my suggestion was to take one page where lots of tales namespace functions are used, replace them all by python expressions and benchmark it to determine an upper bound of how fast it can go.
<jml> sidnei, sounds like a good plan.
<sidnei> jml: and only then worry about improving it further, if there are real gains
<bigjools> bye everyone, and have a great weekend
<jml> bigjools, g'night.
<jml> sidnei, although it doesn't quite answer the question I asked :)
<sidnei> jml: im great at dodging questions about estimates :)
<sidnei> jml: i suspect for someone with some skills in making python code fast (like someone from the bzr team *hint hint*), trying to optimize the python code would be the easy win, though im not sure there's much left to optimize there
<sidnei> jml: i would estimate about one week either way you go
<jml> sidnei, :D
<jml> sidnei, thanks :)
<sidnei> jml: someone mentioned that maybe some sort of local lookup cache (was it mwhudson?) could be used. it's basically doing a few  try:excepts and adapter lookups
<jml> sidnei, cool.
 * jml is off for beers with gnome folks
<barry> gary_poster: Getting distribution for 'pytz==2009l'.
<barry> make: *** [/home/barry/projects/launchpad/py25/bin/py] Error 1
<barry>  
<gary_poster> barry: hm, may have inadvertently done some other tricks there; checking
<gary_poster> barry: oh, no, I know what is up
<barry> gary_poster: cool
<gary_poster> barry: you need the pytz 2.5 egg.  the source distribution of pytz does not play well with easy install (and therefore buildout) for some reason
<gary_poster> just download it from pypi and move on
<barry> drop it in eggs?
<gary_poster> pytzl python2.5 egg, I should say
<gary_poster> I would drop it in download-cache/dist, because that's where it would go if we were going to check things in
<gary_poster> barry: ^^^
<barry> gary_poster: ah, right.  thanks
<gary_poster> np
<barry> gary_poster: this page is only publishing 2009n now: http://pypi.python.org/pypi/pytz
<barry> gary_poster: plus, it's too bad we don't know the maintainer of the package to ask him to fix it for us :)
<gary_poster> barry: http://pypi.python.org/simple/pytz -> http://pypi.python.org/packages/2.5/p/pytz/pytz-2009l-py2.5.egg#md5=b41c8cacb5f4a8a64db05afbdf3ef9ef
<gary_poster> barry: stuart and I have both looked into it.  We are not sure what is wrong.  bug 438634
<mup> Bug #438634: buildout not building pytz egg correctly <Launchpad Foundations:Triaged by gary> <https://launchpad.net/bugs/438634>
<barry> gary_poster: thanks!
<gary_poster> np
<barry> gary_poster: just read the bug report.  how truly odd!
<gary_poster> barry: yeah :-(
<barry> gary_poster, maxb: https://dev.launchpad.net/PythonMigrationStatus
<maxb> good idea
<gary_poster> barry: awesome, thanks.  so now you will be rerunning the tests?
<barry> gary_poster: i'm still not successfully building your branch :(
<gary_poster> barry: no?  what are the issues now?  I will try too...
<barry> gary_poster: still investigating
<gary_poster> ok
<barry> gary_poster: http://paste.ubuntu.com/289439/
<gary_poster> barry: move aside your sourcecode and get it again for 2.5.
<gary_poster> barry: make sense?
<gary_poster> barry: the problem is that _lsprof is in sourcecode, and is build for 2.4
<barry> gary_poster: i think so ;)
<gary_poster> ok :-)
<gary_poster> fwiw, I just built it fine
<gary_poster> after a make clean
<barry> gary_poster: is it in sourcecode because python2.4 doesn't have it?
<barry> gary_poster: yep, that seems to be it.  it's in 2.5 and 2.6
<barry> gary_poster: so once we migrate we won't need it in sourcecode anymore
<gary_poster> barry: ok, I was about to say "that's a good guess."  Great
<rockstar> flacoste, ping
<flacoste> hi rockstar!
<rockstar> flacoste, how's things?
<flacoste> things are great! how are you?
<rockstar> flacoste, good as well.
<flacoste> did you register for YUIConf?
<rockstar> flacoste, no, should I have?
<rockstar> flacoste, we're seeing an increase in bugs where javascript api changes aren't enough to blacklist us from the slave database.
<flacoste> rockstar: i think you should: http://www.yuiblog.com/blog/2009/09/29/yuiconf-2009-registration/
<rockstar> flacoste, looks like "External developer" is "Sold out"
<rockstar> flacoste, is there anything we can do to force a slave db blacklist?
<flacoste> rockstar: sold out, that's unfortunate :-/
<flacoste> for the slave db blacklist...
<flacoste> not really
<flacoste> it's based on the session
<rockstar> flacoste, hrm, that means that we have to duplicate the template is javascript.
<flacoste> ???
<flacoste> what is the problem exactly?
<rockstar> flacoste, https://bugs.edge.launchpad.net/launchpad-code/+bug/447353
<mup> Bug #447353: Subscribing to a branch does not insert your name into the subscriber list <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/447353>
<rockstar> flacoste, I make the API changes, and then get a small page fragment to reload the subscriber list.
<rockstar> If I hit the slave DB, I don't always get the new subscriber in the page fragment.
<flacoste> you shouldn't hit the slave db
<rockstar> flacoste, this is one of two bugs we have open due to thes.
<rockstar> flacoste, I know I shouldn't, but it is.
<flacoste> then the bug to fix is that one
<flacoste> ah, i know what is happening
<flacoste> API requests use the MasterStore policy
<flacoste> which doesn't update the last_write of the session
<rockstar> flacoste, yeah, I think someone in Foundations already knows about this (I thought it was you).
<flacoste> that would be stub or leonard
<rockstar> flacoste, I think there's even an open bug about this.
<flacoste> yeah, i think i saw something about that
<flacoste> rockstar: if you find the bug, i'm sure gary can put stub or leonard on it
<rockstar> flacoste, okay, great.
<gary_poster> rockstar: sure, shoot it at me.
<barry> gary_poster: build succeeded, running the tests (gotta love the quad-core :)
<gary_poster> barry: :-) cool
<rockstar> gary_poster, I couldn't find the bug, so I filed a new one.  https://bugs.edge.launchpad.net/launchpad-foundations/+bug/447453
<mup> Bug #447453: Changes made through the API (via javascript) aren't blacklisting the Slave DBs <Launchpad Foundations:New> <https://launchpad.net/bugs/447453>
<gary_poster> rockstar: ack, looking, thanks
<rockstar> gary_poster, it's possible that the bug I was looking for was never filed, but was a known issue.  If it was filed, just mark it as a dupe.
<gary_poster> ok
<rockstar> gary_poster, I'm willing to bet this breaks almost all of the code javascript, since I wrote most of what's landed so far in this manner.
<gary_poster> rockstar: Does this affect production significantly?  I marked this as high and am sending this to stuart, with an email to highlight it to him--is this critical?
<rockstar> gary_poster, well, yes, it affects production.  It APPEARS to the user that the operation didn't take affect, even though it did, and a small delay (like, maybe a pageload) will illustrate that it's broken.
<rockstar> gary_poster, I think this may also affect what abentley is working on, and probably javascript from other teams.
<gary_poster> rockstar: ok.  /me goes to find the policy for the definition of critical...
<gary_poster> rockstar: (IOW, is this stop the presses, or ask Stuart to do this first thing Monday)
<rockstar> gary_poster, whether that means "critical" to you is your decision, but I'd say I'd like to see it cherry picked before the rollout.
<rockstar> gary_poster, um, well, it's not a stop the presses thing, since we've been experiencing it for two weeks now.  I thought it was already being worked on, which is why I hadn't discussed it before.
<gary_poster> rockstar: ok, cool.  then I'll have someone on it Monday.
<rockstar> gary_poster, thanks.
<gary_poster> np
<rockstar> abentley, how are you running your windmill tests.
<abentley> rockstar: bin/test -v --layer=CodeWindmillLayer test_merge_proposal_commenting
<rockstar> abentley, okay, good.
<sinzui> bac: did you see the buildbot launchpad-login.pt conflict?
<bac> sinzui: no
 * bac looks
<abentley> rockstar: Oh, one problem is that ensure_login fails when the user is already logged in.  This means that bin/test -v --layer=CodeWindmillLayer fails.
<sinzui> bac I think you need to merge stable/lib/canonical/launchpad/templates/launchpad-login.pt into db-devel, then resolve.
<rockstar> abentley, yeah, I've seen that.
<rockstar> abentley, right now I'm getting: http://pastebin.ubuntu.com/289474/
<bac> sinzui: that was a weird conflict.
<abentley> rockstar: I dunno why that would be.
<rockstar> abentley, yeah, me neither, chasing now.
<bac> sinzui: we're not in testfix.  so i can submit this to db-devel normally.  rs=sinzui ?
<sinzui> bac: yes you can, but may I see the conflict?
<sinzui>  /patch
<bac> sinzui: not sure how to do that
<sinzui> bac: then how do you know you have something to submit?
<bac> sinzui: the conflict was resolved as part of the merge from devel so it doesn't show up separately in a diff
<sinzui> bac: you mean merge3 is better than start merge?
<sinzui> bac: so I take your point that you have a branch of db-devel that is correct and it looks just like the login.pt that you intended to land?
<bac> sinzui: yes
<bac> sinzui: i updated my devel branch
<bac> sinzui: i updated my db-devel branch
<bac> sinzui: then i merged devel into db-devel, resulting in the one conflict
<bac> sinzui: after resolving that conflict there are 61 files that have changed to be committed, including my conflict fix
<bac> sinzui: so, given that i cannot show you exactly the changes from the conflict resolution.
<gary_poster> beuno: did you ever try rebuilding devel?
<sinzui> bac: could you have just merged lib/canonical/launchpad/templates/launchpad-login.pt ?
<beuno> gary_poster, I started from scratch
<bac> sinzui: hmm.  perhaps.
<bac> sinzui: i can revert and try that
<gary_poster> beuno: ok
<bac> sinzui: except merge does not take a single file
<sinzui> bzr merge ../db-devel/lib/canonical/launchpad/templates/launchpad-login.pt
<sinzui> bac ^ not that exact example, but you can merge a file
 * sinzui did get a conflict going from db-devel to devel
<sinzui> ahh
<sinzui> bac: The conflict is with my indentation fix
<bac> sinzui: ok, i merged just that file (never tried that before).  here is the diff:  http://pastebin.ubuntu.com/289480/
<bac> sinzui: the actual conflict was at line 27 of the diff
<sinzui> okay. the direction I went put the problem on 172.
 * rockstar lunches
<sinzui> bac: can you fix the indentation of <ol class="subordinate"> ?
<sinzui> bac: This looks good to land, rs=me
<bac> ok
<dobey> is it just me, or is code hosting down?
<rockstar> dobey, scheduled maintenance.
<dobey> rockstar: i thought that was this morning, and it was already "back" ?
<rockstar> dobey, oh, my math is bad.
<al-maisan> is PQM operating normally at present?
<dobey> rockstar: or maybe mrevell's is
<rockstar> dobey, code hosting looks fine to me.
<al-maisan> a branch of mine was submitted to PQM via "ec2 test" approx. one hour ago but I don't see it anywhere
<dobey> rockstar: really?
<dobey> rockstar: https://code.edge.launchpad.net/~dobey/ubuntuone-client/emblem-tweaking
<dobey> rockstar: that should have been done 25 minutes ago...
<rockstar> dobey, okay, code hosting down and mirroring lag are two different things.  :)
<dobey> rockstar: i'm a user. to me "my code on launchpad" == "code hosting"
<dobey> :)
<rockstar> dobey, you're in the wrong channel then.  :)
 * rockstar looks for failed scripts.
<rockstar> abentley, do you know how often crowberry:branch-puller runs?  It looks like it died at 19:07:03 UTC today.
<rockstar> Is it really hourly?
<abentley> rockstar: No idea.
<abentley> rockstar: Actually, isn't it minutely?  It mirrors hosted branches into the mirrored area.
<rockstar> abentley, yeah, that's what I thought too, except the mail to the list says: The script 'branch-puller' didn't run on 'crowberry' between 2009-10-09 18:07:03 and 2009-10-09 19:07:03
<abentley> rockstar: That's not a contradiction.
<rockstar> abentley, so it failed every minute for exactly an hour?
<abentley> rockstar: That means that, regardless of how many times it should have run, it didn't run at all during that period.
<abentley> rockstar: Probably for more than an hour, but ran at least once during the other periods.
<rockstar> So maybe it's time to look at some oopses.
<barry> gary: Total: 24511 tests, 56 failures, 2 errors in 124 minutes 53.859 seconds.
<barry> gary_poster: ^^ that is with your branch
<gary_poster> barry: is my branch different at all from maxb's at this point?
<barry> gary_poster: i have not looked closely yet, since i'm ocr and chr today.  i basically just branched your branch, got it to build, and then ran the test suite :)
<maxb> Mine has nothing interesting in it at the moment. I was thinking about discarding it, replacing it with a bit of scripting to just sed some makefiles and shebangs
<gary_poster> barry: cool, thanks.  I don't expect they are different.  For comparison, the last run maxb reported was 29 failures I think
<gary_poster> maxb: eh, if you want, but this should happen soon enough
<gary_poster> the transition should happen, I mean
<barry> gary_poster: i think />>> foo/>>> print foo/ would fix a lot of tests
<maxb> !
<gary_poster> barry: cool
<rockstar> abentley, puller esploded: https://pastebin.canonical.com/23188/
<rockstar> abentley, all the failing branches appear to belong to jelmer.
<dobey> fun
<barry> gary_poster: we're going to need a new launchpadlib that prints its strings instead of reprs them
<gary_poster> barry: in its tests you mean?
<barry> gary_poster: yep
<gary_poster> barry: ok easy enough
<barry> yep.  i'm picking off a few low hanging fruit right now (that's not one of them tho :)
<gary_poster> barry: :-) cool.  I'll add a section about dependencies to the wiki page, and include the zope.publisher bit I mentioned.
<gary_poster> (and launchpadlib)
<barry> gary_poster: +
<barry> er, +1
<gary_poster> :-)
<gary_poster> barry: when you have a test run that shows the failures we have left (maybe after your low-hanging-fruit fixes), I'd love a copy.
<dobey> rockstar: hey. any luck with the mirroring, or do we need to smack jelmer? :)
<rockstar> dobey, still working on it.
<dobey> thanks
<barry> gary_poster: i'll put it in the wiki
<gary_poster> barry thanks
<barry> gary_poster: heh.  i didn't save my draft.  did now and added my branch
<gary_poster> barry: great
<wgrant> Hm, there is a buildbot failure, but two non-testfix branches have landed since then. Is that meant to happen?
<wgrant> The blog's grey-on-white really really hurts.
#launchpad-dev 2009-10-10
 * wgrant curses BPR's immutability, and goes on a messy NascentUpload refactor...
<jml> hello weekenders
<jml> wgrant, refactoring nascentupload eh?
<kiko> again? :)
<jml> kiko, I've already had a stab at it. there's a lot to refactor.
<kiko> jml, yeah, so have I. and yeah. there is lots. did your sim arrive btw?
<jml> kiko, yes. I shall tell you my real number...
#launchpad-dev 2009-10-11
<thumper> morning
<mwhudson> thumper: hello
<thumper> mwhudson: hey hey
<mwhudson> thumper: want to chat soon, or do you have all the email in the world to read first?
<thumper> mwhudson: we should have a call :)
<mwhudson> thumper: ah :)
<mwhudson> thumper: a few minutes?
<thumper> mwhudson: lets talk before I attack the eamil
<thumper> yep
<thumper> mwhudson: skype only seems to think I have pulsa audio
<thumper> mwhudson: not my logitech headset
<mwhudson> thumper: if you run pavucontrol (installing it if needed)
<mwhudson> and do the test call thing, you should be able to sling it over to the headset
<thumper> ok
<thumper> mwhudson: how do I tell pulseaudio server to use the headset?
<thumper> the pavucontrol app didn't seem to have a setting
<mwhudson> thumper: it didn't appear on the 'output devices' tab when you plugged it in?
<thumper> mwhudson: oh yes, it is showing there
<thumper> but skype only shows pulseaudio server
<mwhudson> thumper: ah
<mwhudson> thumper: when skype is actually doing audio (i.e. test call)
<mwhudson> thumper: go to pavucontrol
<mwhudson> thumper: you should be able to change it in there
<thumper> ok
<mwhudson> thumper: http://yui.yahooapis.com/combo?3.0.0pr2/build/widget/assets/skins/sam/widget.css&3.0.0pr2/build/widget/assets/skins/sam/widget-stack.css&3.0.0pr2/build/overlay/assets/skins/sam/overlay.css
<jml> good night
<jml> actually...
<jml> mwhudson, thumper: if the puller thing has been fixed, please post to identi.ca/launchpadstatus saying so.
<mwhudson> jml: how do i do that?
<jml> mwhudson, Matt Revell sent an email to the internal list with instructions.
<lifeless> https://sourceforge.net/apps/trac/sourceforge/ticket/5568
<lifeless> sf stopped supporting arbitrary openid providers
<wgrant> I am particularly amused that that page requires my non-OpenID credentials, which I do not remember.
<mwhudson> lifeless: i'm asked for a username/password on that page
<wgrant> Intriguing. When I first load the login page, I get an OpenID text widget. But that later turns into a set of images for each provider.
<lifeless> wgrant: yeah
<lifeless> mwhudson: you need to be logged in to read the ticket
<mwhudson> er
<mwhudson> one of the boxes is "openid"
<wgrant> Ah, so it is.
<wgrant> That makes no sense, but at least it's still possible.
<lifeless> really? it wasn't a couple of days back...
<mwhudson>  A site identifying as https://sourceforge.net  has asked us for confirmation that https://launchpad.net/~mwhudson  is your identity URL. However, that is not a valid Launchpad OpenID identity URL, such as https://launchpad.net/~USER
<lifeless> or I was jetlagged :P
<mwhudson> er
<lifeless> mwhudson: sweet. Not.
<lifeless> mwhudson: I've seen that using the apache mod-openid
<lifeless> I don't know the cause
<wgrant> I've seen people complaining that delegation broke after 3.0.
<lifeless> mwhudson: want to file the bug on lp, or shall I?
<mwhudson> lifeless: feel free
<wgrant> Strange buildd issue.
<wgrant> Is spm back yet?
<lifeless> done
<spm`> wgrant: yes, but apparently with the wrong nick....
<wgrant> spm`: Ah. Hi. Is cocoplum's apache alive?
<spm> wgrant: yup - what's the problem you're seeing?
<wgrant> spm: Lots of builds failing in really bad ways because they can't talk to ftpmaster.internal:80. eg. https://edge.launchpad.net/~pyg3t-dev-team/+archive/ppa/+build/1287542
<wgrant> Just noticed it timed out rather than being refused, which is rather more sinister...
<wgrant> https://edge.launchpad.net/~gustavo-avila/+archive/ppa/+build/1133503 is failing as we speak.
<wgrant> Seems it's only the virtual builders that are broken.
<wgrant> They're in a different DC, aren't they?
#launchpad-dev 2010-10-11
<wgrant> Were there insufficient goat sacrifices to make it work, or has it just not been done yet? Natty is suspiciously empty.
<lifeless> it wasn't qablessed into prod, so we need a cp
<wgrant> The disabled arch i-d-s thing? I thought that was CPd along with my disabled arch indices thing.
<lifeless> we're talking different things ;)
<thumper> so... any movement on the psychopg problem?
<thumper> mwhudson: so... I've been thinking about translatePath again
<thumper> mwhudson: I think we can safely ignore any path after a branch if it doesn't start with .bzr
 * thumper thinks
<mwhudson> thumper: do we care about bzr cat lp:launchpad/README not working?
<thumper> oh maybe not
<thumper> mwhudson: bzr cat -d lp:launchpad README works
<mwhudson> (i'm not sure how related that is, actually)
<thumper> I think it may break hitchhiker if we do though
<thumper> as hitchhiker sits on the transport
<mwhudson> thumper: also at one point http requests to loggerhead went through translatePath
<mwhudson> not any more though
<lifeless> what are you planning?
<poolie> thumper: i was wondering if we should bulk-upgrade all the branches on launchpad sometime
<poolie> 2a format came in a long time ago now
<thumper> lifeless: I'm trying to get better errors from translatePath
<thumper> poolie: perhaps...
<lifeless> we should definitely bulk upgrade all the import branches
<poolie> that'd be a good starth
<poolie> however, some others are stacked on them, so it may get a bit complicated
<poolie> hello thumper, lifeless, btw
<lifeless> a feature scope using % could do that without overload
<lifeless> poolie: yes, thats true. OTOH we have that complexity doing any upgrade.
<wgrant> We can't ever bulk-upgrade all of Launchpad.
<wgrant> That would break everyone's checkouts.
<lifeless> wgrant: why?
<wgrant> lifeless: Won't the world end if my non-richroot branch's parent becomes rich?
<spiv> Perhaps not quite that bad, but it would cause some grief.  People would need to upgrade their local branches to be able to continue to merge or pull from the upgraded remote branches.
<wgrant> Yes. And that's unprecedented.
<wgrant> Bazaar's format changes suck enough (although it's pretty good now) without hosting services breaking branches without any action from the project owner.
<spiv> Hmm, again I think that's too strong a word.  But I agree it's worth thinking about the impact before doing it.
<spiv> (It's not unprecedented because many hosted branches have been upgraded without being able to contact every user of that branch, so people have certainly gone through this before, and the world didn't end ;)
<wgrant> A Launchpad change means that my Ubuntu 8.04 LTS systems can no longer access my project's branches.
<wgrant> My project was perfectly happy using pack-0.92. Nobody asked for it to be upgraded.
<lifeless> wgrant: I think upgrading users branches would be rude
<lifeless> wgrant: I'm not, and have never proposed that we do that.
<lifeless> wgrant: the branches lp 'owns' though, are different IMNSHO
<wgrant> Import branches? Sure.
<lifeless> wgrant: and, we can certainly (and should) encourage folk to upgrade
<lifeless> and make it easy for them to bulk upgrade
<wgrant> Definitely.
<wgrant> On all counts.
<lifeless> wgrant: however, supporting pack-0.92 etc has serious caveats and consequences (like massive memory bloat) for LP
<lifeless> wgrant: so we need to do something about that
<poolie> lifeless: could you have a look at https://code.edge.launchpad.net/~mbp/bzr/597791-http-tests/+merge/37941
<poolie> you don't need to read it line by line but i would like your thoughts on the general idea
<poolie> a line-by-line readthrough would be good
<lifeless> line 264 is against PEP8 (vertical WS between class: and the docstring)
<poolie> :)
 * thumper sighs
<lifeless> poolie: the tests are a bit opaque
<poolie> it's funny you should mention that, doesn't launchpad insist on having vws there?
<poolie> ok
<lifeless> I think variations.py would benefit from a module docstring with some overview & pointers in it.
<lifeless> poolie: no, LP doesn't.
<poolie> true
<lifeless> [lp follows PEP8 for its docstring conventiions)
<lifeless> one thing I can't tell is whether variations append or multiply
<lifeless> that is given two variations that return 2 scenarios each
<poolie> multiply
<poolie> good point though
<lifeless> sorry, 3 variations with 3 scenarios is it 6 or 9.
<poolie> heh, were you going to compare 2+2 with 2*2? :)
<lifeless> yes :P
<thumper> any one else seeing: Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
<lifeless> thumper: yes, for ages.
<thumper> what is it?
<lifeless> there was a discussion/bug about it
<poolie> you could have [AppendVariations(VaryByFruit, VaryByVegetable), VaryByCookingMethod]
<mwhudson> thumper: i saw it on my arm board, of all places
<lifeless> there is a test which deliberately triggers it.
<poolie> it's a test for handling this in the pyrex bencode
<poolie> lifeless: the example of concatenating them kind of points to the fact that if they were plain list-returning callables, you could more simply use itertools etc there
<lifeless> poolie: I think this is nice.
<poolie> but on the whole i think objects are better
<lifeless> theres a  bit of stylistic stuff like 'their_variations' (and variations which isn't usefully different to scenarios really) that might be tweakable
<poolie> thanks :) i'm very happy with it
<lifeless> poolie: I think multiplying is fine, it lets you do cross product well.
<poolie> (which is not to say it can't be improved)
<poolie> doesn't multiplication mean cross product?
<lifeless> yes
<thumper> I'm slightly concerned that `bzr revno lp:~thumper/launchpad/foo` never seems to complete
<poolie> right, the by-hand multiplication in test_http was what finally got me around to this
<lifeless> poolie: I'd really consider using __call__ - that is, having the objects be factories.
<poolie> rather than .scenarios()?
<lifeless> poolie: and rather than variations, perhaps 'scenario_factories'
<lifeless> writing that makes me wonder if instead, just a helper function which gets the scenarios would be better
<lifeless> scenarios = multiply_scenarios(VaryByHttpClientImplementation(), VaryByHttpProtocolVersion())
<poolie> that would be a bit more explicit
<poolie> hm
<poolie> bit of a question there about just when it's going to be evaluated
<poolie> which may matter wrt registries etc
<poolie> that is, at module load time vs later
<poolie> of course multiply_scenarios could return a lazy multiplier
<poolie> https://bugs.edge.launchpad.net/testscenarios/+bug/658044
<_mup_> Bug #658044: want declarative per-test-class variations <testscenarios:New> <https://launchpad.net/bugs/658044>
<lifeless> poolie: that sounds nice
<lifeless> poolie: (lazy evaluator)
<poolie> in that case i'd probably name it like an object, rather than something that sounds imperative
<lifeless> poolie: I think there would be less code, and one less class attribute (no need for .variations)
<lifeless> poolie: agreed (naming)
<poolie> MultiplyScenarios(...)
<poolie> does it support .scenarios now?
<spiv> thumper: FWIW the test that triggers the __subclasscheck__ warning is suppressed in bzr trunk
<lifeless> poolie: ues
<lifeless> poolie: yes.
<poolie> ah ok
<lifeless> 'TestWithScenarios'.
<spiv> Or rather, the warning is suppressed, the test is still there :)
<poolie> i looked for that in bzr but not in testscenarios
<poolie> that sounds better then
<poolie> perhaps we should depend on that at some point
<lifeless> http://bazaar.launchpad.net/~lifeless/testscenarios/trunk/annotate/head:/lib/testscenarios/testcase.py
<poolie> ah i see, this is a bit different to bzr
<lifeless> this is an optional helper
<lifeless> for doing lazy expansion
<lifeless> http://bazaar.launchpad.net/~lifeless/testscenarios/trunk/annotate/head:/lib/testscenarios/scenarios.py is the guts
<lifeless> http://bazaar.launchpad.net/~lifeless/testscenarios/trunk/annotate/head:/lib/testscenarios/scenarios.py#L61 specifically.
<poolie> so in that code, using generators would perhaps fit more naturally
<thumper> spiv: so a daily build soon should fix it?
<thumper> spiv or poolie: could one of you skype so I can explain a problem?
<spiv> thumper: even a build of 2.3b2 should
<thumper> spiv: which is found where?
<spiv> I can skype, give me a moment to grab the headset.
<thumper> spiv: I have bzr-nightly-ppa and bzr-beta-ppa and no 2.3b2
 * spiv wonders why skype is having trouble logging in
<spiv> thumper: yeah, I don't think we have anyone spending time to keep the PPAs fully up to date atm.
<spiv> Ah, now it's connected.
<thumper> spiv: you know we have recipes now right?
<thumper> spiv: https://pastebin.canonical.com/38472/
<poolie> are you guys ok together?
<lifeless> poolie: yes, they have a room
<lifeless> </groan>
<poolie> lifeless: is there cross-product code already in testscenarios?
<lifeless> no, there is in bzr and it should be trivially portable
<lifeless> or even usable from bzr
<poolie> right
<poolie> wfm, thanks
<thumper> $ bzr revno sftp://bazaar.launchpad.net/~thumper/launchpad/foo
<thumper> bzr: ERROR: Not a branch: "sftp://bazaar.launchpad.net/~thumper/launchpad/.bzr/branch/".
<spiv> lftp bazaar.launchpad.net:/> cat ~thumper/launchpad/.bzr/branch/location
<spiv> cat: Access failed: No such file: u'/.bzr/branch' (~thumper/launchpad/.bzr/branch/location)
<thumper> spiv: I'm watching a bzr process take up 2.5 gig of ram
<thumper> spm: as a result of that local test
<spiv> thumper: congratulations
<spiv> thumper: you obviously have a fair bit of ram ;)
<thumper> 4 + 8 swap
<spiv> thumper: what operation is triggering this?
<spm> thumper: ? I assume that was really aimed at sp4 vs sp1000?
<thumper> spiv: not sure
<thumper> spiv: well, the revno call
<thumper> spiv: the BzrDir.open_branchV3
<thumper> spiv: call to the server
<thumper> spiv: pretty sure it was the 'lp-serve', u'--inet' one that was not stopping
<spiv> thumper: related to the recursion them?
<spiv> s/them/then/
<thumper> yep
<thumper> spiv: is there a way to break into the bzr process?
<thumper> spiv: I have the pid
<thumper> it is in the loop now
<thumper> currently at 2.2 gig of ram and growing
<spiv> thumper: SIGQUIT is one option, gdb is another
<thumper> spiv: what number is siq quit?
<spiv> SIGQUIT would be my first choice in this case
<spiv> Ctrl-\
<spiv> kill -QUIT
<spiv> Pick your poison :)
<spm> spiv: kill -DIEDIEDIEDIEDIE ?
<thumper> in the debugger
<thumper> hmm...
<thumper> how can I bring the debugger to the foreground?
<spiv> spm: that's a lot of "IE DIED" ;)
<spiv> thumper: oh, hmm
<spiv> With --inet?  That does seem tricky.
<spm> spiv: some things need to be stabbed with flaming scissors while running, for extra died.
<spiv> Hmm, I bet we can do better there.
<thumper> hmm...
<thumper> doesn't seem to be in the debugger at all
<thumper> still in a tight loop
<thumper> seems to be stable around 2.6gig of ram though
<thumper> FWIW
<thumper> mwhudson: got a minute for some gdb help?
<spiv> thumper: I'd resort to gdb at this point
<mwhudson> thumper: ok
<thumper> mwhudson: I've killed the process, but I can regenerate at will
<mwhudson> thumper: run gcore $pid
<mwhudson> thumper: then follow the instructions on https://code.edge.launchpad.net/~pygdb-hackers/pygdb/trunk
<spiv> I think just 'bt' on maverick system would be a great start in this caes
<spiv> gdb on maverick has shiny new python smarts.
<thumper> I've not used gdb in years
<spiv> thumper: do you have a core file or running process?
<spiv> thumper: gdb -c CORE; or gdb -p PID
<thumper> $ gcore 1338
<thumper> core.6f7KUY:1: Error in sourced command file:
<thumper> ptrace: Operation not permitted.
<thumper> gcore: failed to create core.1338
<spiv> (I usually work with running processes)
<spiv> Oh, right, maverick...
<thumper> ptrace: Operation not permitted.
<thumper> ?
<spiv> there's a maverick setting you need to change
<spiv> to relax a security setting
<spiv> I forget what it is, but if you try to attach e.g. strace to a running process it helpfully reminds you.
<spiv> /etc/sysctl.d/10-ptrace.conf I think?
<spiv> echo 0 | tee -a /proc/sys/kernel/yama/ptrace_scope
<spiv> (the latter will relax it until the next reboot)
 * thumper has a core file
<spiv> Ok, "gdb -c COREFILE"
<spiv> then "bt"
<spiv> And pastebin that; that is hopefully enough in this case.
<spiv> Otherwise time to play with mwhudson's stuff I guess :)
<thumper> spiv: nothing useful at all
<thumper> spiv: http://pastebin.ubuntu.com/510610/
<spiv> thumper: pastebin?  gdb in maverick ought to be including Python function names automatically now.
<spiv> Oh wow, I guess you don't have python2.?-dev installed
<spiv> Or, hmm.
<spiv> -dbg
<thumper> mwhudson: pygdb.mi.GdbError: No symbol table is loaded.  Use the "file" command.
<thumper> spiv: I do have python2.6-dev installed
<spiv> Yes, python2.6-dbg
<spiv> For the debug symbols
<thumper> ah
<thumper> do I need a new core?
<thumper> or just install dbg and try again?
<spiv> Yep
<spiv> Just install dbg and look at the core file again
<thumper> yep to what?
<thumper> 52s to go
<spiv> Time for Dunedin to get a second wet string to the rest of the internet?
<thumper> spiv: no change
<thumper> should I have python-gdbm-dbg installed?
<spiv> No, unless you really care about getting extra details in tracebacks involving the 'gdbm' module
<spiv> (So, no.)
<thumper> spiv: I'm not getting anything useful with gdb
<spiv> Does gdb say anything about 'loading symbols'?
<spiv> Or it is verbatim the same output?
<thumper> spiv: same output
<mwhudson> then it's not finding the debug symbols somehow
<thumper> spiv: perhaps it needs the symbols when generating the core file?
<spiv> thumper: no, very much not the case
<mwhudson> thumper: when you run gdb /usr/bin/python2.6
<mwhudson> do you get a message like:
<mwhudson> Reading symbols from /usr/bin/python2.6...Reading symbols from /usr/lib/debug/usr/bin/python2.6...done.
<thumper> Reading symbols from /usr/bin/python2.6...Reading symbols from /usr/lib/debug/usr/bin/python2.6...done.
<thumper> yes
<spiv> Ok
<spiv> Now with that gdb process try typing "core core.1338"
<thumper> ok
<thumper> oh... lots of stuff
<spiv> (It seems pretty weird that 'gdb -c CORE' is failing to load debug symbols that gdb normally finds, but so long as we can workaround it I guess we just shrug our shoulders...
<spiv> )
<thumper> so, can I get the contents of bt to a file?
<thumper> there is a lot of stuff there
<spiv> Probably, but I'd have to spend too many minutes reading gdb docs to figure it out :/
<lifeless> spm: hey
<lifeless> spm: do you have any word on where the restrictedlibrarian ticket is up to ?
<thumper> spiv: actually, I could paste the first 300 levels of the stack :)
<spiv> thumper: sure :)
<thumper> spiv: http://pastebin.ubuntu.com/510619/
<thumper> spiv: perhaps that makes sense to you :)
<spiv> thumper: it's recursing during the str-ification of a NotBranchError
<spiv> In a way that tries to open a branch
<spiv> And causes another NotBranchError...
<spiv> For added confusion, it's happening in a Deferred callback chain.
 * thumper facepalms
<thumper> spiv: bzr error or lp error?
<thumper> spiv: or screwy interaction?
<spiv> Screwy interaction, I think :(
<spiv> bzr error is definitely part of it.
<spiv> NotBranchError(..., detail=None, bzrdir=a_bzrdir) calls a_bzrdir.open_repository during string formatting
<thumper> spiv: why?
<spiv> Which in this case is presumably triggering a NotBranchError, via a fairly long chain of events.
<thumper> to format the error?
<spiv> So it can add "location is a repository" to the error message, as a hint to the user
<thumper> in this case there is no repository with the bzrdir
<spiv> So that someone that tries e.g. 'bzr branch PATH_TO_SHARED_REPO' gets a helpful error
<spiv> I'll fix the bzr bug for that right now, it's pretty shallow.
<spiv> I'm not sure if LP should do anything differently, actually.
<thumper> yeah
<thumper> I'm not sure what we would do
<thumper> it then seems that python spins somewhat
<thumper> when it has hit its limit
<spiv> Well, it's doing nasty things
<spiv> Like capturing a lightly-strified copy of the entire call stack
<spiv> As part of the Twisted callback error handling
<thumper> really?
<thumper> that sounds kinda icky
<spiv> It is a bit :/
<thumper> is that twisted?
<thumper> or us?
<spiv> Hmm
<spiv> That's Twisted.
<spiv> So I wonder why NotBranchError in the first place.
<spiv> And/or, why a_bzrdir.open_repository() would raise NotBranchError
<thumper> spiv: could be in the translate path?
<thumper> maybe?
<spiv> Yeah
<spiv> Is it raising NotBranchError itself at any point?
<thumper>  self.assertRaises(
<thumper>             errors.NotBranchError,
<thumper>             BzrDir.open_containing_from_transport, transport)
<spiv> Well, that seems fine.
<spiv> That's a bzrdir method.
<spiv> If a VFS method ever raised it, that would be a problem I think.
 * thumper steps out for a minute
<spiv> bzrlib's open_repository etc only expect the filesystem to raise filesystem errors, like NoSuchFile and PermissionDenied
<spiv> if the filesystem ever raised something like NotBranchError I can understand it getting confused.
<thumper> spiv: ok, so should I file a bug for any LP bits?
<spiv> thumper: I can't think of anything specific enough
<spiv> I did a quick grep and don't see any obvious culprits in the LP code
<spiv> The full backtrace, all 1000 frames of it, presumably would tell us.
<spiv> If you want to stick "sys.setrecursionlimit(150)" somewhere and regenerate the backtrace, that might be helpful
<spiv> Hmm
<spiv> If I make a fake bzrdir that raises NotBranchError('path', bzrdir=fake_bzrdir) I get the recursion
<spiv> But it copes fairly gracefully
<spiv> i.e. stringifying it just gives NotBranchError: <unprintable NotBranchError object>
<thumper> hmm..
<spiv> Oh, *nice*
<spiv> It's Twisted's fault
<spiv> Specifically, I think it's the fault of it's "safe_repr" function
 * spiv looks more closely
<spiv> Oh, no, it's not, phew.  But then why...?
<spiv> Ok, so:
<spiv>  1) I know that NotBranchError.__str__ can recurse when bzrdir.open_repository raises another NotBranchError
<spiv>  2) I don't know why that causes an infinite loop rather than just a recursion error
<spiv> I can fix 1)
<spiv> But 2) is presumably still an issue in the codehosting server, and will still be lurking to bite us later.
<spiv> Unfortunately I think it will take a fair bit of patience to debug 2)
<spiv> So I'll fix 1) to avoid recursing
<spiv> But it may just change your problem, rather than fix it.
<thumper> that's a start
 * thumper has dinner on the table
 * spiv hmms again.
<spiv> Oh, right, it's something like:
<spiv> a bad error handler that can infinite loop
<spiv> Because str(err) is raising an error
<spiv> Which in turn trips the error handler
<spiv> which does str(err)
<spiv> etc
<spiv> The question is "where is the error handler"
<spiv> It's not that NotBranchError is particularly special
<spiv> Except that it happens to be one of the few errors that can trigger more VFS accesses during formatting.
<spiv> The exact error doesn't matter.
<spiv> thumper: https://code.edge.launchpad.net/~spiv/bzr/notbrancherror-recursion-2.2/+merge/38094
<spiv> thumper: I'd be very interested to know what happens if you apply that patch locally
<spm> lifeless: #41379: HA upload configuration for librarian please. ??
<_mup_> Bug #41379: partitioning in Polish: explain what K, B and F are <partman-target (Ubuntu):Invalid> <https://launchpad.net/bugs/41379>
<lifeless> spm: yes, please do
<lifeless> spm: [though perhaps I misunderstand your question :P]
<spm> heh, was just identifying if that was it
<lifeless> spm: oh, no. thats not the thing I was asking about
<lifeless> spm: 41202
<spm> ah right. different one. looks like it's been purty much suspended being worked on since the last update at the end of september. which given I've spent maybe 15mins on non ZOMG RT tickets in the past.... month, sounds about right.
<lifeless> spm: its zomg in its own way
<spm> 90+ is zomg. 89... isn't. :-)
<poolie> lifeless: the problem with directly using a generator or similar in .scenarios is the hidden cursor within it will be shared across all the instances...
<poolie> perhaps for things that have to be lazy we can just make it a callable that gives back an iterable
<poolie> actually->#bzr
<poolie> here's an interesting factoid: duplicity backups to s3 are about 5x faster with ssl turned off
<poolie> this is pretty much just pumping bulk data intercontinentally
<bigjools> morning all
<wgrant> Morning.
<mrevell> Morning
<jml> mrevell: hi
<stub> Is the topic out of date, or are we still having test failure issues in stable?
<jml> I don't know.
<jml> what's wrong with this commit message?
<jml> All lines of log output:'Commit message [[release-criticial=bigjools][r=jml][ui=none][bug=574083] Merge fix\n\tfor branch-distro script] does not match commit_re [(?is)^\\s*\\[(?:release-critical=[^\\]]+)\\]\\s*\\[rs?=[^\\]]+\\]]'
<jelmer_> jml: criticial?
<bigjools> lol
<jml> jelmer_: thanks.
<bigjools> if I had a penny every time I did that
<wgrant> bigjools: \o/ killing partner
<maxb> Anyone feel like discussing what I should do in an odd vcs-imports reviewing situation? The problem is that someone asked for a debian packaging branch to be imported rooting the branch inside the "debian" directory -- so I "fixed" it.
<maxb> But, then they emailed me saying they needed it otherwise because of bzr-builder infelicities
<maxb> I "fixed" it because there is another branch on Launchpad built on the history with it imported the way I fixed it to.
<wgrant> Isn't that bzr-builder thing fixed now?
<wgrant> Maybe it's not deployed on LP yet.
<wgrant> But that may mean that you can just ignore than for four days and then tell them to use the new bzr-builder feature.
<wgrant> s/than/them/. what happened there, I wonder...
<jelmer> As far as I know the nest-part fix has landed on Launchpad.
<maxb> Ah, has it made it out as part of the new qa-blessed frequent rollouts?
<wgrant> The UI support may have.
<wgrant> But the slave support needs a new bzr-builder in some PPA somewhere.
<jml> I discovered the ArchiveAdministration page today
<wgrant> Uhoh.
<wgrant> Do you like all the workarounds?
<jml> well, I haven't read it in detail
<jml> but how pleasant to have a list of all the major use cases of an important component of Launchpad
<jelmer> maxb: I don't think it can be used in production yet, but it should be in a reasonable period of time.
* jml changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.10 | PQM is Release-Critical (Release manager: EdwinGrubbs) | firefighting: stable has test failures | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting
<maxb> I've sent email to the user suggesting the import remain in the form I fixed it to and requesting any followup discussion proceed on launchpad-users
<maxb> jelmer: I'd welcome your thoughts on the oldest two vcs-imports in Pending Review state - I've looked at them and put an initial comment in the branch whiteboards
 * jelmer takes a quick look before lunch
<jelmer> maxb: the iceplayer one appears to've been recreated - did you take a look at it recently?
<maxb> 20101011 maxb The origin repository is bizarrely structured. I'm not sure there's a meaningful way to import this as a branch, but it's hard to say for sure given the origin repository only has one revision.
<jelmer> maxb: In that case, it doesn't really look all that bizarrely structured to me :-)
<jelmer> the version directory directly under trunk is a bit strange, but not too unusual
<maxb> jelmer: if you go up a level, and look under /unstable, they have a version directory there too
<maxb> If the upstream people continue to do that, the vcs-import would end up being the equivalent of importing multiple versions into one tree
<jelmer> maxb: For the jupiter branch, I agree that a root-level import doesn't make sense if we're already importing jupiter-current (apart from any other issues we might have with top-level root directories)
<jelmer> maxb: fair enough; it's hard to tell with just one revision though.. can you perhaps one of the lp-code developers?
<maxb> perhaps what one of the lp-code developers? :-)
<jelmer> maxb: Sorry, I meant /ask/ one of the lp-code developers
<maxb> right :-)
<jelmer> anyway, lunch!
<LPCIBot> Project devel build (102): STILL FAILING in 3 hr 50 min: https://hudson.wedontsleep.org/job/devel/102/
<cr3> how can I set someone as administrator of a team when there are no administrator yes/no radio buttons when attempting to modify the person within the team?
<jml> bigjools: do you know of any existing diagram kind of like this one: http://people.canonical.com/~jml/soyuz-system-diagram.jpg?
<bigjools> jml: there is something, one sec
<jml> bigjools: I'm talking to the new Ubuntu release manager, who's keen to understand how all everything fits together
<bigjools> I think it's on the old internal wiki
<bigjools> jml: and I can't find it :/  I remember cprov doing something
<jml> bigjools: what about the thing you did for the 2008 Epic?
<bigjools> jml: out of date but might help
<jml> bigjools: is that on the net?
<bigjools> it's a google doc
<bigjools> I'll invite you
<bigjools> jml: aha!    the presentation has got cprov's diagram embedded
<jml> bigjools: got a link?
<jml> oh email
<bigjools> jml: you will get email
<jelmer> jml: Is it public yet who the new Ubuntu release manager is?
<jml> jelmer: Yes. Kate Stewart, aka skaet.
<jml> can these bugs be closed now? https://bugs.edge.launchpad.net/soyuz/+bugs?field.tag=partner
<bigjools> jml: no
 * bigjools reminds jelmer to set bugs "in progress" ...
<jelmer> bigjools: sorry, I'm on it.
<bigjools> jml: I did it for you
<bigjools> jelmer:  even
<jml> I have to go. See you all tomorrow.
<jelmer> Enjoy your evening jml.
<bigjools> good night all
<lifeless> moin
* lifeless changed the topic of #launchpad-dev to: Performance Tuesday | Launchpad Development Channel | Week 4 of 10.10 | PQM is Release-Critical (Release manager: EdwinGrubbs) | firefighting: stable has test failures | https:/â/âdev.launchpad.net/â | Get the code:
<lifeless>           https:/â/âdev.launchpad.net/âGetting
* lifeless changed the topic of #launchpad-dev to: Performance Tuesday | Launchpad Development Channel | Week 4 of 10.10 | PQM is Release-Critical (Release manager: EdwinGrubbs) | firefighting: stable has test failures | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting
<maxb> Who is in charge of bzr-buildder in *-cat-lpbuildd ?
<lifeless> interesting question
<lifeless> cat is the sysadmin archive, so strictly them; but perhaps you mean 'who is responsible for updating it when needed' and that would be, AFAIK, the launchpad team.
<maxb> Mainly I'd like to find out why maverick has 0.3.1 but lucid 0.2
<lifeless> I'd guess at oversight. I think abentley has been doing a lot in this area recently, he may know.
<lifeless> losa ping
<lifeless> https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/304/steps/shell_7/logs/summary
<lifeless> xvfb startup failures :(
<bdmurray> lifeless: there is an issue getting private bug attachments via the API right?
<lifeless> theres an intermittent issue that is being intransigent
<lifeless> we want to deploy the token based approach asap but we're starved for LOSA time at the moment.
<lifeless> if its not intermittent, please comment on the bug how to reproduce reliably.
<bdmurray> I've been seeing the following: httplib2.ServerNotFoundError: Unable to find the server at lplibrarian.internal
<bdmurray> lifeless: which bug is that?
<lifeless> bdmurray: iz in malone somewhere ;P
<lifeless> bdmurray: oh, private bug attachments are DC only too, for now.
<bdmurray> lifeless: is there a timeline for fixing that?
<lifeless> bdmurray: yes, asap. (Its been asap for a month)
<lifeless> bdmurray: its the highest equal RT ticket we have open.
<lifeless> bdmurray: it has been a very busy month though
<lifeless> bbs
<mwhudson> morning
<bdmurray> lifeless: well sure, I was just wondering if it'd be this week, this month or ...
<thumper> morning
<thumper> lifeless: how often is https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html updated?
<lifeless> thumper: 5 minutes I think
<lifeless> thumper: I've asked urshina to run it as often as possible
<lifeless> bdmurray: I wish I knew
<thumper> lifeless: ok
<wallyworld> morning
<poolie> thumper: i'm saying, just once, in the code that runs there
<poolie> register_transport('lp:///', ....)
<poolie> then on the server side, any attempts to access that will be seen as having the right url, but they can be implemented differently
<thumper> wallyworld: morning
<wallyworld> yello
#launchpad-dev 2010-10-12
<LPCIBot> Project db-devel build (62): STILL FAILING in 4 hr 4 min: https://hudson.wedontsleep.org/job/db-devel/62/
<wallyworld> thumper: found problem :-)
 * wallyworld does happy dance
<thumper> wallyworld: awesome
<wallyworld> thumper: how's your stuff?
<thumper> wallyworld: well, I've figured a way to at least stop the worst error
<thumper> but thinking about better error handling
<thumper> rob had an idea but I had to cut him short as I had someone arrive
<thumper> but I think it is more of a future idea
<lifeless> definitely
<lifeless> way out there stuff
<wallyworld> perhaps error handling patterns need to be looked at across the codebase, maybe unify any disparate implementations to use "best practice"
<thumper> so...
<thumper> I'm going to go for the nicer simple fix that avoids the crappy error message
<thumper> possibly get that RCed into the branch we want to release
<wallyworld> my thoughts were blue sky, future stuff
<thumper> and move on to looking at the BranchRevision use cases
<wallyworld> just thinking out loud
<thumper> suer
<thumper> sure
<lifeless> wallyworld: refactoring +1; best practice mmm I prefer to say 'this works well, and let folk adopt it' - the poppendiecks had a quote about best practice - that it stops improvement & experimentation
<wallyworld> "best practice" to me is defined to be whatever a particular project says it is
<wallyworld> what whatever error handling patterns are deemed to work best for lp/bzr, they should be adopted more or less uniformly IMHO
<spm> "best practice" to me, is often a fallacy ;-) http://www.nizkor.org/features/fallacies/appeal-to-common-practice.html
<wallyworld> ok, so i hit a nerve with the bullshit bingo, overused cliche "-)
<spm> :-P
<wallyworld> all i meant was, i think we need, if not already there, a set of well defined patterns for various "things" that people are encouraged top adopt
<wallyworld> :-P right back at ya
<spm> heh
<lifeless> wallyworld: we don't have uniform situations, so uniform handling doesn't make sense.
<lifeless> wallyworld: documenting things that work well so that folk can use them is a good idea.
<wallyworld> hmmm, not sure i agree about the lack of uniformity
<lifeless> wallyworld: I'd like to reduce some of the variation we have because there is cognitive overhead there - I mean things like some bits being in twisted, some zope, some pop, some wsgi
<wallyworld> +1
<wallyworld> also, as a new person, i've found several ways to do stuff, i pick one, and people say "oh don't do it that way, that's bad"
<wallyworld> i've need to get some of these new starter ramp up issues documented. it's on my todo list
<lifeless> wallyworld: when someone says that, it may come from a couple of places
<lifeless>  * stylistic thing - our code review looks at a lot of irrelevant stuff we should just ditch, IMO.
<lifeless>  * functional issues - in which case the place you copied from needs fixing / and XXX would be appropriate.
<lifeless>  * maintenance issues - ditto
<wallyworld> one that comes to mind is design patterns used in "answers" - so not just simple stylistic stuff, but more substantial, legacy implementation issues
<lifeless> sure, that would fit under 'maintenance issues' above, do you think?
<wallyworld> yeah, suppose so, a form of technical debt
<stub> spm: Can you please kick off a staging update? I've swapped the database we built on the weekend into place.
<spm> stub: sure
<lifeless> stub: so, cassandra, you know if you're going to stay for the extra days or not, yet ?
<stub> lifeless: I don't think I can make it at all with the travel time :-(
<lifeless> ok
<lifeless> I'll book my tickets today/tomorrow then
<lifeless> stub: perhaps we can get a video feed of the training for you
<lifeless> or a DVD or something
<stub> If we can, that would be cool for more people than just me
<lifeless> indeed
<stub> We are now on 2.6 everywhere? I have a 2.5 compatibility fix I'd rather not land.
<stub> I'm not sure of the status of our last buildbots
<lifeless> spm: ^
<lifeless> stub: the db's are
<lifeless> stub: like you I'm unsure of buildbot status; there was a zomg rt ticket about it
<thumper> is devel shut off for landings?
<lifeless> jml: I've fixed loading/running of story tests in testr. mp coming soon
<poolie> lifeless: i put up a testscenarios mp
<lifeless> thanks
<stub> thumper: Any reason the revision karma allocater is a separate script rather than part of garbo?
<lifeless> stub: no good reason
<lifeless> stub: garbo was underadvertised
<lifeless> jml: https://code.edge.launchpad.net/~lifeless/launchpad/doctest/+merge/38182
<stub> lifeless, thumper: https://code.edge.launchpad.net/~stub/launchpad/bug-658124-revision-karma/+merge/38181 as it is, or I can move it to garbo after lunch. Might prefer as it is for rc?
<lifeless> as is for rc
<lifeless> stub: rc-reviewed. please let edwin know.
<lifeless> stub: I've code reviewed too, though ec2land won't find it because I can only have one vote.
 * thumper looks
<lifeless> stub: I'm curious why 2 queries are needed though, seems like a pg regression ?
<stub> Its one query assembled in two parts
<stub> http://paste.ubuntu.com/511378/ is the query I wanted, but this was the closest we could get with storm (and performs identically)
<lifeless> stub: ah, I see.
<lifeless> still seems weird to need to move the limit inside the exists; I would have expected pg to optimise ;)
<stub> By putting the limit inside, I'm requesting <= limit rows. If I put it outside, I get == limit rows.
<stub> limit then filter dupes vs. filter dupes then limit
<lifeless> anyhow, its faster. woo.
<wgrant> The Debian BTS sync is working again?
<StevenK> wgrant: I thought I heard a mumbling about it being turned on again, but I'm not sure
<jml> lifeless: cool.
<jml> lifeless: I'll check it once my inbox is empty. (soon now)
<LPCIBot> Project db-devel build (63): STILL FAILING in 4 hr 8 min: https://hudson.wedontsleep.org/job/db-devel/63/
<mrevell> Morning
<jml> mrevell: hi
<nigelb> wedontsleep.org - ha!
<nigelb> StevenK: the caffine link is a nice touch :p
<persia> StevenK, And you've two dead links on the page...
<StevenK> Indeed
<nigelb> "Way cheaper than a trip to Starbucks, Foosh Energy Mints are heavily caffeinated for an energy boost that takes effect quicker than monkeys chomp cheese. And they taste great! Try some now! Each mint contains more than 100 milligrams of caffeine...Wow" - RIGHT
<persia> Clearly the authors of that slogan have never seen monkeys trying to explain to the stupid humans involved that cheese smells rotten (which humans call "having sophisticated tastes")
<bigjools> does anyone know if it's possible to test that some code did a commit()?
<lifeless> bzr or db commit?
<bigjools> db
<lifeless> the commit is seen by the storm tracer
<bigjools> do we have any examples that you know of?
<lifeless> I think so, possibly using the test tracer (rather than the webapp.adapter tracer)
<lifeless> but 2321, I'm not going to try and find the example right now ;P
<bigjools> see you in 6 hours then :)
<lifeless> hah :P
<bigjools> are you at UDS >
<bigjools> ?
<lifeless> I will be
<lifeless> its 2 weeks from now
<bigjools> yeah I know, I'm going too
<lifeless> we'll have to have a beer ;)
<bigjools> the magic word
<bigjools> if I run "bin/test test_builder" I get circular import errors.  If I run "bin/test -t test_builder" I don't.  WTF.
<wgrant> bigjools: I see that sometimes too, eg. -m lp.archivepublisher fails with an SPPH circular import.
<bigjools> yes
<bigjools> I think it's because lp.bugs is importing SPPHG
<bigjools> SPPH
<bigjools> which is wrong on many levels
<wgrant> Well, I suspect c.l.d is involved too.
<bigjools> which is wrong on many levels
<wgrant> Heh.
<wgrant> True.
<bigjools> the Code guys solved this problem but I can't remember how - to get rid of c.l.{i,d} we need to make the API stuff see all the interfaces
<wgrant> It's easy enough.
<wgrant> Add a webservice module somewhere in your tree, import stuff into there.
<wgrant> Then add the <webservice blah blah> ZCML pointing to that module.
<bigjools> that's the badger
<wgrant> That's more c.l.i than c.l.d, though, I think.
<bigjools> btw the new buildd-manager is on DF
<bigjools> seems to work :)
<wgrant> The OMFG-5KLOC-DIFF one?
<bigjools> 6k, yes
<wgrant> Ah, it was only 4K when I last looked.
<wgrant> I didn't extrapolate far enough :P
<bigjools> bzr di -r submit:|wc -l
<bigjools> 6286
<wgrant> Owww.
<wgrant> Hmm.
<bigjools> as jml pointed out we should have started at the top instead of the bottom (wrapping calls in maybeDeferred) and we could have landed stuff sooner
<wgrant> 2 hour downtime with a day's notice? :(
<wgrant> bigjools: DistroSeries.checkLegalPocket refuses to publish binaries in non-Release pockets for a Development series (but Frozen is allowed). This seems fairly strange.
<wgrant> I can't see a good reason for it.
<bigjools> why would you need to do that?
<wgrant> Well, I hit it in tests, but Ubuntu frequently uses -proposed and -security before release.
<wgrant> It just happens to work now because the series is usually frozen beforehand.
<bigjools> why would they do that when they can upload to -release?
<wgrant> bigjools: It is desired that the Release pocket matches the images.
<bigjools> then it should be frozen, no?
<wgrant> And it's handy to get a head-start on SRUs by uploading to -proposed beforehand.
<wgrant> True.
<wgrant> But it seems odd to allow uploads to more when a series is frozen than when it's open.
<bigjools> seems perfectly cromulent to me
<wgrant> Still, the whole Frozen-as-a-status thing is crackful.
<bigjools> why?
<wgrant> I'm not entirely sure. It just doesn't seem right to have the series bouncing between Development and Frozen, particularly since we have other statuses (Future, Experimental) which don't have obvious freeze semantics.
<wgrant> I think it would be nicer if there was a separate field for that.
<wgrant> But anyway.
<wgrant> My tests now work around the crazy restriction -- just thought it was a bit strange.
<wgrant> (I'm fixing that hack I introduced last week, and making the related publisher tests more thorough and less sucky)
<wgrant> (and removing the whole architecture[:7] madness)
<bigjools> great
<deryck> Morning, all.
<maxb> How is RT 41738 ("lpbuildbot needs a Lucid production buildslave") going?
<maxb> I was wondering if launchpad-database-dependencies could require strictly pg8.4 yet
<wgrant> That seems like it sort of has to happen before Thursday...
<jtv> bac discovered that Storm's sqlobject gets is_empty completely wrong.  Bug 659078.
<_mup_> Bug #659078: sqlobject is_empty and __nonzero__ are incorrect <Storm:New> <https://launchpad.net/bugs/659078>
<deryck> allenap, hi.  The kanban board seems to indicate Bug #650991 is qa-ok.  Is that right?
<_mup_> Bug #650991: Add getSubscriptionsForBug to IStructuralSubscriptionTarget <qa-needstesting> <story-subscribe-to-search> <Launchpad Bugs:Fix Committed by allenap> <https://launchpad.net/bugs/650991>
<allenap> deryck: There's one card remaining which I should probably QA on staging.
<deryck> allenap, ah, ok.  Thanks.
<jkakar> Are pop-ups (like to assign a bug or request a review) broken for other people on edge?  I consistently get 'Loading results failed.' and it's been this way for a few days.
<jml> I agree w/ wgrant, I think. It would be good to have the control for what package uploads are allowed separate from status
<bigjools> jml: we need to enumerate the pros and cons for that.  I'm neutral at the moment.
<allenap> jkakar: Everything seems to be working fine here. Is anything else dumped to the js console?
<jkakar> allenap: Let me check.
<wgrant> Several people have seen timeouts in the person picker since the 8.4 migration.
<wgrant> I wish a-f would return an error code upon encountering an error.
<wgrant> Rather than just continuing and indicating success...
<jkakar> allenap: Getting '503 Service Unavailable' when I try to search for 'jtv', to assign a bug, at https://bugs.edge.launchpad.net/storm/+bug/659078
<_mup_> Bug #659078: sqlobject is_empty and __nonzero__ are incorrect <Storm:Fix Committed> <https://launchpad.net/bugs/659078>
<allenap> jkakar: Ah, see wgrant's comment above. Time-outs it seems.
<jkakar> allenap: It's really bad right now, I haven't been able to assign a bug or request a review for days. :/
<jkakar> I've been using /+request-review on merge proposals.  Is there an equivalent for assigning bugs?
<wgrant> jkakar: Expand the expandy thing with the button on the left of the task.
<jkakar> wgrant: Ah, right, thanks.
<allenap> jkakar: That's really bad. I haven't experienced anything nearly that bad. Are the problems consistent with other browsers?
<jkakar> allenap: Dunno, just been trying in Firefox.
 * jkakar tries with Chromium
<jkakar> allenap: Same in Chrome.  I wouldn't expect the browser to make a difference though, given that it's a timeout on the server side.
<allenap> jkakar: Oh, of course. Do you get an OOPS?
<jkakar> allenap: Not obviously, just a message that says 'Loading results failed.' in red, in the person or branch picker dialog.
<wgrant> jkakar: Firebug might be helpful.
<wgrant> Since the JS isn't.
<allenap> jkakar: Gah, bloody javascript!
<allenap> (*Our* javascript; I don't mean to malign javascript in general.)
<jkakar> wgrant: Yeah, I tried Firebug (how I discovered it was returning 503).  Didn't see anything obvious about OOPSes.
<wgrant> jkakar: There's no X-Lazr-Oops response header?
<jkakar> allenap: Javascript deserves some amount of general maligning.  It's too bad it's taking over the world and that, in 5 years, we'll be writing server code in it. :/
<wgrant> It's sometimes there.
 * jkakar looks more closely
<jkakar> wgrant: Hah, now that I try again it's working. :/
<wgrant> Awesome.
<allenap> sinzui: Have you heard of any situations where a deactivated mailing list can't be reactivated? This is with regard to the last three comments in https://answers.edge.launchpad.net/malone/+question/58912
<sinzui> allenap, yes, when the team is renamed, the list and it's email address are invalidated.
<allenap> sinzui: Is there any way to know if a team has been renamed, or shall I just ask the user?
<sinzui> allenap, I am not certain if a losa needs to delete mailman/monharc files or not but It would be mentioned in lphowto on the canonical wiki
<sinzui> we would need to ask the user
<allenap> sinzui: I'll do that. Thanks.
<sinzui> allenap, actually, this team cannot be renamed because the existing list has not been purged
<allenap> sinzui: Ah. Okay, I'll leave this one in the hands of the LOSAs then.
<LPCIBot> Project devel build (103): STILL FAILING in 3 hr 46 min: https://hudson.wedontsleep.org/job/devel/103/
<sinzui> EdwinGrubbs, bug 645702 is qa-ok. I think the registry is ready for release
<_mup_> Bug #645702: oops in holdMessage storing large message  <mailing-lists> <oops> <qa-ok> <Launchpad Registry:Fix Committed by sinzui> <https://launchpad.net/bugs/645702>
<EdwinGrubbs> sinzui: I'm still waiting on getting the cronscript run on staging for the job queue I added, but the web page didn't timeout when approving a bunch of proposed members, so it's looking good.
<sinzui> Edwin and keep in mind that staging is super slow. Loading /gdp timed out 3 times.
<EdwinGrubbs> jtv: ping
<jtv> EdwinGrubbs: yes?
<jtv> EdwinGrubbs: you called?
<EdwinGrubbs> jtv: are you able to QA bug 650877?
<_mup_> Bug #650877: Not generating TranslationTemplatesBuilds on staging <qa-needstesting> <Launchpad Translations:Fix Committed by jtv> <https://launchpad.net/bugs/650877>
<jtv> EdwinGrubbs: if staging is finally runningâ¦  it's not been possible yesterday, or today during working hours.
<EdwinGrubbs> jtv: staging is up
<jtv> Then I'll try it.
<EdwinGrubbs> allenap: ping
<allenap> EdwinGrubbs: pong
<allenap> Ah, okay, staging.
<EdwinGrubbs> allenap: can you QA bug 650991?
<_mup_> Bug #650991: Add getSubscriptionsForBug to IStructuralSubscriptionTarget <qa-needstesting> <story-subscribe-to-search> <Launchpad Bugs:Fix Committed by allenap> <https://launchpad.net/bugs/650991>
<allenap> EdwinGrubbs: Sure.
<EdwinGrubbs> lifeless: ping
<mars> gary_poster, do we now know when we will officially be done with Python 2.5?
<mars> gary_poster, and we can start writing Python 2.6 code? :)
<gary_poster> mars, yes, earlier this morning.  I'm going to submit a branch to make sure that the setup is working, but everything here is Lucid: https://lpbuildbot.canonical.com/waterfall
<mars> \o/
 * mars cues the marching band!
<gary_poster> :-)
<jml> and we are 100% lucid on prod?
<gary_poster> yes, jml.  that's what losas tell me. :-)
<gary_poster> and stub
<sinzui> allenap, is https://bugs.edge.launchpad.net/malone/+bug/551848 fix released or in progress?
<_mup_> Bug #551848: X-Launchpad-Bug link on +subscribe pages links to wrong page <qa-ok> <trivial> <ui> <Launchpad Bugs:Fix Committed> <https://launchpad.net/bugs/551848>
<jml> gary_poster: wonderful :)
<gary_poster> definitely
<jml> what are we doing on production for the psycopg thing?
<gary_poster> an older version is the only option AFAIK.  stub will be working on the proper fix as one of his upcoming tasks.  Would you like me to verify with losas, jml?
<jml> gary_poster: no, that's fine, just curious.
<gary_poster> cool
<jml> I guess the versioning/"can't install lp-deps" problems really only hit maverick.
<allenap> sinzui: It says Fix Released, but why is there doubt?
<allenap> s/Released/Committed/
<sinzui> allenap, look at the date? The code from that date was released last month
<sinzui> So did we release the fix, or should it be targeted to 10.10
 * allenap looks.
<allenap> sinzui: It's released. I've marked it as such and put it in the 10.09 milestone.
<sinzui> thank allenap
<abentley> james_w: I understand there was a bug related to nest-part/manifests in bzr-builder recently.  Is the fixed version in the PPA?
<james_w> abentley, the bzr-builder ppa? yes.
<abentley> james_w: great, thanks.
<james_w> 0.6
<maxb> james_w: What would the ETA be on there being a working nest-part instruction in *-cat-lpbuildd ?
<james_w> maxb, no idea, sorry
<james_w> abentley would probably know better than I
<abentley> maxb: I've just requested it.  You'd have to ask lamont for an actual ETA.
<LPCIBot> Project db-devel build (64): STILL FAILING in 2 hr 19 min: https://hudson.wedontsleep.org/job/db-devel/64/
<jml> g'night
<bdmurray> james_w: do you know if there is way to find out from a bug task if some one is allowed to upload the associated source package?
<james_w> bdmurray, yes there will be a way, but it won't be particularly direct I think
<bdmurray> james_w: I'd want to end up at isSourceUploadAllowed()?
<james_w> bdmurray, ubuntu-archive-tools has an implementation of this, but I think IArchive.checkUpload might do it all now
<james_w> bdmurray, I think, confusingly, that only takes in to account packagesets
<james_w> bdmurray, http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/annotate/head:/sync-helper.py#L67
<bdmurray> james_w: okay, I'm trying to allow people to set milestones in Launchpad
<james_w> bdmurray, ah, you are talking about inside the LP codebase?
<fjlacoste> sinzui: hi!
<bdmurray> james_w: right
<sinzui> hi fjlacoste
<james_w> bdmurray, in that case then checkUpload or verifyUpload or something is probably where you want to start looking
<james_w> bdmurray, also look for lp.code's permission checking on package branches, as they have a similar need
<jtv> Can anyone else push to staging codehosting?
<bdmurray> james_w: okay, thanks!
<james_w> bdmurray, it's complicated by having to deal with components etc., but you should be able to get close to "if this person uploaded a source package of that name to the current distroseries would it be rejected?"
<james_w> bdmurray, I don't know if you want to deal with released series differently there
<lifeless> losa ping
<lifeless> I want to put a new feature rule on staging (for QA)
<lifeless> hard_timeout pageid:BugTask:+index 1 5000
<lifeless> gary_poster: ping
<gary_poster> hey lifeless
<lifeless> up for a brief call ?
<gary_poster> lifeless, in 45 min ok with you?
<lifeless> won't you be on a call with flacoste then ?
<lifeless> (I mean, it would be ok for me)
 * gary_poster though flacoste was out today
 * gary_poster checks calendar
<flacoste> gary_poster: i'm in :-)
<gary_poster> :-) ok
<gary_poster> lifeless: ok, we'll try again later; I'm stepping out in about 3 minutes though, and don't want our call to be *that* short :-)
<lifeless> ok
<EdwinGrubbs> lifeless: can you QA bug 627701?
<_mup_> Bug #627701: Make it possible to use feature flags to override the global timeout for specific pages <qa-needstesting> <Launchpad Foundations:Fix Committed by lifeless> <https://launchpad.net/bugs/627701>
<lifeless> EdwinGrubbs: see my losa ping above
<lifeless> EdwinGrubbs: (no, *I* can't, needs a losa)
<EdwinGrubbs> ok, thanks for getting the ball rolling.
<mbarnett> lifeless: hello.  just got back from snacking
<mbarnett> lifeless: so, new feature rule..
<lifeless> mbarnett: yeah
<lifeless> mbarnett: https://staging.launchpad.net/+feature-rules
<mbarnett> lifeless: added
<lifeless> gary_poster: hey, so whenever you want to chat, just ping me. I'm doing food now, then will be looking at parallel testing more.
<gary_poster> cool thanks lifeless
<rockstar> Woo! Four more windmill tests before a new lazr-js is ready!
<lifeless> mbarnett: thanks was otp
<lifeless> I'm trying now :)
<mbarnett> lifeless: cool.
<lifeless> great, the timeout is way low.
<lifeless> please remove that rule now, or staging will be useless ;)
<wallyworld> abentley rockstar thumper: standup?
<thumper> wallyworld: aye
<thumper> wallyworld: isn't it 6:30 where you are?
<wallyworld> yeah, but i have to go to a breakfast at the kid's school
<thumper> heh
<thumper> breakfast at school?
<wallyworld> there's a middle school orientation thing - he's going into grade 5 next year
<abentley> wallyworld, thumper: sure.
<lifeless> flacoste: oh, there was one thing
<lifeless> flacoste: this ppa/open teams thing.
<flacoste> lifeless: yep
<lifeless> there seems to be a knee-jerk reaction happening, which is a bit unpleasant
<lifeless> thats really all I had to say
<rockstar> abentley, thumper, wallyworld, you guys still can't hear me, can you?
<rockstar> Shite.
<rockstar> abentley, that's because I'm messing with the gain.
* mwhudson changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.10 | PQM is Release-Critical (Release manager: EdwinGrubbs) | firefighting: stable has test failures | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting
<lifeless> does stable still have test failures?
<flacoste> thumper: i'm available
<thumper> flacoste: just getting off with jam
<lifeless> thumper: oh laa
<mwhudson> ...
 * lifeless guesses gary_poster is free now ;P
<EdwinGrubbs> Ursinha-afk: ping
<jcsackett> is there an easy way to set a projectgroup for launchpad.dev?
<wgrant> jcsackett: /projectgroups/+new?
<jcsackett> wgrant: and this is what i get for juggling too many things at once on too little sleep. thanks for pointing out the obvious.
<wgrant> jcsackett: It's not exactly obvious any more, since it's no longer visible to normal users.
<jcsackett> wgrant: that's what confused me. i saw the help state that you had to get an lp team member to do it, and assumed script.
<jcsackett> didn't think about the fact that an lp member has different permissions on the site and could do it from there.
<wgrant> Heh.
<wgrant> bdmurray: Can you share code with the thing that allows uploaders to do release targetting?
<wgrant> bdmurray: That code is wrong (doesn't take into account packageset permissions for teams, or something like that), but it should probably be shared.
<lifeless> thumper: I'd like a chat when you have a few minutes
<lifeless> thumper: not urgent, doesn't need to interrupt anything.
<bdmurray> wgrant: I was looking at BugTask.userCanEditMilestone and _userIsPillarEditor but didn't get very far
<wgrant> bdmurray: There's a reason I gave up on fixing that myself, I presume.
 * wgrant looks.
<wgrant> bdmurray: The current magic is BugNomination.canApprove.
<bdmurray> wgrant: Isn't a nomination for a series not a milestone?
<wgrant> Most of the logic should probably be moved onto a method on BugTask, with canApprove just checking if the user can edit any relevant BugTasks.
<wgrant> bdmurray: Yes, but duplicating that code would be insane.
<wgrant> bdmurray: So it looks like you want to call distribution.main_archive.verifyUpload
<wgrant> Not checkUpload.
<thumper> lifeless: I've got time now if you want to talk
* spm changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.10 | PQM is Release-Critical; devel is closed (Release manager: EdwinGrubbs) | firefighting: stable has test failures | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting
<maxb> Can someone tell me the current status of https://rt.admin.canonical.com/Ticket/Display.html?id=41738 ("lpbuildbot needs a Lucid production buildslave")
<maxb> ?
<lifeless> https://code.launchpad.net/~bzr/bzr-history-db/trunk
<lifeless> maxb: resolved
<maxb> yay
 * maxb unholds the meta-lp-deps pg8.4 MP
<maxb> jelmer: If you have a moment, could you nudge https://code.edge.launchpad.net/~maxb/meta-lp-deps/pg8.4/+merge/32200 to Approved now?
<jelmer> maxb: otp, will have a look when I get back
<wgrant> Ooh, buildd-slavescanner.txt has finally been killed \o/
#launchpad-dev 2010-10-13
<jelmer> wgrant: yes, we should celebrate this joyous occasion.
<wgrant> Although the branch is a bit of a read :/;
<wgrant> LOSA ping: Can someone please run http://paste.ubuntu.com/511984/ on prod? We seem to have corrupt more builds like the ones we found when trying to open Natty.
<spm> wooo
<wgrant> We had to fix those quickly, so the evidence was destroyed.
<wgrant> So it is probably... good... that there is more breakage.
<StevenK> FSVO 'good'
<spm> wgrant: (4510 rows) but they're all looking like " 4789 |      |         |"
<wgrant> (missing BuildQueues in both cases)
<wgrant> Er.
<wgrant> Did I miss a join somewhere...
<wgrant> Whoops. Left out the WHERE clause in that version of the query.
<wgrant>  WHERE sourcepackagerecipebuild.id IN (4256, 4257);
<wgrant> *Two* rows.
<spm> ha
<spm>   id  |  id  |   id    | id
<spm> ------+------+---------+----
<spm>  4256 | 4255 | 6311021 |
<spm>  4257 | 4256 | 6311022 |
<spm> wgrant: ^^
<wgrant> Precisely as I suspected.
<wgrant> Thanks.
<wgrant> Now to work out why we have various builds without BuildQueues.
<wgrant> How I hate this model.
<lifeless> thumper: https://devpad.canonical.com/~stub/ppr/lpnet/latest-daily-pageids.html
<wgrant> How far do buildd-manager logs go back?
<StevenK> A long while
 * StevenK goes for breakfast before his stomach breaks out on its own
<lifeless> rooooar
<lifeless> holy cow
<lifeless> hwsubmission ||  525012.40 tuples/sec
<lifeless> 'release time anyone' ?
<lifeless> except, its not writes. hmmm
<wgrant> Yeah, that can't really be writes, as it would go through the last released count of Ubuntu users in 24 seconds.
<elmo> wgrant: s/count/estimate/
<elmo> :-P
<wgrant> elmo: True that.
<lifeless> thumper: -> https://bugs.edge.launchpad.net/bzr/+bug/93609 <- poolie:
<_mup_> Bug #93609: Better error messages for bzr lp:// <launchpad> <lpurl> <Bazaar:Confirmed> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/93609>
<StevenK> wgrant: Do you need logs?
<wgrant> StevenK: I'd like to see what the logs have to say about BinaryPackageBuilds 1968526, 1968544, 1969032, and SourcePackageRecipeBuilds 4256, 4257.
<wgrant> Because they somehow ended up NEEDSBUILD without a BuildQueue.
<StevenK> wgrant: How far back are we talking?
<wgrant> StevenK: The BPBs are a little over three weeks ago. The SPRBs 11 days ago.
<wgrant> In two months I will be able to stop pestering people for logs, yay.
<spm> wgrant: in that losas aren't people? or???
<wgrant> Heh.
<lifeless> losa ping
<lifeless> I need someone to delete "hard_timeoutpageid:BugTask:+index15000" from https://staging.launchpad.net/+feature-rules
<spm> lifeless: you have been unfeatured
<lifeless> thank you
<lifeless> I *so* want to not get mail for invalid bug tasks.
<wgrant> There are two types, though.
<wgrant> Of Invalid task.
<wallyworld> lifeless: do i also need to ask for a separate review in #launchpad-reviews for that menu branch? or is your stamp of approval enough?
<lifeless> wallyworld: IIRC userdict provides better hook points than dict, though its not really relevant here
<lifeless> wgrant: bad and worse?
<lifeless> wgrant: I've clickly clicked for you
<lifeless> bah
<lifeless> wallyworld:
<wallyworld> lifeless: yo
<lifeless> ^ 3 lines
<wallyworld> ack. so i'll leave the code as is...
<wgrant> lifeless: "This isn't a valid bug", and "This isn't a valid bug here"
<lifeless> uhm
<lifeless> I think you're conflating task and bug
<lifeless> something like : a bug is invalid if all tasks are invalid
<wgrant> It is necessary to conflate them.
<lifeless> â½
<wgrant> We have only per-task statuses.
<wgrant> But, as you say, a bug could be considered invalid if all its tasks are.
<wgrant> The interactions with notifications may depend on both.
<lifeless> well, for my needs, if I'm structurally notified via an invalid task, i don't want to be.
<wgrant> But what if the user is arguing that the bug is valid?
<wgrant> You do want to be notified.
<poolie> hi lifeless
<poolie> 5-digit bug hey
<poolie> i agree that looking at the cases is good
<lifeless> wgrant: can't they toggle it to new?
<wgrant> lifeless: That's impolite.
<lifeless> poolie: hey, so, thumper and I were talking.
<lifeless> poolie: I promised to file a bug describing a design to get better messages out with hopefully backwards compat
<lifeless> poolie: and suggested that spiv would be a great person to look at the detail.
<lifeless> poolie: when I wwent to file it I found such a closely aimed bug that I reused it.
<lifeless> wow
<lifeless> 1026 /  119  Distribution:+ppas
<lifeless> ^- unhappy pages R us.
<wgrant> Yeah, known 8.4 regression.
<wgrant> Not sure of the details.
<lifeless> yeah
<wgrant> But there are a few bugs on it.
<lifeless> count(*)
<lifeless> we've dupped them all I think
<lifeless> bad query is listed in the remaining active
<poolie> yep, i thought a bug would be good too
<poolie> and that's it
<wgrant> I don't see the bug.
 * wgrant searches other projects.
<lifeless> https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=timeout
<lifeless> wgrant: ^
<wgrant> Ah, on launchpad.
<lifeless> fixed
<lifeless> such a nuisance
<wgrant> I was trying to fix it.
<wgrant> But it kept using the non-AJAX form.
<wgrant> Something odd is going on.
<lifeless> you clicked too quickly
<lifeless> gotta wait for yui to initialize and overlay
<wgrant> I thought so.
<wgrant> But apparently not.
<lifeless> odd indeed then
<wgrant> I can wait a few seconds after the status picker works, and the project one still doesn't.
<lifeless> oh, it never has
<wgrant> Hm?
<lifeless> there isn't an ajax project picker is there? just the drop-down if you click on the expander
<wgrant> There is an AJAX project picker.
<lifeless> I've never seen it :P
<wgrant> It's often buggy, but it usually at least appears.
<lifeless> what dor str(Person) do (when Person is a Launchpadlib object)
<wgrant> lifeless: IIRC str()ing an Entry will give you its URL.
<lifeless> blah, thanks.
<wgrant> Ah, now I see the relevance.
<lifeless> wgrant: ?
<wgrant> The qa-tagger bug.
<lifeless> ah yes
<wgrant> I really should add that to my sieve script, since it ends up in my inbox.
<lifeless> open sourcing by incremental pastebin :P
<wgrant> I learnt a lot about LP through dogfood back when it had public tracebacks :P
<wgrant> But then Julian fixed that :(
<poolie> aw
<poolie> i wonder why not enable them?
<wgrant> They leak data.
<poolie> in variable values etc?
<wgrant> Although not much worse than API exceptions can do.
<wgrant> The most obvious one is object reprs in Unauthorized exceptions.
<wgrant> But there are probably others.
<StevenK> As an odd question, I wonder why ohloh doesn't have any updates from Launchpad branches since Jan
<poolie> really?
<poolie> you could mail them
<StevenK> I'm checking again
<maxb> Hmm. I have a PPA build finished 13 minutes ago and still not published
<StevenK> Last commit it shows was 4 months ago, but the code metrics seem much older
<maxb> 18 minutes :-/
<StevenK> The publisher runs every 20 minutes, so that is the worse case, right?
<maxb> The *PPA* publisher used to run every 5 minutes, last time I was told
<StevenK> maxb: Which PPA?
<maxb> bzr-beta-ppa/ppa - it does seem to have just published now
<mars> lifeless, ping, if you have a moment, I am in need of some help with a zope-related implementation question
<mars> or thumper, if you have a moment to spare?
<thumper> mars: whazzup?
<mars> Hi thumper, I have a question about storing state for the duration of a Zope request
<thumper> right...
<thumper> and what is the question?
<mars> The profiling code needs to store the active profiler information for the duration of the request.  I could throw that information onto the request object itself, or take the current approach of using a module-level threading.local()
<mars> One approach turns the request object into a cesspool, the other uses a sort-of-magic secret module level variable - is one approach preferred over the other?
<thumper> mars: does this relate to the existing timeline code?
<mars> no
<thumper> mars: my suggestion would be to do what the timeline code does
<thumper> mars: the request object is already a cesspool
<mars> heh, ok
<mars> thumper, where would I find the timeline code?
<thumper> mars: I think there is a part of the request object used to store "stuff"
<thumper> mars: lp.services ?
<mars> right
<mars> thank you for the help thumper
<lifeless> mars: hi
<lifeless> mars: webapp.adapter
<lifeless> mars: as thumper says, see what lp.services.timeline.requesttimeline does
<lifeless> (which is to shove it into webapp.adapter and cry with XXX's.)
<mars> lifeless, cool, thanks
<lifeless> mars: doesn't the profiler already work though?
<lifeless> [I'm interested in what you're hacking on]
<mars> lifeless, the profiler worked when using lazr.config.  The setting was static for the duration of the request, so profiling was either on or off
<lifeless> mars: are you working on flags to enable profiling?
<lifeless> mars: if so, i think it still needs to be either on or off, just evaluated earlier.
<mars> lifeless, but feature flags are set and cleared with request events, and lo, so is profiling.  If the features get nuked before the profiling end hook is run, no profile is generated
<mars> I am dealing with an event processing order bug
<lifeless> mars: sure, but wouldn't 'just' caching the result of 'should we profile' be all thats needed (and in fact I thought that that is what it did?)
<lifeless> win 67
<mars> lifeless, no, it did not cache the 'profiling is on' flag (unless you count the aforementioned thread-local storage as the flag)
<mars> lifeless, and I was asking about the best implementation for said cache
<mars> either thread-local storage, or a request.atttribute
<lifeless> end_requqest does this
<lifeless> _profilers.profiler is not None
<lifeless> so it caches (by virtue of using an object)
<lifeless> mars: I expect you'll have a great deal of trouble changing the cache implementation for profiling
<lifeless> until we fix two bugs:
<mars> hmm, ok
<lifeless>  - many tests call in-request-context-code outside of a reqest-context
<lifeless>  - scripts don't establish a request-context in th esame way the webapp does
<lifeless> the second point won't really affect you atm as we don't profile scripts, but the first one will hurt - a lot-
<mars> so if I change this then I'll probably trip over yet more test-related bugs
<lifeless> see the 'except AttributeError:' on line 78
<lifeless> I'd be delighted to see the root issue here fixed.
<lifeless> but I don't know if you have the time budgeted for that :)
<mars> this has rotted on the kanban board already (as I am sure you and Martin have noticed).  I think I'll just try and land it :)
<lifeless> ok, so perhaps I can help solve your immediate issue.
<lifeless> what is it ?
<mars> well, I think it is solved then - I just have to add a comment string or two to that thread-local storage to make it less magic
<mars> name it _active_profilers or some such obvious thing, etc.
<lifeless> mmm
<lifeless> there are no inactive_profilers
<mars> well, _active_profile then
<mars> if _active_profile.actions = None
<lifeless> mars: if you come up with a good name; great. Myself, I'd just add a comment to the assignment and the module dostring.
<mars> anyway, something like that
<mars> lifeless, yes, will do
<mars> lifeless, thank you for the help, and for pointing past the minefield
<lifeless> de nada
<wgrant> If I have a db-devel-based branch that will land in devel after the release, how should I propose it? With db-devel as a prereq?
<lifeless> propose it to devel
<lifeless> after the release, the diff will be normal :)
<wgrant> If I somehow convince it to update after the release, sure.
<wgrant> I guess I could just wait until after the release.
<lifeless> one day
<wgrant> Although I have to wonder why we don't merge db-devel into devel at the time devel freezes.
<lifeless> I suggested that on the lit ;)
<wgrant> Ah, I'm a bit behind at the moment.
<Ursinha-afk> EdwinGrubbs, pong?
<Ursinha-afk> EdwinGrubbs, holiday here today, sorryu
<Ursinha-afk> *sorry
<EdwinGrubbs> Ursinha-afk: no problem, we sorted out some issues we were having with the qatagger. It's working now, and we opened bugs for the problems that should be fixed later.
<wgrant> StevenK: re. Ohloh: The import has been tried a few times, but always fails after working for a couple of weeks.
<wgrant> StevenK: Their bzr importer doesn't seem to be awfully good.
 * wgrant requests that it be kicked.
<wgrant> I wonder if the regular failures are because of the frequent LP downtime.
<spm> sush :-)
<wgrant> Well, we are the only hosting site I know of that has regular downtime...
<poolie> lifeless: http://sourcefrog.wordpress.com/2010/10/13/59/ about ssl performance may interest you
<lifeless> poolie: thaks
<jtv> stub: question about the BranchRevision patchâ¦
<stub> ?
<jtv> The problem is too much downtime when setting a new primary key, right?
<jtv> The change requires creation of a huge new unique index, even though we already have one.
<jtv> So I'm wondering: why do we need to declare a primary key in the first place?  Does Slony require it?
<wgrant> Storm does.
<jtv> Storm requires us to declare a primary key _to Storm_.  But does it require us to declare a primary key _in the schema_?
<wgrant> Ah, fair point.
<jtv> Because AFAIK this whole primary key business is little more than convention, a bit of optional syntactic sugar.
<wgrant> "Slony-I needs to have a primary key or candidate thereof on each table that is replicated."
<wgrant> Hm.
<jtv> Okay, what does it consider a candidate?  Because we have unique index and we have not-null.
<wgrant> One can override it to another candidate key.
<wgrant> So it should be doable, yes.
<wgrant> (just needs UNIQUE and NOT NULL)
<jtv> stub: we already have the index and constraint we needâ¦ what do you think?
<stub> jtv: Slony requires a primary key
<wgrant> It says it requires a primary key or a candidate key.
<jtv> stub: see what wgrant just dug upâwe can define a primary key there without declaring it in the schema.
<stub> I like to stick to best practices, and from the best practices section " Discussed in the section on Replication Sets,  it is ideal if each replicated table has a true primary key constraint; it is acceptable to use a "candidate primary key."
<wgrant> Well, it's either use a candidate key or have several hours of downtime...
<mwhudson> there's also the 'make branchrevision2' plan isn't there?
<mwhudson> or has that been shot down for some reason
<wgrant> That would work too.
<wgrant> At the expense of a crapload of disk, I guess.
<mwhudson> yeah
<stub> Candidate key is certainly an option, but we need to teach or maintenance scripts about it.
<jtv> Everyone bring your spare disks to the DC for Operation Dunkirk.  :)
<stub> There is also the ignore-it-until-we-drop-branchrevision route. There might be faster, smaller and better solutions than the big table in the RDB.
<wgrant> How long until we run out of rows?
<mwhudson> yeah, that's probably a reasonable approach
<mwhudson> wgrant: it's at 600 million ish and runs out at 2 billion
<mwhudson> so, no massive rush
<wgrant> Oh, I didn't realise it was only 600 million.
<jtv> What's the next id though?
<stub> The table is pretty much INSERT only
<mwhudson> good question, but probably not noticeably more than the row count
<wgrant> Except on branch deletion and overwrite, I guess.
<stub> Highest id is 757259996
<jtv> And aborted transactions, and maintenance.
<wgrant> True.
<jtv> So that's okay.
<mwhudson> according to the graph (which is only an estimate i think) we've added 300 million ish rows in the last year
<jtv> Well then, let's just take one bit off the id for now and save 1/32nd of the space :)
<spm> jtv: don't muck about eh? drop database.
<jtv> at last we'll have some disk space free
<stub> Also, since the only thing that inserts rows into that table is the branch scanner, we could do magic and have everything live while we do the maintenance and only have the branch scanner disabled.
<jtv> stub: I don't suppose there's a way to make the new index be created concurrently like you can with a regular index?
<stub> The new primary key index? No.
<stub> And the *other* other alternative is to talk to the pg-hackers and update the system catalog to promote an existing unique index to the primary key index.
<jtv> oooh getting dirty now
<StevenK> I keep getting this when I run tests on any branch locally:
<StevenK> Test-modules with import problems:
<StevenK>   lp.services.mailman.tests.test_lpmoderate
<StevenK> (And one other)
<wgrant> It can't find blah.blah.mailman.monkeypatches, or something like that?
<wgrant> That error mysteriously vanished when I reinstalled and did a clean rf-setup.
<StevenK> wgrant: Ah ha
<StevenK> wgrant: Just to be clear, you mailed ohloh and asked them to kick their LP import?
<wgrant> StevenK: I posted in the forum as they suggest.
<wgrant> They seem to kick them pretty quickly.
<wgrant> I wonder if they'll have to do another full re-import (which takes like a month)
<jtv> stub: http://paste.ubuntu.com/512180/ is what I have so farârunning tests now
<wgrant> jtv: That looks rather evil.
<jtv> wgrant: stop, you're making me blush
<wgrant> Less evil, however, than an email I just received from my university.
<jtv> ?
<wgrant> It was apparently generated by a recent Microsoft Office product, and is a fairly short largely textual email. The text/plain version is <1KiB. The text/html version is 14KiB, contains 53 XML namespace declarations, and 6KiB of CSS.
<stub> It is evil, but also something I was considering :) Certainly needs to go past upstream though - everything that needs to be updated may not be obvious.
<jtv> stub: absolutelyâI only found out about the pg_index part because \d didn't pick up the change.
<jtv> wgrant: that's actually pretty good.  Last time I did that sort of analysis, it went something like 10:1 for some very basic HTML cleanups such as not declaring the font for every paragraph, and then it was another 10:1 for the cleaned-up HTML against the text.
<wgrant> jtv: 53 NAMESPACES.
<jtv> That may be a tad on the high side, yes.
<jtv> They probably just couldn't be bothered to see which ones were really needed.
<wgrant> Indeed.
<jtv> After all, who doesn't want flashing Microsoft logos with a half-functional copy of their website embedded in their letters?
<jtv> Or something.
<stub> lifeless: When you say 'the OOPS rate has tripled', is that ongoing or are you referring to the spikes during and just after the upgrades?
<lifeless> stub: its ongoing
<stub> Hmm... wasn't aware it was that much.
<lifeless> daily oops reports - we were at a few hundred, we're at 1.mumble K
<lifeless> its noisy too, not flat
<wgrant> +ppas and the person picker could well make up most of that, though.
<stub> Or maybe we have just tripled our throughput - the DB load is still half what we used to see and I don't know why ;)
<lifeless> stub: we should normalise by requests/day - I have a bug open for that on the oops summaries
<lifeless> ok, tuolumne is doing some -weird- aggregation here - https://lpstats.canonical.com/graphs/OopsEdgeHourly/20100914/20101014/
<stub> lifeless: Oh... and we might be getting a lot of OOPS reports from newly enabled cronscripts, including the doubling up of OOPSes from some scripts. If we just look at timeouts though, the cronscripts won't contribute to that.
<lifeless> stub: the upgrades - https://lpstats.canonical.com/graphs/OopsLpnetHourly/20100914/20101014/
<lifeless> stub: I mispoke, I should have said 'timeout rates have tripled'
<stub> Yer, and those spikes helpfully making the rest of the graph unreadable :-P I agree it looks like hard timeouts have increased significantly, and user generated errors too
<lifeless> stub: the ppa search is a major one
<stub> So this was for pre-release, so we can't blame increased traffic from 10/10
<lifeless> 1000 a day
<stub> I haven't followed the PPA search issues - do you have a bug # handy?
<lifeless> https://bugs.edge.launchpad.net/soyuz/+bug/659129
<_mup_> Bug #659129: Distribution:+ppas timeout in PPA search <dba> <timeout> <Soyuz:Triaged> <https://launchpad.net/bugs/659129>
<lifeless> I tagged it dba :)
<lifeless> (only this morning though - not digging at you)
<lifeless> isn't SourcepackagePublishingHistory a big table ?
<wgrant> Maybe 10-15 million records?
<stub> yup
<lifeless> SELECT DISTINCT archive FROM SourcepackagePublishingHistory WHERE status IN (2, 1)
<wgrant> Is that the package cache updater?
<lifeless> thats the ppa search query
<wgrant> That can't be the whole query.
<lifeless> no, its a in clause
<lifeless> wgrant: see the bug I linked
<wgrant> But still, that's indexed.
<lifeless> Time: 1265.807 ms
<lifeless> 6690 rows
<lifeless> its not an obvious cause for 15 second queries, but its a tad slow.
<lifeless> whats annoying is that the query in the OOPS runs in 1.5s on staging
<lifeless> so I can't reproduce
<lifeless> stub: how long does it take on the prod slaves?
<stub> Just over 2 seconds
<lifeless> ><
<lifeless> on all ?
<stub> Yup. I can run the query and return the 6733 results to Bangkok in 2 seconds.
<lifeless> damn
<stub> 2.7 seconds on a cold slave
<lifeless> actually hitting up https://edge.launchpad.net/ubuntu/+ppas?name_filter=munin times out though
<stub> That would be doing a different query, or is the filtering done client side?
<lifeless> slightly different yes
<lifeless> (Error ID: OOPS-1747ED330)
<lifeless> waiting for that to sync
<mrevell> Hello
<jml> hi
<lifeless> morning jml
<lifeless> grrr oops syncing :<
<jml> lifeless: good morning
<jml> mwhudson: thanks for doing the branch-distro thing
<mwhudson> jml: it's probably still failing intermittently
<jml> mwhudson: I had been meaning to ask, the failures in the bug report, do they require manual intervention?
<mwhudson> jml: no
<mwhudson> actually seems to be going currently
<mwhudson> jml: well, the script needs restarting, that's all
<jml> mwhudson: what's the intermittent failure then?
<jml> mwhudson: ahh... that's manual enough for me :)
<mwhudson> jml: intermittent, as in, until the losas notice
<stub> lifeless, wgrant: Huh. SourcepackagePublishingHistory is only 1.2 million records. I thought it was bigger too.
<stub> Think I must have been confused with BinarypackagePublishingHistory, which is 11 million
<jml> mwhudson: I can't tell you how keen I am to make this much a fire-and-forget operation for next time
<mwhudson> jml: well, you saw my advice on that front i guess
<jml> mwhudson: rather than a multi-person project
<gmb> jtv: Hi. Edwin asked me to check with you about the bug you're still qa-ing. Any news?
<jml> mwhudson: yeah, thanks
<jtv> gmb: yes, the build farm is now finally up and running.  And now something else is broken.
<gmb> Ah. Doubleplusungood.
<jtv> gmb: I'm leaving out some other breakages for brevity.
<lifeless> losa ping - where is OOPS 1747ED330 ?
<mthaddon> lifeless: erm, context?
<gmb> jtv: Anything i can do to help?
<wgrant> stub: Er, yes, I mixed them up.
<wgrant> Oops.
<lifeless> mthaddon: sorry; we're trying to track down the highest timeout since pg8.4
<lifeless> mthaddon: thats an OOPS I triggered 24 minutes ago
<lifeless> but lp-oops isn't showing it
<mthaddon> lifeless: and what do you mean by "where is"? which server is it on, or you can't find it?
<lifeless> mthaddon: I guess I mean 'has it rsynced across, has the injection into lp-oops completed' - I'm very vague about where to look to figure this out myself :(
<mthaddon> oh great, edge4 and edge5 are using the same OOPS prefix
<mthaddon> lifeless: you should familiarise yourself with the OOPS prefix system I think - very useful for tracking this kind of stuff down
<lifeless> mthaddon: I'll file a bug about the fact the overlap wasn't detected
<lifeless> mthaddon: I rewrote part of it recently ;)
<lifeless> mthaddon: but the operational deployment is a bit different
<stub> That 'stable has test failures' in the topic is old now, right?
<lifeless> I don't know :)
* stub changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.10 | PQM is Release-Critical; devel is closed (Release manager: EdwinGrubbs) | firefighting: - | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting
<stub> Its a lie anyway - if there are failures nobody is fighting the fire ;)
<mthaddon> lifeless: I don't see an OOPS with that ID on either edge4 or edge5 :/
<mwhudson> jml: in other news, a longer lead in time on new dev would perhaps allow a more thorough qa, which *might* have caught the other problem
<lifeless> mthaddon: filed https://bugs.edge.launchpad.net/launchpad-foundations/+bug/659752 about the overlap aspect
<_mup_> Bug #659752: duplicate oops prefixes are not detected in production-configs <Launchpad Foundations:New> <https://launchpad.net/bugs/659752>
<jml> mwhudson: I don't quite get it.
<mwhudson> jml: thumper tested his branch on like 1% of package branches
<mwhudson> if he'd tested on 10%, it might have found the bug i'd reported
<mwhudson> (probably not though)
<thumper> it seems there were some maverick branches that hadn't been scanned
<mthaddon> lifeless: I'm not really sure how else to track this OOPS down if it doesn't appear on either of the two server with the "ED" OOPS prefix
<thumper> I poked them to get scanned
<thumper> which seemed to make them continue
<thumper> we are just of 13K through
<thumper> when it fails, it fails after the restacking
<thumper> so the failing ones just need to be scanned
<lifeless> mthaddon: fair enough
<mwhudson> thumper: one of the branches i poked at seemed broken
<thumper> openoffice.org?
<lifeless> mthaddon: I'm assuming that you mean you looked on the appserver itself when you say that ?
<mwhudson> no, the one in the bug report
<lifeless> mthaddon: if so thank you very much for prodding.
<thumper> ok
<mwhudson> i didn't poke very hard
<stub> mthaddon: How about 1746B1391 which also hasn't synced?
 * mwhudson back to chessy drama tv
<mthaddon> lifeless: yeah, looked on both appservers edge4 and edge5
<lifeless> mthaddon: do you need a merge proposal to allocate a new prefix for edge5, or are you doing that?
<mthaddon> lifeless: I'll take care of it
<lifeless> mthaddon: ok, thanks.
<mthaddon> stub: don't see that one on lpnet2 either :(
<lifeless> mthaddon: I have a note here to check that we're still ontarget for the 18th for golive of qastaging
<mthaddon> lifeless: there have been some delays because the DB build for it was causing blocking problems for the staging DB
<mthaddon> lifeless: so I'm not sure if we'll still make the 18th
<stub> lifeless: So the PPA search is still timing out on the COUNT() in the bug report, and that query takes 40+ seconds, and I've added the solution to the bug report. Would be nice to know we are not throwing OOPS reports away though ;)
<lifeless> stub: didn' you just try the count() and have it fast on prod etc?
<lifeless> (it was fast on staging)
<wgrant> I wonder how much of the PPA publisher's time is spent in domination.
<wgrant> That's *really* slow at the moment, since it blows away the cache a couple of times for each (suite, arch).
<lifeless> stub: I'm wondering if we're facing a systematic difference between staging and prod making staging unsuitable for evaluating performance
<stub> lifeless: SELECT DISTINCT archive FROM SourcepackagePublishingHistory WHERE status IN (2, 1), which was the proceeding query in my scrollback when you asked
<lifeless> ah
<lifeless> so on staging
<lifeless> SELECT COUNT(*) FROM Archive, Person, ValidPersonOrTeamCache WHERE Archive.purpose = 2 AND Archive.distribution = 1 AND Person.id = Archive.owner AND Person.id = ValidPersonOrTeamCache.id AND Archive.id IN ( SELECT DISTINCT archive FROM SourcepackagePublishingHistory WHERE status IN (2, 1)) AND Archive.fti @@ ftq('munin') AND Archive.private = FALSE AND Archive.enabled = TRUE AND (1=1)
<lifeless> ;
<lifeless>  count
<lifeless> -------
<lifeless>     11
<lifeless> (1 row)
<lifeless> Time: 1204.301 ms
<lifeless> wgrant: care to whip up a patch for  https://bugs.edge.launchpad.net/soyuz/+bug/659129 with stubs tweaks ?
<_mup_> Bug #659129: Distribution:+ppas timeout in PPA search <dba> <timeout> <Soyuz:Triaged> <https://launchpad.net/bugs/659129>
<wgrant> lifeless: I'd love to, but I have five projects due on Monday, so I probably shouldn't.
<lifeless> stub:  \d validpersonorteamcache
<lifeless> ERROR:  column "reltriggers" does not exist
<lifeless> LINE 1: SELECT relhasindex, relkind, relchecks, reltriggers, relhasr...
<lifeless>                                                 ^
<lifeless> wgrant: ok, no worries.
<stub> lifeless: postgresql client package needs to be upgraded on devpad
<stub> 8.3 client doesn't know about 8.4 system table updates
<lifeless> ah
<bigjools> and it even tells you that in the client at startup :)
<bigjools> lifeless: you've been busy duping bugs, thanks
<lifeless> bigjools: I picked a newer one but it had more detail, hope that is ok
<lifeless> bigjools: and sorry for the confusion about the % bug
<bigjools> lifeless: sure thing
<bigjools> lifeless: no worries.  you did make me double check it.  Twice.  :)
<lifeless> hah :)
<bigjools> I know I'm a little scatterbrained....
<bigjools> lifeless: btw are you fixing that ppa search timeout?
<lifeless> stub: so any idea why the count is fast on staging?
<lifeless> bigjools: certainly not tonight
<bigjools> it would be nice to make the release
<lifeless> bigjools: stub has a proposed fix for the query
<bigjools> I saw, that's great
<lifeless> bigjools: should be near trivial to apply it (ignore my comment about validpersonorteamcache for now)
<bigjools> lifeless: btw your comment on the ML thread about not joining via TeamParticipation confused me - it's not needed I don't think?
<lifeless> bigjools: if you or someone in non-asia timezone can get a fix together it should be possible to make the release.
<lifeless> though thats only 12 hours away now
<lifeless> I know that I can't make the release; to tired to be coding right now, and not enough time to run the test suite after I start work before the release ;)
<lifeless> bigjools: teamparticipation - its needed because 'team X has open subscription' can be achieved two ways:
<lifeless>  - directly and indirectly
<bigjools> eek
<lifeless> for direct, the team flag matters
<bigjools> -> - ops, private matter
<lifeless> for indirect the same flag on *any team that is a member of the team*.
<bigjools> lifeless: do you remember where in the code that slow ppa query is@?
 * bigjools curses cold fingers
<lifeless> bigjools: no, I hadn't looked for it
<lifeless> sorry
<bigjools> np, was just looking for a time-saver :)
<lifeless> yeah, I wish I had one for you
<bigjools> found it
<bigjools> stub: in your fixed query you say joining to Person is not necessary, but I think it is as it's ordering on Person.name
<lifeless> bigjools: its not needed for the count(*); this points at a storm issue
<bigjools> lifeless: interesting - I dunno how it could know that
<lifeless> neither do I :)
<lifeless> but the way we use .count() implies that we need to teach it, or to start using separate query definitions for estimation, sizing and results
<lifeless> we may need to do that anyway.
<lifeless> stubs comment that the distinct is the key thing suggests that ignoring the Person usage is reasonable
<bigjools> lifeless: the batch nav would need fixing to do that
<bigjools> would be a nice fix though
<bigjools> we can supply fake values for huge sets where preciseness is not useful
<lifeless> there is an estimator in the code base
<lifeless> which uses the table stats to make an estimate
<bigjools> I wonder what someone thought that DISTINCT was doing
<lifeless> refactored code perhaps
<bigjools> lifeless: how long are you around for?
 * bigjools grumbles at "make schema" building wadl*3
<lifeless> bigjools: if you need me, I can be around
<lifeless> bigjools: if you don't, given there is a team lead meeting in < 8 hours, I won't be around for long at all
<bigjools> lifeless: ok I'm just running tests on this trivial change, if you can bless the branch that'd be good
 * bigjools will be 5 mins
<lifeless> ok
<bigjools> just doing the MP
<bigjools> lifeless: https://code.edge.launchpad.net/~julian-edwards/launchpad/slow-ppa-search-bug-659129/+merge/38307
<lifeless> rc blessed
<bigjools> ta
<bigjools> lifeless: can you r= it as well :)
<lifeless> no, lp won't let me.
<lifeless> jml: can you?
<bigjools> Oo
<lifeless> bigjools: only one vote type per person
<bigjools> prob cause the diff is not ready
<bigjools> we need a rabbit
<wgrant> You could teach ec2 to interpret 'code release-critical' properly.
<gmb> Bigjools: I'll take a look
<bigjools> ah thanks gmb
<bigjools> still no diff.... is the scanner foobar?
<wgrant> Didn't we just branch Ubuntu?
<bigjools>  /o\
<lifeless> yes
<lifeless> but the branch of ubuntu has staggering code
<bigjools> so, last time the backlog was hojw many days? :)
<wgrant> Bye bye scanner for the next month. Unless that thing got CP'd?
 * bigjools back in 5
<gmb> bigjools: How many lines should there be in the diff?
<gmb> I still see "updating diff" but there's also a diff...
<wgrant> I see no "updating diff" any more.
<gmb> ... and now the message has gone.
<gmb> Right.
<wgrant> Nice.
<gmb> Hurrah for confusing-ui.
<gmb> bigjools: Anyway, r=me.
<gmb> thumper: Edwin-afk asked me to check on the status of https://code.edge.launchpad.net/~thumper/launchpad/better-errors-for-translate-path/+merge/38178 whilst he slept. Is it in EC2 atm?
<bigjools> gmb: ta
<stub> bigjools: Keep the Person join if you want - it doesn't slow things that much. The DISTINCT is the killer.
<bigjools> stub: right.  I can't work out why it was needed for an IN query as well
<bigjools> fix heading to PQM now
<stub> bigjools: It may well have been an optimization. I think PG 8.4 query planner handles IN better now.
<bigjools> good to know, ta
<jml> lifeless: can I what?
<lifeless> jml: do a code review (which gmb has done)
<jml> lifeless: good good :)
<lifeless> halt()
<gmb> jtv: So, talk to me (as an Edwin proxy). What's the situation w.r.t. breakages and how likely are these things to become rollout blockers?
<gmb> (Note that I have *zero* context besides Edwin saying you had bug that was qa-needstesting)
<jtv> gmb: we're still working to get staging fully operational for our purposes, which is kind of a prerequisite for a rollout.
<gmb> Ah, right.
<jtv> One thing we identified is that the librarian gc grace period needs to be long enough to keep essential files present over the lifetime of a staging copy.
<jtv> I don't know if there are any other branches waiting for Q/A that would be affected by this.  Possibly not; most buildfarm Q/A can happen on dogfood.
<wgrant> Can DF not be used?
<jtv> Just one thing missing on dogfood: codehosting.
<wgrant> There's a hack for that.â¢
<wgrant> Oh, but I guess you need the scanner. Sad.
<jtv> Well we need to trigger an ITipChanged event and watch it fire off a buildfarm job.
<jtv> Exactly.
<wgrant> You can't QA the scanner on staging and manually create the records on DF?
<jtv> gmb: it's _probably_ safe to roll back my revision, but again we can't verify that assertion in staging's current state.
<gmb> jtv: Right. Deep joy.
<gmb> jtv: So, once staging's operational for you, your plans are to do QA and / or check that you can roll back safely?
 * gmb stabs wildly in the dark
<jtv> gmb: a brilliant guess
<jtv> I'm still betting on forward rather than back.
<gmb> Cool.
<jml> bigjools: are you going to be working on the buildd-manager branch of death today?
 * jml pokes network driversâ¦ again
<bigjools> jml: otp, but yes
<jml> bigjools: cool. just trying to plan my day.
<bigjools> jml: I'll start on it again in about 30 mins, do you want to join in?
<jml> bigjools: sure
<bigjools> great - just wading through the mountain of email first
<wgrant> bigjools: That branch made me scream, but then I noticed that you killed buildd-slavescanner.txt, so all was forgotten.
<bigjools> :)
<bigjools> it's working on dogfood, did I mention that? :)
<wgrant> You did. That's good news.
 * jml out arranging lunch â it's all about timing the interruptions.
<bigjools> argh, this person picker timout is seriously pissing me off
<bigjools> lifeless: is that on your radar?
<mwhudson_> looks like branch-distro finished?
 * gmb lunches
<jml> mwhudson_: cool! how can you tell?
<wgrant> Finished, or failed again?
<mwhudson_> https://code.edge.launchpad.net/ubuntu/natty/ has a big number on it
<mwhudson_> and it's not changing
<mwhudson_> i guess it might have fallen over again
<thumper> gmb: Revision: 9885 of db-devel, but buildbot seems down
 * thumper -> bed
<wgrant> bigjools: Are we going to need something like CustomUploadPublishingHistory, maybe?
<bigjools> no idea, I've not thought about it
<wgrant> Ah.
<bigjools> possibly, though
<wgrant> I think it would probably make a lot of things suck less. But it needs thought.
<deryck> Morning, all.
<StevenK> gmb: Hi! Can you look at https://code.edge.launchpad.net/~stevenk/launchpad/db-add-derivedistroseries-api/+merge/38189 again? I've made the changes you suggested.
<EdwinGrubbs> thumper, lifeless: do you know if bug 658124 can be marked qa-ok? It's on staging already, but stub is not around.
<_mup_> Bug #658124: Revision karma allocator glacial and needed to be disabled <qa-needstesting> <Launchpad Bazaar Integration:Fix Committed by stub> <https://launchpad.net/bugs/658124>
<EdwinGrubbs> jtv-afk: how goes QA?
<jml> EdwinGrubbs: both are asleep. It's 1am in NZ
<EdwinGrubbs> jml: you wouldn't happen to know about thumper's two branches that are release-critical approved but not landed?
<jml> EdwinGrubbs: not off the top of my head.
<gmb> EdwinGrubbs: I tried to check in with thumper but he'd already left.
<gmb> EdwinGrubbs: jtv-afk's situation is thus:
<gmb> <gmb> jtv: So, talk to me (as an Edwin proxy). What's the situation w.r.t. breakages and how likely are these things to become rollout blockers?
<gmb>  (Note that I have *zero* context besides Edwin saying you had bug that was qa-needstesting)
<gmb> <jtv> gmb: we're still working to get staging fully operational for our purposes, which is kind of a prerequisite for a rollout.
<gmb> <gmb> Ah, right.
<gmb> <jtv> One thing we identified is that the librarian gc grace period needs to be long enough to keep essential files present over the lifetime of a staging copy.
<gmb>  I don't know if there are any other branches waiting for Q/A that would be affected by this.  Possibly not; most buildfarm Q/A can happen on dogfood.
<gmb> <wgrant> Can DF not be used?
<gmb> <jtv> Just one thing missing on dogfood: codehosting.
<gmb> <wgrant> There's a hack for that.â¢
<gmb>  Oh, but I guess you need the scanner. Sad.
<gmb> <jtv> Well we need to trigger an ITipChanged event and watch it fire off a buildfarm job.
<gmb>  Exactly.
<gmb> <wgrant> You can't QA the scanner on staging and manually create the records on DF?
<gmb> <jtv> gmb: it's _probably_ safe to roll back my revision, but again we can't verify that assertion in staging's current state.
<gmb> <gmb> jtv: Right. Deep joy.
<gmb>  jtv: So, once staging's operational for you, your plans are to do QA and / or check that you can roll back safely?
<gmb> * gmb stabs wildly in the dark
<gmb> <jtv> gmb: a brilliant guess
<gmb> <jtv> I'm still betting on forward rather than back.
<gmb> EdwinGrubbs: Not sure if that helps you any.
<EdwinGrubbs> gmb: well, it confirms that it is as bad as I thought.
<wgrant> What's actually broken about staging?
<gmb> No idea.
<wgrant> I see a TTBJ in progress there as we speak.
<wgrant> Ah, it just restarted.
<wgrant> Well.
<wgrant> I think the chroot is missing.
<wgrant> Easy fix.
<wgrant> Yes, the staging DB just needs to have a new chroot thrown at it.
<wgrant> So, unless there's some issue deeper than the obvious fatal one, it should take roughly two commands and ten seconds to fix.
<jml> one of these days I'm going to think seriously about the build farm UI
<wgrant> Oh?
<jml> e.g. that end users care about https://edge.launchpad.net/builders and actually check the page smells wrong to me
<wgrant> I think we should wait and see what happens now that multi-day queues are rare.
<jml> well I'm hardly proposing immediate action
<jml> a page that showed the queue, otoh, I could see being useful to end-users and operators alike
<wgrant> That sounds like my bug #155758
<_mup_> Bug #155758: Global PPA +builds would be useful <ppa> <ui> <Soyuz:Triaged by julian-edwards> <https://launchpad.net/bugs/155758>
<jtv> hi gmb, hi EdwinGrubbs, I'm back from dinner
<jml> wgrant: right
<EdwinGrubbs> jtv: I'm hoping staging works for you now.
<jtv> no, not yet
<jml> wgrant: I guess in general I'm thinking that we should think about operator UI and user UI as being two distinct things that only sometimes overlap
<wgrant> jtv: Is there more to the staging breakage than the obvious chroot LFA expiration?
<jtv> wgrant: I was about to ask how mthaddon had fared
<jtv> mthaddon: staging is backâ¦ have you tried running those commands to upload the new chroot again?
<mthaddon> jtv: I haven't no
<jtv> mthaddon: could you?
<wgrant> Just grabbing the current prod one and manage-chroot.py'ing it in?
<mthaddon> running it now
<mthaddon> jtv: and done
<jtv> mthaddon: yay!  Thanks.
<wgrant> Success.
<jtv> mthaddon: and now it's producing output.  I'll throw in another "thanks" for good measure.
<mthaddon> yer welcome
<jtv> wgrant is obviously watching the same page I am.  :)
<wgrant> Indeed. But I'm a little confused as to how clementine is involved. I thought that was used by the server team for stuff.
<jtv> wgrant: are you saying it's not supposed to be a staging builder!?
<jtv> EdwinGrubbs, gmb: yay!  qa-ok.  Only took a few seconds once everything was set up.  :)
<EdwinGrubbs> jtv: yipeee
<wgrant> I.. don't know.
<jtv> wgrant: I've had clementine for these jobs before.  Can't say if that was IS's intention, but that's how it's been working.
<bigjools> clementine is the staging builder
<jtv> phew
<jtv> and build it did.
<jtv> I got my template.
<jtv> Shouldn't feel like such an achievement for something we've already had in production for a while, should it?  :)
<jtv> So many moving parts.
<bigjools> the build farm is complicated...
<bigjools> ok jml I am about to start hacking on the BFH
<jtv> jam: heh, I just googled for something in libpqxx and found it on arbash-meinel.com :)
<jml> bigjools: \o/
<StevenK> gmb: Did you see my gentle prod?
<StevenK> gmb: You did, never mind. Thanks for the review.
<EdwinGrubbs> wallyworld_, rockstar: ping
<bigjools> wgrant: https://edge.launchpad.net/ubuntu/+source/linux-lts-backport-maverick
<bigjools> spot the problem
<wgrant> bigjools: Already commented.
<bigjools> :)
<bigjools> your diagnosis is the same as mine
<wgrant> bigjools: Right, clementine is clearly a staging builder... but I also saw it being used to publish Maverick's EC2 AMIs. So I'm a little confused.
<wgrant> Maybe there are two clementines.
 * jtv suppresses mumbled remark about her sister
<jtv> âhaving listened to far too much Tom Lehrer for his own good
<EdwinGrubbs> rockstar, abentley: ping
<abentley> EdwinGrubbs: pong
<EdwinGrubbs> abentley: can you QA bug 634149 and bug 639785 that thumper landed?
<_mup_> Bug #634149: Poor error messages from the smart server <codehosting-ssh> <qa-needstesting> <Launchpad Bazaar Integration:Fix Committed by thumper> <https://launchpad.net/bugs/634149>
<_mup_> Bug #639785: InvalidProductName when trying to access some branches in LP <oops> <qa-needstesting> <Launchpad Bazaar Integration:Fix Committed by thumper> <https://launchpad.net/bugs/639785>
<deryck> allenap or gmb, how should I run test_bugtask_status?  I get LayerIsolationError about the librarian being killed or hung.
<deryck> I've tried all manner of ./bin/test with test_bugtask_status
<allenap> deryck: Can you paste the error? I would use bin/test -vvct test_bugtask_status (and I have recently because I've changed it).
<abentley> EdwinGrubbs: I'm not sure.  The merge proposal doesn't describe how to demo the fix.
<gmb> deryck: What allenap said.
<EdwinGrubbs> abentley: well, if we can't QA it, I guess we can't release it.
<deryck> allenap, gmb --  http://pastebin.ubuntu.com/512400/
<deryck> devel should be up to date for me, but confirming that now.
<bac> abentley, adeuring, allenap , bac, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jtv, bigjools, leonard, mars, noodles775: Reviewer Meeting in 3 minutes
<allenap> deryck: Have you tried removing pid files, or even (gasp) rebooting?
<deryck> heh
<deryck> gasp indeed! ;)
<bigjools> deryck: kill all existing librarians then remove the pid file
<gmb> deryck: Again, what the other guy said. I can't reproduce locally...
<gmb> reproduce *the error*
<bigjools> it happens to me occasionally
 * bigjools chuckles at gmb
 * gmb saw that coming
<bigjools> ...
<gmb> *sigh*
<gmb> Oh, hey, grep works better if you spell things right. Who'da thunk?
<deryck> hmmm, no luck.
<deryck> rm'ed /var/tmp/testrunner-librarian.pid, still have the error
<deryck> don't show the librarian running via ps
<deryck> oh, well.  Will dig in more after reviewer meeting
<allenap> deryck: Try lsof +D $tree_dir to see if anything is still running there.
<deryck> nothing running except gvim :-)
<lifeless> deryck: is that plain devel or do you have some changes?
<deryck> a-ha!  rm /var/tmp/fatsam.test/librarian.pid did the trick.
<deryck> lifeless, plain devel.
<deryck> but I've got it now, finally.
<lifeless> thats very odd; you should have been getting a error from setUp
<lifeless> (layers.py line 589)
<bigjools> lifeless!
<lifeless> having trouble sleeping
<lifeless> so hey, is https://devpad.canonical.com/~lpqateam/qa_reports/deployment-db-stable.html down for other people ? I get connection refused
<bigjools> yeah loolks like devpad is misbehaving
<bigjools> jml: ok just looked at your patch *finally* and it appears I hadn't pushed up the latest revision for you to play with :(
<jml> bigjools: I'm not surprised, it looked wrong :)
<jml> bigjools: but I reckon my patch is good enough for illustration
<bigjools> yep
<bigjools> thanks
<EdwinGrubbs> Ursinha, matsubara: do you know of any oopses or or other problems that might be a rollout blocker?
<mars> abentley, are you still having problems with 'make check' failing on your local system?
<Ursinha> EdwinGrubbs, I'm checking right now
<mars> abentley, in reference to bug 629746
<_mup_> Bug #629746: make check fails with "A test appears to be hung. There has been no output for 600 seconds." <build-infrastructure> <Launchpad Foundations:Triaged by mars> <https://launchpad.net/bugs/629746>
<abentley> mars: I dunno-- I stopped using it.  bin/test has always worked fine.
<mars> abentley, ok, I'll flag it as Won't Fix
<abentley> mars: !!!
<abentley> mars: Why would you do something like that?
<abentley> mars: make check uses test_on_merge, which turns out to be completely different code from bin/test.
<mars> abentley, well, 'make check' is a target intended for automated test suite use.  After discussing this with the other build people, we decided that bin/test for local dev was fine, and save 'make check' for the bots
<abentley> mars: The difference in behavour between bin/test and test_on_merge worries me.
<Ursinha> EdwinGrubbs, devpad is down, I can't keep checking right now :/
<Ursinha> it should be back soon, according to losas
<Ursinha> so I'll have an answer soon
<mars> abentley, it only has a call to 'make schema' in between, and it calls xvfb-run
<abentley> mars: last I saw, test_on_merge was its own test runner.
<mars> yes, unfortunately
<bigjools> jml: I reckon _with_timeout could be a nice decorator in lp.services.twisted
<mars> abentley, it checks the child process' exit status
<mars> abentley, and kills hung tests
<jml> bigjools: interesting thought. it assumes that the Deferred has a nice canceller defined, but that might not be a problem.
<bigjools> jml: or perhaps a context manager
<abentley> mars: my mistake.  I guess I saw lots and lots of Python and assumed it was a test runner.
<jml> bigjools: yeah. maybe. I still find it hard to get excited about them.
<abentley> mars: still, I wonder-- are these tests not displaying output for 15 minutes and then succeeding on my box?
<bigjools> jml: I know what you mean, but the code would look much nicer if nothing else :)
<mars> abentley, I would say run the test in isolation with bin/test to see
<jml> no opinion on that yet
<bigjools> jml: oh I was going to ask - does our version of Twisted have that Deferred cancellation in it for the one callRemote returns?
<jml> bigjools: I don't know off the top of my head. the NEWS file will mention it.
<abentley> mars: Do you think testPPAUploadResultingInNoBuilds is the test in question?
<mars> abentley, no, I can't be sure.  The other problem with test_on_merge.py is that output from hung tests, etc. gets buffered
<mars> abentley, usually one needs to run the sub-suite with bin/test
<mars> bin/test does the right thing: hangs, then prints to the console when you hit Ctrl-C
<abentley> mars: Perhaps you should send SIGINT before signal 15, then?
<mars> hmm, I don't know, maybe
<abentley> mars: so by sub-suite, you mean test_ppauploadprocessor?
<mars> yes
<mars> and if that does not reproduce it, step one suite higher in the chain again
<bigjools> jml: yes, it does
<jml> bigjools: cool.
 * bigjools hax0rs
<mars> benji, leonardr, I think I have an idea about cleaning up windmill, if that is indeed the problem
<benji> mars: great
<mars> I'll whip up a patch
<jam> jtv: do you have the link?
<jtv> jam: what, for the libpqxx stuff?  Not anymoreâ¦  I've got a little design problem with notification listeners in libpqxx so I thought I'd look up who uses them and how.
<jtv> gary_poster: thanks for following up on the storm issue
<gary_poster> np jtv
<jam> jtv: hmmm, when I search for it, I get an old .weave file for a project I used to work on. Interesting to have text-readable repository content get indexed
<bigjools> jml: btw did you look into how to pass a connection timeout value to the reactor's connect method?
<jtv> jam: I think there was mention of university stuff.  On an unrelated note, I'm sorry there's so much trouble getting the BranchRevision patch through.
<jml> bigjools: it's still the same as yesterday: patch Twisted or clone & mutate the Proxy class.
<bigjools> jml: yes I realise that :)  Just wondered if you'd done anything.
<jml> bigjools: oh, no.
<bigjools> I think I found a problem with the decorator approach as well - it's kinda hard to pass different reactors for tests :(
<abentley> mars: I can't reproduce the specific delay.  I have noticed the test suite seems to hang sometimes and then gets moving again, but I don't usually run with -vv, so I'm not sure where.
<jml> bigjools: good point
<bigjools> jml: unless we decorate the whole class
<abentley> mars: I worry that it might be because getUniqueInteger now has a random starting point.
<jml> bigjools: that seems like one of solutions in search of a problem
<bigjools> yer
<jml> one of those, I meant to say
<bigjools> I'm just looking for ways to make the code re-usable.
<jam> jtv: well, modifying a 600M row table and having a hard-timeout on how long the upgrade can run is always going to be a bit of a problem :)
<jml> bigjools: well, it can be a function, rather than a method
<jtv> jam: that's the thingâwe're not doing anything that should take noticeable time.
<bigjools> jml: that's the easy approach, yes
<jml> def cancel_on_timeout(timeout, d, reactor=None):
<jtv> jam: dropping a table in postgres is at its core just dropping it from metadata, and leaving the existing rows untouched (until the next vacuum I guessâbut we vacuum anyway)
<jam> jtv: it is changing the primary key, which requires re-indexing
<jtv> jam: that's the stupid thing.  No technical reason for that that we can think of.  It's just that nobody bothered to allow it yet.
<jtv> jam: changing a primary key is a matter of dropping one constraint and adding another, which is really just a not-null plus a unique plus a little marker saying "this is the primary key."
<jtv> jam: a primary key has basically no special meaning, except various scripts and slony like to work with the primary key by default.
<jtv> jam: so stub came up with a good oneâ¦ just ram the change into the system catalog.  Make it say that there's a primary-key constraint and that the existing index was made for it.  But that needs careful deliberation with pg-hackers.
<jam> jtv: true, though I'd rather work with thumper to redesign the whole logic and turn 600M rows into <1M
<jam> :)
<jtv> jam: that's good too  :-)
<jtv> Is that the "compression" scheme you mentioned in Prague?
<jam> it would be interesting to get a dump of that content, and see how small it can be
<jam> yes
<abentley> EdwinGrubbs: qa-ed.
<abentley> jam, speaking of that, can we chat?
<EdwinGrubbs> abentley: thanks
<bigjools> jml: success.  Now to write tests :)
<jml> bigjools: I don't know whether to be happy or sad.
<bigjools> jml: DDT
<bigjools> arf
<EdwinGrubbs> gmb: are we still supposed to write up a rollout report? I don't see one for last cycle. https://wiki.canonical.com/Launchpad/RolloutReports
<gmb> EdwinGrubbs: Yes. https://wiki.canonical.com/Launchpad/RolloutReports/10.09. I just forgot to link to it.
<jcsackett> EdwinGrubbs: ping.
<EdwinGrubbs> jcsackett: hi
<jcsackett> EdwinGrubbs: how do you feel about altering the codehosting_usage property on projects so it's set to LAUNCHPAD if products for the group are?
<jcsackett> rationale is that we have a bug about showing the unknown code hosting message if there are no branches for the projectgroup products, but it seems odd to test branches when we're looking at usage.
<jcsackett> i'm pinging you, EdwinGrubbs, since you most recently refactored that. (really nicely, btw).
<jcsackett> alternatively right now i can just test the output of getBranches on a projectgroup and display the unknown message if it's 0; that just seems odd.
<EdwinGrubbs> jcsackett: hmmm, maybe projectgroups need a special message when there are no branches to say that you can submit code on the following products that have codehosting turned on.
<mars> leonardr, benji-lunch, here is a patch that should if the problem is the windmill suite: http://pastebin.ubuntu.com/512467/
<EdwinGrubbs> jcsackett: I assume that if we change the codehosting_usage to LAUNCHPAD for the projectgroup, it will show a bunch of action links that don't apply.
<jcsackett> EdwinGrubbs: fair point; the overview involvement menu will trigger, which is ridiculous.
 * jcsackett hadn't thought that through.
<mars> leonardr, benji-lunch, create a new branch of your current work, apply this patch, push, and run with "ec2 test -o '-t whatever_the_failing_test'", see if the problem persists.  If it does not, try a full test run.
<leonardr> will do
<jcsackett> EdwinGrubbs: i think a message about no branches and list of links to the products makes sense. just displaying the "we don't know" message seems underwheming to me.
<jcsackett> thanks.
<barry> hi guys, what's the story with python-psycopg2 for lp development on maverick?  launchpad-dependencies won't install because it requires < 2.0.14
<jml> g'night
<jtv> jml: good night
<maxb> barry: manually install the lucid .deb, then install launchpad-dependencies
<barry> maxb: ah.  what are the prospects for updating to the maverick version of the package?
<maxb> I am not the person to ask about that
<barry> maxb: gotcha, thanks.  maybe flacoste, gary_poster or sinzui knows?
<maxb> The underlying question is "How soon can we resolve our/Storm's unicode issues and be able to use PsycoPg 2.2?"
<gary_poster> barry, maxb, you need to revert to the older one.  stub has a task to do the update probably in the next month/cycle
<barry> gary_poster: cool, thanks
<gary_poster> np
<lifeless> bigjools: what was the outcome of testing that query fix ?
<bigjools> lifeless: nothing else happened
<lifeless> barry: https://bugs.edge.launchpad.net/ubuntu/+source/psycopg2/+bug/650777
<bigjools> it doesn't break functionality so there's no point worrying
<_mup_> Bug #650777: operator does not exist: text = bytea <amd64> <apport-bug> <maverick> <psycopg2 (Ubuntu):New> <https://launchpad.net/bugs/650777>
<lifeless> bigjools: ok
<lifeless> bigjools: works for me
<bigjools> lifeless: we can do more investigation on the performance later
<lifeless> ack
<barry> lifeless: thanks.  subscribed
<lifeless> barry: we have lucids version, which works, in the lp PPA
<barry> lifeless: so i just need to uninstall the mav version and it should work?
<lifeless> there is an argument that 'lp is broken and this just shows it'.
<lifeless> barry: downgrade yeah
<barry> +1
<bigjools> lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1747S227
<bigjools> the fixed query is not the one that's timing out
<bigjools> I smell a problem with the ValidPersonOrTeamCache view
<lifeless> oh wow, lp-oops openid dance is speial now
<lifeless> 3 continue buttons
<bigjools> yeah I had to log out/in
<bigjools> I frickin hate openid
<lifeless> yeah, the valid* caches have been the source of lots of timeouts
<lifeless> there's a validity clause for Person
<lifeless> which you can incorporate into a storm query, guess we need the same for team
 * bigjools heads off for dinner
<bigjools> laterz
<lifeless> ciao
<gary_poster> (mars, look over here :-) ) flacoste: do you know if dogfood is on lucid now, or if not, when it will be?
<flacoste> gary_poster: only a losa or bigjools would know
<gary_poster> ok thanks flacoste
<gary_poster> huh, oh look, I haven't been on canonical irc all day :-P
<gary_poster> lifeless: you mentioned to me a while ago that storm trunk had a bug that would bite us.  Do you remember what it was, and do you know if it has been resolved?  If it has been resolved, you can even ignore the first question if you want :-)
<elmo> lifeless/bigjools: try lp-oops now
<lifeless> I don't think it has
<deryck> lifeless, hi.  Are you subscribed to the security mailing list that gets mail for security bugs?
<lifeless> elmo: thanks
<lifeless> deryck: I don't know
<deryck> lifeless, I posed a question for you in bug 638054, and then realized I wasn't sure if you would see it.
<lifeless> deryck: I'm structurally subcribed to 'launchpad-project' ;)
<deryck> lifeless, but that doesn't get you security bugs.  non-obvious as that may be and all. ;)
<lifeless> huh, well I got the bug mail anyhow
<lifeless> and I've replied just now
<gary_poster> lifeless, "I don't think it has" was directed to me, I think; thank you.  Do you know what the issue was?  I'd like to mention it to jamu
<lifeless> something like
<lifeless> there was this cache incoherency
<lifeless> mm
<lifeless> I know, its an XXX
<lifeless> https://bugs.edge.launchpad.net/storm/+bug/619017
<_mup_> Bug #619017: __storm_loaded__ called on empty object <Storm:Fix Committed by therve> <https://launchpad.net/bugs/619017>
<lifeless> thats the bug I mentioned, i think
<lifeless> now to find the fallout
<lifeless> https://bugs.edge.launchpad.net/storm/+bug/620615
<_mup_> Bug #620615: please contact the developers <Storm:In Progress by niemeyer> <https://launchpad.net/bugs/620615>
<lifeless> we hit that one when we use storm with the earlier one fixed.
<lifeless> IIRC
<gary_poster> lifeless: thank you.  the title of the bug made me laugh.  OK, so to your knowledge, when that bug is fixed, we can switch to Storm trunk (via an official 0.18 or unofficial release)?
<lifeless> deryck: my reply is  alittle brief - but all the context is in the rt
<lifeless> gary_poster: I'm not aware of any other blockers
<gary_poster> great thanks again
<deryck> lifeless, ok, thanks for responding.  Brief is fine.  :-)  I'll look at the RT.
<jcsackett> abentley: ping
<abentley> jcsackett: OTP
<jcsackett> never mind then; rockstar, you available for a quick question?
<rockstar> jcsackett, on the phone.
<rockstar> jcsackett, abentley and I are on the phone together.  :)
<jcsackett> rockstar: that's sort of what i guessed from the paired responses. :-)
<EdwinGrubbs> jcsackett: ok, I think I can answer your question now.
<jcsackett> EdwinGrubbs: i'm all ears.
<EdwinGrubbs> jcsackett: if you go to https://launchpad.dev/$project/+branchvisibility, you can specify the visibility policy for multiple teams separately. You can also specify the default visibility for people not in one of those teams.
<abentley> jcsackett: back
<jcsackett> EdwinGrubbs: can anyone with Edit permission for the product use that page?
<jcsackett> abentley: i'm trying to answer a question that EdwinGrubbs has helped me out with a bit. namely, if a product has branches set as private to one team, can you make branches on the product for another team?
<abentley> jcsackett: I don't know a lot about branch privacy.
<jcsackett> ah. Edwin thought you might.
<abentley> jcsackett: I don't think that "private to one team" is a thing.
<lifeless> different teams can have private branches on the same product
<abentley> jcsackett: I'm pretty sure the enum is "private", "private by default" or "public".
<abentley> jcsackett: I don't think there's a team relationship.
<lifeless> the ability to make private branches is a commercial feature
<lifeless> abentley: the policy is team based
<jcsackett> lifeless: i know, i'm trying to answer a question for a commercial team.https://answers.edge.launchpad.net/launchpad-registry/+question/129258
<jcsackett> he marked it as solved, but has a new question in the comment he closed it with.
<jcsackett> nonmunged link https://answers.edge.launchpad.net/launchpad-registry/+question/129258
<jcsackett> EdwinGrubbs pointed out he might be able to set it up with the +branchvisibility link; i'm just figuring out all the bits before i answer him.
<sinzui> jcsackett, you make need to to retarget the question to launchpad-code or at least get thumper or abentley to explain that branch visibly does not work the way they think.
<jcsackett> sinzui: dig. i'll retarget.
<lifeless> sinzui: jcsackett: I don't think it needs retargeting. Have you looked at their oops?
<jcsackett> lifeless: yes, that's why i was asking my initial question.
<lifeless> the fact they are encountering an oops suggests they have found a bug, to me.
<lifeless> they do need to have each *team* that is pushing branches setup with a branch policy (or have a meta-team containing all their teams, and give it the policy)
<lifeless> if the project is proprietary they should have the no-defined-policy behavior be to prevent pushing.
<sinzui> lifeless, they cannot define branch visibility. We suck
<lifeless> sinzui: they can have us do it though, no?
<sinzui> how do they know that?
<sinzui> Who walked them through how privacy works?
<sinzui> Where are the documents that they can read?
<sinzui> lifeless, this is an unusable feature. Lp engineers read the code to find out how it works
<jcsackett> sinzui: i think this *is* us walking them through privacy. :-/
<sinzui> jcsackett, I think we should have done that 6 hours ago. This is the third problem
<lifeless> sinzui: https://help.launchpad.net/Code/SubscribingToPrivateBranches <- does this help?
<lifeless> it seems lightweight to me
<sinzui> jcsackett, I do not service commercial requests anymore because my experience as a subscriber to lp bugs, questions, feedback@ and commercial@ are preventing other engineers from discovering they need to do better
<jcsackett> sinzui: that's reasonable. thus i am now the one learning we need to do better. :-P
<jcsackett> however, i do not seem to have bac's powers to deal with their issue (insofar as setting visibility).
<sinzui> lifeless, no, they want to define visibility for another team, I think 10 people can do that
<lifeless> sinzui: do you file bugs about the things that are faulty/missing?
<sinzui> jcsackett, bac did no put you in the commercial admin team
<sinzui> lifeless, I have done more than that, I have had meetings to explain that is is wrong.
<lifeless> sinzui: could you bind 'what' to a value, for clarity
<sinzui> I also have nasty recipes in FAQs how to setup a commercial project that works somewhat like someone expect
<lifeless> I have an lp create-project tool in lptools
<lifeless> would it be reasonable to extend that for commercial projects (so that jc, bac etc - those with lp perms to do it, can do it easily)
<sinzui> lifeless, I an at 99% frustration and I am on my vacation. Lp engineers do not believe they made an bad service that is an embarrassment to charge money for.
<lifeless> sinzui: I didn't realise you were on leave. Shoo! go relax.
<jcsackett> lifeless: so, acknowledging that this sucks (and that the OOPs in question should probably be a bug, since a useful warning would be better), you good with it being retargeted per our vacationing friend's suggestion?
<lifeless> jcsackett: I don't see that a handoff will help the user.
<lifeless> jcsackett: if you think its the best thing for them to hand it off, sure, by all means do so.
<lifeless> jcsackett: if I was handling the question, I would:
<lifeless>  - file a bug for the user for the OOPS
 * jcsackett nods.
<lifeless>  - write up a help page now with what we know about branch privacy
<lifeless>  - point them at it
<jcsackett> not entirely sure we *know* about it; but i can seed a page with what i've learned.
<jcsackett> s/i've/we've
<lifeless>  - read the wiki page curtis mentioned that is in the internal wiki
<lifeless>   (and use that pages notes as part of the seed for the help.lp.net page)
<jcsackett> dig.
 * jcsackett did not expect to open this can of worms.
<lifeless> if we write it up well, it will stay more closed in future
<rockstar> leonardr, ping
<leonardr> rockstar, hi
<rockstar> leonardr, did you write the lp.client javascript?
<leonardr> rockstar: i don't rember. i probably wrote some of it
<leonardr> can we talk about dominion instead?
<rockstar> leonardr, :)
<rockstar> leonardr, I only see a definition of the lp.client.plugins module, never a mention of just the lp.client module.
<leonardr> rockstar: look in l/c/l/javascript/client/client.js?
<rockstar> leonardr, yeah, no definition in there of lp.client
<leonardr> line 4 seems to have one?
<leonardr> no, it's tautological
<leonardr> well, no, it's not tautological
<leonardr> LP.client starts out an empty dictionary
<rockstar> leonardr, yeah, I can't seem to be able to do YUI().use("lp.client");
<rockstar> leonardr, that's what I mean.
<leonardr> and then over the course of that file, stuff is added to the dictionary
<leonardr> rockstar: at that point you've lost me. it's possible there's some module management thing that this file isn't doing, but you should talk to maybe mars
<mars> rockstar, did you check the base template for it?
<mars> base-template-macros.pt
<rockstar> mars, yes.
<rockstar> mars, it's included there.
<mars> rockstar, what is the problem?
<rockstar> mars, on upgrading to YUI 3.2, I get a "requirement NOT loaded: lp.client"
<rockstar> mars, that's all I know.
<rockstar> I suspect it's related to a dependent module not being available, but I have no idea how to prove that.
<mars> rockstar, have you grepp'd the source tree for the lp.client symbol?
<rockstar> I don't know where the Y.add('lp.client') is.
<rockstar> In fact, I'm almost positive now that there isn't one.
<mars> rockstar, that is odd
<rockstar> mars, I think it's a boo boo that thumper made that might have caused everything to break in yui 3.2.
<rockstar> mars, I think it's gotten stricter.
<rockstar> There is no lp.client.
<mars> that would be nice
<mars> the loose dependency loading in earlier versions caused problems for developers
<rockstar> mars, yeah, I'm doing a clean and a build real quick. I think this might fix it.
<mars> rockstar, well, if there is no .add() for it, but there is a 'requires:' stanza, then I would say it is an error in the requirements
<rockstar> mars, yeah, I think that's what's broken.
<mars> leonardr, benji, any luck with the windmill fix I proposed earlier?
<leonardr> mars: i had promising results, but i'm not giving them a lot of credence since the problem seems to skip from test to test. am doing a full run now
<benji> mars: I haven't gotten my test results back yet (I did a full run because I don't get the same errors twice)
<mars> ok, let me know how it turns out
<rockstar> mars, we upgraded windmill, right?
<mars> rockstar, we did, to tip.
<rockstar> mars, er, we've upgraded windmill since we discovered the 512K bug, right?
<mars> yes
<mars> we upgraded last week
<rockstar> mars, great.  I'm hoping the 512K bug is fixed.  Otherwise, I've hit yet another blocker in my quest to get a new YUI in...
<mars> rockstar, you could ask on #windmill.  It is early PDT
<mars> that reminds me
<rockstar> mars, I didn't think it was a windmill bug, but in the way we used windmill.
<mars> I have a patch I would like to get into windmill trunk
<thumper> rockstar: what boo boo?
<rockstar> thumper, your popup diff claims to require lp.client, but there is no lp.client module.
<thumper> rockstar: so fix it :)
<rockstar> thumper, not a big problem, except that I believed there really was, so I approached the problem thinking something I changed broke it.
<rockstar> Truthfully, something I changed just made the breakage more apparent (and break ALL OTHER JAVASCRIPT in the process...)
<deryck> I'm out.  Later on, all.
<Ursinha> EdwinGrubbs, qa-tagger is back, it tagged a bug as needstesting, should I keep that as qa-bad as it was? it's bug 659129
<_mup_> Bug #659129: Distribution:+ppas timeout in PPA search <qa-needstesting> <timeout> <Soyuz:Fix Committed by julian-edwards> <https://launchpad.net/bugs/659129>
<lifeless> Ursinha: qa-ok for that bug, if you're touching it
<Ursinha> lifeless, cool, in a second
<lifeless> Ursinha: the fix wasn't /wrong/ it just wasn't deep enough (a later query times out instead)
<Ursinha> I see
<lifeless> abentley: thanks for adding to the arch guide
<lifeless> jcsackett: yes, thats the page - see the bottom where it talks about branch privact setup
<jcsackett> lifeless: ok, thanks.
<Ursinha> lifeless, hi
<Ursinha> re. bug 659618
<_mup_> Bug #659618: crash when assignee is None <qa-tagger:Fix Released by ursinha> <https://launchpad.net/bugs/659618>
<lifeless> jcsackett: and unless we're talking confidential stuff, the default place to talk is here :)
<Ursinha> I'm getting the committer from the info of the merged branch
<jcsackett> lifeless: right; i went there b/c i was unsure of the status of that page: re confidentiality.
<lifeless> Ursinha: I'd like some more detail than that, if you can humour me.
<Ursinha> lifeless, sure, a minute
<lifeless> jcsackett: fair enough; uhm, its not about any specific customer or a security vulnerability or embargoed surprise feature etc.
<lifeless> jcsackett: nor is it operational details we'd hold sacred
 * jcsackett nods.
<jcsackett> fair enough.
<Ursinha> lifeless, the committer there: http://paste.ubuntu.com/512644/
<lifeless> jcsackett: nor is it of a personal nature for one of us ;)
<jcsackett> i would hope that case doesn't come up too often on IRC. :-P
<Ursinha> lifeless, get_apparent_authors
<lifeless> Ursinha: so using that for assignee has a few problems.
<lifeless> jcsackett: people taking leave is personal, shouldn't be discussed in public (unless the person in question does)
<lifeless> jcsackett: (because if the house is vacant...)
<Ursinha> lifeless, go ahead
<lifeless> firstly, there may be no merged commits.
<Ursinha> lifeless, in devel/stable?
<lifeless> this happens when someone does a fix directly on trunk on pqm
<lifeless> which is needed (rarely) when things go completely cactus
<Ursinha> I've never saw that happen. As in all commits go to trunk through pqm
<lifeless> Ursinha: there was one about 7 weeks ago in fact :)
<Ursinha> so pqm will always be the first committer, and we'll have the apparent authors
<lifeless> Ursinha: no, that doesn't make sense
<lifeless> in your pastebin
<lifeless> rev 11682
<lifeless> will have apparent authors of pqm
<lifeless> and rev 11643.2.7
<lifeless> will have apparent authors of stevenk
<lifeless> get_apparent_authors applies only to a single rev.
<Ursinha> right..
<lifeless> anyhow, you need to handle the case of there being no merged revisions
<Ursinha> lifeless, it goes one level deeper to get the apparent authors
<lifeless> secondly, if fred does a lot of work but goes on leave, barney may merge devel to fix conflicts and then land it; barney isn't the assignee
<lifeless> or if fred and barney are collaborating, the revision graph would look similar.
<lifeless> what would we want in the web report in those cases?
<Ursinha> lifeless, how do you suggest fixing that?
<lifeless> Ursinha: well, I don't know what 'assignee' in the report is for actually.
<lifeless> Ursinha: so I'd like to understand the use case and our goals before offering solutions
<Ursinha> lifeless, the assignee, in my understanding, should be the person responsible for that fix, as the one that should QA that and fix if anything goes wrong
<Ursinha> lifeless, the person we should poke about that item
<lifeless> ok
<lifeless> if we rename it 'authors'
<lifeless> and include *all* the authors found by looking at the trunk revision and all the merge revisions, transitively
<lifeless> then it would do that comprehensively
<rockstar> thumper, I wonder if you and I could have a phone call/review on my lazr-js branch.
<lifeless> the common case will be one person
<lifeless> but in the uncommon case we'll have accurate information
<Ursinha> lifeless, right.
<Ursinha> lifeless, mind writing this on the bug report?
<Ursinha> I have to leave now and should return in ~1h30
<Ursinha> you'll be here anyway :)
<lifeless> sure
<Ursinha> thanks lifeless
<thumper> rockstar: ok, OTP right now
<rockstar> thumper, ack.  We can do it much later in the day.
<abentley> thumper: https://dev.launchpad.net/ArchitectureGuide
<wallyworld_> morning
<jcsackett> lifeless: got a second to be a second set of eyes on the help.lp.net page?
* Chex changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.10 | PQM is Release-Critical; devel is closed (Release manager: EdwinGrubbs) | firefighting: - | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting | Launchpad down/read-only from 22:00 - 00:00 UTC for a code update
<benji> mars: no dice on the tests: https://pastebin.canonical.com/38615/
<LPCIBot> Project db-devel build (65): STILL FAILING in 3 hr 44 min: https://hudson.wedontsleep.org/job/db-devel/65/
<mars> benji, darnit
<LPCIBot> * Launchpad Patch Queue Manager: [release-critical=lifeless][r=gmb][ui=none][bug=659129] Speed up the
<LPCIBot> query used to search for PPAs.
<LPCIBot> * Launchpad Patch Queue Manager: [release-critical=lifeless][r=jtv][ui=none][bug=634149,
<LPCIBot> 639785] Catch the CannotHaveLinkedBranch exception in translatePath.
<mars> ok
<mars> hmm
<mars> so testtools has this nifty addDetail feature
<mars> perhaps that could be used to create a graceful way to do printf debugging on these errors
<mars> /if/ I can get useful identifying information about the active thread
<mars> monkey-patch threading.Thread.start()?  :(
<mars> yuck
<mars> benji, I'll think about it.  leonardr, looks like the errors persisted for benji.
<lifeless> jcsackett: sure
<jcsackett> lifeless: https://help.launchpad.net/Code/PrivateBranches
<benji> mars: do you know what the errors even mean?  If so, can you explain it to me?
<lifeless> restricted -or- moderated?
<mars> benji, it means that threading.enumerate() says there are still live unjoined threads after the test is finished
<mars> benji, and the thread is still alive
<mars> benji, threading has a settrace() method that may provide some insight
<benji> mars: and that's something that RemotedTestCase tests for and generates errors if it is the case?
<lifeless> jcsackett: other than that, great
<lifeless> benji: RemotedTestCase is just the local proxy for a test that ran in another processs
<lifeless> benji: BaseLayer checks for the threads.
<jcsackett> lifeless: good catch. the internal stuff said restricted, but they're referring to a special case of all of this.
<jcsackett> thanks!
<mars> benji, it is added by zope.testing.testrunner.runner.TestResult, printed as a subunit stream by zope.testing.testrunner.formatter, then the stream is interpreted by RemotedTestCase
<mars> and raises the test error
<rockstar> thumper, https://code.edge.launchpad.net/~rockstar/launchpad/javascript-refresh/+merge/38373
<lifeless> flacoste: have you looked at the google doc I made? Any thoughts?
<flacoste> lifeless: i found it interesting, and a good direction, but didn't have any specific thoughts when i read it,
<lifeless> flacoste: ok; I'm going to code today.
<leonardr> mars: my full test run also failed with three random failures
<lifeless> flacoste: I'll get back to it tomorrow/monday
<wgrant> jtv: The chroot_url URL seems to work fine for me...
<jtv> wgrant: yeah, _now_ it does
<wgrant> jtv: Maybe you caught it in a moment when the chroots were being replaced?
<wgrant> I can't see why they'd be blank.
<jtv> wgrant: so I get you straight: you're saying the production maverick chroot librarian URL works if you edit it to use the staging librarian?
<wgrant> jtv: No, no, I refer to your wiki edit.
<wgrant> Sorry.
<jtv> ah
<jtv> wgrant: no idea what caused it, but glad to hear it.
<wgrant> Ah, now this is one of those "we have no idea how long it's going to take, because staging sucks" upgrades, isn't it?
<jtv> wgrant: We do have some idea; stub did a manual db upgrade that doesn't show up in successful-updates.txt
<wgrant> Ah.
<poolie> thumper: did you see https://lp-oops.canonical.com/oops.py/?oopsid=1747ED661 and https://answers.edge.launchpad.net/launchpad-registry/+question/129258 ?
<poolie> i'm glad someone tweeted at the relevant time
<thumper> poolie: yes I saw it
#launchpad-dev 2010-10-14
 * poolie might try to finish my dkim branch
<poolie> oh, poo, codehosting i guess is entirely off line
<mtaylor> yup
 * mtaylor once again annoyingly renews his objection to making launchpad completely unusable for 2 hours in the middle of the afternoon for the US west coast in the middle of the week
<poolie> i know, it's crazy
<poolie> also, i don't see any good reason why you shouldn't be able to at least read branches
<poolie> and indeed why not write to them, because they're not stored in the db
<poolie> but, it's getting better
<poolie> i have trust in lifeless and co
<lifeless> so today we had a db config issue on the readonly slave; another case where schema problems have bitten us.
<lifeless> (the way we do schema changes, I mean)
<mars> lifeless, what server does PQM run on?
<lifeless> prae
<lifeless> pqm runs outside a chroot, but code from our branches runs inside the chroot
<mars> ah, darnit
<lifeless> ?
<mars> darnit that we are not there yet.
<mars> with Python 2.6
<lifeless> right
<lifeless> there may be other gotchas
<mars> on prae? yes, maybe
<lifeless> the simplest thing IME is to stay compatible until we have *every possible case* covered.
<lifeless> no shortcuts
<mars> well, that is going to be what happens now :)
<bac> thumper, rockstar, stub, mwhudson, stevek, lifeless, wgrant -- Review Meeting starting soon
<wallyworld__> bac: thumper sends his apologies, but i'll lurk if that's ok
<bac> wallyworld__: that's great.
<bac> lifeless: ping
* Chex changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.10 | PQM is Release-Critical; devel is closed (Release manager: EdwinGrubbs) | firefighting: - | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting
<mwhudson> Edwin-afk: so when does devel open again? :-)
<lifeless> bac: hi
<bac> lifeless: join us in #launchpad-meeting?
<wgrant> StevenK: An Ohloh reimport is in process, BTW.
<wgrant> https://www.ohloh.net/p/launchpad/enlistments
<StevenK> Huzzah
<StevenK> mars: Do you have a few seconds for me to bend your ear?
<mars> StevenK, sure
<StevenK> mars: I keep seeing failures such as https://hudson.wedontsleep.org/job/db-devel/lastFailedBuild/testReport/junit/lp.codehosting.puller.tests.test_worker/TestWorkerProgressReporting/test_network/ keep appearing in hudson, do you have any clues?
<StevenK> I think the same failures happen on ec2 too
<mars> looking
<mars> wgrant, this project does amazing things for one's Ohloh Kudos rank :)
<StevenK> mars: If that small snippet isn't helpful, there's a full console output link on the left
<mars> StevenK, unfortunately that tells me enough.  This is Benji's error from ec2 earlier today: https://pastebin.canonical.com/38615/
<mars> /with/ a patch I had to try and fix it
<mars> what's funny is the thread ID is the same
<mars> Always the 18th thread started
<wgrant> mars: It does!
<wgrant> It looks like this import might only take a few days.
<mars> StevenK, I am almost to the point of desperate measures to solve this.  Two thoughts: in the tearDown, enumerate all running threads, .join(3.0) on them.  Give them time to halt.
<StevenK> mars: There are two others linked from https://hudson.wedontsleep.org/job/db-devel/lastFailedBuild/testReport/junit/ as well
<mars> StevenK, or run something yucky like a custom tracer via threading.settrace(), then pick out whatever the heck it is that is hanging around
<mars> StevenK, I think it might be an intermittent race condition between the zope testrunner and our test infrastructure.  I solved this once before (and forget how once again)
<mars> StevenK, this work will probably become a priority.  When it does, you will have a fix for it.
<StevenK> mars: Excellent. My only other concern is why does it impact hudson and ec2, but not buildbot?
<mars> StevenK, my theory: BB servers are faster, affecting the race
<StevenK> That could be why many of us can't reproduce it locally
<mars> yes
<StevenK> mars: So it may even end up being a race in zope's testrunner, and we just happen to tickle it?
<mars> maybe.  The testrunner does no thread cleanup
<StevenK> mars: That sounds like a zope fail to me
<wgrant> When's devel likely to reopen?
<StevenK> wgrant: It was going to be in an hour, but now it's 3.
<StevenK> More seriously, RSN
<mars> StevenK, got to run - fwiw, the testrunner could die horribly when doing a thread.join() - unjoined threads are test garbage and break isolation
<mars> best leave their cleanup to the test itself
<mars> same as leaking memory garbage
<mars> later
* thumper changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.10 | PQM is open | firefighting: - | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting
<lifeless> mars: StevenK: do we know what threads they are?
<wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/bug-655648-a-f-maverick/+merge/37820, https://code.edge.launchpad.net/~wgrant/launchpad/bug-629921-packages-empty-filter <-- can someone please land those?
<StevenK> lifeless: Personally, I have no idea
<lifeless> energy invested in making that automatically determined would be of great evalue
<lifeless> or we could just disable the check, though I know thats not terribly popular an idea.
<StevenK> lifeless: Hudson is showing, time and again, that there is a number of them that fail the same way
<lifeless> Ursinha: I may be confused
<lifeless> Ursinha: but I thought there was a report of oopses-received-today
<Ursinha> lifeless, it's the lpnet-oops.html
<Ursinha> same for edge and staging
<lifeless> Ursinha: how often does it update?
<Ursinha> lifeless, hourly, I guess
<Ursinha> let me check
<lifeless> last updated at 11pm utc, not updated since.
<StevenK> lifeless: Hints on where to look would be awesome
<lifeless> StevenK: have the teardown that bitches introspect the thread objects
<lifeless> theres a few attributes that may be useful like name
<lifeless> but also whether its dameonised and if accessible the start function would be good. oh and the class, though I think we're seeing that already.
<mwhudson> does anyone know if there's a bug report i can associate https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/37531 with?
<lifeless> mwhudson: yes
<lifeless> hmm, there was.
<lifeless> but hell, file a new one.
<mwhudson> lifeless: ok, let me know the number when you have it?
<mwhudson> or link it, either works
<StevenK> lifeless: Using threading.enumerate(): http://paste.ubuntu.com/512834/
<mars> lifeless, we don't know what threads they are.  That is why I am thinking of using the threading.settrace() method to find out.  My research says threads are a black box otherwise
<mars> unless you use the thread name well
<StevenK> mars: ^
<mars> yes, not the most helpful thread names :)
<mars> StevenK, didnt' think of using the imp module - would that work?
<mars> err, inspect, not imp
<mars> StevenK, for each thread, can you see the .__class__ method?
<mars> attribute
<mars> bad typing tonight
<lifeless> mwhudson: I oculdn't find it; want to file one ?
<mwhudson> lifeless: ok
<lifeless> mars: not a black box
<lifeless> >>> t = threading.Thread(target=lambda:None)
<lifeless> >>> t._Thread__target
<lifeless> <function <lambda> at 0x7f75dfdd92a8>
<lifeless> t.daemon
<lifeless> StevenK: print those two things as well please
<lifeless> (t.name, t.daemon, t._Thread__target)
<mars> lifeless, ah, you are accessing a private object member - clever
<lifeless> >>> t = threading.Thread(target=lambda:None)
<lifeless> >>> dir(t)
<lifeless> and look
<lifeless> we may also want _Thread__args
<lifeless> but thats more likely to throw up in our face, I think.
<mwhudson> um
<mwhudson> is person search on launchpad completely horked right now?
<lifeless> yes
<lifeless> the huge vocab bug
<lifeless> 8.4 regression
<mwhudson> ah ok
<lifeless> once Ursinha gets back to me about lpnet-oops being stale I will raise the timeout for it via flags.
<lifeless> its probably validpersoncache
<lifeless> but also we've got this bizarre thing where staging is fine and prod sucks
<lifeless> which reminds me, its bug fiuling time on that
<Ursinha> lifeless, so.. it seems oops-tools can't find any oopses
<lifeless> aarrrgghh
<Ursinha> I'm checking devapd
<lifeless> Ursinha: are there any on disk on sodium?
<Ursinha> devpad
<Ursinha> that's what I'm checking
<lifeless> kk, great minds :)
<StevenK> lifeless, mars: Sorry, was afk: http://paste.ubuntu.com/512844/
<Ursinha> lifeless, hm, I see oopses there
<Ursinha> lifeless, /srv/launchpad.net-logs/lpnet/gandwana/2010-10-14
<Ursinha> I see a bunch
<Ursinha> for instance
<Ursinha> 340
<lifeless> Ursinha: ok, so oopstools is broken ?
<lifeless> StevenK: so, that tells use that that one has a bzr server
<Ursinha> lifeless, investigating what's happening..
<lifeless> StevenK: two threads; making the error print this extra info would be useful :)
<StevenK> lifeless: Which I'm guessing it started and didn't tear down?
<lifeless> StevenK: theres a few possibilities
<mwhudson> oh god
<lifeless> StevenK: process_request_thread may mean that there is a half closed socket, for instance.
<lifeless> mwhudson: been drinking ? :)
<mwhudson> i think this is because bzrlib's test http server implementation doesn't join() its thread
<mwhudson> lifeless: i wish
<Ursinha> lifeless, are you the one that's viewing src/oopstools/oops/dboopsloader.py?
<lifeless> mwhudson: invoking the 'oh god' :)
<lifeless> Ursinha: no
<Ursinha> hm
<StevenK> mwhudson: Does that make it a bzrlib bug, then?
<mwhudson> eggs/bzr-2.2.0-py2.6-linux-x86_64.egg/bzrlib/tests/http_server.py:597 and thereabouts
<mwhudson> StevenK: 'difference of opinion' vs bug
<mwhudson> that said, i thought we joined that thread in launchpad, so maybe it's something else
<StevenK> Heh, I see that, reading the comment.
<mwhudson> that's not entirely unrelated
<Ursinha> lifeless, I see a problem here in the oops loader, have to find out how to break the lock file
<lifeless> Ursinha: ok
<lifeless> Ursinha: I wait with bated breath
<mwhudson> StevenK: you could try putting a join() in there and seeing what happens
<mars> mwhudson, this argues for a test teardown .join() call then
<wgrant>  /win 2
<lifeless> mars: not really
<mars> lifeless, why not?
<lifeless> mars: it argues that our test code looking for thread leaks is wrong
<lifeless> mars: / unnecessarily strict
<lifeless> mars: looking over the life of the whole test run should be sufficient, for instance (which is what bzrlib does, more or less)
<lifeless> that said, there's no reason not to join there, that comment is *almost certainly* premature optimisation.
<mars> lifeless, sorry, you lost me - no reason not to join where?
<lifeless> Can I encourage 'you' to put a patch forward to bzr to fix this.
<lifeless> mars: stop_server(self)
<StevenK> Adding self._http_thread.join() to bzrlib has no effect on the output
<Ursinha> lifeless, oops-tools are mostly matsubara-afk 's domain, I'm not sure what to do there without possibly breaking something
<StevenK> lifeless: ^
<Ursinha> hmm
<Ursinha> I guess I solved :)
<Ursinha> update_infestation is running, let's see if oops-tools loads all oopses now
<lifeless> StevenK: we're not sure that function is being called, are we?
<lifeless> hmm, stop_server is being called
<lifeless> and a gc.collect() is being called
<lifeless> at least, according to the test
<StevenK> Indeed
<lifeless> Ursinha: awesome, how long should I wait before trying
<Ursinha> lifeless, no idea, I'll let you know as soon as it finishes, but shouldn't take long
<Ursinha> lifeless, hm, something is really wrong, script output was "no infestation updated"
<Ursinha> it's not recognizing the oopses
<Ursinha> hmm
<Ursinha> lifeless, the line was commented out the crontab...
<Ursinha> I ran that manually and it's loading the oopses
<Ursinha> but not sure why that was commented
<Ursinha> hopefully it won't cause any trouble
<Ursinha> lifeless, I ran out of ideas. It loaded 7k oopses to the database but it just cannot find it for lpnet, only edge
<Ursinha> edge has a partial report now, but lpnet doesn't
<Ursinha> report generator claims there are no oopses for lpnet
<Ursinha> we'll have to wait for diogo
<lifeless> Ursinha: thanks for trying
<lifeless> stub: hey, can we have a brief skype call?
<Ursinha> no problem lifeless, sorry not being more helpful
<Ursinha> going to eat something and sleep
<lifeless> Ursinha: ciao
<stub> lifeless: sure
<stub> lifeless: stuartbishop
<lifeless>  https://bugs.edge.launchpad.net/soyuz/+bug/659129
<_mup_> Bug #659129: Distribution:+ppas timeout in PPA search <timeout> <Soyuz:Triaged by julian-edwards> <https://launchpad.net/bugs/659129>
<mars> lifeless, StevenK, I tried the .enumerate() patch, but the results are nonsense.  Here is the patch, in case you see anything obviously wrong with it: http://pastebin.ubuntu.com/512867/
<mars> lifeless, StevenK, the threads are still alive at the end of the test run, after TestCaseWithTransport.tearDown(self), but the zope testrunner doesn't complain
<StevenK> mars: Throw that at ec2 and see what happens after runs the test suite?
<mars> StevenK, it fails locally.  It is bunk :(
<mars> no point in running it through ec2
<lifeless> StevenK: http://wiki.postgresql.org/wiki/Postgres-XC
<lifeless> bah
<lifeless> stub: http://wiki.postgresql.org/wiki/Postgres-XC
<lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1747S227
<lifeless> ^
<lifeless> 06:27 < bigjools> lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1747S227
<lifeless> 06:27 < bigjools> the fixed query is not the one that's timing out
<lifeless> 06:28 < bigjools> I smell a problem with the ValidPersonOrTeamCache view
<lifeless> https://bugs.edge.launchpad.net/launchpad-registry/+bug/655802
<_mup_> Bug #655802: Branch:+huge-vocabulary timeout (Person and team AJAX picker fails) <timeout> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/655802>
<lifeless> stub: https://lp-oops.canonical.com/oops.py/?oopsid=1740EC788
<StevenK> "The PostgreSQL Project finally switched from CVS to Git in September 2010"
<StevenK> O.o
<lifeless> stub: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/660291
<_mup_> Bug #660291: inconsistent performance between staging and prod <Launchpad Foundations:New> <https://launchpad.net/bugs/660291>
<lifeless> stub: I've tagged all the bugs pg83; probably a little zealous, but better safe than sorry ;)
<stub> ALL the bugs??
<StevenK> "Every bug is now tagged pg83, enjoy" ? :-)
<lifeless> stub: all the timeout ones
<stub> So can anyone tell me why the debugging information isn't being printed at https://lpbuildbot.canonical.com/builders/lucid_prod_lp/builds/7/steps/shell_7/logs/stdio ? Relevant code is test_on_merge.py around line 80.
<LPCIBot> Project devel build (104): STILL FAILING in 4 hr 2 min: https://hudson.wedontsleep.org/job/devel/104/
<lifeless> stub: what debugging info are you expecting ?
<stub> lifeless: The information about the open connections that test_on_merge.py should emit around line 80.
<lifeless> stub: if not results:
<lifeless>             break
<lifeless> hmm, no, that can't be triggering
<stub> yer - I don't follow. Either it is a logic error I can't see, or buildbot is stripping the information, or it isn't on that branch.
<StevenK> I suspect the latter
<lifeless> that code is in prod-devel
<StevenK> Given how noisy test_on_merge usually is
<lifeless> hangon
<lifeless> stub: thats not the code thats executing
<lifeless> print 'Cannot rebuild database. There are open connections.'
<lifeless> !=
<lifeless> Cannot rebuild database. There are 1 open connections.
<stub> ahh
<StevenK> Can we move to Hudson now? Buildbot is annoying me.
<lifeless> StevenK: you were working on reliability - hows that going?
<StevenK> lifeless: I got distracted by real work
<lifeless> StevenK: fair enough
<lifeless> stub: I don't know what code *is* running, but its not test on merge
<stub> I can't find it in the tree
<stub> Maybe buildbot scripts?
<lifeless> I guess
<lifeless> it claims its running test_on_merge
<stub> yer...
<lifeless> perhaps a .pyc stale issue
<lifeless> thats the old output
<stub> Right. Or that branch just doesn't have my patch.
<lifeless> and now bb is down ><
<lifeless> stub: it does
<lifeless> stub: I've pulled and checked
<lifeless> rev 9848
<lifeless> redoing just to be sure
<lifeless> nope, its good.
<lifeless> hmm, where *has* julians distribution:+ppas patch gone
<lifeless> ah, its in devel
<lifeless> way past eod; ciao.
<lifeless> stub: build 7 was old
<lifeless> https://lpbuildbot.canonical.com/builders/lucid_prod_lp/builds/9/steps/shell_7/logs/stdio was current
<lifeless> till spm nuked bb
<StevenK> My fault
<wgrant> Could someone be convinced to EC2 my two long-approved branches?
<StevenK> wgrant: Oh, sorry, I meant to do that. Link me again?
<wgrant> StevenK: https://code.edge.launchpad.net/~wgrant/launchpad/+activereviews
<StevenK> wgrant: Rah
<wgrant> Oh?
 * StevenK blinks
<StevenK>     return self._mp.queue_status == 'Approved'
<StevenK> AttributeError: 'Entry' object has no attribute 'queue_status'
<wgrant> The URL is right?
<StevenK> Oh, wait
<StevenK> wgrant: Yeah, my fault
<wgrant> Yay.
<wgrant> EC2 doesn't hate me for the seventh time :)
<StevenK> Hm
<StevenK> ec2 still uses pg8.3
<wgrant> Eep.
<StevenK> I think we need a new machine image
<StevenK> wgrant: You don't really care about the ec2 URLs, right?
 * StevenK also notes that ec2 land gets really unhappy if two copies are running
<StevenK> wgrant: Both branches are in ec2
<lifeless> grah we're in testfix ? :(
<StevenK> lifeless: Only because buildbot sucks
<adeuring> good morning
<maxb> heh, oops
<maxb> "
<maxb> Invalid stacked on location: /+branch/qbzr
<maxb> "
<maxb> So whilst the ssh server understands those new URLs, Launchpad gets irked if you use them as stacking locations
<lifeless> please file a bug
<maxb> filed as bug 660358, with a bonus easter egg extra idea :-)
<bac> lifeless: still around?
<StevenK> mars: O hai -- our ec2 images still use postgres 8.3, could you prod them up to 8.4?
<wgrant> StevenK: Thanks.
 * bigjools is way behind on email
<allenap> mrevell: Fancy looking at bug 660283?
<_mup_> Bug #660283: Bug search pages should document valid search expressions <Launchpad Bugs:New> <https://launchpad.net/bugs/660283>
 * mrevell looks
<mrevell> thanks allenap
<bigjools> I'm confused.  Should we have "timeout" and "oops" on timeouts?  Or just oops?    Or just timeout?
<jml> bigjools: timeouts should have 'oops' and 'timeout' unless something has changed recently
<bigjools> jml: I need to have a word with Rob then :)
<jml> bigjools: is lifeless deleting tags?
<bigjools> jml: a bunch of soyuz bugs had "oops timeout" turned into "timeout" IIRC and when he added the pg83 tag the oops tag got removed.  I don't know if that's deliberate.
<jml> bigjools: me either.
<stub> Might have been removed on purpose - pg83 indicates we don't have a current valid OOPS (although a number of non-db ones have got that tag too...)
<jml> ahh, yeah, that'll be it.
<bigjools> furry muff
<lifeless> bigjools: I'm told that timeout and oops tags are mutually exclusive
<lifeless> bigjools: by urshina
<bigjools> lifeless: that seems sub-optimal to me
<bigjools> I'll talk to her and see why, thanks
<lifeless> https://dev.launchpad.net/LaunchpadBugTags doesn't explain
<lifeless> there was a different page
<lifeless> anyhow, on my second day or so I was updating bugs with 'timeout oops' as per how I read the policy
<lifeless> and urshina said that it was meant to be one or the other
<jml> bigjools: to me one seems as good as the other, just as long as we're consistent so tools can be written
<lifeless> jml: bigjools: ah, here it is https://dev.launchpad.net/PolicyAndProcess/ZeroOOPSPolicy
<jml> lifeless: thanks
<lifeless> 'It should be tagged with either 'oops' or 'timeout' on it.
<bigjools> it doesn't say why
<bigjools> and I find it useful to have both tags
<lifeless> bigjools: It doesn't matter to me either way as long as I don't need to remember different rules for different parts of the same project
<bigjools> agreed
<lifeless> bigjools: I'd be delighted to change, if you want to bring it up with urshina/the list
<lifeless> my (probably faulty) recollection is that it was for qa tooling
<bigjools> I find it useful to search for just one tag "oops" and get everything related.  If we don't get stuff tagged with just "timeout" it's more time-consuming, at least for me, to remember to look for the other tag too.
<jml> also, someday I'm going to make that oops/timeout graph that lifeless asked me for
<bigjools> heh
<jml> consistent tagging will be important
 * bigjools totally loves PG84's psql that tells you what other tables reference your column
<bigjools> stub: regarding that sql you did in the bug comment, I vaguely remember someone saying something about there being a way to check person validity directly on Person?
<stub> bigjools: Yer - love that. Pain in the arse backtracking that stuff before
<stub> bigjools: You need person, emailaddress and account for our current 'valid person' rules.
<stub> bigjools: With just person, you can't tell if their account is active or if they have a preferred email address
<bigjools> ok
<bigjools> I still need to order on person, so I need that extra crap :(
<stub> So my timings on current staging seem ok. lifeless got one with a 10 second query.
<bigjools> I'll make another patch to try out with that changed query
<bigjools> sqlobj doesn't do LEFT OUTER JOIN does it :/
<stub> I've blotted all that from my mind.
<bigjools> this is going to be tricky to change
<wgrant> It's not easily Stormifiable?
<bigjools> no
<bigjools> take a look at Distribution.searchPPAs
<bigjools> it has fti stuff - last time I tried that in Storm it was a world of pain
<wgrant> If necessary you could just SQL() that bit.
<bigjools> I could, which is what I think I did
<bigjools> but something else is nagging me and I can't remember what it was
<wgrant> The horrible horrible string concatenation in that method?
<bigjools> heh
<bigjools> that's how it was done with sqlobj
<wgrant> yes, but that's like so three years ago.
<bigjools> I do not want to stormify this query
<bigjools> not right now anyway
<stub> Seems the fastest approach to me
<wgrant> It looks easy enough to Stormify... as long as the callsites aren't braindead.
<bigjools> ...
<bigjools> you know what they say about assumptions
<wgrant> But this should have only one callsite.
<bigjools> hahaha
<wgrant> Well, there's only one non-test callsite that cares about the result.
 * bigjools considers store.execute
 * stub â¥ store.execute()
<stub> Why are you ordering by Person.name anyway?
<stub> Seems... odd...
<bigjools> because this stuff needs to appear on +ppas
<stub> Yer, but Person.name is a very arbitrary order.
<bigjools> true but it's less arbitrary than anything else
<wgrant> displayname is better.
<wgrant> But isn't relevance better still?
<bigjools> yes
<stub> If you pick a field in Archive to order by, you don't have to rewrite it in Storm :)
<bigjools> stub: I know, don't think I hadn't considered that :)
<wgrant> Oh, you order by relevance then name, I see.
 * stub changes his Person.name to 'aaaaaaaaaaaaaaaa_stub'
<bigjools> I could order by relevance, then ppa name perhaps
 * bigjools thinks
 * nigelb points stub to http://uncyclopedia.wikia.com/wiki/AAAAAAAAA!
<bigjools> like :)
<bigjools> wgrant: actually something sensible needs to be the default for when no search term is supplied
<bigjools> I like displayname to some extent
<wgrant> bigjools: Person.name is probably not that
<wgrant> Archive.displayname might be.
<bigjools> indeed
<bigjools> since it will include the person.name anyway unless they changed it :)
<wgrant> Um, well, not any more.
<wgrant> There is no default
<bigjools> mmm true
<bigjools> I think it's a better default, let's see
<wgrant> We really need to fix that lack of default.
<wgrant> Although it's not so bad now that the key doesn't acquire that name permanently.
<bigjools> WARNING:root:Memcache set failed for...
<bigjools> whut?
<wgrant> Didn't you disable memcache on your system?
<bigjools> I did
<bigjools> sigh
<bigjools> actually, not on this machine, so something else is wrong
<bigjools> test isolation crappiness, it seems
<jml> actually...
<jml> mpt did a spec about consolidating the name/displayname/title thingy to make it consistent across LP
<jml> we should do that
<wgrant> We should do a lot of things :(
<jml> Yes!
<jml> Do more things!
<wgrant> An intriguing proposal.
<bigjools> wgrant: https://staging.launchpad.net/ubuntu/+ppas?name_filter=
<bigjools> jml: +1000000000000000000
<wgrant> bigjools: Looks a bit crap, but not much worse than the old one.
<stub> The testsuite doesn't talk to the system memcache
<bigjools> wgrant: seems better to me since it's sorting by something you can see :)
<wgrant> bigjools: True.
<stub> What was the hack in /default to stop rabbitmq starting up? I used to use update-rc.d but that isn't nice apparently
<wgrant> This a.bono guy has a lot of PPAs.
<lifeless> please file a bug on the rabbit package if there isn't something in /etc/default/rabbitmq
<bigjools> stub: I put DAEMON=true in it
<stub> And that *stops* it starting?
<bigjools> yes
<stub> huh
<mpt> jml, https://dev.launchpad.net/RegistrySimplifications
<bigjools> best not to ask :)
<lifeless> please file a bug, thats really nonobvious
<jml> mpt: thank you.
<mpt> I didn't touch Archive. though
<wgrant> mpt: That is a lot of steps.
<jml> wgrant: but they are simple steps.
<wgrant> True.
<jml> (some of them might be tedious, but that's a different axis)
<mpt> Archive.displayname is, I guess, what ends up being shown in the left pane of Ubuntu Software Center
<deryck> Morning, all.
<jml> deryck: good morning
<bigjools> morning deryck
<bigjools> stub: so why was that join to Person having such a big effect in the query?  And only on 8.4?
<stub> I suspect it always had that effect - from my testing it reduced a 1.5 second query to 0.5.
<stub> bug #660460
<_mup_> Bug #660460: Need option to not launch server on boot <amd64> <apport-bug> <maverick> <rabbitmq-server (Ubuntu):New> <https://launchpad.net/bugs/660460>
<stub> Booger. /ubuntu/+ppas just gave me a timeout on staging.
<stub> There seems to be a db restore going on... might just be busy
<bigjools> yeah it was very quick last time
<StevenK> wgrant: Both your branches failed. :-(
<wgrant> @#@!(U$@!$!
<wgrant> #7
<wgrant> Although that's only failure #3 for the other one.
<wgrant> So, um...
<jml> StevenK: I need to check it out, but I think that's a very old "bug" in bzr
<StevenK> jml: Sure, I'd be happy to be pointed at where the issue actually is.
<jml> StevenK: looking now.
<jml> iirc, it might have something to do with python's socket lib being terrible
<jml> StevenK: https://bugs.edge.launchpad.net/bzr/+bug/193253
<_mup_> Bug #193253: sockets being leaked in branch puller tests <Bazaar:Invalid> <Launchpad Bazaar Integration:Fix Released by stub> <https://launchpad.net/bugs/193253>
 * jml replies on list
<jml> done
<LPCIBot> Project devel build (105): STILL FAILING in 4 hr 8 min: https://hudson.wedontsleep.org/job/devel/105/
<deryck> rockstar, ping.  (read: yo, where my new lazr-js, sucka!)
<maxb> jelmer: You know that chardet-dep branch that you fixed? Well I think you forgot to push :-)
<jelmer> maxb: bzr says "No new revisions to push.". Looking into it..
<sinzui> deryck, ping
<deryck> hi sinzui
<sinzui> deryck, I would like your +1 to run this sql update in production. I just confirmed the test run on staging did purge 2500 known spam messages from openjdk: http://pastebin.ubuntu.com/513143/
 * deryck looks
<rockstar> deryck, I have it reviewed and everything, but I have 9 test failures, and they are all bugs' fault.
<deryck> "fault" is such a harsh term. ;)
<deryck> sinzui, r=me.  Do I need to update this on the LPS page?
<deryck> rockstar, do you need our help fixing these test failures?  Are they Windmill or yuitest?
<sinzui> deryck, I do not know.
<deryck> sinzui, if you didn't add the query to LPS, I wouldn't think I need to do so.  If a losa wants it added there, I can update when you ping back.
<sinzui> I will do that now
<rockstar> deryck, windmill.  I think I just need to see details on the failures before I can make a statement on help.
<deryck> rockstar, ok, cool.
<sinzui> deryck, https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus
<sinzui> deryck, bug 660541
<_mup_> Bug #660541: Messages from the list in the moderation queue are spam, discard them with a script <mailing-lists> <Launchpad Registry:In Progress by sinzui> <https://launchpad.net/bugs/660541>
 * deryck updates LPS page
<deryck> sinzui, done. r=me, of course.
<sinzui> thanks
<deryck> np
<jelmer> maxb: fixed
<jcsackett> rockstar, ping.
<rockstar> jcsackett, pong.
<jcsackett> rockstar, could i get your input on https://bugs.edge.launchpad.net/launchpad-code/+bug/652126?
<_mup_> Bug #652126: branch collection action portlet is missing links <bridging-the-gap> <Launchpad Bazaar Integration:In Progress by jcsackett> <https://launchpad.net/bugs/652126>
<jcsackett> it was filed as part of our bridging-the-gap work; i think we can either dismiss it or we need to talk about a different way of presenting the statistics it's talking about.
<jcsackett> if it's the latter, i don't want to take a stab at it without talking with someone on the code team.
<jcsackett> rockstar ^
<dobey> gary_poster: you uh, TIMEd? :)
<gary_poster> dobey, you mean Time Inc?  If so, yeah :-)
<dobey> gary_poster: i mean, i see a CTCP TIME from you :)
<dobey> anyway, lunch is calling. bbiab
<gary_poster> dobey: ah, yeah.  We were having a discussion of python keyring and I was bringing up concerns you mentioned in passing, and I idly did a whois sort of thing
<gary_poster> nothing to respond to
<dobey> ah ok
<dobey> cheers then
<gary_poster> bye :-)
<jml> bigjools: otp now, fwiw.
<jml> bigjools: errr, off the phone
<bigjools> :)
<bigjools> jml: tests are working now
<jml> \o/
<bigjools> jml: one more thing, we're still trapping xmlrpclib.Failure - is that raised by twisted?
<jcsackett> rockstar: had a chance to look at that bug?
<jml> bigjools: you mean xmlrpclib.Fault?
<bigjools> yes :/
<rockstar> jcsackett, yeah, but I'm not entirely sure why we need links there.
<jml> bigjools: yes, it is. I think t.w.xmlrpc.Fault is just a re-export of that
<bigjools> coolio
<rockstar> It's displaying information, but it doesn't need to link anywhere.
<rockstar> At least, that's my opinion.
<bigjools> jml: committing and pushing so you can peruse, one sec
<jcsackett> rockstar: thus my pinging you. it looks to me like that is meant as statistics, not action.
<jcsackett> rockstar: inasmuch as the only place those could link to is the very page you're looking at.
<jml> bigjools: ta
<rockstar> jcsackett, yes.
<jcsackett> rockstar: do you think it's better to dismiss the bug or find a different way to display the info?
<jcsackett> rockstar: i'm not sure, but perhaps the sidebar things are meant to be action links only?
 * jcsackett looks for precedent.
<rockstar> jcsackett, well, there are lots of things wrong with that portlet.
<bigjools> jml: http://bazaar.launchpad.net/~julian-edwards/launchpad/builderslave-resume/revision/11676
<bigjools> well, if it would not OOPS :/
<jcsackett> rockstar: so would something like showing at the top of the page the "N branches, M commits" and removing it from the portlet make sense?
<rockstar> jcsackett, maybe.
<rockstar> jcsackett, although I'd contend that it shouldn't link to active reviews if there are no active reviews...
<jml> bigjools: I'll just pull the branch.
<jcsackett> rockstar: also valid, but maybe that's a different bug.
<bigjools> jml: url works now, but ok
<rockstar> jcsackett, I hate hate hate when we do things like "0 foos in the bar"
<jcsackett> rockstar: yeah; i can see that.
<rockstar> jcsackett, if you're going to fix this portlet, I suggest killing the whole portlet and moving all of the information to be part of the page.
<jcsackett> rockstar: i was just thinking that.
<jcsackett> jcsackett: perhaps placed above the drop down selector
 * jcsackett looks at what he typed.
<jcsackett> i clearly need more sleep and/or coffee. rockstar, last comment was meant for you, not me. :-P
<jml> bigjools: instead of: "server_proxy.queryFactory = QuietQueryFactory" you could also do "server_proxy.queryFactory.noisy = False" and then delete the QuietQueryFactory class
<bigjools> jml: I know, I kinda like the explicit factory
<bigjools> but meh
<jml> bigjools: yeah, it's a taste thing. I think they are both equally explicit in terms of intent though
<jml> bigjools: looks good.
<bigjools> jml: cool, thanks.  So now I have some more tests to write that I thought of that are lacking from the previous manager.
<jml> bigjools: it might be worth adding an errback that transforms the CancelledError into a TimeoutError or something, just to make the API clearer.
<bigjools> ah very good point
<jml> bigjools: and _with_timeout probably ought to be a standalone function in lp.services.twistedsupport
<bigjools> also we need the top-level to handle it
<jml> handle the timeout? yes.
<bigjools> at the moment it would print a stack trace
<bigjools> it just needs to be added to the list of known failures
<bigjools> jml: oh one more thing, when testing on dogfood I noticed that not all types of failure would get back to the top level scan(), which left the scan "dead" after a traceback.
<bigjools> I'm not sure what was going on - but at the very least I need to make sure that *all* errors are caught in scan()
<bigjools> and I don't know why it's not doing that
<jml> bigjools: hmm.
<jml> bigjools: I don't either â that's not much to go on. Was it an "Unhandled error"?
<bigjools> once it gets in there the failure counting will deal nicely with it
 * bigjools hunts logs
<bigjools> jml: yes, Unhandled Error
<jml> bigjools: ahh right
<bigjools> it was a coding mistake
<bigjools> but it should be caught further up
<bigjools> the manager should trap those and kill the build
<jml> bigjools: that means a Deferred somewhere has had errback called on it, but there's nothing handling that error. Normally either the deferred is not being returned ...
<jml> or it is and someone didn't add errback
<bigjools> hmmm
<jml> bigjools: there's not many options open to you if you don't return the Deferred.
<bigjools> jml: so since _startCycle() does d.addErrback(self._scanFailed) then I presume it's the former
<jml> bigjools: or something down deeper.
<jml> bigjools: setting 'debug' (or is it 'DEBUG'?) on the Deferred class to True will give you more information
<bigjools> debug
<bigjools> can you get on mawson?
<jml> no
<bigjools> http://pastebin.ubuntu.com/513226/
<bigjools> that's the general type of thing
<bigjools> I need to handle shutdown gracefully as well, did we work out if there was a reactor hook?
<jml> bigjools: I didn't find out.
<jml> bigjools: part of the problem with unhandled errors is that there's no way of telling a particular error is unhandled until the gc kills the deferred with the error.
 * jml has a look at the code
<bigjools> and that's bad, because in at least one case it failed the builder immediately (I need to purge all those)
<bigjools> jml: def defer_with_timeout(self, d, timeout):
<bigjools> look ok?
<bigjools> in lib/lp/services/twistedsupport/xmlrpc.py
<rockstar> jcsackett, I think that's fine.  It'll probably make that page a little busier.
<jml> bigjools: it's actually not anything to do w/ xmlrpc, I'd put it in __init__ and call it cancel_on_timeout, I think.
<jml> bigjools: and I presume you saw the recent discussion on #twisted
<bigjools> no, not paying attention
<jcsackett> rockstar: i think if it's refactor into one smooth sentence it'll be alright. i'll get a ui review on it when i'm done to be sure though.
<jml> bigjools:  reactor.addSystemEventTrigger('before', 'shutdown', f)
<jml> bigjools: also, we should be using Services, but one thing at a time
<bigjools> oo nice
<jml> mrevell: do we have any docs about the product release finder?
<mrevell> hmm
<mrevell> jml we have this http://blog.launchpad.net/cool-new-stuff/automatically-import-files-to-launchpad-using-product-release-finder
<jml> mrevell: ta
<bigjools> jml: I want to test the scenario where the deferred completes instead of cancelling
<bigjools> and struggling a bit
<jml> bigjools: from a proxy or from cancel_on_timeout?
<jml> bigjools: from a proxy, just do DeadProxy again but with 'return defer.succeed(None)'
<bigjools> jml: testing the cancel on timeout
<jml> bigjools: from cancel_on_timeout, d = cancel_on_timeout(defer.succeed(None), timeout=10)
<bigjools> jml: can I assert it was not cancelled?
<bigjools> that will not fail either way :)
<jml> bigjools: sort of. you can assert that you can add a callback to it and get whatever you passed in to succeed()
<jml> bigjools: and rely on the TestCase to assert that the callLater has been cancelled
<bigjools> right
<jml> bigjools: if that's too implicit for you...
<jml> actually... that won't work anyway
<jml> self.assertEqual([], clock.getDelayedCalls())
<jml> because Trial makes assertions about the actual reactor, and presumably you are passing in a fake.
<jml> (see IReactorTime for docs on that)
<bigjools> implicit is fine
<jml> bigjools: not if you are passing in a clock, it isn't. it won't make the assertion at all.
<bigjools> oh, meh
<LPCIBot> Project db-devel build (66): STILL FAILING in 4 hr 19 min: https://hudson.wedontsleep.org/job/db-devel/66/
<jml> now, where was I
<jml> error handling.
<LPCIBot> Project devel build (106): STILL FAILING in 3 hr 43 min: https://hudson.wedontsleep.org/job/devel/106/
<LPCIBot> Launchpad Patch Queue Manager: [r=jelmer][ui=none][bug=656295] Allow derivers to specify which
<LPCIBot> packagesets they want to copy to the child distroseries in
<LPCIBot> InitialiseDistroSeries.
<bigjools> jml: http://pastebin.ubuntu.com/513242/
<jml> bigjools: sweet.
<bigjools> I'll commit here but land it in a separate branch too
<jml> bigjools: good call.
<bigjools> one of the few things I can :)
<jml> bigjools: I've just looked at that unhandled error in the paste you posted earlier
<jml> bigjools: this is the relevant code:
<jml>         d = self.scan()
<jml>         d.addErrback(self._scanFailed)
<jml>         return d
<jml> if _scanFailed fails unexpectedly, nothing will handle that
<bigjools> ha
<jml> so you could change it to:
<jml>         d = self.scan()
<jml>         d.addErrback(self._scanFailed)
<jml>         d.addErrabck(self._handleUtterDisaster)
<jml>         return d
<jml> but I'm not sure that would win you very much.
<bigjools> so I need an error handler for the error handler
<jml> (particularly if you typo addErrback!)
<bigjools> belt & braces
<bigjools> :)
<jml> bigjools: hmm, I'm not sure writing more code to handle runtime cases where there are programming errors counts as belt&braces
<jml> *deleting* code would be a far more sound strategy :)
<bigjools> I know what you mean, *but* there is one piece of code that's out of the managers hands
<bigjools> builder.getCurrentBuildFarmJob()
<bigjools> that can failed and we have no control
<bigjools> fail, even
<jml> fair enough. in that case maybe put a try/except around it in _scanFailed?
<bigjools> can do - and fail the job immediately
<jml> unfortunately I have to go now.
<dobey> abentley: around?
<gary_poster> bac: hi?
<abentley> dobey: back.
<dobey> abentley: hi. about the bzr upgrade of remote branches issues. is there some way to separately upgrade the repository from the branch itself? or is that what the link on the web does?
<abentley> dobey: I don't understand the question.  Technically, the branch will already be in format 7, and its repository is the only thing that could be upgraded.
<dobey> abentley: ok, i upgraded a branch to 2a several weeks ago, and no new revisions have been committed, and the web page still says KnitPacks5 for the repository format
<dobey> abentley: https://code.edge.launchpad.net/~configglue/configglue/trunk
<abentley> dobey: the branch and its repository have been upgraded, but the database is out of sync.
<dobey> abentley: and there's nothing i can do myself short of committing a new revision to force a rescan, right?
<abentley> dobey: well, we could try taking out a branch lock and seeing if that triggers a scan.
<abentley> dobey: or you could uncommit a revision and then push it again.
<dobey> abentley: ok. i'm not especially concerned at this point. i was just wondering since your e-mail suggested this case shouldn't be happening, as an upgrade should cause a rescan to trigger.
<abentley> It shouldn't be happening.  An upgrade should cause a rescan to trigger.  I can investigate why that didn't happen, now that I have an example.
<dobey> abentley: do you know more specifically when upgrades should have started causing a rescan? if the code that handles that was deployed after i did the upgrade, that would probably be the reason. but "these days" isn't a very exact metric :)
<jcsackett> is there a way to force lowercase on text in a template? ideally without using "python: " ?
<abentley> dobey: months ago.
<dobey> ah ok
<abentley> dobey: probably around May.
<dobey> yeah this was definitely upgraded after that then
<dobey> well the last revision was in August, and I think I did the upgrade probably about 3-4 weeks ago
<abentley> dobey: my logs go back to Sept 23.  Was it before that?
<dobey> let me see if i can find an exact date for it
<dobey> abentley: it probably would have been sept 22 or 23 though
<dobey> Thu 2010-09-23 11:09:34 -0400
<dobey> 0.025  bazaar version: 2.2.0
<dobey> 0.025  bzr arguments: [u'upgrade', u'--default', u'lp:configglue']
<dobey> abentley: should i file a bug?
<abentley> dobey: I guess.  I'm not sure we can do more than mark it incomplete, at this stage.
<abentley> dobey: what's your offset from UTC?
<dobey> abentley: -0400
<abentley> So 11:09 would be 15:09
<abentley> dobey: So you remotely upgraded the branch, rather than using the web page, right?
<dobey> abentley: right, i did bzr upgrade --default lp:configglue
<abentley> dobey: okay, it's possible we don't handle that case.  I was thinking of web-based upgrades, where I know we handle it.
<dobey> abentley: ok, i'll file a bug
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build (107): FIXED in 1 hr 30 min: https://hudson.wedontsleep.org/job/devel/107/
<LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][no-qa] Modify xx-person-subscriptions.txt not
<LPCIBot> to use sample data.
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug 46581] Do not oops when users hack poll
<LPCIBot> types.
<_mup_> Bug #46581: Change a poll type URL manually crashes <oops> <polls> <Launchpad Registry:Fix Committed by sinzui> <https://launchpad.net/bugs/46581>
<dobey> abentley: filed bug #660695
<_mup_> Bug #660695: Remote upgrade not triggering rescans <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/660695>
<abentley> dobey: I can't reproduce it.  I just created a branch and upgraded it remotely.
<dobey> hmm
<dobey> abentley: let me see if i have another branch i can try on
<abentley> dobey: And it shows the correct repository format.
<abentley> dobey: wrong branch format, though.
<dobey> hmm
<dobey> abentley: interesting. i see that as well on another branch i tried. and yet another i tried, has the right branch format, but still says KnitPack6
<abentley> dobey: you mean, you just created a new branch in KnitPack6, upgraded it, and it's showing the wrong data?
<dobey> abentley: no, i found a branch already on lp which i already owned, which was in the old format, and upgraded it
<abentley> dobey: but you upgraded it just now?  Okay, maybe it's something to do with the format.
<dobey> yes
<dobey> abentley: it seems that things that are already BranchFormat7, exhibit the issue of showing the old Repository format info
<abentley> dobey: aha!
<dobey> abentley: and BranchFormat6 branches seem to always show BranchFormat6, but the Repository format gets updated
<dobey> abentley: that makes sense to you i take it? :)
<abentley> dobey: I can see how such a bug would happen.  Someone misunderstood the significance of branch format, and assumed if it hadn't changed, the repository format hadn't changed.
<dobey> abentley: ah. and presumably the reverse as well, in the other case where BranchFormat doesn't change?
<dobey> (doesn't change in the UI)
<abentley> dobey: AFAICT, there are no cases where the branch changes in the UI from an upgrade alone.
<dobey> abentley: so for the case where the UI still shows BranchFormat6 after an upgrade to 2a, is a separate bug?
<abentley> dobey: yes, I've filed a bug for it.
<dobey> abentley: ok, cool. glad i could help :)
<abentley> dobey: bug 660706
<_mup_> Bug #660706: Wronng branch format shown on web page after remote upgrade <branch-scanner> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/660706>
<abentley> dobey: Successfully reproduced the bug.
<dobey> abentley: cool.
<mwhudson> good morning
<lifeless> moin
<wgrant> Any progress on the EC2 breakage?
<mwhudson> wgrant: i just sent a mail that may be related
<wgrant> Ah.
 * wgrant looks.
<wgrant> Hm, yes.
<lifeless> mwhudson: so, have you filed it upstream yet?
<mwhudson> lifeless: no
<mwhudson> at least, not that i remember
<lifeless> mwhudson: (hint)
<mwhudson> yeah yeah
<mwhudson> i don't really want to remember the details, they made me very angry
<lifeless> Simple* can do that ;)
<mwhudson> i'll do it when i get through my mail
<LPCIBot> Project db-devel build (67): STILL FAILING in 3 hr 49 min: https://hudson.wedontsleep.org/job/db-devel/67/
<LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11696
<LPCIBot> included.
<mwhudson> which has a new way for oopsprune to fail today
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=655567] Wire up structural bug subscription
<LPCIBot> filters to the subscriber selection machinery.
<mwhudson> IOError: [Errno 13] Permission denied: '/srv/launchpad.net/production-logs/2010-10-14/57341.C3848'
<wgrant> I wonder why Hudson managed to discover the errors more than a week before EC2.
<lifeless> wgrant: hudson is nice :)
<wgrant> Well, yes, but...
<lifeless> mwhudson: #python-testing may interest you as a lurking channel
<lifeless> I need a teddy bear for where to put some testing code
<mwhudson> lifeless: lp.testing.$whatever?
<lifeless> mwhudson: mocker vs fixtures.*
<mwhudson> ah
<lifeless> so, I'm writing some code that invokes external processes.
<lifeless> I have no interest in actually invoking them in my tests.
<lifeless> partly because the process is bin/test so it would be hugely meta to do so
<lifeless> and partly because the zope stack is so slow I'd die of old age waiting for things to run
<wgrant> Can I send you off on a diversion to fix that slowness? :P
<wgrant> That generally seems to be fairly effective.
<lifeless> wgrant: yes, ditch zcml & global state. Thanks, I'll expect a patch :)
<jam> mwhudson: just to be sure, merging *from* devel and proposing *into* db-devel is always safe, right?
<jam> (aside from short-term bugs in devel that haven't made it into stable yet, that would eventually cause testfix mode)
<mwhudson> jam: yeah, but you'll end up with a diff that's way bigger than necessary in the mp
<mwhudson> it sucks that we can't retarget the existing mp
<mwhudson> thumper: hey, fix that :-p
<thumper> yeah yeah
<thumper> I've talked with wally about that
<jam> mwhudson: why would it be too big? Stuff that devel has that hasn't propagated into db-devel yet?
<wgrant> Right. That can take days if buildbot is screwed.
<wgrant> Which is fairly often these days.
<mwhudson> jam: yeah, exactly
<lifeless> mwhudson: so where was I
<lifeless> right, I want to use a test double for 'subprocess.Popen'
<lifeless> I *could* use a mocking library
<lifeless> but I'll still have an implementation of subprocess hanging around which is a little larger than a mock
<lifeless> So instead I'm thinking to add a tested double and a glue fixture, with setUp monkey patching the system module
<lifeless> mwhudson: what do you think?
<wgrant> lifeless: You wanted less global state, but you are advocating monkeypatching out subprocess.Popen? :P
<lifeless> wgrant: sadly yes. But for the duration of a single test
<lifeless> wgrant: modules are themselves global state; we can work better layers up on top of them though.
<lifeless> another option is to make the code I write take a Popen implementation
<mwhudson> dependency injection woo
<mwhudson> that said, i think monkey patching will produce less wtfs per second
<wgrant> jelmer: Hi.
<lifeless> yeah
<jelmer> wgrant: Hello.
<wgrant> jelmer: I was just stalking recent Launchpad branches, and I think the assert in 135610-duplicated-ancestry is still a little wrong.
<lifeless> hmm, I probably need to upload fixtures to debian soonish
<wgrant> There can be more than one Published publication if the publisher hasn't finished yet.
<wgrant> (it first marks everything has Published, then later marks old ones Superseded)
<jelmer> lifeless: NEW is stalled again though :-/
<jelmer> wgrant: Hmm
<jam> when logging into the local launchpad instance, what username are you supposed to use? (I'm trying to get an ssh key registered, etc)
<jam> It seems to be redirecting me to "testopenid.dev" but that isn't letting me create a new account
<wgrant> jam: admin@canonical.com is an admin.
<wgrant> admin@canonical.com:test
<jam> wgrant: and that person is then "name16"... very strange
<jam> but it worked, thanks
<wgrant> jam: Well, username != password
<wgrant> I think there's a script (utilities/make-lp-user?) which will create a new user and upload your SSH key to it.
<jam> wgrant: or login name, or account name, or...
<wgrant> Not sure if it still works.
<wgrant> jam: By password I of course meant email address.
<wgrant> username != email address
<jam> wgrant: yeah, but also calling "admin@canonical.com" "name16" isn't very obvious, either
<jam> "admin" would have been a bit more obvious
<wgrant> admin@canonical.com is a relatively new alias.
<wgrant> name16 dates to 2005 or so.
<wgrant> Yay sampledata.
<jam> I wouldn't have too much problem, but it seems that every "make schema" nukes the stored ssh keys
<wgrant> Why are you running make schema so often?
<jam> so just about every time I update my launchpad branch, I have to start from scratch
<wgrant> You could always upgrade your DB with database/schema/upgrade.py, I guess.
<jam> wgrant: I get a lot of "schema is out of date" failures, but partly because this was originally based on db-devel
<wgrant> But make-lp-user may be a better option.
<wgrant> I have a couple of scripts which I use to prepare a fresh DB.
<wgrant> So make schema isn't so bad.
<wallyworld>  abentley, thumper, rockstar: standup?
<rockstar> wallyworld, sure.
<poolie> jam, so, still hoping for a landing before uds?
<jam> poolie: well, land, maybe deployed to staging, pretty unlikely to be deployed to production
<jam> is my current thought
<wgrant> Hm.
<wgrant> launchpad-developer-dependencies should depend on lpreview-body, or something.
<jam> mwhudson: so I haven't reproduced the failing tests yet, but mostly because "make schema && bin/test -vvt lp.codehosting" seems to be awfully slow going
<jam> but I'll hopefully get there before I stop for tonight
<mwhudson> jam: you should definitely only have to run make schema once per branch
<jam> mwhudson: well, and every time I update from somewhere
<jam> I think I was slightly out of date from the last time I pulled in db-devel
<mwhudson> jam: if you're targeted devel now, then merge from there, commit, run make schema
<mwhudson> once :)
<jam> mwhudson: right
<mwhudson> it can be a pain though, it takes a long time
<poolie> jam so it looks like you're not blocked, at least
<jam> I'm at the point that "bin/test" has been running for 20 minutes or so, and it is on "lp.codehosting.tests"
<jam> take that back "bin/test" has been running for 1:06
<poolie> jam i recently fixed a bug where resizing the window made the tests crash
<poolie> _that_ is annoying when they've been going for an hour
<jam> poolie: definitely
<jam> I'm running it on a 1GB VM, and having bin/test fork bin/test fork python fork... and all at 177MB of virtual memory isn't very happy, either
<mwhudson> argh
<jam> I'm pretty sure lp. has now bloated from about 120MB to about 150MB since I last updated
<jam> mwhudson: I at least make sure to "/etc/init.d/apache2 stop" since that would be running yet-another copy of lp.*
<lifeless> jam: yes, layers are terrible (layers support the idea of unteardownable fixtures)
<lifeless> which is frankly batshit insane
<poolie> hi lifeless
<rockstar> wallyworld, do you have time for a chat now, or do you have kids to deal with?
<wallyworld> rockstar: i have to do the school drop off - can you ping me alter after you've done your things?
<lifeless> hi poolie
<rockstar> wallyworld, mine things don't need to be done for 2.5 hours, so ping me when you're back.
<jam> lifeless: would it matter if you just made sure all of the layers that *launchpad* has can be torn down?
<lifeless> jam: at that point we can just drop in testresources :)
<rockstar> lifeless, yes please.
<wgrant> Does lp-propose do prereq branches?
<wallyworld> rockstar: actually, we can have a chat now if you like. i don't have to do it for another 20 mins or so
<rockstar> wallyworld, okay.
<jam> lifeless: so is that why it forks its own children? So that it can ensure clean state?
<lifeless> jam: yes, it forks its own child when it hits 'NotImplementedError' in a layer tearDown
<jml> best feature evar
<wallyworld> rockstar: skype?
<rockstar> wallyworld, yea, I'm up.
<lifeless> and depending on where its at in the test process hitting that error means it won't tear down other layers, so a month ago you'd have had multiple librarians, memcached, etc all running too
<jam> any ideas on the "No module named mailman.monkeypatches.*" stuff? I did just run "rocketfuel-get" and "make"
<mars> jam, try 'make clean && make' just to be safe, and check for conflicts
<lifeless> jam: rm -rf lib/mailman
<lifeless> jam: then do 'make
<jml> mwhudson: I can no longer understand your comment in layers.py about twisted signal handling: http://paste.ubuntu.com/513406/
<jam> lifeless: so you're saying that I need to start this 1+ hour test run from scratch again...
<jam> :)
<lifeless> jam: its a stale statically-copied mailman element
<jam> I find it interesting that the import facist complains so loudly, yet it doesn't stop anything from running
<mwhudson> jml: it's possible it doesn't apply with twisted any more
<jml> mwhudson: well, aiui, when the reactor is running there *is* a sigchld handler installed
<mwhudson> jml: let me read some code again
<jml> mwhudson: ok.
<mwhudson> jml: ah ok
<mwhudson> the point is to make sure that the sigchld handler is not installed while the test_* method runs
<jml> mwhudson: the point of the comment or the code?
<mwhudson> if a test returns a non-fired deferred, trial starts the reactor
<mwhudson> which installs a sigchld handler
<mwhudson> and then stops/crashes/mutilates it again
<mwhudson> which doesn't uninstall the handler
<mwhudson> jml: the code
<mwhudson> jml: i can probably rephrase the comment a bunch
<jml> mwhudson: I thought the code was about undoing the mangling that trial does
<mwhudson> jml: i don't think so
<jml> mwhudson: then save & restore are odd names
<mwhudson> jml: they're about undoing the mangling that reactor.run does
<jml> mwhudson: oh ok, that's what I meant.
<jml> mwhudson: if you could rephrase that comment that would help me, I think
<mwhudson> jml: ok
<mwhudson> jml: twisted no longer raises PotentialZombieWarning
<jml> mwhudson: so we can forget about the comment?
<mwhudson> well, simplify it a lot
<jml> heh
<mwhudson> i think we suppressed the warnings in a few tests, but i deleted the suppressions when i upgraded to 10.1
<mwhudson> jml: it's still a bit of a novel: http://paste.ubuntu.com/513424/
<jml> mwhudson: that's good, thanks.
<jml> mwhudson: so if we replaced our Twisted tests with something that always ran the reactor, basically we'd be unable to use tachandler as-is
<LPCIBot> Project devel build (108): FAILURE in 3 hr 42 min: https://hudson.wedontsleep.org/job/devel/108/
<LPCIBot> * Launchpad Patch Queue Manager: [r=edwin-grubbs][ui=none][bug=347218] Allow a project's or
<LPCIBot> distribution's bug supervisor to set the official bug tags for it.
<LPCIBot> * Launchpad Patch Queue Manager: [r=gary][ui=none][bug=628510] Fixes bug 628510 by overriding the
<LPCIBot> default permission value for the oops file and oops dir when
<LPCIBot> those are created.
<_mup_> Bug #628510: OSError at /oops.py/  when using lp-oops <canonical-losa-lp> <Launchpad Foundations:In Progress by matsubara> <https://launchpad.net/bugs/628510>
<mwhudson> jml: yeah
<gary_poster> "IOError: [Errno 28] No space left on device"
<lifeless> \o/
<mwhudson> yeeeeeeeeeeeha!
<wallyworld> rockstar: just checked - old version has same issue :-(
<rockstar> wallyworld, okay. Maybe the problem IS in our code.
 * rockstar sads
<jml> mwhudson: ok, thanks. the testtools/twisted thing I'm coming up with does the signal save/restore, but always runs tests in the reactor
<jml> mwhudson: so I guess I'm going to have to fix tachandler
<mwhudson> jml: ok
<mwhudson> jml: i think there is something in twisted that is supposed to do signal handling in a less interruptive fashion
<mwhudson> jml: but i don't know the details and it didn't seem to work for the buildd-manager so ...
<jml> mwhudson: maybe I'll be forced to write APIs for twistd
<mwhudson> jml: woo
<jml> I would like some more days
<poolie> hello jml
<jml> poolie: hello
<jml> poolie: do you have some days that I can use?
<thumper> jml: you can use saturday and sunday :)
<jml> thumper: you'd think so
<jml> thumper: but they are decreasingly available to me for programming
<poolie> jml, octember's looking good
<thumper> :)
<jml> poolie: Cool, thanks. I'll see what I can do.
 * jml -> bed
<jml> g'night
#launchpad-dev 2010-10-15
<lifeless> thumper: did you really mean to link to bug 240067 ?
<_mup_> Bug #240067: Launchpad projects need wikis <feature> <Launchpad itself:Invalid> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/240067>
<thumper> lifeless: no
<thumper> lifeless: I've fixed it
<thumper> I had two bugs open
<thumper> and I linked to the wrong one :(
 * thumper heading afk for hair cut and lunch :)
<LPCIBot> Project devel build (109): STILL FAILING in 1 hr 28 min: https://hudson.wedontsleep.org/job/devel/109/
<LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=656759] It's now possible to subscribe with,
<LPCIBot> and filter direct subscriptions by, a BugNotificationLevel.
<LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=651240] The Bug:+subscribe functionality
<LPCIBot> has been moved into its own view class.
 * wgrant deletes lucilleconfig.
<lifeless> james_w: around? does that develop= line work to use regular non-buildout projects ?
<james_w> dunno
<james_w> lifeless, I believe the result is to run "setup.py develop" in those dirs, and then add a .egg-link to them
<james_w> and I don't think that requires them to use buildout
<james_w> it wouldn't really surprise me if it didn't work though
<lifeless> develop isn't in standard setup.py
<lifeless> hmm, it may work, something funny with the iport thought
<lifeless> \o/
<lifeless> >>> fixtures.PopenFixture
<lifeless> <class 'fixtures._fixtures.popen.PopenFixture'>
<james_w> depends what you mean by "standard", it's in setuptools, so a fair number of projects will support it, and they don't have to use buildout to have it
<lifeless> distutils 4 eva
<lifeless> anyhow, develop= worked with python-fixtures
<lifeless> which is nice
<LPCIBot> Project devel build (110): STILL FAILING in 1 hr 29 min: https://hudson.wedontsleep.org/job/devel/110/
<LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=650343] Add X-Launchpad-Original-To to
<LPCIBot> recipient lists;
<LPCIBot> move some related files from c/l/mail to lp/services/mail.
<LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=656213] Allow .lpconfig to be honored if
<LPCIBot> initial configuration is "development"
<wgrant>     """Manage a publisher configuration from the database. (Read Only)
<wgrant>     This class provides a useful abstraction so that if we change
<wgrant>     how the database stores configuration then the publisher will not
<wgrant>     need to be re-coded to cope"""
<wgrant> What an *awesome* idea.
<lifeless> uhm
<lifeless> yagni
<wgrant> Yes.
<wgrant> We haven't needed it in more than five years, so I'm deleting it.
<rockstar> wallyworld, hey.
<wallyworld> rockstar: hiho
<wallyworld> see my email?
<rockstar> wallyworld, just out of curiosity, could you `make clean build` and then run the windmill test?
<wallyworld> that's what i did :-(
<rockstar> wallyworld, hm.
<wallyworld> rockstar: any thought's? looks like YUI() is borked in windmill
<rockstar> wallyworld, this is the Y.io() thing, right?
<wallyworld> yeah
<wallyworld> and also any other YUI eg Y.all()
<wallyworld> or maybe not Y.all - it may have been run on the wrong instance. i need to check that
<wallyworld> but Y.io is definitely broken
<rockstar> wallyworld, what happens if you -D, wait for it to fail, and then try and look up the url being requested in the url bar?
<wallyworld> rockstar: good question. hold that thought and i'll get back to you
<rockstar> wallyworld, I'm also curious to know whether or not a YUI 3.2 update would make it work.
<wallyworld> rockstar: i'm not yet familiar enough with the failure mode nor what's new in 3.2 to know if it will help or not. can't hurt to try i guess
<rockstar> wallyworld, well, as I upgraded, I found that lots of bugs were hidden in our javascript that YUI 3.2 doesn't pass silently.  Maybe that might help as well.
<rockstar> wallyworld, I don't know, we're at a weird impass now.
<wallyworld> rockstar: i'll check this one other thing. perhaps you could grab my branch and try it with 3.2?
<rockstar> wallyworld, sure.  One sec.
<wallyworld> rockstar: bin/test -vvt test_branch_broken_links <--- for when you have the branch pulled
<lifeless> rockstar: hey
<rockstar> lifeless, hi sir.
<lifeless> rockstar: I have a question about windmill
<lifeless> rockstar: what will happen if I run two windmill tests concurrently?
<rockstar> lifeless, I SEVERELY doubt I have the answer, but I can probably get as close as anyone...
<rockstar> lifeless, I think, were you to do that, you'd want them running in separate processes at least.  They'll need their own instances of the browser they fire up.
<lifeless> rockstar: will doing xvfb-run be enough to do that ?
<rockstar> lifeless, no idea.
<lifeless> I'll ask on twitter :)
<rockstar> lifeless, :)
<rockstar> lifeless, mikeal may have a good answer for you.
<rockstar> I wish I knew more about windmill, so I could actually fix it.
<wallyworld> rockstar: the client call to the server side endpoint works fine from a console on the test browser, where the Y.io call fails
<wallyworld> rockstar: ie window.open('http://code.launchpad.dev:8085/+check-links?link_hrefs={}')
<rockstar> wallyworld, what if you use the actual browser that it brings up?  The Firefox instance?
<wallyworld> yes, that's what i'm using
<wallyworld> i open the firebug light console
<rockstar> Is that the exact url that is getting requested?
<wallyworld> almost: i have cut out the actual json guts between the {}. with an empty {} it just returns {} so the end-end works
<wallyworld> i can open a new tab and type the url directly or use the firebug console and do a window.open()
<lifeless> do our tests for windmill go through apache?!
<rockstar> lifeless, no.
<lifeless> whew
<lifeless> so the 8085 is just a daft default?
<rockstar> Yeah.
<wallyworld> a default that's typed in many, many places in the code
<rockstar> wallyworld, where?
<lifeless> wallyworld: it shouldn't be; but if it is replace it with a config lookup please
 * wallyworld looks at the code
<rockstar> wallyworld, canonical_url should just give it to you correctly.
 * rockstar wrote that patch...
<wallyworld> lots of tests (doc and py) have code like browser.open('http://launchpad.dev:8085/+login')
<lifeless> ugh
<lifeless> wallyworld: care to file a bug?
<lifeless> (or better yet, just fix)
<wallyworld> lifeless: will do.
<wallyworld> lifeless: after rockstar and i get this @!^#@#@@& YUI and windmill issue fixed
<lifeless> naturally
<wallyworld> rockstar: i'm hungry. i'll grab a bite to eat and check back after that on the progess using YUI 3.2 to see if it sheds more light on the ajax breakage
<rockstar> wallyworld, windmill tests are running now.
<wallyworld> rockstar: ok. i'll wait a bit. did you try the specific one i mentioned?
<rockstar> wallyworld, no, because I'm also trying to fix my test.  :)
<wallyworld> np
<rockstar> wallyworld, I'm testing lifeless' query right now...
<rockstar> My laptop is not happy.
<wallyworld> rockstar: from our discussions, the root cause of the ajax issue for your and my tests is likely the same anyways i think?
<rockstar> wallyworld, I'm not so sure.
<wallyworld> rockstar: ok. i'll wait for a progress report from your side of things. in the meantime, food awaits
<lifeless> rockstar: about parallel testing?
<rockstar> lifeless, yes.
<lifeless> rockstar: I'd expect things to blow up hugely
<lifeless> rockstar: but not because of windmill
<rockstar> lifeless, no, it was windmill.
<lifeless> rockstar: is there some way to identify windmill tests a priori?
<rockstar> lifeless, so, the second instance of bin/test died because port 8085 was in use.
<lifeless> rockstar: right, thats not a windmill issue
<rockstar> lifeless, I think that means that we might be able to run it fine once everything is set up.
<lifeless> rockstar: theres a long chain of things to fix ;)
<lifeless> rockstar: the testdb, all the external helpers, the oops dir, the log dir
<rockstar> lifeless, but there's also probably a huge penalty in starting another firefox instance.
<lifeless> poolie: I htink its a bad idea to link the code style giude from the front page
<lifeless> poolie: but I'd like to know why before rolling your change back
<poolie> i'd like to know why too :)
<lifeless> I think its a bad idea because really all the guides need to be read, to write patches for LP
<lifeless> special casing that one makes it feel like that element on the front page is a nested table of contents
<lifeless> which its not
<lifeless> poolie: your turn :)
<poolie> it's the one i've found myself linking to or looking at most
<poolie> obviously other people may care more about js style
<poolie> feel free to revert
<lifeless> I'd be happy to list them all there and delete the list-page of the guides
<lifeless> there's no content on the indirection page
<lifeless> what do you think?
<poolie> you could make 'Style guides' a new blue-ish section
<poolie> also 'architecture guideline' is not really a style guide
<lifeless> blue section ?
<poolie> heh, doubly so because it does not exist :)
<poolie> like 'process', 'tools',
<poolie> an h2 or h3 or whatever
<poolie> 'does not exist' meaning the first link on https://dev.launchpad.net/StyleGuides is bronke
 * rockstar suspects the js style guide needs some updating.
<poolie> lifeless: so that's settled?
<lifeless> inlined it on the front page
<poolie> great
<poolie> glad i could push it into a better direction :)
<lifeless> how much memory does a bin/test process need
<lifeless> poolie: we can hope it is better :)
<rockstar> lifeless, I guess it depends on what tests it's running.
<lifeless> rockstar: peak memory is what I need
<lifeless> like, if the machine has 2 GB
<lifeless> and 16 procs
<lifeless> should I start 16 test runners
<lifeless> or 4
<lifeless> 16 cores
<lifeless> bac: is that the threading thing
<lifeless> ?
<bac> lifeless: yes
<bac> test_network
<bac> lifeless: do you have a sec to talk about the metric in the ArchitectureGuide wrt 2 second tests?
<lifeless> sure
<bac> so i have a branch that adds a new test, it runs four tests and the test case is instantiated for five different pillars
<lifeless> do you mean irc or voice when you say talk
<bac> lifeless: here is good and my voice is gone today
<lifeless> sure
<bac> so it runs 20 tests and was taking 42 seconds with the straightforward (naive) implmentation
<lifeless> so, new test, 4 cases, parameterised over 5 pillars
<lifeless> the first question I have is why it needs parameterisation (can things actually vary)
<bac> i started playing around with it yesterday and got it down to <11 seconds with the same coverage
<bac> good, yeah?
<lifeless> bac: thats excellent.
<lifeless> bac: I presume thats not including the layer setup time.
<bac> well, in order to do that i had to collapse the four tests into one so the expensive setup was not called multiple times, violating our guideline to only test one thing at a time
<lifeless> what makes the setup expensive?
<bac> that was the bulk of it, caching some properties accounted for the rest, which jtv objected to
<bac> lifeless: creating objects
<lifeless> bac: if caching properties makes the test suite faster, it doesn't necessarily follow that prod will be faster - but it may well.
<lifeless> bac: if its noticably faster, it probably will make prod faster.
<lifeless> anyhow, back to your question.
<bac> well, this is not really a production issue.  the test is just to verify that the correct anti-robot meta is included in the rendered templates based on LP usage
<bac> so the speed or slowness of the test really has nothing to do with performance in production
<lifeless> 2 seconds is a statement of where we'd like to be. If we can't reach it right now, I suggest analying *why* far enough to be confident that we know what to fix, file a XXX bug on that (e.g. creating DB test objects is slow) and move on.
<lifeless> however I'd be utterly delighted if you were to keep driving it down to a sensible figure
<lifeless> bac: I have to disagree about its relevance for production
<bac> lifeless: my question is this:  what do we value more:  test readability and separation or speed?
<lifeless> bac: all three
<lifeless> bac: in this case, for instance, you can use a layer (ugh, but thats the current tool) to provide the same expensive setup for all 20 tests, and have separate clear test code per case
<lifeless> and it should perform identically
<lifeless> except that you'll need to intercept the db layer rollback (and there is a flag for that to let you do so)
<lifeless> so in your layer setUp to set the 'do not rollback' flag, and in your layer tearDown you restore it.
<bac> lifeless: here is the original: http://pastebin.ubuntu.com/513562
<lifeless> bac: I'm still staggered that setUp is so slow for your test
<bac> and here is the restructured one http://pastebin.ubuntu.com/513561
<bac> lifeless: i make the argument about no effect on production b/c all i have done is make changes to the structure of the test not any of the production code
<lifeless> so you're saying that canonical_url and getUserBrowser are sufficiently slow
<rockstar> bac, I'm happy to do reviewer meeting duty next week.
<lifeless> we use canonical_url in prod
<lifeless> bac: I agree, seeing that, but its data we should gather for where prod performance issues are
<bac> lifeless: right.  but i haven't sped them up, i've avoided them
<bac> rockstar rocks
<lifeless> the getUserBrowser cachedproperty looks like it will get no hits, FWIW
<bac> how's that?  getRenderedContents is called four times
<lifeless> oh, I see
<lifeless> thanks
<lifeless> so, I think that that test is fine
<lifeless> personally I'd structure it as a matcher
<lifeless> then you wouldn't need a mixin
<lifeless> but doing multiple similar checks on one fixture are fine
<lifeless> totally readable
<bac> lifeless: i guess my main point is i'm dissatisfied b/c i find the explicitness of the original appealing
<bac> but dog slow
<bac> i did not know about using a new layer to accomplish what you suggest
<bac> i may pursue that and if it works send out an email as a case study
<lifeless> bac: I wouldn't in this case, its nice and clean, not at all what I envisioned
<lifeless> bac: please don't, layers are on the way out
<bac> oh, good
<bac> ok, well maybe i'll just send an email with what i've done and the four-fold increase in speed
<lifeless> I'd suggest you look into testresources or similar, but thats conflicts with layers, so its not a good learning point just yet.
<lifeless> anyhow, If you were testing many different things in those cases, I'd understand and agree with it being better to have 4 cases
<bac> lifeless would you mind putting your stamp on the MP for these changes
<lifeless> but I think you're really testing a single contract
<lifeless> the contract being the 4 cases where robots are blocked.
<lifeless> whats the MP ?
<bac> https://code.edge.launchpad.net/~bac/launchpad/bug-652280-pg-trans/+merge/38195
<lifeless> you couldn't use cached property here anyway, you need to reload the browser each time, you could if you called .open(), but the thing you were measuring was probably the open and render time anyhow.
<lifeless> (looking at the diff in the MP I see that you're not caching)
<bac> lifeless: i do reload the browser each time
<lifeless> cool
<bac> lifeless: the MP is not yet updated
<lifeless> bac: I've stamped my opinion on the bits in question.
<lifeless> I haven't dug really deep, but I see you've had a thorough discussion anyhow ;)
<bac> yeah,thanks
<rockstar> lifeless, just saw your tweet.  I think you need to at least have two separate firefox instances.
<lifeless> rockstar: why?
<lifeless> I mean, if we need it, we need it
<lifeless> but its going to suck having 8 concurrent firefoxes doing their thing
<lifeless> or 16 on serious desktops
<lifeless> e.g.
<lifeless> robertc  15152  2.9  4.2 412104 86656 pts/1    Sl+  14:56   0:01  |       \_ /usr/bin/python -S bin/test -vt test_parallel --parallel --subunit
<lifeless> robertc  15167  7.4  6.5 399240 134248 pts/1   S+   14:56   0:03  |           \_ /usr/bin/python -S bin/test -vt test_parallel --subunit --load-list /tmp/tmpSbVCl6
<lifeless> robertc  15168  7.5  6.5 399320 134244 pts/1   S+   14:56   0:03  |           \_ /usr/bin/python -S bin/test -vt test_parallel --subunit --load-list /tmp/tmpsNzicF
<rockstar> lifeless, I think the interface to remotely control firefox is per browser.  I remember mikeal's pycon talk about it.
<lifeless> ah
<lifeless> still, out of scope for me -just yet-
<lifeless> jml: I'm sad; someone fucked with list-tests and now it prints test descriptions not ids, and prints other guff too.
<lifeless> jml: either that or it never really existed.
<lifeless> ooooh yeah
<lifeless> parallel testing working. |o|
<lifeless> of course, it'll blow up trivially on stuff like rockstars experiment
<wgrant> Or, say, database access?
<lifeless> that will be the height of hilarity.
<lifeless> StevenK: does your hudson have resources to run a parallel version of launchpad tests?
<lifeless> StevenK: one that I expect to fail massively.
<lifeless> wgrant: https://code.edge.launchpad.net/~lifeless/launchpad/paralleltests if you want to play
<wallyworld> can anyone tell me the difference between zope.app.pagetemplate and zope.pagetemplate?
<lifeless> generally zope.app stuff is more tightly tied to the application server environment
<lifeless> often it is glue between generic and specific stuff
<wgrant> Lots of things from zope.app.* are being moved into zope.* as part of the ZTK rework.
<wgrant> So zope.app.pagetemplate could just be a deprecated alias now, or it could still have some functionality of its own.
<wallyworld> i have a patch for zope.pagetemplate.engine.py - is the best course of action to ask on the zope dev list. i assume htere is one?
<lifeless> wgrant: excellent!
<lifeless> bah
<lifeless> wallyworld: ^
<wgrant> https://mail.zope.org/mailman/listinfo/zope3-dev is the list.
<wgrant> But you might be better off talking to some of our Zopeish people...
<wallyworld> lifeless: it's a simple one.  i've replaced if getattr(object, '__class__', None) == dict: with if zope_isinstance(object, dict):
<lifeless> yay
<lifeless> so, find the project in lp and propose a merge proposal
<lifeless> they are usin gLP
<wallyworld> it restores the short circuit for menu links when used with the branch i just did for performance improvements
<wgrant> lifeless: They're even using LP for MPs?
<lifeless> wgrant: yes
<wgrant> Because they still use zope.org svn.
<wallyworld> what's gLP?
<lifeless> incoherently
<lifeless> wallyworld: using LP
<wallyworld> ok. i had a quick look at lp. there's a few zope projects there. i wasn't sure if we were just mirroring their stuff or not
<wallyworld> or if i had to wander over to zope.org
<lifeless> either, AFAIK
<wallyworld> ok. thanks
<wallyworld> wgrant: thanks also for the info
<lifeless> perhaps both is best
<lifeless> wgrant: this is what you'll get:
<lifeless> psycopg2.ProgrammingError: database "launchpad_ftest" already exists
<lifeless> :)
<lifeless> with --parallel on db tests
<wgrant> lifeless: Ah, I see.
<wgrant> Still, that should be reasonably easy to fix.
<lifeless> wgrant: like I say, there's a list of things to fix ;)
 * wgrant is demolishing lucilleconfig while trying to avoid finishing assignments.
<StevenK> lifeless: I'm not sure how to get Hudson to run arbitary branches
<StevenK> TBH, I'd just throw it at ec2 and see what happens
<lifeless> StevenK: set up a new job, also of trunk
<lifeless> StevenK: you misunderstand me
<lifeless> StevenK: I've added a new bin/test option, --parallel.
<lifeless> StevenK: due to our test suite making many inappropriate assumptions, this won't work for all tests yet.
<lifeless> StevenK: I want a ratchet, a visible progress marker.
<lifeless> StevenK: so I want it run, with as many cores at once, to find unknown issues
<StevenK> https://hudson.wedontsleep.org/job/parallel-test/
<lifeless> and when it starts to pass most tests, we can organise a dedicated burn-down window for it
<lifeless> StevenK: awesome; you'll need --parallel in the job options (I can't see the config can I?) and my branch to land.
<lifeless> bbs
<StevenK> lifeless: I can add an account for you and you can fix the tests
<lifeless> fix the tests?
<StevenK> Er, fix the config
<lifeless> its just --parallel on bin/test :)
<lifeless> verry simple.
<StevenK> I don't run bin/test, I call make check
<lifeless> you can validate it using lp:~lifeless/launchpad/paralleltests
<lifeless> ah
<lifeless> ok account me up
<lifeless> we should have openid sometime soon
<StevenK> lifeless: I've added the ACLs, now how do I actually create an account for you?
<lifeless> depends
<lifeless> oh, you've made a warthogs user already ?
<StevenK> Yes
<lifeless> has it got write?
<StevenK> No, but it can
<StevenK> lifeless: You just want to use warthogs?
<lifeless> ok, I can login as that
<lifeless> yeah, why not.. simples
<StevenK> lifeless: Okay, you should be able to configure parellel-test
<lifeless> yea
<StevenK> lifeless: You can turn off IRC notification if you wish, but e-mail notification isn't set up
<lifeless> running a test build
<StevenK> Hm, that should start another executor, not block on devel
<StevenK> Ah, there it is
<StevenK> Bleh, how are people landing things when PQM tells me we're in testfix?
<lifeless> StevenK: failures?
<StevenK> lifeless: On db-devel
<lifeless> right
<lifeless> file a bug :)
<StevenK> And the failures look strange
<lifeless> a librarian process is probably still runnning
<lifeless> *or* was interrupted so violently that the pid wasn't removed.
<lifeless> we need to figure out which
<lifeless> and file a bug to prevent it happening again
<wgrant> Whoops.
<StevenK> Yes, I thought so too, so I suspect the next step is stab buildbot?
<wgrant> 2400 line branch.
<lifeless> StevenK: no
<lifeless> we should never stab
<lifeless> we should analyse the cause
<lifeless> gather data
<lifeless> and make sure we have enough info to fix
<StevenK> lifeless: Even when the failure is 'slave lost'? :-)
<lifeless> *then* stab
<lifeless> StevenK: yes.
<lifeless> why was it lost?
<lifeless> where did it go?
<lifeless> what happened? was it manually rebooted? did the machine crash?
<StevenK> slave lost is usually buildbot going gaga
<lifeless> its the lack of analysis and debugging that has us in this situation.
<StevenK> (Cough, hudson)
<lifeless> right
<StevenK> Speaking of, there's a new one, apparently
<lifeless> but we'll have issues with hudson that need similar care and detailed attention to fix, too.
<LPCIBot> Project parallel-test build (1): FAILURE in 26 min: https://hudson.wedontsleep.org/job/parallel-test/1/
<LPCIBot> Project parallel-test build (2): STILL FAILING in 1 min 39 sec: https://hudson.wedontsleep.org/job/parallel-test/2/
<lifeless> StevenK: can you kill the executor ?
<StevenK> lifeless: Done
<StevenK> lifeless: Just thinking about it, I didn't think anyone had access to the buildbot slaves?
<lifeless> they don't
<lifeless> so someone needs to work with the losas to diagnose.
<lifeless> its way past EOD for me, but I'll swing my irc every hour or two till I sleep
<StevenK> So, spm is off sick, and Tom turns up in ~ 2 hours, and I have branches to land. :-(
<lifeless> ugh
<lifeless> you could ask a gsa
<lifeless> but its really important to understand whats gone on.
<StevenK> I don't know enough about the buildbot infrastructure to know which machines are involved
 * StevenK will wait for Tom
<lifeless> anyhow, I'm off for a while
<lifeless> jml: I've asked for your review on this parallel tests branch; to help you I reviewed all the testtools MP's.
<poolie> hello jml, StevenK
<poolie> lifeless: that's great new about parallelization
<StevenK> poolie: Hi
<jml> lifeless: I'm sorry to hear about list-tests.
<jml> lifeless: and thanks for the reviews, I'll look at your parallel tests branch soon.
<StevenK> Hm, that's odd.
<StevenK> Looks like a stale pid file
<adeuring> good morning
<mrevell> Hello
<lifeless> poolie: thanks, yes.
<lifeless> jml: \o/
<lifeless> jml: yeah to get a listing its --list-tests --subunit | subunit-ls, which is a bit grotty
<jml> lifeless: oh, I think what I did there is deleted our own hack in favour of the upstream support... iirc.
<jml> gotta run, late for an appointment
<lifeless> ciao
<LPCIBot> Project parallel-test build (3): STILL FAILING in 2 hr 4 min: https://hudson.wedontsleep.org/job/parallel-test/3/
<wgrant> bigjools: You're not particularly attached to lucilleconfig, are you?
<bigjools> wgrant: I'm not sure which part of "must die in fire" was ambiguous, no.
<StevenK> Haha
<wgrant> bigjools: Well, I accidentally slipped and deleted it today.
<bigjools> that's quite a slip
<wgrant> 2400 lines or so.
<bigjools> !
<wgrant> Although some of that is a sampledata rebuild.
 * bigjools otp
<lifeless> hahah https://hudson.wedontsleep.org/job/parallel-test/3/testReport/?
<lifeless> *boom*
<lifeless> and meh, something did a 'print' and mangled the stream
<lifeless> I'll look more closely monday.
<poolie> jml, i just added http://pastebin.ubuntu.com/513690/ to my dkim tree
<poolie> is that a better explanation?
<bigjools> it feels like we've been in testfix mode for a week
<bigjools> oh wait ...
<wgrant> bigjools: Could you please grab Ubuntu's lucilleconfig from staging?
<wgrant> Just need to check that it's within archivepublisher.root
<wgrant> Since that's what the new code uses.
<bigjools> wgrant: what are you replacing lucilleconfig with?
<wgrant> bigjools: distroseries.lucilleconfig is now calculated from ComponentSelection.
<bigjools> http://pastebin.ubuntu.com/513712/
<wgrant> distribution.lucilleconfig's paths are calculated from archivepublisher.root, like we already do for !primary.
<wgrant> Aha, thanks.
<wgrant> And stayofexecution should be a new config key.
<wgrant> But right now is hardcoded.
 * wgrant digs out the prod configs.
<poolie> inability to remove hardcoded sample data is another thing that's wrong with doctest :/
<poolie> s//difficulty of
<bigjools> poolie: I think we need more reasons to hate doctest, there's not enough :)
<poolie> perhaps at the 2012 epic it can be burned in effigy
<wgrant> What is the purpose of the 2011 Epic?
<poolie> saying "god that's fast"
<StevenK> wgrant: To laugt at you.
<StevenK> *laugh
<wgrant> :(
<poolie> and when stevenk laughs at you, you stay laughed :}
<bigjools> yet somehow we're laughing at StevenK
<bigjools> poolie: rofl
<wgrant> bigjools: So my change is compatible with production's primary archive setup.
<wgrant> And it aligns it with the way PPA/partner/debug/copy has been done forever.
<bigjools> good
<wgrant> And it removes those goddamn text ini columns.
<bigjools> \o/
<wgrant> I mean, there are some strange bits of Soyuz.
<wgrant> But that just sort of wins.
<bigjools> wgrant: http://imagebin.ca/view/gayZQ1G.html
<bigjools> fun :)
<wgrant> bigjools: That is a pretty picture
<wgrant> But why was utilisation so low towards the end of the low-resource period?
<LPCIBot> Project devel build (111): STILL FAILING in 4 hr 4 min: https://hudson.wedontsleep.org/job/devel/111/
<bigjools> wgrant: different arches
<bigjools> there were a load of amd64 builds queued up and nothing else
<wgrant> bigjools: Oh, right, forgot that.
<bigjools> the graph is good because it's telling us we can share arches
<bigjools> we just need to do the work for that
<wgrant> Well, we could if it didn't break out build time estimation algorithm, somewhat ironically.
<bigjools> indeed
<bigjools> queuing theory...
<bigjools> I hear there's been a bit of research in that area
<wgrant> We could also just declare that dispatch time estimates are too inaccurate and drop them.
<wgrant> That is very tempting.
<wgrant> bigjools: P[P3]As never publish outside main, do they?
<bigjools> wgrant: they're not *supposed* to :)
<wgrant> Even the security one?
<bigjools> yes
<wgrant> bigjools: I'm wondering why we don't restrict the PPA publisher to main.
<wgrant> Like we restrict the partner one to partner.
<bigjools> hysterical raisins
 * wgrant might fix that later, then, now the code is not nauseating.
<wgrant> Ah, yeah, all pubs are overridden to main during creation, so it should be impossible for them to be anywhere else.
<bigjools> we used to publish all components if you remember
<wgrant> I do indeed.
<bigjools> then it was decided that we should simplify it
<bigjools> which was a superb idea
<wgrant> I was really wondering if you knew a reason that the restriction wasn't added then.
<bigjools> I guess nobody thought to do it
<bigjools> I am going to have to fix that double-copy bug - the errors are mounting in the publisher log :/
<bigjools> not to mention a bunch of PoolFileOverwriteError which I can't remember why is happening
<wgrant> The PFOEs were meant to all be fixed.
<wgrant> But I saw some last week.
<wgrant> We must have a new bug.
<bigjools> yes
<wgrant> mthaddon: Did you intentionally not enable natty/armel PPA support?
<mthaddon> wgrant: not intentionally - I just did what I was asked  - bigjools, is that something we'd want to do?
<bigjools> mthaddon: I think so, yes.
<wgrant> Ah, NRCP is wrong.
 * wgrant fixes.
<mthaddon> bigjools: do we need to check with someone?
<bigjools> mthaddon: I'd say lamont but he's not around this week
<bigjools> so whoever is covering him?
<wgrant> It's already enabled for all the old series.
<mthaddon> let me check
<bigjools> ffs, landing one branch worked then the other gets caught by testfix mode
<wgrant> bigjools: See, you should use EC2. It forces you to get used to frequent arbitrary rejections :)
<bigjools> haha
 * bigjools goes to get caffeine
<wgrant> My average success rate in the last three weeks is below 10%.
<elmo> bigjools: sorry, what would lamont be able to tell us?
<bigjools> elmo: whether to enable natty/armel for PPAs
<bigjools> given armel's enabled for the other series (restricted to certain PPAs of course)
<elmo> well, that's why we're not enabling it - it's not clear to me how the restriction works and whether it's automatically carried over
<elmo> I was hoping you would know
<bigjools> elmo: it's carried over - the restriction is based on the ProcessorFamily only
<elmo> mthaddon: ^-- go ahead and enable arm too
<mthaddon> ok
<mthaddon> bigjools: erm, where would I do that?
<bigjools> mthaddon: same as the ones you already did, just for natty/armel/+admin
<mthaddon> doh
<mthaddon> bigjools, elmo: I take it not "Official Support", just "PPA Support Enabled"?
<bigjools> yup
<mthaddon> ok, done
<wgrant> Thanks.
<wgrant> bigjools: We have actually changed it. It's always been 5 days in the code, and 1 day in production.
<wgrant> I guess I could change it to 1 day everywhere.
<wgrant> (I'm not sure when the production change happened)
<bigjools> wgrant: I don't recall it changing so it's been there a while
<bigjools> and changing config is as painful as changing code, so code it and reduce complexity
<wgrant> Yep.
<wgrant> Thanks.
<bigjools> jml: around?
<jml> bigjools: yes
<bigjools> jml: I've started hacking up the shutdown but I could do with a little help on testing!
<bigjools> http://pastebin.ubuntu.com/513776/
<bigjools> jml: we don't need that addSystemEventTrigger since this is a Service ... heh
<deryck> Morning, all.
<jml> deryck: hi
<jml> bigjools: ok. all yours.
<bigjools> jml: how sweet :)
<jml> bigjools: testing reactor shutdown is unsupported, pretty much
<jml> bigjools: I reckon the best thing to do here is call stopService in your tests directly
<bigjools> jml: there's aleady one that does that - well, see testBuilddManagerRuns
<jml> it's not in your diff
<bigjools> but I've no idea if my stopService is being called or not
<bigjools> jml: it's already there
<jml> bigjools: ahh, ok.
<bigjools> starts up via the tac
<bigjools> and then shuts down
<jml> I need to page more stuff in before I confuse myself or you any further
<jml> (also, a pox on London traffic)
<bigjools> s/London/UK/
<jml> well, I'm not learning to drive in the bits of the UK that aren't in London
<jml> bigjools: ok, I think I've got this figured.
<jml> bigjools: BuilddManager is a Service, so you don't need to do the manual reactor.addSystemEventTrigger
<bigjools> jml: I know that bit, I said above :)
<bigjools> forgot to remove it from the diff
<jml> oh ok
<jml> I'm looking at the tip of your branch
<bigjools> not push
<bigjools> ed
<bigjools> hang on
<jml> bigjools: there's no really good way of checking that stopService is called when the reactor is shut down... Twisted makes that promise any way
<bigjools> jml: pushed.  Does the shutdown code look sane though?  I'm just making it wait on all the LoopingCall.start() deferreds that fire when stop() is called.
<jml> bigjools: yeah. it's good. looks correct too :)
<jml> bigjools: I'd probably just keep the return values of startCycle and scheduleScan rather than making a new property on SlaveScanner and NewBuildersScanner, but ymmv
<bigjools> possible, but it's more hassle in the manager
<bigjools> (class)
<jml> yeah. it's a trade-off, more state in the manager vs unnecessary fattening of interfaces
<jml> I don't think either is clearly better
<bigjools> me neither
<bigjools> my main question to you was the sanity of doing that - I think it's ok, but I need to test it on DF to get a better idea.  But DF is down for another day.
<jml> it's completely sane
<bigjools> great
<bigjools> now, I need to go out and get a new photo for my driving licence, for which I am privileged to offer the government 20 of my hard-earned pounds.
<salgado> StevenK, around?
<StevenK> salgado: Barely
<salgado> StevenK, on r11710 you've added a initialisedistroseries section to configs/development/launchpad-lazr.conf but I don't seem to have a matching section in schema-lazr.conf, which causes a trunk branch to fail to build
<StevenK> Eeep
<salgado> StevenK, if you're quick, even buildbot won't notice it. ;)
<StevenK> salgado: Yeah, I'm putting together a branch now
<salgado> cool!
<StevenK> salgado: https://code.edge.launchpad.net/~stevenk/launchpad/fix-idsjob-schema/+merge/38536
<salgado> StevenK, taking ages to update the diff.  can you paste it somewhere?
<StevenK> salgado: http://paste.ubuntu.com/513849/
<mars> StevenK, any luck with the hudson builder fixes?
<StevenK> mars: https://code.edge.launchpad.net/~stevenk/launchpad/test-thread-debug/+merge/38510
<mars> StevenK, great, so that solves the two code hosting threads issue, which is encouraging for solving the windmill issue as well
<StevenK> mars: Yeah, I just don't know where to start with the windmill ones
<mars> StevenK, or does it happen to fix the windmill issue too?
<mars> StevenK, it would if an errant puller was also running in the windmill suite.  I guess your Hudson builder will tell us if it worked?
<StevenK> mars: I've been using ec2 to diagnose if it was fixed, and 2 windmill tests still failed
<mars> argh, ok.  one can always hope :)
<LPCIBot> Project devel build (112): STILL FAILING in 3 hr 40 min: https://hudson.wedontsleep.org/job/devel/112/
<LPCIBot> Launchpad Patch Queue Manager: [r=lifeless][ui=none][no-qa] Create a cancel_on_timeout() helper that
<LPCIBot> cancels Twisted Deferreds after a configurable timeout.
<LPCIBot> Project devel build (113): STILL FAILING in 1 min 14 sec: https://hudson.wedontsleep.org/job/devel/113/
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=608621] Add a cronscript for
<LPCIBot> InitialiseDistroSeriesJobs.
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=608621] Allow parameters to be passed to
<LPCIBot> InitialiseDistroSeriesJobs.
<LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=659129] Prevent the /ubuntu/+ppas page from
<LPCIBot> timing out by fixing a slow query that PG8.4 hates.
<StevenK> salgado: Haha. buildbot may not have noticed, but Hudson did
<abentley> jam: ping
<jam> morning abentley
<abentley> morning, jam.  thumper suggested I should talk to you about history-db.
<jam> sure
<abentley> jam, are you up for a Skype or Mumble conversation?
<jam> sure, in just a bit
<abentley> jam: cool.
<allenap> bigjools: Your landing to db-devel "Prevent the /ubuntu/+ppas page from timing out by fixing a slow query that PG8.4 hates", is that safe to land in devel?
<bigjools> allenap: yes
<bigjools> I landed it on db-devel by mistake, so I also landed it on devel
<allenap> bigjools: Cool, 'cause it will be soon owing to my mistake.
<bigjools> :)
<allenap> bigjools: Oh, so it's already there. Even better.
<bigjools> jml: hello, can I again bounce something off you for a sanity check?
<jml> bigjools: sure
<bigjools> jml: thanks.  See _update_builder_status in builder.py
<bigjools> it's called from updateBuilderStatus
<bigjools> I want to ditch _update_builder_status and make updateBuilderStatus call builder.rescueIfLost
<bigjools> ie, not trap errors there any more
<bigjools> then we can allow the failure to hit the manager code which will look at failure counts
<jml> bigjools: i.e. completely ditch the rescue_failed errback?
<bigjools> jml: yes
<jml> bigjools: I think that's a great idea
<bigjools> I want to move all the failure handling code to the manager
<bigjools> cool, thanks jml
<jml> fwiw, for similar-ish things, it sometimes makes sense to distinguish between "expected errors" and, well, errors that should be in OOPS reports
<bigjools> yeah - eventually that's what I want to do in _scanFailed
<bigjools> hence the list of trapped exceptions
<jml> cool
<jml> I reckon that will make the code much more readable.
<bigjools> jml: I'm also temptedto remove handleTimeout
<jml> hmm.
<bigjools> it does one of two things:
<jml> I'm looking at it :)
<bigjools> 1. if the builder is virtual it immediately tries to reset it.  That's wasteful, because the exact same thing will happen again when the next job comes along
<jam> abentley: want to do the call now? Skype works best for me
<bigjools> 2. for a non-virt builder it just fails it immediately
<bigjools> both of these actions are undesirable
<jml> that sounds reasonable
<jml> also, it doesn't seem like 'timeout' is any different from any other unexpected error
<bigjools> indeed
<bigjools> another thing I want to do is allow more slack for failing builders - sometimes they come back after 4-5 attempts to contact
<bigjools> but that becomes trivial once all the errors are handled in _scanFailed
<jml> message-oriented programming yay
<bigjools> I'd prefer massage-oriented
<jml> :D
<bigjools> jml: one more thing - I am thinking of adding transaction.abort() as the first line of code in _scanFailed(), what do you think?
<bigjools> I reckon in the past we've had problems with data corruption where half of the previous failure was committed with the subsequent successful dispatch
<jml> bigjools: I think until all of the transaction management is done outside of manager.py it's all pretty much rearranging deck chairs. it seems like a not-unreasonable paranoid step.
<jml> bigjools: it would be better if you had a test that reproduced one of those problems
<bigjools> jml: FWIW I think *all* txns should be done in the manager, but we can't realistically do that for everything
<bigjools> yes, a test :)
<jml> well, the manager could conceivably be written so as to only talk to the db via the webservice or XML-RPC. But even before that wire-level change was made, there could be an object that's solely responsible for mutating db state separate from the object that's responsible for coordinating the whole thing. I think such a separation would make the txn business much more transparent.
<EdwinGrubbs> StevenK: I'm getting this error locally.  lazr.config.interfaces.ConfigErrors: ConfigErrors: schema-lazr.conf does not have a initialisedistroseries section.
<gmb> EdwinGrubbs, StevenK: I'm getting the same error in EC2
<bigjools> jml: that's another way of looking at it, yeah.
<bigjools> jml: http://pastebin.ubuntu.com/513924/
<EdwinGrubbs> gmb: I think we just need to remove that section from configs/development/launchpad-lazr.conf until it is added to lib/canonical/config/schama-lazr.conf
<gmb> EdwinGrubbs: Agreed. Can you work up a branch for that and I'll review it?
<gmb> I'm right in the middle of some hairy test changes.
<EdwinGrubbs> gmb: sure
<jml> bigjools: why not delete updateBuilderStatus altogether and just call builder.rescueIfLost directly?
<bigjools> jml: eventually - but some other shit needs it split out (can't remember what offhand)
<jml> bigjools: if you say so, but as best as I can judge here all updateBuilderStatus is adding is an optional log message
<jml> otherwise, looks good.
<gmb> EdwinGrubbs: Thanks.
<bigjools> jml: heh, MockBuilder is using it
<bigjools> updateBuilderStatus is also an utterly crap name
<bigjools> jml: so.......I think the coding is done.  (except the minor cleanups)
<jml> bigjools: awesome
<sinzui> Someone broke devel. the config uses initialisedistroseries but that is not defined in the schema
<bigjools> sinzui: sounds like StevenK's change :/
<bigjools> but I know he used ec2, so ...
<jml> bigjools: can you post it up for review? I won't be able to do a line-by-line, but I'd like a chance to see how it's all come together before it lands.
 * sinzui knows
<bigjools> jml: sure thing.  I'm just going to prune the XXXes that are done
<jml> bigjools: cool.
<bigjools> 12 left!
<sinzui> bigjools, the section was added to a config, but the testrunner does not use that config.
<jml> fwiw, I'm making the twisted/testtools thing I'm doing as rock-solid as I can.
<sinzui> bigjools, I have a branch I want to land. I will have a patch in a few mintues
<bigjools> sinzui: ha.
<bigjools> ok thanks sinzui
<sinzui> Edwin ping
<sinzui> EdwinGrubbs ping
<sinzui> EdwinGrubbs, We can add the section to the schema just as easily as removing it. Are you landing directly to PQM?
<LPCIBot> Project db-devel build (68): STILL FAILING in 4 hr 8 min: https://hudson.wedontsleep.org/job/db-devel/68/
<LPCIBot> Project devel build (114): STILL FAILING in 24 min: https://hudson.wedontsleep.org/job/devel/114/
<EdwinGrubbs> sinzui: gmb was going to review it first. I'm actually looking into adding it to the schema now, although I am surprisingly getting errors.
<sinzui> Edwin, this does not work http://pastebin.ubuntu.com/513935/ when added to the schema?
<sinzui> it works for me
<EdwinGrubbs> sinzui: well, it breaks the cronscript, because it doesn't have a dbuser, but that really shouldn't be my concern, since the tests are so weak, they don't detect that.
<sinzui> EdwinGrubbs, yes, and I do not think that error dir path is in production
<sinzui> EdwinGrubbs, are you submitting directly to PQM?
<bigjools> jml: https://code.edge.launchpad.net/~julian-edwards/launchpad/builderslave-resume/+merge/36351
<bigjools> it'll update with a bit more in 5 mins
<jml> bigjools: ta
<bigjools> jml: I'm confused since I landed the cancel_on_timeout stuff separately but it's conflicting.  It's the same damn revision, so why!
<sinzui> EdwinGrubbs,  this was my test to verify the config is sane: ./bin/test -vvc --layer=Unit -t test_config
<jml> bigjools: I can wave my hands and say criss-cross merges
<bigjools> heh
<bigjools> fixing it ....
<EdwinGrubbs> sinzui: I was going to get a review first, although I'm basically copying your section.
<bigjools> jml: --lca DTRT FWIW.  (that's a lot of acronyms)
<jml> ten four
<bigjools> It's a shame I don't get karma per line of diff
<EdwinGrubbs> sinzui, gmb: here is my mp to fix the config error if either of you want to review it.
<sinzui> bigjools, I would win in that case, and I already have a ridiculous amount
 * bigjools bows to the new overlord, sinzui
<sinzui> I like the sound of overlord.
<bigjools> it fits well with your green nail polish
<sinzui> One day I will be the god-emperor overload of the Earth, The Universe, and Canada
<mars> \o/
<gmb> EdwinGrubbs: r=me.
<jml> bloody internet crap
<bigjools> ooo I just noticed that the merge page groups commits that were pushed at the same time
<sinzui> mars, I think Canada is behind global warming. The transcontinental railroad is a dissatisfying hack to get to the Pacific. Canada really wants a NorthWest passage and it can have it when the Arctic ice cap is gone.
<mars> sinzui, alas, our true intentions became known at Copenhagen.  Why else would we start a war with Denmark over a miserable piece of arctic rock off the coast of Ellesmere Island?  Someone will have to put a lighthouse on it, and the Danes just wouldn't paint it the right colour.
<deryck> abentley, hi.  maybe you can help me.  I pushed a branch for review with bzr lp-propose-merge.  I did this branch as a pipe and the plugin made my early pipe a pre-requisite in the MP...
<sinzui> :))
<deryck> abentley, is there a way to edit the MP and drop the pre-req?
<bigjools> jml: there;s one more thing we didn't get around to fixing - an async getFile()
<bigjools> I should probably do that now since it will have the biggest effect on concurrent performance of any of the changes :)
 * jml looks
<jml> oh right
<jml> if you don't care about streaming data, then t.web.client.getPage is probably enough.
<abentley> deryck: no, you need to create a new merge proposal.
<deryck> abentley, ok, thanks.
<abentley> deryck: why was your early pipe not a suitable prerequisite branch?
<bigjools> jml: didn't we try and use that elsewhere and had issues?
<jml> bigjools: that was a different branch, I think
<bigjools> jml: maybe  - it's all a blur :)
<deryck> abentley, because I wanted all revs from the start of the work in the diff for review.  Using the prev pipe as a pre-req, only the changes in the current pipe were listed in the diff for review.
<salgado> Edwin-afk, StevenK has already fixed the problem you've reported on launchpad-dev@
<abentley> deryck: ah.  The design assumes that you will want to submit each pipe for review separately.
<deryck> abentley, right.  and in my case, I did some work (not submitted) then created new pipes to break up the work.
<abentley> deryck: so you still have the unsubmitted work in the first pipe?
<deryck> sort of.
<deryck> had branch 1, did work which amounted to a bunch of test refactors, saw the diff was getting long, add-pipe to submit it as it's own branch, then back to first pipe to keep working while that gets approved.
<deryck> but I did a couple small fixes in the second pipe to prep for review, which ended up being all that was up for review when the first branch was listed as a pre-req.
 * jml opens up buildout.txt again
<jml> what do I have to do to get "python setup.py egg_info -r -bDEV sdist" to work. Currently getting "error: invalid command 'egg_info'"
<abentley> jam: ping
<jam> hey abentley
<abentley> jam: when would you like to chat?
<jam> now would be ok
<jam> I tried earlier, not sure if you missed my ping
<abentley> jam: I guess I did.  Sorry.
<jam> anyway, skype works best for me, if that is ok
<bigjools> jml: I am thinking "separate branch" for the async getFile - the rabbit hole goes deep again
<bigjools> jml: so go ahead, I won't make any more changes to that branch now
<jml> bigjools: ok. I might defer it until Monday, actually.
<bigjools> jml: defer - heh
<jml> hmm.
<jml> I should probably bump up the default timeout on the testtools twisted support
<jml> 0.005s isn't really going to work for Launchpad
<jml> the good news is that in substance it seems to work
<bigjools> I dunno whether to laugh or cry
<abentley> jam: https://dev.launchpad.net/Code/BranchRevisions
<bigjools> EdwinGrubbs: regarding your email to -dev about the config error, did you see that another branch landed 30 minutes later that adds the schema-lazr stuff?
<jml> g'night all
<rockstar> abentley, does anything use the storm Sugar class?
<abentley> rockstar: I don't know.
<rockstar> abentley, didn't you write it?
<abentley> rockstar: yes.
<rockstar> abentley, did you write it with a specific class in mind?
<abentley> rockstar: well, it was meant to be used with all classes.
<rockstar> abentley, okay, so we're supposed to be moving towards it?
<abentley> rockstar: I dunno.  No one else really got behind it.
<rockstar> abentley, yeah, that's what it looks like.
<LPCIBot> Project devel build (115): STILL FAILING in 3 hr 45 min: https://hudson.wedontsleep.org/job/devel/115/
<LPCIBot> Launchpad Patch Queue Manager: [r=salgado][ui=none][no-qa] Add the initialisedistroseries section to
<LPCIBot> the LAZR schema.
<jam> mwhudson: if you're awake and online, I just pushed up what I think is a successful layer setting up the forking service at the same time as the ssh twisted daemon
<jam> I'd like to discuss one aspect, though.
<wgrant> What is the state of ec2? I had six failures overnight.
<lifeless> jml: hah. I tried to create an mp, the form hadn't submitted.
<jam> wgrant: clearly the state is that it has 6 failures... :)
<wgrant> jam: Well, given that it had at least six very different failure modes over the course of last week, I'm not sure that's a valid assumption.
<lifeless> jml: https://code.edge.launchpad.net/~lifeless/launchpad/paralleltests/+merge/38594 if you'd like to stash an approve vote for the toolchains delight
<barry> lifeless: didn't we talk about problems pushing/pulling looms from lp?
<jam> abentley: you still around?
<lifeless> barry: there was a mail thread about it
<lifeless> barry: where I said roughly 'update looms to use the newer bzrlib api I wrote for it'
<barry> lifeless: yeah, i'd forgotten where we discussed this, and couldn't find a bug on it.  (it's still broken).  i suppose i should file a bug, but where?  launchpad-code?  bzr?
<wgrant> How are people landing stuff? Or is ec2 only broken for me?
<benji> wgrant: broken like this https://pastebin.canonical.com/37924/ ?
<wgrant> benji: EPERM
<mars> wgrant, <Thread(Thread-18, started daemon 47570760992528)> ?
<wgrant> In test_network?
<mars> wgrant, in lp.codehosting.puller.tests.test_worker.TestWorkerProgressReporting.test_network
<wgrant> Yeah, that one.
<mars> wgrant, stevenk has a fix in devel
<wgrant> I know that's known to be broken, and there is a branch that fixes it... but stuff seems to still be landing.
<mars> looking for  alinnk
<wgrant> Is it actually in devel yet?
<wgrant> I didn't see it fly past.
<mars> wgrant, https://code.edge.launchpad.net/~stevenk/launchpad/test-thread-debug/+merge/38510
<mars> wgrant, you may still get windmill errors though.  And the consensus is to ignore the lot and us bzr lp-land
<wgrant> mars: ah, so it has landed.
<wgrant> Thanks.
<mars> np
<wgrant> In that case, could someone please try to ec2 https://code.edge.launchpad.net/~wgrant/launchpad/bug-629921-packages-empty-filter/+merge/37339, https://code.edge.launchpad.net/~wgrant/launchpad/bug-655648-a-f-maverick/+merge/37820, https://code.edge.launchpad.net/~wgrant/launchpad/better-publisher-index-tests/+merge/38462 and https://code.edge.launchpad.net/~wgrant/launchpad/bug-661109-buildable-architectures/+merge/38529?
<LPCIBot> Project db-devel build (69): STILL FAILING in 4 hr 8 min: https://hudson.wedontsleep.org/job/db-devel/69/
<LPCIBot> Project devel build (116): STILL FAILING in 3 hr 41 min: https://hudson.wedontsleep.org/job/devel/116/
<LPCIBot> * Launchpad Patch Queue Manager: [r=sinzui][ui=none][bug=none] Removing redundant config section.
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][no-qa] Fix single-line glob imports in doctests.
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=none] Fixed ConfigError: schema-lazr.conf does
<LPCIBot> not have a initialisedistroseries section.
<LPCIBot> * Launchpad Patch Queue Manager: [r=sinzui][ui=none][bug=652315] Adds nofollow,
<LPCIBot> noindex to unknown code page for products.
<LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][no-qa] Use FixedHttpServer in the branch
<LPCIBot> puller's test_worker.
<wgrant> Down to a single failure. Yay.
<lifeless> barry: bzr-loom + udd
#launchpad-dev 2010-10-16
<barry> lifeless: bug 661508
<_mup_> Bug #661508: code hosting doesn't handle looms <Loom:New> <Launchpad Bazaar Integration:New> <Ubuntu Distributed Development:New> <https://launchpad.net/bugs/661508>
<LPCIBot> Project db-devel build (70): STILL FAILING in 3 hr 45 min: https://hudson.wedontsleep.org/job/db-devel/70/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11707,
<LPCIBot> 11708, 11709 included.
<LPCIBot> Project devel build (117): STILL FAILING in 3 hr 40 min: https://hudson.wedontsleep.org/job/devel/117/
<LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=652134] Updates imported branches on
<LPCIBot> products to display upstream information and present as
<LPCIBot> EXTERNAL codehosting_usage.
<LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=655567] Merge
<LPCIBot> wire-up-filter-subs-bug-655567 into devel.
<LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=652142] Fixes the message displayed to
<LPCIBot> users on product code pages with no branches;
<LPCIBot> previously users without configuration rights were told they could set
<LPCIBot> things up when they couldn't.
<LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=660873] The BugzillaAPI and LPPlugin
<LPCIBot> ExternalBugTrackers will no longer OOPS when a Bugzilla doesn't
<LPCIBot> return an alias for a bug.
<LPCIBot> * Launchpad Patch Queue Manager: [r=bac][ui=none][bug=660628] Make update-image work smoothly on Lucid
<LPCIBot> Project db-devel build (71): STILL FAILING in 3 hr 50 min: https://hudson.wedontsleep.org/job/db-devel/71/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11710,
<LPCIBot> 11711, 11712, 11713, 11714 included.
<cody-somerville> What do folks think of function annotations in Python?
<LPCIBot> Project db-devel build (72): STILL FAILING in 1 hr 30 min: https://hudson.wedontsleep.org/job/db-devel/72/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11715,
<LPCIBot> 11716, 11717, 11718, 11719, 11720 included.
<lifeless> cody-somerville: what do you mean?
<cody-somerville> lifeless, Simply curious what folks think about it and its potential future use in the Launchpad codebase
<lifeless> cody-somerville: I mean, 'what do you mean by 'function annotations in python'
<lifeless> cody-somerville: I parsed the rest of the sentence ok :)
<lifeless> but I can think of,oh, 3? more? things you could mean by function annotations in python
<cody-somerville> I'm referring to PEP 3107, http://www.python.org/dev/peps/pep-3107/
<lifeless> oh
<lifeless> world of pain
<nigelb> heh
<jml> not having to worry about backwards compatibility is a beautiful thing
 * wgrant looks around for someone to EC2 four branches.
<jml> wgrant: hi
<wgrant> jml: The first four on https://code.edge.launchpad.net/~wgrant/launchpad/+activereviews, if you could.
<wgrant> The first has failed eight times now... so if it doesn't work this time, it surely must the next.
<jml> :)
<jml> wgrant: wheels are in motion, I'll let you know when they've all detached.
<wgrant> jml: Thanks.
<wgrant> Hopefully it won't hit that Windmill thread leak.
<jml> wgrant: if it's just that, I'll submit directly to PQM
<jml> two are running, two failed to initialize properly, restarting those
<jml> also, I don't know how I'd live without XXX comments
<wgrant> Oh?
<jml> whenever I'm writing code, I think of things it could do, problems it has and paths that I'm not sure about
<jml> I could either stare and dither for a while, or I could write a XXX comment and get on with it
<wgrant> Ah, yes.
<jml> turns a stack of interrupts into a queue
<wgrant> I thought you were complaining about my branches.
<jml> no, not at all
<jml> I'm sneaking in some naughty work on my twisted testing support for testtools
<jml> but now I'm going
<wgrant> Heh.
<wgrant> Thanks for sending those off.
<jml> np
<LPCIBot> Project devel build (118): STILL FAILING in 4 hr 12 min: https://hudson.wedontsleep.org/job/devel/118/
<lifeless> jml: ping
<LPCIBot> Project db-devel build (73): STILL FAILING in 4 hr 12 min: https://hudson.wedontsleep.org/job/db-devel/73/
<LPCIBot> Project devel build (119): STILL FAILING in 3 hr 45 min: https://hudson.wedontsleep.org/job/devel/119/
<LPCIBot> * Launchpad Patch Queue Manager: [r=bac][ui=none][no-qa] Start de-duplicating the apt-ftparchive and
<LPCIBot> native publishing tests, and add more thorough index generation tests.
<LPCIBot> * Launchpad Patch Queue Manager: [r=bac,
<LPCIBot> stevenk][ui=none][bug=655648] test_ftparchive now works on maverick.
<LPCIBot> - Landed by bac.
<LPCIBot> * Launchpad Patch Queue Manager: [r=henninge][ui=none][bug=629921] Treat an empty PPA package name
<LPCIBot> filter as if it were absent. - Landed by henninge.
<LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=653122] BugSubscriptionSubscribeSelfView is
<LPCIBot> now a LaunchpadFormView.
<wgrant> jml: Thanks.
<wgrant> jml: That testrunner failed without any failed tests thing just seems to appear sometimes.
<lifeless> wgrant: is there a bug with a test run log file?
<LPCIBot> Project parallel-test build (4): STILL FAILING in 1 hr 58 min: https://hudson.wedontsleep.org/job/parallel-test/4/
<wgrant> lifeless: I don't know of one, but I may have missed it.
<lifeless> oh wwow
 * wgrant looks and files.
<lifeless> canonical.testing.layers.LayerIsolationError: App server died in this test (status=241):
<lifeless> lp.code.windmill.tests.test_branch_bugspeclinks.TestBranchBugLinks.test_inline_branch_bug_link_unlinkfirefox-bin: Fatal IO error 11 (Resource temporarily unavailable) on X server :99.0.
<wgrant> Nice.
<lifeless> WARNING: A test appears to be hung. There has been no output for 600 seconds.
<lifeless> Forcibly shutting down the test suite
<lifeless> Process group 6323 will be killed
<lifeless> Sending signal 15 to process group 6323
<lifeless> Sending signal 2 to process group 6323
<lifeless> Sending signal 1 to process group 6323
<lifeless> Sending signal 9 to process group 6323
<lifeless> Process group 6323 is now empty.
<wgrant> It gets violent quickly.
<lifeless> I'm going backwards
<wgrant> lifeless: Bug #661931
<_mup_> Bug #661931: make check sometimes fails on EC2 without test failures <Launchpad Foundations:New> <https://launchpad.net/bugs/661931>
<wgrant> Log attached.
<lifeless> wgrant: bb failure
<lifeless> wgrant: forwarded the bits to the list
<lifeless> wgrant: thanks for the bug
<wgrant> lifeless: The one that gmb just fixed by reverting his broken merge?
<lifeless> wgrant: ah, he must have reverted it after I ec2landed my branch ><
<wgrant> Yes, that one.
<wgrant> He replied to the thread an hour or so ago.
<wgrant> And it was reverted around 20 minuts ago.
<lifeless> blah
<lifeless> thanks
<jml> fwiw, the exit code checker in remote.py could be removed if it's not helpful
<jml> I kept it in there just in case
<wgrant> Ah, hi jml.
<wgrant> jml: Should I get that branch ec2'd again, or do we believe the subunit output?
<jml> wgrant: hi
<wgrant> One of the others that landed overnight had that same failure a couple of times last week.
<jml> wgrant: what does the subunit output say?
<wgrant> jml: No failures.
<jml> hmm.
<wgrant> Oh.
<wgrant> There is a LayerIsolationError.
<wgrant> I hate threads.
<jml> hatred leads to anger, anger leads to twisted, twisted leads to awesome
<wgrant> Heh.
<wgrant> http://paste.ubuntu.com/514687/ is the error. I wonder if the same one appeared last week
 * wgrant looks.
<lifeless> wgrant: what thread did gmb comment in?
<lifeless> wgrant: I canna see it
<jml> I wonder why it didn't get recorded as a failed test
<jml> wgrant: in any case, I'm too tired to judge sensibly about your branch.
<wgrant> lifeless: The buildbot failure at Sat, 16 Oct 2010 22:38:21 +0100
<wgrant> lifeless: The failure email and his reply went to both me and canonical-launchpad@l.c.c
<wgrant> His reply was slightly over an hour ago.
<jml> g'night guys
#launchpad-dev 2010-10-17
<wgrant> Night.
<wgrant> lifeless: Could you please send both the branches on https://code.edge.launchpad.net/~wgrant/launchpad/+activereviews off to ec2?
<lifeless> night jml
<lifeless> wgrant: url me up
<wgrant> lifeless: https://code.edge.launchpad.net/~wgrant/launchpad/bug-661109-buildable-architectures/+merge/38529 and https://code.edge.launchpad.net/~wgrant/launchpad/publisher-release-cleanup/+merge/38530
<lifeless> any special flags?
<wgrant> lifeless: The latter is incremental but has a bug of its own, so probably not.
<wgrant> Oh, hm, the bug might not be linked.
<wgrant> It is.
<lifeless> first one is spinning up now
<lifeless> â½
<lifeless> Traceback (most recent call last):
<lifeless>   File "bin/test", line 73, in <module>
<lifeless>     assert os.environ['STORM_CEXTENSIONS'] == '1'
<lifeless>   File "/usr/lib/python2.6/UserDict.py", line 22, in __getitem__
<lifeless>     raise KeyError(key)
<lifeless> KeyError: 'STORM_CEXTENSIONS'
<lifeless> funky
<lifeless> 9fixed)
<lifeless> -ugh-
<lifeless>   File "/home/robertc/launchpad/lp-branches/working/lib/canonical/ftests/pgsql.py", line 263, in tearDown
<lifeless>     self.dropDb()
<lifeless>   File "/home/robertc/launchpad/lp-branches/working/lib/canonical/ftests/pgsql.py", line 321, in dropDb
<lifeless>     cur.execute('VACUUM pg_catalog.pg_shdepend')
<lifeless>   File "/home/robertc/launchpad/lp-branches/working/lib/canonical/ftests/pgsql.py", line 108, in execute
<lifeless>     return self.real_cursor.execute(*args, **kwargs)
<lifeless> psycopg2.InternalError: right sibling's left-link doesn't match: block 260 links to 259 instead of expected 314 in index "pg_shdepend_depender_index"
<wgrant> ... pardon?
<wgrant> That's a new one.
<lifeless> data corruption in pg
<wgrant> Looks like it.
<wgrant> lifeless: Both branches are running reasonably happily now?
<lifeless> just started second one
<wgrant> Thanks.
<lifeless> and my pg is repaired.
<wgrant> By recreating everything?
<lifeless> no
<lifeless> you reindex pg_catalog.pg_shdepend in single user mode
<wgrant> Ah.
<lifeless> I had to lookup how to do single user mode in 8.4
<lifeless> command line changed :)
 * wgrant cleans up the next 6 branches.
<LPCIBot> Project devel build (120): STILL FAILING in 1 hr 33 min: https://hudson.wedontsleep.org/job/devel/120/
<lifeless> wgrant: hey
<lifeless> http://dev.launchpad.net/Contributions?action=diff&rev1=306&rev2=307
<lifeless> lists jcsackett as outside the lp team
<lifeless> this is bogus ;)
<LPCIBot> Project db-devel build (74): STILL FAILING in 4 hr 10 min: https://hudson.wedontsleep.org/job/db-devel/74/
<lifeless> likewise danilo, ian booth, and benji
<wgrant> lifeless: Yeah, and a few others.
 * wgrant fixes.
<lifeless> thanks
<lifeless> wgrant: is the script in the lp tree, that does that ?
<wgrant> lifeless: utilities/community-contributions.py
<wgrant> (kfogel used to run it on a cron job, but that obviously doesn't happen any more.)
<lifeless> oh, we should do that
<lifeless> should be easy to put it in a service account on dosium
<wgrant> lifeless: All looks reasonably sane now.
<wgrant> Missed one.
<wgrant> Curses.
<lifeless> :>
<lifeless> the sweet sound of deleted code vanishing
<wgrant> What are you eliminating?
<lifeless> ftests.harness
<wgrant> Aha.
<lifeless> I didn't mean to
<lifeless> but I needed to make LaunchpadTestSetup be used as an instance not a magical stateless beasite
<lifeless> and in the course of that I found only one user each of its subclasses
<lifeless> with those gone it was trivial to do stub's XXX and move LTS to layers.py
<wgrant> Heh.
<wgrant> lifeless: Thanks. Will you lp-land it?
<lifeless> already spinning up
<lifeless> my databasefixture branch (pushing now) has the cleanup I mentioned
<lifeless> pushed
<lifeless>  10 files changed, 106 insertions(+), 296 deletions(-)
<wgrant> Yay, both succeeded.
<wgrant> lifeless: Thanks.
<StevenK> You mean something actually passed ec2?
<StevenK> Dear ohloh, import faster.
<StevenK> It's doing 10k every 12 hours or so.
<wgrant> StevenK: It was sitting in a queue for most of yesterday.
<wgrant> It took more than a month the first time, but I think their bzr importer is better now.
<StevenK> Step 2 of 3: Importing source code into database (Running 31872/90554)
<StevenK> It has another 4 days, by my hand-wavy estimate.
<wgrant> deryck is still beating me by a few revs :(
<wgrant> And then I have to defeat henning to make it onto page 3.
<StevenK> I've lost count of mine
<wgrant> It's going to be hard to rise above jml, I fear.
<StevenK> Yes, but jml has been inactive for a while.
<lifeless> are both of these ignorable ?
<wgrant> Ah, I will pull ahead of deryck in about 10 minutes :P
<lifeless> lp.soyuz.windmill.tests.test_archive_packages.TestArchivePackagesSourcesExtra.test_sources_extra_available
<lifeless> and
<lifeless> lp.translations.windmill.tests.test_documentation_links.DocumentationLinksTest.test_documentation_links
<wgrant> lifeless: The latter I haven't seen before.
<lifeless> [<Thread(Thread-74, started daemon 47049195071248)>]
<lifeless> [<Thread(Thread-183, started daemon 47678012303120)>]
<wgrant> But the former has been happening for ages.
<lifeless> is it 'retoss at ec2'
<StevenK> That's the same symptom as the leak I fixed.
<lifeless> or direct to pqm time ?
<wgrant> lifeless: Which branch?
<lifeless> bzr+ssh://bazaar.launchpad.net/~lifeless/launchpad/paralleltest
<lifeless> bzr+ssh://bazaar.launchpad.net/~lifeless/launchpad/paralleltests
<wgrant> The first one is ignorable. I'd also be ignoring the second one, depending on what you changed.
<StevenK> But I'm bloody stumped if I want to print thread counts during every windmill test.
<wgrant> Mmm. Not sure.
<lifeless> I added a file
<lifeless> which nothing calls
<lifeless> and has a few unit tests of its own
<lifeless> and I bumped the fixtures dep
<wgrant> I'd run it again for safety, personally.
<StevenK> lifeless: Keep in mind that Hudson {db-,}devel tests fail with similar errors.
 * StevenK needs to pester mars again.
<wgrant> but I haven't seen the test_documentation_links one before.
<StevenK> wgrant: Go back through Hudson's history -- they keep changing.
<StevenK> test_worker was the only constant for a while.
<wgrant> Come on PQM... work faster.
<wgrant> How does it take half an hour to merge?
<StevenK> I've been wondering that myself.
<lifeless> bzr branch
<StevenK> Why doesn't it just merge directly from the remote branch?
<lifeless> its how long its taking to do a full clone
<lifeless> StevenK: because it runs the precommit checks in a chroot, assuming maximum hostility from the submitter
<StevenK> Yes, but we're only hostile towards PQM, not trunk.
<lifeless> I can think of a few ways to address it, including 'allow merges to fuck the repository'
<lifeless> but you asked why. thats why.
<lifeless> if the precommit checks didn't call bzr at all (which they certainly used to) we could use a lightweight checkout
<StevenK> lifeless: Out of curosity, what are the pre-commit checks doing? Just 'make'?
<wgrant> I presume it's no longer test_on_merge.py.
<lifeless> I don't have access to the pqm both these days (haven't for years)
<lifeless> so I can't answer that
<StevenK> lifeless: Okay, so what did it used to run?
<StevenK> Idle curosity is all, so I'm not after a definite answer.
<wgrant> Yay, PQM loves me.
<lifeless> well it used to do check-on-merge, uhm
<lifeless> it ran the tests obviously
<lifeless> but also checked lint for the commit, which needed a diff, which needs bzr history
<lifeless> another way we might be able to structure it is a http heavyweight checkout of the target branch with/stacked local branch stacked on the target.
<wgrant> lifeless: :( you added code to canonical.*
<lifeless> wgrant: and?
<lifeless> wgrant: I know that there's this big goal to nuke it
<lifeless> but I have very limited coding time.
<lifeless> Should I a):
<lifeless>  make the test suite 16 times faster
<lifeless> or b)
<lifeless>  move some code around to no practice difference
<lifeless> wgrant: or are you referring to testing.parallel? I guess that could be in lp.services.testing or wherever
<wgrant> lifeless: testing.parallel, yeah.
<wgrant> Altering existing code in there is fine IMO. But adding a new file there is probably bad.
<lifeless> shrug
<lifeless> can move it later
<lifeless> ideally that wouldn't exist at all, but I haven't had time to work on testrepository recently, nor am I sure that everyone uses testr
<lifeless> \o/ unique db names
<wgrant> Nice!
<wgrant> I will be very interested to see how this performs.
<lifeless> now, I need to glue the unique db names up to the config system
<lifeless> in process and out of process
<wgrant> Oh urrgh.
<wgrant> Out of process... hm...
<lifeless> in process should be easy once I figure out what layer the idiotic configs are read in
<lifeless> hmm
<lifeless> whups
<lifeless>  launchpad_ftest            | robertc  | UTF8     | C         | C     |
<lifeless>  launchpad_ftest_1099       | robertc  | UTF8     | C         | C     |
<lifeless>  launchpad_ftest_1470       | robertc  | UTF8     | C         | C     |
<lifeless>  launchpad_ftest_1579       | robertc  | UTF8     | C         | C     |
<lifeless>  launchpad_ftest_929        | robertc  | UTF8     | C         | C     |
<lifeless>  launchpad_ftest_978        | robertc  | UTF8     | C         | C     |
<lifeless> wgrant: do you happen to know the dead chicken for increasing a vm disk image size?
<wgrant> lifeless: libvirt?
<lifeless> http://wiki.libvirt.org/page/Tips#Increasing_the_disk_size_of_a_virtual_machine
<wgrant> If it's LVM it's easy. qcow2 I don't really know... I normally just create a new image and copy the data across.
<lifeless> which is odd, I've have expected to be able to just loopback it
<wgrant> Hm?
<wgrant> I loopback the new and old devices then mount them both.
<lifeless> loopback as a disk, then ext2resize
<lifeless> well, fdisk, ext2resize
<wgrant> Oh, I just resize the virtual block device then do the rest from within the VM.
<lifeless> well, thats what they say on that wiki page
<lifeless> it just seems a bit redundant to me
<wgrant> lifeless: Can you manually submit that c-c.py branch?
<wgrant> It failed with that LayerIsolationFailure.
<wgrant> Despite only changing an untested script.
<lifeless> what should the mangled commit message be
<wgrant> [r=lifeless][ui=none][no-qa] Update community-contributions.py with new name mappings and statuses.
<lifeless> and the branch url
<lifeless> wgrant: ^
<wgrant> lifeless: lp:~wgrant/launchpad/community-contributions-updates
<lifeless> sent
<wgrant> Thanks.
<lifeless> wow, we have some leaky shit here
<lifeless> oh, -ha-
<lifeless> layers blows up very badly when testSetup goes boom
<lifeless> wgrant: if you're interested, rev 11738 pushing now
<lifeless> or 739 which has devel for the parallel tests.
<lifeless> jml: https://code.edge.launchpad.net/~lifeless/launchpad/databasefixture/+merge/38643 I'm hoping you'll review that today, so I can get some momentum up.
<StevenK> lifeless: But it's a Sunday?
<lifeless> StevenK: yes
<lifeless> and? You can review it if you like; its very mechanical
<lifeless> I would love it if you did review it :)
<StevenK> I would, but I'm about to run out the door
<LPCIBot> Project devel build (121): STILL FAILING in 4 hr 5 min: https://hudson.wedontsleep.org/job/devel/121/
<wgrant> lifeless: What did you do about that STORM_CEXTENSIONS thing?
<lifeless> make
<wgrant> Ah.
<wgrant> Odd.
<wgrant> Thanks.
<jml> hi ho
<lifeless> jml: hi
<jml> lifeless: I'm just getting to your branch :)
<lifeless> awesome
<LPCIBot> Project db-devel build (75): STILL FAILING in 4 hr 8 min: https://hudson.wedontsleep.org/job/db-devel/75/
<lifeless> I'm polishing the next one - setting a uniqe env variable in BaseLayer
<lifeless> after that it will be using a custom ftesting.zcml + config dir, though I need to really understand WTF the overrides we write are
<jml> oh
<jml> I think I have an answer to your layer question
 * jml checks
<lifeless> then, in theory, we're down to fine tuning, fatsam etc.
<jml> actually, I don't
<jml> my guess was going to be that it had something to do with the way zope goes up the inheritance tree for you
<jml> but since there aren't setUp or tearDown methods on LayerProcessController, I have no idea
<lifeless> I think its because DatabaseLayer has multiple tasks
<lifeless> but for external tests environments like windmill, we don't need them all
<lifeless> or something
<jml> yeah, maybe
<jml> lifeless: working through your branch now
<lifeless> jml: thank you
<lifeless> jml: lp:~lifeless/launchpad/uniqueconfig is where my next thrust is going, if you're interested. It is selfcontained but  not useful until I do config mangling which is why I am not planning on putting it up for review just yet.
<jml> lifeless: thanks
<jml> this is a big branch
<lifeless> I mention it because it alters the branch you are looking at, a little.
<lifeless> jml: its nearly all mechanical.
<lifeless> uhm
<jml> yeah, so I'm seeing :)
<lifeless> in fact I think its reasonable to say that its all mechanical
<lifeless> static -> instance
<lifeless> unused stuff deleted
<lifeless> and the one tiny patch, adding dbname dynamic allocation support
<jml> ooh, I think I've got to the meat :)
<jml> > - Â  Â  Â  Â DatabaseLayer._reset_sequences_sql = None
<jml> lifeless: why'd you delete that line?
<lifeless> because its now held by the _db_fixture
<lifeless> the fixture has two uses, calculating the reset sequences logic, and doing test db initialisation and restoration (which uses the sequences *from the template db* - but the choice to do that is held by the layer
<lifeless> not by the fixture
<lifeless> thats something we can clean up further in future I think.
<jml> lifeless: > + Â  Â  Â  Â  Â  Â self.dbname = self.__class__.dbname + "_" + str(os.getpid())
<jml> lifeless: why self.__class__.dbname and not self.dbname?
<lifeless> because self.dbname would be wrong
<lifeless> mmm
<lifeless> rephrase
<lifeless> self.dbname would be more magical
<lifeless> I want to be explicit here.
<jml> cool.
<jml> just wanted to make sure it was deliberate
<lifeless> sure
<lifeless> DoesNotStartWith sure looks like it could be a simply curry of Not(StartsWith)
<jml> I haven't seen it, but probably yes
<jml> lifeless: also, I've found a case for which Matchers are not a natural fit.
<jml> lifeless: "assert that this Deferred will fail with this exception type"
<lifeless> well, matching would match the exception
<lifeless> I have one of those I need to port to testtools, its in testrepository atm
<lifeless> 'assert that this deferred will raise something matching <matcher>'
<jml> return d.addCallback(self.assertThat, Matches(FooError))
<jml> fsvo Matches
<lifeless> yeah, I guess
<lifeless> I spelt it, in regular code as
<lifeless> err = self.assertRaises(Exception, thing)
<lifeless> self.assertThat(err, MatchesException(...))
<jml> right
<lifeless> this doesn't seem unnatural to me
<jml> well, for deferreds it's a bit awkard
<jml> I guess I could add a convenience function like lambda d, *exc_types: return d.addCallback(self.assertThat, FailureMatches(*exc_types))
<jml> actually, ugh
<jml> it would need to be more complex
<jml> because you actually want to addErrback instead, but also add a callback that will fail if it gets called
<lifeless> yes
<jml> but it can be done
<lifeless> but this glue, isn't it directly equivalent to assertThat + assertRaises ?
<lifeless> e.g., its the adaption to let the concerns be separated
<jml> well...
<jml> the issue is that assertRaises doesn't fit Deferreds
<jml> and the tricky thing is where to put the deferred glue if not on the base class
<lifeless> thats getting interesting ;)
<lifeless> assertThat lives on the base class
<lifeless> hmm
<lifeless> this needs some consideration
<lifeless> hey, do you want to review me moving StartsWith and DoesNotStartWith to testtools?
<jml> so what I meant is that matchers as a solution for adding extra assertion types without doing inheritance magic aren't a good fit for this particular problem, even if they might be a part of the solution
<jml> sure
<lifeless> jml: ok, I get that now, and completely agree; matchers are always going to be just a component
<lifeless> jml: https://code.edge.launchpad.net/~lifeless/testtools/matchers/+merge/38645
<lifeless> jml: I'd like to roll that into an updated testtools snapshot for lp
<jml> lifeless: sure.
<lifeless> jml: or perhaps even a release, though its late and I don't want to do a release at this time of night (but if you did I could update LP in the morning)
<jml> lifeless: yesterday, I was looking into the snapshot bug you filed on testtools
<jml> lifeless: I don't know how to fix it
<jml> lifeless: https://bugs.edge.launchpad.net/testtools/+bug/613734
<lifeless> oh, I remember
<_mup_> Bug #613734: Hard to make snapshots for use with buildout <testtools:Triaged> <https://launchpad.net/bugs/613734>
<jml> I mean, I can think of ways to fix it
<jml> but surely there's already a bog standard way of dealing with this
<lifeless> presumably
<lifeless> or we could go to commits are releases.
<lifeless> if we mad it a little more automated
<lifeless> jml: so, a testtools release, or a snapshot? I'm easy.
<jml> lifeless: release sounds good
<lifeless> jml: do you perhaps feel like doing one?
<jml> lifeless: not right at this minute, but I could do one today
<lifeless> that would be awesome
<lifeless> I'll update testtools in lp tomorrow, rip out the now duplicated code.
<jml> cool
<jml> lifeless: I'm also thinking of making a web page summarizing a bunch of testing stuff that we've done
<jml> lifeless: fixtures, testscenarios, testr, subunit, testtools, tribunal â anything else?
<lifeless> testresources
<jml> ahh, of course
<lifeless> bzrlib.tests
<lifeless> python's unittest addCleanup, load_tests - we provided the protocol and discussion, call it 'moral creation'
<lifeless> or something catchy ;)
<jml> lifeless: good point
<jml> wgrant: I almost wasn't going to review the branch you just posted, and then I read the description
<wgrant> jml: Hm?
<jml> more-a-f-cleanup, re pockets
<wgrant> The code is old and revolting :(
<wgrant> And I have another 7 or so branches in this series :(
<jml> wgrant: that's a good thing :)
<jml> wgrant: I added getSuite when I was doing the package branches work. I'm glad it's now actually helping more broadly.
<wgrant> jml: Ahhh, I wondered why nobody was using it.
<wgrant> I didn't realise it was brand new.
<jml> "brand new" meaning early 2009
<wgrant> jml: This code is largely unmodified from 2005...
<jml> if I did it again now, I might have even added a Suite class.
<jml> point.
<wgrant> What is the policy on sampledata changes in devel these days?
<jml> sodomy non sapiens
<wgrant> Every few times I make a change somebody tries to kill me. I guess it's worth a try.
<jml> wgrant: I say edit boldly
<jml> wgrant: ec2 landing that branch
<wgrant> jml: Thanks.
<lifeless> wgrant: depends on what you mean by sampledata change
<lifeless> wgrant: if you mean 'deleteing a tonne' DOIT
<lifeless> if you mean 'adding a bunch'. Uhm, lets talk.
<wgrant> lifeless: I'm removing DistroSeries.lucilleconfig in favour of ComponentSelection. But one of the sampledata series is broken, having no ComponentSelections.
<wgrant> So I am adding four rows to ComponentSelection rather than rewriting hundreds of tests.
<lifeless> doit
<lifeless> no question that that is the right thing to do.
<wgrant> Thanks.
<wgrant> The sampledata regeneration bloats the diff by 700 lines :(
<lifeless> wgrant: why, its only four rows you said?
<lifeless> wgrant: put them in by hand :)
<wgrant> lifeless: The sampledata hasn't been regenerated for a while.
<lifeless> wgrant: thats not entirely true
<lifeless> what pg version have you used?
<wgrant> I can see columns being added.
<wgrant> The order is fine.
<lifeless> hmm
<wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/destroy-distroseries-lucilleconfig/+merge/38648
<lifeless> wgrant: its midnight, I'm pumpkining
<lifeless> but I smell fishy
<wgrant> Some of it is order, you're right.
<wgrant> But there is also new stuff.
<wgrant> I'm running whatever pg maverick has.
<wgrant> 8.4.5
<wgrant> The order in my branch is right.
<wgrant> It's alphabetical.
<wgrant> The old one wasn't.
<wgrant> I wonder how that happened.
<lifeless> so someone else had a sampledata patch
<lifeless> last week
<lifeless> and it didn't have columns
<wgrant> db-devel has been merged since.
<lifeless> hmm
<lifeless> gnight ;)
<wgrant> Night!
<lifeless> wgrant: I have one thought
<lifeless> if you care to do it.
<wgrant> Sure.
<lifeless> wgrant: write a test that the sampledata is in some reference order; pin that to the pg version on ec2 at the moment (so it skips if it can't run)
 * lifeless laughs maniacally
 * lifeless goes to bed
<jml> lifeless: g'night.
<jkakar> lifeless: When you wake up it'd be nice if you could review https://code.launchpad.net/~niemeyer/storm/bug-620615/+merge/38459
<jkakar> lifeless: It's a blocker for releasing 0.18 which will fix at least two problems you're experiencing with Storm in Launchpad.
<LPCIBot> Project devel build (122): STILL FAILING in 3 hr 42 min: https://hudson.wedontsleep.org/job/devel/122/
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][no-qa] Update community-contributions.py with new name mappings and statuses.
<LPCIBot> * Launchpad Patch Queue Manager: [r=jml][ui=none][no-qa] parallel testing facility that works with subunit.
<LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=655690] Replace the messy
<LPCIBot> FTPArchiveHandler.release_files_needed dict with a simple
<LPCIBot> Publisher.release_files_needed set of suites.
<LPCIBot> Project db-devel build (76): STILL FAILING in 3 hr 49 min: https://hudson.wedontsleep.org/job/db-devel/76/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11729
<LPCIBot> included.
<lifeless> jkakar: hi
<jkakar> lifeless: Hi!
<lifeless> jkakar: sure, for future ref I'm be happy with storm folk reviewing such things
<jkakar> lifeless: Yeah, I figured.  At the time, I was the only reviewer, was mentioning it so you could take second if no one stepped up, but therve has now with some interesting questions about it.
<lifeless> jkakar: that layer of code is pretty opaque, I have to reread it three times each time I approach it :(
<jkakar> lifeless: Me too. :)
<lifeless> that makes me a little sad
<lifeless> jml: I'm not sure why you're using a branch to do the release. The setup.py changes look trivially fine.
<lifeless> jkakar: also thanks for reading the guide/presentation
<lifeless> jkakar: its nice to know you felt it made some useful points
<jkakar> lifeless: Yeah, I really enjoyed it.  Everything you said aligns with my perspective on the issues (and clarified some things I've thought but somewhat vaguely).  Thanks for putting effort into documenting those ideas. :)
<lifeless> jkakar: cool; my pleasure. What things did it clarify for you?
<lifeless> jkakar: also, you might like http://pypi.python.org/pypi/fixtures - its starting to mature/shape up
<jkakar> lifeless: Specifically the comments about transparency.
<jkakar> lifeless: Often, when I review code, I notice problems related to transparency and bring them up.
<jkakar> lifeless: I hadn't attributed the term "transparency" to these observations, but seeing your list of things that contribute to transparency turned the light on.
<jkakar> lifeless: I will definitely check out fixtures!
<lifeless> this is my core-concept-of-testresources extracted to a dedicated library; testresources will be layering on it soonish
<jkakar> lifeless: Cool.
<lifeless> james_w: if you're around, was DoesNotStartWith unused in LP?
<lifeless> jml: https://code.edge.launchpad.net/~lifeless/launchpad/testtools/+merge/38665
<LPCIBot> Project db-devel build (77): STILL FAILING in 4 hr 9 min: https://hudson.wedontsleep.org/job/db-devel/77/
<LPCIBot> Project devel build (123): STILL FAILING in 4 hr 7 min: https://hudson.wedontsleep.org/job/devel/123/
<james_w> lifeless, I don't know
<lifeless> james_w: you could review https://code.edge.launchpad.net/~lifeless/launchpad/testtools/+merge/38665 if you like
<james_w> lifeless, looks fine to me
<lifeless> mwhudson: good morning. https://code.edge.launchpad.net/~lifeless/launchpad/testtools/+merge/38665
<mwhudson> lifeless: done
<lifeless> thanks!
<thumper> morning
<lifeless> hi thumper
<wgrant> lifeless: So you propose to stick the config in a request annotation?
<lifeless> wgrant: I propose to use a single way of finding global state in each environment and have a single abstraction for accessing and changing that
<lifeless> wgrant: the IAnnotations participation seems like the obvious place at the moment
<thumper> lifeless: 2010-10-16 23:12:26 ERROR   Unhandled exception
<thumper>  -> http://launchpadlibrarian.net/57750288/dQsXM3omQy3kDeJMenvfogrK9JQ.txt (FATAL:  Ident authentication failed for user "session"
<thumper> FATAL:  Ident authentication failed for user "session"
<wgrant> lifeless: Right, that sounds like a good idea.
<thumper> lifeless: that is what garbo-daily is finishing with
<thumper> lifeless: it is after the script has finished
<thumper> lifeless: I'm guessing it is the script reporting bit failing
<thumper> garbo-daily is reporting as not having run since 8th of September
<thumper> is change assignee never completing for anyone else?
<thumper> it seems tragically slow
<lifeless> thumper: I haven't tried recently; I had it on my 'this is a little slow' list though, so it wouldn't surprise me. Do you get an oops ?
<thumper> lifeless: is succeeded this time
<wgrant> thumper: The person picker was timing out a lot last week.
<thumper> lifeless: but I don't recall an oops
<wgrant> I don't think we have an OOPS ID.
<lifeless> wgrant: yes, that oopsed
<wgrant> Since you need to get it with Firebug.
<lifeless> wgrant: there is a bug
<wgrant> Ah, good.
<thumper> lifeless: I've had a thought about that weird xmlrpc behaviour
<lifeless> cool
<jml> lifeless: hello
<lifeless> mwhudson: hi, another small branch you might like
<lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/fixtures/+merge/38668
<lifeless>  4 files changed, 11 insertions(+), 274 deletions(-)
<lifeless> jml: hi
<jml> lifeless: thanks for the review
<jml> lifeless: regarding the deferred support, I'd like to know what you think of assert_fails_with
<lifeless> ok, I'll look at that
<jml> lifeless: other than that, I'm going to hold off on making unhandled errors in deferreds look different to regular errors for now
<jml> lifeless: if you're ok with the assertion helper, then I'll probably land it
<jml> lifeless: no use endlessly polishing the darn thing
<mwhudson> lifeless: just one question: should the cleanUp methods upcall?
<lifeless> mwhudson: which ones?
<mwhudson> lifeless: the ones in lib/lp/poppy/tests/test_poppy.py
<lifeless> jml: I'll look now
<lifeless> mwhudson: oh, it doesn't inherit from Fixture yet
<lifeless> mwhudson: that part of it is just tearDown->cleanUp rename
<mwhudson> lifeless: ah, ok
<lifeless> mwhudson: to harmonise on one protocol
<mwhudson> we need to implement meld in the browser and use that on the mp page :-)
<mwhudson> lifeless: approved
<lifeless> schweet
<jml> lifeless: ta
<mwhudson> active and inactive tabs look very similar on maverick :(
<lifeless> jml: so thats assertRaises spelt differently ?
<jml> lifeless: spelt with deferreds
<jml> lifeless: and using failureException shenanigans
<lifeless> I'd like to tweak the name, the implementation seems ok (but we should consolidate the core of it and assertRaises to a single helper, in principle - that can wait)
<jml> subclasses of testtools.TestCase that set different failureExceptions will get errors instead of failures unless they also inform assert_fails_with of their change
<jml> lifeless: I'm happy to put a warning in the docstring saying that it's liable to change API.  All of the twisted stuff is experimental as far as I'm concerned
<jml> caveat invoker
<lifeless> jml: perhaps it could be self.assertFails(exc_types, d)
<jml> lifeless: put Deferred know-how into base TestCase?
<lifeless> to be more like assertRaises and let it use failureException directly
<lifeless> jml: well, a mix in, like TestWithFixtures, perhaps
<lifeless> jml: not thrilled, just speculating
<jml> yeah, it could be a mix-in, but I'm frowning a little as I read that :)
<lifeless> jml: anyhow, I'm fine with adding it as unstable subject to name-and-location-change-etc-etc
<jml> lifeless: fwiw, the Twisted version is TestCase.assertFailure
<jml> (I don't like that name either.)
<lifeless> heh
<lifeless> so future stuff: more like assertRaises, support case.failureException
<jml> lifeless: noted, thanks.
<jml> lifeless: on https://code.edge.launchpad.net/~jml/testtools/run-test-improvements/+merge/38659, you say "Setting the attribute on the object not the method"...
<lifeless> yeah
<jml> lifeless: the decorator doesn't have access to the object. got any objections to a dict on the class?
<lifeless> not at all, I think I even proposed that
<jml> good good.
<lifeless> (in #subunit the other day)
<jml> lifeless: you did propose it, I just wanted to make sure you hadn't changed your mind.
<jml> :)
 * jml frowns
<lifeless> no, its still seems ok given the contract python offers
<jml> I bet f.__class__ only works on some of the supported Python
<jml> s
<lifeless> jml: whats the lowest python we support ?
<mwhudson> lifeless: could i get you to look at http://bazaar.launchpad.net/~jameinel/launchpad/lp-service/revision/11235#lib/lp/codehosting/tests/test_acceptance.py ?
<jml> lifeless: 2.4
<lifeless> jml: you can say 'decorator for functions only works on 2.4 up' if needed
<lifeless> mwhudson: looks like a url
<jml> lifeless: I think f.im_class works, but not sure about Python 3 support for it
<mwhudson> lifeless: it's related to external processes in tests and i just want to check that it doesn't conflict overly with your vision for how they are going
<mwhudson> (and also that there's nothing nicer in tree he can use yet)
<jml> mwhudson: at some later point, I'm going to find out why jam's thing isn't a twisted daemon. not tonight though, please.
<mwhudson> jml: because it forks
<mwhudson> and forking with a running reactor sounds terrifying
<jml> quite
<jml> does it have to fork?
<mwhudson> yes, it's basically the whole point of the excercise
<mwhudson> jml: i don't understand how f.im_class and f.__class__ can be considered in the same category of thing
<lifeless> mwhudson: derive from fixtures.Fixture
<jml> mwhudson: they aren't, f.__class__ was a mistake
<mwhudson> jml: ok
<lifeless> mwhudson: then you can use useFixture as a convenience for use it, or 'with forker:'
<mwhudson> lifeless: it's a helper for a layer at the moment, but i guess that we'll be wanting to move away from that in due course
<jml> >>> Foo.f.im_class
<jml> Traceback (most recent call last):
<jml>   File "<stdin>", line 1, in <module>
<jml> AttributeError: 'function' object has no attribute 'im_class'
<jml> screw you Python 3
<lifeless> mwhudson: also, the atexit is bong
<jml> why do you hate on players?
<lifeless> which reminds me to ask poolie about SIGTERM
<poolie> hello jml
<jml> poolie: hi
<mwhudson> jml: im_class is moderately useless, iirc
<poolie> jml i was thinking this morning my dkim branch may not have shown you the changes because it was in the wip state when i pushed
<jml> mwhudson: how do you find the class of an unbound method then?
<poolie> just a guess
<jml> poolie: that was my guess, but I have a different branch that has been wip & shown changes
<mwhudson> jml: i didn't think python 3 had unbound methods
<lifeless> poolie: hey, so what did you learn about SIGTERM and python
<lifeless> poolie: does SIGTERM cause a stack unwind by default ?
<poolie> what about it?
<jml> mwhudson: how do you find out which scope a function is in then?
<poolie> i don't think so, no
<lifeless> ahh
<poolie> i think by default python has no OS-level handler for it, therefore *zap*
<lifeless> poolie: did you add glue for that to bzr?
<poolie> i think we did
<lifeless> so we'll need that for:
<lifeless>  - appserver
 * poolie looks
<lifeless>  - twisted daemons
<lifeless>  - test runner
<mwhudson> jml: i guess you don't?
<poolie> no, we don't catch it
<poolie> i think there's a bug saying we should
<lifeless> ok
<poolie> it may be
<jml> lifeless: twisted installs a sigterm handler
<poolie> - we should do it and we just haven't
<lifeless> jml: ah, it does? cool.
<jml> mwhudson: that sucks
<poolie> - catching it is messy; other things like sigwinch have been hugely messy in python
<jml> lifeless: it logs & stops the reactor
<lifeless> jml: does it unwind properly? pids get deleted etc?
<lifeless> jml: there are buildbot failures that smell like SIGTERM.
<lifeless> pifiles
<jml> lifeless: pidfiles are at a higher level than the reactor. the rephrased question would be something like "does twistd delete pidfiles at reactor shutdown?"
<jml> lifeless: unless you are talking about piffle :P
<jml> lifeless: and I don't know the answer to that question.
<lifeless> jml: I'm talking about machine reboots of the bb slaves leaving a librarian pid behind
<jml> lifeless: hmm.
<jml> lifeless: I just don't know. it could be a bug in twistd
<lifeless> jml: ok
<jml> lifeless: but the solution would be fixing twistd not installing a different sigterm handler.
<lifeless> jml: sure
<lifeless> jml: details ;)
<jml> lifeless: you architects have it so easy :P
<poolie> what's the context? making sure that external fixtures are torn down?
<lifeless> poolie: yes
<jml> good grief, Python 3 has also crippled Foo.f.__dict__
<jml> nm
<lifeless> ok, raising in a sigterm handler works
<lifeless> trivially
<lifeless> and we have a SIGTERM handling in bin/test already
<thumper> ah.. whut? 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] Connection refused
<thumper> I'm just trying to run a damn test :(
<wgrant> Try bin/kill-test-services
<wgrant> If it failed the first time.
<wgrant> Except that might be broken now.
<wgrant> So maybe remove the librarian pid manually.
<lifeless> thumper: check you don't have a /var/tmp/fatsam.test/librarian.pid
<lifeless> wgrant: it shouldn't be broken
<thumper> $ bin/kill-test-services
<thumper> Traceback (most recent call last):
<thumper>   File "bin/kill-test-services", line 39, in <module>
<thumper>     from canonical.librarian.ftests.harness import (
<thumper> ImportError: No module named harness
<thumper> heh
<wgrant> Yeah, that.
<lifeless> oh, thats broken.
<lifeless> damn thing should be tested shouldn't it.
<wgrant> I pointed that out to you last week, IIRC.
<lifeless> wgrant: I don't remember
<thumper> boo... hiss... FeatureError: Can't remove a sliced result set
<jml> g'night
<lifeless> night
<lifeless> wgrant: that import is just bong
<thumper> why does store = IMasterStore(IPerson) fail in the harness?
<mwhudson> don't you do it to objects or database classes?
 * mwhudson might be wrong
<wgrant> thumper: IMasterStore(Person) or IMasterObject(some_person)
<thumper> ah...
<thumper> that's right
<wallyworld> morning
<thumper> wallyworld: morning
#launchpad-dev 2011-10-10
<lifeless> wgrant: tells haproxy the service hasn't crashed
<wgrant> lifeless: What's the difference?
<wgrant> The only conceivable difference I can see is that in the case of a crashed service you might possibly want to kill leftover connections, but I doubt it does that.
<lifeless> uhm, I looked into it, I don't recall now.
<lifeless> it may have been to do with zope awfulness
<wgrant> Right, but that only affects appservers.
<lifeless> feel free to dig, I don't want to try and page that in right now.
<wgrant> It would be nice to not have to add an HTTP service to every service.
<wgrant> Sure.
<lifeless> wgrant: persistent connections
<lifeless> wgrant: and no alerts generated
<wgrant> lifeless: Do we use persistent connections?
<lifeless> we were; we should on twisted services; we don't on the appservers
<lifeless> s/twisted/non-ultra-tuned/
<wgrant> Why would we use them on Twisted services?
<lifeless> also non-cpu-bound
<wgrant> Why do we care which service it gets dispatched to?
<lifeless> less overheads
<lifeless> tcp will already be open on the second request
<wgrant> Hm? That sounds like HTTP keepalive, not haproxy persistent connections.
<lifeless> same same
<lifeless> at this point I'm going to say 'shoo, go read' - haproxy is terrifyingly evil in some ways
<lifeless> yes we have room to rejigger things
<wgrant> AFAICT the maintenance-mode persistence behaviour affects cookie-based persistence.
<lifeless> also 'how can we tell the service is really down'
<wgrant> It's not listening.
<lifeless> I don't have any requirements that all our services use haprox the same way
<lifeless> wgrant: that not at all the same as really down
<lifeless> wgrant: (if we don't have a status page)
<wgrant> lifeless: Does that matter?
<lifeless> hell yes
<wgrant> .. how?
<wgrant> Assuming I'm using haproxy as a round-robin load balancer, not as a nagios or cookie-based load balancer.
<lifeless> so, again, I don't care if some services are configured differently; the requirements are that its got a sane nodowntime upgrade mechanism, including all the aspects like telling the difference between crashed (so just start it) and going down (do not touch), and getting metrics out
<lifeless> I expect different answers for different stacks and different services
<wgrant> And I think our assumptions for appservers and codehosting are flawed.
<lifeless> right now we have two services with status pages
 * lifeless shrugs
<lifeless> it works, its introspectable, and aided us iding and fixing the root cause of hang-on-restart; preserve the functionality and I'm happy.
<wgrant> Huh, how was it relevant to that?
<wgrant> The regular requests?
<lifeless> I seem to recall you polling it too watch what was gong on
<wgrant> Oh, for codehosting, not appservers.
<lifeless> what has you pulling on this thread ?
<lifeless> why is it interesting to talk about now ?
<wgrant> Well, I don't want to have to add a pointless HTTP service to poppy.
<lifeless> I don't think status pages are pointless even if not used for haproxy
<lifeless> they provide a good place to hook useful metrics we (have in the past) wanted to poke at (vs publishing to *statsd which is also a good idea but not as watchable-by-F5)
<lifeless> conversely, I don't think everything has to have one.
<lifeless> Have you been told you have to add one?
<wgrant> No.
<wgrant> But if there's a reason that codehosting needs one for haproxy, then poppy needs it to.
<wgrant> However, I suspect that neither does, and probably neither do the appservers.
<lifeless> poppy and codehosting aren't the same service, so I don't see that that holds
<lifeless> hah
<wgrant> ?
<lifeless> I've filed 6.2% of open LP bugs
<wgrant> Timeouts do that :(
<wgrant> Bah, I'm just below 3% now.
<lifeless> could you add some technical info to bug 528459 please?
<_mup_> Bug #528459: PPA does not delete old packages after new build <lp-soyuz> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/528459 >
<wgrant> lifeless: NBS
<lifeless> I was hoping for a paragraph, to point future folk straight at the issue
<lifeless> 2-3 lines
<wgrant> But all Soyuz people will know basic stuff like NBS.
<wgrant> Oh wait :(
<StevenK> lifeless: NBS == Not Built from Source. If you have a 'user' source package that builds 'libuser1', and then a new version of user is uploaded that now builds 'libuser2', libuser1 is now NBS.
<lifeless> StevenK: yes, I am slightly familiar with packaging jargon
<lifeless> StevenK: (thanks for chiming in :P)
<StevenK> I was providing said paragraph
<lifeless> StevenK: mmm; Something like 'ppas do not handle NBS binaries, look at <method> for how they are handled in primary archives' - that would be said paragraph
<lifeless> StevenK: though it sounds like wgrant suspects its not NBS handling
<wgrant> Hm?
<wgrant> It is NBS.
<lifeless> you said 'Oh wait :('
<StevenK> But all Soyuz people will know basic stuff like NBS. *Oh wait :(*
<wgrant> That was imitating realisation that there is no longer a Soyuz team to know things.
<StevenK> That is what wgrant meant
<lifeless> and there are now no lp medium bugs
<lifeless> that are not incomplete
<lifeless> + we need a release of loggerhead
<wgrant> Just lots of bugspam :P
<wgrant> Indeed.
<wgrant> erk
<lifeless> are we able to use amqplib 1.0.2 ?
<wgrant> germanium:process-uploaded failed to run for at least 35 minutes.
 * wgrant investigates.
<wgrant> lifeless: What are we using now?
<lifeless> 0.6.1 is in the downloadcache
<wgrant> Seems like 1.0 was released at the end of July.
<wgrant> Two years after the previous release.
<wgrant> Upgrade away.
<nigelb> Morning!
<wgrant> Evening nigelb.
<nigelb> wgrant: Its alreay evening out there?
<wgrant> No.
<wgrant> But correctly timed greetings are silly.
<nigelb> Heh, true.
<lifeless> bwah, going to have to thread-sanitise errorlog.py
<lifeless> unless; do we get one instance per thread? I seem to recall a hateful global in there. <grah>
<mwhudson> quick, stash it on the interaction!
<lifeless> mwhudson: separate non-threadsafe library
<lifeless> mwhudson: giving it a callback to the interaction seems even uglier than a callback to make a connection
<mwhudson> ah ok
<lifeless> mwhudson: however, it won't have global tls; just per object tls
<lifeless> (oops_amqp.Publisher will hold a threading.locals() containing the amqplib Connection object for a given threads oops reporting)
<lifeless> can has revu?
<wgrant> As long as it doesn't involve oops_amqp and thread-globals, probably.
<lifeless> oops-datedir-repo - support to act as a component in oops-tools
<lifeless> https://code.launchpad.net/~lifeless/python-oops-datedir-repo/0.0.9/+merge/78793
<lifeless> the amqp thing I will want you to read, as one of the more amqp fluent folk around
<lifeless> but thats still largely scifi.
<poolie> hi all
<StevenK> wgrant: Can haz mumble?
<wgrant> StevenK: Why?
<StevenK> wgrant: I'd like a pre-impl about the enum that sinzui was talking about
<wgrant> Which enum?
<StevenK> The privacy enum
<wgrant> The one that probably isn't an enum at all?
<wgrant> Oh.
<wgrant> Team privacy?
<StevenK> Right
<wgrant> I think we really need Curtis for this as well.
<wgrant> Do you know the history around private and private membership teams?
<StevenK> Not really, so we probably want to do it after the stand-up
<StevenK> wallyworld_: Your three cards in Deployment-Ready can probably be tossed into Done-Done.
<lifeless> enum ?
<wallyworld_> StevenK: ok
<StevenK> wallyworld_: But check the linked bugs are Fix Released.
 * wallyworld_ checks
<wgrant> lifeless: A less-private privacy level for private teams.
<wgrant> lifeless: To reveal their name.
<StevenK> garbo-hourly is *still* crashing?
<wgrant> StevenK: Yes.
<wgrant> Somebody needs to fix it.
<StevenK> Fail.
 * StevenK looks
<wgrant> It started crashing on Friday night, and will crash for weeks if one of us doesn't fix the code, I expect.
<wallyworld_> but isn't that a maintenance squad role?
<wgrant> Yes.
<wallyworld_> so let them do it
<StevenK> 2011-10-10 00:13:10 ERROR   [BugTaskIncompleteMigrator] Unhandled exception
<StevenK>  -> http://launchpadlibrarian.net/82446649/vWceIFzREh8RMuyErP2OjLr1n4s.txt (can'
<StevenK> t compare datetime.datetime to NoneType)
<StevenK> wallyworld_: So we can get spamed with script-activity for weeks?
<wgrant> Bug #871038
<_mup_> Bug #871038: BugTaskIncompleteMigrator blows up on bugs that were filed Incomplete <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/871038 >
<wallyworld_> StevenK: no, if someone else keeps doing it fot them then nothing will change
<lifeless> wgrant: so we believe some teams will want to be islands and standalone ?
<lifeless> wgrant: (I would question that, particularly for canonical ones)
<lifeless> I suspect brad will see it on monday, as he is working that arc
<wgrant> lifeless: I assume there was a reason that completely private teams were implemented.
<lifeless> wgrant: thats a nice assumption
<lifeless> the history is messy
<lifeless> rather than design a model that scales up as folk need more, we've special cased things with the team-type enum, and its been traumatic
<lifeless> I would like to butt into this discussion
<StevenK> lifeless: I've found a bunch of lines in BugTaskIncompleteMigrator that are either indented incorrectly, or >77 characters. :-(
 * StevenK nails Ursinha to the channel.
<Ursinha> StevenK, sorry
<Ursinha> setting up my bip server
<StevenK> Ursinha: It's okay. Hopefully my nail didn't hit anything vital. :-P
<Ursinha> StevenK, haha
<poolie> lifeless, hi, i might have a go at the affectsmetoo timeouts later
<poolie> i would appreciate some advice or reassurance though
<poolie> because with ~20x variations in query speed on production
<poolie> i feel a bit pessimistic about being able to write something that will be consistently fast :/
<poolie> and trying it out by landing changes has a long latency
<StevenK> Can haz review? https://code.launchpad.net/~stevenk/launchpad/fix-bugtask-incomplete-migrator/+merge/78794
<lifeless> poolie: its tricky, yes.
<lifeless> poolie: basically needs a wholistic approach - look at the whole work happening, what its doing and how, and come up with a way to answer it efficiently
<poolie> hm
<poolie> it doesn't seem like it should be that hard of a query to answer
<poolie> it's not retrieving a large amount of data
<lifeless> poolie: I wouldn't underestimate the warm-up cost for doing that; you can easily spend a couple of days on a low hanging fruit timeout, and a week or more on one that has been previously optimised
<poolie> mm
<poolie> i hate to leave this half baked
<poolie> i really like the feature but it's pretty flakey now
<lifeless> poolie: so, as a for-instance: its going to be cold data, nearly every time
<poolie> i don't suppose we can up the timeout?
<lifeless> so the question is 'how can we answer this query when the data is being read off of disk each time'
<poolie> oh, and it got ~4 bug dupes about the timeout since it launched
<lifeless> poolie: yah, making it visible tends to do that :>
<lifeless> poolie: no, if we can't answer this efficiently, we should drop the feature.
<poolie> re 'cold' - i had heard that the db fitted in memory
<poolie> but, it's not guaranteed to be all in memory, just mostly?
<StevenK> Like fun it does
<lifeless> poolie: nope, not at al.
<StevenK> poolie: The DB is 300GiB, and the DB servers have 128GiB of RAM
<StevenK> There's math in there.
<lifeless> poolie: the DB exceeds main memory on our prod servers by -lots-l
<lifeless> StevenK: re line length - meh; sure; shrug.
<poolie> 'drop the feature' - doing a bug search at all also generally times out :/
<StevenK> lifeless: We have coding standards for a reason. :-(
<lifeless> StevenK: if it wasn't in PEP8, I would be arguing that we should expand it
<StevenK> It makes me unhappy to see them not used.
<lifeless> StevenK: there are standards and standards; amongst other things pragmatism over purity.
<poolie> anyhow
<lifeless> StevenK: line length violations don't cause crashes exceptions unbound variables etc
<poolie> so this stuff might be cold
<lifeless> poolie: its pretty much guaranteed to be
<poolie> ok
<lifeless> poolie: its a separate table with no reason for it to be read until someone consults it for $user-FOO
<StevenK> lifeless: Right, they don't, but we still have the standards for a reason, so they should be followeed.
<StevenK> s/ee/e/
<poolie> is it reasonable to do a query that may do 'a bit' of hard io, but not much, or will even that often be too slow?
<lifeless> poolie: its about 1 to 2 ms per row of IO (thats a terrible rule of thumb but close enough to be useful)
<poolie> thanks
<poolie> so it'd be reasonable to expect someone affected by 5 bugs would always be able to see this without timing out?
<lifeless> StevenK: so fix them; if you're saying I put them there, 'sorry' - I have my editor configured to wrap at 80 and don't usually break the limit, but OTOH if its clearer as it is, then I think its better : standards are meant to help with clarity after all
<StevenK> lifeless: I have fixed them -- I'm not complaining that you put them -- I'm just saying that they make me sad.
<lifeless> poolie: possibly; once it gets enough use for the table statistics to be hot, then it will probably be able to plan the queries quickly and execute in a reasonable timeframe
<lifeless> StevenK: k
<lifeless> StevenK: thanks for fixing the migrator
<lifeless> StevenK: can I ask that you also comment it out :)
<lifeless> StevenK: (see the bug about ProductSeries:+index and migrated bugs)
<StevenK> Er?
<StevenK> Now I'm confused
<lifeless> there were two issues with the branch
<poolie> lifeless: ok so if you were going to work on this, how, generally,  would you go about it?
<lifeless> one is the migrator going boom
<poolie> try different queries in the hope of finding one that's fast?
<lifeless> the other is that a migratde bug in a series causes a manually-mapping function on ProductSeries:+index to time out.
<poolie> or, do some kind of more architectural change as far as ajax loading, or freshening them for active users, or something?
<StevenK> lifeless: So we should revert the migrator wholesale?
<poolie> or something about trying to create different indexes - and if so which?
<lifeless> StevenK: I don't think the whole branch needs reverting; but the garbo job shouldn't convert any more until the web UI issue is fixed
<poolie> s/which/can they just be tested on staging to see how they perform on real data?
<lifeless> poolie: those are all valid strategies; doing ajax loading of just one number is something I'm suspicious off (when I started we had ajax things that themselves time out) - I figure if we can't do the whole page sanely in 5s time, splitting it into bits just lets us be inefficient in more places
<poolie> i'm talking about loading the whole page, like bugs.l.n/~/+affectingbugs
<poolie> not the number
<lifeless> ok
<poolie> and yes, i shared that thing that doing it multiple roundtrips just seems more inefficient
<poolie> ah
<lifeless> so for that, ajax is irrelevant anyhow, you need the batch to be efficient
<poolie> well
<poolie> we could load most of the page, then have the actual bug rows arrive later
<poolie> that would give a bit better of an impression
<poolie> but it would be a lot of work
<lifeless> the timeout though is coming from the batch
<poolie> right, and it would still need a long timeout to actually load the rows
<lifeless> which we won't do - long queries affect liveliness throught the system
<lifeless> we're driving *everything* down to 5s tops
<lifeless> there is a quote request in with IS to examine new hardware
<lifeless> which would have more memory
<lifeless> I think that that will make a significant difference to the 'this works if I keep hitting refresh' cases
<lifeless> StevenK: I think something like removing the job from the garbo list, or putting it in the experimental list or something, is appropriate
<wgrant> StevenK: Can't you just add another disjunct to the existing if?
<lifeless> StevenK: reverting the whole branch would break existing migrated bugs in more ways
<wgrant> StevenK: If either date is None, -> WITHOUT_RESPONSE
<poolie> in case you don't know, i landed this with no count next to it, so there is no performance impact unless you actually click through to the new pages
<lifeless> poolie: yeah, I know :)
<nigelb> Is there a guide somewhere on writing garbo jobs?
<lifeless> nigelb: there are docs on it in the system about how to use the API etc
<wgrant> lifeless: Product:+series OOPSes, it doesn't time out.
<lifeless> nigelb: there isn't a 'for dummies' one AFAIK
<lifeless> wgrant: I know
<nigelb> lifeless: HA.
<nigelb> lifeless: lol :)
<lifeless> wgrant: why do you think I didn't ?
<wgrant> "causes a manually-mapping function on ProductSeries:+index to time out"
<lifeless> wgrant: ah, because I wrote bad words.
<lifeless> wgrant: I meant go boom
<wgrant> Heh
<StevenK> wgrant: Right, fixed.
<StevenK> Is there a bug for Product:+series bangness?
<nigelb> lifeless: Is it on the wiki?
<wgrant> StevenK: Also, rather than using deprecated switchDbUser and testadmin, can you use 'with dbuser' and launchpad?
<lifeless> poolie: so the problem here is you need to consult 4 tables to generate the batch, one of will have a lot of pages loaded
<lifeless> poolie: its not a clustered table IIRC, so take me - 1K rows in the table
<wgrant> StevenK: Bug #871076, but that can be left for maintenance people.
<_mup_> Bug #871076: Product:+series OOPSes on INCOMPLETE_WITH_RESPONSE and INCOMPLETE_WITHOUT_RESPONSE bug tasks <oops> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/871076 >
<wgrant> Since it isn't cronspamming incessantly.
<wgrant> LP can choke and die, as long as it's quiet about it.
<StevenK> wgrant: But then I'm just spreading the problem by fixing garbo-hourly ...
<lifeless> poolie: because they are spread out over the table, and there are 1M rows, its probably loading 1K pages of table data plus 10 or so pages of index, to calculate the query result
<poolie> right
<wgrant> StevenK: Yeah, but it's likely they'll be deployed together.
<StevenK> wgrant: Hopefully.
<wgrant> StevenK: As it's not as if we have any big series things happening this week.
<StevenK> Hah
<StevenK> Hahahahahaha
<lifeless> poolie: so, in short, personalisation of the bug tracker is -hard-, this is going to be very tricky.
<lifeless> poolie: probably we want a personalisation service on its own hardware that can run in-RAM totally and not get paged out, vs the one big DB which just LRU's everything.
<StevenK> wgrant: I'd like to push back on switchDbUser -- I'm following the established pattern, and I'd rather not re-indent the entire function.
<poolie> obviously there's going to be strong locality across actually-active users
<wgrant> StevenK: You should only need to indent the makeBug.
<wgrant> StevenK: It is the established pattern, but I deprecated it weeks ago.
<lifeless> poolie: the crazy thing here is that the table is only 40MB packed and 21MB in the index I would predict will be used.
 * StevenK looks for 'with dbuser' in the code
<wgrant> StevenK: from lp.testing.dbuser import dbuser
<wgrant> with dbuser('launchpad'):
<poolie> so i guess we *could* cluster on user id, but it's probably also used to count up affected users?
<wgrant>   # ahaha I am god
<poolie> or maybe that's cached? otherwise it seems it would always be hot
<lifeless> poolie: for instance, I have only 64K of the data in that table
<wgrant> I have a suspicion that it'd be faster to do it in a few separate queries.
<poolie> have it where?
<wgrant> The enforce optimisation boundaries.
<lifeless> select * into temporary table lifelessbap from bugaffectsperson where person=2;
<lifeless> SELECT
<wgrant> s/The/To/
<lifeless>  \dt+ lifelessbap
<lifeless>                        List of relations
<lifeless>    Schema   |    Name     | Type  | Owner | Size  | Description
<lifeless> ------------+-------------+-------+-------+-------+-------------
<lifeless>  pg_temp_40 | lifelessbap | table | ro    | 64 kB |
<poolie> so how can it get so cold?
<StevenK> wgrant: Fixed, re-running tests.
<lifeless> poolie: we have cron scripts that walk entire tables end to end
<lifeless> poolie: for some very big tables
<wgrant> StevenK: I'll do a batch fix-up and remove switchDbUser eventually.
<wgrant> And then pull some tests back to Functional layers.
<StevenK> poolie: Revision, for instance is nearly a billion rows
<lifeless> poolie: the point that that 64K is spread over everything is still valid
<lifeless> poolie: however - have you deployed stubs query fix yet ?
<poolie> nup
<lifeless> poolie: it was just a crazy query initially, and theres no point stressing until that is landed
<poolie> my point in talking to you was, whether it was too much of a shot in the dark
<poolie> since even the improved one is sometimes quite bad (>3000ms)
<poolie> but perhaps the typical case is better
<lifeless> the bad query is 9s; the improved one is 3x better to start with
<poolie> i'll take that
<StevenK> Bring on longpoll
<StevenK> wgrant: Changed pushed, diff updated.
<wgrant> StevenK: Approved.
<StevenK> wgrant: Thanks, tossing through ec2
<StevenK> wallyworld_: Your 518 ec2 AMI can be deleted.
 * StevenK looks at deleting 519
<wgrant> Ah, yes, was going to poke people about that.
<wgrant> But related stuff on Saturday didn't quite go smoothly.
 * wgrant thwacks buildbot and stuff.
<StevenK> Yes, the build of that old revision was lol-worthy
<wgrant> And then the one afterwards caused a bzrlib exception.
<StevenK> Come on, AWS! Surely you're not slower than SSO!
<nigelb> lol
<nigelb> YOu'd be surprised.
<StevenK> I would not.
<stub> StevenK: Easiest way of handling a garbo job you don't want to run on production but might want to run on staging is to stick it in the 'experimental' list.
<nigelb> lib/lp/scripts/garbo.py is where garbo jobs go?
<StevenK> Yes
 * StevenK kicks AWS and re-loads
<stub> nigelb: For now. It is growing a little unwieldy.
<nigelb> stub: I'm still trying to figure out how it works :)
<StevenK> wgrant: 519 binned
<wgrant> StevenK: Great.
 * StevenK tries to understand bug 307539
<_mup_> Bug #307539: bug attachment HostedFiles refuse to be deleted <lp-foundations> <oops> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/307539 >
<StevenK> Ah. HostedFile is in lazr.restfulclient
<StevenK> lifeless: You commented on bug 307539 -- writing a quick API script: bug = launchpad.bugs[17] ; bug.attachments[0].data.delete() ; results in a 405, not a 500
<_mup_> Bug #307539: bug attachment HostedFiles refuse to be deleted <lp-foundations> <oops> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/307539 >
<lifeless> StevenK: sounds like its Fix Released already then
<wgrant> lifeless: Do you have opinions on how to do per-artifact observer modelling?
<lifeless> wgrant: some testing required but either partitioned FK columns or a single generic-reference intermediary table (which we may want to move BugTask etc to use as well)
<lifeless> the testing basically being tossing variations of existing prod data at both and assessing query performance
<wgrant> lifeless: I was thinking it's probably best (for indices) to just have bugtask/branch FKs on the observer table for now.
<lifeless> do you observe a task or a bug ?
<lifeless> what happens if you observe something thats not in your pillar anymore ?
<wgrant> I'm not sure yet, but I think a task.
<wgrant> Bugs are horrible and will probably need several triggers anyway.
<lifeless> I lean towards a separate table
<wgrant> Oh?
<lifeless> surrogate keys are a common part of query schemas, and generally good for performance
<lifeless> but like I say, needs testing
<wgrant> What would this table look like?
<lifeless> id, bugtask, branch, blueprint, question, milestone, series, sourcepackagename, distroseries
<wgrant> Oh, a universal generic reference table?
<lifeless> possibly a little less ambitious than totally generic, but yes.
<lifeless> immutable rows
<lifeless> (except when we truely are moving the referenced thing around)
<lifeless> by which I mean, if the observer changs from observing bug X to bug Y, you would add a row for bug Y and change the observer FK to its PK, rather than editing the dereference table
<wgrant> Also, I can't see any way around using triggers to ensure that an observer exists for every task if there is an observer for one of them.
<wgrant> Right.
<lifeless> you will probably need a chunk of triggers, yes
<wgrant> And I'm not sure how exactly we'll handle task retargeting, but I guess we can sort that out somehow.
<lifeless> do you mean observer policy ?
<lifeless> '18:15 < wgrant> Also, I can't see any way around using triggers to ensure that an observer exists for every task if there is an observer for one of them.
<lifeless> '
<wgrant> lifeless: Well, that too, but that's far simpler.
<lifeless> ok, so why would you want to ensure observers exist for every task ?
<wgrant> lifeless: The issue is that if I'm an observer for project A, and there's also a project B task on one of A's bugs, I need a restricted observer record for the project B task as well.
<wgrant> Or disclosure views will have to query across bugtask.
<lifeless> or are you suggesting for a 200 task bug, that the special exemption given to let A see the bug, will result in 200 (A, taskN) rules ?
<wgrant> Yes.
<lifeless> uhm
<lifeless> my immediate reaction is to suggest two schemas
<lifeless> a single non-duplicate schema
<lifeless> and a derived query schema
<wgrant> Why?
<lifeless> depends on exactly what the page needs to show I guess
<lifeless> why? so that web and API transactions to change things write a small amount of data
<wgrant> We need to be able to show everyone that has access to the project artifacts.
<lifeless> you have two very different statements here though
<lifeless> one is a statement that (person or team X) has access to (asset Y)
<lifeless> the other is a statement that (anyone that has access to asset Y in project B) has access to (asset Y too)
<lifeless> I presume you're not suggesting that you would expand out all the former statements from project B into restricted statements on project A
<lifeless> because that would make any write to project B's observer list also write to project A
<wgrant> We need to something along those lines.
<wgrant> Or we have to join across bugtask, which would be even worse.
<lifeless> so, don't conflate primary storage with query storage
<lifeless> you need somewhere to record intentions *once*
<lifeless> otherwise you can never audit and tell what things are meant to be where.
<lifeless> DRY etc etc
<wgrant> Why can we never audit?
<lifeless> separately, you can do the math and see whether joining through task.bug to get the observer rules for project B is fast
<lifeless> however, unless you're - ELOCAL
<wgrant> EPARSE
<lifeless> skype?
<wgrant> Sure
<StevenK> wgrant: Are you still skyping?
<wgrant> StevenK: Yes.
<poolie> > ImportError: cannot import name OfficialBugTag
<poolie> halp?
<poolie>     ZopeXMLConfigurationError: File "/home/mbp/launchpad/lp-branches/work/lib/lp/services/messages/configure.zcml", line 44.2-47.6
<StevenK> Do you remove it?
<StevenK> Or move it?
<adeuring> good morning
<poolie> StevenK: no
<poolie> perhaps it's a knock-on import error, i'll shelve my changes and try again
<wgrant> poolie: We have lots of potential circular imports.
<wgrant> Because any sense of layering is for the weak.
<poolie> yep, it was circularity
<poolie> well
<poolie> requiring the imports be a strictly acyclic graph even between closely related modules would be a pretty high bar
<wgrant> Sure, but we are far worse than we could be :)
<poolie> 'we' meaning humans :)
<poolie> also launchpad
<poolie> i will try not to make it worse
<poolie> i would like to clean up the per-person bug views to be not entirely unrelated to the main ones
<lifeless> \o/
<lifeless> amqp oops publishing working
<lifeless> just need the receiver loop and am done
<lifeless> -> family for a bit
<poolie> lifeless: and then zero latency?
<lifeless> gmb: yo
<lifeless> poolie: then open source oops tools, and then add a oops-tools script using the bits to receive oopses over amqplib
<lifeless> poolie: somewhere in there I need to add spilling to disk if rabbit is down
<gmb> lifeless 'sup?
<lifeless> gmb: wanted to check with you - I retriaged some bugs down to high; but if they were critical due to priority inheritance then I can put them back
<gmb> lifeless: I've not seen any yet that I disagreed with. Have you got any particular bugs in mind?
<lifeless> just the ajax fallout ones
<gmb> Okay. I'm happy with those being High rather than critical.
<poolie> short review please? https://code.launchpad.net/~mbp/launchpad/866100-affectsme-timeout/+merge/78806
<poolie> do i need a db review for that?
<poolie>  lifeless, for your interest (realize it's late) i did do the change to a join, in that mp, and it seems it may help
<poolie> stub: could you review it?
<stub> k
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Critical bugs: 269 - 0:[########Segmentation fault (core dumped)
* danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 269 - 0:[########Segmentation fault (core dumped)
* danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Critical bugs: 269 - 0:[########Segmentation fault (core dumped)
<danilos> benji, oh, you are actually in already, can you please take a look https://code.launchpad.net/~danilo/launchpad/bug-869089/+merge/78819 when you find some time? (mostly mechanical, replacing remaining uses of official_rosetta throughout the code)
<benji> danilos: sure
<danilos> benji, thanks
<deryck> Good morning, all.
<bigjools> has anyone seen "UploadFailed: Server said: 500 Internal server error" coming from the librarian when running tests?
<jml> Hmm.
<jml> bigjools: Yes.
<jml> bigjools: But I can't remember what caused it.
<bigjools> it's oneiric
<bigjools> https://bugs.launchpad.net/launchpad/+bug/871596
<_mup_> Bug #871596: Can't run tests involving Librarian <build-infrastructure> <librarian> <Launchpad itself:Triaged> < https://launchpad.net/bugs/871596 >
<jml> Hmm.
<jml> bigjools: no, I haven't seen that thing from the librarian log
<jml> bigjools: but I've only done one or two LP patches in oneiric, and that was weeks ago.
<bigjools> jml: I only get it when running more than one test
<bigjools> single runs are fine
<jml> bigjools: it takes quite a while to get an updated tree with runnable tests.
<bigjools> jml: not sure what you mean
<jml> bigjools: bzr pull; bzr up download-cache; ./utilities/update-sourcecode; make schema
<jml> takes time
<bigjools> ah, that :)
 * bigjools nails 5-digit bug to the wall
<rvba> Thanks for the reviews benji!
<benji> rvba: my pleasure
<lifeless> flacoste: 'yo'
<lifeless> gary_poster: wheee, nice bug there
<gary_poster> lifeless, :-)
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 269 - 0:[########Segmentation fault (core dumped)
* lifeless changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 269 - 0:[########Segmentation fault (core dumped)
<lifeless> wgrant: medical schedule change; I have to pop out quite a bit sooner; I should be on 3g successfully though, once I'm at the place we're going.
<lifeless> \o/ and handling of rabbit down done too. :)
<lifeless> wgrant: can you do a review of the first two commits of python-oops-amqp ?  We don't have a sensible review-first-commit thing yet
<wgrant> Oh, bah, no Curtis today, I suppose.
<lifeless> wgrant: I'm specifically looking for thinkos in my amqp handling
<wgrant> Yep, am looking, since it seems we don't have a standup without the US :)
<lifeless> thanks
<lifeless> just drop me mail; I'll try to get back online ~your 10am
<wgrant> k
<wgrant> lifeless: Also, http://www.rabbitmq.com/faq.html#which-entity-should-declare-exchanges
<lifeless> thanks
 * lifeless goes
<wallyworld> wgrant: StevenK: have you had any issues landing stuff via ec2? The last few things I've thrown at it all fail with hung tests
<wgrant> wallyworld: Which tests?
<wallyworld> wgrant: doesn't specify. just says "A test appears to be hung..."
<wgrant> Can you forward me the emails?
<wallyworld> the last successful test appears to be lp.archivepublisher.tests.test_publisher.TestPublisher.testReleaseFile
<wgrant> Oh.
<wgrant> Merge devel.
<wgrant> You need my new AMI from Saturday.
<wgrant> 522
<wallyworld> i think i'm using 521
<wallyworld> thanks
<StevenK> wallyworld: And 518 can be binned ...
<wallyworld> StevenK: how do i do that?
 * wallyworld looks at the wiki
<StevenK> wallyworld: https://dev.launchpad.net/EC2Test/Image
<StevenK> wallyworld: Last section is 'Deleting AMIs'
<wallyworld> thanks
<lifeless> and on 3g
<wgrant> lifeless:   File "/tmp/python-oops-amqp/eggs/testtools-0.9.12_r228-py2.7.egg/testtools/testcase.py", line 134, in gather_details
<wgrant>     for name, content_object in source_dict.items():
<wgrant> AttributeError: 'RabbitServerRunner' object has no attribute 'items'
<lifeless> wgrant: reproduction instructions ?
<wgrant> lifeless: bzr branch lp:python-oops-amqp; cd python-oops-amqp; ln -s ~/launchpad/lp-sourcedeps/download-cache; ./bootstrap.py; bin/buildout; bin/py -m testtools.run oops_amqp.tests.test_suite
<lifeless> wgrant: on lucid ?
<wgrant> lifeless: oneiric
<wgrant> I could try lucid, I suppose.
<lifeless> thats a mismatch with changed testtools api
<lifeless> between fixtures and testtools
<wgrant> lifeless: But both fixtures and testtools are from eggs.
<lifeless> just reproducing on my laptop (in my lucid lxc)
<wgrant> Ah, works.
<wgrant> On Lucid.
<wgrant> Hmmm.
<wgrant> I suppose it could be a minor problem that I don't actually have rabbitmq-server installed on my oneiric host.
<wgrant> Still, rather opaque error :)
<mwhudson> suggests there's a mismatch in the specified versions then?
<lifeless> yes
#launchpad-dev 2011-10-11
<lifeless> mwhudson: suggests we need a newer testtools
<lifeless> or newer fixtures. EDUNNO
<wgrant> lifeless: So, oops-amqp's AMQP usage.
<wgrant> lifeless: At present, if the queue doesn't exist then OOPSes will silently be dropped.
<poolie> is an ec2 land based on image 522 going to work, or do i need to update onto trunk?
<wgrant> poolie: 522 is the latest. If ec2 says it's using that, it will work.
<StevenK> wallyworld: Thank you for deleting 518
<wallyworld> StevenK: np. i should have done it sooner
<lifeless> wgrant: right, it depends on correct config
<lifeless> wgrant: thats a standard thing in amqp - the producer cannot know what a 'right' config is, can it ?
<wgrant> lifeless: Right.
<lifeless> wgrant: we'd check this via nagios I think - send a probe oops through kindof thing
<wgrant> We could use the mandatory publish flag, but failure notifications are async and not even exposed by amqplib, I don't think.
<StevenK> Can haz review? https://code.launchpad.net/~stevenk/launchpad/rest-glob-imports/+merge/78902
<lifeless> wgrant: right
<lifeless> wgrant: so as it stands I think its feature complete and usable
<lifeless> wgrant: and we can write a small respooler for datedir-repo
<lifeless> anyhow -> next thing
<wgrant> lifeless: Yep.
<wgrant> Arggh
<wgrant> https://launchpad.net/linux-kernel
<wgrant> Hmm, created by a Googler, apparently.
<wgrant> Oddity.
<wgrant> StevenK: Has garbo-hourly run on qastaging yet?
<wgrant> erm
<wgrant> https://code.launchpad.net/~alex-endfinger/google/unity-4.0
<wgrant> I think they must be stopped.
<wgrant> what
<mwhudson> hm, isn't that url already imported somewhere else?
<wgrant> That's lp:google.
<wgrant> mwhudson: linux.git vs linux-2.6.git
<mwhudson> wgrant: ah ok
<wgrant> Tempting to deactivate both projects, too.
<wgrant> One's a dupe, and one's insane.
<wgrant> Ah, jelmer may be on the case as well.
<wgrant> We need a "cripple user until they are not doing crazy things any more" button :(
<wgrant> === Top 10 Durations ===
<wgrant>    190.98s  OOPS-2109ED42   Distribution:+questions
<wgrant>     30.57s  OOPS-2109EC14   Distribution:+ppas
<wgrant> Heh.
<wgrant> Distribution:+ppas is the same thing.
<wgrant> I saw it show up on the OOPS reports a couple of days back, didn't think much o fit.
<wgrant> Bug #872086
<_mup_> Bug #872086: Distribution:+ppas and Distribution:+questions issue unlimited queries when memo=0&direction=backwards <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/872086 >
<StevenK> lifeless: O hai
<StevenK> Oh dear, G in #linode
 * StevenK tries to not confuse the channels
<jtv> StevenK, wgrant: I've got a devastating monster horror branch that overthrows everything the buildd-manager does.  Mind if I try it out on dogfood?
<wgrant> Oh god it burns it burns.
<wgrant> We didn't have too much luck with buildds there last night.
<wgrant> They didn't seem to want to... well, they didn't do very much at all.
<jtv> That would beâ¦
<jtv> â¦âbad,â right?
<wgrant> That's a bit insensitive. They prefer the term "dogfood".
<jtv> Ah, these modern euphemisms.
<jtv> The branch I'd like to test is going to be a tough one.  It basically puts the entire scanning loop in read-only transactions, with a few explicit write transactions that commit immediately (rather than waiting for a response from a slave etc.)
<wgrant> Yeah, saw that.
<wgrant> Unfortunate that you have to put the transaction stuff into the model code.
<jtv> Very.
<jtv> I can only hope it'll be one step on the way to a good redesign.  At least we'll know where the database changes are.
<wgrant> Yep.
<jtv> Two things really annoy me about it: (1) it's now painfully hard to work out the transactional behaviour and inspect it for semantic safety, and (2) it's actually been this way all the time but it was implicit so you couldn't even see what was going on.
<wgrant> Yup.
<jtv> I wonder if this thorough twistification was really the best solution to the performance-bottleneck problem.
<wgrant> Well, the problem is that it wasn't a thorough Twistedification.
<jtv> True, but I probably mean it in a different respect:
<jtv> it probably goes against everything the Twisted crowd believes in, but instead of making entire protocol surfaces asynchronous,
<jtv> it might have been better to identify just one or two high-latency interactions where async could be made safe.
<jtv> I say âmightâ because whether it would have helped enough depends on details I have no knowledge of.
<wgrant> That's how it was initially, I believe.
<wgrant> It was a partial asyncification that jml and bigjools replaced.
<wgrant> With a full asyncification.
<jtv> I thought they started with the synchronous loop.
<wgrant> I think some downloads were async.
<wgrant> Some of it was, at elast.
<wgrant> least
<wgrant> But not much.
<jtv> Ah, true, yes.
<jtv> So maybe that approach had simply been milked dry already.
<jtv> wgrant: I'm still wondering if there's a safe place we can take this code.  Here's one thought: associate a different master store with each builder.
<jtv> Or just give each a thread â I know GIL contention is bad but the structure we have now seems to assume that everything spends most of its time blocked anyway.
<wgrant> That would solve some of the issues.
<jtv> I also see a comment in there: âWe need to re-fetch [â¦] as the Storm store is invalidated over transaction boundaries.â
<jtv> I know SQLObject did that implicitly, but Storm just re-fetches the object if necessary, right?
<wgrant> jtv: I believe it will always refetch in a new transaction.
<lifeless> StevenK: hi?
<StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/kill-set_up_tacfile_logging/+merge/78908 << crack, or am I doing something good?
<lifeless> StevenK: incomplete; you need to migrate not just delete
<jtv> wgrant: I know I should be grateful that Twisted is here to liberate us from structured programming and transparent multitasking and bring us the awesome scalability of single-threading.  But on days like this I'm just not feeling it.  I'll grab some more coffee.
<lifeless> StevenK: what set_up_tacfile_logging does is bridge python logging to twisted.python.log logging
<lifeless> StevenK: I filed a bug on this last week
<lifeless> StevenK: I have a branch that overlaps with this too, so we'll conflict. You might want to hold off a few days
<wgrant> Mmm.
<wgrant> I think deleting it is good.
<wgrant> I believe it's doing more harm than good.
<wgrant> Causing hangs, for example.
<lifeless> it needs to be addressed, yes. Just deleting however will cause stderr spew
<wgrant> Better than what we have now.
<lifeless> different
<lifeless> still a problem.
<lifeless> why do you think it is causing hangs ?
<wgrant> I know it is.
<wgrant> A unicode exception (like, say, uploading a changes file with a key that's on the keyserver but not registered in LP) will cause the upload to hang.
<lifeless> how
<wgrant> Yes.
<lifeless> no, really. How.
<wgrant> I don't know. I drowned in Twisted before I could work it out.
<wgrant> But it seems to recurse and then melt.
<lifeless> python logging should be eating unicode formatting errors.
<lifeless> anyhow, if you have a SSCCE it should be easy to address that
<wgrant> utilities/start-dev-soyuz.sh; gpg --keyserver keyserver.launchpad.dev --send-key somekey; debsign -ksomekey something.changes; dput lpdev:anyything something.changes
<StevenK> lifeless: Yes, I did that branch due to the bug you filed
<lifeless> StevenK: ah, I wasn't sure as the bug wasn't linked ;)
<StevenK> Is now :-)
<lifeless> heh
<lifeless> StevenK: can you WIP that branch for now ?
<StevenK> Done
<lifeless> than ks!
<lifeless> anyone happen to know if we have semi-sane configs for rabbit yet? (e.g. not None etc)
<lifeless> in prod
<wgrant> lifeless: We don't.
<lifeless> k, so I need a review for oops 0.0.9 (lp:~lifeless/oops/fallbacks)
<lifeless> https://code.launchpad.net/~lifeless/python-oops/fallbacks/+merge/78911
 * StevenK looks at pofile-stats-daily and runs screaming, his eyes bleeding
<jtv> StevenK: if you need help with that, I'm here for you.
<jtv> Right after lunch.
<StevenK> It last ran 2 months ago
<StevenK> And it takes on average 10 seconds to do one POFile.
<StevenK> And given the query in IPOFile._countTranslations(), I'm unsurprised.
<wgrant> (132 rows)
<wgrant> Nearly there.
<StevenK> wgrant: For what?
<wgrant> StevenK: That's the number of remaining private multi-pillar bugs that aren't in known evil projects or tagged apport-crash.
<lifeless> wgrant: can I nab you for a small follow on review - the changes to oops to support fallbacks from oops-amqp
<lifeless> jamesh: ping (touching base on oops migration)
<wgrant> lifeless: "if the first publisher doesn't and returns None"
<lifeless> blah, You want english now ?
<wgrant> 'fraid so.
<lifeless> well, it is.
<lifeless> But it can be clearer. how about
<lifeless> 'if the first publisher does not publish and instead returns None'
<wgrant> True.
<wgrant> 78+ if id:
<wgrant> Do you want to make that explicitly "is None"?
<lifeless> I'm torn
<lifeless> I'm thinking of rewriting the docs to say 'evaluates nonzero'
<wgrant> You need to do one of those.
<lifeless> I don't think an oops id of 0 or '' is useful
<lifeless> do you ?
<wgrant> Not useful, but it's possibly also not useful to special-case them.
<lifeless> there is a case for 0 in a single-creator monotonic allocation scheme, but bleh.
<lifeless> wgrant: well, they aren't special cased at the moment
<lifeless> (other existing code also just tests for if report.get('id'):)
<lifeless> wgrant: contributors shouldn't be a wiki page
<wgrant> I take it that poolie's +affectingbugs fix landed, then? :)
<lifeless> yes
<lifeless> wgrant: how hard would it be to switch that to be a blat to lpqa?
<wgrant> lifeless: You could just change your subscription regex to exclude it :P
<wgrant> But it wouldn't be hard.
<StevenK> lpqateam seems like ... the wrong place
<lifeless> I am open to any place
<lifeless> just wiki seems wrong to me - its not actually an editable page
<lifeless> wgrant: so, that review.
<lifeless> wgrant: I presume ESHINY happened
<wgrant> EMAWSONNEEDSMORERAM
<lifeless> I've pushed up fixes around those two points
<lifeless> bbiab
<poolie> wgrant: and my patch fix it?
<wgrant> poolie: Hm?
<poolie> <wgrant> I take it that poolie's +affectingbugs fix landed, then? :)
<poolie> seems to work for lifeless; that's a good sign
<poolie> hm, but not when sorted, oh well
<wgrant> No, that shouldn't even be on qastaging yet.
<wgrant> lifeless complained about dev.launchpad.net/Contributions
<nigelb> whats wrogn with it?
<wgrant> I guess lifeless subscribes to the whole wiki.
<poolie> oh, i see
<poolie> it's through pqm but not yet deployed
<nigelb> ohlol
<poolie> wbn to have it built in
<lifeless> nigelb: its an advert, not shared-editable-docs
<nigelb> lifeless: hehe, but its not a qareport either :)
<nigelb> Want to get launchpadcontributions.com? :D
<lifeless> sure it is; its a blamelist
<lifeless> :>
<lifeless> this is kindof an ohloh feature
<nigelb> not entirely
<nigelb> we only measure external contributors.
<lifeless> yes, and ?
<lifeless> I mean, for 'measure thing about code and contributions' - thats what ohloh have specialised in
<lifeless> now, I'm not saying we shouldn't do it ourselves, what with geeknet having bought ohloh (so no longer a neutral web service), but as a feature, thats the space its in
<poolie> didn't jml say 'every wiki page is a prototype of a web app'?
<lifeless> something very close to that
<lifeless> however, this is already not a wiki page ;)
<jtv> StevenK, wgrant: the dogfood builders look happyâ¦ mind if I try upgrading the codebase, merging my branch, and triggering some builds?
<wgrant> jtv: Go ahead.
<jtv> OK
<mrevell> Guten morgen.
<adeuring> good morning
<jtv> stub: seen the ongoing work on index-only scans?  Exciting.  Though Simon feels they're nowhere near as useful as people think.
<lifeless> mwhudson: I had a q for you actualy :P but now I forget what it was
<mwhudson> lifeless: heh, well, you have a few seconds i guess :)
<mwhudson> lifeless: i updated https://code.launchpad.net/~mwhudson/launchpad/permit_timeout_from_features-on-participation-bug-861510/+merge/78355 on the off chance it was about that
<bigjools> wgrant: can you review this please? https://code.launchpad.net/~julian-edwards/meta-lp-deps/add-rabbit-management/+merge/78930
<lifeless> rvba: bug 872077 needs an LP task
<_mup_> Bug #872077: Import of crosstool-ng from Mercurial fails with unknown revid <Bazaar Hg Plugin:New> <NULL Project:Triaged> < https://launchpad.net/bugs/872077 >
<lifeless> rvba: (because it would'nt be fixed if bzr-hg fixed it and we *didn't* deploy a new bzr-hg
<wgrant> bigjools: Doesn't it need to be in CAT?
<wgrant> bigjools: apt will use the new version if it's there.
<bigjools> wgrant: yes, but Tom wanted this ....
<rvba> lifeless: ok, thanks.
 * bigjools shrugs
<wgrant> bigjools: Depending on rabbitmq-management is sufficient.
<wgrant> It won't install unless there's a matching version of rabbitmq-server.
<wgrant> And that's all we care about.
<bigjools> is it worth removing the dep on -server?
<wgrant> No.
<bigjools> doesn't make any difference :)
<wgrant> But there's no point versioning them unless we actually have known version constraints.
<bigjools> that's what I thought
<wgrant> Which we don't.
<bigjools> this is probably being used as a cheating kind of way to figure out if everything was backported to cat properly
<wgrant> If rabbitmq-management installs, it has been.
* gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 269 - 0:[irc://irc.freenode.grahambinns.com/#%23%23%23%23%23%23%23Segmentation fault (core dumped)
<G> hey silly question but the rocketfuel scripts upgrade to a special/newer version of bzr right?
<jml> Don't think so.
<nigelb> G: check the PPA's it adds?
<bigjools> they don't
<bigjools> only the bzrlib that LP uses
<G> oh so, bzrlib gets changed, as in the one in /usr/lib64/python2.7/dist-packages by any chance?
<bigjools> no, the buildout one
<G> okay then
<wgrant> rocketfuel-setup probably adds a bzr daily PPA.
<wgrant> Or maybe only bzr beta.
<wgrant> bzr stable, even.
<wgrant> BZR_PPA="deb http://ppa.launchpad.net/bzr/ppa/ubuntu ${DISTRIB_CODENAME} main"
<G> wgrant: ahhh thanks, yeah, just cehcked my sources.list
 * G should get back to tackling a couple of LP bugs, but seem to run into a completely seperate issue first
<soren> gmb: Was that topic change intentional?
<soren> gmb: All of it, I mean?
<G> soren: I think it's a reference to more than 256 crits
<G> my observations have been each OCR has a different 'joke' to put there
<soren> G: The irc://irc.freenode.grahambinns.com/ bit?
<soren> Ok.
<G> it nxdomain's so it's not a phishing attempt :)
<gmb> soren: Hah, no. I copied and pasted; didn't realise that my IRC client was having a bad day :).
<gmb> (Well, probably my proxy...)
 * gmb goes to fix it.
<soren> It used to say: "| 0:[########Segmentation fault (core dumped)"
<soren> oh
<soren> gmb: It used to say: "| 0:[########Segmentation fault (core dumped)"
<gmb> soren: I see "| 0:[irc://irc.freenode.grahambinns.com/#%23%23%23%23%23%23%23Segmentation fault (core dumped)"
 * soren hugs topic-diff.pl
<gmb> Is that correct?
<gmb> No.
<soren> That's what i says now, yes.
<bigjools> I'd be happy to see the lame attempt at humour removed
<gmb> bigjools: Ah, see, I  couldn't tell it was supposed to be funny, because bip segfaulted yesterday. I thought it was an error.
 * gmb removes it.
<bigjools> heh
* gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 269
<gmb> Whomsoever can be bothered to add a progress bar can add one at their leisure.
<soren> "[#-] (not to scale)"
<gmb> Heh.
<nigelb> lol
<bigjools> that's funny :)
<nigelb> heh, someone should add that :)
<jtv> Argh.  Ayiiee.  Test doubles don't hold up very well across transaction boundaries.
<bigjools> wgrant: are you going to approve that meta-lp-deps branch?
<wgrant> bigjools: No, I don't agree with it.
<wgrant> We care that rabbitmq-management installs.
<wgrant> Not what version it is.
<bigjools> wgrant: in that case, please reply to RT 48032
<wgrant> Sure.
<bigjools> thanks
 * lifeless deletes tests that test operational config.
<bigjools> !
<lifeless> bigjools: oops-tools have tests that there is a particular summary report; the summary reports for an install are done by pointing and clicking in the admin interface, *or* by a django migration
<lifeless> it should be clear that the latter isn't relevant to trunk :)
<wgrant> bigjools: Done.
<bigjools> thanks
<bigjools> bin/test is now segfaulting ...
<lifeless> \o/
<lifeless> I'm sorry Dave, I can't let you test that!
<bigjools> :)
<bigjools>   Set up canonical.testing.layers.LibrarianLayer in 23.685 seconds.
<lifeless> 3 tests to go. Tomorrow's task.
<bigjools> *cry*
<bigjools> TDD is painful with LP, really painful :(
<bigjools> hmmm bin/test is segfaulting on oneiric and natty
 * nigelb screenshots and frames.
<lifeless> theory: there are no new bugs, only more or less obvious duplicates
<nigelb> Well, that depends on the kind of bugs already filed.
<nigelb> If you file a bug saying -  "LP sucks", everything can dup to it :P
<nigelb> I believe there's always edge cases and newer ways to break things.
<wgrant> bigjools: Do you think someone from your squad might be able to look at bug #872086 soon?
<_mup_> Bug #872086: Distribution:+ppas and Distribution:+questions issue unlimited queries when memo=0&direction=backwards <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/872086 >
<wgrant> bigjools: It only appeared yesterday, but causes appservers to be useless for three minutes, and cronspam.
<bigjools> I'll schedule it
<wgrant> Thanks.
<bigjools> googlebot... awesome
<wgrant> Yep.
 * bigjools â lunch
<allenap> gmb: I've got a nice branch lined up for you :) I lie, it's not nice. (It's not that bad either.) Are you interested? https://code.launchpad.net/~allenap/launchpad/bug-stats-key-error-bug-871076/+merge/78870
<gmb> allenap: Sure.
<allenap> Thanks.
<rvba> adeuring: Hi, can I ask you a quick question about the code in lib/canonical/launchpad/webapp/batching.py?
<adeuring> rvba: sure
<rvba> I know you've been working in this area lately.
<rvba> adeuring: If you go to the definition of reverseSortOrder in that file,
<rvba> In there there is a sub function called invert_sort_expression
<adeuring> yes
<adeuring> morning deryck
<deryck> Morning, adeuring
<rvba> The parameter name is 'expr' but it manipulates 'expression'.
<rvba> adeuring: Maybe I'm seeing straight but why is it not a problem? :)
<rvba> I'm not* seeing straight even
<adeuring> rvba: i think you are right: s/expression/expr/ would make the function look much more sane. but let me check a bit more...
<rvba> adeuring: Thanks for looking into it, I just randomly came across that code and it looked strange ;)
<adeuring> rvba: yes, the code is ismply nonsense. I am a bit surprised that it worked at all...
<adeuring> rvba: thanks for spotting this!
<rvba> I confess I was surprised too.
<rvba> You're welcome.
<rvba> adeuring: The only solution for this to work is that this code is never called :)
<adeuring> rvba: well, it is called in __init__()
<rvba> Indeed.
<adeuring> rvba: >>> [x for x in range(2)]
<adeuring> [0, 1]
<adeuring> >>> x
<adeuring> 1
<adeuring> so, expression is visible to the function
<adeuring> but that's purely accidental..
<rvba> I see, well spotted.
<deryck> abentley, adeuring -- https://dev.launchpad.net/Projects/CustomBugListings
<gmb> allenap: approved with some comments
<bigjools> gmb: when we do an expiration countdown for incomplete bugs, how does that work when say only one of the tasks is incomplete?
<gmb> bigjools: I have no idea, I'm afraid. You would hope that the countdown would only appear for the bug in that context, but I don't know whether that's the case or not.
<bigjools> gmb: the countdown is bug-wide it seems, so ...
<bigjools> well let me explain
<bigjools> see these 2 bugs
<bigjools> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/849414
<_mup_> Bug #849414: plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events() <apport-crash> <bugpattern-needed> <i386> <oneiric> <rls-mgr-p-tracking> <plymouth (Ubuntu):Incomplete> <plymouth (Ubuntu Oneiric):Incomplete> <plymouth (Ubuntu Precise):Incomplete> < https://launchpad.net/bugs/849414 >
<bigjools> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/553745
<_mup_> Bug #553745: plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events() <apport-collected> <apport-crash> <bugpattern-written> <i386> <iso-testing> <lucid> <maverick> <oneiric> <patch-forwarded-upstream> <rls-mgr-p-tracking> <Plymouth:Confirmed> <plymouth (Ubuntu):Incomplete by canonical-foundations> <plymouth (Ubuntu Lucid):Triaged by canonical-foundations> <plymouth (Ubuntu Maverick):Triaged by canonical-foundations> <plymouth (Ubuntu Natt
<bigjools> the former has got "expiration in 59 days"
<bigjools> the latter has not, despite it having 2 incomplete tasks
<bigjools> I don't know if this is a bug - just looking to triage something
 * gmb looks
<gmb> bigjools: I don't think it's a bug. See the conditions on https://help.launchpad.net/BugExpiry.
<gmb> The latter has been assigned to someone (several someones) so it doesn't count for expiry.
<bigjools> ah ok
 * gmb didn't know those conditions until just now :)(
<bigjools> heh, thanks for finding them, I didn't know that page was there
<allenap> gmb: Thanks!
<gmb> bigjools: Nor did I. There's a (find out why) link in the expiry notice, but I only spotted it the third time I looked at the bug.
<bigjools> hidden in plain sight
 * gmb -> late lunch
<abentley> deryck, adeuring: allenap presented mustache: http://mustache.github.com/
<adeuring> abentley: thanks!
<abentley> deryck, adeuring: They call it logic-less templates, but thankfully, they're lying; they support loops and conditionally-rendered blocks.
<deryck> abentley, yeah, I thought the same thing when I saw the guy from Yahoo.
<cr3> has anyone ever felt the need to check code before committing for code that might've been left around when exploring? I know that bin/lint in launchpad runs pocketlint which would detect things like pdb statements left behind by accident, but could it detect other things like behind perhaps identified with a TODO or FIXME comment?
<sinzui> cr3, Given the large number of those plus XXX: comments those will be spurious warnings
<sinzui> cr3, I think a switch is needed to support those kinds of comments so that they only warn when you want to get rid of them
<cr3> sinzui: I'm thinking dedicating a particular keyword for warnings that should not be committed, so perhaps keeping XXX and only warning about TODO for example
<bigjools> TODO would be one I'd be interested in
<bigjools> I use TODO markers a lot, the bzr "todo" plugin is great
<cr3> sinzui: I've often reviewed merge requests, noticed some weird code, commented on the request only to find out some code was left behind by accident. This has a long turnaround time and I wouldn't be surprised it happens regularly, so might be worth considering.
 * jml accepts donations
<cr3> bigjools: hm, that might be exactly what I'm looking for. thanks!
<bigjools> jml: :D
<sinzui> cr3, We see them in reviews and ask why the issue in the comment was not address. We often require a bug reported about the issue if the work is incomplete.
<sinzui> cr3, I think a lot of those kinds of comments are spurious, which is what I think your concern is. Lp has a lot of such comments because the issue described in the comment is not important.
<danilos> hum, anybody using balsamiq in oneiric?
<sinzui> danilos, I was
 * sinzui checks if it still works
<sinzui> danilos, my old 32bit installation of air + MockupsForDesktop_1_6_50.air works
<bigjools> jelmer: any idea why this import is failing? https://code.launchpad.net/~tillkruess/humanstxt-wp-plugin/trunk
<jelmer> bigjools: the repository contains invalid data, which isn't properly encoded and makes us unable to access all history
<bigjools> jelmer: ok thanks
<danilos> sinzui, right, I guess I'll have to investigate the 32-bit installation which has changed in oneiric then
<jml> so, you guys test javascript without a browser, right? how do you do that?
<jml> (and would it work for jquery code?)
<abentley> deryck, abel: random thought: mustache rendering would need to use the web service object representation to be reusable, so the server-side implementation could be a web service-consuming micro-service.
<deryck> abentley, thinking through that statementâ¦. sorry was on call.
<deryck> abentley, so stepping into the territory of "web service consuming micro service" from "another tempting option" makes me slightly nervous.
<abentley> deryck: is just random thought.
<deryck> abentley, mostly due to keeping this scoped right to deliver on time.
<deryck> abentley, right.  I'm fine with that as the next logical step for this.
<bigjools> jelmer: is there anything they can do to fix it, BTW?
<jelmer> bigjools: removing the invalid data from the repository, which stops the svn libraries from falling over
<jelmer> bigjools: that's a fairly intrusive process though, which requires taking the repository offline
<bigjools> jelmer: how can they find out what's invalid? It wasn't obvious to me from the log
<jelmer> bigjools: the first available revision is 108326, so most likely 108325 is problematic
<bigjools> jelmer: ah a bad revision.... gotcha
<bigjools> thanks jelmer
<jelmer> bigjools: svn itself falls over too:
<jelmer> svn log -v --xml --with-all-revprops http://plugins.svn.wordpress.org/ -r108325
<bigjools> heh
* gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 269
<cr3> why does launchpad say that my project has three open bugs in the right-hand summary when there are only two in the main listing: https://bugs.launchpad.net/launchpad-results/+bugs
<jelmer> cr3: IIRC that's the result of caching - could it be that there were 3 open bugs a while ago?
<cr3> jelmer: there were probably more but I'll wait 24 hours to see if the cache gets refreshed correctly
<cr3> jelmer: caching is hard to get right :(
<jelmer> cr3: yes, and arguably it's not really useful to cache this kind of thing if there are only 3 results
<jelmer> cr3: btw, is launchpad-results the result of the speccing you were doing earlier to store subunit results in Launchpad?
<cr3> jelmer: yep, https://dev.launchpad.net/LEP/ResultsTracker
<cr3> jelmer: you were actually a use case on that LEP but the primary use case because the Ubuntu Friendly programme: https://wiki.ubuntu.com/UbuntuFriendly/Website
<cr3> s/because/became/
<jelmer> cr3: ah, neat!
<jelmer> I should have a closer look at it some time
<cr3> jelmer: here's a temporary EC2 instance that has some interesting data already: http://107.20.153.224/
<cr3> jelmer: the /systems page has almost 2000 models submitted by the community, so it's getting fun to look at
<jelmer> cr3: wow, that's really nice
<jelmer> cr3: how do the submissions work, is it subunit based or something else?
<cr3> jelmer: that information comes from the launchpad hardware database which only stores checkbox submission files. if you happen to have a bunch of subunit files, those could be uploaded as well
<jelmer> cr3: ah, cool
<cr3> jelmer: I'd also like to support the document format from the linaro team and junit commonly used in hudson/jenkins so that they could all be piped into the results tracker... all your tests are belong to us
<jelmer> bzr (and the bzr plugins) and samba generate subunit so if that's somehow supported that's great
<cr3> jelmer: oh, another project would be to probe the bugs in launchpad for those reported by apport to create system entries in the results tracker too
<bigjools> night all
<jelmer> have a nice evening bigjools
<abentley> deryck: Where I've gotten so far with Mustache: http://people.canonical.com/~abentley/mustache.png
<deryck> abentley, very nice.
<deryck> working from mockups is so nice :)
<abentley> deryck: indeed.
<lifeless> morning
<deryck> Morning, lifeless
<mwhudson> benji: did you see my update to https://code.launchpad.net/~mwhudson/launchpad/permit_timeout_from_features-on-participation-bug-861510/+merge/78355 ?
<benji> mwhudson: I hadn't.  Thanks for pointing it out.
<benji> mwhudson: I've responded to the MP (with approval).
<mwhudson> benji: \o/ thanks
<mwhudson> (it passed ec2 overnight btw)
<bdmurray> There was some work done on Incomplete searches recently right?
<bdmurray> using the API and search for "Incomplete" as a status used to return those with and without a response
<bdmurray> it no longer does this and just returns 0
<lifeless> there was yes
<lifeless> hum
<lifeless> please file a bug
<bdmurray> is bug 872496 sufficient?
<_mup_> Bug #872496: All package stats now report zero "Incomplete" bug reports <Launchpad itself:New> <Ubuntu QA Website:New> < https://launchpad.net/bugs/872496 >
<lifeless> its arguably a regression (but since its inconsistent with bug searches outside the API, its arguably just a harmonisation and correct)
<bdmurray> inconsistent how?
<lifeless> look at the advanced bug search form
<lifeless> there are two incomplete statuses there, and no unified one
<bdmurray> so I should rewrite all my searches to use incomplete with and incomplete without?
<lifeless> bdmurray: well, theres no reason we can't restore the old behaviour; I'm surprised it broke in fact :(
<lifeless> but yes, it would be more precise to search with both states
<lifeless> and it may work immediately if you do so
<lifeless> sinzui: hi
<lifeless> sinzui: I'll try to catch up with you later, today I'm making up for a fragmented day yesterday, but am kindof here
<kb9vqf> Quick question--what is the easiest way to turn off debugging stack traces on a production instance of Launchpad?
<kb9vqf> usually they appear when a user fumble-fingers a URL
<wgrant>  kb9vqf canonical.show_tracebacks is the setting.
<kb9vqf> wgrant: In which file?
<wgrant> kb9vqf: launchpad-lazr.conf in the config that you're using.
<kb9vqf> ok, thanks again! :)
#launchpad-dev 2011-10-12
* StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugs: 269
<mwhudson> hm
<jelmer> hmm indeed!
<mwhudson> there is a LOT of crack in canonical.launchpad.webapp :(
<mwhudson> is read only mode officially dead now?  can we just nuke the relevant code from orbit yet?
<mwhudson> lifeless: ^ ?
 * mwhudson settles for nuking 6 year old crack instead
<wgrant> mwhudson: There is, yes :(
<wgrant> mwhudson: We're preserving RO-mode for a few months.
<wgrant> Just in case.
<mwhudson> ok
<wgrant> The rest of canonical.* is nearly cleaned out, but canonical.launchpad.webapp is particularly bad and mostly untouched.
<mwhudson> wgrant: i just pushed a branch called i-dont-believe-for-a-minute-that-steveIsFixingThis
<wgrant> Heh.
<wgrant> Hey, it's not yet 7 years old.
<mwhudson> it was hilariously old and stale _when i started working on launchpad_ though
<wgrant> Yes.
<wgrant> There's lots of that :)
<wgrant> Every couple of weeks I spend a few hours cleaning up canonical.*... eventually the maintenance squads will do that, I suppose, but it's a very long-term "eventually".
<mwhudson> luckily i don't have the constraint of being paid to work on lp :-)
<lifeless> mwhudson: not quite dead yet
<wgrant> lifeless: You're not here -- go away.
<lifeless> mwhudson: but yeah, I just need to tweak mthaddon a bit about it :)
<mwhudson> lifeless: ok
<lifeless> wgrant: I had a 6 hour unexpected medical thing yesterday
<lifeless> wgrant: so I'm partly here
<wgrant> Ah.
<wgrant> Carry on, then.
<mwhudson> wgrant: if you have a spare minute, can you search for 'thread_locals' in canonical.launchpad.webapp.publication?
<mwhudson> i think it's complete crack and don't see at all why it's stored on a thread locals object
<mwhudson> ... unless publications are process global or something...
<wgrant> Used by publication and servers. This can't be anything good.
<wgrant> Oh, thread_locals is only publication.
<mwhudson> wgrant: i think the one in servers is different
<wgrant> Yes.
<mwhudson> and is there because of zope crack rather than old pointless crack
<mwhudson> (i think)
<wgrant> Yeah.
<wgrant> I don't think the publication is actually per-request.
<mwhudson> i think it is :-)
<mwhudson> the only way i can imagine checking is a print statement though :/
<wgrant> It's been several years since I last dealt with this stuff. I forget how it is stuck together.
<mwhudson> yeah fair enough
<wgrant> (this was before LP was open)
<mwhudson> don't waste too much time on it
<wgrant> Ewww canonical_url constructs its own request.
<wgrant> Forgot about that bit.
<mwhudson> haha\
<mwhudson> yes that is particularly terrible
<mwhudson> (i found that earlier too)
<wgrant> Hmm, so you're right, the publication is normally per-request.
<wgrant> But then why do most of its methods take a request...
<lifeless> the word baroque comes to mind
<mwhudson> oh my yes
<mwhudson> i wish the person who came up with all this was a bit less able to cope with complexity
<mwhudson> aaaaaaa
<mwhudson> wgrant: i'm not sure publications _are_ request local
<mwhudson>         publication = self._publication_cache.get(publication_class)
<mwhudson>         if publication is None:
<mwhudson>             publication = publication_class(self._db)
<mwhudson>             self._publication_cache[publication_class] = publication
<mwhudson> (this is in zope.app.publication.httpfactory)
<wgrant> mwhudson: But the RequestPublicationFactories take the class as a factory...
<wgrant> Are they lying?
<mwhudson> "sort of"
<wgrant> Stuff like this is why I've been focusing more on the layer above. The cruft that integrates with our Zope integration cruft.
<wgrant> Not our Zope integration cruft itself.
<mwhudson> yeah fair enough
<wgrant> Because that is messy and awful :(
<mwhudson> wgrant: do you want to do the honours? https://code.launchpad.net/~mwhudson/launchpad/i-dont-believe-for-a-minute-that-steveIsFixingThis/+merge/79047
<wgrant> mwhudson: Done.
<mwhudson> wgrant: :-)
<StevenK> mwhudson: I came across that code the week I started on LP ... it was unsettling
<huwshimi> anyone else getting an oops when visiting https://code.launchpad.net/~launchpad-pqm/launchpad/devel/+activereviews ?
<StevenK> NotOneError: one() used with more than one result available
<StevenK> Whee
<wgrant> That may be from the staticdiff migration...
<wgrant> But I don't see how.
<StevenK> huwshimi: https://code.launchpad.net/launchpad-project/+activereviews
<wgrant> They've been on the OOPS reports for a couple of weeks.
<wgrant> But https://code.launchpad.net/launchpad/+activereviews still works.
<StevenK> wgrant: You said you didn't agree with Julian's meta-lp-deps change?
<wgrant> StevenK: Correct. But he hasn't withdrawn it yet.
<StevenK> I think I agree with you, it's unnecessary
<huwshimi> wgrant, StevenK: I got that link from: https://code.launchpad.net/~launchpad-pqm/launchpad/devel and then clicking on "56 branches proposed for merging into this one."
<StevenK> huwshimi: Bug
<wgrant> There may already be a bug for it.
<wgrant> It's been on the OOPS reports for ages.
 * StevenK waits for wgrant's celeberal LP link to fire up.
<mwhudson> it means there are diffs that are linked to by more than one mp?
<StevenK> cerebral, even
<wgrant> It's somewhat concerning that PreviewDiff.branch_merge_proposal is meant to be a single object, but there's apparently no UNIQUE constraint on the table.
<wgrant> There are 35 offending diffs.
<wgrant> 33 have two references, 2 have 3.
<StevenK> But we dropped them all
<wgrant> Our changes couldn't have caused this.
<StevenK> Ah
<lifeless> 3 failures. 2 are doctests. -nearly- there.
<wgrant> lifeless: oops-tools?
<lifeless> yes
<lifeless> then its just purging / getting an ack on bundled code
<lifeless> and we're done. muahahahahahhahahahahaa
<lifeless> hahhaa
<lifeless> hahahah
<lifeless> hahahahahahaha
<lifeless> and the errors finally all fit in my terminal scrollback
<wgrant> StevenK: Actually, I think it may have been the staticdiff dropping that did it :(
<StevenK> Oh?
<wgrant> There's an undeclared uniqueness requirement on BranchMergeProposal.preview_diff
<wgrant> Whereas I believe staticdiffs were meant to be shared if they were between the same revisions.
<StevenK> This is upsetting.
<wgrant> So we will have converted a single shared staticdiff into a single shared previewdiff.
<wgrant> Which is illegal, although permitted by the DB.
<StevenK> Perhaps we should purge the illegalness and toss up a DB patch to add a UNIQUE constraint
<lifeless> wgrant: did you and sinzui talk about private N-pillar bug tasks ?
<wgrant> lifeless: A little, but the call was cut short.
<wgrant> lifeless: He intends to talk to stakeholders tomorrow about eliminating them.
<lifeless> ack
<lifeless> 1 test
<lifeless> at the loss of a little test coverage. Sob, don't know how ai shall cope
<lifeless> (no, I didn't just rm the test ..)
<StevenK> Ah, so you commented it out instead
<lifeless> I trimmed the sample data rather vigorously
<lifeless> the report has a lot less to show now:)
<poolie> lifeless: just for my education, could we cluster bugaffectsuser by user?
<poolie> to make the paging behaviour better?
<poolie> i guess the main objection would be if it commonly is queried by bug?
<lifeless> offhand - yes
<poolie> but i think not, or only to generate the counts
<lifeless> no, that wouldnt be an objection
<poolie> oh, why not?
<lifeless> generally indices are what matters
<lifeless> its only in rare cases (perhaps like this) that the table page order matters
<lifeless> currently there is no clustering
<lifeless> if you mean 'an alternative cluster would be by bug' - well yes
<lifeless> poolie: but clustering is a one-off in psql
<poolie> you mean it's not automatically maintained? i read that.
<poolie> so to try this i could: ask stub to on staging make the per-person index be clustered, and then reorder the table to cluster, and then see if it's faster?
<lifeless> well, on the next downtime
<lifeless> and we'd need to test on staging to see how long it takes, but it should be fast.
<poolie> right, but we could test it on staging fairly freely?
<lifeless> then you'd need to wait for a cold cache, and then you could try
<lifeless> yes
<poolie> it wouldn't need a particular downtime window to do it there?
<lifeless> its ok to tie staging up for a few minutes
<poolie> obviously the timing is pretty noisy, but if it's worth doing hopefully the effect would stand out from the noise
<lifeless> poolie: whats the current query you run? I want to check its plan
<poolie> it's in bug 866100
<_mup_> Bug #866100: bug search with affects_me=on times out <affectsmetoo> <bugs> <qa-ok> <timeout> <Launchpad itself:Fix Committed by mbp> < https://launchpad.net/bugs/866100 >
<poolie> that's a paste of the actual sql generated by my updated branch
<poolie> ok, so it seems affected_user_count is maintained redundantly (as it should be)
<poolie> well, not that it probably matters
<lifeless> poolie: so you have a problem
<lifeless> ignore the times for now
<lifeless> http://paste.ubuntu.com/706443/
<lifeless> different plans for user 2 and user 16
<lifeless> using different indices
<lifeless> clustering by person won't help for user 2 - that plan uses the bug,person index
<lifeless> well, won't help - it won't align completely.
<lifeless> it will mean the backing table data is in one place, but the index pages will still be scattered all over
<poolie> just looking at that query i'm a bit surprised
<poolie> i was mostly working on the 'affecting bugs in a product' but that query is all bugs for a user
<poolie> which is fine
<poolie> just thought i pasted for the other one
<poolie> so why a different plan for different users?
<lifeless> I've clustered staging and qastaging on bugaffectsperson__person__idx for testing purposes
<poolie> perhaps because it thinks selecting only bugs affecting user 2 won't reduce it much?
<poolie> it seems like a poor choice
<lifeless> it may be. This is where checking the stats targets may influence things
<lifeless> we can get more info out of new pg's as well - the explain/analyze stuff got sexy in 9.x
<poolie> is it on the roadmap for lp to switch to that?
<lifeless> yes
<poolie> are the stats going to be reasonably up to date on qas?
<lifeless> before the cluster yes
<lifeless> I need to updat ethem, one sec
<poolie> so https://bugs.qastaging.launchpad.net/~gz/+affectingbugs with 42 results, works ok in 2.66s
<poolie> ah, you and i work now too, though perhaps it's just warmed up
<poolie> btw did you read of http://www.thumbtack.com/engineering/googlebot-makes-post-requests-via-ajax/
<lifeless> win!
<lifeless> poolie: yes, its warm
<poolie> right, and mpt for instance fails once then works
<lifeless> poolie: it seems faster when hot, though there are confounding issues (clustering also compresses pages, which reduces bloat, which itself helps with performance - less parsing of data structures)
<poolie> it seems at the moment to consistently work first go on users with small lists
<lifeless> poolie: I would wait and see how your thing goes on prod
<poolie> https://bugs.qastaging.launchpad.net/~silbs/+affectingbugs  :)
<poolie> https://bugs.qastaging.launchpad.net/~sabdfl/+affectingbugs - only 40!
<poolie> ok
<lifeless> note that fully *half* of the poor performance on me cold is in bugtask:
<lifeless>                      ->  Index Scan Backward using bugtask_importance_idx on bugtask  (cost=0.00..153181.30 rows=341880 width=161) (actual time=189.469..46810.549 rows=5993 loops=1)
<lifeless>                            Filter: ((status = 10) OR (status = ANY ('{15,13,14}'::integer[])) OR (status = 20) OR (status = 21) OR (status = 22) OR (status = 25))
<lifeless>  46 seconds walking bugtask backwards by importance
<poolie> well, that would be very big, right?
<lifeless> 6000 rows
<poolie> that's going to be pulling out ~500,000 rows?
<poolie> oh, why so few?
<lifeless> LIMIT 8 OFFSET
<lifeless> 0
<lifeless> apparently I have 8 open affecting me bugs in the last 5993 filed bugs
<poolie> huh, i wonder how that got in there
<lifeless> if we raise that 8 (launchpad.dev) to 75 (launchpad)
<lifeless> we may see different plans etc
<lifeless> yeah, limit 75 switches the plan to the same as the original one for user 16
<lifeless> pg is pretty smart ;)
<poolie> i'm a bit confused why my code running on dev would have put a 'limit 8' into the query
<poolie> how would it know there are 8
<lifeless> the batch code does a count(*)
<lifeless> and if < limits to match
<lifeless> abel's work helps stop this crazy behaviour, but we have to roll it out over each collection individually
<poolie> wow, i see
<lifeless> anyhow, just a thing to watch for when copying test plans around :)
<poolie> so it really seems to me it ought to be using bugaffectsperson__person__idx
<lifeless> it does for user=2 with limit 75 offset 0
<poolie> even for you, that should cut down the bugtask table quite a lot
<lifeless> but not for limit 8 offset 0
<lifeless> its going to be assessing linear IO costs in there vs random
<lifeless> I think we need to do some benching and tweaking of these params
<poolie> ok, so, like you suggest i'll just wait for it on prod
<poolie> and - should we do anything further on clustering, or just if it's passing on prod leave it alone?
<lifeless> if it works don't touch it
<lifeless> :)
<poolie> :) yeah
<poolie> i have more context to understand abel's mail now, thanks
<poolie> so if this does time out, one thing i could try is to make that update in the bug list pages
<poolie> ok i might take a break, thanks
<wgrant> [A3
<poolie> +1
<lifeless> wgrant: you know stderr is meant for non-exceptional stuff :)
<lifeless> wgrant: per POSIX :)
<wgrant> lifeless: Meh.
<StevenK> It's Launchpad. Everything is non-exceptional because it's all NORMAL. :-(
<lifeless> wgrant: explicitly even.
<lifeless> StevenK: actually this is referring to apt-ftparchive
<StevenK> Sigh.
<StevenK> Bring on NMAF
<lifeless> StevenK: which does progress chatter on stderr (which is ok, but it should have a -q to get it to bare bones)
<lifeless> wgrant: (and btw, did you file a bug upstream ?)
<wgrant> lifeless: I didn't. It may be silencable.
<wgrant> (this is what was already done for the publisher, it just needed to be done for generate-contents-files too)
<lifeless>   -q    Quiet
<StevenK> -qq --shut-the-hell-up
<lifeless> from its help :)
<nigelb> Who's orange team?
<nigelb> The bug list mocks up look... WOW
<StevenK> nigelb: Deryck and the rest of the mafia
<nigelb> StevenK: heh
<nigelb> StevenK: I guess Teal is the assasin squad, seeing the amount of code you kill :P
<StevenK> Hahaha
<StevenK> I shall have to propose that to Curtis
<nigelb> heh
<nigelb> StevenK: "The Teal Assasins"
<StevenK> Yes, I was thinking that
 * G joins the group "Save the Ducks" and starts protesting :)
<StevenK> nigelb: "Assassinating bad code, one line at a time."
<nigelb> StevenK: bwahaha, I <3 it.
<nigelb> wgrant: ^^
<wgrant> Heh
<StevenK> G: You like duck typing?
<G> StevenK: no, but I happen to like all ducks, Teals included, not keen on the idea of assassinating them :)
<StevenK> wgrant: globalErrorUtility is defined in errorlog, and not exported :-(
<G> StevenK: in fact, the server that my irssi connection is located on, is named after the brown teal (Pateke)
<wgrant> StevenK: You're not meant to use getUtility(IErrorReportingUtility)?
<StevenK> wgrant: I have no idea :-(
<StevenK> G: I name my machines after things that can befall them that make them stop working
<StevenK> G: My mail server is 'mangled', my desktop is 'liquified'
<nigelb> You work machine is 'deleted'? :P
<G> heh, subconciously all my VPS' have been named after ducks :)
<nigelb> *your
<StevenK> nigelb: No, I do my work on liquified
<nigelb> StevenK: ha :)
<StevenK> liquified might prove to be true, sadly.
<StevenK> I think the lone fan needs a clean
<G> StevenK: you are going to put in water-cooling?
<StevenK> No, I'm just commenting that it is running a little too hot at the moment.
<wallyworld_> anyone tried to create_initialised_view(some_person, name='some_view') and got a LocationError: 'link-display-name-id'?
<wgrant> Bah.
<wgrant> Unity stole my text editor
<wgrant> It is still running, but nowhere to be found.
<jtv> wgrant: want to take this question?  https://answers.launchpad.net/launchpad/+question/173985
<wgrant> jtv: Julian should be here in 10, right?
<wallyworld_> wgrant: what's the easiest way to get a mp on qas that i can play around with?
<wgrant> wallyworld_: Create one fresh.
<wallyworld_> ok. i think last time i tried it didn't work but i'll try again
<wgrant> It should work OK, but you might need to get the runner run manually if you want a diff.
<wallyworld_> ah, i think i remember - i never get a diff
<wallyworld_> what's the runner script called?
<wgrant> Should be merge-proposal-jobs.py
<wallyworld_> thanks
<jtv> wgrant: yes
 * StevenK grumbles at the existance of cronscripts/run_jobs.py and cronscripts/process-job-source.py
<adeuring> good morning
<lifeless> bigjools: lp:python-oops-amqp :)
<bigjools> good morning
<jelmer> g'morning
<bigjools> :)
<bigjools> lifeless: someone's been busy
<lifeless> bigjools: things are coming together
<lifeless> bigjools: I'm going to do a spool-from-disk module for oops-datedir-repo, and then we can use that as the backing store when rabbit is down
<lifeless> bigjools: at which point, it will be time to land it all in LP trunk :)
<bigjools> lifeless: backing store?
<lifeless> fallback
<lifeless> if rabbit is awol and an oops is raised, what should happen...
<bigjools> depends what raises the oops
<lifeless> (answer: we write it to disk, and we have a separate mini task that picks it up from disk and sends it to amqp when amqp comes back)
<bigjools> oh wait - you're talking about pushing OOPSes down to rabbit?!
<jtv> danilos: I think I saw movement from your direction.  Want to review a very small translations change?  https://code.launchpad.net/~jtv/launchpad/bug-872646/+merge/79053
<lifeless> bigjools: its configurable (just depends on what publishers we setup), but this seems like a sane setup for all our services/scripts to me
<lifeless> bigjools: yes !
<bigjools> lifeless: ah! I thought you mean picking up rabbit problems and filing an oops
<lifeless> bigjools: no, though that is needed too
<lifeless> bigjools: that wouldn't get a generic name though :)
<wallyworld_> wgrant: sadly, running the job got rid of the "Updating Diff" message but no diff has been created
<wgrant> wallyworld_: Are the source and target branches in place?
<wallyworld_> not sure. the target branch is lp trunk, the source is one i did a few weeks ago
<wgrant> LP trunk probably isn't there.
<rvba> wallyworld_: if it's similar to what happens locally, you need to run the script *twice* to get a diff.
<wallyworld_> rvba: hi! twice? could be, although i suspect it's more due to qas not having the source and/or target branches available
* danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK, danilos | Critical bugs: 269
<danilos> jtv, r=me, as for the expiration period, 6 months is fine (we can certainly go lower, but doesn't really matter imho)
<jtv> danilos: that was my thinking too.  Thanks.
<jtv> Thought I might as well grab you as long as I still can.  :)
<danilos> jtv, heh, yeah, good point, I am also making a point of fixing some of the important translations issues :)
<danilos> bigjools, hi, do you happen to know if there are actual reasons for +configure-translations page to have builder-related stuff? (see https://translations.launchpad.net/ubuntu/+configure-translations)
<jtv> danilos: saw that, including the policy change on approval permissions.  Good news.
<jtv> danilos: bigjools & I are otop atm  :-P
<danilos> jtv, ask him if configuring arm builders is part of translations settings then :P
<bigjools> danilos: there is no reason at all for those 2 options
<danilos> bigjools, cool, thanks, I'll remove them from that page
<bigjools> danilos: ubuntu uses non-virt, everyone else virtual
<jtv> Pending team membership requests don't ever expire, do they?
<wgrant> No.
<jtv> Shouldn't they?
<wgrant> Why?
<jtv> I'd like to answer that in 2 ways.
<StevenK> "Here, let me your question with another question." ?
<jtv> 1. Why should they?  â Because if a request hasn't been reviewed after, say, a year, that amounts to âno you can't join.â
<jtv> 2. Why do you ask?  â Because we've got teams with eternally pending membership requests, caused by problem with person merger, that currently can't be got rid of.
<jtv> That wasn't so bad, was it?
<jtv> I know, I know, we should fix person merger.  But that's marked as Low.  We'll never have time for it unless it becomes super-urgent.
<jtv> It also won't help people who are affected by this problem already.
* StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: danilos | Critical bugs: 269
<poolie> "here, let me answer your question with unicode glyphs"
<jtv> poolie: oh â£ off
<nigelb> ....
<nigelb> Never a dull moment in this channel
<nigelb> jtv: As a team admin, I'd want to set a limit of number of days. If a person isn't approved within that time, they're not getting approved.
<nigelb> 1 year sounds arbitary
<nigelb> Oh, just saw your m/l post. /me will reply to it.
<jtv> nigelb: thanks for thinking about it though.
<nigelb> :)
<adeuring> danilos: fancy a review of a trivial MP: https://code.launchpad.net/~adeuring/launchpad/feature-flag-for-custom-bug-listings/+merge/79103 ?
<danilos> adeuring, r=me ;)
<adeuring> danilos: thanks :)
<G> jtv: btw, I was looking at the person merger, and I might take a stab at it?
<StevenK> We have a person merger :-P
<jtv> G: you mean fixing the bug itself?  That'd be great, but it looks like it could get complicated.
<bigjools> awesome, generate-contents-files is producing 646 oopses a day
<jtv> For example: person A is in team X, and person B is in team Y, and team Y is in team X, and you mere A & B.  What happens to each of the TeamParticipations?
<jtv> What happens when A and B are in the same team, but with different statuses?
<jtv> Etc.
<G> and yeah, I agree w/ nigelb that groups should set the expiration period per group, but really, shouldn't the default be more like 4-6 months, anything longer kind of implies an inactive group (or I guess indecision)
<G> jtv: a valid point, but is there actually any harm for the merged user to be a member in both groups?
<nigelb> jtv: Perefect interview question ;)
<nigelb> *perfect (oh the irony)
<jtv> G: Teams.  I would expect it to be simply impossible; it would probably violate a database constraint.
<jtv> nigelb: does sound like it, doesn't it?
<G> err yeah teams, sorry
<nigelb> It sounds like a fun problem to solve, because its non-trivial.
<jtv> Meanwhile, person A departs Manchester in a train heading towards London, where person Bâ¦
<nigelb> lol
<jtv> There can be especially nasty bugs if you delete one record; update another; move on; and later hit a database error when the two changes get flushed to the database in the wrong order.
<nigelb> ah. replication.
<G> as far as A & B in the same group w/ different status' shouldn't the higher status be the one kept? After all they'd have that access anyway
<G> ooooh yeah, replication
<jtv> nigelb: carefulâreplication is a different matter altogether.  I'm talking about a different layer of caching, within the ORM itself.
<jtv> The replication machinery won't make that mistka.e
<jtv> *mistake
<jtv> (speaking of irony)
<bigjools> bug 860245
<_mup_> Bug #860245: generate-contents-files.py should be a LaunchpadCronScript <qa-ok> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/860245 >
<bigjools> that ^^ is causing 1000+ oops a day
<nigelb> jtv: Oh right. I didn't realize ther was an ORM layer of caching
<jtv> bigjools: the bug is, or the fix is?
<bigjools> the fix
<jtv> Ouch.
<bigjools> the script logs at WARNING
<bigjools> sigh
<jtv> Ah that.
<wgrant> bigjools, jtv: Fix landed a couple of hours ago.
<jtv> You say critical, I say cheap karma.
<bigjools> wgrant: ah, good.  What's the bug?  I just filed a dupe
<nigelb> ~>
<nigelb> ~>
<wgrant> It was a 5-character fix so I didn't file one :P
<bigjools> :/
<G> jtv: hmmm I certainly get what you are saying, might try and think of a way to counter it
<jtv> G: looking at the bug again, I'm not even sure if there are TeamParticipations for these particular membership records.  It seems such a simple problem, butâ¦
<G> jtv: yeah, I haven't looked at the code, my checked out branch is a few weeks old, so I'm just updating it now
<nigelb> jtv: It may depend in which directions the accounts are merged wouldn't it?
<G> now if only postgres had a databasediff tool :P
<nigelb> (I'm guessing this is merging imported automatically created accounts with real ones)
<jtv> nigelb: probably, too.  Lots of choices to be made.  Sometimes you just have to start coding to find out what the choices are, and then you have to be willing to throw away your code and start over if need be.
<nigelb> jtv: Or start writing tests :)
<jtv> G: it's not perfect but you can create two dumps and diff them.
<G> jtv: yeah, thats what I was thinking
<nigelb> G: use meld to do the diffing
<jtv> nigelb: point takenâbut what I said about choices is also about behaviours to test for.  :)
<nigelb> ah. RIght.
<G> nigelb: ewwwwww
<G> (and yes, I've used that before)
<nigelb> G: It is *good* for diffing launchpad db dumps
<nigelb> I've used it.
<jtv> nigelb: did you follow up to my email?  If so, I'm not seeing your reply.
<G> nigelb: I'll just stick to diff -y :)
<nigelb> jtv: not yet. composing and multitasking
<jtv> Ah OK, no worries then.
<G> but yeah, I'm going to have a poke at the underlying bug
<jtv> G: cool!  There's always the chance that it's not as bad as it seems.
<G> jtv: one can only hope :)
<jtv> Where there's hope, there's code.
<G> I'm in a particularly bughunting mood this week
<G> jtv: in re: to your second e-mail, what about just a button, "Expire requests over [   ]  [days|weeks|months|years] old
<G> (and maybe in addition to that, a disabled by default option so it doesn't disrupt anyone)
<jtv> G: that's one of the worst words in software development: "just."  As in, âwhy don't you just implement [â¦]â :)
<jtv> See, you're already piling on features.  Great stuff, but every idea you add reduces the chances of anyone actually getting around to completing ig.
<jtv> *it
<nigelb> Unless you do it yourself.
<jtv> I don't know why I'm trying to rain on everyone's parade today.  Sorry about that!  I just mean: sometimes the most effective thing to put your creativity towards is how to minimize the change so as to optimize its chances of it getting done.
<jtv> I've often managed to sabotage myself by making things too pretty.
<G> jtv: sorry yeah, I was thinking a way of doing it simply, and then a future way that could implement your main suggestion, with code reuse and not stepping on anyone's toes
<jtv> This is going to be a fun thread on the list.  :-)
<nigelb> heh
<nigelb> BUt its launchpad, I've seen sensible heads prevail almost always.
<jtv> It's not a bad project, really!  But I wasn't being ironic.  I really enjoy seeing people think about this problem already.
<nigelb> Should. Resist. Temptation. To. Volunteer.
<deryck> Morning, all.
<bigjools> benji: I've got the corrupted launchpadlib password thing again (hence get a traceback), can you remind me where to reset it please?
<benji> bigjools: I don't remember last time very clearly.  It's either in a keyring (Gnome or KDE) or a file in ~/.launchpadlib
<benji> if you show me the traceback I can probably narrow it down
<bigjools> benji: thanks: http://pastebin.ubuntu.com/706700/
<bigjools> benji: funny thing is that it was working, then suddenly went bad :(
<benji> bigjools: that's really odd. That should be one of the ~/.launchpadlib directories, probably api.launchpad.net if you're using prod; if you would, tar it up and send it to me (there might be private things in there, so I wouldn't just put it on a bug report) then you can just rm -rf that directory and you'll have to reauthenticate but you should be back in business
<bigjools> benji: I removed ~/.launchpadlib already... :)
<benji> pfft
<benji> and you're still getting the error?
<bigjools> benji: AHA, I found it in kwallet
<bigjools> it threw me because it was in the gnome-keyring beforehand but I think oneiric has fixed that bug
 * benji tries to remember why in the world we're storing ini-formatted data in a keyring
<bigjools> and how does it get corrupted
<benji> we really need a bug for this (if there isn't one already)
<bigjools> I'll file it
<benji> is there any chance you ran two scripts at the same time?
<bigjools> ummm don't *think* so
<benji> We handle concurrency so poorly it was the first thing I though of.
<bigjools> bug 872853
<_mup_> Bug #872853: Crash due to corrupted password in keyring <launchpadlib :Triaged> < https://launchpad.net/bugs/872853 >
<bigjools> thanks for the help benji
<benji> bigjools: my pleasure; thanks for the bug
<bigjools> benji: so I am getting consistent corruption on consecutive uses :(
<bigjools> however the data looks ok in the wallet
<benji> "looks ok in the wallet"?
<benji> well, at least it's reproducable, that's a start
<bigjools> the contents of the "password" look ok
<bigjools> deryck: is this bug of interest to you guys, ref. the new bug page? https://bugs.launchpad.net/launchpad/+bug/872848
<_mup_> Bug #872848: List of remote bug watches is hard to find <ui> <Launchpad itself:New> < https://launchpad.net/bugs/872848 >
 * deryck looks
<deryck> bigjools, no, not for this project.
<bigjools> ok thanks
<deryck> Thank you. :)
<deryck> adeuring, http://people.canonical.com/~deryck/new-bugs-form.png
<adeuring> deryck: thanks
<deryck> adeuring, I'm making some notes for you too about this.
<dobey> hey guys
<dobey> anyone have any idea why a private bug would be viewable by someone, but the bug display would not show the task table area for the task, preventing them from changing the status/importance/etc?
<Daviey> bigjools: do you have a moment?
<bigjools> Daviey: OTP
<Daviey> bigjools: ok, thanks
<bigjools> will ping later
<dobey> http://ubuntuone.com/4Sl9zWfR83MC0x1s0b7hNm <- like this
<Daviey> bigjools: raising a bug, will PM it to you.
<Daviey> bigjools: when you have a moment, https://bugs.launchpad.net/launchpad/+bug/872870
<jcsackett> dobey: it's a currently in progress bug. (bug 865467). there's a workaround for now in the description.
<_mup_> Bug #865467: bug task missing from affects table because bug supervisor is not subscribed <disclosure> <regression> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/865467 >
<dobey> jcsackett: ah, thanks.
<jcsackett> sinzui: got a few moments to mumble?
* abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: danilos, abentley | Critical bugs: 269
<bigjools> Daviey: hey, I saw the bug
<sinzui> jcsackett, sorry, I was in conversation
<sinzui> jcsackett, I can mumble
<bigjools> thanks for triaging his bug sinzui
<jcsackett> sinzui: no worries.
<nigelb> dobey: they don't havve rights for the project perhaps?
<nigelb> dobey: Oh. that looks weird.
<Daviey> bigjools: yeah, wasn't as bad as i thought it was.  I thought it was odd, because it was a bug i thought i raised :)
<bigjools> indeed
<bigjools> Daviey: I removed the branch link so you can see it now
<Daviey> bigjools: thanks :)
* danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugs: 269
<nigelb> heh
<nigelb> github just got a slightly new design
<nigelb> the tabs remind me of old launchpad
<bigjools> GitHub - Yesterdays Technology, Tomorrow
<lifeless> moin
<mwhudson> grr why didn't permit_timeout_from_features-on-participation-bug-861510 land
<mwhudson> NonZeroExitCode: Test process died with exit code 2, but no tests failed.
<mwhudson> what does this mean?
<mwhudson> ah Exception: RabbitMQ server is not running.
<lifeless> -> allergy shot, bbiaf
<StevenK> sinzui: https://code.launchpad.net/~stevenk/launchpad/soft-oops-on-private-team-disclosure/+merge/79066
<sinzui> StevenK, This is how I read my oopses: less `ls /var/tmp//lperr/2011-10-04/* -t1 | sed '1!d'`
<sinzui> wallyworld, bug 1342
<_mup_> Bug #1342: Can't delete spurious "Affects" lines (bugtasks) from bug reports <canonical-losa-lp> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1342 >
<sinzui> I am sure that 4 digit number make you happy
<StevenK> wgrant: What did you suggest for the feature flag?
<wgrant> StevenK: disclosure.log_private_team_leaks, perhaps.
<poolie> huwshimi: http://www.codinghorror.com/blog/2008/02/the-ultimate-unit-test-failure.html
<poolie> > "We are not very important because we don't cut code." (A boo and hiss from the audience.)
<huwshimi> poolie: Interesting. Makes me happy that our feature development has moved to a design first model :)
<poolie> did you read that thing about amazon soa?
<huwshimi> poolie: I don't think so
<huwshimi> poolie: Link?
<poolie> join canonical-tech :)
<poolie> http://buu700.com/steverant
<poolie> > Jeff Bezos is an infamous micro-manager. He micro-manages every single pixel of Amazon's retail site. He hired Larry Tesler, Apple's Chief Scientist and probably the very most famous and respected human-computer interaction expert in the entire world, and then ignored every goddamn thing Larry said for three years until Larry finally -- wisely -- left the company. Larry would do these big usability studies and demonstrate beyond any shred
<poolie>  of doubt that nobody can understand that frigging website, but Bezos just couldn't let go of those pixels, all those millions of semantics-packed pixels on the landing page. They were like millions of his own precious children. So they're all still there, and Larry is not.
<poolie> :)
<StevenK> But he's wrong. amazon.com recently changed
<StevenK> (And IMO, it looks better)
<huwshimi> poolie: Oh I am actually subscribed. I didn't read that one though
<StevenK> Because it isn't a post, but a novel?
<StevenK> wgrant: Did you have any other issues with my branch aside from 1) The flag name, and 2) the lack of tests?
<poolie> StevenK: well, he's out of date
<poolie> their new stuff, like some of the kindle pages, certainly looks remarkably better
 * poolie checks
<StevenK> The front page has changed is what I was refering to
<wgrant> StevenK: Not really. As long as it gives a good traceback and contains the pageid and URL and user and stuff.
<StevenK> Certainly the top has
<StevenK> wgrant: Right, excellent. I've fixed the flag name, now to write a test
<poolie> even ebay is not quite such a ridiculous mess as it used to be
<poolie> but still awfully noisy
#launchpad-dev 2011-10-13
<poolie> wallyworld: bug 1342, whoa :)
<_mup_> Bug #1342: Can't delete spurious "Affects" lines (bugtasks) from bug reports <canonical-losa-lp> <lp-bugs> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/1342 >
<wallyworld> poolie: are you happy or sad?
<poolie> happy and impressed
<wallyworld> happy yes, there's nothing to be impressed about
<poolie> i would like if you qa http://launchpad.net/bugs/861979 some time so my oops fix can have a go at production
<_mup_> Bug #861979: utf-8 encode diffs attached to outgoing email <qa-needstesting> <Launchpad itself:Fix Committed by wallyworld> < https://launchpad.net/bugs/861979 >
<wallyworld> poolie: doing it now but it's being difficult
<poolie> because not enough of that stuff works easily on qas?
<wallyworld> branch scan job oopsed
<StevenK> poolie: We can't deploy until Monday at least.
<lifeless> wallyworld: hey
<lifeless> wallyworld: whats the implementation strategy you guys are planning for bug 1342 ?
<wallyworld> lifeless: hello
<_mup_> Bug #1342: Can't delete spurious "Affects" lines (bugtasks) from bug reports <canonical-losa-lp> <lp-bugs> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/1342 >
<StevenK> lifeless: Magic
<lifeless> StevenK: sadly, I'm too jaded to consider that a great answer ;)
<wallyworld> lifeless: log activity and delete unless it is the last task on a bug
<wallyworld> do it via api initially
<StevenK> That isn't what lifeless meant.
<StevenK> And blocked via flag
<wallyworld> yes
<StevenK> Personally, I'm picturing IBugTask.remove()
<lifeless> probably wants to be on Bug, but I'll let you guys figure that out
<wallyworld> i haven't looked yet. doing qa and other administrivia
<lifeless> wallyworld: things to watch out for - conjoined masters will make 'last task on a bug' hard to determine
<wallyworld> hmmm
<StevenK> Conjoinness rises its ugly head to bite us in the ass again
<wallyworld> dumb question - what exactly is a conjoined master?
<lifeless> wallyworld: will notifications be sent to the context the task is removed from ?
<wallyworld> lifeless: i expect so
<lifeless> wallyworld: your team can help you on the conjoined master thing :) - I mention it because its not obvious until you're in the trenches.
<StevenK> wallyworld: BugTask for Ubuntu, and then it's nominated for natty
 * wallyworld needs to buy some gum boots
<lifeless> wallyworld: I think they should; as there isn't a LEP, I'm using this forum here to toss some constraints your way :)
<lifeless> StevenK: uhm, no. :) thats not a conjoined master
<StevenK> Oh
<StevenK> lifeless: I don't like it on IBug -- I prefer the idea of grabbing IBug.tasks, grabbing the one you want and calling .remove() or .delete() on it
<lifeless> StevenK: wallyworld: when you create a task for a *pillar directly* one task is made. If you also create a task for that pillars *development focus*, then those two tasks are shown as one in the Web UI, and are together a 'conjoined master'
<lifeless> StevenK: sometimes that will delete two tasks.
<wgrant> Why would it delete two tasks?
<lifeless> StevenK: so while you like the idea, I think it will be harder to code and harder to get right, if you put it on BugTask. Just saying.
<lifeless> wgrant: again, conjoined masters.
<wgrant> We don't have to continue treating them as conjoined for deletion.
<lifeless> wgrant: I will wait for a second while you headdesk.
<lifeless> wgrant: we have to show the difference in the UI then...
<wgrant> Delete one of the two, and it is magically not conjoined any more.
<wgrant> Magical!
<lifeless> wgrant: unless you delete the non-series task.
<wgrant> And?
<wgrant> There's no longer a conjoined slave.
<wgrant> No problem.
<lifeless> its not a valid state to have a series task with no non-series master
<wgrant> Isn't it?
<wgrant> I thought you argued a couple of months ago that it was.
<wgrant> When I was attempting to restrict it during my retargeting work.
<wgrant> I'm pretty sure we permit it now.
<wallyworld> does the BugTaskSearch code have explicit code for dealing with conjoined masters?
<wgrant> Even if we want to forbid it, it's not directly related to conjoinment.
<wgrant> *Any* series task is affected.
<wgrant> Conjoinment is unspecial.
<lifeless> I argued that we have such states already, and that the conjoined thing messy, and that we shouldn't make it worse by breaking existing things
<lifeless> wgrant: thats true
<lifeless> wgrant: So let me phrase this differently: delete shouldn't let users create a state that they cannot already create.
<wgrant> Certainly.
<lifeless> Its my understanding that you cannot create a series task w/o a non-series same-pillar task, today.
<lifeless> (via web UI)
<lifeless> anyhow, long story short: beware the jabberwocky; send notifications to the folk the task was removed from; log enough that someone can undo brain damage; think about who can delete (the person who added it, the owner of the context, who else?) carefully. Have fun!
<wallyworld> if the two tasks are shown as one in the web ui, if someone changes the assignee etc, which task gets updated?
<lifeless> wallyworld: both
<wgrant> lifeless: https://bugs.qastaging.launchpad.net/ubuntu/+bug/1234
<_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
<wallyworld> why do we need two task then?
<lifeless> wallyworld: the idea is that when a task nominated for the development focus is closed, its closed for the project as a whole too (in the absence of older series tasks)
<lifeless> wallyworld: the current implementation is just that, an implementation.
<lifeless> wallyworld: I would like to get rid of non-series tasks
<wgrant> lifeless: As for permissions, we agreed that bug supervisor + task creator is probably sensible.
<lifeless> wgrant: I'd suggest owner of the original task context, but that way lies madness
<wgrant> lifeless: Never let me hear you use the phrase "original task" again :)
* StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 269
<lifeless> sinzui: ping
<lifeless> feeling better?
<stub> me? mostly.
<StevenK> lifeless: You are a BAD MAN
<StevenK> BAD!
<stub> Been crook a few days. Yesterday it had mutated into a head cold but that seems to have cleared up now.
<lifeless> stub: ugh. Glad you're better :)
<stub> Just in time to be flooded tomorrow :-)
<lifeless> StevenK: getting things done in a tolerable fashion isn't bad. Cody can do that work unless it actually has holes in it.
<StevenK> lifeless: I don't think it's tolarable, I think it's a terrble hack
<StevenK> IPerson is already too fricken big
<StevenK> And advocating a celebrity?
<lifeless> StevenK: what are the consequences of it that make it intolerable ?
<StevenK> We want LESS celebrites, not more.
<StevenK> lifeless: That we are stuck maintaining it
<lifeless> until someone creates a launchpad-itself model object that such policy objects can link to, we need celebs
<StevenK> Cody or Tim drive it by and say "Excellent, the LP security model is out of our way, thanks" and we're stuck with the baby
<wgrant> There is also the issue of non-virt builders.
<StevenK> So, I object.
<wgrant> Ideally this would only grant them access to their own little world of fake-virt armel.
<lifeless> StevenK: you're rather they web scraped ?
<wgrant> lifeless: Web scraping is always better, because it's not an interface that we have to support.
<lifeless> wgrant: I'm not sure how to do that without deeper plumbing work; I was aiming to limit the scope of the permissions rather than rework
<wgrant> :)
<StevenK> lifeless: I'd rather we give them a restricted account with the privs they want, rather than other madness
<StevenK> But no one listens to me anyway, so meh
<lifeless> StevenK: this gives them a restricted account with the privs they want
<lifeless> StevenK: *I* listen to you - do you have a proposal on how that would work, and how does it compare in dev + maintenance effort to the other proposals ?
<wgrant> I wonder how close the secure panda cluster is.
<lifeless> stub: bug indices at 98% bloat :)
<wgrant> That would make this easier.
<stub> awesome
<elmo> time to try pg_reorg? :)
<elmo> oh, it's an index
<elmo> I'll shutup now
<lifeless> elmo: :)
<lifeless> elmo: aieeeeeeeeeee
<elmo> haha
<stub> https://code.launchpad.net/~stub/launchpad/replication/+merge/78914 has landed, but the scanner hasn't flagged it as merged.
<elmo> hahaha
<elmo> lifeless just googled pg_reorg
<wgrant> stub: db-devel vs devel
<stub> pg_reorg is for wimps.
<StevenK> I just did, that's *insane*
<wgrant> Oh, it landed on devel.
<stub> wgrant: nah...
<wgrant> Nevermind me then, something's just screwed.
<wgrant> Ah.
<stub> Will it have been logged somewhere? I'm not fussed but not sure if it should be raised somewhere.
<wgrant> https://code.launchpad.net/~stub/launchpad/replication
<wgrant> Ancient branch.
<wgrant> The scan probably timed out.
<mwhudson> pg_reorg is that thing you use when you write to your database too much for vacuum to work right?
<wgrant> Because our branch scanner is fast and awesome and reliable and perfect.
<mwhudson> (and want to die in a fire)
<stub> All my branches are ancient ;)
<wgrant> stub: Well, crucially, this one is missing 18 months of revisions.
<StevenK> Hah
<wgrant> Ahh
<wgrant> And the old scan is based on db-devel
<wgrant> The new one is probably devel.
<wgrant> So it has to rewrite tonnes.
<stub> I just crapped on https://code.launchpad.net/~allenap/launchpad/oneiric-librarian-bug-871596/+merge/79175 . Anyone disagree that this is a Storm bug and better to address there?
<wgrant> stub: Agreed.
<wgrant> That seems to pretty clearly be a DisconnectionError.
<lifeless> +1
<StevenK> lifeless: Oh, I noticed this yesterday:
<StevenK> steven@liquified:~/launchpad/lp-branches/devel% head -n 1 LICENSE
<StevenK> Launchpad is Copyright 2004-2009 Canonical Ltd.
<lifeless> yes, copyright overheads are a PITA
<StevenK> lifeless: Should I JFDI the fix?
<lifeless> yeah
<lifeless> cron it for the 1/1/*
<StevenK> On my desktop? Not likely :-P
<StevenK> "But Robert tells us that the problematic team membership records are harder to clean up than regular old requests."
<StevenK> Clearly, both jtv and I are missing something.
<lifeless> ECONTEXT
<lifeless> wallyworld: \o/ at ajax batching
<wallyworld> lifeless: seems to work well. if we get sorting solved, we can add it to the bug and blueprints tables on the milestones page
<wallyworld> there's already a half done branch for that
<lifeless> whats the sorting issue?
<wallyworld> when sortable.js is used for client side sorting, it doesn;t make sense if only a batch of results is rendered
<lifeless> well, thats what we do today right ?
<wallyworld> the sorting doesn;t break, but it only sorts the current batch
<lifeless> how does avoiding page-loads make it worse?
<wallyworld> yes but today for those tables there's no batching
<lifeless> oh, I see.
<wallyworld> so the sort works on the entire results set
<lifeless> yes
<wallyworld> so we need to catch the table header click and send a new query to the back end
<lifeless> can I make two suggestions
<wallyworld> sure
<lifeless> rather than replacing the batch, consider - at least as an option - *appending* to it.
<lifeless> (and scroll down to the new bits)
<wallyworld> lifeless: otp just a sec
<lifeless> I suspect, much of the time, that that would be closer to what users want
<lifeless> wallyworld: np
<lifeless> -> picking up lynne
<wallyworld> lifeless: will ping you later
<StevenK> wgrant: Hai
<nigelb> *yawn* Morning
<wgrant> StevenK: Hello.
<StevenK> wgrant: I have a test, but I want to see that it creates an OOPS.
<wgrant> getLastOopsReport?
<wgrant> Or self.oopses perhaps.
<wgrant> Depending on how you do it.
<StevenK> Traceback (most recent call last):\nMixedVisibilityError\n
<StevenK> I am disappoint.
<StevenK> So I guess I need to inject a traceback into my raising() call
<lifeless> StevenK: no, if you do thats a bug somewhere else
<lifeless> StevenK: is it in a subprocess?
<lifeless> StevenK: if not, self.oopses is the thing to use.
<StevenK> lifeless: self.oopses looks good, but I want the full traceback
<lifeless> StevenK: it should be there
<lifeless> StevenK: if its not, something is mangling it
<lifeless> StevenK: report['tb_text'] should have it
<StevenK> 'tb_text': 'Traceback (most recent call last):\nMixedVisibilityError\n'
<lifeless> StevenK: as I said, something is mangling it
<StevenK> getUtility(IErrorReportingUtility).raising(
<StevenK>                 (MixedVisibilityError, MixedVisibilityError(), None),
<StevenK>                 request)
<StevenK> That's how I'm raising it, perhaps that is wrong
<lifeless> uhm, lets start over. What are you trying to do ?
<StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/soft-oops-on-private-team-disclosure/+merge/79066
<lifeless> there are no soft oopses
<wgrant> There are no *informational* OOPSes.
<wgrant> There can certainly be soft ones.
<lifeless> this has the potential to cause thousands of oopses
<lifeless> are you sure you want to do it ?
<lifeless> (for instance, an api collection with 75 members in it will be trimmed by lazr, and that one web API call will generate 75 oopses)
<lifeless> oh, and I see that you won't log from the API, which is good on one hand, but means you won't see it on the other
<lifeless> .
<lifeless> bloody ISP
<StevenK> lifeless: So, we want to turn this on for an hour or so and then see what happened
<StevenK> This is not a feature flag to leave enabled for too long
<StevenK> And it is purely for data gathering
<StevenK> So we can nail down the prime suspects, as it were
<lifeless> ok
<lifeless> so you actually need an *exception*:
<lifeless> try:
<lifeless>  raise MixedVisibilityError('some text here')
<StevenK> I don't want to stop it
<lifeless> except MixedVisibilityError:
<StevenK> I just want to log it
<lifeless>  ...raising()
<lifeless> StevenK: have faith that I understand your use case :)
<StevenK> try raise except results in 'tb_text': 'Traceback (most recent call last):\nMixedVisibilityError\n'
<lifeless> paste the updated code ?
<StevenK> lifeless: http://pastebin.ubuntu.com/707156/
<lifeless> StevenK: nono, don't make the tuple by hand
<lifeless> sys.exc_info()
<StevenK> lifeless: Which tuple, sorry?
<StevenK> Oh, just toss sys.exc_info() rather than (MixedVi ...
<lifeless> http://paste.ubuntu.com/707159/
<jtv> Can someone who knows code imports help with this question?  https://answers.launchpad.net/launchpad/+question/174071
<StevenK> lifeless: Modulo the left bracket, I just did that myself, so great minds
<lifeless> StevenK: that should work better for you
<StevenK> 'tb_text': 'Traceback (most recent call last):\n  Module lp.app.browser.tales, line 1327, in _report\n    raise MixedVisibilityError()\nMixedVisibilityError\n'
<StevenK> Although I'm calling into the formatting API myself, so that should be okay.
<StevenK> lifeless: Thanks for the help.
<lifeless> StevenK: anytime
<StevenK> I was expecting more frames, but I shouldn't in this case.
 * wgrant yearns for IArchiveCollection and IPublicationCollection
* wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 267
<wallyworld> lifeless: batching - you want to append the next batch to the current batch? to create a table with twice as many rows (and a scroll bar)? doesn't sound quite right to me
<wgrant> Why not?
<wgrant> That's how most modern batchers work.
<wgrant> Start scrolling down, it automatically loads the next bit and extends the page.
<wallyworld> that would be a significant rewrite of the current batcher though
<wallyworld> well, the js etc
<wallyworld> i was just wanting to do something backwards compatible and in line with the current implementation
<wallyworld> at least for now
<nigelb> WIth launchpad's move to SOA, this might be an interesting read, if you folks haven't read it already - https://plus.google.com/112678702228711889851/posts/eVeouesvaVX
<wgrant> Yeah, that's been circulating around a bit. A rather impressive work.
<StevenK> Indeed
<StevenK> lifeless: Hai, Mr. OCR.
<wallyworld> stub: has the branch transitively_private not null patch been applied to prod?
<StevenK> wgrant, wallyworld: Do either of you want to review my logging branch?
<wallyworld> StevenK: i'll have a look
<wgrant> wallyworld: The NOT NULL patch is next in the DB queue.
<wgrant> wallyworld: Will probably be deployed on Monday, unless oneiric breaks stuff.
<wallyworld> ok
<wallyworld> just curious
<wgrant> The last few windows have been used for oneiric-critical cocoplum deployments, unfortunately.
<wallyworld> StevenK: the method _report() - could it have a better name, like _report_visibility_leak() or something
<StevenK> wallyworld: I like the _ since it is internal, and I doubt it will remain there for long
<wallyworld> StevenK: it's not the _, but the name
<wallyworld> report
<wallyworld> vs report_visibility_leak
<StevenK> Yes, alright
<wallyworld> sorry
<StevenK> :%s/\(_report\)/\1_visibility_leak/
<StevenK> Fixed
<wallyworld> StevenK: i also think the test should ensure the ooops content is related to the mixed visbility error raised
<wallyworld> at the moment, there's nothing to test that the oops is informational or is related to the error we are raising
<wallyworld> it could be any oops
<wallyworld> and we wouldn't know
<StevenK>             self.assertTrue(
<StevenK>                 'MixedVisibilityError' in self.oops[0]['tb_text'])
<StevenK> Rather than what is there, okay?
<wallyworld> i think that works. is there a way to tell that it's a soft oops?
<StevenK> That the call returns u'<hidden>', which I already test.
<wallyworld> ah ok, since a hard oops would not return a result
<wallyworld> it would just error out
<StevenK> Exactly.
<wallyworld> cool. thanks for making the changes. r=me
<lifeless> wallyworld: its a desired feature, even though it is different to the non-js batch
<lifeless> wallyworld: non-js batch being the same as js-batch isn't a goal in and of itself :)
<lifeless> wallyworld: if you don't have time, thats fine. Consider though that the bugtask comment js batch works this way ;)
<wallyworld> lifeless: sure. i'm just doing a bit at a time - small chunks of improvement
<wallyworld> it was just a coding spike rather than a proper part of disclosure
<lifeless> ah cool
<lifeless> I think its great.
<lifeless> just tossing out nice to haves ;)
<wallyworld> for what it is it works. backwrads compatible with non-js etc
<wallyworld> i agree with the nice to haves
<wallyworld> lifeless: while i have you - i wanted to put the deleteBugTask() on IBugTaskSet. it makes sense to me that the xyzSet interfaces be used to manage the lifecycle of the items they create etc
<wgrant> Any method on a Set that isn't set-based is a bug.
<wgrant> deleteBugTasks(), perhaps.
<lifeless> opinions are mixed about the *Set interfaces/instances
<lifeless> they are misnamed for much of what they do
<wgrant> wallyworld: Also, that doesn't work too well for the API.
<wgrant> As the Sets can't really be exported sensibly.
<wallyworld> agreed. that was the issue i was going to aks about
<wgrant> This is most inconvenient.
<lifeless> putting it on there would be fine by me; I agree that it should take an interable of tasks, as future proofing. The API side of it is interesting though, as (IIRC) we haven't exposed the Sets on the PAI
<wallyworld> we export IBranchSet
<wallyworld> but it needs a url and default collectio method
<wgrant> We can't use a Set here.
<wgrant> As we need permission checking.
<wallyworld> we pass in the user as part of the request
<lifeless> wgrant: that seems like a non-sequitur
<wallyworld> deleteBugTask(bugtask, deleted_by)
<wgrant> lifeless: Until it's not awkward as hell, it's very relevant.
<lifeless> wgrant: its not awkward as hell ...
<wgrant> You have to manually work out the security stuff.
<wallyworld> and we use call_with(who_deleted=REQUEST_USER)
<wgrant> Sure, we can get the user in there.
<lifeless> do you mean 'you'd have to check the security by probing rather than security adapters' ?
<wallyworld> that seems to be the pattern used everywhere else
<wgrant> But then you have to manually determine and invoke security adapters.
<wallyworld> i like the idea of a separate manager type interface to control the lifecycle of objects
<wallyworld> it fits more with a service based design where domain objects encapsulate state and services manage the workflow etc
 * StevenK attempts to stop his eyes glazing over
<wallyworld> so we need to stick the deleteBugTask() method somewhere other than on IBugTask itself or even IBug
<wallyworld> StevenK: you know you love this stuff
<lifeless> wallyworld: the current pattern in LP, for good or ill, is destroySelf()
<StevenK> Love to see it burn, sure.
<wallyworld> yuk!
<wgrant> wallyworld: I would introduce BugTaskSet.delete(sequence_of_tasks)
<StevenK> IBugTask.destroySelf()
<wgrant> Then BugTask.destroySelf calls that.
<wallyworld> nooooooo
<wallyworld> domain objects do not call services
<wgrant> In our current architecture they do.
<lifeless> wallyworld: we don't have a domain/service split today
<wallyworld> domain objects should just encapulate state and nothing more
<wgrant> Yes, it is bloody awful.
<wgrant> But this is Launchpad.
<wallyworld> lifeless: yes, but do we want to propogate bad edesign?
<wgrant> We have no choice here.
<lifeless> wallyworld: introducing one incrementally is fine, but I would like to have some confidence we won't get lots of stubby attempts that don't flow together
<wallyworld> sure
<wgrant> The current API and security design mandates that the method be on the object.
<wallyworld> so given we have an addTask method on IBug, i could put a deleteTask method there too
<wallyworld> and then it can update the heat etc
<nigelb> wgrant: Did you see the new design github deployed? It reminds me of old Launchpad :P
<lifeless> I don't think destroySelf is 'bad design' - its the logical consequence of the design of the zope stack.
<wallyworld> just like addTask does
<lifeless> wallyworld: -the entire stack-
<wgrant> nigelb: Indeed, with the tabs along the top.
<wallyworld> lifeless: destroySelf is ok, but that should not be exposed via the service layer
<wgrant> wallyworld: What service layer?
<StevenK> The API, I guess
<wallyworld> wgrant: i'm generising
<wgrant> LP has no layers.
<lifeless> wallyworld: consider the interactions between ORM-objects-are-content-objects, security adapters and highly delegate-to-content-object design
<lifeless> wallyworld: if you grok that, and still want to add a service layer as part of this work, you have my blessing.
<lifeless> wallyworld: few folk do grok all those interactions though :( [because its bloody vicious]
<wallyworld> lifeless: i'd like to move to a different design which separates out content from behaviour from workflow modelling from business process modeliing from orm etc
<wallyworld> but that's in an idea lworld
<wallyworld> i realise we have something different
<wallyworld> largely dictated by the design of the zope stack i guess
<wallyworld> lifeless: wgrant: so you happy if i add a deleteBugTask method to IBug?
<wallyworld> and if so,i would raise an exception if a bug task were passed in that didn;t belong to the bug?
<wgrant> wallyworld: I don't think it should be on the bug.
<wgrant> addTask is there because it's adding a task to the bug.
<wallyworld> but the bug needs to be involved because it needs to update bug heat
<StevenK> I think it should be on the task
<wgrant> Fucking bug heat.
<wgrant> Kill it.
<wallyworld> so if it is on the bug task, i would need to update bugg heat still
<wallyworld> and call back to the parent bug
<wallyworld> sigh
<wgrant> Well, ideally the *Set method would do that.
<wgrant> In a batch fashion.
<wallyworld> yes, but to expose the IBugSet method - it needs a url and a default collection method
<wallyworld> and there isn;t one at the moment
<wgrant> Sure, which is why you put a trivial method on BugTask to delegate to it.
<wgrant> Matching the rest of LP's deletable objects.
<wallyworld> ok, but i will have to have a shower afterwards. that is just sooooo wrong
<poolie> i was thinking the other day about bug 678090 - i'd like to see how many people are actually affected by bugs, across dupes
<_mup_> Bug #678090: Affected people from duplicates aren't included in the master bug's affected count <affectsmetoo> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/678090 >
<poolie> stub, or someone, could you comment on my db performance question on the bug
<poolie> basically, is counting them at run time going to be fast enough, or should we maintain a count?
<wallyworld> wgrant: StevenK: to do it on bugtask seems the best option, but it just gets the layering *completely* wrong :-(
<wgrant> wallyworld: It's as good as it can get now.
<wgrant> wallyworld: Until we end up with a sensible architecture.
<StevenK> "lol"
<wgrant> Which may happen in 10 years when we're out of criticals :)
<wallyworld> yeah :-(
<wgrant> But don't worry, there's nothing wrong :)
<wallyworld> wgrant: i have to run away and pick up the kid from school. i doubt we'll see any qastaging email today :-(
<nigelb> How do I find which things are exposed over the API and wwhich arent?
<poolie> nigelb: search through http://launchpad.net/+apidoc ?
<wallyworld> nigelb: they are annotated and also listed in the webservice.py modules
<nigelb> poolie: Well, I was asking from the point of looking at the code and figuring out
<wallyworld> that's if you want to see in the code
 * wallyworld runs away
<nigelb> aha
<StevenK> nigelb: They are declared in the relevant interfaces
<nigelb> Ah, anything declared in the interface is available over the API?
<StevenK> No, it needs to decorated
<StevenK> nigelb: Taking lib/lp/bugs/interfaces/bug.py, getVisibleLinkedBranches is exported since it is has a @export_read_operation() decorator
<lifeless> 18:50 < lifeless> wallyworld: I want what you want, I just see more things in the way :)
<nigelb> funnily enough, I was looking at that exact file.
<lifeless> and
<lifeless> 18:49 < wgrant> Matching the rest of LP's deletable objects.
<StevenK> nigelb: latest_patch_uploaded is exported, but latest_patch is not
<lifeless> before my connection crapped out.
<lifeless> I see an ISP change in my future
<StevenK> Haha
<StevenK> I suggest a country change first
<lifeless> StevenK: layer 2 blip
<nigelb> Or a continent
<lifeless> nigelb: I've the choice of two right now, just need to drive over the mountains :)
<nigelb> heh
<StevenK> Haha
<StevenK> nigelb: Clear as mud?
<nigelb> StevenK: clearer than before at least
<StevenK> Haha
<StevenK> nigelb: So exporting things that haven't been can be easy if the interface they are in has had some groundwork laid -- but it can be complicated too
<nigelb> StevenK: Ok, so the reason I asked is searchTasks is available over the API, but I don't see BugTaskSearchParams anywhere
<stub> poolie: There will be little difference between filtering duplicates like we currently do and counting them. It may well be much faster even, as we may be able to avoid joining the bug table in some cases.
<lifeless> stub: bug.private
<stub> lifeless: Which is starting to be overhauled in any case.
<lifeless> stub: yes, but we still need to know, don't we ?
<stub> lifeless: It will move to task I think, as your bug could be targetted at pillars with different policies? Anyway...
<poolie> so at the moment it does
<poolie> select affected_user_count from bug where bug.id = %d
<wgrant> stub: We're actually very strongly leaning to removing cross-pillar private bugs.
<poolie> we could change that to
<wgrant> stub: Once we beat OEM and ISD into submission.
<wgrant> Hm.
<stub> poolie: The query for 'users affected by this bug' will be slower and more complex if you count duplicates, but it will still be fast.
<poolie> select count(user) from bugaffectsuser where bugaffectsuser.bug = %d or bugaffectsuser.bug in (select id from bug where duplicateof = %d)
<wgrant> We need a rabbitmq logging transport.
<poolie> or something like that
<poolie> that's more or less what bug.affected_user_count_with_dupes does
<stub> wgrant: I thought of that but was worried about clogging rabbit with debug2 spam.
<wgrant> stub: Yeah, it would need testing.
<lifeless> wgrant: this is for realtime logging?
<wgrant> lifeless: Yes.
<lifeless> wgrant: the ISP project should cover that
<lifeless> wgrant: I'd rather not overlap for a bit at leasrt
<wgrant> Yes, but they're nearly as slow at feature development as we are.
<nigelb> ISP?
<stub> wgrant: Would involve hooking into the existing log_options crud, adding an option to control the level of messages to send to messaging, and a log handler installed that sends to rabbit. Not terribly much work once rabbit is operational.
<lifeless> nigelb: information systems projects
<wgrant> stub: Yep, fits in very well with the existing script logging infrastructure.
<nigelb> lifeless: ah
<lifeless> StevenK: you wanted a review?
<lifeless> speaking of which, I could use a couple
<StevenK> lifeless: You're like an hour late.
<lifeless> StevenK: so you don't ?
<lifeless> oops-tools test time down to 4.7 seconds + db setup of maybe 7
<lifeless> \i/
<StevenK> lifeless: No, wallyworld has done it for me, but thanks
<poolie> stub: so you're still pretty sure that will be safe?
<lifeless> poolie: we bring up the dupes already
<stub> poolie: Yer.
<lifeless> poolie: I suggest not changing that query
<lifeless> poolie: instead, sum up the affecting counts from the dupes (that we already retrieve)
<poolie> ok
<poolie> good idea
<poolie> that's not precisely accurate in the case one person is affected by multiple bugs
<poolie> but, perhaps that's not important
<lifeless> I think for dupes that it doesn't matter :)
<poolie> tags +pedantic
<poolie> ok that seems pretty safe then
<poolie> how about for sorting by affected-users across dupes?
<lifeless> what do you mean ?
<poolie> part of the related bug is that getting a list of bugs sorted by number of affected users probably should sort by total affected users across bugs
<lifeless> ah
<poolie> if you want to know which bugs cause the most pain
<lifeless> perhaps we should stop offering that sort
<poolie> !
<lifeless> because bug heat is intended to provide a unified value representing pain, interest etc
<poolie> but it fades over time, right?
<poolie> though apparently not really?
<lifeless> right
<lifeless> and for affected users, wouldn't something that 1000 people marked affecting me in 2005 be less interesting than one where they marked it that way yesterday?
<poolie> i don't know what the fall off is
<lifeless> [Note: I'm not endorsing that decay is useful, just taking it as an axiom for the discussion]
<poolie> it seems reasonable to want to know about either of them
<lifeless> poolie: IIRC 1% a day or something
<lifeless> poolie: everything in the UI has a cost; I'm questioning the value of the affected-user-sort
<poolie> so
<lifeless> given we have something intended to be more than it
<poolie> i think it's a good question
<poolie> i guess i dislike that both heat and affectance have this "you don't need to know that" attitude
<poolie> and heat has some bugs, due to eg security bugs (many marked in error) getting a big boost
<poolie> but, perhaps they can just be fixed
<poolie> and it'll be a reasonable default
<lifeless> rhetorical question: if you fix both affected and heat to be perfect, would we need both anymore ?
<lifeless> [modulo the 'stop bug noise' aspect of affected]
<lifeless> affected users count towards heat
<poolie> another good question
<poolie> i know
<poolie> i think they mesh without overlapping much
<poolie> if bug heat worked well i don't think i'd care much about sorting by #affected
<lifeless> anyhow, I bet that a self join onto duplicates will trigger table scans in Ubuntu bug searches unpleasantly often.
<poolie> but i do want to know the number of affected people
<lifeless> thats a WAG, needs testing to be sure.
<lifeless> poolie: I totally support showing the # affected sanely ;)
<poolie> conversely, i think the heat metrics on an arbitrary scale have little or no value, cause confusion, and ought to be removed or deemphasized - ie make it only an ordering
<poolie> eg the (fairly hot :) bug about heat being per-bug vs per task
<poolie> what do you think?
<lifeless> I think heat is an ambitious project that we've underdelivered on
<lifeless> it has many significant operational issues as well as the UI related ones you refer to
<lifeless> folk like deryck are keen to fix it, but the current approach is tweaking;
<lifeless> I think it needs ground up re-evaluation, to fix both the UI and operation issues
<lifeless> (e.g. it causes search timeouts)
<poolie> well, i am kinda tweaking here
<poolie> a rethink could be good
<poolie> but, perhaps is not necessary to just make dupes work better
<lifeless> sure; we were talking about the affected sort, which is a bit orthogonal to dupes
<poolie> s//affectsmetoo
<poolie> i mistyped
<poolie> mis-thought
<rvba> Hi lifeless, thanks for your feedback on the weird storm behaviour, I was a little bit surprised to see such a crazy thing but you're right, it really seems like I should fix this in storm (as opposed to a quick fix in the batchnavigator).
<lifeless> rvba: you may want to fix batchnav too, as google won't be making up those urls itself - we're emitting them somewhere
<lifeless> rvba: you can use googles link: search to find the pages containing the bad url and look at whats happening there
<wgrant> Why won't it be?
<rvba> lifeless: not sure about that, I've heard that google tried to fiddle with query parameters to crawl the web.
<lifeless> wgrant: because its a spider, not an AI
<wgrant> lifeless: Erm...
<lifeless> rvba: ah.. well, its worth checking that we're not emitting them
<lifeless> rvba: on the 'better safe than sorry' side
<rvba> lifeless: Right.
<lifeless> grah. ISP DIE DIE DIE DIE
<lifeless> ....
<lifeless> .
<lifeless> .
<lifeless> I wonder if setting my MSL to 5 seconds would help things or wreck em
<mrevell> Howdy
<rvba> Hello mrevell!
<mrevell> hallo rvba
* rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba* (allenap) | Critical bugs: 267
<allenap> stub: Thanks for the review. I don't mind the crapping-on :) I wasn't sure of the fix, but I wanted to show you something that might illustrate the problem. I'm going to relocate now, back in ~20m.
<stub> allenap: So the fix should be pretty simple - just need to add to is_disconnection_error() in databases/postgres.py. Tests might be harder to engineer, although for all I know perhaps the existing test suite fails under Oneiric.
<stub> allenap: Assuming you want to work on it rather than hand ball it a Storm dev (me or jamesh would be most likely to grab this one)
<poolie> o/ mrevell
<mrevell> hey poolie, not so loud, I'm hiding from the 50ft marshmallows.
<lifeless> I need a guinea pig
<mrevell> s/ft/tonne
<poolie> :) who _are_ you going to call, mrevell? :)
<lifeless> how wide must a ft long marshmallow be to weight a tonne ?
<mrevell> Heh. Hmm, who's the most Dan Ackroydy member of the team.
<poolie> Huw?
<lifeless> you gonna call...
<lifeless> that was terrible poolie
<mrevell> hah
<poolie> :)
<poolie> actually he does also look vaguely like him
 * lifeless puts out the call for guinea pigs
<mrevell> lifeless, Id the experience you have planned for these guinea pigs too scary to describe in your sales pitch?
<mrevell> Feck, "Is"
<lifeless> yes, of course
<lifeless> :)
<lifeless> mrevell: I want someone to quickly once-over the oops-tools release branch I've prepared
<lifeless> mrevell: its mind numbing looking for any production data references I've missed *that matter*
 * bigjools wonders who Robert Collings is
<lifeless> probably the dude whose mail I keep getting
<lifeless> from hotels, gyms, their daughters wow account [parental control bit woo] and more
<lifeless> the sheer number of services that *don't* do a probe to check they got the mail address right is astonishing
<bigjools> lifeless: well he attended the TL call last night
<lifeless> bigjools: ah, no idea then.
<lifeless> anyhow
<lifeless> someone, please pull bzr+ssh://devpad.canonical.com/code/robertc/python-oops-tools and check I didn't miss anything big
<lifeless> kthanks release
<wgrant> That's very FHS.
<nigelb> FHS?
<wgrant> Filesystem Hierarchy Standard
<nigelb> Hrm, maybe I don't wanna know.
<nigelb> Ok, urbrandictionary'ing it wasn't a great idea.
<StevenK> FHS mandates things like binaries in /bin or /usr/bin, things that the machine serves go under /srv, /usr/local is for locally installed stuff, etc, etc
<nigelb> Ah
<lifeless> wgrant: you didn't know about /code ?
<lifeless> so that was amazing time consuming; I think for qatagger I'll rewrite
<wgrant> lifeless: I didn't.
<StevenK> The FHS didn't specify /code last I read it.
<lifeless> it doesn't
<poolie> what do you want people to look for?
<lifeless> poolie: stuff we wouldn't be happy pasting in this channel
<lifeless> machine name references, internal config details, that sort of thing
<poolie> grep -ir f.ck .
<nigelb> heh
<lifeless> there are some I've deliberately kept, because we depend on them for some of the aggregation (but those are obvious when reading the code) - and already known via lp source I strongly suspect :)
<poolie> lifeless: well, the buildout.cfg has canonical.com as example data
<poolie> if anyone else runs this we might be annoyed by backscatter
<poolie> or they might be embarrassed by it
<lifeless> poolie: thanks - thats one I missed, and exactly what I was hoping for
<lifeless> this has been brain numbing :)
<poolie> thanks :)
<poolie> there is no obvious licence on it
<poolie> and the readme's "for more information" is a private url
<poolie> also the "real world example" url
<lifeless> no licence? where are you looking
<lifeless> ah, I haven't overhauled README.
<lifeless> shall do.
<poolie> oh, the top-level readme
<poolie> there is one in the python module
<poolie> some of it is agpl and some is lgpl?
<lifeless> should be all AGPL
<poolie> (which can be valid, but may not be intentional)
<lifeless> presumably I missed a header
<poolie> src/oopstool/README.txt
<lifeless> thanks
<poolie> oh no
<poolie> it has doctests
<poolie> better fix that ;)
<lifeless> its a child of its time
<lifeless> I have purged many
<lifeless> however my goal is a release not code overhaul
<lifeless> I suspect folk interested will poke at it after its out there
<poolie> i know, i was just joking
<poolie> in models.py there is some code flagged as lp-specific
<poolie> embedding some policy about lp custom exceptions
<poolie> probably fairly harmless to leave it as an example in the first relase thoug
<poolie> that's all i can find
<poolie> that's great to get this released!
<nigelb> what does this do?
<nigelb> oops tools?
<lifeless> poolie: yeah, thats the code I was referring to that needs to stay
<lifeless> poolie: theres no extension points for this yet
<lifeless> poolie: we need to make these data driven or something
<poolie> nigelb: you may never have seen this but occasionally launchpad times out
<poolie> :P
<poolie> those things are gathered into a database and there's a tool that does some summaries and reporting
<poolie> which we're apparently now going to release \o/
<nigelb> poolie: heh, I did guess right :)
<allenap> stub: Storm does string matching in is_disconnection_error. Do you think I should stick with that, or should I use pgcode like in my Launchpad branch?
<stub> allenap: It does string matching because we were not getting error codes before for these exceptions. I think error code matching is better as we don't need to worry about localization issues. Perhaps we can do this for the other disconnections too under Oneiric and leave the string matching for backwards compatibility with older psycopg2/libpq releases?
<poolie> jtv, fair enough
<jtv> poolie: "just following orders"  :)
<allenap> stub: Okay, I'll try to use pgcode if it exists, and I'll leave the fallback to string matching in place too. Thanks.
<jtv> Anyone here who can help with a failing code import?  https://answers.launchpad.net/launchpad/+question/174071
<bigjools> jtv: jelmer is the best to ask about that
<jtv> Thanks bigjools
<poolie> can anyone explain this test failure? https://pastebin.canonical.com/54298/
<wgrant> allenap: ^^
<wgrant> poolie's issue looks like yours.
<poolie> i do have some lines like this in the postgres log
<poolie> [2011-10-13 20:45:26 EST] mbp@launchpad_ftest_template_17866 FATAL:  database "launchpad_ftest_template_17866" does not exist
<jtv> jelmer_, is this something you can help with?  https://answers.launchpad.net/launchpad/+question/174071
<jtv> poolie: I get those log lines too
 * allenap looks
<jtv> Yup, that's the one allenap's working on.
<bigjools> poolie: oneiric>
<bigjools> ?
<allenap> poolie: bug 871596
<_mup_> Bug #871596: Not handling administrative shutdown under Oneiric <build-infrastructure> <librarian> <Launchpad itself:Invalid by allenap> <Storm:In Progress by allenap> < https://launchpad.net/bugs/871596 >
<bigjools> allenap: you might want to announce you're fixing that on the dev list, we'll get loads of questions about it today
<poolie> hooray for chroots
<lifeless> poolie: no other feedback ?
<lifeless> poolie: e.g. 'you need a copy of the GPL in there :P' (one I just noticed)
<sladen> mbp pointed me this way.  What's the up-to-date method for getting a LP install working, such that I can test a proposed patch to Malone
<nigelb> sladen: are you on oneric?
<poolie> lifeless: that's all i can find
<poolie> o/ paul
<nigelb> you can either sacrifice your apache to LP or you can run it in a container
<poolie> dev.launchpad.net/Running
<wgrant> /Running/LXC if you want more isolation
<sladen> https://dev.launchpad.net/Getting <-- there's that, is it current?
<nigelb> https://dev.launchpad.net/Running/LXC
<poolie> those two
<wgrant> Right, that works too, if you want to sacrifice your system postgres and apache to LP.
<poolie> personally i use Schroots
<nigelb> sladen: it is current, but like I said. Sacrifice involved :)
<lifeless> Running/LXC is my recommendation
<danilos> jtv, thanks for taking care of that en_GB removal request
<lifeless> ok, bzr+ssh://devpad.canonical.com/code/robertc/python-oops-tools should be in shape now
<lifeless> poolie: care to eyeball again ?
<jtv> danilos: np.  Just realized though that we'll need to delete the POFile as well.  :(
<poolie> lifeless: sorry i have to go out, maybe tomorrow
<poolie> well, maybe just the diff, ok
<lifeless> its a push--overwrite, but you can use heads and diff the two
<poolie> someone read https://code.launchpad.net/~mbp/launchpad/612171-diff-generation-spam/+merge/79244 for me?
<lifeless> no diff yet, but I've added commentary based on your cover letter
<lifeless> I'm v tired so lets talk about it tomorrow
<poolie> thanks
<poolie> how ironic if the diff fails
<poolie> np
<poolie> lifeless: looks pretty good
<poolie> not sure if you ticked off every item i mentioned (that you want to fix)
<poolie> ok night all
<nigelb> night poolie
<lifeless> poolie: I updated both README's, added LICENSE, and fixed buildout.cfg, deleted the isd and u1 index templates and made the LP one be called index (its a bit ugly that thats in-tree, but ... meh)
<lifeless> and bleh png files to nuke too
<lifeless> done
<lifeless> wgrant: care to add some paranoia to this process?
<wgrant> lifeless: Is the devpad branch up to date?
<wgrant> Looks like it.
<wgrant> As I must pull --overwrite
<wgrant> lifeless: Don't want to s/lp-oops.canonical.dev/oops-tools.dev/ or so?
<lifeless> sure, can do that
<wgrant> The remaining sample OOPSes are non-sensitive?
 * wgrant checks.
<wgrant> Ah, you must have mangled them.
<lifeless> hatchet and slashet
<lifeless> pushed that sed up
<wgrant> Getting distribution for 'wadllib'.
<wgrant> error: Couldn't find a setup script in /usr/lib/python2.7/dist-packages
<wgrant> An error occured when trying to install wadllib 1.2.0.Look above this message for any errors thatwere output by easy_install.
<wgrant> :(
<lifeless> details :P - bootstraps on lucid with the lazr sourcedeps branch
<wgrant> (oneiric)
<wgrant> I just ran make
<wgrant> Which grabs that branch.
<lifeless> (yay)
<lifeless> so, I think once we get this out, someone probably wants to run around and cleanup
<lifeless> I mean I don't want it to be terrible
<wgrant> Perhaps the system wadllib is killing it.
<lifeless> but diminishing returns and all
<wgrant> Anyway, will ignore for now.
<wgrant>     maintainer_email='launchpad-developers@lists.launchpad.net',
<wgrant> Really?
<wgrant>     license='LGPL v3',
<wgrant> Lies.
<lifeless> bah
<lifeless> the former - etired. the second, grrr
<lifeless> trove classifiers are where its at
<wgrant> Yep.
<lifeless> deleted the license line and fixed the list
<wgrant> Thanks.
<wgrant> Checked that the secret key doesn't match prod?
<lifeless> secret key ?
 * sladen deletes some Top Gear to make way for Launchpad.  I hope you're all grateful
<wgrant> In buildout-templates/src/oopstools/settings.py.in
<allenap> stub: I'm struggling to replicate the admin_shutdown thing in a Storm test. Do you know how I can do that?
<lifeless> changed to 12345
<lifeless> and added a note to the README
<wgrant> Thanks.
<lifeless> thank &you&
<lifeless> allenap: python-pgbouncer perhaps ?
<wgrant> lifeless: So, I think that looks fine otherwise!
<allenap> lifeless: Ah, okay, that's already in LP, right?
<lifeless> allenap: as a dep? yes
<lifeless> allenap: its how we do the fdt tests
<wgrant> lifeless: Huh, do the tests pass now?
<wgrant> I see matsubara's email address in report.txt, but nowhere else in the codebase.
<lifeless> they were before the latest set of edits
<lifeless> fixing
<lifeless>  Ran 23 tests in 4.600s
<lifeless> OK
<wgrant> Excellent.
<wgrant> That's nice and quick, too.
<wgrant> Can you do the same thing to LP? :)
<lifeless> if I can delete the same amount, sure
<danilos> jelmer_, hi, do you think you could QA bug 485932 or share some instructions on how to do it?
<_mup_> Bug #485932: should stack foreign branch imports <code-import> <lp-code> <qa-needstesting> <Launchpad itself:Fix Committed by jelmer> < https://launchpad.net/bugs/485932 >
<stub> allenap: One approach that might work is to open a second connection and 'select pg_terminate_backend(procpid) from pg_stat_activity where datname='$testdbname' and procpid <> pg_backend_pid()'
<stub> allenap: That might work. There is a chance it is a pgbouncer specific thing and we would need to pull in the python-pgbouncer as lifeless suggested.
<allenap> stub: I'll give that a go, thanks :)
 * sladen gets to  utilities/update-sourcecode
<sladen> what does  "bzrlib.errors.ConnectionReset: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist."  mean?
<sladen> http://pastebin.ubuntu.com/707303/
<deryck> Morning, everyone.
<nigelb> Morning deryck. The mockups for the buglists look cool! Can't wait to see it in action :)
<deryck> nigelb, cool.  Glad you like it.
<StevenK> Neither.
<StevenK> Are they implemented now?
<StevenK> How about now?
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba* (allenap), jcsackett | Critical bugs: 267
<rvba> Morning jcsackett.
<jcsackett> morning, rvba.
 * jcsackett decides he needs more coffee after looking at the review queue
<rvba> hehe
<rvba> jcsackett: I'm sorry but I'm stuck with a critical bug I need to work on ... I'll take new reviews; I know the review queue is a little bit daunting.
<jcsackett> no worries, rvba. i'm juggling things today as well -- it happens. :-)
<rvba> jcsackett: ;)
<deryck> abentley, mumble time?
<nigelb> sinzui: Hey, you have a few minutes?
<sinzui> I will in a few minutes :)
<nigelb> :)
* rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugs: 267
<mrevell> Hey deryck, do you have time to talk about Steve Magoun's email in the next hour or so?
<deryck> mrevell, yeah, I can chat now.
<deryck> mrevell, mumble?
<mrevell> sounds good
<deryck> mrevell, meet me in Orange 1 o 1 then.
<mrevell> It's refusing to let me join
<sinzui> nigelb, I can talk now
<nigelb> sinzui: aha, so that bug about description - the database change has landed
<sinzui> nigelb, the status description we dropped?
 * sinzui tries to remember
<nigelb> no
<nigelb> hang on
<nigelb> the description we created in person
<nigelb> bug 5283
<_mup_> Bug #5283: "Home page" vs. "Description" is misleading <easy> <lp-registry> <qa-needstesting> <tech-debt> <ui> <Launchpad itself:Fix Committed by nigelbabu> < https://launchpad.net/bugs/5283 >
<sinzui> ah description and home_page
<nigelb> So, now its land garbo job and the temporarily insert into both columns.
<nigelb> I'm stuck at garbo job :)
 * sinzui thinks
<sinzui> nigelb, I wonder is step 3 (Update the index pages and forms to use the new field (do not show the old fields if the description is not empty)). is better to do next
<nigelb> sinzui: Ah! That's slightly more easier, and makes sense.
<nigelb> I won't be writing temporary code at least :)
<nigelb> Ohwait.
<nigelb> what about existing content?
<sinzui> If we update the template to use description OR old fields, we know users are always seeing the right data
<sinzui> the edit forms should only show the new field.
<nigelb> Ah.
<nigelb> That sounds good.
<nigelb> I'll get to it :)
<sinzui> nigelb, LaunchapdFormView has a property (default_values?) that is used to populate the form values. We often do not need it, but in this case, we can use it to concatenate the values in the old field in the rare case where an old team/person is edited
<nigelb> okay :)
<sinzui> nigelb, initial_values is the property that returns a dict of fieldnames and values
<nigelb> ok!
<mrevell> Night all
<SpamapS> Hey guys, getting OOPS's every time I search for 'zookeeper' on https://bugs.launchpad.net/juju
<SpamapS>  OOPS-2112K92
<SpamapS> other searches do not timeout
<elmo> it's a trap
<flacoste> gary_poster: very nice changes to the YUI XHR fixtures! will make it much easier to use thanks!
<gary_poster> cool, thanks flacoste :-)
<lifeless> SpamapS: cool
<deryck> lifeless, I violently disagree with "must be able to copy and paste in excel" as a requirement and that failing to do so is a regression.
<deryck> lifeless, if that becomes a requirement we might as well never change the UI.  It's a by product of a design that you can copy in a certain order.
<deryck> no one meant for that happen in the original design, I'm sure.
<lifeless> deryck: they didn't, and note that I didn't keep 'copy and paste' as my proposed requirement - getting the data *into* excel is the thing they need
<lifeless> deryck: e.g. the csv export
<lifeless> deryck: oem /currently/ depend on this
<lifeless> deryck: are you proposing we leave them high and dry for an unknown time period ?
<deryck> lifeless, no, of course not.
<deryck> lifeless, And I don't think anyone was saying that.  in fact, I told mrevell I think we can deliver csv pretty easy when we finish the bulk of the work in 4 weeks, but I'd prefer to see where we're at then.
<lifeless> deryck: I'm saying that if they cannot meet their use case that they can currently, its a regression
<deryck> lifeless, I thought mrevell echoed my "let's wait and see where we're at soon" sentiment.
<lifeless> deryck: sure; I'm saying that we shouldn't open the flag to OEM until we have CSV
<deryck> fair enough.
<deryck> lifeless, however, I don't like the word "regression" for this.
<lifeless> deryck: I'm not trying to say when-or-how, I'm trying to say that releasing this to them without a replacement for their use case will negatively impact them, and that we, in that discuss, were apparently not hearing that clearly enough
<deryck> lifeless, well, to be fair, there's a lot in the email thread. ;)
<lifeless> deryck: which is true, and fine :)
<deryck> lifeless, and also to be fair, the fact that they get by today is a happy accident.  I certainly don't want to make things worse than now, so we're in agreement.
<deryck> lifeless, but I just don't like all this regression talk when we never supported this use case yet.
<lifeless> the reality is that we do support it, even though we never intended to
<deryck> No, we don't support it.  We allow it.  Those are different things.
<flacoste> deryck: csv export wouldn't hard, but not trivial either since we are likely to hand the CSV generation to a job as not to timeout when there are lots of bugs (we shouldn't paginate CSV exports)
<flacoste> deryck: so we have all the infrastructure to implement this, but it's not a simple take the JSON and write it throug csv.DictWriter either
<flacoste> well, it's that, but needs some wrapping :-)
<deryck> flacoste, right, I didn't mean to imply it was that simple. :)  Just more attainable at the end of this work than at the beginning.
<flacoste> deryck: agreed
<lifeless> and I agree with the difficulty etc; I'm not suggesting we need to change the order we do the work in; but we do need to acknowledge and deal with their needs
<flacoste> SpamapS: that looks like bug 735966, weird though that only zookeeper search triggers it
<_mup_> Bug #735966: Product:+bugs timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/735966 >
<flacoste> lifeless: anything that could explain that Product:+bugs time outs when trying to ftq(zookeeper), but not without it?
<flacoste> on juju
<lifeless> posibbly cold pages in the text index
<lifeless> or pathological layout - we're at 98% bloat as of last night
<lifeless> I don't think stub has managed to fix it yet
<SpamapS> I can search for lots of other common things
<SpamapS> just not zookeeper
<lifeless> SpamapS: works for me
<lifeless> SpamapS: a bit slow - 107 queries/external actions issued in 8.86 seconds
<lifeless> re-running,
<lifeless> timeout
<lifeless> may be db server specific
<lifeless> flacoste: the main bugtask search is whats timing out
<lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-2112K92#longstatements
<flacoste> yeah, i saw
<flacoste> but since it seems to work for SpamAs when he doesn't use zookeeper as a term, i wondered if it wouldn't be only the ftq() clause that slows it down
<lifeless> flacoste: SpamapS: http://paste.ubuntu.com/707506/
<flacoste> lifeless: doesn't that confirm my hypothesis?
<flacoste> Index Scan using bug_fti on bug  (cost=0.00..1830.44 rows=51 width=761) (actual time=45.069..10902.728 rows=71 loops=1)
<lifeless> yes
<lifeless> sorry, am juggling a few threads right now
<lifeless> on my baby-addled brain (yesterday was first immunisation shots)
<flacoste> lifeless: ouch, yeah shots, that throws a baby sleep-cycle off for a week!
<SpamapS> lifeless: DTP, MMR, and the best immunity.. Diplomatic
<lifeless> SpamapS: :)
<lifeless> flacoste: so yes, 10 seconds to get 71 rows
<lifeless> flacoste: sick index
<lifeless> we need a new one and a pivot
<lifeless> this isn't automated yet and is tricky to do live
<abentley> deryck: http://people.canonical.com/~abentley/client-side-mustache.png
<abentley> deryck: I'd like to chat about how to maintain a common template for server side and client side.
<deryck> abentley, ok, may have to wait a bit.  I'm currently in 2 other conversations.  I'll try to wrap shortly and ping.
<abentley> deryck: okay.
<lifeless> flacoste:
<lifeless> https://launchpad.net/python-oops-tools
<flacoste> !
<flacoste> finally
<lifeless> flacoste: indeed, long road
<flacoste> lifeless: thanks for pushing this past the finish line!
<lifeless> flacoste: we still need to deal with the fallout: isd an u1 custom front pages were removed, branding cut back etc
<lifeless> flacoste: but I think folk will step up now that we can't cheat ;)
<lifeless> flacoste: and http://pypi.python.org/pypi/oops-tools
<lifeless> flacoste: hasn't rendered right, but meh :(
<lifeless> the hard part is ~ over
<lifeless> flacoste: so we used a new project to prevent old branches being pushed wrongly; I'm going to deactivate the old project
<lifeless> flacoste: It has 46 open bugs, I'm thinking to just manually retarget, no sql or anything - safer.
<lifeless> flacoste: unless you have a different recommendation ...
<flacoste> lifeless: nah, sounds fine
<lifeless> (and am leaving closed bugs behind)
<mwhudson> when i forget to land a change --no-qa, what should i do to the tags?
<mwhudson> mark it qa-untestable?
<lifeless> qa-untestable
<mwhudson> cool
<lifeless> and the old project disabled
<lifeless> nigelb: lp:python-oops-tools
<nigelb> lifeless: <3
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 267
<wallyworld_> sinzui: mumble is taking all my cpu and freezing. trying to fix
<jcsackett> sinzui: can you hear us?
<mwhudson> wallyworld_: try deleting ~/.MumbleSocket or something like that
<wallyworld_> mwhudson: i reboot fixed it, thanks :-)
<sinzui> wallyworld_, bug 663923
<_mup_> Bug #663923: Cannot view list archive of private team <mailing-lists> <ml-archive-sucks> <regression> <Launchpad itself:In Progress by mars> < https://launchpad.net/bugs/663923 >
 * StevenK glares at lifeless.
<lifeless> StevenK: oh?
<StevenK> lifeless: Reassigning 52 bug pillars
<lifeless> StevenK: faster this way
<lifeless> wait for me to get going on the high review
<StevenK> Uh oh, I've broken Mumble.
<StevenK> I shaded it, which Unity took as minimising.
<StevenK> Using the Mumble notification to bring the window back shows the toolbar. Only.
<StevenK> Oh look, I fixed it.
<lifeless> flacoste: I've mailed stub about bug_fti
<lifeless> flacoste: to execute his evil workaround
<flacoste> lifeless: thanks!
#launchpad-dev 2011-10-14
<poolie> hi flacoste, all
<wgrant> [A3
* wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Critical bugs: 267
<wgrant> jelmer_: Around?
<wgrant> jelmer_: Any reason not to revert your bad codeimport stacking branch?
<jelmer_> wgrant: it's a trivial fix
<jelmer_> also, hi :)
<wgrant> Ah, your presence is unexpected. Hi.
<wgrant> That's good.
<wgrant> If you can land it before the weekend, I guess it can stay.
<wallyworld_> poolie: i just claimed your mp before i saw aaron's comments. are you working on making changes?
<poolie> i think my cover letter was just really confusing :/
<poolie> so i haven't made any code changes but i have explained it better and generated the right diff
<wallyworld_> ok. i'll have another look
<poolie> i see he replied
<poolie> wallyworld_: thanks, i replied again
<poolie> nb there's a new mp for it
 * wallyworld_ looks
<wallyworld_> poolie: doesn't look like you've reclassified the diff generation error? or am i looking at the wrong mp? i can only see one
<poolie> i accidentally deleted the old one
<poolie> https://code.launchpad.net/~mbp/launchpad/612171-diff-generation-spam/+merge/79351
<poolie> but you may still have mail about the old thing
<wallyworld_> that's one one. but there's no code to raise a different exception etc as discussed in the comments
<poolie> yeah we talked about doing it (10m ago) but i haven't done it
<poolie> yet
<wallyworld_> ah ok
<poolie> wallyworld_: any comments beyond that?
<poolie> curious what you think about testing logging ,from your experience elsewhere
<wallyworld_> poolie: i was avoiding that issue :-)
<wallyworld_> but i sort of agree with your take on it
<wallyworld_> so long as nothing breaks, to me it's logging etc is orthogonal to the core functionality
<poolie> the only test is really "can I solve my problem further down the line"
<poolie> the validation level is more important than the verification
<wallyworld_> and so we can avoid being too pedantic about explicitly testing it to the same level as other code
<wgrant> poolie: What takes so long to get LP running again each time?
<poolie> "does the right thing" vs "does it right"
<wgrant> sudo apt-get update; sudo apt-get upgrade; rocketfuel-get should do it.
<poolie> from someone i got the idea i should not use rocketfuel-get to update, but rather update the directories directly
<poolie> but, an example is for instance allenap's storm psql bug yesterday
<poolie> or, um
<StevenK> I always use rf-get ot update
<wallyworld_> poolie: if the output were being consumed by a reporting package or something else downstream where there were a formal intergration contract etc, then it would be different
<poolie> i see rf-get fails in a colo branch
<poolie> i don't know, it just seems like there's always a snag
<poolie> w: yeah
<poolie> wgrant: you must have seen me come on here and say "why am I getting random error X when I try to run the tests?"
<wgrant> poolie: True.
<poolie> i can still get stuff done but it does show up
<poolie> i suspect it's about a constant factor whether you try to do 4 hours of lp per week or 40
<poolie> a constant amount of hassle, but the percentages are worse
<wgrant> It probably works better if you don't also have an unstable distroseries involved.
<poolie> that is part of it
<poolie> i did see some snags when running earlier series though
<wgrant> Hmm.
<wgrant> I have little friction with a Lucid LXC container.
<poolie> oh, another example would be the thing you helped with a while ago, where one of the js symlinks was wonky
<poolie> it's not awful
<poolie> but it could be a bit easier
<poolie> i think paul is jumping to conclusions a bit by asking for debs
<poolie> otoh perhaps we could have recipe builds of more things that are currently brancehs
<StevenK> Debs of Launchpad?
<poolie> no of dependencies
<poolie> for instance of bzr or of mailman
<StevenK> mailman is difficult, since we monkey-patched it
<wgrant> bzr is an egg, too.
<wgrant> While using the packaging system would be nice, it's not practical for our deployment strategy.
<wgrant> Because we need multiple concurrent versions of LP to run at once.
<wgrant> And Debian packaging does not support that.
<poolie> right
<poolie> you would need to run them inside some kind of container which would be probably difficult and maybe not have any other benefits
<poolie> so that's why i say i think sladen is jumping to solutions
<wgrant> Yes.
<wgrant> LP development could certainly suck a lot less.
<wgrant> But packaging is not going to help that.
<wgrant> One does not develop using packages.
<wgrant> One cannot reasonable deploy using packages.
<wgrant> => packages are not a benefit.
 * wgrant reverts r14149, since buildbot doesn't like yuixhr apparently.
<wgrant> mwhudson: Linaro doesn't produce XM builds any more?
<mwhudson> wgrant: a lot of the time when linaro says "beagle" it really means "beagle xm"
<mwhudson> wgrant: or do you mean something else?
<wgrant> That's what I meant.
<wgrant> Ah, there are community "BeagleBoard" builds down the bottom.
<mwhudson> in terms of architecture i think they're fairly similar
<mwhudson> although the xm is a bunch better specced, obviously
<wgrant> Yep.
<wgrant> Thanks.
<lifeless> poolie: debs for dependencies is a no-show until we have concurrent versions installed in dpkg, or we radically change our deployment story
<lifeless> poolie: did you want to talk about the jobs thing ?
<StevenK> lifeless: wgrant and I would like to talk about the privacy enum when you're free
<wgrant> Private teams.
<lifeless> sure
<lifeless> I'm here all week
<StevenK> Except Wednesday :-P
<lifeless> did you want voice?
<StevenK> Yeah
<StevenK> Let me grab my laptop so I can do this whole Skype thing
<lifeless> sounds good (har har)
<StevenK> Boo, hiss
<StevenK> wgrant: Hai ^
<wgrant> I'm there.
<StevenK> Waiting for laptop to boot
<wgrant> StevenK: I'm trying to invite you.
<wgrant> StevenK: Do you want to host?
<StevenK> I don't mind either way
<wgrant> lifeless is supposedly calling you now.
<StevenK> Oh, sigh, Skype is being crap
<wgrant> We can't bring you in...
<lifeless> StevenK: 'remote sound problem'
<StevenK> Problem with playback device and then it hangs up
<lifeless> StevenK: try hosting it
<wallyworld> StevenK: do you know about security adaptors?
<StevenK> wallyworld: ... what about them?
<wallyworld> StevenK: i want to use one for a method on an object, but from what i can tell looking in security.py, they are declared for the entire object
<wallyworld> so i want a mechanism for method level permissions
<StevenK> Security is declared by interface
<StevenK> In ZCML
<wgrant> wallyworld: We need a specific example.
<StevenK> So you can split the interface into another and change permissions for that one interface in the ZCML
<wgrant> StevenK: Not quite.
<wallyworld> i want a specific set of permission checks for destroySelf() on BugTask
<wallyworld> that do not mess up any existing permissions
<wallyworld> so i guess i would have a IBugTaskDelete interface
<wgrant> You may be able to use launchpad.BugSupervisor.
<wallyworld> with the destorySelf method on it
<wgrant> Or you could do permission checking inside destroySelf.
<wallyworld> i could but i was wanting to try and use the zope security model
<wgrant> StevenK: Could you reinvite me, please?
<StevenK> wgrant: I have been trying
<lifeless> wgrant: can you see my ping ?
<wgrant> I can.
<lifeless> X getting OOM killed == bad
<StevenK> And wgrant puts me on hold. Hah.
<poolie> mwhudson: hi, the more i think about it the more i think oauth-based ssh would be good
<poolie> https://answers.launchpad.net/bzr/+question/174075 is the second example today of someone having trouble making ssh keys
* wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 267
<lifeless> rvba: btw we don't use wishlist - just low
<lifeless> rvba: (because there isn't a useful difference)
<stub> Any objections if I take down staging and qastaging for a few minutes soon?
<rvba> lifeless: okay, thanks for the heads up
<mrevell> Hello 'padders
<jtv> hi mrevell
<adeuring> good morning
 * danilos pulls his hair because local codehosting now doesn't work for him, yet it used to work just fine two days ago... argh
<wgrant> danilos: You're still looking at the buildfarm issue?
<jtv> adeuring: are you reviewing today?  Got a simple one for you: https://code.launchpad.net/~jtv/launchpad/bug-812500/+merge/79373
<adeuring> jtv: I'll look
<jtv> thanks
<danilos> wgrant, yeah
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Critical bugs: 267
<danilos> wgrant, so, log files are still not recorded for translationtemplatejobs, and I want to see why is that
<wgrant> danilos: Do you have a local builder?
<danilos> wgrant, because the job kicks in, and then fails at the last moment, it could be simply that intltool is not installed
<wgrant> Yeah.
<danilos> wgrant, yeah, I am trying to get that set-up
<wgrant> I could also see if I can convince it to do something on DF.
<wgrant> Or locally.
<danilos> wgrant, but now that soyuz seems to work locally, code-hosting is broken for me :/
<wgrant> Hah.
<wgrant> What's it doing?
<danilos> wgrant, well, not accepting connections when I try to bzr push lp://dev/...
<wgrant> You're doing make run_codehosting?
<wgrant> Not just make run?
<danilos> wgrant, and I already changed the poppy port to 5022
<wgrant> (make run_all works too)
<danilos> wgrant, I was doing make run_all
<wgrant> Hm, codehosting normally listens on .99:5022
<wgrant> poppy-sftp may well be listening on *:5022
<wgrant> Or does codehosting listen on .88:5022... I can't quite remember.
<wgrant> Host bazaar.launchpad.dev HostName launchpad.dev Port 5022
<wgrant> That's .88:5022
<danilos> well, they were conflicting the other day, I used to just kill poppy to make it work, but now after doing a fresh 'make schema', and then make-lp-user, I am having trouble getting it to listen properly on any port
<wgrant> I don't think I've run them simultaneously since poppy started listening on 5022
<danilos> wgrant, so, sftp.tac is also listening on .88:5022
<danilos> but run_codehosting wants to run it like that :/
<wgrant> Best to move poppy-sftp. Add another 0 or something.
<danilos> wgrant, I've moved it to 5023 already (and confirmed with netstat -palnt)
<wgrant> Oh, you said above you'd changed it to 5022 :)
<wgrant> There's no stale bzr-sftp lock?
<danilos> wgrant, so, I ain't sure what daemons/sftp.tac presents, because it's run directly by "make run_codehosting", is that poppy? I don't think so because there's poppy-sftp.tac as well
<wgrant> sftp.tac is bzr-sftp
<wgrant> /var/tmp/development-sftp.pid may be relevant and stopping it from starting.
<wgrant> Of course, if you're not dealing with packages then you don't actually need poppy at all.
<danilos> wgrant, right, I've killed it in the meantime, but it hasn't helped now (that's how I initially solved the problem of conflicting ports, thought I'd be smarter this time :)
<wgrant> Heh.
<wgrant> I just changed its sftp port to 50022, and now both are running fine.
<danilos> wgrant, hum, yeah, I guess something else is borked here for me, I may have to start from scratch if I don't want to spend too much time trying to debug local setup
<wgrant> danilos: What if you blow away all the pidfiles in /var/tmp?
<danilos> wgrant, nope, doesn't help, log file does have some interesting input like https://pastebin.canonical.com/54374/
<wgrant> Ohh.
<danilos> I am not sure why it's passing around danilo@bazaar.launchpad.dev as the email since I've made an LP user with my canonical.com address
<wgrant> Ctrl+C, rm /var/tmp/launchpad_forking_service.sock, make run_codehosting
<wgrant> The forking service likes to leave its FIFO around.
<wgrant> danilos: What's a good branch to test with?
<danilos> wgrant, lp://staging/~danilo/translated/trunk should be good enough (and small), lp:eog is another good candidate
<wgrant> Thanks.
<danilos> wgrant, depending on when you set-up translations import (i.e. before or after the branch is scanned), you may want to push another revision since only the branch scanner actually creates templates build jobs
<wgrant> Yep.
<danilos> wgrant, and yes, the socket file was the problem, thanks for helping out
<adeuring> jtv: your changes , but what about a test?
<jtv> adeuring: the case is tested; it just wasn't tested realistically.  So the first thing I did was fix the test by using a slave-store object, so that it broke in the same way as production.
<jtv> The main code change then fixes that failure.
<adeuring> jtv: gah, sure -- seems that I had not have enough coffee. r=me
 * jtv looks up the diff
<jtv> Ah.  :)  Thanks!
<jtv> Phew, yes, it's right there, with a comment.
<jelmer_> jtv: I think bug 375013 is already fixed for Launchpad, isn't it?
<_mup_> Bug #375013: Cannot commit directly to a stacked branch <commit> <launchpad> <lp-translations> <rodeo2011> <stacking> <Bazaar:Fix Released by jameinel> <bzr-builder:Fix Released by jelmer> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/375013 >
<jelmer_> jtv: nevermind, I only just got the notification of your linked branch
<jtv> ok
<jelmer_> jtv: nice to get rid of another workaround :)
<jtv> jelmer_: yup, paying off our tech debt.  Too bad I can't tag the bug as tech-debt, because it only applies to the Launchpad task.
<wgrant> danilos: All working now? My local attempts were delayed when I realised that lpbuildd won't work in LXC.
<jtv> jelmer_: feel like reviewing it?  https://code.launchpad.net/~jtv/launchpad/bug-375013/+merge/79378
 * bigjools sighs at bugspam from lifeless
<jtv> Ah yes, always nice to get mail.
<bigjools> maybe I should do what mwhudson did and upgrade to oneiric and have 10k emails deleted
<jtv> That sounds efficient.
<jtv> Inbox Zero, wayhay!
<bigjools> I am practising inbox ~750
<StevenK> I am currently on inbox 17,425
<bigjools> there was something I read recently about people who hoard everything in their inbox are quicker at finding emails that those who file them away
<danilos> wgrant, not really, fighting the build-queue-builder readding "missing" stuff to buildqueue which I don't care about and which makes it fail
<wgrant> Why are you running queue-builder?
<danilos> wgrant, I thought it was a replacement for buildd-manager, but I guess I was wrong ;)
<wgrant> queue-builder is ancient and probably doesn't work any more.
<wgrant> It served a different purpose to buildd-manager.
<danilos> wgrant, now, I only have an issue where bob the builder is not considered a PPA builder, and translation template jobs seem to be
<danilos> wgrant, right, I thought it was a newer "builder" for stuff in the "build queue" :)
<jelmer_> jtv: Sure, I'll have a look
<wgrant> danilos: https://launchpad.dev/builders/bob/+edit, check "Virtualized", and enter garbage for the VM host.
<jtv> thanks jelmer_!
<danilos> wgrant, cool, thanks; I wonder what do I make ftpmaster.internal resolve to (https://pastebin.canonical.com/54376/)
<wgrant> danilos: Just ran into that myself. archive.ubuntu.com should work.
<wgrant> (but I changed the URL in the chroot)
<danilos> wgrant, right, I'd probably even add my local apt-cacher-ng proxy there, but I don't want to get into editing a chroot tarball now :)
<wgrant> cd /tmp/; sudo tar xf ~/Downloads/chroot-ubuntu-natty-i386.tar.bz2; sudo sed -i s/ftpmaster.internal/blah.blah.blah/ /etc/apt/sources.list; sudo tar jcf ~/Downloads/chroot-ubuntu-natty-i386-2.tar.bz2 chroot-autobuild; scripts/ftpmaster-tools/manage-chroot.py -s natty -a i386 -f ~/Downloads/chroot-ubuntu-natty-i386-2.tar.bz2 add
<wgrant> danilos: No module named canonical.buildd.pottery
<wgrant> Hahahaha
<wgrant> There's our problem.
<wgrant> Bad Translations team is bad.
<wgrant> it's copying into python2.6 in the chroot.
<danilos> wgrant, thanks :) I am having it building like this as well, but actually, it worked for me :/
<wgrant> So when the default Python version changed to 2.7...
<wgrant> danilos: Which chroot are you using?
<danilos> wgrant, lucid
<wgrant> Pre-Natty?
<wgrant> Yeah.
<wgrant> that's the problem.
<danilos> wgrant, yep, that explains it
<wgrant> And why it broke in October.
<wgrant> We use the dev series chroot.
<wgrant> So, it's been entirely broken for a year and nobody really noticed... amusement.
<wgrant> $ grep -r python2.6 .
<wgrant> ./generate-translation-templates:PYMODULES=/usr/lib/pymodules/python2.6
 * wgrant looks disapprovingly.
<danilos> wgrant, well, it's been noticed, but those who did were never sure if it was supposed to work considering it was such a recent feature anyway
<wgrant> Still, there's also LP-side bugs causing logs to not happen.
<danilos> wgrant, right, I'd like to fix that: any idea why the log file would not be recorded?
<danilos> wgrant, as for the python detection, even though I hate sh scripts like these, our best bet is probably to go with modifying PYTHON_PATH instead; what do you think?
<wgrant> danilos: Well, or we could s/2.6/2.7/... ahem.
<wgrant> As for the log issue, see TranslationTemplatesBuildBehavior.updateBuild_WAITING
<danilos> wgrant, yeah, and trust that Barry's claim how there won't be further pythons in 2.x series :) works for me, though, but we are ultimately going to switch LP to 3.0 as well, and then there'll be more fun
<wgrant> danilos: The BPB/SPRB equivalent of updateBuild_WAITING calls handleStatus, which calls _handleStatus_PACKAGEFAIL in this case.
<wgrant> See PackageBuildDerived._handleStatus_PACKAGEFAIL for our log storing stuff.
<danilos> wgrant, thanks
<danilos> wgrant, I assume storeBuildInfo does that based on the slave_status?
<wgrant> danilos: I believe so.
<wgrant> Actually, slave_status is just used to find missing dependencies.
<danilos> wgrant, I so want to fix bug 691530 as well, but I don't have the time
<_mup_> Bug #691530: Split up TranslationTemplatesBuildJob into a BranchJob and BuildFarmJobOld <lp-translations> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/691530 >
<wgrant> But storeBuildInfo is pretty obvious mostly.
<wgrant> danilos: I think there'll be a better refactoring around that area once we get SOA stuff going. But that will be after your time, sadly.
<danilos> wgrant, yeah, but this is bound to be broken once the refactoring happens simply because it's one class pretending to be two things at the same time, iow, very easy to confuse what it's doing
<wgrant> danilos: Well, the model will hopefully be thoroughly rethought and reworked at that point.
<wgrant> danilos: But for now if you can store logs, we may be in a better state to diagnose this within 12 months :)
<danilos> wgrant, right, supposedly that'll help
<danilos> wgrant, heh, exactly, I'll get that done
<wgrant> Should be pretty easy.
<wgrant> Just steal bits of storeBuildInfo :)
<adeuring> gmb: a question to you as the "retired bug import specialist": Did you see this MP: https://code.launchpad.net/~ceejatec/sfbugs2launchpad/user-mapping/+merge/78076 ? looks really interesting to me, but you have more experience with bug imports.
<adeuring> the core change is a better mapping of SF user names to LP names
<gmb> adeuring: I'll take a look.
<adeuring> gmb: cool, I'm asking for just a general assessment. I see a number of small issue, and one bigger problem: the script becomes complex enough to devsreve testing
<gmb> adeuring: Ah, I hate it when that happens :)
<adeuring> but otherwise, I think is it a very nice imporvementz
<gmb> adeuring: Okay. I'll cast a weather eye over it and see if I spot anything.
<adeuring> gmb: cool, I would do a detailed review,  but I'd appreciate a "general comment" from you
<gmb> adeuring: Righto, I shall endeavour to provide one, then :)
<gmb> adeuring: That's a really cool branch. I don't see anything glaring at me about the way it does things, but I agree that that script requires some tests now.
<adeuring> gmb: ok, thanks! I'm now more comfortable to review the M :)
<danilos> wgrant, btw, it was my understanding that all the indirection through .specific_job.build should be gone by now already, I guess it turned out to be impossible? (current state of things confuses me to no end, I am never sure what object type is the right one to pass around for these kind of things)
<wgrant> danilos: Not impossible, just a bit of work.
<gary_poster> sinzui, hi.  I'd like to talk sometime this morning about the possibility of html5browser growing the abilites to notice incremental test progress; to report what incremental records it saw, if anything; and to have timeouts per-increment in addition or instead of per-page.  I'll look into the code and see if I think I can pull this off.
<gary_poster> This is because of a buildbot test failure on something that passed locally and in ec2 but failed in buildbot with only the report "timeout error." That doesn't give me much to go on when the test passes in 10 seconds locally in a vm, and the timeout limit is 30 seconds.
<sinzui> gary_poster, okay
 * sinzui needs to review what hh wrote
<gary_poster> thanks sinzui.  I have a doctor visit later this morning.  lemme know when you are available
<gary_poster> I mean, later, when you are
<jelmer_> hmm, it seems somewhat odd I'm rewarded with a higher build score for doing PPA builds in private rather than in public
<bigjools> jelmer_: not at all - we consider private builds more urgent
<wgrant> jelmer_: Well, people with private PPAs are generally either privileged Canonical people or commercial customers.
<jelmer_> bigjools: s/private/commercial/ ?
<bigjools> what he said
<wgrant> ie. they're not random daily builds of web browsers that take 4 hours each and there are 40 of them a day.
<jtv> Thanks jelmer_
<jelmer_> jtv: geen dank :)
<jtv> :)
<gary_poster> sinzui, I've made it through my email. Are you going to be available for a hopefully quick call within the next 30 minutes, or will it be sometime after that?
<sinzui> gary_poster, I should be ready in 15 minutes
<gary_poster> great thank sinzui
<gary_poster> s
<dobey> Internal Server Error
<dobey> ShortListTooBigError
<dobey> whee :(
<abentley> sinzui: I have a file being linted that shouldn't be linted.  Are you around to chat?
<sinzui> abentley, you are in a queue. Gary is the next out
<gary_poster> :-)
<abentley> sinzui: cool.
<gary_poster> I'll try to be quick
<jtv> jelmer_: getting a strange test error from code I didn't touch... ImportError: No module named builder.recipe
<sinzui> abentley, I have a list of things I do not wanted linted too.
<jtv> jelmer_: any ideas?
<sinzui> gary_poster, I am on mumble?
<jelmer_> jtv: hmm, not sure. it sounds like it might be related to removing an import of lp.codehosting somewhere, either directly or indirectly?
<jtv> jelmer_: I was thinking, maybe because the auto-import-formatting-tool has moved it.  I tried moving it back, but with the test trouble on oneiric it's hard to keep track of which test run has it which way!
<sinzui> hi abentley
<abentley> sinzui: hi.
<abentley> sinzui: mumble in orange 1o1?
<sinzui> abentley, I think this is the sed fix: -e '/@$/d'`
<abentley> sinzui: cool.
<jtv> jelmer_: yup, got a successful one at last.  It's a matter of importing the bastards in a specific order.
<jtv> We really should fix this.
<jelmer_> jtv: urgh, indeed
<jtv> ./utilities/format-new-and-modified-imports orders imports in an agreed, canonical way.
<jtv> And, it seems, breaks some code that relies on lp.codehosting's import side effects in particular ways.
<abentley> adeuring: could you please review https://code.launchpad.net/~abentley/launchpad/support-mustache/+merge/79404 ?
<adeuring> abentley: sure
<adeuring> abentley: r=me
<abentley> adeuring: thanks!
<cjwatson> bug 874298 (which I'm working on fixing) - any reason not to use lp-query-distro to get the list of architectures as well as the suite, given that it already supports this?
<_mup_> Bug #874298: cron.germinate needs to be fixed to examine the armhf architecture <Launchpad itself:New> < https://launchpad.net/bugs/874298 >
<cjwatson> the hardcoded architecture list looks like elderly cruft to me
<cjwatson> adeuring: ^- as OCR?
<adeuring> cjwatson: I must admit to have no clue without a closer look...
<cjwatson> I can just submit the 30-line patch for review if you prefer that over a pre-impl chat
<adeuring> cjwatson: well, I'd prefer if you could discuss this with somebody who has more soyuz-fu than myself ;)
<cjwatson> jtv: maybe if you're available?
<bigjools> cjwatson: #sup?
<cjwatson> bigjools: bug 874298, any reason not to use lp-query-distro to get the list of architectures as well as the suite, given that it already supports this?
<_mup_> Bug #874298: cron.germinate needs to be fixed to examine the armhf architecture <Launchpad itself:New> < https://launchpad.net/bugs/874298 >
<cjwatson> just checking before I submit this branch for review
<bigjools> checking
 * jtv looks at what cjwatson & bigjools are discussing
<bigjools> cjwatson: +1
<bigjools> cjwatson: FWIW I consider that code to be yours anyway
<bigjools> I eventually want it out of our tree so you can manage your scripts in the .d directories
<jtv> It _sounds_ sensible, but then cron.germinate is a script I haven't been told to rewrite yet.  :-)
<jtv> Yes yes yes
<cjwatson> bigjools: yep, indeed I mentioned that in the merge request.  https://code.launchpad.net/~cjwatson/launchpad/germinate-armhf/+merge/79416
<bigjools> cjwatson: lol @ pre-imp notes
<cjwatson> context is for losers
<bigjools> cjwatson: it's approved
<cjwatson> ta
<cjwatson> bigjools: if you wouldn't mind landing it for me, that would be brilliant
<bigjools> ok
<cjwatson> bug 874377 is a regression
<_mup_> Bug #874377: sync-source.py is broken: Values instance has no attribute 'moreverbose' <Launchpad itself:New> < https://launchpad.net/bugs/874377 >
<dobey> sinzui: do you know how to fix bug #870130? hit the same error today, not even trying to build the recipe, but just edit it.
<_mup_> Bug #870130: OOPS when requesting recipe build <easy> <oops> <recipe> <Launchpad itself:Triaged> < https://launchpad.net/bugs/870130 >
* adeuring changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 267
<sinzui> dobey, I do not exactly, but I expect anyone on the maintenance team can fix the issue in 2 hours using my summary of the historic issue
<dobey> sinzui: should we bug someone in particular?
<sinzui> dobey The other route is to delete things that are causing the oops. The only thing I see from the candidate list is branches
<sinzui> hmm
<sinzui> we seem to be missing the Americans who are on maintenance
<dobey> sinzui: hrmm. can you tell what's causing it exactly?
<dobey> sinzui: ah, they are on holiday today?
<sinzui> maybe
<sinzui> dobey per the bug, Lp is preparing to send an email, so it makes a copy of the thing in the email. It is coping 1000's of things that you will never ever every never see.
<dobey> sinzui: fun times :-/
<sinzui> Since this issue only happens in a few cases, I believe that early adopters of recipes or bug users are branches are all heading to a bug pile up
<sinzui> We have known about this issue for 18 months, we wrote code to ensure it will not happen, but developers and reviewers do not enforce the rules
<sinzui> The fix really is fucking trivial
<dobey> heh
<sinzui> dobey: I am feeling unproductive today. I will attempt to fix this after lunch if no maintenance teams see that this bug blocks Canonical projects from meeting their goals
<dobey> sinzui: you haven't eaten yet?
<sinzui> too many machines broken by oneiric upgrades. There is a queue to get the one network cable in the house
<dobey> :-/
<dobey> ugh, and LP just changed a bug to "confirmed" because someone clicked "affects me too" on it, even though the bug was already marked a dup
<lifeless> dobey: theres a bug for that
<dobey> cool
#launchpad-dev 2011-10-15
<wgrant> jelmer_: I'm reverting the codeimport stacking stuff so we can deploy on Monday.
<jelmer_> wgrant: ok
#launchpad-dev 2011-10-16
<lifeless> cr3: ol
<lifeless> ola
<nigelb> Morning lifeless :)
<nigelb> Damn, its still yesterday for me.
<lifeless> it always will be
<lifeless> nigelb: hey, hows the jsoopsd going ?
<nigelb> lifeless: Haven't started yet. Life.
<lifeless> :)
<cr3> lifeless: hola senor!
<lifeless> cr3: I'm wondering how to get the service integration for the results tracker underway
<lifeless> cr3: like e.g. should we identify a couple of useful steps and create bugs for the, ?
<lifeless> s/the,/them/
<cr3> lifeless: my understanding is that the next step consisting of auditing the code, does that sound about right?
<cr3> lifeless: if so, I thought that perhaps having a production instance running might be useful which was completed last week. however, only IS has access to that instance, so I'm not really sure that was really a blocker come to think of it
<lifeless> :)
<lifeless> so the code review was part of being willing to open backend ports betwee it and LP
<lifeless> we kindof need to do that & the first backend service at the same time
<cr3> lifeless: what do you mean by "first backend service"?
<lifeless> service call
<lifeless> thing where it calls into LP via a trusted API
<lifeless> e.g. direct person access
<cr3> lifeless: ok, does LP already have direct person access?
<lifeless> currently the only APIs for person at the launchpadlib ones - which means you'll run into trouble if the account is renamed
<cr3> lifeless: btw, opening backend port can be done as one step and then actually using that port a second step
<lifeless> sure, I kindof like to have a use case up my sleeve when changing firewall rules - so that someone monitoring can see it gets used.
<cr3> lifeless: do you envision the person access needing a microservice of its own? how will that work?
<lifeless> long term we might do a dedicated directory service, yes.
<lifeless> medium term LP is the directory, so I'd expect targeted APIs on its services
<cr3> lifeless: short term, database access? privileges launchpadlib api?
<lifeless> 9
<lifeless> bah
<lifeless> no, no db access, ever ever ever ever evcer
<cr3> good, I was going to whine otherwise :)
<lifeless> possibly a privileged lplib API, or an xmlrpc api
<cr3> lifeless: ideally, I'd like for the results tracker to still be runnable standalone by people on the outside. although that's my problem, just thought I'd share some of my pain :)
<lifeless> cr3: thats a good goal, but there are two very distinct paths to it
<lifeless> cr3: one path is to say 'run up as much of LP, *or equivalent services*, as the tracker needs'
<lifeless> cr3: the other path is to say 'the tracker knows how to run standalone and how to run integrated'
<cr3> lifeless: I could start looking into contributing a person access, any preference between lplib api or xmlrpc? I think there's more lplib api precedent for my inspiration, so that would be my inclination
<lifeless> cr3: launchpadlib API only knows how to speak active urls; I don't think there is -any- precedent for using things that aren't exposed in the regular traversable fashion over lplib
<cr3> lifeless: I was leaning towards the latter: being able to parameterize whether the tracker is running integrated or standalone
<lifeless> cr3: that implies that you'll have two copies of every template, for instance (one for standalone, and one in the lp template service for integrated)
<cr3> lifeless: I haven't even started thinking about the user interface, I'm hoping to find a way to make template sharing possible somehow
<lifeless> cr3: If I were working on it, I wouldn't do a standalone mode; I would make the services it depends on clear, crisp, contracts, so that thin versions can be written and combined to run outside of LP
<cr3> lifeless: maybe a tracker aware zope component that points to templates in the tracker codebase, I really don't know
<lifeless> cr3: That sounds awfully complex vs saying 'templates are in the LP tree'
<cr3> lifeless: to me, "LP tree" means it can't run standalone
<cr3> lifeless: anyways, we'll burn that templates bridge when we're on it, lets concentrate on the person access service for now :)
<lifeless> so to define it, we need to figure out what data you need, and in what access patterns, so that you can drop your mirrored person table
<lifeless> (or reduce it to non-duplicated data [e.g. an enterprise-wide person reference]
<cr3> lifeless: I'm not sure I understand "aren't exposed in the regular traversable fashion", I was thinking something like the hwdb in the lplib api which is only accessible to members of a particular group
<lifeless> cr3: the hwdb is still referencing things by their current url
<lifeless> cr3: the current url might be defined in an immutable fashion, but its still 'current url'
<cr3> lifeless: could the enterprise-wide person reference be the database sequential id in lp or are we thinking of something wider than that?
<lifeless> cr3: I don't think it can, no. Person ids get merged.
 * cr3 will probably have to research how others have solved this problem before
<cr3> lifeless: just for my edification, when do person ids get merged?
<lifeless> or rather, it may be we can use the row key, but we need a way to handle lookups on persons that have been merged
<lifeless> cr3: 'claim my account'
<lifeless> cr3: or 'this person is me'
<cr3> lifeless: ok, solving this problem will probably be useful for me in other contexts too, like when merging similar systems for ubuntu friendly
<cr3> lifeless: do you know if this problem has been tackled before within canonical? any leads you know I should be following to start my exploration down this person access service?
<cr3> lifeless: also, should we create a bug as you suggested before, or something else, to keep track that someone is looking into this?
<lifeless> so, I think you need to look at how you use the mirrored person metadata
<lifeless> and you need to make a bug / LEP that says 'results tracker needs real-time access to <foo> for <bar>' (repeat items in the bug/lep for batch vs single vs search)
<lifeless> then we can think about how best to expose that and things that will cause trouble.
<cr3> lifeless: sounds like a plan. I'm not entierely clear but it certainly gives me something to do and bounce later for feedback.
<lifeless> cool
<cr3> I need to jet for now, thanks for the guidance!
<lifeless> to help clarity: look at your mirrored metadata; look at where you use it (queries, batches, individual templates) and write up a list so that we can together figure out how to meet those uses without you mirroring [all] of the data.
<lifeless> bwah
<lifeless> has anyone around atm setup a local oops-tools instance before?
<jelmer> no
<jelmer> also, g'morning :-)
<lifeless> hi :)
<nigelb> evening jelmer :)
<jelmer> hey Nigel, what are you hacking on?
<nigelb> jelmer: Nothing much tonight :)
<nigelb> Need to do some stuff over the week.
<lifeless> hmm
<lifeless> I wants rabbitmqadmin packaged :)
<lifeless> ah , it is
<lifeless> where is that hack to change the command line ?
<lifeless> (to hide passwords etc)
<mwhudson> setproctitle?
<lifeless> ah thanks
<lifeless> I suspect I won't use it here (anyone with access to the same machine has access to the prod configs...)
<lifeless> but its nice to remember it exists
<lifeless> also
<lifeless> amqp for oops-tools. Done.
<lifeless> \o/
<mwhudson> i don't know if using that for security is valid btw, there might be some way of digging out the original command line
<lifeless> mwhudson: + race conditions
<lifeless> python takes a while to start up after all
<mwhudson> yeah, that too
<lifeless> did I mention amqp ?
<lifeless> :P
<mwhudson> yes, that sounds very nice :)
<lifeless> https://code.launchpad.net/~lifeless/python-oops-tools/amqp/+merge/79505
<lifeless> (diff is there now)
<lifeless> righto and local setup working. \o/
<wgrant> lifeless: lucid?
<lifeless> wgrant: of course
<lifeless> anyone else seeing "Launchpad encountered an internal error during the following operation: generating an incremental diff for a merge proposal.  It was logged with id OOPS-2115MPJ4.  Sorry for the inconvenience"
<lifeless> I thought we had incrementals turned off ?
<wgrant> They're not displayed.
<wgrant> But I think they're still generated.
<wgrant> And yes, we've had a couple of reports of that last week.
<lifeless> win ec2
<lifeless> ec2test@i-da2526ba$ cd /var/launchpad/test; bzr merge lp:~lifeless/launchpad/useoops
<lifeless> ssh: connect to host ec2-50-17-126-253.compute-1.amazonaws.com port 22: Connection timed out
#launchpad-dev 2012-10-08
<wgrant> I'm on the way
<wallyworld_> i'll do the hg branch then
<StevenK> Excellent. I don't want to kill it, I just want to see it dead.
<StevenK> wgrant: Shall I commit a change to dbpatches -- 36-1 for me for DROP COLUMN private_bugs and 36-2 for you to kill BVP?
<StevenK> Hmm, you already have one, 26-[01]
<StevenK> wgrant: In that case, can I co-opt 26-2 to DROP COLUMN private_bugs ?
<StevenK> Sigh, I should learn to read at some point.
<wgrant> StevenK: You should probably use 26-5 or so
<StevenK> Yeah, I just picked 26-5
<wgrant> Oh right, forgot about hg
<mwhudson> are private bps in a useful state yet?
<wgrant> They break everything
<wgrant> But they are private, I believe
<mwhudson> heh
<mwhudson> do they make listing views 403 and such?
<wgrant> Right, that sort of thing
<mwhudson> are they being worked on by anyone?
<wgrant> The most egregious regressions were fixed a few days after they were switched on on production
<wgrant> But they're still working on the others
<wgrant> They should be fixed soon
<mwhudson> ok cool
<mwhudson> are they feature flagged ?
<wgrant> To beta-testers, I think
<wgrant> Some would say that the beta test is slightly premature
<mwhudson> ah, i think i need to acquire a commercial subscription to do anything
<wgrant> Right
<wgrant> A project needs a commercial sub to enable proprietary features.
<wgrant> And there's no security- or user-related private blueprints
<mwhudson> do you know if linaro projects can get a commercial sub by asking?
<wgrant> I believe that's still the case.
<mwhudson> cool
<wgrant> If you add Other/Proprietary to your licenses you'll get a 30 day sub, and then you can ask us to extend it
<wgrant> StevenK: I've put a few minor comments on the MP
<StevenK> So has Curtis
<wgrant> Oh
<wgrant> So he has
<StevenK> wgrant: Damn it, I thought I had renamed that Mixin :-(
 * StevenK laughs at your 'orly'
<mwhudson> wgrant: i guess i'll wait until things have settled down a bit, but thanks
<wgrant> mwhudson: Sounds reasonable.
<StevenK> wgrant: So I guess we could make use of getDefaultBugInformationType if the target is an IProduct and override to PRIVATESECURITY if security_related
<wgrant> StevenK: Except that BugSharingPolicy.PROPRIETARY doesn't permit PRIVATESECURITY
<wgrant> StevenK: This should perhaps use similar rules to the API's BugSet.createBug'
<wgrant> (which will likely reveal bugs in that method)
<StevenK> wgrant: So we already set information_type using convert_to_information_type() just before createBug
<StevenK> And in fact, it's always created on a product
<StevenK> wgrant: Perhaps we should do what you suggest -- assert self.product.bug_sharing_policy == BugSharingPolicy.PUBLIC
<wgrant> That's certainly safest for now, and probably not immensely limiting
<wgrant> Huh
<wgrant> Project:+branches shows BVPs publicly
<wgrant> Didn't realise that
<wgrant> (Project, not Product)
<StevenK> wgrant: So the only thing I haven't done is re-add the block that starts with 465 - # Security bugs must be created private, so set it correctly.
<StevenK> wgrant: Why should we run it all the time? We create the bug with information_type specified.
<wgrant> Do we?
<wgrant> Then why is that block there :/
<StevenK> Maybe all that's missing is if security_related: private = True and we're done
<StevenK> But people can import bugs as PUBLICSECURITY, it doesn't matter much
<StevenK> wgrant: Have another prod at that MP?
<wgrant> StevenK: Looking
<wgrant> StevenK: Mysterious
<StevenK> wgrant: What is?
<wgrant> I ran format-imports over the tree just two weeks ago
<wgrant> Perhaps there were comments in the way
<wgrant> Ah
<wgrant> Obsolete cElementTree crap
<wgrant> Can you remove that
<wgrant> ?
<StevenK> bugimport resists format-imports due to that bloody try
<StevenK> wgrant: Sure, I just didn't know which one is the obsolete one
<wgrant> THe one that doesn't work any more :)
<wgrant> cElementTree is long-deprecated IIRC
<wgrant> >>> import xml.etree.cElementTree
<wgrant> >>> import cElementTree
<wgrant> Traceback (most recent call last):
<StevenK> Yeah, already done
<StevenK> wgrant: The MP has updated.
<wgrant> StevenK: You still seem to have that XXX'd block in createBug
<wgrant> 395 - if (IProduct.providedBy(params.target) and params.target.private_bugs
<wgrant> 396 + if (IProduct.providedBy(params.target)
<wgrant> Oh, that's gone
<wgrant> Hm
<wgrant> Ahh, in an earlier rev while I was writing my first review
<wgrant> Sneaky
<StevenK> Yeah, because Curtis pointed it out
<wgrant> r=me
 * StevenK tosses it at ec2 test to see how much hate mail he gets
<StevenK> death-to-private_bugs => devel            [FAILED]   (up for 0:31:04) i-35592f48
<StevenK> Hahah, that didn't take long
<StevenK> from lp.bugs.scripts.bugimport import ET
 * StevenK facepalms
<wgrant> That's impressive
<wgrant> Or is that a test?
<StevenK> It's in a test
<wallyworld_> bollocks. my ec2 credentials have become invalid :-(
<StevenK> Oh?
<wallyworld_> ec2 land spits back a 401
<StevenK> Paste?
<wallyworld_> let me retry
<wallyworld_> boto.exception.EC2ResponseError: EC2ResponseError: 401 Unauthorized
<wallyworld_> <?xml version="1.0" encoding="UTF-8"?>
<wallyworld_> <Response><Errors><Error><Code>AuthFailure</Code><Message>AWS was not able to validate the provided access credentials</Message></Error></Errors><RequestID>3b25f70c-bc80-4470-b867-e24ad24f42da</RequestID></Response>
<StevenK> Wow
<StevenK> wallyworld_: Can you log into AWS at aws.amazon.com ?
<wallyworld_> trying now
<wallyworld_> yep, everything ok
<wallyworld_> maybe i'll have to reset my credentials
<wallyworld_> i recently updated lp-dev-utils and it started happening after that, probably a coincidence
<StevenK> wallyworld_: So while logged in, compare ~/.ec2/aws_* with what's on AWS.
<wallyworld_> StevenK: you mean the Key/Pair link on aws?
<StevenK> wallyworld_: I have .ec2/aws_id and .ec2/aws_user
<wallyworld_> yes, me too
<wallyworld_> the only security setting i can see on the aws site is the Key Pair link
<StevenK> wallyworld_: And no, these are your details
<StevenK> While logged into your AWS account, find the "Access Credentials" link (via "Account" -> "Security Credentials".
<StevenK> On the page, you'll see "Access Key Id:" and "Secret Access Key:". Make a ~/.ec2 directory in your dev box with a file called aws_id. In the first line, put your access key id. In the second line, put your secret access key id.
<wallyworld_> StevenK: they both match
<StevenK> wallyworld_: Then try it again?
<wallyworld_> without having to edit anything
<wallyworld_> i've tried several times
<wallyworld_> same error
<wallyworld_> maybe i just need to create new credentials
<wallyworld_> i've paid my bills i'm sure
<StevenK> Does your account have access to EC2?
<StevenK> I successfully started an ec2 test run using lp-dev-utils r128 this morning
<wallyworld_> it let me launch an instance from the web interface
<wallyworld_> which shows up in ElasticFox
<StevenK> wallyworld_: bzr revno of lp-dev-utils?
<wallyworld_> 113
<StevenK> wallyworld_: Maybe you should update that?
<wallyworld_> just did, i'm on the latest rev
<wallyworld_> i updated earlier too just to be sure
<StevenK> Then how am I on r128?
<wallyworld_> hmmm.
<wallyworld_> "Tree is up to date at revision 113 of branch bzr+ssh://bazaar.launchpad.net/+branch/lp-dev-utils  "
<wallyworld_> i'll try grabing it again
<StevenK> I just went backwards too
<StevenK> ec2 ls still works for me
<wallyworld_> sigh, it hates me
<StevenK> Hmmmm, before I updated I had a bunch of revs from lifeless
<StevenK> Which I suspect were his PPR changes
<wallyworld_> i just checked out again and got rev 113 as tip
<StevenK> Yeah, Robert's stuff was merged in as r111 by Curtis
<wallyworld_> StevenK: the traceback shows system packages implicated
<wallyworld_> perhaps i've hit a quantal bug
<wallyworld_>   File "/home/ian/projects/lp-dev-utils/ec2test/credentials.py", line 87, in connect
<wallyworld_>     aws_secret_access_key=self.secret)
<wallyworld_>   File "/usr/lib/python2.7/dist-packages/boto/ec2/__init__.py", line 55, in connect_to_region
<wallyworld_>     for region in regions(**kw_params):
<wallyworld_>   File "/usr/lib/python2.7/dist-packages/boto/ec2/__init__.py", line 39, in regions
<wallyworld_>     return c.get_all_regions()
<wallyworld_>   File "/usr/lib/python2.7/dist-packages/boto/ec2/connection.py", line 2421, in get_all_regions
<wallyworld_>     [('item', RegionInfo)], verb='POST')
<wallyworld_>   File "/usr/lib/python2.7/dist-packages/boto/connection.py", line 896, in get_list
<wallyworld_>     raise self.ResponseError(response.status, response.reason, body)
<wallyworld_> boto.exception.EC2ResponseError: EC2ResponseError: 401 Unauthorized
<wallyworld_> <?xml version="1.0" encoding="UTF-8"?>
<wallyworld_> <Response><Errors><Error><Code>AuthFailure</Code><Message>AWS was not able to validate the provided access credentials</Message></Error></Errors><RequestID>f8efcb7a-afb9-45b3-98b0-75d18ee945f7</RequestID></Response>
 * StevenK stabs wallyworld_ 
<wallyworld_> ouch
<StevenK> We have this thing, it's a called a pastebin. Maybe you've heard of it?
<wallyworld_> it was only a few lines
<wallyworld_> sorry
<StevenK> 13 lines is a few?
<wallyworld_> less than 14 :-)
<wallyworld_> fsvo i guess
 * StevenK stabs wallyworld_ again
<wallyworld_> ouch
<StevenK> wallyworld_: You may be right, though. My desktop is still precise
<wallyworld_> yeah, let me see if i can rollback those packages
<wallyworld_> StevenK: sadly, only the quantal version of python-boto is listed as being valid
<StevenK> wallyworld_: https://launchpad.net/ubuntu/+source/python-boto
<StevenK> Download the 2.2.0 version for precise
<wallyworld_> thanks, will try that
<StevenK> wgrant: I can't even force a team that owns a product to private using rSP? :-(
<wallyworld_> StevenK: bollocks. still no go. i must have neglected to sacrifice something to the gods
<StevenK> With the same traceback?
<wallyworld_> yeah, more or less
<wallyworld_> to the naked eye
<StevenK> Your eye should put some clothes on
<wallyworld_> perhaps
<wallyworld_> but i feel so comfortable without
 * StevenK installs orca and scratches his own eyes out
<StevenK> wallyworld_: So I think you should work out where ec2 is loading your credidentals from
<wallyworld_> yeah, i'll do some digging. thanks for the input
<wallyworld_> let me know how orca goes for you :-)
<StevenK> Haha
<wallyworld_> there are some launchpad issues with it could could help fix
<StevenK> wallyworld_: At my last job, my manager was vision impaired. I could never work out how he could hear his screen reader nattering in his ear at 90wpm while having a conversation on the phone
<wallyworld_> yeah. i guess it takes practice
<wallyworld_> i can't understand how anyone can use a computer with just a screen reader to reply on
<wallyworld_> rely
<StevenK> wallyworld_: You should talk to TheMuso some time.
<wallyworld_> would be an insight for sure
<StevenK> wallyworld_: He's the one who filed the accordian widget doesn't love screen readers bug
<wallyworld_> there are others too for bug subscriptions i think?
<StevenK> I think that's the only one directly related to screen readers
<StevenK> ICBW
<StevenK> wallyworld_: Have you heard of Keith Packard?
<wallyworld_> no
<StevenK> wallyworld_: Works on X, and has been since the early 80s
<wallyworld_> vision impaired?
<StevenK> No, just glasses. But I'm getting to that
 * wallyworld_ needs to learn patience
<StevenK> wallyworld_: He was giving a talk a few years on compositing to group of vision impaired people -- he found it a little confronting talking about GL transforms to a group of people who all had laptops, and half of them had no screens at all, since their user had no need for it at all.
<wallyworld_> i can imagine. we do take a lot for granted having decent eye sight
<StevenK> wgrant: So I can create a private team, but then that team can't own a product. Or I can create a public team and have it own a product, but then I can't force that team to be private.
<wgrant> StevenK: What are you trying to do and why?
<wgrant> Also, why can't you?
<StevenK> wgrant: https://bugs.launchpad.net/launchpad/+bug/1031751/comments/3
<wgrant> We have private teams that own projects
<_mup_> Bug #1031751: KeyError: 'primary_vars'  raised setting branch for a project <oops> <qa-ok> <Launchpad itself:In Progress by stevenk> < https://launchpad.net/bugs/1031751 >
<StevenK> In [13]: removeSecurityProxy(team).visibility = PersonVisibility.PRIVATE
<StevenK> ImmutableVisibilityError: This team cannot be converted to Private since it is referenced by a product and an accesspolicygrant.
<wgrant> I'm not sure that the project owner actually matters
<wgrant> Isn't it the team that you select on the form?
<StevenK> OH. I just need to be a member of it?
<wgrant> Any participant will do
 * wgrant is still forcing a terrible weightloss regime on 2000 lines of test_branchnamespace
<StevenK> wgrant the Drill Master?
<wallyworld_> StevenK: found it. something has set some EC2 environment variables, which overrode my credentials
<StevenK> Haha
<wallyworld_> i have no idea whta/when/why
<StevenK> BLEH
<StevenK> ComponentLookupError: ((<lazr.restful.fields.ReferenceChoice object at 0xc48f690>, <lp.services.webapp.servers.LaunchpadTestRequest instance URL=http://127.0.0.1>), <InterfaceClass zope.app.form.interfaces.IInputWidget>, u'')
<StevenK> :-(
<wgrant> StevenK: Are you in the right layer?
<StevenK> wgrant: I'm in 'make iharness', so what's a layer
<wgrant> Ah
<wgrant> That should be fine
<StevenK> Except it isn't
<wgrant> Now now
<wgrant> You know how I feel about "facts"
<StevenK> wgrant: Ah. You say it should be fine, so it is?
<StevenK> wgrant: http://pastebin.ubuntu.com/1266897/
<wgrant> StevenK: What have you changed?
<StevenK> wgrant: It's current devel with me creating two teams, a product, a series and then calling the view
<wgrant> Do you get the same exception in a test?
<StevenK> Last time I wrote this as a test, you told me it was pointless :-)
<StevenK> So I was trying to avoid that
<wgrant> Ah
<wgrant> You could try the Web UI.
<wallyworld_> ah. broken build. will do test fix
<StevenK> PrivatePersonLinkageError: Cannot link person (name=team-name-100005, visibility=PRIVATE) to <CodeImport for ~team-name-100005/product-name-100006/blazer-branch> (name=None)<br />
<StevenK> So the owner really can't be private
<wgrant> The owner of the codeimport isn't currently permitted to be, no
<wgrant> The owner of a branch is fine
<StevenK> The owner field is only enabled on ProductSeries:+setbranch if you say it's an import
<StevenK> So I guess it's validation time
<wgrant> Owner should be on +setbranch if it's an import
<wgrant> Isn't it?
<wgrant> Yes, and that's exactly what you just said
<wgrant> I can't read
<StevenK> Haha
<StevenK> So, time for a test
 * StevenK stabs doctests
<StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/no-private-registrant-setbranch-redux/+merge/128415
<StevenK> wgrant: How goes test_branchnamespace's radical diet?
<wgrant> Nearly there
<StevenK> Curtis is a tease. He commented on my MP, but didn't review it.
<wallyworld_> StevenK: sorry, was doing school pickup and buying coffee, i'll do your mp now
<wallyworld_> r=me
<StevenK> wallyworld_: Thanks
<wallyworld_> np. i fell better now i've had coffee
<wallyworld_> feel even
<StevenK> wallyworld_: You were going through withdrawl symptoms?
<StevenK> Did you phone up bigjools and beg him for a hit?
<wallyworld_> yes, and i had totally run out so it would have been unbearable tomorrow morning
<wallyworld_> no, not that desperate
<wallyworld_> yet
<bigjools> wallyworld_: that's condition double red
<wallyworld_> StevenK: bigjools and i are out of coffee sync sadly
<wallyworld_> he ran out last week while i still had some
<StevenK> wallyworld_: There's this thing, perhaps you've heard of it -- 'forward planning' ?
<bigjools> we need to sync our cycles
<wallyworld_> maybe we need to sniff each other's armpits
<bigjools> O_o
<wallyworld_> bigjools: i got that expensive stuff. hope it's good
<bigjools> wallyworld_: it's bloody great.  Did you not try any when there?
<wallyworld_> didn't have time. got a take away which was ok but not spectacular
<wgrant> wallyworld_: Hmm
<wallyworld_> ?
<wgrant> Ah, bug #1052639
<_mup_> Bug #1052639: Cannot change the information type of a branch when I unshare with the owner <disclosure> <fallout> <information-type> <qa-ok> <sharing> <Launchpad itself:Fix Released by wallyworld> < https://launchpad.net/bugs/1052639 >
<wgrant> Was looking for the rationale for the extra check in ProductNamespace.getAllowedInformationTypes
<wgrant> Since it means that if the user has proprietary privileges, they can change the owner to any of their teams
<wgrant> Which possibly means that we want to dump the team restriction entirely
<wgrant> Thoughs?
<wgrant> eg. I was able to make https://code.qastaging.launchpad.net/~auditor-team/lp-production-crontabs/grackle2
<wgrant> auditor-team has no privileges in lp-production-crontabs
<wallyworld_> not sure. i'll have to reread the code to get some context again
<wgrant> Until that fix, you could only change the branch owner to a team with privileges.
<wgrant> Which is a restriction we kept from the old BVP days, but we possibly just want to throw out now
<wallyworld_> so you can change the owner to anyone?
<wallyworld_> i guess if it's easy enough to correct mistakes and the principals fit with the goals for disclosure
<wallyworld_> then why not
<wallyworld_> maybe discuss tomorrow
<StevenK> wallyworld_: You didn't mark r16110 as a rollback of 16109
<wallyworld_> ah bollocks. sorry
<StevenK> 56 revisions waiting. WCPGW
<wallyworld_> oh ye of little faith
<StevenK> wgrant, wallyworld_: I've marked the bug attached to r16109 as qa-ok just based on the fact it was rolled back in the next rev.
<wgrant> I imagine UK webops will be tied up for a while
<wgrant> StevenK: Yep
<wallyworld_> thanks, sorry
 * StevenK peers at qastaging-update.log
<wgrant>  33 files changed, 105 insertions(+), 2741 deletions(-)
<wgrant> I think that's about it
<StevenK> Holy crap
<nigelb> StevenK: Does he beat your maximum deletions in one MP record? :)
<StevenK> Not sure
<nigelb> We need an app for that.
<nigelb> On that note.
<nigelb> I just realized, I have an incomplete MP.
<nigelb> Sigh. I wish I had time to finish it up.
<StevenK> steven@undermined:~/launchpad/lp-branches/devel% bzr di -c 12253 | diffstat -s
<StevenK>  19 files changed, 1789 insertions(+), 2767 deletions(-)
<StevenK> So, no.
<nigelb> Hah.
<StevenK> nigelb: [r=jelmer, henninge, gmb, allenap, edwin-grubbs, deryck][ui=none][bug=384220][no-qa] Take a bunch of Soyuz doctests, burn them in a large fire, and replace them with unit tests.
<nigelb> hahahahaha
 * StevenK waits for the qa-tagger
<StevenK> Finished my qa before it ran
<rick_h_> morning
<czajkowski> rick_h_: ello
<czajkowski> rick_h_: you not off today ?
<rick_h_> czajkowski: I've got to try to finish this branch for private projects alpha, had tests/buildbot fail over hte weekend :(
<rick_h_> but plan on running away once I get it working
* benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugs: ~300
<czajkowski> rick_h_: any idea when https://bugs.launchpad.net/launchpad/+bug/1062207  will get looked at ?
<_mup_> Bug #1062207: Unable to raise blueprint <lp-blueprints> <private-projects> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1062207 >
<wgrant> rick_h_: Ah, since you're here... I reverted the product launchpad.View stuff, as it broke production
<wgrant> Just in case it's relevant to what you're doing here on your day not-so-off
<rick_h_> czajkowski: tomorrow. abel knew what was up there.
<rick_h_> wgrant: lanuchpad.View stuff? /me tries to jumpstart the brain
<wgrant> rick_h_: You guys restricted most of IProduct's attributes behind the launchpad.View permission last week
<czajkowski> grand
<rick_h_> wgrant: ah ok
<wgrant> If you current branch relies on private projects being private, it won't work :)
<wgrant> But otherwise you should be unaffected
<rick_h_> hah, well we were supposed to be getting to alpha with it so I wonder if this blows that up
<rick_h_> I'm hitting a different conflict I think
<rick_h_> somewhere _information_tpe got turned into a db column information_type and I lost my getting/setter @property
<rick_h_> but that's in the product model
<wgrant> There's still another month at least of work before you can think about having a single private project
<wgrant> On prod
<wgrant> I'm not sure what alpha entails, though
<rick_h_> right, but deryck is supposed to be here today for a bit to flip the bits on enabling the alpha which lets users register a non-public project and we can check things out.
<wgrant> rick_h_: I probably reverted that infotmation_type bit
<wgrant> rick_h_: Um, no
<wgrant> Nobody is going to be registering any non-public projects for some weeks :)
<wgrant> Even if I hadn't reverted the code today
<wgrant> No code knows how to handle them
<wgrant> And it will make pages all across Launchpad 403
<rick_h_> heh
<wgrant> 10 bugs that Curtis filed over the weekend will immediately become critical regressions
<wgrant> And I'll be able to file another 20 or so
<rick_h_> well, what I get for going on vacation and coming back just in time to pick up the alpha going boom :)
<rick_h_> ok, well I'll still try to figure out how to fix this change up on my branches so they can land up and go from there. thanks for the heads up
<wgrant> Right, sounds like a good plan
<rick_h_> I'll make sure to catch deryck when he comes online and get it sorted out
<wgrant> Turning on private projects on production today... not such a good plan!
<rick_h_> oh boooo :P
<wgrant> Think of the blueprint 403 regressions, except on basically every page on Launchpae
<wgrant> d
<wgrant> That's what private projects on production today will do
<rick_h_> ok, I knew we had an issue with the project listing page and abentley was working on updating the query, but I'm not up on the rest there
<wgrant> Entering an un-QAed restricted alpha is OK for normal things, but not for denying access to artifacts that leak to just about every single page of the application
<wgrant> It just takes one person to be even slightly adventurous and dozens of people can no longer do their work
<wgrant> Because pages they need are 403ing
<rick_h_> gotcha
<rick_h_> speaking of hte alpha bossman
<deryck> yeah, what's this bad news?
<rick_h_> deryck: so wgrant was telling me he had to do some reverting for us with launchpad.View because it broke production
<rick_h_> and my branches didn't land over the weekend due to a test fail and buildbot breakage.
<wgrant> Right, various pages were 403ing after deploying r16090 (IProduct launchpad.View stuff), mostly due to deactivated projects showing up and no longer being accessible
<rick_h_> but wgrant says that enabling the alpha right now would break a ton of stuff. He says curtis filed a bunch of bugs over the weekend
<rick_h_> I'm still catching up on weekend stuff atm, but wanted to make sure you were caught up deryck
<wgrant> I reverted it so we could deploy the other 50 waiting revisions to production
<StevenK> More than 50
<wgrant> What are the alpha plans?
<deryck> wgrant, thanks, that makes sense defintely.
<deryck> I need to look at sinzui's bugs to see what his concerns are.
<wgrant> deryck: What's the next alpha step?
<deryck> wgrant, I'm sorry, I don't follow what you're asking.  What do we need to do to get to alpha?  Or what will the alpha provide?
<wgrant> Well, what's the general timeline for turning this stuff on?
<deryck> wgrant, I had hope to get a deploy around late morning, early afternoon.  I have a few test fixes to go for my last branch.
<rick_h_> wgrant: doh yea so the revert changed back the model that my branch was based off of
<wgrant> deryck: So people creating private projects this week?
<deryck> wgrant, but if the security adapter stuff is reverted, there's no point.
<deryck> wgrant, yes, but only a small group.  I will create an alpha team, and only add those who request it.
<wgrant> rick_h_: That bit can possibly be cheaply relanded. I just reverted the whole revision rather than weeding out the problematic bits (of which there are a lot)
<wgrant> deryck: I'm not sure that's such a good idea.
<wgrant> deryck: LP doesn't know how to filter private projects yet
<rick_h_> wgrant: yea, it's abel's beast hitting a lot of stuff so I think at this point I'll wait until tomorrow and work with abel to catch up.
<wgrant> So if one of those projects shows up anywhere, that page will 403
<wgrant> Similar to the blueprint issues, except 100x worse
<wgrant> And on just about every page of the application
<deryck> we know this.  we've discussed it at length, with both flacoste and sinzui.
<wgrant> They need to be fixed before we can think about having even a single private project on production.
<wgrant> Ubuntu's a couple of days away from final freeze
<deryck> yeah, that's a fair point, though.
<wgrant> We cannot be breaking things now
<wgrant> It's fine if the alpha projects break the alpha projects
<wgrant> But at this stage they will break just about *everything*.
<wgrant> So even a closed alpha on production is extraordinarily risky
<deryck> This is basically what happened with Abel's change that you reverted, except only for deactivated and not private projects?
<wgrant> Right
<wgrant> We already filter out deactivated projects in most places, but it *still* broke
<wgrant> We don't even try to filter out private projects anywhere yet
<wgrant> So it will be far worse
<deryck> right
<deryck> well, the alpha was more a symbolic release/early feedback kind of thing.  to keep us on track.
<deryck> we could just skip it and march on to beta.
<czajkowski> wgrant: was this why madel couldnt see his LP page earlier on but could see his code page ?
<wgrant> Sure, it's really good to have a nice visible milestone like that.
<wgrant> And it's fine to be releasing unstable stuff onto production if the scope of the breakage is limited
<wgrant> But this is unlimited. Projects affect just about everything.
<czajkowski> *mandel
<wgrant> czajkowski: Right
<wgrant> Person:+index is an example of a page that was broken in many cases by this
<czajkowski> ah ok, but this won't affect people now as it's been reverted right.
<wgrant> czajkowski: Right
<czajkowski> cheers
<wgrant> So yeah, the private project changes are looking good so far. But it's a really risky thing to be deploying, and we need to not take unnecessary risks particularly this close to an Ubuntu release
<deryck> wgrant, I agree with you.  I don't want to make the call entirely to kill the alpha without chatting with flacoste.  But I don't see the point, given all that.
<deryck> rick_h_, see my thoughts here ^^
<rick_h_> deryck: rgr, so my branch friday failed to land and I was going to get it fixed up this morning, but with the revert it seems there's a lot more work to do to get it to land
<deryck> rick_h_, yes, there is.  Take the holiday and don't worry about it.
<rick_h_> deryck: so let me know what you think and I can work on it, but right now thinking of turning tail and regrouping with everyone tomorrow
<rick_h_> deryck: ok
<deryck> rick_h_, yeah, the others are not available today.  Might as well regroup tomorrow.
<deryck> rick_h_, are you still around?
<wgrant> deryck: Great
<deryck> wgrant, thanks for reverting that work.  sorry you guys were left to deal with it.
<wgrant> A lot of this stuff can be relatively easily discovered with a bit of nosing around qastaging, so I'm not sure we lose much non-psychological value from dropping/delaying the alpha
<wgrant> np, was easy to fix
<deryck> yeah, agreed on the points one line back.
<wgrant> Although from working on disclosure I know how awful it can be for everyone to see no visible progress for weeks/months, so I understand the inclination to release early :)
<deryck> Yeah. :)
<deryck> And we need to release regularly to hit the timeline, since it's aggressive.  But in this case, I don't think there's harm.
<rick_h_> deryck: I am what's up?
<deryck> rick_h_, why did you say the model was missing parts you needed?  The revert changed the way we get information_type but that should be there still.  What is missing?
<rick_h_> deryck: so abel added the getter/setters on the information type
<rick_h_> and I was using the setter
<wgrant> That should be fine
<wgrant> The setter just passed it through
<rick_h_> I tried a quick change back to _information_type with the @property getter/setter but tests blew up all over
<wgrant> Perhaps the security configuration is broken
<wgrant> What's the error when you try to set it?
<rick_h_> I was just starting to look into what was up when wgrant ping'd and all this started up
<deryck> you would just set information_type directly now.
<deryck> but as I say, you don't have to fix it now.  we can regroup tomorrow.
<rick_h_> sorry, closed up my lxc with the info. sec.
<deryck> was just wondering what you were seeing.
<rick_h_> yea, just some error from the db about _information_type not existing
<rick_h_> so I assume there's something else to make the storm/query side happy witht he rename
<wgrant> Oh, if you're using it in a query then it'll matter, yeah
<rick_h_> since I had changed the ENUM column to a leading understore for the getter/setter/property to wrap
<wgrant> For now you can just s/_information_type/information_type/
<wgrant> Or that, yeah
<rick_h_> wgrant: right, so shouldn't be anything huge I guess but I need to poke at what else is in that revision and such with the renames and all that
<wgrant> There were three minor conflicts, mostly in tests IIRC
<wgrant> But most stuff was pretty isolated.
<rick_h_> cool
<deryck> wgrant, so did the lp.view changes actually get released to lpnet?  or you just reverted them from the stack of pending revisions to deploy?  I didn't think we deployed at all last week.
<wgrant> deryck: It was deployed to lpnet a few hours ago
<wgrant> The appservers are presently reverted to the previous ndt (from Monday last week)
<wgrant> I immediately reverted the revision from devel, and there's an ndt scheduled for that
<deryck> wgrant, ah, I follow now, thanks.
<wgrant> Mostly so we can get the rest of the stuff out and check that none of us have broken anything else, before we add more revisions to the pile
<deryck> flacoste was lurking and knows all. :)
* wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ~280
<lifeless> flacoste: hi, I'm around whenever you want to have our call
<flacoste> lifeless: i'm available now
<lifeless> cool
<StevenK> wallyworld_: I guess the bugs.dynamic_bug_listings.enabled feature flag can be removed from prod?
<StevenK> rick_h_: At some point, you and I should remove js.combo_loader.enabled from the code
<wallyworld_> StevenK: yes
<StevenK> lifeless: O hai
<wallyworld_> now that my branch has deployed
<StevenK> lifeless: I'd like to remove bugs.dynamic_bug_listings.enabled and code.simplified_branches_menu.enabled from prod. The code no longer requires that they be set. Can haz approval?
<rick_h_> StevenK: definitely, and jsbuild, and such
<StevenK> Death to jsbuild would make me very happy
<lifeless> sure
<StevenK> lifeless: Thanks
<rick_h_> StevenK: it's more jsbuild/combobuild I think but some clean up required
<StevenK> rick_h_: Given the errors with yui-3.5.1 on build, certainly
<StevenK> wallyworld_: You've undone your python-boto fun from yesterday?
<wallyworld_> yep
<wallyworld_> 'fun'
<StevenK> FSVO, indeed
<StevenK> wallyworld_: Are we (being wgrant and myself) now one hour ahead of you?
<wallyworld_> yes :-(
<rick_h_> StevenK: errors?
<StevenK> rick_h_: If you make and then make again, you see a bunch
<wgrant> Intriguing
<wgrant> My ec2 instance from 2am is still going
<wgrant> 9 hours later
<wgrant> Not hung, just very very slow
<wgrant> StevenK: So you removed all makeLegacyProduct calls in lib/lp/bugs?
<StevenK> wgrant: r16114 in my death-to-private_bugs branch
<wgrant> Great.
<wgrant> And you've rerun those tests to be sure they work?
<StevenK> Total: 39 tests, 0 failures, 0 errors in 50.183 seconds.
<wgrant> StevenK, wallyworld_: Do either of you feel like reviewing a 3800-line BVP elimination diff, or shall I self-review it?
<wgrant> StevenK: Great
<wallyworld_> i reckon self review. let the tests decide
<wgrant> Well, I also deleted a lot of tests. But I think I was pretty sensible, so I agree
<StevenK> wgrant: I'd like to glance at it, but I don't want to review it
<wgrant> You can't really "glance" at a 286KB diff
<StevenK> skim, then
<StevenK> demolish-bvp has no MP :-(
<wgrant> I was going to save Launchpad the effort if nobody dared review it
 * wgrant proposes
#launchpad-dev 2012-10-09
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/demolish-bvp/+merge/128610
<StevenK> wgrant: lib/lp/code/browser/tests/test_branch.py the lp.code.enums import should be shrunk
<wgrant> Ah, and there were two ordering issues that appear to not have been my fault
<wgrant> But those were the only format-imports complaints
<wgrant> And they are now fixed
<StevenK> wgrant: I don't think you need the _is_private_team helper
<StevenK> People are implicity public, so if self.private: should be fine
<wgrant> We usually check both
<StevenK> wgrant: Looks great.
<wgrant> Thanks
<wgrant> Oh good
<wgrant> My new terrible version of retry-depwait is 30% faster than the old one
<wgrant> Despite my version considering several times more builds than it needs
<StevenK> How is still terrible?
<wgrant> It does just about no filtering in the core looptuner query
<wgrant> So it doesn't exclude obsolete series etc. until inside the main loop
<StevenK> Hah
<StevenK> That should be easy to be fix
<StevenK> But this is Soyuz
<bigjools> that old code is older than wgrant
<StevenK> Just about
<StevenK> wallyworld__, wgrant: https://code.launchpad.net/~stevenk/launchpad/sanity-check-bugwatch-bug-id/+merge/128625
<wallyworld__> StevenK: can has comment inthe test as to what consistutes a valid/invalid bug number?
<wallyworld__> maybe it's clear, but not from just looking at the diff
<wallyworld__> s/bug number/bug url perhaps
<StevenK> wallyworld__: http://pastebin.ubuntu.com/1268760/
<wallyworld__> cool. thanks
<wallyworld__> r=me
<StevenK> wallyworld__: Thanks
<wallyworld__> np
<StevenK> wallyworld__: I was expecting a query about the usage of re.sub, TBH :-)
<wallyworld__> why? seems ok to me
<StevenK> wallyworld__: "Why are you doing it that way, that's terrible" etc :-)
<wallyworld__> well, it's concise and it works, so meh
<wallyworld__> and there's a comment in the test
<adeuring> good morning
<wgrant> Test results: demolish-bvp => devel: SUCCESS
<wgrant> yay
<StevenK> After how many hours?
<wgrant> This was the third run today
<wgrant> Added sampledata... broke tests that depended on IDs of new stuff
<StevenK> Hah
<StevenK> I just merged devel into mine, that was horrible
<dpm> hi all, who can edit the VCS source for vcs-imports? I was looking at why translations weren't being imported from upstream's e-d-s and it seems it's because the VCS import is still set to SVN instead of git - could someone help me with editing the upstream source branch on https://code.launchpad.net/~vcs-imports/evolution-data-server/trunk ?
<maxb> dpm: Members of ~vcs-imports - what would you like changed?
<wgrant> dpm: You'll need to create a new import if the VCS has changed
<maxb> Indeed - shall I rename the old one out of the way?
<dpm> maxb, if you could do that, that'd be great, thanks!
<maxb> Renamed to old-svn-trunk and set to 'Merged' status so that it doesn't show up in the default branch listings
<maxb> Go ahead and create a new import
<dpm> maxb, hm, how do I actually create a new import (I'm not a member of ~vcs-imports)?
<cjwatson> dpm: https://help.launchpad.net/VcsImports
<dpm> thanks cjwatson
<maxb> https://code.launchpad.net/evolution-data-server , "Import a branch"
<maxb> dpm: Under the new system of vcs import creation, the branch owner will be you or a team you are a member of if you select it - if you want the new import back at lp:~vcs-imports/evolution-data-server/trunk for consistency, let me know when you've created it and I'll move it over.
<dpm> maxb, https://code.launchpad.net/~dpm/evolution-data-server/trunk - if you could move it over to ~vcs-imports, that'd be great
<maxb> done
<dpm> thanks maxb
<cjwatson> Is there any pattern in Launchpad for a Job type that allows newly-created jobs to preempt existing ones in the middle of a long run of many jobs?
<cjwatson> The usual iterReady implementations seem to compute the whole list of ready jobs up-front, which won't allow preemption.
<cjwatson> I could turn the relevant iterReady implementation into a generator and have it suck jobs out of the DB in batches or something, but it seems a bit ad-hoc and I was wondering if there was anything pre-existing for this
<wgrant> cjwatson: I know of nothing like that already
<cjwatson> wgrant: OK, thanks :-/
<cjwatson> Would it be ridiculously OTT to glue in a looptuner?
<wgrant> I don't think a looptuner's too useful or feasible there
<cjwatson> Why infeasible?
<cjwatson> Doesn't really know the operation times, I suppose
<wgrant> Right, and particularly with rabbitmq, it's reasonably important that if a job gets aborted then only that job gets aborted
<wgrant> What benefit would a looptuner provide?
<cjwatson> Not having to pick a hardcoded chunk size
<wgrant> The operations will frequently fail. I'm not sure they can be sensibly batched like that.
<cjwatson> They're already batched ...
<cjwatson> process-job-source (eventually) calls iterReady, gets a list of however many ready jobs there are back
<cjwatson> All at once
<cjwatson> So, OK, not so much batched as one giant batch
<cjwatson> But failure is handled at the level of individual jobs anyway
<cjwatson> It doesn't propagate out to the level of whatever calls iterReady
<wgrant> Right, it doesn'
<wgrant> t chunk AFAIK
<wgrant> So no point to a looptuner
<wgrant> We usually use a looptuner to get small transaction lengths without committing 1000x more often than necessary
<cjwatson> It doesn't chunk at the moment, but in order to allow preemption in the middle of a few thousand jobs that arrived all at once, it needs to
<cjwatson> Or at least I don't see how to do that otherwise
<wgrant> Is there likely to be a significant performance issue if you were to simply query for the head of the queue each time a job was needed?
<wgrant> I'm not sure how terrible these queries tend to be
* frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban | Firefighting: - | Critical bugs: ~280
<cjwatson> wgrant: Not too sure how I would tell.  All I can divine from logs is that it's usually sub-second
<tumbleweed> frankban: care for an easy one? https://code.launchpad.net/~stefanor/launchpad/retry-cancelled-build/+merge/128683
<frankban> tumbleweed: sure
* rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban, rick_h | Firefighting: - | Critical bugs: ~280
<tumbleweed> frankban: thanks. Would you mind landing it for me?
<frankban> tumbleweed: yes, in a minute
<frankban> tumbleweed: done
<tumbleweed> frankban: thanks again
* frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: rick_h | Firefighting: - | Critical bugs: ~280
<sinzui> jcsackett, what bug are you looking at now?
<jcsackett> sinzui: i'm exploring bug 994561 and bug 1007124 as they seem related. was reading through the code and going to ping you for thoughts in a few.
<_mup_> Bug #994561: IndexError: string index out of range <dkim> <email> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/994561 >
<_mup_> Bug #1007124: Incorrect padding <dkim> <email> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1007124 >
<jcsackett> happy to chat now though if you're free.
<sinzui> okay
<tumbleweed> to QA bug 1016337, I'd need a working PPA builder on a staging environment. Should I just not bother to QA it?
<abentley> rick_h_: Could you please review https://code.launchpad.net/~abentley/launchpad/private-product-listings/+merge/128800 ?
<rick_h_> abentley: sure thing
<rick_h_> abentley: are the conflicts listed anything to worry about?
<abentley> rick_h_: I don't think so.
<abentley> rick_h_: Okay, yeah, there's a problem-- I've modified code that's been deleted, and DB columns I've used have been renamed.
<rick_h_> abentley: so _information_type is getting renamed back in my branch I sent to ec2 land this morning
<abentley> rick_h_: Okay, this is because of the rollback.
<rick_h_> abentley: right
<rick_h_> but yea, should we hold on this until abel finishes his update then?
<abentley> rick_h_: Yeah.  I'd normally mark his branch as a prerequisite, but it's not clear what his work-in-progress branch is.
<rick_h_> abentley: ok, we'll catch up in the morning and I can look it over then.
* rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ~280
 * StevenK stabs OOPS pruning.
<StevenK> Clearly, I need to take a copy of the OOPS file to have any hope of reading them after linking them to a bug.
<lifeless> StevenK: recent or old ?
<StevenK> lifeless: https://bugs.launchpad.net/launchpad/+bug/956339 comment 1
<_mup_> Bug #956339:   IntegrityError: new row for relation "codeimport" violates check constraint "valid_vcs_details"  <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/956339 >
<lifeless> StevenK: so old
<StevenK> lifeless: Given neem has OOPSes back to 2012-06-12, I don't buy it.
<lifeless> StevenK: we had that bug which wgrant fixed recently
<lifeless> StevenK: where we were only keeping references made w/in the first 24 hours
<StevenK> Mmmm, I've been trying to recall how long the fix has been on neem.
<wgrant> I think there may be another pruning bug
<wgrant> But it's not quite so bad, I don't think
<wgrant> And I don't know what it is yet
<wgrant> StevenK: When you run into a case from the last month or so, let me know and I will fix it.
<StevenK> wgrant: Does the 24th of November count? :-)
<StevenK> Er, September
<wgrant> Yes
<StevenK> wgrant: bug 956339 comment 1
<_mup_> Bug #956339:   IntegrityError: new row for relation "codeimport" violates check constraint "valid_vcs_details"  <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/956339 >
<wgrant> Thanks.
<lifeless> did we have it deployed then? I thought it was a couple days later ;)
<wgrant> Oh
<wgrant> It was Sep 24 itself
<wgrant> Interesting timing :)
<StevenK> Yeah, great. It's pruned the one OOPS again.
<wgrant> Well, should be pretty easy to work out
<wgrant> Find things that create codeimports
<wgrant> Look at DB constraint
<wgrant> See how those codepaths could violate the DB constraint
<StevenK> I did, on the day I linked that OOPS.
<StevenK> It looked pretty sane to me.
<wgrant> StevenK: It may be useful to note that the most recent OOPS was not in fact from +new-import, but from +setbranch
<wallyworld_> sinzui: StevenK: wgrant: jcsackett: mumble keeps hanging for me again, will keep trying
<StevenK> No OOPS mentioning ArchiveSubscriptionError either :-(
<StevenK> wgrant: So I think what is probably happening is the valid_absolute_url call in the CHECK CONSTRAINT is failing, but I have no proof
#launchpad-dev 2012-10-10
<wgrant> StevenK: Right, that's the most likely cause4
<StevenK> And I've been trying to figure out how to defeat it without success
 * wallyworld_ has a few errands to do, bbiab
<wgrant> StevenK: It may be some subtle difference between lazr.uri and urlparse, but it's not exactly obvious. Have you tried grepping for other occurrences?
<StevenK> wgrant: On neem? find . | xargs grep -H "valid_vcs_details" gives no results
<wgrant> StevenK: :(
<wgrant> And I don't think our postgres logs go back far enough
<wgrant> Although they might
<StevenK> I can recall the original OOPS mentioning https://lomse.svn.sourceforge.net/svnroot/lomse/trunk. (yes, with the extra .), but qas doesn't succumb to handing over an OOPS.
<wgrant> OH
<wgrant> That's easy, then
<wgrant> Yeah, there we are
<wgrant>  (Error ID: OOPS-45b1bf391bcdcaec312388d7a2907957)
<wgrant> Now, can you work out how I did that? :P
<StevenK> wgrant: No, actually.
<wgrant> It's not actually visible in the page
<StevenK> Because I did the same thing and it didn't OOPS
<wgrant> But it's in the source
<StevenK> wgrant: The generated HTML or ProductSeries:+setbranch ?
<wgrant> StevenK: The HTML of the OOPS page
<StevenK> OH
<StevenK> It's a SPACE
<wgrant> A leading space, yes.
<StevenK> Hmm, does that make it a lazr.uri bug?
<wgrant> No
<StevenK> I thought zope would have stripped fields
<wgrant> URIField strips it before giving to lazr.uri
<wgrant> lib/lp/services/fields/__init__.py
<StevenK> I see that
<wgrant> _validate() calls lazr.uri.URI on a normalized version
<wgrant> But all it returns is the superclass' validated version of the input
<wgrant> And it's just a TextLine, not a StrippedTextLine
<StevenK> Hah
<StevenK> It should return uri, not value
<wgrant> No
<wgrant> We probably don't want to store the normalised value.
<StevenK> wgrant: Then I'm confused
<wgrant> I would suggest that it be turned into a StrippedTextLine, normalize be taught to stop stripping, and _validate to do the super() call first, before passing the validated value into lazr.uri
<StevenK> wgrant: http://pastebin.ubuntu.com/1270322/
<wgrant> StevenK: Something like that, yeah
<StevenK> wgrant: Did you see the copyright fix? :-)
<StevenK> wgrant: And how can I test that fix?
<wgrant> StevenK: There should be existing tests for URIField
<wgrant> I'd look at them for inspiration
<StevenK> wgrant: There's already a test that checks that URIField.normalise() returns a stripped version
<wgrant> Maybe it actually does intend to return the normalised version
<wgrant> But fails
<StevenK> wgrant: But it does, the _validate() actually uses it
<wgrant> StevenK: Sure, it uses it for validation.
<wgrant> StevenK: But then it returns the superclass' validated version of the *original* value, not the normalise one.
<StevenK> wgrant: Hah, uri-field.txt fails when calling normalize on '  http://www.ubuntu.com/   '
<StevenK> Aw, my fix worketh not.
<wgrant> :(
<StevenK> wgrant: You said you don't think we want to store the normalized value? We do already?
<StevenK> Or is .set() not used for storing?
<wgrant> set()'s probably used for setting the value in the *field*, usually from the one in the model.
<StevenK> Given my changes have had no effect, and there is already a test for URIField stripping input, I'm inclined to think the bug is at another level
<wgrant> Perhaps the field infrastructure is slightly different from the rest of the form stuff
<wgrant> I'd trace through and see where it might be going wrong
<wgrant> Since we can reproduce it now.
<mwhudson> ah
<mwhudson> so guys you should learn something bad about code imports
<mwhudson> i am sure there is a bug for this
<mwhudson> but code import editing does not use the usual methods of updating the object
<mwhudson> i.e. LaunchpadFormView.updateFromData or whatever it's called
<mwhudson> so the field validators/cleaners do not get run
<wgrant> Yeah, luckily we're not quite near that piece of evil atm
<mwhudson> ok
<wgrant> This is ProductSeries:+setbranch, which uses normalish form stuff and only calls newCodeImport
<wgrant> But thanks for the warning
<wgrant> jelmer: Is https://code.launchpad.net/~jelmer/launchpad/retry-update-node-tags meant to be against MAAS?
<StevenK> wgrant: So does URIField even factor into it?
<StevenK> How does.
<StevenK> wgrant: ProductSeries:+setbranch just calls url = data.get('repo_url') and then tosses it straight into getUtility(ICodeImportSet).new()
<wgrant> StevenK: But data.get('repo_url') should be the post-validation value, shouldn't it?
<wgrant> request.form will be pre-validation, but data should be post-validation
<wgrant> AIUI
<StevenK> wgrant: Ah. So tracing in update_action is after the horse has bolted
<wgrant> StevenK: Yes
<wgrant> StevenK: The form infrastructure will usually validate request.form to produce data, then call the action based on that
<wgrant> I believe
<wgrant> But don't quote me on that, unless I'm right
 * StevenK shifts the pdb call to URIField._validate
<StevenK> So it validates correctly,
<StevenK> And the superclass validate is just checking if the string not empty
<StevenK> So then zope.app.form.browser.widget calls getInputValue and gets the non-stripped value
<StevenK> So maybe it's a bug in URIWidget
<wgrant> So perhaps field validation and setting stuff are separate, unlike forms.
<StevenK> OH
<StevenK> Dear URIWidget, 2004 called, and wants you to start using super.
<wgrant> Hah
<StevenK> Hah, I think I can see another bug
<StevenK> Yeah
<StevenK> If you pass it a list, it will raise UnexpectedFormData.
<StevenK> If you pass it a tuple, it won't.
<wgrant> wallyworld_: Hmmm
<wgrant> wallyworld_: Why do you not just call getPrecachedPersonsFromIds?
<wallyworld_> i do
<wgrant> wallyworld_: You don't usually need to do messy caching stuff like that if you're using the PK
<wallyworld_> you do if the view sets up a decorstor
<wgrant> Since calling bugactivity.person will look up the PK in the Storm cache
<wallyworld_> i found i had to add that or else it didn't work but i can retry
<wgrant> Make sure you're actually evaluating the resultset you get from getPrecachedPersonsFromIds
<wallyworld_> ok, i'll try again and see what happens
<wgrant> Yeah, I suspect you just forgot the unobvious fact that you have to eg. call list() on it, or it doesn't do anything
<wgrant> Since I just tried that without the other changes, and the query count test still passes.
<wallyworld_> i knew i had to evaluate the resultset and thought i had. clearly not :-(
<wgrant> It's really easy to miss, sadly.
 * wallyworld_ makes an optometrist appointment
<wgrant> Heh
<wallyworld_> changes pushed, thanks for noticing that
<wgrant> Great
<wallyworld_> wgrant: the "ALL" in the doc string is the sharing permission "ALL", not all pillars
<wgrant> I know
<wgrant> But if you skim the docstring, its emphasised that all the pillars are checked
<wallyworld_> so you still think it's confusing?
<wgrant> Indeed. Not sure if it's important, but it's certainly confusing.
<wallyworld_> hmm, ok. can't say i agree but will reword
<StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/urifield-with-leading-space/+merge/128855
<wgrant> StevenK: Do you get to remove the manual stripping?
<lifeless> yay -
<lifeless>     91.85s  OOPS-0ad9cf4a4b00e8030eb9033a83b705cf  Person:branches.atom
<wgrant> :)
<StevenK> wgrant: Oh, from URIField?
<StevenK> Hmm, maybe
<StevenK> wgrant: Yeah, if I kill the normalize() strips test, the URIWidget test still passes
<wgrant> Yay
<StevenK> wgrant: http://pastebin.ubuntu.com/1270464/
<wgrant> StevenK: Right, something like that
<StevenK> ... Why is RootObject:+openid-callback doing 875 SQL statements?
<wgrant> Probably name collisions
<wgrant> Do you have an OOPS ID?
<StevenK> OOPS-3bd6bd0eddf3594799308c1c32b6b4e6
<StevenK> From the error report
<wgrant> Yes, but that's all the way over there
<wgrant> Yeah, name collisions
<StevenK> We have the branch scanner and celery competing again? OOPS-0d92c20fe1d6766c6637b1ee558aca28
<wgrant> Right, that's an ongoing issue
<wgrant> there's a bug for it
<wgrant> Assuming that's the illegal job state transition thing
<wgrant> scan_branches.py sometimes picks up a job before celery can get to it
<wgrant> Then celery tries to start it, which dies
<StevenK> Why are we running both? :-(
<wgrant> NFI
<wgrant> celery was turned on by nobody at nobody's request, from what I can tell
<wgrant> As nobody was aware it was running except me
<wgrant> And I was only aware because I saw it in logs
<StevenK> wgrant: MP updated
<StevenK> wgrant: Yeah, there's two. One is caused by that and there is another that implicates the PCJ machinery
<wgrant> wallyworld beat me to it
<wallyworld_> wgrant: are you ok to +1 my mps?
<wgrant> wallyworld_: r=me, thanks for the fixes
<wallyworld_> np. thnk for finding them
<wallyworld_> StevenK: bzr lp-land doesn't grab any dependent branches like ec2 land does it?
<wallyworld_> if not i think bb will break
<StevenK> ec2 land doesn't either?
<wallyworld_> it does
<wgrant> wallyworld_: Your dependent branch was merged into the one you landed
<wallyworld_> ah right, good
<wgrant> ec2 land and bzr lp-land ignore prereqs
<wallyworld_> so what happens if you ec2 land a branch with a pre req?
<wallyworld_> i could have sworn it worked, even if not merged in?
<wallyworld_> maybe not
<wgrant> It doesn't know it exists
<wgrant> So if it's not merged then it doesn't exist
<adeuring> good morning
<StevenK> wgrant: Is bug 1062291 another dupe of bug 839141?
<_mup_> Bug #1062291: timeout on Bugtask:+Index in subscription lookups <bugs> <subscriptions> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1062291 >
<_mup_> Bug #839141: Bug page times out getting subscriptions for logged in users on bugs with many duplicates <critical-analysis> <timeout> <Launchpad itself:Triaged by stevenk> < https://launchpad.net/bugs/839141 >
<StevenK> Hmmm, maybe not
<wgrant> StevenK: The fix for one may fix the other
<wgrant> And they are caused by the same thing
<wgrant> But they're different bugs
<StevenK> Yeah, I came to that conclusion too
<StevenK> Maybe we need to denorm subscriber ids into BTF
<StevenK> That idea might make you murder me
<wgrant> No real need for that
<wgrant> Even assuming 1000 dupes, the lookups shouldn't be that bad
<wgrant> If you do it all in one query
<StevenK> Right
<wgrant> allenap, jelmer, adeuring: You guys each have a fairly old branch on <https://code.launchpad.net/launchpad/+activereviews>. Could you dispose of them one way or another?
<wgrant> Just trying to get the queue cleaned up
<jelmer> wgrant: marked mine as rejected
<wgrant> jelmer: Thanks
<cjwatson> Mine probably wants a feature flag added, which I haven't had time to do
<wgrant> I left yours out because its situation was clear, yeah
<allenap> wgrant: Done.
<wgrant> allenap: Thanks
<rick_h_> adeuring: ping, do you know much about the garbo job ProductInformationTypeDefault ?
<adeuring> rick_h_: no that much. but what is the problem?
<rick_h_> so my branch failed to pass tests because it's doing queries against information_type and I changed it to _information_type
<rick_h_> so if I update the field the tests/query pass
<rick_h_> but I'm nervous that this thing is ok to do and we don't need to update it in some way to make sure that the ensurePolicies bit gets taken care of
<rick_h_> if this thing is going on in the background changing the informatino type, then again I guess it's just setting None to PUBLIC
<rick_h_> so shold be safe
<adeuring> rick_h_: i had to add the leading '_' for other reasons. I am aware that of this prblem; once the gabro job is finished, we can omit the '_' again.
<rick_h_> adeuring: ok, I think I should be fine with the change for now. Thanks
<rick_h_> just got nervous there for a second
<czajkowski> rick_h_: have ye broken bp search ?
<czajkowski> rick_h_: https://bugs.launchpad.net/launchpad/+bug/1064996
<_mup_> Bug #1064996: Blueprints search is totally broken <Launchpad itself:New> < https://launchpad.net/bugs/1064996 >
<wgrant> rick_h, adeuring: the garbo job shold have finished yesterday. i suspect if you ask ops to check the database, all the information types will be set.
<rick_h_> czajkowski: but but but...
<rick_h_> wgrant: ah, ok good to know thanks.
<wgrant> the job can probably be deleted.
 * czajkowski peers at rick_h_ 
<rick_h_> wgrant: cool, I just merged but will add a card to follow up on it thanks
<wgrant> great
<rick_h_> czajkowski: so *I* didn't, looking to see if we have a bug on that already
<wgrant> stub: aha! can you please apply my index before librarian-gc spoils my plan?
<stub> ok
<stub> and we can kill the librarian-gc if it is ever a problem, it will catch up the next day
<wgrant> sure, but i prefer not to encourage evil workarounds like that
<rick_h_> czajkowski: hmmm, so if you search for arm it works. arm-m doesn't, but it looks like we probably tokenize on the - so not sure it would match.
<rick_h_> czajkowski: I'm not sure if this worked before so I can't say for sure, but it sure seems he just hit a bad search term
<rick_h_> if you just search for arm and sort the blueprints the arm-m ones all jump to the top peachy
<adeuring> czajkowski: that shows a limit in postgresql's search capabilities.
<czajkowski> adeuring: nods
<rick_h_> czajkowski: so I'm going to note that and mark it as an invalid bug
<czajkowski> rick_h_: aye I did try but getting conflicting results
<adeuring> czajkowski: searchinf for "arm m" should work
<adeuring> i'll add a comment
<rick_h_> or let adeuring do it
<rick_h_> yea, arm m works fine
<rick_h_> thanks adeuring
<stub> wgrant: done
<wgrant> stub: thanks
<czajkowski> sinuzi beat us all to the bug and marked as a duplicate
<rick_h_> ah, even better
<czajkowski> https://bugs.launchpad.net/launchpad/+bug/1025357
<_mup_> Bug #1025357: BluePrint searchtext= not returning correct results <lp-blueprints> <search> <specifications> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1025357 >
<wgrant> it seems like a trivial fix would be to just do prefix or trigram matching on the name in addition to fti
<rick_h_> you'd need to build the extra indexes though right? /me tries to remember when he setup pgsql fulltext
<wgrant> well, it would just be a normal string index next to the fti one
<rick_h_> nvm, you mean just or'ing/distinct on matching the name itself
<rick_h_> yea, gotcha
<wgrant> we use this pattern for eg. person searches, where we do fti on displayname, but also prefix on name and email
<wgrant> because fti works for text, and those names are barely text
<rick_h_> adeuring: I made buildbot happy so my changes are landed
<rick_h_> adeuring: might want to pull updated trunk before you go do ec2 land in case we have conflicts in my adding back in the _information_type and getter/setter that you also had in
<adeuring> rick_h_: thanks for the heads-up!
<czajkowski> sinzui: wgrant said to talk to you rehttps://answers.launchpad.net/launchpad/+question/210838  possible subkey issue again?
<sinzui> I will look
<sinzui> czajkowski, he has only one key: http://keyserver.ubuntu.com:11371/pks/lookup?op=vindex&search=0xD543BD02B52EF7A5
<sinzui> but he may want to be certain he is signing with the one key that Lp knows about
 * sinzui looks for command
<sinzui> czajkowski, If he has more than one key in his keyring, he needs to sign using this command that selects the same key that Lp knows about:
<sinzui> gpg -u B52EF7A5 --clearsign
<czajkowski> ahh ok
<czajkowski> didnt know that
<sinzui> yes, we have no faq on that
<sinzui> considering how common this issue is, maybe we want an faq explain this
<czajkowski> nods
* abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugs: ~280
<rick_h_> abentley: review for you if you get a sec please https://code.launchpad.net/~rharding/launchpad/bp_default_1062207/+merge/129001
<sinzui> abentley, do you have time to review https://code.launchpad.net/~sinzui/launchpad/moderated-messages-0/+merge/129013
<adeuring> abentley: another review request: https://code.launchpad.net/~adeuring/launchpad/authentication-for-private-products/+merge/129014
<adeuring> rick_h_: could you review my MP: https://code.launchpad.net/~adeuring/launchpad/authentication-for-private-products/+merge/129014 (abentley seems to be away/busy, and I'd like to land the branch soon...)
<rick_h_> adeuring: looking
<adeuring> rick_h_: thanks!
<rick_h_> adeuring: ok, so in looking at that. Can sinzui look that one over since you guys had a chat. I just feel that I don't know that well enough to help protect against another round of issues.
<adeuring> sinzui: ^^^?
<rick_h_> and I'll try to pick up for sinzui's mp in return?
 * sinzui looks
<abentley> sinzui, rick_h_: Sorry, was lunching.
<rick_h_> abentley: np on my end. looked over sinzui's
<sinzui> I am reading adeuring's branch. I will be done a few minutes. The branch looks good, I want to browse an instance as a few users to verify nothing odd is shown to non-registry users
<abentley> rick_h_: So your review still needs doing.
<rick_h_> abentley: yes please
<abentley> rick_h_: Does your branch handle the case where PUBLIC is not a valid value?
<rick_h_> abentley: yes, the second test covers that case.
<rick_h_> because right after the default being set to PUBLIC, it gets updated based on allowed values
<abentley> rick_h_: I see.
<abentley> rick_h_: I think the right way to do this is to use lp.blueprints.model.specification.SPECIFICATION_POLICY_DEFAULT_TYPES
<rick_h_> looking
<abentley> rick_h_: You should do that via Product.getDefaultSpecificationInformationType
<rick_h_> abentley: ah ok that makes sense. I didn't see that.
<abentley> rick_h_: Yeah, I'm currently mucking around in that area, too.
<abentley> rick_h_: getDefaultSpecificationInformationType appears to be provided by all the other pillars, too, so you should be good to go.
<rick_h_> abentley: ah ok that's what I was going to say that it already hits that for product, but we were getting it None so it must have been a diff context
<abentley> rick_h_: This is exactly at the seam between my work and deryck's.  Clearly we left a gap.
<rick_h_> right, makes sense once it comes up
<rick_h_> abentley: so if you're in there did you want to apply the fix to your branch or am I clear enough not to break up your work?
<abentley> rick_h_: You're clear.  I'm dealing with all those dicts in a different context.
<rick_h_> ok cool
<abentley> rick_h_: Speaking of that, want to review my new branch?
<abentley> https://code.launchpad.net/~abentley/launchpad/specification-policy/+merge/128998
<rick_h_> abentley: sure thing
<abentley> rick_h_: thanks.
<abentley> rick_h_: Hmm, so I think I retract my suggestion on your branch.  Since the value will be set to something reasonable if it's a product, defaulting to PUBLIC if it's not is fine.
<abentley> rick_h_: Because the context doesn't necessarily provide a pillar.
<abentley> rick_h_: NewSpecificationFromNonTargetView and its descendants don't know what the pillar will be, so PUBLIC is the best default we have.
<rick_h_> abentley: ah ok cool. Still good to know about the getDefault...
<rick_h_> abentley: r=me with a small nitpick on updating the comment
<abentley> rick_h_: Thanks.
<sinzui> adeuring, I found an issue in the branch, but I think we can tweak the security checker to keep the current behaviours. We can adjust the interfaces and checker in future branches maybe
<adeuring> sinzui: ok, what is the issue?
<adeuring> nm, found your comment
<sinzui> gary_poster, can I have your plus-one for these instructions to fix a production mailing list. https://pastebin.canonical.com/76259/
 * gary_poster looks
<gary_poster> sinzui, you are the expert we have here, so I'll happily approve if you say thsi is right.  That said, I have suggestions/thoughts.  after first test query, I suggest you clarify what youe expect the output to be (I assume one row).  You did not include instructions to tar or remove the mhonarc bits--that seems like it might be intentional?  You aren't asking for any of those bits to be archived, actually; if t
<gary_poster> hat's what you want cool, but that's not what the page says.  Finally, is 2500 really our timeout these days for writes?  I thought it would be shorter
<sinzui> 2.5secods is the timeout
<sinzui> for changes
<gary_poster> cool
<sinzui> gary_poster, I revised to comment about the deletes: https://pastebin.canonical.com/76265/
<sinzui> Lp and mailman are in disagreement. I think the first 'rm' will do nothing because I believe mailman did delete the list directory.
<gary_poster> cool, sinzui, looks good. If you don't think we need the tars, great. +1.   :-) I have to run
<sinzui> gary_poster. apparently we do not because there never were any messages.
<gary_poster> heh
<gary_poster> ok
<lifeless> wgrant: hey
<lifeless> wgrant: do you know if the new FDT stuff is all live ?
<wgrant> lifeless: Yes
<lifeless> wgrant: is there timing data to be foubd?
<wgrant> lifeless: There are still changes planned to speed up security changes, and to make appservers fall back more
<lifeless> wgrant: how did the appservers handle it ?
<wgrant> lifeless: Slave->master failover worked fine
<lifeless> in phase2?
<wgrant> Yes
<wgrant> Though it was very quick
<lifeless> kk
<wgrant> Let me find times
<wgrant> It was something odd like 4.2s
<lifeless> that sees slow
<wgrant> Yes
<wgrant> We need to start logging milliseconds
<lifeless> yes
#launchpad-dev 2012-10-11
<StevenK> Bleh
<StevenK> Even with 400 dupes I get 85 queries on dev
<wgrant> StevenK: Make sure you're not subscribed (structurally or otherwise) to the master
<StevenK> I'm logged in as name16, so I shouldn't be
<StevenK> wgrant: I thought the terribleness is lp.bugs.model.personsubscriptioninfo PersonSubscriptions, can you peer at https://oops.canonical.com/oops/?oopsid=OOPS-d4b24378110b85ccc7ed204eebd50f3f and see if you agree?
<wgrant> StevenK: Oh
<wgrant> StevenK: Testing things as admins == bad idea
<bigjools> yeah, who cares about admins
<StevenK> Right, let me make a person
<wgrant> StevenK: nopriv
<StevenK> wgrant: Hmmm, now it's 94 queries
<lifeless> wgrant: did you find those times?
<wgrant> lifeless: Sorry, got distracted by unity being terrible
<wgrant> I think we only have one; give me a sec to find it
<wgrant> All input events had about 400ms lag :/
<wgrant> Outage complete. 0:00:04.138329
<wgrant> Is the only one we have
<lifeless> okies
<lifeless> thanks
<wgrant> We'll likely have another one on Monday
<wgrant> But that might be a bit late :)
<lifeless> for me to harangue stakeholders... yes
<StevenK> wgrant: I think it's more than just lots of duplicates, but I can't work it out
<wgrant> StevenK: Let me poke around
<StevenK> wgrant: The OOPS directly implicates BugSubscriptionPortletDetails.extractBugSubscriptionDetails
<wgrant> StevenK: Could it be due to team memberships, perhaps?
<wgrant> I haven't read the code yet
<StevenK> wgrant: What's your thought? Subscribers in lots of teams, structsubs in lots of teams, or self.user in lots of teams?
<wgrant> Yes
<wgrant> An interesting possibility is that we could be filling the Storm cache
<StevenK> On prod? But it's like OMGLOTS
<StevenK> wgrant: I still think I'm missing something because 400 dupes on a bug on dev is only 90 something queries
<wgrant> prod's only 10000
<wgrant> Hm
<wgrant> That's a few dupes, though
<wgrant> Aha
<wgrant> My unprivileged account works fine
<wgrant> I suspect that it times out for everyone that's a participant of ubuntu-bugs
<wgrant> Because it ends up tracking details sub info for all the dupes
<wgrant> Let's see if the code agrees
<wgrant> Oh
<wgrant> Ha
<wgrant> ha
<wgrant>         bug_id_options = [Bug.id == bug.id, Bug.duplicateofID == bug.id]
<wgrant>         info = store.find(
<wgrant>             (BugSubscription, Bug, Person),
<wgrant>             BugSubscription.bug == Bug.id,
<wgrant>             BugSubscription.person == Person.id,
<wgrant>             Or(*bug_id_options),
<wgrant>             TeamParticipation.personID == person.id,
<wgrant>             TeamParticipation.teamID == Person.id)
<wgrant> Read that code
<wgrant> Think of the people and bugs we've seen reports about
<wgrant> StevenK: ^^
<wgrant> They're all apport crashes, and they're all Ubuntu people
<wgrant> Not random users
<wgrant> All of the dupes probably have ~ubuntu-crashes-universe subscribed
<wgrant> Of which all the affected users are participants
<wgrant> Yeah
<wgrant> With the user subscribed to 600 dupes, it's not exactly fast
<wgrant> 3159 queries/external actions issued in 25.20 seconds
<wgrant> StevenK: Is that enough to unblock you?
<wgrant> Basically the world collapses when the user is subscribed to a lot of dupes
<wgrant> So we even have a workaround now
<StevenK> wgrant: Drop out of ~ubuntu-crashes-universe?
<wgrant> StevenK: That requires leaving motu
<StevenK> That isn't the workaround, then?
<wgrant> StevenK: The dupes will have been made public by apport, so one can just API the subscriptions away
<wgrant> They are no longer required
<StevenK> So I need a user in a team, and that team directly subscribed to each dupe, right.
<wgrant> The user itself can be subscribed too
<wgrant> Doesn't really matter
<wgrant> You don't need a team at all
<wgrant> If you filed 500 dupes of the one bug, you'll see the same problem :)
<StevenK> wgrant: I was headed off at the pass by the reporters claiming they weren't subscribed.
<wgrant> Indeed
<wgrant> Then I realised they were
 * wgrant -> out for a while
<StevenK> But it isn't Tuesday
<StevenK> :-P
<StevenK> rick_h_: http://pastebin.ubuntu.com/1272460/ make schema and then make run gives that fun on the run
<wgrant> StevenK: Any luck reproducing it?
<StevenK> wgrant: Oh yes
<StevenK> I've got a test doing 115 queries for 20 dupes
<wgrant> Great
<StevenK> And that's only Bug:+portlet-subscription
<StevenK> If I comment out that horrible info query, the count drops to 14
<StevenK> But I can't work out what that block is doing with the query
<StevenK> Ah ha. That query is the symptom
<wgrant> It goes through every bug that the query returns
<wgrant> Iterating through its tasks and their targets
<StevenK> Yeah, I just figured that bit out
<StevenK> Why does it want to do that?
<wgrant> Because
<wgrant> Possibly because the same code might be used to generate notification rationales
<wgrant> But mostly just because
<StevenK> Right, so commenting out that bit gets us to 15 queries
<StevenK> So it's the obvious cause
<wgrant> Well
<wgrant> The query log clearly shows it's the cause too :)
<StevenK> I can't work out why they want to annotate the bug supervisor in. :-(
<StevenK> wgrant: So, I don't know why this function wants to annotate the bug supervisor in. I'm tempted to gut it and then toss the branch at ec2 and see what falls out.
<wgrant> StevenK: Check what uses the annotations
<wgrant> It's probably for the notification rationale, or potentially the awkward prose that replaced the (+) Subscribe link
<StevenK> Yeah, it's certainly implicated in lp/bugs/javascript/subscription.js
<StevenK> Hold on, isn't there a handy function we could use, IBug.affected_pillars or something?
<wgrant> Right, but you still need to preload them
<StevenK> Can't I just use BTF for that?
<wgrant> BTF doesn't provide a significant benefit here
<wgrant> It's wider than bugtask, so it may actually be detrimental
 * StevenK tries to remember the load function
<wgrant> load
<wgrant> Though you may want load_related instead
<wgrant> Both live in lp.services.database.bulk
<wgrant> StevenK: buildbot's going to fail. Looks spurious, though I've never seen it before
<StevenK> I was watching until I got distracted
<StevenK> wgrant: Wait, how can I use load_related? There's no foreign key on Bug that references bugtask
<StevenK> wgrant: That test passes locally at least
<wgrant> StevenK: You can't use load_related for grabbing the tasks, just the pillars
<wgrant> We probably have existing code for grabbing affected_pillars
<wgrant> Although maybe not
<wgrant> It's already cached, AFAIK, but maybe not preloaded ever
<StevenK> wgrant: Not that I can see
<StevenK> Actually, how does load_related even help for affected_pillars?
<wgrant> You can grab all the tasks then load the referenced products and distributions in one hit-
<StevenK> wgrant: Sure, but load_related is expecting an object type as the first argument not a mishmash
<wgrant> StevenK: Right, so run it twice
<wgrant> O(2) is still O(1)
<StevenK> wgrant: Shall I force BB?
<StevenK> Ah, you/somebody already did
<wgrant> I did
<wgrant> Why is a single user subscribed to 144 public duplicates of bug #512096...
<StevenK> Down from 115 queries to 36
<StevenK> Right, it's a contrived case, but 400 dupes is down from 2015 queries to 21.
<StevenK> When in doubt, add more preloading.
<wgrant> That's a mild improvement
<StevenK> 20 dupes is also 21.
<wgrant> wallyworld_: Bug #1016156 is one of about five criticals we have that are probably not what they seem
<_mup_> Bug #1016156: ProjectGroup:+index timeout due to slow query of subprojects <timeout> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/1016156 >
<wgrant> They're one-offs that make no sense, probably indicating a separate issue that's nothing to do with the page.
<wgrant> Investigating it is likely to be fruitlessly frustrating
<wgrant> I don't have enough data to conclusively dupe them all yet, though
<wallyworld_> there were a few lazy loaded people etc
<wallyworld_> but nothing really bad
<wgrant> The PPR shows that the page is bad, but the 99% is 4.59 and it exceeds 6s ~0.3% of requests
<wgrant> The particular issue described in that bug is not related to the page's general slowness
<wallyworld_> 4.59 seems high
<wgrant> It is, yeah
<wgrant> The page could use some work
<wallyworld_> given how little is rendered
<wgrant> ProjectGroup stuff is notoriously difficult to index
<wallyworld_> i might look a little more, and pick up another bug tomorrow
<wgrant> Because it delegates just about everything down to multiple (or, in some cases, lots) of products
<wallyworld_> opportunity for preoading
<wallyworld_> i do think we need to expunge some of the criticals
<wgrant> Indeed
<wgrant> I've pruned most of them fairly well, but some are in a grey area
<wgrant> Like that one
<wallyworld_> what about ones with no oops anymore
<wgrant> In some cases you can reasonably work out what the issue is
<wgrant> But if you can't, Invalid :)
<wallyworld_> or old ones which haven't occurred in ages and may well be fixed
<wgrant> We have OOPS reports to tell us if they happen again
<wallyworld_> but wtf knows
<wgrant> If I didn't want to make a point out of the critical graph, I'd suggest we should rather focus on the top offenders in the OOPS reports.
<wallyworld_> yep, agreed
<wgrant> But I think it's important to make a point :)
<wallyworld_> really?
<wgrant> Plus also the obvious benefit of having a more manageable list
<wgrant> 'cause it was pretty daunting before
<wallyworld_> yes
<wgrant> It's much easier to manage 250 bugs than 410
<wallyworld_> i'd argue that only a small percentage of those are truely critical
<wgrant> Sure, but that question goes away if we fix them all, as we are on track to do :)
<wallyworld_> by most accepted definitions of critical
<wallyworld_> perhaps
<wallyworld_> until we start slowing down
<wgrant> Shhhh
<wallyworld_> well people have been arguing thst there was no low hanging fruit left
<wallyworld_> which was clearly false
<wgrant> There were 150 bugs of low hanging fruit, at least
<wallyworld_> plus many that have been fixed were not easy, just required some analysis
<wgrant> There's at laest 50 more
<wgrant> The remaining 200 are probably a bit messier
<wgrant> But we shall see
<wallyworld_> indeed
<wallyworld_> and if their impact is minimal, you'd have to question are they critical
<wgrant> Part of the argument for their being critical is that they make the error reports noisy
<wgrant> So it's difficult to detect real issues
<wgrant> This is a real problem, as we've missed many indications of production issues because they only caused eg. 50 OOPSes a day
<wgrant> Simply because there's so much noise
<wgrant> However, most of these OOPSes are old
<wgrant> New timeouts keep showing up, but OOPSes tend to be shoddy old code
<wgrant> So as we fix them, the total count should monotonically decrease.
<wgrant> (counting the total number of OOPS issues that exist, not just those that have been reported)
<wgrant> And new timeouts usually are legitimately critical
<wgrant> They block people, they block appservers, and they use valuable DB time
<wallyworld_> i'm guessing several timeout criticals just don't apply anymore since code has been fixed but not linked to the bug
<wgrant> wallyworld_: Quite possibly, yeah. Compare with https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-monthly-pageids.html
<wgrant> I've been through most, but not all
<wallyworld_> i think we should interest current oops reports with timeout/oops related criticals
<wallyworld_> and delete any that are not common
<wgrant> Some of the timeouts don't show up more than a few times a month
<wgrant> But they're still important
<wgrant> Others only show up around Ubuntu releases
<wgrant> So for a few weeks every 6 months
<wgrant> (some of which intersect last month, so latest-monthly-pageids is ideal atm)
<wallyworld_> true
<wgrant> You can see from the graph whether things ever time out
<wgrant> On little-used pages you can even see that eg. a single request took 8.5s.
<wgrant> So it was probably a random glitch, and the page actually performs fine
<wgrant> Or you can see that a page is <1s, except when it's >9s, presumably due to locks
<wgrant> So it doesn't deserve a timeout exception, and doesn't need work directly
<wgrant> Speaking of which, time to delete a few feature flags
<adeuring> good morning
<czajkowski> adeuring: well it's morning, not sure about good, perhaps it's good almost weekend :)
<adeuring> czajkowski: ;)
<jml> everyone seen http://blog.datomic.com/2012/10/codeq.html already?
<czajkowski> jml: nope I usually rely on reading your G+ posts for new links to read :)
<jml> czajkowski: :)
<czajkowski> jml: no this is a good thing :)
<jml> the codeq thing is pretty neat, although ultimately unusable for Launchpad.
<jml> uses datomic (a data store that layers on existing dbs, leveraging all sorts of neat things off facts being immutable) to do things including cross-repo searching
<jml> czajkowski: oh good. I'm glad. I think :)
<jml> since they are lisp weenies, they go all crazy and parse the source code
<jml> but it ties in with stuff that LP already does w/ BranchRevision
<wgrant> We don't speak its name.
<jml> wgrant: very sensible.
<wgrant> jml: It currently has approximately 2 billion rows, of which around 950 million are for branches of lp:launchpad
<wgrant> It is not sensible.
<jml> wgrant: I meant it was sensible to not call the blighted gaze of the elder tables down on to our own mortal heads.
<wgrant> Indeed
<jml> wgrant: have you looked into datomic at all? [note: I am in no way suggesting Canonical use it, but the ideas are pretty cool]
<wgrant> jml: I've seen it around, but not had the chance to look at it myself.
<wgrant> Should I?
<jml> wgrant: if you've looked into some of his other thinking about values & immutability, it's nice to see that working out into an actually useful db that makes scaling, caching and other things much less your problem.
<wgrant> jml: I am sufficiently intrigued.
<jml> http://jaxenter.com/clojure-datomic-creator-rich-hickey-on-deconstructing-the-database-44170.html is the talk I watched, off the back of http://www.infoq.com/presentations/Value-Values, which is a more philosophical keynote.
<wgrant> Thanks
<jml> np
* wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugs: ~270
<czajkowski> nice to see that number shrinking
<stub> wgrant: So dropping tables can be done live now.
<stub> Which is rather scary. Much easy to defer destroying data to a robot so you don't have to think about it :)
<wgrant> stub: Dropping the FKs probably still requires a lock
<wgrant> BVP has an FK to person
<wgrant> And product/project
<wgrant> I haven't tested that, though
 * wgrant tests that
<stub> I don't think it would be a problem...
<stub> but have thought that sort of thing before
<wgrant> Confirmed, it blocks
<stub> And no gain splitting it
<wgrant> Exactly.
<wgrant> Well
<wgrant> Maybe if it was a large relation
<wgrant> But it's not
<stub> The data can't actually get removed until all the running transactions have completed
<stub> So it isn't like we need to wait for the filesystem to clean things up
<wgrant> DROP TABLE isn't always as instantaneous as you would expect
<wgrant> Although that may just be because there were contended locks
<wgrant> I guess we'll find out tomorrow :)
<czajkowski> wgrant: is there a way to see the history of a project creation, and their licence choice ? I've a team that reguarly seems to change their licence
<wgrant> czajkowski: Sadly not
<czajkowski> wgrant: I've a team that seems to make useof the commercial 30 day trial and then switch to another licence for a month then back to commercial
<wgrant> czajkowski: That's a little suspicious
<wgrant> Which?
<czajkowski> sent to pm
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugs: ~270
<czajkowski> sinzui: have a project that seems to change its licence regularly, it's gone from properitary to all sorts back to commercial changes after 30 days from there to another one, wgrant says you've dealt with them
<czajkowski> sinzui: https://launchpad.net/akiban-server
<sinzui> Yes
<sinzui> czajkowski, They updated their licensing for a few projects earlier this year. They made some projects non-proprietary and opened the code.
<sinzui> They are probably doing another review and an uncertain about making the server project open
<czajkowski> ah ok just seems to be every few weeks they change.
<czajkowski> deryck: if I've learnt anything in the last 8 months since joinging is that I am happy to never go near zope!
<deryck> heh
<adeuring> flacoste: the problem is still the permission lp.View. lp/app/browser.launchpad.py,
<adeuring> line 766:
<adeuring>         if pillar is not None and check_permission('launchpad.View', pillar):
<adeuring>              return (something_useful)
<adeuring>         return None
<adeuring> So, the idea is that ordinary users do not have lp.View on inactive products
<adeuring> but they still need to be able to access pillar.name for for "tricky"
<adeuring> bug pages...
<flacoste> adeuring: any idea on how we could change that logic to do the right thing?
<adeuring> not really...
<adeuring> the permission check makes sense
<flacoste> well
<adeuring> but it does not allow us to protect the attributes name, displayname and-whatever-else with lp.view
<flacoste> how about you check the active flag directly there
<flacoste> ?
<adeuring> flacoste: so, special-casing IProduct?
<flacoste> active is on IPillar right?%
<flacoste> so no need to special case
<adeuring> that's as ugly as having a  new permission ;)
<flacoste> it's at least localized
<flacoste> and more directly express the intent
<adeuring> flacoste: ok, I'll try it. But this is also a band-aid....
<sinzui> jcsackett, I have a branch for review. The bug is low so I expect this to be reviewed only if there is nothing else to do: https://code.launchpad.net/~sinzui/launchpad/nomination-investigation-0/+merge/129223
<flacoste> adeuring: well, my understanding was that we were looking for a quick band-aid to unblock the rest of team
<flacoste> so that fits the bill :-)
<jcsackett> sinzui: fear not, you are the only review in the queue. :-)
<jcsackett> looking now.
<adeuring> flacoste: sure, but I am a bit concerned that any other kind of check will sometimes return a wrong result...
<adeuring> ok, I can check for product.private too
<flacoste> adeuring: why?
<flacoste> does check_permission returns False or raises an error?
<adeuring> flacoste: we should nreturn a 404 for an active but private project, if a user does not have grants for the product
<jcsackett> sinzui: looks fine to me. r=me.
<adeuring> flacoste: itjust return False
<flacoste> adeuring: should or shouldn't?
<adeuring> flacoste:  we shlould return 404
<flacoste> so the logic above covers that
<adeuring> flacoste: yes, but for an inactive public product, the user needs to have the lp.view permission
<flacoste> adeuring: well, no, only some people should
<flacoste> adeuring: but the checker should already cover that, no?
<flacoste> by delegating to ViewPillar
<adeuring> flacoste: let me think a bit about it...
<flacoste> maybe the problem isn't in that area then
<sinzui> adeuring, didn't my proposed checker solve the test case I outlined? It deferred the ViewPillar if the project was not private
<adeuring> sinzui: the problem is that the same checker is user for for IProductView and for IPillar, see my comments in the MP
<sinzui> adeuring, my change was largely to remove the extra permission check that was applied to all projcts in the new checker
<sinzui> I did, and I did not see that...did my test case fail for no-priv and anon?
<sinzui> adeuring, StevenK, wgrant, and myself landed 4 branches to get private team permission right. I think the same will happen for projects. We can make safe incremental changes to get to the proper implementation. The hard problems solve in the next branches will change the checkers, drop or redefine more interfaces, and change traversal rules
<sinzui> We just want to make each change without causing a regression that affects 100-1000's of users
<adeuring> sinzui:  the problem is that we want (1) a 404 for a public inactive product. but (2) need access to product.name, product.displayname and whatever else for bug pages. SO we can't use lp.View for these properties
<adeuring> and the 404 is right now a check for lp.View
<adeuring> sinzui: flacoste suggests to create the 404 in some other way
<flacoste> adeuring: name and display name should be protected by LimitedView, no?
<flacoste> not View
<sinzui> But everyone has lp.view on a public project even if it is deactivated. We show them in the UI and we have bugs about that. The issue as wgrant suggested is one of traversal
<adeuring> flacoste: yes
<sinzui> you will find we special case private team traversal to get the correct error
<adeuring> sinzui: please try my test branch.
<flacoste> sinzui: that's why i suggested handling the exception in the traversal code
<sinzui> flacoste, agreed. We changed traversal, checkers, and interfaces to get this to work over api and web
<rick_h_> anyone seen this mercurial error trying to run tests today? https://pastebin.canonical.com/76367/
<rick_h_> I was doing tests ok in another branch this morning, but now trunk and my branch are doing this to me
<rick_h_> ok, it'd help if I could type/spell at the same time
<abentley> rick_h_: A typo shouldn't cause that, though.
<rick_h_> abentley: not sure, I switched back to my old branch this morning, fixed the typo and it works.
<rick_h_> not tests are running for me on my working branch ok
<abentley> rick_h_: And with the typo is it broken?
<rick_h_> hmmm, no.
<rick_h_> I flipped something when I swapped branches back/forth
<abentley> rick_h_: Since bzr-hg has recently been removed from sourcecode/, I suspect you were working in a branch that required it, without having run utilities/update-sourcecode.
<rick_h_> abentley: ah yea, I ran make clean/make and updated sourcedeps, but didn't check out update-sourcecode
<lifeless> sinzui: you may enjoy https://bugs.launchpad.net/launchpad/+bug/1065682
<_mup_> Bug #1065682: bad email when admin adds someone to a team <Launchpad itself:Triaged> < https://launchpad.net/bugs/1065682 >
<czajkowski> lifeless: intersting as I had webops do that for me
<lifeless> czajkowski: tis a bug.
<lifeless> czajkowski: I'm curious why you changed it before I actually leave :)
<czajkowski> lifeless: I changed it from elliot to rbbie not you
<czajkowski> unless I've made a mistake
<lifeless> czajkowski: ah, was it still owned by statik? Doh, I clearly forgot to move it once robbiew was announced.
<czajkowski> lifeless: :)
<czajkowski> lifeless: lets not give me heart failure today shall we
<lifeless> czajkowski: but, but, but.
<lifeless> czajkowski: iz fun!
<lifeless> :)
<czajkowski> lifeless: no fun would be marking all new bugs by you as invalid as payback but I also value my life! :)
<lifeless> :P
<lifeless> speaking of which, time to add me to the emeritus team
<lifeless> (https://launchpad.net/~launchpad-emeritus)
<lifeless> its not fully setup - the intent hasn't been reached, but the intent is documented ;)
<czajkowski> lifeless: also https://launchpad.net/~not-canonical
<sinzui> lifeless, didn't wgrant report that same thing a few weeks ago?
<lifeless> sinzui: maybe, I thought this one was different.
<lifeless> sinzui: it may be a variation on a theme, a cluster of buglets.
<lifeless> sinzui: I was sure I saw a *fix* for something related go by
<sinzui> In both cases Lp's code the team owner made the change because it believes that is the only person who can make the change
<lifeless> czajkowski: https://launchpad.net/~not-canonical is full of randoms :)
<sinzui> The code wgrant shows looks like the same path
<lifeless> czajkowski: specifically, it has folk that are mistaken for canonical staff, which /might/ apply to me in future :)
<lifeless> sinzui: ah, wgrants fix has not landed ?
<sinzui> We haven't planned a fix.
<czajkowski> lifeless: it started off a lot smaller and had folks like me and popey in it
<czajkowski> it's kinda gotta others now in there
<czajkowski> it was amusing to start and I left it the morning I joined canonical as had kept the news quiet and only the admins knew :)
<czajkowski> 8 months this week!
<lifeless> sinzui: ah ok :)
<czajkowski> rick_h_: did you get a mifi in the end?
<rick_h_> czajkowski: I ended up buying a http://www.amazon.com/gp/product/B007WYS7CK/ref=oh_details_o00_s00_i00 we'll see how it works
<czajkowski> rick_h_: ah nice.
<rick_h_> lots of options, but all seem to have some issues
<rick_h_> really just bummed I couldn't upgrade my current mifi on verizon and have them unlock it
<czajkowski> rick_h_: ours is http://url.ie/g0wk does the job
<czajkowski> we put random sims in it when travelling to other parts of eU
<rick_h_> cool, yea I think most anything will end up working just got caught up in review loop of doom
<czajkowski> heh
<rick_h_> that and it's just spooky since it's hard to test/figure it out from here in the US
<czajkowski> nods
<czajkowski> at least you'll have it after this trip
<rick_h_> yea, that's what I figure. And it should work on ATT here in the states on a prepay (will find out)
<rick_h_> so I can lend one of mine to my wife when she goes around and still have mine here
<czajkowski> I usally just tether my phone
<rick_h_> yea, my phone isn't world so figured it's cheaper to upgrade the mifi
<czajkowski> or I did til I upgraed to jellybean and it wont connect
<rick_h_> doh
<czajkowski> :/
<rick_h_> <3 my LTE mifi though. LTE is FAST
<rick_h_> faster than my home broadband connection so don't want to give it up any time soon
<czajkowski> https://bugs.launchpad.net/ubuntu/+source/gmtp/+bug/903422  <--- pita bug
<_mup_> Bug #903422: Mount / Provide access to Android 4.x (Ice Cream Sandwich and above) MTP devices <gvfs:In Progress> <libmtp:Fix Released> <gmtp (Ubuntu):Confirmed> <libmtp (Ubuntu):Fix Released> <udev (Ubuntu):Confirmed> <gmtp (Ubuntu Precise):Confirmed> <libmtp (Ubuntu Precise):Confirmed> <udev (Ubuntu Precise):Confirmed> <gmtp (Ubuntu Quantal):Confirmed> <libmtp (Ubuntu Quantal):Fix Released> <udev (Ubuntu Quantal):Confirmed> < https://launchpa
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ~270
<wgrant> lifeless: I haven't fixed anything quite like that
<lifeless> wgrant: thanks
<wgrant> But that's an odd one... it's not quite a dupe
<wgrant> I didn't even know this one was a problem
<wgrant> But they should probably be fixed together, so being marked as a dupe is probably correct :)
<mwhudson> bug relationships!
 * mwhudson runs away
<lifeless> testing
<StevenK> wgrant: So, how do we attack this query?
<wgrant> StevenK: Yes
<wgrant> StevenK: Well
<wgrant> StevenK: Ideally you'd find a bug on dogfood for which it gave a similar slow plan
<StevenK> That could be difficult
<wgrant> Not really
<wgrant> Just need something with a tonne of apport dupes
#launchpad-dev 2012-10-12
<StevenK> wgrant: I'm not certain that the info query in _getDirectAndDuplicateSubscriptions is to blame. The slow query is using ORDER BY and DISTINCT
<StevenK> wgrant: It's pretty much the same query, though
<StevenK> wgrant: Yeah, the long query is from IBug.getSubscribersForPerson
<StevenK> And just took 4 minutes on DF
<wgrant> :D
<wgrant> So, explanalyze it
<StevenK> That was what took 4 minutes
<wgrant> What's the plan?
<StevenK> wgrant: http://pastebin.ubuntu.com/1274106/ and http://pastebin.ubuntu.com/1274107/
<StevenK> wgrant: Still distracted?
<wgrant> StevenK: Sorry, food was required.
<wgrant> Let's see
<wgrant> StevenK: So, do you see in the plan what I described on the call this morning?
<StevenK> That's okay, I amused myself by destroying Bug{Security,Visibility}Change.
<wgrant> Great
<StevenK> y% bzr di | diffstat -s
<StevenK>  7 files changed, 36 insertions(+), 236 deletions(-)
<wgrant> :)
<StevenK> wgrant: So I can recall you said there are two ways postgres can look up the information, either by the bug or the team
<StevenK> And it's obviously going via the bug due to:
<StevenK>                      ->  Index Scan using bug_pkey on bug  (cost=0.00..0.62 rows=1 width=4) (actual time=1.729..1.729 rows=0 loops=147850)
<StevenK>                            Index Cond: (id = bugsubscription.bug)
<StevenK>                            Filter: ((id = 429322) OR (duplicateof = 429322))
<wgrant> StevenK: Not quite.
<wgrant> The plan is largely executed from inside to out, top to bottom
<wgrant> So it starts with the innermost topmost thing
<wgrant> In this case, the teamparticipation index scan
<wgrant> So it's finding all teamparticipations for the person in question
<wgrant> And if you look at the right, you'll see "rows=27"
<wgrant> So it finds 27 teamparticipation rows
<wgrant> for that person
<StevenK> wgrant: Right
<wgrant> Then it you go up to the parent node
<StevenK> wgrant: And that feeds into the bugsubscription index with loops=27
<wgrant> And see it's a nested loop
<wgrant> A nested loop has two nodes: the second is executed once for every row in the first node
<wgrant> So for each teamparticipation record, it finds the relevant bugsubscriptions
<wgrant> And there are 27 rows, so loops=27
<StevenK> Ah, right
<wgrant> The row count there is an average
<wgrant> So, now we exit the first nested loop
<wgrant> And find ourselves in a second one
<wgrant> With 150000 rows to process
<wgrant> *Now* we query the bug for each of those 150000 bugsubscriptions
<wgrant> And check whether it matches our filter
<wgrant> So that's roughly 150000 random seeks
<wgrant> (although in reality it'll be cached, it's still not good)
<StevenK> Right
<wgrant> Once we find the bugs that match, we do one final nested loop to join the people so we can return Person.name
<wgrant> So, what's the problem here?
<StevenK> wgrant: That bug number is the worst of the lot with 1.1k dupes
<wgrant> Right
<wgrant> Is there an alternate strategy that postgres could use to get the same result?
<StevenK> wgrant: I guess we'd ideally like to answer the bugsubscriptions for the bug and the person in one shot using an index
<wgrant> Not really
<wgrant> The problem here is that it has to do 150000 index lookups
<wgrant> If we can minimise that step, we win
<StevenK> It wouldn't be that many
<StevenK> Since it filter the index based on the information we want
<wgrant> An alternate strategy is to first ask for all the duplicate bugs, then for each bug look for the subscriptions, and compare them to a list of teams that we participate in
<wgrant> That works out to roughly one index scan and a hash lookup for each bug
<StevenK> wgrant: Using a JOIN, or what are you thinking?
<wgrant> Well, once we've devised a plan, we need to trick postgres into using it
<wgrant> We can't tell it directly.
<StevenK> wgrant: And we do that by tweaking the query?
<wgrant> Right
<wgrant> It requires a bit of experimentation
<wgrant> Often you can force it to do your bidding using subqueries or CTEs
<wgrant> eg. a common thing is to convince it to build a hash of the teams we're looking for
<wgrant> By using "
<wgrant> WITH teams AS (SELECT team FROM teamparticipation WHERE person = 1191103)"
<StevenK> wgrant: http://pastebin.ubuntu.com/1274170/
<wgrant> That's a different query, isn't it?
<wgrant> Although it is quite related
<wgrant> And a similar plan
<StevenK> Yeah, it's different
<StevenK> Bug.id IN (SELECT id FROM BUG WHERE id = 429322 OR duplicateof = 429322)
<wgrant> Right
<StevenK> Versus Bug.id = 429322 OR Bug.duplicateof = 429322
<wgrant> Note also in both plans where postgres goes wrong
<wgrant> After the nested loop against bug:
<StevenK> Yeah, in the same place
<wgrant>                      ->  Nested Loop  (cost=0.00..1172.79 rows=139 width=16) (actual time=0.063..2313.480 rows=147850 loops=1)
<wgrant> The first parenthesised bit is the estimate
<wgrant> The second is the actual
<wgrant> So it expected it'd get 139 bugs
<wgrant> But actually got 147850
<StevenK> It estimated ~150 rows and got back ~150k ?
<wgrant> Right
<wgrant> Its plan was a good one given the estimates it had
<StevenK> wgrant: How does the teamparticipation CTE look?
<wgrant> StevenK: Monumentally unsuccessful
<StevenK> Maybe a bug CTE?
<wgrant> StevenK: That might be worth a try
<wgrant> It could convince it to use a hash for the bug lookups
<StevenK> And the query in IPersonSubscriptionInfo._getDirectAndDuplicatesSubscriptions has the same estimate versus actual factor difference, so the same change will probably make both queries performant
<wgrant> Right :)
<StevenK> WITH bugs AS (SELECT id FROM bug WHERE id = 429322 OR duplicateof = 429322)
<wgrant> Right
<StevenK> Where does that go in the query, though?
<wgrant> CTEs always go at the start
<wgrant> eg
<wgrant> WITH teams AS (SELECT team FROM teamparticipation WHERE person = 1191103), bugs AS (SELECT id FROM bug WHERE duplicateof = 429322)
<wgrant> SELECT BugSubscription.id, BugSubscription.bug
<wgrant> [...]
<StevenK> and then WHERE Bug.id IN bugs ?
<wgrant> Bug.id IN (SELECT id FROM bugs)
<wgrant> It appears as a table
<wgrant> Not an expression itself
<wgrant> (also note that the CTE I quoted ignores the bug.id check, just to simplify this initial experimentation)
<wgrant> So it only counts duplicates, not the bug itself
<StevenK> http://pastebin.ubuntu.com/1274176/
<StevenK> It still sucks as estimating
<wgrant> It's never going to estimate well
<wgrant> Because this is an utterly extraordinary case
<wgrant> We have to force its hand
<StevenK> Let me try the two CTEs like you suggest
<wgrant> That sounds like a good plan
<StevenK> wgrant: http://pastebin.ubuntu.com/1274179/
<wgrant> StevenK: You have a pointless bug join in your main query
<wgrant> StevenK: You can just say bugsubscription.bug IN (SELECT id FROM bugs)
<wgrant> StevenK: Any luck?
<StevenK> wgrant: Sorry http://pastebin.ubuntu.com/1274200/
<wgrant> StevenK: Oh
<wgrant> StevenK: You have this person join there that's unconstrained
<StevenK> wgrant: I don't need Person.id IN ... ?
<StevenK> I wasn't really sure about that bit
<wgrant> You perhaps want "AND Person.id = BugSubscription.person" instead
<wgrant> So Person is actually joined against BugSubscription
<StevenK> wgrant: http://pastebin.ubuntu.com/1274207/
<StevenK> That one came back quicker than I was expecting. :-)
<wgrant> Indeed, that's more like it
<wgrant> Now, index-only scans would make a pretty nice difference here
<wgrant> Sadly we don't have them yet
<wgrant> StevenK: It may be helpful to see what's going on by using EXPLAIN (ANALYZE ON, VERBOSE ON) instead of EXPLAIN ANALYZE
<wgrant> THen it'll show the columns it grabs from each result node
<StevenK> wgrant: http://pastebin.ubuntu.com/1274209/
<wgrant> So we can now see exactly what it's doing
<wgrant> StevenK: It's still trying to go TeamParticipation->BugSubscription->Bug, as you can see
<wgrant> But that's faster now since it's just a hash lookup on a thousand bugs
<wgrant> Not an index lookup
<wgrant> It may be worth trying to convince it to start at the bugs, then go to the bugsubscriptions
<StevenK> So you want faster still?
<wgrant> Perhaps by creating a CTE of bugsubscriptions
<wgrant> StevenK: Right
<wgrant> StevenK: This is still quite slow
<wgrant> Fast enough to work
<wgrant> But it'd be nice if we could get it a bit faster
<StevenK> Nod
<StevenK> wgrant: Can you have a play, I need to get lunch?
<wgrant> Sure
<wgrant> Well
<wgrant> I already have had a play
<StevenK> wgrant: Oh?
<lifeless> might be better to nab the subscriptions and do a constrained cross product with person
<lifeless> move the person manipulation out of the inner loops
<lifeless> what you have there is 8 seconds on prod
<lifeless> mm, you are already.
 * lifeless fiddles
<lifeless> btw - http://paste.ubuntu.com/1274216/
<wgrant> I have a reasonable solution myself, I'm trying to walk StevenK to it :)
<lifeless>                ->  Nested Loop  (cost=0.07..857.65 rows=4 width=19) (actual time=0.447..622.478 rows=147850 loops=1) is the issue, cold cache effects will hurt you
<wgrant> lifeless: Hm, which query is that from?
<wgrant> Yes
<lifeless> wgrant: http://pastebin.ubuntu.com/1274209/
<wgrant> That's what we're trying to eliminate
<wgrant> Oh, that one, right
 * lifeless tries w/out person
<lifeless> that distinct you have is distinctly odd
<lifeless> why do you want order by person.name ?
<wgrant> I haven't looked at that particular query, so I don't know
<wgrant> I was looking at the other one
<lifeless> if its the portlet
<wgrant> The core loop is similar
<lifeless> then we're not slicing
<lifeless> so bring them all back and sort in appserver.
<lifeless> 1200ms
<lifeless> 300ms hot
<wgrant> Right, about 1.5x faster than DF, as usual
<lifeless> the person including one comes down to 500ms hot
<lifeless> 229ms
<lifeless> 344ms
<lifeless> new one is 285,193, 400 - significantly faste
<lifeless> he says from probably too few trials
<lifeless> 5000 lookups on bugsubscription_person_idx
<lifeless> 11ms there, 35ms on bug hash lookups
<lifeless> still 159K rows scanning bugsubscriptions
<lifeless> union time perhaps
<lifeless> http://paste.ubuntu.com/1274226/ is what I just played with for ref
<wgrant> Huh
<wgrant> That's a bit slow
<wgrant> That sort of thing was like 500ms on DF an hour ago
<wgrant> Or is it subtly different somehow...
<lifeless> union is faster at the innermost layer
 * lifeless tries again
<lifeless> nah, needs bigger hammer
<wgrant> Yeah
<wgrant> I have a 15ms hammer
<wgrant> I'm pretty sure you can't do much better than that
<lifeless> gnar hash join diaf
<wgrant> :D
<wgrant> Then you disable hashjoin
<wgrant> And it does mergejoin instead :)
<wgrant> Ah
<wgrant> And this thing is even <100ms on the worst bug in existence
<lifeless> wait, wtf is this doing
<lifeless> its expanding all the teams?
<lifeless> I mean, if its the portlet, *why are we expanding teams* ?
<lifeless> or is it 'teams I am a member of that are subscribed'
<lifeless> that must be it
<wgrant> That's the one
<wgrant> http://pastebin.ubuntu.com/1274107/ is similarly misbehaved, but without the insane distinct/order
<wgrant> The core misbehaviour is identical
<wgrant> It endeavours to identify those duplicate bugs to which the user or their teams has a bugsubscription
<lifeless> wheee, seq scan on bugsub
<lifeless> diaf again. Srs for reals.
<wgrant> Ah
<wgrant> And with another tweak it's down to 20ms for the worst bug ever
<lifeless> you have become very good at this
<lifeless> you should blog about it
<wgrant> Hah
<lifeless> seriously
<lifeless> I'm down to 13ms
<lifeless> whats the worst bug ever ?
<lifeless> or is that bug, person combo I've been using the worst case already ?
<wgrant> On DF, 429322 and 419488 are probably at the top of their respective badness dimensions
<lifeless> 7ms
<lifeless> for the pair I've been testing
<lifeless> which is bug 42933 and person 1191103
<_mup_> Bug #42933: Kubuntu Installer crashed trying to manually edit partitions table -- Reproduceable <ubiquity (Ubuntu):New> < https://launchpad.net/bugs/42933 >
<lifeless> wgrant: http://paste.ubuntu.com/1274251/
<lifeless> person 419488 gives me 0.168ms
<wgrant> I mean bug 419488
<wgrant> One has the most dupes, the other has the most dupe subscribers
<lifeless> ah, stay with person 1.1M ?
<wgrant> Right
<lifeless> 14ms
<lifeless> wgrant: I'm curious what you came up with
<lifeless> wgrant: and serious about bloggin :)
<wgrant> sec
<wgrant> just trying with another bug
<wgrant> 492322 is very strange
<wgrant> Er, 429322
<wgrant> It has 1107 duplicates
<wgrant> But only 35 dupe subscribers, apparently
<wgrant> 659438 has around 1000 of each
<wgrant> lifeless: http://paste.ubuntu.com/1274256/ is what I had
<lifeless> 333 cold, 18 hot
<wgrant> On 659438 the performance is basically identical to yours
<wgrant> 26-27ms
<lifeless> for 659438
<wgrant> I can probably inline two of those CTEs
<lifeless> as low as 11
<wgrant> I haven't tried since createing the bugsub CTE
<wgrant> Which is the critical bit
<wgrant> Ah
<wgrant> So yours is basically the same
<lifeless> I think you'll trigger hash joins
<wgrant> Just unformatted and with joins instead
<lifeless> I threw a union in there
<wgrant> CAn you try mine on prod/staging with 429322, 419488 and 659438?
<lifeless> 52,12,20
<wgrant> :(
<lifeless> 19,11,12
<lifeless> 39,16,13
<wgrant> Oh
<wgrant> Those are three runs from each?
<wgrant> So mine's pretty competitive
<lifeless> yes
<wgrant> Yay
<lifeless> yah, and a bit simpler
<lifeless> but returning different data
<wgrant> Is it? :/
<wgrant> Oh, just the missing decorations like person and distincts and such
<lifeless> I'm returning the person
<wgrant> I ripped them out since they weren't relevant to optimising the core
<lifeless> you're returning the subscription id and the bug
<wgrant> Yeah
<lifeless> 42, 29, 36
<wgrant> I was worried that this technique would be terrible for people with few teams on bugs with tonnes of dupe subs
<lifeless> doing 6* with changed return column to bugsubscription.person
<wgrant> But it seems to be pretty fast
<wgrant> Hm
<wgrant> Mysterious
<lifeless> I get 66,11,25 doing three of mine on it
<lifeless> more variance
<lifeless> 10,27,27 repeating
<wgrant> Anyway, a bit better than what we had before
<lifeless> induitable
<wgrant> Though I think we might have scared StevenK away
<lifeless> y
<StevenK> I just got back from lunch
<StevenK> Since it's raining cats and dogs, I had to drive
<lifeless> teamparticipation_person_idx + bug_duplicateof_idx + bugsubscription_bug_idx and a hash on the directsubscribers result.
<wgrant> lifeless: I had this 20ms solution before you started investigating, FWIW :P
<wgrant> Right, that's basically the optimal plan, AFAICT
<StevenK> Excellent, so now you share :-P
<lifeless> for you, teamparticipation_person_idx a BitmapOr on bug_duplicateof_idx, and - here is the difference - a HashAggregate on bugs + bugsubscription_bug_idx scan.
<lifeless> and then you also on top o fthat do a hash for the teamwork
<lifeless> wgrant: I know, but you were teasing StevenK with a solution you had.
<lifeless> wgrant: which btw is slightly cruel.
<wgrant> I hadn't revealed I had a good solution yet!
<wgrant> I was hoping to walk StevenK through optimising that query, but I had to know I was going the right direction first :)
<StevenK> I didn't think he was teasing
<StevenK> He was waiting for me to catch up
<StevenK> Admitedly, he could have landed and QA'd his solution before I got there
<wgrant> lifeless: Inlining my bugs/teams CTEs as joins gets removes the excess hashes.
<lifeless> mentoring is good
<lifeless> wgrant: /query me the new one
<StevenK> wgrant: Ah ha, so we want Joins
<wgrant> StevenK: Well, yes and no. The key is a CTE
<StevenK> Oh, so BOTH. A CTE and we join on it?
<lifeless> wgrant: interestingly I have that union *because* without it I got big dirty great hashes on bugs
<wgrant> lifeless: Interesting
<lifeless> 258ms
<wgrant> lifeless: I've run into that before, but it doesn't end up as a problem here
<wgrant> Huh
<lifeless> 15ms
<wgrant> That very query
<wgrant> Ah :)
<lifeless> 14ms
<wgrant> It's 24ms on DF
<lifeless> fwiw mine is still strictly faster :P
<wgrant> fuuuu
<wgrant> Where's the time?
<wgrant> Might be able to save a couple of ms with a slightly different TP join
<lifeless> http://paste.ubuntu.com/1274276/
<lifeless> both in one paste
<lifeless> best of the runs I just did for each.
<wgrant> Yours is actually 1.5ms slower on DF
<wgrant> Intriguing, thanks
<lifeless> inconsequential diff on teams
<wgrant> Yeah
<wgrant> I'm not sure how your union wins
<wgrant> But it does
<lifeless> directsubscribers is 3ms faster
<lifeless> unions are good
<wgrant> Right, but it should be inconsequential here
<wgrant> It's probably the extra heap scan on bug
<wgrant> Because the bitmapor needs a recheck
<wgrant> Yeah, that likely explains it
<wgrant> It's trivial in just about every case
<lifeless> it is inconsequential, its like 20% on a query with 5000% variance
<wgrant> But we are competing over trivial differences here, exactly :)
<lifeless> whose competing :)
<lifeless> <- ego.
<wgrant> Heh
<lifeless> right, time to mail silbs
<wgrant> :(
<StevenK> Indeed :-(
<wgrant> Hm
<wgrant> You might be getting away without the recheck because of your limited select list
<wgrant> Yep
<wgrant> I think
<wgrant> ... or not
<wgrant> lifeless: Your query has the heap scan when run on DF
<wgrant> Around the bug_duplicateof_idx scan
<wgrant> Same as mine...
<wgrant> And that indeed explains the extra 2ms
<lifeless> wgrant: combine both and get a win ?
<StevenK> Hah, this might mean that we can destroy self._subscriber_cache in IBug
<StevenK> If the query in getSubscribersForPerson is performant, we can just check
<lifeless> StevenK: long as you don't destroy they 'and folk unsubscribing, unassigning etc still get notified hack that that cache serves'
<StevenK> lifeless: The only use of _subscriber_cache was in another method
<StevenK> lifeless: So I don't think that cache serves that function
<StevenK> I think that cache serves that function because the query was a pig
<wgrant> StevenK: It'll be fast, but still not as fast as looking at a local cache
<wgrant> We don't want to run this query more than once a request
<StevenK> Aww
<wgrant> It's still not superfast, and probably cannot be
<wgrant> 20ms is quite a while
<wgrant> Or 14ms or whatever the latest result was
<wgrant> And, in general, you don't want to be repeating queries at all
<StevenK> Right
<StevenK> So I'll leave it alone, sadly
<StevenK> INNER JOIN is the same as LEFT JOIN, isn't it?
<wgrant> No
<wgrant> LEFT JOIN is shorthand for LEFT OUTER JOIN
<wgrant> A plain JOIN is an INNER JOIN
<StevenK> Right
<wgrant> No, a RIGHT JOIN is also an outer join :)
<StevenK> Bleh
<StevenK> Blah, lifeless' query is too simple
<wgrant> Yeah, lifeless' doesn't give you enough to get the subs/bugs back
<wgrant> Just the teams
<StevenK> And I don't understand your query either :-(
<StevenK> Right
<StevenK> Now I have a query, I need to translate it to Storm
<wgrant> You just want the bug IDs, right?
<StevenK> Which is messy since you're using the CTE as the main table in FROM
<wgrant> I forget the original query
<wgrant> Right, that is a tad awkward
<StevenK> IBug.getSubscribersForPerson() wants (Person, BugSubscription)
<wgrant> Ah, I forgot about that method
<wgrant> Let's see what it actually does
<StevenK> Populates a cache using DRS and results the results
<StevenK> returns the results even
<wgrant> StevenK: Look what it does with the the BugSubscription, though
<wgrant>         def cache_subscriber(row):
<wgrant>             subscriber, subscription = row
<wgrant>             if subscription.bug_id == self.id:
<wgrant>                 self._subscriber_cache.add(subscriber)
<wgrant>             else:
<wgrant>                 self._subscriber_dups_cache.add(subscriber)
<wgrant>             return subscriber
<wgrant> It doesn't even really care about the bug ID; it just cares about whether it's this bug or not
<StevenK> That's what the DRS does, what about IBug.getSubscribersForPerson()'s callsites?
<wgrant> StevenK: They don't get to see the subscription
<wgrant> DRS just says "return subscriber"
<wgrant> They get the person
<StevenK> Right, okay, it really wants bug.id
<wgrant> And it's somewhat inefficient to query each person out
<wgrant> It might be worth just grabbing (Person.id, Bug.id), then querying the distinct people
<wgrant> But then this leads to something interesting
<StevenK> wgrant: Why? It's always one person.
<wgrant> If you have multiple subscriptions to dupes, it will return the person many times
<wgrant> StevenK: No, it may be a team
<StevenK> Ah
<wgrant> And, in the pathological case we discovered yesterday, it will be crash-bugs-universe 400 times
<wgrant> Perhaps look at revising the callsites
<wgrant> I suspect they don't need the full functionality of this method, and it can be cut back
<StevenK> lib/lp/bugs/browser/bug.py only cares if it's empty
<wgrant> I suspect that it's the same with a lot of the others
<wgrant> But I haven't looked
<StevenK> lib/lp/bugs/browser/bugsubscription.py probably wants distinct anyway
<wgrant> I can't see much of a legitimate use for the detail
<wgrant> s
<StevenK> lib/lp/bugs/browser/bugtask.py seems to want to use it as a preload if it's the callsite I'm thinking of
<wgrant>         # This line of code keeps the view's query count down,
<wgrant>         # possibly using witchcraft.
<wgrant> Encouraging.
<wgrant> It doesn't make very much sense
<wgrant> So I'd look at the bug and delete it
<wgrant> Oh
<wgrant> The bug is actually just saying we should delete it
<wgrant> It's two years old now
<wgrant> Nuke
<wgrant> Pray
<StevenK> Destroy the function?
<StevenK> bugsubscription's use of it is ... interesting
<wgrant> Destroy the preloading callsite in browser.bugtask
<wgrant> It doesn't care about the output, at least
<StevenK> lib/lp/bugs/browser/bug.py is fine, since it doesn't care about the output either
<wgrant> Right, so browser.bugsubscription just wants distinct people
<StevenK> Right
<wgrant> Which ends up being what lifeless' thing does
<wgrant> But it may also use the extra caching side-effect
<wgrant> Which lifeless' doesn't satisfy
<StevenK> bugsubscription doesn't, no
<StevenK> Other things in model/bug want it
<StevenK> wgrant: Oh, it alreayd does distinct on Person.name, bugsubscription.person_id
<wgrant> StevenK: What does?
<wgrant> Oh, so it does
<wgrant> wtf is it trying to do
<wgrant> I assumed it was distinct on person, bugsubscription
<StevenK> wallyworld: https://code.launchpad.net/~stevenk/launchpad/destroy-old-bugactivity/+merge/129339
<StevenK> wgrant: I don't get it either
<StevenK> Given the only thing that cares about its output is a bugsubscription browser property that wants distinct people we can probably just make it sane
<wgrant> You should also track down everything that uses the cache
<wgrant> Forget what the function does today
<wgrant> Just look at what the function and cache callsites need
<StevenK> The cache callsites are all in model/bug
<StevenK> They're using the cache to work out if the person is subscribed or not and if it is this bug or one of the dupes
<StevenK> personIsDirectSubscriber uses _subscriber_cache and _unsubscribed_cache
<wgrant> Does anything care about the actual list of subscribed teams?
<wgrant> Possibly +subscribe
<wgrant> I suspect most things just care about "am I or my teams subscribed to this bug?" and "am I or my teams subscribed to any of this bug's duplicates?"
<StevenK> personIsSubscribedToDuplicate uses _subscriber_dups_cache and _unsubscribed_cache
<StevenK> That's it
<wgrant> So
<wgrant> Make a list of the function and cache callsites
<wgrant> And what they need
<wgrant> What each needs, that is
<wgrant> Then we can work out what the function has to do
<StevenK> wgrant: http://pastebin.ubuntu.com/1274325/
<wgrant> There's also the browser.bug and browser.bugtask callsites
<StevenK> browser.bugtask is gone
<wgrant> It may be gone
<wgrant> It probably is
<wgrant> But we should check if the lack of cache might confuse things
<wgrant> OK, so I agree with your assessment of those callsites
<StevenK> wgrant: http://pastebin.ubuntu.com/1274328/
<wgrant> StevenK: Right. So now we need to look at their callsites to see what's done with them
<wgrant> Messy :(
<StevenK> wgrant: The two cache callsites are easy, they're just a boolean, so the cache is entirely internal
<wgrant> StevenK: It's not quite that simple
<wgrant> StevenK: They only return a boolean, sure
<wgrant> But they take a person argument
<wgrant> wat
<wgrant> Anyway
<StevenK> Digging
<wgrant> BugSubscriptionSubscribeSelfView.shouldShowUnsubscribeFromDupesWarning calls personIsDirectSubscriber and personIsSubscribedToDuplicate
<wgrant> Indirectly, with all of the user's participated teams
<wgrant> That may in fact be the only place it's called with anyone other than the current user
<StevenK> Ah
<StevenK> wgrant: So what should we do
<wgrant> StevenK: Fix the world
<StevenK> Hah
<wgrant> Most pages probably only care if the user is subscribed
<wgrant> Somehow
<wgrant> Not whether a specific team is subscribed
<StevenK> We want to all this trouble to write a query, so let's make use of it for IBug.getSubscribersForPerson and IPersonSubscriptionInfo._getDirectAndDuplicateSubscriptions?
<wgrant> Other than like +subscribe, basically everything else probably just wants to know if there's a participated subscription for the bug, or for its dupes
<wgrant> Right, either way the reworked query is necessary there :)
<wgrant> So it may be best to work on that first
<wgrant> Now, IIRC that just wants bug.id?
<StevenK>         info = store.find(
<StevenK>             (BugSubscription, Bug, Person),
<wgrant> That's what it asks for
<wgrant> What it asks for and what it wants are often not the same thing
<StevenK> It adds the bug to a set
<StevenK> It adds the subscriber, bug and bugsubscription to another set
<wgrant> Ah, it uses it to build the annotations, right
<wgrant> Still don't know why that's there, but I guess we should preserve it
<lifeless> or nuke with prejuidice
<lifeless> WCPGW
<StevenK> lifeless: Then you deal with the fallout
<StevenK> I'd like to get this landed before EOD due to holidays
<lifeless> <sarcastic response elided>
<wgrant> Oh right, holidays
<StevenK> wgrant: Yes! And we're so damn close!
<StevenK> Which I'm in favour of just fiddling the two queries and then review/landing
<wgrant> http://paste.ubuntu.com/1274347/
<wgrant> May be a reasonably easy way to stormify it
<wgrant> You can grab BugSubscription, Bug, Person in the outer query as before
<wgrant> But all the filtering is done in the CTEs
<wgrant> I think the CTEs have to be split like that, or it'll try to optimise
<StevenK> wgrant: You assume I've done CTEs with Storm before ...
 * StevenK finds a nice example in sharingservice
<wgrant> StevenK: Grep for store.with_
<wgrant> Yeah
<wgrant> sharingservice's isn't too bad
<wgrant> There's also a good one in I forget where
<wgrant> bugsummaryrebuild is a nice example of using complex CTEs to pull complex data out
<wgrant> But we don't need that here.
<wgrant> Still, the bugsummaryrebuild stuff might be a good example
<StevenK> wgrant: How do I shoehorn the join in Select() ?
<wgrant> StevenK: You can either specify it explicitly with eg. tables=[Foo, Join(Bar, Bar.id == Foo.bar_id)], or tables=[Foo, Bar], where=(Bar.id == Foo.bar_id)
<StevenK> wgrant: http://pastebin.ubuntu.com/1274363/ and then I'm stuck
<wgrant> StevenK: http://pastebin.ubuntu.com/1274369/ might work
<wgrant> I haven't tested it
<wgrant> And it's only slightly different from yours
<wgrant> But I think it might work
<StevenK> Except for the hanging Person.id which is what I was actually asking about
<wgrant> Oh
<wgrant> Person.id == BugSubscription.personID
<wgrant> Or person_id
<wgrant> I forget if it's new or old
<wgrant> And Bug.id == BugSubscription.bugID
<StevenK> person_id
<StevenK> wgrant: So refactor the with_statement out and make use of it in model/bug?
<wgrant> StevenK: Right, probably
<wgrant> StevenK: postgres doesn't try very hard to optimise across CTEs, so they usually act as a handy optimisation barrier
<wgrant> So you can more reliably substitute them into another query and have them behave as you expect
<StevenK> Right, pyflakes is happy at least
<wgrant> And the queries work?
<wgrant> You probably also want to throw the branch at DF
<wgrant> To confirm
<StevenK> I'm even earlier than that, I'm running tests.
<wgrant> Well, if the query compiles at all then that's good enough for me
<StevenK> So far it doesn't, and I've been fixing it
<wgrant> Ah
<StevenK> TypeError: __init__() takes exactly 3 arguments (5 given)
<StevenK> Still getting that
<wgrant> From which constructor? Select()?
<StevenK>     with_statement = generate_subscription_with(bug, person)
<StevenK>   File "/home/steven/launchpad/lp-branches/no-more-o-n-queries-bug-dupes/lib/lp/bugs/model/bug.py", line 2847, in generate_subscription_with
<StevenK>     where=[TeamParticipation.personID == person.id]))
<StevenK> TypeError: __init__() takes exactly 3 arguments (5 given)
<StevenK> So ... I guess?
<wgrant> StevenK: Oh
<wgrant> You need a second With()
<StevenK> Oh, handy.
<nigelb> lifeless: are you leaving Canonical?
<wgrant> [With('foo', ...), With('bar', ...)]
<wgrant> I think
<StevenK> ProgrammingError: relation "all_bugscriptions" does not exist
<StevenK> Oh, facepalm
 * StevenK goes to wipe the egg from his face
<lifeless> nigelb: I have left as of ~2 hrs back
<lifeless> StevenK: nice typo
<wgrant> bugscriptions
<wgrant> That's new one
<wgrant> a new one
<nigelb> lifeless: oh!
<StevenK> lifeless: Oh, thanks. I try.
<nigelb> lifeless: congrats! What next? :)
<StevenK> This is what I get for rushing
<lifeless> nigelb: I start at HP Cloud Services on Monday
 * nigelb blinks
<nigelb> Nice!
<StevenK> ProgrammingError: column reference "id" is ambiguous
<StevenK> LINE 1: ...ption, Person WHERE BugSubscription.id IN (SELECT id FROM bu...
<StevenK> Haha
<StevenK> I guess that wants bugsubscription.id
<lifeless> nigelb: I hope so :)
<lifeless> nigelb: be a real PITA to go through the effort of leaving... and then have it be a bad choice :)
<nigelb> Hehe
<StevenK> You should find out by Monday afternoon :-P
<nigelb> Been there, done that :)
<spm> o/ nigelb
<nigelb> Hey spm!
<StevenK> wgrant: So now I'm getting an AssertionError from PSI.add
<wgrant> PackageSetInclusion?
<wgrant> Oh, PersonSubscriptionInfo?
<StevenK> Yeah
<wgrant> What is the assertionerror?
<StevenK>     assert principal.is_team, (principal, self.person)
<StevenK> AssertionError: (<Person at 0x122a14d0 name12 (Sample Person)>, <Person at 0x12b71c90 person-name-100517 (Person-name-100517)>)
<wgrant> Sounds liek the query might not be returning just relevant people
<StevenK> So my query is buggy :-(
<wgrant> StevenK: What is the query?
<StevenK> wgrant: http://pastebin.ubuntu.com/1274401/
<wgrant> StevenK: I'm surprised that postgres accepts it
<wgrant> "(SELECT all_bugsubscriptions" probably wants to be "(SELECT all_bugsubscriptions.id"
<wgrant> I'm not sure what it's interpreting the former as
<wgrant> But it might not be what you want
<StevenK> Heh
<StevenK> wgrant: Same AssertionError
<StevenK> With AS (SELECT all_bugsubscriptions.id FROM all_bugsubscriptions ...
<wgrant> StevenK: Oh
<wgrant> WHERE BugSubscription.id IN
<wgrant>     (SELECT bugsubscription.id
<wgrant>      FROM bugsubscriptions)
<wgrant> Spot the issue
<StevenK> Hahahaha
<StevenK> wgrant: Shall I revert the SELECT all_bugsubscriptions bit then?
<StevenK> Or that's fine too?
<wgrant> You should need both fixes
<wgrant> It even returns the same number of rows on DF
<wgrant> WIth those fixes
<StevenK> Total: 35 tests, 0 failures, 0 errors in 48.975 seconds.
<StevenK> (test_bug_views)
<wgrant> :)
<StevenK> It neatly exercised both queries, totally by accident
<wgrant> (that query is also confirmed fast on DF)
<StevenK> :-D
<StevenK> So, commit and push?
<wgrant> Might as well
<StevenK> Right, done
 * StevenK waits for the branch scanner
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/no-more-o-n-queries-bug-dupes/+merge/129355
<czajkowski> morning
<adeuring> good morning
<rick_h_> morning
<czajkowski> rick_h_: ello
* wgrant changed the topic of #launchpad-dev to: Assign me
<wgrant> blah
* wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ~260
<czajkowski> wgrant: we can assign you everything if thats what you want
<adeuring> bac, sinzui, flacoste: could one of you please review my latest attempt for the security adapter for IProduct: https://code.launchpad.net/~adeuring/launchpad/authentication-for-private-products-2/+merge/129459 ?
 * sinzui looks
<flacoste> adeuring: i'll leave someone else to actually review the code, but the explanation you give in the MP looks very good to me
<adeuring> thanks :)
<sinzui> adeuring, looks good. I think we can simplify one test. overall r=me
 * sinzui update MP with smaller test
<adeuring> sinzui: thanks
<czajkowski> sinzui: a question from potential user on commerical, I'm unsure of. in what form code is stored
<czajkowski> locally at your site -- is there any encryption ?
<sinzui> no
<czajkowski> that answers that then
<czajkowski> thank you
<abentley> gary_poster: I believe I've found a bug in Zope: http://pastebin.ubuntu.com/1275277/
<gary_poster> abentley, hi.  I'm actually mildly curious--those two particular parts of Zope are historically rock solid, with expectation bugs if anything--but I'm in crunch mode till this upcoming Tuesday's demo
<gary_poster> bugs in the expectations of the code, is what I mean
<gary_poster> I mean people expect something different than it does
<gary_poster> sigh :-)
<abentley> gary_poster: What I can tell is that the adaptation of ProductSeries to IInformationType (which returns a Product) has the side effect of changing the Checker for the Product so that Checker.set_permissions does not include 'bugtracker'.
<abentley> Even though I don't use the instance of Product that's returned.
<abentley> gary_poster: When you do have time, I've pushed the example to lp:~abentley/launchpad/adaptation-checker-insanity
<abentley> deryck, rick_h_, adeuring: Adaptation (i.e. to IInformationType) has side effects that look like a bug in Zope.  http://pastebin.ubuntu.com/1275277/
<deryck> abentley, hmm, yeah, that looks odd.
<abentley> deryck: So if you see ForbiddenAttribute, it doesn't necessarily mean that the attribute isn't exposed in configure.zcml.
<deryck> abentley, can you work around it?
<abentley> deryck: Yes.  First I'll see if using IProductUtil helps.  If not, I can just check self.product.information_type.
<abentley> s/IProductUtil/IPackagingUtil/
<deryck> ok, cool.
<gary_poster> ack abentley
<sinzui> bac, Do you have time to review a rewrite of a docttest? https://code.launchpad.net/~sinzui/launchpad/nomination-investigation-1/+merge/129489
<bac> sinzui: actually, no.  i'm trying to land two branches.  maybe later.
<bac> hi statik!
<sinzui> thanks bac
<abentley> rick_h_: When I go to change information_type for a product, I see radio buttons, not the choice widget.  And it includes choices it shouldn't (Public Security, Private Security...)
<rick_h_> abentley: heading out the door, but shoot me the info of where you see this and I'll look.
<abentley> rick_h_: https://launchpad.dev/firefox/+edit
<rick_h_> https://qastaging.launchpad.net/launchpad/+edit I see the edit, only the three options
<rick_h_> firefox a projectgroup? maybe I missed something there
<abentley> rick_h_: No, firefox is a product, same as elsewhere.
<abentley> rick_h_: If I disable JavaScript, I see the same thing on qastaging.
<abentley> deryck: If you're around, could you please review https://code.launchpad.net/~abentley/launchpad/no-proprietary-linked-products/+merge/129507 ?
<deryck> abentley, sure
<abentley> deryck: Thanks.
<deryck> abentley, np
<deryck> abentley, r=me
<abentley> deryck: Thanks.
#launchpad-dev 2012-10-13
<Kelteseth> Hiho
<Kelteseth> I have a question: Am I allowed to use Launchpad for my distro?
<Kelteseth> on my own server...
<Kelteseth> anyone?
<jelmer> hi Kelteseth
<jelmer> Kelteseth: Launchpad is licensed under the AGPL; you can set up your own instance, though you might also want to consider using the central instance so you e.g. can more easily link to bugs in other distros
#launchpad-dev 2013-10-07
<Laney> is the LoC delta policy still being operated?
<wgrant> Laney: To a reasonable extent.
<wgrant> If someone wants to add 5000 lines without taking anything away I will probably tell them to go away.
<Laney> See #launchpad earlier; I just want to expose a property on PackageUpload. Shouldn't be that big (code-wise, never sure about tets).
<wgrant> That's fine.
<wgrant> Will need a bit of extra code to preload the relevant objects to avoid timeouts, but still pretty easy.
 * Laney nods
<cjwatson> Laney: I think the PU tests are reasonably rational these days.
<cjwatson> lib/lp/soyuz/tests/test_packageupload.pyu
<cjwatson> -u
<cjwatson> Actually that wouldn't be for webservice stuff would it
<cjwatson> Oh yeah, the webservice tests are in there as well.
<cjwatson> class TestPackageUploadWebservice
<cjwatson> wgrant: I've landed everything I want in the next lp-buildd release, FWIW.  Not going to have time to QA it tonight
<cjwatson> The master side is -106 so far although without handling builder_version yet
<wgrant> cjwatson: Yeah, it should be a bit cleaner now you can avoid handing both the dict and list around.
<cjwatson> I can only assume the code that mangled it into a dict was written well after the original slave code, or else that whoever wrote it didn't know that you could pass dicts through xmlrpc.
<wgrant> It was written well after the slave code.
<cjwatson> That makes some sense at least.  If they'd been written together it would have been manifest lunacy
<wgrant> I think the dicts happened with the introduction of BFJB in 2009.
<wgrant> Because the BFJB can extend the dict with its own keys.
<cjwatson> Yeah.  Which I've destroyed.
<wgrant> (that's why it gets both the sentence and the dict)
<wgrant> Ah, good :)
<wgrant> Because it needed to die.
<wgrant> It wasn't providing any significant value and means the BFJB is involved in yet another place it shouldn't be.
<wgrant> Oh, I see you went the whole way and matched the names to the existing ones on the master side. I guess that makes sense.
<cjwatson> I figured why not.
<wgrant> Yeah
<cjwatson> Otherwise I have to have a totally pointless thing that renames them.
<wgrant> builder_status is probably sufficiently clearer that it makes sense.
<wgrant> Yep
<wgrant> cjwatson: I haven't noticed any other regressions. Have you seen any?
<cjwatson> From 116/117?  No
<wgrant> Great.
<cjwatson> The depwait one has the amusing effect of turning things into upload failures
<wgrant> Yes
<cjwatson> But that was obvious once I looked at it
<wgrant> That's how I first noticed it.
<cjwatson> I got Alexander to land my builddfitzer change and he said he'd include a reminder to update local checkouts in his report, so hopefully other webops will use it
<wgrant> Yep, saw that.
<wgrant> Thanks.
<cjwatson> But it might be worth watching out for cases where builders appear to have been reset rather than rebuilt
#launchpad-dev 2013-10-08
<cjwatson> wgrant: I'd like to add a version column to builder.  Is 2209-50-0 a reasonable patch number to claim?
<lifeless> wgrant: please delete the mailing list from ~tuskar and merge it into ~tripleo
<lifeless> wgrant: I have confirmed it was never really used
<wgrant> cjwatson: Sure
<wgrant> lifeless: It'll purge all the members from the old team, so you'll need to readd them to the new one.
<lifeless> wgrant: already done
<lifeless> wgrant: if by old team you mean ~tuskar
<wgrant> lifeless: Yes. Merge queued.
#launchpad-dev 2013-10-09
<cjwatson> wgrant: Is it deliberate that we typically scan building slaves twice per cycle?  Once in rescueIfLost and once in updateBuild.
<cjwatson> Perhaps that should be hoisted up to SlaveScanner.scan.
<wgrant> cjwatson: Not deliberate, as such, just not avoided.
<wgrant> It should indeed.
<cjwatson> Gets more noticeable when we may need to update the master's record of the slave version.
#launchpad-dev 2013-10-11
<cjwatson> wgrant: http://lpbuildbot.canonical.com/builders/lucid_lp_lxc/builds/908/steps/shell_9/logs/summary - two spurious failures, I think, but do we need to get python-lpbuildd manually upgraded on the buildbot slaves?
<wgrant> cjwatson: I would have expected that to happen automatically. It did for the ABORTED change, AFAICR.
<cjwatson> Maybe we got lucky and crossed a napalm run.
<wgrant> Except a napalm won't have entered the LXC container.
<cjwatson> I'll ask an op
<wgrant> Nothing seems to upgrade it regularly AFAICT.
<cjwatson> Maybe the tests against the live slave just don't test ABORTED
<cjwatson> Doesn't look to me like they do
#launchpad-dev 2015-10-05
<wgrant> cjwatson: I could randomise the sequences on DB setup, but few enough tests were affected that I don't think it's going to be a huge problem.
 * cjwatson nods
<wgrant> cjwatson: So close.
<wgrant> In the most obvious test, too :P
<cjwatson> Grr.  I ran all the tests but must have been a little out of date.
<blr> morning
<blr> wgrant: made that wee change to launchpad-buildd when you have a moment. https://code.launchpad.net/~blr/launchpad-buildd/snap_http_proxy/+merge/273355
<wgrant> blr: Your os.environ set is bad.
<wgrant> And did you manage to confirm the approach with Martin?
<blr> wgrant: no he hasn't responded yet.
<blr> wgrant: at the snappy sprint presumably
<blr> I'll try pinging him again
<wgrant> cjwatson: Huh, no idea how that test slipped through, sorry. I ran the entire test suite with all the sequences set to strange values...
<wgrant> I wonder if I missed a case in the fixture, will rerun.
<cjwatson> wgrant: I think it must depend on the BPPH sequence starting just the right amount offset from the SPPH sequence
<cjwatson> Probably should just test that it doesn't get a thing of the wrong type back, rather than specifically None
<blr> wgrant: ah, env=os.environ in _reactor.spawnProcess
<wgrant> blr: More that you're setting the http_proxy environment variable to "http_proxy=[...]"
<blr> ah, so I am... >.<
<wgrant> cjwatson: Yeah, will fix.
<wgrant> And try to come up with a more diabolical sequence breaking strategy.
<blr> wgrant: updating startBuild in the buildd snap test, however can't find the 'apt
<blr> ' module
<blr> and there's no setup.py or dependency manifest afaict
<blr> is that python-apt?
<cjwatson> Yes
<blr> thanks cjwatson
<wgrant> blr: You are meant to run the buildd tests under LP's bin/py, IIRC.
<wgrant> But the snap ones may work without that.
<cjwatson> It's in the package dependencies ... and yes, what wgrant says
<blr> ah, didn't realise that was possible.
<cjwatson> There's a comment in the Makefile about it
<cjwatson> It's a bit awkward because they don't necessarily always end up being in version sync, but txfixtures isn't packaged IIRC
#launchpad-dev 2015-10-06
<wgrant> Ohh, whoops.
<wgrant> I didn't mangle sequences for empty tables.
<wgrant> That explains the recipe failure earlier, too.
<wgrant> And the SPPH/BPPH one was just a silly test.
<wgrant> Running the full suite with empty tables mangled too.
<wgrant> Last test run is 7000 tests short.
<wgrant> Just an unfortunate test_disconnectionerror_view_integration, I think.
<wgrant> I'm pleasantly surprised at the lack of DB connection fallout.
<wgrant> cjwatson: TestBranchView.test_query_count_index_with_subscribers is breaking the subunit stream, I think.
<wgrant> I imagine an extra count query appeared or something.
<cjwatson> Yeah, probably due to the +recipes change
<cjwatson> I thought something like that might happen but it didn't seem worth contortions to fix
<wgrant> Agreed.
<cjwatson> I'll fix
<cjwatson> It's annoying that Storm doesn't cache that, since I believe it's on the same ResultSet object.
<wgrant> Storm's only cache is PK -> object.
<cjwatson> Yes.  Still annoying :-)
<cjwatson> Oh, we actually gained a query somewhere.
<cjwatson> I mean, one fewer query than before.
<wgrant> Oh.
<wgrant> That's... unusual.
<wgrant> Possibly there was previously a LIMIT 1 in a tal:condition, and a COUNT(*) in the tal:content?
<cjwatson> Two evaluations of view/context/recipes/count in TAL, I believe.
<cjwatson> <tal:no-recipes/> followed by <tal:recipes/> because TAL lacks else
<blr> morning
#launchpad-dev 2015-10-07
<blr> morning
<wgrant> Morning.
#launchpad-dev 2015-10-08
<cjwatson> wgrant: buildbot failure is yours rather than mine, I believe
<wgrant> Bah
<wgrant> Dodgy import.
<cjwatson> wgrant: The unauthenticated-modifying-BMP thing seems to happen in various zopeless situations, judging from the test suite, and lp.code.subscribers.branchmergeproposal already had a similar check.  Do you want me to track down the exact causes of that and try to remove those guards?
<wgrant> cjwatson: Sounds reasonable enough, feel free to leave it.
<cjwatson> I'm not sure of the difference between user is None and isinstance(user, UnauthenticatedPrincipal).
<wgrant> Indeed, I was surprised it was UnauthenticatedPrincipal rather than None.
<cjwatson> It might only be in the test suite, due to login(ANONYMOUS) in TestCaseWithFactory.setUp.
<wgrant> Does it rSP, or does it really login() in Zopeless?
<wgrant> Or fire the events directly?
<cjwatson> lazr.lifecycle does queryInteraction to get the user if you don't pass it one directly
<cjwatson> And TCWF.setUp login()s regardless of layer
<cjwatson> The event dispatch is just something like notify(ObjectModifiedEvent(proposal, snapshot, [])), no rSP involved
<wgrant> Right, so it fires it directly.
<wgrant> Anonymous code couldn't usually modify an MP to cause an event.
<cjwatson> Oh, sorry, you mean the point where it enters MP editing.  In the cases I'm looking at it's just Zopeless, so things like merge detection.
<cjwatson> Which does notify_modified(proposal, proposal.markAsMerged, merge_revno)
<mpt> wgrant, hi, is there a current graph of your progress with Critical LP bugs over time? I remember there was one a couple of years ago, but no idea where it was
<wgrant> mpt: http://webnumbr.com/launchpad-critical-bugs
<mpt> brilliant, thanks
<cjwatson> mutter non-zero-based axis
<wgrant> https://lpstats.canonical.com/graphs/LPProjectCriticalBurndown/20101208/20151009/
<StevenK> It has remained remarkably constant
<wgrant> Most of the remaining bugs are pretty boring.
<wgrant> There are one or two timeouts that occur more than a dozen times a day.
<wgrant> New ones crop up and we slay them.
<cjwatson> I'm a little surprised the timeout chunk didn't drop more with the new DB servers.  Maybe some of those never show up in practice any more.
<wgrant> Most that were slow for DB reasons (other than perhaps bug edits) were death by a thousand queries or absolutely terrible queries.
<wgrant> Not just a few bad queries.
 * cjwatson runs into the tension between writing "... for which this ... builds" because that way people won't make bogus Victorian grammar complaints, or writing "... that this ... builds for" because the grammar is fictional but getting complaints anyway
<wgrant> We've classically used the former, but the latter I have no problem with.
<blr> morning
#launchpad-dev 2015-10-09
<cjwatson> wgrant: I think I've got the webhook privacy code we discussed written, and I'm trying to write tests for negative cases, starting with the situation you suggested where the owner of a branch in a private project leaves the team granting them access to that private project and thus no longer has access to view a branch they own.  I can't quite get the test to work, though, because the owner of a branch always has an artifact grant ...
<cjwatson> ... which doesn't appear to be removed by their leaving the team.  Could you explain how this is meant to work?
<cjwatson> (the owner of a non-public branch, that is)
<wgrant> cjwatson: The owner doesn't have an artifact grant if the artifact grant is revoked.
<wgrant> Nor should they have an AAG by default if they already have an APG, though I believe there is a bug or two which can erroneously result in an AAG in some cases.
<cjwatson> I think the only thing that would naturally revoke the owner's artifact grant would be unsubscribing from the branch.
<wgrant> Or direct revocation.
<cjwatson> which is done by the sharing job, but it only does that if there isn't an artifact grant.
<cjwatson> right, or I could do that in the test, I suppose.
<wgrant> Right, the normal situation is direct revocation from +sharing.
<cjwatson> So that's certainly a good point about having an AAG by default - I wonder why that exists in my case
<wgrant> If you can reproduce it, then that is good.
<cjwatson> I may have done a stupid thing, since I get a bit lost in the disclosure code.
<wgrant> The code is somewhat convoluted, but the concepts are relatively simple.
<cjwatson> Do I need to commit after creating the project/team/branch to get Branch.access_{policy,grants} up to date or something?
<cjwatson> I thought the triggers happened immediately after the INSERT statement and before any subsequent statement
<wgrant> Indeed, a flush is sufficient.
<wgrant> It is not just security adapter caching?
<cjwatson> getVisibleArtifacts should bypass all that, shouldn't it?
<cjwatson> I'm not explicitly flushing here
<wgrant> It should indeed.
<wgrant> Have you reviewed the queries and the database state?
<wgrant> -D and psql are handy
<wgrant> And LP_DEBUG_SQL=1
<wgrant> (do remember to commit before psqling, though)
<cjwatson> Yeah I'm trawling through LP_DEBUG_SQL_EXTRA=1 now
<wgrant> _EXTRA? My condolences.
<cjwatson> I think possibly there is no AccessPolicyArtifact created before the point where getVisibleArtifacts is called
<wgrant> Oh, during branch creation?
<wgrant> That is a possibility.
<cjwatson> Yes
<wgrant> Ah
<wgrant> Because _reconcileAccess is called only after subscribe, perhaps.
<wgrant> Is the getVisibleArtifacts call within subscribe?
<wgrant> It has been some years since I reviewed this code.
<cjwatson> Right, it is.  I think BranchNamespace.createBranch is calling those in the wrong order
<wgrant> I can't think why that would be.
<cjwatson> So the APA is only created after subscribing the owner, which means that the initial subscription of the owner always thinks that the owner doesn't have a policy grant and therefore creates an artifact grant.
<cjwatson> Reversing those makes my test work.
<wgrant> I don't quite recall the history here.
<wgrant> But I probably wrote that code.
<wgrant> I don't remember whether that might have been because it was syncing subscribers and AAGs during the migration.
<wgrant> So it was important that it was after subscribe.
<cjwatson> r15357 seems to be where this was introduced, and doesn't appear to have any evidence of this.  It's structurally more or less the same as today.
<wgrant> I don't have the code in front of me, will investigate in a bit.
<wgrant> But it sounds reasonable.
<cjwatson> But branches weren't the first artifact to be managed this way; maybe bugs had something like that previously.
<cjwatson> Do bugs need a similar fix?  APA creation comes after subscribing the owner in that case too.
<cjwatson> Blueprints don't have the same problem.
<wgrant> Hm.
<wgrant> What creates the AA?
<wgrant> Is it automatically created when subscribe() goes to create the AAG?
<cjwatson> Both reconcile_access_for_artifact and SharingService.ensureAccessGrants do getUtility(IAccessArtifactSource).ensure(artifacts)
<cjwatson> Branch.subscribe calls SharingService.ensureAccessGrants
<wgrant> Right.
<wgrant> from experience I don't think bugs have the same problem.
<wgrant> but they may accidentally get around it due to tasks
<wgrant> createBug likely calls createTask, possibly before subscribe
<cjwatson> It does
<wgrant> and createTask is likely to _reconcileAccess or equivalent
<cjwatson> Aha, yes, I hadn't noticed that
<wgrant> whoever duplicated that for bugs may well have just done it exactly the same way
<wgrant> er branches, not bugs
<wgrant> and it just happened to work for bugs due to the way target setting works
<cjwatson> Would still be better to be explicit rather than having a basically useless and misleading _reconcileAccess at the end of bug creation
<wgrant> createTask must be before subscribe for notifications to work
<wgrant> so that would explain it
<cjwatson> It is
<cjwatson> I think I'll delete the explicit bug._reconcileAccess from BugSet.createBug and leave a comment
<cjwatson> Because it's really more about the bug task since that's the thing that's setting up the association with the pillar
<wgrant> as long as there's no opportunity for privacy/target changes between createTask and _reconcileAccess, and createTask really calls fullblown _reconcileAccess, that sounds fine
<cjwatson> it's createTask, subscribe, assignee, importance, milestone, _reconcileAccess; so no
<wgrant> yay
<cjwatson> and yes, removeSecurityProxy(bug)._reconcileAccess() at the end of BugTaskSet.createManyTasks, which does most of the work for createTask
<wgrant> ugh, that's right
<wgrant> sorry, was roughly on the right track at least
 * cjwatson kicks off a test run for -t bugs -t code and goes out to run errands
<cjwatson> I'll work out specific tests once I've ensured it doesn't blow up the world
<wgrant> tests are good!
<cjwatson> thanks for the help figuring this out
<cjwatson> (it was making no sense whatsoever yesterday evening, and no wonder ...)
<cjwatson> I wonder if we need a way to find all the incorrect AAGs. :-(
<wgrant> glad my vague recollections led you down the right path!
<wgrant> they're not incorrect, just excess.
<cjwatson> well, they mean that people retain access after leaving the team that grants them access
<cjwatson> so at least some of them are incorrect
<wgrant> ish
<wgrant> when you're kicking someone out of a project you should be checking +sharing anyway
<wgrant> for Canonical employees that's all handled automatically by the leaver process
<cjwatson> I guess they have an explicit subscription too
<wgrant> the main intent of not creating an AAG was to avoid polluting +sharing
<wgrant> rather than automatic revocation
<cjwatson> ok
<cjwatson> I won't panic about it then
<wgrant> anyway, hopefully the test suite will be happy
<wgrant> Have a good weekend!
<cjwatson> you too
#launchpad-dev 2015-10-11
<blr> morning
<wgrant> Morning.
<blr> hey wgrant, how was your weekend?
<wgrant> Pretty good, you?
<blr> far too busy!
<blr> wgrant: mojo run this morning https://pastebin.canonical.com/141563/
<wgrant> blr: That'll be the dodgy python SRU from last week.
<wgrant> blr: Remove that container and LXC's cache, and then try again.
<wgrant> Python 3.4.3 was SRUed to trusty then backed out.
<blr> ah, I refreshed the container this morning, but didn't dump the cache
<wgrant> https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1500768
<mup> Bug #1500768: python3.4.3 SRU break requests <regression-update> <trusty> <python3.4 (Ubuntu):Invalid> <python3.4 (Ubuntu Trusty):Triaged by doko> <https://launchpad.net/bugs/1500768>
<blr> wgrant: thanks
<wgrant> blr: Mojo happy again?
<blr> wgrant: appears to be yep, thanks.
#launchpad-dev 2016-10-11
<mkayaalp> Where can I find the scripts that build the chroots that are used for the buildd?
<mkayaalp> The chroots I build with debootstrap are slightly different than the ones downloaded with "ubuntu-archive-tools/manage-chroot get"
