#launchpad-dev 2009-01-26
<mok0> bigjools: you found our priorities?
<bigjools> mok0: yes I did, thank you for doing those
<mok0> OK, just wanted to check!
<mok0> bigjools: we just left the "dont-care" ones blank
<bigjools> mok0: yep, that's fine.  Only the top 10 are really relevant anyway
<mok0> alright, good to know
#launchpad-dev 2010-02-01
 * mwhudson lunches
<mwhudson> (not that there's anyone here to care)
 * ajmitch cares
<ajmitch> mostly because I have my lunch here with me :)
<lifeless> thumper: ping
<lifeless> thumper: re bug https://bugs.edge.launchpad.net/launchpad-code/+bug/411357 - is there an API's equivalent to +activereviews. e.g. see https://code.edge.launchpad.net/~ubuntu-main-sponsors/+activereviews which has useful content
<MTecknology> wow - you guys have a lot of builder machines
<lifeless> some of the time
<beuno> gooood morning
<al-maisan> Good morning beuno :)
<wgrant> If only Launchpad had some easy way to turn a branch into a source package -- these release instructions would be so much easier.
<al-maisan> wgrant: ha ha :)
<noodles775> hi wgrant - on that note, if you have time, please go through https://dev.launchpad.net/BuildBranchToArchiveUI and see if you've any thoughts or ideas or corrections etc. I'm planning to send out a RFC/Input sometime in the next few days.
<noodles775> Especially the "Questions still requiring thought" section :)
<wgrant> noodles775: I think there'll need to be a new (set of?) tables for scheduled builds.
<wgrant> Since I might want to build this recipe whenever the tip changes.
<wgrant> Somebody else might want to build only releases of this same recipe.
<wgrant> So storing it on the SPRecipe probably won't work well.
<noodles775> yeah, I don't think the current schema even supports daily builds properly (see the third question still requiring thought).
<noodles775> So your suggestion would be a good general solution.
<wgrant> noodles775: Regarding the first and second points, the changelog in the packaging branch is irrelevant. bzr-builder concocts a new changelog entry with the information given to it by the master. That data is stored in the SPRB when it is created.
<wgrant> (you must currently specify it when the build is requested)
<noodles775> hrm
<noodles775> <jml> noodles775, in case you missed it on #bzr, bzr-builder gets it from the changelog.
 * wgrant checks the code.
<wgrant> We definitely pass the suite all the way through.
<noodles775> OK, that would make things easier - so the user specifies it, we set it on the build and it's passed through to bzr-builder? I'll have to digg a bit deeper.
<noodles775> Great. Thanks.
<wgrant> The package name too.
<noodles775> But that's the question there, where do *we* specify the package name? A branch (or packaging branch) doesn't necessarily link to a source package name?
<wgrant> A packaging branch does.
<noodles775> But it really should be linked somehow to the packaging branch (as it is for actual distro...) oh?
<wgrant> noodles775: SPRecipe already has distroseries and sourcepackagename columns.
<noodles775> wgrant: yeah, I know, the question was more, "when do we fill them in, and where does the info come from?"
<wgrant> noodles775: One probably creates a recipe at a URL like /ubuntu/lucid/+source/dpkg/+new-recipe
<noodles775> Yeah, that's fine for a distroseries source package... but what about for my personal branch foo with my personal packaging branch bar, that I want to build into my ppa?
<wgrant> That's where package branches fall down.
<noodles775> (or maybe I'm trying to generalise it too far?)
<noodles775> Oh, ok.
<wgrant> That is a general hole in Launchpad's model.
<noodles775> Yeah, hence the question there. I think we need to resolve it, as we need to be able to build general branches.
<wgrant> The current solution is to have unofficial branches under the Ubuntu namespace.
<wgrant> That probably makes a bit of sense.
<wgrant> And since recipes are namespaced by owner, there's little-to-no problem keeping them all under Ubuntu.
<wgrant> It's reasonably correct -- they are branches of the Ubuntu package.
<wgrant> (the bigger problem is that Ubuntu branches are branches of Debian branches, which are branches of the upstream project. Yet all these branches are kept in independent spaces. But that's not terribly important here)
<noodles775> OK, so that would mean that when I select my packaging branch, it is automatically implying the distroseries.
<wgrant> Well, a packaging branch needn't really be distroseries-specific.
<noodles775> s/packaging branch/recipe
<wgrant> Although they must for now live in one.
<wgrant> Yes.
<wgrant> A recipe has a distroseries.
<wgrant> (this is too complicated and messy and aaarrggh)
<noodles775> But here's the problem - when I am *creating* the recipe to build a branch...
<noodles775> +1
<wgrant> You always create a recipe from a view or method on a SourcePackage.
<noodles775> Yes, that may be necessary then - I was hoping the process of recipe creation could be done while requesting the build (ie. in a single step) as outlined in the ui mockups.
<wgrant> Hmmmm, true. That is unfortunate.
 * wgrant looks at the mockups.
<wgrant> We can probably infer the SPN from project<->package links. But I cannot see a sane way around asking for the distroseries.
<wgrant> That's probably something that you *always* want to ask for anyway.
 * wgrant grabs Balsamiq.
<noodles775> Thanks!
<wgrant> Hrm hrm hrm.
<noodles775> yarp.
<wgrant> I guess that in a lot of cases the recipes will be identical between multiple series.
<noodles775> Huh? Won't they require different packaging branches? (if the packaging branches are distroseries specificy)
<noodles775> (ie. different merge directives)
<wgrant> If they are, yes.
<wgrant> It seems really awkward to ask for a distroseries which is probably redundant with information on the package branch, but I cannot think of a way around it.
<noodles775> Yeah, and what if the information conflicts?
<noodles775> Could we require something like the ISeriesSourcePackageBranch to be defined for personal branches also?
<wgrant> I don't think that makes sense.
<wgrant> The case here is that I want to build this non-distroseries-specific project branch. I might not even own that branch. It shouldn't need any magic on that branch.
<wgrant> We shouldn't complain if the series conflict. If it works, it will work. If it doesn't, it will fail to build.
<wgrant> Restrictions like that are more likely to be inconvenient than anything else, I think.
<noodles775> Yep, it'd just be strange to say "you said this was for karmic but then your source package branch was for lucid".
<noodles775> OK, true.
<wgrant> I might be doing that because I'm (quite feasibly) reusing the hardy packaging branch all the way up to lucid.
<wgrant> I do that.
<noodles775> In which case it shouldn't fail, but give priority to the recipe distroseries right?
<wgrant> I don't think we should look into the recipe data at all.
<wgrant> So yes, the one the user specifies explicitly wins.
<wgrant> Because we might have multiple package branches, or none.
<mwhudson> <wgrant> (this is too complicated and messy and aaarrggh)
<mwhudson> that seems to describe the problem domain well enough
<mwhudson> bigjools, noodles775: good morning
<noodles775> Hi mwhudson
<wgrant> Evening mwhudson, morning bigjools.
<bigjools> hello
<bigjools> not here for long, in a meeting
<wgrant> Windows Me!
<noodles775> lol
<mrevell> Morning
 * wgrant mourns the 12 i386 builders that have vanished in the last few hours.
<al-maisan> wgrant: what do you mean? How did they vanish?
<wgrant> al-maisan: There were 19 earlier. There are 7 now. I presume Enablement stole them back for a while.
<wgrant> (fortunately the queue isn't too huge yet)
<al-maisan> ah, I see.
* henninge changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 0 of 10.02 | PQM is open | gary_poster is release manager | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http:/
<asabil> Hi all
<adiroiban> jtv, henninge Hi, I'm looking at bug 512307, and rather than filter âmergedâ contributors in the view, would not it be recommended to filter them in the âsourceâ POFile.contributors ? In doing so, in the view we would just display them.
<adiroiban> are there any place in LP where we would like to manage translations of merged accounts ?
<jtv> adiroiban: did my reply just now get through?  having trouble with irc spam protection I guess
<adiroiban> jtv: nope
<jtv> ah.  First of all, I said hi.  :)
<jtv> Second: it does sound sensible to me to do this further down, like you suggest.
<jtv> In fact, I'm not sure mere filtering is quite right; why not display the target account instead?
<adiroiban> jtv: because there is a list of top 20 contributors
<adiroiban> and displaing the target will create duplicate entries
<adiroiban> I will filter in the view then
<jtv> Yes of course you need to filter _as well_, but _mere_ filtering has the weird effect of leaving out contributors.
<adiroiban> I was thinking that merging two accounts will also transfer all the contribution to the new one
<jtv> That's exactly what I mean.
<asabil> Did anyone think about using bzr-externals with the launchpad code ?
<asabil> for managing the download-cache and sourcecode ?
<wgrant> noodles775/al-maisan: Can you guys see germanium's publisher logs?
<noodles775> I just tried to check, but can't ssh in at the moment, can you al-maisan ?
<al-maisan> wgrant: I am not sure, let me see whether they are replicated on devpad
<al-maisan> noodles775: cannot ssh into devpad either
<wgrant> The source and binary files in question are on disk, the binaries are listed in Packages, but the sources are not in Sources, and the source publishing statuses haven't been set.
<wgrant> One special thing of note: the Lucid source is 3.0 (quilt), and shares its orig.tar.gz with the 1.0 sources from earlier series, that also remain unpublished.
<al-maisan> wgrant: hmm .. maybe the publisher died before finishing its run properly
<wgrant> al-maisan: But that would mean it would just try again on its next round.
<wgrant> And there should have been quite a few since.
<al-maisan> wgrant: good point. I am trying to get access to the logs and see what can be gleaned from these.
<wgrant> al-maisan: Thanks.
<al-maisan> wgrant: it appears the files to be published already existed on disk but the check sums did not match (see, lib/lp/archivepublisher/diskpool.py|188|)
<wgrant> al-maisan: Argh. I checked that the sizes were all OK, but didn't bother with the checksums.
<wgrant> al-maisan: It's the orig.tar.gz, isn't it?
<wgrant> How was that copy not rejected, I wonde.r..
 * al-maisan looks at the log again
<wgrant> Yeah, that copy should have been rejected.
<al-maisan> the copy logic probably does not look at the check sums
<wgrant> I thought it did.
 * wgrant looks.
<wgrant> Well, it appears not to.
<wgrant> I'd always assumed it did :/
<al-maisan> wgrant: would you like to file the bug .. or should I?
 * wgrant will.
<al-maisan> wgrant: thank you
<wgrant> Bug #387049
<al-maisan> oh wow! There was a bug already?
<wgrant> Now, how to fix the PPA... deleting the two old publications should resolve the situation once processdeathrow runs. But that seems evil.
<wgrant> Yes, there was.
<wgrant> No bot?
<al-maisan> nope
<al-maisan> "Copy backend does not detect file conflicts", https://bugs.edge.launchpad.net/soyuz/+bug/387049
<al-maisan> wgrant: thanks for digging that bug out!
<wgrant> al-maisan: Thanks for fighting devpad for me.
<al-maisan> well, for us :)
<henninge> Does anybody know where I should find the "ec2-register" command?
<henninge> Is that one of our tools or something from Amazon?
<wgrant> henninge: It's part of the 'ec2-api-tools' package.
<henninge> wgrant: cheers!
<adiroiban> any idea how to get around the ForbiddenAttribute: ('__len__', <storm.sqlobject.SQLObjectResultSet error. Here is my code: http://paste.ubuntu.com/366780/
<wgrant> adiroiban: You should use .count() instead.
<wgrant> Oh, you're not calling it explicitly. I seeeee.
<adiroiban> I guess I have to convert it to a "plain" array ?
<salgado> adiroiban, you have to generate a list out of self.context.translators before you can reverse() it
<adiroiban> salgado: ok. thanks!
<salgado> adiroiban, but that might not be a good idea if context.translators can return an arbitrary number of items -- it might cause timeouts
<adiroiban> then just use for statement
<adiroiban> iterating using the index ?
<salgado> adiroiban, no, in that case it's best to create a new method on the content class which returns the items in the order you want.  or extend the existing one to let you specify the sort order
<adiroiban> well, the current one is a property
<salgado> it can be turned into a method easily
<adiroiban> thanks. I will try this way
<asabil> Did anyone think about using bzr-externals with the launchpad code ?
<adiroiban> salgado: any hints regarding turning a property into a method ? The property is also used as a schame.Field
<salgado> adiroiban, I'm not following you
<adiroiban> you said that is easy to turn a property into a method, but I don't know what is the easy way
<salgado> adiroiban, you just need to remove the decorator (@property), add the extra arguments you want and update callsites
<adiroiban> thanks! and how I change the interface, as the property is defined in the interface using Field(required=true)
* bac changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 0 of 10.02 | PQM is open | gary_poster is release manager | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu.com/
<noodles775> Hi james_w
<noodles775> In your email about the 'trigger' for the buildfrombranch work, were you talking about this branch, or something else:
<noodles775> https://code.edge.launchpad.net/~abentley/launchpad/build-recipe
<noodles775> (it's approved but not landed - so I wasn't sure if you and abentley had found more work required there).
<thekorn> hi, who is the best person to guide my through the process of fixing bug 282178 ?
<thekorn> hmm, no bot, https://bugs.edge.launchpad.net/malone/+bug/282178
<thekorn> intellectronica, ^^ you maybe, since you put some hints in the title
<EdwinGrubbs> mars: ping
<mars> hi EdwinGrubbs, want to have that pre-implementation call?
<EdwinGrubbs> mars: yes
<EdwinGrubbs> mars: skype?
<mars> EdwinGrubbs, yes, just a minute
<bac> intellectronica: and here?
<intellectronica> 1 2 3 test
<bac> intellectronica: but i guess we have the larger problem with unregistered users.
<intellectronica> yeah :-/
<rockstar> Morning
<intellectronica> morning, rockstar
<rockstar> bac, we shouldn't need voice, just be identified by Freenode.
<bac> rockstar: i have no idea what i'm doing.  just discovered that worked to get intellectronica back
<intellectronica> i was muted, i guess i'm not registered
<bac> intellectronica: i think all unidentified users are muted
<intellectronica> but we do want unregsitered users to be able to talk in these channels
<rockstar> intellectronica, I think the answer is yes, until we have a problem with it.
<rockstar> bac, try /mode -q $~a
<rockstar> Then take away intellectronica's voice.
<intellectronica> rockstar: plotting against me again? o_O
<rockstar> intellectronica, now talk!
<intellectronica> 1 2 3 test
<rockstar> :)
<intellectronica> cool, that worked! :)
<rockstar> bac, I think we may need to do that in all our channels.
<bac> rockstar: just did #launchpad
<bac> rockstar: there seems to be another problem with #launchpad-reviews as it is unregistered
<bac> rockstar: i cannot become an op in there
<rockstar> bac, cool.  It doesn't look like you have op in launchpad-meeting either.
<bac> rockstar: didn't try
<asabil> are there any plans to make/help making lp easy to deploy on private servers ?
<maxb> Canonical seems to be rather staunchly against that
<asabil> maxb, I am aware of that fact, but are there any people interested in making it happen ?
<maxb> I'd love it to happen, but I don't really have any time to lend to such an effort for the forseeable future.
<asabil> maxb, if you can provide directions, I can work on it
<james_w> noodles775_: no, the trigger was the next task we took on, hoping to provide an API call to trigger a recipe build
<noodles775_> ok, thanks james_w
<bac> abentley: do you know about https://launchpad.net/people ?
<bac> abentley: i point it out based on your CHR handover email
<abentley> bac, no, I didn't.
<abentley> bac, where should I have looked for it?
<bac> abentley: it appears a link to that page got dropped from the front page when we went to UI3.0
<abentley> I'm glad it's just a navigation issue, not a missing feature.
<kfogel> beuno: is http://paste.ubuntu.com/366934/ the right way to incorporate your suggestions to add an "order by: " label (along with getting rid of the word "by" in the selection items)?
<kfogel> allenap: (see my above question to beuno; you might know the answer, as this is an easy one)
<allenap> kfogel: I don't know that one, sorry :-/
<kfogel> allenap: np
<beuno> kfogel, looks like it, yes
<kfogel> beuno: thanks
<kfogel> intellectronica: in your comments on https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report/+merge/18181, I didn't quite understand one of them:
<kfogel> "Why do you need to read from the request directly? If there's a zope form
<kfogel> covering this, you can get the value from self.request.form. If there isn't a
<kfogel> form then maybe we should consider having one, since it gives us validation
<kfogel> "for free" (here it seems there's no validation at all).
<kfogel> "
<kfogel> intellectronica: not quite sure what you meant by "a zope form covering this".
<intellectronica> what i meant is that you are reading parameters from the reply, but usually we use zope's form machinery, which renders the form using the definition of an interface, renders the form, validates the input (reloading the page with an error message) and finally collects the correct values in self.request.form
<intellectronica> if you're not going to use this because it's overkill, then i guess at least you need to make sure it's safe
 * kfogel reads carefully
<kfogel> intellectronica: I'm not sure how to judge whether it's overkill or not.  This is just the "orderby" dropdown selector on the patches view list.  What's a good example of how to use Zope's form-processing machinery to do this instead?
<intellectronica> kfogel: hmmmm ... maybe it's overkill given the time available. ideally this should be a zope form backed by an enum with all the options
<kfogel> intellectronica: I grok what you're saying about validation.  Is the idea that, if we don't use Zope's way of doing this, then I will have to violate DRY because I'll have to repeat the valid values in the code, in order to validate them?
<intellectronica> so i'd say for now let's just make sure the input is safe and valid, and file a bug (and an XXX?) for the rest of the work
<kfogel> intellectronica: I don't mind leaving an XXX, given the time constraints.
<kfogel> intellectronica: I'll show you a diff hunk in a moment, just to make sure I'm on the right track.
<intellectronica> cool
<bac> abentley: https://bugs.edge.launchpad.net/launchpad-registry/+bug/504633
<mup> Bug #504633: add a link to /people page from / page <Launchpad Registry:Triaged> <https://launchpad.net/bugs/504633>
<abentley> bac, thx.
<intellectronica> kfogel: and exactly about how using an enum and a form for both the ui and validation will save us from repeating ourselves
<kfogel> intellectronica: http://paste.ubuntu.com/366945/  (you'll see some other stuff in there, also due to your review, but the top of the hunk is what matters right now)
<kfogel> intellectronica: I'll put the XXX in there too, of course
<intellectronica> kfogel: cool
<kfogel> intellectronica: is there a special tag or summary marker we use for XXX bugs, btw?
<intellectronica> kfogel: tech-debt?
<intellectronica> maybe i'm inventing it, don't know
<kfogel> intellectronica: I'll check, thx.
<kfogel> intellectronica: https://bugs.edge.launchpad.net/malone/+bug/515584
<mup> Bug #515584: BugsPatchesView:batchedPatchTasks() should use a Zope form, instead of validating form values manually <Launchpad Bugs:Confirmed for kfogel> <https://launchpad.net/bugs/515584>
<intellectronica> cool
<didrocks> hey
<didrocks> I try to create a serie with Launchpadlib (not a milestone, nor a release, but a serie), but I can't find if the function is exposed. Any idea?
<maxb> There doesn't appear to be a relevant method on project at edge/+apidoc, so I would say no
<didrocks> maxb: ok, thanks, maybe I should ping jml on that, I don't want to do screenscraping for Quickly :)
<kfogel> intellectronica: any hints for example code on how to get the bug icons to color along with importance?  (right now, the bug images stay grey, which is wrong of course)
<kfogel> intellectronica: I'm starting at lib/lp/bugs/templates/buglisting-default.pt, but the code to do it apparently isn't in there.
<kfogel> adeuring: I'm going to ping Jorge soon and give him an update.  How's the patch-age sorting progress?
<intellectronica> kfogel: iirc you need to set their css class using something that contains the importance value. don't remember exactly, but will try to find an example now
<adeuring> kfogel: slowly :( I'm still fighting with Storm...
<kfogel> adeuring: ugh, sorry.
<kfogel> intellectronica: I'll keep looking too.  thanks
<intellectronica> hmmm, maybe not
<intellectronica> kfogel: are you using bugtask/image:icon to render them?
<kfogel> intellectronica: let me see
<kfogel>              <td style="padding-right: 1em;"
<kfogel>                  tal:content="patch_task/importance/title"
<kfogel>                  tal:attributes="class string:importance${patch_task/importance/name}"></td>
<kfogel> intellectronica: ^^
<intellectronica> this should give the colourful behaviour without anything additional in the template
<kfogel> intellectronica: lib/lp/bugs/templates/bugtarget-patches.pt is where this is
<intellectronica> kfogel: but that's the importance, which is textual, not the icon
<kfogel> intellectronica: right now, patch_task/importance/title is giving the icon too, AFAICT
<kfogel> OH
<kfogel> intellectronica: no, it's this:
<kfogel> <a tal:replace="structure patch_task/bug/fmt:link" />
<intellectronica> and that includes both the icon and the bug #?
<kfogel> intellectronica: yup.  it includes icon, followed by fully linked text like this:
<kfogel> Bug #24: Bug I: six attachments (three patches, three non-patches).
<intellectronica> hmmmm ....
<mup> Bug #24: uploading language po file causes extra lines to be appended <Launchpad Translations:Fix Released by carlos> <https://launchpad.net/bugs/24>
<kfogel> intellectronica: (all of that text is a link to the bug)
<intellectronica> the problem, of course, is that bugs don't have importance, it's bug tasks that do
<kfogel> intellectronica: right :-)
<kfogel> intellectronica: but I think we list by task too
<kfogel> intellectronica: so it's okay
<kfogel> intellectronica: let me make a listing that has the same patch listed multiple times with different task importances, one sec
<intellectronica> what happens if you remove the /bug/ and try fmt:link on the task directly? does it do anything sensible?
<kfogel> intellectronica: okay, got it (with my sampledata, it's https://bugs.launchpad.dev/ubuntu/hoary/+patches)
<kfogel> let's see...
<kfogel> intellectronica: hunh.  it still works, but the bug icons are all the same color
<kfogel> intellectronica: AH
<kfogel> intellectronica: no, it works.  It just happens that the tasks for ubuntu/hoary were "confirmed" and "undecided" or something,
<kfogel> so they showed up the same color.
<intellectronica> yay
<kfogel> confirmed and new, actually
<kfogel> oky
<kfogel> wow
<kfogel> intellectronica: that was the fastest fix ever.  thank you
<kfogel> intellectronica: progress, just fyi: all of beuno's suggestions are now incorporated, and about half of yours so far.  I'm pushing branch up as I go.
<intellectronica> awesome
<intellectronica> kfogel: i'll have to leave shortly, but will be back in ~2-3h for more
<kfogel> intellectronica: great.  (Do you always work that late?)
<intellectronica> no, but there's still so much to do and i did waste some of the morning and i do have to run out for an appointment, so i don't mind sitting for another hour or two when i'm back
<kfogel> intellectronica: gotcha
<mrevell> nytol
<kfogel> intellectronica: ayt?
<kfogel> adeuring: in intellectronica's comment here, http://paste.ubuntu.com/367021/, where do you think a good place to put the new helper function would be?  I'm thinking maybe in lib/lp/testing/factory.py somewhere, but not sure.
<jtv> henninge: heyyy, did I see pottery landing there?
<henninge> jtv: yes, you did!
<jtv> \o/ !
<henninge> :-D
<henninge> jtv: I got it figured out with mwhudson this morning
<jtv> that's great
<henninge> jtv: and I created a wiki page about it ...
<kfogel> allenap: how's progress on person/team for patches view?
<henninge> jtv: https://dev.launchpad.net/EC2Test/Image
<jtv> henninge: even better... thanks for that!
<mwhudson> good morning by the way
<kfogel> mwhudson: good morning.  Kind of early for you, no?
<henninge> mwhudson: Hi, thanks for the help!
<mwhudson> kfogel: 08:23? not really
<mwhudson> henninge: your wiki page misses a step, understandably enough, as i don't think i told you about it :-)
<mwhudson> ah, no
<henninge> mwhudson: oh, what is it?
<mwhudson> henninge: i thought it skipping making the image public
<henninge> marking the image as public?
<henninge> ;-)
<mwhudson> henninge: i think i'll edit the page to include the command to do that
<henninge> mwhudson: please do, I did it through the AWS dashboard.
<mwhudson> henninge: done
<henninge> cool
<mwhudson> henninge: something i've gradually learnt is that the command line tools are actually more convenient than any of the other tools for some things :-)
<adeuring> kfogel: that helper could go somewhere "close" to the test factory, i think. i.e. lib/lp/testing./factory.py
<adeuring> I mean, it could go into that file
<kfogel> adeuring: cool.  I'll have another question in a moment; chatting with jcastro right now about his timing.
<mwhudson> hm
<mwhudson> i wonder where my headset is
<kfogel> barry: got a sec to help me figure out why my attempt to use Python's glorious 'with' statement isn't working?
<thumper> hi mwhudson
<mwhudson> thumper: hello
<kfogel> Anyone here successfully used Python's 'with' statement in story tests?
<kfogel> http://paste.ubuntu.com/367057/
<kfogel> adeuring: ^^
<mwhudson> hm, doctests vc future
<adeuring> kfogel: mwhudson mihgt be right... sorry for my obviously nonsensical suggestion...
<kfogel> mwhudson: "doctests vc future" ?
<adeuring> kfogel: also, we haven't yet heard about jtv's reason not to like !iwth" in conjunction with transactions.
<kfogel> is that "vs" ?
<jtv> "!iwth"?
<kfogel> adeuring: hmmmm.  Okay, given this, I'm going to fall back (for now) on just making it a normal meta-factory method, with a user parametere.
<kfogel> jtv: Python 'with' statement :-)
<jtv> ah :)
<mwhudson> kfogel: yeah, was meant to be vs
<kfogel> mwhudson: oic
<adeuring> jtv: as kfogel said. Barry suggested in the reviewer meeting that we should start to use "with"
<adeuring> but he said also that you have some objections
<jtv> I think I've already seen it used.
<kfogel> mwhudson: Oh well.  Once again, I give up something I used to get 15 years ago in Lisp, so that I can write code in the modern age.  *cough*  *cough*  :-)
<mwhudson> kfogel: you could just not use doctests <wink>
<jtv> kfogel: My objections against "with" are more from a language design standpoint and database frontend design standpoint; I think it'd be nice to have it apart from some insane over-engineering that luckily is optional.
<kfogel> mwhudson: I have a choice? :-)
<jtv> kfogel: Although IMHO it also fails to solve the main thing it's almost useful for.
<jtv> kfogel: so I'm not objecting to its use per se; but sadly it ends up being a very thin layer of syntactic sugar for "try: ... finally:"
<allenap> kfogel: I've been spending some time looking at lp:~thekorn/launchpad/make_iperson_ihasbugs, which intellectronica said was related. It is, but not strongly (I think), so one won't hold up the other. I also discovered what the problem was in thekorn's branch.
<kfogel> allenap: excellent (for thekorn, anyway :-) )
<allenap> thekorn: If you're around, the problem is that the Person model class does not fulfil IHasBugs. However, IHasBugs is an ugly interface which needs some refactoring. This, I think, will fix IPerson.searchTasks() for the API without too much pain.
<thekorn> allenap, I think one problem was that IPersonPublic should not inherit from IHasBugs but IBugTarget
<noodles775_> hi mwhudson, have you got time for a brief call when you're finished your standup?
<thekorn> allenap, btw, thanks for looking at this branch
<mwhudson> noodles775_: yes, and it's just finished
<thekorn> allenap, give me one second, let me push what I have changed over the last couple of hours
<allenap> thekorn: Well, the relationship is not really right. People can't have bugs targeted to them. But, if we move searchTasks() into a separate interface, say IBugTaskSearchable (argh, but I can't think of anything better right now), then IPersonPublic can inherit from that.
<allenap> thekorn: And so can IHasBugs.
<thekorn> ok, so IBugTarget means: "there can be bug targetted to this object"
<thekorn> this logic is new to me, but makes perfect sense
<allenap> thekorn: Yes, that's the idea I think.
<thumper> abentley: I've noticed some diffs having a link saying there are conflicts, but there are no conflict markers in the diff shown
<allenap> thekorn: But then IBugTarget should be that.
<thumper> rockstar: what's the status of the scanner cherry pick?
<abentley> thumper, I believe it's all diffs.
<thumper> abentley: is it None vs '' ?
<rockstar> thumper, failed tests on Friday.
<allenap> thekorn: Actually, you know, I'm probably wrong :)
<abentley> thumper, I think so.
<rockstar> thumper, back in ec2 now.
<thekorn> allenap, but there is a good chance you know better than me ;)
<thekorn> will change it back to IHasBugs, for now
<intellectronica> kfogel: back
<kfogel> intellectronica: hey there.  Everything is proceeding okay on my end; no questions yet, though there may be later.  You're here for how long, you think?
<intellectronica> kfogel: 2h
<kfogel> intellectronica: just fyi, I tried to use the new Python 'with' when rewriting that meta-factory in the story tests, but no dice.  I didn't spend too much time on it (see backscroll), before falling back to a traditional function.
<kfogel> intellectronica: *nod*  unfortunately some of that time I'm on a phone call, but I'll try to dig up any questions early, before you're gone.
<intellectronica> yeah, we can revisit that later. i never implemented a with thingster, so i don't know what's involved
<kfogel> I'll be working on this late tonight, but that doesn't help you EU peeps :-).
<kfogel> intellectronica: for now, I changed the name from 'make_thing()' to 'do_as_user()' (and that's pushed up now).  I want to move it into lib/lp/testing/factory.py and make it a helper method in class LaunchpadObjectFactory, named doAsUser().  Does that seem reasonable?
<intellectronica> kfogel: yeah, that sounds like a good plan
<kfogel> *nod*
<kfogel> okay, thanks
<allenap> Ahem, where has testtools gone?
<thekorn> allenap, intellectronica, what I have is working now. next step is to do the right thing on the web api side: my idea right now is: someperson.searchTasks() should be equal to bugs.lp.net/~someperson
<thekorn> and I would also like to add some alias like method like searchCommentedTasks
<thekorn> although I don't like the mixture of tasks and bugs here
<thekorn> (tasks cannot have comments), but this is a more general problem ;)
<allenap> thekorn: Get searchTasks() working first, and landed :)
<thekorn> okidoki
<henninge> Hi, does anybody know if "combine-css" is broken in any way? It fails like this (make build) http://paste.ubuntu.com/367080/
<kfogel> intellectronica: okay, inside that class I've defined doAsUser(self, ...) now.  But the code for do_as_user() in patches-view.txt invoked login() and transaction.commit() and logout().  Where was it getting those functions from?  In the factory.py context, they're not defined, i.e.:
<kfogel>     NameError: global name 'login' is not defined
<thekorn> allenap, another question: I started working on this some time ago, should I merge recent changes to the main launchpad branch into it, or should I just ignore them (for now)
<allenap> thekorn: Ah, that's why I'm missing stuff. Yes, definitely merge devel every so often.
<thekorn> ok
<intellectronica> kfogel: you can grep for where they're imported from. i don't remember off the top of my head, and they're imported magically into doctests, so i'll try to search for them in python files
<kfogel> intellectronica: yeah, I figured it must be magic somewhere :-)
<intellectronica> kfogel: from canonical.launchpad.ftests import login, logout
<kfogel> intellectronica: what file ar eyou in?  ( I was starting with bin/test)
<mwhudson> i think you can import them from lp.testing as well
<allenap> thekorn: I just pulled your branch again and you'd added official_bug_tags to Person, the same as I had :) I think official_bug_tags needs to move to another interface. It makes no sense at all for people and teams (at the moment anyway).
<kfogel> mwhudson: you were right
<thekorn> allenap, so, now I'm confused, official_bug_tags is already in its own interface IOfficialBugTagTargetPublic, but I don't get how this is injected into IHasBugs
<allenap> thekorn: It's defined in IHasBugs.
<thekorn> oh right
<allenap> thekorn: It should be removed from IHasBugs. It was probably an oversight that didn't break anything.
<allenap> thekorn: Of course, something will probably rely on it :) Test suite to the rescue!
<thekorn> allenap, how do I find relevant tests to such changes?
<allenap> thekorn: That's hard. You could just run every test with "bug" in the name for a fair guess. If you have a powerful machine it'll probably take less than an hour.
<thekorn> uhh, so no test driven development for me ;)
<allenap> kfogel: I /think/ you committed the test data changes to lp:~kfogel/launchpad/506018-patch-report.
<kfogel> allenap: aaaaaaaaack.
<kfogel> I did.
<kfogel> allenap: thank you.  I can easily revert that.
<kfogel> allenap: will do after phone call
<allenap> kfogel: Cool, it's not bothering me, so no urgency.
<thekorn> what is the correct way to merge recent changes from the ../devel branch?
<thekorn> just bzr merge, or is there some helper script which does the right thing?
<thekorn> (updating dependencies etc)
<maxb> I don't think there's any "right thing" that needs doing on top of "bzr merge"
<maxb> In some circumstances you might need to run update-sourcecode
<maxb> But update-sourcecode takes long enough that I wouldn't want to run it after every merge just in case
<allenap> thekorn: It's worth having a local copy of devel (I keep a local copy of devel, db-devel, stable and db-stable).
<allenap> thekorn: rocketfuel-get will maintain devel for you.
<allenap> thekorn: pulling all source deps, etc.
<thekorn> right, that's what I have too
<allenap> thekorn: Then I just merge from the local copy of devel. Your branch is old, so it's probably worth doing a make clean && make.
<thekorn> ok, trying ...
<mwhudson> ground control looks pretty nifty
<intellectronica> yeah? does it call major tom?
<allenap> kfogel: I have a branch that registers the BugPatchesView for people and teams: lp:~allenap/launchpad/patch-report-for-people-and-teams-bug-506018. Now I'm off, so cheerio until tomorrow.
<james_w> could someone from the bugs team help me work out why we can't edit bugs through the API anymore?
<james_w> the new bug heat stuff doesn't edit every bug every few seconds or anything does it?
<james_w> it is blocking us doing syncs without a lot of pain
<wgrant> abentley: What happened to landing that slave branch?
<abentley> wgrant, the test suite is a much bigger pain to run than it was before windmill became mandatory.
<abentley> wgrant, my latest attempt has failed with "address in use".
<wgrant> abentley: Oooh yes.
<wgrant> I gave up on running the whole thing locally, since I couldn't get Windmill to run properly.
<intellectronica> wgrant: really? when did you last try? it used to be a nightmare but it works pretty smoothly for me now
<wgrant> I haven't tried since around the sprintÂ¸ IIRC.
<abentley> intellectronica, so far, running under xvfb has led to lots of spurious errors.  I'm now running under screen, with a vnc session as my DISPLAY.
<intellectronica> i never tried running under xvfb locally, i just let it fire up firefox
<bigjools> there was a bug in xvfb that was fixed
<intellectronica> kfogel: say, in your doctest, why do you use user_browser? shouldn't you be able to view this page as an anonymous user?
<intellectronica> sorry for not spotting this earlier, b.t.w
<james_w> grr, task_age
<james_w> what's that for?
<intellectronica> james_w: ask bdmurray - he uses it for something, not sure what
<intellectronica> james_w: and why grrr? is it creating any problems for you?
<wgrant>         return self.age.seconds
<wgrant> Yes, that's going to break everything.
<kfogel> intellectronica: very good question.  Not sure; may have just been a cut-and-pasto on our part.  I'll try with anon.
<intellectronica> kfogel: cool
<intellectronica> wgrant: please elaborate
<james_w> intellectronica: you can't edit bugs over the API, as that's changing every second
<kfogel> allenap: yay!  Thank you.  I'll check out your branch.
<wgrant> intellectronica: That value will change every second, as james_w says.
<wgrant> Which is going to mean that holding a bug across a second boundary then saving it will fail with a 412.
<james_w> task has date_created, can't task_age just be calculated from that?
<james_w> I'm pulling devel to have a look at the code myself
<intellectronica> james_w, wgrant: wow, haven't thought about that. can you please file a bug?
<james_w> intellectronica: sure, but I think we will want a CP for this
<intellectronica> i think it's worth getting rid of that. it's easy to calculate age locally
<intellectronica> james_w: maybe. it's easy to use the api from edge. in fact i assume most people do
<intellectronica> i'll happily review a branch that kills BugTask.age :)
<mwhudson> rockstar: hi
<rockstar> mwhudson, hey there.
<rockstar> mwhudson, I assume you have some reviews you need from me.
<mwhudson> rockstar: actually no
<mwhudson> rockstar: i was wondering what the status of your scanner fixes is
<mwhudson> rockstar: because i want to land a bzr upgrade, but that will probably conflict with them
<james_w> bug 515747
<mup> Bug #515747: Exporting task_age breaks editing over the API unless you PATCH within a second of GET <Launchpad Bugs:New> <https://launchpad.net/bugs/515747>
<intellectronica> james_w: thanks
<rockstar> mwhudson, I got disconnected, so I didn't see what you needed.
<mwhudson> <mwhudson> rockstar: actually no
<mwhudson> <mwhudson> rockstar: i was wondering what the status of your scanner fixes is
<mwhudson> <mwhudson> rockstar: because i want to land a bzr upgrade, but that will probably conflict with them
<rockstar> mwhudson, it's in ec2 running against devel right now.
<rockstar> mwhudson, it should land in the next few hours.
<mwhudson> ok
<rockstar> mwhudson, I'll ping you when it lands.
<mwhudson> rockstar: what's the url?
<rockstar> mwhudson, for what?
<mwhudson> rockstar: your branch
<rockstar> mwhudson, one sec.
<rockstar> mwhudson, bzr lp-open
<rockstar> Er...
<rockstar> mwhudson, https://code.edge.launchpad.net/~rockstar/launchpad/scanner-events
<mwhudson> rockstar: :-D
<rockstar> mwhudson, the Ctrl-C and middle click has different behavior in different apps.  :)
<mwhudson> yar
<mwhudson> rockstar: thanks
<james_w> https://code.edge.launchpad.net/~james-w/launchpad/kill-task_age/+merge/18418
<intellectronica> james_w: out of curiosity, when first running into this problem, were you using edge or production?
<james_w> is that the right target to get it on edge ASAP?
<james_w> intellectronica: edge
<james_w> it happens on both
<intellectronica> james_w: you rock. waiting for the diff
<james_w> I'm guessing this change landed in the last week
<mwhudson> james_w: yes, that's the right target
<intellectronica> james_w: yes, i know it happens on both, i'm just trying to evaluate whether it's worth a CP
<james_w> well, edge for a start please so that we can process syncs without a lot of manual work
<james_w> then see if anyone complains :-)
<james_w> also note that if heat is exposed on IBug it will cause some people headaches if you are using jobs to calculate it
<james_w> that's not really fixable, so you should document the way to handle it
<intellectronica> james_w: r=me. can you land or would you like me to land this on your behalf?
<james_w> please do
<james_w> I have no powers :-(
<intellectronica> james_w: sure thing
<thekorn> what is a CP ?
<intellectronica> thekorn: Cherry Pick
<mwhudson> rockstar: yes, my branch conflicts with yours
<intellectronica> patching the production servers between releases
<mwhudson> rockstar: a ping when it's landed would be nice
<thekorn> ah ok
<mwhudson> or i can just subscribe to the branch i guess
<rockstar> mwhudson, sowwy  :(  I'll ping you when it's there.
<mwhudson> rockstar: blame bzr!
<rockstar> mwhudson, :)
<intellectronica> james_w: it's on EC2. with enough luck it'll make it in before the nightly rollout
<james_w> thanks intellectronica
<intellectronica> james_w: thanks a lot for uncovering and fixing this. sorry for the inconvenience
<intellectronica> kfogel: are you aware of your tests not completing successfully?
<kfogel> intellectronica: ??
<kfogel> intellectronica: no, they succeeded for me.  what are you seeing?
<kfogel> intellectronica: you mean patches-view.txt, right?
<intellectronica> oh, maybe i'm talking nonsense and it's my fault. let me go through them more thoroughly  before i waste your time
<intellectronica> yes, patches-view.txt
<kfogel> intellectronica: let me know if there's an issue, I'll be here
<kfogel> intellectronica: just ran them again -- success
<intellectronica> kfogel: false alarm. stupid me. i've changed the behaviour when there are no patches and added a test, and forgot to amend a few of the existing ones.
<kfogel> intellectronica: ah, np
<didrocks> intellectronica: btw, I tried to checkout launchpad and I have an error when running "make schema"
<kfogel> intellectronica: what's the "proper
<kfogel> " way to revert a change to a file in bzr?
<kfogel> intellectronica: I could just diff -rNEW..OLD it and commit the change, and it would work.  But is there a best practice here?
<kfogel> didrocks: what's your error?  (can you paste at paste.ubuntu.com?)
<intellectronica> kfogel: bzr revert -r revno [file_path]
<didrocks> kfogel: http://paste.ubuntu.com/367149/
<kfogel> intellectronica: that doesn't do anything ugly to mergeinfo in our branches?  We're okay with it?
<kfogel> intellectronica: (some recent burns on the emacs devel list have made me very cautious)
<intellectronica> kfogel: i'm not sure what exactly you're asking, but i don't think it does anything bad. it forgets all the revisions you rolled back
<kfogel> didrocks: you've followed every step at https://dev.launchpad.net/Getting to get to the 'make schema' point?
<kfogel> intellectronica: sounds good.  (well, other things changed in that rev, and I'm not reverting them, so I don't want it to forget about the entire rev...)
<didrocks> kfogel: right, I've checked twice :)
<intellectronica> kfogel: right. i'm not sure how it works if you only revert a single file
<intellectronica> i doubt that it will forget the entire revision, but it's worth checking
<kfogel> intellectronica: ok, thanks.  I'll read the help and make sure.  I can alwys uncommit if it's bogus.
<didrocks> (I didn't notice any error, but let me check back for the last part of the script which should have done lp-branches/devel/utilities/link-external-sourcecode call)
<kfogel> didrocks: and you got no errors when you ran rocketfuel-setup?
<didrocks> kfogel: oh bad, didn't notice that error first: http://paste.ubuntu.com/367157/
<didrocks> I'm on lucid
<kfogel> didrocks: ah.  Well, if bzr hiccups, things are probably not going to work :-).  I'm embarrassed to say I'm not on Lucid yet myself.
<kfogel> didrocks: is bzr working for you otherwise?
<didrocks> kfogel: right, I'm using it more than heavily :)
<didrocks> (packaging and Quickly)
<wgrant> LP needs a couple of tweaks to work on Lucid, but that isn't one of them.
<kfogel> didrocks: I would say google for some unique part of "bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "'Inter1and2Helper' object has no attribute 'source_repo'")
<kfogel> "
<didrocks> kfogel: right, found https://bugs.edge.launchpad.net/bzr/+bug/515325
<mup> Bug #515325: 'Inter1and2Helper' object has no attribute 'source_repo' <Bazaar:Confirmed> <https://launchpad.net/bugs/515325>
<didrocks> quite fresh bug :)
<kfogel> and see if this is solveable.  If you can get Bazaar behaving okay, at least you could then make it to the roadblocks wgrant is thinking of!
<kfogel> didrocks: hmmm.  yeah, that's fresh.  I'm not sure what to suggest, except maybe downgrading bzr?
<kfogel> for now
<didrocks> kfogel: do you think I just can run again just make install?
<didrocks> as it seemed to have crashed in that part
<didrocks> kfogel: this version of bzr has almost one month. I don't think I can afford to downgrade it
 * mwhudson lunches
<kfogel> didrocks: well, I would expect it to just crash again, but couldn't hurt to try...
<lifeless> thumper: https://bugs.edge.launchpad.net/launchpad-code/+bug/513432
<mup> Bug #513432: AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo' <fetch> <Bazaar:Fix Released by mbp> <Bazaar 2.0:Invalid> <Bazaar 2.1:Fix Released by mbp> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/513432>
<lifeless> thumper: this is affecting folk
<lifeless> thumper: fixed in bzr, but you need to roll out newer bzr to fix it on lp
#launchpad-dev 2010-02-02
<kfogel> intellectronica: saw your branch get linked just now
<intellectronica> kfogel: yes. had a chance to look at it?
<kfogel> intellectronica: not yet, about to
<intellectronica> i think it's good to go
<kfogel> intellectronica: in this comment, "lisp-style identifier" means with hyphen instead of camelCase, right?
<kfogel> Is this a new CSS class or an existing one. If it's new, let's change it to
<kfogel> lisp-style-identifier. Otherwise don't worry about it.
<intellectronica> kfogel: right. sorry for not being clearer.
<kfogel> intellectronica: no, I think you were clear -- just you were here, so I thought I'd check to make abs sue.
<kfogel> sure
<kfogel> intellectronica: also, you wrote this: "Repeating the same style over and over again kinda' screams CSS class."
<kfogel> but making a new class for this feels wrong -- I'd think the right class already exists somewhere.  Do you know if there's one I should use?
<kfogel> This is for the table cells in the patches view.
<intellectronica> kfogel: i have no idea. launchpad's css is a messy business, but look at the file and if you don't find one feel free to add
<kfogel> intellectronica: "the file" is lib/canonical/launchpad/icing/style-3-0.css or lib/canonical/launchpad/icing/style.css
<kfogel> ?
<kfogel> or somethig else? :-)
<intellectronica> kfogel: lib/canonical/launchpad/icing/style.css, i think
<intellectronica> there's a section in it dedicated to the bugs application, so it should be ok to jsut add the class there
<lifeless> thumper: poing
<kfogel> intellectronica: oh, and I'm taking the "<!--" ... "-->" out of the script type=text/javascript block.  Thanks for the comment about the 90s calling :-).
<intellectronica> :)
<mwhudson> rockstar: if you *are* in the reviewing mood though, https://code.edge.launchpad.net/~mwhudson/launchpad/less-import-requestMirrors-bug-487357/+merge/18361
<rockstar> mwhudson, I assume you're probably pretty lonely in your hemisphere currently, so I would review it even if I wasn't in the mood.
<mwhudson> rockstar: indeed; thanks
<lifeless> mwhudson: ping
<lifeless> mwhudson: I'm going to nag you as thumper seems awol. please see up about one page for the bug link  I threw at him
<kfogel> intellectronica: what I'm going to do is make an integration branch with your branch, my brancha, and allenap's branch (adding patches view to persons/teams), and run that integration branch through EC2 tests.  I assume if we get review on the three branches, then when the integration branch passes tests, we can merge each of the three individually to devel, right?
<intellectronica> kfogel: yups
<lifeless> kfogel: or bomb the lot in :P
<kfogel> intellectronica: want to review https://code.edge.launchpad.net/~allenap/launchpad/patch-report-for-people-and-teams-bug-506018/+merge/18414 ?
<kfogel> lifeless: well, how does one write the PQM submit message for that? :-)
<lifeless> kfogel: "foo bar baz"
<kfogel> I'm thinking what the combination of "[r=foo...]" on the front would be.
<kfogel> ah
<intellectronica> ok
<kfogel> maybe I'll just do that
<kfogel> intellectronica: thanks
<kfogel> intellectronica: btw, do you need to get review on https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message ?  (I am not a reviewer, unfortunately.)
<kfogel> (s/unfortunately/fortunately/, as you please :-) )
<mwhudson> lifeless: thumper is in london
<intellectronica> kfogel: i do need to get a review, yes
<kfogel> intellectronica: is that something I can submit, or do you have to do it?  because if I could, I'd pick one of these gents currently in the channel (assuming cross-team reviews are kosher).
<intellectronica> kfogel: wow, if you feel like doing that that would be super awesome, because i'm dying to go to bed
<intellectronica> but don't feel obliged
<mwhudson> lifeless: do you know if 2.1rc2 will be out soon and if it will have the fix?
<kfogel> intellectronica: remember, I'm just submitting to someone else, not reviewing.  But sure, I'll create a merge proposal and point to some test data for them, etc.
<intellectronica> kfogel: approved allenap's branch, b.t.w
<kfogel> intellectronica: great!
<intellectronica> kfogel: you rock
 * intellectronica --> zZz
<kfogel> intellectronica: if tests pass, and the other branch passes review, then tomorrow we are all focused on the patch-age sorting, because IIUC that's the only thing left.
<kfogel> intellectronica: good night!
<lifeless> mwhudson: soon yes
<lifeless> mwhudson: otoh this bug is going to be biting people, 2+ reports of it a day at the moment (judging by malone + hallway conversations here)
<mwhudson> hmm
<mwhudson> i wonder if the diff applies cleanly to the bzr we're currently running...
<lifeless> yes, it will. its a tiny patch
<mwhudson> ok cool
<kfogel> mwhudson, thumper: will y'all be around, say, an hour from now?
<mwhudson> kfogel: i will, thumper won't (i really hope)
<wgrant> +upgrade is severely lacking in the text department.
<wgrant> And it seems to be letting me upgrade a branch on which others are stacked. That seems bad.
<kfogel> mwhudson: I may hit you with an easy review request a bit later then :-)
<mwhudson> kfogel: ok
<lifeless> wgrant: you have to be able to do that
<wgrant> lifeless: Yes, but there's this nice clicky button with no explanation that will let me break everything.
<rockstar> Huh, ec2 missed the fact that my branch wasn't up to date...
<mwhudson> rockstar: thanks
<mwhudson> rockstar: it's possible the branch hadn't been mirrored by the time ec2 grabbed it?
<rockstar> mwhudson, no, my public branch was out of date.
<mwhudson> oh
 * rockstar shrugs
<lifeless> rockstar: hi
<lifeless> rockstar: so, the upgrade button seems to show up right after push until the branch is scanned
<lifeless> rockstar: I presume the default value in the table causes it to be shown
<rockstar> lifeless, :(
<rockstar> lifeless, can you please specify that in the bug? I'll fix it tomorrow.
<lifeless> rockstar: cool, thanks
<rockstar> lifeless, no, thank you for reporting and following up on the bug.  I really appreciate it.
<lifeless> anytime, its easy karma :)
<rockstar> mwhudson, could we chat really quick?  I'm trying to figure out some of jml's suggested voodoo that I bet you know a lot about.
<mwhudson> rockstar: sure
<mwhudson> (i've even found my headset now)
<rockstar> mwhudson, yay!
<rockstar> mwhudson, http://pastebin.ubuntu.com/367205/
<rockstar> mwhudson, http://pastebin.ubuntu.com/367206/
<lifeless> mwhudson: so you're going to cherrypick the fix ?
<mwhudson> lifeless: i guess i should
 * mwhudson tries to remember what the process is for using non-released versions of sourcedeps is
<mwhudson> rockstar: i'm not going to land the bzr upgrade until after this cp is sorted
<mwhudson> rockstar: so don't rush things on my account
<rockstar> mwhudson, well, I was already rushing.  :)
<mwhudson> heh
<lifeless> mwhudson: rockstar was landing another non released version for bzr-loggerhead
<lifeless> mwhudson: so build on that :)
<lifeless> mwhudson: for now, I'd like to assign the bug to you and bump to critical
<rockstar> mwhudson, well, I'm actually doing one cherry pick at a time.
<rockstar> Is there a dev wiki entry on landing against the production branches?
<kfogel> mwhudson: https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428
<kfogel> rockstar: does dev.launchpad.net/Trunk link to what you need?
<rockstar> kfogel, no.
<kfogel> rockstar: pity
<kfogel> :-)
<rockstar> kfogel, I'm looking for the instructions for landing against production branches.
<kfogel> rockstar: they may not be in the dev wiki.  Is this different from landing against one of the four usual horsemen (db-devel, devel, stable, db-stable)?
<kfogel> rockstar: i.e., I'm not clear on the shorthand "landing against production branches".
<rockstar> kfogel, yes.  I need to land against what's in production right now.
<rockstar> kfogel, none of those four are currently deployed.
<rockstar> kfogel, AIUI, I submit to PQM with a release-critical against a production db.
<kfogel> rockstar: you mean you need to land your change into production right away??  (Sorry, I'm not being deliberately dense, I'm just not clear on what you're trying todo.)
<rockstar> kfogel, yes.  I have a high priority issue that needs to get cherry picked to production.
<kfogel> rockstar: I'm not expert in this, having never done it, but I thought you just land the change on one of the regular trunks and then request a cherry pick.
<kfogel> The request can be by email?  check with mthaddon or someone who might know better.
<spm> what kfogel said
<mwhudson> no, it has to be landed on production-devel
<mwhudson> doesn't it?
<spm> errr....
<rockstar> mwhudson, yea, I think that's new.
<mwhudson> which ties up pqm for like 14 hours
<kfogel> mwhudson: but that's what the cherrypick does, no?
<spm> don't you land against one of the rarely used, yet still in PQM branches?
<rockstar> spm, yes, and I'm trying to figure out which one.
<mwhudson> i think there is much talking past each other going on here
<rockstar> After it lands, I then beg a LOSA to deploy it to production.
<rockstar> I'm just trying to find a wiki page on how to do it.
<mwhudson> rockstar: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/production-devel
<rockstar> mwhudson, thanks.
<kfogel> mwhudson: (I don't think so; I think it just took a moment to figure out the goal)
<kfogel> rockstar: this should be a note somewhere on dev.launchpad.net/Trunk
<lifeless> mwhudson: https://bugs.edge.launchpad.net/bzr/+bug/513432 metadata twiddled.
<mup> Bug #513432: AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo' <fetch> <Bazaar:Fix Released by mbp> <Bazaar 2.0:Invalid> <Bazaar 2.1:Fix Released by mbp> <Launchpad Bazaar Integration:Confirmed for mwhudson> <https://launchpad.net/bugs/513432>
<lifeless> for now, dinner time here.
<kfogel> wowwwwwww... combination of "<<<<"  ">>>>" conflict markers and story test ">>>" lines is... dazzling to the eye.
 * kfogel rubs his eyes
<wgrant> james_w: Oh, 2.5 is going to be gone entirely?
<james_w> that's the plan
<james_w> 2.5->2.6 was less painful than 2.4->2.5 so there's less holding it back, and moving to 2.6 only means that we can move quicker towards python3
<wgrant> The intention has been to only move LP to 2.6 once Lucid is out and the DC is upgraded.
<james_w> that could make things tricky
<wgrant> Yes.
<james_w> we can always stick 2.5 in a PPA for those couple of months, but it would obviously be better if there were fewer PPAs involved
<wgrant> I think everybody thought that 2.5 would remain like 2.4 did.
<wgrant> We already have 2.5 rebuilds of most stuff in the PPA.
<kfogel> mwhudson: any idea what this is about?  I see the import line right where the error message implies it is, but I have no idea what it means nor why it has never happened to me before :-).
<kfogel> http://paste.ubuntu.com/367245/
<mwhudson> kfogel: make build?
<kfogel> https://lists.launchpad.net/launchpad-dev/msg00071.html ...
<kfogel> mwhudson: oh, hmrm.  I'd done successful 'make run', I thought.  But let me do make build, let's see.
<kfogel> mwhudson: *embarrassment*
<kfogel> mwhudson: my 'make run' was in the wrong branch.  nothing to see here, move along...
<thekorn> allenap, intellectronica, just in case anyone of you is still around, I got Person.searchTasks() working in my branch, it still needs some more tests, but I'm getting there
<kfogel> thekorn: they're in bed (and I'm about to be) but they'll be on in the morning UK time
<thekorn> ok
<mwhudson> kfogel: reviewed that branch, finally
<kfogel> mwhudson: thanks.  I think I should have explained that only Tom Berger's changes needed review -- but actually, you've saved us time by reviewing a lot of my recent changes too :-).
<mwhudson> kfogel: oh
<mwhudson> well, i just reviewed the diff :)
<kfogel> mwhudson: I meant allenap, but same thing.
<kfogel> mwhudson: yeah.  That's kind of a bug, in that "the diff" was the wrong thing.  I'm sure there was a way for us to set things up so it would be the right thing, but I didn't do that...
<kfogel> mwhudson: no, I was right the first time: intellectronica, sorry
<Ursinha> hey mwhudson, I have a question that you might know the answer
<mwhudson> Ursinha: shoot
<Ursinha> mwhudson: what exactly sets the properties of a bzr revision?
<mwhudson> Ursinha: in what context?
<Ursinha> mwhudson: I'm using bzrlib to get all the lp commits, one by one, and looking in its properties for the name of the "original" branch
<mwhudson> oh right
<Ursinha> mwhudson: and I just hit one that has no properties set
<mwhudson> well, there's the branch nick i guess
<mwhudson> Ursinha: in some sense, there's not much more of an answer than "bzrlib"
<Ursinha> hm
<mwhudson> there are some common properties, but none you can absolutely 100% rely on
<Ursinha> mwhudson: I see
<mwhudson> particularly given how old a codebase launchpad is
<Ursinha> I was counting on the branch-nick property, and then it exploded because a revision had no branch-nick property
<mwhudson> yeah
<mwhudson> i think you just have to cope with that case
<Ursinha> mwhudson: I'm trying to find one alternative way to get the bugs related to a commit besides people having to add the bug tag to the commit message
<mwhudson> Ursinha: ah, i see
<Ursinha> I know that this is automagically added to the commit message when you use ec2 land
<Ursinha> mwhudson: I think I'll keep relying on the commit message now the bug is added without intervention
<Ursinha> do you have any ideas? :)
<mwhudson> Ursinha: not really
<Ursinha> mwhudson: I mean, do you know a way of getting to a list of related bugs from a branch revision?
<mwhudson> Ursinha: well, if the associate was done with ci --fixes lp:12345 then it's a revision property
<mwhudson> if the fix was recorded in the web ui, then no, not from the bzr branch
<Ursinha> mwhudson: I was thinking about getting the branch nick, then the owner, and searching for the original branch in lp, and getting the list of linked bugs...
<mwhudson> Ursinha: that would most likely work, i guess
<Ursinha> mwhudson: yeah, that works but it's slow and if you don't have a branch-nick, it fails
<mwhudson> Ursinha: really, you want to get the branch with tip revid that of the rhs parent of the mainline commit
<mwhudson> Ursinha: which is easy if you have db access :-)
<Ursinha> mwhudson: trying to understand what you mean here :)
<mwhudson> Ursinha: all mainline commits for launchpad are merges made by pqm
<mwhudson> so the revisions have 2 parents
<Ursinha> mwhudson: right
<Ursinha> pqm and the owner's
<mwhudson> the second parent revid is the tip revision of the branch being merged
<mwhudson> so if you can find the branch with a given revid as its tip revid, you can find the merged branch
<Ursinha> hmmmm
<mwhudson> (well, probably, unless the branch has been deleted or something, but then you're SOL anyway)
<Ursinha> mwhudson: so searching in the db for the branch using the tip revid
<Ursinha> I wonder if that's overkill now
<mwhudson> Ursinha: i think using the branch nick is probably a reasonable approach for now
<mwhudson> Ursinha: we could export "get me the branch with tip revid $foo" over the api i guess
<mwhudson> (maybe it is already! but i doubt it)
<Ursinha> mwhudson: that would be neat
<Ursinha> mwhudson: I couldn't find it
<mwhudson> Ursinha: it's probably not there then
<Ursinha> I see I can search using the branch url or the unique name
<mwhudson> i don't think it's even an internal api
<Ursinha> hm
<Ursinha> mwhudson: is that bug 356360?
<mup> Bug #356360: API call for finding branches that contain a revid <api> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/356360>
<mwhudson> Ursinha: looks like it!
<Ursinha> mwhudson: :)
<noodles775> Morning ppl
<al-maisan> Good morning noodles775 :)
<wgrant> Morning.
<thumper> morning
<thumper> wgrant: I bet it isn't morning for you :)
<wgrant> thumper: Not quite, no.
<thumper> mwhudson: around at all?
<adeuring> good morning
<al-maisan> moin adeuring
<adeuring> hi al-maisan!
<mwhudson> thumper: ish
<thumper> mwhudson: what's the status of the bzr update cp?
<mwhudson> thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/apply-fix-for-bug-513432/+merge/18435
<thumper> mwhudson: was it branched from the production branch?
<mwhudson> thumper: no
<thumper> mwhudson: I'll get flacoste to rc it
<thumper> mwhudson: hmm
<mwhudson> thumper: but i think it'll cherrypick cleanly :-)
<thumper> if you want to land on the production branch, you'll need that
<thumper> we don't tend to CP any more
<thumper> we just merge a branch into production
<mwhudson> sure
<mwhudson> but merge into devel first?
<thumper> mwhudson: yes, normally
<mrevell> hi
<mwhudson> thumper: you can review it for that then :-)
<thumper> mwhudson: you might want to replace the branch content with the same content but from the production revision
<thumper> yep
<thumper> done
<thumper> mwhudson: so land on devel and I'll have flacoste rc approve before lunch
<mwhudson> thumper: at the risk of sounding churlish, it's 22:14 here
<mwhudson> thumper: want to do it yourself?
<noodles775> mwhudson: Enjoy your evening. I'm assuming there was nothing that stood out as drastically wrong when you went over the bfb ui?
<mwhudson> noodles775: no indeed
<noodles775> Great, thanks for that.
 * noodles775 writes the email to get wider feedback.
<intellectronica> james_w: the bad news are that your patch didn't land because of test failures. the good news is that looks like these are unrelated, spurious failures
<intellectronica> some good news...
<intellectronica> mwhudson: thanks a lot for the review. i guess karl forgot to mention that mine was a tiny branch, dependent on his previous work?
<intellectronica> mwhudson: anyway, you didn't make any comment about my work, so i'll interpret that as r=you and ask karl to look the rest of your comments. sorry that you had to do so much extra work (i'm sure the comments are valuable, though).
<thekorn> intellectronica, hey, I have Person.searchTasks working for the webservice API in lp:~thekorn/launchpad/make_iperson_ihasbugs, it already has two (doctest) testcases, I'm wondering how many of them do I need, and esp. where to put them
<jtv> henninge: what went wrong with my branch to check for unique template names?
<adiroiban> danilos: Hi. Should I create a MP for bug 340664 , or since the performace issue is not solve, it is better to not push those changes?
<mup> Bug #340664: Add administration page for all POTemplates in ProductSeries or DistroSeries <ui> <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/340664>
<danilos> adiroiban, sorry, in the meeting
<jtv> henninge: ahhh, let me guess: you ran into the problem before my fix had landed?
<jtv> adiroiban: if there's a performance problem... it's not the one where Language is being queried far too often?
<adiroiban> jtv: i don't think. This is for the +templates
<henninge> jtv: I had checked the revisions but mixed up some numbers ...
<adiroiban> and afaik this is a long standing issue
<jtv> adiroiban: makes sense, but thought I'd better ask
<jtv> henninge: right, I don't think it's on staging yetâit only just came out of EC2.
<jtv> henninge: s/staging/edge/
<asabil> Hi all
<jtv> hello
<henninge> jtv: just two revisions missing, actually
<asabil> does anyone know that the download button on wide screens look bad ?
<asabil> (the background image is not large enough)
<jtv> asabil: thanks for the report... let me see if that's a known problem.
<asabil> you're welcom
<jtv> asabil: looks like that one's not known yet... could you file a bug against the "launchpad" project and attach a piece of screenshot to illustrate?
<asabil> yeah sure
<jtv> thanks
<asabil> done: https://bugs.launchpad.net/launchpad/+bug/516000
<mup> Bug #516000: The download button look bad on wide screens <Launchpad itself:New> <https://launchpad.net/bugs/516000>
<jtv> asabil: great, thanks.  The people who would normally deal with this are in a meeting this week, so it could be a while before somebody gets to it.
<asabil> jtv, yeah sure
<asabil> looks like lazr.config is used in the launchpad code
<asabil> anyone knows if it supports variables substitution ?
<jtv> asabil: it doesn't afaik
<asabil> ok I see
<asabil> thanks
<danilos> adiroiban, hi, sorry, in a live meeting here and get only short breaks from time to time :)
<adiroiban> danilos: np. just ping me when you have more time. I want to know if I can continue with the implementation for some branches
<danilos> adiroiban, anyway, I'd suggest you prepare an MP for 340664 and get it landed, it's still useful where it works
<adiroiban> danilos: thanks. That is all for now
<danilos> adiroiban, it was just a comment that we should definitely fix those performance problems as well (bug 475435)
<mup> Bug #475435: More timeouts on +templates page <timeout> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/475435>
<noodles775> Hi james_w, you mentioned in your email that you won't have time to continue the trigger work. I'm looking at continuing it (as I'll need the api exposure for some of the UI), but have a few questions.
<noodles775> First, is there any reason that you didn't land your approved branch here: https://code.edge.launchpad.net/~james-w/launchpad/create-source-recipe-build
<noodles775> And secondly, ah, I was going to ask about the inclusion of distroseries as an argument for requestBuild() (as defined on the iface), but then noticed that you haven't included it in the implementation?
<noodles775> which ever way your intention was, I'd be keen to hear the argument behind it (ie. whether a build should be able to define a distroseries different to the recipe).
<kfogel> adeuring: btw, I forgot to list that I'm making screenshots for Jorge (today or maybe tomorrow)
<adeuring> kfogel: noted ;)
<kfogel> intellectronica: http://paste.ubuntu.com/367596/   has full results so far.  How on earth can it not have terminated after more than eight hours??
<intellectronica> kfogel: because technology sucks?
<kfogel> intellectronica: oh
<kfogel> intellectronica: looking for failures now
<intellectronica> sometimes our EC2 machines don't terminate. they have very strong will to live, i guess
<intellectronica> it's worth looking at the mgmt console from time to time, because the costs can run very high if an instance is left running for many days
<intellectronica> (i'm saying that from experience)
<kfogel> intellectronica: "Failure in test test_inline_request_a_reviewer (lp.code.windmill.tests.test_branchmergeproposal_review.TestRequestReview)"
<kfogel> intellectronica: *nod*
<intellectronica> kfogel: i'd bet this is an unrelated spurious failure. we still get lots of those from windmill
<intellectronica> let's try to run the same test locally to verify, but most likely that's the case
<kfogel> intellectronica: so, that failure appears after lots and lots of successes, including success of patches-view.txt.
<kfogel> okay
<intellectronica> yay
<kfogel> intellectronica: how do I run a particular Windmill test?
<intellectronica> kfogel: https://dev.launchpad.net/Windmill
 * kfogel hides his head
<kfogel> intellectronica: thanks :-)
<intellectronica> kfogel: crucial difference from the example is that it will be a different layer in this case. CodeWindmillLayer (iirc)
<intellectronica> the windmill tests for each subdomain run in a separate layer, because of the restrictions browsers place on accessing JS code over different domains
<kfogel> intellectronica: ah, gotcha
<kfogel> intellectronica: running now.  Meanwhile, the EC2 test seems to be stuck at that spot -- there's been no more output, it just ends in the middle of a word....
<intellectronica> argh
<intellectronica> happened before. guess you'll have to kill that machine and fire a new test run.
<kfogel> intellectronica: ok.  well, I was going to have to re-run anyway, what with the DB patch coming up and possibly a few more changes from me due to mwhudson's review, so no loss really.
<kfogel> intellectronica: so test runs get stuck sometimes?  This is not unheard of?
<intellectronica> yeah, it happened to me before
<kfogel> oh goody, now my whole browser has frozen up
<intellectronica> that's not unheard of either ;)
 * kfogel snarkily observes that it never happens to him on his Debian box
<kfogel> Although, I don't do Launchpad development on my Debian box either, so it's under considerably less strain :-).
<intellectronica> because it only runs lynx? :P
 * intellectronica runs and hides
<kfogel> Yesterday I nearly shut down my whole Ubuntu laptop by running 'bzr log -v -n0 > outfile' in a devel branch.
<kfogel> OH
<kfogel> intellectronica: I didn't realize windmill tests actually display a browser dancing around!  This is spooky.
<intellectronica> kfogel: yes. there's also a way to run them headless, under xvfb.
<intellectronica> but they have to run a browser to complete the test. that's the whole point of these tests - they interact with a real browser.
<kfogel> intellectronica: sure, I just didn't know that that browser displayed on the screen.
<kfogel> intellectronica: anyway, it passed
<intellectronica> yes, for me too
<kfogel> intellectronica: okay, I'm terminating this instance in Elasticfox.  Any reason I should show mercy?
<mars> intellectronica, ping, could you help confirm a JavaScript bug for me?
<intellectronica> mars: sure. what's the problem?
<asabil> when running launchpad, how can I disable the creation of the thread-*.request files ?
<intellectronica> kfogel: no, you should feel free to terminate it if you've lost all hope of getting anything useful from that machine
<mars> intellectronica, try going to a bug on staging.launchpad.net, and edit the product.
<mars> intellectronica, when I do so I see an infinite spinner
<intellectronica> mars: yes, we've seen this problem before
<mars> intellectronica, and if I have Firebug turned on to catch all errors, it does grab something
<intellectronica> oh?
<mars> I can't make out the red error text though.  It is hidden by the long line.
<mars> Maybe the error is also present in .dev
<intellectronica> mars: sorry, back now
<intellectronica> there's a bug already filed about this, let me try and find it
<mars> ok
<intellectronica> oh, and i can reproduce on FF
<intellectronica> mars: https://bugs.edge.launchpad.net/malone/+bug/443217
<mup> Bug #443217: Changing a bug's affected project or description doesn't ever finish <bug-page> <javascript> <ui> <lazr.restful:New for intellectronica> <Launchpad Bugs:Triaged by intellectronica> <https://launchpad.net/bugs/443217>
<kfogel> adeuring: question about our "make_thing()" meta-factory function from patches-view.txt story tests.  That function has now moved to factory.py, and is LaunchpadObjectFactor.doAsUser().  In https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428, Michael Hudson asks: "Do you really need to commit here?  Zope-level users and database transactions are basically orthogonal."   Full context at http://pas
<kfogel> te.ubuntu.com/367658/
<adeuring> kfogel: yes, I think we must commit here. A story test does not access the database directly, but via a web server, which has its own database connection. When we manipulate the database via factroy.makeSomething(), the connetcion of the web server does not "see" any change, if we don't commit(). Also, I think we get an error message if we don't commit when the web server accesses the DB after a factory.mkeWhatever() call. Just re
<kfogel> adeuring: thanks.  I'll respond to mwhudson with that.
<kfogel> adeuring, intellectronica: advice: I'd like to change the "package" column to be called "target" in the patches view, because sometimes it's a package and sometimes it's a product (e.g., if you show the patches view on a project group).
<kfogel> Thoughts?
<adeuring> kfogel: sounds good. But there is another option, ii think
<kfogel> ?
<adeuring> you can display "package", if the context is a distribution or distroseries,
<adeuring> and you can display "project" if the context is a project group
<intellectronica> kfogel: wouldn't it be better to title it dynamically, depending on what kind of target it is? i don't think we use 'target' anywhere in the UI.
<intellectronica> adeuring: high five!
<adeuring> kfogel, intellectronica: though things will become messy with this approach when we have a patches view for persons...
<adeuring> kfogel: ignoring the IPersoncontext, you could get the right column name for the current context from a browser class property.
<kfogel> adeuring, intellectronica: So here's why I didn't propose the conditional solution: is it possible that the same view (same column) may display multiple types of targets?
<adeuring> kfogel: yeah, now you mention this...
<adeuring> if we have a bug with emough targets, that will happen...
<adeuring> e.g., a bug where target 1 is a package and target 2 is a project
<intellectronica> but don't we only deal with one target at a time?
<kfogel> adeuring: well, it's not a matter of quantity, it's just that it could happen -- heck, maybe I could make it happen right now with project group, by attaching a bugtask to a package in a project in that group?
<adeuring> kfogel: sure
<kfogel> intellectronica: let me see if I can actually make this happen here
<intellectronica> i mean, doesn't the patches view filter only bug tasks for a single target (unless it's a distro)?
<kfogel> intellectronica: distro, or project group,...
<adeuring> intellectronica: but distros are the context where we need this "target/"Pakcages" column...
<kfogel> intellectronica: and when the view is on a product, then it shows different src packages
<intellectronica> in fact, maybe you also want to hide that column if it's not a distro or a project group
<kfogel> intellectronica: we do
<kfogel> intellectronica: that is, we hide that column whenever it's not applicable
<intellectronica> cool, so i think you should be safe to use either 'project' or 'package' depending on the type of the context
<adeuring> intellectronica: really? If we run serachTasks() for a disto, are butasks for projects indeed not included?
<adeuring> s/butasks/bugtasks/
<intellectronica> adeuring: correct
<adeuring> intellectronica, kfogel: OK, then it makes sense to display a more specific column title that "target"
<adeuring> ...provided that distro-related bugtasks a not returened for IProject.searchTasks()
<intellectronica> the problem with 'target' is that users will confuse it with release-management. we never use target in the UI to mean what it means in the code
<kfogel> intellectronica: good point
<kfogel> adeuring: that's what I'm trying to confirm right now, re distro-related bugtasks, and also project-group-related bugtasks.
<kfogel> adeuring: in https://bugs.launchpad.dev/evolution/+patches, we don't show the "Package" column.  Was this on purpose?  If there's a bugtask on a package related to the evolution product, do we not want to show that in bugs targeting evolution itself?  (I can see a case both ways...)
<adeuring> kfogel: yes, because evolution is project (or IProduct)
<kfogel> adeuring: "yes, we don't want to show package bugtasks" ?
<adeuring> kfogel: well, let's double-check what searchTasks() returns in this case...
<kfogel> adeuring: I'm trying to do that via the UI right now, yep.
<adeuring> kfogel: bugs/model/bugtask.py, line 1492: extra_clauses.append("BugTask.product = Product.id")
<adeuring> so, only bugtasks for the current project(IProduct) are retuned
<adeuring> erm, returned
<kfogel> adeuring: so trusting of the code... :-)
<adeuring> yeah ;)
<kfogel> adeuring: but yes, you're probably right.  I'm trying it in the UI anyway, just to make sure.
<adeuring> kfogel: sure, that's always better, considering the famous remark by Mr. Knuth about proving corretness and testing code ;)
<kfogel> adeuring: okay, I filed this with a patch attachment: https://bugs.launchpad.dev/ubuntu/+source/evolution/+bug/25 .
<mup> Bug #25: Allow discussion/commenting on translations <feature> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/25>
<kfogel> BUT, it does not show up in https://bugs.launchpad.dev/evolution/+patches
<kfogel> adeuring: what's that remark?  I don't know it.
<adeuring> something like "beware with the code above. While Iproved its correctness, I did not run it"
<adeuring> kfogel: from /usr/share/games/fortunes/computers; Beware of bugs in the above code; I have only proved it correct, not tried it.   -- Donald Knuth
<kfogel> nice :-)
<jamalta> so i'm having this issue
<jamalta> https://lists.launchpad.net/launchpad-dev/msg02281.html
<jamalta> i've tried rocketfuel-get, but that doesn't seem to solve the problem
<jamalta> and running the mentioned script tells me "Bazaar Explorer requires QBzr. Please install it and try again." but i have both bzr-explorer and qbzr installed.
<mars> jamalta, running rocketfuel-get complains about qbzr?
<jamalta> nvm, i think i found my problem
<jamalta> mars: no the utilities/update-sourcecode script
<jamalta> my problem is that rocketfuel-get was failing to download anything because of my proxy :)
<jamalta> this time it should be able to solve the problem
<lifeless> jml: nice patch
<jamalta> i lied, i still can't run launchpad
<jamalta> i installed bzr-builder from apt, so i can import bzrlib.plugins.builder.recipe from the python interpreter
<jamalta> but make run still complaints it can't import it
<jamalta> here is what make run is giving me http://paste.ubuntu.com/367682/
<thekorn> jamalta, I had something similar yesterday, after running make clean & make this was solved for me
<jamalta> thekorn: thanks
<jamalta> thekorn: make fails with the same error :(
<lifeless> do you have builder in your optional bzrplugins dir ?
<jamalta> lifeless: where is the optional bzrplugins dir?
<jamalta> ignore that question
<jamalta> there is a broken symlink there
<jamalta> hmm.
<jamalta> that explains a lot
<jamalta> sourcecode/bzr-builder was gone
<jamalta> s/was/is
 * jamalta sighs
<jamalta> still having the issue, this is strange
<jamalta> am i supposed to have a sourcecode/bzr-builder?
<jml> jamalta, I think so.
<jml> lifeless, the subunit-by-default one or the on-edge one?
<jamalta> jml: So how can I get it? rocketfuel-get is not fetching it and I'm not quite sure how I lost it in the first place
<jamalta> Unless it was recently added, in which case, I don't have it
<lifeless> jml: subunit
<jml> jamalta, it was added recently, I think. I'm not sure about rocketfuel-get
 * jamalta has a feeling that's what scripts/update-sourcecode is for
<jml> jamalta, yeah, run that.
<lifeless> jml: the on-edge one is  intereseting too; I haven't read the code though, so can't comment about it so much :)
<jamalta> jml: i can't
<jamalta> ok now i can
<jml> lifeless, heh heh.
<jamalta> Having bzr-explorer installed on my system broke it for some odd reason
<jml> poolie, can you please add a commit message to https://code.launchpad.net/~mbp/launchpad/436294-review-mails/+merge/18227
<poolie> oh sure
<jml> poolie, you don't have to bother with any of the tags.
<jml> poolie, just something meaningful with no newlinesn
<poolie> done
<jml> poolie, thanks.
<kfogel> adeuring: (back from an early lunch)  So, TAL conditions can only be Booleans, right?  But I can do tal:condition="python: arbitrary python code here resulting in boolean"
<jml> poolie, fwiw, if you have a commit message and an approved proposal, any Launchpad dev can land it with './utilities/ec2 land <merge_proposal_url>'
<jml> poolie, so there's rarely an excuse for a delay in landing
<jml> dev w/ commit access, I guess I should say. old habits die hard.
<kfogel> jml: when one uses that script, the MP "commit message" is used as the commit message, right?
<adeuring> kfogel: yes you can do that. But tal:condition can take anything that _evaluates_ to true/false
<jml> kfogel, mostly
<jml> kfogel, it also automatically does the [r=oaue][ui=aoueo][bug=4234,908034] stuff
<kfogel> jml: ah, ok
<jml> kfogel, which I was sick of figuring out manually
<kfogel> adeuring: here's what I'm solving: we're going to choose the presence or absence of that patches view column, and (if present!) choose its ("package" vs "project") in a conditional way.
<kfogel> s/its/its name/  sorry
<adeuring> kfogel: I think the best readable version for this would be to add a property to the the browser.
<kfogel> adeuring: "target_name" or something?
<kfogel> target_type ?
<adeuring> kfogel: right, or target_column_header_name
<kfogel> adeuring: so the idea is, if browser.shouldShowTargetName is true, then we choose the column name based on that property
<james_w> noodles775: it's not landed as I don't have the rights to do so, and I think the review tweaks still need to be made
<adeuring> kfogel: yes
<kfogel> adeuring: beautifulicious
<kfogel> adeuring: on it
<kfogel> adeuring: what's status of patch-age-sort db patch?  landing today you think?
<adeuring> kfogel: I'm still waiting for a second DB review...
<james_w> noodles775: and nice spot on the distroseries argument, it just needs to be removed from the interface
<adeuring> kfogel: my point for using a browser property is: something "if IDistribution.providedBy(context)" in a tal expression tends to look quite ugly. And I am not sure if/how we can import IDistribution into a TAL expression...
<kfogel> adeuring: I was considering a route where shouldShowTargetName() becomes a non-boolean method 'targetName()', and returns either a column name or None, and then the .pt file is adjusted accordingly.  Do you think that way is better or your way is better?
<kfogel> adeuring: who was your first db review?  jml?
<adeuring> kfogel: no, it was stub
<kfogel> adeuring: rhetorically, just to shoot the breeze here in the channel, I will ask you if jml is aware of the urgency of this db patch getting in?
<adeuring> ahh, I see jml. jml, could you have a look at this mp https://code.edge.launchpad.net/~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort/+merge/18446 ?
<adeuring> kfogel: yes, you can do something like tal:define="target_name view/target_name" tal:condition="target_name"
<thekorn> hi allenap. does lp:~allenap/launchpad/patch-report-for-people-and-teams-bug-506018 in any way interfere with my work on making searchTasks() available for persons?
<adeuring> kfogel: thouhg i need to double-check if these expression can go into the same XML tag
<kfogel> adeuring: oh, if a TAL condition expr evaluates to None, then it is treated as false?  That's considered okay?
<allenap> thekorn: No it won't, it'll be fine.
<adeuring> kfogel: yes. I think an empty string also evaluates to False, for example
<kfogel> adeuring: (style-wise, I mean)
<kfogel> adeuring: in Python yes, but I never assume TAL == Python.
<noodles775> james_w: great, I'll take it from there then. Thanks!
<thekorn> allenap, ok, super
<james_w> thanks noodles775
<kfogel> adeuring: $ python
<kfogel> Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15)
<kfogel> [GCC 4.4.1] on linux2
<kfogel> Type "help", "copyright", "credits" or "license" for more information.
<kfogel> >>> TAL == Python
<kfogel> Traceback (most recent call last):
<jml> hi
<adeuring> kfogel: yes, I think that's ok -- at least i would do the reveiw ;)
<kfogel>   File "<stdin>", line 1, in <module>
<kfogel> NameError: name 'TAL' is not defined
<kfogel> >>>
<kfogel> see? :-)
<jml> adeuring, kfogel: you have some stuff for me, I see :)
<jml> I'll take a look
<jml> it's got conflicts.
<adeuring> jml: yes, this branch: https://code.edge.launchpad.net/~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort/+merge/18446
<kfogel> adeuring: and in the UI, the column name for a Product should be "Project", right?
<adeuring> kfogel: yes
<adeuring> jml: sigh, yes, I see the conflicts now too...
<adeuring> jml: let me merge db-devel again
<jml> adeuring, np.
<jml> has this patch been discussed before?
<jamalta> Are API permissions defined by configure.zcml?
<allenap> jamalta: Yes. But then see security.py for where the permissions are actually checked.
<jamalta> allenap: thanks
<jamalta> allenap: thanks!
<allenap> jamalta: Welcome :) You might not be saying that once you've read security.py ;)
<jamalta> allenap: It's not too bad! I think I found what I needed actually
<jamalta> Much easier than reading configure.zcml ;)
<adeuring> jml: yes, I sent a mail to the lp-dev list (last Thursday, I think), and I discussed with stub some problems that we have without the schema change. Basically, it boils down to Storm bot supporting DINSTINCT ON (column name) and to nest query like SELCT * from (SELECT ... ) ORDER BY ...
<allenap> jamalta: Cool.
<jml> adeuring, ok, thanks.
<jml> adeuring, it's all fine by me.
<adeuring> jml:  great, thanks!
 * adeuring needs to restart X. windows are not properly redrawn. back in two minutes...
<allenap> thekorn: Sorry, I'm just looking at your branch. I think the approach of moving IHasBugs.official_bug_tags into a new interface would be better than moving searchTasks().
<allenap> thekorn: Person already implements all of IHasBugs because it inherits HasBugsBase, with the exception of official_bug_tags. I'm not sure why that was put on IHasBugs, it doesn't belong there, but I don't think it'll be a big job to move it.
<kfogel> adeuring: I have this memory that the exact name "shouldShowTargetName" is something we used because it would have certain effects elsewhere, not merely to match a previously-existing view's method name.  Should I be worried about changing it to targetName or whatever?  http://paste.ubuntu.com/367724/ for kicks
<kfogel> I see that lib/lp/bugs/templates/bugtarget-macros-search.pt uses it, but I'm not sure that matters for us, since it's presumably referring to the one in bugtask.py.
<allenap> thekorn: A few changes are in my branch at lp:~allenap/launchpad/make_iperson_ihasbugs. I'll test it overnight and see what breaks.
<adeuring> kfogel: I think we can choose any name, as long as we won't mess with bugtarget-macros-search.pt.
 * adeuring would prefer to do that, but others disagree
<kfogel> adeuring: we haven't edited bugtarget-macros-search.pt AFAIK, so we shouldn't affect it.
<adeuring> kfogel: xactly.
<thekorn> allenap, actually I'm fine with any solution, as long as the resulting person obect does not have an official_bug_tags attribute, I'll look what you have in your branch tomorrow
<thekorn> allenap, there is one thing left for me, I don't know how detailed the tests must be, how many of them are needed, and especially where to put them
<mpt> sinzui, are you available to talk about USC ratings and reviews?
<sinzui> mpt: I may have time this week
<mpt> sinzui, we're getting kind of concerned since we have only two weeks until Feature Freeze
<sinzui> mpt: I cannot start working on it until this weekend. I will not work on it during my core hours. My team must catchup the work it lost because of spammers
<jamalta> So I'm looking into figuring out how to solve bug #515761 and I'm completely stumped. I can't find anything in configure.zcml and security.py that excludes public access to a project's series
<mup> Bug #515761: Not able to access project releases anonymously <launchpadlib :New> <https://launchpad.net/bugs/515761>
<jamalta> Is there something obvious I could be missing? I don't really want to waste anyones time with this :)
<james_w> did edge rollout in the last 12 hours?
<thekorn> allenap, I thought about what you said again, I we move official_bug_tags away from IHasBugs, I think we would have similar problems with getUsedBugTagsWithOpenCounts() and getUsedBugTags()
<thekorn> where should this methods go?
<kfogel> adeuring: want to re-review https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report ?  It's changed a lot.  (My latest comment on https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428 has details, actually.)
<adeuring> kfogel: yes, I'll have a look
<kfogel> adeuring: also, I think I should now make an integration branch that includes lp:~kfogel/launchpad/506018-patch-report, lp:~intellectronica/launchpad/no-patches-message, your branch (which should be attached to https://bugs.edge.launchpad.net/malone/+bug/512500 but isn't? :-) ), and lp:~allenap/launchpad/patch-report-for-people-and-teams-bug-506018 .
<mup> Bug #512500: In patches view, offer sorting on patch age. <story-patch-report> <Launchpad Bugs:Triaged by kfogel> <https://launchpad.net/bugs/512500>
<kfogel> ah, https://code.edge.launchpad.net/~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort/+merge/18446, got it now
<adeuring> kfogel: that branch went into ec2test just 30 minutes ago...
<kfogel> adeuring: ah, ok.  But we still need to test all these things together, right?
<kfogel> No one has put all four branches together in one instance, AFAIK.
 * kfogel afk to put laundry in dryer, bbiab
<adeuring> kfogel: if you simpyl merge tehse brnaches, I think sepaeate tests are not necessary. Only when you actually add more code, you'll need new tests
 * adeuring is afk for dinner
<kfogel> adeuring: well, we shouldn't be adding more code; there are a couple of minor conflicts to resolve, but they're trivial.
<mwhudson> adeuring: i think you're mistaken about how page tests work, btw
<mwhudson> there's no web server
<mwhudson> the testbrowser talks to the publication code directly, there isn't network-level stuff
<sesammases> where in the code tree do I find the entry point for the "answers" subsite?
<mwhudson> sesammases: ./lib/lp/answers
<bac> abentley: you indicate in the whiteboard that you were going to follow up on https://code.edge.launchpad.net/~davidcaste/eopsoa/trunk
<abentley> bac, yes.  I actually wanted to talk to mwhudson about that.
<mwhudson> oh right
<sesammases> thx :)
<abentley> mwhudson, are you on duty?
<mwhudson> abentley: yeah
<abentley> mwhudson, skype?
<mwhudson> abentley: one sec
<mwhudson> abentley: ok
<abentley> mwhudson, I don't see you on Skype.
<adeuring> mwhudson: right, there is no "real" webserver, but I maintain that the "server side" of a pagetest uses a different DB connection that that we use directly in tests to manipulate test data
<adeuring> kfogel: what is the revision of your branch that Tome reviewed?
<kfogel> adeuring: oh, wow, let me see
<adeuring> kfogel: sorry, didn't yet start th review -- had to fill my stomach first...
<kfogel> adeuring: np (I was also (re)filling mine)
<abentley> mwhudson, 516222
<kfogel> adeuring: I *think* it was roughly http://bazaar.launchpad.net/%7Ekfogel/launchpad/506018-patch-report/revision/10175
<kfogel> give or take a rev or two
<adeuring> kfogel: ok
<mwhudson> adeuring: i'm still a bit sceptical of that, but i can't be bothered to check now...
<kfogel> adeuring: I'm getting tangled up here thinking about this question: if I want to put all four branches together just to do some manual testing, should I base the "root" branch from devel or db-devel?
<kfogel> yours is the only one with db patches
<adeuring> kfogel: ca't you simply merge one branch into [db-]devel, then merge the next brach and so on?
<adeuring> mwhudson: are you sure that DB changes in page tests without  login() and commit() calls work?
<mwhudson> adeuring: you need to login() and logout() yes
<kfogel> adeuring: oh, I'm trying that
<kfogel> adeuring: can think of various reasons why it "shouldn't" work, but I'm probably over-theorizing.
<mwhudson> adeuring: but look at, say, the bottom of lp/code/stories/codeimport/xx-codeimport-view.txt
<adeuring> mwhudson: oh, yes, now I get it. thanks!
<james_w> any chance of a CP for the task_age fix? It's not on edge so I'm still blocked.
<kfogel> dang it, bzr merge lp:~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort/+merge/18446 should work!
<adeuring> kfogel: yes, but then you can't any longer merge to devel, due to the DB patches in my branch
<kfogel> adeuring: no, I mean merging a merge proposal should work
<kfogel> adeuring: instead of a branch (i.e., treat it like the branch it refers to)
<adeuring> kfogel: interesting...
<kfogel> adeuring: Assuming all the branches have been approved, I can land them all with the appropriate "[r=foo]" from the MP, right?
<kfogel> adeuring: and I land three of them on devel and one on db-devel, right?
<kfogel> adeuring: (I'm not landing any until I've got the integration branch running here -- I want to see this stuff all play together first)
<adeuring> kfogel: yes. But again, there is not real point yet for you to merge my branch, because it just contains the DB schema, no real code. I'll try to finish a branch that implements the new sort order for searchTasks() this evening.
<kfogel> adeuring: oh!  I didn't realize that, sorry.
<kfogel> adeuring: okay, then I won't try to land your branch.  But I _will_ try to get the others into devel today/tonight.
<adeuring> kfogel: yeah, makes sense
<kfogel> adeuring: though since I've just done the work, I'm going to run with your new db schema and see what happens :-).
<kfogel> adeuring: people.canonical.com/~kfogel/patches-view/512500-current-dev-sql.diff in case you want my test data
<adeuring> kfogel: no, sorry, need to focus now on my own brnach ;)
<kfogel> adeuring: that's for your branch!
<kfogel> adeuring: "I'm only trying to help you because I love you, honey..."
<adeuring> kfogel: ah, sorry... my fault... seems to be too late for me proper read IRC channels...
<kfogel> adeuring: except, it seems it's broken, one sec, trivial fix
<kfogel> adeuring: okay, fixed up that diff.  And it's working for me, in an integration branch that includes your db changes.
<adeuring> kfogel: great
<kfogel> adeuring: http://paste.ubuntu.com/367826/  (some sample URLs under launchpad.dev for you)
<adeuring> kfogel: thanks!
<kfogel> adeuring: no problem.  oh, I think the "https://bugs.launchpad.dev/ubuntu/warty/+source/evolution" URL should be https://bugs.launchpad.dev/ubuntu/warty/+source/evolution/+patches
<kfogel> sigh
<kfogel> will fix up and make a new reference paste
<Ursinha> rockstar: hi
<rockstar> Ursinha, hi back
<kfogel> http://paste.ubuntu.com/367828/
<Ursinha> rockstar: :) don't know if you saw jtv's request earlier today, about bug 356360
<mup> Bug #356360: API call for finding branches that contain a revid <api> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/356360>
<rockstar> Ursinha, I did.
<rockstar> Ursinha, I don't think that will happen for a while though.
<rockstar> I started work on it, but after talking with thumper about the Revision table, it would be work that would just get removed.
<rockstar> We want to change how we gather revisions.
<Ursinha> rockstar: hm.. I see
<rockstar> Ursinha, did you see abentley's comment?
<Ursinha> rockstar: let me explain why that would be useful
<Ursinha> rockstar: reading now
<rockstar> He (as usual) has a good point.
<Ursinha> rockstar: I need to know the merged branch to be able to get the bugs linked to it, right?
<rockstar> Ursinha, yes.
<rockstar> Ursinha, also, we put the bug numbers in the PQM commit message.
<Ursinha> rockstar: all this work would be to avoid that
<Ursinha> rockstar: it would be great if that never fails, but it does, so I'm trying to find another approach
<rockstar> Ursinha, well, I'm not sure if we'll be able to provide a better approach soon.  :(
<Ursinha> rockstar: to migrate all teams to the tagging schema, we'd like to get rid of the wiki pages
<rockstar> Ursinha, you could always mail thumper.  He's in London this week, but putting a bug in his ear about it being important for QA might help.
<Ursinha> rockstar: to get rid of the wiki pages, I'm searching for a safe approach to just ignore orphaned commits
<abentley> Ursinha, it should be easy to find all the merged branches.  If it's not, we can tweak the API.
<Ursinha> rockstar: so, it would be good to be able to rely on the bug added to the commit message by the ec2 script, but not everyone here uses that
<Ursinha> rockstar: what I found out is that I can get the branch-nick in the revision properties, but it turns out not all revisions have that
<Ursinha> having the branch-nick, I can guess the branch url and search for it using the API
<Ursinha> rockstar: but not having that, I have no way out
<Ursinha> abentley: how?
<Ursinha> abentley: how to find the merged branches using bzrlib, I mean
<abentley> Ursinha, look for the merge proposals that are marked merged.
<Ursinha> abentley: how do I correlate that with the revision?
<abentley> Ursinha, why do you want to start with the revision?
<Ursinha> abentley: because when I see a new one in the branches I monitor (stable and db-devel) that triggers the tagging of the bug fixed by that
<Ursinha> unless I start to monitor the branches being merged instead of the main branches
<Ursinha> by main branches I mean stable and devel
<abentley> Ursinha, why not look at branches merged into stable and devel instead of revisions committed to stable and devel?
<Ursinha> abentley: could be an option, just haven't thought about that yet :)
<Ursinha> abentley: this revision thing is how it works today
<abentley> Code is already tracking which branches fix which bugs and which branches have been merged into their targets, so there's an opportunity to avoid double work here.
<Ursinha> abentley: good. I'll look into that
<Ursinha> thanks for the idea
<Ursinha> thanks rockstar
<abentley> No problem.
<adeuring> kfogel: sorting by creation date of most recnetly added patch is now possible in bugtarget.searchTasks(). lp:~adeuring/launchpad/bug-512500-model-change
<adeuring> I'm still waiting for the base branch to run through ec2, so I'm not yet submitting this one for review.
<adeuring> kfogel: simply use  bugtarget.searchTasks(orderby='latest_patch_uploaded')
<adeuring> sigh.. I meant '-latest_patch_uploaded', for the +patches view
<mwhudson> abentley: https://code.edge.launchpad.net/~mwhudson/launchpad/ssl-imports-bug-512763/+merge/18479
<abentley> mwhudson, what would you think about providing that comment on force_bzr_to_use_urllib as a docstring?
<mwhudson> abentley: i guess it's slightly better
<abentley> mwhudson: r=me, preferably with that docstring.
<mwhudson> abentley: ok
<mwhudson> abentley: thanks
<abentley> mwhudson, np.
#launchpad-dev 2010-02-03
<wgrant> spm: Around? bug #514074 has been going on for a few days now, and I think it's probably a sysadmin/LOSA thing.
<mup> Bug #514074: PGP fingerprint registration fails to find key <pgp> <Launchpad Foundations:New> <https://launchpad.net/bugs/514074>
<spm> hrm. I have a sneaking suspicion I may know what's causing that....
<wgrant> Is keyserver.internal not syncing with the rest?
<didrocks> do you know if there is some plan to upgrade the launchpad bzr branch to fix bug #513432? (I'm stuck for installing LP on lucid to expose some new element on the API)
<mup> Bug #513432: AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo' <fetch> <Bazaar:Fix Released by mbp> <Bazaar 2.0:Invalid> <Bazaar 2.1:Fix Released by mbp> <Launchpad Bazaar Integration:Confirmed for mwhudson> <https://launchpad.net/bugs/513432>
<james_w> didrocks: you can't work around it?
<didrocks> james_w: I guess I have to init-repo 0.92 format, right?
<didrocks> so, change the lp-rocket script?
<james_w> didrocks: I'll find you.
<didrocks> james_w: thanks, just one sec, getting some coffee right now :)
<wgrant> I can't see which branch would be problematic, though.
<wgrant> spm: Any luck? (I suspect this will affect me tomorrow, so I'm fairly interested)
<spm> wgrant: not yet unf; I'm about 2-3 layers down in higher priority interrupts atm. sorry... :-/
<wgrant> Ah, right.
<mwhudson> well, getting online in town was a bit more of an adventure than i expected
<abentley> mwhudson, surprised.  The nets were favourable at LCA.
<mwhudson> abentley: yeah, it was a bit strange
<mwhudson> abentley: i'm now in the library about 150m from the lca venue and it's working fine :)
<abentley> :-)
<mwhudson> i had a 70000 (yes 70 seconds) ping to python.org from the other place i tried
<wgrant> Does Wellington's Internet somehow break when it no longer has the extra load of 700 geeks?
<mwhudson> it's possible the access points got rebooted more aggressively that week or something
<mwhudson> right, time to go and see some dotty art
<MTecknology> 150m ??
<MTecknology> I'm getting ~30kb/s between my two systems trying to doanlowd ~200MB
<kfogel> Anyone here who can do UI review?
<kfogel> stub: if code review has approved https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report, and martin's UI review said "need fixing" but then I fixed all the things he said need fixing, is it okay to land it?
<kfogel> stub: my intuition is yes, but I don't want to step on any toes.
<stub> Need Fixing means they want to see it again.
<kfogel> stub: thanks.  Second question is finding someone who can do UI review right now, then :-).
<stub> You can get Approved conditional on changing stuff
<stub> That wouldn't be me then :)
<kfogel> stub: ah, I see.
<kfogel> yeah, I wonder if the dev wiki lists ui reviewers, let's see...
<kfogel> stub: https://dev.launchpad.net/ReviewerSchedule   pretty much everyone is EU/Americas right now.  Oh well.
<kfogel> spm: okay, ready for some questions.  http://paste.ubuntu.com/368019/ lists five branches, in various states of review (some can be landed now, some need review or re-review first).  For the purposes of argument, let's say they're all approved already, so we can focus on the mechanics of landing.  Three of the branches are against devel, two are against db-devel.  The goal is to have the total (all five) live on staging.  Would I land
<kfogel>  the three devel ones on devel, the two db-devel on db-devel, and then... anything special to do after that?
<kfogel> I see I stumped him :-)
<spm> yup
<spm> I think I know the answer, just confirming :-)
<spm> ahh this is what I was looking for. it's moved. https://dev.launchpad.net/Trunk
<spm> yup. land on devel 1st; when that gets thru to db-devel; land against db-devel. from a high level.
<wgrant> Is there any point in landing the first one separately?
<spm> so it gets to edge?
<spm> or is your meaning; why not merge the 1st 3 into one mega merge?
<wgrant> It's not clear that the second and third are related, but they both include the first so landing it separately seems pointless.
<spm> ahh. that'd be code issues - /me hands that Q back to kfogel :-)
<kfogel> spm: one of these db-devel branches has no dependencies on the others, and is approved.  I assume I can land that one now, right?
<kfogel> wgrant: as for how to land them, yes, I may do it all as one mega merge.
<kfogel> wgrant: point is, they all need to be approved first -- separately.
<kfogel> spm: specifically, https://code.edge.launchpad.net/~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort/+merge/18446  seems approved.  I'm not sure it's landed yet.  I know it passes tests because I just ran them on a mega-integration branch :-).
<kfogel> if it hasn't landed, I'm going to land it
 * kfogel issues fair warning
<spm> kfogel: ...
<spm> kfogel: yeah that looks fine; stub's given the nod and he's the one I know needs to care about db-devel landings
<kfogel> spm: oh, wait, I forgot to mention that there are *slight* conflicts (trivial) between some of these branches.  I already resolved them once in my integration branch, so I may just land that when the time comes.
<spm> oh?
<spm> being ware that if BB can't merge; it'll reject
<spm> heh (evil grin ON) much a losa does when doing a manual merge.....
<kfogel> spm: what does "can't merge" here mean?  If I've resolved the conflicts in my mega-integration branch, and that's the branch I land, then it's okay, right?
<spm> kfogel: rephrasing - if you submit a branch; and "something/one" goes to merge against their version of the code; and it fails. Boom.
<kfogel> spm: sure.  But I don't see why it would fail to merge, in this case, that's all.
<spm> ie. you need to verify your branch (whichever one you submit) works as a merge against, eg, db-devel
<kfogel> spm: *nod*
<spm> so if it has a trivial conflict; it's still a conflict
<spm> kinda thing....
<kfogel> spm: sure, but I resolved those (on the integration branch)
<spm> sweet, shouldn't be a problem then. and we can all igore the last 5 minutes of conversation. :-D
<kfogel> spm: interesting -- in all of db-devel, two revisions seem to have a pqm commit message of the form "[db=foo]"; all the rest use "[r=foo]" :-)
<spm> I'd put down a small wager that was eitehr one of us; or stub, getting bored. :-)
<spm> [db=foo] doesn't appear to be in the RE, so that should be fine
<kfogel> spm: sanity check: bzr pqm-submit --submit-branch=lp:~launchpad-pqm/launchpad/db-devel -m "[r=stub,jml][bug=512500] Add Bug.latest_patch_uploaded column, to allow efficient sorting by patch age."
<spm> looks good to me
<kfogel> spm: holy cow, PQM is backed up though.  I guess this'll be landing in 2012 sometime.
<spm> oh oh....
<kfogel> spm: btw, I got this error, because it's abel's branch not mine:
<kfogel> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~kfogel/launchpad/bug-512500-searchtasks-patch-age-sort/".
<kfogel> I don't see an option to pqm-submit to tell it "use ~adeuring/... instead of ~kfogel/..." though
<wgrant> Most people seem to use 'ec2 land' or push the branch up themselves.
<wgrant> I'm not sure if there's another way.
<spm> kfogel: https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadRollout <== under prep there's a complete submit we/I use for config submissions. that may help? I've used that to land eg branches from francis.
<kfogel> spm: thanks
<kfogel> wgrant: I've already run through ec2, so don't want to reintroduce that delay
<kfogel> spm: hunh, looks like the '--public-location' option of bzr pqm-submit might be useful here.  I've been trying to figure out what it's doc means :-).
<kfogel> "Use this url as the public location to the pqm." is not exactly crystal clear
<kfogel> spm: this worked (I think) -- http://paste.ubuntu.com/368037/
<spm> kfogel: if any consolation, when I worked that recipie out istr I was almost at the level of bliding trying random configs in the hope something worked. :-)
<spm> s/bliding/blindly/
<kfogel> spm: pqm is to code submission as reed snorkel is to traversing arctic sea under ice?
<spm> on the grounds of living near to lead dev for same - ie thumping range: No Comment.
<kfogel> spm: I'm a little worried -- pqm.launchpad.net says "Wed Feb 3 07:01:51 2010 UTC: Karl Fogel <karl.fogel@canonical.com>, Request for non-PQM managed branch."
<kfogel> spm: I was trying to land abel's branch *onto* db-devel, and I thought db-devel is a PQM managed branch.  So why that message in the queue (currently #16, at the bottom)?
<spm> hrm. I suspect the syntax may be backwards on the submit; I'll check the mesg
<kfogel> spm: ack, sorry.  I can redo w/ reverse values to the options...
<al-maisan> kfogel: did you use "--submit-branch=ARG" ?
<kfogel> spm: you know, reverse values, like http://paste.ubuntu.com/368039/    (/me giggles)
<kfogel> al-maisan: I used both --submit-branch and --public-branch, and fear I messed it up.  I'm submitting a branch of adeuring's, not my own branch.
 * spm falls out of chair; hurts self laughing and sues the pants offa kfogel
<al-maisan> --submit-branch is probably all you need
<kfogel> al-maisan: my exact command is here: http://paste.ubuntu.com/368037/
<kfogel> al-maisan: no, that got an error (is backscroll available to you?)
 * al-maisan looks
<kfogel> al-maisan: here, I'll clarify:
<kfogel> I originally did this:
<kfogel>   1) I branched lp:~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort locally
<kfogel>   2) I cd'd into that local branch
<kfogel>   3) I ran this pqm submit command: bzr pqm-submit --submit-branch=lp:~launchpad-pqm/launchpad/db-devel -m "[r=stub,jml][bug=512500] Add Bug.latest_patch_uploaded column, to allow efficient sorting by patch age."
<kfogel>  
<kfogel> That got me an error:
<kfogel> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~kfogel/launchpad/bug-512500-searchtasks-patch-age-sort/"
<al-maisan> ah
<al-maisan> I see
<kfogel> al-maisan: ...okay, so it was looking in lp:~kfogel instead of lp:~adeuring.  How to tell it to use the lp: branch where my local branch "came from", not the branch it "would go to" if I pushed?
<al-maisan> just a second
<kfogel> al-maisan: so next, I tried http://paste.ubuntu.com/368037/  (just so you're up to date)
<kfogel> al-maisan: and that got the result that the PQM queue at pqm.launchpad.net has a weird message at the bottom of the queue now:
<kfogel> "Wed Feb 3 07:01:51 2010 UTC: Karl Fogel <karl.fogel@canonical.com>, Request for non-PQM managed branch."
<kfogel> al-maisan: that's where we are now.
<al-maisan> kfogel: I believe for '--submit-branch' you should use the uri syntax from ~/.bazaar/locations.conf
<kfogel> al-maisan: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel  ?
<al-maisan> i.e. --submit-branch=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel
<kfogel> :-)
<al-maisan> :)
<kfogel> spm: wanna get my dud out of the queue, and I'll try al-maisan's suggestion above?
<spm> sure
<spm> gone
<al-maisan> kfogel: also, https://dev.launchpad.net/WorkingWithDbDevel
<spm> (fwiw, was prepping to do just that, figuring it'd be needed shortly)
<kfogel> spm: nice magic wand you got there
<kfogel> al-maisan: thank you!
 * kfogel reads
<al-maisan> last section: "Submitting to PQM"
<al-maisan> Even Minotaur would be proud of the labyrinth called launchpad (development) .. *sigh*
 * spm bows in admiration to al-maisan for THAT line
 * al-maisan blushes
<stub> If you want to land abel's branch, you don't need to fake things with --public-location. Just tell pqm to land it (bzr pqm-submit -m 'comment' --submit-branch=bzr+ssh://... bzr+ssh://bazaar.launchpad.net/~abel/...
<kfogel> stub: just pass abel's branch as a direct argument?
<stub> Yes. bzr pqm-submit --help gives you the command line syntax
<stub> No need to stuff around with local branches - its not like pqm can access your hard drive.
<kfogel> stub: Thank you.  Believe me, I've been poring over that help quite a bit :-).  It doesn't make clear when one can/can't use the "lp:" shorthand, and the difference between --submit-branch and --public-location is not clear.
<stub> Glitches are bits of pqm can't cope with lp: urls and you need to explicitly specify --submit-branch because you likely haven't got abel's launchpad branches configured in your locations.conf
<kfogel> stub: yeah, I thought it looked in the local branch to divine the upstream lp branch to submit, but if there's a way to just tell it, then... no need.
<kfogel> right, I don't have anything in locations.conf about it
<stub> Use bzr+ssh: all the time for pqm - I think they work in some bits, but no idea which bits they are
<kfogel> stub: http://paste.ubuntu.com/368044/
<stub> Bah
<kfogel> stub: if I did use --public-location, would adeuring's branch be the right arg to it?
<stub> Bah. Could have sworn that worked. echo "star-merge bzr+ssh://bazaar.launchpad.net/~abel/...  bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/foo-devel" | gpg --cl | mail pqm@canonical.com -s "merge message"
<stub> kfogel: Might work with --public-location
<kfogel> stub: I'll try.  I can always get spm to clean a dud out of the pqm queue again :-)
<spm> heh
<kfogel> stub: well, that seemed to succeed.  let me see what pqm front page says about it.
<kfogel> looks good to me!  item #16
<kfogel> spm: seriously, though: should I worry about the size of that pqm queue?
<spm> kfogel: nope
<spm> we have a real landing taking place; and the tests are... slow
<kfogel> spm: ok
<spm> it's still doing real work
<kfogel> stub: thanks
<spm> yeah, most recent, just a few mins ago. slowly but surely...
<noodles775> Howdy people
<spm> hey noodles775
<kfogel> hey noodles775
 * noodles775 waves to spm and kfogel 
<spm> huh. that'd be why mwh and myself were able to attempt to break buildbot with impunity earlier; all the merges are stuck behind pqm. win.
<kfogel> beuno: ping
<beuno> kfogel, hi
<kfogel> beuno: hey, morning
<kfogel> beuno: need some UI re-review on some branches.
<kfogel> beuno: actually, give me a sec and I'll point you to a mail with lots of nice info
<kfogel> beuno: this is all assuming you've NOTHING BETTER to do, of course :-)
<beuno> kfogel, I still need to get out of bed
<kfogel> beuno: what are you doing on IRC, man??
<beuno> but if you give me a link, I will get to it within the next few hours  :)
<beuno> kfogel, danilo got to the bathroom first!
<kfogel> beuno: https://lists.launchpad.net/launchpad-dev/msg02411.html
<kfogel> beuno: that mail gives context for what's going on.  The actual branches that need ui review are:
<kfogel> https://code.edge.launchpad.net/~allenap/launchpad/patch-report-for-people-and-teams-bug-506018/+merge/18414
<beuno> kfogel, cool, will feed back soon
<kfogel> https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428
<kfogel> and a re-review for this one:
<kfogel> https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report/+merge/18181
<kfogel> beuno: re that mail: I'm writing a followup in which I de-confuse something that is very confused toward the end of the mail.  sorry.  It's late here.
<beuno> and I'm still sleepy, so it should even out
<kfogel> heh
<kfogel> beuno: okay, followup sent
<kfogel> beuno: upshot is, there will probably be one more MP later that needs UI review ("patches view sorting by patch age" basically), in addition to the above.  But the new one doesn't exist yet.
<adeuring> good morning
<kfogel> adeuring: heh
<kfogel> adeuring: I'm about to go to bed -- see my email.
<kfogel> adeuring: good morning :-)
<kfogel> adeuring: but before I go to bed, let's coordinate a bit maybe?
<adeuring> hi kfogel, must have been a long for you,..
<adeuring> kfogel: yes, but let me find your mail first.
<kfogel> adeuring: well, it was punctuated by an amazing concert by Radu Lupu in Carnegie Hall, that's why I'm up now.
<kfogel> adeuring: https://lists.launchpad.net/launchpad-dev/msg02411.html
<kfogel> adeuring: note that right after, I send a followup that clarifies something confusing in the original post.
<kfogel> adeuring: (it's where I wrote the wrong summary line for the hypothetical merge proposal text; it'll be obvious)
<kfogel> adeuring: so, I'm going to go brush teeth and stuff while you read.  I'll check back here in some minutes.
<adeuring> kfogel: do you have screenshots for the ui re-review of lp:~kfogel/launchpad/506018-patch-report ?
<kfogel> adeuring: no, but I could make them
<kfogel> adeuring: hey, let me brain dump at you briefly about conflict resolution:
<kfogel> adeuring: some subsequent changes of 506018-patch-report trivially conflict with the other branches for which it is a prereq.  I've had to resolve them two or three times now, so I know them almost by heart :-).  It's that in the story test, "user_browser" became "anon_browser", and "expected_contents" became "contents".
<kfogel> And in factory.py, we init is_patch to the "_DEFAULT" object instead of None now, and test for that.
<kfogel> there might be some others, but they're equally trivial if so
<adeuring> kfogel: ok.
<kfogel> adeuring: now, would you like some screenshots?
<adeuring> kfogel: na, i think you should go to bed ;) I'M trying to understand what i need to do today, except to get a review for one of my branches
<kfogel> adeuring: main thing, I think, is actually implement the UI for patch age sorting.
<adeuring> kfogel: right.
<kfogel> adeuring: it's actually easy for me to make the screenshots, let me do that.  I have martin's three Ui comments right here in front of me anyway.
<kfogel> - Padding in the tooltips would be super nice
<kfogel> - I'd add an "Order by: " label to the ordering drop down, and drop the "by" from each option to improve readability
<kfogel> - Bug icons don't respect importance
<kfogel> adeuring: urrrrgh, just noticed a buglet: if you view patches by user:
<kfogel> https://bugs.launchpad.dev/~name16/+patches
<kfogel> the page says:
<kfogel> "Patch attachments in Foo Bar"
<kfogel> where Foo Bar is the person's name.
<kfogel> should be "for Foo Bar" or something.
<adeuring> kfogel: I like this ;)
<kfogel> you like the "in"?
<adeuring> kfogel: yes
<kfogel> adeuring: as a native speaker, I'm going to have to assert my authority here :-).
<adeuring> kfogel: yeah, I get the meaning .-- that's the reason why I like it
<kfogel> adeuring: okay, here you go:
<kfogel> http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-distroseries-2010-02-03.png
<kfogel> http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-no-patches-message-2010-02-03.png
<kfogel> http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-orderby-dropdown-2010-02-03.png
<kfogel> http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-padding-around-tooltip-has-orderby-label-bug-icon-respects-importance-2010-02-03.png
<kfogel> http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-project-group-2010-02-03.png
<adeuring> kfogel: thanks!
<kfogel> adeuring: before I go to bed, are you set?
<adeuring> kfogel: yes ;)
<kfogel> adeuring: beuno should be coming back soon, and has the list of things needing UI review, but might be good to confirm with him.
<kfogel> Okay, I'm off.
<kfogel> adeuring: thanks!  Sorry not to have had the new patch-age-sorting UI ready for you :-(.
<adeuring> kfogel: ok. BTW, I think my branch for sorting by patch age does not need a ui review, because it does not implement any UI chenages
<adeuring> kfogel: no problem with the patch age sorting still missing.
<kfogel> adeuring: (if I handed beuno your branch for UI review, it was an accident -- in fact, I think I *did* do that accidentally at one point, then deleted the MP right afterwards when I realized)
<kfogel> but you might have gotten an email about it
<adeuring> kfogel: ah, right, just tred to find that MP and got a 404
<kfogel> :-)
<kfogel> adeuring: let beuno know that was an accident when he comes back, please :-)
<adeuring> kfogel: sure
<kfogel> adeuring: ok, g'night for realz.  See you later.
<noodles775> Night kfogel
<kfogel> night noodles775
<adeuring> night kfogel
 * kfogel gets stuck in an infinite good night loop...
<thekorn> hi, after reading some launchpad code, I'm a bit confused. what is a Project, and what is a Product?
<thekorn> hmm, I think I got it now, it looks like for example "firefox" is called a "project" in the web UI, but internally it is implemented by IProduct
<thekorn> and IProject defines a super-project/project-group
<intellectronica> thekorn: IProduct is what is called in the UI a 'project', and IProject is what is called in the UI 'project group'. confusing, eh? :)
<asabil> hi all
<thekorn> it, is confusing! same with bug and tasks, in the web UI your can search for bugs, but get a list of tasks as the result
<thekorn> launchpad needs a glossar ;)
<asabil> what's the difference between the lp_person table and the person table ?
<intellectronica> thekorn: that's actually a good idea. maybe we should start one on the wiki
 * intellectronica doesn't know :-O
<thekorn> yeah, let's called it "launchpad speech for n00bs"
<thekorn> -ed
<asabil> anyone ?
<intellectronica> asabil: stub would probably know, but i can't see him online at the moment
<asabil> ok thanks, I will wait then
<wgrant> asabil: It's to do with integration with the Ubuntu SSO service. Ignore the lp_* tables.
<wgrant> (they should be identical copies of the corresponding non-lp_* tables -- eg. lp_person has the same content as person.)
<asabil> wgrant, that's what I see, but I don't really understand the purpose
<wgrant> asabil: We can't see the code that uses them, so that's not surprising.
<asabil> oki thanks
<thekorn> allenap, hi, I merged your official_bug_tags changes to my branch, now the xx-official-bug-tags.txt test is failing, http://paste.ubuntu.com/368114/
<thekorn> do you have any idea what's going wrong there?
<allenap> thekorn: I'll take a look..
<thekorn> thank you
<allenap> thekorn: It's because I made IOfficialBugTagTargetPublic.official_bug_tags read-only.
<thekorn> allenap, oh yeah, makking it readonly=False works
<allenap> thekorn: Of course, other things break now :)
<thekorn> allenap, but in my understanding there are a few lines in registry/interfaces/product.py which make this field writable?
 * allenap goes to look
<thekorn> around line 727
<allenap> thekorn: In r/i/distribution.py too.
<allenap> thekorn: This is all a bit hacky and unpleasant.
<thekorn> allenap, ok, I don't think I have enough voodoo powers to understand what's going on there, and maybe to work around it,
<allenap> thekorn: I think I've got something... I'll paste a diff in a minute or two.
<thekorn> wow great
<allenap> thekorn: Well, more like 10 or 20.
<thekorn> take your time
<allenap> thekorn: Merge my branch again; it's got something that seems to work in it.
<asabil> can someone explain what is zopeless please ?
<thekorn> allenap, thanks. looking
<thekorn> allenap, super, I finally was able to merge your changes, it works great, (altought I don't get how this is different to the old hackish solution)
<thekorn> thanks again
<allenap> thekorn: Well, the difference is that it's less hackish ;)
<thekorn> allenap, ok, but this does not explain why it was not working the other way :)
<allenap> thekorn: That's the magic of Zope! (Meaning, I will try and think of a better answer...)
<thekorn> allenap, anyway, it seems to work now, is something fundamental missing (or wrong), if not I think I will go an file a merge proposal for this branch
<thekorn> so I can get this searchTasks in, in a later branch I will try to add methods like  searchCommentedTasks() ...
<Ursinha> A/5
<allenap> thekorn: Go for it :)
<thekorn> done, https://code.edge.launchpad.net/~thekorn/launchpad/make_iperson_ihasbugs/+merge/18523
<thekorn> allenap, thanks again for your help, you helped me alot
<allenap> thekorn: Cool, you're welcome, you're helping us a lot :)
<bac> hi rockstar
<rockstar> bac, hi
<bac> hi rockstar.  nm, i was able to get help from abentley
<rockstar> bac, awesome. abentley is handy like that.  :)
<allenap> rockstar: When using "Resubmit proposal", can I change the merge target?
<rockstar> allenap, no, because then you're not resubmitting.  Your submitting to another target.
<allenap> rockstar: Ah, fair. (I'm trying to be constructively lazy when I submit to lp:launchpad when I mean devel.)
<allenap> thekorn: The merge proposal for make_person_ihasbugs is proposed for merging into lp:launchpad, aka db-devel, so the diff is huge. You'll need to file a new proposal for devel.
<rockstar> allenap, yeah, I've done that a few times as well.  I just delete the proposal and start over.
<allenap> rockstar: Yep, me too. Thanks.
<abentley> rockstar, allenap: We are planning to allow resubmitting with a changed target in the future.
<allenap> abentley: That will be great.
<abentley> rockstar, chat?
<rockstar> abentley, 5 mins?
<abentley> rockstar, sure.  Call me.
<kfogel> adeuring: I haven't read all email yet, btw
<adeuring> kfogel: so, Martin ui-approved your main branch, and (implicitly) also the "no patches available" variant
<adeuring> my branches landed on db-devel
<kfogel> adeuring: both of yours?  awesome!
<kfogel> adeuring: so the three devel branches still need to land, then?
<adeuring> intellectronica branched from your big-iintegration branch and added sorting by patch age
<adeuring> kfogel: yes, but i think we can just land tom's most recnet branch, if...
<adeuring> if we are sure that everything is reveiwed ;)
<kfogel> adeuring: ah, it has everything, right.
<kfogel> whew
<kfogel> adeuring: well, I'm doing that now: checking the review status on all the individual branches, then will look at tom's integration+sorting branch.
<adeuring> kfogel: cool.
<kfogel> beuno: can you mark https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428 as approved by you, since you implicitly approved that UI in another branch already?
<kfogel> adeuring: https://code.edge.launchpad.net/~allenap/launchpad/patch-report-for-people-and-teams-bug-506018/+merge/18414 has no UI review yet, and it's not clear to me if beuno or anyone else did persons/teams.
<kfogel> ?
<adeuring> kfogel: well, the presentation is the same as for the other variants
<beuno> kfogel, done
<kfogel> adeuring: well, there is that "in" vs "for" issue we noticed last night
<kfogel> beuno: thank you!
<allenap> kfogel: I think it's safe to not do a UI review. There are, however, some pending changes to that branch which abel noticed this morning.
<kfogel> allenap: pending changes?
<adeuring> kfogel: yes, the things you moticed earlier
<allenap> kfogel: The title was wrong for people, and the target column was not showing up.
<adeuring> "patches in..."
<kfogel> allenap: so the necessary changes are in the branch now, or need to be made?
<adeuring> and i think that we should show the target on ~person/+patches
<allenap> kfogel: I'm making them, and will be done soon.
<intellectronica> adeuring, kfogel: you can land my branch, it's reviewed and all. it does require a test run, though i'm quite confident about it
<kfogel> adeuring: I'm actually a little curious, now that I think about it, about the meaning of ~person/+patches.  Is it showing all patches for bugs which that person is somehow associated with, or...?
<intellectronica> kfogel: i'll have to go away in an hour. are you cool to take over?
<kfogel> intellectronica: yes
<kfogel> intellectronica: your branch https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428 was part of my mega-test-run yesterday.
<adeuring> kfogel: yes, but don't ask me about details, what "associated" exactly means...
<kfogel> adeuring: IOW, it's about how a person/team "has bugs", whatever "has" means
<adeuring> kfogel: yes
<kfogel> adeuring: the issue, though, is what should the title of the target column be then?
<intellectronica> kfogel: i have another branch, ~intellectronica/launchpad/sort-by-patch-age, which does what it says on the tin. that's the one i was referring to
<kfogel> adeuring: what if it can be both packages and products, for example?
<kfogel> intellectronica: ah, ok, thanks
<adeuring> kfogel: right
<adeuring> it can be packages and products...
<kfogel> adeuring: so, we need a better title :-)
<adeuring> so, "target"?
<kfogel> ugh
<kfogel> adeuring: loathe to use "target", since (as others have pointed out) it has a verb meaning for series and milestones.
<adeuring> or "package/product"?
<kfogel> prackuct?  prodage?
<adeuring> kfogel: let's try that ;)
<kfogel> whoo boy
<adeuring> kfogel: but I wouldn't put too much effort into this detail right now. There isn't very much time left to run the ec2 test and to merge
<adeuring> kfogel: let's take something vaguely reasonable, like target, and replace it by a better word later
<kfogel> adeuring: *nod*
<kfogel> beuno: are you seeing above?  I can summarize if you want.
<beuno> kfogel, sorry, am not
<kfogel> beuno: I'll summarize, np:
<beuno> what's up?
<kfogel> When seeing the patches view for a person/team, we're going to make two simple UI tweaks.
<kfogel> One is obvious: "Patches in J. Random" isn't a good page title, should be "Patches *for* J. Random".
<kfogel> I assume no controversy there :-).
<kfogel> The second is that there's a variable column in the view -- second from right column, it's sometimes called "Package" and sometimes called "Project" (meaning product) depending on the type of the view.  But in the case of persons/teams, it can vary row-by-row, sometimes pkg, sometimes proj.
<kfogel> beuno: so, we're thinking we have to call it "target" for now, unless you can think of a better name.
<kfogel> the column, that is
<kfogel> (maybe "Task Target" ?)
<beuno> kfogel, target I think is something we only know what it means
<kfogel> beuno: I know.  I just can't come up with a better word right now.  "Pkg/Proj" ?
<kfogel> "Package / Project" is awfully long.
<beuno> kfogel, this is the table header?
<kfogel> beuno: right, column name in the table.
<kfogel> adeuring: okay, so I'd like to sketch out what comes next if you don't mind.
<adeuring> kfogel: sure
<kfogel> adeuring: first of all, we're done with db-devel, right?  No worries there.
<adeuring> kfogel: right
<kfogel> adeuring: we now have four other branches to integrate
<kfogel> (one sec)
<adeuring> kfogel: well, they _are_ integrated, aren't they?
<kfogel> s/integrate/land/
<kfogel> but one of them needs some code changes!
<kfogel> I don't actually have intellectronica's new branch; let me find it.
<adeuring> kfogel: i think allenap's branch is not yet merged into your big integration branch
<kfogel> oh, allenap's
<kfogel> adeuring: how much longer are you on?
<kfogel> adeuring: (subtext is: I'm going to need some food at some point soon)
<adeuring> kfogel: not very long, at least not in a "useful way". I think I caught a bronchitis
<adeuring> kfogel: but grabbing food right now is a good idea :)
<kfogel> adeuring: oh, sorry :-(
<kfogel> adeuring: 15 min, just some quick breakfast
<kfogel> I'll be much more functional after that
<adeuring> kfogel: sure, I'll be afk for 20 minutes to buy some food
<kfogel> see you back here
<thekorn> allenap, damn, sorry. will file a new one
<allenap> thekorn: No worries, I do it all the time. abentley earlier said that a feature to resubmit a proposal for a different merge target is planned, but for now you've got to create a new one and delete the old one.
<thekorn> allenap, that's the new one: https://code.edge.launchpad.net/~thekorn/launchpad/make_iperson_ihasbugs/+merge/18541
<allenap> thekorn: Cool.
<kfogel> adeuring: back
<kfogel> intellectronica: (still there?)  what about UI review on your branch?
<intellectronica> kfogel: come on, for adding another option to the combo?
<intellectronica> ui=me
<kfogel> intellectronica: okay.  I'm still learning the processes :-).
<intellectronica> me too :)
<poolie> hi
<poolie> what is the username/password in the sampledata
<kfogel> poolie: foo.bar@canonical.com, "test" I think
<kfogel> allenap: so reading backscroll, I'm not quite clear on what changes you're making to which branch.  Can you give me a one-sentencer?
<poolie> thanks
<kfogel> poolie: np, thanks for looking it over
<allenap> poolie: test@canonical.com, mark@example.com (I think), with "test" as the password.
<beuno> kfogel, sorry I moved away. Need me to click on anything?
<kfogel> poolie: I never used that one allenap said above, but maybe it works too :-)
<poolie> karl's stuff worked
<kfogel> beuno: no, won't be for at least half an hour yet unfortunately
<allenap> kfogel: Sorry if I was butting in. There are several users to choose from.
<kfogel> beuno: sorting out some chaos here.
<beuno> kfogel, take my ui=beuno and land. I can always file bugs  :)
<kfogel> beuno: many branches flying around, trying to reduce that to just one or two :-)
<poolie> oh that's so sexy
<poolie> a not-quite-so-trivial branch
<kfogel> beuno: heh.  thanks, wil do
<allenap> intellectronica: Do you have time to review r10187 in https://code.edge.launchpad.net/~allenap/launchpad/patch-report-for-people-and-teams-bug-506018/+merge/18414? I /hope/ it'll be swift and painless. No harm in saying no though.
<kfogel> allenap: ah, great!  I see rev 10187; you were doing what I was about to do, great.
<kfogel> (except probably doing it faster, cough cough)
<allenap> kfogel: Oh, don't believe that; I took a fair old time doing that one.
<kfogel> allenap: and IPerson.providedBy(foo) counts teams as well, right?
<allenap> kfogel: Yep.
<kfogel> allenap: in another branch, shouldShowTarget name is now targetName and looks like this:
<kfogel> http://paste.ubuntu.com/368365/
<kfogel> allenap: and the .pt file has been updated accordingly.
<kfogel> allenap: that's in https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report/
<kfogel> allenap: the purpose of that is to vary that column name depending on whether it should be "Package" or "Project" (product).  after discussion, beuno suggested defaulting to "Project" when it's a person view (since the column may show both, but "project" is broader).
<allenap> kfogel: I have to go, erm, basically now. I will be back in about 2.5h, can it wait, or could you perhaps fix it up in the integration branch? I would guess it should be something like "Project or Package" for IPerson.
<kfogel> allenap: I can fix it up, np.  I just wanted to let you know.
<poolie> kfogel: or whoever: where should new bugs-related pagetests go?
<poolie> lib/lp/bugs/pagetests/ or something else?
<kfogel> poolie: not sure
<allenap> kfogel: Thanks.
<poolie> BjornT: ^^ ?
<kfogel> allenap: np.  thank you so much for finishing those UI fixes!
<allenap> kfogel: Sorry I was so slow.
<kfogel> allenap: I dunno, man, I was sleeping :-).
<kfogel> if you'd been faster, I wouldn't have woken up earlier!
<kfogel> adeuring: ayt?
<adeuring> kfogel: yes
<kfogel> adeuring: now that we're both fooded, let's resume :-).  My next steps are to integrate https://code.edge.launchpad.net/~intellectronica/launchpad/sort-by-patch-age and the new r10187 from https://code.edge.launchpad.net/~allenap/launchpad/patch-report-for-people-and-teams-bug-506018 into my patches-view-mega-integration branch (which is based off db-devel, btw).
<kfogel> There will be some trivial adjustments to make, at least in allenap's code, but nothing that should be a problem.
<kfogel> Then I'm going to run EC2 on that, and then submit it (I believe we have all the approvals now, will double-check that).
<kfogel> adeuring: when I submit, I submit to db-devel?
<adeuring> kfogel: yes
<kfogel> adeuring: actually, I should the ec2-land thing, right?
 * kfogel realizes these tools exist for a reason
<adeuring> kfogel: yes ;)
<adeuring> kfogel: but ec2 test -s "submit message" etcetc works too
<kfogel> adeuring: so, I'm sure that the ec2 run will start in less than an hour, probably less than half an hour.  Given that, I think I can tell jcastro not to move his talk to friday, but keep it thursday.
<adeuring> kfogel: right
<kfogel> adeuring: thanks
<adeuring> kfogel: but to be sure, let's double-check with the LOSAs when staging is update
<adeuring> ...updated
<kfogel> adeuring: ok.  losas, ayt? :-)
<mthaddon> kfogel: what's up?
<kfogel> adeuring: you'll be more competent at asking this question.
<kfogel> mthaddon: (what adeuring says; I'll listen and learn)
<adeuring> mthaddon: at whoch time is the code on staging  updated?
<adeuring> i.e.;: What is the lastest time to land a branch so that it is included in the next code update?
<mthaddon> adeuring: it runs every half an hour, but if it includes DB updates, the upgrade can take up to 1 day, so it's very hard to estimate
<adeuring> mthaddon: wow, that's more frequently than i assumed
<adeuring> The DB patch already landed, BTW
<kfogel> adeuring: in my patches-view-mega-integration branch (locally), I should *not* do 'bzr merge ../devel', right?
<adeuring> kfogel: no, it's better to merge db-devel
<kfogel> adeuring: how frustrating.  'bzr update' in my db-devel branch locally gets no changes, but 'bzr pull' does.  How is one supposed to remember this?
<kfogel> sorry, just grumbling
<adeuring> ;)
<kfogel> adeuring: 'cd patches-view-mega-integration; bzr merge ../db-devel'
<kfogel> Warning: criss-cross merge encountered.  See bzr help criss-cross.
<kfogel> adeuring: should I worry about that?
<adeuring> kfogel: gah, yes :(
<adeuring> kfogel: do you get many conflicts?
<kfogel> adeuring: 4, yes
<kfogel> adeuring: I can redo the entire integration branch; that'd add maybe 15 minutes delay.
<adeuring> kfogel: well, that's not many ;)
<kfogel> adeuring: should I just resolve them before committing?
<adeuring> kfogel: yes, I think so. But our bazaar specialists might have better advice
<kfogel> adeuring: I just worry that the "criss-cross" merge could end up screwing up db-devel's history.
<kfogel> is that possible?
<adeuring> kfogel: I must admit that I was never sure about the side effects of a criss-cross merge...
<adeuring> kfogel: but I think it is hard to avoid it now...
<kfogel> adeuring: I'm asking in bzr.
<kfogel> adeuring: poolie says that won't screw up the history.
<adeuring> kfogel: ok, so, if the conflicts are not too difficult to resolve, let's try that
<kfogel> adeuring: they're actually not completely trivial.  I'm asking poolie in #bzr about maybe reordering my operations to avoid it, one sec.
<adeuring> kfogel: which files show conflicts?
<kfogel> adeuring:
<kfogel> Text conflict in lib/lp/bugs/doc/bugtask-search.txt
<kfogel> Text conflict in lib/lp/bugs/interfaces/bugtask.py
<kfogel> Text conflict in lib/lp/bugs/stories/webservice/xx-bug.txt
<kfogel> Text conflict in lib/lp/testing/factory.py
<kfogel> adeuring: first file is trivial whitespace, no issues
<kfogel> second one is small, but not immediately obvious which side is "right"
<adeuring> kfogel: I think these are real conflicts.
<adeuring> kfogel: let me have a look myself. Is your integration branch on LP up to date?
<adeuring> (except for the db-devel merge, of course)
<kfogel> adeuring: yes.  it has tom's change, but I havne't committed nor pushed the db-devel merge yet.
<adeuring> kfogel: ok
<kfogel> adeuring: note jam suggest 'bzr merge --weave' or 'bzr remerge --weave' over in #bzr
<adeuring> kfogel: right, that helps quite often. You could try that, but I think the conflicts detcted by bzr are all real
<kfogel> adeuring: *nod*  if you can resolve them, that'd be great.  can you just push to my branch, or do you have to push to somewhere else and then I merge from your branch?
<kfogel> "my branch" meaning mine up on launchpad
<adeuring> kfogel: a few minutes, please ;)
<kfogel> I suppose you can't do that.  Oh well, no big deal.
<kfogel> adeuring: sure :-)
<kfogel> mthaddon: so I wasn't clear on the resolution of the conversation you and abel had just now.  We're going to send a db-devel branch through EC2 in the next hour or so; assuming it passes and lands, when will staging get the update?
<mthaddon> kfogel: the conclusion was there's not really an easy way to tell - I'd have to dig into it in a lot more detail to be able to tell you but I'm already past EOD - we update every 30 mins, but with DB updates it can take a day to restore
<kfogel> mthaddon: np, I don't want to keep you late.  Is there another LOSA who will be around the next few hours?
<mthaddon> kfogel: it depends on if there are any other commits with db changes that hit before that one does - if so, two days, if not, one day is about as close as we can get
<kfogel> mthaddon: one day as in ~24h ?
<mthaddon> yep
<mthaddon> assuming there are no problems with the staging update process
<adeuring> kfogel: conflicts resolved: lp:~adeuring/launchpad/patches-view-mega-integration
<kfogel> adeuring: I will now merge that into my local patches-view-mega-integration and push up, and then take care of getting allenap's chnages in
<kfogel> mthaddon: thanks.
<adeuring> kfogel: ok
<kfogel> adeuring: based on what mthaddon says above, I think I need to tell jcastro to move his talk to friday.  concur?
<didrocks> installing LP on lucid is still failing, but not in the bzr part this time (thanks james_w!). It seems to try to executes something in a non existing file: http://pastebin.com/f5426fbab
<adeuring> kfogel: yes, that's probably better
<kfogel> adeuring: okay, lp:~kfogel/launchpad/patches-view-mega-integration is now totally up-to-date; includes your branch, which means it's up to date with latest db-devel.  Right?  I'm being extra verbose just to make sure I don't miss a step here :-).
<adeuring> kfogel: yes ;)
<adeuring> kfogel: except... that db-devel has been updated in the last minutes. but that shouldn't matter
<kfogel> adeuring: thanks.  Now, I need to merge *just* http://bazaar.launchpad.net/~allenap/launchpad/patch-report-for-people-and-teams-bug-506018/revision/10187 .  Is that just this command?:
<kfogel> bzr merge -c 10187 lp:~allenap/launchpad/patch-report-for-people-and-teams-bug-506018
<adeuring> kfogel: yes, but I think you don't need to specify the revision. We want the recent verion, don't we?
<adeuring> s/verion/version/
<kfogel> adeuring: oh, right, duh -- bzr will just DTRT.  I'll try it without -c.
<kfogel> adeuring: merging now.  remember this is the one where I will have to resolve some conflicts.
<adeuring> kfogel: right
<mwhudson> good morning
<thekorn> how is this +apidoc generated out of thes wadl file?
<kfogel> mwhudson: morning
<kfogel> thekorn: oh, wait, I think we covered this long ago, I might have a branch that has notes on this...
<thekorn> kfogel, sorry, already found it, there is a stylesheet in launchpadlib which is used for it
<thekorn> I was just confused because I expected to find something in launchpad itself
<kfogel> thekorn: so https://code.edge.launchpad.net/~kfogel/launchpadlib/426323-apidoc-html-title-attrs is of no help to you now, I guess :-)
<kfogel> more specifically, https://code.edge.launchpad.net/~kfogel/launchpadlib/426323-apidoc-html-title-attrs/+merge/12442
<thekorn> kfogel, it tells me that launchpadlib is the correct place to look at
<thekorn> thanks kfogel
<kfogel> thekorn: np
<didrocks> kfogel: any idea about the failing installation? ^
<kfogel> didrocks: I'm afraid I'm under the gun right now with a deadline, sorry.  Wish I could look :-(.
<didrocks> kfogel: no pb, I can handle other task and ping you again when you're up again. It's just that LP doesn't want me apparently :-)
<kfogel> didrocks: no, it wants you, I promise.  It's just coy sometimes.
<didrocks> kfogel: hehe right, do you mind I ping you later? (next week if you prefer?)
<didrocks> just need my changes to land before alpha3 for Quickly Feature Freeze
<kfogel> didrocks: it's always okay to ping, sure!
<kfogel> if i'm tied up I'll just say so
<kfogel> didrocks: but, others may be available sooner (like now, maybe?)  worth a try, if you're in a rush
<kfogel> adeuring: http://paste.ubuntu.com/368404/
<kfogel> adeuring: ^^ trouble building patches-view-mega-integration.  were you able to run the branch?
<kfogel> adeuring: I got the same error with 'make run', btw
<kfogel> adeuring: hmmm, maybe I didn't link external sourcecode?
<kfogel> I'll try that...
<kfogel> nope
<kfogel> still get the error afterwards
<adeuring> kfogel: strange....
<kfogel> adeuring: you can build it?
<kfogel> adeuring: btw, the pending changes in my tree are allenap's fixes, with conflicts resolved.  I can push those, I just wanted to actually test them first.
<adeuring> let me try...
<adeuring> kfogel: no problems running "make", "make schema"
<kfogel> adeuring: whoa
<kfogel> adeuring: well, in the interests of time, let me push up then
<adeuring> kfogel: when running utilities/link-entrnal-sourcecode, did you specified ../devel or ../db-devel?
<adeuring> kfogel: gah, sorry, used the wrong branch
<kfogel> adeuring: I specified ../db-devel
<adeuring> kfogel: hmmm... that should be right...
<adeuring> kfogel: let me run the tests you want. (I have r8960 of the iegration branch)
<kfogel> adeuring: wait, pushing now
<kfogel> you want 8961
<adeuring> kfogel: i have it
<adeuring> ..now
<kfogel> :-)
<kfogel> adeuring: run bin/test -v -t patches-view.txt first, I'd say, just to make sure
<adeuring> kfogel: a few simple test failures. http://paste.ubuntu.com/368409/ I'll fix tehm
<kfogel> adeuring: dang it.  what'd I miss?  reading...
<kfogel> adeuring: hunh.  I wonder why we get those?
<kfogel> ohhhhhh
<kfogel> I see why
<kfogel> allenap change the displayname, yeah...
<kfogel> good, makes sense now
<adeuring> kfogel: i think defualt sort order changed too ;)
<kfogel> adeuring: could be
<kfogel> Anyone here know what might cause http://paste.ubuntu.com/368404/ ("ImportError: No module named canonical.config" "make: *** [compile] Error 1" when trying to build a branch) ?
<kfogel> mwhudson: ^^
<kfogel> barry: ah, you might know answer to above
<mwhudson> kfogel: no, not really
<mwhudson> i guess i'd try make clean; make
<adeuring> kfogel: lp:~adeuring/launchpad/patches-view-mega-integration has the test fix
<kfogel> adeuring: thank you.
<kfogel> mwhudson: that may have fixed it...
<adeuring> kfogel: np
<kfogel> adeuring: pushed up now, 8962 is latest in my branch
<kfogel> adeuring: I'm doing 'make schema' and 'make run' now just to sanity check, and run the patches-view.txt tests.  Then I will start the EC2 run with auto-land on success.
<adeuring> kfogel: great. So let's start ec2 test
<kfogel> adeuring: start now in parallel you mean?
<kfogel> adeuring: makes sense
<kfogel> let me compose the cmd
<adeuring> kfogel: nah -- I'll leave that to you ;)
<adeuring> I guess that I'm sleeping when the test will finish
<adeuring> so I wouldnt notice any problems...
<kfogel> adeuring: hm?  the cmd is now -- I meant the ec2 command, which will have the pqm submit message in it
<adeuring> kfogel: now I'm conpletely confused ;)
<kfogel> adeuring: I thought you were saying "Start the ec2 tests now, with the option to auto-land via pqm if the tests are successful."
<adeuring> kfogel: yes, that's what i meant
<kfogel> adeuring: so the cmd I'm composing begins with "utilities/ec2 ..."
<kfogel> adeuring: I'm trying to figure out whether to use 'land' or 'test'.  I guess 'land' wants a merge proposal, whereas 'test' takes a branch.
<adeuring> kfogel: I've always used "ec2 test -s 'submit-messge'"
<adeuring> kfogel: ...which would in our case also need the traget branch speciiftaion
<kfogel> adeuring: that's all?  Don't we need to specify db-devel as the dest?
<kfogel> :-)
<adeuring> kfogel: yes
<kfogel> adeuring: *nod*  okay, one sec, I'm writing the submit message
<adeuring> kfogel: so, --pqm-submit-location=bzr+ssh://...
<adeuring> but without a trailoing '/'
<kfogel> adeuring: it's important that it be w/o trailing '/' ?
<adeuring> kfogel: IIRC, pqm bails out if it sees a trailing '/'
<kfogel> adeuring: ok
<adeuring> kfogel: and you can't use the lp:~launchpad-pqm/... notation either. You must use bzr+ssh://
<kfogel> adeuring: yeah, learned last night :-(     :-)
<kfogel> adeuring: should I actually make an MP for lp:~kfogel/launchpad/patches-view-mega-integration ?  I don't see any need, really, but if I should I can.
<adeuring> nah, i think that's not necessary
<kfogel> adeuring: sanity check please:
<kfogel> utilities/ec2 test --pqm-submit-location=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel --submit-pqm-message='[r=intellectronica,adeuring,allenap][ui=beuno][bug=506018,512500,516593,512498,516186] Implement a "+patches" view on packages, products, project groups, distroseries, persons, and teams.'
<kfogel>  
<kfogel> (should we say just "series" instead of "distroseries" ?)
<kfogel> oh, forgot jml and stub as reviewers, let me add them
<adeuring> kfogel: i think it doesn't matter ;)
<adeuring> kfogel: -...i mean the [distro]series stuff
<kfogel> ok
<adeuring> but right, stub and jml should appear in r=
<kfogel> I made it "series" and added jml and stub
<kfogel> utilities/ec2 test --pqm-submit-location=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel --submit-pqm-message='[r=intellectronica,adeuring,allenap,jml,stub][ui=beuno][bug=506018,512500,516593,512498,516186] Implement a "+patches" view on packages, products, project groups, series, persons, and teams.'
<kfogel> Ready to launch? :-)
<adeuring> looks good (ti my somewhat tired eyes ;)
<adeuring> kfogel: yes, ready to launch to the pad
<adeuring> erm, launch the pad ? from the pad?
<kfogel> adeuring: wow, you are tired
<kfogel> adeuring: :-)
<kfogel> wow, instance taking a long time to start up
<kfogel> adeuring: should I have done --headless?
<kfogel> adeuring: I will need to be able to shut my laptop later... :-)
<EdwinGrubbs> salgado-afk: ping
<EdwinGrubbs> mars: ping
<adeuring> kfogel: yes, --headless have been better,
<adeuring> kfogel: so, just stop the current test and restart with --headless
<kfogel> adeuring: yup
<adeuring> kfogel: but make sure that the current instance is really goone in the AWS management console
<kfogel> adeuring: why is it that, after I ^C in the terminal, *and* hit the "Terminate" button in elasticfox, the instance is still listed?
<adeuring> kfogel: no idea...
<kfogel> adeuring: if I hit the "don't show terminated instances" checkbox, then it goes away, which is reassuring, but still... oh well.
<kfogel> not going to worry.
<adeuring> just kill the instance in elasifox
<kfogel> adeuring: I did, see above :-)
<adeuring> kfogel: perhaps elastifox is simply slow in updating the machine status...
<kfogel> adeuring: could be
<kfogel> anyway, restarting with --headless
<wgrant> bac: Bug 514074 concerns me.
<mup> Bug #514074: PGP fingerprint registration fails to find key <pgp> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/514074>
<wgrant> bac: All of the involved keyservers are contained within the DC.
<wgrant> The synchronisation issues that sinzui speaks of should be nonexistent.
<wgrant> And it's well over a few hours.
<bac> wgrant: the keyservers were synced by IS a little while ago by pjdc
<bac> wgrant: i'm not sure why this situation occured
<kfogel> adeuring: I see this line in the output:
<kfogel> ec2test@i-64584b0c$ bzr branch bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel /var/launchpad/test
<kfogel> shouldn't that be db-devel?
<adeuring> kfogel: hmmm
<kfogel> adeuring: full output so far:
<kfogel> http://paste.ubuntu.com/368440/
<wgrant> bac: Are they regularly syncing now?
<adeuring> kfogel: I think you're right -- but I assume that the ec2tests I ran today worked the same way
<kfogel> adeuring: well, if they checked out devel, then folded your entire branch -- including the db-devel changes -- into the devel dest, I guess in theory that would wok.
<kfogel> work
<adeuring> right
<kfogel> mwhudson: see paste above, and my question to adeuring a bit before that about "shouldn't that be db-devel?".  Are my ec2 tests abut to run on the wrong trunk?
<bac> wgrant: i will follow up with IS after i verify the problem is gone
<mwhudson> kfogel: did you run "ec2 test -b db-devel" ?
<kfogel> mwhudson: nope, thanks
<mwhudson> if you used -s, if the tests pass it will be pqm-submitted to devel, which will fail
<kfogel> mwhudson: okay, terminating the instance and restarting.
<kfogel> mwhudson: (I read the help for -b, and did not take away from that that it does what I know understand it does, though on re-reading it seems clearer -- hindsight is great)
<kfogel> mwhudson: you mean "-b bzr+ssh://...lots of stuff/db-devel", not just "-b db-devel", right?
<mwhudson> kfogel: i don't know all of the things -b does but i know what -b db-devel does :-)
<mwhudson> kfogel: actually no
<kfogel> mwhudson: literally "-b db-devel"
 * kfogel breathes a sigh of relief
<mwhudson> kfogel: literally "-b db-devel"
<kfogel> At least something works kind of the way one would want :-).
<kfogel> thanks
<kfogel> mwhudson: about to re-start.  Does anything about this command strike you as wrong?:
<kfogel> utilities/ec2 test --headless -b db-devel --pqm-submit-location=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel --submit-pqm-message='[r=intellectronica,adeuring,allenap,jml,stub][ui=beuno][bug=506018,512500,516593,512498,516186] Implement a "+patches" view on packages, products, project groups, series, persons, and teams.'
<kfogel> mwhudson: uh, aside from that fact that you should also be listed in the reviewers, I mean! :-)
<mwhudson> kfogel: i don't *think* you need the  --pqm-submit-location if you have "-b db-devel"
<mwhudson> but that's just possible redundancy, not wrong
<mwhudson> kfogel: go for it
<kfogel> mwhudson: that would make sense.  It can't hurt, though.
<kfogel> mwhudson: firing away; thanks for reviewing.  I added your name and henninge's to the r= list.
<mwhudson> kfogel: cool
<kfogel> adeuring: third try's the charm...
<kfogel> mwhudson: I think I do need the full expansion of the db-devel URL after all; see http://paste.ubuntu.com/368452/ (search for 'bzr: ERROR: Invalid url supplied to transport: "lp:db-devel": No such project: db-devel')
<mwhudson> kfogel: :(
<kfogel> mwhudson: or at least the "lp:..." expansion
<kfogel> if not the full URL
<kfogel> easy enough to fix
<mwhudson> kfogel: try -b launchpad=db-devel
<kfogel> mwhudson: whoa, really??
<kfogel> not this?
<kfogel> utilities/ec2 test --headless -b lp:~launchpad-pqm/launchpad/db-devel --pqm-submit-location=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel --submit-pqm-message='[r=intellectronica,adeuring,allenap,mwhudson,henninge,jml,stub][ui=beuno][bug=506018,512500,516593,512498,516186] Implement a "+patches" view on packages, products, project groups, series, persons, and teams.'
<kfogel> mwhudson:  I've never seen that "launchpad=foo" syntax before.  You are making me suspicious, sir.  Kindly back away from the machinery.
<mwhudson> kfogel: i have that in my shell history a few times, at least
<mwhudson> (tbh, i mostly use ec2 land these days)
<kfogel> mwhudson: above should work too, though, right?
<mwhudson> kfogel: yes, it should
<kfogel> ok
<kfogel> fourth try now
<kfogel> mwhudson: nope, fail again.  Your syntax may have been the way to go.  http://paste.ubuntu.com/368457/
<mwhudson> kfogel: grrr
<kfogel> mwhudson: trying your way now
<kfogel> it's great, though: I'm accumulating all these terminated instances in my elasticfox.  I think of them like shrunken trophy skulls lined along my belt.
<kfogel> Er, well, lined down my suspenders.  Anyway.
<mwhudson> kfogel: you DO know what "suspenders" means in british english?
<kfogel> mwhudson: oh, right, forgot
<kfogel> mwhudson: s/suspenders/braces/ :-)
<mwhudson> :-)
<kfogel> mwhudson: success at last: http://paste.ubuntu.com/368469/
<mwhudson> kfogel: yay
 * mwhudson wanders off for a couple of minutes
 * kfogel does same
<thumper> mwhudson: ping
<mwhudson> thumper: hi
<thumper> mwhudson: can I get you to triage some of the new recipe bugs?
<thumper> mwhudson: or actually any bugs :)
<thumper> new ones that is
<thumper> mwhudson: also, the priority on the incremental import work just got ratcheted up somewhat
<mwhudson> thumper: ok
<mwhudson> thumper: goodie
<thumper> I'll tell you more when I'm back next week
<mwhudson> thumper: ok
<mwhudson> thumper: step 1 is done now
<thumper> yeah, I saw that lnad
<thumper> land even
<lifeless> hey, who would be a good person to chat to about tweaking the CoC signing workflow
 * mwhudson lunches
#launchpad-dev 2010-02-04
 * mwhudson stares at a pqm regex failure mail
<wgrant> mwhudson: Um, not choking on self-signed certs is a feature?
<mwhudson> wgrant: for svn imports, yes
 * mwhudson sighs
<mwhudson> release-criticial=flacoste
<james_w> has edge still not rolled out with my task_age fix?
<maxb> It would be really quite nice if someone could get around to making xx-resetpassword-of-sso-account.txt not be an unavoidable test failure for non-Canonicalites :-/
<lifeless> hey, who would be a good person to chat to about tweaking the CoC signing workflow
<mwhudson> rockstar: you there?
<rockstar> mwhudson, yes.
<mwhudson> rockstar: can you triage https://bugs.edge.launchpad.net/launchpad-code/+bug/497603 ?
<mup> Bug #497603: Y.codereview.connect_links creates a new picker every time the link is clicked <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/497603>
<mwhudson> hm
<mwhudson> i haven't had any email from launchpad for a few minutes
<mwhudson> where's my patch -> branch feature
<kfogel> mwhudson: whoo hoo!  That branch we were ec2-ing earlier has passed all tests and, it seems, landed.  *relief*
<kfogel> matsubara: thanks for marking all that stuff Fix Committed.
<devmod> hello
<devmod> So, im trying to install launchpad and im running the script and it gets stuck in "[#########\          ]  61430KB   163KB/s | Fetching revisions:Inserting stream" been sitting there for like 15 mins and no progress has been made... wondering if that is normal
<kfogel> devmod: what version of bzr?
<devmod> Bazaar (bzr) 2.0.2
<kfogel> devmod: hunh.  That doesn't sound normal to me.  All I can suggest is upgrading bzr, to bleeding edge if necessary.
<devmod> its the same version I have on my other ubuntu karmic machine
<kfogel> devmod: temporary network error?
<devmod> happened twice
<kfogel> devmod: (I'd stick around to debug more, but it's 11:30pm where I am; I'm just here to get a couple of things done and then zzzzz.  Sorry not to get more engaged :-(  ).
<devmod> that is ok thanks
<kfogel> spm: is there anything we can do to ensure that db-devel (in particular, the recently-landed http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/revision/8961) gets deployed to staging "soon"?  I'm not sure if that's an automatic process that just happens to take ~1day, or if there is prodding I'm supposed to do.
<spm> kfogel: it's automatic; and if there's DB changes, hastening it is a Really Bad Ideaâ¢
<kfogel> devmod: Don't know what TZ you're in, but there should be more people in a few hours.
<kfogel> devmod: UK time morning, you see
<devmod> oh yeah EST here
<kfogel> spm: there are DB changes, and I don't particularly need to hasten it, I just want to know that it will be available for Jorge Castro to use by EOD Thursday (he's giving a talk Friday morning, demo'ing against staging if he can).  I can't remember what TZ he is in right now -- I think US West Coast?
<elmo> yes, US west coast
<kfogel> elmo: thx
<spm> kfogel: hmmm. that may be cutting it fine. fwiw: https://staging.launchpad.net/successful-updates.txt
<kfogel> spm: hunh..  So every half hour it does... something?  What's it waiting for?
<spm> updates it can apply; but if you have db updates; it (still does?) a full DB rewhatsit. which is ... slow.
<spm> kfogel: as in a full staging restore takes something like 20 hours.
<kfogel> spm: and how can we tell when that's started?
<spm> kfogel: ps fuxww | grep restore. :-)
 * kfogel growls
<spm> one kicked off yesterday... trying to find the exact time
<spm> kfogel: what revno are you waiting on?
<spm> if 8955, that's currently doing an update to the DB as well; if > than that...
<kfogel> spm: the one above
<kfogel> spm: let me grab it
<kfogel> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/revision/8961
<kfogel> so, 8961
<spm> hmmm. I may be able to break this and kick off a new restore.
<devmod> I manually did "bzr branch lp:~launchpad-pqm/launchpad/devel lp-branches/devel/" and it got stuck on the same exact place "[#########|          ]  61430KB     0KB/s | Fetching revisions:Inserting stream" wth?
<spm> devmod: any network activity still happening?
<spm> kfogel: to verify. this one: Implement a "+patches" view on packages, products, project groups, series, persons, and teams.
<kfogel> spm: right
<devmod> what port would bzr branch lp: use?
<spm> kfogel: oki, first problem - that hasn't landed on db-devel yet; is still in Buildbot.
<spm> has ~ another 3.5 hours ETA
<spm> devmod: 22, ssh. or also look for host 91.189.90.11
<kfogel> spm: oh, that rev has to go through buildbot?
<kfogel> first, I mean?
<spm> kfogel: yup
<kfogel> spm: wait, I'm confused.  I've updated db-devel here, and that rev is definitely present.
<kfogel> I mean, it's in my branch here, which is just a branch of db-devel.
<spm> staging is db-stable
<spm> kfogel: https://dev.launchpad.net/Trunk (pretty diagrams :-) )
<kfogel> spm: so it moves from db-devel to db-stable after it's been through buildbot?
<spm> right
<kfogel> spm: diagram is very helpful, thanks
<spm> the idea was to get *a* landing is fast; get an approved and tested landing; happens; and gets a bunch of other merges in one hit; but only after testing is it applied to staging; and hence makes for a 4 step process diagram.
<spm> 4 branch - process/diagra
<devmod> 04:59:04.674042 IP crowberry.canonical.com.www > 192.168.75.132.52521: Flags [R], seq 3835263603:3835263606, win 0, length 3
<devmod> gets stuck there
<devmod> win 0 ?
<kfogel> spm: so basically, we shouldn't count on this being live on staging by Friday morning US west coast time, though it *might* happen, right?
<spm> kfogel: the only way it's even got a chance is if I stop the existing restore; and hold pending that landing getting thru buildbot; and even then... yeah, cutting it fine.
<kfogel> spm: urgk.  Well, I don't know how often these things come up.  Jorge wants to use it in a plenary talk on Friday.
<spm> kfogel: is the DB side critical? as in the other changes as part of the set should be on edge; or soon will be?
<kfogel> spm: the db changes are a critical part of the overall change, yes
<kfogel> spm: this stuff hasn't landed on devel, afaik, since it needs its db changes.  It's only in db-devel.  So I'm not expecting to see it on edge right away.
<spm> kfogel: oki; I'll see what I can do, but zero promises unf. these restores are not fast.
<kfogel> spm: thank you.  I'm composing a mail to lp-dev; I'll make it clear that no promises are being made.
<kfogel> spm: g'night
<kfogel> well, g'afternoon
<kfogel> zzz
<spm> kfogel: likewise!
<spm> heh
<thekorn> hi, bug 515761 is about not being able to get collections correctly when using this anonymous API feature,
<mup> Bug #515761: Not able to access collections anonymously <launchpadlib :Confirmed> <https://launchpad.net/bugs/515761>
<thekorn> what is the correct bug target for this, launchpadlib looks wrong to me
<wgrant> thekorn: launchpad-registry.
<wgrant> Or is it all collections?
<bigjools> hello hackers
<thekorn> wgrant, looks like all collection, maybe it's lazr.restful?
<wgrant> It could be.
 * wgrant looks.
<bigjools> al-maisan: morning.  Did you get far with bug 516922?
<mup> Bug #516922: process-pending-packagediffs breaking <Soyuz:Triaged> <https://launchpad.net/bugs/516922>
<wgrant> thekorn: It's not all collections. I am digging further.
<al-maisan> bigjools: I did not start on it yet, looking at yesterday's bug.
<al-maisan> bigjools: should I get going on Bug #516922?
<mup> Bug #516922: process-pending-packagediffs breaking <Soyuz:Triaged> <https://launchpad.net/bugs/516922>
<bigjools> al-maisan: yes this one is more important
<al-maisan> bigjools: ack
<bigjools> al-maisan: thank you
<thekorn> wgrant, oh, so it seems like I had bad luck only picking collections where something goes wrong
<al-maisan> bigjools: de nada
<wgrant> thekorn: eg. bug.bug_tasks works.
<thekorn> wgrant, hmm, right
<mrevell> Morning
<wgrant> thekorn: Ahem.
<wgrant> thekorn: I found the cause for product.series.
<wgrant>     permision = 'launchpad.View'
<wgrant> somebody cannot spell.
<wgrant> thekorn: What other cases are there?
<thekorn> wgrant, bug.messages and bug.subscriptions
<wgrant> thekorn: Yeah, I see why this is all happening.
<thekorn> wgrant, super, great, thanks a lot
<wgrant> Basically, lazr.restful returns an object if you hold launchpad.View on it.
<wgrant> Objects like messages and bugsubscriptions have no security adapters, so it falls to the root one.
<asabil> hi all
<wgrant> Which, in this case, is ('launchpad.View', Interface) -> ViewByLoggedInUser, which only allows authenticated users.
<asabil> is it normal that the xmlrpc service is handled by codebrowse ?
<wgrant> (I had actually wondered from the start how it knew to hide objects, given that I saw no way for it to happen reliably. I was right.)
<thekorn> wgrant, so will the solution for this be to write security adapters for all affected collection, or might there be a more general solution?
<wgrant> thekorn: I think ViewByLoggedInUser is probably a bug.
<wgrant> thekorn: It should probably just be View.
<wgrant> There may be a couple of places that it makes sense, but not many.
<wgrant> It shouldn't be the default security adapter.
<thekorn> wgrant, I think even if the typo is fixed IProductRelease will need a security adapter for launchpad.View in order to get a working product.releases, but this is just a minor side note ;)
<wgrant> thekorn: Yes, the underlying issue needs to be fixed oto.
<jml> thumper, time.mktime(date_time.timetuple())
<jml> thumper, but! it fucks up timezones
<jml> thumper, it doesn't actually, utctimetuple would
<asabil> can someone help me with this: http://pastebin.com/d68e0056c ?
<asabil> I am setting up launchpad manually to learn about things
<asabil> anyone ?
* salgado changed the topic of #launchpad-dev to: Launchpad is feeling unwell right now, but we're working on it || Launchpad Development Channel | Week 0 of 10.02 | PQM is open | gary_poster is release manager | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu.com/
* salgado changed the topic of #launchpad-dev to: Launchpad is feeling unwell but should be fully recovered real soon now || Launchpad Development Channel | Week 0 of 10.02 | PQM is open | gary_poster is release manager | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu
<mars> hmm, our "The Server is Down" page probably shouldn't try to load it's CSS from a file on self-said server...
<mthaddon> mars: it's hosted statically so it doesn't matter
<mars> mthaddon, ok, thanks.  Then the styling is just plain messed up.
<mthaddon> could be, yeah
<henninge> salgado-lunch: Hi, ping me when you get back, please.
* mrevell changed the topic of #launchpad-dev to: Launchpad is back online. Please report any problems. || Launchpad Development Channel | Week 0 of 10.02 | PQM is open | gary_poster is release manager | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu
<thekorn> allenap, thanks for your review, looking at it now
<matsubara> Chex, rockstar, bigjools, Ursinha, sinzui, allenap: LP production meeting in 3 min @ #launchpad-meeting
<al-maisan> matsubara: bigjools is sprinting .. I'll stand in for him.
<matsubara> henninge, ^
<matsubara> thanks al-maisan
<salgado> hi henninge
<henninge> salgado: Hi! ;)
<henninge> salgado: I have some ideas about the LP security system and wanted to ask you if you know of any plans to work on it?
<sinzui> EdwinGrubbs: can you attend the production #launchpad-meeting
<salgado> henninge, if I have plans to work on it or if there's any work planned on that area at all?
<henninge> salgado: in general. I am talking to you because I thought that this falls into your team's expertise.
<henninge> salgado: I could just put my ideas out on the mailing list or a wiki page or a blueprint but thought I'd checked if any work in that direction is already planned.
<salgado> henninge, it does, yes, but I'm not aware of any planned work on that area
<henninge> salgado: do you use blueprints, bugs or wiki pages to collect plans/ideas?
<henninge> Or should I start with an RFD on the ML?
<salgado> henninge, bugs, mostly, but I guess a RFD on the ML would be good in this case
<henninge> salgado: cool, will do that. Thanks.
<jml> intellectronica, great link!
<jml> sinzui, http://www.runleiarun.com/lebowski/
<intellectronica> oh, it's amzing
<intellectronica> it's this kind of stuff that restores my faith in the internet
<jml> intellectronica, well put :)
<jtv> good night, folks!
<jml> you guys
<jml> your coding standard is basically stupid
<jml> how come functions and methods are differently formatted?
<jml> is there a thing that makes them different?
<intellectronica> jml: one you can have in java and the other you can't
<intellectronica> we're industry standard like that
<didrocks> hey, I can't remove some token from my authorized applicatoin list today (from production or edge server): https://edge.launchpad.net/~didrocks/+oauth-tokens
<didrocks> I got a "Sorry, you don't have permission to access this page. You are logged in as Didier Roche."
<didrocks> when trying to revoke an authorization
<maxb> didrocks: It got broken in the last rollout. Let me find the bug number....
<maxb> bug 511567
<mup> Bug #511567: Can't remove authorised oauth tokens <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/511567>
<didrocks> maxb: thanks, I'll follow it
<didrocks> btw, do someone have any clue about the crash I got trying to install LP locally to extend Launchpad API? (http://pastebin.com/f5426fbab)
<jamalta> would you guys care if i make the community-contributions script merge the 3 version of me? ... i kinda ruined the count there, heh
<EdwinGrubbs> salgado: ping
<intellectronica> didrocks: did you use rocketfuel-setup to install?
<salgado> hi EdwinGrubbs
<EdwinGrubbs> salgado: are you the person to ask questions about adding a launchpad-dependency and a package to the PPA? I saw the wiki page, but it didn't really have any guidelines.
<salgado> EdwinGrubbs, I used to be responsible for that, but since we moved to a PPA I'm not.  I might be able to answer any questions you have, though
<jamalta> also, could i get some input for bug #515761?
<mup> Bug #515761: Anonymous API access to some collections returns nothing <Launchpad Foundations:Confirmed> <https://launchpad.net/bugs/515761>
<EdwinGrubbs> salgado: I was just going to have PIL 1.1.7, which is already in Lucid, rebuilt for Karmic in the PPA and add that to the launchpad-developer-dependencies. Do I need to get any review of that work?
<maxb> We lack defined process for this
<maxb> I don't think there's been a case of needing a backported version of a python library in the PPA before
<salgado> we had a backported python-apt, IIRC
<maxb> You'd have to also backport to hardy and jaunty (or first get jaunty de-supported and deleted from the PPA)
<maxb> The closest recent occurrence would be a backported dpkg
<maxb> If there was a backported python-apt, I think it must have been pre-opensourcing
<salgado> it was
<salgado> EdwinGrubbs, so, as maxb pointed out, there are a few extra steps you might have to take.  although we don't require a formal review, it's probably a good idea to email the list about it
<EdwinGrubbs> salgado: ok, thanks
<mwhudson> good morning
<didrocks> intellectronica: right (sorry for the delay). But it failed because of wrong bzr base version on one of your LP branch. james_w fixed it locally for me and opened a bug. Then, I tried to continue the process and run the command I pastebin
<james_w> didrocks: try a ./utilities/rocketfuel-get
<lifeless> abentley: what does 'xvfb-run xdypinfo' do for you?
<abentley> lifeless, /usr/bin/xvfb-run: 180: xdypinfo: not found
<lifeless> bah
<lifeless> dpy :)
<lifeless> I don't care about the particular output, just whether it errors or not
<abentley> lifeless, http://pastebin.ubuntu.com/369066/
<abentley> lifeless, no error if I run xdpyinfo
<lifeless> ok so the base server seems to be happy
<didrocks> wgrant: do you know about something special to do for installing LP on lucid? it seems it can't import bzrlib as python2.5 is in my path in the devel/lib/devscripts/sourcecode.py and not 2.6?
<jamalta> i have to close firefox to run bin/test, haha
<maxb> didrocks: ah, yes. update-sourcecode is a special case
<didrocks> maxb: any hint about changing that? adding python2.6 in the path in the script?
<didrocks> be back in a minute
<maxb> didrocks: I think it should work if you just change the shebang in update-sourcecode to be /usr/bin/python
<didrocks> maxb: oh right, let's try this
<didrocks> maxb: apparently, it didn't crash (yet :)) and I'm getting more branch back. Thanks a lot!
<EdwinGrubbs> mars: ping
<mars> hi EdwinGrubbs
<EdwinGrubbs> mars: I'm sorry to pester you again. Did you want to take a look at my sprite implementation? I have something that will work, so I could just get it ready for review, but you seemed interested in the design.
<mars> EdwinGrubbs, I did read it.  Reviewing it again now...
<mars> EdwinGrubbs, why do the makefile targets not depend on the files they output?
<mars> I could ask the same for combine-css
<EdwinGrubbs> mars: because I'm not finished with the branch yet.
<mars> lol
<EdwinGrubbs> mars: I think someone else is working on combine_css so I should check that I don't conflict with their changes.
<mars> I don't think anyone has touched that yet.
<mars> funny, I thought it would be a big deal to fix the combine_css step
<mars> turns out you just have to rewrite the Makefile target to Do The Right Thing (that being, depend on the generated file)
<EdwinGrubbs> mars: now that I think about it some more, I believe rockstar was going to work on that when he becomes chr, so he probably hasn't started on it.
<rockstar> mars, I'm already working on that.
<rockstar> mars, I said in our meeting on Monday that I'd be working on that.
<rockstar> So shame on you for not listening...  :)
<mars> rockstar, yep!  I remember.  So does EdwinGrubbs
<mars> rockstar, but if you haven't fixed it, maybe Edwin can, as he will probably be rewrite and testing his Makefile targets in the exact same way.
<EdwinGrubbs> rockstar: out of curiosity, is your fix going to be smart enough to regenerate combo.css if any of the twenty odd individual css files are updated?
<rockstar> EdwinGrubbs, it doesn't in its current form in my branch, but I need to look into why, because make is supposed to figure out that when those files change, it has to re-create the target.
<rockstar> EdwinGrubbs, basically, we're doing something with the Makefile that is against nature.
<mars> hehe
<mars> EdwinGrubbs, I liked the "PIL as a developer dependency" bit
<mars> that part makes sense
<maxb> I have two changes to update-sourcecode to submit: (1) Make it not break if you have bzr-git installed. (2) Make it not pull sourcecode branches if there is no update, to avoid triggering bzr-dbus/bzr-gtk notifications for every sourcecode branch.    Should I submit them as one branch or two?
<EdwinGrubbs> mars: is there anything that doesn't make sense?
<mwhudson> maxb: one sounds ok to me
<mars> rockstar, sorry, I didn't realize you were rolling up a bunch of stuff into one branch like that.
<rockstar> mars, well, it's all relatively related.
<mars> EdwinGrubbs, the contents of icon-sprites.positioning is confusing.  Is it JSON or something?
<mars> no, python?
<EdwinGrubbs> mars: yes, it's json, but it could just as easily be a pickled object.
<mars> oh no thank you!  JSON is better.
<mars> EdwinGrubbs, so that file is a build system output?
<rockstar> mars, basically, we need separate targets for css and js combinations.
<mars> rockstar, yes, that would make things sane again.  Are you going to try and move those targets out of the main Makefile?
<rockstar> mars, I don't see any benefit to doing that.
<EdwinGrubbs> mars: actually, that file is a build system input. You have to commit it when you commit icon-sprites, so that "sprite-util create-css" knows what background-position to set for each sprite.
<rockstar> It just means it's harder to find when someone wants to make changes to it.
<mars> rockstar, ah.  I was worried that trying to clean up the static build system would lead to an explosion of targets (css, js, images)
<mars> EdwinGrubbs, ok, is the file edited by hand?
<mars> whether it is or not is not clear from the diff context
<mwhudson> abentley: my main thought in response to your recent email is
<mwhudson> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
<abentley> mwhudson, +1
<EdwinGrubbs> mars: no, icon-sprites.positioning is generated by "sprite-util create-image" using the savePositioning() method.
<mars> abentley, is mozrunner playing shenanigans on module import?
<abentley> mars, yes.
<mars> EdwinGrubbs, ok, that is not clear from the context.  Does that file have a warning and developer instructions at the top?
<abentley> mars, there is a function definition where the default is os.environ['PATH']
<mars> abentley, argh
<mars> abentley, do you have the source line?  I can ask about a fix in #windmill if you like
<abentley> mars, windmill/dep/_mozrunner/global_settings.py: 42
<mars> if it is fixed in trunk/ then we might be able to do a quick backport patch
<mars> abentley, cool, thanks
<EdwinGrubbs> mars: that's a good idea. I'll put a warning at the top. It seems a little strange to use json for this, but it is nice that it is human readable. Of course, a pickle would discourage people from editing it by hand.
<mars> EdwinGrubbs, I think a message will suite better.  That way you can tell the developer "Here is how you fix this file".  A pickle is just mysterious and confusing.
<mars> abentley, ah, a violation of the "use None for default keyword arguments" convention
<mars> that should be a trivial patch
<mars> but I must go and take care of the twins for a minute.  bbiab
<mars> abentley, but unfortunately I have no idea how to update the windmill package we use :(
<mars> beyond my ken
<mars> rockstar, you are build engineer, perhaps that falls under your domain? :)
 * rockstar reads backchat
<rockstar> mars, I say "file a bug and assign it to me"
<maxb> Is there a standard for order of import statements? dev.lp.net/PythonStyleGuide is not very forthcoming on that aspect
<rockstar> mars, I'd like to do as much work on windmill as I can, but my specific target as build engineer is getting it so that our javascript file can be bigger than 500K.
<wgrant> didrocks: The only changes that I need are to use Karmic's python-pkg-resources and python-setuptools.
<mwhudson> maxb: generally it goes system imports, blank line, "local" (i.e. sourcecode & egg imports), blank line, launchpad imports
<mwhudson> maxb: alpha sort within each section
<wgrant> ie. PEP8
<mars> rockstar, ok
<mars> abentley, looks like windmill is kept as python library dependency, and that we are already keeping a patch of some sort
<mars> upgrading it should be trivial
<mars> 'simple'
#launchpad-dev 2010-02-05
<mwhudson> bah, installing postfix on karmic asks questions, even with apt-get -y :(
<maxb> DEBIAN_FRONTEND=noninteractive, perhaps?
<mwhudson> maxb: worth a try i guess
<mwhudson> maxb: btw launchpad-developer-dependencies doesn't seem to be installable on jaunty; don't know if that's news to you
 * mwhudson late lunch
<maxb> hmm. I wasn't sure.
<maxb> Oh, right, it doesn't have the dpkg backport
<wgrant> So it has been broken for a couple of months.
<wgrant> That might mean that nobody cares.
<wgrant> (FWIW, I've tried to get that backport copied a couple of times, but nobody has ever done it)
<maxb> copied hardy->jaunty?
<wgrant> Yes please.
<maxb> I can do that, assuming we decide we care about jaunty any more
<wgrant> We might as well care about it, since it's so trivial.
<maxb> It can hardly become less broken, I guess
<mwhudson> maxb: yay double negatives :)
<maxb> copied
<maxb> it works find in my jaunty cowbuilder
<wgrant> Thanks.
 * wgrant should try LP on Lenny again soon.
<mwhudson> maxb: DEBIAN_FRONTEND=noninteractive seems to have worked, thanks
 * mwhudson EOWs
<devmod> anyone awake?
<noodles775> Morning
<thumper> morning
<noodles775> Hi thumper
<thumper> hi noodles775
<thumper> bigjools, mrjazzcat and I will be going through your UI mockups this morning
<noodles775> thumper: ah, it'll be great to get more input... thanks!
<mrevell> Morning
<jml> mrevell, hi
<mrevell> hey jml
<jml> mrevell, still at team lead sprint, so no call today.
<mrevell> okay no problem jml. I hope the sprint is going well.
<thekorn> allenap, hi, I'm thinking about Person.searchTasks() again, and I'm a bit confused about how "related bugs" (or "commented bugs" etc.) is defined
<allenap> thekorn: I'm pretty confused by that stuff too ;) Anything specific, or do you just want to chat about it?
<thekorn> I always thought "related bugs" means "user is either commenter, assignee, subscriber or owner of a bug"
<thekorn> allenap, no, my problem is: https://bugs.staging.launchpad.net/~thekorn/+bugs?batch=300 does not listen bug 123456
<mup> Bug #123456: podcast crashes amarok <Amarok:Invalid> <xine-lib (Ubuntu):Fix Released> <https://launchpad.net/bugs/123456>
<thekorn> although I commented on it
<thekorn> so the question is: bug or wanted behaviour?
<allenap> thekorn: I think it's because it's Invalid.
<wgrant> It's closed.
<thekorn> atrgh, ok
<wgrant> You can try reopening it on staging -- it should appear.
<allenap> thekorn: Yes, actually, what wgrant said; both Invalid and Fix Released = closed.
<thekorn> yeah, right, silly me
<thekorn> ha, I knew there is a bug ;)
<wgrant> thekorn: Is there one?
<thekorn> this result looks wrong too me: https://bugs.edge.launchpad.net/~wgrant/+bugs?field.assignee=thekorn&field.bug_reporter=thekorn&field.bug_supervisor=thekorn&field.bug_commenter=thekorn&field.subscriber=thekorn
<thekorn> I mean, you are not working on zeitgeist-firefox-extension, aren't you ;)
<wgrant> Heh, that /is/ odd.
 * wgrant doesn't know that bit of code very well.
<allenap> thekorn: Did you craft that query by hand, or is it based on something you were able to create with the search form?
<thekorn> allenap, I've just cut it dowbn to the relevant parts, you can go to https://bugs.edge.launchpad.net/~wgrant/+bugs?advanced=1 and enter "thekorn" to all fields
<thekorn> and you will gett the same result
<thekorn> by all fields I mean "assignee", "reporter", "supervisor", "commenter" and subscriber
<allenap> thekorn: My guess is that the person search normally fills in one or more of those fields, but only if they're not set.
<allenap> thekorn: But I wonder why it's only showing zeitgeist stuff.
<thekorn> allenap, because this is the only bug where I'm supervisour, commentor, AND report at the same time
<allenap> thekorn: Oh yeah, doh :)
<thekorn> allenap, is it save to assume that this query should always return an empty set of tasks?
<allenap> thekorn: Yes, so it's a bug. The result should probably be the intersection of all bugs related to a user with the specific query entered.
<thekorn> I mean it makes no sense to search for related bugs, and change all user related values to something else
<allenap> thekorn: No. One solution would be to display an error, the other would be to modify the query. I think the error is probably less surprising.
 * allenap reboots
<thekorn> reported as bug 517476
<mup> Bug #517476: It is possible to give all user related arguments in a query on user related bugs <Launchpad Registry:New> <https://launchpad.net/bugs/517476>
<allenap> thekorn: Thanks for reporting that. I've commented and triaged it.
<thekorn> super, thanks
<thekorn> hmm, the whole search on persons bugs is kind of broken, https://bugs.edge.launchpad.net/~thekorn/+bugs?field.assignee=allenap is another, maybe more common example, again three bugs I never got in touch with
<allenap> thekorn: Yeah, it's because it's doing a UNION across those searches I think.
<allenap> thekorn: It makes sense, if you know the code, but that's it.
<allenap> thekorn: Do you want to comment on the bug or shall I?
<thekorn> I will add it to the bugreport
<thekorn> who is the owner of a bugreport? and what is the difference between owner and bug_reporter?
<intellectronica> thekorn: i don't think there is a difference
<intellectronica> owner is launchpad lingo for 'person who created this record'
<thekorn> intellectronica, but why does the seatchTask API method have both parameter?
<thekorn> searchTask
<intellectronica> thekorn: by "don't think" i meant, "i'm certain", b.t.w :)
<thekorn> intellectronica, aha, I got it: in this context owner means "search for tasks created (owned) by this person" and bug_reporter means "search for tasks which underlying bug was created by this person"
<intellectronica> right
<thekorn> if I could put this in one small sentence I would like to add it to the description of the export, so it appears on apidoc ;)
<wgrant> poolie: Doesn't Launchpad run on Hardy and Jaunty as well?
<wgrant> And pretty much Lucid?
<noodles775> jml: when you're around could you pls take a look at the last few comments on bug 516496, it'll effect what is and isn't possible in the UI work for build from branch.
<mup> Bug #516496: Allow Recipes to be re-used with different base_branch revisions <wellington> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/516496>
<jml> noodles775, will do.
<noodles775> Ta.
<jml> poolie, https://code.edge.launchpad.net/~mbp/launchpad/436294-review-mails/+merge/18227 is merged
<jml> noodles775, actually, next week, can we work quite closely together on this?
<jml> noodles775, because I won't get to do it today.
<noodles775> jml: yep, that'd be great.
<poolie> wgrant: i was told only on Karmic, and on lucid only if you force some packages back to the karmic version
<poolie> i'm sure it's possible
<poolie> but i think it may be easier for new contributors to just use the supported platform
<poolie> enough strange things can go wrong already
<poolie> https://code.edge.launchpad.net/~jml is persistently timing out
<jml> poolie, wfm
<poolie> back now
<maxb> poolie: Who/what told you that? I think that's wrong
<poolie> i don't recall, but it was a canonical lp dev
<thekorn> deryck, hi, you triaged bug 517570, is the fix as easy as adding a tags_combinator field to IPersonBugTaskSearch, or will there be side effects?
<mup> Bug #517570: tags combinator ALL does not work on users bugviews <search> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/517570>
<deryck> thekorn, honestly, I haven't looked at the tag combinator.  allenap wrote that code.
<deryck> thekorn, let me look here
<thekorn> well, I can just try and see if it works ;)
<deryck> thekorn, yeah, you can just try it. :-)  But I think that's all that is needed.
<deryck> on my quick glance at the code.
 * deryck is out for meeting at sprint
<EdwinGrubbs> mars: ping
<mars> hi EdwinGrubbs
<bdmurray> How could I get somebody un-subbed from all of the Ubuntu bugs in Launchpad.
<jamalta> i know you guys would probably oppose to this, but what do you think?
<jamalta> http://paste.ubuntu.com/369670/
<jamalta> to fix stupid mistakes by idiots like myself ;)
<maxb> It seems nicer to me to hack the script, than to have the duplicate identities on the page
<maxb> hmm. I need to land more. you're about to overtake me :-)
<jamalta> maxb: haha, well my contributions are all trivial
<jamalta> so they don't really count
<jamalta> i'm just trying to learn the system
<jamalta> i fixes it a bit thanks to thekorn http://paste.ubuntu.com/369688/
<thekorn> bdmurray, do you mean by using the webservice API, or were you looking some admin magic?
<bdmurray> thekorn: admin magic but it seems to have already been done
<EdwinGrubbs> mars: hi, sorry I didn't see your reply before.
<mars> EdwinGrubbs, np.  What's up?
<EdwinGrubbs> mars: do you think there is a good reason to have multiple sprite files? We currently have five. The file sizes are practically the same for five files versus one. I can also use the smartsprites solution for repeat-x.
<EdwinGrubbs> mars: Eventually, we may need to split up files, but I have tested firefox, and it works with files up to about twice the number of pixels.
<mars> EdwinGrubbs, I don't know the entire reason behind having a sprite file for each icon size.  If you think they can all go into one sprite file, then go for it.
<mars> EdwinGrubbs, if there are problems, then we will know soon enough :)
<EdwinGrubbs> cool, thanks
 * maxb wonders if lp:~maxb/launchpad/py2.6-importfascist has reached the PQM queue yet?
<mars> maxb, it is in buildbot, ETA 4444s (22:05:31)
<mars> maxb, ah, maybe not.  The changes list doesn't have the branch that is actually merged
<bac> mars: it looks like that one is  https://code.launchpad.net/~maxb/launchpad/update-sourcecode-miscellanea/+merge/18648
<bac> the one maxb asks about has not been through PQM yet
<maxb> I suppose it's off in ec2test land still, then
<bac> yep
<devmod> Hello, I am installing launchpad but I am not quite sure about the requirements of two ip addresses? anyone care to explain?
<EdwinGrubbs> maxb: ping
<maxb> pong
<EdwinGrubbs> maxb: I see that python-imaging-1.1.7 is already in the ~launchpad PPA for lucid, but it's not in there for Hardy or Karmic. Is that just in process, or do I need to pester a ~launchpad team admin?
<maxb> It doesn't require an admin
<maxb> In general we're lacking in defined process about managing the PPA, but since no one has yelled on the list, I'm inclined to Just Do It
<maxb> Shall I do so now?
<EdwinGrubbs> maxb: that would be great. BTW, how do I copy a package between PPAs?
<maxb> The "Copy packages" link is on the "View package details" page
<maxb> pending publisher
<devmod> Hello, so I installed launchpad following the directions and I get a 503 service termp unavailable.. any ideas?
<maxb> That is not enough information to assist you
<devmod> i was just reading a post, so let me change the question. How difficult is it to get launchpad running on a fully qualified domain ?
<maxb> devmod: For production purposes? Legally? Very. First you need to remove all the images, replace them with ones you are legally permitted to use, and excise the name "Launchpad" from all areas of the site.
<maxb> https://dev.launchpad.net/LaunchpadLicense
<maxb> "The image and icon files in Launchpad are copyright Canonical, but unlike the source code they are not licensed under the AGPLv3. Canonical grants you the right to use them for testing and development purposes only, but not to use them in production (commercially or non-commercially).
<maxb> The Launchpad name and logo are trademarks of Canonical, and may not be used without the prior written permission of Canonical.
<maxb> "
<devmod> ohh I see
<devmod> even if used locally I still need to strip all launchpad images, etc
<devmod> (local network, commercially )
<maxb> sadly yes
<maxb> I wish I could do that myself, but I don't have the time
<devmod> ohh that sucks :/
<maxb> yes, yes it does
<devmod> i got all excited when seeing that blog post
<maxb> likewise
<devmod> i guess i should have read it more carefully
<maxb> mbarnett, rockstar : That launchpad-dependencies version number is still wonky
<mbarnett> maxb the one in the changelog?
<maxb> yes
<mbarnett> ah, i see. it has that ubuntu1 appended. i will fix
<mbarnett> maxb: thx
<maxb> It's a package for which we ourselves are upstream, so there's no forking off of an ubuntu version
<mwhudson> is there a way to get dch to know do that?
<mwhudson> eh
<mwhudson> s/know/not/
 * mwhudson wonders how his brain manages these nearly-phonetic "typos"
<maxb> mbarnett: No problem - when you're doing that, could you put a space after the asterisk too - looks nicer :-)
<mbarnett> maxb: certainly
<maxb> I don't believe there's a way for dch to know.
<maxb> It seldom bothers me since I have dch aliased to 'dch --distributor X' to avoid that particular irksome ubuntu patch
#launchpad-dev 2010-02-06
<_Groo_> hi/2 all
<_Groo_> when are the dput quirks gonna be fixed, its impossible to dput anything anymore :(
#launchpad-dev 2010-02-07
<mwhudson> morning
<mwhudson> oh yes
<mwhudson> chr this week
* mwhudson changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 1 of 10.02 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu
<mwhudson> jpds: hi
<jpds> mwhudson: 'lo, so right now I have http://pastebin.ubuntu.com/371167/ - however, line 38 isn't taking any effect on the mirror's registration.
<mwhudson> jpds: hmm
<mwhudson> jpds: where is the corresponding browser code?
<mwhudson> oh lp.registry.browser.distributionmirror
<mwhudson> jpds: well, you don't do anything with the view
<mwhudson> there's nothing in the test to make it look like a POST
<jpds> mwhudson: Hmm, OK, all the other +edit seem to be doing the same thing.
<jpds> +edit tests*
<mwhudson> jpds: ah, you need 'field.actions.something' in the dict
<mwhudson> like dict['field.actions.save'] = 'Save'
<mwhudson> to cargo cult from another test
<jpds> mwhudson: Oh, that's what I was missing, thanks!
<mwhudson> jpds: np
<mwhudson> jpds: i hope you're enjoying hacking launchpad :-)
<jpds> mwhudson: When it works, when it works. :) http://people.canonical.com/~jpds/2010-02-07-170142_1280x800_scrot.png
<mwhudson> jpds: doesn't mean that much to me, but cool :-)
<mwhudson> wgrant: how in-progress is https://bugs.edge.launchpad.net/launchpad-code/+bug/509892 really?
<mup> Bug #509892: Store upload log for SourcePackageRecipeBuilds <wellington> <Launchpad Bazaar Integration:In Progress by wgrant> <https://launchpad.net/bugs/509892>
<mwhudson> wgrant: is there a branch?
<Ursinha> mwhudson: hi
<mwhudson> Ursinha: hello
<Ursinha> mwhudson: yet about the tagging script.. :) I had a little chat with abentley about how to solve that problem of branches without branch-nick property set
<mwhudson> Ursinha: ok
<Ursinha> he suggest that instead of monitoring revisions on devel/db-devel branches, I could watch for new merged branches
<Ursinha> mwhudson: but I couldn't find a way of doing tht
<Ursinha> *that
<thumper> morning
<mwhudson> thumper: AKL?
<thumper> yep
<mwhudson> thumper: 'grats, i guess
<thumper> I have fruit toast and a flat white
<mwhudson> thumper: domestic lounge?
<thumper> yep
<mwhudson> Ursinha: hmm
<Ursinha> mwhudson: I mean, I don't know how to ask launchpad for the latest merged branches, is that I way?
<thumper> Ursinha: are you doing the tag qa stuff?
<mwhudson> thumper: i liked that lounge, the one time i've been there so far
<Ursinha> thumper: yes
<Ursinha> trying to :)
<mwhudson> Ursinha: yeah, i don't think there is a direct way
<thumper> Ursinha: jml has a script that you should see
<mwhudson> (we don't record when branch status changes happen)
<Ursinha> thumper: what does the script do?
<thumper> works out which branches are on devel but not edge, and db-devel but not staging
<thumper> maybe revisions, not branches
<Ursinha> thumper: so, here's the problem
<thumper> we do track date_last_modified on branches
<thumper> and when something is marked as merged, that is set
<thumper> so while not perfect, it is something
<mwhudson> tbh
<Ursinha> thumper: but how can I ask only for the recently changed? otherwise I'd have to ask for all of them and see which one are new in the set
<mwhudson> probably the most reliable way of doing this currently is subscribing to the branches and parsing the emails
<mwhudson> though that only works if there's a merge proposal i guess...
<thumper> Ursinha: you are right, no easy way right now
<mwhudson> thumper: it's sunny in dunedin, i can tell from the cricket :-)
<thumper> cool
<Ursinha> thumper: I'd love suggestions :)
<Ursinha> thumper: first I thought that getting the branch-nick from the revision would work
<Ursinha> but some doesn't have the branch-nick property set
<thumper> Ursinha: often works but not always
<Ursinha> thumper: yeah, I realized that
<mwhudson> i guess we want a richer hook in the scanner really
<thumper> there should always be a branch nick I thought
<thumper> mwhudson: richer hook to do what?
<Ursinha> thumper: what sets the branch nick?
<mwhudson> thumper: be notified when a branch is marked as merged
<thumper> Ursinha: the branch command, or explicitly setting the nick
<thumper> mwhudson: there is an event that is fired for that
<Ursinha> thumper: hmm, nice
<mwhudson> thumper: yeah, but it's in process only
<mwhudson> something like http://code.google.com/p/pubsubhubbub/ might be cool
<thumper> hmm...
<thumper> mwhudson: I was also thinking web-hooks
<mwhudson> or xmpp or whatever
<thumper> mwhudson: although that may not do exactly what we want
<thumper> webhooks wouldn't be too hard to write
<Ursinha> thumper: how would I use that?
<mwhudson> Ursinha: so first, fix launchpad!
<mwhudson> :-)
<thumper> heh
<Ursinha> lol
<thumper> Ursinha: well, we'd have to write it first
<thumper> but then you would be able to connect a web hook to a branch
<mwhudson> Ursinha: http://timothyfitz.wordpress.com/2009/02/09/what-webhooks-are-and-why-you-should-care/
<thumper> Ursinha: what mwhudson said
<mwhudson> we'd have to offer project wide subscriptions or something
<mwhudson> if you could subscribe to attribute changes on all branches already you could do it by parsing email
<Ursinha> mwhudson: hmm, that's cool
<Ursinha> (the link, I mean)
<mwhudson> yeah, it's a cool idea
<mwhudson> i guess it doesn't solve your immediate problem though...
<mwhudson> interesting bunch of people in the commenters
<mwhudson> simon willison makes the point that had occurred to me...
<mwhudson> i'd probably want to write the webhook pinger in twisted
<thumper> mwhudson: well, structural subscriptions for branches was never really delivered
<mwhudson> thumper: yah
<thumper> s/really//
<Ursinha> mwhudson: when subscribed to a branch, what changes do I get?
<thumper> mwhudson: I would have thought a job to do the webhooks
<thumper> Ursinha: it depends what you ask for
<mwhudson> thumper: i guess using aaron's twisted runner :-)
<thumper> Ursinha: you can ask for all revision mail
<Ursinha> thumper: what can I ask for :)
<Ursinha> ah
<mwhudson> Ursinha: you can get notification of status updates for sure
<thumper> Ursinha: you can get revision email without diffs if you like
<thumper> Ursinha: and status updates for when merged
<Ursinha> thumper: I guess that subscribing to all branches and parsing email could be one way.. but even though, how would I know about newly created branches only?
<Ursinha> thumper: or, how hard would it be to implement a way to getting branches by date_created?
<thumper> Ursinha: with that structural subscriptions stuff that we haven't written yet
<thumper> Ursinha: probably not too hard
<thumper> thumper: although I feel that adding lots of optional fields to getBranches is getting a little icky, but may be the only way
<thumper> mwhudson: thoughts?
<mwhudson> thumper: "it would be nice if we could expose branchcollection through the api"
<mwhudson> until then, lots of optional fields to getBranches isn't so bad i guess
<thumper> mwhudson: we don't have an adaptation method in the api
<thumper> mwhudson: although gary was keen to hear more about the idea
<thumper> mwhudson: so something may happen
 * thumper crosses fingers
<mwhudson> yeah, jml was vaguely optimistic at lca about it
<Ursinha> thumper: when you say it's probably not hard, you mean it could be done in a near future? :)
<thumper> Ursinha: it could be done in less than 30 minutes
<Ursinha> holy crap
<thumper> Ursinha: most of that is writing the test
<thumper> Ursinha: the code to do it is trivial
<thumper> Ursinha: if you know where to look
<Ursinha> thumper: really? can you do that? :)
<thumper> not right now... my brain is fuzz
<Ursinha> thumper: I can find you coffee if you want :)
<thumper> Ursinha: file a bug, assign it to me, and I'll get it done first as a priority for you
<mwhudson> my brain is not so fuzzy but i don't know how to do it :-)
<Ursinha> thumper: thank you very much a bazillion times
<thumper> mwhudson: I've created the branch already
<thumper> I'll see what I can get done in the next 10 minutes before boarding
 * thumper violates kanban even more
<Ursinha> thumper: that's ninja
<thumper> mwhudson: do you know how to pass a date into the API?
 * thumper tries just setting as datetime
<mwhudson> thumper: no
<thumper> Ursinha: would a modified_since be enough for you?
<thumper> Ursinha: we don't currently expose the created since through the collection
<Ursinha> thumper: hm
<thumper> Ursinha: well, tough that is what you are getting :)
<Ursinha> thumper: haha
<Ursinha> thumper: well, modified_since should work, I guess
<Ursinha> thumper: if I create a branch today, that modified_since would be today, right?
<thumper> yep
<Ursinha> thumper: so awesome
 * thumper is just finishing off the test
<thumper> boarding call expected in < 5 minutes
<thumper> TypeError: datetime.datetime(2010, 1, 1, 0, 0, tzinfo=<UTC>) is not JSON serializable
<thumper> arse
<dhillon-v10> mwhudson: hi there :)
 * thumper tries something else
<Ursinha> thumper: bug 518607
<mwhudson> dhillon-v10: hi
<mup> Bug #518607: Add a way of searching for branches by date_created using the API <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/518607>
<dhillon-v10> mwhudson: a quick question, is is possible to add a page to launchpad, this was a feature request, someone wanted to have stock replies in launchpad, so what I thought we could do is to copy/port the stock replies from ubuntu wiki page to a launchpad page, and on the little sidebar where it says "Convert to Question" have a link to that page, is that possible
<mwhudson> dhillon-v10: well, there's already the faq system in the answers application
<thumper> boarding now
<thumper> Ursinha: branch being pushed
<mwhudson> i guess you could convert-to-bug and answer with a faq at the same time
<mwhudson> thumper: are you working tomorrow?
<thumper> mwhudson: probably partially
<Ursinha> thumper: <3
<mwhudson> thumper: ok
<thumper> I have to go now, but will try to sumbit for review in CHC
<Ursinha> thanks thumper :)
<dhillon-v10> mwhudson: this was more off in malone, so bug triagers can easily refer to them when needed
<mwhudson> dhillon-v10: ah
<Ursinha> thumper: have a nice flight
<mwhudson> dhillon-v10: this rings faint bells, have you searched the tracker?
<dhillon-v10> mwhudson: please reword that? do you mean looking for a duplicate bug
<mwhudson> dhillon-v10: i mean, i think there is a bug asking for this already
<mwhudson> https://bugs.edge.launchpad.net/malone/+bug/30655
<mup> Bug #30655: stock replies would be nice <feature> <ubuntu-qa> <Launchpad Bugs:Triaged by dhillon-v10> <https://launchpad.net/bugs/30655>
<mwhudson> oh i see, you commented on it a few days ago :-)
<dhillon-v10> mwhudson: :)
<dhillon-v10> mwhudson: that's precisely it, you are pretty fast at searching bugs :)
<mwhudson> dhillon-v10: well, it sounds sane to me
<mwhudson> dhillon-v10: i'd suggest talking to someone in the malone team, and also looking at the faqs in answers
<mwhudson> (as that is the most similar functionality we have today)
<mwhudson> dhillon-v10: i think we'd want something that a project or distro admin/bug supervisor could edit
<mwhudson> dhillon-v10: and then 'a stock reply' link could pop up a javascript overlay that would allow selecting an answer
<mwhudson> (i think bdmurray has a greasemonkey script that does something like this already?)
<dhillon-v10> mwhudson: faq are good, but IMHO not of much use if users can't refer to them, also the wiki page I was talking about has some really nice and general instructions, oh yes the js link could be *very* useful and yes bdmurray does have one that works :)
<mwhudson> dhillon-v10: something ubuntu-specific or that required changing the launchpad source code to change the stock replies would probably not be popular
<dhillon-v10> mwhudson: ahh, didn't think of that :) you are right
<mwhudson> hm, yes some of those replies are pretty generic
<mwhudson> apart from the way that they all start "Thank you for taking the time to report this bug and helping to make Ubuntu better. "
<mwhudson> but that's fixable i guess
<dhillon-v10> mwhudson: :) yes, so what do you say, this is something that could be potentially useful especially for new users
<mwhudson> dhillon-v10: all of this sounds like a fair amount of work, tbh
<dhillon-v10> mwhudson: ahh, like how much, a lot or a lot lot lot
<mwhudson> dhillon-v10: if you've not hacked on launchpad before, i'd find something smaller to start with
<mwhudson> dhillon-v10: maybe "a lot", definitely not "a lot lot lot" :-)
<dhillon-v10> mwhudson: I am working on that blueprint spec that we talked about the other day, have quite a bit of it figured out, just a little left on that one :)
<dhillon-v10> mwhudson: * blueprint tacker
<dhillon-v10> mwhudson: haven't been able to get in touch with Curtis though
<mwhudson> dhillon-v10: curtis should be back online in a couple of days
<mwhudson> (he just sent an email about his travel arrangements being disrupted by snow)
<dhillon-v10> mwhudson: i figured he must have been pretty busy :) so in the mean time I decided to look up something else like this one, but if you think I shouldn't work on this one, I'll probably find a different task
#launchpad-dev 2011-01-31
<StevenK> Right
<lifeless> so no builds is a subset of no builds in the last 24 hours
<lifeless> mvoe the date constraint into th ejoin
<lifeless> as a > $earliest_build_date_we_would_consider
<lifeless> either http://pastebin.ubuntu.com/560426/ or
<lifeless> http://pastebin.ubuntu.com/560428/
<lifeless> I think 50426 will work though; use that if possible - write tests to be sure
<StevenK> I think I have enough test cases
<lifeless> ok
 * StevenK waits for druzhnaya to actually talk to him
<StevenK> lifeless: So with 560426, I should put an And() inside the LeftJoin?
<wgrant> Huh.
<wgrant> https://lpstats.canonical.com/graphs/PrivateArchiveTokens/20100201/20110201/
<wgrant> What happened at the end of November?
<huwshimi> lifeless: with your comment on Bug #435779 about changing staging to qastaging it can be done, but will it mean changing the push lines to bzr push lp://qastaging/~your-id/branch-name etc? I'm just looking at the sandbox "What's this?" dialogue: https://launchpad.dev/+help/home-page-staging-help.html
<StevenK> wgrant: SC, at a guess
<wgrant> StevenK: That was my thought, but I would have expected that a month or so earlier.
<wgrant> Perhaps apps only started really appearing in November.
<wgrant> huwshimi, lifeless: Also, qastaging updates should be fixed before we recommend it.
<StevenK> wgrant: I can think of someone you can ask. :-)
<StevenK> lifeless: Storm seems to eat my brackets :-(
<lifeless> huwshimi: yes
<lifeless> wgrant: perfect enemy of good
<lifeless> wgrant: thats really not a must do to suggest it rather than staging
<lifeless> StevenK: yes, and AND
<huwshimi> lifeless: Great thanks for that
<lifeless> StevenK: what brackets is it eating
<wgrant> lifeless: It's awkward to try things on qastaging when your project probably isn't there.
<lifeless> wgrant: that applies equally for new projects to both staging & qastaging
<lifeless> wgrant: its also straight forward to fix
<StevenK> lifeless: http://pastebin.ubuntu.com/560435/
<lifeless> StevenK: should be fine
<lifeless> StevenK: unless pg is bitching?
<StevenK> Except it doesn't work :-)
<lifeless> in what way
<StevenK> lifeless: My test case is create a recipe, then create two builds for the recipe, one created 24 hours ago, and then other 8, and then call makeDailyBuilds(), which should return []
<lifeless> ...
<lifeless> StevenK: (and what is it returning)
<lifeless> StevenK: I'm not doing anything else while I help you
<StevenK> lifeless: Oh. It returns a new build
<lifeless> which of the two
<StevenK> Neither of them, a new one
<thumper> huwshimi: hi
<lifeless> StevenK: sounds like you need more visibility into what its doing/seeing
<huwshimi> thumper: Hey there
<thumper> huwshimi: do you know where we are supposed to make CSS edits?
<thumper> huwshimi: I'm wanting to make the yui3-ieditor-error not be 0.5em
<thumper> can't read the freaking error :(
 * thumper is supping on a lovely quad-shot flat white in a cafe
<thumper> lovely
<huwshimi> thumper: most of the css is in one of two files. I'll just grab you the location
<thumper> huwshimi: ta
<huwshimi> thumper: Are you adding something new or modifying something?
<thumper> huwshimi: I think it is new as I can't find a style locally for it
<thumper> huwshimi: does come from combo.css
<thumper> whereever that is
<james_w> yui?
<thumper> I tried some css.in file... but it didn't end up showing
<thumper> james_w: yeah
<lifeless> StevenK: also, do you need to restrict by archive?
<StevenK> lifeless: makeDailyBuilds() decides what to do based on the query, if the query returns a recipe when it shouldn't, it will create a build for it
<huwshimi> thumper: I'm not sure of the best way to do it when it's dealing with the YUI stuff.
<lifeless> StevenK: I get that, but to figure out whats wrong we need more info. 'Transparency'
<thumper> huwshimi: so what is the best way?
<huwshimi> thumper: that .in file is the main one, but there are separate files that specifically deal with yui stuff
<lifeless> StevenK: e.g. perhaps log 'creating new build for recipe %s with prior build %s on %s'
<thumper> huwshimi: do I need a special make target to make our css?
<huwshimi> thumper: but they are in the lazr-js build directories and I'm not sure if we can touch them
<StevenK> lifeless: Sorry about the wrapping: http://pastebin.ubuntu.com/560436/
<thumper> huwshimi: I'm sure I can sort something out :)
<huwshimi> for example there is this file: lazr-js/build/inlineedit/assets/skins/sam/editor-skin.css
<huwshimi> thumper: ^
<StevenK> lifeless: It's the earlier query where we moved date_created into the JOIN. I'd expect that to return zero rows, not two
<huwshimi> thumper: which references .yui3-ieditor-errors
<thumper> huwshimi: yes it does, and it says 0.5em
<thumper> grr!!!
<huwshimi> thumper: but if you change that file I'm not sure if it will get overwritten at some point if there is a lazr-js update
<huwshimi> thumper: I don't really know how the lazr stuff works
 * thumper thinks....
<lifeless> StevenK: its returning 2 rows because you've unique data in the select clause
<thumper> haha
<thumper> huwshimi: the reason it is 0.5em is for the title errors
<thumper> huwshimi: if you are editing an h1, then 0.5em is fine
<thumper> huwshimi: but editing a multiline box where the text is 12pt
<thumper> huwshimi: 0.5em sucks arse
<StevenK> lifeless: So removing BuildFarmJob.date_created, I still get one row
<huwshimi> thumper: Ah right, yeah that would
<thumper> huwshimi: seems like a general fail all round
<thumper> huwshimi: where there is an implicit assumption on the text size
<lifeless> StevenK: add a constraint that date_created is NULL to the where
<huwshimi> huwshimi: And now you know why text sizing is so difficult with em or %
 * huwshimi is talking to myself
<huwshimi> thumper:  And now you know why text sizing is so difficult with em or %
<thumper> huwshimi: yup
<thumper> w00t
<thumper> my widget refactoring branch just passed ec2 test
<thumper> and is being landed \o/
<huwshimi> thumper: so you could add a specific rule for the situations where the font size will be too small
<thumper> huwshimi: yeah, I'll be looking at something like that
<thumper> huwshimi: I have a cunning plan
<StevenK> lifeless: Adding BuildFarmJob.date_created == None still has the test failing
<thumper> hmm....
 * thumper bets that webservice_error values aren't inherited
<lifeless> StevenK: sigh, grumble. (Not at you)
<lifeless> StevenK: gimme a sec
<huwshimi> thumper: I don't like the sound of this... often when I hear cunning plan it equals "dodgy hack"
<thumper> huwshimi: trust me grasshopper :)
<huwshimi> thumper: haha
<thumper> huwshimi: what turns our css.in file into a real css file?
<huwshimi> thumper: we have a build script. It will get built every time you run 'make run' or you can rebuild it while the dev server is running by using 'make css_combine'
<thumper> huwshimi: ta
 * thumper didn't even need to add a new css class
 * thumper stabs the code in the face
<thumper> my css fix worked
<lifeless> StevenK: ok
<thumper> but not my webservice error annotation to existing exceptions
<lifeless> StevenK: I'm all yours, lets look harder
<huwshimi> thumper: I don't think I even want to know what you just did
<thumper> huwshimi: not rocket science: .lazr-multiline-edit .yui3-ieditor-errors {    font-size: 100%;     }
<huwshimi> thumper: Ah ok that looks ok
<StevenK> lifeless: I have the test logging, but it doesn't help much, since it's query
<thumper> huwshimi: although editing the programming languages of a project when there is an error will render unreadable error text
<thumper> huwshimi: as it is a text line editor
<thumper> huwshimi: however it does this now
<thumper> so it isn't new
<thumper> just still shit
<lifeless> StevenK: ok, so, we have 0 > N rows in bfj
<StevenK> Right
<lifeless> if we constrain(in the join) any of the relations such that no rows are emitted, the left join means that the spr will be returned
<lifeless> this applied to each left join expansion
<StevenK> Hm
<StevenK> lifeless: This is fine, for the no-builds case
<lifeless> ok
<lifeless> we *do* need the right join
<lifeless> because
<thumper> oh FFS
<lifeless> we want to treat those three tables as inner joins
<lifeless> this works perfectly for me
<lifeless> and takes 6ms
<StevenK> lifeless: Can haz query you used?
<lifeless> just pasting
<lifeless> http://pastebin.com/5x6vkZx5
<lifeless> on qsstaging, which has an updatish awn-testing recipe, it excludes it, and includes it when I drop the date back a day
<lifeless> the brackets in the join don't matter
<lifeless> I just had them in from before
<StevenK> lifeless: So expanding this out to the code: This means that BFJ and PackageBuild change from LeftJoin to Join and the other LeftJoin turns into a RightJoin?
<lifeless> yes
<lifeless> and that you need the right join as the outer one
<StevenK> RightJoin(Join(Join ?
<lifeless> StevenK: yes, I think so
 * StevenK tries it
<lifeless> wgrant: btw, you need to be more paranoid about what users do
<lifeless> wgrant: I refer to bug 498642
<wgrant> lifeless: Uh, I tried it.
<wgrant> Which page?
<lifeless> wgrant: put one space, or carriage return in the description
<lifeless> wgrant: I used bugs.qastaging.launchpad.net/launchpad/+filebug
<wgrant> Ahh, different bug.
<StevenK> lifeless: Crumbs, I think that worked.
<lifeless> wgrant: hmm?
<wgrant> lifeless: 498642 and two others that I just closed were filed when any error on the bug form caused an OOPS.
<wgrant> Having a whitespace-only body is a different thing.
<lifeless> wgrant: given that I filed 498642, I beg to differ
<wgrant> I know, but your description doesn't say that :)
<lifeless> wgrant: anyhow, I've reopened it for you
<lifeless> and linked in an oops
<wgrant> I will clarify the description.
<wgrant> However, given the timing, I'm pretty sure this is not the issue you initially reported.
<StevenK> We cannot log you on at the moment due to very high levels of usage
<StevenK> Please try again later
<lifeless> StevenK: ?
<StevenK> Dear NAB, you faiol
<StevenK> *fail
<lifeless> hah, eep
<StevenK> lifeless: So I think the query works for the 'we have builds' case, but not the 'no builds' case.
<lifeless> StevenK: show me the query being generated ?
<lifeless> oh the order_by is totally unneeded, I was using that for my edification
<StevenK> lifeless: I figured, which is why I ignored it
<StevenK> lifeless: http://pastebin.ubuntu.com/560449/
<StevenK> lifeless: I think it's putting the right join in the wrong place
<lifeless> indeed
<lifeless> paste the python
<StevenK> http://pastebin.ubuntu.com/560450/
 * thumper is getting there...
<StevenK> lifeless: I was going to try Join(Join(RightJoin(
<lifeless> StevenK: you've got the wrong table in the joins
<StevenK> I do?
<lifeless> yes
<lifeless> you're inner joining spr and sprb
<lifeless> you want to right outer join spr and the other composite table
<lifeless> I'm just rearranging, one sec
<lifeless> http://pastebin.ubuntu.com/560451/
<lifeless> my indenting is still whack, I just did enough to see what was binding to what
<StevenK> I think mine is worse, but let's see
<StevenK> lifeless: So I think I get why my code was wrong -- the right join was for *both* BFJ and PackageBuild together, right?
<lifeless> StevenK: a join joins two 'tables' together
<lifeless> StevenK: your code was wrong because it inner joined SPR and SPRB togehter.
<lifeless> StevenK: when what we want is an outer join on SPR + [all the rest]
<lifeless> I don't know if that makes sense to you
<StevenK> lifeless: Now we get http://pastebin.ubuntu.com/560452/
<StevenK> lifeless: If that query looks sane, I'll throw it at the rest of the tests
<lifeless> StevenK: that looks sane
 * StevenK bursts into flames to cool down
<StevenK> lifeless: That looks like all tests pass, \o/
<lifeless> excellent
<wgrant> lifeless: Do you have a moment to EXPLAIN ANALYZE the top query on https://lp-oops.canonical.com/oops.py/?oopsid=1839G1380?
<wgrant> It upsets dogfood greatly; I hope qastaging may survive better.
 * thumper sighs
<thumper> time to relocate home
<wallyworld> why the sigh?
<StevenK> Argh, it's getting hotter
<StevenK> Tomorrow is going to be worse :-(
<lifeless> wgrant: iz terribad
<wallyworld> what temp is it?
<wgrant> lifeless: Clearly.
<lifeless> wgrant: jtv has suggested that a union of public + private will perform better
<StevenK> wallyworld: Currently, 33degC, feels like 37
<lifeless> wgrant: (because they are typically lopsided)
<wgrant> lifeless: I've suspected that, yes.
<wallyworld> yeah, it's humid here too. days like this i miss working in an office :-(
<lifeless> stub: hey
<wgrant> lifeless: Ah, it finished on DF... in slightly under 5 minutes.
<lifeless> stub: are you back on deck ?
<stub> lifeless: yo. back on deck.
<lifeless> cool
<StevenK> wgrant: That's better than the last query you got me to run on DF
<lifeless> I have a crazy idea I'd like to run past you
<wgrant> StevenK: Shh.
<lifeless> is it possible to use a plpython(or plsql) function to index on fields in other tables ?
<StevenK> wgrant: Is it hot down there today too?
<wgrant> If so, it would fix just about everything :)
<wgrant> StevenK: Only meant to be 34 today.
<wgrant> So, not really.
<StevenK> Hotter than here
<wgrant> Ah, it was around 40 yesterday.
<lifeless> wgrant: so, 200 seconds cold
<lifeless> 4.2 seconds hot
<wgrant> lifeless: 6s on DF, yeah
<stub> lifeless: Yes, but it is ugly and the indexes might lie (because you have to declare the function as stable rather than volatile, and thus the function definition is a lie too)
<stub> lifeless: A joining table might be more appropriate, either denormalizing or moving the columns if they are only used in tandem.
<lifeless> stub: would they like for reasons other than the referenced data changing ?
<lifeless> stub: so the specific case I'm thinking of is the one I discussed in last tuesdays perf tuesday mail
<wgrant> I also have a very similar case, which makes the publisher slow.
<stub> lifeless: Only when the referenced data changes (inserts, deletes, updates depending on what you are indexing).
<stub> lifeless: It will make inserts slow too of course.
<lifeless> stub: so, perhaps you could have a look at the case I analysed, see the mistakes I made ;). I'm curious what you mean by 'joining table'
<lifeless> stub: is a cross-table function better or worse than denormalisation
<lifeless> or is it case-by-case evil ?
<stub> cross table function can surprise you and shoot you in the foot. If your source data changes (maybe it is stable now, but can you promise about tomorrow?), then you start returning incorrect results. Denormalization is explicit and obvious, can be maintained with triggers, but makes tables wider so more storage and slower to query.
<lifeless> stub: yeah, thats about what I thought
<lifeless> stub: the particular case I'm thinking of the fields being referenced are immutable
<stub> lifeless: There was also a bug where index lookups on a function index where still calling the underlying function, so the approach was useless. Hopefully this has been fixed in 8.4 (I last checked around 8.1 or 8.2 I think)
<lifeless> stub: whee; thats not the case here, but we'd want to test to be sure I think.
<lifeless> wgrant: analyzing now
<wgrant> lifeless: Analyzing what?
<lifeless> http://pastebin.com/rx1F4KRE
<lifeless> you wanted an explain analyze
<wgrant> Oh, right, yes.
<wgrant> Thanks.
<lifeless> wgrant: moving product from prejoin to separate all-product query would help too I think
<wgrant> lifeless: In this case it's all NULL, but yes, it would probably help a little.
<lifeless> wgrant: it will reduce appserver time
<StevenK> lifeless: Did you want to actually review https://code.launchpad.net/~stevenk/launchpad/queue-recipes-better/+merge/47358 or shall I add the usual suspects?
<lifeless> wgrant: 1/2's the query time
<lifeless> Time: 2318.619 ms
<lifeless> wgrant: if I remove the product and spn relations
<wgrant> Huh.
<lifeless> wgrant: http://pastebin.com/he1NJvxx
<stub> Now that Open Office has forked, should we be putting resources into supporting their unique translations format, or should we be putting resources into moving Libre Office to a standard translations format?
<thumper> heh
 * thumper goes to work out how to install libre office
<lifeless> I'd make sure there is a bug upstream
<lifeless> but AIUI we have an importer from their format already, don't we?
<stub> IIRC we do one of mozilla and open office. I think open office.
<wgrant> We definitely do Mozilla.
<wgrant> That's the XPI stuff.
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>      365 / 8767  Archive:+index
<lifeless>       14 /  239  POFile:+translate
<lifeless>       14 /    4  Cve:+index
<lifeless>       13 /  305  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>       13 /   24  NullBugTask:+index
<lifeless>       12 /   12  BugTask:+editstatus-page
<lifeless>        9 /   30  Distribution:EntryResource:searchTasks
<lifeless> bah freenode
<lifeless> hates
<lifeless> I bet that got filtered
 * StevenK prods lifeless so he can go to lunch
<lifeless> StevenK: oh, sorry
<lifeless> StevenK: so
<lifeless> StevenK: there is a daily build archive
<lifeless> StevenK: but we're not filtering the builds against that. Does that matter?
<lifeless> StevenK: e.g. if I manually build a recipe into some other ppa/suite/whatever; does that invalidate the results we're getting?
<StevenK> If it's the same recipe, it will, but I don't think that's a bad thing
<wgrant> We need to restrict the search to the daily build archive.
<lifeless> StevenK: why would it be a good thing?
<StevenK> lifeless: Some sets up a daily build, and requests a build manually. The system then shouldn't request another build for that recipe for another 24 hours.
<lifeless> StevenK: if they do a test build into a different place, why ?
<lifeless> StevenK: I get it if they build into the same archive
<StevenK> Right, I get it
<thumper> grr!!!
<wgrant> thumper: What are you trying to break?
<StevenK> Yeah, we can pull Archive into it
<thumper> why can't we have our javascript not crippled
<wgrant> Heh.
<lifeless> StevenK: so, this can be a different patch; could you file a bug though so we don't forget ?
 * thumper needs to debug some javascript
<thumper> which firebug is normally pretty good at
<lifeless> actually
<lifeless> wgrant: care to review this; I will mentor your review
<lifeless> StevenK: go to lunch
<StevenK> lifeless: But finish reporting the bug first? :-)
<lifeless> StevenK: yes
<wgrant> lifeless: Looking.
<StevenK> lifeless: bug 710435
<StevenK> I never get good numbers
<thumper> anyone know how to non-compress our javascript?
<wgrant> thumper: deryck recently (probably less than a month ago) adjusted devmode to minify everything into a single file, since YUI otherwise wanted to request 500 JS files.
<wgrant> Tracking down that rev might give you a hint.
 * thumper grunts
<thumper> wgrant: I've emailed the list with the real problem
<thumper> wgrant: and that is how to debug javascript
<lifeless> StevenK: when triaging you need to set status as well as importance ;)
<wgrant> StevenK, lifeless: Reviewed.
<StevenK> wgrant: Bah, lifeless agreed that could be done later, as long as filed a bug
<wgrant> I disagree :)
<wgrant> Also, I don't think the series issue was brought up.
<wgrant> But I wasn't really following your conversation.
<StevenK> wgrant: thumper and I spoke about this multiple times at the Thunderdome -- if they add another distroseries to an existing recipe, they can either wait or request a manual build -- I don't think it is going to happen very often
<wgrant> StevenK: I request a test build for Natty to the usual archive.
<wgrant> The other series are then skipped the next day, despite being stale.
 * wgrant lunches.
<huwshimi> Anyone available to review this: https://code.launchpad.net/~huwshimi/launchpad/get-started-text-435779/+merge/47958 (for #435779).
<StevenK> wgrant: The query in question only finds recipes that should be built -- it doesn't care about series.
 * StevenK also lunches, finally
<wgrant> StevenK: Sure, but it needs to check that all the series have been built.
<wgrant> StevenK: Or a build for a single series will cause no builds to be created for *any* series.
<wgrant> mwhudson: Did you get anywhere with that codebrowse auth issue?
<wgrant> lifeless: They're not already present in the tree.
<mwhudson> wgrant: no
<wgrant> lifeless: We don't unset staleness except in the case of daily builds.
<mwhudson> wgrant: didn't really try beyond what i said in the report
<wgrant> mwhudson: Ah :(
<wgrant> I guess I will try to reproduce it locally.
<mwhudson> that would be great
<wgrant> c-i-p funtimes, yay.
 * thumper has found a way
<StevenK> wgrant: Within 24 hours, yes
<wgrant> WTF :/
<wgrant> WTF
<wgrant> c-i-p is just getting more impossible.
<wgrant> It now wants to talk to a 10.x.x.x host.
<wgrant> StevenK: Yes, but it's still a regression.
<StevenK> wgrant: I think it's one we can live with
<wgrant> Why?
<wgrant> Random people requesting builds of my recipe should not affect my builds of my recipe.
<StevenK> Random people can't write to your archive
<wgrant> Ah, if you do add the archive restriction, sure.
<wgrant> Then it's not quite so bad.
<StevenK> wgrant: I'll fix the lint, I think the join is more readable
<wgrant> StevenK: Were you able to avoid the RightJoin?
<StevenK> I'll look at the archive and Archive.default_component
<thumper> wgrant: c-i-p ?
<wgrant> thumper: canonical-identity-provider
<thumper> ha
<thumper> ah
<StevenK> wgrant: lifeless and I have rewritten that query about 3 times
<wgrant> StevenK: Can't you just reverse the order and use a LeftJoin?
<wgrant> Oh good.
<wgrant> And the dev config files are private to ISD.
<StevenK> wgrant: But why are you trying to avoid RightJoin?
<wgrant> StevenK: Consistency, mainly.
<wgrant> Nowhere else in the tree uses it.
<StevenK> wgrant: I'm tempted to leave it, since lifeless and I have spent a while crafting it
<StevenK> wgrant: In terms of adding archive, I'm worried the tests are naive
<StevenK> And don't set daily_build_archive
<wgrant> Is this a concern?
<StevenK> wgrant: It could be
<StevenK> wgrant: Is http://pastebin.ubuntu.com/560480/ more to your tastes?
<wgrant> StevenK: Unity doesn't want me to see that.
<wgrant> But yes, that looks OK.
<StevenK> Haha
<wgrant> As for the RightJoin, the tests pass if I s/Right/Left and invert the first two arguments.
<StevenK> All of them?
<wgrant> test_sourcepackagerecipebuild
<StevenK> Drop the build
<StevenK> There's one or two pertinent tests in spr
<wgrant> + pip install -r ./requirements.txt -f 'https://launchpad.net/lazr.restful/+download?start=21' -f 'https://launchpad.net/lazr.restfulclient/+download?start=9'
<StevenK> wgrant?
<wgrant> StevenK: SSO's installation script seems to hardcode batch numbers.
<StevenK> Whee
<wgrant> StevenK: Lots of the SPRecipe tests fail because lazr.restful hates Natty, but all the relevant ones look good.
<StevenK> wgrant: See lifeless' comment on the MP, though
<wgrant> StevenK: http://pastebin.ubuntu.com/560481/
<wgrant> Ah, hm.
<wgrant> I don't particularly buy that rationale. But perhaps I misunderstand.
<StevenK> You don't think information for a build is split between BFJ, PackageBuild, and SPRecipeBuild?
<wgrant> I do.
<StevenK> Still can't bring myself to say SPRB
<wgrant> But I have never seen a case where a right outer join is justified. Unless I seriously misunderstand what it is, it can be trivially replaced with a left outer join.
<wgrant> 'we can't left join with it because the condition for restricting interesting builds is to the right of one of the partitions' makes very little sense.
 * thumper stabs CSS in the face
<huwshimi> thumper: In a good way?
<thumper> huwshimi: I'm finding lots of CSS stuff ups
<thumper> huwshimi: go into any bug on qastaging
<thumper> huwshimi: and delete the description
<thumper> huwshimi: and try to save
<thumper> huwshimi: I've worked out how to fix the "always loading" issue
<thumper> huwshimi: but the error styling messes up how it looks "a lot"
<thumper> huwshimi: for any multi-line editor, the tab gets an off by one error when you edit
<thumper> huwshimi: the curved line gets an extra pixel
<thumper> huwshimi: the edit box is one pixel too wide
<thumper> (those are two different off by one errors)
<thumper> huwshimi: and I told you about the off by one pixel issue on mouse over
<huwshimi> thumper: ouch
<huwshimi> thumper: oh, now I see what you mean by the error text too
<thumper> the "always saving" issue is a lazr-js problem
<thumper> I'll be submitting a fix for that soonish
<thumper> but the styling is really annoying
 * thumper fires up a lazr-js branch to mess around in
<huwshimi> thumper: Might add that hover stuff to my queue for this afternoon
<thumper> huwshimi: it may well be in lazr-js
<thumper> huwshimi: let me look, since I'm there anyway
<huwshimi> thumper: ok sure.
<wgrant> huwshimi: Yay for eliminating facet colours.
<wgrant> Although it does sort of invalidate our logo.
<huwshimi> wgrant: Haha. We MUST keep all the colours, the logo says so. Whatever will we do!?
<wgrant> Exactly!
<StevenK> Hm
<huwshimi> wgrant: Just don't mention that logo thing to anyone else alright! :P
<thumper> I liked the facet colours
<thumper> :(
<thumper> what's changed?
<thumper> huwshimi: I've fixed two 1px problems
<thumper> now looking at the error one
<huwshimi> thumper: Awesome. Nice work.
<StevenK> wgrant: Attempting to add packagebuild.archive == sprecipe.daily_build_archive isn't working. :-/
<wgrant> StevenK: Oh?
<wgrant> What does it do?
<wgrant> And where are you putting it?
<StevenK> In the join of PackageBuild
<wgrant> Hmm
<StevenK> And it doesn't like it since SPRecipe isn't in the mix yet
<lifeless> wgrant: that aren't ?
<wgrant> lifeless: Pardon?
<lifeless> bah
<lifeless> wgrant: what defects are not already intree ?
 * StevenK kicks AWS and attempts to extract an invoice from its website
<lifeless> wgrant: also right join is fine, left join would be wrong
<wgrant> lifeless: The ones I mentioned in the bug: creating a build for any series in any archive will prevent daily builds from being created.
<wgrant> This is not the case at the moment.
<wgrant> lifeless: So you keep saying, but I do not see why.
<wgrant> Could you explain?
<lifeless> wgrant: I don't see how it can be the case at the moment
<wgrant> lifeless: Now you have me confused.
<lifeless> wgrant: bah, I mean, why isn't the bug present in the tree at the moment
<wgrant> lifeless: Because it only checks for is_stale. is_stale is set when a change is made to the branch, and unset when a daily build is requested.
<wgrant> Manual builds do not affect the flag.
<lifeless> ok, Isee
<wgrant> Now, in addition to the flag being set, there must be no builds.
<lifeless> then yes, we need to constrain by archive to fix that
<lifeless> s/\./in the last day./
<wgrant> Right.
<lifeless> wgrant: whats the left join that you think works ?
<wgrant> lifeless: The right join, except with the arguments reversed.
<wgrant> I pasted a diff somewhere above.
<wgrant> http://pastebin.ubuntu.com/560481/
<lifeless> wgrant: what sql does that compile to ?
<wgrant> SELECT DISTINCT SourcePackageRecipe.build_daily, SourcePackageRecipe.daily_build_archive, SourcePackageRecipe.date_created, SourcePackageRecipe.date_last_modified, SourcePackageRecipe.description, SourcePackageRecipe.id, SourcePackageRecipe.is_stale, SourcePackageRecipe.name, SourcePackageRecipe.owner, SourcePackageRecipe.registrant FROM SourcePackageRecipe LEFT JOIN (SourcePackageRecipeBuild JOIN PackageBuild ON PackageBuild.id = ...
<wgrant> ... SourcePackageRecipeBuild.package_build JOIN BuildFarmJob ON BuildFarmJob.id = PackageBuild.build_farm_job AND BuildFarmJob.date_created > %s) ON SourcePackageRecipeBuild.recipe = SourcePackageRecipe.id WHERE SourcePackageRecipe.is_stale = %s AND SourcePackageRecipe.build_daily = %s AND BuildFarmJob.date_created IS NULL
<wgrant> Which looks fine.
<lifeless> ok, that would be ok
<lifeless> StevenK: you can switch to that if you want; I don't care. Otoh avoid right join just because it hasn't been used would be noddy
<StevenK> You really do like using the word 'noddy' recently, have you been reading the books?
<lifeless> which books?
<wgrant> lifeless: Avoiding divergence that cannot be explained sounds very reasonable to me.
<StevenK> lifeless: http://en.wikipedia.org/wiki/Noddy_%28character%29
<wallyworld> why do elephants have big ears?
<wgrant> The use of RightJoin confused everyone into thinking it was more complex than it was.
<lifeless> StevenK: no
<wallyworld> because Noddy wouldn'y pay the ransom HAHAHAHAHA
<wgrant> When a perfectly good LeftJoin worked perfectly fine.
<lifeless> wgrant: its not complex; a left join with inner table is more complex (need brackets to express it)
<StevenK> wgrant: A LeftJoin and a RightJoin aren't any more complex than each other?
<wgrant> StevenK: No, they are identical. But some were arguing that a right join was the only way to do it.
<lifeless> that said, I don't care; its entirely irrelevant that right join hasn't been used so far. LP is only beginning its optimisation path.
<wgrant> lifeless: I'd want the right join parenthesised too, for clarity.
<lifeless> I'd stay with the right join at this point because its working, is correct, and produces more readable SQL.
<wgrant> Hm?
<lifeless> wgrant: for that, you need to patch storm
<wgrant> What is unreadable about "table LEFT JOIN (other table JOIN other table ...)"?
<wgrant> It expresses the intent more clearly.
<wgrant> We want table.
<lifeless> less readable
<wgrant> Not (other table JOIN other table ...)
<lifeless> this seems like a pointless debate
<wgrant> It is.
<lifeless> from a review standpoint, right join does the job and is correct, and no clearer than left
<lifeless> nor less clear
<StevenK> lifeless: To be frank -- so the fact that nothing else uses it in the tree is irrelevant?
<lifeless> indeed
<lifeless> identical plans
<lifeless> wgrant: the nothing-else-uses-it argument is irrelevant because left isn't intrinsically better than right, and there will always be things that happen for the first time.
<lifeless> viva la difference
<wgrant> lifeless: Things do happen for the first time, yes. But in this case there was precisely 0 benefit in introducing a new way to do things.
<wgrant> And I believe the left join expresses the intent more clearly.
<wgrant> So I argued for that.
<lifeless> wgrant: why do you think it expresses it more clearly?
<StevenK> Ugh, 33degC
<StevenK> Perhaps the other side of the apartment is cooler, but I doubt it
<wgrant> lifeless: Because the left one joins conditions onto the target table, rather than joining the target table onto the conditions.
<StevenK> wgrant: "Bikeshed"
<wgrant> Definitely.
<lifeless> I agree
<wgrant> I was not going to argue for it strongly until lifeless stated that a left join would not work.
<lifeless> For reviews, we need a massive increase in readability to cover the cost of a discussion
<wgrant> Then I feared that I had some deep misunderstanding of joins.
<lifeless> wgrant: I misspoke; I was having fumble-fingers in crafting manual sql
<wgrant> Right.
<lifeless> LEFT actually.
<wgrant> That is clear now.
<wgrant> But it didn't become clear until this argument was well underway :)
<lifeless> :)
<lifeless> wgrant: nice catch on bug 579987
<lifeless> wgrant: are you cruising for oopses to fix ?
<wgrant> In other news, SSO has actually succeeded in being harder and more time consuming to install than the Launchpad that it is mean to be an improvement on.
<StevenK> Where did our bug bot go?
<wgrant> lifeless: I'm babysitting c-i-p for now, but plan to look at Archive:+copy-packages seriously next.
<lifeless> cip ?
<lifeless> howso?
<wgrant> canonical-identity-provider, so I can debug the private codebrowse issues.
<lifeless> \o/
<lifeless> wgrant: O
<wgrant> Since they hit me a few times a day, and it is sort of getting old.
<lifeless> wgrant: I've pointed bigjools and sinzui at the 16K oopses from codebrowse;
<wgrant> lifeless: Yes, but loggerhead.
<lifeless> wgrant: you do look at /launchpad-project for bugs, right ?
<wgrant> Occasionally.
<lifeless> so, partial success \o/
 * thumper away cooking
<BjornT_> lifeless: fwiw, the lp-architecture i was doing wasn't a complete redo. it re-used existing docstring and doctests. i was careful which doctests got included, though, since probably more than 90% of the existing doctest do a bad job at being documentation. it was also meant as a guideline of how to write new documentation.
<lifeless> BjornT_: kk; some of that nuance got lost in handover
<poolie> lifeless, is lp planning to make a new api version snapshot some time?
<poolie> i see people are now being advised "just point to /devel" which seems likely to cause the same problems as with beta all over again
<lifeless> poolie: yes
<lifeless> poolie: for things that they aren't shipping on cd-roms
<lifeless> we probably need to get a bit more rigorous about when to freeze things
<poolie> probably
<poolie> even just freezing whatever's in there every six months could be a start
<poolie> (i don't know if supporting multiple versions is expensive in the code or something)
<wgrant> And more rigorous about what we freeze.
<lifeless> hugely
<poolie> hugely expensive?
<lifeless> its awfully complex, prevents refactoring, freezes concepts that are mutable
<poolie> sure
<lifeless> prone to failure, hard to report on.
<poolie> it's like our api stability
<lifeless> poolie: its worse
<poolie> oh, why?
<lifeless> poolie: because we have to support them all concurrently
<poolie> hm, kind of
<lifeless> poolie: we can't say 'if you want the old api, don't upgrade your package'
<poolie> i see what you mean, but in practice when people get a new ubuntu release, they get a new bzr
<poolie> and either bzr or the plugins needs to cope
<poolie> anyhow
<poolie> istm that at the moment lp just says "there are no promises about apis"
<poolie> which may actually be the most sensible way to do it
<poolie> anyhow, it is hadr
<poolie> my main concrete suggestion was just to do a snapshot once or twice per year
<poolie> even if they're only supported for a year after that
<poolie> tangentially, from max:
<poolie> > Yes, it's really true - earlier launchpadlib versions only offered you the choice of edge or staging.
<wgrant> Well, lpnet didn't have the API for ages, because it was in beta.
<poolie> i know
<poolie> i just wonder if it would have been better to declare the url, even if it didn't work
<poolie> maybe not
<poolie> was from https://code.launchpad.net/~maxb/bzr/launchpadlib-service-root-api-compat/+merge/47885
<wgrant> mwhudson: Naturally, codebrowse auth is completely reliable locally with a local c-i-p.
<wgrant> Hmm.
<wgrant> It's a bit of a wild guess, but I wonder if only one of the login.launchpad.net IPs is visible from wherever runs codebrowse.
<lifeless> so
<lifeless> lp had the crazy thing of 'beta means a different cluster' which had all sorts of negatives
<lifeless> I would have done it differently
<lifeless> but its history: no second guessing
<wgrant> s/would //
<lifeless> we're doing it differently now
<wgrant> lifeless: Who can check firewall rules?
<lifeless> losa + gsa I believe
<spm> well gsa only actually.
<wgrant> poolie: Oh, ugh, just read that MP.
<wgrant> That's really awful.
<poolie> lifeless/lp hackers, congratulations on your timeout reduction!
<lifeless> poolie: thanks
<lifeless> (on behalf of the folk that did all the work)
<lifeless> bwah, no stub
<lifeless> spm: what LPCONFIG / dbuser does the garbo run under?
<spm> prod for 1
<spm> garbo_daily & garbo_hourly for 2
<lifeless> spm: you can do permission changes live, right ?
<spm> with extremely good reasons for, maybe. depends.
<lifeless> so yes, great.
<lifeless> spm: do we run security.py --incremental on nodowntime deploys yet?
<spm> not that I'm aware of. that'd require a manual intervention on the db servers
<lifeless> spm: shouldn't need to be manual.
<lifeless> I'll ask stub to RT up whats needed.
<spm> oh god yes it should.
<lifeless> spm: why?
<poolie> i got a "Your message was rejected" mail in response to my mp comment
<poolie> i guess this is because a list is subcribed, perhaps launchpad-bugs
<lifeless> yes
<lifeless> grrr
<lifeless> any reviewers around ?
<lifeless> \o/
<lifeless> https://code.launchpad.net/~lifeless/launchpad/bugtask+index/+merge/47969
<lifeless> stub: ^ if you're around, I can has review?
<stub> k
<stub> Internet is still sucking :-P
<LPCIBot> Project devel build (404): FAILURE in 6 hr 54 min: https://hudson.wedontsleep.org/job/devel/404/
<lifeless> well, thats bangkok isn't it ? :)
<stub> At least I have the excuse of living in the 3rd world.
<wgrant> Hah.
<wgrant> c-i-p boog.
<lifeless> wgrant: you've made progress ?
<wgrant> lifeless: I can reproduce it locally and see why it's doing what it's doing.
<wgrant> Now I need to go and read the spec :(
<lifeless> stub: how long will it take to add an index to BugMessage.index
<stub> lifeless: Any reason why indexMessages rewrites .index on all BugMessages, even if it is already set?
<lifeless> stub: its simpler than checking that all the unallocated ones have been allocated by the same algorithm
<lifeless> stub: e.g. if someone deletes a BugMessage it will handle that
<stub> There is already one on (bug, index)...
<lifeless> stub: yeah, but the garbo needs to find all with index is NULL
<lifeless> stub: for a few months while we let the garbo build the per bug indices
<stub> 6.5 seconds on staging for just an index on BugMessage.index
<stub> lifeless: I thought one of the points of this column was to keep stable message indexes?
<lifeless> stub: it is; needs to be phased in
<stub> Shouldn't take months. I would have thought fairly quick even with the current index (I think it will get used once a sizable percentage of the rows are filled, even if it isn't the optimal index).
<lifeless> stub: phase 1 - get the index approximately up to date; phase 2 - appservers / mail processing starts writing BugMessage.index too; phase 3 field mandatory garbo job removed; phase 4 start querying from the index
<adeuring> good morning
<lifeless> stub: looks to do a seqscan at the moment; we can wait for doing an index on bm.index specifically
<stub> It will do a seqscan until it is more efficient to use an index, which would mean a pretty high percentage of the rows have been updated. Until then, it is faster to do seqscan than use an index.
<lifeless> stub: indeed, and thats fine; I'm not sure that there *is* an index for it to use.
<lifeless> stub: because the (bug, index) index isn't selective on index unless bug is being considered (which it isn't for the populate case)
<bigjools> morning
<stub> lpmain_staging=# explain select bugmessage.id from bugmessage where index is null limit 50;
<stub>                                                   QUERY PLAN
<stub> ---------------------------------------------------------------------------------------------------------------
<stub>  Limit  (cost=0.00..2.03 rows=50 width=4)
<stub>    ->  Index Scan using bugmessage__bug__index__key on bugmessage  (cost=0.00..149895.69 rows=3700397 width=4)
<stub>          Index Cond: (index IS NULL)
<stub> (3 rows)
<lifeless> stub: *blink*
<lifeless> stub: that shows a seq scan fo rme
<lifeless> on staging
<lifeless> oh if you turn seq scan off it will force an index; doesn't mean its a good one :)
<lifeless> stub: I suggest we sit on the need for an index until this is running live
<lifeless> stub: and we can see how its going
<stub> I think they introduced that around 8.3 - before it could only use the index if you where selecting on the left most columns.
<stub> lifeless: You need to explicitly disable sequential scans (set enable_seqscan to false)
<lifeless> yeah
<stub> I can create the index live if we want, or we can add one in a db patch it we also open a bug stating it to be removed
<lifeless> stub: indeed
<lifeless> stub: either way I think deferring it till we have the garbo live makes sense, do you ?
<stub> yes
<stub> Do we still have an anal XXX policy  or did we drop that?
<stub> Hehe... anal XXX
<stub> See what Google thinks of our IRC logs now.
<bigjools> thanks stub, I just lost a mouthful of coffee over my desk
<lifeless> stub: nothing in https://dev.launchpad.net/PythonStyleGuide  about xxx :P
<lifeless> stub: even if we have something, I would argue that this one is going to last 4 months tops till the migration is complete.
<lifeless> then the garbo job goes away
<stub> Sure. Just wondering if it will trigger any XXX reporting tools someone is running that expects a bug number in there.
<lifeless> oh no
<lifeless> they are stale
<mrevell> Hi
<stub> lifeless: reviewed. A few niggly bits, most likely irrelevant if this code is going away in your stage 4.
<wgrant> lifeless: See my last comment in bug #676372.
<wgrant> I think we should just disable stateful association for now.
<lifeless> wgrant: I don't know what that means
<lifeless> stub: thanks
<wgrant> lifeless: Yay OpenID.
<wgrant> Who knows OpenID?
<stub> I used to
<lifeless> stub: I don't want have to deal with db constraint issues if someone plays silly buggers in the db between now and phase 4 - thats why I'm making them al the same
<lifeless> stub: do you see an issue with that ?
<lifeless> stub: separately, we don't have a bug yet for the separate phases; I don't feel much need to precreate them. Do you?
<stub> Its to make sure the task doesn't get lost or forgotten.
<lifeless> stub: it won't have that affect though :)
<lifeless> stub: 6000 items - anything > 1000 down has been effectively lost already
<stub> I do like todos or XXXs to link to the relevant discussion so if some person trips over them in 2 years time it is clear it is tech debt.
<stub> Referencing Bug #704446 is appropriate
<lifeless> sure, I can do that (though thats not a future bug, thats the current bug :))
<stub> Anyone know about wireless boosting? I'm getting interference and moving the base station is going to be a pain.
<lifeless> you can use iwconfig to set power levels
<lifeless> you could try a different channel
<lifeless> or a second ap
<bigjools> new channel is best bet
<stub> Looks like I'm at max. I already rebooted this morning and got a new channel.
<lifeless> how does reboot <-> new channel ?
<bigjools> multiple APs?
<stub> Second AP might be best. Biggest problem is no power on the stairs.
<stub> lifeless: Its set to auto, so it detects what channel looks cleanest. Of course, what is cleanest on the ground floor isn't necessarily what I get on this side of the house on the 3rd floor.
<bigjools> stub: did you see the last couple of comments on the MP my for debversion changes?
<stub> bigjools: Yes. I was about to test an updated DB patch before lifeless distracted me with his review.
<bigjools> stub: great
<stub> bigjools: I'm preparing a branch based on yours anyway
<bigjools> all the tests pass apart from the db restore one
<lifeless> bigjools: I commented on that; I'm pretty sure its just trusted.sql you need to fiddle
<bigjools> I said that from the start but apparently I needed to put the change in the patch file ...
<lifeless> bigjools: you need both
<lifeless> bigjools: trusted for new dbs, patch to load it in prod
<bigjools>  /o\
 * bigjools -> otp
<lifeless> bigjools: back in england?
<bigjools> yarp
<stub> lifeless, bigjools: I think I'll run it manually on production and staging, and add it to the baseline for devs (launchpad-2208-00-0.sql)
<lifeless> wheee 1727 sql statements
<bigjools> stub: you're talking about my patch?
<stub> bigjools: The debversion.sql stuff, yes.
<bigjools> ah ok
<bigjools> not the other stuff
<bigjools> stub: the other stuff takes 4h on dogfood, can you see a way of speeding it up?  The SPRs take only a few minutes, the rest is the BPRs :/
<stub> Gah... need that debversion package installed on staging.
<stub> http://paste.ubuntu.com/560548/ is the optimized version, and it will go a lot faster with suitable RAM (and workmem setting)
<stub> But we need an empirical test
<lifeless> gnight
<bigjools> stub: huh, didn't think changing types would work
<bigjools> nn lifeless
<stub> bigjools: It probably won't speed things up though - might save a few table scans but that isn't much compared to rewriting all the rows.
<bigjools> I suspect rebuilding the index is the big part
<bigjools> stub: so did you figure out how to include the contrib's sql without pasting it to the patch file?
<bigjools> or are you just literally running it manually?
<stub> bigjools: I'm currently testing manually. I will include it inline in the baseline .sql script (which will be exactly how it will be next time I dump the production schema to create a new baseline .sql).
<bigjools> stub: cool - so are you going to land the patch as well?  If so I'll remove it from my branch (I have other code changes dependent on it)
<stub> bigjools: If you remove stuff from your branch, that will cause conflicts with my branch.
<bigjools> stub: you're confusing me
<stub> I've branched your branch. When I have sorted my end out, including what to do with contrib/debversion.sql I can land it or you can merge it back into your branch.
<bigjools> ok cool
<stub> I think these timings are not going to be happy and this is going to be a sucky two or three part process :-(
<bigjools> yes
<stub> 7 minutes just for spr, not including building the new index.
<bigjools> I don't see how we can upgrade any of it without a load of extra downtime
<bigjools> BPR will take an hour at least
<stub> Ok. There are some active jobs running, but I don't think they will affect things that radically.
<jml> howdy folks
<stub> bigjools: huh. or maybe not.
<bigjools> stub: que?
<bigjools> morning jml
<stub> bpr took 13 minutes
<stub> (setting work_mem to 3GB might be the win there)
<bigjools> stub: to change the  column type or regenerate the index?
<stub> Change the column type
<bigjools> tell me when the index is done :)
<jml> using a different computer & OS today :\
<stub> bigjools: Indexes took < 2mins to build.
<bigjools> !!!
<stub> Setting a high work_mem means indexes get done in ram rather than temporary files
<bigjools> awesome
<stub> So, is this good enough?
 * jml continues experimenting w/ IRC clients
<bigjools> if we're going to be within budget, yesw
<stub> bigjools: http://paste.ubuntu.com/560560/ has the timings
 * stub tries to remember what the budget is atm
<bigjools> 1h total but not sure what else we have
<stub> bugger all after the epic I suspect
<bigjools> those figures are on staging, how different to prod is that?
<stub> Yer - just dropping a column from blueprintnotification
<bigjools> looking good anuway
<stub> Add 50% for production because it has 3 nodes rather than stagings two, and you get a conservative timing (conservative because the production hardware is much faster)
<stub> oh... I just ran that on a single node.
<stub> So triple
<stub> I think we just squeeze in
<bigjools> 22 mins * 3 then?
<bigjools> minus hardware advantage
<bigjools> that is a squeeze
<jml> ahh, that's better
<jml> never been able to use Pidgin / Adium for IRC.
<stub> bigjools: And the fact staging was busy at the time I did the timing.
<bigjools> right
<bigjools> jml: are you being traitorous today? :)
<jml> bigjools: kind of
<jml> bigjools: my laptop is a bit buggy atm due to running natty upgrades. Now I'm using my other computer, which isn't running Ubuntu (although not for lack of trying)
<stub> work_mem != maintenance_work_mem
<jml> I have a feeling we're not in Kansas anymore
<jml> -bash: make: command not found
<jml> -bash: make: command not found
<jml> -bash: make: command not found
<wgrant> Af
<wgrant> Er.
<wgrant> Are you trying to run Launchpad on OS X again?
<jml> wgrant: no, not at all.
<jml> wgrant: and also, I don't recall trying before, unless it was four years ago
<wgrant> Hmm, must have been someone else.
<jml> wgrant: I had a Macbook when I started until about Oct 2008, but I'm pretty sure I dual booted into Linux for Launchpad development. the OS X partition was just for WoW.
<jml> in fact, IIRC, it was missing several core system files. There wasn't much room on that partition, and I had to get rid of *something*
<bigjools> stub: FYI I had to apply this patch to get database upgrading working on DF:  http://pastebin.ubuntu.com/560565/
<stub> bigjools: So it only works at the moment if the cwd is database/schema ?
<bigjools> stub: it worked previously from anywhere, dunno why it stopped working
<bigjools> wallyworld: attaboy :)
<wallyworld> bigjools:  context? my email?
<bigjools> wallyworld: yep
<wallyworld> that's the way i've always approached such things :-)
<gmb> Does anyone know if there's a way to get launchpadlib to stop trying to interact with the Gnome keyring? It always fails if you're in a screen session or accessing the machine remotely.
<wgrant> I hack the keyring egg.
<wgrant> There's a function in there that tries to import the GNOME keyring stuff. I adjust it to always fail.
<gmb> wgrant: Well, I was hoping for something other than "HULK CRUSH", but that works.
 * maxb lols at HULK CRASH
<maxb> on a bus, so quietly :-)
<bigjools> gmb: set a config file
<gmb> bigjools: Can you be a bit more specific?
<bigjools> yes, gimme some, was just looking it up
<gmb> Cool, thanks.
<bigjools> gmb: http://pypi.python.org/pypi/keyring#customize-your-keyring-by-config-file
<gmb> bigjools: Ah, thanks.
<bigjools> use the file backend
<stub> bigjools: lp:~stub/launchpad/debversion-denormalise
<gmb> Right.
<bigjools> stub: ta
<bigjools> stub: so I need to put the contrib sql in trusted.sql now to make local stuff work....?
<bigjools> test_testSampledata still fails anyway
<deryck> Morning, all.
<StevenK> wgrant: https://bugs.launchpad.net/launchpad/+bug/710578 looks like what you were investigating
<_mup_> Bug #710578: Not able to see contents of private branch <Launchpad itself:New> < https://launchpad.net/bugs/710578 >
<stub> bigjools: Nothing needs to go in trusted.sql
<bigjools> stub: ok, how do we fix test_testSampledata?
<stub> bigjools: Works for me with a freshly built database
<bigjools> :/
<bigjools> I just did a make schema and tried it and .... fail
<stub> Doh... wrong tree
 * bigjools keeps sanity - temporarily
<stub> bigjools: Looks like a PostgreSQL bug
<stub> pg_restore --clean is dropping the type, then functions with parameters of that type (which fails, because the type no longer exists)
<bac> mrevell: ping
<mrevell> Hi bac
<bigjools> stub: awesome
<bigjools> stub: can we work around it?
<stub> bigjools: Bug #5857 upstream at http://archives.postgresql.org/pgsql-bugs/2011-01/msg00247.php
<_mup_> Bug #5857: Give clue to scope of changes when linking to changelogs <feature> <lp-soyuz> <Launchpad itself:Fix Released by cprov> < https://launchpad.net/bugs/5857 >
<stub> bigjools: work around will be annoying - rather than use clean, we need to create an empty database and restore into that without --clean
<bigjools> yay :/
<stub> (so race conditions on database creation and tear down to deal with)
<bigjools> stub: what is that test actually testing?  As in, where is that restore stuff used?  Is it just tests?
<jtv> gary_poster: got a minute to help me out with a question about twisted?
<jml> how would you go about telling people about expected mail volume when they "structurally" subscribe to something?
<gary_poster> jtv, I can try
<gary_poster> jml, history
<jtv> gary_poster: voice might helpâ¦ can we mumble or skype?
<jml> gary_poster: is that history in the db?
<gary_poster> jtv, actually, no, I can't. :-) I have tonsillitis
<jtv> Oh!  That's not fun.
<gary_poster> no :-/
<jtv> Hope that gets better soon.
<gary_poster> thank you
<jtv> On a sidenote, it's an affliction I pointedly fail to recommend for distant sprints.
<gary_poster> jml, at a hand-wavy level, at least, yes: most of the things we are interested in filtering on for bugs appear to be visible when you view a bug
<gary_poster> (status changes, and so on)
<gary_poster> but it would be a manual thing
<jml> gary_poster: manual how?
<jml> jtv: #twisted is often helpful, fwiw.
<jtv> Thanks.  I'm looking to parallelize something, and wondering whether twisted is worth it.
<gary_poster> jml, manual is the wrong term.  um, expensive
<stub> bigjools: when we load the sampledata, all the constraints are disabled - including foreign key constraints. So if you edit the sampledata manually, you can end up with corruption.
<jml> gary_poster: ahh, I see.
<gary_poster> unless we did code to make it less so, probably involving cacheing statistics
<jml> gary_poster: was just thinking that it might be a good way to mitigate the social concerns of subscription
<stub> bigjools: foreign key references pointing to non-existent rows in the database. This has happened in the past, thus the test.
<bigjools> ok
<jml> "You will get around 500 emails a day if you do this"
<bigjools> jtv: using twisted on the publisher?!
<bigjools> nonono
<jml> hmm.
<jtv> bigjools: just thought I'd explore how stupid an idea it was before suggesting it. âº  What's the reason?
<bigjools> jtv: way too hard for a quick fix
<jml> actually, that could be quite complex if you start taking a user's existing mail into account.
<bigjools> jtv: and it'll need to Popen the a-f process anyway
<bigjools> twisted won't give us any net win unless we need to block on external stuff
<bigjools> it's still single threaded
<gary_poster> jml, yeah, I can see it. bdmurray also suggested, as I expect you saw. I'd say first step to explore feasibility would be to talk to gmb or deryck and see if they had any obvious "no no no, this is way expensive."  If there were no solid answers then, I wouldn't feel comfortable estimating without commissioning some kind of exploratory spike
<jml> gary_poster: I reckon we should do a timeboxed spike. e.g. give someone a day to do a proof-of-concept
<jml> gary_poster: which is to say, that sounds like a sensible plan :)
<gary_poster> :-)
<gary_poster> cool
<jml> gary_poster: the LEP looks good, btw. Only unsure about one thing...
<jml> gary_poster: bdmurray says that he wants to get mail for all High & Critical bugs on Ubuntu. It seems that the "all bugs on Ubuntu" condition is met, but I can't tell if the "High & Critical" bit is part of the LEP or not.
<gary_poster> jtv, I agree with bigjools that integrating Twisted into our Zope process is probably not a good quick fix, if that is what you mean.  I have tried to get some people excited about making the "new" Twisted wsgi support allow for a WSGI result to be modified by postprocessing within Twisted but that is not hear now, nor have we integrated it.
<jtv> bigjools: I'm all for doing it directly and easily, since I'm lazy.  But I wouldn't want people to come back later and say "why, why, WHY didn't we do this in twisted?"  I'm not all _that_ familiar with the thing.
<bigjools> jtv: twisted is the wrong thing to use here, so don't worry about that
<jtv> Relieved to hear it.
<jtv> Popen it stays then.
<bigjools> jtv: popen the a-f processes, wait, profit :)
<gary_poster> jml, great, thanks.  "High & Critical" are importances, so we can filter on them
<gary_poster> ("Only subscribe to notifications that happen on bugs that have any of one or more selected importances." in Must)
<jml> ahh yes
<jml> I see it now.
<jml> gary_poster: cool. I'll give it a look over again & then send an email for the public record.
<gary_poster> sigh, why do I misspell thing with homophones that I know perfectly well are incorrect when I am typing quickly?  s/that is not hear/that is not here/
<gary_poster> awesome, thanks jml
<cr3> heads up folks, I just registered a project with proprietary license: certify-hudson
<jml> gary_poster: I don't know, but one day I would love to read a study on typing mistakes made by highly proficient typists.
<gary_poster> heh, that would be interesting :-)
<henninge> abentley: https://lpstats.canonical.com/graphs/TranslationMessage/20100201/20110201/
<stub> jtv: http://paste.ubuntu.com/560623/ is surprisingly doable, although there might be non-messages that still trigger emails and it doesn't take into account email batching (but better to over estimate than under)
<jtv> stub: did you mean to tell someone else?
<jtv> I'm a bit ENOCONTEXT on this.
<stub> jml: ^^^
<jml> oh hi :)
<jml> stub: ooh, nice.
<jml> stub: isn't ~650ms a bit long though?
<stub> 2.5 secs for ubuntu, so certainly not in the web ui. But we can build caches maybe.
<stub> (11380 message rows in the last week...)
<jcsackett> any chance someone can review https://code.launchpad.net/~jcsackett/launchpad/assertion-error-697294/+merge/47911
<stub> bigjools: I'm tempted to say disable the test and open a bug saying it is disabled and referencing the upstream bug.
<bigjools> stub: if we have to take unreasonable workarounds, that sounds ok but when would we be likely to get a fix?
<jml> stub: fair enough. we would probably only want rough numbers anyway.
<bac> deryck: i just noticed the bug tag entry widget on qastaging is not using JS.  known?
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build (405): FIXED in 6 hr 16 min: https://hudson.wedontsleep.org/job/devel/405/
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=710360] Add a config schema section for
<LPCIBot> gina to import wheezy.
<LPCIBot> * Launchpad Patch Queue Manager: [r=stevenk,
<LPCIBot> thumper][ui=sinzui][bug=334336] Extend recent revision listing on the
<LPCIBot> branch index page to show additional information for each revision,
<LPCIBot> including the branch merged and any associated bugs for that branch.
<bigjools> 6 hours?  *weep*
<gary_poster> jml, mbp gave two LEP ideas in his reply on the thread that I think are worth your review.  Since you are about to give an official blessing, this might be the last good chance, at least for a while.
<gary_poster> I've put up the ideas here, with my comments
<gary_poster> http://typewith.me/Y9qOZdZ6Kn
<gary_poster> his idea is in "original" and I'm "Gary" ;-)
<deryck> bac, for a bug page?
<bac> deryck: yep
<deryck> bac, no, not known to me.  And not sure what might have changed to cause this.
<bac> deryck: can you reproduce it
<deryck> let me see....
<deryck> bac, works for me
<bac> hmm
<deryck> bac, I tried Firefox on Ubuntu.  What browser you using?
<bac> deryck: safari.  trying ff now
<deryck> bac, I can try Safari too
<bigjools> why would a code.l.n URL be running queries to get bugtasks?
<bigjools> ah nm
<deryck> bac, works for me on safari too
<bac> deryck: on qastaging i see i was logged in using a test, unprivileged account
<deryck> ah
<bac> when logged in as myself it works
<deryck> gotcha
<bac> still unright
<deryck> bac, I didn't realize we prevented tagging by unprivileged users
<bac> we don't.  it takes you to the +edit page where it can be done
<bac> deryck: so i was able to add a tag, just didn't get the JS widget
<deryck> hmmm, ok.  That stills seem wrong.  The js is expecting something to make that action inline, which it doesn't find with no-priv users.
<allenap> henninge: Fancy a review? https://code.launchpad.net/~allenap/launchpad/bugs-with-blueprints-bug-707103/+merge/47866
<leonardr> henninge et al: i have a translations-related question
<leonardr> i need to know if there are any objects published in the web service but not in the website
<stub> bigjools: I've pushed my branch with that test fixed.
<bigjools> stub: thanks
<leonardr> it looks like structural subscriptions are published through the web service but not the website. can anyone confirm?
 * leonardr has confirmed to his own satisfaction
<allenap> leonardr: I think the closest you can get is /<product>/+subscribe or /~<user>/+structural-subscriptions (but the latter is not linked to from anywhere yet).
<leonardr> former soyuz people: in addition to the artifacts we talked about on wednesday, it looks like IArchiveDependency is published on the web service but not on the web site. is this right?
<bigjools> leonardr: we can see dependencies in the UI
<leonardr> bigjools: i made a request to http://launchpad.dev/~cprov/+archive/ppa/+dependency/1 and got this error:
<bigjools> for example , https://launchpad.net/~julian-edwards/+archive/testing/+edit-dependencies
<leonardr> NotFound: Object: <ArchiveDependency at 0x1100ba90>, name: u'index.html'
<leonardr> bigjools: i'm talking about a link to one specific dependency
<bigjools> oh, ISWYM
<bigjools> no, they don't exist
<leonardr> there's no reason why the canonical_url of every dependency couldn't be +edit-dependencies, but for now i will omit it from web_link
<bigjools> ok
<bigjools> where are you blacklisting those?
<leonardr> bigjools:
<leonardr> class IArchiveDependency(Interface):
<leonardr>     """ArchiveDependency interface."""
<leonardr>     export_as_webservice_entry(publish_web_link=False)
<bigjools> ah great, so there's no surprise if we add a UI page later
<leonardr> right
<leonardr> bigjools: IBinaryPackagePublishingHistory also seems to have no working web link, is that right?
<bigjools> leonardr: yup
<leonardr> bigjools: but a build job does?
<leonardr> http://launchpad.../~cprov/+archive/ppa/+buildjob/26
<leonardr> (it seems to work, i'm just sanity checking)
<deryck> henninge, I assigned bug 710591 and added it to the kanban board.  Just so you know.
<bigjools> leonardr: yeah that's relatively new, it was IBuild but we redirect that now
<henninge> deryck: cheers
<leonardr> bigjools: PackageUpload also has no web link?
<bigjools> leonardr: it doesn't
<leonardr> maybe i should just ask you about all of these instead of testing them manually
<bigjools> heh
<bigjools> that would mean I need to remember them
<leonardr> bigjools: the only 2 that seem to be left are distro arch series (which i believe has a web link)
<bigjools> it does
<leonardr> and "source package publishing" (not sure what the name of the interface is, not sure if it has a webl ink)
<bigjools> it doesn't
<bigjools> sourcepackagepublishinghistory
<jml> is sinzui still powerless?
<allenap> henninge: Do you have time to review a branch of mine? https://code.launchpad.net/~allenap/launchpad/bugs-with-blueprints-bug-707103/+merge/47866
<allenap> He forgot to pick up his superpower from dragnob at the end of the Thunderdome.
<jml> allenap: that's unfortunate.
<bigjools> he's been behaving oddly, perhaps it's just red kryptonite
<allenap> jml: That he forgot the superpower, or my attempt at humour? :)
<jml> allenap: that he forgot the superpower.
<leonardr> former bugs people: it looks like there is no web url for a bug subscription or a bug nomination. is this right?
<jcsackett> bac, any chance i can trouble you for a review? https://code.launchpad.net/~jcsackett/launchpad/assertion-error-697294
<bigjools> jml: hi, got 5 mins to help with a twisted test please?
<leonardr> similar question for registry: does a distribution source package have a web url? it looks like not
<bigjools> leonardr: yes it does
<leonardr> hmm...
<bigjools> ubuntu/+source/package
<leonardr> bigjools: ok, maybe i'm getting a 404 here because the distribution is private?
<leonardr> i'll try again with admin_browser
<leonardr> bigjools: if you say it has a web url i'll go along with it, but look at stories/webservice/xx-person.txt, around line 690
<leonardr> supposedly the web_url is http://launchpad.dev/distribution327800/+source/fooix
<leonardr> but when i GET that i get a 404 because distribution327800 doesn't exist. any idea why?
<henninge> allenap: looking now
<bigjools> leonardr: in xx-person.txt?
<leonardr> bigjools: yes, lib/lp/registry/stories/webservice/xx-person.txt
<leonardr> the call to getBugSubscriberPackages
<bigjools> ok
<bigjools> leonardr: I've no idea why.... but the URL looks fine though
<leonardr> ok, i'll leave it as is for now
<jcsackett> leonardr: does your webservice test set up everything the same was as in xx-person? that distribution looks like it was made on the fly for the test.
<jcsackett> s/same was/same way/
<leonardr> jcsackett: i added code to xx-person.txt, so it runs right after that code
<jcsackett> leonardr: ah. that *is* weird.
 * jcsackett looks closer.
<jcsackett> leonardr: you've already tried with admin? the only thing i can think of offhand is your conjecture about it being private.
<leonardr> jcsackett: yes, same result with admin. the distro itself is allegedly not there
<jcsackett> leonardr: yeah, i just pdb'd in that test and tried to find fooix in a distribution set. nothing doing--bad hack in the setup, maybe.
<leonardr> jcsackett: do you know if a product release file should have a web link? i have it being the same as the web service link, and a link like this doesn't work:
<leonardr> http://launchpad.dev/firefox/trunk/0.9.2/+file/firefox_0.9.2.orig.tar
<leonardr> er, let me cut out the trunk and try again
<leonardr> no, that trunk should be there
<jcsackett> leonardr: only link for those files i know of is http://launchpad.dev/firefox/trunk/0.9.2/+download/firefox_0.9.2.orig.ta
<jcsackett> i'm not sure that's the sort of link you want.
<leonardr> jcsackett: maybe a project release file isn't the sort of thing that needs a distinct 'web link'?
<leonardr> what would you get if you hit that link? you'd download the file, right?
<jcsackett> leonardr: yeah.
<jcsackett> aside from web ui, wget is perhaps the only reasonable thing to be hitting it. :-P
<leonardr> and self_link would give you the file anyway, so it doesn't need a web_link too
<jcsackett> henninge: are you still on call reviewer?
<henninge> jcsackett: yes
<jcsackett> got time for another (and possibly one teeny one after that)?
<jcsackett> https://code.launchpad.net/~jcsackett/launchpad/assertion-error-697294/+merge/47911
<jcsackett> henninge^
<henninge> jcsackett: sure
<jcsackett> henninge: thanks! i'll ping you with the second one in a moment (it's one line change + test)
<lifeless> mornink
<jelmer> hi lifeless
* lifeless changed the topic of #launchpad-dev to: Performance Tuesday | https:/â/âdev.launchpad.net/â | PQM is open | firefighting: - | On call reviewer: henninge  | https://code.launchpad.net/launchpad-project/+activereviews
<jcsackett> henninge: the seconde mp. https://code.launchpad.net/~jcsackett/launchpad/tags-portlet-708693/+merge/48029
<jcsackett> i'll leave you alone now. thanks. :-)
<jcsackett> lifeless: have some time to chat about bug 702620? we've been leaving each other comments on it and the MP. i thought actually talking would be good. :-P
<_mup_> Bug #702620: Can't delete branches from the API that can be deleted from the web UI <api> <code-integration> <oops> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/702620 >
<lifeless> jcsackett: hi
<lifeless> jcsackett: I collared sinzui last week
<lifeless> I think sinzui then filed a bug about the use case being unsatisfied
<jcsackett> lifeless: ah, so then i can go ahead and land that branch as a fix against that bug?
<lifeless> yes
<jcsackett> fantastic. :-)
<lifeless> sorry for causing friction
<sinzui> I have not files the bug yet...
<jcsackett> lifeless: no, not at all. it was a reasonable question.
<lifeless> sinzui: are you going to, or would you like me to?
<lifeless> sinzui: (or would you like no such bug :P)
<sinzui> My self-esteem is near empty because I have not landed a branch in a week. I have been plagued by natty and power troubles
 * sinzui needs a fortress of solitude to work
<lifeless> sinzui: \o/
<bac> jcsackett: you still need a review?
<lifeless> sinzui: me too, I started a branch last tuesday that I landed last night
<lifeless> sinzui: so exactly one week end to end
<jcsackett> bac: no, henninge is OCR and i have eaten his time. :-)
<jcsackett> thanks tho.
<jcsackett> sinzui: did you sort kernel issues today?
<sinzui> lifeless: I agree there should be a bug. The core issue is that there is no single place for a user to know what are the deps on an object, and how to remove them. Fixing this is beneficial to Lp engineers as well as external API users
<sinzui> I lost grub
<lifeless> wheeee
<sinzui> Booting from a usb sent me in a near spiral back to the bad grub
<jcsackett> man, EST green squad has been plagued.
<jcsackett> sinzui, you're good now? or still just limping along?
<sinzui> I think I will refuse updates for a week or so. I need to establish a rhythm to complete my branches
<sinzui> jcsackett: My computer is at 100% I think. I just need to keep the distractions away for 5 days to recover my balance
<jcsackett> sinzui: dig. i will cease distracting you, and good luck. :-)
<lifeless> jml: could you perhaps ask matsubara to eyeball https://bugs.launchpad.net/oops-tools/+bug/710831 ?
<_mup_> Bug #710831: duplicate query detection not handling Bugtask Queries in OOPS-1857O1288 <OOPS Tools:Triaged> < https://launchpad.net/bugs/710831 >
<lifeless> flacoste: what did we agree our downtime budget would be?
<flacoste> lifeless: 90 minutes AFAIKR
<flacoste> lifeless: that's end-to-end
<flacoste> or total downtime
<flacoste> so we have to remove the constants from it
<flacoste> to get the DB upgrade budget
<lifeless> hey
<lifeless> so we should get librarian and loggerhead page renders into the PPR
<lifeless> what do you think ?
<henninge> allenap, jcsackett: Please look at my reviews.
<jcsackett> henninge: thanks. i've replied on the MP.
<lifeless> henninge: are you still around ?
<henninge> lifeless: yes
<lifeless> henninge: btw we have login_celebrity, or the sampledata constants
<lifeless> henninge: so IIRC you know a bit about translations?
<henninge> lifeless: I do ;-)
<lifeless> henninge: I wonder if you could triage bug 707895
<_mup_> Bug #707895: LP - translation problem - inexisting terms shown as untranslated  <Launchpad itself:New> < https://launchpad.net/bugs/707895 >
 * henninge looks
<lifeless> I can't tell if this is situation normal or fallout from recife
<lifeless> or something else
<henninge> lifeless: it's a duplicate of bug 373269. I'll mark it as such.
<_mup_> Bug #373269: Message sharing and POFile statistics <lp-translations> <message-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/373269 >
<lifeless> henninge: awesome thanks
<lifeless> statik: sorry, missed my reminder
* henninge changed the topic of #launchpad-dev to: Performance Tuesday | https:/â/âdev.launchpad.net/â | PQM is open | firefighting: - | On call reviewer: -  | https://code.launchpad.net/launchpad-project/+activereviews
<henninge> jcsackett: r=me
<jcsackett> henninge: thanks!
<leonardr> i'd love a review of https://code.launchpad.net/~leonardr/lazr.restful/web-link/+merge/48052
<deryck> henninge, ping.  how goes the fix for overriding upstream translations?
<henninge> deryck: it won't be done today, sorry, but it seems to tie in with the groundwork I was doing.
<henninge> for the feature
<henninge> at least this fix does.
<lifeless> james_w: did you mean to forward francis announcement to lp-dev ?
<james_w> lifeless, nope
<james_w> linaro-dev
<lifeless> :P
<mwhudson> morning
<mwhudson> (finally)
<deryck> henninge, ok, well that's nice at least.  Do you have an eta for a fix?
<henninge> deryck: since I am not here tomorrow it will be on Wednesday. I will try to get something up for review by tonight.
<wgrant> mwhudson: How much do you know about codebrowse OpenID?
<mwhudson> wgrant: i guess i knew a bit once
<deryck> henninge, ok.  if you can't get something up for review, then send us a hand off email.  One of us can pick it up tomorrow.
<henninge> ok
<deryck> henninge, thanks!
<wgrant> mwhudson: I wonder if you have any thoughts on my last comment in bug #676372.
<_mup_> Bug #676372: "Server denied check_authentication" from bazaar.launchpad.net private branch since 11926 deployed <lp-foundations> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/676372 >
<jml> huwshimi: ok to have our call a bit early?
<jml> lifeless: will do
<huwshimi> jml: Sure. When do you want to do it?
<jml> huwshimi: now, if possible.
<mwhudson> wgrant: ah yes, i guess using a MemoryStore should be a bit of a giveaway
<huwshimi> jml: Can you give me two min?
<jml> huwshimi: sure.
<jml> huwshimi: just skype me when you're ready
<huwshimi> jml: Thanks
<deryck> later on, everyone!
<wgrant> mwhudson: Do we disable association entirely, or use SQLite?
<StevenK> wgrant: Did you see my pointer about a possible dupe?
<mwhudson> wgrant: what are the consequences of disabling the association entirely?
<wgrant> mwhudson: One extra HTTP request from the server to SSO per authentication attempt.
<wgrant> So, nothing.
<mwhudson> wgrant: seems least effort
<wgrant> StevenK: Yeah, thanks.
<mwhudson> wgrant: i guess i can review that branch rather easily
<wgrant> mwhudson: I haven't started yet, but I'll do it shortly.
<mwhudson> cool
<lifeless> sinzui: hi; bug 710547 - what would i look for in his mbox ?
<_mup_> Bug #710547: Answers not accepting e-mails correctly <Launchpad itself:New> < https://launchpad.net/bugs/710547 >
<sinzui> lifeless: I look at his reply and I cannot see why Lp has nothing more that the quoted part.
<lifeless> so, iz bug?
<sinzui> lifeless: I think next steps are to look at the production db, read the parsing rules or rendering rules to see what Lp thinks the message is and how to render it
<sinzui> lifeless: I am not certain if Lp or the message is at fault
<lifeless> sinzui: sure; but something is wrong ;) I'm going to mark it triaged
<sinzui> And if you discover that evo made a bad message or the user inserted an bad character you will mark it invalid
<sinzui> I think the bug is incomplete because I have never heard of message corruption as described in the bug, and there are enough messages in entering Lp to demonstrate Answers app and Message handling is working
<lifeless> sinzui: it should be incomplete if we want more data from david
<lifeless> sinzui: otherwise it will expire
<sinzui> no
<sinzui> it is incomplete if we do not now if it is a bug
<StevenK> lifeless: Ping me when you're free -- I'd like to deal with that join today, but I need to call my bank.
<lifeless> sinzui: this seems incompatible with bug expiry
<sinzui> If we wanted more information, then users and engineers would be switching bug status all the time, which is not what we intend
<sinzui> mpt has even cited the ambiguity of incomplete that causes users to think incomplete means "want information".
<lifeless> sinzui: but how do you explain bug expiry then ?
<sinzui> There bug/feature cannot be resolved because it cannot be understood or reproduced. But that is beside the point. I do not know there is a bug. I do not that triaged means I have enough information to work on the issue. I certainly do not
<lifeless> sinzui: thats not what triaged means though :)
<lifeless> sinzui: triaged means 'importance assigned'
<sinzui> It does
<sinzui> really it DOES
<jml> thumper: ping
<thumper> jml: hey
<jml> thumper: up for a quick chat?
<thumper> sure
<thumper> mumble?
<jml> thumper: sure
<sinzui> triaged means someone understands the issue and correctly judge the priority.
<sinzui> Lp could know triaged without and ENUM. If an LP engineer sets a priority. It is triaged. The problem is that Engineers come and go, so we do not trust the implicit nature of triaged
<lifeless> sinzui: sorry for going quiet, I'm otp with flacoste
<lifeless> sinzui: ok, I'm off the phone
<leonardr> thumper, StevenK et al: https://code.launchpad.net/~leonardr/launchpad/web-link/+merge/47258, https://code.launchpad.net/~leonardr/lazr.restful/web-link/+merge/48052
<lifeless> sinzui: so, if something is not *known* to be a bug, but the next step is an engineers, what status should it have?
<lifeless> sinzui: it cannot have incomplete or it will expire.
<sinzui> lifeless: We have 60 days to understand this
<lifeless> sinzui: but a poor queue to look at
<lifeless> sinzui: and any stall will result in expiry; this is undesirable.
<sinzui> lifeless: It will not expire if the bug is assigned to an engineer to triage it
<lifeless> sinzui: I'm ok with saying 'if someone is looking at it but not sure they will claim the bug'
<lifeless> sinzui: we don't currently say that
<lifeless> sinzui: would you like us to say & do that?
<sinzui> Claim? Do you mean the engineer cannot see he has a bug assigned? Engineers must unassign bugs that they are not committed to take to the next status because that causes users to think something is happening.
<lifeless> sinzui: claim/manager assigns are equivalent in terms of discussing the process
<lifeless> sinzui: I suspect I am, at best, confused here. Perhaps we could switch to voice, or start over, or something.
<sinzui> I do not permit my team members to have a lot of bugs. I think holding on to a bug that will not be fixed in a month leads to terrible miscommunications with the team, our stakeholders and our users
<lifeless> sinzui: I want to make sure that this report doesn't get expired when *we* were the folk that needed to look further.
<sinzui> I reguarlly unassign bugs that are not demonstrated to be progressing.
<lifeless> sinzui: I don't think leaving it incomplete and subject to expiry is sensible
<sinzui> lifeless: I really do that the bug, and email in my browser, but It cannot understand the issue at this moment, and I have a an 7 day-old branch. I need to move my branch before I can move the question
<lifeless> sinzui: ok; I'll get out of your hair.
<lifeless> sinzui: I think there is something to discuss more, another time.
<gerbilschool> If I replace 'devel' with 'stable' in bzr --no-plugins cat http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/utilities/rocketfuel-setup > rocketfuel-setup, will this download and run launchpad stable, instead of developement?
<lifeless> no
<lifeless> you need to start with devel, once you have that you can switch to stable (which is only a couple of days older)
<gerbilschool> I see, how then do I switch to stable? (I can't login on devel)
<sinzui> gerbilschool: stable is not stable like desktop software. there are not releases because Lp is always in development
<gerbilschool> I understand, thanks a lot!
<lifeless> No, you really dont :(
<poolie> lifeless, :-D
<lifeless> gerbilschool: what do you want to achieve?
<StevenK> lifeless: I have this feeling that gerbilschool is trying to log in to a local instance using their production credentials
<lifeless> StevenK: who knows
<lifeless> StevenK: you pinged
<lifeless> StevenK: my stack is clean now, I'm looking for perf tuesday bugs and to help folk that need help
<gerbilschool> lifeless: sorry for the delay (I was forced to reboot)
<lifeless> gerbilschool: no problem
<gerbilschool> lifeless: I want to see if I can get a 'working' launchpad instance on my machine,
<sinzui> gerbilschool: you may have...
<StevenK> lifeless: Indeed. I'd like to fix this join to also check that PackageBuild.archive == SPRecipe.daily_build_archive, but that causes an issues since SPRecipe isn't in the mix when we're adding the PackageBuild join.
<lifeless> StevenK: hmm
<StevenK> lifeless: What I just thought about was I could do this in the ON section when we join in SPRecipe
<gerbilschool> sinzui: I followed the instructions at dev.launchpad.net, which were very clear and worked, except that if I tried to access the login screen, I got a launchpad 'Oops' screen
<sinzui> gerbilschool: Lp does not support account management/login/passowords. It uses OpenID. We test Lp either by logging in as users in sample data (test@canonical.com:test) or using tool (utilities/make-lp-user)
<lifeless> StevenK: this is another modelling glitch :(
<gerbilschool> sinzui: I tried to login, but got this mystery error as soon as I clicked 'login/register'
<StevenK> gerbilschool: Are you able to pastebin the error?
<wgrant> lifeless: How is it a modelling glitch?
<lifeless> wgrant: builds in general fall into the data space of daily builds
<StevenK> lifeless: http://pastebin.ubuntu.com/560759/
<StevenK> lifeless: diff at the top, generated SQL at the bottom
<wgrant> lifeless: How would you model it?
<wgrant> lifeless: Daily builds are builds too.
<lifeless> StevenK: and what goes wrong?
<lifeless> wgrant: yes they are
<sinzui> wgrant, huwshimi, jcsackett: mumble?
<lifeless> wgrant: but we're not explicitly recording daily build
<lifeless> wgrant: we're saying we can infer it
<lifeless> wgrant: which is more complex
<jcsackett> sinzui: anytime. think i got a burst of static from you a moment ago.
<wgrant> lifeless: Right.
<StevenK> lifeless: Nothing, I wanted you to eyeball the SQL if it looks sane and I'm joining it in the right way
<lifeless> wgrant: one way would be to record the nature of the build
<wgrant> lifeless: Although we also want to skip a daily build if there was a recent manual build with the daily parameters.
<lifeless> StevenK: I think its fine; it looks good to me; do your tests concur?
<lifeless> wgrant: according to another bug there is no way to do that
<StevenK> lifeless: All the tests I've run so far pass -- just writing another
<lifeless> wgrant: the auto builds are sufficiently special
<gerbilschool> StevenK: I'm now being redirected to  'testopenid.dev' rather than 'launchpad.dev/+login'.  testopenid.dev works and I am now logged in.
<gerbilschool> StevenK: launchpad.dev/+login is redirecting to openid as well, so I cannot pastebin the error. Thanks for all the support!
<wgrant> jcsackett: Could you move your approved cards into QA/Landing? Development is now overfull.
<wgrant> Thanks.
<jcsackett> wgrant: yeah; i'm not terribly comfortable doing that b/c they're not actually landing till after ec2 lets them, but close enough i suppose.
<wgrant> Also, Deployment/Ready tends to get overfull pretty easily...
<wgrant> sinzui: Why is there a limit on that?
<lifeless> wgrant: WIP
<wgrant> lifeless: Hm?
<lifeless> wgrant: the same reason there is a limit on any lane having a backlog there usually correlates to high latency and churn
<wgrant> In this case we have a limit of 6, and 5 cards that are waiting for a DB deploy.
<sinzui> wgrant: lifeless: we can easily exceed a low limit when there state staging changes
<lifeless> wgrant: ah
<jcsackett> sinzui: forgot in standup; i also started and will soon be landing bug 708693
<_mup_> Bug #708693: LocationError: 'tags_cloud_data' on project bugs' page <lp-bugs> <oops> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/708693 >
<sinzui> I think the older boards had no limit or it was set to something like 4 x count(team members)
<wgrant> StevenK: What's happening with your recipe merge thing?
<sinzui> jcsackett: locationError is also a traversal error, which is what I think you describe in your comment
<jcsackett> sinzui: yes.
<wgrant> TALES catches lots of things and reraises them as LocationErrors.
<StevenK> wgrant: I'll be looking it at after I'm done with the queueing branch
<wgrant> StevenK: Great, thanks.
<wgrant> StevenK: Impending Debian release -> gina config schema change :(
<StevenK> wgrant: I've pushed my changes for queue-recipes-better
<StevenK> wgrant: *hint*
<wgrant> StevenK: k, looking.
<lifeless> mwhudson: ping
<lifeless> mwhudson: the branch mapping script; does it do xmlrpc or db access itself ?
<wgrant> StevenK: Your RightJoin still offends me, but I'll let it slide. Apart from that it looks fine, except for the indentation of the second line of the new condition.
<StevenK> wgrant: How would you prefer the indentation to look?
<wgrant> StevenK: I believe the second line is meant to be one level further in. Let's see if I can find a reference for that.
<lifeless> wgrant: no, its correct
<StevenK> wgrant: TBH, it looks like the And() that's a few lines above it
<lifeless> wgrant: even if it wasn't, its clear enough :)
<wgrant> lifeless: Eeh, I think it looks too much like there are three conjuncts, but OK.
<lifeless> wgrant: if you have a better layout, just give StevenK a diff
<lifeless> wgrant: standards mean bollux in this sort of thing
<wgrant> I know. But in this case it actually made it slightly less readable.
<lifeless> wgrant: right, so hand StevenK a diff and we can move on :)
<StevenK> wgrant: Is http://pastebin.ubuntu.com/560772/ better?
<mwhudson> lifeless: db
<lifeless> mwhudson: https://bugs.launchpad.net/launchpad/+bug/433888/comments/11 - what do dyou think?
<_mup_> Bug #433888: Branch path mapping exceeding threshold regularly <canonical-losa-lp> <lp-code> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/433888 >
<mwhudson> lifeless: yes, that makes sense
<mwhudson> the 10 second problem is a theoretical thing though, and not what the bug is really about
<lifeless> mwhudson: actually, losas are seeing very long responses up in it
<lifeless> mwhudson: but what is the bug really about then ?
<mwhudson> lifeless: the limit that triggers the nagios check is 12.5 milliseconds
<lifeless> mwhudson: yes
<lifeless> mwhudson: and we're seeing what, 600 a day, or 1% ?
<lifeless> mwhudson: alternatively we could set a db limit of 25ms or something
<mwhudson> lifeless: to step back
<mwhudson> there is "the horrible edge case" i talked about
<mwhudson> adding the 500ms timeout will alleviate that worry
<mwhudson> but i don't think this has actually ever happened
<lifeless> mwhudson: they seem to say is has
<lifeless> mwhudson: *it*
<lifeless> mwhudson: up in the comments
<mwhudson> the description of the bug is that a the nagios check that responses take longer than 12.5 ms, maybe 10 times a week
<lifeless> yes
<mwhudson> lifeless: are you talking about the https://bugs.launchpad.net/launchpad/+bug/433888/comments/9 comment?
<_mup_> Bug #433888: Branch path mapping exceeding threshold regularly <canonical-losa-lp> <lp-code> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/433888 >
<mwhudson> i think that's only talking about the nagios check tripping
<spm> it is. it's a constant source of low grade "false alarms" - which is bad. as we get in the habit of ignoring them.
<mwhudson> lifeless: i'll file another bug about getting the 500ms timeout in place and leave this one in peace to deal with the nagios check issue
<lifeless> mwhudson: sure
<lifeless> mwhudson: note that the description includes mention of 10 second lookups
<mwhudson> oh right
<mwhudson> spm: can i get you to look again at that?  are you still seeing timeouts in the nagios alerts?
<spm> mwhudson: I believe so; let me see if I can get some science to bear here
<spm> mwhudson: ew. yes. around 9 a day on average.
<spm> given how infrequently nagios checks. that's a lot.
<mwhudson> spm: 9 *timeouts* a day?
<spm> yarp.
<mwhudson> as in, no response after 10 s
<mwhudson> wow
<mwhudson> i'm amazed our users aren't at the gates with pitchforks
<spm> Oh I see. hang a sec. I may be misreading the data.
<spm> these are critical events per the check. not necessarilly timeouts.
<mwhudson> ah
<mwhudson> that's less worrisome
<mwhudson> (though obviously still not great)
<spm> yeah. these don't often result in an sms - need 3 in a row; but they do add a constant irregular stream of noise.
<spm> there's no obvious pattern I can see either. over the past 31 days, pretty even all day long.
<StevenK> thumper: You mentioned something on the stand-up call yesterday that would be useful to rename branches and recipes that conflict. Can you remind me?
<sinzui> thumper: ping
<sinzui> thumper: unping
 * mwhudson does some log foodling
<mwhudson> of the last nearly 200k lookups that hit the db, about 150 exceeded the 0.0125ms threshold
<lifeless> mwhudson: we probably only need 99th percentile @ 12.5ms
<mwhudson> er
<mwhudson> lifeless: what do you mean exactly?  that 99% complete < 12.5ms ?
<lifeless> yes
<lifeless> the odd outlier is tolerable
<lifeless> its sustained failure to reply in < 12.5ms that will mess us up
<mwhudson> well, we're already at 99.9% of that it seems
<mwhudson> although this measurement doesn't include backlog
<lifeless> sadl
<lifeless> sadly
<mwhudson> yeah
<wgrant> mwhudson: https://code.launchpad.net/~wgrant/launchpad/bug-676372-codebrowse-openid/+merge/48086, if you could.
<wgrant> QA is going to be just about impossible, but it works locally against c-i-p, which is a start.
<lifeless> \o/
#launchpad-dev 2011-02-01
<mwhudson> if 99.9% requests were really ok though, nagios would be having to making sqillions of requests to trip at all often
<lifeless> wgrant: what is hard vis-a-vis shared cache?
<wgrant> lifeless: We could go with a shared SQLite DB for now. But that probably introduces concurrency issues, and is clearly harder than None :)
<wgrant> It also becomes a lot harder once we de-SPOF guava.
<mwhudson> particularly, using sqlite would mean we'd have to remember it when we load balance across machines
<lifeless> yes
<wgrant> Exactly.
<lifeless> a concern for historydb too
<wgrant> Does historydb have to be shared?
<wgrant> I don't really know how it works.
<spm> I heard a rumour that sqlite is webscale?
<mwhudson> yes, although that's suboptimal performance vs not working
<lifeless> wgrant: sharing is how its faster than the prior cache
<mwhudson> lifeless: not really
<wgrant> :(
<mwhudson> it's mostly faster than the other cache because it can be updated incrementally
<lifeless> mwhudson: its faster on additional branches because it can be reused
<mwhudson> the caches are already shared between the two instances of loggerhead running on guava
<mwhudson> yes
<mwhudson> i agree a cache that could be shared across machines would be better
<wgrant> Do I want to fix ec2 land to stop adding [ui=none]?
<lifeless> yes
<wgrant> It's also tempting to fix the formatting of the post-bug-filing alert.
<lifeless> I think thats tagged high not critical, though I wouldn't obeject
<wgrant> If it were critical I wouldn't be mentioning it to see if you objected :P
<lifeless> its really up to curtis to object or not ;)
<thumper> StevenK: it is BranchNamespace.renameBranch
<thumper> StevenK: it has a param rename_if_necessary
<wgrant> lifeless: You define the set of critical bugs, and you are around, so you'll do!
<lifeless> hah
<lifeless> anyhow, its probably shallow, and would be lovely to have
<lifeless> and I'm a strong believer in engineer discretion
<wgrant> StevenK: Hi.
<StevenK> wgrant: O hai
<wgrant> StevenK: I have a quick review for you, if you've got a sec.
<wgrant> https://code.launchpad.net/~wgrant/launchpad/bug-711016-no-ui-clause/+merge/48094
<StevenK> wgrant: Did you see my earlier prod?
<StevenK> [10:11] < StevenK> wgrant: Is http://pastebin.ubuntu.com/560772/ better?
<wgrant> StevenK: Completely missed that, sorry.
<wgrant> StevenK: That looks good. Did you see my diff?
<StevenK> wgrant: Nope, so I went and changed it anyway.
<StevenK> wgrant: That MP looks good -- with one proviso -- there's still tests that check ui=blah, right?
<wgrant> StevenK: Yup.
<StevenK> thumper: https://code.launchpad.net/~wgrant/launchpad/bug-711016-no-ui-clause/+merge/48094 when you can
<thumper> StevenK: ack
<wallyworld> StevenK: you have time today to take a look at this (after your other stuff is done) ???? https://code.launchpad.net/~wallyworld/launchpad/recipe-find-related-branches/+merge/47367
<wallyworld> thumper: what's your verdict about the extra text in the related branches view - as per my comment to your comment :-)
<thumper> wallyworld: I don't think the text is accurate, and is likely to be confusing
<wallyworld> thumper: ok. i'll get rid of it
<StevenK> thumper: I'm preparing a rollback of recipe deletion, are you fine to rs it?
<thumper> yep
<wgrant> You know, it would be really nice if ec2 phoned home.
<wgrant> So we could have a full branch dashboard.
<StevenK> Bloody hell, it's not even 1pm and it's already 36degC
<wgrant> It's already hit the max (38Â°C) here.
<wallyworld> StevenK: know what you mean. i tempted to go sit in my pool and try not to splash water on the laptop :-)
<StevenK> Haha
<StevenK> thumper: Bah! It's *moveBranch*
<wgrant> lifeless: Thanks.
<wgrant> huwshimi: Hi.
<huwshimi> wgrant: Hey there
<wgrant> huwshimi: I'm currently having some fun with the notification CSS.
<huwshimi> wgrant: what kind of fun?
<wgrant> huwshimi: I want to put some <p>s in a notification instead of straight text. But then the notification's bottom padding and the <p>'s bottom margin combine to make a huge gap.
<lifeless> wgrant: and urls plox ?
<huwshimi> wgrant: Ah right
<wgrant> huwshimi: I can fix it by adding a .informational > p:last-child {margin-bottom: 0;}, but that seems bad.
<wgrant> https://code.launchpad.net/~wgrant/launchpad/bug-654585-linkify-bug-acknowledgement is the branch.
<huwshimi> wgrant: so, using last-child is a good thing, but it only works in modern browsers. The usual way around it is to apply a class of "last" to the last <p>.
<huwshimi> wgrant: This is also kind of ugly, but it's how we've been solving the the problem for years.
<wgrant> huwshimi: Even IE7 supports it, right?
<wgrant> We already use last-child somewhere... possibly breadcrumbs.
<huwshimi> wgrant: Actually I believe it only works in IE9. But I could be wrong about that
<wgrant> You're right.
<wgrant> WTF
<huwshimi> wgrant: Indeed.
<wgrant> Do we care enough about IE<=8 to fix it there too?
<wgrant> Oh, IE>=7 support :first-child, but not :last-child. Lovely.
<lifeless> sweet
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>      644 / 8052  Archive:+index
<lifeless> wgrant: did I just paste three timeouts ?
<wgrant> lifeless: Just the one.
<StevenK> But three lines.
<lifeless> 15:43 < lifeless>      644 / 8052  Archive:+index
<lifeless> 15:43 < lifeless>      200 /  410  BugTask:+index
<lifeless> 15:43 < lifeless>       91 /  194  Distribution:+bugs
<lifeless> Also I hate the latest freenode rev
<wgrant> Only got the first of those.
<lifeless> *hate*
<huwshimi> wgrant: I'm not sure. So I think we should take a time + effort vs  how badly it breaks attitude.
<lifeless>       68 /   33  Branch:+index
<lifeless>       43 /   14  Archive:+copy-packages
<lifeless>       32 /  295  POFile:+translate
<lifeless>       24 /  283  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>       16 /   49  Archive:+packages
<lifeless>       11 /   40  Product:+code-index
<lifeless>       10 /   16  DistroSeriesLanguage:+index
<wgrant> huwshimi: Mm. I suppose I could hack text_to_html to add a class to the last paragraph.
<wgrant> But I hate IE.
<huwshimi> wgrant: in this case, if the break is aweful and it is easy enough to fix, then do it.
<huwshimi> wgrant: I believe we have low numbers of IE users, but enough to be significant.
 * thumper heads to coffee
<StevenK> Do we have accessible stats of browser usage?
<wgrant> Some people have Google Analytics access.
<wgrant> sinzui was looking at them during the Thunderdome.
<huwshimi> wgrant: I personally have the opinion that it is time to let things break on IE6, because as long as we attempt to make it look half decent, organisations etc. will not bother to upgrade, but once the web experience starts to break then the pressure from users will be enough to make organisations make the upgrade
<wgrant> huwshimi: Certainly, disregarding IE6 has been good standard policy for a while.
<lifeless> huwshimi: a massive hack attack on it wasn't enough ?
<wgrant> lifeless: No.
<huwshimi> lifeless: You would think so
<huwshimi> infact I think that even if a couple of major websites were broken on IE the pressure would mount (e.g. facebook)
<lifeless> but those sites have the most to lose ;)
<huwshimi> lifeless: Well facebook is phasing out ie6 support for some of their features already
<lifeless> \o/
<StevenK> Surely businesses will play the "You shouldn't be viewing Facebook at work anyway" card, and not upgrade anyway? :-)
<wgrant> Oh good, just to make it easy the thing that text_to_html iterates over is a generator.
<huwshimi> wgrant: Is this so that you can add the last class?
<wgrant> huwshimi: Yes.
<huwshimi> wgrant: I'm guessing that means it's going to be hard to add the class? Or impossible?
<wgrant> huwshimi: Well, I can turn the generator into a function that returns a list instead.
<wgrant> Ugh.
 * wgrant gives up for a while and lunches.
<huwshimi> wgrant: When you get back let me know and we can talk about this again.
<StevenK> thumper: So I'm struggling with this rename-recipes-when-merging branch -- do you think I should subclass IBranchNamespace and then call it from the merging code?
<wallyworld> if i were to raise a bug to address a performance issue, that would be a Defect rather than an Improvement? Or not?
<lifeless> wgrant: we don't really have defect/improvement in our workflow
<lifeless> bah
<lifeless> wallyworld: ^
<wallyworld> sooooo, the verdict?
<lifeless> wallyworld: So I don't understand the question
<wallyworld> i'm talkin abou the kanban board
<wallyworld> sorry, not enough context
<wallyworld> i knew what i meant :-)
<lifeless> wallyworld: so, you're on the recipe squad right?
<lifeless> wallyworld: in principle everything you're working on is improvement
<wallyworld> yeah, but it's to fix the +daily-builds performance issue
<wallyworld> ok, i'll use improvement, thanks
<lifeless> wallyworld: its an improvement :)
<wallyworld> lifeless: many times i'm included to consider performance issues as defects :-)
<wallyworld> another question too: i've had an ec2 failure email, with no errors attached but instead the message "SMTPError: SMTP error: 552 Message size exceeds maximum permitted"
<wallyworld> where do i look to see what happened?
<lifeless> blah
<lifeless> the compressed subunit log was larger than the mailserver would accept
<lifeless> 'someone' should make ec2 test attach that to the branch using the subunit API in launchpad
<lifeless> thumper: you've added brand new things to the API before, right ?
<lifeless> thumper: new types etc, I mean.
<wallyworld> lifeless: in the meantime, how do i get the test log? i guess it's lost when the ec2 instance shuts down?
<spm> stub: what's the table/query to see what DB patch a given DB is currently up to?
<lifeless> wallyworld: yeah :(
<wallyworld> bollocks :-(
<stub> select * from launchpaddatabaserevision order by major,minor,patch;
<spm> ta
<wallyworld> lifeless: it was the recently done sql bind parameters branch. perhaps something failed so spectacularly that the log file got too big?
<lifeless> spm: I'm guessing that means we has tree ?
<lifeless> wallyworld: thats quite possible
<spm> lifeless: no not yet. I was wonder htf qastaging get's it's db patches at all.
<lifeless> spm: it doesn't
<lifeless> spm: it gets restored to.
<lifeless> spm: it *must not* apply db patches because its what we QA our deployments on
<spm> yah. and hence was wondering how it managed to maintain some semblance of code/db sync at all.
<lifeless> spm: its meant to be restored weekly with staging, and for db deploys it has the patches applied to it.
<lifeless> however something seems to be quirky there
<spm> yes. hence my questions and htf'ing
<lifeless> spm: not functionally quirky, if that makes sense.
<spm> :-)
<StevenK> wgrant: Do you think I should just force a build to get buildbot/pqm happy again?
<lifeless> wallyworld: hi
<wallyworld> lifeless: hello
<lifeless> wallyworld: we have db transactions, reading twice from the DB is pointless.
<lifeless> wallyworld: perhaps I'm misunderstanding something.
<wallyworld> you mean in the deleted recipe branch?
<lifeless> yes
<lifeless> unless you're in two separate transactions (which you may need to be to avoid having long running transactions on big uploads)
<wallyworld> i wasn't sure of the transaction boundaries and so was being (overly) cautious
<lifeless> if you're in two separate transactions, then I'd just check at the end
<wallyworld> just to avoid any possible race conidions
<lifeless> wallyworld: well, it raises red flags to me
<wallyworld> i didn't want to go to the expense of trying a build if there was no pint, hence the check up front
<lifeless> wallyworld: thusly: it makes it more complex, and its either not needed, or it is needed but wasn't clear that it is.
<lifeless> wallyworld: I guess I'm asking for more surety that it is/isn't rather than a hopeful statement that doesn't fit with transaction semantics.
<lifeless> wallyworld: separately, whats this daily build performance bug you're going to look at? I'm curious.
<wallyworld> not so much transaction semantics but where the transaction boundaries are. i'll revisit it though....
<wallyworld> https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-timeout-candidates.html
<lifeless> ah, a page dear to my heart
<wallyworld> +daily-builds, about 1/2 way down
<lifeless> ah yes
<lifeless> I was mentioning this to tim the other day
<lifeless> never completes in < 5 seconds
<lifeless> suggests its doing -way- to much work
<wallyworld> yeah :-(
<wallyworld> to me that's a defect but.....
<wallyworld> ... i've added an improvement card
<lifeless> :)
<lifeless> spm: can you toss a haproxy status page screeny my way? We're seeing more might-be-GIL stuff, and as we haven't done single-threaded appservers yet, I can't eliminate it...
<lifeless> but the queue dpeth stuff often gives decent hints
<spm> prod?
<lifeless> yeah, servers C,E,H
<wgrant> StevenK: Always.
<lifeless> hmm is +code-index memcached?
<StevenK> Fricken buildbot
<lifeless> ok, phew, new bugs for new timeout limit filed
<lifeless> wallyworld: https://bugs.launchpad.net/launchpad/+bug/711072 - I've doctored it up to add more info for you
<_mup_> Bug #711072: RootObject:+daily-builds times out <timeout> <Launchpad itself:Triaged by wallyworld> < https://launchpad.net/bugs/711072 >
<lifeless> wallyworld: I hope that helps
<wallyworld> lifeless: thanks, although you've taken all the joy away of me finding that myself :-) i don't mind getting down and dirty with a profiler you know :-)
<lifeless> wallyworld: I logged into devpad
<lifeless> cd /srv/launchpad.net-logs
<lifeless> grep +daily-builds lpnet/*/2011-02-01 -r
<lifeless> (I didn't get the joy of profiling either)
<wallyworld> lifeless: thanks for the tip
<StevenK> buildbot, DIAF. Whoever thought the xmlrpc interface to it is documented is brain-dead
<lifeless> StevenK: it was fairly straightforward when I read the code
<StevenK> I love how buildbot-poller hard codes lucid_lp and lucid_db_lp in multiple places.
<thumper> lifeless: yes in the past I have, but not for ages
 * thumper is making dinner
<lifeless> wgrant: where are you up to on archive:+index ?
<wgrant> lifeless: The OOPSes I've looked a recently have been for a copy archive, and resulted in bug #709717.
<_mup_> Bug #709717: ArchiveView.num_pkgs_building can be very slow <lp-soyuz> <oops> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/709717 >
<wgrant> I haven't checked the general case since Julian's fixes.
<lifeless> wgrant: can you pleae put page ids in titles of such bugs? helps me at least ;)
<wgrant> lifeless: Sure, sorry.
<lifeless> no need to apologise
<lifeless> its informal
<huwshimi> Have a good rest of the day people.
<lifeless> StevenK: so whats up with Revision 12277 can not be deployed: needstesting
<lifeless> wgrant: still around ?
<lifeless> wgrant: why in bug 691478 do we need a union ?
<_mup_> Bug #691478: Archive:+index timeouts <dba> <qa-ok> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/691478 >
<wgrant> lifeless: There are a couple of places we use them.
<wgrant> One is to determine the set of builds that we need to consider: we grab those in the archive itself, and union with those that were copied in.
<lifeless> I'll be glad when wallyworld's parameter saving patch gets stashed
<lifeless> lol
<lifeless> ok, I think I need to call it a day
<StevenK> lifeless: Sorry, I was picking up Sarah; still here?
<lifeless> StevenK: here
<StevenK> lifeless: I'm rolling it back and not QA'ing since I don't want users to lose information when they merge if they have recipes.
 * wgrant stabs lucid_db_lp.
<lifeless> StevenK: ok, nowish ?
<StevenK> lifeless: It has been rolled back, it's tip of devel
<lifeless> StevenK: sweet
<thumper> https://code.launchpad.net/~thumper/lazr-js/multi-line-editor-goodness/+merge/48118 if someone likes looking at styles and javascript
 * thumper is really done
<bigjools> morning
 * thumper claims 6 bug fixes with that merge proposal \\o/
 * thumper flees the office
<gmb> Low bandwidth good morning.
<bigjools> coffee shop or 3g?
<adeuring> good moring
<gmb> bigjools: Hahaha. 3G round here? To make a hollow laughing. At the moment I'm doing irc and email over GPRS. Coffee shop will happen later when traffic in town has died away.
<bigjools> zoiks
<gmb> I know. Party like it's 1995.
<mrevell> Howdy
<bigjools> open id + redirects = FAIL
<bigjools> wgrant: around?
<wgrant> bigjools: Hi.
<wgrant> Did you break mawson?
<bigjools> wgrant: no
<wgrant> :(
<bigjools> but I am testing on it
<wgrant> bigjools: What provides bzr lp-land? bzr-pqm?
<bigjools> wgrant: yes
<bigjools> wgrant: quick question for your consideration:
<bigjools> in rescueBuilderIfLost() I want to fail the builder if a nonvirtual builder ends up in ABORTED
<bigjools> because we can't be sure abort() worked
<bigjools> what do yo uthink?
<wgrant> They only end up ABORTED if someone manually kills things. Acting on ABORTING might be more useful.
<bigjools> wgrant: the manually killing thing is precisely the situation I am considering
<bigjools> and catches the ABORTING stage too
<bigjools> see bug 705342
<_mup_> Bug #705342: buildlog contains a mix of two different builds <Launchpad itself:In Progress by julian-edwards> < https://launchpad.net/bugs/705342 >
<wgrant> Hmm, actually, they will also end up ABORTED once the build finishes.
<wgrant> That's the normal case.
<wgrant> Sigh.
<bigjools> hmmmmn?
<bigjools> there's nothing normal about it
<wgrant> Builders will eventually recover from ABORTING without manual intervention.
<wgrant> Because the build will finish.
<wgrant> I wonder how often that happens.
<bigjools> well the double build thing happens even when we call cleanSlave after seeing ABORTED
<bigjools> there's a plethora of slave bugs here
<wgrant> Right. After manual intervention.
<bigjools> yes
<wgrant> (in other news, a few hundred lines of lpland look remarkably identical to autoland)
<wgrant> I wonder if the same diff applies.
<bigjools> so if we end up in ABORTED on a nonvirtual slave I am suspicious
<bigjools> and therefore want to fail it
<bigjools> because it means the admin has pebkac
<wgrant> Not always.
<bigjools> mostly
<wgrant> I do not know the relative frequencies.
<wgrant> I suspect that the problematic case is a tiny minority.
 * bigjools greps
<bigjools> I only see one case
<wgrant> OK, I should not be able to take a 154 line diff and apply it to a different project with no conflicts.
<bigjools> I am making the change anyway
<bigjools> wgrant: :(
<wgrant> bigjools: OK.
<wgrant> I guess we'll see how it goes.
<bigjools> yeah
<bigjools> if nothing else it'll prevent serious issues
<wgrant> bigjools: Also, as you may be aware, We have an upcoming Debian release.
<bigjools> now, to work out why assertFalse doesn't fail for a True value
<bigjools> yeah
<wgrant> I've landed the config changes already.
<bigjools> I saw
<wgrant> Do we need to do anything beyond creating the new series and adding the series name to iron's crontab?
<bigjools> not entirely sure tbh, it's been a while since we changed gina config!
<bigjools> dogfood FTW
<wgrant> Indeed.
<wgrant> I know this will work. I was mostly wondering if there were any instructions to create the series, or if we should just imitate the previous one.
<bigjools> test it on DF
<wgrant> k
<wgrant> How do I get the Debian archive onto there?
<wgrant> Can I sync bits of it from iron or similar?
<bigjools> let me know if you want to bring it down/up since I am testing
<bigjools> ummm ask Steve, he did something with it recently
<wgrant> I can't do it yet, since wheezy doesn't exist.
<wgrant> Although I guess I could mangle the squeeze indices to look like wheezy.
 * bigjools - > call
<jtv> Hi folks how do I make my tests pass in python?  I keep saying "pass" but it doesn't work.
<bigjools> can someone take a look at this and guess as to why, although the assertionerror is raised, the test doesn't fail? http://pastebin.ubuntu.com/560674
<bigjools> jml: around?
<LPCIBot> Project devel build (407): FAILURE in 5 hr 38 min: https://hudson.wedontsleep.org/job/devel/407/
<jml> bigjools: am now
 * gmb returns, via Starbucks.
<bigjools> jml: can you check my paste above please
<gmb> The coffee blows, but the wifi is oh so sweet.
<bigjools> jml: I've got a failure in a twisted test but it's not causing the test to fail
<bigjools> dunno where the problem is, trying to debug the test runner ...
<bigjools> gmb: compared to the Dallas hotel coffee, Starbucks was great.  :(
<jml> bigjools: yuck. can you paste the test & what happens when you run it?
<gmb> Well, yeah.
<jml> (the full class would be nice, actually)
<bigjools> jml: http://pastebin.ubuntu.com/560899/
<bigjools> the if 1==2 is to avoid the condition that makes the test pass
<jml> bigjools: does the breakpoint get triggered?
<bigjools> jml: yes
<bigjools> jml: see http://pastebin.ubuntu.com/560674
<jml> bigjools: the problem is that the assertion error is being swallowed?
<bigjools> jml: that's what it looks like
<bigjools> when I debug, I can see it getting recorded as a Failure, then nothing happens when it ends up in fail_if_exception_caught()
<jml> bigjools: OK. Let's try to whip up a minimally reproducing example.
 * bigjools tries something else
<bigjools> jml:
<bigjools>     def test_failing_test(self):
<bigjools>         self.assertFalse(True)
<bigjools> does not fail ...
<jml> bigjools: that would be a minimally reproducing example.
<bigjools> indeed :)
<jml> bigjools: just trying locally, in case it's something in your branch / local config.
<bigjools> ok
<bigjools> jml: I added that to TestBuilder FWIW
<jml> cannot import name BuildNavigationMixin...
<bigjools> circ imports :/
<jml> I haven't changed anything!
<bigjools> if you run with -t it doesn't do it
<jml> oh right.
<bigjools> only if you specify the module
<bigjools> le sigh
<bigjools> jml: I've narrowed it down to the presence of this line in the test class:
<bigjools> run_tests_with = AsynchronousDeferredRunTest.make_factory(timeout=10)
<bigjools> remove that and the simple case fails
<bigjools> this is rather worrying :)_
<jml> bigjools: that line says "use the reactor when running tests and wait for deferreds to fire"
<jml> I expect the bug is in ADRT though.
<jml> dammit. I've got to go.
<jml> bigjools: please see if you can reproduce it using just testtools.
<jml> bigjools: file a bug on testtools and I'll fix it when I get back.
<bigjools> jml: I'll dig
<bigjools> thanks
<deryck> Morning, all.
<bigjools> jml: https://bugs.launchpad.net/testtools/+bug/711209
<_mup_> Bug #711209: When running Twisted tests, failures are not reported <testtools:New> < https://launchpad.net/bugs/711209 >
<wgrant> jelmer: Could you please land that bzr-pqm change? I don't think I have privs.
<jelmer> wgrant: sure
<jelmer> wgrant: I really think this kind of stuff should live in another plugin, perhaps the same plugin as lpreview_body
<jelmer> anyway, not your fault :)
<wgrant> jelmer: Yes :(
<wgrant> Hmm, recipes are pretty cool.
<gary_poster> allenap: ping?
<allenap> gary_poster: Hi there.
<gary_poster> Hi allenap :-) .  Could I have a second review from you on a branch?  It is a branch that moves the bug_notification_level from structural subscriptions to the filter.  I have one specific question for you, and then I'd appreciate a general review as well.  https://code.launchpad.net/~gary/launchpad/move-events-to-filters/+merge/48069  Can you take the time for that?
<gary_poster> it's a big branch :-/
<allenap> gary_poster: Sure :)
<gary_poster> thank you!
<gary_poster> allenap, the specific question is about the delete method on the filter.  I pose the question/concern in the second reply to the MP, about the XXX
<allenap> gary_poster: Cool.
<gary_poster> thanks again
* bac changed the topic of #launchpad-dev to: Performance Tuesday | https://â¬â¹dev.launchpad.net/â¬â¹ | PQM is open | firefighting: - | On call reviewer: -  | https://code.launchpad.net/launchpad-project/+activereviews
<deryck> abentley, adeuring -- I
<deryck> I'm coming :-)
<maxb> bac: Um... did you just introduce weird unicode into the topic? :-)
<bac> maxb: no, i tried to remove weird unicode
* bac changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: -  | https://code.launchpad.net/launchpad-project/+activereviews
* leonardr changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: leonardr  | https://code.launchpad.net/launchpad-project/+activereviews
<jml> bigjools: the test doesn't fail when run purely with testtools
<jml> as in, it fails correctly
<bigjools> jml: :/
<bigjools> did you see the bug?
<jml> bigjools: yeah, I did.
<jml> bigjools: bringing in more of the LP stack now to reproduce
<bigjools> jml: I have no clue why it thinks that attribute is not settable
<bigjools> trez bizarre
<jml> this would be easier if my laptop wasn't suffering display refresh problems
 * jml tries a different runner
 * bigjools discovers how hard it is to search for an sql statement containing "except"
<jml> hmm.
<jml> so w/ ADRT it passes incorrectly
<jml> w/ SDRT it gives that stack trace that you supplied in the bug
<jml> w/ RT it fails as it ought.
<bigjools> hummm
<jml> let me eliminate zope.testing
<bigjools> thanks for debugging
<jml> actually, first, getting rid of LP's base TestCase
<jml> bigjools: np.
<jml> http://paste.ubuntu.com/560985 - huh
 * jml tries with just testtools
<bigjools> jml: I bet that something is declaring that attribute as a @property when the other classes are not
<bigjools> easy to grep for it
<jml> which attribute!
<bigjools> the one in the traceback
<jml> the exception message specifies neither the object nor the attribute name
<bigjools> I pdb'd far enough to find it
<bigjools> look in the traceback!  last line
<jml> f_locals
<bigjools> appropriate name
<jml> hmm.
<bigjools> the other worrying thing is that an except was totally swallowed
<bigjools> exception
<jml> this is perplexing.
<jml> the exact same test behaves correctly (i.e. fails) when run as part of the testtools suite
<bigjools> so is the async runner inserting a class into the hierarchy that declares f_locals as a property?
<bigjools> sorry, not giving this my full attention
<jml> no, it's not.
<jml> if it were, it would fail when run as part of the testtools suite
<jml> hmm.
<abentley> bigjools, I seem to be getting None for this when processing a source package recipe build fails.  Could some of these relationships be waiting for the upload to succeed before they're set? http://pastebin.ubuntu.com/560988/
<bigjools> checking
<jml> bigjools: also, don't worry about attention. it helps me enough to dump new data in the channel :)
<bigjools> abentley: SourcePackageRelease won't exist will it?
<bigjools> jml: heh ok :)
<abentley> bigjools, I guess not.  Is there another way I can find the sourcepackagerecipebuild for a packageupload?
<bigjools> lemme see
<jml> ok. I have no idea how I got the behaviour I pasted.
<adeuring> danilos: do you have some time to discuss the remove_translations script (bug 705652)?
<_mup_> Bug #705652: Make remove_translations side aware. <upstream-translations-sharing> <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/705652 >
<danilos> adeuring, sure, in say 30 mins, would that work for you?
<adeuring> danilos: sure.
<danilos> thanks, adeuring, and feel free to re-ping me in that time :)
<adeuring> danilos: ok, will do :)
<bigjools> abentley: hmmm I don't understand how there is a packageupload at all if the upload failed
<jml> hah
<jml> ok
<bigjools> at what point are you looking for this data, in the failure code?
<jml> I think it's something imported by test_builder that's playing havoc
<bigjools> jml: yay....
<jml> easy enough to figure out
<bigjools> abentley: if there's a failure, you need to fall back to the data in the changes file really, the database will not be intact and is about to get its txn aborted
 * jml bisects
<bigjools> two jmls!
<bigjools> can we put one of you in another timezone?
<abentley> bigjools, this is in the archiveuploader, which already uses a PackageUpload object.
<bigjools> abentley: right, but I doubt it's committed yet
<bigjools> abentley: what are you fixing/doing exactly?
<abentley> bigjools, I am fixing the way the PackageUpload object determines whether it's processing a user upload or a build.
<abentley> bigjools, until my changes, it used self.builds for that.
<bigjools> as in a recipe build
<bigjools> abentley: the builds won't be signed
<abentley> bigjools, as in a recipe build or binary build.
<bigjools> user uploads are always signed
<bigjools> abentley: what's the problem you're fixing?
<abentley> bigjools, it's sending two emails because part of the code thinks it's doing a user upload and part of the code thinks it's doing a build upload.
<bigjools> ok
<bigjools> what are the conditions it's checking?
<bigjools> and, wtf, why 2 places!
<jml> hah
<jml> ok.
<abentley> bigjools, PackageUpload is now using self.builds and getSourceBuild to determine whether it's doing a build.  UploadProcessor is using its own, very different  self.builds to determine whether it's processing ubilds.
<jml> found the offending line in lp.testing.__init__.
<jml> now have to figure out why it's there before I kill it with great killing.
<abentley> s/ubilds/builds/
<jml> (also, implicit global monkey patches of core libraries should always have a comment)
<jcsackett> jml: and should maybe be avoided, if possible. :-P
<bigjools> abentley: ok, I'll have a looksee
<jml> jcsackett: well, I guess.
<jml> huh. I reviewed the change.
<jcsackett> jml: i mean, you're talking the realm of tests, where monkeypatching is sort of required. but "implicit global monkeypatch" is sort of a frightening prhase, don't you think? :-P
<bigjools> abentley: what is calling those, the notify() stuff?
<jml> jcsackett: yeah, it is.
<bigjools> _Frame.f_locals = property(lambda self: {})
<bigjools> wtf!
<jml> jcsackett: here it's really a specific instance of "imports should not have side effects"
<jml> bigjools: looking into it now
<jcsackett> jml: dig.
<jml> bigjools: found the bug and the code review
<jml> 425113 fwiw
<bigjools> excellent
<bigjools> bug 425113
<_mup_> Bug #425113: Some tests can fail without detection <build-infrastructure> <lp-foundations> <Launchpad itself:Fix Released> <Twisted:New> < https://launchpad.net/bugs/425113 >
<abentley> bigjools, yes, PackageUpload.notify
<bigjools> oh the irony
<bigjools> abentley: right, there's two lots of email that goes out
<bigjools> so it makes sense
<jml> hmm.
<jml> there was a comment in the MP
<jml> ahh, it got moved, probably by a zealous import formatter.
<abentley> bigjools, I think ultimately it would be good to have polymorphism change the behaviour of PackageUpload.notify depending on whether it's a build or user upload.
<bigjools> abentley: so, the code at the top of notify() is clearly wrong for recipe uploads
<jml> curse you distribution mirror prober!
<bigjools> jml: it'll be fun to see how many tests start failing when you remove that
<abentley> bigjools, the test for whether it's SECURITY?
<jml> bigjools: thing is, it was added to stop tests from failing silently
<bigjools> jml: hence: [15:29:34] <bigjools> oh the irony
<jml> yeah
<jml> I guess what I mean is, I don't think anything will fail when I remove it
<bigjools> abentley: oh actually, scratch that
<jml> oh
<jml> except that maybe some tests are failing silently now
<jml> was a bit too focused to get that
<bigjools> exactly
<jml> the thing here is that testtools doesn't have the bug that trial has
<bigjools> abentley: so sending two emails is the right thing in some circumstances
<bigjools> abentley: do you have a case where that's wrong?
<jml> I'm going to move this monkey-patch into the TwistedLayer, which should do the trick.
<bigjools> abentley: actually for PPA uploads it should always be one, I am thinking of the distro case
<abentley> bigjools, right.
<jml> ffs
<jml> how do I change a bugtask against testtools to be targeted against Launchpad? it says "too many matches" when I type "launchpad"
<abentley> jml, use the dropdown thingy.
<bigjools> abentley: can you point me at the code in the upload processor?
<bigjools> it's been 2 years since I delved into the notification code
<jml> abentley: ta
<abentley> bigjools, lib/lp/archiveuploader/uploadprocessor.py:634
<bigjools> abentley: the email bit I mean
<bigjools> it's not sending email there?
<bigjools> grar, this code is utterly shite
<abentley> bigjools, it's invoking self.build.notify there.
<abentley> bigjools, and hey! that's my code!
<bigjools> lol :)
<abentley> bigjools, well, I refactored it, anyhow.
<bigjools> ok, so that code there is for BFNs
<abentley> BFN=Build Farm Notification?
<bigjools> all the routine notification should be done in PU.notify
<bigjools> build failure notification
<abentley> bigjools, what do we notify about except failure (and success for recipe builds):?
<bigjools> uploaders always get an email
<bigjools> for source uploads anyway
<abentley> bigjools, and we don't permit binary uploads, right?
<danilos> adeuring, heya :)
<bigjools> abentley: not from user
<bigjools> s
<adeuring> hi danilos. shall we talk on mumble?
<danilos> adeuring, sure thing
<bigjools> abentley: process-upload is invoked with --builds in the buildmaster machine and then it knows to allow build uploads
<abentley> bigjools, right, that's where UploadProcessor.builds comes from.
<bigjools> abentley: if you can, I  would try and poke all your notification code into PU.notify
<bigjools> move it away from the build
<bigjools> then it will be consistent with the existing processing
<bigjools> and you can easily check to see if it's a recipe upload if you want to tweak any text
<abentley> bigjools, I can do that, but PU will still be incorrectly detecting that this is a user upload.
<bigjools> abentley: check to see if the upload is signed
<bigjools> it does that in a couple of places already IIRC
<bigjools> self.signing_key
<bigjools> abentley: once you move the notification code here, the logic will then be correct for when we start uploading sources from recipe to Ubuntu
<abentley> bigjools, actually, in order to move the code into PU.notify, I'd need to pass the build into PU.notify, so I guess I can just check whether it's None.
<bigjools> abentley: you don't need to pass the build
<abentley> bigjools, I want to do notification by calling self.build.notify, as we do with other build notifications.
<bigjools> abentley: no, use PU.notify
<abentley> bigjools, I don't want to duplicate the code needed to send a build notification.
<bigjools> otherwise it will never work properly
<bigjools> this is not a build notification
<bigjools> it's a source upload notification
<abentley> bigjools, does not compute.
<bigjools> you are uploading a source package that has come from a recipe
<bigjools> all of the notification logic for that is already there
<bigjools> all you need to do is possibly add extra text if you know it's from a recipe (I've not seen the recipe notifications)
<abentley> No, it's not.  Users would get a totally different email from what they used to get.
<bigjools> doing this as a build notification is wrong
<abentley> bigjools, why?
<bigjools> I just explained
<bigjools> where are the recipe "build" emails?
<abentley> I disagree.  I think upload failures should look like other build failures, except they should include the upload log.
<abentley> bigjools, this is how we used to do it.
<sinzui> I wonder how hard it would be to add a feature to inline help to create self-documentation for enums
<bigjools> then they are totally different to normal source upload emails and that is inconsistent
<bigjools> we created the source upload format after a LOT of consultation with people
<abentley> bigjools, the people who are doing recipe builds are expecting consistency with build failure emails, not source  upload emails.
<bigjools> who are they?
<abentley> bigjools, upstreams.  This is "bridging the gap" work.
<bigjools> what about successful uploads?
<abentley> For recipes, successful uploads are generating build-style notifications.
<bigjools> I don't think we should be doing that
<bigjools> it's inconsistent with source uploads
<abentley> bigjools, I think we should, because it's consistent with what we were doing before async uploads were implemented, and because source upload format is not valued by the target audience.
<bigjools> this will cause a lot of issues when we start doing recipe builds for ubuntu
<bigjools> errr, yes, it is
<bigjools> the format is irrelevant anyway, I am telling you where to send the notifications from
<bigjools> you can format them how you like
<bigjools> or they like
<abentley> bigjools, in order to format them how I like, I'm going to pass the build in.  Otherwise, I'd have to omit useful information from the notification.
<bigjools> if you do it from the build object, you will end up duplicating all the logic in PU - as you are now discovering
<bigjools> ok - you'll need to pass the build in if you can't get hold of it
<abentley> bigjools, no, I won't.  the logic is quite different.
<bigjools> ok - ignore me
<jml> need a review for https://code.launchpad.net/~jml/launchpad/failing-tests-bug-711209/+merge/48184
<jml> fix for some tests failing silently
<sinzui> hi jml: I will take it
<jml> sinzui: thanks.
<sinzui> jml: r=me
<jml> sinzui: ta
<jml> branch now in ec2
<jml> I can hardly wait.
<sinzui> bigjools: ping
<leonardr> reviewer needs some reviews done: https://code.launchpad.net/~leonardr/lazr.restful/web-link/+merge/48052 and https://code.launchpad.net/~leonardr/launchpad/web-link/+merge/47258
<bigjools> sinzui: otp, will get back to you
<danilos> allenap, hi, you around?
<allenap> danilos: Yes, but I need a few minutes.
<danilos> allenap, sure thing
<leonardr> all unassigned reviews in the review queue are done
<leonardr> except mine
<bigjools> sinzui: hi, how can I help
<sinzui> bigjools: I am reading line 1974 of lib/lp/soyuz/doc/archive.txt. Why is the team OPEN.
<abentley> bigjools, I see that isAutoSyncUpload checks both signing_key and contains_build, which suggests that they could vary independently.  Are you sure checking for a signature is a reliable test, or did you mean something else?
<bigjools> sinzui: I suspect no reason at all
<sinzui> Actually I think I know. Because a MODERATED requires an extra approval step for future tests in the doc
<bigjools> sinzui: ah yes, good point
<bigjools> that doctest is a nightmare
<bigjools> I've watched it grow over 3 years
<sinzui> bigjools: so it is. I am going to change the doc to MODERATED and will update another test to use addMember
<sinzui> Or I can delete the entire section if I find a unittest for this behaviour
<bigjools> sinzui: +1
<sinzui> thank bigjools
<bigjools> abentley: it's possible in the past that they did, but builds are never signed now
<bigjools> abentley: what time do you start work normally?  I want to call you about this tomorrow
<abentley> bigjools, I start work at 14:00 UTC.
<bigjools> ok, thanks
<allenap> danilos: Sorry about that. My son was demanding some toy train time. What's up?
<LPCIBot> Project devel build (408): STILL FAILING in 5 hr 24 min: https://hudson.wedontsleep.org/job/devel/408/
<LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][bug=708785] Fix a trivial speeling mistak
<LPCIBot> on the 'bug also affects' popup help text.
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless,
<LPCIBot> stevenk][bug=711016] Stop ec2 land from adding [ui=none] to commit
<danilos> allenap, no worries :)
<LPCIBot> messages, since PQM no longer requires it.
<LPCIBot> * Launchpad Patch Queue Manager: [rs=thumper][bug=683798,
<LPCIBot> 669288][rollback=12277] Stop deleting recipes when people/teams are
<LPCIBot> merged.
<danilos> allenap, so, I have this lovely duty of implementing LIFECYCLE direct subscriptions
<danilos> allenap, I've so far implemented the way to figure out what a certain change should be notified on
<danilos> allenap, like this: https://code.launchpad.net/~danilo/launchpad/lifecycle-subscription/+merge/48185
<danilos> allenap, now, I wonder how to best test for any changes in subscribers/bug.py add_notification where I want to use change.change_level directly
<danilos> allenap, also, in add_bug_change_notifications there's a few getRecipients calls which all use METADATA as the level
<danilos> allenap, and I am not sure how to best modify this
<allenap> danilos: Did you say anything between "I've so far implemented ..." and "and I am not sure ..."?
<danilos> allenap, I think I did :)
<allenap> danilos: Rats, I got knocked off t'internet and bip didn't give me any scrollback.
<allenap> danilos: Can you say it again?
<danilos> allenap, pasted privately
<danilos> allenap, under the assumption that it was you who got knocked off, and not me :)
<allenap> danilos: Cool. Erm, can I look at the branch so far?
<danilos> allenap, sure thing, it shouldn't be hard to deduce URL from the WIP MP :)
<danilos> allenap, and in the MP, you can also see the diff so far, just to get an idea of what I am doing
<allenap> danilos: You're making me work :)
<danilos> allenap, there is a diff ready to consume at https://code.launchpad.net/~danilo/launchpad/lifecycle-subscription/+merge/48185 :)
<danilos> allenap, and ok, lp:~danilo/launchpad/lifecycle-subscription :)
<danilos> allenap, the diff so far has no changes to  add_bug_change_notifications (I first want to understand how best to test this, since it seems to be involve zope event machinery or something, and events are fired "manually" in most tests I've seen)
<allenap> danilos: It's taking me a while to swap this back in... :)
<danilos> allenap, heh, I can understand that, you probably haven't touched this for a few years (it seems most of this code is from 2009)
<allenap> danilos: Yeah, we did a sprint for this when BjornT was the team lead and I think the only thing since then is that it's moved into lp.bugs.
<danilos> allenap, I am basically looking for the most minimal way to test that notifications are added properly and for the right group of people, before I go on the changing spree...
<danilos> allenap, so, my idea is to basically do something like the following change: http://paste.ubuntu.com/561035/
<danilos> allenap, however, without knowing exactly what's going on, and without tests that describe how this is properly used, I don't feel comfortable JFDI
<allenap> danilos: Okay. I'll try and figure something out.
<danilos> allenap, heh, if you've got to dive into code yourself, I don't want to bother you, since I can do the same thing :)
<allenap> danilos: I don't mind, but yes, that's what I'm going to do. I can't remember any of it without reading it again, though it might come back quickly.
<danilos> allenap, sure, if you can do it quickly and come up with a good attack plan, I'd appreciate it; if not, just set yourself a time limit on when to give up :)
<gary_poster> allenap: thank you for the review!  I've been looking at options for the deletion.  I wanted to explore __storm_remove__ hook but I don't see any reference to that (in LP code, storm, or https://storm.canonical.com/Manual#Hooks) or anything similar, to my surprise.  Unless you direct me to something I missed, I'll make "delete" or something like that.
<gary_poster> following the pattern on the filters themselves
<allenap> gary_poster: Sorry for sending you on a wild horse chase... afaik, __storm_remove__ doesn't exist. I was just thinking about it as an idea.
<gary_poster> gotcha, allenap.  A good idea :-)
<gary_poster> but understood.  I'll go with delete for now then.
<gary_poster> Thank you!
<allenap> gary_poster: Welcome :)
<allenap> danilos: There are no unit tests of add_bug_change_notifications(). I think I'd start some, and simply check that the right set of recipients have notifications added for them. The notify/subscriber machinery should be tested already. It might be even clearer to stub out bug.addChange() to get the recipient list directly, and no faff around with the database.
<allenap> danilos: All you really need to know is that the change_level from the IBugChange class is being used when calculating subscribers, isn't it?
<danilos> allenap, yeah, but I also need to understand exactly what's going on inside that method so I don't break it as well :)
<danilos> allenap, and I want to be able to state with some authority what kind of emails will people get after my changes :)
<danilos> allenap, anyway, thanks for looking into it
<allenap> danilos: I don't think you'll break it. For this branch I don't think you need to worry about asserting exactly what the end product looks like; the composition of the messages already tested elsewhere. You just need to check that the correct recipients are chosen.
<allenap> danilos: One aside: I don't addChangeNotification() is really being used any more, except in bugnotification-sending.txt. I will throw up a branch to remove it.
<bigjools> the branch diff overlay on bugs pages is not removable :/
<leonardr> sinzui, shall i review https://code.edge.launchpad.net/~sinzui/launchpad/team-membership-policy-1/+merge/48203 ?
<danilos> allenap, thanks
<sinzui> leonardr: yes please
<leonardr> sinzui, changing the order of the enums doesn't affect which numbers they're given behind the scenes?
<leonardr> sinzui: i understand the difference between a delegated team and a moderated team but i don't see what difference it makes. are you going to/have you reduced the powers of people who are indirect members of a delegated team?
<leonardr> sinzui: was subscription_policy_description simply not used at all? the only place it's referenced here is when you remove it
<sinzui> leonardr: all it really does is place the new members in the proposed state. It is an open team with all the restrictions of an open team
<sinzui> subscription_policy_description was not used. It has not been used in 18 months
<bigjools> jml: merged your branch into mine and it's all hunkydory now, cheerfs
<bigjools> and on that note, dinner time
<bigjools> nn all
<sinzui> leonardr: locoteams is MODERATED now because they want to prevent people and unapproved teams from joining. They think it is fine if people or teams join at a local level.
<leonardr> sinzui: so it's an open team that requires approval for direct memberships but not indirect memberships, and there is no functional difference between a direct and an indirect membership?
<sinzui> leonardr: correct
<leonardr> sinzui: 96 "contol" => "control"
<leonardr> also "polcy"
<sinzui> ah
<leonardr> 166 "verses" => "versus"
 * leonardr is more picky about typos in user-visible text
<leonardr> sinzui: i see the answer to my first question. you reordered the enums but you didn't change the numbers
<sinzui> damn right I did not change the enums. Those are in the database. making moderated teams into open teams will make 1000's of ppas insecure
<leonardr> i was just wondering how you had done that
<leonardr> sinzui: your split of the __doc__ on line 264 seems a little hacky to me, but it's ok
<sinzui> leonardr: Lp forms layout enums by their sequential order. They are easier to read and understand if the rules are changing along one axis
<sinzui> yeah. it is wacky. I do not like it. I could not think how to compose the enum from a title and description so that a common description could be shared.
<leonardr> sinzui: maybe TestTeamSubscriptionPolicyChoiceCommon.POLICY should be None?
<sinzui> That will break one of the tests that creates a team
<leonardr> never mind, i thought it was being used as a base class
<sinzui> I could either inline the helper logic, or I could change the helper to failover
<sinzui> Maybe inheritance is bad in this case because the test was ambiguous
<leonardr> i think it's ok
<leonardr> i think what tripped me up was the comment
<leonardr> # Any policy can be used in set of tests.
<sinzui> leonardr: yuck
<leonardr> would it be accurate to say "Any policy will work here, so we'll just pick one"
<sinzui> yes, that is better
<leonardr> sinzui: a little confused about line 598
<leonardr> why is cprov now a team owner?
<sinzui> that is not the method sig
<sinzui> ITeam.addMember(member, review)
<sinzui> The team owner is the reviewer adding cprov
<sinzui> The "ignore" is a TeamMembership record for the new membership
<leonardr> got it
<sinzui> The previous code relied on the auto-approved rule in join() for OPEN teams. The problem is that no OPEN team can own a PPA, so the example documentation will actually fail in most circumstances.
<leonardr> i understand now. it's fallout from line 589
<leonardr> sinzui: r=me with the minor changes mentioned above
<sinzui> thanks. my spelling will need fixing in the enum, the html help, and the wiki page because I pasted from the enums
<lifeless> moin
<sinzui> The pun never ends
<leonardr> sinzui: "polcy" and "contol" are only in the help afaik
<leonardr> maybe the wiki as well
<leonardr> bigjools, i will review https://code.edge.launchpad.net/~julian-edwards/launchpad/double-build-bug-705342/+merge/48219 now
<jtv> hi lifeless
<lifeless> hi jtv
<jtv> lifeless: I didn't find a good way to run external commands in parallel, so wrote up a simple manager class.  Might be something you want to look at: https://code.launchpad.net/~jtv/launchpad/commandspawner/+merge/48226
<jtv> I'm going offline now though to deal with other people's IT problems.
<lifeless> jtv: did you look at the existing job system code for doing that? or the various twisted things we have?
<lifeless> jtv: we can talk later
<leonardr> bigjools: what's the difference between a virtual and a nonvirtual builder?
<jtv> lifeless: yes, looked at those.
<lifeless> leonardr: a nonvirtual one we don't run kvm/xen on; its just a chroot
<lifeless> leonardr: policy around those is we only run trusted builds on nonvirtual builders
<leonardr> lifeless: you mean that the only builds run on nonvirtual builders are trusted builds?
<lifeless> leonardr: yes (that is, ubuntu archive builds rather than PPA builds)
<leonardr> lifeless: thanks. bigjools:r=me
<leonardr> jtv, lifeless: do you want me to take a look at https://code.edge.launchpad.net/~jtv/launchpad/commandspawner/+merge/48226 or do you want to talk it over first?
<lifeless> leonardr: I think you should just review it
<leonardr> ok
<jtv> leonardr: thanks
<lifeless> leonardr: we certainly don't have a look-alike in-tree
<lifeless> there's likely something on pypi we could use
<lifeless> but whats written is written
<lifeless> jtv: if you had time in the future to either incorporate a pypi module, or to factor this out to a truely standalone thing we can publish on pypi, I think either of those things would be most excellent.
<jtv> lifeless: that's a good idea, though it lacks all sorts of things that others might want but we currently don't.
<lifeless> jtv: sure; we can accept patches for such things :)
<jtv> "the Internet will solve it!"
<lifeless> https://github.com/taichino/python_prefork is similar
<jtv> Oh, sorry, that's Internet 1.0.  The 2.0 phrase is "we'll crowdsource it."
 * jtv mumbles something about not needing not steenkin' github projects
 * jtv instantly regrets this as github sends chromium into an unusable state
<lifeless> oh oracle
<lifeless> you sad cats
<jtv> lifeless: ?
<lifeless> you know about the hudson trademark thing, right ?
<jtv> Not enough, evidently.
<lifeless> ok, so oracle buy Sun
<jtv> yes me knoooo
<jtv> me hold share
<jtv> but cats?
<lifeless> day one they have the hudson lead developer go from a decent work environment - good sized dual lcd yada yada yada, to a puny single screen in a existing oracle block
<lifeless> not long later he walks
<lifeless> then this trademark thing brews up
<lifeless> community voted - 90
<lifeless> 90% wanted to rename to get out from under the trademark.
<lifeless> overnight a 'susan duncan' from oracle posted a 'hudson will continue as hudson, we have a team @ oracle, come one come all' kind of email.
<lifeless> so rather than following 90% of the devs + users, they are going alone, with -1- person that knows the codebase at all.
<lifeless> (and who wrote ~ 1% of it)
 * jtv nods attentively
<jtv> lifeless: so were you using the word "cats" strictly in the sense of "people"?
<lifeless> yes, getting my 70's thang on
<jtv> Now I see.
<jtv> So yes, sad cats indeed.
<jtv> How about we pass the hat around and see how much we can offer Michael to change his name?
<lifeless> lol
<jtv> The prefork thing looks like it would't do much for our use case by the way, though it's hard to say without documentation.
<lifeless> its not a direct fit
<lifeless> thats for sure
<lifeless> jtv: lol; the first two replies to her message: 'unsubscribe'
<jtv> <laugh>
<jtv> Now if they could re-do it in python, that'd be different.
<lifeless> sonatype are going with hudson
<lifeless> cloudbees with jenkins
<lifeless> wheee
<leonardr> jtv: can you make it clear in line 287 that error 11 *is* "resource temporarily unavailable"? i had to look it up to make sure
<jtv> leonardr: oh, I thought I'd done that.  Will fix fortwith.
<jtv> forthwith.
<leonardr> jtv: it's just a little vauge
<jtv> leonardr: You're right.  Found a better spelling: errno.EAGAIN!
<jtv> Fix pushed.
<jtv> leonardr: you may be wondering why, in communicate(), I didn't extract the loop body into a method.  I did that originally, but that hid the fact that I remove an entry from the dict that the loop iterates overâand therefore the reason to iterate over keys() instead of iterkeys().
<leonardr> jtv: do you need to iterate over dead processes once they're dead?
<jtv> No, I just don't want to upset the iteration.
<leonardr> i don't think it matters much, but do i have it right that it's not necessary?
<jtv> Yes, you have it right.
<jtv> Maybe I'm just being too conservative.
<leonardr> i was wondering about test_communicate_returns_after_event
<leonardr> what happens to the sleep process? it just keeps running in the background?
<leonardr> would it make sense to tear that down?
<leonardr> if it's running in the background it's not a big deal
<jtv> It does, but that's why I did the self.addCleanup(spawner.kill).
<leonardr> thanks, i was looking for a TestCase style teardown
<leonardr> ie an actual teardown method in the class
<jtv> Though come to think of itâ¦ it'd be neater to do actual wait()s for the child processes wouldn't it?
<leonardr> i don't know much about this--is wait() blocking?
<jtv> Technically it is, I think, but not for long.
<jtv> It's been ages, so I'm vague on the detailsâ¦ wasn't un-wait()ed children how you got zombies?
<leonardr> jtv, i am also vague on the details
<jtv> I can whip up a quick test to find out.
<jtv> Yup, that's a zombie.  Need to wait() for it.
<leonardr> jtv: will that cause the test to stall for 10 seconds?
<jtv> No
<jtv> Just keep a zombie process around.
<jtv> Which is basically garbage and not nice,
<leonardr> jtv: i mean if you wait() will it cause the test to stall
<jtv> No, only if the sub-process catches the terminate signal.  Which doesn't happen in the tests.
<thumper> morning
<jtv> morning thumper!
<thumper> jtv: up late?
<jtv> thumper: no, in NL
<jtv> leonardr: I'm just pushing a change that does a kill()/complete() on all spawners in the acceptance test.  That oughta take care of any zombie danger.
<leonardr> i'm glad i could stumble into an improvement
 * thumper goes to look at the vast amount of email in the inbox
<jtv> leonardr: so am IâI'm not a big believer in permissive reviews. âº
<leonardr> taking a look at your changes now
<lifeless> ~/win 63
<jtv> I've heard of win64, butâ¦
<leonardr> jtv, r=me
<jtv> leonardr: thanks!  I'm adding a docstring note to explain about the zombies, but otherwise, should be good to go.
* lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: leonardr  | https://code.launchpad.net/launchpad-project/+activereviews
<leonardr> ok
<thumper> deryck: ping
<lifeless> flacoste: can you high-pri rt 43756 ?
<lifeless> flacoste: I have to run to town with Lynne, back in ~3 hrs
<thumper> deryck: https://code.launchpad.net/~thumper/lazr-js/multi-line-editor-goodness/+merge/48118
 * leonardr could still use reviews of two of his branches
<thumper> leonardr: https://code.launchpad.net/~thumper/lazr.restful/only-traceback-system-errors/+merge/48075
<thumper> leonardr: what do you need?
<leonardr> thumper: hi there
<thumper> leonardr: I started on one
<thumper> leonardr: the other was still work in progress
<deryck> thumper, I didn't have time to look yet.  You wanting me to review it for you?  Or just see what's up?
<thumper> leonardr: although I did look through it
<leonardr> yeah, i responded to it. the other one is ready now
<thumper> deryck: I'm after a real review :)
<leonardr> the other one being https://code.launchpad.net/~leonardr/launchpad/web-link/+merge/47258
<thumper> deryck: but pointers to what testing may be needed
<leonardr> thumper, looking at your lazr.restful branch now
<flacoste> lifeless: no permission to view ticket, did you file using launchpad@rt... ?
<thumper> deryck: the only JS thing that has really changed is the stripping of trailing whitespace, and hiding the spinner
<deryck> thumper, ok, give me a minute, and I'll try to get it before I EOD.
<thumper> deryck: thanks
<deryck> np
<lifeless> flacoste: jam filed it
<lifeless> jam: ^
<lifeless> flacoste: gone; back later
<leonardr> thumper: r=me
<thumper> leonardr: your lp weblink branch looks fine to me
<thumper> leonardr: shall I mark it needs review?
<jml> g'night.
<thumper> night jml
<leonardr> thumper: yeah, go ahead. i didn't realize that was what was keeping it
<thumper> ok
<leonardr> gary, i am reviewing https://code.launchpad.net/~gary/launchpad/bug711362/+merge/48232
<gary_poster> thank you leonardr
<leonardr> gary, i am confused by lambda: self.subscription.delete instead of self.subscription.delete. what's the difference?
<leonardr> is it the very attempt to access the delete attribute that causes the exception?
<thumper> hmm... I need to configure my local bits to be able to sumbit to lp:lazr.restful
<gary_poster> leonardr: yeah, I tried that first too.  yes, exactly
<leonardr> thumper: do a bzr co of trunk, then merge in and bzr commit. that's what i do
<thumper> leonardr: it isn't pqm managed?
<leonardr> thumper: no
<thumper> leonardr: ah... ok
 * thumper does that
<leonardr> we could maybe make it pqm managed again, but it used to be submitting a change to lazr.restful ran the launchpad test suite for no reason
<deryck> thumper, so looks good to me.  I would add a js test that the icons are re-enabled on error.  And some text on the example page to explain that it will error every other attempt would be nice.
<deryck> thumper, r=me with those changes.
<thumper> deryck: ok
<leonardr> gary: what do you mean "The original delete fails if it does not remove the filter first"? i don't see that in the code. do you mean that the only way the filter could not be removed is if the delete failed?
<flacoste> leonardr, benji: any news on the packaging of the new desktop integration into natty?
<leonardr> flacoste: no, i'll ping barry again
<flacoste> leonardr: thx
<gary_poster> leonardr: the DB rejects the delete of the structural subscription because the database would then be an inconsistent state
<gary_poster> (with the filter record pointing to the structural subscription)
<leonardr> ok, in that case i'm not sure what 'the original delete' is
<gary_poster> leonardr: it removes the filter first in the delete method.  I think "the original delete" is a bad term at least in part because there is no need to call it "original".  I guess I meant something like this:
<thumper> wow... the second buildout of lazr.restful was much faster than the first
<leonardr> thumper: that's the cache advantage
<gary_poster> "Trying to delete the structural subscription without first deleting the filters, as the "delete" method does, would raise a database IntegrityError.  Therefore, we know that the filter really is gone, but we double check it here anyway."
<gary_poster> leonardr: and fwiw, this is the exception you would have gotten:
<gary_poster> IntegrityError: update or delete on table "structuralsubscription" violates foreign key constraint "bugsubscriptionfilter_structuralsubscription_fkey" on table "bugsubscriptionfilter"
<gary_poster> DETAIL:  Key (id)=(5) is still referenced from table "bugsubscriptionfilter".
<thumper> leonardr: lazr.restful branch landed \o/
<thumper> leonardr: much faster than PQM :)
<gary_poster> "as the delete method does" is still confusing :-/
<leonardr> gary: ok, that's what i thought was going on. how about this wording
<leonardr> "We know that the filter is gone, because we know the subscription is gone, and the database would have prevented the deletion of a subscription without first deleting the filters"
<leonardr> "but let's double check"
<gary_poster> yes, leonardr
<gary_poster> thank you
<leonardr> gary, np
<leonardr> gary, r=me
<gary_poster> Thanks leonardr.  I'm improving the comment now.
<gary_poster> I'll also add a comment about the lambda
<leonardr> thumper: once my ec2 test completes i will do a lazr.restful release and land the launchpad branch
<thumper> leonardr: sounds great
<leonardr> i was able to verify that launchpadlib can access web_link if it's present
<thumper> leonardr: my editor work has to wait for that to land first
<thumper> great
<abentley> thumper, chat?
<thumper> abentley: sure
<thumper> abentley: mumble?
<abentley> thumper, yep
<jam> flacoste: I just used rt@admin.canonical.com, was I supposed to do something different?
<flacoste> jam: yes, please use launchpad@rt.canonical.com, it puts it in the right queue automatically
<jam> flacoste: k
<jam> that's the first I've heard of that address
<leonardr> thumper: got some test failures. some very minor, one possibly serious
<thumper> leonardr: oh?
<leonardr> thumper: minor ones are tests that had 'launchpad.net' urls instead of 'bugs.launchpad.net' for cves and so on
<thumper> ok
<thumper> wallyworld_: https://code.launchpad.net/~thumper/lazr-js/multi-line-editor-goodness/+merge/48118
<leonardr> the possibly serious one is a launchpadlib test that systematically checks every _link parameter as though it were a link to another launchpad web service object
<leonardr> basically, it sees web_link and thinks there must be a corresponding 'web' property
<thumper> hmm...
<thumper> if it is just a test, surely we could add an exception
<thumper> leonardr: mumble?
<thumper> StevenK: mumble ping
<leonardr> thumper, sure
<StevenK> thumper: Coming, sorry
<wallyworld_> sinzui: you around?
<sinzui> I am
<wallyworld_> sinzui:  are you able to sign off on: https://code.launchpad.net/~wallyworld/launchpad/recipe-find-related-branches/+merge/47367
<wallyworld_> pretty please :-)
<wallyworld_> ui review
<sinzui> wallyworld_: You have my approval
<wallyworld_> sinzui: thanks! much appreciated
<wgrant> abentley: Did you end up reaching agreement with bigjools about where to do notifications?
<abentley> wgrant, no, and I am handing off the project to thumper.
<wgrant> abentley: Well, from the snippets I read he argued that PU should do the notification. I am adamant that he is wrong, FWIW.
<abentley> wgrant, where do you think it should be done?
<wgrant> abentley: Build.notify, as it always has been.
<abentley> wgrant, cool.
<leonardr> thumper: first off, the test failure
<thumper> yep...
<leonardr> i believe the correct thing to do is to change lazr.restfulclient to interpret 'web_link' as a scalar value, not a link, when producing lists like lp_attributes and lp_entries
<leonardr> that's an easy change to make but it's not easy to test
<leonardr> so i suggest we file a bug for it, hack similar behavior into the launchpad tests, and land what we have
<thumper> leonardr: I'm not entirely clear on the underlying meaning in lazr.restfulclient with respect to the lp_attributes and lp_entries
<thumper> and how the web_link fits into it
<thumper> is it that web_link will move from lp_entries to lp_attributes?
<leonardr> thumper: yes, to put it slightly more accurately, 'web' will move from lp_entries to lp_attributes and will become 'web_link'
<thumper> leonardr: that sounds fine to me
<leonardr> lazr.restfulclient thinks that anything ending in 'link' is a link to another object comprehensible by lazr.restfulclient
<leonardr> in this case it is a link, but not one comprehensible by lazr.restfulclient
<thumper> right
<thumper> I think special casing it is fine
<leonardr> it doesn't have to be all that special
<leonardr> we can distinguish ahead of time between comprehensible links and incomprehensible, we've just never had incomprehensible links before
<thumper> how do we determine that it is incomprehensible?
<leonardr> thumper: by looking at the wadl. web_link has a <param> tag whose <link> element is empty--it doesn't point elsewhere in the wadl
<leonardr> in the words of the test failure error, "Parameter is a link, but not to a resource with a known WADL description."
<thumper> ok, is this part of the quick fix of the longer bug fix?
<leonardr> no, this is the longer bug fix--the problem is testing it
<leonardr> we might be able to fake this, but i believe we need to change lazr.restful so that the example web service publishes web_link (right now web_link only shows up in unit tests)
<thumper> so to be clear, we can make the fix quickly, and file a bug for the testing of it?
<leonardr> thumper: i was suggesting fixing it in launchpad, but yeah, we can fix it for real pretty easily
<thumper> leonardr: does the restfulclient *need* lazr.restful example service to publish web_link?
<thumper> I would think that a fake would be better
<leonardr> thumper: that's how we do the tests. i would prefer a fake as well, but i don't think we have the infrastructure for it
<thumper> ah.. the tests for lazr.restfulclient depend on the lazr.restful example server?
<leonardr> yes, they are integration tests making simulated http requests and getting responses
<leonardr> we can do unit tests in lazr.restful but not so much in the client, i think
<thumper> I'm thinking of a potential solution...
<thumper> it may be completely off though
<leonardr> let's hear it
<thumper> what if, as part of the tests for restfulclient, we had a decorated server, that intercepts the calls to the example restful server and annotates it with a web link?
<leonardr> thumper: it would be simpler to make the example server serve a web link for real
<thumper> probably
<leonardr> actually, i could probably work something up with a fake wadl document
 * thumper likes fakes (of a certain kind)
<leonardr> that would be closer to a unit test
<leonardr> since there is no data going over the wire
<leonardr> it's just restfulclient making judgements about the structure of the web service based on the wadl
<leonardr> barry: lazr.restfulclient in natty is up-to-date
<leonardr> so don't worry about that
<StevenK> wgrant: Have we seen the test_404 and one other failures in ec2 before?
<leonardr> thumper: two possibilities, your call
<wgrant> StevenK: i've seen them once.
<wgrant> And they've appeared on Hudson
<wgrant> But they only appear often on buildbot.
 * thumper nods
<leonardr> 1. i'll fix the failing tests in launchpad, get my branch into ec2 land, and fix it in restfulclient tomorrow
<leonardr> 2. i'll fix it in restuflclient tomorrow and land everything tomorrow
<StevenK> wgrant: What do you think? Resubmit and hope ec2 is kinder?
<thumper> leonardr: what breaks if we go for 1 ?
<wgrant> StevenK: I'd just go to lp-land if they were the only failures.
<thumper> leonardr: just test failures in lazr.restfulclient?
<leonardr> thumper: launchpad contains code to work around the problem for a little while
<thumper> leonardr: what is the impact of that though?
<leonardr> thumper: not much. just "this is hacky"
<thumper> leonardr: lets land everything when it is good to work together
<leonardr> thumper: ok, that will be my goal for tomorrow
<thumper> ok
<leonardr> i'd like to hear your suggestions for what to do after that
<thumper> leonardr: i was looking at the lazr.restful errors
<thumper> well, bugs, not errors
<leonardr> right
<thumper> bug 619180 is listed as critical, and probably not too much
<_mup_> Bug #619180: UnicodeEncodeError creating a team that contains non-ASCII on name via API <api> <lp-foundations> <oops> <lazr.restful:Triaged> < https://launchpad.net/bugs/619180 >
<thumper> also, bug 373370 looks like it should be a good to do candidate
<_mup_> Bug #373370: Text fields can be made empty via the API, but not via the web UI <api> <lp-foundations> <Launchpad itself:Triaged> <lazr.restful:Triaged> < https://launchpad.net/bugs/373370 >
<leonardr> thumper: ok, i'll take a look. may be lazr.restful, may be launchpad
<thumper> leonardr: understood
<huwshimi> leonardr: Thanks for approving my branch.
<leonardr> huwshimi: np
<wgrant> Any idea why staging is out of date?
<thumper> leonardr: the example given in bug 619180 actually has unicode in the name, which would hit a validation error
<_mup_> Bug #619180: UnicodeEncodeError creating a team that contains non-ASCII on name via API <api> <lp-foundations> <oops> <lazr.restful:Triaged> < https://launchpad.net/bugs/619180 >
<wgrant> There's nothing in the logs since the last update finished several hours ago.
<thumper> leonardr: I wouldn't expect a unicode encode error though
<thumper> my guess is that it should be a 400 Bad input type error rather than an oops
<wgrant> Hmm. It's possible that it's a Launchpad issue, and the exception's __str__ is trying to do bad things.
<thumper> wgrant: could be
<leonardr> thumper: that says to me that validation code is not running, since errors during validation are turned into 400s
<wgrant> leonardr: This seems to be a UnicodeEncodeError while reporting the validation failure, right?
<thumper> leonardr: perhaps with our change several weeks ago, to fix the validation, it may now fail better :)
<wgrant> thumper: I reproduced it when I reassigned it.
<wgrant> It's still present.
<thumper> wgrant: from when?
<leonardr> i guess i should have looked more carefully at the traceback
<leonardr> yeah, it's an error presenting the validation error
<wgrant> thumper: Hm? I reproduced it like 3 days ago.
<thumper> could be
<StevenK> wgrant: Did you tag the other bug too?
<wgrant> StevenK: Yes.
<wgrant> To unbreak qa-tagger.
<StevenK> wgrant: Yes, I just got the mail, thanks.
<wgrant> It needs bad-commit-* for the rollback to be effective.
<thumper> abentley: is there a bug for this?
<wgrant> I had to read the code to find out why it wasn't working :/
<StevenK> wgrant: :-/
<StevenK> wgrant: Aside from Henning, it looks like your QA
<abentley> thumper, you mean bug #681125?
<_mup_> Bug #681125: Async uploader sends recipe mail as if it were source package uploads <lp-code> <qa-ok> <recipe> <Launchpad itself:Triaged> < https://launchpad.net/bugs/681125 >
<wgrant> StevenK: Yup.
<wgrant> StevenK: But qastaging's codebrowse is either broken or not there, and staging is one rev too old.
<thumper> abentley: yep, thanks
<StevenK> wgrant: So tempted to reply 'lolwut'
<wgrant> abentley: To be clear, your recipe mail changes at the head of the deployment queue are still OK to roll out?
<wgrant> Despite the current debate?
<abentley> wgrant, yes.  My current changes are deployable, but an incomplete fix.
<wgrant> Great, thanks.
* leonardr changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: -  | https://code.launchpad.net/launchpad-project/+activereviews
<sinzui> wgrant: mumble?
* StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: StevenK | https://code.launchpad.net/launchpad-project/+activereviews
<jcsackett> sinzui: you want to continue on Person:+bugs, or just catch up tomorrow?
<huwshimi> wgrant: Your mumble stutters quite a bit for me, but everyone else sounds fine. Is everyone clear for you?
<wgrant> huwshimi: Hm... Everyone's clear for me, and I sounded clear enough from the feedback I heard through sinzui's mic.
<wgrant> Odd.
<huwshimi> wgrant: yeah that is odd
<wallyworld_> wgrant: are you testing rev 12290? - it's currently blocking subsequent rollouts
<wgrant> sinzui/jcsackett: Was my mumble connection OK?
<wgrant> wallyworld_: I am waiting on a LOSA to unbreak qastaging codebrowse. I have a nodowntime rollout request for 12293 in my clipboard :)
<wallyworld_> wgrant: thanks :-) just trying to get ready for pqm closure on friday
<jcsackett> wgrant: yeah, you sounded fine.
<huwshimi> sinzui: I fixed my css issue
<huwshimi> sinzui: How do I go about using the sprites?
<sinzui> huwshimi: drop the new image into lib/canonical/launchpad/images . Add a new class to lib/canonical/launchpad/icing/style-3-0.css.in (the comment is required)
<sinzui> huwshimi: run make sprite_image then make css_combine to see your change
<wgrant> StevenK: Could you review https://code.launchpad.net/~wgrant/launchpad/bug-654585-linkify-bug-acknowledgement/+merge/48254?
<StevenK> Can I get bzr di to give more context with it's diffs? The manual page and bzr di --help weren't very helpful
<wgrant> StevenK: I don't think it can do it directly, but you could use --diff-options.
#launchpad-dev 2011-02-02
<wgrant> "bzr diff --diff-options='-C 10' -rancestor:../devel" seems to work fine.
<StevenK> wgrant: Ooh, thanks!
<huwshimi> sinzui: Great, thanks!
<huwshimi> sinzui: How do I manually position that sprite (it always sticks it in the top right of the container right)?
<sinzui> huwshimi: you cannot :(
<huwshimi> sinzui: oh
<sinzui> however maybe we can change the generation rules to create more white space to offset when the colour starts
<huwshimi> sinzui: so should I create an html element to contain the sprite and position that?
<sinzui> That will look right, but I think we have a line-height issue
<huwshimi> sinzui: This seems like a pretty fundamental issue with our sprite generator :(
<huwshimi> sinzui: you can't even right/center align or anything then.
<sinzui> huwshimi: you are over thinking this. We have something that makes the sprite. We have rules in .sprite that does the basic offset. the other items in the css are non-negitiable
<sinzui> huwshimi: that is because the image is a background
<lifeless> wgrant: whats up with qas codebrowse?
<wgrant> lifeless: qas http codehosting is broken.
 * StevenK kills hudson
 * sinzui looks for the sprite generation rules
<wgrant> lifeless: I am hoping that codebrowse will magically unbreak once HTTP in general works.
<lifeless> 301 look
<lifeless> 301 loop
<wgrant> Or that buildbot will not explode this time, will update db-stable, and then allow me to QA on staging instead.
<wgrant> Yes.
<lifeless> wgrant: is there an RT open ?
<wgrant> lifeless: No.
<wgrant> But spm was working on it before.
<lifeless> win
<lifeless> oracle kicked kohsuke from the java.net project for hudson
<StevenK> That's a bit rude
<lifeless> yes
<lifeless> http://java.net/projects/hudson/lists/dev/archive/2011-02/message/15
<StevenK> lifeless: To be frank, I'm disgusted at ORA for their handling of this
<wgrant> Oh, awesome.
 * StevenK is fixing Hudson to actually run a build
<StevenK> Which wasn't helped by the cloud controller going off into lala-land
<lifeless> StevenK: yeah, ditto
<wgrant> Is anyone not disgusted about Oracle's handling of anything recently?
<lifeless> oracle?
<StevenK> Haha
<lifeless> StevenK: want to review https://code.launchpad.net/~wgrant/launchpad/bug-654585-linkify-bug-acknowledgement/+merge/48254 ?
<lifeless> flacoste: still around ?
<StevenK> wgrant, lifeless: Reviewed
<lifeless> StevenK: you still need a mentor right ?
<StevenK> lifeless: Right
<lifeless> thumper: ^ :)
<thumper> ah?
<lifeless> thumper: you're StevenK's mentor, right ?
<thumper> yup
 * thumper looks
<thumper> StevenK: do you realise that wallyworld_ is waiting on a review from you?
<StevenK> Oh, argh
 * StevenK looks at that
<StevenK> Got distracted by Hudson being broken
<wgrant> StevenK: :( zip is awesome
<StevenK> wallyworld_: Ugh, 960 lines.
<StevenK> wgrant: Why :( ?
<wallyworld_> StevenK: it's mostly tests etc
<wgrant> StevenK: You said you hadn't seen it before.
<StevenK> wgrant: No, I use map() for that sort of thing, but zip() looks good.
<StevenK> The map() in Perl is scarier
<wallyworld_> StevenK: thanks for review. You completely happy the code used to find the related package branches is ok?
<StevenK> wallyworld_: Yes, it looks fine, providing your tests exercise it all.
<thumper> StevenK, wgrant: commented
<wallyworld_> StevenK: i think they do but i'm not 100% familiar with that part of the domain model so am a little nervous that i have missed something
<wgrant> thumper: I initially added the class unconditionally, but it seems redundant, may be a lie (when text_to_html is inserted in the middle of some other text), and breaks dozens of tests.
<thumper> wgrant: hmm...
<thumper> wgrant: I'm flexible on the conditionalness of the css class, but I think the code needs tweaks
<thumper> wgrant: it is unfortunate that it breaks so many tests
<wgrant> And yes, your proposal is much easier to understand. The current one evolved from when it was unconditional.
<mwhudson> wgrant, StevenK, lifeless: well, at least oracle's behaviour means that everyone should immediately jump ship to jenkins on github, i guess?
<StevenK> That'd be nice.
<lifeless> mwhudson: its not that simple ;)
<StevenK> lifeless: It isn't?
<lifeless> mwhudson: sonatype are following oracle; various corporate users have expressed concerns about the discussion with *their* mgmt
<mwhudson> urgh
<wgrant> well, let's hope that Oracle keeps blundering around destroying things.
<StevenK> TBH, it seems more like controlled destruction rather than blundering
<wgrant> They surely can't want the entire community to evacuate.
<StevenK> They haven't been entirely clear and open about what they do want, either.
<lifeless> they have
<StevenK> Last I read, they were still discussing, have things moved on?
<lifeless> they want the trademark, the core infrastructure libraries changed to ones with contributor agreements, compulsory contributor agreements for plugin authors
<lifeless> strict process
<StevenK> And this while they swear they don't have any customers using Hudson?
<lifeless> the have support customers of hudson inherited from sun; they ak'd that. they don't have a hudson /product/ that they sell
<thumper> rockstar: ping
<thumper> or anyone else who is familiar with the lazr-js tests
<wallyworld_> thumper: when you have a spare moment, can you rubber stamp (or not) that related bracnhes mp? i'm still a little nervous that the algorithm used to find the related branches is correct. it looks ok but...
<thumper> wallyworld_: ok
<StevenK> thumper: Seems like moveBranch is used by branch.setOwner, which will rename if necessary, but it wants a user to do the move as, and I don't feel comfortable just randomly grabbing at an admin
<thumper> StevenK: ah... whut?
<thumper> StevenK: perhaps we should talk this through
<StevenK> thumper: Sure
<thumper> StevenK: but give me a few minutes
 * wallyworld_ thinks it's interesting that +linkbug on a branch page pops up an ajax form whereas +linkbug on an answer page goes to a separate page. would have expected some consistency there
<thumper> wgrant: hey, can I throw a bug your way? https://bugs.launchpad.net/launchpad-buildd/+bug/693524
<_mup_> Bug #693524: java failure in recipe builders <recipe> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/693524 >
<thumper> wgrant: I was discussing with flacoste and we agreed it is an operational thing
<thumper> wgrant: seems like an intermittent failure of some kind
<thumper> wgrant: most likely needs input from lamont
<thumper> mwhudson: hi, got a minute?
<mwhudson> thumper: sure
<thumper> mwhudson: otp now
<lifeless> poolie: https://launchpad.net/~ubuntu-branches/+members#active
<poolie> yes, i see
<thumper> mwhudson: mumble or skype?
<mwhudson> thumper: skype is usually more reliable
<thumper> ok
<mwhudson> logging in now
<mwhudson> thumper: i can hear you!
<mwhudson> let me play with alsamixer
<thumper> mwhudson: what? no pulse?
<mwhudson> thumper: can you hear me now?
<lifeless>     Hard / Soft  Page ID
<lifeless>      832 / 8921  Archive:+index
<wgrant> lifeless: We have a winner.
<lifeless> \i/
<wgrant> 13:31:23 < lifeless>     Hard / Soft  Page ID
<wgrant> 13:31:24 < lifeless>      832 / 8921  Archive:+index
<wgrant> 13:33:12 < wgrant> lifeless: We have a winner.
<wgrant> lifeless: Do we have a pattern for caching SQLMultipleJoins?
<lifeless> gimme a sec
<wgrant> I think I can probably turn it into a cachedproperty that returns a list. But I am hoping there is a less bad way that I've missed.
<lifeless> Sorry was otp
<lifeless> whats the join you're looking at ?
<lifeless> wgrant: are you talking about caching the collection on a domain object ?
<wgrant> lifeless: BinaryPackageRelease.files
<wgrant> I need to prepopulate and cache that.
<wgrant> Apart from iteration its users are fortunately few.
<lifeless> wgrant: the simplest answer is don't use the .files attributes
<wgrant> lifeless: Replacing it with what?
<lifeless> wgrant: actually, lets step back
<lifeless> wgrant: whats the service point you're optimising ?
<wgrant> lifeless: CopyChecker.checkCopy and PublishingSet.copyBinariesTo
<wgrant> This particular case applies to both, but mostly the former right now.
<lifeless> they are internal apis
<wgrant> Ah.
<wgrant> Archive:+copy-packages and Archive.syncSource.
<lifeless> whats the *service* point: LP API or pageid
<lifeless> ok
<wgrant> Both.
<lifeless> do they deal with > 1 BinaryPackageRelease ?
<wgrant> Yes.
<lifeless> wgrant: ok, so we need to eager load for some N b-p-r the releated binary package files
<lifeless> wgrant: we're going to want decorated result set's pre_iter_hook for this
<lifeless> wgrant: in terms of exposing it, cached property is completely correct
<lifeless> wgrant: If I was doing it I would:
<lifeless> changes 'files = SQLM...'
<lifeless> to '_files = SQLM...'
<lifeless> create a cachedproperty for files which returns self._files
<lifeless>  - not listified =
<lifeless> and then eager load from where needed
<lifeless> wgrant: do you see why not listified ?
<wgrant> lifeless: No.
<lifeless> its a collection; adding to a list wouldn't DTRT
<wgrant> Right, but we never add to the collection, except with addFile.
<wgrant> And the collection will be lazy.
<lifeless> so perhaps that doesn't matter
<wgrant> So we have to return a list.
<lifeless> the service pointyou're optimising won't ever access the SQMLMultipleJoin anyway
<lifeless> because you're going to be eager loading
<wgrant> So it is going to sometimes return a list and sometimes a ResultSet?
<wgrant> Er, SQLMultipleJoin, not ResultSet, but same thing.
<lifeless> not the same, though similar ;)
<lifeless> yes, thats correct, because result sets don't cache
<wgrant> Same problems.
<wgrant> eg. .count() works on one, but not the other.
<lifeless> SQLMultipleJoin is  SQLObjectResultSet
<wgrant> (oh how I wish we used SQLAlchemy...)
<lifeless> wgrant: do you need to do counts() ?
<wgrant> lifeless: Some places do.
<wgrant> But I will make them use len.
<lifeless> wgrant: in which case, back to my prior statement - stop using .files
<wgrant> Because files will be a list very shortly.
<lifeless> create a new thing - e.g. getFiles, have *that* always return a list and cache, and eager load it for the service point.
<lifeless> or, migrate completely to lists if you like
<wgrant> That seems like overkill for something that is an iteration-only attribute anyway.
<wgrant> Right.
<lifeless> wgrant: well, its not iteration only from what you say ;)
<wgrant> Or we could use SQLAlchemy :D
<wgrant> iteration and counting, no mutation or indexing, then.
<lifeless> shiny http://www.thinq.co.uk/2011/2/1/new-it-announces-dreamplug-arm-box/
<wgrant> Is Sheeva ARMv7?
<wgrant> I thought it was Kirkwood.
<thumper> [15:16:22] <thumper> wgrant: I was discussing with flacoste and we agreed it is an operational thing
<thumper> [15:16:36] <thumper> wgrant: seems like an intermittent failure of some kind
<thumper> [15:16:42] <thumper> wgrant: most likely needs input from lamont
<thumper> wgrant: not sure if you saw those
<wgrant> thumper: I didn't. I don't even know what they reference.
<thumper> wgrant: sorry, I missed the earlier bits
<wgrant> Sorry, my connection was out for 5 minutes or so.
<thumper> [15:16:07] <thumper> wgrant: hey, can I throw a bug your way? https://bugs.launchpad.net/launchpad-buildd/+bug/693524
<_mup_> Bug #693524: java failure in recipe builders <recipe> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/693524 >
<wgrant> Ah, right, that bug.
<wgrant> Yay.
<wgrant> bigjools poked lamont about it a couple of days back, IIRC.
<wgrant> He said he didn't know of anything.
<thumper> hmm...
<lifeless> we really need some trigram support in the namecache
<wgrant> It sounds like it's running out of RAM, though.
<wgrant> lifeless: namecache? targetnamecache, or is there another one?
<lifeless> only one
<lifeless> its a little noddy; we might be better off to move the target dereferences into it
<wgrant> thumper: Hmmm, that's really odd.
<wgrant> It's definitely a lamont sort of thing, unless someone else can hijack a virt builder and check it out.
 * wgrant wanders out for a while.
<stub> There is trigram support in postgresql-contrib. I've not bothered with it yet as it was part of the whole search story and unclear what our goal is.
<stub> 'for sale in the UK' but the power plug in the picture is US. That might be my future media centre.
<lifeless> stub: I think broadly we want to bring lucene/lucandra in
<lifeless> stub: but we need stopgaps along the way
<lifeless> stub: are you able to look at the scripts that restore [qa]staging ?
<stub> whats up with them?
<StevenK> qastaging's database is a few months out of date
<lifeless> stub: as StevenK says, the qastaging db, while its schema is ok, has very stale data.
<stub> We don't have a script to rebuild it?
<stub> There seems to be a restore_launchpad_qa.sh in ~postgres/scripts on sourcherry
<stub> So I guess a losa needs to run that.
<lifeless> stub: hmm, I thought the plan was:
<lifeless>  - restore to a temp db; clone that for staging (and patch); clone it for qastaging
<lifeless> so both would restore at the same time.
<lifeless> stub: could you run 'explain analyze select count(*) from bug join bugtask on bugtask.bug=bug.id where ftq('kpassgen') @@ BugTask.fti;
<lifeless> '
<lifeless> on the prod instances for me ?
<stub> http://paste.ubuntu.com/561236/
<lifeless> stub: thanks; thats very interesting
<StevenK> Anyone available to review a branch of mine?
<lifeless> apparently our full text index is sufficiently poor that a seqscan of all bugtasks is better than an index scan
<lifeless> for a search returning one row
<lifeless> StevenK: shoot
<StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/merge-recipes-during-merge/+merge/48264
<lifeless> wgrant: want some review practice?
<stub> I can redo the 'build _new databases' and 'swap into place' processes, which is in database/replication/Makefile in the lp tree. The losa scripts will then need tweaking.
<lifeless> stub: if you have the time, this would be nice to sort out
<stub> I'll try and get something to test at the start of the next cycle. If we are desperate this cycle, we should rebuild with the existing process.
<stub> I'm not sure now why this speeds things up.
<stub> We only rebuild staging once per week at the moment because it is replicated, and the bulk of the time is building the replica.
<stub> And rebuilding qastaging is faster with the existing process (restore dump, swap into place) than (restore dump, copy to new db, swap into place)
<lifeless> stub: not desparate
<lifeless> stub: whatever is faster is fine; I had an incomplete understanding
<stub> It will speed things up if we go to Slony-I 2.0, because then we can use a new feature to build two replicated databases quickly.
<lifeless> stub: the goal is weekly qastaging rebuilds
<lifeless> stub: question for you on slony 1.x - with 2 slaves, are transactions done in parallel on the slaves?
<stub> (restore a db, clone it, set up replication but tell slony the data is already good so no need to copy it from master -> slave)
<lifeless> e.g. N time on master and then ~N on each slave, but the slaves don't wait for each other
<stub> Its done in parallel.
<lifeless> cool
<lifeless> stub: in which case I think you confused yourself analysing the time for julians type change patch
<stub> Otherwise replication would stop if any one slave fell over or was down.
<stub> Oh... DDL.
<lifeless> stub: its the same, surely?
<stub> I think it is done master then all slaves in parallel. What is the formula on the wiki?
<lifeless> stub: not sure; just saw you add another 50% for the second slave in backlog here the other day
<stub> We tested this and worked out the correct formula  for DDL, but now I'm fuzzy on the actual empirical results :)(
<lifeless> stub: uhm
<lifeless> stub: help me out here; where is the bugtask.fti index
<lifeless> stub: I see a gist index for bug.fti, but none for bugtask.fti
<stub> For DDL, it could be either. Depends if Slony's EXECUTE SCRIPT runs the script on all nodes one in series, or all nodes in parallel, or creates an event that goes through the normal replication channels, or runs on the master then creates an event so changes propagate to the slaves per normal replication.
<stub> Think the latter.
<stub> Whoops. I guess we lost the index somewhere. They get created by fti.py.
<stub> Perhaps when experimenting with GIN indexes a few years ago?
<stub> Or fti.py might be broken and the index never got created...
<lifeless> stub: could you create it on qastaging?
<lifeless> I'm looking at this 7 second query, and 4 seconds of it seems to be text search
<lifeless> wallyworld_: whats the bug you're working on that bug 711619 is a dup of ?
<_mup_> Bug #711619: "Merged at revision" in merge proposal pages doesn't link to the revision <Launchpad itself:New> < https://launchpad.net/bugs/711619 >
<stub> lifeless: its building now
<lifeless> stub: wicked, thanks.
<wallyworld_> lifeless: i'll look
<lifeless> wallyworld_: perhaps its not a dup; but it seemed to be offhand to me.
<stub> lifeless: Created
<lifeless> stub: \o/
<wallyworld_> lifeless: i'm landing bug 334336
<_mup_> Bug #334336: Show which branch and bug are related to a revision <bugjam2010> <lp-code> <qa-ok> <Launchpad itself:Fix Committed by wallyworld> < https://launchpad.net/bugs/334336 >
<wallyworld_> i'm only doing the extended reision listing on the branch index page though
<wallyworld_> the merge proposal page is unchanged
<lifeless> stub: drops the queries I was trying from 800ms to 50ms
<stub> I'm creating the indexes on production (Bug #711632)
<_mup_> Bug #711632: BugTask.fti missing an index <Launchpad itself:Triaged by stub> < https://launchpad.net/bugs/711632 >
<lifeless> stub: thanks!
<lifeless>          ->  Seq Scan on bugtask  (cost=0.00..52921.26 rows=158774 width=152) (actual time=0.022..550.938 rows=184186 loops=1)
<lifeless>                Filter: ((distribution = 1) AND ((status = 10) OR ((date_incomplete IS NOT NULL) AND (status = 15)) OR (status = 15) OR (status = 20) OR (status = 21) OR (status = 22) OR (status = 25)))
<lifeless> ><
 * wallyworld_ hates qastaging timing out all the time :-(
<wallyworld_> lifeless: if you want to see what it looks like: https://code.qastaging.launchpad.net/~bzr-pqm/bzr/bzr.dev
<wallyworld_> bear in mind most bzr revs have linked branches
<wallyworld_> many other series don't and only one or two revs will have those links
<poolie> hi ian
<wallyworld_> hi poolie
<poolie> wallyworld_, oh, wow, that is nice
<wallyworld_> makes it easier to get to stuff, that's why i picked up that branch during the bug jam - thought it would add value
<wallyworld_> had to out it on hold while i was on leave, but landing now :-)
<poolie> it would be nice if the bug icon was colored and the status/importance was shown
<wallyworld_> s/branch/bug
<poolie> i guess if this is already landed that could be done as a follow on
<wallyworld_> hmmm. i just use the default rendering.
<wallyworld_> perhaps if a bug is fixed it is always grey
<wallyworld_> but i could show the importance
<wgrant> wallyworld_: That requires identifying the task.
<wgrant> MPs and branches already have code to do that, though.
<wallyworld_> that would have to be another branch though, since this one is already qa-ok
<lifeless> wallyworld_: ui thought; 'with linked bugs' is prose-like, but this isn't prose
<lifeless> wallyworld_: just having the indented table of bugs is pretty self explanatory
<wallyworld_> poolie: raise a bug if you want anything extra added :-)
<wallyworld_> lifeless: i agree now that you point it out :-)
<lifeless> At least 178 queries/external actions issued in 2.18 seconds
<stub> lifeless: You might want to add input to https://code.edge.launchpad.net/~gary/launchpad/bug548-db/+merge/48263 , which is adding a boolean flag to Person.
<lifeless>  thats reasonably snappy; could reduce the qquery count a little
<lifeless> wallyworld_: nice work
<lifeless> stub: is there a better place to add it?
<wallyworld_> ta
<lifeless> stub: ah, I see
<stub> lifeless: New table maybe. At the moment, personal settings like this just got tacked onto Person (like the existing verbose_bugnotifications flag)
<stub> and mailing list subscription policies
<lifeless> commented
 * wallyworld_ wonders why fields on ajax popup render in different order to when a separate page is rendered for the no script usage?
<StevenK> lifeless: O hai, did my review fall off your radar?
<lifeless> StevenK: I'm mentoring wgrant
<lifeless> StevenK: and hes awol (lunch I guess)
<wgrant> Oh, sorry, forgot about that.
 * wgrant looks.
 * StevenK reads scrollback
<StevenK> Oh, now I see the prod. Sorry.
<StevenK> lifeless: As a 'yes, this is a good idea' or 'no, this idea sucks' re bug 711636
<_mup_> Bug #711636: Support linking bugs directly from the MP <Launchpad itself:New> < https://launchpad.net/bugs/711636 >
<lifeless> StevenK: nice idea
<poolie> wallyworld_, what tags should such a bug have?
<wallyworld_> perhaps just ui?
<wallyworld_> i don't think it's confusing-ui
<poolie> no, i was wondering if it was 'code' or something
<poolie> but perhaps that's irrelevant now
<wallyworld_> that's what i was thinking
<wallyworld_> poolie: could you also add a comment to remove the "with linked bugs" prose pretty please as per a comment a few lines back :-)
<wallyworld_> it can be done as the one branch then
<poolie> sure
<wallyworld_> thanks
<poolie> i agree with that too
<poolie> is it just me or is that font especially tiny?
<wallyworld_> i made it small (but hopefully readable) to ensure the rev listing didn't require so much page space with all the new info shown
<wallyworld_> i can read it ok. do you think it's too small? it passed a proper ui review
<poolie> oh ok
<poolie> i can _read_ it
<poolie> it just kind of jars
<poolie> it's something like 50% of the size of the regular body text
<poolie> and it's not really fine-print informaiton
<wallyworld_> i like it because it still allows you eye to scan the individual revision lines easier
<poolie> for instance it's 50% smaller than the copyright notice, and i care much more about the bugs
<poolie> well, i just thought i'd mention it
<wallyworld_> i can see your point too though
<poolie> not a showstopper
<wallyworld_> maybe we could let the dust settle so to speak and see if there are many complaints
<wallyworld_> easy to change if required
<poolie> wallyworld_, what happens if the bug was directly fixed in that revision rather than by a merge?
<poolie> it's still shown, but not indented?
<poolie> sure
<wallyworld_> the bugs which are shown are those linked to the merged branch. so no branch = no bugs
<stub> lifeless: For design, I'm leaning towards PersonSettings and TeamSettings. Columns not filtered on and the appserver doesn't need when dealing with lists of people can be moved into one of those two. So Person.displayname stays, but mail_resumption_date goes to PersonSettings and renewal_policy, mailinglist_* goes to TeamSettings.
<wallyworld_> that's the current behaviour
<wallyworld_> poolie: perhaps something else to add to your bug report?
<stub> We start getting explicit separation of team/person then too, while keeping Person as PersonOrTeam which has been useful and will be hard to change.
<poolie> wallyworld_, https://bugs.launchpad.net/launchpad/+bug/711641
<_mup_> Bug #711641: bugs directly fixed in a revision aren't shown in branch view <Launchpad itself:New> < https://launchpad.net/bugs/711641 >
<thumper> lifeless: should we be doing "except Foo, e" or "except Foo as e" ?
<poolie> to me that's more of an actual bug (if true) not just a tweak
<wallyworld_> poolie: agree. i'll look at it and do a fix sooner rather than later if there's a problem there
<poolie> https://bugs.launchpad.net/launchpad/+bug/711643 for the nits
<_mup_> Bug #711643: tweaks to branch merged-revisions view <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/711643 >
<lifeless> thumper: either
<poolie> thanks for adding it though
<wallyworld_> poolie: will likely be next week after 11.02 rollout
<lifeless> thumper: I'd write as e for things which are in lp core; things which bzr may want, for instance, we'll want python 2.4 compat
<wallyworld_> poolie: np. spiv was interested as well in this feature i think
<poolie> wallyworld_, btw, i'll help you and spm roll out the forking lp-serve changes next week
<poolie> it's on the LPS page as an unusual deployment task
<thumper> ok
<StevenK> thumper: No mail from Aaron?
<lifeless> stub: could you look at my last comment in bug 661988 - is there anything else we can /should do? and would a union like that be useful or nuts.
<_mup_> Bug #661988: Timeout on Distribution:+bugs search <lp-bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/661988 >
<thumper> StevenK: yes actually
<wallyworld_> poolie: thanks. i hadn't yet followed up with that stuff
<thumper> StevenK: I'll forward it to you
<lifeless> stub: lastly, why do we bother having a bugtask fti column at all?
<StevenK> thumper: Thanks
<stub> lifeless: Full text search on targetnamecache?
<stub> and statusexplanation (dunno why we want to search on that)
<stub>  kde-guidance (Ubuntu)                    | 'back':70C 'bug':9C,45C,53C 'chang':67C 'click':57C 'close':7C 'column':65C 'comment':27C 'current':60C 'describ':23C 'futur':49C 'give':34C 'guidanc':3B 'hesit':42C 'inform':15C,38C 'investig':19C 'kde':2B 'kde-guid':1B 'lack':13C 'miss':37C 'need':17C 'new':72C 'pleas':28C 'previous':26C 'problem':21C 'reopen':29C,51C 'report':10C,46C,54C 'status':61C,64C,69C 'submit':44C 'thank':73C 'ubuntu':4B 'us'
<stub>  update-manager-core (Ubuntu)             | 'core':4B 'manag':3B 'ubuntu':5B 'updat':2B 'update-manager-cor':1B
<stub>  mozilla-firefox (Ubuntu)                 | 'around':26C 'b':31C 'back':37C 'check':50C 'complet':45C 'disabl':46C 'experi':41C 'firefox':3B 'flash':10C,22C,48C 'flash-play':21C 'float':25C 'folder':30C 'home':29C 'incompat':20C 'inde':8C 'left':58C 'ly':32C 'mozilla':2B 'mozilla-firefox':1B 'ok':5C 'old':16C 'player':23C 'pleas':35C 'plugin':49C,53C 'presum':19C 'problem':42C 'report':36C 'still':24C,40C 'ubuntu':4B
<lifeless> thumper: is monday a pub hoiday?
<thumper> lifeless: do you want it to be?
<lifeless> would be nice :P
<thumper> that it would
<thumper> I think if all NZers agree, then it should be
<thumper> we only have to convince mwhudson and pjdc
<thumper> :)
<lifeless> waitangi day is feb 6
<thumper> yes
<thumper> it is also the weekend
<mwhudson> sadly it is not a holiday
<poolie> wallyworld_, oh also https://bugs.launchpad.net/launchpad/+bug/711647
<_mup_> Bug #711647: link from branch page to merge proposals <code-review> <easy> <ui> <Launchpad itself:Confirmed> < https://launchpad.net/bugs/711647 >
<StevenK> lifeless: But you don't know what 'holiday' means?
<thumper> mwhudson: if enough of us agree it could be
<thumper> mwhudson: who'd tell them?
<thumper> them being people and culture :)
<mwhudson> http://www.stuff.co.nz/the-press/news/4593872/Labour-offers-to-Mondayise-public-holidays
<mwhudson> well, this is a fair point
<thumper> mwhudson: oh I know the current news
<lifeless> ah
<StevenK> wgrant: Thanks for the review. I'll fix all of the points.
<lifeless> unlike christmas its not moved
<lifeless> http://www.ers.dol.govt.nz/holidays_act_2003/dates/2010_13.html
<wgrant> StevenK: Not pushed yet, or is LP being stupid?
<stub> lifeless: LEFT JOIN is LEFT OUTER JOIN, unnecessary since all BugTasks have a corresponding Bug.
<wallyworld_> poolie: those links in the revision listing are to the merge proposal
<wallyworld_> but they render as the source branch name
<lifeless> stub: yes, I've been testing with inner joins, no impact
<poolie> ah, doh
<poolie> they're all 404 on qastaging so i didn't realize that
<poolie> what if there is no mp then?
<wallyworld_> i think the data on qastaging is way old
<poolie> to be precise, 500 not 404
<poolie> sure
<poolie> it doesn't have all branches
<poolie> wallyworld_, in some ways it's weird to have a link with just the branch name go to the mp
<poolie> it's inconsistent with almost everywhere else
<wallyworld_> if there's no mp, then nothing is shown, the idea being (for launchpad at least) that all merged must come as a result of a mp
<poolie> i agree it's the most useful link to have
<lifeless> there is bug with the librarian on [qa]staging
<lifeless> it doesn't have all the data
<lifeless> and doesn't forward to the main librarian consistently
<wallyworld_> the text you want to see is typically the branch, but the link goes through to the mp so you can see what was done etc
<wgrant> lifeless: It forwards consistently. Except restricted files, which it doesn't do at all.
<lifeless> right
<lifeless> so its inconsistent :P
<lifeless> fixable
<lifeless> just need tuits
<wgrant> Yeah.
<poolie> ah, actually https://code.qastaging.launchpad.net/~nmb/bzr/239523-quiet-tag/+merge/37555 is a timeout error
<poolie> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1859QS7
<poolie> wallyworld_, i do think there's a ui bug here somewhere
<poolie> perhaps it can be fixed as simply as just extending the link region to be
<poolie> over the wards 'merged branch' too
<poolie> maybe it doesn't matter
<wallyworld_> poolie: pooliethat oops link doesn't work for me
<wallyworld_> is it just the timeout?
<StevenK> wgrant: TypeError: 'GenericBranchCollection' object is not iterable :-(
<wallyworld_> not sure about including 'merged branch' in the link though
<wgrant> lifeless: Why always use the ID columns?
<wgrant> StevenK: Is there an obvious method to materialise it?
<wgrant> .getBranches()
<StevenK> wgrant: Oh, call .getBranches() on the collection?
<wgrant> StevenK: Yes.
<wgrant> StevenK: the collection can also be used to get MPs and stuff, so it's not directly iterable.
<poolie> wallyworld_, try the oops again now; there is some flakiness
<wallyworld_> poolie: that's just qastaging timing out as has been its want of late :-(
<poolie> sure
<wallyworld_> most times lately i've had to hit refresh several times for each new page i want to load
<wallyworld_> seems to have gotten worse
<poolie> just thought i'd mention it, seemed quite persitent
<StevenK> wgrant: Which makes my tests break :-(
<wallyworld_> poolie:  yeah, np.  quite frustrating
<StevenK> Oh, I know why
<StevenK> The objects from the store aren't security proxied
<wallyworld_> poolie: i'm told it the server for qastaging "only" has 32GB of memory or something like that
<StevenK> wallyworld_: The *db* server
<StevenK> And it's shared with staging
<wallyworld_> oh, yes. sorry. misremembered
<StevenK> wgrant: Your choices are: 1) Use removeSecurityProxy, 2) Go back to using IMasterStore. Which of those two bad opinions do you like?
<wgrant> StevenK: For what?
<wgrant> Oh.
<wgrant> Hm.
<wgrant> No, for what?
<StevenK> wgrant: _mergeBranches
<wgrant> Why?
<StevenK> wgrant: getUtility(IBranchCollection).ownedBy(from_person)
<StevenK> wgrant: That returns security-proxied objects, using the Store doesn't.
 * thumper EODs
<wgrant> StevenK: rSP is better.
<wgrant> More explicit.
<wallyworld_> thumper: that failed ec2 land (the smtp error) - i ran the test via ec2 keeping the console open and they all passed. so i'm stuffed if i know why 2 ec2 land attempts failed. should i just lp-land directly?
<lifeless> wgrant: avoids a few failure modes
<lifeless> wgrant: Reference == Reference -> BOOM (bug filed on storm)
<lifeless> wgrant: Reference == object -> late evaluation
<StevenK> lifeless: I've stopped doing that anyway, based on wgrant's suggestions.
<lifeless> StevenK: sure; I'm documenting why the suggestion per wgrant's query
<lifeless> http://techcrunch.com/2011/02/01/bing-google-fight/ is hilarious
<StevenK> wgrant: Changes pushed, diff updated
<wgrant> lifeless: Could you please mentor that?
<lifeless> sure
<wgrant> StevenK: I am quite a fan of your _mergeBranches reduction.
<StevenK> I know, it's awesome!
<StevenK> Picking apart direct SQL, one cur at a time?
<StevenK> wgrant: I can drop the cur argument from _mergeBranches and _mergeSPRecipes; or you don't care?
<wgrant> StevenK: Missed that. Please do.
<lifeless> oh
<lifeless> hang on
<lifeless> why are you changing from using UPDATE?
<lifeless> doing this in python is a sure fire way to make it crawl to a halt
<wgrant> It already iterated over all branches.
<lifeless> wgrant: that sfine
<wgrant> Ah, because we're now getting the actual branch objects, where we weren't before?
<lifeless> no
<lifeless> because we're issueing one update per branch
<lifeless> rather than one update.
<wgrant> We always were.
 * lifeless rereads
<wgrant> I had to read it a couple of times, yeah.
<wgrant> It looks like it uses SQL to batch it.
<wgrant> But no.
<wgrant> It just uses it to be awkward.
<lifeless> reviewed
<lifeless> I think it needs  alittle more work, sorry.
<StevenK> lifeless: nr is naked recipe
<lifeless> poolie: do you have permission to set bugs to 'triaged' ?
<lifeless> poolie: if not, I'd like to get you such permission so you can do triage :)
<wgrant> rSP is inevitable in this sort of code.
<lifeless> (in bugs about launchpad itself)
<lifeless> StevenK: nr is very much a wtf variable name.
<lifeless> StevenK: pep 8 says it would be n_r at minimum
<StevenK> lifeless: How is possible that the merge operation would ever be permissible? You're effectively forcibly changing the owner out from under the current owner
<StevenK> And ew, I like n_r even less
<lifeless> StevenK: then perhaps naked_recipe :)
<lifeless> letters are free
<StevenK> I was trying to avoid that
<wgrant> StevenK: I think we are tainted by Soyuz, where acronyms are inevitable.
<lifeless> no charge
<lifeless> StevenK: the person delete is the last step to occur, permission checks should pass trivially.
<StevenK> They don't
<StevenK> lifeless: And I can't think of a way to do a mass update -- how does that handle name conflicts?
<StevenK> Aside from bailing :-)
<wgrant> How should they pass trivially?
<wgrant> We are stealing someone else's objects.
<lifeless> one thing at a time
<lifeless> wgrant: we should be running in the context of the user handing the objects over
<wgrant> lifeless: Heh.
<StevenK> And they still don't have permission to edit someone elses objects?
<lifeless> StevenK: they don't need it? they edit their own object to be acceptable, then hand it over.
<wgrant> They shouldn't be able to do that.
<wgrant> They can, but it's a bug.
<StevenK> Actually, merge code is called from the person *recieving* the objects
<StevenK> It's *merge* *into*
<lifeless> so, if thats the case, we will need rsp, but its a *bug* that we need it.
<wgrant> You can't reassign a recipe to someone else, only one of your teams.
<lifeless> wgrant: I would solve this by establishing a temporary team binding the two accounts together, both in admin roles
<wgrant> Perhaps merge needs to adopt both security contexts.
<lifeless> right
<poolie> lifeless, i have permission to triage bugs in lp
<wgrant> But that sounds somewhere between difficult and OMGZOPEKILLMENOW
<lifeless> wgrant: StevenK: rsp will be ok, but please add #fuglywhy notes where it is used.
<poolie> i thought i triaged the ones i filed now
<poolie> i might have missed on
<lifeless> poolie: you marked them confirmed
<lifeless> poolie: rather than triaged
<lifeless> poolie: (or at least one of them)
<poolie> just a slip
<lifeless> no worries
<StevenK> lifeless: rSP comment added, smaller comment addressed.
<StevenK> lifeless: The two three line comments make sense to me, and obviously made sense to wgrant
<lifeless> so the from person has a recipe with the same name as the to person
<lifeless> type(left) == recipe
<lifeless> type(right) == person
<StevenK> Right
<lifeless> which is bogus
<StevenK> How is it bogus?
<StevenK> Users are free to name recipes whatever they want
<lifeless> but the name of the person doesn't matter, does it ?
<StevenK> No, the name of the recipe is utterly seperate
<StevenK> Just like the name of a branch
<lifeless> Right, but the comment talks about the name of the *to person*
<lifeless> I think we can rephrase it to avoid that :)
<StevenK> if the from person has a recipe with
<StevenK>         # the same name as the to person,
<StevenK> I thought the 'has' would encompass both?
<StevenK> That was the intent
 * poolie wonders if it would be faster to write a non-email client than to get through all jelmer's bugspam :/
<lifeless> Perhaps this:
<lifeless> If both the from and to people have recipes with the same name, merging renames the duplicate from the from person's side.
<wgrant> I thought the new policy was not to nitpick this sort of thing? I am happy to, but I thought we'd decided to avoid it.
<lifeless> wgrant: its to only deal with things that cause confusion
<lifeless> wgrant: I read it and my brain exploded
<StevenK> Mission accomplished
<StevenK> When Sarah asks me what I did at work today, I can tell her I made lifeless' brain explode.
<lifeless> wgrant: when its a 'you say tomato' problem, theres no real benefit in trying to make everyone happy; when its unclear or wrong, it will cause wtfs on reading.
<lifeless> wgrant: I've not been arguing for permissive, I've been arguing for functional.
<wgrant> lifeless: Sure.
<wgrant> I will do so in future.
<lifeless> StevenK: so the problem (for me) with what you wrote was 'same (name as the to person)' - changing that to 'same name (as a recipe of the to person)' [() for clarity] would avoid the brain boom
<lifeless> StevenK: that said, what do you think of my total rephrase?
<lifeless> 18:30 < lifeless> If both the from and to people have recipes with the same name, merging renames the duplicate from the from person's side.
<StevenK> lifeless: I liked it, so I've used it
<lifeless> cool
<StevenK> lifeless: Changes pushed.
<lifeless> StevenK: +    def test_merge_moves_branches(self):
<lifeless> 121	+        # When person/teams are merged, branches owned by the from person
<lifeless> 122	+        # are copied.
<lifeless> StevenK: and similarly in test_merge_moves_recipes
<lifeless> StevenK: is it copy, or merge.
<lifeless> I mentioned this in my review
<lifeless> as it stands, noone can determine your intent
<StevenK> The diff hasn't updated
<lifeless> oh
<lifeless> fooey
<StevenK> lifeless: *Now* it has updated.
<StevenK> lifeless: :-(
<StevenK> lifeless: I'd hope the WTFPM is zero
<lifeless> StevenK: can't be, we haven't solved the root cause
<lifeless> (security context craziness)
<StevenK> rm -rf zope
* StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<lifeless> stub: would nuking the nametargetcache and instead searching on the targets (20K vs 400K) help ?
<stub> We used to do that IIRC... and targetnamecache was the 'solution'
<lifeless> solutions are often moving targets ;)
<lifeless> or really stopgaps (like prejoin)
<lifeless> and sometimes genuine problems themselves ;)
<stub> targetnamecache contains quite a bit - I'd have to check the script to see all the sources.
<stub> So minimal impact would be working out trigrams and making the substring search fast. Next option would be turning off substring search (changing search behavior, but not sure how many people will notice). Next option dropping targetnamecache and doing substring search (or trigram) on pillarname.name (searching on less information, but people want fewer bugs rather than more don't they? :) )
<stub> I'd go for dropping the ILIKE personally, but then I don't generally hear the screams of annoyance from our users ;)
<stub> Leaving dropping targetnamecache altogether for our Search Solutionâ¢
<lifeless> I'll mail ubuntu-devel about that
<stub> The answer will be 'noooo', but most of that will be because people won't know things will work without it or know if they are making use right now.
<stub> Perhaps drop the ILIKE if a feature flag is set so we can point people at the faster but more limited version?
<lifeless> mailed
<lifeless> stub: that would be a good way to experiment
<LPCIBot> Project devel build (409): STILL FAILING in 6 hr 33 min: https://hudson.wedontsleep.org/job/devel/409/
<wgrant> Can I knock windmill out of the test suite again? Plllllease?
<wgrant> Is there more to making a custom egg than hacking the version in setup.py and running sdist?
<lifeless> shouldn't be
<lifeless> check __version__ matches
<wgrant> Sigh.
<lifeless> wgrant: so
<lifeless> rev 12290
<lifeless> is it qa bad?
<wgrant> lifeless: I marked it as such a couple of minutes back.
<lifeless> kk
<lifeless> was just eyeballing deployment-stable
<lifeless> I might get 12289 deployed
<lifeless> BugMessage.index ftw
<wgrant> I still have a 12293 deployment request sitting in a text editor.
<wgrant> You might want to grab its bug numbers, unless you want to reharvest them yourself.
<lifeless> oh foo, can only doo 12276
<wgrant> Oh, right, yes.
<lifeless> 90 being fixed would let 93 be goodd
<lifeless> I'll add the security.py to unusual rollout nodes
<lifeless> wgrant: fyi I've qa'd all the other revs
<adeuring> good morning
<allenap> Morning adeuring :)
<adeuring> hi allenap!
<wgrant> OMG
<wgrant> lucid_db_lp passed!
<mrevell> Hello
<jtv> hi mrevell!
<mrevell> Hey there jtv
<wgrant> Uh.
<wgrant> Massive devel failure.
<bigjools> helleau
<lifeless> wgrant: ?
<wgrant> lifeless: r12302 (the SQL parameter logging thing) appears to be spectacularly broken.
<wgrant> buildbot should fail shortly.
<wgrant> Hmm, maybe not. It says <1 min left, but it's only done a couple of thousand tests (with 80ish failures).
<lifeless> wallyworld: you did ec2 land that, right ?
<wgrant> I guess I won't throw that openid thing at ec2 just yet.
* jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: jtv | https://code.launchpad.net/launchpad-project/+activereviews
<wgrant> lifeless: Should we roll that back?
<wgrant> It's not obvious what exactly is wrong, so fixing it sounds less trivial than I would hope.
<lifeless> where are you seeing the fail ?
<wgrant> lifeless: lucid_lp
<wgrant> https://lpbuildbot.canonical.com/builders/lucid_lp/builds/581/steps/shell_6/logs/summary
<lifeless> let me wait for openid....ok
<lifeless> yeah thats borked
<lifeless> rollback
<wgrant> k
<lifeless> wallyworld: we're rolling it back, its naffed.
<wgrant> It's a couple back in the queue now.
 * wgrant wanders off for a while.
 * bigjools waits before ec2 landing stuff then
<lifeless> allenap: hi
<lifeless> actually, nvm.
<allenap> lifeless: Hi anyway :)
<lifeless> hi :)
<lifeless> <- slightly batty today
<lifeless> night all
<bigjools> wgrant: are you working on the remaining log parser errors?  (or is it a pending-landing fix you already did?)
<wgrant> bigjools: Pending deployment.
<wgrant> I believe they're all fixed.
<bigjools> awesome
<bigjools> now, where has my daily soyuz report gone....
<wgrant> mpt wants to make our database explode :(
<bigjools> :)
<bigjools> it would be a great change
<wgrant> It would.
<wgrant> I've wanted it for a while. But it's going to be a biggish table.
<bigjools> resorting to dpkg -S sucks
<bigjools> yeah, will need some interesting fti work
<bigjools> oh man I can't wait for this debversion column to come in
<bigjools> it's going to speed up so much stuff
<wgrant> We can hope.
<bigjools> no hoping, I know!
<bigjools> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1858B2816
<bigjools> look at the top query
<bigjools> 2nd one makes me cry but for entirely different reasons
<wgrant> It still needs cross-table indices to be not slow.
<wgrant> This will make it less slow.
<wgrant> But it will still be slow.
<bigjools> debversion_sort_key is 90%+ of the time
<wgrant> Hmm.
<wgrant> It would still be nice to have indices :)
<wgrant> Come on PQM, unbreak devel faster.
<bigjools> yeah, they'll come in time but one thing at a time
<wallyworld> lifeless: wgrant: i ec2 tested it and it all passed, 12000+ tests
<wallyworld> i have the email to prove it :-)
<bigjools> stub: so where are we at with the debversion stuff?
<wgrant> wallyworld: Huh.
<wallyworld> wgrant: the branch that's being rolled back - the sql logging one
<wallyworld> just got back to my computer and saw some chatter about issues with that branch
<wallyworld> wgrant: how did it show up as borked? given all ec2 tests passed i'd like to know what happened
<stub> bigjools: If you merged back my branch, ready to land as far as I'm aware - apart maybe from getting launchpad-database-dependencies installed on various boxes. But I suspect we don't want it this cycle as we won't have enough time for testing.
<bigjools> stub: it's been on dogfood for a week, I'm happy with it
<bigjools> I'll chat to lifeless and see what he thinks
<stub> Then I guess its full steam ahead from my pov.
<wgrant> wallyworld: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/581/steps/shell_6/logs/summary
<bigjools> stub: ok cool, I'll land it
<wgrant> wallyworld: The change looks reasonable, too :/
<bigjools> well when I've talked to rob
<lifeless> bigjools: you're in luck, I was just about to really turn in
<wgrant> wallyworld: But I can reproduce it locally
<bigjools> lifeless: woohoo
<wgrant> wallyworld: nascentupload.txt is the one I just tried.
<stub> Shouldn't be an hour to apply either - 20-30 mins.
<wallyworld> wgrant: thanks, i'll take a look. i also want to find out how my ec2 test run passed everything
<wgrant> wallyworld: Could you forward the email?
<lifeless> bigjools: so be quick :)
<lifeless> bigjools: whats up?
<bigjools> stub: right, 2* what staging took minus fudge factor is what I though
<bigjools> t
<bigjools> lifeless: I want to land the debversion change
<bigjools> lifeless: and wondered what your thoughts are
<lifeless> bigjools: What day is the releasE?
<lifeless> db deploy
<lifeless> thingy
<wallyworld> wgrant: when i tried to ec2 land it, i got an email complaining an smtp attachment was too big, so i did an ec2 test run instead with the console held open to see if any failures would show up and everything passed
<bigjools> uhrm
<bigjools> next week
<lifeless> yeah, thursday I think
<lifeless> so
<lifeless> if it:
<lifeless>  - passes tests
<wallyworld> lifeless: 9th feb
<bigjools> it's been on dogfood for a week and seems fine
<bigjools> I've hammered various bits with it
<lifeless>  - is measurably faster in the case we're working on
<wallyworld> wednesday utc
<lifeless>  - and has stubs blessing
<lifeless> then I think we're in decent shape to do it
<bigjools> schweet
<bigjools> lifeless: I'm just worried about package dependencies
<lifeless> bigjools: I think you nede to build a new AMI
<lifeless> or something
<lifeless> for buildbot
<bigjools> lifeless: that's fucking insane :/
<lifeless> bigjools: AIUI it doesn't auto upgrade its package
<wgrant> wallyworld: Oh, it was that branch?
<wgrant> wallyworld: Hmm.
<bigjools> lifeless: we need to fix that
<wallyworld> wgrant: just look at the email now - i want to check something first
<wallyworld> s/look/looking
<lifeless> bigjools: we're nuking buildbot
<bigjools> lifeless: I suppose I need to fix buildbot as well?
<lifeless> bigjools: that will go a long way :)
 * bigjools hunts for desctructions
<lifeless> bigjools: the losas have installed the dependency on all db machines; worth checking with mthaddon about whether he updated bb instances too
<bigjools> ok thanks lifeless, go to bed now
<lifeless> wallyworld: whats this thing about mpt ?
<wgrant> wallyworld: It is rather disturbing, although not at all unbelievable, that ec2 has some horrible bug here.
<wallyworld> lifeless: what does mpt mean?
<lifeless> wallyworld: matthew paul thomas
<mpt> Many people have asked that question
<bigjools> wgrant: or we have different packages installed ....
<wallyworld> wgrant: i'd blame me before ec2. i had to have dome something wrong i'd say
<wgrant> lifeless: I think you meant me.
<lifeless> i did
<wallyworld> lifeless: why you asking? now sure what you mean?
<lifeless> darn
<lifeless> wgrant: whats this thing ..
<wgrant> lifeless: mpt (hi mpt) wants to put Contents in the DB.
<wgrant> A good idea.
<wgrant> But slightly scary.
<lifeless> wgrant: thats the binary file mapping ?
<bigjools> we eat scary for breakfast in soyuz
<mpt> wgrant, is it a problem that I don't know what you're talking about? :-)
<lifeless> wgrant: its only a few GB for all uploads ever to Ubuntu
<lifeless> wgrant: I've  readyt made schema with fast queries we can use in the conflictchecker.
<wgrant> lifeless: Yes.
<lifeless> bigjools: ok, you're unblocked?
<wgrant> But it's still quite a few rows.
<lifeless> wgrant: 4M or something small like that
<wgrant> lifeless: +ppa
<bigjools> lifeless: yarp, thanks
<lifeless> wgrant: files are pretty much statick
<lifeless> wgrant: the join table is rather larger, but it has excellent selectivity
<wgrant> True.
<lifeless> wgrant: is there a LEP ?
<wgrant> No.
<lifeless> so, lets have one
 * wgrant throws the codebrowse fix at ec2.
<lifeless> we'll want use cases for schema design, the cases conflictchecker does may not match.
<lifeless> sayonara
<wgrant> Night.
<bigjools> night
<lifeless> oh
<lifeless> one more thing
<wgrant> Hmm.
<lifeless> mpt: how do you feel about 'to use new features you must have javascript' being a default position for LP development ?
<wgrant> Do I want to land this with rollback=?
<lifeless> wgrant: yes, that tells qatagger where the bad-commit is fixed
<lifeless> wgrant: also I think you haven't tagged it bad-commit yet
<lifeless> mpt: food for thought, ciao
<wgrant> I only worked out what bad-commit-* does this morning.
<mpt> lifeless, I don't know how many current or potential users use script-less browsers for accessibility reasons, or are in corporate environments which disallow untrusted JavaScript
<mpt> That's probably a research job for mrevell
<wgrant> wallyworld: that's a bit special. The email body gives the right branch's revno, but the subunit log shows that the branch was not merged; the tests were run against devel itself.
<wallyworld> hmmm.
<wallyworld> wonder why i couldn't see the doc test in the logs?
<wgrant> wallyworld: Try looking for nascentupload_txt instead.
<wgrant> I'll look in a sec.
<wallyworld> wgrant:  pretty sure i tried that but i am tired
<wgrant> But natty's X stack is in league with ec2test; my kernel hung moments after I accused ec2 of being buggy.
<wallyworld> wgrant: it was there.  cme can't type
<wallyworld> wgrant: just looks like i managed to get it to run the tests against devel even though it thought it was using my branch
<wgrant> Heh
<wgrant> Yes.
<wgrant> That is slightly odd.
<wallyworld> wgrant: reason i did that in the first place was that when i did an ec2 land, it tried to email me the results and complained about the attachment being too big
<jml> ?
<wallyworld> so i thought i run the tests manually
<jml> 300k attachments are blocked for you?
<wallyworld> jml: not sure, never had an issue before
<wallyworld> i'm sure i've had larger attachments than that
<wallyworld> even with ec2 landings which ended up having lots of errors
<jml> wallyworld: interesting. I think uncompressed the maximum output under 3MB. I guess if the test run crashes somehow you might get an attachment that big.
<wallyworld> yeah guess so.
<jml> anyway, I'd better get coffee & so forth.
<wallyworld> now i need to figure out how i tricked ec2 to give me misleading info :-)
<danilos> jtv, hi Jeroen, I'd love to get a review from you :)
<jtv> danilos: oh, didn't see that on the system yesterdayâ¦
<danilos> jtv, I am sure you didn't :)
<danilos> jtv, https://code.launchpad.net/~danilo/launchpad/lifecycle-subscription/+merge/48185
<jtv> danilos: I'll have to do it after lunch.
<danilos> jtv, sorry, I think lunch is bad for you, so please do it now :)
<danilos> jtv, anyway, sure, but if you think you'll take long, I might find a different reviewer
<jtv-eat> There's a conflict by the way.
<jtv-eat> I have to go get some stuff, so a different reviewer may be better.  Unlucky timing.
<danilos> jtv-eat, indeed, thanks :)
<danilos> jtv-eat, oh, btw, I am also OCR today :)
<danilos> forgot about that ;)
<danilos> gmb: hi, how do you feel taking a review of my LIFECYCLE change?
<gmb> danilos: Well, I'm about to grab lunch, but once I've eaten I'll take a look.
<danilos> heh, everybody runs for lunch when I ask for a review :)
<danilos> gmb: sure thing, if jtv doesn't get to it first :)
<gmb> Reviewing your code is obviously only possible after a significant intake of calories.
<gmb> danilos: Okay, cool.
 * gmb -> lunch
* danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: jtv, danilos | https://code.launchpad.net/launchpad-project/+activereviews
<danilos> allenap, hi, I am taking a look at your https://code.launchpad.net/~allenap/launchpad/subscribe-to-tag-bug-151129-6/+merge/48295
<danilos> allenap, can you tell me more about it? (it kind of scares me as well, since we are touching roughly the same stuff :)
<allenap> danilos: I have to give my kids some food now. Can we talk in about 1h?
<allenap> But sure, let's talk about it :)
<danilos> allenap, sure, I'll try to review it in that time
<danilos> allenap, perhaps coming up with more questions :)
<allenap> danilos: Cool :)
<deryck> Morning, all.
<gmb> jtv-eat: I'm going to assume that you've not yet got to danilos's branch, so I'm going to grab it.
<danilos> gmb: woohoo, thanks :)
<gmb> :) np
<allenap> danilos: Thanks for the review... I think you've uncovered a bug or two :) I'll reply now.
<jtv> gmb: and since you've done that, it is now safe for me to return and find your message.  :)
<gmb> :)
<jtv> (Seriously, just got backâwasn't sitting here waiting âº )
<LPCIBot> Project devel build (410): STILL FAILING in 5 hr 56 min: https://hudson.wedontsleep.org/job/devel/410/
<LPCIBot> * Launchpad Patch Queue Manager: [r=abentley][ui=none][bug=702024] Expose a status page for haproxy on
<LPCIBot> codehosting.
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][no-qa] Include sql bind variables in the oops
<LPCIBot> sql statements.
<LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=435779] Changed "Get Started" text to make
<LPCIBot> it a little more engaging (bug #435779). Also changed the
<LPCIBot> sandbox link to point to http://quastaging.launchpad.net
<LPCIBot> instead of http://staging.launchpad.net.
<_mup_> Bug #435779: "Get started" text anti-climactic <lp-web> <post-3-ui-cleanup> <qa-needstesting> <Launchpad itself:Fix Committed by huwshimi> < https://launchpad.net/bugs/435779 >
<LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=181368] CommandSpawner.
<gary_poster> stub, thank you for the personsettings code!  Am I right that to get that landable I'll need to get new sampledata, or will that not really be necessary because it is a new table?  Also, I assume that your intent is that, for now, we don't remove verbose_bugnotifications from Person because that would make the ISD replication code more annoying?  So, we change the Person class to use personsettings for that flag,
<gary_poster> worry about removing it from the Person table till later
<gary_poster> truncated, I'm guessing
<gary_poster> So, we change the Person class to use personsettings for that flag, but don't worry about removing it from the Person table till later
<jtv> bigjools: parallel runs of apt-ftparchive seem to be passing all existing tests, plus what new ones I could come up with.  Now how do I see whether it's _really_ producing exactly the expected results?
<jtv> I'm tempted to say I don't have enough of a "feel" for soyuz test coverage, butâ¦
<jtv> danilos: sorry about the reviewâI later realized you meant MP, not HRA, in your initial question.
<jtv> Or as it's also known: "oh dear Kibo no, what do I need to countersign now?"
<danilos> jtv, heh, no worries
<bigjools> jtv: we run it on dogfood after uploading a package and make sure that we see the expected changes in the Packages file
<jtv> bigjools: neither of my branches has hit db-devel yet, alas.  But it'd be really good to eyeball the changes _before_ I go into review.
<jtv> Maybe I should ask wgrant to have a look.
<bigjools> jtv: I can merge your branch into DF
<bigjools> I can look too
<jtv> bigjools: but you need at least db-devel for that, right?
<bigjools> no, I can merge devel branches
<jtv> oh great!  In that case, it's lp:~jtv/launchpad/bug-181368-parallelize
 * bigjools mergerates
 * jtv cheers the mergerati
<jtv> bigjools: meanwhile, want me to take on those loggerhead oopses?
<jtv> bug 701329
<_mup_> Bug #701329: loggerhead OOPS - error: [Errno 32] Broken pipe <oops> <Launchpad itself:Triaged> <loggerhead:Invalid> < https://launchpad.net/bugs/701329 >
<bigjools> jtv: I think someone analysed it already, have a look
<stub> gary_poster: Yes, it needs new sample data generated. I forgot to remove the old Person.verbose_bugnotifications in the db patch and twiddle the trigger to do the right thing. hang on.
<gary_poster> oh, k, thanks stub
<stub> gary_poster: Or since you wanted this landed soon...
<stub> I guess we do need to keep the old column around until the code is updated?
<gary_poster> yeah
<gary_poster> I could do that today
<jtv> bigjools: alternatively, I could work on the patch to drop BranchRevision.id.
<stub> gary_poster: Can you put in a code update so when Person.verbose_bugnotifications is set, PersonSettings.verbose_bugnotifications is also set? Or do I need to do that in a trigger?
<bigjools> jtv: see if you can do a simple fix for loggerhead, I reckon it was just a case of swallowing the pipe error, so to speak
<allenap> danilos: I've replied to your review. Let me know if you want to talk about BugSubscriptionInfo in general. I'm keen on promoting the idea (the implementation is okay, but I'm less concerned about that).
<danilos> allenap, sure, otp now, so back to you in 10
<jtv> bigjools: looking into it.  Lots of stuff that's not familiar but I see that as a good thing.
<bigjools> jtv: indeed
<gary_poster> stub, on call now, off call in 5
<leonardr> jtv, danilos, i'd like a review of https://code.launchpad.net/~leonardr/lazr.restful/example-service-has-web-link/+merge/48313
<leonardr> i can walk you through it if you have any questions
<jtv> leonardr: I'll take it
<gary_poster> stub, back.  If I put in that code, why don't I just change the code to look at personsettings instead?
<gary_poster> Then we won't care about verbose_bugnotifications
<stub> gary_poster: Sure. I suspect it will be minor.
<gary_poster> Exactly
<gary_poster> OK, stub, I'll work from your existing branch.  I assume your EoD is very soon.  Is this a plan?
<gary_poster> - You make the change to "remove the old Person.verbose_bugnotifications in the db patch and twiddle the trigger to do the right thing".  Tell me when you are done with that, and I'll merge it into my branch, and MP it only asking for a db review initially.
<jtv> leonardr: wasn't web_link something that came up in feeds?
<leonardr> gary, i think we were going to do some work on lazr.restfulclient's bootstrap code and it got dropped on the floor
<gary_poster> - I'll work on the other code.  I might be done when you are; if not, no problem, because you will have already approved the db parts, and I can get another reviewer to do the small code bits, and then land it
<leonardr> jtv: can you be more specific?
<leonardr> it might be a different feature with the same name
<gary_poster> (stub: end)
<leonardr> or it might be a client that woudl benefit from the feature
<jtv> leonardr: I'm asking what web_link is, and I think I came across the term in the context of feeds recently.
<danilos> allenap, all good, r=me
<gary_poster> leonardr: yeah, that rings a vague bell.  I know lazr.restful couldn't make the update because zc.recipe.cmmi did not have a new version
<allenap> danilos: Thanks :)
<gary_poster> but restfulclient probably can
<leonardr> jtv: i think it's another feature with the same name
<leonardr> to give you an example,
<leonardr> the web_link of https://api.launchpad.net/devel/~leonardr is https://launchpad.net/~leonardr
<leonardr> does that make sense?
<leonardr> it's the same object but on the website rather than the web service
<jtv> ah
<danilos> allenap, also, the branch itself seems to only be a relatively straightforward refactoring, so it didn't raise any concerns for me :)
<stub> gary_poster: Yup. I'm finalizing the db stuff now.
<allenap> danilos: Tip top.
<gary_poster> awesome thanks stub
<jtv> leonardr: thanks, that helps.  Different question: interested in the reason for moving your adapter registration from code to zcml.
<leonardr> jtv: i didn't move it, those are new registrations
<jtv> ah
<leonardr> i can try to put them in code
<jtv> No particular need (apart from I Hate ZCML), just asking.
<leonardr> i didn't do them in code in the first place because the classes they register are not all defined within the example web servie
<jtv> We need a structural improvement for that stuff, not two tags less.  :-)
<leonardr> and i wanted all the definitions in one place
<danilos> allenap, generally, I think add_bug_change_notifications should make better use of BugSubscriptionInfo instead of calling methods on the bug directly, but that'd be a long discussion that we wouldn't be doing anything on right now, so let's not have it :)
<jtv> leonardr: thanks for explaining.
<allenap> danilos: My plan at first was to make all of the subscription methods on Bug shells around BugSubscriptionInfo. Then it's easy to change call-sites.
<allenap> Or easier at least.
<danilos> allenap, agreed
<leonardr> gary: depending on how much time you have, can you help me upgrade restfulclient or remind me what i need to do? i remember trying to just copy in bootstrap.py from launchpadlib
<jtv> leonardr: in lines 62â63 of the diff, why the zope.interface.Interface in the "for" attribute that also has lazr.restful.interfaces.IWebBrowserOriginatingRequest?
<gary_poster> leonardr: afternoon?
<leonardr> jtv: it's a multi-adapter of a model object + a request
<leonardr> i can try to make it a little more specific
<jtv> If there is a fitting interface, that'd be nice.
<leonardr> gary: earlier would be better, but i'll take what i can get
<jtv> If there isn't, probably not worth it though maybe a comment would be nice.
<gary_poster> leonardr: understood.  I'll ping earlier if I can
<leonardr> jtv: i can use ILocation, but that's not really "more specific"
<leonardr> it just happens to be the base interface of all these interfaces
<jtv> leonardr: the name seems slightly more specific to me thoughâ¦ would it be an appropriate choice?
<leonardr> i'll go ahead and do it. i'm a little worried it might be misleading
<allenap> bigjools: Have you got a branch to add your AWS ID to VALID_AMI_OWNERS?
<bigjools> allenap: yes
<allenap> bigjools: Okay, I'll shut up.
<allenap> :)
<jtv> leonardr: at the risk of revealing my stupidity: might IHasLocation be appropriate?
<leonardr> jtv: checking...
<bigjools> allenap: just sent it to the gatekeeper...
<leonardr> jtv: i believe IHasLocation is a launchpad interface, so i can't use it
<jtv> ah, yes it probably isâ¦
<leonardr> i could define something similar but it would only exist to make that bit of zcml more readable
<jtv> Not worth that then.
<jtv> leonardr: moving right along, I read the name WebBrowserOriginatingRequest as meaning that the request either originated with a browser or originates a browser.  I can't make sense of the latter, and isn't the former the opposite of what it is?
<jtv> Hmm I'm not being very clear myself.
<leonardr> jtv: i understand what you're saying
<leonardr> *as far as lazr.restful is concerned*, that request originated with a browser
<jtv> I mean: isn't WebBrowserOriginatingRequest an adapter for requests that _didn't_ originate as a normal web browser request?
<jtv> Ah.
<stub> gary_poster: I think that is all done
<leonardr> it turns requests that didn't come from a browser into requests that "did"
<gary_poster> stub, awesome, thank you.  I'll merge and push up to a new branch for a db review then?
<jtv> leonardr: but instances of its base class (probably) really did originate from a browser, right?
<leonardr> jtv: in launchpad, yes
<leonardr> you'd only do this if you were also handling real web browser requests
<stub> bah... still pushing
<stub> done
<gary_poster> :-) k
<jtv> leonardr: what I'm then wondering is: is "web-browser-originating" a good characterization of how this class differs from its base class?
<leonardr> jtv: how about calling it SimulatedWebsiteRequest?
<jtv> leonardr: that would be crystal clear to me, and match the description.  I like it.
<jtv> Thanks also for cleaning up those old-style import lines, by the way.
<jtv> leonardr: you have my vote.
<leonardr> jtv: thanks
<jtv> np
<leonardr> gary, i've upgraded bootstrap.py. buildout.cfg looks like it was already changed. when i run bin/py i get the right code, but when i run bin/test it runs the wrong tests
<bigjools> jtv: looks like you already did the parallisation unless I am misreading the diff?
<jtv> bigjools: yup
<bigjools> jtv: and it's landed?
<jtv> Nope
<gary_poster> leonardr: be with you as soon as I can
<bigjools> heh ok
<bigjools> just about to test it
<leonardr> gary: np, just writing it down so it doesn't get lost
<gary_poster> cool
<jtv> bigjools: the landed version uses the CommandSpawner (a.k.a. MF) but still only runs one big process.
<bigjools> jtv: I should probably be QAing that then, but later
<jtv> bigjools: I was hoping to learn whether it's really still producing the right files.
<jtv> It just runs separate apt-ftpserver instances all with a different --arch argument.
<jtv> I _think_ that generates separate files without clashing, but it'd be nice to be sure. :)
<jtv> (Note that "source" is an architecture for this purpose)
<gary_poster> stub: https://code.launchpad.net/~gary/launchpad/bug548-db-2/+merge/48318
<bigjools> allenap: how does one delete ami images?
<allenap> bigjools: I used to know... let me try and figure it out again.
<bigjools> allenap: when you do so can you update https://dev.launchpad.net/EC2Test/Image :)
<allenap> bigjools: http://pastebin.ubuntu.com/561412/ -- and okay.
<gary_poster> I use that in-browser console thingy
<gary_poster> Amazon provides
<bigjools> ahhh
<gary_poster> yeah, what Gavin said
<bigjools> shame theres no way of letting the scripts delete old ones
<bigjools> we probably only need to keep the last 3
<bigjools> "Unintrusize" - wth? :)
<jtv> jam, got time to discuss bug 701329?
<_mup_> Bug #701329: loggerhead OOPS - error: [Errno 32] Broken pipe <oops> <Launchpad itself:Triaged> <loggerhead:Invalid> < https://launchpad.net/bugs/701329 >
<bigjools> abentley: your fix for recipe build mail landed on the 27th is breaking scripts
<bigjools> they now need access to sourcepackagerecipebuild and are blowing up where they don't have it
<abentley> bigjools, I added permissions to the script that failed tests because it needed it.  Which scripts are failing?
<bigjools> scripts/ftpmaster/queue so fart
<bigjools> so far, even :)
<bigjools> I suspect the test is crap
<gary_poster> stub: I changed my code to actually work :-P (using lazr.delegates now too) and ran a test.  I got this: https://pastebin.canonical.com/42725/
<gary_poster> That looks like something I might need your help with...or someone else with experience in those permissions
<abentley> bigjools, doesn't that use the "queued" user?  I added sourcepackagerecipebuild = SELECT to that user.
<bigjools> abentley: yeah that's right - this might be my bad then, one sec
<stub> gary_poster: That just needs some tweaking in security.cfg
<gary_poster> stub, I'm trying adding INSERT
<gary_poster> to the table
<gary_poster> in security.cfg
<stub> Shouldn't need insert given the table is populated by a trigger...
<gary_poster> yeah, that didn't help
<stub> I don't have enough traceback to deduce further
<gary_poster> any other suggestions?  ok one sec
<stub> You need to make schema once you twiddle security.cfg of course
<gary_poster> yeah, I did.  Here's the fuller context: https://pastebin.canonical.com/42727/
<stub> gary_poster: So the user that script connects as needs permissions
<gary_poster> oh!
<danilos> allenap, deryck: hi, anyone has some spare minutes to pre-imp discuss bug 548? :)
<_mup_> Bug #548: Launchpad sends change notification updates to the person who requested the change <email> <lp-bugs> <story-better-bug-notification> <story-better-notification-sending> <Launchpad itself:In Progress by yellow> < https://launchpad.net/bugs/548 >
<allenap> danilos: In a few minutes?
<danilos> allenap, sure thing
<deryck> danilos, I'm jumping on another call now.  but I see allenap has you :-)
<danilos> deryck, yeah, go on jumping about, thanks :)
<bigjools> abentley: indeed it was my bad, apologies
<flacoste> jml: mumble?
<abentley> bigjools, no problem.
 * bigjools needs to remember to run security.py
<jml> flacoste: yep
<gary_poster> OK, stub, I got that working.  I do have two test failures though, which increased a concern I was already wondering about.  The problem is that stuff like this fails
<gary_poster>     >>> concise_team = factory.makeTeam(
<gary_poster>     ...     name='conciseteam', displayname='Concise Team')
<gary_poster>     >>> concise_team.verbose_bugnotifications = False
<gary_poster> because the trigger fires at transaction commit, I assume
<gary_poster> so the settings is not around yet. Should I just change the Python code to make a PythonSettings object if needed?
<gary_poster> (Will that upset the trigger?)
<gary_poster> (Or does that mean we should forgo the trigger entirely in favor of some Person.__init__ code?
<gary_poster> )
 * danilos has learned to hate triggers implementing any application logic in translations ;)
<gary_poster> :-)
<allenap> danilos: Mumble or Skype?
<danilos> allenap, "yes" :) mumble
 * danilos tries to find allenap's colour
<abentley> allenap, I'm looking at the test you wrote for mrevell, and surprised to see monkey-patching.  Why not just use pop_notifications like we do in so many other tests?  Here's how I'd change it: http://pastebin.ubuntu.com/561431/
<allenap> danilos: Bug 711910.
<_mup_> Bug #711910: Move remaining subscription methods from Bug to sets on BugSubscriptionInfo <Launchpad itself:Triaged> < https://launchpad.net/bugs/711910 >
<stub> gary_poster: The trigger fires when completing the statement. The problem will be that Storm might not notice?
<gary_poster> oh! :-/
<stub> gary_poster: or the trigger hasn't fired because Storm hasn't flushed changes yet.
<gary_poster> stub, FWIW, I got a change that made the problem go away
<stub> gary_poster: We can drop the trigger and maintain this in Python if it is easier - I'm not fussed.
<gary_poster> I don't know if it is a good change
<gary_poster> here's what I did:
<gary_poster> lines 8-9, 125-130 in http://pastebin.ubuntu.com/561443/
<gary_poster> I'd be fine with moving that to an __init__ and removing the trigger too; I'm too inexperienced with these bits to have an opinion.
<stub> gary_poster: That will make things explode when the trigger gets fired, as it doesn't look before it leaps
<gary_poster> stub, ack.  OK, the only easy solution I see is to rip out the trigger and put that logic in the __init__.  agree?
<stub> gary_poster: Easy solution I see is to make _person_settings flush the Store before attempting to retrieve the PersonSettings
<gary_poster> oh ok
<stub> If that doesn't work, rip out the trigger. Or rip it out anyway if you develop a stronger opinion :) I put the trigger in simply because I thought it was less effort than tracking down everywhere Person objects get created (although I guess that should pretty much be covered by Person.__init__).
<gary_poster> ack.  I am trying the test run with a flush, and removing the creation code
<deryck> bac, hey, I'm about to look at that accordion stuff again, if that helps.  Had lots of YUI questions and work since we chatted....
<gary_poster> nope, that fails
<deryck> bac, so not able to look again until now
<danilos> food, finally
<stub> gary_poster: ok. you ok pulling out the trigger? Just needs the statement removed from the patch.sql and the function from trusted.sql
<gary_poster> stub, yeah, I think I can do it
<bigjools> jtv: http://pastebin.ubuntu.com/561451/
<jtv> bugger
<jtv> On a side note, like the error reporting?
<bigjools> bt is always nice
<jtv> I wonder why the existing tests don't reveal this.
<jtv> I added script return values per architecture.
<jtv> Is --arch a newer option perhaps?
<allenap> abentley: Sorry I missed your ping. I was otp and forgot about it when I was done. I like your improvements :) mrevell, do you want to merge abentley's patch?
<mrevell> Sure, will do
<bigjools> jtv: check what versions of a-f are in lucid vs maverick
<jtv> checkingâ¦
<abentley> mrevell, please use the version in my MP comment; it is slightly improved.
<mrevell> Will do abentley
<abentley> allenap, cool.
<mrevell> Thanks both
<jtv> bigjools: big differenceâ0.7.25 vs 0.8.3.
<bigjools> there you go
<jtv> The lucid version doesn't have --arch. â¹
<bigjools> our servers are all on lucid
<bac> hi deryck.
<bigjools> jtv: you could see if there's a backport
<jtv> worth trying!
<bigjools> look in -backports
<jtv> excrement
<jtv> Don't see it.
<jcsackett|afk> deryck: any chance i could chat with you today about bug 421901 (particularly some refactoring ideas)?
<_mup_> Bug #421901: Person:+bugs timeouts <lp-bugs> <timeout> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/421901 >
 * jcsackett wonders when his nick changed to afk...
<jtv> bigjools: on the bright side, the lucid version does have the _configuration item_ for architecture.
<gary_poster> stub, my smoketest passes now.  I have pushed the branch, and diff is http://pastebin.ubuntu.com/561454/ (good bits starting line 1055)
<bigjools> jtv: can we poke differently that in multiple parallel runs?
<bigjools> edit fail
<jtv> I thought you were just being funny.
<bigjools> normally, yes
<deryck> jcsackett, yeah, sure.  I'm trying to look into some YUI issues for bac now. then I want to eat.  Then we could chat.  cool?
<jcsackett> deryck: sure. any chance at an approx time?
<deryck> hmmm, you try to ping me down! ;)
 * deryck looks at calendar/clock
<deryck> jcsackett, forgot about team lead call, too.  Somewhere just after 1800 UTC work for you?
 * jcsackett tries to do tz conversion...
<jcsackett> that's like noon your time, 1pm my time, yeah?
<jcsackett> deryck ^
<deryck> jcsackett, yes
<jcsackett> deryck: that would be great. thanks. :-)
<deryck> jcsackett, google calendar can do dual time zones now, if that helps you :-)
<jcsackett> deryck: that may very well help, thanks.
 * deryck can teach you how to quickly convert TZs, win friends and influence people
 * jcsackett laughs
<stub> gary_poster: Looks fine.
<gary_poster> Thank you very much stub
<abentley> henninge, ping
<henninge> abentley: Hi
<henninge> abentley: sorry, got held up. Your review is next. Really.
<henninge> ;-)
<stub> gary_poster: Oh... your Python generates a PersonSettings for all Person records created, even teams.
<abentley> henninge, can we mumble about how to share messages when new links are created?
<gary_poster> stub, ah.  I forgot about that.  And I'm not even entirely sure how to distinguish.  But assuing you actually want to get off the computer, I'll try to find someone else to bother about that.  Thank you for the warning
<henninge> abentley: sure
<stub> if self.teamownerID is None: settings = PersonSettings()...
<gary_poster> ah, easy enough
<henninge> abentley: will be there in 30 sec ;)
<bigjools> jtv: mvo says that we can backport maverick's a-f to lucid
<jtv> bigjools: if that's easier/safer than writing separate config filesâ¦
<bigjools> jtv: well I don't know how hard the latter would be, so you can make the call
<bigjools> but it sounds like we should use --arch if we can
<jtv> For the config file I'd have to figure out what else might rely on that config file.
<jtv> I'll see how easy the backport would be.  I happen to have a lucid machine handy.
<sinzui> mrevell: can you review the text and UI of my branch: https://code.launchpad.net/~sinzui/launchpad/team-membership-policy-1/+merge/48203 . You can also see/edit that same text at https://help.launchpad.net/Teams/CreatingAndRunning#Subscription%20policies
 * mrevell looks
<bigjools> jtv: mvo can help you, he's the package maintainer, have a word with him.
<jtv> bigjools: thanks, I was just typing.  :)
<bigjools> jtv: huh, didn't see you were on that channel :)
<lifeless> moin
<deryck> oh good holy internet gods it can't be so simple!
<deryck> bac, gah!
<deryck> bac, the script has to be inline on the page *after* the html elements. :-)
<deryck> or defer all the stuff until domready
<bac> deryck: really?
<deryck> bac, *really*
<deryck> the complexity of YUI makes us overlook the obvious
<deryck> it's trying to render a widget based on html it doesn't know about yet
<bac> deryck: doh.  cool, i'll play with it more after lunch.  thanks.
<deryck> bac, np
<lifeless> gary_poster: you can use self.is_team IIRC, which is specialised during __storm_load__ or whatever the hook it
<deryck> adeuring, just reminder to update that bug status and delete card on the board. :-)
<gary_poster> lifeless, yes, thank you. I found that and switched to it :-)
<lifeless> \o/
<adeuring> deryck: well... after my talk with Henning we decided that a bit work on the bug is reasonable ;)
<deryck> adeuring, ah, ok.  I'll catch up about that after this call if you're still around
<adeuring> ok
<lifeless> allenap: oh, right - ih
<lifeless> allenap: using one bug for several landings interacts poorly with our QA
<lifeless> allenap: you might like to not do that :>
<lifeless> allenap: (because you'll be fighting with the qa tagger robot otherwise)
<allenap> lifeless: Okay, sure. Using bugs for managing QA interacts badly with my development process ;)
<lifeless> allenap: yes, its a bit of a nuisance, and eventually we should decouple this more
<allenap> lifeless: Cool. I'll file separate bugs in future.
* jtv changed the topic of #launchpad-dev to:  https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: danilos | https://code.launchpad.net/launchpad-project/+activereviews
<lifeless> allenap: what I do is this; if I'm building up to something, I don't link to that bug until I'm there; I either land unqaable (if there isn't a user impact) or land with new bugs that focus the exact thing I'm changing rather than the user request
<lifeless> allenap: this is a bit hit n miss
<allenap> lifeless: Okay, that would work for me.
<lifeless> allenap: anyhow, whatever works for you is fine; I only mentioned this cause I saw you starting to haggle over bug status with the qabot :)
<allenap> lifeless: I keep forgetting to use the --incremental flag which, aiui, would dtrt for me.
<lifeless> flacoste: so, 21utc you say ?
<deryck> jcsackett, I'm off early.... wanna chat in mumble in 5?
<jcsackett> deryck: sure.
<lifeless> flacoste: which is what, 3.25 hrs ??
<jcsackett> deryck: mano-a-mano in Green?
<deryck> sure
<lifeless> allenap: --incremental generats qa-untestable commits
<allenap> lifeless: Ah, okay. I'll go with the multiple bugs then.
<lifeless> allenap: so if you are confident they are deployable w/out qa, then yes, its what you want.
<allenap> lifeless: Mmm, not normally :)
<lifeless> :)
<bigjools> lifeless: http://pastebin.ubuntu.com/561519/
<bigjools> lifeless: any idea why my new ami does that when I start an instance?!  missing postgres.... wtf
<lifeless> bigjools: pg 8.2
<bigjools> lifeless: not even 8.2 is there
<bigjools> the script is bong
<maxb> The 8.2 is because the script is busted if no pg exists at all
<lifeless> what ubuntu baseline did you use ?
 * lifeless takes wild guesses
<bigjools> lifeless: the one in the wiki page telling you how to do this stuff
<lifeless> I love line 43
<bigjools> https://dev.launchpad.net/EC2Test/Image
<maxb> Does this AMI have launchpad-dependencies installed?
<bigjools> lifeless: that's exactly why I pasted it :)
<lifeless> blank lucid is right
<bigjools> maxb: well that's interesting because I patched that package to include the new dependency
<lifeless> bigjools: IIRC there is an issue with the metapackage
<bigjools> ah crapola, I wonder if the dependency is on lucid
<lifeless> something about v3, but that may be the CAT dependencies
<bigjools> if only I had the output from the creation session
<lifeless> postgresql-8.4-debversion |    1.0.3-1 | lucid/universe | amd64, i386
<lifeless> postgresql-8.4-debversion | 1.0.3-1build1 | maverick/universe | amd64, i386
<lifeless> postgresql-8.4-debversion | 1.0.4-1ubuntu1 | natty/universe | amd64, i386
<lifeless> its on lucid
<bigjools> I'll have to make a new image and watch where it fails.  Unless you have a better idea?
<deryck[lunch]> adeuring, I must needs eat.  So we can chat tomorrow in the standup about this.  No big deal.
<deryck[lunch]> just curious about what's happening
<adeuring> deryck[lunch]: ok, no problem. Need to start lunch too ;)
<adeuring> deryck[lunch]: ...and enjoy lunch
<leonardr> danilos, please review this easy branch: https://code.launchpad.net/~leonardr/lazr.restful/bug-619180/+merge/48355
<danilos> leonardr, hi, is .encode(utf-8) safe to do for URLs?
* danilos changed the topic of #launchpad-dev to:  https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<lifeless> if it is a url, then it must be a subset of ascii
<lifeless> by definition
<leonardr> danilos: what specific case are you thinking of?
<danilos> ok, let me rephrase that... leonardr, is .encode('utf-8') safe to do before passing to webservice.get() [i.e. does it do escaping as appropriate, and is it documented that our webservice works with UTF-8]
<danilos> leonardr, line 48
<leonardr> danilos: well, the test works... that's a good question, though
<danilos> leonardr, heh, ok, fair enough
<danilos> leonardr, how do we answer that question?
<leonardr> danilos: i'll take a look at the incoming request
<jam> jtv: are you still around? I got stuck shoveling snow for a couple of hours this morning, but I'm around now
<danilos> leonardr, cool, thanks... even if it might be a problem already, it doesn't have much to do with this branch I suppose, so r=me
<danilos> leonardr, please do file a bug if you find it is, though
<leonardr> danilos: actually, i know it works in reality, because ursula's test request went through properly (and once this fix is applied, it works everywhere)
<leonardr> so i think httplib2 percent-encodes the utf-8, and that's how it works
<danilos> leonardr, right, makes sense, thanks
<danilos> leonardr, nice simple branch, thanks for the fix :)
<leonardr> np
 * danilos wanders off...
<abentley> sinzui, I notice that Packaging is a many-to-many relationship.  Is this commonly used?  Our modeling of translation sharing assumes that there is at most one product per sourcepackage and vice versa.
<sinzui> abentley: depends on the direction actually
<abentley> sinzui, it's really one-to-many, then?  Which way?
<LPCIBot> Project devel build (411): STILL FAILING in 5 hr 59 min: https://hudson.wedontsleep.org/job/devel/411/
<LPCIBot> * Launchpad Patch Queue Manager: [rs=wgrant][rollback=12302] Revert r12302, which caused test failures.
<LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=698032] When a recipe build has been
<LPCIBot> removed since a recipe build was started,
<LPCIBot> ensure the archive uploader does not fall over.
<sinzui> abentley: a product series can provide many packages, but *at this time* a distroseries can have only one package
<abentley> sinzui, thanks.
<sinzui> abentley: That describes PRIMARY. There is hidden packaging type INCLUDES that makes the relationship very complex by stating a that implies a distroseries could have multiple sources. We are not allowing users to select that
<abentley> sinzui, I don't understand "by stating a that implies a distroseries could have multiple sources"
<abentley> sinzui, do you mean "by stating that implies a distroseries could have multiple sources"?
<abentley> actually, I wouldn't understand that either.
<sinzui> PackagingType.INCLUDES implies that a package for a distroseries is provided by many product series. This relationship really does happen, but it is much abused, and very confusing. We are not using it now, but I believe there is historical data using it
<abentley> sinzui, okay, thanks.
<sinzui> We never solved how to show multiple distroseries->packages in the UI, so no one knows we removed the kind of relationship
<sinzui> abentley: I mention this because historical data could cause issues if you build something that requires distroseries(1) -> packaging -> (1) productseries
<abentley> sinzui, I appreciate your completeness.  I'll discuss this with the Orange Mafia.
<lifeless> sinzui: more than historical no? once we get buildfrombranchtomain underway?
<sinzui> lifeless: no, There is no code using INCLUDES, and has not for more than a year
<lifeless> sinzui: ok
<sinzui> a lot of the uses were bogus because product owners do not understand packaging
<lifeless> sinzui: we may get pushback on that in the future
<sinzui> I understand. That is why I did not remove the type. We just need to ensure the people who need it have access to it
<lifeless> ack
<abentley> deryck, around?
<deryck> hi abentley
<abentley> deryck, mumble?
<deryck> sure.  let me fire it up.
<abentley> henninge, mumble?
<deryck> henninge, can you join abentley and I?
<henninge> deryck: 2 minutes
<deryck> henninge, cool
<thumper> deryck: hi
<thumper> deryck: how would I know if all the of the tests for lazr-js worked?
<deryck> thumper, install a jre and run ./bin/test
<leonardr> gary, gentle ping
<thumper> deryck: well, bin/test did run tests
<thumper> deryck: I have a jre from libre office
<deryck> thumper, and did it report x passed, x failed, etc.?
 * thumper is running them again
<thumper> deryck: one of the problems is that it left a firefox window open
<thumper> deryck: it didn't look finished, even though it reported success
<thumper> Total: 221 tests, 0 failures, 0 errors in 16.997 seconds.
<thumper> deryck: is that the right number?
<deryck> thumper, yeah, it doesn't close the browser
<deryck> yes
<thumper> deryck: that kinda sucks
<deryck> what sucks?
<sinzui> jcsackett: I have an call at 3:00. We can talk later today or tomorrow
<thumper> deryck: that it doesn't close the browser window
<jcsackett> sinzui: tomorrow morning sound good?
<deryck> thumper, why is that a bad thing?  for having them run automatically you mean?
<thumper> deryck: the open window left me wondering if it was done, broken, or what
<thumper> deryck: it doesn't seem to be documented that it leaves it open
<deryck> thumper, well it's not documented at all, if we're honest ;)
<deryck> it's magic, luck, and/or smarts that allow you to even get it running.
<thumper> heh
<abentley> henninge, deryck: http://packages.ubuntu.com/dapper/bazaar
<lifeless> hi
<lifeless> anyone have pqm swallow a merge recently?
<lifeless> if so, the problem should be fixed now on praseodymium (thanks lamont); but we need to throw something that was broken at it again to see it fixed
<abentley> sinzui, is it possible for two source packages with the same name in different Ubuntu series to contain entirely different software?
<sinzui> abentley: I am not sure I can answer your question. Since a SPN is being linked to a distrroseries productseries pairs, and user can make mistakes...Lp thinks they can be different. BUT distros use SPN to mean a package that has only only evolving line of software.
<abentley> sinzui, I remember with bazaar, we renamed it to "baz" so that we could later provide a "bazaar" that would be bzr.
<sinzui> oh, abentley, distros often create parallel versions of packages, like glade (version 2) and glade3, when 2 is unsupported, glade3 becomes a migration package to glade (latest version)
<sinzui> These are considered to be the same line of development though
<abentley> sinzui, right.
<abentley> sinzui, we're currently sharing translations among sourcepackages with the same name and distribution.  I'm trying to assess whether that's a bad thing.
<lifeless> abentley: yes, it is possible.
<lifeless> abentley: I'm not sure it worries translations though, as long as the pot modelling still generates the right set of strings to be translated
<abentley> lifeless, it worries hennninge.
<lifeless> abentley: then it may be an issue ;)
<lifeless> abentley: I don't have any particular view, FWIW.
<sinzui> abentley: this will be a problem when users do something stupid like claim that app provides firefox because it *depends on* firefox
<sinzui> abentley: but the problem is not about translations or Ubuntu. it is about users providing bad data
<abentley> sinzui, heh, okay.
<abentley> sinzui, well, it points to the importance of being able to unshare translations when packaging links go away...
<sinzui> abentley: I looked at packaging link differences between natty and maverick a few months ago. I saw about 20 links that were wrong so I deleted them
<mwhudson> yay for the haproxy-for-twisted-services branch
 * thumper fires up mumble
<lifeless> flacoste: hai
<flacoste> lifeless: hi
<lifeless> is now when you meant?
<flacoste> lifeless: i skype you in 5 minutes?
<lifeless> sounds great
<flacoste> ttys
<StevenK> RARGH, Windmill!
<lifeless> StevenK: wgrant: oh hai .au
<StevenK> lifeless: O hai. Not sure about wgrant, but I have a call
<thumper> StevenK: mumble?
<lifeless> StevenK: wgrant: at the team lead meeting we talked hudson; the idea of less issues than buildbot has is very intruiging, but as in the short term we'd be bucking the default for losa involvement.
<StevenK> thumper: Sure, one sec
<thumper> leonardr: mumble?
<leonardr> thumper:on my way
<lifeless> StevenK: wgrant: having a report/graph/whathaveyou - actual empirical data - about when bb fails and hudson doesn't (and vice verca) would make the discussion a lot more straight forward.
<StevenK> Why does this feel like pushing uphill?
<lifeless> StevenK: current status is this: if hudson was packaged - no brainer; if its not packaged we either need losas to operate the linode, or we need to run the war/external deb in the datacentre
<lifeless> StevenK: we (the lp team) can push for one of those two alternatives, and will, but given the scare resources... it needs a little more incentive for flacoste to get out and push ;)
<StevenK> lifeless: In the shortish term, the war sounds fine
<lifeless> StevenK: right, but its /not the default/ for the losas to run an externally built binary.
<StevenK> I'm well aware
<StevenK> You know exactly how much work it is to package it
<lifeless> StevenK: which is why francis wants a bit more backing about the benefits
<StevenK> lifeless: 1) No more slave lost crap. 2) Cancelling builds doesn't mean that the LOSAs spend an hour fixing it. 3) Windmill tests can be run seperately under a windmill plugin for Hudson if we wish. 4) subunit support?
<StevenK> lifeless: I wonder why Francis didn't bring any of this up at the epic? :-(
<lifeless> StevenK: I'm otp now too sorry; will talk more in a bit
<leonardr> benji, is there any chance you can help me figure out the problem with the lazr.restfulclient build environment?
<wgrant> Grar.
<StevenK> http://pastebin.ubuntu.com/561626/ :-(
<lifeless> flacoste: btw bug 712108
<_mup_> Bug #712108: shared ssl session cache support not possible out of the box <apache2 (Ubuntu):New> < https://launchpad.net/bugs/712108 >
<wgrant> Why did buildbot poller request two identical stable -> db-devel merges four minutes apart? :/
<StevenK> Awesome
<StevenK> Ugh, apparently it's going to be 37 today
<huwshimi> StevenK: You have aircon right?
<StevenK> huwshimi: Nope
<huwshimi> StevenK: Ouch
<StevenK> lifeless: Still on the phone?
<lifeless> yep
<huwshimi> Anyone able to review  a UI change? https://code.launchpad.net/~huwshimi/launchpad/tag-list-wrapping-708436/+merge/48393
<sinzui> huwshimi: I understand the change you made, but I have a few questions
<huwshimi> sinzui: Sure
<sinzui> huwshimi: style.css is deprecated. Do we want to move .tags-container to style-3.0? Can this be generalised? I do not see anything tag specific in it
<sinzui> Is there a better name, does it overlap with other styles
<sinzui> I wonder if the text-align instruction is required
<huwshimi> sinzui: ok, let me have a look.
<sinzui> huwshimi: I think div.left could be just .left and it will do the right thing
<sinzui> huwshimi: acutally. I think changing the page to use .left and deleting the class also works
<huwshimi> sinzui: Actually I wonder if we need any of that.
<sinzui> what is it floating from? Is that your question?
<huwshimi> sinzui: yeah the float doesn't seem to be doing anything... well that I can tell initially
<sinzui> huwshimi: I wonder if it was once in a two column layout. I think we are looking at an obsolete rule
<huwshimi> sinzui: yeah that might make sense of why it was set to 45% width as well
<sinzui> I see a test looks for it but it is not important. The template does two odd things with it to make a composite class
<wgrant> StevenK: Can I steal DF for a few hours to QA r12300?
<lifeless> poolie: hi
<lifeless> poolie: got a few minutes?
<huwshimi> sinzui: So would you be happy for the fix to be removing the tags-container rules from style.css?
<sinzui> I would be happy with that
<huwshimi> sinzui: Thanks I will commit the new changes.
<lifeless> StevenK: hi, I'm off the phone for a bit; would you like a brief voice call about hudson? wgrant too, if you're interested?
<wgrant> StevenK: I'm not sure I have much to add.
<wgrant> Er, lifeless too ^^
<sinzui> wgrant: mumble
<poolie> lifeless, hi, yes, but stephane's on the phone atm
<lifeless> sinzui: thanks for spotting that dupe
<lifeless> poolie: skype?
<lifeless> poolie: or same room ?
<sinzui> huwshimi: https://bugs.launchpad.net/launchpad-help-moin-theme/+bug/488241
<wgrant> Er
<wgrant> launchpad@mawson:/srv/launchpad.net/codelines/current$ ./scripts/publish-distro.py -A -s natty-proposed
<wgrant> 2011-02-02 22:39:45 INFO    Processing ubuntu Primary Archive for Ubuntu
<wgrant> 2011-02-02 22:41:43 WARNING a-f: E: Command line option --arch is not understood
<wgrant> Oh, it's a local change.
<huwshimi> sinzui: in that template (for the bug tags) what does this line do?  tal:attributes="class python: ('tags-container ' +...
<sinzui> huwshimi: it is concatenating classes to "tags-container '
<wgrant> And putting it in the class attribute of the tag.
<huwshimi> Ah ok right
<sinzui> huwshimi: I need to take my daughter to a class. I will be back in 30 minutes
<huwshimi> sinzui: Sure, thanks for your help
<huwshimi> wgrant: What were you saying the other day about how feature flags are implemented now?
<wgrant> huwshimi: There's documentation and admin UI for them, so you should define them in lib/lp/services/features/flags.py. There are also a few different ways of testing them, so you might have to look around.
<StevenK> lifeless: I'm free now if you are.
<huwshimi> wgrant: Thanks, taking a look
#launchpad-dev 2011-02-03
<StevenK> wgrant: You're not done with mawson?
<wgrant> StevenK: I would have been if it hadn't crashed.
<wgrant> Nearly done.
<wgrant> But I still need the buildd.
<lifeless> StevenK: hi
<StevenK> wgrant: Is perfectly fine, tell me when you're done.
<StevenK> lifeless: mumble?
<StevenK> lifeless: Or would you prefer something else?
<lifeless> mumble is still fail on my link
<StevenK> Get a better one? :-)
<lifeless> 2012
<StevenK> lifeless: Skype or pots?
<lifeless> skype
<StevenK> Bleh, that requires commitment
<lifeless> I don't think you're craazy
<StevenK> Bad puns will be punishable at the Epic
<lifeless> i.e. never
<lifeless> :>
<StevenK> lifeless: On Skype and ready
<lifeless> StevenK: skype id
<StevenK> wgrant: Are we there yet?
<wgrant> StevenK: Just finished about a minute ago.
<wgrant> It's all yours.
<wallyworld> thumper: ping
<StevenK> wgrant: Didn't you say you'd fix the en_AU locale on mawson?
<StevenK> wgrant: https://code.dogfood.launchpad.net/~stevenk/+recipes :-D
<wgrant> StevenK: No. I was going to look at overriding LANG.
<wgrant> Indeed, my .profile has:
<wgrant> export LANG=C
<wgrant> export LC_ALL=C
<wgrant> And there are no more warnings.
<wgrant> StevenK: Also, let me know when you're done with DF.
<wgrant> I want to stab the publisher in the face.
<wgrant> (that may be taken to mean optimising publishFileLists, or maybe not)
<StevenK> wgrant: I'm done once I clean up, but I wanted you to see the evil I created.
<lifeless> what should I do today?
<wgrant> StevenK: What was the evil?
<StevenK> wgrant: https://code.dogfood.launchpad.net/~stevenk/+recipes
<wgrant> Besides what looks like a bug in findStaleDailyBuilds, or a manual request.
<StevenK> wgrant: Look at the source branch
<StevenK> wgrant: It was a manual request.
<wgrant> Ah.
<wgrant> you're trying to kill our builders!
<StevenK> Haha
<wgrant> What're you testing?
<StevenK> I was QA'ing my findStaleDailyBuilds() change
<StevenK> I needed a branch ...
<wgrant> Ah
<StevenK> wgrant: Recipe deleted, you should be good
<wgrant> Thanks.
<henninge> &away
<LPCIBot> Project devel build (412): STILL FAILING in 6 hr 10 min: https://hudson.wedontsleep.org/job/devel/412/
<LPCIBot> Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=707103] UI for searching for bugs with or
<LPCIBot> without linked Blueprints.
<thumper> wallyworld: whazzup?
<wallyworld> thumper: mumble?
<thumper> aye
<wgrant> poolie: With the oauth thing... you did s/contrib.oauth/oauth/, right?
<lifeless> wgrant: hey
<lifeless> in oops 1855H1087
<lifeless> for th elong query; can you suggest a likely value for archive?
<lifeless> and the two status values
<wgrant> That query suggests it was a copy archive.
<wgrant> It's going to be difficult to reproduce entirely now.
<lifeless> I'm looking for one that will be on qas
<wgrant> Ah, yes, it was the copy archive.
<wgrant> There's nothing like it on qas.
<wgrant> Possible on staging, though.
<wgrant> Let me see.
<lifeless> not even lucid itself?
<wgrant> No.
<wgrant> This relies on there being lots of pending builds.
<wgrant> We could create one on qas, though.
<StevenK> Sure, how much do you want asuka to cry blood?
<wgrant> The first status is 0 (there were probably 25000 or so matching BFJs), the second is 6 (probably only about 30).
<lifeless> StevenK: it would hardly notice
<wgrant> staging's snapshot is from just the right time.
<StevenK> lifeless: Because it already is?
<wgrant> But the pending builds have been nuked.
<lifeless> hmmm, I wonder if https://help.launchpad.net/Code/Imports can be made snappier
<wgrant> Snappier?
<lifeless> easier for users of bzr to follow successfully
<lifeless> so how do we go about creating one of these archives on [qa]staging?
<wgrant> lifeless: We need to turn off the build farm, then run populate-archive.py.
<wgrant> Or we could possibly leave the build farm on and the archive disabled.
<thumper> wallyworld: are you all good?
<thumper> wallyworld: we have a laptop emergency
<thumper> wallyworld: and need to get Rachel a new one
<lifeless> wgrant: https://qastaging.launchpad.net/builders is full of lies
<wgrant> "scripts/populate-archive.py -v --distribution=ubuntu --suite=natty -a i386,amd64 --to-user=lifeless --to-archive=bye-bye-asuka --reason='i hate alive servers'" should do it.
<lifeless> will that try to build things straight away?
<wgrant> lifeless: Looks like qastaging has no buildd-manager.
<StevenK> lifeless: Of course it is. We don't delete builders on qas
<wgrant> So you can safely run it there.
<lifeless> thats correct
<lifeless> spm: hi
<StevenK> I think he's lunching
<lifeless> spm: 6 lines before I said hi, kthxburn
<StevenK> On that note, so am I
<lifeless> StevenK: I'm sure he is
<wgrant> spm, lifeless: It may need to be "-a i386 -a amd64" instead of "-a i386,amd64". One will work, one will not, I forget which.
<thumper> wallyworld: too late, off to hardly normal
<lifeless> wgrant: where is your openid fix
<wgrant> lifeless: In buildbot.
<wgrant> It was testfixed away last night.
<wallyworld> thumper: sorry, was eating
<wgrant> So it is still a few hours away from qasbounce.
<lifeless> wgrant: kk
<spm> wgrant: so scripts/populate-archive.py -v --distribution=ubuntu --suite=natty -a i386 -a amd64 --to-user=lifeless --to-archive=bye-bye-asuka --reason='wgrant hates alive servers' <== on LPCONFIG=QAS on asuka?
<wgrant> spm: I see what you did there.
<wgrant> But yes, that should work.
<spm> sneaky aren't I
<spm> technically it's *you*, not I, as the command would have it. So I had to correct the 'person' sense. <== BIG ISSUES
<wgrant> Indeed.
<lifeless> spm: thanks
<spm> ho ho.FATAL:  Ident authentication failed for user "lucille" <== fixin'
<wgrant> I think that is the sole remaining reference to lucille.
<wgrant> It is tempting to quickly remove that.
<StevenK> Death to lucille
<wgrant> Ah, no, the demon lives on in poppy's ident.
<StevenK> Sigh, it's moving. Kill it.
<spm> haha
<wgrant> StevenK: What should I call the new user? archivepublisher?
<spm> but yes. names that match functions, if only loosely, do help us. pls to fix. :-)
<spm> wgrant: sigh. lucilleball of course. for shame.
<wgrant> Needs more "l"s.
<spm> llllllllllll ?
<lifeless> loball
<StevenK> wgrant: I'm tempted to suggest 'lolwut'
<spm> lollball?
<StevenK> Just due to the queries that lucille currently runs
<wgrant> StevenK: mawson can handle the SPPH indices OK.
<wgrant> But not both it and BPPH, it seems.
<wgrant> Once hot, the source override queries are all sub-second... But the moment you run a binary override query, they exceed a minute.
<wgrant> Yay, mawson.
<StevenK> The BPPH indices suck?
<lifeless> proposition: the queries suck
<wgrant> They're all just a bit big.
<lifeless> the number of rows being considered is too high
<wgrant> SELECT SourcePackageName.name, Component.name, Section.name FROM SourcePackagePublishingHistory JOIN Component ON Component.id = SourcePackagePublishingHistory.component JOIN Section ON Section.id = SourcePackagePublishingHistory.section JOIN SourcePackageRelease ON SourcePackageRelease.id = SourcePackagePublishingHistory.sourcepackagerelease JOIN SourcePackageName ON SourcePackageName.id = SourcePackageRelease.sourcepackagename WHERE ...
<lifeless> or they are too widely spread out
<wgrant> ... SourcePackagePublishingHistory.archive = 1 AND SourcePackagePublishingHistory.distroseries = 103 AND SourcePackagePublishingHistory.pocket = 0 AND SourcePackagePublishingHistory.status = 2 ORDER BY SourcePackagePublishingHistory.id DESC LIMIT 10000 OFFSET 0;
<wgrant> Component and Section are small. SPN isn't bad.
<lifeless> moving to an actual model of suite would help.
<wgrant> A little, yes.
<StevenK> No, it wouldn't
<StevenK> It would make adding a new suite for Ubuntu a lot harder
<lifeless> by which you mean easier and more controlled
<StevenK> No, by which I mean creation of new tables and duplicated data\
<wgrant> I unfortunately have to agree with lifeless here.
<wgrant> And I normally disagree with his Soyuz model arguments :P
<StevenK> wgrant: Who are you, and what have you done with the real wgrant?
<spm> <wgrant> I unfortunately have to agree with lifeless here. <== my world. It has ended.
<StevenK> Haha
<spm> I had 3 cornerstones. Death, Taxes and lifeless/wgrant not agreeing. This is now over. /me hols forearm theatrically and dramatically to forehead
 * lifeless applies stablegun
<lifeless> *staple*
<lifeless> something that shoots stables would be awesome, scary, and worrying.
<spm> meh. I play a pally. I can still faceroll and out dps
<wgrant> Yet far more effective than a mere staplegun;
<lifeless> spm: I need to get that stuff off you
<lifeless> also fix my gems etc, I struggle to do 5k dps
<lifeless> [as ret]
<wgrant> DEPART, WoW SCUM!
<StevenK> Haha
<lifeless> wgrant: join us, be one of us.
<StevenK> lifeless: Pfft. My DK is currently doing 9k and I button mash
<lifeless> its a dk.
<lifeless> bastards.
<spm> wgrant: for the record - what are you doing that needed that DB access change? "add to pg_ident: lucille for qastaging access for wgrant doing soyuz builders <...>" ?
<StevenK> lifeless: Hell, I did 7k as *prot* in H SFK last night
<lifeless> spm: we're making a copy archive to test performance of some soyuz q's.
<lifeless> StevenK: prot dk ? again...
<StevenK> lifeless: Prot pally, dks tanking tree is 'blood'
<spm> lifeless: ta
<lifeless> StevenK: I roll between 5 and 9 in prot, depending on encounters.
<StevenK> Due to classes, we had no reliable CC for the entire instance
<StevenK> Although Holy Wrath is awesome again
<StevenK> lifeless: Back to work time things. wgrant has tagged my bugs qa-bad, and with the rollback. What will the qatagger do when the new branch hits stable?
 * lifeless started work at 6am
<lifeless> whats this work time you speak of?
<wgrant> StevenK: Your thing is OK to deploy since the rollback./
<wgrant> Just tag the bug qa-ok as normal once this thing is QA'd.
<StevenK> lifeless: Sorry, s/time/type/
<StevenK> wgrant: And leave the rollback tag?
<lifeless> StevenK: the rollback comes from the commit, not the bug
<lifeless> StevenK: it will all Just Work
<wgrant> Leave bad-commit-39423423, though.
<StevenK> wgrant: Are you using mawson?
<wgrant> StevenK: No.
<StevenK> Pondering how best to create test accounts to QA my branch
<wgrant> Oh?
<wgrant> Ah, the merge one?
<StevenK> Yes
<wgrant> No need for test accounts.
<wgrant> Just find an account with recipes and subsume it.
<lifeless> nom nom nom
<StevenK> Don't I need to be logged in as that person?
<wgrant> You merge them into you.
<wgrant> It will send an email to the mergee with a logintoken.
<wgrant> You have DB access.
<lifeless> or
<wgrant> Or use adminpeoplemerge
<lifeless> use the staging mailbox to read the email
<wgrant> Or that.
<wgrant> But that's slow.
<wgrant> And non-TLs aren't meant to have access, IIRC.
<wgrant> $ bzr push
<wgrant> Using saved push location: lp:~wgrant/launchpad/the-death-of-lucille
<wgrant> bzr: ERROR: No such file: '/~wgrant/launchpad/the-death-of-lucille/.hg/requires'
<wgrant> Pardon?
<lifeless> \o/
<wgrant> Ah, new bzr-hg this morning.
<lifeless> jelmer: ^
<wgrant> lifeless: I don't know the archive ID, but "SELECT id FROM archive WHERE owner=2 AND name='bye-bye-asuka'" should tell you.
<wgrant> Also, damn, that's a nice UID.
<lifeless> wgrant: the boss wanted 1.
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/the-death-of-lucille/+merge/48424
<StevenK> wgrant: +1'd with a comment
<StevenK> wgrant: I have to say, I don't quite like the idea of merging random people into my account on DF
<lifeless> Be the big dog.
<wgrant> StevenK: :(
<wgrant> StevenK: Remove email addresses and OpenIDs from some other account, reassign your cookie or OpenID to that user, then merge people into that.
 * StevenK blinks
<wgrant> Or is +adminpersonmerge effective here too?
<wgrant> I think it might be.
 * StevenK tries to work out if a person is a team using only the DB
<wallyworld> thumper: can you find that working example we discussed? i can see in firebug the post is happening but it's not getting to the back end code.
<StevenK> Ah, teamowner. Sneaky
<huwshimi> wallyworld: Are you avoiding the natural disasters again this time?
<wallyworld> huwshimi: yeah, i'm about 600km south of the action
<wallyworld> haven't seen the news today yet so don't know how much bad shit has happened
<huwshimi> wallyworld: You avoided the floods too right?
<wallyworld> yep - just :-)
<wallyworld> bloody hot today though - and very humid :-(
<wgrant> This is why we don't live in Queensland :)
<wgrant> Also cyclones.
<wgrant> And floods.
<wgrant> But yeah.
<StevenK> Currently 35degC in my room
<StevenK> Feels muggy as hell, too
<StevenK> wgrant: So, feel like helping? A suitable candidate is merging 'liferea' into 'midori'
<huwshimi> wgrant: There are other reasons too :P
<wgrant> StevenK: ~midori hath no recipes.
<wgrant> Oh.
<wgrant> It does on dogfood.
<StevenK> wgrant:  https://code.dogfood.launchpad.net/~midori/+recipe/development ?
<StevenK> And identically named branches
<wgrant> doit
<StevenK> wgrant: So, I should mark liferea's 3 PPAs as DELETED?
<wgrant> StevenK: I'd say so.
<wgrant> lifeless: Any idea on QAing that last thing?
<wgrant> It's advanced subscriptions stuff.
<wgrant> But I'm not sure if it's in the UI.
<lifeless> wgrant: join the alpha team
<wgrant> I enabled it globally on DF.
<wgrant> Still couldn't see the UI anywhere.
<lifeless> ok
<lifeless> uhm
<lifeless> sec
<wgrant> Maybe I should grep around.
<wgrant> Ah, the new UI is there if you bypass AJAX.
<lifeless> spm: so that merge is in the pqm queue in slot 4
<lifeless> spm: but the merge to db-devel is in slot 0
<lifeless> spm: its liable that staging will blow up as a result.
<StevenK> wgrant: Done, what next? :-)
<wgrant> StevenK: Did the merge work?
<StevenK> wgrant: I'm still trying to work out *how* to do the merge
<wgrant> lifeless: Could you mentor https://code.launchpad.net/~wgrant/launchpad/the-death-of-lucille/+merge/48424?
<wgrant> StevenK: /people/+adminteammerge
<huwshimi> wgrant: Can you show me how to reproduce bug #392079?
<_mup_> Bug #392079: "Recent revisions" header on branch page jumps around due to "clear: both" <lp-code> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/392079 >
<spm> lifeless: no worries. staging blowing up is nothing abnormal :-)
<StevenK> Oh damn it
<StevenK> I am a muppet
<wgrant> huwshimi: I think that's fixed.
<wgrant> there's now just a clear: left;
<StevenK> Can I unmerge a team? :-)
<huwshimi> wgrant: Want to close that bug then?
<wgrant> huwshimi: Doing so.
<wgrant> StevenK: Hah. What did you do?
<huwshimi> wgrant: Thanks mate :)
<StevenK> wgrant: Forgot to merge in my branch *first*
<wgrant> Heh.
<StevenK> So, bugger
<wgrant> lifeless: that's why I branched from and proposed to db-devel :)
<lifeless> great minds
<wgrant> Grrr
<wgrant> nightly.sh still sucks.
<wgrant> And it doesn't log :(
<stub> Now lets see if this is just good timing, or if this position cuts out the wireless interference from next door.
<stub> 0.5% packet loss down from 25-50%
<lifeless> nice
<lifeless>     Hard / Soft  Page ID
<lifeless>      862 / 8918  Archive:+index
<lifeless> spm: did that copy archive creation complete?
<wgrant> Yes.
<spm> yup
<lifeless> how hard would it be to add an expander to the subscriber portlets
<lifeless> just the 'subscribers' and 'also notified' buts
<stub> wgrant: How do you want nightly.sh improved? We should certainly twiddle all the jobs to use --log-file=DEBUG:/srv/wherever/foo.log and only emit errors.
<wgrant> stub: it sucks because it doesn't finish within 24 hours, and you can't tell what's going on unless you're subscribed to launchpad-error-reports.
<wgrant> Which I am, as of about a minute ago.
<stub> launchpad-error-reports only sees logs at the end, so that sucks too.
<wgrant> But it at least confirms that update-pkgcache is still running when the next thing starts.
<stub> So it needs to echo "Running foo `date`" >> /srv/whatever/nightly.log so we can see wtf it is running, and --log-file added to the command line so we get detailed logs of what is running, syncing the new logs regularly, and commenting out crap running far too long (bugs opened, separate cronjob installed)
<wgrant> Ah, there's the full log.
<wgrant> Yup.
<wgrant> Curtis removed a couple of things during the thunderdome.
<huwshimi> Another UI branch to be reviewed when someone has the chance: https://code.launchpad.net/~huwshimi/launchpad/remove-icon-alt-528367/+merge/48430
<wgrant> spm: Could you confirm when scriptactivity says update-pkgcache.py last finished? It seems to call itself update-cache.
<spm> wgrant: loganberry:update-cache with all the other nightly.sh's
<poolie> would someone kindly review https://code.edge.launchpad.net/~mbp/launchpad/701545-oauth/+merge/48431
<poolie> it should be very easy
<wgrant> spm: When did it finish? It's the one time that isn't logged by nightly.sh.
<wgrant> I want to know how far over we are running.
<spm> ahh. you should be able to infer that from when the email was actually sent
<spm> but one sec
<wgrant> Fair point.
<wgrant> Oh wow.
<wgrant> 7 hours.
<spm> but a fix as to "I'm finished date/time" would be nice.
<wgrant> Er, no, that's wrong.
<wgrant> The time on the email seems to be the time the cron job started :(
<wgrant> And pipermail won't give me the headers.
 * wgrant finds the mbox.
<lifeless> wgrant: so its archive 20929
<wgrant> You don't have permission to access /mailman/private/launchpad-error-reports/Week-of-Mon-20110131.mbox on this server.
<lifeless> wgrant: what are the enums we expect ?
<wgrant> lifeless: The first status is 0, the second 6.
<spm> wgrant: https://pastebin.canonical.com/42777/ 15 hours
<wgrant> spm: ... ouch.
<wgrant> thanks.
<lifeless> wgrant: what creates the buildfarmjobs ?
 * spm won't mention the name of "nightly".sh ;-)
<wgrant> lifeless: populate-archive.py should.
<lifeless> launchpad_qastaging=> select count(*) from packagebuild where archive=20929;
<lifeless>  count
<lifeless> -------
<lifeless>      0
<lifeless> (1 row)
<wgrant> Uh.
<wgrant> Could you enable the archive?
<wgrant> I can't see it unless it's enabled.
<lifeless> url
<wgrant> https://qastaging.launchpad.net/ubuntu/+archive/bye-bye-asuka/+edit
<wgrant> Oh.
<lifeless> timeout
<wgrant> Goddammit.
<lifeless> OOPS-1860QS14
<lifeless> gottendamerung?
<wgrant> I bet qastaging is old enough that it doesn't have any natty chroots.
<wgrant> Hm, no, it does.
<wgrant> upports_virtualized
<wgrant> False
<wgrant> Fail.
<wgrant> We have a half-initialised natty on qas.
<wgrant> spm: Could you rerun populate-archive.py with a new archive name, and maverick instead of natty?
<spm> sure
<spm> hereeeeees-asuka, underway
<spm> with apologies to Here's Johnny.
 * huwshimi is away
 * henninge is here
<henninge> Hi!
<henninge> Anybody feel like doing a review for me? ;-)
<wgrant> Hmm.
<wgrant> I wonder if I can just delete all DistributionSourcePackageCache and DistroSeriesPackageCaches for PPAs and copy archives.
<wgrant> Nothing uses them except the package count calculation.
<wgrant> Which is easily implementable in other ways.
<wgrant> And avoids a million inserts a night.
<poolie> henninge, i'll happily look
<henninge> poolie: thanks, it's https://code.edge.launchpad.net/~henninge/launchpad/devel-710591-sharing-info-groundwork-0/+merge/48416
<poolie> i infer you're using Idea - is it good?
<poolie> to me it looks clear and well explained and not obviously wrong
<poolie> of course i'm not familiar with that code
<wgrant> poolie: You lie.
<wgrant> poolie: You proposed the branch to the wrong place.
<wgrant> lp:~mbp/bzr/trunk
<poolie> :/
<poolie> that'd be it
<wgrant> Scared me for a minute, since I thought I'd fixed that bug two weeks ago.
<wgrant> Indeed I had.
<poolie> i did check for that but must have glazed over the url
<wgrant> Heh
<poolie> in https://bugs.launchpad.net/launchpad/+bug/707808
<_mup_> Bug #707808: Unmerged revisions list does not exclude merged revisions <qa-ok> <regression> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/707808 >
<wgrant> stub: You suggest that the script should log stuff directly to a file, but is there a reason to do that over just redirecting its output in crontab?
<wgrant> That's what all the rest do.
<wgrant> spm: Is qasbounce automatically updating now?
<poolie> i just tried make check in a branch off lp trunk and got
<spm> wgrant: should be
<poolie> a failure in testPPAPublisherOverrides ... connection_raw_execute ... not enough arguments for format string
<wgrant> spm: Yay, thanks.
<spm> wgrant: qastaging-logs/qastaging-update.log <== should be on carob for qaasbounce
<wgrant> poolie: That should have been fixed in r12305
<wgrant> poolie: Broke in r12302
<wgrant> spm: So it is.
<poolie> thanks
<lifeless> wgrant: losa long term goal, previously agreed strategy etc
<wgrant> lifeless: ECONTEXT
<lifeless> wgrant: output logging / redirect for scripts
<wgrant> Ah, right.
<lifeless> you'd need to talk to tom for more info
<lifeless> so, query stil returns 0 rows
<lifeless> with archive 20930
<wgrant> lifeless: Could you enable it so I can poke around?
<lifeless> no
<lifeless> I'd love to
<lifeless> but I can't even show the edit page
<lifeless> is there a trivial UPDATE?
<wgrant> Er, what do you mean you can't?
<lifeless> e.g. spm: can you please do 'update archive set enabled=TRUE where id=20930' on qastaging
<wgrant> It times out?
<lifeless> wgrant: yes
<wgrant> Huh.
<lifeless> OOPS-1860QS19
<spm> wgrant: the problem is that LP scripts tend to only write to STDERR. which is bad. because we either get emailed flooded and miss errors, or dump everything to a log and miss errors.
<wgrant> It's not complete, but that UPDATe will work for all we need it to.
<spm> lifeless: wgrant: is that a real "pls make it so #1" request?
<wgrant> spm: Yup.
<spm> coo. the ''eg' threw me
<spm> UPDATE 1, done
<StevenK> You can
<StevenK> Sigh
<StevenK> You can
<StevenK> You can't be Number One, your face doesn't look like balsa wood.
<LPCIBot> Project devel build (413): STILL FAILING in 5 hr 11 min: https://hudson.wedontsleep.org/job/devel/413/
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless, wgrant][bug=506630, 669288,
<LPCIBot> 683798] Also merge recipes on person/team merge.
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][bug=676372][rollback=12290] Use a custom python-openid
<LPCIBot> which suppresses the Expect: 100-continue that makes loggerhead auth choke.
<LPCIBot> * Launchpad Patch Queue Manager: [r=danilo][ui=none][bug=681326] Add a duplicate_only_subscriptions
<LPCIBot> set to BugSubscriptionInfo.
<lifeless> wgrant: so, ...
<lifeless> packagebuild is still 0 rows
<wgrant> lifeless: It is.
<wgrant> I am chasing that once I work out WTF is up with buildbot-poller.
<StevenK> wgrant: Eh?
<StevenK> wgrant: What's wrong with buildbot-poller?
<wgrant> StevenK: It failed to notice that 12309 is good.
<wgrant> Possibly because the next build started immediately after?
<wgrant> You've hacked it recently -- do you have any ideas?
<lifeless> doubt that, it gets a vector
<StevenK> wgrant: It should ignore the currently building job
<wgrant> lifeless: Ha ha.
<wgrant> lifeless: It gets the last 10 in case the checkout fails.
<wgrant> If it was successful, it only uses the last one.
<wgrant> But StevenK's suggestion makes sense.
<wgrant> Does it log anywhere?
<spm> ugh. So I'm ignorant on current "how I build Dev LP". I have an updtaed tree, how do I get the eggs?
<lifeless> wgrant: its noting 12307 is good
<wgrant> lifeless: It submitted that to PQM ages ago.
<lifeless> spm: you should have a dist-cache somewhere
<StevenK> spm: utilties/update-sourcecode
<wgrant> Is it still doing that?
<spm> ta
<lifeless> spm: run 'bzr update' in that
<wgrant> StevenK: that doesn't do eggs.
<lifeless> spm: and then 'make
<lifeless> '
 * StevenK looks at hudson
<wgrant> spm: rocketfuel-get does it all. Otherwise bzr up in ~/launchpad/lp-sourcedeps/download-cache
<spm> I suspect my original branch is too old for a dist-cache.
<StevenK> spm: If you use the rocketfuel stuff, rf-get works
<StevenK> Otherwise, I can furnish you with the script Hudson uses
<spm> probably should have gone that path. nm, see if this works.
<StevenK> spm: http://pastebin.ubuntu.com/561781/
<spm> ta
<wgrant> lifeless: Does it log somewhere?
<lifeless> wgrant: does what?
<wgrant> lifeless: buildbot-poller
<lifeless> wgrant: I believe so, on prase
<lifeless> wgrant: spm may know the location
<StevenK> lp.codehosting.codeimport.tests.test_workermonitor.TestWorkerMonitorIntegrationScript.test_import_hg
<lifeless> and if its replicated
<StevenK> Failing test on hudson :-(
<wgrant> StevenK: It does that occasionally.
<spm> I know Nothing!
<wgrant> But I haven't seen it on Hudson in months...
<wgrant> I blame Windmill.
<lifeless> spm: wee, thats a quotes page thing :)
<spm> :-)
<StevenK> spm: Are you also from Barcelona?
<spm> alaas no
<StevenK> (I think that's it)
<wgrant> spm: hereeeeeeeeeeeeeeeeeeeeeeeeeeeeeees-asuka seems to be a little too natty.
<spm> wgrant: hrm. not sure how? https://pastebin.canonical.com/42778/
<wallyworld> wgrant: you still working on getting r12290 unblocked?
<wgrant> wallyworld: It's stuck behind a laggy buildbot-poller.
<wallyworld> ah ok
<wgrant> wallyworld: But it should be on qastaging tonight.
<wgrant> And I already know it works.
<wallyworld> cool :-)
<wgrant> Sorry, it should have been done this morning. But curl and testfix intervened.
<wallyworld> no problem at all. just trying to get loose ends tidied up sp pqm can close tomorrow
<wgrant> spm: headdesk.
<spm> oh?
<spm> whaddididowrong?
<wgrant> spm: That script doesn't take --suite. It's what we've always used, but it doesn't actually do anything.
<spm> hahahahaha
<wgrant> But we've never copied a non-development series before.
<lifeless> I had a private bet on this
<wgrant> --from-suite
<wgrant> And --to-suite
<lifeless> it just ignores unknown options?
<wgrant> Try setting both to maverick.
<wgrant> lifeless: No, I think --suite is a standard SoyuzScript option.
<spm> I've just now had two complaints - from both wife and son - to pls quiet down the laughter
<lifeless> wgrant: which isn't used here
<wgrant> Right.
<lifeless> wgrant: thus effectively unknown :)
<wgrant> spm: So, s/--suite maverick/--from-suite maverick --to-suite maverick/, and pick a new appropriately offensive name.
<spm> "wgrant-likes-to-deskhead" ?
<wgrant> Sounds appropriate.
<spm> you'll get me in trouble with my family for laughing too loud again you know!
<wgrant> :(
<spm> heh
<spm> launchpad@asuka:~$ $LP_PY /srv/qastaging.launchpad.net/qastaging/launchpad/scripts/populate-archive.py -v --distribution=ubuntu --from-suite maverick --to-suite maverick -a i386 -a amd64 --to-user=lifeless --to-archive=asuka-wants-to-get-rocked --reason='wgrant hates alive servers'
<wgrant> :(
<spm> with no apologies to Def Leppard.
<wgrant> spm: are buildbot-pollers logs synced anywhere?
<wgrant> Add apostrophes as required.
<spm> bah. I was chasing that. ta.
<wgrant> The build finished 70 minutes ago, yet no push has happened.
<spm> Oookay. more to the point. where does the poller run, if indeed it still does.
<wgrant> prasÃ©
<wgrant> buildbot-poll.py
<spm> yeah. found it - was inside another script
<spm> should be with the stoick pqm logs. buildbot.log
<wgrant> Ah, indeed. How odd.
<wgrant> Thanks.
<wgrant> Merge request already in queue
<wgrant> Well, that's not a very good excuse.
<spm> probably a case of "we can easily sync from there over" vs any logical location
<wgrant> What calls buildbot-poll?
<wgrant> Because that check is crackful.
<wgrant> And it's not in lp:lpbuildbot.
<spm> parent branch: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/lpbuildbot/trunk/ ?
<lifeless> cron pehraps :P
<spm> or do you mean the wrapper script?
<spm> or cron...
<lifeless> whatever is causing it to not poll when there is a merge proposal outstanding
<wgrant> Something stops it from starting if there's already a merge in the PQM queue.
<wgrant> That's crackful and I want to delete it.
<lifeless> the promotion is orthogonal to the merges.
<spm> that's the wrapper script
<spm> https://pastebin.canonical.com/42779/
<wgrant> I cannot see any reason for that.
<wgrant> Oh.
<wgrant> Of course, it'll submit multiple times. Bah.
<wgrant> Because it's running multiple branches in one instance.
<lifeless> the check needs to be inlied
<lifeless> rather than as a wrapper
<wgrant> Yeah.
<spm> it's also been like that for about 1.5 years. so may be dated.
<lifeless> you could import the pqm queue class
<lifeless> or roll your own
<wgrant> Or ignore it and wait for tarmac.
<wgrant> It wouldn't be a problem if PQM didn't take 30 minutes to merge a 1-line diff.
<lifeless> remove the bzr lookups in the merge and tell pqm to do a lightweight checkout
<lifeless> very easy
<lifeless> wgrant: so tell me again why we have three tables filtering this query ?
<wgrant> lifeless: Hmm?
<lifeless> wgrant: anyhow, there is a low hanging fruit
<lifeless> wgrant: I've commented in the bug
<wgrant> lifeless: Thanks.
<lifeless> I suspect it can be made faster by not using except
<wgrant> I don't really know why it uses EXCEPT.
<wgrant> sinzui: p-r-f seems to be failing with an FTP connection error. Not sure how fatal it is.
<lifeless> wgrant: it can be made trivially simpler still by the obvious substitution of the relating column
<lifeless> but I doubt that will affect performance
<lifeless> wgrant: so in english, from the composite table bpb, pb, bfj, it wants - for all builds ever made in the archive, those with state 0 for which there is no spr with state6 ?
<lifeless> what is 0 and 6 ?
<wgrant> lifeless: 0 is NEEDSBUILD, 6 is BUILDING.
<lifeless> so this is packages for which none of the binarys have started to build?
<wgrant> lifeless: I believe so.
<lifeless> wgrant: is this used a lot?
<lifeless> I have 260ms on 11K packages
<wgrant> lifeless: It's used on Archive:+index, but only for copy archives will there be more than a few dozen builds.
<lifeless> wgrant: do you happen to know the 'and its done' row count?
<wgrant> lifeless: "and its done"?
<lifeless> the copy archive
<lifeless> we're at 15919
<wgrant> Sources?
<lifeless> yeah
<lifeless> 16077
<wgrant> I would have expected the copy to finish an hour ago.
<wgrant> Hmm.
<wgrant> Odd.
<lifeless> 'asuka'
<wgrant> Yeah, but on mawson it takes 15 minutes.
<wgrant> Although that was only for armel.
<wgrant> And main.
<wgrant> So 4000 builds, not 27000.
<wgrant> I guess that makes sense.
<lifeless> 25K binaries so far
<wgrant> Must be nearly there.
<wgrant> Since maverick is not quite as big as natty, and the natty archive had something like 27000
<wgrant> Ugh.
<lifeless> wgrant: anyhow
<lifeless>  count
<lifeless> -------
<lifeless>  17185
<lifeless> that was
<lifeless> 21:29 < lifeless>  count
<lifeless> 21:29 < lifeless> -------
<lifeless> 21:29 < lifeless>  17185
<lifeless> 21:29 < lifeless> (1 row)
<lifeless> 21:29 < lifeless> Time: 357.483 ms
<wgrant> Aha.
<wgrant> So it's quick now>
<lifeless> thats the query I've come pu with
<lifeless> I think we're done - 17332, 380ms hot.
<lifeless> wgrant: this one - https://bugs.launchpad.net/launchpad/+bug/709717/comments/3
<_mup_> Bug #709717: Archive:+index timeouts : ArchiveView.num_pkgs_building can be very slow <lp-soyuz> <oops> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/709717 >
<wgrant> lifeless: Give me a sec, just untangling the db-devel merge conflict.
<wgrant> StevenK: Is your recipe merger qa-ok?
<wgrant> It is an optional extra for the next deploy.
<wgrant> lifeless: Could you try https://bazaar.qastaging.launchpad.net/~launchpad-pqm/launchpad/production-stable?
<wgrant> It auths me properly, but I'd like a second check just in case.
<wgrant> Plus your username is longer.
<lifeless> OOPS-1860QSCB1
<wgrant> Good.
<StevenK> wgrant: It is, yes. I was waiting for the mail from the qa-tagger
<wgrant> StevenK: Great, thanks.
<lifeless> it prompted and passed me through
<wgrant> That'll be 20 minute off.
<wgrant> lifeless: yeah, it's still screwed, but it's qastaging, not auth.
<lifeless> ok
<wgrant> We are good to deploy 12309, yay.
<lifeless> we should fix that tomorrow
<wgrant> Yes.
<lifeless> faaaaaaaantastic
 * wgrant prepares the request.
<wgrant> Oh, damn, still need r12307.
<wgrant> But that's easy enough, particularly once allenap arrives in 20 minutes.
<adeuring> good morning
<wgrant> I think I want to patch qa-tagger to generate a deployment request template.
<lifeless> wgrant: theres an open bug for that
<wgrant> Since collecting these bug numbers is tedious.
<Ursinha> bug 667390
<_mup_> Bug #667390: provide wiki syntax bug links in deployable revision reports for easy copying to the LPS report <qa-tagger:Triaged by ursinha> < https://launchpad.net/bugs/667390 >
<lifeless> Ursinha: good morning ? :P
<Ursinha> lifeless, morning :P
<wgrant> Morning Ursinha.
<Ursinha> morning
<Ursinha> wgrant, I'd be happy to review your patch
<wgrant> I'm thinking about how it should handle rollback=
<wgrant> I'm not sure there is a sensible way.
<lifeless> offer a menu
<lifeless> or add in rollforward
<lifeless> which is just a yak shave away
<lifeless> night all
<wgrant> Night lifeless.
<Ursinha> good night lifeless
<mrevell> Hello
<wgrant> Hmm, that's a bit sad.
<wgrant> Ursinha: qa-tagger is crashing :(
<wgrant> ERROR:qa-tagger:Something went wrong when marking bugs: 'LPQAStagingDeployment' object has no attribute 'deployed_source_revno'
<Ursinha> wgrant, where are you seeing this?
<wgrant> Ursinha: https://devpad.canonical.com/~lpqateam/qa_reports/logs/output-launchpad-stable.log
<Ursinha> wgrant, let me look previous runs logs
<wgrant> Ah, it got a 504 from qas.
<wgrant> I guess it updated right then.
<Ursinha> ah
<Ursinha> yes
<Ursinha> is qastaging down?
<Ursinha> or was
<wgrant> It just updated.
<wgrant> It's up now.
<Ursinha> good
<allenap> Morning wgrant, what's up?
<Ursinha> there's a bug for this too
<wgrant> allenap: Morning. Could you QA r12307, or tell me how to do it?
<allenap> wgrant: Sure.
<Ursinha> bug 688082
<_mup_> Bug #688082: when qastaging is down deployment reports crash and stop updating <qa-tagger:Triaged> < https://launchpad.net/bugs/688082 >
<wgrant> It's not entirely obvious, and I'd like to get a rollout done ASAP.
<wgrant> Ursinha: Can you easily run it manually, or should I just wait?
<Ursinha> wgrant, I can, but maybe it's already running again
 * Ursinha checks
<StevenK> wgrant: Have you tagged my bugs, or should I?
<wgrant> StevenK: Can't until it runs.
<wgrant> I think it's */30, but I don't know for sure.
<wgrant> StevenK: The last run crashed.
<Ursinha> wgrant, yeah, it's running
<Ursinha> wgrant, */15
<Ursinha> wgrant, https://devpad.canonical.com/~lpqateam/qa_reports/logs/output-launchpad-stable.log
<Ursinha> on its way
<wgrant> Ursinha: Ah, I see. Thanks.
<adeuring> jtv: still aroud?
<Ursinha> wgrant, which revisions will you request deployment?
<wgrant> Ursinha: 12309
<allenap> wgrant: Looks fine, I'll update the bug. However, marking a bug as a duplicate is consistently timing out on qastaging, in recalculateBugHeatCache(). I'm pretty sure that's not my fault :)
<wgrant> allenap: That's been happening for weeks. It's fine.
<wgrant> Thanks.
<allenap> wgrant: Cool :)
<Ursinha> wgrant, I see bug 676372 is blocking other revisions in the report, is that really qa-bad?
<_mup_> Bug #676372: "Server denied check_authentication" from bazaar.launchpad.net private branch since 11926 deployed <bad-commit-12290> <lp-foundations> <qa-ok> <regression> <Launchpad itself:Fix Committed by wgrant> < https://launchpad.net/bugs/676372 >
<wgrant> Ursinha: I fixed that like two minutes ago.
<Ursinha> ah, right
<wgrant> Heh.
<wgrant> I forgot I had to manually fix that up, since the rollback was marked untestable.
<bigjools> Ursinha: up early?
<Ursinha> bigjools, yes sir
<bigjools> or, are you up late
<Ursinha> no, up early :)
<wgrant> That would be quite late indeexd.
<Ursinha> it's rarer to wake up this early than to be up this late :)
<bigjools> as I suspected :)
<wgrant> I find that I am more likely to be doing workish things when up early then when up quite that late.]
<bigjools> the fact that I can't restore any browser tabs with oops reports on them is seriously irritating
<wgrant> bigjools: jcsackett has a hack for that.
<wgrant> But I believe it's blocked on ISD.
<wgrant> And they are sprinting at the moment.
<bigjools> does it fix the throwing away of the ?arg ?
<wgrant> Yes.
<bigjools> \o/
 * bigjools goes back to AMI building
<Ursinha> bigjools, that's hateful
<bigjools> yes, it's making me sad
<wgrant> bigjools: AMI building again?
<wgrant> Do we have a new apt already?
<bigjools> the first one doesn't work
<bigjools> I need to build another to see why
<bigjools> something wrong with the database, it's not installed
<wgrant> bigjools: BTW, I shelved your a-f changes on DF.
<wgrant> Then DF crashed.
<wgrant> It seems to have survived, but don't be too surprised if something breaks.
<wgrant> (it stopped responding to ping and everything)
<bigjools> it's been rebooted
<wgrant> Right, bradm powercycled it.
<wgrant> Could find no explanation for its vanishment.
<wgrant> Somewhat concerning.
<bigjools> hardware
<wgrant> Almost certainly.
<bigjools> wgrant: so you QA'd jtv's CommandSpawner stuff?
<bigjools> the problem is that it does not fix that bug, it needs a new bug
<wgrant> bigjools: Right. It works fine, but does not fix the bug.
<wgrant> I will set it back to Triaged when I close everything else later tonight.
<bigjools> this is just highlighting that we need to QA revisions, not bugs
<wgrant> Yes, it is a bit of an issue. But I think the current process is pretty good apart from that.
<wgrant> Although qa-tagger seems to not be doing much right now.
<jtv> wgrant: Hi!  So you looked at my MF code?  On staging, or locally, or on dogfood?
<wgrant> jtv: MF?
<wgrant> a-f?
<bigjools> MotherForker....
<jtv> Well one of the names I considered was MotherForker.
<wgrant> Ah.
<wgrant> That would have been better.
<wgrant> Yes, I looked at it. Looks good. Even works on DF.
<jtv> I don't like calling classes "manager."  Unexpressive.
<jtv> Cool!
 * wgrant stabs merge conflicts in the face.
<bigjools> jtv: there's a backport of a-f available
 * jtv cruelly laughs at wgrant turn of phrase
<wgrant> jtv: That's the second set I've resolved in two hours.
<bigjools> I'd like to stab ec2 in the face
<wgrant> db-devel hates me.
<jtv> bigjools: fantastic!  But the code that needs that actually does run a-f in parallel.
<bigjools> how do you know?
<jtv> bigjools: are you asking me or wgrant?
<bigjools> jtv: either
<jtv> Sigh.
<jtv> The problem with the extra apt-ftparchive option only happens in the code that runs all apt-ftparchive instances in parallel.
<bigjools> I have a feeling we're not on the same page here
<bigjools> stub: around?
<jtv> bigjools: Okay, let's start again: "how do you know" what?
<stub> yo
<bigjools> stub: any idea why my new ami image is failing to find a PG instance?  http://pastebin.ubuntu.com/561519/
<bigjools> I am building a new one and pg seems to be installed...
<bigjools> jtv: how do you know that the parallelised version of your code works?
<stub> bigjools: looks like it is getting confused because PG 8.2 is installed
<jtv> bigjools: we don'tâso far we only know that we can't run the parallel version on lucid's a-f.
<stub> bigjools: And PG 8.4 is not...
<bigjools> stub: 8.2 is not installed
<jtv> bigjools: I was saying "that's fantastic" because the backport removes that obstacle, not because Now Everything Works Perfectly.
<bigjools> jtv: ah :)
<bigjools> irc is great
<jtv> *However*
<stub> grep isn't finding some critical files anyway, so PG 8.4 is not setup on that box or setup weirdly, like in a chroot
<jtv> it would also be really really nice if we could now proceed to establish that it works.
<jtv> bigjools: yes this is something I hate about IRC too.
<bigjools> stub: can you help me debug it please?  I am ssh'ed into the instance as  it's building the image
<stub> bigjools: When I've installed PG under Ubuntu, /etc/postgresql/8.4/main/* exists. On that box, it looks like it doesn't.
<bigjools> /etc/postgres is not there at all
<jtv> postgresql, not postgres
<bigjools> just /etc/postgresql-common/
<stub> If it is there, then the script is buggered. If not, the PG package installation is buggered. Maybe needs some dpkg magic to set it up?
<bigjools> /etc/postgresql is not there at all either
<jtv> I think I added some looping over available postgres versions at one point.
<stub> I'd uninstall and reinstall the PG packages
<jtv> What do you get for ls /etc/init.d/postgres*?
<bigjools> stub: /etc/postgresql/8.4/main/ does not exist on mawson, yet it has a functioning database ...
<jtv> ahhh
<jtv> launchpad-database-setup loops over known postgres versions, from latest to oldest.
<jtv> It stops at 8.2, but doesn't check for the case where it didn't find anything.
<bigjools> jtv: exactly :)
<bigjools> I have /etc/init.d/postgresql-8.4 installed
<stub> That script would fail on mawson too then. If PG is setup in a strange way, it won't work because files it needs are not where it expects them.
<stub> This is lucid?
<bigjools> yes
<stub> I have /etc/init.d/postgresql
<bigjools> yeah that's maverick
<stub> So I'd say the package is installed but some step hasn't been run. dpkg reconfigure or whatever (I just stick to the gui tools).
<bigjools> I am just running the "bin/ec2 update-image" script ...
<bigjools> that's all that's in the desctructions at https://dev.launchpad.net/EC2Test/Image
<stub> I can't really help - I know bugger all about packages or ec2 images.
<wgrant> stub: Want to review https://code.launchpad.net/~wgrant/launchpad/nightly.sh-fixes/+merge/48441?
<wgrant> (I have to wonder why this is in the tree at all...)
<bigjools> stub: well, here's a clue.  Trying to start the PG server and literally nothing happens.
<bigjools> not even a message to the terminal
<wgrant> Sounds like you might have -common installed, but not the server itself.
<wgrant> init scripts will generally exit early if the binary is not present.
<bigjools> /usr/lib/postgresql/8.4/bin/postgres
<jtv> Or in this case, if /usr/share/postgresql-common/init.d-functions is not present.
<bigjools> they are there
<jtv> It may help to know what return code you get when you run the init.d script.
<bigjools> remind me of the bash-fu to get that?
<jtv> echo $?
<wgrant> echo $?
<jtv> right after the command.
<bigjools> 1
<jtv> So it's not all those nice "am I installed" checks.
<jtv> Note the init.d script runs with -e, so it can be an implicit failure.  Of anything.
<adeuring> jtv: could you have a look at this MP: https://code.launchpad.net/~adeuring/launchpad/bug-705652/+merge/48437 ?
<jtv> adeuring: I will, yes!
<adeuring> jtv: thanks!
<bigjools> it's because /etc/postgresql/ is missing, it just bails out
<bigjools> no package owns that directory
 * bigjools gets caffeine in the hope that the answer will come
<jtv> Good idea!
<jtv> Colour me copycat.
<Ursinha> â
<stub> wgrant: Fine here. mthaddon might want a look (https://code.launchpad.net/~wgrant/launchpad/nightly.sh-fixes/+merge/48441 )
 * stub waits for the intertubes to let him click 'approve'
<wallyworld> wgrant: any idea why stuff is so slow to get merged into devel once ec2 has finished with it. and also deployment to qastaging seems slower than usual?
<mthaddon> wgrant: we tend to prefer the $(command) vs. `command` convention
<mthaddon> (handles escaping slightly better, not that that's relevant here)
<wgrant> mthaddon: Ah, I just used the same as the old code.
<wgrant> I will fix.
<wgrant> wallyworld: ec2 takes a lot longer since windmill was reenabled, and there has been a bit of a PQM backlog the last couple of days.
<wgrant> wallyworld: qastaging deployment can also be slow because of the PQM backlog.
<wgrant> And buildbot is slow.
<wgrant> And buildbot fails a lot now.
<wallyworld> wgrant: yeah, i have probably 3 branches that i want to qa before pqm closes and i am waiting for them to appear on qastaging
<wallyworld> why is buildbot so flakey?
<wgrant> wallyworld: It should start updating in about 30 seconds.
<wgrant> wallyworld: To 12314, I believe.
<wgrant> wallyworld: Windmill and those spurious librarian failures.
<wallyworld> \o/
<wgrant> And the occasional bad branch :P
<wallyworld> :-P
<gmb> Windmill is making me sad today.
<gmb> Just wanted to spread it around.
<wallyworld> share the love
<bigjools> I need to punch something
<gmb> Thing is, it's so easy to come to the conclusion that Windmill is the thing that's to blame rather than my shoddy code.
<bigjools> stub, jtv: TADA
<bigjools> "Error: The locale requested by the environment is invalid."
<bigjools> when installing PG
<bigjools> it didn't like my LC_LANG of en_GB.utf8
<bigjools> now, how do I override that in the setup script
<danilos> allenap, hi, I assume bug 151129 is not really fix committed (marked by qa-tagger for one of your branches?)
<_mup_> Bug #151129: Can't subscribe to a tag <bad-commit-11972> <bugtag> <lp-bugs> <lp-dogfood> <qa-ok> <story-better-bug-notification> <story-subscribe-to-search> <ubuntu-qa> <Launchpad itself:Fix Committed by yellow> < https://launchpad.net/bugs/151129 >
<danilos> allenap, fwiw, we believe we've got a lot more work to do on this, and I am not sure what's the best way to indicate this in the bug tracker now that we are using bugs for QA as well
<wgrant> danilos: I try to set those sort of bugs back to In Progress when I close the rest after a deployment.
<wgrant> It might be nice if we could tag them somehow to prevent qa-tagger from changing the status, though.
<danilos> wgrant, yeah
<danilos> wgrant, incremental?
<stub> bigjools: LC_LANG=C ./whateveryouarerunning ?
<allenap> danilos: I had a discussion with lifeless about this yesterday. I've agreed to only land one branch per bug in the future. It is fix committed for the last branch, fix released in spirit.
<bigjools> stub: I meant LC_TIME
<bigjools> but yeah, about to try that
<wgrant> danilos: --incr prevents QA tags, though.
<allenap> danilos: Apparently that causes landing to be marked untestable.
<wgrant> Right.
<gmb> So, interesting fact: Windmill doesn't work over X-forwarding.
<bigjools> it does for me!
<bigjools> well, define "work"
<danilos> allenap, ah, ok
<wgrant> mthaddon: The diff is updated with your requested changes.
<wgrant> It even still works.
<mthaddon> wgrant: looks good
<wgrant> wallyworld: qastaging should be on 12314 in half an hourish.
<gmb> bigjools: Well, it loads, then it just sort of stops whilst waiting for a pageload.
<bigjools> gmb: oh, it always got further than that for me
<gmb> Yeah, well, it's Windmill.
<wallyworld> wgrant: cool. thanks. i hate waiting
<gmb> Let's not expect consistency here.
<jtv> adeuring: don't you mean logger.getEffectiveLevel() > logging.WARN, i.e. with ">" instead of "<="?
<wgrant> That often happens even without X forwarding...
<gmb> Hah.
<jtv> adeuring: sorry, >=
<bigjools> It was whenever I forgot to set DISPLAY= before running the tests on a machine I'd ssh'd to
<wgrant> wallyworld: I think these deploys would become a lot faster if we cached the built eggs/ dir.
<gmb> Also, it's doing it's "I'm going to fail at random points" thing.
<gmb> I suspect that the timeouts are a touch too short.
<bigjools> or windmill is pants
<gmb> Well, that.
<wallyworld> wgrant: for sure
<bigjools> I think, at the 3rd attempt to build a new AMI, it's DTRT at last
<wgrant> Yay, private codebrowse works on production again!
<bigjools> wallyworld: you are a crazy guy - up at 3am - and you're still up?!
<wgrant> stub, mthaddon: Thanks for the reviews.
<wallyworld> bigjools: no rest for the wicked :-)
<gmb> allenap: Are you OCRing today?
<adeuring> jtv: no, I think level <= WARN is correct:
<allenap> gmb: Oh yes. What have you got for me?
* allenap changed the topic of #launchpad-dev to:  https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: allenap | https://code.launchpad.net/launchpad-project/+activereviews
<adeuring> >>> import logging
<adeuring> >>> logging.DEBUG
<adeuring> 10
<adeuring> >>> logging.WARN
<adeuring> 30
<adeuring> >>> logging.ERROR
<adeuring> 40
<gmb> allenap: JS fun and games: https://code.launchpad.net/~gmb/launchpad/make-subscriptions-editable-bug-710603/+merge/48359
<gmb> allenap: To test the UI you need to add a feature flag for "malone.advanced-subscriptions.enabled"
<allenap> gmb: I chose a bad day to quit glue sniffing.
<gmb> Yeah.
<gmb> My sympathies.
<allenap> gmb: Okay, how do I add a feature flag?
<gmb> allenap: Using PSQL works quite well. Hang on, I'll paste you the necessary.
<gmb> allenap: http://pastebin.ubuntu.com/561875/
<allenap> gmb: Ta.
<wgrant> allenap, gmb: There's UI too.
<wgrant> I used it on DF earlier.
<wgrant> It's pretty nice.
<gmb> wgrant: I always forget about that because it needs rubber ducky powers in production / staging / qastaging
<gmb> But you're right.
<allenap> wgrant: Is it a big textarea? Truth be told, I don't understand feature flags properly so it was greek to me.
<jtv> adeuring: you're right :)
<wgrant> allenap: It's a big textarea, yes. But it is very pretty and shows diffs and avoids SQL, and has a link to a page which documents possible flags and scopes and their values.
<allenap> wgrant: Neat :)
<jtv> adeuring: it may help to extract that piece of code into a function by the way.  The script (mea culpa) does far too little of that.
<adeuring> jtv: right, makes sense
<jtv> adeuring: btw looking at this brings up a far greater concernâthe script in its current form is hard-wired to remove Ubuntu translations.  Won't work for upstream ones AFAICT.
<adeuring> jtv: do you mean setting is_current_upstream?
<jtv> Which isn't surprising really, given that the bug mentions making it side-aware.
<adeuring> jtv: setting is_current_upstream would be even more difficult.
<jtv> Well it may need to set either is_current_upstream or is_current_ubuntu, depending on which side the template is on.
<adeuring> I discussed this woth Henning and Danilo, and we agreed that it is not worth the effort to implement this
<jtv> There's a helper class, TranslationSideTraits, which knows things like "what is the name of the flag that applies for translations on this side."
<adeuring> jtv: I know about this class -- the main issue is: Setting an Ubuntu translation as current in upstrem might simply be wrong...
<jtv> Yes, but that's a separate policy issue.
<jtv> Isn't that basically just a big "if" around the unmasking code?
<danilos> jtv, from my glance at the script, it seems to have both is_current_upstream and is_current_ubuntu options
<danilos> jtv, and it seemed pretty symmetric to me, fwiw
<danilos> (other than the "unmasking")
<jtv> danilos: it has both options for what exactly?
<adeuring> I don't think it works for is_current_upstream. But making the script "more symmetric" regarding finding another is_current_(upstream|ubuntu) would affect poilcy...
<jtv> Yes, but that's only the unmasking code which should simply be skipped when deleting on the upstream side.
<danilos> jtv, it has an option for removing is_current_ubuntu translations, and option for removing is_current_upstream translations
<adeuring> well, you can delete translations for upstream and ubuntu in one script run.,..
<jtv> danilos: oicâyes, so it should be able to do both.
<jtv> Ah
<danilos> jtv, adeuring: the only thing is that you have to specify the side yourself when you run the script, other than that I think it's fine
<jtv> I'm looking againâ¦ maybe it's just the unmasking code that has the hard-coding.
<adeuring> danilos: ? you can set --is-current-upstream and --is-current-ubuntu, but this affect the filter which messages shall be dleteld
<adeuring> but it does not affect the question if any other translation should become current instead
<danilos> adeuring, right, that's what we are calling "unmasking" (as per the code itself, fwiw :)
<jtv> danilos: I think he means the asymmetry in when we should unmask.
<adeuring> well, ok... but... perhaps I am a bit slow, but what does this mean for the script?
<jtv> In other words, the fact that unmasking on the upstream side is dangerous because it activates Ubuntu messages in upstream.
<adeuring> jtv: right, that's what I mean
<danilos> jtv, right, but I believe we have hard-coded unmasking only for ubuntu side, because that's the only thing that made sense in the past
<danilos> worth checking, of course :)
<jtv> At the moment that's a bit implicit in the code (even though it's well-documented); it may make sense to extract unmasking into a function and put an "if" around it.
<danilos> jtv, sure, agreed
<danilos> anyway, I am just introducing more confusion into the discussion, so I'll be quiet :)
<jtv> No, no, it's fun!
<danilos> heh, it sure is :)
<jtv> adeuring: I _think_ the script only removes messages on one, user-selected side (ubuntu or upstream).
<jtv> What may not have been worth the trouble, but would have been nice, is to detect automatically which side that should be based on what templates are selected.
<adeuring> jtv: well, you have a ton of options to select messages. If you specify simply IDs, both sides can be affected
<jtv> ah, clever!
<jtv> Never even thought of supporting that, to be honest.
<adeuring> similar for filtering ny reviewer or translator
<jtv> Sorry for all the confusion; I'm a bit rusty with this script.
<jtv> The "current_ubuntu" and "current_upstream" flags are further filters, not choices of side.
<adeuring> jtv: well, my main conclsuion regarding bug 705652 was: it's not worth to make the script more clever, but it makes sense to give more warning
<_mup_> Bug #705652: Make remove_translations side aware. <upstream-translations-sharing> <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/705652 >
<jtv> One relatively simple option might have been to require that the caller choose a side.
 * gmb -> lunch
<adeuring> ...and I removed the clause "imported.potemplate = doomed.potemplate" because does not seem to make sense
<gmb> allenap: I'll respond to your review when I return.
<allenap> gmb: Cool. I haven't done it yet :)
<adeuring> jtv: ok, we can do that. But how would that be an important feature?
<jtv> adeuring: yes, I think that's a holdover from a relatively mechanical conversion.
<jtv> adeuring: true, feature-wise all it brings us is more speed and limited protection against typos in ids.
<jtv> Which isn't a huge deal.
<jtv> I'll try to stay away from the bikeshed.  :)
<adeuring> I am more inclined to make the script simpler... like the clean up of the WHERE clause. I neede some time to figure out that it was just obsolete...
<jtv> Yes, that's also why it's there: massive conversion to the new model didn't allow us much time to contemplate that.
<jtv> So we thank you for spotting it.
<deryck> Morning, all.
<adeuring> morning deryck
<jtv> adeuring: It does raise the question: does removing a diverged translation unmask a shared one?  But that's not a "sides" issue, more a concern about a previous migration.
<jtv> Or wait.
<adeuring> jtv: I think it does. But isn't this a useful feature?
<jtv> Yes.  It gets complicated in unexpected ways: deactivating a diverged message should unmask an underlying shared one, not a shared one from the other side.
 * jtv ponders
<adeuring> jtv: if we try to figure out if there was another diverged translation being is__current_whereever before, we're close to the undo feature...
<jtv> No, no, previous diverged translations can go take a hike.
<adeuring> that would be really cool, but it should not be implemented in this script, i think
<jtv> We don't _like_ translations to be diverged.  :)
<adeuring> maybe, but I think there are valid/useful situation
<jtv> Well we do support them.  We just don't encourage them.  :)
<adeuring> but anyway, if we unmask a shared thanslation automagically, that's just fine, isn't it?
<jtv> Yes, I was just verifying that the new code does that.
<jtv> (The "Imported" table aliases in the queries are misleading by the way: that's a name from the old model.  Now they would be either Upstream or OtherSide, depending)
<jtv> (Or Alternate)
<adeuring> jtv: can we leave this for a another "cleanup" bug?
<jtv> Sure.
<jtv> Sorry to hold you up like this; I need to restore a lot of forgotten detail in order to grok the work.
<jtv> I didn't know about the log handler.  You make nice use of it.
<jtv> adeuring: in the last paragraph of the diff, "current" really should be "ubuntu" or future readers will misunderstand.
<adeuring> jtv: right, that should read "When a shared, current Ubutnu message is deleted..."
<jtv> Well maybe not Ubutnu.  ;-)
<adeuring> sure ;)
<jtv> adeuring: meanwhile, you have my vote.
<jtv> Thanks for doing this.
<adeuring> jtv: Thanks!
<jtv> Ursinha: did you paste that coffee cup (e.g. from the character map), or do you know of a way to type it?  It's so incredibly useful.
<Ursinha> jtv, I pasted
<jtv> Ah blast â¹  I would so love to be able to type this (without customizing config I can barely read)
<wgrant> I think we need to add it to the compose key map and SRU to all supported releases.
<Ursinha> me too!
<jtv> Yes!
<Ursinha> hahaha
<jtv> I want my "ij" ligatures too.  But I'm told they're discouraged now.
<salgado> jelmer, do you know of a good howto-style guide for using bzr and Launchpad?
<jelmer> salgado: I think one of the bzr docs describes it pretty well. Let me see if I can find a link...
<jelmer> salgado: http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html?highlight=launchpad
<salgado> jelmer, cool, thanks!
<jtv> jam: free to discuss bug 701329 today?
<_mup_> Bug #701329: loggerhead OOPS - error: [Errno 32] Broken pipe <oops> <Launchpad itself:Triaged> <loggerhead:Invalid> < https://launchpad.net/bugs/701329 >
<bigjools> this ec2 management stuff is archaic
<jtv> bigjools: which is great because we'll also need that backport in our AMI.
<bigjools> and now my 4th attempt at making an AMI
<gary_poster> stub, hey.  Could you take a look at https://code.launchpad.net/~gary/launchpad/bug548-db-2/+merge/48318 ?  I had to change it significantly.  allenap, you would be a great code reviewer too, if you are willing and able.
<allenap> gary_poster: Okay, cool.
<LPCIBot> Project devel build (414): STILL FAILING in 6 hr 15 min: https://hudson.wedontsleep.org/job/devel/414/
<LPCIBot> * Launchpad Patch Queue Manager: [r=sinzui][ui=sinzui][bug=708436] Fixed the width of the tag list so
<LPCIBot> it doesn't wrap (bug #708436).
<LPCIBot> * Launchpad Patch Queue Manager: [r=stevenk,
<LPCIBot> thumper][ui=sinzui][bug=670452] Add display of related branches to
<LPCIBot> recipe add and edit pages
<_mup_> Bug #708436: Bug tag list wrapping <css> <qa-needstesting> <ui> <Launchpad itself:Fix Committed by huwshimi> < https://launchpad.net/bugs/708436 >
<LPCIBot> * Launchpad Patch Queue Manager: [r=stevenk, thumper][bug=654585,
<LPCIBot> 710291] Linkify and preserve line breaks in the bug acknowledgement
<LPCIBot> message.
<LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=680733] Fix query used to load recipe build
<LPCIBot> jobs so those which have failed to build expire off the recent
<LPCIBot> builds list as expected
<LPCIBot> * Launchpad Patch Queue Manager: [rs=sinzui][ui=none][bug=711527][no-qa] Migrate widgets to the lp
<LPCIBot> tree.
<gary_poster> thank you
<jtv> bigjools: is there anything I need to do to get the a-f backport rolled out (df, *staging, AMI, production)?
<bigjools> jtv: file an RT to get the package installed on DF + cocoplum, plus PQM and buildbot
<bigjools> the AMI you need to do yourself, but please wait since I am currently doing one
<jtv> bigjools: OKâ¦ where do we keep this backport?
<bigjools> jtv: the losas will install it to CAT, but we also need to copy it from mvo's PPA to the launchpad PPA
<bigjools> put it in the LP PPA first
<jtv> bigjools: what _is_ CAT?
<bigjools> and make it a dependency of launchpad-dependencies
<bigjools> canonical admin team
<jtv> _thank_ you!
<bigjools> they have their own prod repo
<jtv> They run a business reposessing cattle prods?
<bigjools> this is a good time to go to lunch methinks
<gary_poster> stub, thank you again.
<gary_poster> I did a fair amount of changes and investigation--and had to throw out some of the more interesting parts of your patch--because I thought you actively wanted to separate person and team bits.
<gary_poster> Would you like me to throw together another branch just with the verbose_bugnotifications changes?  It would probably be easy.
<gary_poster> I tended to think that it would be easier to have a shared settings object too, but it is true AFAIK that selfgenerated_bugnotifications will be specific to people and not teams, so attributes like that exist (I think).
<gmb> allenap: Yay for fragile JS.
<gmb> I'll look into that shortly.
<allenap> gmb: Yeah :) You can ignore [2] and on, don't worry, they're just my mumblings. And [1] is only a suggestion.
<gmb> Noted, thanks.
<stub> gary_poster: I do want PersonSettings and TeamSettings separate. But your observation threw a spanner in the works. We need to think more about settings shared between teams and people before moving them to PersonSettings.
<gary_poster> stub, ah ok.  cool, I'll leave it alone then.  Thanks
<deryck> henninge, I'll just take a look at the branch for you now.  to review it.
<henninge> deryck: thanks, I'll look at Aaron's
<henninge> deryck: did you just hear me OK or was I a bit faint?
<deryck> henninge, no, I heard you fine.
<henninge> ok, cool
<deryck> henninge, what's the bzr ignore for .idea for?
<henninge> deryck: I am trying out pyCharm, the idea that Ian demostrated in Dallas.
<henninge> deryck: that is using that directory.
<deryck> ah, ok
<deryck> henninge, and what have you disabled for pylint in the test?  (Sorry don't know those codes myself.)
<henninge> oh, that must be a copy-and-paste error ... ;)
<henninge> deryck: I'll remove that.
<deryck> henninge, ok, cool.
<LPCIBot> Project db-devel build (338): FAILURE in 5 hr 0 min: https://hudson.wedontsleep.org/job/db-devel/338/
<deryck> gah!  adeuring, call time.  Sorry.  Was doing henninge's review.
<adeuring> deryck: no problem
<henninge> yeah right, blame it on me ... ;)
<deryck> adeuring, let's bump it a half hour, if that doesn't throw you off.  and let me finish this review.
<adeuring> deryck: sure, let's do that
 * deryck always blames henninge 
<deryck> :-)
<deryck> henninge, I have questions/comments about the review... can we get on Mumble for higher bandwidth?
<jml> sinzui: hi
<sinzui> hi jml
<jml> sinzui: what's the status of the team subscription policy discussion?
<sinzui> I am resolving a merge conflict now. I will send it to ec2 in 25 minutes
<leonardr> allenap, would you like to review a wadllib branch? they're incredibly rare
* jcsackett changed the topic of #launchpad-dev to:  https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: allenap, jcsackett | https://code.launchpad.net/launchpad-project/+activereviews
<leonardr> jcsackett: maybe you want to review it? https://code.launchpad.net/~leonardr/wadllib/what-kind-of-link/+merge/48485
<jcsackett> leonardr: sure.
<leonardr> aargh... did someone do a 1.1.8. of wadllib and not tell me? how did this happen?
<bigjools> latest devel pull is giving me a conflict on lib/canonical/widgets.moved
 * sinzui hands leonardr a dagger.
<sinzui> bigjools: I just got that
<leonardr> the trunk says 1.1.7, but pypi says 1.1.8
<bigjools> sinzui: and Conflict adding file lib/canonical/widgets.
<sinzui> I was going to send an email when I got distracted by seemingly impossible merge conflicts with lp.bugs.emum
<bigjools> I am freaking doomed trying to land my branch
<sinzui> bigjools: rm -r lib/canonical/widgets.moved, then resolve the three listed dirs
<bigjools> sinzui: yeah, I just wish I'd not encountered it in ec2.... :)
<sinzui> right. Why did it land without a conflict?
<jml> sinzui: oh, as in you're landing a patch? great news :D
<sinzui> jml: yes. mrevell approved the text/help revisons a few hours ago
<allenap> leonardr: Yeah, sure.
<leonardr> allenap: jcsackett has it
<allenap> leonardr: Okay. I would have to choose now to get a cup of tea. Next time.
<sinzui> allenap: do you have time to review https://code.launchpad.net/~sinzui/launchpad/itemswidgets-term-title-1/+merge/48483
<allenap> sinzui: Sure.
<allenap> sinzui: I got an Unauthorized error followed by Chromium's "This web page is not available".
<allenap> sinzui: Back to simple Unauthorized now: http://pastebin.ubuntu.com/562026/
<allenap> Any ideas?
<jtv> <mutter>It's the zcml, you'll see.  Knew it the first time I met it.</mutter>
<jcsackett> leonardr: r=me, with a few suggestions. i've requested follow up from sinzui.
<leonardr> ok
<sinzui> allenap: someone change my branch to private without making suer we can access.
<sinzui> branch privacy is "funking" retarded
 * sinzui looks
<sinzui> sweet only me and admins can see the branch
<sinzui> allenap: I subscribed you to the branch
<allenap> sinzui: Thanks, got it.
<sinzui> I see we have ~launchpad-reviewers setup to leak private information to a list
<allenap> sinzui: Perfect :)
<leonardr> jcsackett, sinzui: i've incorporated your comments and i've also been able to reconstruct the missing version 1.1.8 (benji's fault)
<bigjools> so it turns out that ec2 land doesn't warn about uncommitted revisions.... :'(
<jtv> ouch
<jcsackett> leonardr: cool.
<jml> branch up for review: https://code.launchpad.net/~jml/launchpad/sphinx-it-up/+merge/48502
<leonardr> jcsackett, sinzui: i added another useful method while i was at it. it's revision 23 and very simple
<jcsackett> leonardr: looks fine by me.
<sinzui> leonardr: r=me
<maxb> AWOOGA: Code import farm is broken. SourceForge have changed their SSL certificate such that every https: import now blocks with a "This certificate is untrusted: (R)eject, accept (t)emporarily or accept (p)ermanently?" prompt, until the import times out after an hour.
<maxb> I think we need to find a LOSA to use SQL to suspend all code imports matching https://%.svn.sourceforge.net/%
<maxb> gary_poster: It's not exactly CHR, but.... ^^^
<gary_poster> maxb, ack, I'll try to wave my arms around.  ythanks
<leonardr> jcsackett: maybe you want to take the follow-up branch as well
<leonardr> https://code.launchpad.net/~leonardr/lazr.restfulclient/know-your-limitations/+merge/48511
<jcsackett> leonardr: sure.
<jcsackett> jml: sorry, missed your branch up for review. i'll hit it after leonardr.
<jml> jcsackett: thanks.
<jcsackett> unless allenap is already looking at it.
<allenap> jcsackett: Nope, not yet.
<gary_poster> maxb: is the certificate change legitimate and permanent?  I don't see an announcement with a quick google search
<maxb> uncertain. I just know it's breaking the importd farm right now. Furthermore, due to the way svn stores certificate exceptions, it would need an exception stored for *each separate sourceforge project*, so that's not feasible
<henninge> abentley: Thanks for the reply! Can you please push your changes? Or are you not done yet?
<abentley> henninge, I have pushed my changes and emailed a diff.
<henninge> hm
<abentley> Well, I emailed a diff.  Now I've pushed the changes.
<henninge> ah, there is the diff! Thanks!
<abentley> henninge, I replied before I started work, so that if you had further comments, I would get them sooner.
<henninge> ah!
<henninge> abentley: only other comment is that you could use ResultSet.is_empty() but that is just an optimization.
<henninge> abentley: thank you for the fixes, r=me
<abentley> henninge, thanks.
<gary_poster> emergency-ish: who is on bug rotation right now?
<gary_poster> that is here and available to do some investigation?
<gary_poster> deryck, do you happen to know where I can find a list of people on bug rotation?
<gary_poster> ah, flacoste's email might work...
<deryck> gary_poster, hmmm, I feel dumb.  I don't know what bug rotation is.
<gary_poster> deryck, I mean, not doing feature work
<gary_poster> squad stuff
<deryck> gary_poster, ah.  red and green, I believe.
<gary_poster> ok thanks
<deryck> gary_poster, "bug rotation" sounds much better than "import work" :-)
<gary_poster> :-)
<deryck> gary_poster, gah.  ruined my funny.  that was meant to be "interrupt work" but yes, the two names are equivalent often.
<gary_poster> heh, yeah
* allenap changed the topic of #launchpad-dev to:  https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: jcsackett | https://code.launchpad.net/launchpad-project/+activereviews
<allenap> jcsackett: If you have time, would you be able to take a look at https://code.launchpad.net/~allenap/launchpad/remove-addChangeNotification/+merge/48351? I won't be around to ask question of though.
<jcsackett> leonardr: your diff shows you bumbing wadllib to 1.20; i thought even given the oddities in wadllib version we were now at 1.19?
<gary_poster> maxb, do you happen to have some specific failing branches you could send me very quickly?
<gary_poster> links
<jcsackett> sinzui: think you might be able to mumble around 1pm? i finally got some test runs back for the not-ec2ing assertion error branch, and have a weird error i cannot figure out.
<sinzui> jcsackett: I have interviews at 1 and 3
<jcsackett> sinzui: nevermind then. :-)
<maxb> gary_poster: Pretty much anything currently on the importds: https://code.launchpad.net/+code-imports/+machines (because each problem import sticks around on the importds for 1 hour)
<gary_poster> maxb, many thanks
<jcsackett> allenap: looking at your branch now.
<sinzui> mbarnett: maxb I see https://dev.launchpad.net/ReviewingCodeImports suggests changing https to http for SF. Do either of you know if there are projects that are https-only
<maxb> urgh
<maxb> that wiki page advice is greivously out of date
<maxb> I now change all new sf imports *to* https, because they have stupid connection timeouts on http that break long operations
<sinzui> I suspected as much. I found it from an obsolete CHR page
<leonardr> jcsackett: i decided to take it to 1.2.0 since i added new features
<jcsackett> leonardr: okay, cool. i missed that bit.
<maxb> If we change all existing URLs to http, most of them will probably keep going because they'll only be importing a few revisions at a time. However, new imports over http from SF generally fail
<maxb> So it might be worth doing that, to preserve service levels as best we can
<danilos> deryck, hi, do you happen to know if BugNotificationRecipients are "expanded"? (i.e. if we are creating notifications for entire team, we evaluate it and create them by person instead)
<deryck> danilos, I believe the rule is "if the team doesn't have a contact address, send to individuals"
<danilos> deryck, right, but do you know where is that rule applied? I'm trying to modify addChange/addChangeNotification to remove the changee if they don't want email they generated themselves (by using recipient_set.remove(changee)), but I just figured that we might have a team in there which includes the changee, so that might not work
<danilos> deryck, I guess it's best if I write a test for this just to be sure :)
<deryck> danilos, I'm looking at the code.  I assume it's where the recipient list is built, but am checking....
<danilos> deryck, I was doing the same thing, and then figured it's faster to ask :)
<deryck> danilos, yeah, no. :-)  Sorry, but I never could keep this all in my head.
<deryck> it's moved around a bit lately, too.
<danilos> deryck, yeah, I know, and it's still moving around according to allenap :) anyway, I wrote a test which confirms that team is in the list of notifications, which means that it's just a tad bit harder for me to figure out :)
<deryck> danilos, lib/canonical/launchpad/doc/notification-recipient-set.txt confirms how it all works.
<danilos> deryck, basically, since notifications are async, we don't have enough information to decide this when they are actually sent out
<danilos> deryck, how would you feel about: 1) adding "changed_by" DB column to BugNotification and/or BugNotificationRecipient and 2) flattening out teams for which the changer is member of?
<danilos> deryck, I'm leaning to 2), and I'd only do it when the "changer" actually wants to suppress email for his changes, but if this happens inside POST requests, it'd be a terribly bad idea
<deryck> danilos, so the point is to suppress my own emails, if I've selected this as a configurable option for bug mail?
<danilos> deryck, exactly
<danilos> triple digit bug, fwiw, 548 :)
<deryck> hmmm, db change seems heavy weight.  I would think we could turn this off when we build the recipient list.  or is the db column for performance?
<danilos> deryck, well, it'd move any harder decision logic back to the backend, so yes, DB field would be for performance
 * deryck is thinking
<danilos> deryck, basically, if we don't introduce "changer" in the DB, we'd have to evaluate all team members and add notification rows for each of them except the "changer" (in this case: I wouldn't change how it behaved previously)
<danilos> deryck, and since this might be happening on each change to a bug through a web page, if there's a very large team a person is a member of, it may mean a very large number of rows being inserted, and we know that causes trouble
<danilos> deryck, (iow, I've stopped leaning to 2, and lean more to 1 now, though I'd love to be told that 2 is better because it's easier :)
<deryck> I'm not convinced we need either :-)
 * deryck is still thinking
<danilos> deryck, excellent, I'd be happy to hear any other option :)
<danilos> deryck, (though, to be honest, I don't believe there is any other option, but I'd be delighted to be proven wrong :)
<lifeless> danilos: deryck: FWIW I'd probably add change to the notification if its not there already
<lifeless> but I'm simple minded
<lifeless> *changer*
<deryck> danilos, lifeless -- so I would favor just changing construct_email_notifications to drop the notification if person has this config flag set and he/she is the changer.  can we not work out who the changer is from that function?
<deryck> I thought if person == email_person in that function, we would have the changer.  but I'm not entirely sure, even after having read through it all, jumping around a bit now.
<danilos> deryck, there's nothing in either of bugnotification/bugnotificationrecipient which can tell us who the changer is
<danilos> deryck, we can probably parse one of rationale or something but that'd be pretty fragile
<danilos> lifeless, so, I am generally in agreement, thanks for the support :)
<deryck> danilos, who is BugNotification.message.owner  ?
<danilos> deryck, I don't know, but isn't that just for comments?
<leonardr> sinzui, the sooner you can mentor jcsackett's review of my lazr.restfulclient branch, the better--it's all i need to land a huge launchpad branch
<danilos> deryck, fwiw, bugnotificationrecipient.person is the actual recipient (eg. a team in the case I want to solve)
<sinzui> leonardr: I am on the phone at the moment I will get to it in 30min
<leonardr> sinzui, ok
<deryck> danilos, I thought "message" was the message being sent, not just a comment.
<lifeless> deryck: does construct_email_notifications run in the webserver context ?
<deryck> lifeless, nope
<danilos> deryck, and you are right, it is the message being sent
<lifeless> so something a little unrelated
<lifeless> that I'd like us to do
<danilos> deryck, and owner does seem to be the person who changed stuff, wooohooo
<lifeless> is to setup valid participations in backend services
<deryck> danilos, so if the message owner is the person who created the notification -- i.e. the changer -- then I see no point in storing that in the db.  especially since this runs offline.  however....
<deryck> danilos, if I'm wrong, feel free to add a column. :-)
<lifeless> this would let you look up the participation to find out who the work is being done on behalf of
<danilos> deryck, agreed
<deryck> danilos, the down side of adding it if it's already there, is that people will create new queries where none exist today.  just cause they can :-)
<danilos> deryck, yeah, it's just that I didn't really understand what message was, but you were right all along
<deryck> danilos, no worries.  Wasn't trying to prove myself right.  Just wanted to avoid more columns if we could.
<danilos> deryck, there are plenty downsides to unneeded redundancy, so let's not go into that :)
<deryck> and I wasn't completely sure, honestly. :)
<deryck> danilos, right :-)
<danilos> deryck, heh, well, you did prove yourself right, cheers :)
<deryck> cheers :-)
<danilos> deryck, btw, where is the code that actually assembles notifications for sending then? :)
<danilos> deryck, (I've so far not touched on that side of things, only up to the point of creating BugNotification records)
<deryck> danilos, in lp.bugs.model.bug start with addChange and work your way down :-)
<danilos> deryck, heh, actually, that's this side of things that I have touched; it seems it might be bugs/scripts/bugnotifications.py
<deryck> danilos, ah, the look up side.  sorry.  yes, that script.  the first function there is what you want.
<danilos> deryck, thanks, very useful help, I'm running off now, but will have this ready for landing tomorrow :)
<deryck> danilos, cool.  catch you later.
<allenap> jcsackett: Thanks for the review :)
<jcsackett> allenap: you're welcome. :-)
<LPCIBot> Project devel build (415): STILL FAILING in 6 hr 8 min: https://hudson.wedontsleep.org/job/devel/415/
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][bug=711901] Implement LIFECYCLE notification level for direct
<LPCIBot> subscriptions.
<LPCIBot> * Launchpad Patch Queue Manager: [r=bac,
<LPCIBot> benji][ui=none][bug=699719] A (currently disabled) JS overlay has
<LPCIBot> been added for advanced direct bug subscriptions.
<sinzui> leonardr: r=me
<leonardr> yay
<abentley> henninge, does this make any sense to you? http://pastebin.ubuntu.com/562165/
<henninge> abentley: looking
<abentley> henninge, nm
<abentley> henninge, it was because it defaults to 0 for sequence.
<henninge> right ;)
<abentley> henninge, I think this is confusing behaviour, though.
<henninge> abentley: of the factory method?
<henninge> I guess it could default to getUniqueInteger
<abentley> henninge, I think that would be better.
<henninge> but there are so many tests that use this, we'd have to check all of them.
<henninge> well, we could just see which are failing ...
<henninge> I guess
<abentley> henninge, or if having a continuous sequence is valuable, we can find out the last sequence number.
<henninge> abentley: actually, in most cases sequence != 0 would be the important information.
<abentley> henninge, It's also confusing that getPOTMsgSets does not, by default, return all msgsets.
<henninge> tests that test the actual sequence of POTMsgsets would set it explicitely.
<abentley> henninge, I realise that getting active messagesets is probably the common case for that method, though.
<henninge> abentley: exactly
<LPCIBot> Project db-devel build (339): STILL FAILING in 5 hr 21 min: https://hudson.wedontsleep.org/job/db-devel/339/
<LPCIBot> * Launchpad Patch Queue Manager: [rs=wgrant][no-qa] Merge stable,
<LPCIBot> resolving conflicts. Again. We like conflicts.
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless, stevenk][bug=712249] Remove remaining lucille references.
 * jcsackett is having some irc difficulties.
<deryck> henninge, hey.  Your friendly neighborhood nag coming your way. :-)
<deryck> henninge, hows the work for a fix for bug 710591 coming?
<leonardr> what's the best way to dynamically set the title of a launchpad page?
<leonardr> ie. set it to some non-static value determined by the view code
<wallyworld> leonardr: see SourcePackageRecipeEditView
<wallyworld>     def title(self):
<wallyworld>         return 'Edit %s source package recipe' % self.context.name
<wallyworld>     label = title
<wallyworld> is that what you want?
<henninge> deryck: it's underway but won't be done today, we'll be aiming for an r-c tomorrow here.
<leonardr> wallyworld: not ideal, but let's see if i can make it work
<wallyworld> leonardr: there may be a better way - that's the one way i have personnally seen
<deryck> henninge, ok, thanks
<wallyworld> StevenK: leonardr: thumper: we having a standup today?
<thumper> wallyworld: yep
<leonardr> thumper: my mic isn't plugged in
<StevenK> wallyworld, thumper; I'm coming, just having laptop issues
<wallyworld> lifeless: ping
<lifeless> wallyworld: hi
<wallyworld> lifeless: i need to qa something but the db for qastaging is so old that i can't do it
<lifeless> how so?
<wallyworld> can we organise to refresh the qastaging db?
<wallyworld> there's some recipe build records that reflect the problem in production but qastaging doesn't have them
<wallyworld> i need to test on a system that has those particular records
<wallyworld> i think qastaging db should be updated once a week? but it appears way older than that?
<lifeless> wallyworld: in this situation is better to create the problem
<lifeless> rather than wait for a sync
<lifeless> particularly as we may well need to fix data in prod so there is never any guarantee that a problem will exist on [qa]staging
<wallyworld> the data in prod doesn't need fixing
<wallyworld> the issue is with how it is displayed
<wallyworld> so you mean script some sql and get it run on qastaging?
<lifeless> wallyworld: I'm familiar with the bug; opinions vary about whether the data is a problem or not :>
<lifeless> wallyworld: putting that aside.
<lifeless> wallyworld: yes, geting losa to help you reproduce the issue on qastaging
<wallyworld> ok, so i'll write some sql to generate some records. do i have query access to the qastaging database?
<wgrant> Morning.
<lifeless> wallyworld: You don't need sql
<lifeless> wallyworld: login to qas; make a recipe; request a build; request another build; ask losa to update the finished time on the one that would normally sort lower and check it sorts higher
<lifeless> wallyworld: they may want sql for the last step, but the losas are pretty familiar with sql too :)
<wallyworld> lifeless: isn't that sql?
<mbarnett> lies
<mbarnett> we know nothing about your fancy structured languages!
<wallyworld> oh ok, i don't need to write the sql myself
<lifeless> it can also be done via bin/harness without any sql at all
<lifeless> wallyworld: you may be asked to; but don't prejudge.
<wallyworld> i'm not familar with bin/harness :-)
<lifeless> certainly don't *start* with sql, start with the web ui :)
<wallyworld> lifeless: ok. i'll grab some breakfast and do it after that
<wallyworld> mbarnett: i think you know more than you admit to :-)
<mbarnett> shhh!
<wallyworld> mbarnett: will you be around for another hour or so? can i ping you to help with the data manipulation?
<mbarnett> wallyworld: most likely.  I should be here, and if i am swamped, i'll fool one of my compatriots into helping!
<lifeless> wallyworld: the other thing
<lifeless> wallyworld: remember that the goal of the final qa step is 'ok to deploy'
<huwshimi> Did someone break the bugs api on qastaging? I'm trying to add tags to a bug and it fails with a 503 (trying to hit this page: https://bugs.qastaging.launchpad.net/api/devel/bugs/664553).
<_mup_> Bug #664553: Arduino should be in ubuntu software center <Ubuntu:Expired> < https://launchpad.net/bugs/664553 >
<james_w> huwshimi, 503 means "sorry, try again" here
<james_w> possibly it implies a problem with the qastaging appservers or similar though
<lifeless> huwshimi: do you see the headers?
<huwshimi> lifeless: Chrome console is giving me the headers
<huwshimi> lifeless: But the status code is "503 Service Unavailable"
<lifeless> if there isn't an OOPS header, then that is the frontend detecting qas not responding at all within 30 seconds
<lifeless> which isi odd
<huwshimi> I can't see anything referring to oops. There's some stuff about zope, but that's all I can see.
<lifeless> paste the headers?
<wgrant> huwshimi: A 503 is almost always a timeout.
<wgrant> There should be an OOPS ID.
<wgrant> Most bug changes currently time out due to heat recalculation.
<wgrant> qastaging seems worse than staging :/
<huwshimi> lifeless: http://paste.ubuntu.com/562237/
<lifeless> blaj
<lifeless> the oops is probably in the body :(
<wgrant> I guess the timeout code doesn't know the X-Lazr-Oops stuff :(
<lifeless> depends on the render path
<lifeless> api -> header; web -> body
<poolie> huwshimi, hi
<poolie> huwshimi, i am hungry for the fix for bug 708436 but it doesn't seem to be active in https://bugs.qastaging.launchpad.net/bzr
<_mup_> Bug #708436: Bug tag list wrapping <css> <qa-needstesting> <ui> <Launchpad itself:Fix Committed by huwshimi> < https://launchpad.net/bugs/708436 >
<poolie> despite the revision number seeming to say it would be
<poolie> i may be just confused though
<huwshimi> poolie: I'm just trying to test that on qastaging, but now I've run into a problem with adding bugs to a task
<huwshimi> *tags to a bug
<huwshimi> I'm not sure what happened with my words there
<huwshimi> lifeless: the body didn't have any helpful stuff (it was a standard "sorry, try again later" page)
<huwshimi> poolie: Oh, now I think I understand your confusion. That is a different bug to the one about tag clouds.
<huwshimi> ok seems to be working now
<lifeless> flacoste: so when you're done with calls; we should talk briefly about the output from the rt meeting
<flacoste> lifeless: i'm done
<flacoste> lifeless: skype me
<poolie> o/ flacoste
<poolie> huwshimi, ah, you're right, i was confusing them
<poolie> or they were confusing me
<huwshimi> poolie: It's ok, we were all confused.
<wallyworld> thumper: you able to tick and flick that mp?
<cody-somerville> Does zope security policy for an object only come into effect when its instantiated or would it also throw an exception if for example you try to delete an object the current principle doesn't have access to via a bulk operation on a result set which is done using SQL (and thus no objects are actually loaded into Python)?
<wgrant> cody-somerville: Only attribute access on the Python object is protected.
<lifeless> cody-somerville: can't delete an object you can't talk about.
<StevenK> jtv: Ping
<lifeless> cody-somerville: but operations below the object layer are not relevant to the zope security framework
<cody-somerville> Okay.
<StevenK> lifeless: O hai
<lifeless> StevenK: hi
<StevenK> lifeless: Could you take a look at https://code.launchpad.net/~abentley/launchpad/recipe-errors/+merge/42305 ? It's not a review, but I'm wondering if you agree with the reviewers comments.
<cody-somerville> How does Zope magically wrap objects returned by a storm result set in a security proxy?
<abentley> StevenK, I rejected that because I don't plan to work on it anymore and it wasn't approved by the reviewer.
<wallyworld> lifeless: i have a question when you are free
<lifeless> wallyworld: quick or involved?
<wgrant> cody-somerville: The ResultSet is itself wrapped.
<wallyworld> likely involved :-)
<lifeless> wallyworld: if it can wait for me to do a shopping run for Lynne, that would be awesome
<StevenK> abentley: I figured as much, I'm just trying to understand why there was so much pushback.
<wallyworld> lifeless: of course. just wanted to see if you were free. just ping me when you are able
<abentley> StevenK, so I think he's right that it would make more sense to fix the text of the errors, so that they could just be stringified.
<lifeless> abentley: FWIW I think the use of the __exit__ to consolidate the exception statements is pretty cool
<lifeless> abentley: I'm a little ambivalent about the use of it for flow control as well
<lifeless> abentley: if there was some way to tease that apart, that might make it really good
<lifeless> abentley: if the exceptions can be reliably stringified - or if they could be given some extended protocol to let us get a web page error from them, that would be simpler overall
<lifeless> wallyworld: ok, in a bit then.
<StevenK> lifeless, abentley: I guess my hidden question is "Do you feel this is a good base to start work with, or shall I scorched earth and start from scratch?"
<cody-somerville> wgrant, Interesting. I assume thats because the store is also wrapped? And if so, what prevents an unwrapped store from being instantiated?
<wgrant> cody-somerville: Nothing.
<abentley> lifeless, I think the three cases, no error, user error and programming error, make it difficult to deal with in a ContextManager unless we do the oops handling there.
<lifeless> cody-somerville: zope security is insurance
 * cody-somerville nods.
<abentley> StevenK, if this was the only way of avoiding code duplication, I would probably still do it this way.  Maybe you can think of another way.
<cody-somerville> Does Zope keep the the current principle in a thread local storage or is that information only available if you have the request object like in Django?
<StevenK> abentley: I was tempted to write a validator function that returns None on no error, or the string of the exception
<StevenK> abentley: And then call it from the two sites
<StevenK> abentley: Which means we can iterate and get the recipe text set using a AJAX text field
<abentley> StevenK, validators are look-before-you-leap.
<wgrant> cody-somerville: It uses TLS.
<StevenK> abentley: Yes, I was suggesting calling it before setRecipeText()
<cody-somerville> Is using TLS as naughty as the Django folks make it seem?
<abentley> StevenK, to be clear, I believe EAFP is a better pattern than LBYL.
<wgrant> cody-somerville: Just about.
<wgrant> But it's convenient sometimes.
<StevenK> abentley: Sorry, can you expand EAFP?
<lifeless> easie to ask forgiveness than permission
<StevenK> Ah
<abentley> StevenK, http://docs.python.org/glossary.html#EAFP
<lifeless> StevenK: and I'm with aaron - the default behaviour should be to try and handle rejection, rather than plan and then try. There are some cases where performance or correctness will be better the other way around, but they are precious few.
<thumper> abentley: unfortunately that isn't how launchpad forms normally work
<thumper> StevenK: fyi - the webservice just calls set recipe text and returns propagates the error with a 400 response code
<lifeless> wgrant: :( I missed sinzui
<mwhudson> cody-somerville: given the settings module, django people are in no position to regards other practices as evil
<StevenK> mwhudson: Their moral high ground is on a bed of quicksand?
<wgrant> lifeless: Why'd you want him?
<mwhudson> StevenK: something like that
<lifeless> wgrant: apache-openid.
<lifeless> wgrant: bug 712698
<_mup_> Bug #712698: No way to expire existing sessions <Apache OpenID:New> < https://launchpad.net/bugs/712698 >
<lifeless> wgrant: I was going to ask if he could spare a slot for it
<wgrant> lifeless: Hmm.
<wgrant> lifeless: Also, re. Debian, what status did you have in mind for squeeze?
<lifeless> wgrant: dunno; not-dev-focus ?
<wgrant> The development focus is not explicit for distributions.
<lifeless> wgrant: something controls branch stacking ......
<wgrant> lifeless: Whichever series has status DEVELOPMENT.
<lifeless> there are three for debian, surely.
<lifeless> sid, experimental and $next
<lifeless> wgrant: also https://bugs.launchpad.net/apache-openid/+bug/712698/comments/1
<_mup_> Bug #712698: No way to expire existing sessions <Apache OpenID:New> < https://launchpad.net/bugs/712698 >
<lifeless> bbiab
<wgrant> Right. Experimental is currently EXPERIMENTAL, Sid is FUTURE, and Squeeze is DEVELOPMENT.
<wgrant> We could possibly swap Sid and Squeeze.
<wgrant> But making the dev focus explicit is probably better.
<wgrant> "Given the depths of the cuts already made to reclaim CD space, and the
<wgrant> fact that we should be taking a leadership position in encouraging
<wgrant> migration to Python3, I don't think it makes any sense to keep
<wgrant> python2.6 around in Ubuntu for Natty.
<wgrant> "
<wgrant> :(
<wgrant> Porting time yay?
<james_w> porting Launchpad?
<wgrant> Yes.
<james_w> to 2.7?
<wgrant> Right. It's still a bit broken.
<james_w> that was surely inevitable before the next LTS
<wgrant> Indeed.
<wgrant> But not necessarily before Natty.
<james_w> you are just concerned about developers?
<james_w> deployment obviously isn't going to move to natty is it?
<wgrant> Right.
<james_w> ok, with you
<abentley> thumper, forms seem to handle setting errors in actions (i.e. asking forgiveness) very well.  The problem we've got here is how best to generalise the control flow.
<thumper> abentley: I think the main reason for the validation code is to catch all the errors at once, rather than one at a time
<abentley> thumper, there's that.
#launchpad-dev 2011-02-04
<lifeless> wallyworld: ok shoot
<wallyworld> bang
<wallyworld> you mean with the uzi?
<lifeless> wgrant: we don't need it for natty
<wallyworld> i love the uzi
<lifeless> wgrant: vm's for the win
<wallyworld> lifeless: you know that wide query taking a long time to run - the daily recipe builds one.....
<lifeless> nope, remind me
 * wallyworld looks up bug nr
<wallyworld> bug 711072
<_mup_> Bug #711072: RootObject:+daily-builds times out <timeout> <Launchpad itself:Triaged by wallyworld> < https://launchpad.net/bugs/711072 >
<lifeless> ok
<lifeless> how can I help
<wallyworld> tables like person, sourcepackagename, archive are only in the query to get data to display
<wallyworld> so they could be removed to reduce the nr of joins, and subsequent queries done to look up that data
<lifeless> wallyworld: btw has your parameter filling thing had the test failure figured out and landed ?
<lifeless> wallyworld: yes, changing from wide to serial is likely to help
<wallyworld> not yet. i updated from trunk and can now reproduce locally but it's on the back burner till after rollout. bad rev rolled back
<lifeless> kk
<wallyworld> but values from those tables are used in thr oder by
<lifeless> matsubara has improved lp-oops to group with inferred parameter types
<wallyworld> cool.
<wallyworld> so if i remove those tables from the query, i will have to load all the values and do an in memory sort
<lifeless> wallyworld: huh, no
<wallyworld> unless there's another way that storm can help that i don't know about
<lifeless> DecoratedResultSet
<lifeless> pre_iter_hook
<lifeless> done
<lifeless> I mean, you do need to load
<lifeless> but sorting should always be db
<wallyworld> ok. i'll have to look at that hook to see how it fits in
<lifeless> otherwise slicing will fail
<wallyworld> yeah, that was my problem
<lifeless> look in lib/lp/blueprints/model/specification.py
<lifeless> for pre_iter_hook
<lifeless> this is one I prepared earlier.
<wallyworld> excellent, a working example. thanks
<lifeless> exact transform we're talking about
<wallyworld> i knew that you would be able to help :-)
<lifeless> actually, this is more complex
<lifeless> but it shows pretty much all that you might want to do, and as I haven't seen the code you're looking at yet.
<wallyworld> by "this" you mean the thing i am doing cf the example you gave?
<lifeless> the specification hook is doing more than you ma yneed
<wallyworld> ah ok
<lifeless> its doing eager loading *and* object injection
<wallyworld> a useful thing to bookmark for later for when needed
<lifeless> so, looking at your query
<wallyworld> thanks for the tip, i'll take a look and go from there
<lifeless> why are you sorting on the things you're soring on
<lifeless> also note the utterly utterly insane group by
<lifeless> perhaps we should start with the use case ;)
<wallyworld> the group by is needed because of the max()
<wallyworld> the sort order was as per the requirements
<lifeless> the max means you're bring back too many things
<lifeless> which will make it slow
<lifeless> (and thus, its slow)
<wallyworld> there's several build records and we only want the latest one
<lifeless> that sounds a bit delphic, sorry
<lifeless> perhaps voice would help; I dunno.
<lifeless> the first thing I'd want to do is to grab a bit of paper and map it out
<wallyworld> taking out archive, person,sourcepackagename will help the base query look more sane
<wallyworld> thumper developed the initial query in straight sql - i adapted it to storm.
<wallyworld> it produces the correct results. how about i make the changes we've just discussed and see where that takes us
<lifeless> you can't take the things out that you need to sort on
<wallyworld> yes, hence my original question :-)
<lifeless> ok
<lifeless> so, first thing is to ask if we need to sort on all those things
<wallyworld> that's why my first thought was to load the result set and do an in memory sort
<wallyworld> there's only around 300 records - not sure what that may grow to in the future
<lifeless> 16K or more
<lifeless> its still in beta.
<wallyworld> hmmm. that's too many
<wallyworld> so yes, will have to revisit the sort order question then
<lifeless> you have 600 ms in late evaluation of Branch
<lifeless> looking at https://lp-oops.canonical.com/oops.py/?oopsid=1858D164
<lifeless> another 800ms in late evaluation of SourcePackageRecipeData
<wallyworld> why doesn't that oops link work?
<lifeless> apache-openid brekaage
<lifeless> login
<lifeless> click again
<wallyworld> those late evaluation times can certainly be fixed, but the main query - the count and the select - do swamp the overall number though
<lifeless> actually
<lifeless> thats 2.3 seconds in late evaluation
<lifeless> so the main query is more
<lifeless> but not like 90%
<lifeless> anyhow
<lifeless> first step, define the definitive goals
<wallyworld> sure. i guess i'm saying that fixing the late eval stuff is necessary but not sufficient
<lifeless> ORDER BY SourcePackageName.name,
<lifeless>          Person.name,
<lifeless>          Archive.name LIMIT 76
<lifeless> wallyworld: all its all necessary and nothing will be sufficient ;)
<lifeless> so the source package name is the driving thing
<lifeless> its used for pagination
<wallyworld> i'd agree with that
<lifeless> personally I think that paginated lists are suboptimal
<lifeless> I'd rather we presented a query interface
<wallyworld> +1
<lifeless> and showed the 75 most recent builds the rest of the time
<lifeless> or something like that
<wallyworld> if we did do that, the count() query would be required
<lifeless> well the count can be simplified
<wallyworld> and we would shave 1/2 of the most significant execution time off
<wallyworld> but that's not how the batch navigator works is it?
<wallyworld> the bn simple does a count() on the underlying query
<lifeless> its just select count(*) from sourcepackagerecipe where daily_build is true
<lifeless> the batch navigator makes some simlifying assumptions
<lifeless> we may need to pass in an object with a custom count
<wallyworld> not really - we only want the latest, but anyway, unless there's a hook i don't know about, the bn uses the same underlying query to do the count
<lifeless> spr is 1:M
<lifeless> if you count 1, you don't need the max
<wallyworld> let me talk to thumper so see if we can adjust the requirements for what is displayed
<lifeless> wallyworld: yes, the bn will need to be given an adapted result set, not a real one.
<thumper> hell no!
<thumper> sorry what?
<wallyworld> thumper: read the last 10000 lines ^^^^^^^^^^^^ :-)
<thumper> wallyworld: no
<wallyworld> thumper: wanna mumble, may be easier
<lifeless> thumper: listing all the source package builds as a collection seems pointless
<thumper> wallyworld: I'm in a cafe without headphones
<lifeless> thumper: we're saying lets just give users the 75 most recently built daily ones + a search box.
<thumper> lifeless: I'm not listing them as a collection
<lifeless> thumper: what do you call 'https://code.launchpad.net/+daily-builds'
<thumper> what are you talking about?
<wallyworld> thumper: we're talking about the +daily-builds sql times
<thumper> lifeless: that is really a requirement from the community guys
<wallyworld> and the fact that the current sort oder requires a query with a number of joins to get the data to sort on
<lifeless> thumper: how was it phrased though?
<thumper> they wanted a listing of packages built with recipes
<thumper> not search rubbish
<lifeless> thumper: search is hardly rubbish; who asked for this, and what did they want to achieve?
<wallyworld> but if we are prepared to relax the sort order we can small a smaller more efficient query
<wallyworld> s/small/use
<thumper> :)
<lifeless> wallyworld: so we can make it better as is
<lifeless> wallyworld: I'm separately saying that its not actually a brilliant UI as it stands.
<thumper> wallyworld: the only sort order I care about is source package name
<thumper> wallyworld: everything else is extra
<wallyworld> thumper: ok. will do that first up
<thumper> wallyworld: most of the results will return only one daily recipe for a source package
<thumper> at least for now
<lifeless> thumper: that presupposes having a collection though; so can we talk about that seriously?
<thumper> there are a few packages where there are more than one
<wallyworld> and get some numbers on the improvement
<thumper> lifeless: I'd be terribly sad if you took the collection away
<lifeless> thumper: why?
<wallyworld> can i ask to have a query run on production?? to get some numbers?
<lifeless> wallyworld: a losa
<lifeless> wallyworld: or stub
<wallyworld> sure. just wanted to see if it were a kasha thing to ask for
<lifeless> wallyworld: the numbers haven't changed substantially though.
<thumper> because I think it looks nice, and validates the work we are doing
<wallyworld> lifeless: did you just try it?
<lifeless> thumper: I don't think it validates it - uptake will validate it; as far as looking nice, it looks like something where its impossible to find what a user wants to find.
<lifeless> thumper: I don't mean to be negative here.
<wallyworld> i meant to see what benefit removing person and archive from the sort oder would do
<lifeless> wallyworld: for that sort of thing, we use qastaging until we're fairly sure we've got the good stuff
<wallyworld> but qastaging has a really old db  :-(
<lifeless> wallyworld: if you have a canned query I can run on qastaging, that would be great.
<lifeless> wallyworld: it doesn't matter for this; it has 270 recipes
<wgrant> lifeless: PQM still executes baz? Seriously?
<lifeless> wgrant: probes for it, backend lookup
<lifeless> dunno if it has it there.
<thumper> lifeless: it should be up to the stakeholders and the strategist, so check with jorge and jml
<wallyworld> lifeless:  yes, but what about all the other data (eg in the archive table) that serves to make the query slow
<wgrant> lifeless: It uses it to get config-manager.
<thumper> lifeless: I see no reason to defend it to you
<wgrant> lifeless: That seems to be what takes all the time. It already does a lightweight checkout.
<lifeless> thumper: I was asking who was pushing for it to be /like this/ - I wasn't asking you to defend it; I don't know how we got here conversation wise.
<lifeless> thumper: I'll be delighted to talk to jorge and jono
<lifeless> wgrant: it doesn't spend 30 minutes talk to baz, I assure you
<wgrant> lifeless: The logging is a bit crap, then :/
<StevenK> No, it spends 30 minutes spinning
<lifeless> wallyworld: so the point I was making was that a search interface generates a very specific lookup
<thumper> lifeless: https://wiki.ubuntu.com/DailyBuilds/AvailableDailyBuilds was the justification
<wgrant> Feb 03 23:26:09 pqm [140001309406976] INFO: running: baz get /home/pqm/archives/rocketfuel/lp-production-configs/trunk/config-manager /srv/pqm.canonical.com/chroot/home/pqm/pqm-workdir/home/devel
<lifeless> wallyworld: so the intermediary tables will be very small
<wgrant> Then it disappears for 17 minutes.
<wgrant> Every time.
<lifeless> thats in bzr land at that point
<lifeless> the bzr backend doesn't log such a message
<lifeless> thumper: thanks
<wgrant> Oh yay, another db-devel conflict.
<thumper> lifeless: sorry for being touchy... lots of stuff going on
<wallyworld> lifeless: sure
<lifeless> thumper: so, looking at that; the goal is to avoid duplicate effort; making it real easy to find dailies of audacity (e.g. search / linking on the source package side) would seem best to me.
<lifeless> thumper: no worries; it is friday after all.
<thumper> lifeless: perhaps a tag cloud for package names would be better?
<thumper> given how much we love tag clouds :)
<lifeless> so, I propose to mail jml and jorge, cc thumper and wallyworld and propose a different UI which can give us a much simpler problem to solve
<thumper> although determining size / shade would be interesting
<lifeless> thumper: thats a cool idea too
<lifeless> thumper: search is the cheapest for us to do
<lifeless> thumper: I don't know that its the best; tag clouds are pretty interesting too.
<lifeless> thumper: I suspect we need discoverability as a primary mechanism though.
<lifeless> thumper: is there anything I can help with ? [re lots of stuff going on]
<thumper> not unless you want to read CVs and interview people
<lifeless> am I allowed to shoot myself first ?
<wallyworld> thumper: btw, the guy i mentioned wasn't interested
<thumper> sure
<StevenK> lifeless: Depends. Where?
<lifeless> wallyworld: ok, so lets see what we can do
<lifeless> wallyworld: first thing, we *don't* want to return all the previous builds in the intermediary tables
<thumper> \0/
<lifeless> wallyworld: but the thing before that
<thumper> web-link branch of leonard's has landed in devel
<lifeless> wallyworld: is to see what the current plan is
<lifeless> wallyworld: do you have a query I can run
 * wallyworld looks
<wallyworld> lifeless: the current implementation uses this query - https://pastebin.canonical.com/42856/
<wallyworld> lifeless: but i don't mind working through the issue if you have other stuff to do
<lifeless> nothing I can't procrastinate over.
<wallyworld> so i'll immediately get a win by removing the person and archive from the sort
<lifeless> spm: could you please do an explain analyze on http://pastebin.com/nASE7Tq6 ?
<lifeless> spm: on prod
<lifeless> wallyworld: getting the explain should tell us a lot about what its doing
<wallyworld> then we could get a rs with only the latest builds and use that to filter the main query - so a subselect instead of a big join, not sure how postgres performs for that
<lifeless> wallyworld: it depends
<wallyworld> jcsackett: ping
<lifeless> if its uncorrelated and huge relative to final rows, poorly; if its correlated and about as selective as outer, poorly.
<jcsackett> hello wallyworld.
<wallyworld> jcsackett: hi. i just need a quick tick and flick on a mp to fix a small layout issue. can i reassign to you?
<wallyworld> https://code.launchpad.net/~wallyworld/launchpad/recipe-related-branches-layout/+merge/48463
<wallyworld> it's only like 2 lines of pt
 * jcsackett realizes he's still listed as OCR.
<wallyworld> sorry if you weren't
<wgrant> jcsackett: You can't escape.
<jcsackett> yeah, i can take a look at it, wallyworld; but you'll need to find someone to follow up, since my mentor is definitely not on shift.
* jcsackett changed the topic of #launchpad-dev to:  https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<wallyworld> ah ok
<jcsackett> wallyworld, you want me to still take a look? i don't mind (need the reviews) but as i said, r=jcsackett isn't enough to land something. :-)
<wallyworld> jcsackett: no, it's cool. thanks
<jcsackett> wallyworld: dig. sorry for the confusion. i need to be better about removing myself from OCR. :-P
<wallyworld> jcsackett: no problem :-)
<wgrant> StevenK: Do you have any suggestions for getting a newer archive to gina on mawson?
<wallyworld> lifeless: while waiting for that explain, can you quickly approve this 2 line pt change?
<wallyworld> https://code.launchpad.net/~wallyworld/launchpad/recipe-related-branches-layout/+merge/48463
<spm> wallyworld: lifeless: https://pastebin.canonical.com/42858/
<wallyworld> spm: thanks
<lifeless> wallyworld: sadly I don't know the css classes we use well enough to say if thats sane or not
<lifeless> I seem to recall a lot of discussion about tables vs nontables in this
<LPCIBot> Project devel build (416): STILL FAILING in 6 hr 17 min: https://hudson.wedontsleep.org/job/devel/416/
<LPCIBot> * Launchpad Patch Queue Manager: [no-qa] [r=allenap][ui=none][bug=707103] Clean-up of lint after
<LPCIBot> bugs-with-blueprints-bug-707103.
<LPCIBot> * Launchpad Patch Queue Manager: [bug=75976] [r=abentley][ui=none] When someone asks to merge two
<LPCIBot> accounts, Launchpad sends an email to the primary account asking for
<LPCIBot> confirmation. That email was hard to understand and badly
<LPCIBot> written. This branch rewrites that email's text and introduces
<LPCIBot> a test that the email is sent with the correct text.
<LPCIBot> * Launchpad Patch Queue Manager: [r=mthaddon, stub][bug=712282,
<LPCIBot> 712285][no-qa] Improve nightly.sh transparency,
<LPCIBot> and remove update-pkgcache.py from it.
<lifeless> wallyworld: clearly its trivial textually.
<wallyworld> lifeless: the css - should have been there from the start - cut'n.paste error. the other collapsible field sets use it
<lifeless> wallyworld: want to mumble on the explain
<wallyworld> lifeless: ok
<lifeless> well, try mumbling, it may still be epic fail fo rme
<wallyworld> or skype
<lifeless> I can hear you
<lifeless> spm: please analyse this on prod - http://pastebin.com/3ZA20XvA
<lifeless> sadly staging/qastaging are not fresh enough
<spm> lifeless: https://pastebin.canonical.com/42859/
<lifeless> thanks!
<lifeless> there will be more
<lifeless> wallyworld: http://www.postgresql.org/docs/8.4/static/tutorial-window.html
<lifeless> rank() OVER (PARTITION BY BuildFarmJob.date_finished DESC) FROM
<jtv> StevenK: pong
<lifeless> wgrant: ping
<wgrant> lifeless: Hi.
<lifeless> wgrant: hi
<lifeless> you know wallyworld and I are looking at a slow query
<lifeless> its filtering all binary package builds that are recipes
<wgrant> The +daily-builds one?
<lifeless> in state 1
<lifeless> yeah
<lifeless> we had an idea
<lifeless> what if we narrow this to 'published'
<lifeless> it might consider less data?
<lifeless> we have binary package build and build farm job already in there
<wgrant> So we're finding BPBs that are built from an SPR that has an SPR?
<lifeless> have a look at one of the pastebins
<lifeless> the goal is 'all source package recipes showing the date of the most recent successful binary build'
<lifeless> one thing that isn't clear to me/us is whether fullybuilt in this case means 'the bzr-builder worked' or 'all binaries were build'
<wgrant> It's the binary build status.
<wgrant> Note that your last pastebin doesn't restrict to builds in the daily archive, so manual builds to other archives will show up.
<lifeless> indeed
<lifeless> what table was that on - BPB ?
<wgrant> PackageBuild
 * wgrant silences mirror-prober.sh.
<wgrant> These noisy scripts irk me.
 * spm gives wgrant 100 awesome points
<lifeless> PackageBuild ON (PackageBuild.id = BinaryPackageBuild.package_build and PackageBuild.archive = SourcePackageRecipe.daily_build_archive)
<wgrant> lifeless: I think so.
<wgrant> I'm not sure which direction is clearer.
<wgrant> Should we go from daily recipes to builds, or find builds that have daily recipes?
<gary_poster> wallyworld, ping?
<wallyworld> gary_poster: hey
<gary_poster> hey
<gary_poster> I really want ~gary/launchpad/bug548-db-2 to get on db-devel before we close pqm or mark things closed or so on.  Some tests failed, and in order to fix them, I had to make enough changes that they warrant their own separate review.  So...
<gary_poster> I'm wondering how to get that to happen/if I can get that to happen
<gary_poster> in order for that to work, I'll need a review, and I'll need to land
<gary_poster> with tests passing..
<wallyworld> gary_poster: just give me a sec : otp
<gary_poster> oh, sure
<lifeless> whats the mp url ?
<wallyworld> gary_poster: well i am talking to lifeless atm :-)
<wallyworld> he may want to help
<gary_poster> thank you both, getting the mp up now
<wallyworld> gary_poster: there's still 9 hours or so before we close :-)
<wallyworld> plenty of time!
<gary_poster> :-) yes, but I wanted to stop working hours ago :-)
<wallyworld> yeah. understood :-)
<wallyworld> gary_poster: so i can land it for you once it passed review
<gary_poster> thank you!
<wallyworld> gary_poster: what about qa? is it clear how to do that?
<gary_poster> it is no-qa
<wallyworld> even better!
<gary_poster> :-)
<wallyworld> gary_poster: so i think your work here is done :-)
<wallyworld> assuming it passes review :-)
<lifeless> gary_poster: whats the mp url ?
<gary_poster> lol, thank you.  Well, I need to get the MP done
<gary_poster> lifeless: https://code.launchpad.net/~gary/launchpad/bug548-db-2-tests/+merge/48570 but diff is still coming
<gary_poster> the mp message is, uh, one of my more hurried :-P
<gary_poster> and it shows :-)
<gary_poster> ok diff has emerged lifeless
<gary_poster> uh?
<gary_poster> I did not touch the lib/canonical/widgets thing :-/
<wgrant> gary_poster: You're getting a conflict there when merging locally?
<wgrant> If so, ignore.
<wgrant> Delete the widgets.moved directory.
<gary_poster> wgrant, it is something in the MP-generated diff
<gary_poster> not in my local diff
<wgrant> OK, that's not normal.
<gary_poster> I'm trying a local merge of my branch into a up-to-date-db-devel...
<gary_poster> wgrant, conflict on my db-devel pull.  I assume this was correct?
<gary_poster> rm -rf lib/canonical/widgets.moved
<gary_poster> bzr resolved lib/canonical/widgets.moved lib/canonical/widgets lib/canonical/widgets.moved/tests
<wgrant> gary_poster: Yes, that's right.
<gary_poster> cool
<wgrant> I just merged that branch into db-devel.
<gary_poster> cool, thanks
<wgrant> lib/canonical/widgets is still there...
<wgrant> So the LP diff is odd.
<wgrant> I resolved that conflict last night.
<gary_poster> My branch merges cleanly into db-devel touching only the files I expect, so it looks like it is a diff-generation odity in the MP
<lifeless> launchpad_qastaging=> select count(*) from sourcepackagerecipe where build_daily
<gary_poster> oddity
<lifeless> ;
<lifeless> Time: 1.512 ms
<gary_poster> lifeless, I never asked explicitly--are you reviewing the branch or should I ask around?
<gary_poster> be thar a reviewer in these here parrts?
<gary_poster> wallyworld: are you a reviewer, by chance?
<lifeless> I will, one sec
<gary_poster> oh thanks
<wallyworld> gary_poster: no. not yet. soon hopefully
<gary_poster> :-) cool
<lifeless> gary_poster: hi
<gary_poster> hey
<lifeless> isn't with logged_in_user() sufficient ?
<lifeless> sorry
<lifeless> person_loggefd_in
<lifeless> *bah* person_logged_in
<gary_poster> this is about the dbuser, not the application user, so I don't think so.  Do I misremember my helpers?  looking for it
<lifeless> ah right
<lifeless> layers ;)
<gary_poster> right :-)
<gary_poster> and db, rather than application
<lifeless> so
<lifeless> a few thoughts
<lifeless> I'll sketch here
<lifeless> the restore_name seems a bit unrelated
<gary_poster> to...?
<lifeless> the problem you're solving
<gary_poster> in the sense that we should always look at _dbuser?
<lifeless> run-some-code-as-a-user
<lifeless> right
<gary_poster> completely agree
<lifeless> I'm saying having it do a push/pop and if someone wants to change after that, they can do that separately - would make this code leaner
<gary_poster> (it was probably some kind of misthought subliminal reaction to disliking the fact that I was looking at an underpants attribute.)  Yeah push/pop was my only intent really
<lifeless> given the lack of tests for the helper, my inclination is to suggest making it as lean as possible
<lifeless> I like the helper.
<lifeless> I'm curious why your tests failed
<gary_poster> a few existing tests failed that were creating things without a dbuser that actually had privileges to do so
<lifeless> is it that LaunchpadZopelessLayer runs as an unusual user?
<gary_poster> by adding an additional obeject that we were creating
<lifeless> gary_poster: so, you're creating a PersonSetting whenever a Person is created?
<lifeless> gary_poster: rather than lazy-creating?
<gary_poster> unusual user: yeah, it is usually run as the user that a given script needs
<gary_poster> which is often not pwerful enough to create stuff
<gary_poster> if you tickle the database enough then things will flush
<gary_poster> so essentially my change exposed (some) problems that were already existing
<gary_poster> (I think there are a lot more like these that have not yet been triggered)
<gary_poster> not lazy-creating: yes, I dislike write on read, and didn't want the complexity of look-for-the-underlying-object-and-if-it-is-not-there-look-for-the-interfaces-default.
<gary_poster> (that is, write-on-write is ok, but I thought simplicity had a virtue)
<lifeless> gary_poster: I dislike write-on-read too; That implies creating a million rows when the db deploy happens though
<lifeless> anyhow
<lifeless> approved
<lifeless> I would like it if you could shrink the helper.
<lifeless> more so if you add tests.
<gary_poster> yes, I wondered about that but that was the design stub made, so I figured he had thought it through.
<gary_poster> I shrunk the helper locally already, after discussion.  lemme run a smoketest...
<lifeless> gary_poster: At a guess - I suspect he intended lazy create.
<gary_poster> no, he made the trigger
<lifeless> heh, ok.
<lifeless> anyhoo, all sorted.
<gary_poster> ok lifeless, thank you. yeah, the smoke test passed with http://pastebin.ubuntu.com/562319/ .  So, I'll push the non-test change to the helper now and ask Ian to land it, and then promise to make a branch with a test for it tomorrow.  Sound ok?
<lifeless> grewat
<lifeless> great
<lifeless> the commit is a bit sad
<lifeless> I wonder if rollback would be better, but thats a separate discussion
<gary_poster> :-) I hear you
<gary_poster> that's the pattern I saw throughout the tests for this thing
<gary_poster> I dunno
<gary_poster> I also am not entirely sure why it is a sqlbase commit
<gary_poster> rather than a transaction.commit
<gary_poster> but I was in a bit of "land the thing" and I felt this was at least an improvement over the status quo
<lifeless> sure
<gary_poster> wallyworld: ok, here's hoping the tests pass now. :-/
<gary_poster> https://code.launchpad.net/~gary/launchpad/bug548-db-2-tests/+merge/48570
<gary_poster> Let me do one last paranoid check...
<wallyworld> gary_poster: so ready to ec2 land?
<gary_poster> wallyworld: yes!  all previously failing tests , and all tests I touched, pass.  Let's give it a whirl.  Thank you so much!
<wallyworld> gary_poster: my pleasure. pleased to help.
<gary_poster> Thank you all.  Have a good day and ttyl
<wgrant> Could someone review https://code.launchpad.net/~wgrant/launchpad/the-silence-of-the-probers/+merge/48571?
<wallyworld> thumper: you free to talk about the form submit thing? or you have too much else happening?
<thumper> wallyworld: I'm doing expenses, so I can talk to you now :)
<wallyworld> :-D
<wallyworld> mumble?
 * wgrant cries.
<thumper> wallyworld: https://code.qastaging.launchpad.net/~wikkid/+recipe/wikkid-daily
<lifeless> wgrant: ?
<wgrant> lifeless: Fourth stable->db-devel conflict in 24 hours.
<thumper> :(
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (340): FIXED in 5 hr 37 min: https://hudson.wedontsleep.org/job/db-devel/340/
<wgrant> lifeless: Do you have a sec to review https://code.launchpad.net/~wgrant/launchpad/the-silence-of-the-probers/+merge/48571?
<lifeless> wallyworld: want the review practice?
<wallyworld> lifeless: for ^^^^ ?
<lifeless> yes
<wallyworld> ok
<lifeless> man its fugly:)
<wallyworld> about time i had a go at one :-)
<lifeless>      498 / 7263  Archive:+index
<lifeless>      245 /  374  BugTask:+index
<lifeless>       91 /  182  Distribution:+bugs
<lifeless> huwshimi: please triage when filing!
<mwhudson> lifeless: is there/could there be a link to the triage guidelines in the +filebug page?
<mwhudson> i guess it's only really intended for devs
<huwshimi> lifeless: OK :)
<huwshimi> lifeless: Self-triaging suggestions to change things just feels wrong though.
<lifeless> huwshimi: you're a dev, you're able to assess importance.
<lifeless> huwshimi: if you truely have no idea how relevant this is in the overall scheme of things, thats fine, but I've met very few engineers without such opinions ;)
<huwshimi> lifeless: Yeah ok fair point
<huwshimi> lifeless: I guess people will tell me if I'm doing it wrong anyway :)
<lifeless> for sure
<wgrant> wallyworld: Thanks.
<wgrant> How are we looking for the release?
<wallyworld> wgrant: np. well, i need to finish some qa (just waiting on a qastaging update). there's a mp from gary that fixes some failing tests that i am landing but it just barfed with some rrors :-(
<wgrant> :(
<wallyworld> many related to nascentupload stuff
<wallyworld> i think that stuff was recently changed?
<wgrant> What are the errors?
<wgrant> Parts of it were refactored a week ago.
<wallyworld> cause i had the same issue the other day - tests passed locally
<wallyworld> this is a merge into db-devel
<wallyworld> wgrant: https://pastebin.canonical.com/42864/
<wallyworld> i've not looked at the detail yet, and there's more failing besides just the nascentupload ones
<wgrant> Ah, that's interesting.
<wgrant> I renamed that DB user yesterday.
<wgrant> But it's probably unrelated.
<wallyworld> sure? :-)
<wgrant> Let's see.
<wallyworld> wgrant: i think the purpose of the mp was to specify a db user to use for things to ensure the correct permissions were available and so have not get permission denied errors
<wgrant> Yeah, security.cfg needs lots of fixes.
<wgrant> This is going to be difficul;t.
<wallyworld> and yet the failures had permission issues
<wgrant> wallyworld: Anything that creates a Person needs INSERT on personsettings.
<wgrant> Lots of things create Persons.
<wgrant> But only the webapp has permission to do so.
<wallyworld> wgrant: hmmm. the failures seem to be in different tests to what the mp changes
<wgrant> wallyworld: Indeed, they will be in various scripts throughout the tree.
<wgrant> And they should be fixed by adding permissions, not changing DB users.
<wgrant> We could be bad and add personsettings to the 'write' group.
<wgrant> That may fix everything.
<lifeless> wgrant: why /should/ they be fixed like that?
<wallyworld> lifeless: wgrant: i have to go and pick up the kid from school and buy him some cricket whites. be back soonish.
<wallyworld> i'll catch up about this mp issue when i return
<lifeless> wallyworld: they won't be white long
<wgrant> lifeless: Because unless we are going for a single-user model, we have no choice.
<wallyworld> not sure if it will make pqm cut off now :-(
<wallyworld> hah
<lifeless> I don't know why they don't call them cricket greens
<wallyworld> :-)
<lifeless> wgrant: that doesn't follow; perhaps you can expand your reasoning
<wgrant> lifeless: We have special DB users like archiveuploader.
<wgrant> They have permissions that other users do not.
<lifeless> yes
<wgrant> So some scripts must run as those special users.
<lifeless> yes
<wgrant> So those users need these new permissions.
<lifeless> the create PersonSettings permission?
<wgrant> That one.
<lifeless> certainly things that can create Person need that.
<wgrant> Right.
<lifeless> but you were saying something rather broader than that.
<lifeless> -or-
<wgrant> I was saying that would be a quick fix.
<lifeless> you were being unclear
<wgrant> I thought the "We could be bad" was a big enough hint that the following suggestion was an awful, suboptimal, but effective fix.
<lifeless> I thought it was a catholic bad
<lifeless> you know, good
<wgrant> So, my preferred fix is to grant SELECT, INSERT on PersonSettings to everywhere with INSERT on Person. Including, probably, write.
<wgrant> And possibly review the test changes to work out if the DB users really needed to be changed.
<lifeless> that sounds fine
<wgrant> It looks like we want to revert the test changes. But I might keep those cool context managers :)
<huwshimi> Can anyone explain what's going on with the "TREE" and "MERGE-SOURCE" stuff on the diff on this mp? https://code.launchpad.net/~huwshimi/launchpad/tag-label-687546/+merge/48577
<wgrant> huwshimi: A conflict occurred during the merge.
<huwshimi> wgrant: How do I resolve that?
<StevenK> Merge from devel, edit the conflicting files to remove the conflicts, run bzr resolve, bzr ci and push
<huwshimi> StevenK: How do I merge from devel? I've done it before, but the instructions got removed from the wiki :9
<huwshimi> *:(
 * huwshimi is still branching newbie
<wgrant> huwshimi: In your branch, 'bzr merge ../devel'
<wgrant> Assuming that you have the usual branch layout created by rocketfuel-setup.
<huwshimi> wgrant: yeah, thanks
<huwshimi> wgrant: I guess I need to update devel to the latest first though right?
<wgrant> Right.
<wgrant> cd into there, and 'bzr pull'
<wgrant> Or probably bzr pull -d ../devel
<StevenK> Or rocketfuel-get
<wgrant> Or that.
<wgrant> But that takes forever from .au.
<StevenK> It's only a few minutes for me
<wgrant> That is longer than it takes to do a non-parallel branch build.
<wgrant> And that is already forever.
<StevenK> Kids these days
<lifeless> spm: hi
<spm> hola
<spm> lifeless: ?
<lifeless> spm: I have two queries
<lifeless> in http://pastebin.com/kwXPWJyT
<lifeless> I'd like them both run, and explain analyzed, on prod please
<spm> I'm shocked. only 2???? :-P
<spm> np
<lifeless> its 6:30
<StevenK> lifeless: So effectively 4 queries?
 * spm cheers StevenK on ;-)
 * lifeless throws peanuts
<spm> :-)
<spm> lifeless: https://pastebin.canonical.com/42865/
<lifeless> spm: did you run twice?
<lifeless> spm: also I need the actual output of said queries
<spm> I didn't run twice, but can; output coming.
<lifeless> (I don't need the plan again)
<lifeless> just run the queries a couple of times each
<StevenK> And query count rises
<huwshimi> ok that'll have to be fixed on Monday. Have a good weekend for all those who are about to begin them.
<spm> night huwshimi
<spm> lifeless: 1st is count 270
<lifeless> spm: and how long did it take ?
<lifeless> (\timing ftw)
<spm> ~ 1.5 secs each
<spm> will paste shortly
<lifeless> kk
<spm> lifeless: https://pastebin.canonical.com/42866/
<lifeless> thanks
<lifeless> spm: can you change the select count(*) in the first query to just select *
<lifeless> spm: run it, and let me know how long
<spm> ugh. yes. one sec.
<spm> ew. I wish I hadn't done that to console. try #2.
<StevenK> Haha
<StevenK> lifeless: The mail I just sent to you makes me sad
<lifeless> yes
<lifeless> me too
<lifeless> why is it like that though
<lifeless> we should debug
<StevenK> Querying Hudson over it's Python API is like pulling teeth
<lifeless> how do you know
<lifeless> have you pulled teeth ?
<StevenK> No, but I've had a molar pulled
<lifeless> stub: you might want to land bigjools debversion patch yourself given how close to pqm closure
<lifeless> spm: I can prep the query for you if you like
<wgrant> wallyworld: lp:~wgrant/launchpad/bug548-db-2-tests
<spm> lifeless: https://devpad.canonical.com/~spm/lifeless.out
<wgrant> wallyworld: I've run some previously failing tests, and they're OK. Running more now.
<lifeless> spm: you missed the *time*
<lifeless> spm: and I didn't care about the output :)
<lifeless> spm: (sorry for the evident confusion)
<spm> oh I see
<spm> ~ 1.7 to 2.0 secs. call it 1.9.
<lifeless> great
<lifeless> wgrant: I'm starting to think that in the second half of this year we're going to have to do a schema refactoring to make soyuz - and things that have followed its lead - actually queryable
<wgrant> lifeless: If you have some concrete suggestions I would be glad to hear them.
<spm> drop database
<lifeless> for starters, collapse the tables where we have 'A if B and B if A'
<lifeless> unless you are never filtering on A or B, this sort of split destroys query performance
<wgrant> eg?
<lifeless> BPB-PB-BFJ
<wgrant> That means denormalising everything.
<lifeless> if we filtered on BPB rather than BFJ it would be different
<lifeless> wgrant: I don't see that it does
<lifeless> wgrant: it may mean modelling it differently
<wgrant> lifeless: SPRBs? TTBJs?
<lifeless> three tables
<lifeless> BPB SPRB TTBJ
<wgrant> Denormalised, forcing everyone to query against all three.
<lifeless> not true
<lifeless> some folk will have to query three
<lifeless> *most* folk will query one.
<wallyworld> wgrant: thanks, looking now
<wgrant> lifeless: So, if we are going to move to a denormalised model we can. But that's a big policy change.
<wgrant> And it is going to need to have good evidence behind it.
<lifeless> wgrant: I haven't proposed denormalised so far.
<lifeless> wgrant: as for policy; we have lots of denormalisation, there is no need for a policy change at all.
<wgrant> You do not propose redundancy in data, but redundancy in schema.
<wgrant> That is almost as bad.
<lifeless> uhm
<lifeless> not at all
<lifeless> totally different
<lifeless> *and*
<lifeless> in the object model we can still map up to three objects if we want; or base classes.
<lifeless> but sql /is not/ an object db, and its query performance /is not/ that of object traversal.
<lifeless> approaching things from the wrong end here will give shocking results. (Which btw, we have).
<wallyworld> wgrant: those changes look sensible to me. wonder why they were needed now? what's changed?
<wgrant> wallyworld: Nothing changed. They've been needed since the new table was introduced.
<wallyworld> lifeless: the changes to security.cfg and reverting use of the lp_dbuser cm pretty much make the original mp redundant
<wallyworld> wgrant: ah ok. didn't realise it was a new table.
<wallyworld> so it the tests need the permissions, how does it work in production ie for the app itself?
<wgrant> wallyworld: I reverted the test DB changes, instead granting INSERT on personselection to every DB role that has INSERT on person, since Person.__init__ creates a PersonSelection.
<wallyworld> wgrant: yeah i realise that :-) just wondering how this hasn't come up before now, unless the original branch which introduced the new table was very recent
<wgrant> wallyworld: The original branch hasn't landed yet...
<wgrant> This MP has a prereq.
<wgrant> The prereq adds the table, and has not yet landed.
<wgrant> That's why this is on db-devel.
<wallyworld> ok. now it makes sense
<wallyworld> although staging uses db-devel
<wallyworld> wgrant: so you are going to put up a mp for your branch?
<wgrant> wallyworld: I suppose so.
<wgrant> Not sure it really needs one.
<wgrant> But I might as well.
<wallyworld> wgrant: i'm not sure what sop is in these cases?
<wgrant> If it were my branch to start with, I'd just land it without rereview.
<wallyworld> wgrant: me too, but in this case, not sure. maybe lifeless can look since he was the original reviewer?
<lifeless> wgrant: you're fixing an unlanded mp right?
<lifeless> wgrant: throw up a branch with the other one as a predicate
<lifeless> I'll have a look in a minute, once I finish this mail.
<wgrant> lifeless: Half way there.
<wallyworld> wgrant: where do i look to estimate when a particular rev will deploy on qastaging, like you did yesterday
<wgrant> wallyworld: Ha ha ha.
<wgrant> wallyworld: You need to predict when buildbot will bless it.
<wgrant> Once buildbot has blessed it, buildbot-poller will pull it into stable within 15 minutesish.
<wallyworld> wgrant: it's green in bt now
<wallyworld> /sbt/bb
<wgrant> Unless there is a stable->db-devel merge stuck in PQM, in which case it won't pull anything more until that is processed.
<wgrant> Once it's in stable, it should be on qastaging in about an hour.
<wallyworld> wgrant: ok. bb finished it about maybe 30 minutes ago i think
<wgrant> You can check /srv/lp-pqm-logs/pqm_logs/buildbot.log and /srv/launchpad.net-logs/qastaging/asuka/qastaging-update.log to get some progress info.
<wallyworld> wgrant: ah. that's what i needed. thanks
<wgrant> And you can rsync them manually if they are not syncing frequently enough.
<wallyworld> wgrant: i can wait a little longer. once that rev lands in qas, i can qa it
<wgrant> lifeless: MP and diff up.
<wgrant> https://code.launchpad.net/~wgrant/launchpad/bug548-db-2-tests/+merge/48579
<wgrant> wallyworld: What about bug #670452?
<_mup_> Bug #670452: Hard to find related branches when composing recipe <lp-code> <qa-needstesting> <recipe> <Launchpad itself:Fix Committed by wallyworld> < https://launchpad.net/bugs/670452 >
<wallyworld> wgrant: that's then one i need this latest rev to finish qaing
<wgrant> Ah.
<wgrant> 12320 is a bit odd.
<wallyworld> how so?
<wgrant> It has [no-qa], and there are no linked bugs, but it lists two bugs and says it's missing QA tags.
<lifeless> check the revisions
<lifeless> jus ta thought
<wgrant> I am looking.
<wgrant> But codebrowse is being disagreeable.
<StevenK> wgrant: More than usual?
<wgrant> Ah, interesting.
<wgrant> One bug is in the branch name.
<wgrant> The other linked to the branch.
<wgrant> But not in the commit message.
<wgrant> I didn't think it looked beyond the commit message :/
<wgrant> Ah, it does.
<wgrant> It checks the branch nick, extracts bug numbers from that, and then looks up linked bugs on the LP branch with the same name.
<wallyworld> wgrant: interesting that the rev is listed twice in the qa report?
<wgrant> wallyworld: Because there are two bugs.
<wallyworld> doh!
<wallyworld> wgrant: but 12317 has 2 bugs too
<wgrant> wallyworld: Ahh, I see what's happened.
<wgrant> It saw the no-qa.
<wgrant> So it tagged both bugs as qa-untestable.
<wgrant> But then henninge untagged one of them.
 * wgrant retags.
<henninge> wgrant: no, why?
<henninge> wgrant: it's not the fix for the bug
<henninge> oh, hang
<henninge> on
<wgrant> henninge: It was in the branch name, so qa-tagger thinks it is.
<spm> wgrant: did I ever tell you that asuka-wants-to-get-rocked is complete?
<wgrant> It needs to retain the qa-untestable tag.
<wgrant> Until we deploy r12320.
<henninge> ah, ok
<wgrant> spm: I think so.
<spm> oh cool. just had a moment of doubt there.
 * henninge did not know about the branch name
<wgrant> henninge: Neither did I.
 * wallyworld didn't either
<lifeless> spm: you didn't, we knew, query fixed, landed earlier today
<lifeless> might even be on qas now
<spm> oh cool.
<lifeless> wgrant: 477 lines (+127/-96) 5 files modified (has conflicts)
<wgrant> lifeless: Huh?
<wgrant> Grrr.
<wgrant> It does not conflict locally. Perhaps the prereq is breaking things.
<wgrant> The number of conflicts visible in that diff is between 0 and 0.
<wgrant> Must be in the prereq. yay.
<lifeless> heh
<lifeless>  where did that copy archive query fix go
<lifeless> I shot it at ec2
<wgrant> No, that's not it either.
<wgrant> Oh.
<wgrant> I proposed into devel, not db-devel.
<lifeless> ah
<lifeless> 12323
<wgrant> :( Deployment-Ready has filled up again
<lifeless> ok, its on stable
<lifeless> waiting for qas to update
<wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/bug548-db-2-tests/+merge/48580
<lifeless> mars: hi
<wgrant> lifeless: The lib/canonical/widgets is a lie.
<wgrant> But apart from that it looks OK.
<wgrant> Actually, I think the whole thing is a lie.
<lifeless> wow that widgets file sure gets around
<lifeless> ok, so you've backed out all the stuff, because none of was actually broken.
<wgrant> I didn't back it out far enough, though.
<lifeless> even though we may have more person.insert than needed, we're not trying to fix that right now.
<lifeless> what did you miss?
<wgrant> Ah, no, I think it's OK.
<wgrant> Just some confusion as to what was there before.
<lifeless> doit
<wgrant> Thanks.
<wgrant> wallyworld, lifeless: Heading off to ec2.
<wgrant> I'm out for most of the evening, but I'll check up on it when I return home.
<wallyworld> wgrant: \o/ thanks!!!
<lifeless> wgrant: ciao
<wgrant> wallyworld: You need 12327, right?
<poolie> hi all
<wallyworld> wgrant: yeah. waiting, waiting
<poolie> i hope the oauth change doesn't break anything
<wallyworld> hi poolie
<wgrant> wallyworld: That's about 5 hours away.
<poolie> i guess we shall see
<poolie> it would be a shame if there was some weird side effect
<wallyworld> wgrant: WTF?
<wgrant> wallyworld: The last successful buildbot run was 12324
<wgrant> wallyworld: The one in progress is 12328
<wgrant> I think tomorrow I will try to write a cron job to automatically report this stuff, because it is too spread out.
<lifeless> poolie: oauth change?
<wallyworld> wgrant: bollocks. it's cutting it real fine then for pqm closure
<wgrant> wallyworld: Hm? It's already past PQM.
<wgrant> And if it's broken, then you can r-c the fix yourself :P
<wallyworld> wgrant: in case there's something else wrong :-)
<wallyworld> true, but i don't want to do that :-)
<poolie> lifeless, i deleted the second copy of oauth.py from the tree
<lifeless> oh right
<lifeless> poolie: did you land via ec2 land?
<poolie> there's not much specific benefit, so it would be a shame if there's accidental breakage
<poolie> i ran it here
<lifeless> the full suite?
<poolie> it failed due to something else in the tree being broken
<poolie> but with exclusions it passed
<wallyworld> poolie: we know where you live if something happens :-)
<poolie> i'd be more concerned there's something about deployment that causes it to not find the right external oauth
<poolie> but, we shall see
<poolie> it was still waiting for hudson
<wgrant> poolie: It'll be fine if it works on ec2.
<lifeless> deployment matches test environment quite closely
<wgrant> Except for sourcecode.
<wgrant> But this isn't sourcecode.
<wgrant> I know it's OK egg-wise, because that's what makes it take so. damn. log.
<poolie> this is making it depend on sourcecode for something where it previously did not
<wgrant> +n
<wgrant> poolie: This is an egg, not sourcecode.
<poolie> ok
<LPCIBot> Project devel build (417): STILL FAILING in 6 hr 13 min: https://hudson.wedontsleep.org/job/devel/417/
<LPCIBot> * Launchpad Patch Queue Manager: [r=thumper][bug=316694] Add a web_link property to the JSON
<LPCIBot> representation of all web service entries that correspond to
<LPCIBot> some page on the Launchpad website.
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][bug=709717] Remove an unnecessary join to
<LPCIBot> sourcepackagerelease when counting packages that are being
<LPCIBot> built/waiting to be built in ArchiveView.num_pkgs_building
<LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][bug=705342] Fail nonvirtual builders in the ABORTED
<LPCIBot> state rather than cleaning them,
<LPCIBot> since we can't guarantee that there's no active build.
<LPCIBot> * Launchpad Patch Queue Manager: [r=jtv][bug=705652] Log warnings in the remove_translations script if
<LPCIBot> current translations are removed. Removed the theoretically
<LPCIBot> impossible case of finding a diverged translation being current
<LPCIBot> in upstream which is linked to a POTemplate having a diverged
<LPCIBot> translation being current in Ubuntu.
<LPCIBot> * Launchpad Patch Queue Manager: [r=deryck][ui=none][no-qa] Provide translation sharing information.
<mrevell> Hey up 'padders
<jtv> hi mrevell!
<bigjools> helleau
<jtv> hi bigjools
<jtv> Which reminds me of coffee
<jtv> brainzzz
<bigjools> yay PG vuln
<jtv> integer overflowâa type of vuln I suspect we haven't even begun to make a dent in, as an engineering discipline.
<jtv> Well okay, in this case, buffer overflow from large integers I suspect
<bigjools> interesting
<jtv> hi al-maisan!
<al-maisan> hello jtv, how are things?
<jtv> al-maisan: they are bloody cold, thank you. âº  You?
<al-maisan> jtv: ha-ha .. you must be in good, old Europe then :)
<al-maisan> jtv: doing well, thanks, the weather in ZÃ¼rich is "mild" in comparison with the previous days
<jtv> Soâ¦ ice but no penguins?
<Ursinha> morning
<jtv> Hi Ursinha!
<al-maisan> jtv: penguins .. in the zoo maybe ;)
<jtv> allenap: http://pqxx.org/development/libpqxx/wiki/AllSoftwareIsBroken
<allenap> jtv: Cheers :)
<lifeless> jtv: typo
<lifeless> 'that what' should be 'than what'
<jtv> allenap: still needs work, and Maris had some useful feedback on it.  If you have any ideas (maybe I should open a discussion page) I can forward them.
<jtv> thanks lifeless!  Will fix right away.
<Ursinha> hi jtv :)
<lifeless> jtv: actually, I think I misparsed.
<lifeless> jtv: either way :)
<jtv> lifeless: did you misread the "That was"?
<lifeless> I think so
<jtv> OK, then it stays unchanged.
<lifeless> mars: hi
<lifeless> actually
<lifeless> gnight
<bigjools> jtv: remind me where your MF branch is and I'll re-test
<jtv> bigjools: I thought my MF branch was already on dogfood.  But it's also at lp:~jtv/launchpad/bug-181368-parallelize
<jtv> Why do I have so much trouble spelling that word lately?
<bigjools> jtv: for some reason DF has a diff in test_ftparchive.py but not in the publisher code
<jtv> ough
<bigjools> "pilfering_puppy" ....?!
<jtv> Yes, doesn't that make sense?
<jtv> I think it's a wonderful release name.
 * bigjools wonders what Q will be
<jtv> querulous quopossum?
<bigjools> reaching
<jtv> very
<adeuring> good morning
<jtv> morning adeuring!
<adeuring> hi jtv!
<jelmer> jcsackett: hi
<jtv> and hello jelmer, hello jcsackett :)
<jelmer> Jeroen!
<al-maisan> Good morning adeuring
<adeuring> hi al-maisan!
<jelmer> hi Abel, Muharem
<al-maisan> hello jelmer :)
<adeuring> hey jelmer!
<jtv> jelmer: you strike me as a likely chap to be able to improve this documentation: https://dev.launchpad.net/LaunchpadPpa?highlight=%28launchpad%5C-dependencies%29#launchpad-dependencies
<jtv> "Edit debian/control to add or change the dependencies. Your name + email address must match an identity in your GPG key exactly."
<jelmer> jtv: maybe :)
<jtv> As an amateur, I would've thought the name and email address went into changelog.
<jtv> Also, I don't suppose there's any way to add a dependency for lucid?
<jelmer> jtv: That comment doesn't seem like it belongs on the line about debian/control
<jtv> Right.
 * jelmer does the wiki editing thing
<bigjools> jtv: we need a separate lucid package, *unless* the new a-f version is larger than lucid and less than maverick's
<bigjools> you can add "apt >= <new version>" in that case
<jtv> It's inbetween.  I'm just wondering: if I say "maverick" in the changelog, will the change still go into lucid machines?
<bigjools> jtv: when I changed them recently, I uploaded to maverick, and then package-copied w/binaries to lucid
<jtv> I have a >> dependency to be precise, for complicated reasons.
<bigjools> and natty
<bigjools> why?
<jtv> Complicated reasons.
<jtv> gmb added a "lucid" entry to the changelog last month.
<jtv> bigjools: I guess the binaries don't amount to much for this stuff.
<bigjools> no
<jtv> So the same copy would work for me as well.
<bigjools> but you need to select that option or it won't copy
<jtv> It'll detect the maverick entries in the changelog and refuse to build for lucid?
<bigjools> no, you can't copy intra-archive without binaries
<jtv> ah
<jtv> jelmer: thanks for the fix :)
<henninge> jtv: Hi!
<jtv> hi henninge!
<henninge> jtv: Can you have a look at this mp, please and possibly review it?
<henninge> https://code.launchpad.net/~henninge/launchpad/devel-710591-setcurrenttranslation-extension/+merge/48594
<jtv> henninge: yes on the former, maybe on the latter :-P
<henninge> I know, I know ...
<henninge> ;)
<jtv> JokingâI'll review.
<jtv> For a price^H^H^H^H^H^H^H^C
 * henninge might fall asleep though
<jtv> and jtv might eat a bitâwon't take long.
<jtv> henninge: typo in ITranslationMessage.acceptAsImported: sold_style_import
<jtv> henninge: also, please move the "real" docstring from the model class to the interface.
<jtv> Oh, the big one is on POTMsgSet, not TranslationMessage.
<henninge> jtv: right, that is modeled after approve.
<jtv> Sorry about that.
<henninge> jtv: I just saw that "lib/lp/app/widgets/__init__.py" appears in the diff. I had a conflict when pulling the latest devel.
<jtv> I was wondering about that but decided not to whinge. :)
<henninge> That is not supposed to be in my brnach.
<jtv> henninge: I see that the design discussion opened up another can of worms about imports as well.
<henninge> which design discussion?
<jtv> The design discussion for your branch.
<jtv> "What to do about Ubuntu packaged/published/imported/upstream imports."
<henninge> ah, that.
<henninge> Well, I realized when doing this that using "approve" in the importer is just not The Right Thing.
<jtv> If I read the docstring correctly, this means that messages that get made current during import aren't marked as reviewed.  I thought they were, actually.
<henninge> jtv: btw, the next branch will actually update the importer.
<henninge> No, they were not,
<henninge> I checked the old code.
<jtv> That explains why I can't look up the answer to that question in the diff.  :)
<jtv> So we were getting is_current messages without a review date?
<henninge> Obviously yes, since ever.
<henninge> David and Robert were pretty confused when all translations uploaded by Robert were marked as being reviewed by him.
<jtv> When you update the import code, will we keep the implicit support for non-reviewer uploads?
<jtv> "if is_reviewer: acceptAsImported(...)"?
<jtv> Because I thought that was very nice in your existing code.
<henninge> Hm
<bigjools> jtv: what did you change in the a-f stuff?
<bigjools> jtv: it works for the package I uploaded but there's loads of new warnings in the log
<jtv> bigjools: ah
<jtv> that was a bonus
<jtv> I logged stderr from the sub-process at a higher level.
<jtv> It was previously DEBUG, which seemed inappropriate.
<bigjools> hmmm ok
<jtv> Want me to change that?
<bigjools> no, let's roll with it
<jtv> I was about to haggle down to INFO.  :)
<jtv> But stderr is meant to be for error stuff, after all.
<bigjools> the DF warnings are genuine, just annoying
<jtv> Then maybe the real lesson is that we should fix them.
<bigjools> it's basically because we've not got an intact archive on there due to lack of space
<henninge> jtv: I had not planned on that. I was going to use "old_style_imports" only if the upload is by_maintainer and to a source package and no upstream template eixists.
<bigjools> jtv: nothing to fix
<henninge> jtv: but I don't plan to use approve for anything.
<bigjools> other than to publish with the "careful" option - but we'd run out of disk space pretty quick
<jtv> henninge: is this related to it being old-style though?  I would have thought you were going to replace the approve call with an acceptAsImported one.
<henninge> exactly
<henninge> but the "old_style" parmeter is only True when those three conditions are met
<henninge> s/is/will be/
<jtv> henninge: then this isn't really "old style" (especially since AFAIK we have no plans to change it), more a kind of "upstream-by-proxy style" import.
<henninge> well, I called it old_style because it uses "is_current_upstream" like the old "is_imported"
<henninge> when importing to a source package
<jtv> henninge: yes, but think from the perspective of an engineer who's not familiar with Translations as it was before Recife, who now has to work on the codebase.
<jtv> Unlikely, I know.  :-)
<bigjools> is anyone already fixing devel?
<henninge> oh, I have a few engineers here in my squad that are having fun with the codebase...
<jtv> henninge: that engineer won't have "old style" as a reference base, and won't be interested in it, and will interpret it as legacy stuff, to be grandfathered in eternally and then removed.
<jtv> So can you come up with a more descriptive name?
<henninge> jtv: ok, renaming is fine by me.
<jtv> "Two things are hardâ¦"
<henninge> Not when I am this tired ... ;)
<henninge> what was the other one?
<bigjools> is anyone even bothered about devel?
<henninge> What's wrong with it?
<henninge> jtv: upstreamless_imports ?
<henninge> one_sided ?
<jtv> bigjools: is it buildbot?
<bigjools> it fails locally too
<jtv> We may have grown too accustomed.
<jtv> whoops
<jtv> henninge: deliberately taking the distraction to give the brain time to percolate. :)
<jtv> bigjools: what test?
<bigjools> Failure in test canonical.launchpad.webapp.tests.test_authentication.TestOAuthParsing.test_split_oauth
<bigjools> see my email
<jtv> argh not oauth
<wallyworld> bigjools: i just logged on the check how things were going. build failure :-(
<bigjools> wallyworld: yeah, see the email I sent
<wallyworld> jtv: bigjools: poolie landed a branch which deleted a "duplicate" oauth.py or something like that
<wallyworld> perhaps we rollback that branch?
<bigjools> that was my thought unless someone knows how to fix it
<wallyworld> i'm not across fully the reason for making the change that was made
<bigjools> I know pretty much bugger all about oauth :/
<wallyworld> well that makes at least 2 of us
<wallyworld> i'm waiting on rev 12327 to get to qastaging so i can complete qa of one of my bugs too
<wallyworld> but with the build failure, that ain't gonna happen anytime soon
<jtv> Passes for me locally.
<deryck> Morning, all.
<jtv> Few hours old all.
<bigjools> jtv: the failing test?
<jtv> Hi deryck
<jtv> Few hours old *though* :)
<jtv> bigjools: yes, test_launchpad_login_source
<bigjools> you have latest devel?
<jtv> Few hours old.
<jtv> I'm not sure about updating it now!
<bigjools> test_split_oauth is the test
<jtv> Ah that oneâpassed as well.
<bigjools> ?!
<bigjools> you have latest sourcedeps etc?
<jtv> Guess not.
<jtv> henninge: how about calling the new behaviour "upstream for package"?  POTMsgSet.acceptAsImported is really two methods dressed up as one horse though, so I'd advocate splitting it up and putting the "if" all the way in the calling code.
<wallyworld> bigjools: the oauth.py removed from lib/contrib is different to the one from the oauth egg
<bigjools> AWESOME :)
<wallyworld> so that's likely the reason that test fails
<wallyworld> the one removed could well be the old, buggy version but.......
<wallyworld> and maybe all we need to do is update the failing test, but i don;t have enough knowledge about all this to do that
<bigjools> me neither
<wallyworld> anyone else likely to know?
<bigjools> we probably need to wait for our friends in North Carolina to wake up
<wallyworld> we could ask one of the reviewers but they're not here atm
<wallyworld> bigjools: so pqm should close as scheduled in 30 minutes and we land a rc fix after that?
<wallyworld> or we want to land a rollback now?
<wallyworld> or something else?
<bigjools> wallyworld: I thought PQM was closing in another 3.5 hours
<wallyworld> oh have i got the tz wrong?
<bigjools> it was 1600 UTC right?
<wallyworld> 14:00UTC
<wallyworld> but it can be 16:00 :-)
<bigjools> argh
<bigjools> seems an odd time :)
<wallyworld> i just copied from what happened last release :-)
<bigjools> make it 23:00, go on :)
<bigjools> you can do whatever you like, you're the RM
<wallyworld> well, i vote that we make it 16:00 to fix this issue :-)
<bigjools> typically we close it when the US guys finish on a Friday
<bigjools> which is 2300
<wallyworld> which tz?
<bigjools> there is Only One TZ
<bigjools> :)
<bigjools> my db-devel branch is in ec2 right now as well, if it doesn't land I'll probably have to kill kittens
<wallyworld> bigjools: just to be sure, so you saying to close pqm in 3.5 hours
<bigjools> wallyworld: in 11.5 hours
<wallyworld> bigjools: cool, even better. it's late here and i'm easily confused
<bigjools> you'll allmost certainly catch people off guard closing at 1600!
<bigjools> wallyworld: actually I meant 10.5 hours :)
<wallyworld> ok. i should check in with a losa to make sure the closing time is clear
<bigjools> probably a good idea
<wallyworld> bigjools: so that will allow your db-devel branch to land and the us guys time to look at the oauth issue
<bigjools> yup
<wallyworld> ok
<bigjools> awesome - go get some sleep, enjoy your weekend
<wallyworld> are you able to ping someone from across the pond to follow up?
<bigjools> yeah I'll chase
<wallyworld> awesome. thanks
<bigjools> nae prob
<wallyworld> gary_poster: that branch i submitted to ec2 failed tests
<wallyworld> so as a quick fix, wgrant added the required insert/update permissions to security.cfg for the personsettings table
<wallyworld> and the use of the db_user context manager was rolled back
<wallyworld> gary_poster: just as an fyi in case you were wondering what happened ^^^^^^
<wallyworld> bigjools: i'll send mbarnett an email about the altered pqm closing time but if he appears before your eod, if you could irc him also that would be great. tia :-)
<bigjools> sure thing
<adeuring>  /topic https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: adeuring | https://code.launchpad.net/launchpad-project/+activereviews
* bac changed the topic of #launchpad-dev to:  https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: bac| https://code.launchpad.net/launchpad-project/+activereviews
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: bac, adeuring| https://code.launchpad.net/launchpad-project/+activereviews
<gary_poster> wallyworld: thank you!  so, the main branch landed
<gary_poster> ?
<gary_poster> and I should clean up the insert/update bits ?
<wallyworld> gary_poster: i think instead your branch was branched and the changes i alluded to made and that one was landed
<gary_poster> awesome
<gary_poster> looking for db-devel
<wallyworld> i had to go and get the kid from school so missed the main action
<gary_poster> I assume I should fix that up now
<gary_poster> :-)
<wallyworld> gary_poster: i think the concensus was that the lack of permissions on the personsettings table was the true root cause issue that needed fixing
<wallyworld> so not sure there's too much to fix
<wallyworld> in other words, perhaps the db_user context manager was not needed
<gary_poster> hm.  I didn't think that was actually necessary, especially for the files I touched for instancer
<gary_poster> that is, the tests needed the enhanced permissions
<wallyworld> ceratinly it's still there but the tests have been reverted not to ust it i believe
<gary_poster> for stup
<gary_poster> gotcha
<gary_poster> for setup I meant
<gary_poster> I don't see it on https://code.launchpad.net/~launchpad-pqm/launchpad/db-devel
 * wallyworld looks
<wallyworld> gary_poster: here's the branch https://code.edge.launchpad.net/~wgrant/launchpad/bug548-db-2-tests
<gary_poster> yes I found, thank you
<gary_poster> What does status "Superseded" mean I wonder
<gary_poster> never seen that one before
<wallyworld> me either :-)
<gary_poster> oh there it is
<gary_poster> https://code.launchpad.net/~wgrant/launchpad/bug548-db-2-tests/+merge/48580
<wallyworld> i thought it was submitted to ec2
<gary_poster> maybe it failed some more :-/
<wallyworld> there's a buildbot failure atm which may be holding things up
<gary_poster> ah
<wallyworld> you don't know about oauth per chance?
<gary_poster> foundations was in charge of it but I barely knew much of anything.  lessee...benji is still sick...stub also worked on it
<gary_poster> and then salgado is on another team
<gary_poster> so we have no experts :-(
<gary_poster> I can stare at it too
<wallyworld> :-(
<gary_poster> there's no visibility into the test output of my branch
<wallyworld> the oauth.py frob lib/contrib was removed sinces there's a version in the oauth egg
<gary_poster> which is a shame
<wallyworld> but the 2 versions are different and now there's a test failure
<gary_poster> so I guess I'll dig into this a bit
<gary_poster> can we simply revery?
<gary_poster> revert
<salgado> gary_poster, I'm happy to have a look at that, if you'd like
<wallyworld> gary_poster: you mean the one that i landed?
<gary_poster> salgado: thank you!
<wallyworld> the test output from that ec2 run i did for you?
<gary_poster> wallyworld: I got that.  I meant the one from wgrant
<wallyworld> oh.
<gary_poster> the changes in wgrant's branch do look good, but actually, I still think what I had will be necessary
<wallyworld> gary_poster: btw, bigjools is going to follow up with someone in the usa about the oauth thing. i asked you because i had your attention :-)
<gary_poster> there are some dbusers who don't have person access at all
<gary_poster> :-)
<bigjools> I was going to be asking gary anyway :)
<gary_poster> :-P :-)
<jtv> bigjools: another thing that should become faster with my "view" branch is finding binary package files on a distribution.  The soyuz queue and sync-source seem to make use of that.
<gary_poster> Since salgado has volunteered I think we're officially saved
<gary_poster> bigjools, wallyworld ^^^
<wallyworld> \o/
<bigjools> gary_poster: sorry I'm a bit behind on this conversation, is he fixing the issue or reverting it?
<gary_poster> yes bigjools :-P  I never got around to seeing what the issue was
<bigjools> jtv: great!
<wallyworld> gary_poster: also as an fyi, i got the pqm closing time wrong so it's now 23:00UTC not 14:00UTC
<wallyworld> so there's time to get stuff sorted
<jtv> bigjools: the more positive you are, the more I feel we must be ignoring some major screwup on my part.  :-)
<wallyworld> there's a db-devel rev which needs qa but i'm sure curtis will do that before eod :-)
<bigjools> jtv: I'm sure you'll be fine :)
<gary_poster> yay!  so now we are at...13:16 UTC?  I forget if I am -5 or -4 .  looking
<bigjools> wallyworld: I have a db-devel that will land soon when ec2 finishes it
<gary_poster> yeah
<jtv> bigjools: I guess you just found my "be more careful" button.  :-)
<wallyworld> i've got one to but need 12327 to land on qastaging first >:-(
<gary_poster> so we have 9:40-ish, yeah wallyworld?  That's awesome.  Thanks for the heads up
<bigjools> wallyworld: mine's already QAed
<wallyworld> gary_poster: yeah. i thought i copied from what happened last release but clearly was smiking something that day to get the time so wrong
<gary_poster> :-)
<wallyworld> bigjools: thanks!
<wallyworld> night guys, have a good day. good luck with the oauth thing. email if you need me to do anything for the release
<gary_poster> thank you wallyworld !
<wgrant> gary_poster: Hi.
<salgado> so, this is what happened
<gary_poster> wgrant: hi, and thank you too.  1 sec finishing call
<salgado> mbp fixed bug 314507 by changing contrib/oauth.py, and in the process of that he wrote a test for the fix
<_mup_> Bug #314507: OAUTH server ignores ignores first element in header (rather than realm key) <api> <lp-foundations> <qa-ok> <Launchpad itself:Fix Released by mbp> <python-oauth (Ubuntu):Invalid> < https://launchpad.net/bugs/314507 >
<wgrant> gary_poster: My changes are fine. But webservice tests fail because snapshotting hits "Teams do not support this attribute.
<salgado> he then noticed we didn't need contrib/oauth.py because we already have a python-oauth egg new enough, which has a fix similar to the one he did to contrib/oauth.py
<wgrant> ImmutableVisibilityError: This team cannot be converted to Private since it is referenced by a personsettings.
<wgrant> That also.
<wgrant> gary_poster: Those are the only two failure modes. But I'll forward you the email.
<salgado> but the upstream fix is not really compatible with his fix, so the test fails
<gary_poster> wgrant, yeah the email would be perfect
<gary_poster> thank you again wgrant
<wgrant> No worries.
<wgrant> Email sending...
<LPCIBot> Project devel build (418): STILL FAILING in 6 hr 8 min: https://hudson.wedontsleep.org/job/devel/418/
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless,
<LPCIBot> wallyworld][bug=712882][no-qa] Silence non-error output from
<LPCIBot> mirror-prober.sh.
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][bug=670452] Fix layout of related branches collapsible
<LPCIBot> fieldset
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][no-qa] Remove duplicated urgencymap in gina.
<LPCIBot> * Launchpad Patch Queue Manager: [r=jcsackett,
<LPCIBot> sinzui][ui=none][bug=701545][no-qa] remove extra copy of oauth.py
<salgado> gary_poster, I've replied to bigjools' email.  bottom line is, I think the change should be reverted until we get a python-oauth with a fix that makes the test pass
<gary_poster> salgado: makes sense.  thank you very much!
<jtv> adeuring: I'm about to head off for FOSDEM, but was wondering if you could review this one: https://code.launchpad.net/~jtv/launchpad/bug-181368-view/+merge/48609
<gary_poster> bigjools: are you available to (find someone on a bug rotation to) do that?
<adeuring> jtv: sure, I'll look
<jtv> adeuring: and thanks for that other review, very discreet!
<jtv> bigjools: any luck on dogfood?
<salgado> gary_poster, np
<gmb> deryck: YUI JS tests are run as part of our harness, True or False?
<deryck> gmb, True
<gmb> deryck: Thanks.
<deryck> abentley, hey, hey.  standup ping.
<deryck> gmb, and YUI tests should be preferred to Windmill
<bac> deryck: so how does one run a YUI test from the command line?
<jtv> bigjools, adeuring: I'm not long for this login.  If there's anything you need me for, speak now or for the weekend hold your peace.
<wgrant> gary_poster: Did my email make it?
<gary_poster> yes, thank you much wgrant.
<deryck> bac, firefox path/to/test/file.html
<wgrant> Great.
<wgrant> gary_poster: They look easy enough to fix.
 * wgrant sleeps.
<gary_poster> wgrant, agreed.  night
<deryck> bac, and currently, they are not pretty and easy to read unless you set fetchCSS: true in the test.
<bac> deryck: that's not command line.  how are they run by our test harness?
<deryck> bac, ah, sorry. xvfb-run ./bin/test -cvvt test_yuitests
<deryck> bac, that will run *every* YUI test.  You can limit by adding --layer=BugsWindmillLayer (or whatever app layer you need)
<bac> deryck: thanks!
<deryck> bac, also, there is no way to run a single YUI file via bin/test.
<bac> deryck: gotcha
<bac> deryck: i'll add that to the wiki
<deryck> but if you TDD with YUI test it makes sense to keep the browser open.  so using firefox path/to/test makes sense there, I think.
<deryck> or whatever browser you prefer, obviously.
<bac> deryck: right
<jtv> henninge: I gave you a conditional approval, by the way, on the points we discussed.
<bigjools> jtv: it worked ok
<bigjools> thought I'd already said that :)
<bigjools> gary_poster: I can revert it
<jtv> bigjools: maybe I just missed it.  All I remember seeing is the bit about the warnings.  So the files were produced correctly, not one architecture overwriting the rest or anything?
<gary_poster> thanks bigjools
<jtv> bigjools: and also, what did it do to performance?
<bigjools> jtv: hard to say about that, DF only has one builder
<bigjools> but the Package file I looked at was updated ok
<jtv> bigjools: well for this purpose, "source" is an architecture.
<bigjools> jtv: the Sources file was also ok
<bigjools> no idea with performance
<bigjools> the longest part by far is where we generate the files for a-f
<jtv> bigjools: I've been assuming that the outputs for different architectures never write to the same files, based on wgrant's note that it could be parallelized.
<bigjools> correct
<jtv> Phew.
<jtv> Got a branch in review that'll hopefully speed that part up a bit, but had to stop myself from trying to fix everything.
<bigjools> there's one file per suite-arch
<jtv> What I thought/hoped.
<jtv> I think we could probably ditch the batch processing now, since it's trying to force the StupidCache's hand but we now have GenerationalCache.
<jtv> One thing it _could_ still be useful for is prejoining.  Can't do that with those get-all-packages queries, but can with a reasonably-sized batch of rows.
<jtv> That'd apply nicely to practically the entire BinaryPackageFilePublishing view: select BPPHs and BinaryPackageFiles, batch them, then batch-fetch the stuff that pulls in the other tables.
<jtv> That could save us something like half the tables in the join.
<jtv> Anyway, I have to run now!
<danilos> bac, adeuring: hi, anyone eager to take on a pretty simple branch?
<adeuring> danilos: I'm currently reviewing a branch from jtv... bac?
<bac> danilos: ok
<danilos> bac, thanks, it's up at https://code.launchpad.net/~danilo/launchpad/bug-548-use-preference/+merge/48616
<danilos> bac, fwiw, I am not sure where exactly does the change in app/widgets/__init__.py come from in there
<danilos> bac, probably one of merging artifacts (I've based in on as of yet unlanded gary_poster's branch)
<gary_poster> yeah
<gary_poster> it was an artifact on mine too, starting yesterday
<danilos> gary_poster, ah, interesting
 * bigjools just sent a testfix to PQM
<allenap> gmb, deryck: Would one or both of you have time to review https://devpad.canonical.com/~gavin/howto-import-bugs-into-launchpad.html?
<deryck> allenap, sure, I can look.
<allenap> Thanks :)
<salgado> where's sinzui?  he's replying to lp questions but is not around here?
<deryck> allenap, it's very nice.  very thorough.
<deryck> allenap, The only "gotcha" I've had that wasn't covered, was importing bugs into a private project on staging.  Thinking the bugs didn't import, when it was just that I couldn't see them.
<deryck> not sure if that should be covered or not, but otherwise, it's very well done and accurate.
<allenap> deryck: Cool. I've never done an import into a private project. Is it just that the bugs are not visible unless you've got the right puppy powers?
<deryck> allenap, exactly.  so you completely have to depend on the person to followup and check them completely themselves.
<danilos> allenap, gmb: hi guys, do you know if it's possible to set a direct subscription to LIFECYCLE through UI already (on qastaging)?
<allenap> deryck: Okay.
<gmb> danilos: It isn't.
<allenap> deryck: Thank you :)
<deryck> allenap, private is the exception, obviously.  but commercial customer imports will be this way.
<deryck> allenap, np! :-)
<gmb> danilos: Oh, wait.
<gmb> I tell a lie
<danilos> gmb, ok, thanks... ok, no thanks for you then! :)
<gmb> danilos: Yes, it can be done (sorry, I saw LIFECYCLE and read NOTHING for some reason)
<danilos> gmb, is it just +subscribe on the bug?
<gmb> danilos: if you go to bug/+subscribe you can choose it there.
<danilos> gmb, I assume I need malone-alpha membership?
<danilos> gmb, because I don't see it on https://bugs.qastaging.launchpad.net/malone/+bug/548/+subscribe
<_mup_> Bug #548: Launchpad sends change notification updates to the person who requested the change <email> <lp-bugs> <story-better-bug-notification> <story-better-notification-sending> <Launchpad itself:In Progress by yellow> < https://launchpad.net/bugs/548 >
<gmb> danilos: You're not a member of malone-alpha on qastaging. I've added you.
<danilos> gmb, excellent, thanks
<danilos> I keep getting timeouts on qastaging trying to subscribe to a bug... let me try modifying an existing subscription isntead
<mars> bac, ping
<bac> hi mars
<bigjools> testfix landed 10 mins ago
<bac> hi danilos, i'm looking at your branch.
<bac> danilos: i'm confused by bugnotification.py
<bac> danilos: why do you test not person.selfgenerated_bugnotifications instead of not recipient.selfgenerated_bugnotifications
<bac> danilos: why do you test "not person.selfgenerated_bugnotifications" instead of "not recipient.selfgenerated_bugnotifications" ? (redone for clarity)
<bac> nm
<danilos> bac, ok :) (fwiw, it's because recipient might be including the person transitively, so this is the cheapest check)
<bac> danilos: for the list of bugnotifications, the first_notification.message.owner is the person who performed the action that is generating the message?
<danilos> bac, that's right
<bac> for all bugnofitications
<danilos> bac, in that method, all notifications that are passed in are caused by the same person and for the same bug (look at asserts below)
<bac> perhaps changing 'person' to something more descriptive, like 'instigator'
<danilos> bac, sure, makes sense
<danilos> bac, btw, how do you feel about: 1) 'originator', 2) 'person_causing_change', 3) 'changed_by', 4) 'change_caused_by' or something like that?
<bac> 2
<bac> it's wordy but unambiguous
<sinzui> I suspect the worst. gedit and gvim go belly up seconds after they launch. I think I should restart before natty's desktop session ends the same way
<danilos> bac, cool, thanks
<bigjools> how had I not noticed before that the branch page shows what branch was merged in each revision and the bug - that's awesome
<jml> allenap: do you want to give my branch a spin again, see if it builds now?
<jml> bzr+ssh://bazaar.launchpad.net/~jml/launchpad/sphinx-it-up
<allenap> jml: Cool, yeah.
<sinzui> bac: do you have time for a trivial branch: https://code.launchpad.net/~sinzui/launchpad/reg-docs-1/+merge/48627
<bac> sinzui: sure
<allenap> jml: Works nicely :) security.txt had a "severe" error, which can be fixed with http://paste.ubuntu.com/562626/. I'll go and update the mp.
<jml> allenap: ta
<bac> sinzui: sorry, i was overcome by hunger and had to grab some lunch
<sinzui> bac: np. I an struggling to bring some stability to natty
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: bac| https://code.launchpad.net/launchpad-project/+activereviews
<bac> sinzui: do we need to specify the hkp port since the value you list is the default?  it's kind of like saying http://www.foo.com:80, no?
<sinzui> I do not know
<sinzui> google is not forthcoming on this question
<bac> sinzui: the bug report seemed to indicate the port was not necessary, unless i misread
<sinzui> bac: I agree
<sinzui> I am very disappointed by the lack of documentation about this
<sinzui> bac: I will remove the port because we know the default port is being used by ubuntu's keyservers
<bac> sinzui: great.
<bac> hi abentley, there is a question about code imports failing.  could you look at it?  https://answers.launchpad.net/launchpad/+question/143861
<sinzui> bac: ping
<bac> hi sinzui
<sinzui> bac: can you add open-cat-team so that I can veryify the membership is proposed: https://staging.launchpad.net/~delegated-team/+add-my-teams
<bac> done
<sinzui> \o/
<abentley> henninge, I am updating the template precedence rules so that we can merge productseries templates with sourcepackage templates.
<henninge> abentley: wie bitte?
<abentley> henninge, I'm guessing that a product translation focus should take precedence over a package translation focus.  What do you think?
<abentley> henninge, ja
 * henninge has to think about this for a moment
<henninge> abentley: I never really touched that, I think that's Jeroen's making.
<henninge> abentley: where is this precedence applied?
<bac> hi henninge and abentley.   there were questions related to your expertise that i assigned to you.  hope that is ok.
<henninge> bac: I answered mine ;)
<abentley> henninge, it's used by the message sharing migration script, which I have now refactored to be used from the job.
<bac> cool, thanks henninge
<henninge> abentley: I figured but where exactly? Is it about chosing which POTMsgSet to keep and which to throw away?
<abentley> bac, alright.
<abentley> henninge, it's used to decide which is the most "representative" POTMsgSet, which yes, I believe affects which ones get deleted.
<henninge> abentley: yes, I assume we'd want to favor the upstream template here.
<henninge> otoh, I don't think it makes a huge difference.
<abentley> henninge, in case of clashes, the subordinate is "saved" by diverging it.
<henninge> abentley: hang on, but now you are talking about translation messages.
<abentley> henninge, you're right, it's diverging translationmessages.
<henninge> abentley: in that case it might be smarter to do it the other way round.
<henninge> because of the 1:n relationship
<henninge> scratch that
<abentley> henninge, I think it's a question of whether you want to favour diverging upstream or ubuntu translations.
<henninge> abentley: a clash between upstream and Ubuntu should be solved by keeping both and setting is_current_upstream and is_current_ubuntu on each of them respectively.
<henninge> so that's not really a clash.
<abentley> henninge, would you have to mark one of them diverged?
<henninge> no
<henninge> the one will be shared on the product side, the other on the ubuntu side
<henninge> A clash is when you have different translations within different series of the same product or source package.
<henninge> Then diverging is the only solution.
<abentley> henninge, okay.
<henninge> abentley: the question here is, will the job deal with both kinds of merging: The old kind within a prouduct/sourcepackage and the new kind between a product and a sourcepackage.
<henninge> or will it assume that all products and sourcepackages it encounters are already sharing within themselves?
<abentley> henninge, the answer is "kinda".
<henninge> I think that might be okay.
<abentley> henninge, the laziest solution is to perform the merge within the product and all linked sourcepackage/distroseries.
<abentley> henninge, because we already have ways of getting that list.
<henninge> abentley: sounds right
<abentley> henninge, but we could query for just the templates within the productseries and sourcepackage that were just linked.
<abentley> Presumably, that's more efficient if we assume that the product and sourcepackage are already sharing maximally.
<abentley> (in their separate domains)
<henninge> oh, now I see your point
<henninge> officially, the message sharing migration has finished.
<henninge> (the old one)
<henninge> so the script should rightfully assume that each are sharing within themselves.
<henninge> abentley: I have to go afk for a while.
<abentley> henninge, okay.  Ping when back.
<henninge> sure
<henninge> abentley: ping (back for a little while)
<abentley> henninge, why do we limit potmsgsets to templates with the same name?  Why not share all translations of the same phrase within a piece of software?
<henninge> abentley: wow, that is a very fundamental question you are raising there!
<henninge> abentley: but I guess one easy anser might be that one of the reasons to partition the translatable strings of a piece of software into different templates is to keep domains appart.
<henninge> e.g. the UI and the backend, where the same term might be used differently.
<henninge> Also, without that, we'd have to re-define divergence a little although that already points to individual templates.
<abentley> henninge, If we really did want different translations of the same term, we could use divergence.
<abentley> henninge, it's just that I'm reimplementing that restriction, so I had to wonder how much sense it makes.
<henninge> otoh the overlap between different templates should be small.
<henninge> abentley: yes but that is not the only place in the code were that restriction is used/enforced.
<abentley> henninge, I think this restriction means that if one template splits into two, or two combine into one, we'll lose an opportunity to carry translations across.
<henninge> that is true
<henninge> abentley: I'd say that is something to think about but it would be an extra branch to introduce it.
<abentley> henninge, cool.
<henninge> But it shows how spreading the domain knowledge bring in new views and ideas. ;-)
<henninge> (or possibly an extra feature)
 * henninge has to lunch now
<maxb> Is someone doing something to the sourceforge code imports right now?
<maxb> Because I'm seeing what looks like an import that got dispatched to an import slave despite being in suspended status
<lifeless> maxb: theres no chatter in -ops about such a change
<maxb> lifeless: They're failing to present the intermediate cert in their change
<maxb> *chain
<maxb> This means that tolerant things like firefox are happy. Stricter things like gnutls and java are very much not
<lifeless> maxb: yes, so they all failed
<maxb> Someone has evidently set the imports to Suspended status, but I don't understand why they are still apparently being dispatched to the importds
<lifeless> mm
<maxb> https://code.launchpad.net/~vcs-imports/emesene/trunk for example
<lifeless> perhaps they were already queued
<lifeless> mwhudson: ^ you were involved...
<deryck> heh.  I just completed the Thunderdome survey.
<deryck> it's not exactly rick rolling.  But it's nice. :-)
<lifeless> maxb: I've toggled that one into failed and back to suspended
<lifeless> maxb: we'll see if that sorts it out
<maxb> we need code imports exposed in the api :-/
<maxb> oh for a tuit :-)
<lifeless> maxb: that would be great.
<maxb> Maybe after I finish off my in-progress bzr work :-)
<james_w> code imports are exposed to some extent
<jam> lifeless: maybe you can point me to someone else. I'm trying to write a launchpad test that asserts when something fails we *do* create an oops
<jam> but the test infrastructure seems to say "getting an oops == the test failed"
<lifeless> jam: in what context are you doing htat
<lifeless> jam: the different layers will impact this
<jam> lifeless: the oops_middlewear for the loggerhead test suite isn't yet tested
<jam> so I wanted a test that it creates an oops normally
<jam> and then doesn't create one for socket exceptions
<jam> like EPIPE
<lifeless> cool
<jam> I tracked into the stack, and we *are* suppressing the exception in the WSGIHandler, but that is above the application
<jam> and the oops logic is an app that traps it underneath that
<lifeless> yah, I saw your mail on that
<lifeless> so
<lifeless> what method is treating oops=test fail
<lifeless> jam: or are you not sure?
<jam> I'm not sure
<lifeless> pastebin the failure ?
<jam> lifeless: https://pastebin.canonical.com/42908
<jam> It may be that the oops is only reported because the test failed?
<jam> Obviously RuntimeError was raised, but maybe it doesn't propagate all the way up the stack
<lifeless> right
<lifeless> that oops is just accumulated via addDetails
<lifeless> your line 186 is the actual failure
<lifeless> File "/home/jameinel/dev/launchpad/work/lib/launchpad_loggerhead/tests.py", line 186, in test_exception_triggers_oops
<lifeless>     self.runtime_failing_app)
<jam> ahh, oops_middleware has "if error_page_sent: return" rather than raise
<jam> so if it can get to the point it can report the error, then it *doesn't* re raise the exception
<jam> I'm not entirely sure why, but I can live with it
<lifeless> well
<lifeless> we want to show a page describing the oops
<lifeless> if we raise the user gets a INTERNAL SERVER ERROR page
<jam> lifeless: which they'll get if we get an internal error after starting the response body
<jam> but... meh
<jam> not something I have to fix for what I'm working on
<lifeless> right
<lifeless> in lp proper we buffer until we know we'll succeed
<lifeless> for a few reasons, this being one of them.
<jam> mwhudson: if you're around. When I run 'make run_codebrowse' it fails when trying to access the xmlrpc server. It seems to work with 'make run_codehosting'. Should we get rid of the 'make run_codebrowse' target entirely?
<jam> ah, nm, we can't
<jam> because 'bin/run codewbrowse' actually calls back into 'make run_codebrowse'
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: -| https://code.launchpad.net/launchpad-project/+activereviews
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build (419): FIXED in 6 hr 34 min: https://hudson.wedontsleep.org/job/devel/419/
<lifeless> sinzui: hi
<sinzui> hi lifeless
<lifeless> I was wondering
<lifeless> bug 712698
<_mup_> Bug #712698: No way to expire existing sessions <Apache OpenID:New> < https://launchpad.net/bugs/712698 >
<lifeless> may be pretty - or even very - shallow
<lifeless> its outside our direct remit, but as a team we'd gain a lot if we can increase the openid nonce timeout
<sinzui> wgrant: was looking at this code two weeks ago
<lifeless> yeah
<lifeless> so it might be easy for him to eyeball and write up /how/ sysadmins can reset nonces
<lifeless> I imagine there is a non-coding solution.
<sinzui> mailman polls to keep this information synced. I am not sure if it is viable to do a push scenario since there are a lot of sites to push too
<lifeless> sinzui: well, this is for our microsites
<sinzui> getMembershipInformation(team) is the very method I refactored last week
<lifeless> sinzui: the goal is some means for the losas to ensure that folk which have left the company do not retain access
<lifeless> sinzui: e.g. its a very rare event
<sinzui> That is a special case in leaveTeam() admins (losas) can force the leave to be silent
<lifeless> sinzui: at the moment the only mechanism is doing a new openid handshake, which is very slow and annoying
<lifeless> sinzui: perhaps we're talking at cross purposes?
<sinzui> No
<sinzui> I understand what you are asking, but there is a massive gap between what we do now and what we are asking in therms of Lp integration
<lifeless> sure; this is why I was talking low tech
<lifeless> just a 'reset all the nonces for a given microsite'
<sinzui> bridging that gap requires understand what we do now, why and asking if we want to extend the behaviour or replace everything with a more comprehensive solution
<lifeless> there are only a few such sites - devpad, lpstats, lp-oops
<lifeless> sinzui: fair enough, I am rather jumping the gun :)
<lifeless> sinzui: however, sadly, I have to pop out for a while; it would be cool to make this better in any regard
<henninge> Hi! Is this a known failure? http://paste.ubuntu.com/562802/
<wgrant> lifeless, sinzui: I think we can probably just tell people to purge the OpenID session cache.
<wgrant> It would be nice if the server could rerun check_authentication behind the scenes, but it can't :/
<sinzui> wgrant: if we recorded which sites asked for which teams, and see a removal from such as team, we should push. That does require co-ordinated work of course
<wgrant> s/OpenID/mod_python/
<wgrant> sinzui: We could.
<wgrant> But that is probably going to require OpenID extensions and stuff.
<wgrant> bac: Why did you assign me to that Google Code import question?
<henninge> wallyworld: Hi, are you available to grant r-c's?
<henninge> Hm, is PQM really still open or is the subject lying?
 * henninge tries
#launchpad-dev 2011-02-05
<wgrant> It should have closed an hour ago, right?
<henninge> exactly
<henninge> I am pretty sure it's just the subject
<wgrant> sinzui: Looks like your branch broke the build?
<sinzui> :(
<sinzui> wow I played that test
 * sinzui prepares a fix
<henninge> ah, I had seen that on ec2 but could not reproduce it locally. My devel must be too old.
<henninge> which means nothing will land anyway atm because of testfix mode.
<sinzui> oh good, this looks like the test is actually wrong now. I thought I had broken one requirement while fixing another
<wgrant> Does anybody read launchpad-error-reports?
* mbarnett changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is in RC for devel | firefighting: - | On call reviewer: -| https://code.launchpad.net/launchpad-project/+activereviews
<sinzui> wgrant: I do.
<wgrant> sinzui: There is so much noise.
<wgrant> And so many errors.
<sinzui> production's would be more intelligible if several of us fixed checkwatches + external bugtrackers to not report offsite data issues as oopses. Or we add a nominal data cleansing task before we read the broken xml
<wgrant> sinzui: Oh, not the OOPS reports. The launchpad-error-reports ML's cron spam.
<sinzui> wgrant: checkwatches was divorced from the normal reports because of this, but the issues were not fixed. lifeless hops to may the problem visible by spamming the report
<sinzui> wgrant: sorry, my confusion. I specifically tag the messages that talk about teams, karma, the prf, and distributionmirrors
<wgrant> sinzui: Ah. I silenced the DMP (except for errors) yesterday.
<sinzui> I was certain your bug was a dupe. spm had remarked about it in the past. I could not find it though
<wgrant> :(
<wgrant> Damn. We could deploy that and the nightly.sh fix now, if it wasn't Friday afternoon.
<LPCIBot> Project db-devel build (343): FAILURE in 5 hr 38 min: https://hudson.wedontsleep.org/job/db-devel/343/
<LPCIBot> Project devel build (420): FAILURE in 5 hr 18 min: https://hudson.wedontsleep.org/job/devel/420/
<LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][no-qa] Machinery for building documentation with sphinx
<LPCIBot> * Launchpad Patch Queue Manager: [r=bac][bug=710054][bug=530476][bug=530477] Fix the protocol in the
<LPCIBot> gpg documentation and branch and MP api docs.
<LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=693689] Escape the token and title in
<LPCIBot> lp.app.widgets.itemswidgets renderer.
<LPCIBot> * Launchpad Patch Queue Manager: [r=henninge][ui=none][no-qa] Add direct unit tests for
<LPCIBot> TM.shareIfPossible
<lifeless> wgrant: resetting the cache would be fine, but noone knows how to do that
<lifeless> it would be nice to fix deleting of unpublished packages to actually delete.
<wgrant> Possibly.
<lifeless> wgrant: so what do you think, is there some way to purge apache-openid nonces?
<wgrant> lifeless: Probably rm /tmp/mp_sess.dbm
<wgrant> Unless the mp config has been customised.
<wgrant> But devpad has that file.
<lifeless> wgrant: care to note that in the bug; do we need a graceful or will it be recreated automatically?
<lifeless> hmm
<lifeless> ProtocolError for xmlrpc.lp.internal:8097/codehosting: 502 Bad Gateway
<wgrant> lifeless: I believe it should be recreated automatically, but I've never used the default dbm store before.
<lifeless> not a great sign
<lifeless> hmm, i think I made it oops :P
<wgrant> Which?
<lifeless> pushing to lp:debian/sid/python-poster/packaging
<lifeless> 8boom8
<wgrant> Hah.
<wgrant> That should blow up. But nicely, not with an OOPS.
<lifeless> just gives a 502
<lifeless> I'm sure its booming in the background
<wgrant> Awesome.
<wgrant> Does it tell you which method it was executing?
<lifeless> no
<lifeless> robertc@lifeless-64:~/source/debian/poster-0.7.0$ bzr push lp:debian/sid/python-poster/packaging
<lifeless> Working tree "/home/robertc/source/debian/poster-0.7.0/" has uncommitted changes (See bzr status). Uncommitted changes will not be pushed.
<lifeless> bzr: ERROR: Server sent an unexpected error: ('error', '<ProtocolError for xmlrpc.lp.internal:8097/codehosting: 502 Bad Gateway>')
<wgrant> Ah. Fun.
<lifeless> btw ^ - lets you upload to +storeblob
<wgrant> Anyway, add a username.
<wgrant> Hmm, why would we want to do that?
<lifeless> wgrant: subunit stream storage
<lifeless> wgrant: also, shrink the code in apport
<lifeless> I'm getting round to an old tuit of mine - subunit-upload -> lp
<wgrant> Ah, right.
<lifeless> ok, two bugs for one action with lp.
<lifeless> good times.
<lifeless> wgrant: ok, so openid -  we can experiment I guess; if you can record what you *do* know, I can pester a sysadmin on monday
<wgrant> lifeless: Commented.
<lifeless> thanks
<lifeless> !
<LPCIBot> Project db-devel build (344): STILL FAILING in 5 hr 19 min: https://hudson.wedontsleep.org/job/db-devel/344/
<LPCIBot> * Launchpad Patch Queue Manager: [r=bac][ui=none][bug=548][incr] Mute self-generated bug notifications
<LPCIBot> for accounts that set that option (iow, mute themselves).
<LPCIBot> * Launchpad Patch Queue Manager: [r=bac][ui=none][no-qa] Add "selfgenerated_bugnotifications" as a
<LPCIBot> global option for people so that we can work on bug 548. Only
<LPCIBot> in the DB at this time,
<LPCIBot> since the actual implementation is not yet done.
<_mup_> Bug #548: Launchpad sends change notification updates to the person who requested the change <email> <lp-bugs> <story-better-bug-notification> <story-better-notification-sending> <Launchpad itself:In Progress by yellow> < https://launchpad.net/bugs/548 >
<lifeless> what is webservice:register in configure.zcml for
<lifeless> figured it
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build (421): FIXED in 6 hr 13 min: https://hudson.wedontsleep.org/job/devel/421/
<LPCIBot> * Launchpad Patch Queue Manager: [testfix][rs=sinzui] Print the escaped text of the structured string.
<LPCIBot> * Launchpad Patch Queue Manager: [r=henninge][ui=none][bug=697294] Refactors create_questionreopening
<LPCIBot> to be called as a helper, rather than a listener to notifications;
<LPCIBot> this avoids the need for a slew of guards on the method, and keeps it
<LPCIBot> from doing work when we don't want it to.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (345): FIXED in 5 hr 17 min: https://hudson.wedontsleep.org/job/db-devel/345/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12330,
<LPCIBot> 12331, 12332, 12333, 12334, 12335 included.
<wgrant> jelmer: It's emailing you for successful binary builds?
<jelmer> wgrant: actually, I just have a lot of failing builds at the moment :)
<elv> Hi, how can i copy  a package fromubuntu primary archive to my ppa? i just saw some packages marked as Copied from ubuntu natty in Primary Archive for Ubuntu .
<elv> thanks
<cjohnston> This bug (Bug #340640) says there is no plan of fixing this "at the moment" but that was a year ago... Any chance we can revisit this? It is currently breaking the LoCo Directory.
<_mup_> Bug #340640: Standard way of finding mugshot url, default if not set <api> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/340640 >
<lifeless> cjohnston: we have 6000 bugs and close ~ 1000 a year
<lifeless> cjohnston: why is it breaking the loco directory now ?
<cjohnston> we are trying to pull the profile images.. but if there isnt one, it gives a broken image
<lifeless> what makes it broken? Why don' you catch the exception and use the default in that case?
<cjohnston> it tries.. i dont know if maybe the LD code is broken in that aspect or what
<lifeless> I would assume it is
<lifeless> anyhow, in the set of things we're trying to focus on, this really seems appropriate as low
<cjohnston> ok
<lifeless> if you need it escalated, the stakeholder process provides a forum for the different stakeholders to convince each other about the relative importance of things
<lifeless> -or-
<cjohnston> http://bazaar.launchpad.net/~chrisjohnston/loco-directory/edge/revision/384
<lifeless> you can supply a patch
<cjohnston> that is the code we have.. i dont know if you know anything about how it would be broken or not
<lifeless> well
<lifeless> its hard coding api urls
<lifeless> thats pretty much guaranteed to run into trouble
<lifeless> specifically -
<lifeless> beta is deprecated
<lifeless> you should use 1.0 for clients that are packaged
<lifeless> and devel for clients where you're tracking bugfixes etc
<cjohnston> ok
<lifeless> secondly
<cjohnston> thanks
<cjohnston> oo.. more
<lifeless> issuing those urls back to browsers will be very very slow
<lifeless> your website should resolve the real url using lp apis and then output that.
<lifeless> otherwise you're forcing directory viewing to do an HTTPS handshake with launchpad.net
<lifeless> (when you're already logged in and have handshaked already)
<lifeless> both of the urls you are returning are going to do a full appserver request and then issue a 302
<lifeless> what would be most efficient would be for whatever collection you're asking Launchpad for to return things with preresolved urls (which we can do for public assets).
<cjohnston> ok.. thanks
<lifeless> I'd consider a bug to enhance LP to do that high (which means 3-9 months away) priority, because we're trying to make Launchpad snappy across the board
<lifeless> in the meantime, lets see if we can work around your issue
<lifeless> got a link to a broken page on the diretory?
<cjohnston> http://loco.ubuntu.com/events/team/666/detail/
<cjohnston> sorry.. just finished dinner
<lifeless> how do we land things on lazr-js
<lifeless> cjohnston: ok
<lifeless> so in that page you're outputting this:
<lifeless> <img src="https://api.edge.launchpad.net/1.0/~drubin/logo" title="David Rubin" valign="top" width="32" height="32">
<lifeless> cjohnston: but this is a little crazy because you've done an API call to determine the team membership anyway.
<cjohnston> ok
<cjohnston> i dont know very much about the api and such... so bare with me
<lifeless> whats the api call you make to find out about the members of the team?
<cjohnston> Ronnie: do you know what the api call is that finds out the members of teams
<lifeless> Ronnie: specifically how are you populating http://loco.ubuntu.com/events/team/666/detail/
<cjohnston> lifeless: i know that we pull what team a person belongs to, the code is there, but i dont know if we use it for finding out their TZ
<cjohnston> the attendees statuses are all done completly through LD... you dont have to be a member of a team to attend an event, only to create/edit an event
<lifeless> cjohnston: do you verify their lp uids?
<cjohnston> I believe that we do now lifeless
#launchpad-dev 2011-02-06
<cjohnston> as I said, im not very familiar with this part.. thats why I invited Ronnie and I've invited mhall119 here as well
<Ronnie> im not familiar with the lp code too, it was created before i started hacking, but i think i know where too look
<cjohnston> if mhall119 makes it, hes the most familiar i believe
<mhall119> hola
<cjohnston> hey
<cjohnston> mhall119: < lifeless> whats the api call you make to find out about the members of the team?
<cjohnston> < lifeless> cjohnston: do you verify their lp uids?
<mhall119> no, we assume that the openid response 'nickname' matches the launchpad username
<cjohnston> lifeless: see... i told you he would know the answers
<wgrant> That's not ideal. Is there a reason you can't check the OpenID identifier?
<cjohnston> howdy wgrant
<mhall119> wgrant: what do you mean?
<wgrant> mhall119: LP usernames are mutable.
<mhall119> http://paste.ubuntu.com/563231/ is what we do
<mhall119> wgrant: I know, I have a merge proposal in to django-openid-auth that'll update the username on our end when the user logs in
<mhall119> can we look it up based on the identity url?
<wgrant> mhall119: Probably not at the moment. But that can be fixed easily enough.
<mhall119> we're using the launchpadlib
<mhall119> wgrant: we have the openid identity url, we can change our lookups to use that instead of username if/when that interface is available
<mhall119> lp.people[ld_user.username] is doing a lookup on the People collection exposed by the webservice API to launchpadlib
<wgrant> Right.
<wgrant> We can easily expose a method on lp.people to get a person by an OpenID identifier.
<mhall119> our other problem, and I'm not sure if you can help us with that, is that SSO sometimes returns a response without a 'nickname' field, even when the user has a launchpad profile
<wgrant> For particular users?
<mhall119> I suppose once we can do lookups based on the identity url, we can change our code to get nickname for that
<mhall119> wgrant: let me see if I can find the name
<wgrant> SSO has a bug like that for some users at the moment. It's fixed, but not yet rolled out.
<wgrant> I investigated it with one particular LD user a couple of weeks ago.
<mhall119> wgrant: that might have been for us
<Ronnie> i thought (but am not sure) that it was for users with unicode characters in the name
<wgrant> So, known SSO issue, fixed in trunk a month or so ago, but awaiting deployment.
<james_w> wgrant, lookup based on identity url would be spiffy
<wgrant> Sadly it'll be a few days, because we are frozen for the release.
<mhall119> well we've been dealing with this for months, another few days isn't going to kill us
<Ronnie> mhall119: cant we check if the username has changed each login?
<mhall119> Ronnie: we can, yes, infact I have a code change to that pending with django-openid-auth
<mhall119> but we don't want to wait on them to log in to LD, after changing their username in LP, for us to get their profile information again
<Ronnie> if so, we can do checkups with the username instead of identity, right/
<mhall119> in theory, but again we'd have to wait for them to log in
<lifeless> wgrant: I think there is a bug already requesting openid lookups
<wgrant> lifeless: I tried to find it.
<wgrant> But couldn't.
<mhall119> if we can do lookups based on identity url, we can get updated during our nightly refresh
<wgrant> Oh.
<wgrant> Possibly bug #655565
<_mup_> Bug #655565: Immutable reference to users in API <api> <lp-foundations> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/655565 >
<lifeless> yes
<lifeless> mhall119: so separately I'd like to get away from polling for updates
<lifeless> mhall119: would pubsubhubbub work for you, if we implemented it ?
<mhall119> is it strange that every time I see a number that starts with '655' I automatically think "oh no, integer overflow!"
<lifeless> ah, a 16 bitter
<mhall119> pubsubhubbub?
<wgrant> lifeless: Thinking of future plans, is there any reason not to expose a collection of OpenID identifiers, and a method to get a person by one?
 * mhall119 has actually barely ever written C code
<lifeless> mhall119: http://code.google.com/p/pubsubhubbub/
<lifeless> wgrant: collection - yes, person - no
<lifeless> wgrant: but perhaps I'm being paranoid in objecting to such a collection
<wgrant> Once we support non-SSO authentication we may want to grant people the ability to make identifiers private, but I don't see much reason to not expose all the releated SSO ones now.
<lifeless> wgrant: it just seems a little too like iterating /etc/passwd
<mhall119> lifeless: are they talking real multicast?
<wgrant> lifeless: I mean something like lp.person['wgrant'].openid_identifiers
<lifeless> wgrant: that would be fine with me; might want to check if stuartm has any reservations
<wgrant> We already expose the primary one in the HTML.
<lifeless> wgrant: I thought you meant lp.openid_identifiers
<wgrant> Ah, no, that would be pointless.
<mhall119> yeah, I can already get a person's identifier if I have their username
<lifeless> mhall119: its point to point but with hubs that multiplex
<mhall119> lifeless: I'm sure we could implement whatever needs implementing on our end to achieve that
<lifeless> ok
<lifeless> I suspect we can nuked 20 or 30 % load if we do this.
<lifeless> But someone is going to need to do some hard core log analysis to confirm that
<Ronnie> back to our mugshot. what is exactly the problem?
<lifeless> ok
<lifeless> so the LD page includes a reference to an api attribute which is the mugshot object; this acts like a symlink - it gets resolved and then does a 302
<lifeless> if the object isn't there, you end up with a redirect to the containing object AFAICT - the user page.
<lifeless> there are several problems with just embedding the LP API url
<lifeless> firstly, its slow for users: you make them do 2 new https lookups
<wgrant> lifeless: The bug seems to say that OpenID identifiers are not sufficient to fix it. But I think they are reasonable for this use case, so I'll open a separate bug.
<lifeless> one to LP, which does a webapp request, then issues a 302, then a new https connection to th e librarian, which finally shows the content
<lifeless> if you're on http you don't even actually want https but you have no choice as lp won't answer on http
<lifeless> wgrant: is it right?
<lifeless> wgrant: https://bugs.launchpad.net/launchpad/+bug/655565/comments/3 ?
<_mup_> Bug #655565: Immutable reference to users in API <api> <lp-foundations> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/655565 >
<lifeless> Ronnie: secondly, LP doesn't expose a magic object - one that transparently fills in the default mugshot if none is set
<wgrant> lifeless: In this case I don't think they're really tracking LP users. They're tracking SSO users, getting extra info on them from LP.
<wgrant> The LD case, that is.
<lifeless> Ronnie: and arguably it shouldn't, because that would make it harder for actual API clients (rather than img dereferences) to use; it would be very special case.
<mhall119> lifeless: LD checks if the user's logo_link starts like a URL, and sets a default if it doesn't
<lifeless> Ronnie: LP doesn't want such a magic attribute itself, because it would be heinously slow
<lifeless> mhall119: http://loco.ubuntu.com/events/team/666/detail/ - broken images here
<mhall119> yeah, I'm not sure sure why
<mhall119> http://paste.ubuntu.com/563231/ shows the code we use set the mugshot url
<lifeless> also, you guys know not to use edge, right ?
<mhall119> yes, cjohnston already submitted a fix to that
<lifeless> http://blog.launchpad.net/general/edge-is-deprecated
<lifeless> cool
<mhall119> nigelb pointed it out earlier today
<lifeless> great
<lifeless> just ensuring the message is out there :)
<lifeless> edge has our oldest servers
<lifeless> so moving off it will help you
<mhall119> yeah, we've been migrating off
<mhall119> just a few things we overlooked
<Ronnie> cjohnston: your lp login still uses edge: def lp_login(lp_instance=EDGE_SERVICE_ROOT):
<mhall119> Ronnie: I think it only uses that for local setups
<lifeless> still should be changed
<mhall119> or not
<lifeless> launchpad has dropped the EDGE_SERVICE_ROOT constant
<mhall119> lifeless: we had some issue with using openid from behind a firewall, I think is why we used different servers
<wgrant> Also, you should probably be using the devel API.
<wgrant> Rather than beta.
<lifeless> or 1.0
<wgrant> I like to consider 1.0 a deprecated mistake :)
<lifeless> if the software is packaged, 1.0, if its just a live website you update a lot devel is fine.
<mhall119> what's the url for the devel api?
<wgrant> mhall119: Which version of launchpadlib are you using? Lucid's?
<lifeless> version='devel' in the login call to launchpadliv
<wallyworld_> henninge: ping
<mhall119> wgrant: yeah, lucid
<wgrant> mhall119: lifeless' suggestion will work, then.
<mhall119> that'll work with login_anonymously too?
<lifeless> yes
<wgrant> Use something like Launchpad.login_anonymously('Loco Directory', 'production', version='devel')
<mhall119> got it https://bugs.launchpad.net/loco-directory/+bug/713868
<_mup_> Bug #713868: Use Launchpad devel API  <loco-directory:Confirmed> < https://launchpad.net/bugs/713868 >
<mhall119> thanks
<lifeless> ok
<lifeless> our logo_link and mugshot_links are crack.
<wgrant> Are they?
<mhall119> good crack or bad crack?
<lifeless> bad
<mhall119> is there something better we can be using?
<wgrant> lifeless: Because they always link to the same URL?
<lifeless> we need to fix them
<wgrant> Which then redirects to the librarian?
<lifeless> wgrant: because they link to appserver code
<lifeless> but for a public person (all people atm) we should just emit the librarian reference immediately.
<lifeless> the whole LFA->LFC chain will complicate the performance of this slightly
<lifeless> but we don't have a use case for 'can query the person and not their logo'
<wgrant> Oh, Squeeze has happened.
<lifeless> wgrant: feel like eyeballing  apartial patch adding a new package - lp.testing as a webservice entity - and see if I've massively missed anything?
<wgrant> lifeless: Sure.
<lifeless> http://pastebin.com/CaTTajjy
<wgrant> lifeless: Uh, lp.testing is probably not what you are looking for...
<lifeless> wgrant: well, I thought that might be contentious ;)
<lifeless> wgrant: OTOH, there is a certain logic to i.
<lifeless> it.
<wgrant> There is, but this does not work.
<wgrant> We need to move one or the other.
<wgrant> lifeless: Why are we storing subunit streams in LP, anyway?
<lifeless> wgrant: so we can get them back out again
<wgrant> lifeless: I don't really see why this is in scope for LP.
<lifeless> mhall119: cjohnston: https://bugs.launchpad.net/launchpad/+bug/713873
<_mup_> Bug #713873: Person.logo_link is hard to use and performs poorly <Launchpad itself:Triaged> < https://launchpad.net/bugs/713873 >
<wgrant> Ugh.
<wgrant> Do we have a branching-debian process that we need to run for squeeze->wheezy branches?
<wgrant> I guess the Ubuntu script will work just as well.
<lifeless> well
<lifeless> this is why the 'lets make sid the dev focus'
<wgrant> I'm not sure the script will work too well in that case.
<wgrant> But yes.
<henninge> wallyworld_: Hi! in a rush ...
<henninge> wallyworld_: but thanks for the approval! I'll see to it first thing on Monday.
<wgrant> :( They've created wheezy already.
<lifeless> man, I don't understand why we get 170 updates to lucid :<
<wgrant> I hope the package importer is using 'squeeze', not 'testing', like gina was last time.
<lifeless> it was discussed on the caonical bazaar list, james_w seemed unconcerned about the basic correctness aspects
<wgrant> Is ~canonical-bazaar going to handle the branches side of the new series?
<wgrant> Including running branch-distro.py.
<lifeless> wgrant: so you think using lp.testing as is will be too confusing ?
<wgrant> lifeless: Yes. Using it for something other than internal testing utilities is crack.
<wgrant> Well, more precisely, using it for both is crack.
<lifeless> wgrant: its probably too late for the script; the new branches will be populating right now
<lifeless> they'll all stack
<wgrant> No they won't.
<lifeless> has the development focus changed already?
<wgrant> The new series doesn't exist yet.
<lifeless> then they won't be created
<wgrant> However, the new series will be created and imported package-wise on Monday, unless the branch importer means I can't ask for that.
<lifeless> It would be best to stop it, then create, run the branch script, then start it.
<lifeless> *or*
<lifeless> stop it, create, make sure sid is the development focus, run the branch script, then start it.,
<james_w> I've stopped the importer
<lifeless> (and that way we never have this again)
<wgrant> OK, so. Tomorrow I will convince a LOSA to make lenny supported, squeeze current, sid development, and create a future wheezy.
<lifeless> yes
<wgrant> Then we can fix gina crontabs, run branch-distro, and the package importer can be restarted at our leisure.
<wgrant> it would also be nice to restack the rest of the branches on sid, but that's a bit hard.
<lifeless> the branch script moves the current ones to the new dev
<lifeless> then branches *back*
<wgrant> Right.
<lifeless> oh you mean -2 etc
<lifeless> meh
<wgrant> Ah, and in this case we probably don't have lenny branches.
<lifeless> yes, in principle.
<lifeless> wgrant: were there any other things about the patch;
<wgrant> lifeless: Your security is crack.
<wgrant> It should inherit it from the branch.
<lifeless> wgrant: how does one do that - I knew thats what I wanted, but not the mechanism to do so
<wgrant> lifeless: See things like CodeReviewCommentView
<wgrant> You do the delegation manually.
<wgrant> Or you write a base class which automates it :)
<lifeless> anything else?
<wgrant> lifeless: Your security ZCML doesn't use your security adapter.
<wgrant> You need to require launchpad.View
<wgrant> Not allow.
<lifeless> wgrant: sure, but thats tied to the other bit; thanks for being complete though.
<wgrant> I also wonder how linkStream will function if the UUID doesn't exist.
<wgrant> Apart from that it looks good.
<wallyworld_> henninge: no problem. thanks
<lifeless> wgrant: it will blow up, which is ok
<wgrant> lifeless: It will probably OOPS, which is not OK.
<lifeless> well
<lifeless> indeed, I guess.
<lifeless> however, I'm willing to land and iterate
<wgrant> It's probably another three lines to fix this and avoid a Critical bug.
<lifeless> if its that simple, cool.
<lifeless> I can has patch?
<lifeless> I'll be shelving this until next weekend I suspect
<wgrant> lifeless: Check if TSM.fetch returns None, if so raise some webservice-annotated exception.
<wgrant> If there is no appropriate webservice-annotated exception, three lines create a new one.
<lifeless> whats the one for 404
<wgrant> Is a 404 appropriate here? Possibly, I guess.
<lifeless> if the uuid is absent
<lifeless> the spec is ambivalent :)
<wgrant> There's lp.app.errors.NotFoundError.
<wgrant> I am not entirely sure if that's annotated.
<wgrant> james_w: So can we go ahead and run branch-distro.py on Monday?
<james_w> I don't see why not
<wgrant> It worked fine for Natty, so it seems safe enough.
<wgrant> D:
<lifeless> wgrant: hey, you were looking at bug 32464
<_mup_> Bug #32464: guess_bugtask() fails on distribution tasks without a source package <lp-bugs> <oops> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/32464 >
<lifeless> wgrant: I thought you found the bug still existed?
<lifeless> hmm
<lifeless> we really need a profile for where the python time in oopses like OOPS-1862C1669
<lifeless> 33.	8790	35ms	SQL-launchpad-main-slave	
<lifeless> SELECT ValidPersonCache.id
<lifeless> FROM ValidPersonCache
<lifeless> FROM ValidPersonCache
<lifeless> WHERE ValidPersonCache.id = %sLIMIT 1
<lifeless> 3 seconds between those trivial queries
<lifeless> flacoste: OOPS-1862C1669 - these are the things making me think we're running into GIL overload quite a bit atm. I think we're going to need to escalate single threaded to the top rather than waiting for RFWTAD
<lifeless> flacoste: same situation we had with the xmlrpc; same symtoms, and it was totally fixed when we gave it more resources.
<wgrant> lifeless: It doesn't fail. It just does insane things, but the whole method is insane, so that's OK.
<lifeless> ok
<lifeless> cool, thanks.
<wgrant> Yes, I was a bit surprised when he closed it too.
<lifeless> wgrant: do you know where jon is at with bug 421901 ?
<_mup_> Bug #421901: Person:+bugs timeouts <lp-bugs> <timeout> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/421901 >
<wgrant> lifeless: Still actively working on it.
<wgrant> Was going to talk to deryck about a couple of things, IIRC.
<lifeless> 15 second query
<lifeless> wgrant: ok, I'm going to do some analysis, on the basis that he seems stalled, and that sucks,
<wgrant> Uhoh, they are going to enable testing migrations again tomorrow.
<wgrant> A few days earlier than I expected :(
<lifeless> ?
<wgrant> wheezy isn't going to be static for long.
<lifeless> ahha
<lifeless> its 'commented on'
<lifeless> that is terribad
<wgrant> Of course.
<lifeless> well
<lifeless> its poorly constructed
<lifeless> no particular reason it should be bad
<lifeless> -wow- minutes of runtime on qas
<lifeless> hahahaha
<lifeless> 8.4 fallout
<lifeless> the inner correlated join is the problem I think
<lifeless> 178 seconds cold
<wgrant> Ouch.
<lifeless> 20 hot
<lifeless> heh
<lifeless> apport has commented on more bugs than anyone else
<lifeless> seb128 a close second
<wgrant> Heh.
<lifeless> ok, wrapped in a bow and ready to cod
<lifeless> e
<lifeless> wgrant: is there anything you were needing extra inspiration on?
<StevenK> lifeless: Re your bugs about mugshot and logo -- there is precendent for that -- build records have a build_log_url property that is None if there none or a librarian URL if there is one
<lifeless> cool
<wgrant> Why is OpenIDRPSummary still in the LP tree? :/
<wgrant> Ah, it's still used to warn about account renames.
<wgrant> But it seems to no longer be used.
<wgrant> mawson's latest record is from April.
<wgrant> Perhaps we should make profile delegation optional, and warn on rename if it's delegated at all.
<wgrant> I wonder what SF.net does.
<wgrant> They have relatively unawful OpenID support.
<wgrant> Ah, indeed. Delegation is optional, and you can select the identifier that you wish to delegate to.
 * maxb is surprised to be able to wget https://api.launchpad.net/1.0/branches?ws.op=getByUrl&url=lp:bzr without any oauth fiddling
<maxb> When did that happen?
<lifeless> morning
<lifeless> maxb: 6 july last year
<lifeless> allenap: around per chance ?
<lifeless> ah
<lifeless> actually brad
<lifeless> bac: ping
<wallyworld_> thumper: morning. did we need a call this morning?
<thumper> wallyworld_: hi
<thumper> wallyworld_: I'm trying to leave the office to get coffee and a warrent for the car
<thumper> but got suck clearing through emails
<wallyworld_> thumper: np. ping me later if required
<wallyworld_> i've had my coffee :-)
<thumper> phew
<thumper> just done with the email
<thumper> wallyworld_:  how's your recipe work going?
<wallyworld_> thumper: ok. didn't get much else done with those forms. been doing rm stuff - just landing r-c db-devel branch for julian now. gotta get that done asap
<thumper> ok
<thumper> gah
<thumper> found out that it was "self..." that was screwing up my js tests, should be "this.foo"
<lifeless> heh
<lifeless> https://code.launchpad.net/~lifeless/launchpad/bug-661988/+merge/48740
<huwshimi> Has anyone hit this problem when using rocketfuel-branch today? Error: Couldn't find a distribution for 'windmill==1.5pre-deryck'
<lifeless> update your download cache
<huwshimi> lifeless: How do I do that. There were instructions on the wiki, but they got removed :(
<lifeless> they did?
<lifeless> I cd to the download cache and run bzr update
<huwshimi> well they were on the canonical wiki
<StevenK>   Set up canonical.testing.layers.DatabaseLayer in 10.542 seconds.
<StevenK>   Set up canonical.testing.layers.LibrarianLayer in 16.152 seconds.
 * StevenK peers at his machine
<wallyworld_> StevenK: hot last night? meant to be the hottest on record
<StevenK> wallyworld_: Last night? No, last night was fine, it was the night before that
<wallyworld_> ah ok.
<StevenK> 41degC during the day, and it only dropped to 36 inside or so when Sarah and I went to bed.
 * wgrant wonders how to QA r12321.
<huwshimi>  lifeless: Thanks that's fixed it. Just so I can understand, what does that download-cache do?
<lifeless> its where we have buildout configured to 'download' from
<lifeless> rather than grabing untrusted stuff off of the net
<wallyworld_> wgrant: not sure but thanks for looking. btw i'm doing r12315 as soon as i get a feature flag enabled
<wgrant> wallyworld_: I just did that. It's not behind FF, though -- it's just plain disabled.
<wgrant> So there is no change, as long as existing subscriptions work.
<huwshimi> lifeless: Right. Thanks.
<wgrant> Which they do.
<wallyworld_> wgrant: i the advanced fields alluded to in the bug report and qa notes are hidden behind a feature flag i thought?
<wallyworld_> or maybe i missed something
<wgrant> use_advanced_subscriptions is hardcoded to false for now.
<wgrant> It *should* be behind FF. But it isn't.
<wallyworld_> so how did you test then if advanced_sub is false?
<wgrant> I tested that the JS around it still works. It's impossible to QA the stuff inside the change, but I know it didn't break anything that is not disabled.
<wgrant> And that is what matters.
<wallyworld_> sure, but the bug also talks about updating the bug notification level field
<wallyworld_> and that can be tested if the advanced subscriptions were enabled
<wallyworld_> s/bug/mp
<wgrant> Ahem, a couple of Unity crashes later...
<StevenK> ne
 * StevenK glares at Do
<wgrant> I didn't realise you were looking at that bit, sorry. https://bugs.dogfood.launchpad.net/ubuntu/+bug/1234/+subscribe is where I QA'd that, since I can add FFs there.
<_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 >
<wgrant> wallyworld_: ^^
 * wallyworld_ looks
<wgrant> Um, it seems to not have come back up properly after I pulled the debversion stuff.
<wgrant> Hrmm.
<wallyworld_> wgrant: that page on dogfood errors for me.
<thumper> :-(
<thumper> car needs two new tires
<thumper> I'm home to collect charger and usb cable so I can continue to work from town while care is getting fixed
<thumper> at least #launchpad is quiet on Mondays
<wallyworld_> thumper: i think you meant to say "tyres" :-P
<thumper> wallyworld_:  what ever....
<thumper> stupid english language
<wallyworld_> no, the english language is fine. it's "american english" that is broken :-)
 * thumper afk again
<wgrant> wallyworld_: It's back now, but that restart destroyed the cache, so Launchpad bug heat updates time out like on qas... however it still works fine on smaller projects like https://bugs.dogfood.launchpad.net/ivle/+bug/647286/+subscribe
<_mup_> Bug #647286: Ability to import/export exercises and worksheets <exercises> <worksheets> <IVLE:Triaged> < https://launchpad.net/bugs/647286 >
<wallyworld_> wgrant: thanks
<wallyworld_> wgrant: the rev on dogfood is too old to qa 12315
<wgrant> launchpad@mawson:/srv/launchpad.net/codelines/current$ bzr revno
<wgrant> 10180
<wgrant> Not sure what updates the footer.
<wgrant> But it clearly hasn't happened in a while :/
<wallyworld_> yup :-)
 * wgrant goes Makefile diving.
<poolie> hi all
<wgrant> wallyworld_: The footer no longer lies.
<wallyworld_> cool
<wgrant> But we have a LOSA now anyway.
<StevenK> wgrant: Did you fix it to actually update when the branch does?
<wgrant> StevenK: No. make clean does, that but it seems to be all :/
<poolie> guys, should i have another go at removing the oauth.py duplication, or just leave it?
<lifeless> poolie: I thought it was fixed
<lifeless> I saw a new python-openid in the download cache
<wgrant> lifeless: != oauth
<poolie> i think that's different
<poolie> the last mail i have is just talking about reverting the attempted removal
<lifeless> I'd roll a fixed egg
<lifeless> better than having this thing hiding in contrib that noone knows to look for
<poolie> you'd prefer an updated egg to using the ubuntu package?
<wgrant> Yup.
<poolie> launchpadlib currently uses the ubuntu package
<poolie> wgrant: yup to what?
<wgrant> poolie: To lifeless "I'd roll a fixed egg"
<wgrant> poolie: We don't use the launchpadlib package.
<wgrant> We use an egg.
<poolie> for the sake of my education, why is this better than using the distro package?
<wgrant> Because someone said so.
<poolie> because it's easier to make our own changes later?
<wgrant> I disagree.
<lifeless> uhm
<lifeless> my understanding is that the distro package in lucid is too old.
<wgrant> It makes it easier to do upgrades.
<lifeless> is that wrong ?
<wgrant> lifeless: We have PPAs for that.
<poolie> wgrant, no, i know the server doesn't use launchpadlib, but istm there is some benefit from having both the client and the server use the same thing
<poolie> lifeless, no, it's been fixed in ubuntu since... karmic, at least
<wgrant> You would think.
<poolie> i think also since hardy
<lifeless> so, if its fixed in lucid packages, we can use that
<poolie> 'rmadison python-oauth' shows it's actually unchanged since karmic
<lifeless> the more complex the package, the less likely we can use it in production deployments
<lifeless> because of the 'only one can be installed' nature of python packaging; I've posted to debian-python a few times, and been talking to allison, barry etc about this
<poolie> right
<poolie> in this case it is just two py files, and also slowly moving (maybe dead) upstream
<lifeless> the big thing here is that the api isn't changing
<poolie> right, it's highly unlikely to get anything more than just bug fixes
<wgrant> wallyworld_: FWIW the translations change seems to be good. But it's hard to be sure, since I don't really know translations.
<poolie> so, the right way to proceed is:
<poolie> update launchpad-dependencies to pull it in
<poolie> somehow get that rolled out
<poolie> delete the egg
<poolie> and ditto get that updated by everyone
<lifeless> which is why we can switch to using the package; add it to launchpad-*-dependencies, build that, remove from download cache, let the losas know the package is needed (they generally port the dependencies package to address this)
<wgrant> Why do the translations DB tables hardcode 'ubuntu' in some column names? :/
<poolie> then resubmit the deletion of the copy in contrib?
<lifeless> poolie: was it rolled back ?
<wallyworld_> wgrant: i don't know translations either.
<poolie> yes, it caused a buildbot failure friday night my time
<lifeless> poolie: anyhow yes; but after the release.
<poolie> sorry
<lifeless> this coming friday.
<poolie> sure
<lifeless> wallyworld_: wgrant: a pragmatic denormalisation
<poolie> is there documentation somewhere of how to update the dependencies package etc?
<lifeless> wallyworld_: wgrant: possibly unneeded, possibly needed.
<lifeless> poolie: pretty sure its on the dev wiki
<wgrant> lifeless: But definitely bad :)
<poolie> ok, i'll shelve it until next week and maybe try then
<lifeless> wgrant: I live in a world with greys
<wgrant> wallyworld_: Note that staging will take a while to update with the debversion change.
<wgrant> wallyworld_: The patch itself could take half an hour to run.
<lifeless> poolie: sure; sorry you're having such trouble landing it successfully.
 * thumper is connected again
<thumper> more coffee on its way
<poolie> it's ok
<poolie> it's been interesting
<poolie> i'm more just sorry to have caused a buildbot failure for something with no immediate concrete benefit
<wgrant> buildbot failures happen.
<poolie> however, i guess if you tolerate duplication because it's hard to remove, things get worse and worse
<poolie> it's possible there are other fixes in the newer package too
<lifeless> poolie: this is because we have too many ways to do dependencies.
<poolie> right
<poolie> righ
<lifeless> I'd like to have one - the python upstream way (there isn't one), and have the packaging system back us up (but it can't yet)
<poolie> :)
<wallyworld_> wgrant: yeah, i know that patch will take some time to apply. just trying to communicate that rev 10178 doesn't have to be qa'ed right this second, but sometime soonish would be good :-)
<poolie> when you say the rollout's this coming friday
<poolie> i thought it was thursday a/nz time
<lifeless> poolie: it is, I'm saying try landing on friday
<poolie> oh i see, ok
#launchpad-dev 2012-01-30
<lifeless> it would be nice, yes
 * wgrant sobs
<wgrant> (@ the bug-columns-related new sort orders)
 * StevenK tries to work out what to get run on qas to generate mail to qa bug 114753
<_mup_> Bug #114753: Team membership status change emails should be gender neutral <lp-registry> <qa-needstesting> <teams> <trivial> <Launchpad itself:Fix Committed by stevenk> < https://launchpad.net/bugs/114753 >
<StevenK> Or where the staging mailbox password even is. I thought I had it locally. :-(
<wgrant> Probably cronscripts/send-person-notifications.py
<lifeless> wgrant: StevenK: would like your opinions on bug 897442
<_mup_> Bug #897442: maintained packages page not up to date after several weeks <Launchpad itself:Triaged> < https://launchpad.net/bugs/897442 >
<wgrant> lifeless: Aw, you're ruining all the fun.
<lifeless> wgrant: howso?
<wgrant> Asking me directly about derived distros omissions that I pointed out a year ago, so I can't just sadly and derisively laugh at it from the sidelines.
<StevenK> I *think* that was due to the gina fallout
<nigelb> Morning!
<nigelb> I can't wait to ask bigjools about cricket.
<lifeless> StevenK: so, fixed already?
<lifeless> StevenK: or 'operational glitch not a bug' ?
<wgrant> Not fixed.
<wgrant> The solution is undefined, and probably unclear.
<lifeless> ok
<wgrant> And to some extent probably impossible.
<lifeless> can one of you define the problem clearly in the description then ?
<wgrant> It's very similar to the notification issue, which was only vaguely solved recently.
<lifeless> the symptoms are fairly clear, but too high level :)
<StevenK> nigelb: Oh, why?
<lifeless> 370 tech debt bugs
<lifeless> wgrant: StevenK: ^ [please to be updating the bug]
<nigelb> StevenK: England bowled out in the second innings for 72.
<StevenK> nigelb: Bwahaha
<StevenK> #1 in the world my left foot
<nigelb> Exactly.
<lifeless> wheee httpbis goes insnae
<wgrant> lifeless: Oh? I've not been following it much.
<wgrant> What have they done now?
<lifeless> its about to be recharted
<lifeless> rechartered
<lifeless> httpbis is done, now onto a new version of http
<lifeless> you can imagine the long carried concepts that this is dragging out of the woodwork
<lifeless> some good
<lifeless> some, uhm, less
<wgrant> Oh yes.
<lifeless> ok, htf does bug 235168 remain open ??
<_mup_> Bug #235168: Database user fiera needs access to table GPGKeys <lp-soyuz> <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/235168 >
<lifeless> StevenK: wgrant: you may know. We should be seeing massive failure unless its been worked around somehow.
<wgrant> lifeless: It *does* have access to gpgkey.
<wgrant> Perhaps the bug is that it shouldn't need it.
<wgrant> But it clearly should.
<lifeless> ok
<lifeless> s s/needs/has/ then close invalid
<wgrant> Let me just check when it was added.
<wgrant> It was added the day after that bug was filed.
<wgrant> By al-maisan
<wgrant> So I think it can be closed, as it's not a bug.
<lifeless> yay timeouts
<lifeless> wgrant: so it has access to the gpgkeys table to find folk from keys?
<wgrant> lifeless: Right.
<lifeless> thanks
<wgrant> lifeless: Any idea why we can now sort bugs by tag or spec name?
<wgrant> They both seem only marginally useful, if that.
<lifeless> the bugcolumn project decided that every shown field should be sortable
<wgrant> O_o
<wgrant> o_O
<lifeless> so they can show the fields being shown as 'columns'
<wgrant> -_-
<lifeless> and they can be clicked on to sort.
<wgrant> This didn't raise performance concerns?
<wgrant> It's both somewhat useless, and likely to be very slow.
<lifeless> I flagged that with the team, yes.
<lifeless> I don't know if they have measured.
<lifeless> The original idea was to allow arbitrary combinations of sorts.
<lifeless> importance + age, etc.
<wgrant> Sure.
<wgrant> That sort of thing is useful.
<lifeless> Yes, but complex and hard to get right performance wise.
<wgrant> But it's made a little more challening by having 9 billion combinations.
<wgrant> 8.7 billion of which aren't useful
<lifeless> sure
<lifeless> anyhow, so a) the squad were, AFAIK, aware that performance is a factor
<wgrant> I have a feeling that even ordering by assignee will no longer work for Ubuntu.
<lifeless> and b) I don't know if they profiled the resulting queries.
<wgrant> Indeed it does not.
<lifeless> timeout?
<wgrant> of course :)
<lifeless> file a bug
<lifeless> this probably needs revisiting
<wgrant> I am trying to work out how to safely do the fact table.
<wgrant> But there's about 10 useless sort orders that I really don't want to have to test against it.
<wgrant> lifeless: Hah
<wgrant> lifeless: Did you know that there are still several per-bug query regressions left in the new bug listings?
<lifeless> I didn't
<lifeless> please file a bug and flag for deryck
<wgrant> I did a month ago :/
<lifeless> That got fixed, I thought.
<wgrant> So did I.
<wgrant> Ah, no.
<wgrant> Bug #901122
<_mup_> Bug #901122: New bug listings need to preload more attributes <bug-columns> <regression> <timeout> <Launchpad itself:In Progress by deryck> < https://launchpad.net/bugs/901122 >
<wgrant> It's the other one, with duplicated 4s queries, that got fixed.
<wgrant> Nearly 2 months ago.
<lifeless> ok
<lifeless> I have a clal planned with deryck this week anyhow
<lifeless> I will mention that bug
<wgrant> Does the 5s policy not apply in weaker form to that sort of thing?
<wgrant> Something like "can't release with known trivial performance regressions"?
<StevenK> Hah
<lifeless> yes,
<rick_h> lifeless: wgrant I know he reported on it a couple of times during stand ups
<lifeless> we're not meant to release with known regressions
<rick_h> it's on our kanban and in coding
<lifeless> and all new pages are meant to be 5s capped.
<lifeless> we haven't yet agreed to 'changed pages need to be 5s capped' - I don't think we are quite ready for that.
<wgrant> lifeless: Sure, but "changed pages shouldn't have obvious easily-fixed speed regressions" seems reasonable enough.
<lifeless> wgrant: I think francis would support 'changed pages should not have regressions'
<lifeless> we don't have a formal checkpoint for this today
<lifeless> (and in fact if you check the current release process stuff, squads are not meant to rotate while there are regressions
<lifeless> but we're not following through all that well yet; still figuring out the mechanics
<wgrant> I've given up on pointing that bit out :)
<lifeless> please don't give up
<lifeless> sometimes just a reminder is very useful
<wgrant> We conciously regressed with speed, usability, information density regressions.
<wgrant> Presumably because the feature was dragging on.
<wgrant> s/regressed/released/
<lifeless> I was only aware that the latter one was considered
<wgrant> Fortunately for products it's somewhat usable.
<wgrant> As you can turn off location display.
<wgrant> And get near-normal density.
<wgrant> For Ubuntu you can't :/
<lifeless> hates isp.
<lifeless> StevenK: \o/ 114753
<StevenK> lifeless: I think you should your ISP exactly what you think of them.
<StevenK> At length.
<StevenK> Sigh. Should *tell* your ISP
<lifeless> StevenK: I've started whinging on twitter to them when it goes :P
<StevenK> Oh sure, *that* will help.
<lifeless> makes me feel better
<lifeless> and back to the bug triage. wgrant - could you please comment on / update the description for bug 897442 ?
<_mup_> Bug #897442: maintained packages page not up to date after several weeks <Launchpad itself:Triaged> < https://launchpad.net/bugs/897442 >
<lifeless> hah, crazy, my if-I-had-to-choose tweet is *still* being retweeted
<lifeless> to another 3K folk today. *boing*
<wgrant> lifeless: Which tweet?
<lifeless> https://twitter.com/#!/rbtcollins/status/160126945995141122
<nigelb> ohyeah, I RT'd that the other day.
<lifeless> .
<lifeless> .
<lifeless> .
<james_w> hi lifeless
<wgrant> Ah
<lifeless> james_w: hi
<james_w> hi wgrant
<james_w> I've been looking at getting Django to include the oops id in the response body
<james_w> I have an approach that does it, but it has to use thread local storage
<wgrant> Hi james_w.
<lifeless> james_w: can't you use the wsgi context?
<james_w> hmm, possibly
<james_w> and then get it back out from the report in the error_render function
<lifeless> james_w: I was suggesting, at the point you decide you are oopsing (which is probably the django error handler, which is inside the wsgi shell)
<james_w> at that point we can either publish the oops directly, dropping some of oops_wsgi from the stack
<lifeless> that you use a timeuuid, (uuid1?) back that to a unicode string, stash it in the wsgi context in a oops.id or oops.context['id'] or some such
<lifeless> and change the oops-wsgi default handlers to honour if from there, if found.
<james_w> that would work, but would break publish_only_new
<james_w> I wonder if that should use some mechanism other than the id to decide if the report has already been published?
<lifeless> uhm
<lifeless> I wouldn't publish directly, theres no value in doing so
<lifeless> and you'd have to duplicate logic
<james_w> yeah
<lifeless> (consider that we also want to make oopses for soft timeouts, local 404's etc)
<lifeless> the fact that django isn't structured like a wsgi app is a nuisance :)
<james_w> yes
<james_w> would a published key in the report work sufficiently well for publish_only_new to do the amqp->datedir fallback?
<lifeless> we'd need to teach it
<lifeless> e.g. have a requested_id field or some such
<lifeless> allocation in publish() is very clean, but then we get this nasty django interaction
<wgrant> lifeless: I've commented on that bug, but it has probably only confused matters :)
<lifeless> one way would be to track 'published' separately
<lifeless> (e.g. in a key, or as a separate publishing-state-variable)
<wgrant> (most interpretations of the bug would have previously been very confused, but in too simple a fashion)
<lifeless> another is to have a helper in the oops code that publishers can use to decide what id to use (see also the related 'preserve id' flag to DateDirRepo
<lifeless> wgrant: thanks
<lifeless> wgrant: whats the jargon for the 'functionality to which lifeless refers'
<spm> 'impossibilities and other fantastic legends'
<nigelb> zing!
<StevenK> Haha
<wgrant> lifeless: Not sure it has a name.
<StevenK> +1 for calling it what spm did
<spm> :-)
<nigelb> All hail spm, the well-timed.
<spm> years of practice
<spm> :modest:
<StevenK> lifeless: O hai. Can I please kill the maverick packages in the LP PPA?
<StevenK> By rights we should kill natty too, but one DAS at a time
<wgrant> There are still natty users
<wgrant> I don't think anyone's still on maverick, though.
<wgrant> In fact I think maverick's broken.
<lifeless> StevenK: L, O and P should be all we need
<lifeless> wgrant: what natty users?
<wgrant> At least one LP dev uses natty.
<lifeless> wgrant: !cite
<StevenK> lifeless: There is an already existing Obsolete PPA which contains a bunch of hardy stuff, I'll copy the maverick packages there and then delete them
<lifeless> coolio
<lifeless> given the canonical policy for O/S use
<lifeless> I wouldn't bother asking me about this, JFDI :) - after checking on buildbot and any non-prod machines, of course [as prod machines use the losa repo...)
<spm> s/losa/is/
<lifeless> 6/1 1/2 other
<StevenK> lifeless: buildbot does not use the PPA
<StevenK> ec2 and dev machines only
 * StevenK gets distracted by changing the displayname of the obsolete PPA to something better
<lifeless> StevenK: blargh, I knew whereof I meant.
<lifeless> wgrant: what dev uses natty?
<wgrant> lifeless: I don't recall, but I'm pretty sure it came up at the Thunderdome.
<StevenK> I can recall hearing it too
<StevenK> I think it was one of the mac fanbois
<wgrant> That makes sense, yes.
 * StevenK waits for the copied packages to be published before deleting them
<lifeless> so, tough luck for them, really.
<lifeless> we should all be dogfooding precise in the next month or so anyhow.
<lifeless> and everyone should have gotten onto O in similar fashion.
<StevenK> lifeless: I'll be mailing about Maverick after the fact, the mail warns about Natty.
<lifeless> thanks
<lifeless> lets aim to clean natty and O up a week or so after P ships.
<lifeless> clean sweep
<StevenK> That late? I was going to clean up natty this week
<lifeless> oh, sure
<lifeless> I was figuring you wouldn't want to fiddle with it again so soon
<lifeless> but if you're inclined, I won't get in the way :)
<StevenK> Meh, most of it is waiting for the PPA publisher
<wgrant> StevenK: Why?
<wgrant> You don't need to wait.
<StevenK> wgrant: I'd prefer them to be published in the other PPA before I delete them from the first.
<wgrant> Unnecessary, unless you're going to take more than 7 days to copy them.
<StevenK> They just published, anyway.
<StevenK> "Source and binaries deleted by Steve Kowalik request:"
 * StevenK eyerolls
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/ppa-packages-deletion-grammar/+merge/90646https://code.launchpad.net/~stevenk/launchpad/ppa-packages-deletion-grammar/+merge/90646
 * StevenK glares at his mouse
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/ppa-packages-deletion-grammar/+merge/90646 that is
<wgrant> StevenK: Needs fixing, but you have to work out why :)
<wgrant> It's not a bug you've introduced.
 * StevenK peers at wgrant
<StevenK> Can I have a clue? :-)
<StevenK> messages = []; messages.append() is a horrid way of expressing it, so I've fixed that too
<wgrant> It's not in the test, or the comment.
<wgrant> I thought that was a reasonable way to do it, but I'm not too fussed.
<lifeless> gnar
<lifeless> I can't find the bug about bug 1
<_mup_> Bug #1: Microsoft has a majority market share <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Invalid by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-m
<StevenK> wgrant: Your issue is with the prose, then?
<wgrant> No, it's a code bug.
<lifeless> escaping?
<wgrant> Bingo.
<lifeless> cause we like xss ?
<StevenK> Ah
<StevenK> +        messages = [
<StevenK> +            '<p>Source and binaries deleted by %(self.user.display_name)s:']
<StevenK> wgrant: ^
<lifeless> StevenK: ?
<wgrant> wut
<lifeless> StevenK: nice troll :P
<lifeless> StevenK: display_name is untrusted data
<lifeless> StevenK: you are assembling html.
<StevenK> Obviously
<lifeless> StevenK: so you need to html entity escape the display name to stop monkey business
<wgrant> No.
<StevenK> But that pattern is used like five lines down
<StevenK>         messages.append("<p>Deletion comment: %(comment)s</p>")
<lifeless> StevenK: oh yay, even more holes
<StevenK> So I guess I get to fix both ...
<lifeless> StevenK: actually, let me rephrase - that second one depends on the value of comment when the string is substituted
<wgrant> dafuq.
<wgrant>         # Replace the 'comment' content added by the user via structured(),
<StevenK> comment = data.get('deletion_comment')
<wgrant>         # so it will be quoted appropriately.
<wgrant> I DO NOT GET IT
<wgrant>         messages.append("<p>Deletion comment: %(comment)s</p>")
 * wgrant blame
<StevenK> wgrant: Shall I just go on a rampage and delete this code for being utter rubbish?
<wgrant> No, you should fix it, while I write bzr blamestab.
<StevenK> cprov
<StevenK> wgrant: Hm, it is wrapped in structured() a few lines down?
<wgrant> Oh
<wgrant> So it is
<wgrant> So yes, that bit is correct.
<wgrant> (but that was only fixed relatively recently)
<wgrant> In r5945
<StevenK> Hah, recently
<StevenK> wgrant: http://pastebin.ubuntu.com/822187/
<wgrant> Amusingly there were two identical vulnerabilities in the preceding 10 lines, which were not fixed.
<wgrant> StevenK: That's fixed one of them.
<StevenK> And the source displayname?
<wgrant> That one is probably not presently exploitable, due to some constraints in our current data model, but yes.
<StevenK> Right
<StevenK> I'm not sure how to fix that in the same way, given the loop
 * StevenK wraps source.displyname in structured()
<wgrant> Right, it may be best to use the nested structured() support that you added a while back.
<StevenK> Like I just did? :-)
<StevenK> Hmmm, wrapping source.displayname in structured didn't work
<wgrant> How did you try it?
<StevenK> % structured(source.displayname) effectively
<wgrant> That's precisely the opposite of what you want.
<StevenK> Which is utterly wrong, since I've just managed to swap in how to actually use it. :-)
<wgrant> structured()'s first operand is markup.
<StevenK> notification = "\n".join(messages)
<StevenK>     TypeError: sequence item 1: expected string, structured found
<StevenK> Oh, BAH
<StevenK> This is utterly pointlessness to do it with an array. May as well build a string
<wgrant> You know what would be good here? :)
<wgrant> A... TEMPLATE! [jarring chord]
<StevenK> Haha
<StevenK> Oh, damn it, can't use += for strings and structured
<wgrant> No, you'd have to use .escapedtext, which would be nice to avoid.
<StevenK> Hopefully += works if everything is structured
<StevenK> ... which it does not.
<wgrant> No.
<wgrant> This is where MarkupSafe is nice.
<wgrant> But IE.
<wgrant> IE destroys everything :)
<StevenK> Sigh, this would be easy if it wasn't for the loop of sources in the middle.
<wgrant> Sure. This is the sort of thing templates were invented for.
<StevenK> Grrr
<StevenK> I can't see a nice way to do this. I wonder how to pull in pystache
<wgrant> Use escapedtext
<wgrant> Or I guess you could use pystache, but eeeeh.
<wgrant> mustache is slow and awful.
<StevenK> Oh, bah, structured is replacing the < and > too
<wgrant> Hmmm?
<wgrant> That's the point of it.
<StevenK> But I'm building HTML :-(
<wgrant> How are you trying to use structured()? Because it's wrong :)
<StevenK> wgrant: http://pastebin.ubuntu.com/822199/
<wgrant> StevenK: So, you need to wrap the final thing in structured(), or addNotification will escape it.
<StevenK> wgrant: That works. Other than that, I guess I'm using structed() correctly? :-)
<StevenK> Sigh, structured()
<wgrant> StevenK: Not correctly, but not wrongly.
<wgrant> There's no correct way here.
<StevenK> I think I can cope with "It's not perfect, but much better than what was there."
<StevenK> wgrant: Diff updated.
<wgrant> StevenK: Approved, with one change.
<StevenK> wgrant: Like http://pastebin.ubuntu.com/822212/ ?
<wgrant> StevenK: Right.
<wgrant> Possibly with a comment "If you change the next statement, wgrant will send rabid dogs after you."
<StevenK> Haha
<StevenK> Hm, have we been wallyworld-less today?
<wallyworld> no?
<StevenK> You've just said nothing all day
<wallyworld> been busy
 * StevenK is getting quite tempted to upgrade the ec2 image
<wallyworld> do, you know you want to
<StevenK> jtv: You can delete your ec2 ami-2b5e9e42
<StevenK> bac: You can delete your ec2 ami-9165a5f8 of id 521.
<wgrant> lifeless: Do you know if anybody in maintenance is sorting out the remaining longpoll issue, or should I JFDI given that Red is no longer with us?
 * StevenK purges Java off his system now that he doesn't need ec2-api-tools
<wallyworld> poor Java :-(
 * stub adds Zookeeper to -dependencies for a laugh
<wgrant> I hope we'll need it eventually :)
<stub> Ooh... counter troll.
 * StevenK stabs Thunderbird, pulls the knife out, and stabs it again, twisting the knife.
<StevenK> Why does every single mail client have to completly suck?
<StevenK> Perhaps it's mandated in RFC 3501.
<wgrant> StevenK: A combination of 3501 and 5322, yes.
<adeuring> good mornig
* adeuring changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2
<lifeless> wgrant: they are not
<lifeless> wgrant: if you want to DI, that would rock
<wgrant> lifeless: Will need some CORS stuff in Apache, I suspect, but will look at some point.
<danhg> Morning everyone
<nigelb> Morning danhg, mrevell
<nigelb> bigjools: Watched the cricket? I heard England had fun :D
<stub> StevenK: Are we going to conflict with ec2 images or are you finished now? I'm just about to attempt to build a PG 9.1 image.
<stub> (but that won't be public until testing is done, couple of days)
<lifeless> stub: hey
<wgrant> stub: That sounds dangerous, given that 9.1 on prod is probably some time away...
<stub> lifeless: yo
<lifeless> stub: so, I missed our catchup last week
<stub> wgrant: Says who?
<stub> lifeless: That is fine. I wasn't there either :)
<lifeless> stub: I'd like to catch up tomorrow; reckon you could be around a bit earlier?
<stub> lifeless: sure
<wgrant> stub: Says me not trusting pg_upgrade, and an insufficient CPU count to do it any other way :)
<wgrant> But if pg_upgrade works now, that's great.
<lifeless> stub: also, there are about 4 bugs that all boil down to 'make a new user', wondering if you want to knock them over sometime soonish; seems like one straightforward patch should do it
<lifeless> stub: I've tagged them 'dbuser'
<stub> wgrant: I need to push it forward or it will never happen. There are problems, and we will go ahead when I have solutions :)
<lifeless> stub: (tomorrow - thanks)
<lifeless> and now, for me, gnight
<stub> lifeless: k
<StevenK> stub: I'm done, 524 was just an update since I got sick of waiting for ec2 to upgrade 80MiB worth of packages.
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugtasks: 4*10^2
<deryck> Morning, all.
<sinzui> jcsackett, do you have time to mumble?
<nigelb> Interesting quit message there :)
<jcsackett> sinzui: i can mumble now, sorry i missed your ping.
 * sinzui starts mumble
 * jcsackett does too
<lifeless> mornink
<lifeless> deryck: hey
<deryck> lifeless, hey man.  been meaning to reply to you all day.  sorry
<deryck> lifeless, how about sometime after the TL call this week?
<lifeless> mm, pretty sure that that morning is wall to wall calls
 * lifeless consults calendar
<lifeless> I think statik cancelled, so I could do tlstart + 2h as the start time
<deryck> lifeless, 2100 UTC?
<lifeless> I think so
<flacoste> lifeless: hang out time?
<lifeless> flacoste: sure, can you send a regular invite? that one is on the wrong machine :P
<flacoste> lifeless: i did
<lifeless> oh, google notifications fail
<lifeless> 'this service is unavailable please try again later'
<flacoste> i resent the invite
<deryck> lifeless, I'll calendar you and move it if it's wrong.
<lifeless> deryck: thanks, looks fine to me
<deryck> lifeless, awesome
<lifeless> danhg: hiya
<lifeless> danhg: thanks!
<wallyworld> deryck: hi, wanna have a quick chat?
<wallyworld> deryck: sorry, network dropped out, not sure if you replied
<deryck> wallyworld, hey.  sure.  I'm near EOD, and I'm nearly spent.  But I'll take a shot at it.  mumble or hangout?
<wallyworld> deryck: mumble, just a quick one
<deryck> ok
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2
<reed> hi folks
<reed> is there a way for a manager to extract the list of email address of people in a LP team?
<reed> need to run the openstack elections based on the members of openstack, I'd like to see if I can save some energy
<sinzui> StevenK, This is a few days before NG agreed to hire me and 6 months are we took all the data out of illustra (proto-postgresql) and ran on python 1.2 http://web.archive.org/web/19961111220245/http://www.nationalgeographic.com/main.html
<sinzui> it's so tiny
<StevenK> wallyworld: https://code.launchpad.net/~stevenk/launchpad/combo-url/+merge/90093
<sinzui> Ian. After the underpants protest, they stopped tampering with the pictures: http://web.archive.org/web/19961221170010/http://www.nationalgeographic.com/modules/contact2/dispatch/Nicolas/clickup/rd50up.html
<wallyworld> sinzui: lol :-)
<sinzui> Though think this through...if they have never been in contact with modern civ...why are they posing.
<StevenK> Haha
<wallyworld> you raise an excellent point, hmmm
<wallyworld> wgrant: StevenK: yay, my 128GB SSD just arrived. now to clone my current hdd so i can run without my disk thrashing so much
<StevenK> wallyworld: My desktop doesn't thrash at all, and my laptop has an SSD already. So I'm not sure why your laptop is so terrible
<StevenK> Hah
<StevenK> I see that lifeless' ISP is running in 'operational excellence' too
<lifeless> yeah
<lifeless> (not really)
#launchpad-dev 2012-01-31
<StevenK> lifeless: So is 'irony' just a metal to you? :-P
<lifeless> I think the boron sell it?
<wgrant> lifeless: Hm
<wgrant> I think we can speed up the test suite significantly by completely disabling the lazr.restful representation cache.
<wgrant> We don't read from it, but we still invalidate it on every object flush.
<wgrant> Saves 25% on makePerson.
<lifeless> bug 780835
<_mup_> Bug #780835: representation cache a pessimization <easy> <performance> <tech-debt> <lazr.restful:Triaged> < https://launchpad.net/bugs/780835 >
<wgrant> Sure, but it doesn't say that even when disabled (which is everywhere) it still hurts writes.
<lifeless> wgrant: feel free to add that (or just rip the cache out)
<wgrant> I'm just going to rip it out, since reading from config there is probably too slow.
<wgrant> lazr.config is pretty awful.
<wgrant> (seriously, just profiled)
<wgrant> That saves 40% now, both in and outside the profiler.
<lifeless> o/
<wgrant> Our Storm tracers are slowish too, but not so bad
<lifeless> they need to be replaced
<lifeless> there is a cleaner version in storm trunk
<lifeless> I context switched at the wrong point
<wgrant> Ah
<wgrant> Timeout checking goes through lazr.config
<wgrant> Oops
<lifeless> only until its overridden by the feature flag IIRC?
 * StevenK goes next door to relocate a lawn mower ...
<wgrant> lifeless: Ah, true, so it only happens in the test suite I guess.
<StevenK> wallyworld__: How is the SSD?
<wallyworld__> StevenK: not sure yet. i downloaded a precise iso and am yet to install it
<lifeless> wgrant: check the implementation if you like
<wallyworld__> gotta decide if swap should live on the sdd r not. opinion?
<lifeless> wallyworld__: swap? what swap.
<wgrant> s/ should live on the sdd r not//
<wallyworld__> lifeless:  guess you have lots of ram?
<lifeless> wallyworld__: 8GB on my laptop, 16GB on my desktop.
<wallyworld__> i have 4BB
<wallyworld__> GB
<lifeless> wallyworld__: should be able to do quite a lot w/out swap
<wgrant> Oh, right, and you run LP on amd64.
<StevenK> I have swap on the SSD, but that was so I could hibernate. Which doesn't actually work anyway, so I could kill it.
<wallyworld__> yeah, i do run lp on amd64. it's not too bad
<wallyworld__> fsvo too
<lifeless> I have 1GB swap just-in-case
<lifeless> Swap:  1050616k total,        0k used,
<wallyworld__> i'm afriaid if a put it on the ssd it will kill the ssd
<wallyworld__> well, shorted it's life
<wallyworld__> significantly
<lifeless> only if you use it
<lifeless> what SSD did you get?
 * StevenK peers at jenkins
<wallyworld__> crucial M4
<wallyworld__> $180 on amazon
<wallyworld__> 128GB
<wallyworld__> yeah, and i will be using swap, so best to leave on the hdd i guess
<lifeless> if you're using swap, andhave an hdd available, definitely put it on the hdd
<lifeless> also
<lifeless> http://www.tomshardware.com/news/Crucial-m4-Firmware-BSOD,14544.html
 * wallyworld__ looks
<wallyworld__> lifeless: yeah, saw that issue. i think the drives shipping recently already have the updated f/w but need to check that.
<lifeless> wallyworld__: anyhow, I don't know the crucial arch; the intel one its fine to run swap on - they have (IIRC) 30% slack space to wear level across
<wallyworld__> ok. thanks for the info. i'll do some research :-)
<lifeless> but that said, IMO when you hit swap you've already lost
<StevenK> 2.6 and 3.x are swappyish kernels anyway. They will try *really* hard to swap out at least a little bit if they can.
<lifeless> StevenK: I beg to differ :)
<lifeless>  uptime
<lifeless>  14:00:30 up 9 days, 18:34,  6 users,  load average: 0.05, 0.12, 0.10
<lifeless> uname -a
<lifeless> Linux lifeless-64 3.2.0-8-generic #15-Ubuntu SMP Wed Jan 11 13:57:44 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
<StevenK> lifeless: Where a little bit is like a few pages
<lifeless> Swap:  1050616k total,        0k used
<lifeless> StevenK: yes, I got that; but I don't /see/ it :)
<StevenK> steven@liquified:/media/ECD5-838E/tv% free | tail -n 1
<StevenK> Swap:      3903484       5184    3898300
<lifeless> free | tail -n 1
<lifeless> Swap:      1050616          0    1050616
<wallyworld__> wow, a geek dick measuring contest
<thumper> someone said dick?
<wallyworld__> "my swap is smaller than yours"
<lifeless> anyhow, a few pages won't break an ssd under any circumstances
<StevenK> No, I think lifeless just doesn't believe me
<wallyworld__> thumper: yes, of course it was me
<lifeless> StevenK: I accept you have a few pages swapped out
<thumper> hi wallyworld__
<wallyworld__> g'day thumper. you make it home ok?
<lifeless> StevenK: its had 9 days to find such a page for my laptop, and hasn't.
<wallyworld__> we had a "small" delay
<thumper> wallyworld__: eventually
<wallyworld__> you delayed too?
<wallyworld__> how was the opera?
<wallyworld__> wgrant: that reminds me, i got a $300 Qantas voucher because of the delay. did you get one?
<StevenK> I did
<wallyworld__> StevenK: oh yeah, forgot you were delayed
<StevenK> NFI what the heck I'm going to do with it
<wallyworld__> come to brisbane :-)
<StevenK> Perhaps my wife and I will visit her family in Adelaide again
<lifeless> StevenK: adelaide?!
<wallyworld__> it says it's not transferable :-(
<wallyworld__> so i don't think you can split it up or share it with anyone else
<StevenK> wallyworld__: I was planning on buying 2 return seats. They shouldn't have a problem with that. I hope.
<wallyworld__> hope not. if you do, let me know how it goes
<StevenK> lifeless: And?
<lifeless> StevenK: I thought they were sydney-folk
<StevenK> lifeless: Sarah and her family are all from Adelaide.
<StevenK> wallyworld__: Bloody hell. $275 to fly to ADL on Qantas. One way.
<wallyworld__> wow
<wallyworld__> bit of a rip off
<StevenK> A bit, you say?
<StevenK> That's like calling a fish 'a bit wet'.
<StevenK> Or $380, if I choose to go via Melbourne.
<StevenK> May as well send me via Perth
<lifeless> StevenK: interesting! I wonder why I thought she was from Sydney
<thumper> wallyworld__: the opera as a little surprising
<thumper> wallyworld__: I was jet-lagged, and the opera theatre was warm and dark
<thumper> wallyworld__: the normal naps and snaps occurred
<wallyworld__> oh no, you fell asleep
<thumper> wallyworld__: I feel sorry for the people behind us
<wallyworld__> hah
<thumper> wallyworld__: not fully asleep, just nodded off a few times
<thumper> wallyworld__: I wasn't the only one though
<wallyworld__> it's the head snaps that give it away :-)
<StevenK> I can recall doing that in dark lecture halls when I was at uni ...
<thumper> wallyworld__: I found the opera was better after half time when I read the storyline someone had printed out from wikipeadia and stopped trying to read the subtitles
<wallyworld__> lol
<wallyworld__> and how were the meetings? everything sorted out?
<wgrant> wallyworld__: I did too
<wallyworld__> too bad $300 doesn't get very far on Qantas
<lifeless> it gets you on the plane
<wgrant> Sometimes.
<StevenK> Haha
<StevenK> Sigh. Can we kill polls yet?
<wgrant> Now I wonder what could have triggered that? :)
<StevenK> I wonder. :-P
<wallyworld__> what happened with polls?
<StevenK> wgrant: I have to admit, I'm a little worried adding combobuild into build.
<wgrant> StevenK: Check the qastaging, staging and production build scripts. If they don't use build, you're safe enough.
<wgrant> (enough)
<StevenK> wgrant: Ah, but where the scripts?
<wgrant> StevenK: staging_restore.sh is in lp:lp-staging-scripts
<wgrant> qastaging-update.sh is elusive
<wgrant> And an old version of the production deploymgr config is in carob:~wgrant/dpm-lp-configs
 * StevenK stabs SSO, and then twists the knife.
<wgrant> connection resets?
<StevenK> ssh launchpad@asuka "make -C /srv/staging.launchpad.net/staging/launchpad-new build LPCONFIG=staging" >> $LOGFILE 2>&1
<StevenK> No build for me
<wgrant> Ah, but that's asuka.
<wgrant> Exactly where you want it.
<StevenK> It does it on gandwana too
<wgrant> That's probably because it was copied from asuka; not because it's necessary.
<wgrant> build: compile apidoc jsbuild css_combine sprite_image
<wgrant> The only thing gandwana needs from that is compile.
<StevenK> Right, so I want to branch this and set a CONVOY_ROOT
<wgrant> Probably
<wgrant> You also need to obtain qastaging-update.sh
<wgrant> And possibly a more recent deploymgr config from prasÃ© c/o spm
<nigelb> Mornin'
<StevenK> wallyworld_: You don't show up in mumble as 'harshal-sengar' any more, right?
<wallyworld_> StevenK: not that i'm aware of
<StevenK> wallyworld_: You have an open RT (#43809) about that issue, you could ask IS to close it.
<_mup_> Bug #43809: missing manpage for wcsftime <manpages-posix (Ubuntu):Invalid> <manpages (Debian):Confirmed> < https://launchpad.net/bugs/43809 >
<wallyworld_> ok
<wgrant> wallyworld_: Can't you just use an 'LP' namespace or something?
<wgrant> Or is that too global for deryck/rick_h's liking?
<wallyworld_> tried something like that, doesn't work across instances
<wgrant> Just for the event.
<wgrant> :(
<wallyworld_> atm, i'm devoid of ideas
 * wallyworld_ goes to get the kid from school and transfer rego on "new" car. old faithful blue one finally died :-(
<wgrant> :(
<wgrant> Removing the representationcache may only have saved 5-10 minutes :(
<StevenK> It's still a plus
<wgrant> wallyworld_: Is bug #923973 the event issue?
<_mup_> Bug #923973: sync page is broken <Launchpad itself:New> < https://launchpad.net/bugs/923973 >
<wallyworld_> i didn't raise that one, let me look
<wgrant> I assume the AJAX log and MP longpoll breakage is also that.
<wgrant> But those two are less important, as they only affect us.
<wallyworld_> wgrant: i'm not familiar with that bit of code. i raised bug 923619 to cover cases like editing a recipe, editing a blueprint, changing a branch name
<_mup_> Bug #923619: client model changed events broken <regression> <ui> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/923619 >
<wgrant> wallyworld_: I imagine they'll need separate fixes.
<wallyworld_> i don't know if the breakage in the bug you posted uses the cahce model events or not
<wallyworld_> or what meachanism is used, but sounds similar to what we're seeing elsewhere
<wgrant> It doesn't use those, no.
<wallyworld_> but if it does use Y.fire in some way, shape or form it most likely is now broken
<wallyworld_> just a guess
<wgrant> That was my assumption.
<wallyworld_> it depends on if separate yui() instances are used
<wallyworld_> but if there's a few breakages like this, we need to get this fixed asap
<wallyworld_> and two of the current maintenance squad were involved in the yui work at the epic, so they are well placed to look at this
<adeuring> good morning
<danhg_> #launchpad-kitchen
* gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Firefighting: - | Critical bugtasks: 4*10^2
<StevenK> AttributeError: 'TestPullerMasterIntegration' object has no attribute '_lock_actions'
<StevenK> I thought bzr 2.5 fixed that from happening? :-(
<jelmer> StevenK: I think it's mostly got to do with hook installation
<jml> I just edited a milestone inline on a bug page and the new impage where the edit icon should be was a 404
<jml> with this URL: https://bugs.launchpad.net/testtools/+bug/881052/undefined
<_mup_> Bug #881052: assertRaises gives error about a lambda <regression> <testtools:Fix Committed by jml> < https://launchpad.net/bugs/881052 >
<rick_h> bah, missed him
<deryck> abentley, adeuring, rick_h -- standup in 5 cool?
<rick_h> deryck: k
<adeuring> deryck: fine for me
<abentley> deryck: sure
<deryck> rick_h, adeuring, abentley -- having issues connecting to mumble for some reason.
<abentley> deryck: same here.
<deryck> rick_h, adeuring -- did you guys get in?  We may need Skype for abentley and I.
<rick_h> yea, we're both in
<adeuring> deryck: yes
<deryck> hmmm, yeah, I can't get in.  Doesn't like my password.
<deryck> I got in.
<deryck> adeuring, rick_h, abentley ^^
<rick_h> heh, adeuring and I jumped out. adeuring went looking for a machine with skype installed
<deryck> and abentley just got in!
<rick_h> ok, back to mumble!
<salgado> mrevell, are we supposed to have a call in 10 minutes?  I didn't get any invites for it
<salgado> my calendar just warned me but I didn't see any invites before this
<mrevell> Hey salgado, yeah I sent an invite. Is that okay with you or do you want to reschedule?
<salgado> mrevell, it'd be nice to have mabac and danilos as well.  let's see what danilos thinks
<salgado> danilos, ^
<mrevell> Okay, great.
<salgado> mrevell, did you send the invite to them as well or just me?
<mrevell> salgado, only you
<danilos> salgado, mrevell knows me all to well to want to talk to me
<mrevell> :)
<salgado> I know, but I thought you'd like to talk to him ;)
<salgado> danilos, so, if you don't want to join I think I'll do it now and fill mabac later
<danilos> salgado, mrevell: I'd be happy to join in, mumble on canonical server?
<mrevell> Sure or Google Hangout
<salgado> ok, I'll be back in 1 minute
<danilos> mrevell, salgado: let's do mumble, I am not yet comfortable enough with hanging... out
<danilos> mrevell, can you hear me?
<mrevell> I hear you
<mrevell> I'm having some trouble with the mic
<mrevell> yes
<salgado> unmute me!
<danilos> salgado, can't you unmute yourself?
<salgado> mrevell, https://blueprints.launchpad.net/linaro-status-website/+spec/individual-engineer-upcoming-work-view-mockup
<jml> lifeless: do you have a tabular schema for subunit data anywhere?
<lifeless> jml: maybe?
<jml> lifeless: thinking of writing a subunit -> csv filter to make data analysis easier.
<lifeless> ah
<jml> lifeless: want to try to stop me?
<lifeless> not at all
<jml> :)
<lifeless> subunit is streaming after all; so either casting it to a static form, or using a streaming language -> either make a lot of sense
<lifeless> the lp results tracker may have some inspiration, as may the linaro thingy
<jml> thinking id,start_time,stop_time,status for now
<jml> lifeless: do you know where I can find those?
<lifeless> somewhere on LP? lp:launchpad-results is one
 * bigjools waves at lifeless the insomniac
<lifeless> o/
<deryck> wallyworld_, you around?
 * deryck needs to get away from the screen, back soon
<wallyworld_> deryck[lunch]: hi, ping me when you get back from lunch. i have to drop the kid at school soon, won't be long
<deryck> wallyworld_, back when you are.
<wallyworld_> deryck: give me 25 minutes. i'm just leaving to drop the kid to school, be back as soon as i can
<mhall119> is there a way in launchpadlib for me to get a list of bugs that have a patch attached to them?
<deryck> wallyworld_, np.
<deryck> mhall119, use searchTasks and pass in the has_patch argument. see:  https://launchpad.net/+apidoc/
<mhall119> thanks deryck
<deryck> np
<wallyworld___> deryck: hi, mumble?
<deryck> wallyworld___, hey.  give me 3 or 4 minutes to wrap what I'm doing and I'll meet you there.
<wallyworld___> ok
<deryck> wallyworld___, and what's with all those underbars? ;)
<wallyworld___> no idea
<wallyworld___> NickServ says my nick is temporarily unavailable
<deryck> wallyworld___, my brother in law came in sorryâ¦. 5 more minutes
<wallyworld___> np
<wallyworld___> wgrant: i installed precise on a clean system. debversion for postgres 8.4 wouldn't install because libapt-pkg.4.10 wasn't there (precise uses 4.11 ). i can't find a deb for 4.10 anywhere. any hints?
<wallyworld___> wgrant: to get it working, i forced debversion to install and symlinked the required .so files to the 4.11 ones. but now apt insists on uninstalling debversion since it thinks it's broken
<deryck> wallyworld___, ok, free now.  firing up mumble
<wallyworld___> ok
<wgrant> wallyworld___: According to gary on the ML, LP on precise is broken in other ways too. I'll do a fresh LP installation today and sort it out.
<wallyworld___> wgrant: thanks
<wallyworld___> deryck: for the single instance name, a few people have expressed a dislike for "LPS". perhaps "LP_YUI" or something
<deryck> wallyworld___, sure, I don't care about that.  I'd like to avoid underbars though.
<wallyworld___> deryck: i have no opinion, just relaying someone else's :-)
<deryck> wallyworld___, what's the dislike of LPS?  Just a weird name?
<wallyworld___> yeah
<deryck> yeah, I can see that.
<wallyworld___> np, leave it to you to decide :-)
<deryck> ah, I don't care.  I'll change it but drop the under bar.  LPYUI work?  Or LPUI?  Or â¦?
<deryck> :)
<lifeless> Launchpad Production Status
<lifeless> ^ LPS already exists, lets not have two.
<wallyworld___> lifeless: it used to be LPS, we are deciding on a new name
<deryck> I think it was originally meant to be LPJS, but the sed script was wrong, and no one noticed or complained til now. ;)
<lifeless> thanks! :)
<wallyworld___> deryck: you serious???!!!!
<deryck> wallyworld___, I am. ;)
<wallyworld___> lol
<deryck> heh, I know.
<wallyworld___> LPYUI sounds ok to me, but meh
<deryck> yeah, I'm not passionate about it either.
<deryck> Just too lazy to type an underbar all the time.
 * wallyworld___ nods
<deryck> I think we should try again for LPJS and see if we get it right this time. ;)
<StevenK> LPJS sounds okay to me
<StevenK> Better than LPS anyway
<deryck> I'm just kidding around.  Any other name is fine with me.  Will let rick_h pick since he'll be doing the sed-based branch tomorrow.
<deryck> Later on, everyone.
#launchpad-dev 2012-02-01
<wgrant> wallyworld___: ppa:launchpad should work on precise now
<lifeless> man once you start looking for dupes
<lifeless> there are tonnnnes
<lifeless> (e.g. bug 132300)
<_mup_> Bug #132300: mail for new bugs inconsistent with other bug mail (ignores mail-on-my-actions disabled, missing footers, duplicate mail vs structural subscriptions) <email> <lp-bugs> <notifications> <Launchpad itself:Triaged> < https://launchpad.net/bugs/132300 >
<wgrant> lifeless: Well
<wgrant> lifeless: They're not necessarily dupes
<wgrant> They would all be solved by making them consistent, but they're really separate bugs.
<lifeless> wgrant: I think there is one that isn't necessarily a dupe
<lifeless> wgrant: anyhow, we have limited facilities for saying 'X symptom', 'Y symptom' of a given root cause, so meh:)
<wgrant> Bah
<wgrant> lxc has been apparmored
<wgrant> Ahhhh
<wgrant> And that explains why my syslog has been all broken.
<wgrant> rsyslog from a container sometimes takes hold of the same stream
<wgrant> So /var/log/kern.log only gets the occasional byte
<lifeless> ok so I need help finding a damn bug :)
<lifeless> there was one about bugs like bug 1
<lifeless> which get flashcrowded
<_mup_> Bug #1: Microsoft has a majority market share <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <LibreOffice Productivity Suite:New> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Invalid by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Progress> <metacity:In Prog
<lifeless> I cannot find
<wgrant> Bug #73122?
<_mup_> Bug #73122: individual bug reports can become very noisy and confused when unrelated comments, tasks and other links are created <lp-bugs> <ubuntu-platform> <Launchpad itself:Triaged> < https://launchpad.net/bugs/73122 >
<lifeless> aiie thanks
<wgrant> Hmm
<wgrant> So I guess by apparmoring lxc-start you actually end up apparmoring an entire userspace, which is probably unprecedented.
<wgrant> Not surprising it doesn't work.
<lifeless> wgrant: so it looks like it works but fails hard?
<wgrant> Most stuff works
<wgrant> But eg. dpkg-divert sometimes doesn't.
<lifeless> 'nice
<lifeless> '
<wgrant> Yeah, that's it.
<wgrant> Breaks ephemeral entirely too.
<wgrant> Probably because overlayfs doesn't like LSM much.
<lifeless> wgrant: filed a bug ?
<wgrant> Nah, mailing gary about it.
<wgrant> Needs some investigation to see what's actually going on.
<wgrant> And I've got two further non-feature things to do today
<lifeless> work? zomg
<wgrant> I really hate Erlang.
<wgrant> wallyworld_: Do you still have the rabbitmq-management-agent issue?
<wallyworld_> wgrant: yes, not sure exactly what the root cause is, but the 4 or 5 rabbit packages don't install
<wgrant> wallyworld_: sudo rm -r /usr/lib/erlang/lib/rabbit_management_agent
<wgrant> There's something wrong with part of the rabbitmq-management-agent package
<wallyworld_> wgrant: and try reinstalling now?
<wgrant> Yes.
<wgrant> And you can remove the libapt-pkg symlink as well
 * wallyworld_ fires up apt-get
<wgrant> I've fixed the PPA up.
<wallyworld_> and the debversion package too?
<wgrant> The fixed version is built.
<wallyworld_> too slow at typing, yay, thanks. trying it now \o/
<wgrant> So just upgrade
<wgrant> A fresh installation of launchpad-developer-dependencies works in precise now, apart from the rabbitmq issue
<wallyworld_> wgrant: yes, it indeed works. thanks, that's awesome
<wgrant> Huh
<wgrant> rabbitmq-management installs lots of files that should be in rabbitmq-management-agent
<wgrant> Ahhh
<wgrant> lynxman typoed it
<wgrant> --- rabbitmq-management-2.6.1+hg20110927.orig/debian/install
<wgrant> +++ rabbitmq-management-2.6.1+hg20110927/debian/install
<wgrant> @@ -0,0 +1,2 @@
<wgrant> +build/app/rabbitmq_management-2.6.1/* usr/lib/erlang/lib/rabbit_management_agent
<wgrant>        85 /   69  MaloneApplication:+bugs
<wgrant> Why don't I believe that.
<wgrant> lifeless: Any idea about those numbers?
<wgrant> They seem implausibly low.
<lifeless> 144 /    0  MaloneApplication:CollectionResource:#bugs
<lifeless> mm
<lifeless> 2K total timeouts
<lifeless> wgrant: '54 /  205    '
<lifeless> wgrant: might be hiding something
<lifeless> wgrant: the numbers seem consistent with the total timeout count
<StevenK> wgrant: Do you mind QAing r14737?
<wgrant> StevenK: Done
<wgrant> lifeless: "may never" lolol
 * StevenK reaches for mawsonm
<StevenK> s/m$//
<StevenK> wgrant: Plan is to get r14738 deployed to NDT as soon as mawson behaves, and hopefully FDT it onto ppa/ftpmaster tonight
<wgrant> Correct.
<StevenK> wgrant: I just came up with that plan, how can it be correct?
<wgrant> It is the right plan.
<wgrant> The only plan, even.
<lifeless> hey
 * StevenK waits for mawson to finish WADLing
<lifeless> does poppy need DB access any more ?
<wgrant> No.
<wgrant> Well
<wgrant> In 5.5 hours it won't.
<wgrant> But it may still connect.
<lifeless> cool, lets rip it out
<StevenK> lifeless: Your bullet points should be seperate points
<StevenK> lifeless: "or of bugs filed against launchpad-project "
<StevenK> Which doesn't make sense either
<lifeless>  * Increasing the number or difficulty of bugs filed against launchpad-project
<lifeless>  ?
<StevenK> Yes, which requires it and the previous point to be read together, and it scans awkwardly
<wgrant> lifeless: Bug #246022: team admins/owners (and possibly members?) can contact all members (or the mailing list if one is configured). Everyone else can only contact the owner.
<_mup_> Bug #246022: No way for team admins to contact all members of the team <contact-via-web> <feature> <lp-registry> <mailing-lists> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/246022 >
<lifeless> StevenK: I'ma sking if that rephrasing is better
<lifeless> wgrant: bah, I dropped the list condition from the summary
<StevenK> lifeless: Oh, right. Sounds fine to me. There is a similar issue in the second group of bullets
<nigelb> Mornin'
<nigelb> StevenK: For a minute there, I wondered why lifeless was skiing.
<StevenK> Hah
<StevenK> nigelb: Looking forward to the first T20I? :_D
<nigelb> Not really.
<nigelb> I think they'll get crushed. :)
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/ttb-no-chroot/+merge/91015
<StevenK> wgrant: Can haz review?
<wgrant> StevenK: Is there a test for _getDistroArchSeries?
<StevenK> It just returns ubuntu.currentseries.nominatedarchindep, I suspect that is already well-tested
<StevenK> lifeless: Didn't we kill oops prefixes?
<StevenK> wgrant: Distracted much? :-P
<wgrant> StevenK: Sure, but the method isn't tested any more.
<wgrant> I would reinstate _getChroot and the test.
<wgrant> They're doing not much harm.
<wgrant> Or is dispatchBuildToSlave fairly well tested?
<wgrant> Given what it does, it seems unlikely that its tests are stellar.
<StevenK> wgrant: Why did you unassign yourself from bug 780835?
<_mup_> Bug #780835: representation cache a pessimization <easy> <performance> <qa-ok> <tech-debt> <lazr.restful:Triaged> < https://launchpad.net/bugs/780835 >
<StevenK> Oh, since it probably needs to be ripped out of lazr.restful now that LP doesn't make use of it?
<wgrant> StevenK: Right.
<wgrant> It was a lazr.restful task, which I didn't notice until after I'd landed the branch.
 * StevenK waits for the diff to update. :-(
<StevenK> wgrant: The diff isn't updating, but http://pastebin.ubuntu.com/824788/ is a diff against submit:
<wgrant> StevenK: Diff looks updated to me.
<wgrant> Note that AJAX updating is presently broken.
<wgrant> Approvalised
<StevenK> I've been refreshing anyway
<nigelb> Wait. diff stuff is now queued?
<nigelb> Or is it for launchpad team only for now.
<StevenK> nigelb: Currently, you need to be a member of ~launchpad
<StevenK> It needs a bit of polish
<wgrant> And it's been broken for a couple of days, but will hopefully be back next week.
<nigelb> Hrm, I suspect as much. But still, closer.
<StevenK> nigelb: Jealous? :-P
<nigelb> StevenK: You have *no* idea.
<nigelb> 44
<nigelb> bah irssi
<lifeless> StevenK: so oops_prefix -> reporter in the new oops stack
<lifeless> StevenK: we have glue in LP to dynamically allocate them for scripts etc
<lifeless> StevenK: but they are still used in appservers (but with little reason, we can discriminate via hostname...)
<wgrant> lifeless: Can we migrate to one-config-per-user yet?
<lifeless> I don't see why not
<lifeless> I only ever wanted us to just limit the rate-of-change, for auditability
<adeuring> good morning
<danhg> Morning
<stub> wgrant: I see you rebuild postgresql-8.4-debversion for precise. Are you using the lucid packages atm. for the rest of things?
<wgrant> stub: I grabbed slony (1) from oneiric in the primary archive, but had to rebuild debversion due to a libapt-pkg soname bump in precise.
<stub> no signer listed for slony... don't know if that is a problem
<stub> Are your PostgreSQL packages from precise?
<wgrant> Nah, the lack of signer is just because it was synced from Debian.
<stub> Just wondering if I should leave things as they are or try to push the pg8.4 packages into the lp ppa.
<wgrant> postgres itself we're still using from the primary archive.
<wgrant> Which, as you say, will probably go away in less than a month.
<stub> I'd like devs on PG 9.1 in the next week or two in any case
<stub> ok. I'll leave it as things are then and assume gary's missing PG packages are his problem.
<wgrant> But we can grab 8.4 from precise once it vanishes, if we haven't moved to 9.1 by then.
<wgrant> His problem was debversion and slony.
<wgrant> Which I fixed a few hours back.
<stub> oic. thanks.
<wgrant> I also diagnosed the postgresql-common issue, as you may have seen.
<wgrant> Unrelated to postgres, as it turns out.
<stub> and now I see your email :)
<stub> yes, saw that thread earlier ta.
<stub> How is package syncing/package copyiHow is package syncing/package copying being done now? The sync_packages database user exists but I can't find anything in the code base that actually uses it.
<stub> How is package syncing/package copying being done now? The sync_packages database user exists but I can't find anything in the code base that actually uses it.
<wgrant> stub: It's used by IPlainPackageCopyJobs
<wgrant> Which are run when IPlainPackageCopyJobSource is given to process-job-source.py
<wgrant> Which gets the dbuser from schema-lazr.conf
<stub> Which doesn't mention sync_packages, so must be using a different database user
<wgrant> dbuser: sync_packages
<wgrant> Line 1958
<stub> pebkac. Was running bzr grep in the wrong directory.
<wallyworld__> nigelb: watching the T20? :-P
<nigelb> wallyworld__: Not you too :P
<wallyworld__> oh yeah!!!
 * wallyworld__ loves cricket
<wallyworld__> especially when India lose :-P
<wallyworld__> and another wicket falls!!
<nigelb> fuuuuuuu
<bigjools> wallyworld__: haha :)
<wallyworld__> yep :-)
<bigjools> nigelb, wallyworld__: new Indian interweb domain: .ball
<wallyworld__> lol!!!
<wallyworld__> that is hilarious
<wallyworld__> i almost spit out my wine
<wallyworld__> all over the keyboard
<bigjools> my work here is done
<wallyworld__> indeed it is
<nigelb> bigjools: At least India didn't get bowled out for 72....
<wallyworld__> ouch
<wallyworld__> nigelb pwned bigjools
<bigjools> nigelb: wanna talk about your tour to England last year? all those innings defeats? :)
<nigelb> Still. 72. It happened even in T20 in a while.
<StevenK> I was enjoying the '35 needed from 4 balls' counter
* abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb, abentley | Firefighting: - | Critical bugtasks: 4*10^2
<abentley> deryck: qastaging's database appears at least a month out of date from production.
<deryck> flacoste, is this known ^^ ?
<flacoste> deryck: yes, it's a known problem
<flacoste> we don't have a regular update of the qastaging db
<flacoste> unlike staging which is reset every week-end
<deryck> ah ok
<abentley> flacoste: I see.  Thanks.
<deryck> flacoste, do we schedule it on demand then?
<flacoste> deryck: tbh, i have no idea :-/
<flacoste> but something like that yes
<deryck> ok, cool :)  thanks, flacoste
<flacoste> mthaddon might know
<mthaddon> yep, it's on demand
<rick_h> abentley: can you peek at https://code.launchpad.net/~rharding/launchpad/one_yui_instance/+merge/91111 when you get a sec?
<abentley> rick_h: sure thing.
<rick_h> abentley: ty
<abentley> rick_h: Why "LPJS"?  Wasn't it something else before?
<rick_h> abentley: it was LPS before but it was brought up that LPS stands for something and isn't as clear
<abentley> rick_h: r=me.
<rick_h> abentley: ty
<deryck> actually, it was always meant to be LPJS.  But I can't type a J for some reason.  And my sed command was wrong. ;)
<deryck> and no one caught it or complained until recently. :)
<sinzui> jcsackett, do you have a few minutes to mumble?
<deryck> abentley, I'm triaging bugs.  Bug 921213 looks like Bug 760735 to me.  Do you agree?
<_mup_> Bug #921213: recipe does not build: make: Cannot open: Permission denied <Launchpad itself:Confirmed> < https://launchpad.net/bugs/921213 >
<_mup_> Bug #760735: Daily recipe: failure because of Permission denied accessing build/patch directories <recipe> <soyuz-build> <Launchpad itself:Fix Released by jelmer> < https://launchpad.net/bugs/760735 >
<jelmer> deryck: they are
<abentley> deryck: yes
<deryck> abentley, jelmer thanks!
<deryck> abentley, adeuring, rick_h -- I did my hour.  yay me! :)  I cleared project review, open bugs, and answered a couple questions.
<adeuring> deryck: congrats!
<rick_h> deryck: woot!
<abentley> deryck: cool
<jcsackett> sinzui: i can mumble now, sorry i was on the phone when you pinged earlier.
<jcsackett> sinzui: are you still free?
<sinzui> I am
 * jcsackett fires up mumble
<lifeless> morning
<mhall119> can I check if a person is a canonical  employee or not through the launchpadlib api, using the anonymous login?
<james_w> no
<mhall119> ok, then I need to get an app authorized to access that
<dobey> mhall119: authorized in what sense? you will only be able to see members of that team, if you are also a member of it, as it's a private team.
<mhall119> dobey: I'm adding to the script that builds bug stats for unity
<mhall119> I need to show the number MPs coming from community
<jelmer> mhall119: have you seen the contributors script in Launchpad?
<mhall119> jelmer: no, does it involve zope?
<lifeless> no, why would it?
<jelmer> mhall119: IIRC it doesn't; it just looks at bzr commits in the mainline rather than merge proposals though
<mhall119> lifeless: because it's launchpad?
<mhall119> where can I see this?
<jelmer> utilities/community-contributions.py in lp:launchpad
<dobey> mhall119: you can probably check that the owner of the source branch with is_valid_reviewer() on the target branch, in a proposal
<jelmer> mhall119: the result of that script is at http://dev.launchpad.net/Contributions
<dobey> jelmer: if it returns true, the owner is part of the unity team, if it's false, the owner is community :)
<mhall119> jelmer: where can I see the script itself?
<jelmer> mhall119: it's linked from the wiki page
<mhall119> dobey: what object has is_valid_reviewer?
<mhall119> dobey: ok, I see <branch>.iPersonTrustedReviewer
<abentley> deryck: I'm OCR.  Could you possibly review https://code.launchpad.net/~abentley/launchpad/fix-index-download/+merge/91160 ?
<dobey> mhall119: yeah, sorry, isPersonTrustedReviewer
<mhall119> but that only tells me if someone is on the unity team, not if they're non-employees
<dobey> mhall119: why does it matter if they're an employee or not?
<mhall119> dobey: because that's the metric my manager wants
<deryck> abentley, sure
<mhall119> besides, I'm not even sure if everyone in the dx team would be isPersonTrustedReviewer on unity's trunk
<abentley> deryck: thanks.
<deryck> np!
<dobey> mhall119: possibly not, but not everyone on dx works on unity, either
<mhall119> dobey: right, so I don't think jono wants DX members who don't work on unity counted in this metric
<dobey> *shrug*
<deryck> abentley, r=me
<abentley> deryck: thanks.
<deryck> abentley, np!
<lifeless> -> l'hopital
<lifeless> bbiab
<mhall119> dobey: ok, I've got it working, now to optimize it
<mhall119> dobey: is there a way to pre-fetch all the people who can review lp:unity, and check against that for each MP against lp:unity
<dobey> mhall119: you can get the default reviewer that's set for the branch, and branch owner, and compare against those (they might be different)
<mhall119> dobey: right, but it'll always be the same team as reviewer
<mhall119> so can I hit LP once to get all of the members of that team, and then check locally?
<dobey> yes; your script should check both in case they are different. if you've already got the branch object, it shouldn't be expensive to see if they are the same.
<dobey> (to save having to fix the code later, if you decide to run the script against a project which does have different values set) :)
<mhall119> how far back does <branch>.landing_candidates go?
<mhall119> and is that the best way to get a historical list of merge proposals
<abentley> deryck, rick_h: Did my interrupt duties.  Project review, some Questions, spam deletion, and I updated https://wiki.canonical.com/Launchpad/FeedbackMonitoring
<deryck> abentley, awesome, thanks.
<rick_h> StevenK: ping when you're around to chat make/js build dir stuff
<StevenK> rick_h: Hmmmm?
* abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2
<StevenK> abentley: If you tag a bug as 'qa-bad', could you also add 'bad-commit-<revno>' ?
<StevenK> abentley: Not trying to pick on you, it just keeps happening. I think a mail to -dev is in order.
<abentley> StevenK: It seems absurd that I should need to.
<StevenK> abentley: Why? Its needed for the qa-tagger if you rollback the branch
<abentley> StevenK: Because there's only one revno I could possibly be talking about.
<StevenK> abentley: No, there could be more -- land, qa-bad, rollback, land, qa-bad ....
<StevenK> It has happened like that.
<abentley> StevenK: I'm saying there *aren't* more.
<abentley> StevenK: And at the time something is marked qa-bad, I don't think there's ambiguity either.
<deryck_> Later on, everyone.
<wallyworld_> rick_h: have you submitted your LPJS branch to ec2?
<lifeless> StevenK: I agree, a mail to -dev is in order.
<lifeless> StevenK: if the process is wrong / needs more automation, we can/should do that; but driving the tools inconsistently confuses folk and that consumes time and energy.
#launchpad-dev 2012-02-02
<lifeless> jelmer: I find it amusing that a feature designed to reduce spam still spams when used via email.
<jelmer> lifeless: oh, you're getting the affectsmetoo emails?
<jelmer> sorry about that, I'll avoid using that via email
<lifeless> jelmer: https://bugs.launchpad.net/launchpad/+bug/925224
<_mup_> Bug #925224: affectsmetoo emails still spam all subscribers of a bug <Launchpad itself:Triaged> < https://launchpad.net/bugs/925224 >
<rick_h> wallyworld_: yes, submitted and missed 3 tests
<rick_h> wallyworld_: I've got to fix those and resubmit
<rick_h> StevenK: howdy
<wallyworld_> rick_h: ok. i've had to merge that branch locally inro my own own. if you could ping me when you've finished updating, that would be great
<wallyworld_> s/own own/own work
<rick_h> wallyworld_: will do, might be a bit. Out with some people atm
<wallyworld_> rick_h: np. i didn't mean now, tomorrow if fine :-)
<rick_h> wallyworld_: k, sounds good. Yea, just some stray doctests checking for YUI() vs LPJS so should be quick updtes
<wallyworld_> cool :-)
<huwshimi> lifeless: I think I'm getting bug 775214 from one of the Launchpad doc tests. I think the test passing but testr just ouputs "String or Integer object expected for key, unicode found". Is this actually a failure?
<_mup_> Bug #775214: On python 2.7: String or Integer object expected for key, unicode found <Testrepository:Fix Committed by lifeless> < https://launchpad.net/bugs/775214 >
<lifeless> huwshimi: where are you seeing this?
<huwshimi> Output from "testr run -- -t sprites" (in the file lib/lp/services/doc/sprites.txt)
<huwshimi> lifeless: ^
<huwshimi> lifeless: But only from my modified version of that file
<lifeless> huwshimi: probably not that bug
<lifeless> huwshimi: does 'bin/test -t sprites' error ?
<huwshimi> lifeless: nope: http://paste.ubuntu.com/825853/
<lifeless> ok, could you run
<lifeless> bin/test --subunit -t sprites > foo.log
<lifeless> and then mail me that log file ?
<huwshimi> lifeless: sure
<huwshimi> lifeless: Mailed
<lifeless> ok, so possibly you are seeing that
<lifeless> what testr version are you running ?
<lifeless> jelmer: was that irony?!
<huwshimi> lifeless: testrepository 0.0.5-1.1 I think
<lifeless> add the testing-cabal PPA
<lifeless> that should sort things out for you
<huwshimi> lifeless: Great, I'll try that
<huwshimi> lifeless: Perfect, works now :)
<lifeless> cool
<lifeless> I have on my todo one more patch then a release for testr
<huwshimi> lifeless:  I assume that ec2 test won't be confused by this somehow?
<lifeless> it won't be
<huwshimi> awesome
<wallyworld_> StevenK: do you know how the lp credentials/ssh keys get into the ec2 instances, such that bzr commands against lp "just work" inside the instance
<wgrant> wallyworld_: You might want to avoid thinking about it.
<wgrant> ssh -A
<wgrant> WCPGW
<wallyworld_> wgrant: i've got a canonistack instance i'm playing with
<wallyworld_> and i want to run some commands to pull lp trunk and run tests etc
<mwhudson> i think ec2 test just uses ssh -A
<wgrant> RIght.
<wgrant> It uses ssh -A
<wgrant> Which is why it's really not healthy to think about it for long.
<wallyworld_> so i do "ssh -A <ip>" ?
<wgrant> However you normally ssh into the instance, add -A
<wallyworld_> right
<wallyworld_> will try that, thanks
<wgrant> However
<wgrant> Depending on your SSH config that may not work.
<wallyworld_> but it works when ec2 scripts do it
<wgrant> Right, but they don't go through the DC.
<wallyworld_> and the DC is more locked down?
<wgrant> It is, but that's not relevant here. I think it was recommended at one point to locally disable forwarding for some hosts.
<wgrant> But I don't have anything in mine, so I may have been misremembering.
<wallyworld_> ok, will try it and see :-)
<wallyworld_> thanks
<StevenK> wgrant: How do I QA the TTBJ failure on DF?
<StevenK> Since I've managed to avoid TTBJs completly until now
<wgrant> StevenK: Difficult
<wgrant> StevenK: TTBJs are normally done on staging
<wgrant> But the code may not be there yet.
<StevenK> wgrant: Happy enough to qa-untestable it, since let's face it, it's 3 lines
<wgrant> Yeah
<wgrant> And they were broken for a year without anybody noticing.
<wgrant> So I'm not too concerned.
<StevenK> I'm not interested in deploying either, given it's effectively the only change.
<wgrant> StevenK: We can't deploy for a while anyway.
<wgrant> stub landed some DB user changes that require production changes.
<StevenK> They're still going through buildbot
<wgrant> Ah
<StevenK> Not interested in deploying 3 revisions with one change.
<wgrant> No :)
 * StevenK stabs gnome-terminal
<rick_h> StevenK: hey, got a sec?
<StevenK> rick_h: Sure do
<rick_h> hey, so I started working on getting the YUI tests back up and linked right away from icing
<rick_h> and to do that, I think I need the lp js files in the build/js/lp dir like we started out with
<rick_h> and then just make all tests walk up ../../../build/...
<rick_h> and then our convoy dir would be a symlink from build/js/lp off to the convoy root instead of building into the convoy root as we do now
<StevenK> Why would we do that?
<StevenK> I'm uncomfortable with out-of-tree symlinks
<rick_h> for a couple of reasons. The YUI code is there now, and I want to keep that so we can swap out YUI versions in tests with a new make command that would swap out a symlink build/js/yui -> 3.3.0/3.4.0
<rick_h> and I don't want to build twice, once into build/js/lp and once into $convoy_root/js/lp
<rick_h> since we do things like min and such
<rick_h> and if we create a build/js/lp then all the tests can point there and you it provides one place for all the files to be and if they're missed in the build step, the tests will fail
<StevenK> rick_h: So, we don't currently build the rootdir automatically since it will blow up on qas/staging/prod, so I'm not sure about this plan.
<rick_h> StevenK: right, so we don't currently build into the convoy dir
<StevenK> make build is used by too many things currently
<rick_h> but there's nothing that prevents us from the build/js dir
<StevenK> rick_h: But we already build into icing
<lifeless> rick_h: so the way we do it for icing is that the deploy process makes one symlink *into* our tree
<rick_h> we build a single .js file into icong
<rick_h> lifeless: and that could still do that right? It would symlink into build/js/lp
<lifeless> rick_h: there are several symlinks in a farm in the root directory of the icing area on the apache server
<rick_h> right now, the combo-rootdir places files into a $convoy_root dir but I want them to exist in build
<lifeless> rick_h: yes, thats my proposal. So the symlinks point *into* our tree
<StevenK> I don't think convoy follows symlinks
<rick_h> lifeless: right, that's what I'm trying to change to
<lifeless> StevenK: well, thats fixable :)
<lifeless> rick_h: +1
<rick_h> StevenK: ah right, I think that was the issue wasn't it. Well maybe I need to take a stab at fixing that then
<StevenK> But I'm happy to investigate that change
<lifeless> I'd like this to be as close to icing as possible, given they are so conceptually similar
<lifeless> less surprises for new folk staring at it
<rick_h> StevenK: ok, well I wanted to bring it up, see what we thought. Like lifeless says, I'd like the files to exist in our tree for the test purposes and then work out from there
<rick_h> I don't want the tests knowing about $convoy_root and I'd like the tests to look at the build files in case the build is broken to know at the test level
<StevenK> So we can populate build/js and then make /var/tmp/convoy be a symlink to that dir
<rick_h> StevenK: yea, and if convoy doesn't follow symlinks I'll work on fixing that
<rick_h> I think that'll be closer to what we do now with icing and would be cleanest.
<StevenK> I'll see about doing that
<rick_h> ty much
 * StevenK grumbles
<StevenK> Can't create a yui symlink under build/js since yui is already a directory
<rick_h> StevenK: I thought there was a new command for installing the alt yui versions and such working
<StevenK> The yui directory has changed from yui to build/js/yui
<rick_h> StevenK: yea, that's part of what needs moving because if I want to run all the JS tests from YUI 3.3 to 3.4 then I need to update the seed file on all the tests
<rick_h> so I want to write the tests to build/js/yui and have a make command to swap that symlink to the "active" yui version running
<StevenK> Can you deal with build/js/yui/yui ?
<StevenK> I can give you that easily
<rick_h> yea, it can be whatever we want
<rick_h> we just need to figure out what we want and stick with that standard
<rick_h> but it needs to be coordinated between the make script, the test's seed file, and potentially convoy
<StevenK> I might change the buildout yui stuff
<rick_h> that's why I wanted to chat with you on it? :) I'm reading the Make book, but still researching make/buildout
 * StevenK learnt make out of sheer self-defense
<rick_h> anyway, time for bed here, really appreciate the help and let me know what goes wrong and how I can work on getting it going
<rick_h> sorry to keep changing things over and over
<StevenK> And now the icing yui links to the convoy rootdir?
<StevenK> BAH
 * StevenK shakes his fist at wallyworld_ 
<wallyworld_> why?
<StevenK> You can't break icing like that
<StevenK> icing is served statically on banana/nutmeg and they won't have convoy installed
<StevenK> I'd prefer icing's js stuff is left entirely alone
<wallyworld_> the original build scripts from ages ago put yui stuff in icing
<StevenK> I'm trying to sort this out, so I can bend build/js to my will
<wallyworld_> cool
<StevenK> wgrant: I can use inplace, since that is the default make target, but qas/s/prod don't call it
<wgrant> huwshimi: That mockup is sort of along the lines of what I'd been thinking, but I was trying to work out how to distinguish some and all. Possibly all has a border or something.
<wgrant> Because distinguishing them is reasonably important.
<huwshimi> wgrant: Ah ok. Maybe we can think about colouring each status instead of all being grey. A bit like what Curtis had done for the text, but for the background.
<wgrant> That's a possibility.
<wgrant> But it seems like that might make more sense to indicate the policy.
<wgrant> But I guess that's not so important if we show Nothing.
<wgrant> I was assuming we'd not show policies with no access.
<huwshimi> wgrant: Yeah, me too
<huwshimi> wgrant: I guess then you'd have to have a "Add policy" button
<wgrant> Right, there'd probably be an Add/+ link at the right which lets you select a new policy.
<wgrant> But given that there's probably only three policies, it might be nicer to have them more tabular like this.
<huwshimi> wgrant: Yeah.
<wgrant> Then it becomes very scannable, particularly if we visually distinguish All and Some.
<huwshimi> wgrant: It might be sensible if the reality is that there are a lot of "nothings"
<wgrant> There are loooots of nothings.
<huwshimi> wgrant: I might actually mock something up and send it to the list. I don't remember ever hearing why that changed (my original intention had been to hide the nothings)
<huwshimi> wgrant: I guess it would be slightly less scannable though
<huwshimi> wgrant: Also I guess it's slightly less explicit
<huwshimi> wgrant: How often is it that a user/team will have more than one policy?
<wgrant> huwshimi: Most projects will have either just proprietary or both embargoed security and user data. Some projects will have all three. Of those, project owners will generally have all of the available policies, most other users will only have user data, but the occasional user will probably have both security and user data.
 * StevenK blinks
<StevenK> Why is os.path.exists(full) returning False? :-(
<wgrant> StevenK: Note that it follows symlinks.
<huwshimi> wgrant: Ok, so in most cases we're talking about one or two policies being used for the whole project (so there won't be a jumble of all three very often)
<wgrant> So will return False if the path points at a broken one.
<wgrant> huwshimi: Right.
<huwshimi> wgrant: Great.
<StevenK> lrwxrwxrwx 1 steven steven 53 2012-02-02 16:22 /var/tmp/convoy -> /home/steven/launchpad/lp-branches/combo-url/build/js
<StevenK> That looks fine to me
<StevenK> [Thu Feb 02 16:55:41 2012] [error] [client 127.0.0.1] IOError: [Errno 13] Permission denied: '/var/tmp/convoy/yui/yui/yui-min.js'
<StevenK> Hm, the plot thins
<StevenK> Hmm, /var/tmp is 1777, so perhaps you can only cd if the owner matches
<StevenK> Which sounds likely
<StevenK> Since root can't cd either
<wgrant> huwshimi: I think the scannability may recover if each policy type gets a colour.
<wgrant> As lots of sites do with tags nowadays.
<huwshimi> wgrant: I guess you could still do a lighter/darker shade of that colour to show "some" or "all"
<wgrant> Exactly.
<wallyworld_> StevenK: why ~/launchpad/lp-branches/combo-url?  is that local or on prod?
<wallyworld_> i'd think we'd want it to point to somewhere in the tree
<StevenK> That is the tree!
<wallyworld_> not the tree where the lp source code is checked out to
<wallyworld_> ie why not somewhere under lp-branches/my-lp-checkout/...
<StevenK> Because I use seperate directories per branch
<wallyworld_> :-(
<wallyworld_> that's even more reason to put it under the proper source tree
<wallyworld_> so different branches have their own copy
<StevenK> It is in the source tree!
<StevenK> That's the point of the build/js at the end
<StevenK> The symlink is so I don't have to rewrite /usr/share/convoy/convoy.wsgi and reload apache everytime the branch changes
<wallyworld_> so if your working tree for launchpad is lp-branches/my-lp-sandbox, how is lp-branches/combo-url in the launchpad working tree?
<StevenK> What? You've lost me
<wallyworld_> so the lp source code is checked out to lp-branches/some-working-dir
<wallyworld_> and under there is lib/lp etc etc ie all the lp source
<wallyworld_> so i would expect all build artifacts for that checkout to be located under that source dir
<wallyworld_> not a level above
<StevenK> wallyworld_: http://pastebin.ubuntu.com/826045/
<wallyworld_> StevenK: oh, that is the name of a branch
<wallyworld_> i thought it was just a directory where stuff got built into
<StevenK> Yes!
<wallyworld_> sorry, misunderstanding
<lifeless> anyone up for a small revu ?
 * lifeless makes a note to ring telecom tomorrow and complain about shocking performance occuring again
<mabac> I'd like to submit a really small fix and wonder if a change to lib/lp/testing/_login.py should be accompanied by unit tests?
<mabac> http://paste.ubuntu.com/826108/ is what I'd like to do btw since that would have let me know about trying to use the wrong function.
<adeuring> good morning
 * wgrant declares victory over triggers.
<StevenK> wgrant: Oh, so you didn't win, you're just declaring victory?
<wgrant> I think I've ironed out the last bugs.
<wgrant> And they're not too slow.
<wgrant> And they seem to do the right thing.
<wgrant> (mapping legacy bug disclosure onto modern disclosure, and keeping it up to date across task/subscription/bug transitions and removals.
<StevenK> wgrant: Can't we just unilaterally move the legacy stuff to modern terms?
<wgrant> StevenK: Not in 20 seconds, no.
<StevenK> wgrant: Hmm. And I guess a garbo job won't help?
<wgrant> StevenK: The source data changes constantly.
<wgrant> And we need to have it consistent eventually so we can flip the switch.
<wgrant> The switch will tell the appservers to update the new schema instead, and tell the triggers to stop mirroring.
<wgrant> (although some of the triggers will remain forever, the really ugly bits are only for the migration)
<wallyworld_> wgrant: question, i have a test failure where it says httplib.HTTPSConnection does not exist, yet from the command line i can dir(httplib) and see that class is there. any ideas?
<wgrant> wallyworld_: Hm, it exists in both 2.6 and 2.7.
<wallyworld_> yes, hence mu confusion, although this error is in a canonistack instance
<wallyworld_> running oneiric
<wallyworld_> i've hand crafted some scripts to set up the instance, based on those used for aws. only a few test failures so far
<StevenK> wallyworld_: Some scripts, or changes to lib/devscripts/ec2test?
<wallyworld_> StevenK: some hand crafted python scripts to set up the instance and prepare launchpad, based on what's in devscripts
<wallyworld_> StevenK: so far, about 1/2 way through, 3 test failures due to httplib.HTTPSConnection not being found, plus
<wallyworld_> the only 2 other failures so far - one of them has output that includes a SHA512 checksum, causing the assert equals to fail https://pastebin.canonical.com/59271/
<wallyworld_> so i'm not too disappointed for a first attempt
<StevenK> wallyworld_: Nice. So perhaps the next step is to integrate your scripts into devscripts?
<wallyworld_> StevenK: that is the plan - there's a cloud instance object that i'm thinking about factoring out and making pluggable, depending on whether --aws or --canonistack is specified
<StevenK> wallyworld_: Hmmmm. I'd prefer it try canonistack first and fall back if there is no credientals or it can't start an instance.
<wallyworld_> StevenK: details, details :-) i was merely talking generally
<wallyworld_> the test run just blew up with an out of memory error, so need to arrange for a bigger instance
<StevenK> You can specify the size when you start it
 * wallyworld_ goes to find doco
<StevenK> Perhaps you should find a lack of work :-P
<StevenK> wallyworld_: You may need to ask IS about which sizes are configured, too
<wallyworld_> yeah, might call time for today. but you can't be too critical yourself :-P
<wallyworld_> i've been talking to andrew who has been most helpful
<StevenK> I'm waiting for Steam to install a game, so speak for yourself. :-P
<wgrant> wallyworld_: Is this on the private LP canonistack?
<wgrant> Or the main canonistack?
<wallyworld_> wgrant: i have no idea tbh
<wallyworld_> perhaps the private one if i had to guess
<stub> Anyone recall if there is a reason we are still using psycopg2 2.2.2?
<stub> Nope... that's not it. Seems we or Storm are breaking string quoting
<stub> >>> c.execute("SELECT %s", ("Hello\nMom",))
<stub> >>> c.fetchone()[0]
<stub> 'Hello\\nMom'
<wgrant> stub: I thought it was psycopg2 that was the problem.
<wgrant> Sure you upgraded the right one?
<stub> With raw psyocpg2
<stub> >>> cur.execute("SELECT %s", ("Raw\nPsycopg2",))
<stub> >>> cur.fetchone()[0]
<stub> 'Raw\nPsycopg2'
<stub> Works. Thought it was I had 2.4.2 installed and lp was using 2.2.2. Upgraded lp and still happening. Suspect a dodgy Storm decision in the past.
<wgrant> Sure you reran buildout etc. sufficiently?
<stub> Or maybe we broke it for some reason
<stub> Yes... psycopg2.__version__ reports what I expect
<wgrant> :(
<stub> Hmm...
<stub> So 'make harness', 'from lp.services.database.sqlbase import cursor' gives the bug
<stub> But 'make harness', 'import psycopg2; connect; cur=con.connect' etc. works
<stub> And then the cursor() helper in sqlbase gives the right answers
<wgrant> Huh
<stub> nah... mixed up my cursors.
<stub> raw psycopg2 works in make harness, cursors returned through that helper are busted.
<stub> Yay. Think I'm about to wade through connection and cursor wrappers...
<wgrant> :D
<wgrant> It's a bit of an awful mess.
<stub> oic. The 'cursor' does its own interpolation for some reason, using sqlvalues. And sqlvalues won't know about the stricter quoting I want.
<wgrant> Heh
<stub> And fixing sqlvalues should fix gobs
<stub> I guess we do that so we get sane statement logs containing interpolated values
<stub> And the root quoting is done by... sqlobject.sqlbuilder.sqlrepr
<wgrant> Which is Storm :)
<stub> Nope... looks like us in lib/sqlobject.py
<wgrant> Huh
<wgrant> Indeed
<wgrant> WTF is that still there
<stub> circa 2007
 * stub puts on his fedora
<wgrant> I thought lib/sqlobject was just importing stuff from Storm :/
<stub> I have a feeling fixing that to do strict E quoting is going to have a lot of doctest fallout...
<wgrant> We'll find out soon :)
<stub> I could still chicken out and leave it 'for later'
<rick_h> morning
<rick_h> wallyworld_: heads up, relanding the LPJS stuff so hopefully will be merged when you get going again
<mabac> I just proposed a tiny change and I haven't really pestered anyone to review it earlier. :) would anyone want to have a look at this? https://code.launchpad.net/~mabac/launchpad/login-raises-non-string/+merge/91265
* rick_h changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rick_h* | Firefighting: - | Critical bugtasks: 4*10^2
<rick_h> mabac: is this in response to a bug? Isn't there already email validation?
<mabac> rick_h, I didn't file a bug (yet). this function gives me confusing zope errors when I passed a Person to it by mistake. I figured that it might help someone else to debug tests if it would give a better error.
<mabac> rick_h, it's not related to production code btw, it's in testing/
<rick_h> mabac: do you know off hand what a "participation" is?
<rick_h> mabac: the docstring there suggests you can pass an email, a const, and a participation
<rick_h> mabac: and it appears the participation can implement IPublicationRequest so that would be some object that would fail your str test
<rick_h> bah, too early in the morning
<rick_h> that's a second param
<rick_h> sorry mabac, sending you in wrong circles this morning
<mabac> rick_h, thanks, that saved me some typing ;)
<mabac> rick_h, no problem
<rick_h> so the only concern is what the ANONYMOUS constant is, and it appears that's set to a string as well
<mabac> rick_h, yup, I think that constant is used as if it would be an email address
<mabac> rick_h, seems to be mostly (only?) used in calls to this function
<mabac> rick_h, rather these login* functions
<salgado> mabac, rick_h, we can't use 'str' there because most callsites are actually passing in unicode. so basestring, maybe?
<mabac> argh, good catch salgado. thanks
<rick_h> salgado: sounds like a good plan
<salgado> a full test run, for those who can afford it, would've caught that as well, though :)
<rick_h> salgado: yea, definitely, but still nice to get it before several hours of ec2'ing
<mabac> rick_h, salgado I'll fix that and try to survive running the tests locally again ;)
<rick_h> mabac: so noted in the MP, let me know when the change is up and I'll ok and pass it to my mentor
<mabac> rick_h, will do. thanks for you time!
<mabac> rick_h, I've pushed a new revision https://code.launchpad.net/~mabac/launchpad/login-raises-non-string/+merge/91265
<rick_h> mabac: ok, looks good thanks
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rick_h*, jcsackett | Firefighting: - | Critical bugtasks: 4*10^2
<rick_h> abentley: yea, that wiki update looks good to me. Thanks!
<abentley> rick_h: cool.
<cjohnston> Is there any sort of status on bug #881019? This is causing problems with Summit where users aren't able to retrieve their schedules and could cause them to miss private business meetings that they can only see if they are logged in properly.
<_mup_> Bug #881019: Lp login is broken after account merge <merge-deactivate> <openid> <regression> <users> <Launchpad itself:Triaged> < https://launchpad.net/bugs/881019 >
<sinzui> cjohnston, We are not working on it really.The current understanding is that the issue with offsite systems misunderstanding how OpenId works and that Lp supports multiple identifiers
<sinzui> cjohnston, You should comment on the bug to provide information about what is broken for the summit site
<cjohnston> sinzui: ty
<adeuring> rick_h: fancy a review? https://code.launchpad.net/~adeuring/launchpad/bug-829074/+merge/91302
<rick_h> adeuring: sure thing
<adeuring> thanks
<salgado> does it really take ages to run 'make newsampledata'?
<salgado> 30 minutes at 100% CPU and counting
<lifeless> well sampledata needs to diaf
<lifeless> salgado: you're not adding sample data are you ?
<lifeless> jcsackett: ola! - https://code.launchpad.net/~lifeless/loggerhead/bug-594591/+merge/91212
<lifeless> salgado: (but 30 minutes is 5-6 times too long)
<salgado> lifeless, I am!  (I probably won't commit it but I did newsampledata just so that I can restore my sampledata changes after a make schema)
<salgado> maybe there's an easier way to do that?
<salgado> lifeless, while I have your attention... I'm working on a script to migrate work items from the whiteboard of blueprints into a separate table.  it uses a fresh transaction for every BP because it rolls back if anything goes wrong.  is it worth using DBLoopTuner for that (also, we're talking about 2500 BPs that have work-items on their whiteboard)
<lifeless> salgado: (I hate my internets)
<lifeless> salgado: so, sampledata is officially reviled; the current practice is to use the factory to add test data
<lifeless> salgado: and do it per test
<lifeless> salgado: if you need the same exact test data in a number of tests, wrap it in a Fixture
<salgado> lifeless, I know that; I once gave a talk on why sampledata was bad ;)
<salgado> and that's why we now have two sets of sampledata
<lifeless> righto :)
 * lifeless wasn't sure how much you'd forgotten over in the land of django
<salgado> I'm only changing the -dev sampledata, and even then I probably won't submit those changes
<lifeless> whew ;>
<salgado> it has the ~2500 BPs from production that have work-items on their whiteboard, and I'm testing my new script against that
<salgado> and I wanted to restore those after a make schema, but I can probably avoid a make schema or dump just the one table I care about
<salgado> but anyway, I have one important question for you... :)
<salgado> <salgado> lifeless, while I have your attention... I'm working on a script to migrate work items from the whiteboard of blueprints into a separate table.  it uses a fresh transaction for every BP because it rolls back if anything goes wrong.  is it worth using DBLoopTuner for that (also, we're talking about 2500 BPs that have work-items on their whiteboard)
<lifeless> yes
<lifeless> dblooptuner is trivial and solves plenty of issues ;)
<lifeless> shove it in the garbo hourly
<lifeless> if there is no native way to show 'BP x was done' you can use memcache to store the highest migrated whiteboard (o
<salgado> oh, but we I don't think we want that as a cronjob... we should run it just once
<lifeless> salgado: so, you could manually arrange it
<lifeless> but garbo means no sysadmin intervention
<lifeless> you add it, watch the logs, remove it all without having to ask a single question
<salgado> and it shouldn't hurt to run it a few extra times, so maybe that's a good idea
<lifeless> we need a data migration specific helper I think
<lifeless> one that will ignore cluster lag, has a dedicated storage area for point-migrated-to
<salgado> yeah, that'd be nice
<lifeless> but this is orthogonal to using it or not, just would make it easier to do each time
<jml> lifeless: where's that thing you wrote about what to do instead of using an ORM?
<jml> I can see https://dev.launchpad.net/LEP/PersistenceLayer, but ISTR something with implementation notes
<rick_h> adeuring: man, you know how to build a MP phew
<adeuring> rick_h: how dow mean ;)
<rick_h> brain melted I think
<lifeless> jml: you might mean two things
<adeuring> sorry... let me know if I can help to up the mess#
<lifeless> jml: do you mean having the template service depeend wholly on services
<jml> lifeless: no, I think  I mean the other thing
<lifeless> jml: or do you mean a rethink of how appservers that do both data access and business logic would get at their data?
<jml> lifeless: that one
<lifeless> I think that LEP is what there is
<jml> hmm.
<lifeless> there was a list thread with science fiction in it
<jml> I'm sure I remember you & wallyworld talking more about it
<jml> maybe the list thread is it
 * jml looks
<lifeless> jcsackett: hi
<jml> lifeless: thanks.
<lifeless> jml: you founds it ?
<jcsackett> lifeless: hi.
<lifeless> jcsackett: still reviewing ?
<jcsackett> lifeless: all day. :-)
<lifeless> jcsackett: oh, nvm, jam got to it
 * lifeless fishslaps himself
<jcsackett> lifeless: righto. :-)
<jcsackett> you have a fish that near at hand? that's useful. :-P
<jml> lifeless: yeah, over a couple of threads.
<lifeless> no comment :P
<jml> lifeless: think my head was conflating some of the code snippets from the API thing that Foundations was doing at roughly the same time
<lifeless> yeah, some similarities
<jml> lifeless: the "Simple made easy" talk has had me thinking about what I would want to use instead of ORMs
<lifeless> aiming at similar sorts of overheads
<lifeless> jml: cool
<lifeless> e.g. scala? :)
<jml> lifeless: well, Hickey would say Clojure, I think.
<jml> lifeless: mostly I'm thinking about stuff within Python for now.
<jml> lifeless: since most of my output needs to be deployed to Canonical DC
<jml> and I'm disappointed with Go not having Haskell-like type classes. (I blame niemeyer for raising my hopes)
<jml> I've got to head out. Maybe back in 4 hrs.
<lifeless> jml: I'm underwhelmed by go fwiw
<jml> lifeless: the concurrency thing seems kind of nice
<adeuring> rick_h: thanks for the review!
<jml> lifeless: but I'd agree it's mostly a bit meh.
<jml> lifeless: if it ends up as "write code almost as easily as in Python but have it run 5x faster" then that's still pretty interesting
<lifeless> that would be interesting
<lifeless> I seem to have chosen cases that python is faster at every time so far, though
<lifeless> which may just be bad luck
<jml> heh
<jml> My SMH target solver is faster in Go :)
<jml> anyway, I really do have to go.
<lifeless> smh?
<jml> lifeless: sydney morning herald
<lifeless> shoo
<rick_h> jml: you played with pypy with it?
<rick_h> I don't seen to find a ton of CPU bound issues that make pypy awesome, but wonder if something like that would fit
<jml> rick_h: no, but my #twisted friends all love PyPy and want to marry it
 * jml gone
<salgado> lifeless, so, IIUC my ITunableLoop.__call__(chunk_size) should process up to chunk_size items in a single transaction and the loop tuner will tweak chunk_size on the next call according to the time my transaction takes. is that right?
<lifeless> yes
<salgado> lifeless, because of the way my code is structured, though, it would be more natural to process each item in a separate transaction (like http://paste.ubuntu.com/826728/), so that I can rollback if anything goes wrong when parsing the whiteboard of a given item.  that should play fine with DBLoopTuner, right?
<lifeless> I don't know why it wouldn't, though you may find you need to ensure there is an open xaction etc
<salgado> oh, right, other ITunableLoops seem to begin() a transaction when they're done processing a chunk
<lifeless> salgado: yes, the timing of chunks is to prevent impacting webapp requests
<salgado> I see
<lifeless> sinzui: is ie8 'supported' for us ?
<sinzui> :( yes. an a-level browser for YUI
<sinzui> lifeless, we have a several IE bugs too
<lifeless> so, per bugtriage I think 925154 should be critical ?
<lifeless> page-worked, now errors ?
<sinzui> lifeless, I think so, somone needs to fix the other IE bugs too. We have sat on the fence about the issue because we claim they can always use the featurewithout JS...which has not been true for a year
<lifeless> abentley: ^ a heads up - per BugTriage supported browser issues are critical
<sinzui> lifeless, Lets ask deryck and rick_h to look at them and determine if these are critical because we do not offer an alternate for IE
<abentley> lifeless: that's a supported browser?
<lifeless> abentley: per sinzui, yes - A-level
<sinzui> lifeless, this is YUI's doc on graded browser experience: http://yuilibrary.com/yui/docs/tutorials/gbs/
<abentley> lifeless, sinzui: To my knowledge, no testing was performed on IE.  I was under the impression that our support was C grade.
<sinzui> abentley, I sure that is true. I do not have windows to ever do such a test
<abentley> sinzui: A-grade for YUI does not imply A-grade for us, does it?
<rick_h> yea, we've had broken IE for a while. I filed a bug a while ago on the portlets failing in IE causing JS to stop running
<sinzui> abentley, I certainly does not, we have always said. the feature gracefully degrades. We have written a lot of JS in the last year that does not degrade...that does not even have a html-form equivalent to fall back to
<lifeless> so, we have a business rule that IE needs to work for the core functionality for OEM
<lifeless> whether we call it A grade or not is by-the-by
<sinzui> lifeless, the rule is not that simple. We heard IE6 which is very difficult to support in modern libraries. Our own browser reports indicate that IE very minute. We have not had a report from OEM in two years that IE is broken.
<lifeless> sinzui: I requested a confirmation that they still care about IE6 a few months back
<lifeless> I will send another
<lifeless> YUI still claims A for IE6, interestingly
<rick_h> hmm, i thought they announced dropping that a year ago
<rick_h> even Google apps all fail to work in IE6 any more
<rick_h> my wife's medical practice just finally got chrome this month because of it
<lifeless> maybe I am misreading that gbs page?
<lifeless> ah
<lifeless> http://www.yuiblog.com/blog/2011/07/12/gbs-update/#grades-deprecated
<lifeless> 'graded browser experience with deprecated grades'
<sinzui> rick_h, out Chinese counter-parts couldn't give a toss about what MS supports
<rick_h> http://www.yuiblog.com/blog/2011/07/12/gbs-update/
<rick_h> nvm, you found it
<rick_h> so it's no longer a/b/c
<rick_h> but "tested" with failback
 * lifeless mails stakeholders 
<rick_h> sinzui: sorry, just meant that as a "big web players" moving away from IE6
<sinzui> rick_h, right. IE was very difficult to support even when it was an A-grade browser
<rick_h> sinzui: definitely not against getting things working in IE at all. Don't want to seem that way
<sinzui> lifeless, maybe you missed rick_h's and I's exchange about JS support: https://lists.launchpad.net/launchpad-dev/msg08750.html
<sinzui> We seem to be talking it now
<sinzui> rick_h, I had a round of fixes about 6 months ago when we discovered that IE's event bubbling failed because something like YUI.Event was not being loaded for them
<rick_h> hmm, the one I hit was that the portlets load into a <tbody> which IE won't allow and throws an error so those ajax loads fail
<rick_h> sinzui: but yea, I'm sure there's a bunch of issues that'd take some time to work through
<rick_h> especially with buglistings as I don't know it's ever been IE tested
<lifeless> sinzui: I saw that yes
<sinzui> rick_h, we do not have a written doc about which browsers we support, and what happens when it is not supported.
<lifeless> sinzui: I'm a big fan of inline rendering :)
<rick_h> so I'm guessing that a landing page linked to Chrome Frame isn't going to fly? :)
<lifeless> we might get away with chrome frame activeX control
<lifeless> if the factories can use it
<lifeless> sinzui: I probably got all the facts wrong; please correct my mail if so :)
<sinzui> okay
<abentley> sinzui: What do we do when one of our upstreams asks for their project to be deleted? https://answers.launchpad.net/launchpad/+question/185361
<abentley> sinzui: nm, I see you're already on it.
<sinzui> We deactivate if it is not being used by other communities. this one is. It is used by Ubuntu and the request is disputed. I did what I could by disabling answers and bugs
<sinzui> ^ abentley
<sinzui> The question answer I gave was final
<rick_h> lifeless: so if we go the route of the U1 response with full graded support, is there any chance we'd be able to grab some sort of test bed for tests or QA of these?
<rick_h> lifeless: sinzui at least running the js test .html files via something like webdriver?
 * rick_h has been secretly looking to do something with just FF and Chrome, but IE gives a bigger excuse
<sinzui> rick_h, We have talks about browser shots and a selenium test suite in the past.
<rick_h> sinzui: yea, I've assumed so, I don't know the history so forgive repeat questions
<sinzui> rick_h, our YUI tests are webkit because gecko is a bitch to compile and keep patched
<sinzui> rick_h, note the irony in the webkit selection; it does not provide the JS engine used by firefox and chromium users
<cjohnston> /wc/48
<rick_h> chromium is webkit base at least, but yes. What I meant was I was trying to tinker with things like yeti and sst
<rick_h> things that fire up real browsers
<sinzui> oh yuck. I ran away from that level of testing. I do not disagree with it. I just think I should not be writing those tests are maintaining the infrastructure. I use libraries and standards as my guide to writing yui tests
<rick_h> sinzui: definitely, but I know in buglisting we hit issues between FF and chrome alone and I was trying to think of a way to run just the JS tests in both.
<sinzui> yes. I saw some comment about chromium oddities in the tests.
<rick_h> it's something I'll continue to try to get running locally, but wanted to bring it up
<lifeless> so jenkins + grid + browser tests yes
<lifeless> or whatever - that sort of conceptual setup
<lifeless> james_w: I've now chatted with mthaddon, and the consensus is to go with one shared oops-tools instance
<lifeless> james_w: he is going to run it past james first
<james_w> lifeless, ok, what were the reasons OOI?
<lifeless> james_w: user/dev perspective: single shared service, no need to figure out which service instance a particular oops-id belongs too
<lifeless> james_w: ops perspective - one instance to care for and feed; consumers can easily split out oopses on disk so resourcing can be partitioned off per-department if needed
<lifeless> james_w: dev perspective - less instances to run around upgrading when there are security issues or whatnots
<james_w> ok
<james_w> we unfortunately have rather a long deployment pipeline before we can send the oopses anyway, but at least this probably shortens it a bit
<lifeless> The mild overhead of going multitenant was an already expected cost as LP gets more SOAised
<lifeless> ssltunnel to rabbit should let you start pretty quickly
<james_w> it's not that
<lifeless> oh, ok :)
<james_w> there's branches queued up, but it needs code deployes
<james_w> and packages in to CAT in co-ordination
<lifeless> ah
<james_w> then settings updates via puppet to turn it on
<abentley> lifeless: could you explain what you mean about the script being misconfigured?
<abentley> lifeless: Is it the fact that you're forcing the logs to INFO?  IMO, that's a stopgap, because the oops-id and message-id still aren't being logged at the same level as the error that they correspond to.
<lifeless> abentley: the script was running with stdout/stderr capturing rather than with a --log-file=INFO:/... parameter
<abentley> lifeless: Why include the -q parameter? is that for stdout/stderr?
<lifeless> yes
<abentley> lifeless: So the information that gets logged to stdout/stderr will still be deficient.
<lifeless> abentley: it won't log anything to stdout/stderr
<abentley> lifeless: Okay, so why include the -q parameter?
<lifeless> so that it doesn't
<lifeless> uhm, I don't mean this to be like playing 20 questions
<abentley> lifeless: AIUI, the -q parameter prevents stdout/stderr from emitting INFO messages.
<lifeless> abentley: yes; the goals for the setup are:
<lifeless>  - we log direct to a file anything we want to log
<lifeless>  - WARNING and above messages generate oopses for aggregation and analysis
<lifeless>  - stdout/stderr are empty except when the script runner itself catastrophically fails (and we then get immediate notification on lp-error-reports)
<lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=20e752ffc3566d6bee8c71afcadaa5a7 is an example of the oopses we get
<lifeless> which seems to have a decent backtrace
<abentley> lifeless: That all sounds good, though I'm not sure we really want to be logging at INFO level.
<abentley> lifeless: Not with our volume.
<lifeless> abentley: we can push less common stuff down to DEBUG
<lifeless> abentley: I think, given that email has no guarantee of showing the user, that we probably do want to capture the messageid and oopsid every time.
<abentley> lifeless: Yes, I can agree with that.
<lifeless> we log what, 8M web requests a day, on apache + on the zope access logs, and email is a tiny % of that
<lifeless> so we could be quite fat and it wouldn't be an issue
<lifeless> thats not a reason to log more (or less) just a data point from the ops aspect
<abentley> lifeless: It still seems wacky *not* to emit the oops-id and message-id at error level, since we do want to know that about errors.
<lifeless> the problem is how to notify @ 'ERROR' when notifying @ 'ERROR' triggers an OOPS
<lifeless> in regular logging parlance, the use of different levels is to permit filtering of output
<abentley> lifeless: You stick it in the error that we're already emitting.
<lifeless> abentley: how? that error is what becomes the oops - it shouldn't be getting written to the log file at all
<abentley> lifeless: The message-id, I mean.  When the ERROR->OOPS handling is in place, the oops-id automatically gets logged at ERROR level, no?
<lifeless> abentley: no, the oops-id generally isn't logged at all
<lifeless> abentley: (because most of our scripts have no concept of UI - we find out via the oops reports)
<lifeless> abentley: process-mail seems to do a lot of special handling that makes this worse than for other scripts
<abentley> lifeless: Jobs that use the standard runner log their oops ids.
<abentley> lifeless: I'm not sure how "concept of UI" relates to logging.
<abentley> lifeless: I never read the oops reports, and when I get a bug report, I hit the logs to try and find out what happened.
<lifeless> abentley: so the job runner does it's own generation and reporting - it doesn't depend on error behaivour
<lifeless> abentley: the jobrunner reports oops ids at INFO
<abentley> lifeless: true, true.
<abentley> lifeless: I was just giving an example that contradicts "the oops-id generally isn't logged at all"
<lifeless> ah right
<lifeless> so, the logging OopsHandler
<lifeless> exists to ensure we capture the error for the reports
<lifeless> which are (currently) our primary signal for the health of the system in advance of user initiated reports
<lifeless> I'm not sure if it is possible to emit a logging message from a logging handler, but if it is, logging the oops id at info would match what our twisted equivalent, and the job runner equivalent, do.
<abentley> lifeless: I would imagine the logging OopsHandler could also append it to the message.
<abentley> lifeless: Though that runs the risk of losing the whole thing if oops handling fails.
<lifeless> abentley: the oops config is built with a couple of fallbacks, but yes that is a risk
<StevenK> wgrant: Oh, how should that query change?
<wgrant> StevenK: It should change to not return a list of people, but existence of a matching row for a particular person.
<StevenK> WHERE cs.date_expires < NOW() AND u.id = self.user (effectively) ?
<wgrant> Something like that.
<StevenK> And drop the distinct, hand wave, hand wave
<lifeless> ooh pub holiday monday \o/
<StevenK> What's the occasion?
<lifeless> waitangi
<StevenK> lifeless: Have you yelled at your ISP today?
<lifeless> not yet
<lifeless> our ajax detection log has broken :(
#launchpad-dev 2012-02-03
<lifeless> and I get a Bad Request trying to edit the title of https://bugs.launchpad.net/launchpad/+bug/925791
<_mup_> Bug #925791: OOPS-24bbc670994b55b2e26d848fce30c554 trying to update bug parameters <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/925791 >
 * lifeless twitches
<lifeless> StevenK: can you try editing a bug title ?
<lifeless> oh, nvm I had a CR in the field
<lifeless> odd but not major
<rick_h> I think there's a bug about something like that lifeless
 * StevenK prods wallyworld to update the topic.
<lifeless> rick_h: probably ;)
<rick_h> of course now I can't find it
<StevenK> rick_h: The thought of rsync makes me sad :-(
<rick_h> StevenK: it does me as well
<lifeless> rsync ?
 * wallyworld will as soon as he lands his branch
<rick_h> sorry, forgot that wasn't on the mailing list
<StevenK> lifeless: So, I changed the convoy root dir to be inside the tree, like icing
* wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Firefighting: - | Critical bugtasks: 4*10^2
<rick_h> lifeless: give me a sec to get a summary between StevenK's email and my response
 * StevenK goes back to his branch, leaving rick_h to explain
<StevenK> (Sorry, it *has* to be done today)
<rick_h> lifeless: https://pastebin.canonical.com/59345/
<rick_h> lifeless: I wanted to get with deryck on it today, but he left early sick so we didn't get a chance to talk
<lifeless> StevenK: is /var/tmp a temp dir? I thought it was an lp spethial
<wgrant> /var/tmp is in the FHS
<StevenK> lifeless: And is 1777, so yes
<wgrant> It's more persistent than /tmp
<rick_h> lifeless: oh and this was the bug I was thinking of, not the right bug: https://bugs.launchpad.net/launchpad/+bug/703061
<_mup_> Bug #703061: Tags edit with syntax error makes further tag editing impossible <lp-bugs> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/703061 >
<wgrant> ie. not a tmpfs
 * StevenK tries to remember how to check if a feature flag is turned on
<rick_h> StevenK: /+feature-rules I think
<StevenK> In code :-P
<rick_h> oh, heh
<rick_h> StevenK: well check the app/templates/layout-macros since it's got checks there
<huwshimi> StevenK: lp.services.features.getFeatureFlag(name)
<StevenK> Ah!
<StevenK> I thought it was get_
<lifeless> huwshimi: hi; remember that cool ajax log you wrote ?
<lifeless> huwshimi: it seems to not be seeing ajax requests anymore for me (on FF in precise)
<rick_h> lifeless: that could be the broken JS due to localizing events that my branch landing today shold hopefully fix
<rick_h> if it's not fixed after that lands let me know
<lifeless> kk
<huwshimi> lifeless: Yeah, killed by the non global attachement of the io event, I guess
<lifeless> ok cool
<wgrant> Would be fixed on prod by now if buildbot hadn't lost its mind.
 * StevenK shakes his fist at buildbot more.
<rick_h> lifeless: wgrant appreciate any thoughts on the JS/build location fun there in the pastebin
<wgrant> You're going to regret that.
<lifeless> why won't the owner match?
<rick_h> *yawn* getting sleepy... /me runs to bed
<StevenK> lifeless: The symlink is created by me.
<rick_h> lifeless: because on your dev system make run is performed as you while apache is run as root
<StevenK> Apache does NOT run as root
<lifeless> we have the same split on prod etc
<StevenK> It runs as www-data
<rick_h> well www-data I guess
<lifeless> so why would it work on prod etc
<rick_h> sorry sorry
<StevenK> lifeless: Because the symlink won't be in a temp dir
<lifeless> righto
<lifeless> so, to me the obvious thing is 'wth are we putting this in a temp dir'
<lifeless> /srv/launchpad.dev/convoy
<StevenK> So we don't need root and the need to use sudo in our Makefile
<lifeless> make that owned by stevenk
<rick_h> lifeless: because we have to tell the apache .wsgi file for convoy where it's root directory it serves out of is.
<lifeless> rick_h: thats a constraint, but not a reason for that specific directory
<rick_h> lifeless: so we want that to be a constant spot, but still allow you to switch branches/etc in dev without breaking/relinking things
<rick_h> lifeless: true, just describing what led to where we are
<lifeless> rick_h: still with you, still don't see why that specific directory.
<lifeless> we need root to do the one-time setup
<lifeless> sites-enabled, bzr rewriter configuration, wsgi config addition to apache.
<lifeless> making and chowning /srv/launchpad.dev/convoy at the same time seems pretty straight forward, or am I missing something?
<StevenK> So that's 'sudo make copy-apache-config'
<StevenK> I'm a bit loath to have that do, well, more than that
<rick_h> lifeless: right, but after we make /srv/launchpad.dev/convoy, apache is serving the files in there as www-data while the symlink you create as the dev will be owned by your user
<lifeless> rick_h: but it won't be marked 1777 so who cares
<rick_h> lifeless: ah ic
 * StevenK sees
<rick_h> wallyworld: ping, the second question in that MP was less about the . in the ids, but that the code you wrote uses Y.Dom.getById while the code in the tests uses Y.one('[name=]')
<rick_h> wallyworld: so one code is finding html elements by ids, while the tests are searching for elements with a name attribute, so they're testing different things
<rick_h> wallyworld: e.g. tests could pass with html that would fail the production code
<wallyworld> rick_h: ah, right. what zope does is spit out elements with id = name
<StevenK> Success
<rick_h> wallyworld: right, I know it works and all, but just struck me as the tests html is manually generated/etc
<rick_h> wallyworld: anyway, just wanted to clear up the question wasn't about the periods, but the matching methods
<wallyworld> rick_h: np. thanks. i'll look at it since there's still a couple more branches to go yet
<lifeless> wgrant: https://lp-oops.canonical.com/oops.py/?oopsid=9040bdec04b696e8fd0c80de3462cca5 may make you laugh maniacally
<StevenK> lifeless: It works with /srv/launchpad.dev
<rick_h> StevenK: yay!
<rick_h> StevenK: one step closer to domination
<lifeless> StevenK: wicked :)
<StevenK> Let me get this other branch put to bed, and I'll fix up combo-url
<wgrant> lifeless: Heh
<wgrant> lifeless: Handy
<wgrant> Speaking of loggerhead, it's very tempting to halve our exception count by fixing one of its bugs.
<StevenK> Just one?
<wgrant> Yes.
<wgrant> Hm
<wgrant> Why has the theme changed
<lifeless> wgrant: I'm going to do a release today. release today. release today.
<wgrant> Context menus etc. are light grey now :(
<lifeless> wgrant: in lh ?
<huwshimi> wgrant: Yeah, some of the theme stuff got fixed, I think a few things broke too
<lifeless> wgrant: fixing that exception would be pretty awesome
<lifeless> actually, I'm going to upgrade our revision. Check its copacetic on qastaging and then release on tuesday.
<StevenK> WCPGW
<lifeless> E-WHUT?
<StevenK> What Could Possibly Go Wrong
<lifeless> with what I'm doing? We might have to rollback a rev if trunk is buggered somehow. Thats about all.
<StevenK> lifeless: I know. YHBT, HTH, HAND
 * StevenK tries to figure out how to add a commercial subscription
<lifeless> <- was sick, now just sleep deprived
<StevenK> Welcome to fatherhood
<wgrant> StevenK: I think that's the only LP action I've never performed.
<StevenK> wgrant: I mean in a test, anyway
<StevenK> Tempted to just store.execute() and be evil
<wgrant> Hm
<wgrant> lifeless: How do I run loggerhead?
<wgrant> serve-branches just 404s
<wgrant> Do I have to symlink it into by bzr plugins path?
<lifeless> wgrant: you can use file://$(pwd)
<lifeless> wgrant: its getting a base url of readonly+path-you-gave-it
<lifeless> which doesn't trigger the readonly decorator for some odd reason, I think a bzr change
<lifeless> so you end up using $(pwd)/readonly+pathyougaveit
<lifeless> which fails humourously
<wgrant> lifeless: Ahh
<wgrant> Thanks.
<wgrant> I was just giving it a path, not a URL
<lifeless> you are meant to be able to
<lifeless> its a change :P
<wgrant> I certainly used to be able to.
<wgrant> Right
<lifeless> ah, mwhudson sucks
<lifeless> he fixed three bugs and didn't upgrade us
<StevenK> Haha
<nigelb> Mornin'
<wgrant> Good lord
<wgrant> Do not edit loggerhead with pocket-lint vim integration.
<wgrant> The red will make your eyes melt
<nigelb> heh
<StevenK> Haha
<wgrant> Now to extend Loggerhead's exemplary test suite to cover my fix.
<wgrant> *cough*
<lifeless> wgrant: do you want me to wait on  https://code.launchpad.net/~lifeless/launchpad/loggerhead/+merge/91379 ?
<wgrant> lifeless: Might as well, it's a trivial try/except/raise NotFound
<wgrant> Just going to see if I can be bothered writing a test.
<wgrant> lifeless: This fixes exceptions #1 and #3 for the last 9 months, so might as well wait a few minutes :)
<lifeless> who wants to be the one to flip the switch on heat on monday?
<wgrant> me me me
<StevenK> Haha
<lifeless> wgrant: ok, please do
<lifeless> wgrant: I will be doing $notwork
<wgrant> !
<wgrant> Oh, right, public holiday.
<StevenK> Skyrim!
<StevenK> X3!
<StevenK> All of the above!
<lifeless> x3:ap probably
<nigelb> another horse race?
<lifeless> that and house work
<wgrant> What's AP?
<wgrant> Is that the one after TC?
<lifeless> albion prelude
<lifeless> tc engine, terrans at war with argon
<wgrant> Ah
<StevenK> nigelb: No, the New Zealand people signed a treaty. Apparently, this is worth a day off
<nigelb> StevenK: wow.
<StevenK> Said treaty was signed in 18xx
<nigelb> To be fair, it sounds better than a holiday for a horse race :P
 * nigelb ducks
<wgrant> lifeless: https://code.launchpad.net/~wgrant/loggerhead/bug-728209/+merge/91383
<wgrant> lifeless: Hm
<wgrant> lifeless: I wonder if we want to drop heat from the default listings.
<lifeless> perhaps, but orthogonal
<lifeless> they won't change all that much even without aging because comments reset sging
<wgrant> True
<wgrant> lifeless: So, can has review, or should I throw it at wallyworld?
<wgrant> lifeless: Was that a +1 without a +1?
 * wallyworld taps fingers waiting
<wgrant> Hah
<wgrant> Thanks.
<lifeless> handoffs cost :P so I've done it
<StevenK> nigelb: Only Melbourne gets the public holiday for Melbourne Cup Day
<StevenK> nigelb: The rest of the country have to work, but not much gets done
<lifeless> the rest of the country just fakes it
<lifeless> tis with ec2
<nigelb> StevenK: Wait, I thought you lived in Melbourne.
<wgrant> Nah, only I'm in Melbourne.
<wgrant> Everyone else is Sydney or Hobart.
<wgrant> jamesh and wallyworld don't exist.
<StevenK> Bwahaha
 * wallyworld goes to hospital to get wife
<nigelb> heh
<StevenK> AttributeError: type object 'Product' has no attribute 'owner_id' :-(
<wgrant> owneriD
<wgrant> ID
<StevenK> That doesn't work either
<wgrant> !doesn't work
<StevenK> AttributeError: type object 'Product' has no attribute 'ownerID'
<wgrant> StevenK: _ownerID
<wgrant> owner is a property
<StevenK> Bah
<lifeless> wgrant: is 1043 /  485  MaloneApplication:+bugs what you were expecting?
<wgrant> lifeless: That's more like it.
<lifeless> wgrant: whats up with 'unable to find source package foo in suite'
<wgrant> lifeless: It means the build's source is no longer active.
<wgrant> ie. it's superseded or deleted
<lifeless> why is it an oops?
<wgrant> Because nobody has fixed it.
<wgrant> Because it's not clear how best to fix it.
<lifeless> wgrant: what is there to fix?
<lifeless> bbiab
<StevenK> TypeError: Expected datetime, found (datetime.datetime(2012, 3, 4, 9, 15, 45, 96703),)
<wgrant> StevenK: tuple != datetime
<StevenK> Yes
<StevenK> I found the one-char bug :-(
<StevenK> wallyworld: But whereas I previously held for Java a cordial dislike borne of having only a cursory notion of how it worked, now my dislike for the language can no longer be called at all "cordial", for familiarity has bred contempt. -- Tom Christiansen
<wallyworld> why?
<StevenK> Why what?
<wallyworld> what made you have even more contempt?
<StevenK> It isn't my quote
<wallyworld> oh, ok. i thought you were using the quote to communicate your own revelation
<StevenK> Nah, just teasing your like of Java
<wallyworld> s/like/not blind hatred
<StevenK> s/like/respect/ ?
<wallyworld> perhaps. it's done a fine job for 16 or so years
<wallyworld> in the enterprise space
<wallyworld> client not so much
<wgrant> $ ls -lh ~/.cache/checkbox/checkbox.log
<wgrant> -rw-rw-r-- 1 wgrant wgrant 50G Oct 15 17:02 /home/wgrant/.cache/checkbox/checkbox.log
<wgrant> The first and the final lines are 21 hours apart.
<StevenK> Impressive
<StevenK> wallyworld: O hai
 * wgrant considers rejecting on the basis that the description matches /empower/.
<StevenK> Bah
<StevenK> wgrant: Would you mind reviewing it since wallyworld seems to be afk?
<lifeless> wgrant or StevenK - could you please land my loggerhead branch? I'm suffering the lp-land breakage abently is fixing
<StevenK> lifeless: Link me
<wgrant> I'm knee-deep in a few hundred lines of PL/pgSQL and bug search code and appserver logs, so I'd prefer not.
<StevenK> lifeless: If it's updating the revno, I can JFDI
<StevenK> wgrant: Okay
<lifeless> its a tiny bit more
<StevenK> lifeless: Then link me
<lifeless> StevenK: https://code.launchpad.net/~lifeless/launchpad/loggerhead/+merge/91379
<StevenK> export tarballs false? Why?
<lifeless> new feature
<lifeless> unknown overheads
<lifeless> don't know if it would cripple us, or be totally fine
<lifeless> so being conservative
<StevenK> Oh, so it doesn't currently exist?
<lifeless> right
<StevenK> Objection withdrawn, landing
<lifeless> I think; let me triple check
<lifeless> nope, I'm wrong, we were on 461, which added that
<wgrant> lifeless: Is postgres smart enough to walk backwards from the end of a segment of a composite index?
<lifeless> but, I am moderately sure I intended for it to be turned off :P
<StevenK> lifeless: But it might be being used
<lifeless> StevenK: I'll delete that hunk, one sec
<wgrant> ie. if I have an index on (foo, bar, baz), filter on (foo, bar), and order by -baz, will it use the index sensibly?
<lifeless> wgrant: pretty sure it won't. If you order by -foo -bar -baz, then yes
<lifeless> StevenK: pushed
<StevenK> lifeless: Thanks
<StevenK> lifeless: ec2 is pointless?
<lifeless> FSVO
<lifeless> put it this way, if it breaks, tell me on tuesday :)
<StevenK> lifeless: For that branch. I can toss it through ec2 if you wish
<lifeless> its probably safer
<lifeless> I don't -expect- surprises, but then, who does?
 * StevenK wonders where wallyworld has gotten to.
<huwshimi> StevenK: (13:00:57) wallyworld: *goes to hospital to get wife*
<StevenK> But he spoke at 3pm
<huwshimi> StevenK: Oh, that's true
<wallyworld> StevenK: was picking up kid from school
<StevenK> wallyworld: He can walk home
<StevenK> :-P
<wallyworld> still need a review?
<StevenK> wallyworld: Please
<wallyworld> looking now
<StevenK> wallyworld: https://code.launchpad.net/~stevenk/launchpad/show-visibility-teamadd/+merge/91389 that one
<StevenK> wallyworld: combo-url can be done by rick_h
<wallyworld> sounds good to me :-)
<wallyworld> StevenK: btw - Total: 17029 tests, 5 failures, 0 errors in 210 minutes 43.985 seconds.
<StevenK> Nice, it's a smidge faster than ec2
<wallyworld> 3 of the failures were mailmain, 1 was due to oneiric, not sure about the other
<StevenK> We don't run Mailman tests
<wallyworld> this one was the one that failed: lp.services.mailman.tests.test_mlist_sync.TestMListSync
<wallyworld> so we don't run that one?
<StevenK> Let me check
<wallyworld> StevenK: what's the difference between launchpad.Commercial permission and "current commercial subscription"?
<wgrant> We clearly run it, or it wouldn't have run :)
<wgrant> We don't run MailmanLayer
<StevenK> wallyworld: launchpad.Commercial == commercial admin
<wallyworld> ok, so like curtis etc
<StevenK> wallyworld: "current commercial subscription" == have paid monies to us
<wallyworld> StevenK: you'd have thought that folks who paid money would have had this feature already
<StevenK> steven@liquified:~% zcat Desktop/ttb-no-chroot-r14741.subunit.gz | subunit-ls | grep -c TestMListSync
<StevenK> 3
<StevenK> wallyworld: They can ask for it, like Curtis said
<wallyworld> StevenK: yep, those 3 tests all fail, probably same root cause
<StevenK> So, they can already have it, but it isn't self-service.
<StevenK> wallyworld: Right
<wallyworld> right. pretty sucky though
<StevenK> That's why we're fixing it!
<wgrant> wallyworld: Yes, this is what I've been complaining about.
<wgrant> Someone implemented an overly-restricted checkbox in 2007, unrelatedly implemented commercial subscriptions, and then said "lol, we have a commercial offering"
<wallyworld> i'm pretty embarrassed we charge people money, for not much it seems
<wgrant> Precisely.
<wgrant> I've long maintained that we should have discontinued the commercial offering years ago :)
<wallyworld> yeah, can see why
<wallyworld> StevenK: the logic in conditionallyOmitVisibility(self):... imho it needs a bit of love, and we should only type "self.form_fields = self.form_fields.omit('visibility')" once
<wallyworld> in the method
<wallyworld> StevenK: i'm not sure how the logic changes allow normal admins to see the field whereas before they didn't. perhaps extend the code comments to say how?
<StevenK> wallyworld: Like so http://pastebin.ubuntu.com/827310/
<StevenK> wallyworld: Before they could, there are other tests for that
<wgrant> dammit postgres, it's not that hard to vacuum a 50000 row uncontended table :/
<StevenK> admins have launchpad.Commercial too
<wallyworld> StevenK: ok. the pastebin look better thanks. do we need "return None" or just "return"? just return would suffice?
<StevenK> wallyworld: Right, fixed too
<wallyworld> StevenK: thanks. my only other comment is a personal preference - i would have used a helper method "hasCurrentCommercialSubscription(person)" to get the storm stuff out of the main method and make it a lot cleaner
<wallyworld> perhaps there's already a helper method like that
<StevenK> I doubt it
<wallyworld> hmmm. i would have thought there would be several places where we would need to know that
<wallyworld> maybe even add the method to IPerson
<wgrant> There *should* be.
<wgrant> But this is the first.
<wallyworld> so we should set things up "properly" perhaps - add the method to IPerson?
<wgrant> Yep
<StevenK> I can move it to IPerson
<StevenK> Then you'll want more tests
<wallyworld> cool. that would be peachy. thanks
<wallyworld> yeah, sorry. just one or two
 * StevenK kicks wallyworld 
<wallyworld> ouch
<wallyworld> be back in a sec, wife wants something
<wgrant> wtf postgres
<wallyworld> what has it done now?
<wgrant> slow vacuum
<wallyworld> maybe it needs to use a Dyson
<wallyworld> wgrant: could you do me a favour and lp-land this? a single test failed ec2 which i fixed by editing the test. lp:~wallyworld/launchpad/confirm-reviewer-subscription-330290
<wallyworld> lpland still broken on precise for me
 * StevenK grumbles at that
 * StevenK kicks wallyworld again
<wallyworld> ouch
<stub> I can land it if wgrant isn't on it
<wgrant> stub: How close it 9.1?
<wgrant> s/it/is/
<wgrant> Hah, nice timing.
<wallyworld> thanks stub
<stub> 28 failures, 25 errors
<stub> And a lot of that is probably due to using E style quoting if we want to push it through faster
<stub> AttributeError: 'Entry' object has no attribute 'source_branch'
<stub> yay
<stub> lp-land seems pretty broken without the branch existing locally
<StevenK> Yes
<stub> wallyworld: its with pqm now
<stub> https://pqm.launchpad.net/ is showing some odd errors - new?
<stub> bzr: ERROR: no such option: -0
<wgrant> It's done that since I changed the regexps a year ago.
<wgrant> Not sufficiently harmful that I've found time to fix it.
<StevenK> wallyworld: Diff updated.
 * wallyworld looks
<stub> Rather than fix it, I'm going to nuke the mockdb stuff which failed.
<StevenK> stub: That sounds like an excellent plan.
<wallyworld> StevenK: me like. you could now use an "and" in your if condition in conditionallyOmitVisibility()
<StevenK> wallyworld: Where?
<StevenK> Oh, if getFF and if hasCurr
<wallyworld> 50	+ if getFeatureFlag(
<wallyworld> 51	+ 'disclosure.show_visibility_for_team_add.enabled'):
<wallyworld> 52	+ if self.user.hasCurrentCommercialSubscription():
<wallyworld> 53	+ return
<StevenK> wallyworld: Not much point, it's +3/-3
<wallyworld> sure, but it reads much better. anyways, your choice
<StevenK>         if getFeatureFlag(
<StevenK>             'disclosure.show_visibility_for_team_add.enabled') and
<StevenK>             self.user.hasCurrentCommercialSubscription():
<StevenK>             return
<StevenK> But doesn't
<wallyworld> i would write it as: f_flag = getFeatureFlag('xxxx')
<wallyworld> if f_flag and self.user.hasCommercialSubsction():
<wallyworld> ....
<StevenK> wallyworld: Pushing
<wallyworld> thanks, already approved :-)
<StevenK> wallyworld: But thanks for the +1, I'll toss it at ec2
 * StevenK cackles at the register
<StevenK> "iPhoners are the most likely to date a co-worker, with nearly a quarter saying they had an office fling in the past five years, perhaps because they all work in graphic design and don't have any real work to do."
<stub> http://ahbahb.com/TH/shop/typography-collection/ahbtypo03-m.html
* wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2
<adeuring> good morning
<nigelb> wallyworld__: http://www.youtube.com/watch?v=2V9-g8JuBZc
<nigelb> Other YUI frontend people might love this ^
<nigelb> rick_h: ^^
<wallyworld__> nigelb: let me take a look
<wallyworld__> good sense of humour he has :-)
<nigelb> heh
<rick_h> nigelb: yea, saw that. Funny stuff
<jelmer> hi launchpadders
<rick_h> howdy jelmer
<nigelb> rick_h: heh
<nigelb> O hai jelmer
<StevenK> rick_h: So, you can review combo-url at some point?
<lifeless> adeuring: I found an OOPS for bug 925937 in yesterdays oops report
<_mup_> Bug #925937: Does this bug affect you: Timeout error popup <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/925937 >
<adeuring> lifeless: cool, thanks!
<lifeless> adeuring: looks like classic death by many queries and/or sending mail - at a first glance
<rick_h> StevenK: is there a branch for that then?
<lifeless> adeuring: np
 * rick_h must have missed it
<adeuring> lifeless: can you add the OOPS ID to the bug report?
<lifeless> adeuring: I have
<adeuring> lifeless: gah, i looked only at comments...
<lifeless> :P
<rick_h> StevenK: nvm, found it. Forgot that branch was around still
<StevenK> rick_h: It should be good to land, and shouldn't impact qastaging and so on
<rick_h> StevenK: cool, I'm pulling it to try it out and will update and try to get jcsackett to ok today then
<StevenK> rick_h: Okay -- if there isn't any problems, hoping to land on Monday morning
<rick_h> StevenK: would be awesome and I can move this test rewrite forward with the build files in place
<rick_h> StevenK: now this is using the older convoy version right? where it ignores the path?
<rick_h> StevenK: did you ever get a chance to verify what the $revno was in dev mode?
<StevenK> rick_h: It is the current revno of the branch
<StevenK> But it doesn't impact on devmode
<rick_h> StevenK: even in dev mode? I thought someone thought it was 'unkonwn' or something
<StevenK> Yes, even in devmode.
<rick_h> StevenK: so when I first run this I get an error that ln: creating symbolic link `/srv/launchpad.dev/convoy': No such file or directory
<rick_h> should it create the directory for me or is that my duty as dev?
<StevenK> rick_h: Right, so you need to do two things -- you need run 'sudo make copy-apache-config' which will create the dir for you, and you probably need to hack /usr/share/convoy/convoy.wsgi to point to it and reload apache.
<StevenK> It's a bit rough, I'll be updating convoy on Monday.
<StevenK> I may guard that ln to not bite people
<rick_h> StevenK: yea cool
<StevenK> Actually, guarding that ln would probably work
<rick_h> StevenK: so just for the review, want to make sure that the make file won't be a problem landing this out since that stops make?
<StevenK> rick_h: Right, so 'inplace' does not get run on qastaging and so on, and I just want the usual review for the rest of it since there are a large number of changes since the previous MP
<rick_h> StevenK: ok, yea sorry I just want to make sure.
<StevenK> rick_h: I think my plan of having devs needing to run 'sudo make copy-apache-config' once is a sane one, since the /+combo stuff will need to be there before they can enable the FF locally anyway
<rick_h> StevenK: yea, while it's a FF thing I think that's fine personally
<rick_h> And we can update the live sites that serve convoy to do that so that non-devs can use it on the live site then
<StevenK> rick_h: Right. One concern I have is I'm not sure how to inject CONVOY_ROOT into apache's environment. But that is only a deployment issue for qastaging/staging
<StevenK> And I was planning on RTFMing on Monday
<rick_h> StevenK: can we just do that at copy-apache-config?
<rick_h> sed the file as it's written?
<StevenK> qastaging doesn't use that make file target, and it should not
<rick_h> ok
<StevenK> Like I say, it's a deployment problem, it does not impact this branch
<rick_h> StevenK: ah ic, so we just use a different url in the dev mode combo_url property.
<StevenK> Eh?
<StevenK> Oh, right. Yes.
<StevenK> We don't care about revnos on dev
<rick_h> StevenK: just going over the MP and understanding why "it doesn't matter" what the revno is in dev mode
<rick_h> Sorry, early in the morning, slowly winding up :)
 * StevenK sticks rick_h with a caffeine IV.
<nigelb> lol
<rick_h> I need one, out of Dr Pepper this morning. Might need a run to the coffee shop
<rick_h> Damn Fridays, kitchen gets empty
<StevenK> nigelb: BAH
<StevenK> nigelb: BAH
<StevenK> nigelb: BAH
<nigelb> StevenK, what?
<StevenK> Guess.
<nigelb> cricket not going well?
<StevenK> Cricket finished
<nigelb> OMG
<nigelb> EPICWIN
<nigelb> muhahahaha
<nigelb> Finally!
 * StevenK stuffs nigelb out of an airlock
<rick_h> nigelb is a cricket fan as well?
<rick_h> man, who knew that was a real game people played? :P
<nigelb> As much as StevenK.
<nigelb> We both actually hate the game, but like it when our respective countries beat each other.
<rick_h> StevenK: so how does libapache2_modwsgi fit into this then?
<bigjools> rick_h: there's a load of Brits, Aussies and Indians around. There will be cricket fans :)
<rick_h> StevenK: that's another manual step right? Or can copy-apache-config check/install that?
<nigelb> bigjools has a valid point.
<rick_h> bigjools: yea, I'm getting an education. In the US it's just something we see in the occassional movie poking fun at the aristocracy kind of thing
<StevenK> rick_h: libapache2-mod-wsgi is still manual step
<StevenK> rick_h: I think I'm okay with that *for now*
<rick_h> StevenK: ok, cool. Just wanting to get the notes together so that as this moves forward we can have it documented or something
<bigjools> rick_h: I can't think why it's linked with aristocracy. I think you need to go to a game some time :)
<StevenK> rick_h: Documentation? What does that word mean?
<rick_h> bigjools: yea, I'll have to find out if it's legal in the US and see what's up.
<rick_h> StevenK: :) I'm going to have to tell deryck how to turn it on at some point
<StevenK> Three steps, which I was planning on announcing to -dev, once that branch lands
<rick_h> StevenK: ok, approved with the note on the ln command blowing up
<rick_h> StevenK: I'll poke jcsackett when he's around later this morning so you should be golden for Monday hopefully
<StevenK> Yeah, I think I will guard that ln just so I don't catch anyone out
<rick_h> Yea, if you're not using the combo loader it should be invisible I think
<StevenK> Right
<rick_h> Thanks for working on it!
<StevenK> if [ -d /srv/launchpad.dev ]; then ln ... ; fi
 * rick_h is finally starting to see that this might actually work in the near future
<StevenK> rick_h: And then qas is waiting for the RT
<StevenK> But this branch must come first
<rick_h> StevenK: ok cool. Well, once we're actually ready maybe we can ping someone or something
<rick_h> StevenK: right, this opens up me getting tests fixed, and running locally to start fixing bugs/issues
<StevenK> Get going, then. :-)
<rick_h> heh, lifeless did we come to any conclusion on the browser front?
<rick_h> lifeless: should I bring up IE8 testing/fixing to deryck on our stand up today?
<nigelb> StevenK: heh, "Finally India" is trending on twitter in India :P
<StevenK> nigelb: I would have expected "About *bloody* time MS Dhoni!"
<nigelb> haha
* bac__ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac | Firefighting: - | Critical bugtasks: 4*10^2
* bac__ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac__ | Firefighting: - | Critical bugtasks: 4*10^2
<bac__> hello, adeuring -- reviewing today?
<adeuring> bac__: oops, yes...
 * nigelb hands gmb a "Did not Die" badge :)
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac__ , adeuring | Firefighting: - | Critical bugtasks: 4*10^2
<gmb> nigelb: We should start a club :)
<nigelb> heh
<nigelb> I'll be riding 30km everyday from today though
<lifeless> rick_h: it has elliots +1, and it is pretty common out there, so I doubt francis will object to us fixing ie8 :)
<gmb> nigelb: Might take me a couple of weeks to get back up to that; depends on the temperature outside. But before Christmas I was managing a 20k hilly ride every lunch, which wasn't so terrible.
<gmb> Can't wait for the mornings to get lighter so that I can get out before work.
<nigelb> Ah. I drive to a co-working space sorta thing everyday. Through amazing traffic :)
<gmb> Oh, lovely.
<gmb> I'm fairly rural, so early morning rides in the dark are a bit hairy, especially on icy days.
<nigelb> Ah, that's scary.
<nigelb> My roads are filled with potholes to slow me down.
<gmb> :)
 * gmb -> emergency cup of tea before team call
<rick_h> jcsackett: if you get a sec can you look over this review we did for StevenK a while back? https://code.launchpad.net/~stevenk/launchpad/combo-url
<jcsackett> rick_h: sure, i can look right now.
<rick_h> jcsackett: thanks, hoping to get it through to land on monday for him
<jcsackett> StevenK: you actually up and around?
<rick_h> jcsackett: I chatted with him about it this morning if you've got a question I might know
<jcsackett> rick_h: so, i see he's changed rocketfuel-setup to install mod-wsgi; what's the hurdle in getting make/rocketfuel to do all the setup we need for convoy?
<jcsackett> since i would prefer that to a guard on the convoy path.
<rick_h> jcsackett: ah, not sure on that the setup side. I know I was worried about current users just running an updated make
<rick_h> jcsackett: but yea, it might make sense to have the setup support the whole thing then
<jcsackett> rick_h: yeah. you have any idea of how long this stuff has been blocked? i don't want to be yet another holdup on something we need, but i want this question answered too.
<rick_h> jcsackett: well this is just to get things going in dev. There's still an issue getting it to run in QA and we're waiting on a RT for convoy I think
<rick_h> jcsackett: so this is mainly to land enough so that a dev can start working on it behind a FF
<rick_h> jcsackett: while the rest is still in progress on the ops side
<rick_h> jcsackett: so I guess I'm saying even if we hold off on ok'ing this until Monday, it's not like production will be getting combo loader monday anyway
 * jcsackett nods
<jcsackett> rick_h: that's what i needed to know. thanks. :-)
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac , adeuring | Firefighting: - | Critical bugtasks: 4*10^2
<bigjools> jml: if I get a defer.succeed() in a test and add callbacks to it, can I expect them to fire?
<jml> bigjools: yes. they'll generally fire immediately, i.e. before the addCallback call returns.
<bigjools> jml: ok thanks, then something else is borked in my test, it spins forever :(
<jml> bigjools: http://paste.ubuntu.com/827747/ as a demo
<bigjools> jml: right, thanks.
<jml> bigjools: generally spinning forever means that the deferred being returned is never fired.
<bigjools> jml: if I return that deferred to the testtools ...
<bigjools> hmm that's not it
<jml> bigjools: if you want to paste the test I can have a quick look
<bigjools> jml: thanks, at the bottom of here: http://pastebin.ubuntu.com/827750/
<jml> bigjools: test_get_nodes should probably return d. I doubt that would be the cause of the spinning though.
<bigjools> jml: yeah I just removed it to see if it made any difference
<jml> bigjools: Yeah, it looks like connection.deferred isn't being fired at all.
<jml> bigjools: not enough context in the diff to say much more.
<bigjools> jml: the whole branch:  http://pastebin.ubuntu.com/827757/
<bigjools> jml: line 285 is the deferred that is returned
<bigjools> oh wait
<bigjools> I'm a twit
<bigjools> ah no, I'm not (well I am, but not here)
<jml> trippy
<jml> using the connection_factory method definition as a default...
<jml> bigjools: in FakeMaasHTTPConnection, I'd put an addBoth that prints out whatever it's passed and then returns it, just to see if it really is being fired.
<jml> (putting the 'return d' back in the test also)
<bigjools> ok
<bigjools> jml: yeah it gets fired
<jml> bigjools: with the JSON you expect?
<bigjools> yes
<jml> bigjools: and if you remove test_get_nodes you don't get the hanging?
<bigjools> jml: right
<jml> bigjools: what if you add a print-and-return callback to the thing returned from get_nodes in the test?
<bigjools> jml: I did that - it shows the value ok, then spins...
<jml> :\
<bigjools> something is borked inside testtools perhaps? I am using the package in precise
<jml> bigjools: it's possible.
 * jml tries
 * bigjools tries with trial
<bigjools> jml: it works in trial
<jml> bigjools: that's a bad sign. :\
<bigjools> jml: 'fraid so.
<bigjools> I'll do a basic test case and see if I can reproduce for a bug report
<bigjools> jml: hmmm, would it be a problem using the testtools TestCase with the trial runner?
<jml> bigjools: couldn't imagine why
<jml> bigjools: but a basic test case would be great, thanks.
<jml> bigjools: yeah, it looks like a trial / testtools interaction.
<jml> pissbum
<bigjools> jml: crapola.  did you get a basic test case working?
<jml> bigjools: working with testtools.run but hanging with trial runner.
<bigjools> ok
<jml> bigjools:
<bigjools> I failed at that
<jml> bigjools: http://paste.ubuntu.com/827787/
<jml> bigjools: that's it.
<bigjools> !
<jml> $ trial istesttoolsbuggy
<jml> $ python -m testtools.run istesttoolsbuggy
<bigjools> shag
<jml> after saving to istesttoolsbuggy.py
<jml> well, I guess this trumps what I was doing
<jml> will try to fix.
<bigjools> ah I reproduced it now
<bigjools> jml: did you file a bug already? I'd like to reference it (or I can file it for you)
<bigjools> beware that it eats swap, so it's not just spinning
<jml> bigjools: yeah, it's calling addObserver over & over
<jml> (trial --spew ftw)
<bigjools> ah ok
<jml> bigjools: I haven't filed a bug, no. Would appreciate it if you could.
<bigjools> sure thing
<jml> bigjools: thanks
<bigjools> jml: https://bugs.launchpad.net/testtools/+bug/926189
<_mup_> Bug #926189: Using the Trial test runner results in a spinning test <testtools:New> < https://launchpad.net/bugs/926189 >
<rick_h> adeuring: abentley you guys know what this hwdb thing is that is being asked about in #lp? https://launchpad.net/+hwdb/+fingerprint/edda5d4f616ca792bf437989cb597002
<abentley> rick_h: Not me.  I've heard of it, but couldn't describe it.
<adeuring> rick_h: I'm looking
<jml> bigjools: I've narrowed it down a bit. It's something to do with the interaction between trial's LoggedSuite and testtools run_with_log_observers
<bigjools> jml: cool, at least you are getting somewhere
<jml> bigjools: which kind of makes sense, since both are designed to do the same thing (catch logged errors and make sure they are turned into test errors)
* adeuring changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: bac | Firefighting: - | Critical bugtasks: 4*10^2
<jml> bigjools: http://paste.ubuntu.com/827841/ <- the fix
<jml> bigjools: very embarrassing.
<bigjools> jml: :D
<bigjools> jml: if that can make it into precise I'd be very happy
<jml> bigjools: me too
<jml> grap
<jml> when's feature freeze?
<bigjools> does that matter for this?
<bigjools> 'tis a nasty bug
<jml> it's easier if I can just (ask jelmer to) upload the latest release
<jml> jelmer, lifeless: https://code.launchpad.net/~jml/testtools/trial-hang/+merge/91470
<jml> otherwise I'll land sometime tomrrow.
<jml> Have to go now
<jml> Have a great weekend all.
<bigjools> cheers jml
<abentley> gary_poster: I have gotten to the bottom of the test_mlist_sync failures.  They happen because we end up running python 2.7 with a pythonpath suitable for python2.6.
<abentley> gary_poster: Do you have any suggestions for how to ensure we run the script with the correct python interpreter?
<gary_poster> abentley, I am guessing you are referring to the canonistack thread.  I haven't followed those details closely enough to know the exact test of which you speak.  Where do I find the script in the tree?  I'll try looking...
<abentley> gary_poster: scripts/mlist-sync.py
<gary_poster> ack abentley looking
<abentley> gary_poster: The tests are in ./lib/lp/services/mailman/tests/test_mlist_sync.py and specify python path, but not python interpreter.
<gary_poster> abentley, this is on precise, I assume?
<abentley> gary_poster: No, oneiric.  I'm waiting for beta.
<gary_poster> ah ok
<abentley> gary_poster: I think Precise will have the same issue, though.  Basically, ssl.py imports symbols defined in libpython.*.so, and at least one symbol defined in 2.6 is not defined in 2.7
<gary_poster> abentley, well, one thought is to simply specify pthon2.6 in the shebang.  That's the kind of thing we've done before for this kind of transition period.  Maybe we could instead use /usr/bin/env [path to bin/py] in the #! line, and move the script to the buildout template location. That would probably work just fine, and it would work whether you were on 2.6 or 2.7..
<gary_poster> but /usr/bin/python2.6 was our approach in the past.
<gary_poster> The template location could even put the output back in utilities if so desired
<abentley> gary_poster: I'm more of a mind to fix the invocation; I think it's broken to specify a python path and not specify the python interpreter.
<gary_poster> You'd just want to clarify in the code that the actual location was in the template directory, so don't change it in situ
<gary_poster> abentley, bin/py, either explictly or in the shebang, is the only way I know to do that.  It also sets the path using that approach
<abentley> gary_poster: I mean to fix the call site, i.e. ./lib/lp/services/mailman/tests/test_mlist_sync.py
<abentley> gary_poster: But I guess if we moved it to the template, we could stop specifying the pythonpath in the call site.  That would be even better.
<gary_poster> abentley, template, right, that's one of the advantages.  I think it also gives you a way to specify the python that LP is currently using, and substitute that in the shebang, rather than bin/py.  We do that now IIRC.  Alternatively, looking at the call site, I suppose you could change the script to use /usr/bin/env python as the shebang, and then manipulate the PATH so that the Python you want is first in your invo
<gary_poster> cation.  But I do think that the template is better.  Lemme see if there is an example already...
<gary_poster> abentley, buildout-templates/bin/bzr.in shows one way--the way we've done it so far
<gary_poster> The first 10 lines (! :-( ) would be boilerplate that you would put at the top
<abentley> gary_poster: cool.
<gary_poster> you could make a utilities directory in buildout-templates and it would copy it over in utilities, or make the script go in bin like the other templates we have now.
<gary_poster> bin is already bzr ignored
<gary_poster> in its entirety
<gary_poster> so if you put it in utilities you might want to explicitly bzr ignore the output
<abentley> gary_poster: any reason not to keep it in "scripts"?
<gary_poster> oh, abentley, no I was just not being detail oriented.  s/utilities/scripts/ in what I said
<abentley> gary_poster: cool.  I think I've got the buildout side working.
<gary_poster> great
<abentley> gary_poster: tests passing, no PYTHONPATH needed anymore.
<abentley> gary_poster: Thanks for the help.
<gary_poster> awesome abentley
<gary_poster> welcome
<abentley> gary_poster: seems like buildout should have a "clean" command that deletes the artifacts it would otherwise create.
<gary_poster> abentley, yeah, that's been said for years.  It has the info to do it.  No such command exists.
<abentley> bac: Could you please review https://code.launchpad.net/~abentley/launchpad/stable-test-failures/+merge/91504 ?
<bac> abentley: :)
<bac> abentley: you're late
<bac> abentley: can it wait just a while?  i'm in a call with gary atm.
<abentley> bac: Sure.
<bac> abentley: no, i'll do it now.  short and testfix.
<abentley> bac: Thanks.
<bac> abentley: np
* bac changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2
#launchpad-dev 2012-02-05
<nigelb> Morning!
<wgrant> Morning nigelb.
<nigelb> O Hai wgrant
<wgrant> Oh good, bug search got even more complicated over the weekend while I wasn't looking :(
<huwshimi> wgrant: In what way?
<wgrant> huwshimi: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14748
<huwshimi> wgrant: Oh, is this because of disclosure stuff?
<wgrant> huwshimi: That rev is unrelated to disclosure, except that it makes my current task (rewriting bug search queries to use a fact table so they perform reasonably with new disclosure) harder.
<huwshimi> wgrant: Fun!
<lifeless> s/with new disclosure//
<wgrant> lifeless: True.
#launchpad-dev 2013-01-28
<adeuring> good morning
<plomme> hey guys, anyone know how often the site is updated from the lp trunk?
<StevenK> plomme: We deploy from stable upon request, usually 3 or 4 times a week
<StevenK> (As in we request the deployment)
<plomme> ok thanks for the info =) fingers crossed for the next one.
<plomme> have a nice day/evening/night !!
<StevenK> plomme: Ah yes, I see why you're looking forward to it. :-)
<plomme> ;)
<czajkowski> jtv1: am getting timeouts when doing the reviews of the pots as there are over 740 again due to the same user as before
<czajkowski> https://oops.canonical.com/oops/?oopsid=OOPS-ee441619f6fa6e6fe521fbc39c2133c0
<czajkowski> BosnianUniverseTranslation trunk series
#launchpad-dev 2013-01-29
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/cache-known-viewers-specification/+merge/145299
 * StevenK grumbles at bug 1107811. The edit function calls tag_input.focus()
<_mup_> Bug #1107811: Clicking "Add tags" or "Edit tags" doesn't focus the tags field <bug> <form-focus> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1107811 >
<wgrant> StevenK: Looking
<wgrant> StevenK: Can't you unnest _preload_specification_people?
<StevenK> wgrant: I probably can. Then I append the bare function to the decorators array?
<wgrant> StevenK: Right, a function that takes no arguments and then returns a function is not useful; you can just use the inner function directly.
<StevenK> wgrant: http://pastebin.ubuntu.com/1584386/
<wgrant> StevenK: That looks more reasonable :)
<StevenK> wgrant: Is that your only issue, or still pawing at the rest?
<wgrant> StevenK: The rest looks fine :)
<StevenK> wgrant: TBH, I was expecting you to complain about the function I added to test_specification :-)
<wgrant> Meh :)
<StevenK> (And ISpecification.userCanView() is finally readable again)
<wgrant> Indeed.
<StevenK> wgrant: That MP has updated
<wgrant> StevenK: r=me
<StevenK> wgrant: Shall we pull apart that checkwatches core on carob, or you give me a clue about mpt's latest bug?
<wgrant> StevenK: Have you traced mpt's in a debugger?
<StevenK> In the five minutes or so I've spent on it, I've reproduced it on prod, and read the code.
 * StevenK goes looking for Firebug
<StevenK> Hmm
<StevenK> So the focus() gets called
<wgrant> Does the widget exist?
<StevenK> It's hidden at the time
<StevenK> http://pastebin.ubuntu.com/1584453/ seems to work
<wgrant> Sounds plausible.
<StevenK> NFI how to test it
<StevenK> How do I check which widget has focus in a YUI test?
<wgrant> StevenK: document.activeElement might work
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/ttb-refactor-create/+merge/145305
<StevenK> wgrant: Won't 90+ return ubuntu.currentseries.nominatedarchindep.default_processor die horribly when a new series is in the midst of populating?
<wgrant> StevenK: Yes, and it does
<wgrant> But fixing that is harder
<wgrant> We generally lose a couple of jobs each time we initialise
<StevenK> Mmmm
<StevenK> wgrant: I'd prefer the one-line comment on line 89 die, and be replaced by the XXX on line 95-98
<StevenK> 95-97 even
<wgrant> Done
<wgrant> StevenK: Any other objections?
<StevenK> wgrant: Sorry, was distacted by phone
<StevenK> wgrant: r=me, looks great
<wgrant> Thanks
<StevenK> Expected: [object HTMLBodyElement] (object) Actual: INPUT#tag-input yui_3_5_1_1_1359436804933_377 (object)
<StevenK> Hmmm
<StevenK> And Firebug does not love the test page at all
<wgrant> Chromium :)
<StevenK> Haven't used Chromium's JS tools
<wgrant> Well
<wgrant> They're not implemented in XUL
<wgrant> Which puts them a fair way ahead of Firebug
<StevenK> +a few million
<StevenK> Uncaught TypeError: Cannot read property 'style' of null /home/steven/launchpad/lp-branches/devel/build/js/yui/dom-style/dom-style.js:65
<StevenK> At least it doesn't cause Chromium to spin, but it is increasing a timer for that error very quickly
<wgrant> Ah, archive.txt, my old nemesis...
<StevenK> Haha
<StevenK> DESTROY
<StevenK> Hmmm, so the _yuid of the #tag-input and document.activeElement are different
<wgrant> StevenK: It looks like the activeElement is the <body>, doesn't it?
<wgrant> Which probably means that activeElement doesn't do what you wnat here
<StevenK> Hmmm, not sure about that
<wgrant> 16:20:24 < StevenK> Expected: [object HTMLBodyElement] (object) Actual: INPUT#tag-input yui_3_5_1_1_1359436804933_377 (object)
<StevenK> Oh, innerHTML is LARGE
<StevenK> Chromium helpfully shows me one line
<StevenK> Right, looks like the <body>
<StevenK> Googling for YUI docs is pretty useless
<StevenK> wgrant: I wonder if r16453 is qa-meh ...
<wgrant> StevenK: It's easy to do
<wgrant> StevenK: Find a project with lots of proprietary specs
<wgrant> Check that the query count is sensible for a user that can see them
<wgrant> And check that users who can't see them indeed can't see them
<StevenK> And since qas has been reset, this easier said than done
<wgrant> Easier done that said, you mean
<StevenK> wgrant: http://pastebin.ubuntu.com/1584603/
<wgrant> StevenK: person_ids.remove(None) might be nicer, but otherwise that seems sensible.
<StevenK> wgrant: .remove will raise a KeyError if we happen to get all specs with everything set. -= will not.
<wgrant> Ah, true.
<wgrant> Carry on, then
<jtv> Hmm...  I'm getting an Unauthorized error when  viewing the translations import queue.  That's new, and a potential problem for maintenance.  Is it a private-projects thing?
<wgrant> jtv: The traceback will tell you
<jtv> I'm well out of practice with deciphering zope tracebacks...  Last line is: Unauthorized: (<ProductSeries at 0x2aac8d794d90>, 'name', 'launchpad.LimitedView')<br />
<wgrant> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<wgrant> Somehow a private project has managed to get translations...
<jtv> Letters and thoughts to that effect occurred.
<wgrant> jtv: What's the URL?
<jtv> https://translations.launchpad.net/+imports
<wgrant> Oh, right
<wgrant> Well, there's the problem
<wgrant> Hmm
<wgrant> The relevant items have been in the queue for 18 days
<wgrant> So I guess the importer knows to ignore them
<wgrant> But one wonders why they were allowed to be created in the first place.
<wgrant> jtv: Can you see it now?
<jtv> wgrant: yup, that works
<jtv> What did you do?
<wgrant> I set the problematic imports to Blocked to get them to what I assume is near the end of that list.
<jtv> Yuck :)
<wgrant> Rather, but better than a 403 :)
<jtv> Quite.
<StevenK> Yay, another critical
<jtv> czajkowski: it'd be a lot easier for everyone if that Bosnian project could just chuck their templates into a branch.  Assuming they're well-structured, approval will be fully automated.
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/better-person-preloading-specsearch/+merge/145316
<wgrant> jtv: Why haven't UTC vetoed the Bosnian project?
<jtv> I don't know that they haven't.
<jtv> Last I heard, we were eager to see that project into a shape
<jtv> that we could be happy with.
<jtv> But I haven't kept track.
<jtv> As far as I know, the UTC aren't really organized at the moment.  But my position is:
<jtv> ideally there should be one Universe translation project.
<jtv> If we can't have that, we should try not to get in the way of useful contributions too much.
<jtv> The _problem_ with the project, as I see it, is that it invites doomed translations to other languages.
<wgrant> If a universe translation project is desired then it might as well be done under the normal Ubuntu translation infrastructure
<jtv> What we suggested for that was: set up a translation group with just a Bosnian translation team, and set permissions to Restricted.
<jtv> Yes, absolutely.  Question is: who could manage such a thing?
<jtv> If we don't have manpower to manage it, we should take a minimal-suffocation look at what the actual problems are, because the old policies aren't serving us well enough.
<StevenK> wgrant: Can haz review, or your peer at the pastebin earlier was enough?
<wgrant> StevenK: r=me
<czajkowski> hmm no jtv to work out what to do with this translation community
<mpt> I've forgotten ... How can I log in to staging.launchpad.net?
<mpt> since login.staging.launchpad.net doesn't accept my 2-factor auth
<czajkowski> you'll need to ask webops for help there mpt
<wgrant> StevenK: If you feel like doing another small spec branch tomorrow, preloading specificationbranch should make the page constant
<StevenK> wgrant: I meant to look at that -- what's prod versus qas now?
<StevenK> wgrant: I guess that will just be a load_referencing() call in the pre_iter_hook
<wgrant> StevenK: qas is 85 to prod's 185
<wgrant> 50 of those 85 are specificationbranch
<wgrant> And yeah, it should be a matter of populating a cachedproperty with load_referencing
<StevenK> wgrant: Well, it would be nice to get the page to <40 queries
<wgrant> Exactly
<wgrant> And this one thing seems to be all of the repetition
<StevenK> wgrant: I'll circle back after I sort out the tests for mpt's latest critical.
<wgrant> StevenK: Great
<wgrant> Thanks
<StevenK> wallyworld: O HAI
<StevenK> wallyworld: O HAI
<StevenK> Let's see if you ping out again
<wallyworld> hello there
<wallyworld> how's lp?
<StevenK> wallyworld: Do you have a few seconds to help with some JS, or has Go rotten your brain?
<wallyworld> oh yes, Go has well and truely started that process
<wallyworld> but i may still have some cells left
<wallyworld> a few
<StevenK> And then you had wine with dinner last night, so they're dead ...
<wallyworld> perhaps
<wallyworld> if not, Go will finish them off today
<StevenK> Haha
<StevenK> wallyworld: http://pastebin.ubuntu.com/1587421/ is my in progress diff
<wallyworld> ok
<StevenK> wallyworld: I've shifted the call to .focus() when the widget isn't hidden to fix a critical, but my test breaks because document.activeElement is <body>
<wallyworld> i'm not sure all browsers support activeElement?
<StevenK> Is there any way to see which widget has focus?
<wallyworld> isn't there a yui call to do that?
<wallyworld> ie there should be an attr which reflects the current focus state
<wallyworld> i'll have a quick look
<StevenK> I couldn't find one when looking through yuilibrary
<StevenK> But you and rick have always managed to find stuff when I can't
<wallyworld> StevenK: there's a :focus css selector
<wallyworld> perhaps you can select a child of the form which has focus and see if it it the element you want
<wallyworld> activeElement appears to be supported across major browsers now, but I'd have to check to see if :focus is also widely supported
<StevenK> wallyworld: I've pulled out the element I want, I do .one('#tag-input:focus') ?
<wallyworld> form_node.one("#tag-input:focus")? i think so
<wallyworld> or even Y.one((...) i guess
<wallyworld> i'm not sure why activeElement would not be working
#launchpad-dev 2013-01-30
<wallyworld> StevenK: any luck?
<StevenK> Fighting with Chromium
<StevenK> Because Firebug hates our test pages
<wallyworld> :-(
<StevenK> wallyworld: form_node.one('#tag-input:focus');
<StevenK> Sigh
<StevenK> wallyworld: form_node.one('#tag-input:focus'); == null
<wallyworld> StevenK: so perhaps something else is being assigned focus
<StevenK> Or the test is braindead
<wallyworld> StevenK: you could attach an onblur event handler to the tag-input node and log something so that you can see if focus is being lost
<wallyworld> or the test ia dead, yes
<wallyworld> at least activeElement and :focus are behaving consistently
<wallyworld> StevenK: i haven't the code handy, but perhaps autocomplete render is messing with the focus
<StevenK> It could have focus rather than the text box
<StevenK> I guess
<StevenK> If :focus works, I just have to Y.Assert.isNotNull();  -- I hope that, or something like it exists
<wallyworld> yes, it exists, can't recall the exact syntax
<wallyworld> my brain is rotten
<StevenK> Y.one('.bug-tag-complete:focus') is also null
<StevenK> Y.one(':focus'); is also null
<StevenK> wallyworld: So I'm not sure if :focus works either
<wallyworld> hmmm
<wallyworld> can you fire up an instance, and click on an input field and then in firebug type a css expression to see if it selects the field you just clicked?
<wallyworld> ah won't work
<wallyworld> since clicking out of the input takes away focus
<StevenK> Hmmm, I think the <form> is activeElement now
<StevenK> With a id of 'tag-input'
<StevenK> That might even be success
<StevenK> Expected: [object HTMLInputElement] (object)
<StevenK> Actual: INPUT#tag-input yui_3_5_1_1_1359506644965_424 (object)
<StevenK> But from my reading in the debugger, the _yuid's are the same
<wallyworld> Actual aboce is correct
<StevenK> wallyworld: Expected is document.activeElement, tag_input is the actual
<wallyworld> i think the assert is comparing the DOM node wityh a YUI node perhaps
<StevenK> Right
<wallyworld> so you need to "convert" the document,activeElement to the YUI node
<wallyworld> there's a YUI.DOM method for that
<wallyworld> from memory
<StevenK> % bzr grep YUI.DOM | wc -l
<StevenK> 0
<StevenK> -i helps not
<wallyworld> let me check
<wgrant> Don't you just give it to the YUI.Node constructor?
<wgrant> IIRC
<wallyworld> StevenK: Y.one() accepts a DOM element from memory
<wallyworld> and returns the YUI node
<StevenK> Let's see
<StevenK> No failures!
<wallyworld> \o/
<StevenK> NoCanonicalUrl: No url for u'http://blueprints.launchpad.dev/product-name-100004' because u'http://blueprints.launchpad.dev/product-name-100004' broke the chain.
<StevenK> canonical_url, I hate you
<wgrant> That's a string
<wgrant> You can't take the URL of a string
<StevenK> url = canonical_url(product, rootsite='blueprints')
<wgrant> product is the URL
<wgrant> Not a product
<StevenK> product = self.factory.makeProduct()
<wgrant> I suspect
<wgrant> You sure it's failing on that line?
<StevenK> Oh, god damn it, getViewBrowser
<StevenK> I hate you, please die in a fire
<wgrant> StevenK: Looking
<wgrant> StevenK: Why'd you remove the first assert?
<wgrant> And why do you get form_node, rather than going straight to #tag-input?
<StevenK> wgrant: Compare line 19 and 22
<wgrant> Ah, true
<StevenK> I can go straight to #tag-input, but I wanted to be sure it was the unhidden form's node
<wgrant> If there's a duplicate ID that has focus then there are probably bigger problems
<wgrant> 'cause both of those requirements are problems
<StevenK> wgrant: http://pastebin.ubuntu.com/1587567/
<wgrant> StevenK: You can probably inline that now
<StevenK> wgrant: http://pastebin.ubuntu.com/1587573/
<wgrant> Much better.
<StevenK> The line is too long with Y.one(document.activeElement), so that can stay outside as the var
<StevenK> wgrant: The MP has updated
<wgrant> StevenK: r=me, thanks
 * StevenK stabs himsefl
<StevenK> *himself
<wgrant> What did you do?
<StevenK> No wonder my query count is tiny, I'm not invalidating the cache
<StevenK> Hmmm, that doesn't help
<StevenK> And I switch to c_i_v() and the query count drops to 17. WTF.
<wgrant> StevenK: Did you actually render the view?
<StevenK> view() should do that, no?
<wgrant> Yes
<StevenK> Oh, HAH
<StevenK> official_blueprints
<StevenK> STAB
<wgrant> Heh
<StevenK> sudo dpkg -P hayfever
<StevenK> Hm, blueprints.l.d/product is only showing 5
<wgrant> Right, batch size on launchpad.dev is 5 by default
<StevenK> I think my test is slighly broken
<StevenK> The query list shows an INSERT INTO specification
 * StevenK peers at the oops attached to 1108261
<StevenK> The sreg_info we got back was None?
<wgrant> Or not present at all, more likely
<wgrant> Which possibly means that the user tried to authenticate with an SSO account that had no LP account, or somehow convince SSO not to send the info
<StevenK> wgrant: http://pastebin.ubuntu.com/1587769/ the rest of the changes (ISpecification.linked_branches cachedproperty and preloading are shelved)
<wgrant> StevenK: You need to check that the query count is constant, because a query count of 35 for 5 specs could easily include 3 queries for each spec.
<wgrant> so eg. create one, check query count, create another 4, check query count is still the same
 * StevenK peers at this test
<StevenK> I think getViewBrowser screws with the interaction
<StevenK> wgrant: http://pastebin.ubuntu.com/1588354/
<wgrant> StevenK: That looks more test-like, though I'm not sure about having that query count hardcoded in a generically-named method :)
<StevenK> wgrant: http://pastebin.ubuntu.com/1588558/
<wgrant> StevenK: Have you considered BrowsesWithQueryLimit?
<wgrant> That might even handle invalidation for you
<StevenK> Doesn't look like it handles invalidation
<adeuring> good morning
<czajkowski> mgz: may want to add your details to https://wiki.ubuntu.com/Fosdem/2013  and poke Jelmer :)
<mgz> ah, hadn't realised there was a wiki.ubuntu.com page, I put 'em on the canonical one
<czajkowski> nods
<czajkowski> community one is public :)
<czajkowski> now to poke the canonical folks to add their details there
<mgz> global poke'd
<czajkowski> cheers
<czajkowski> mgz: http://www.drugopera.be/
<czajkowski> very close to delierium  then for friday night beers
<mgz> that is the stupidest name...
<czajkowski> indeed
<czajkowski> but is within the perdiem also
<czajkowski> easily
<czajkowski> mgz: oh this also means I finally get to meet jelmer
<mgz> wait, you've never met 'im?
<czajkowski> NO!
<czajkowski> I joined the month  after the sprint
<czajkowski> :(
<mgz> he's coming to london immediately after and settling in :)
<czajkowski> aye
<czajkowski> has he found a place to live?
<mgz> has a place arranged for the first month or so and will start looking for something longer term
<czajkowski> cool
<czajkowski> a weekend of beer waffles chocolate and geeks :D
<czajkowski> cannot wait
<mgz> don't eat the geeks!
<cjwatson> wgrant,StevenK: any chance of a review of https://code.launchpad.net/~cjwatson/launchpad/bpph-phase/+merge/144154 ?
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/precache-specification-linked-branches/+merge/145544 has updated
<wgrant> StevenK: You still need the explicit invalidate?
<wgrant> Also, the "specs" list is not useful at all
<wgrant> You only read from it to get the store to invalidate, and you can get that from product just as easily
<StevenK> wgrant: The test passes without the invalidate
<StevenK> But I'm still not convinced it invalidates the store
<wgrant> Looks like you're right
<StevenK> I could make it do so, but that may have far reaching implications
<wgrant> Anyway, I guess that means you should eliminate the specs var and I will be happy :)
<StevenK> I've already done so: http://pastebin.ubuntu.com/1591256/
<wgrant> Much better :)
<StevenK> wgrant: I'm happy to make BrowsesWithQueryLimit invalidate the store in a seperate branch and toss it at ec2
<wgrant> StevenK: That might be worth a try
<StevenK> wgrant: The MP is updated
<wgrant> StevenK: r=me
#launchpad-dev 2013-01-31
<StevenK> wgrant: Thanks. When that hits devel, I'll rip out the invalidates, add one to the match method of BrowsesWithQueryLimit and toss it at ec2
<StevenK> wgrant: Yes, having just found the code in the glue, I was going to move the project back, and you alreadyd did it.
<wgrant> Yes :)
<wgrant> loggerhead doesn't have Launchpad-specific bits
<wgrant> They're in launchpad_loggerhead, in the LP tree
<StevenK> Yes, the glue
<wgrant> failures=36
<StevenK> 37 queries/external actions issued in 4.41 seconds
<StevenK> That looks like SUCCESS
<wgrant> DF?
<wgrant> Or it on qas already?
<StevenK> That's qas
<wgrant> Nice
<wgrant> ubuntu needs DS preloading, but at least there's only ever likely to be a few DSes
<wgrant> So it's not so important.
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/loggerhead-reject-no-sreg/+merge/145760
<wgrant> StevenK: Terrible error message is terrible.
<StevenK> The log, or the exception
<StevenK> ?
<wgrant> The one that's going to be entirely unhelpful to users :)
<wgrant> (also, we prefer "cannot" to "can not" in most contexts)
<StevenK> wgrant: http://pastebin.ubuntu.com/1591934/
<wgrant> Maybe "You don't have a Launchpad account. Check that you're logged in as the right user, or log into Launchpad and try again."
<StevenK> wgrant: I've pushed that up and the diff has updated.
<wgrant> It's a bit sad that you can't set explanation in __init__
<wgrant> But there seems to be no way around it
<wgrant> StevenK: Is this testable?
<StevenK> I couldn't find any tests
<wgrant> Indeed
<StevenK> That entire method that block is in is mocked out
<wgrant> r=me
<wgrant> Yeah
 * StevenK peers at these failures
<StevenK> IntegrityError: new row for relation "specification" violates check constraint "specification_completion_recorded_chk"
<StevenK> wgrant: Do you have a broken OpenID account on staging handy?
<wgrant> StevenK: OOPS-17fcee4cc96517eb7f0dca9fe7cdf8ec
<wgrant> codebrowse must be lagging
<StevenK> Oh, the glue is run on tellurium?
<wgrant> StevenK: It's run as part of the codebrowse application, yes.
<StevenK> wgrant: No magic BFJ branches for me yet?
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-0-db/+merge/145540 https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-1-populate/+merge/145541 https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-2-garbo/+merge/145542 https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-3-query/+merge/145543 are the majority of the current state, but not yet ready for review
<StevenK> Crumbs
<wgrant> 0, 1, and 2 will grow a couple of extra bits each
<wgrant> 3 is basically done, as the corresponding additions are worth a 3.5
<wgrant> There'll be a 2.5 to drop garbo
<StevenK> Yeah
<wgrant> And 4 has another 100 lines of diff or so
<StevenK> But that's a clean revert of the revno -2 ends up as, so meh
<wgrant> Exactly
<StevenK> wgrant: I thought our Zope machinery caught Unicode errors? Bug 897053
<_mup_> Bug #897053: apport generated urls can trigger UnicodeDecodeError <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/897053 >
<wgrant> StevenK: In URLs, sure
<wgrant> That bug's not about that.
<StevenK> wgrant: It isn't?
<wgrant> StevenK: That doesn't seem to be an error involving invalid Unicode in a URL segment, no
<StevenK> Oh, the URL segment is okay, it's the form data that's bong
<wgrant> No
<wgrant> It's the widget that's the problem.
<wgrant> Well, or something's not giving the widget unicode, I guess
<wgrant> Look at the traceback.
<StevenK> wgrant: Haha, I see that OOPS
<wgrant> ?
<StevenK> wgrant: https://oops.canonical.com/?oopsid=OOPS-cc84945e33282c37b36e0441a72db951 but it causes an ISE
<wgrant> StevenK: "that OOPS"?
<wgrant> Oh
<StevenK> wgrant: ./2013-01-31/OOPS-986af52b1270191ca6d71de17241b352 on neem, it has your username on it, and is a UnicodeDecodeError
<wgrant> The instance that I generated?
<wgrant> Right
<StevenK> I'm a little worried that it's ISEing
<StevenK> Without giving an OOPS id
<StevenK> And the access log is not helpful
<wgrant> The access log won't show errors
<wgrant> Because it's an access log :)
<StevenK> The error log is also unhelpful
<StevenK> I can view other OOPSes, just not that one
<StevenK> wgrant: ('value', "package uml-utilities 20070815-1.1ubuntu2 failed to install/upgrade: el subproc\xe9s post-installation script retorn\xe0 el codi d'eixida d'error 1")
<StevenK> Note the lack of u
<wgrant> StevenK: Well, yes, that was pretty obvious from the exception :)
<wgrant> Casting a unicode to a unicode doesn't try to decode it!
<StevenK> Still trying to work out the cause
<StevenK> So it's a TextWidget, and it seems to expect unicode strings
<wgrant> Right
<StevenK> I wonder if it's the call to self.widgets['title'].setRenderedValue(self.extra_data.initial_summary)
<StevenK> Which may point to publishTraverse() not doing unicode-y things
<wgrant> I'm not sure it's the publisher's place to decode query string arguments.
<wgrant> Work out how it ends up undecoded.
<StevenK> Sadly, it isn't that
<wgrant> publishTraverse handles the path, not the query string, so I'm not terribly surprised.
<StevenK> I mean the extra_data bit, which has a comment saying that it was populated by publishTraverse
<wgrant> Oh, are you sure you care about extra_data?
<wgrant> That's usually the bit retrieved from the apport blob
<StevenK> I do not in this case
<wgrant> (which is referenced by a trailing UUID path segment; hence the publishTraverse relevance)
<StevenK> My theory was incorrect
<StevenK> H
<StevenK> *Hmmm
<StevenK> We just toss the data straight into render()
<StevenK> WCPGW and all
 * wgrant comes up with a cunning plan
<StevenK> Oh?
<wgrant> buildfarmjob will survive my purge
<wgrant> Though it shall be gravely disfigured.
<StevenK> /home/steven/launchpad/lp-sourcedeps/eggs/zope.app.form-3.8.1-py2.7.egg/zope/app/form/browser/textwidgets.py:139: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
<StevenK>   if self.convert_missing_value and input == self._missing:
<StevenK> Which means something is tossing a string into _toFieldValue
<StevenK> Which is implicated by the zope form machinery
<StevenK> wgrant: Disfigured how?
<wgrant> StevenK: Gravely!
<wgrant> Duh
<StevenK> Hah
<StevenK> wgrant: Your helpfulness knows no bounds :-P
<wgrant> :)
<StevenK> wgrant: In other news, I don't understand this error
<wgrant> StevenK: Why not?
<StevenK> It looks like we just toss the string into the widget, and then it goes bang.
<wgrant> Who is "we"?
<wgrant> Given the arg is named field.title, it's plausible that it's zope.app.form doing it itself
<StevenK> wgrant: http://pastebin.ubuntu.com/1592257/
<StevenK> Portion of a traceback.print_stack()
<wgrant> StevenK: That's probably well after the problematic value has been injected
<StevenK> wgrant: A large chunk of the traceback is all TALES, and then zope's publisher calling render()
<wgrant> Ah, that sequence isn't actually valid UTF-8
<wgrant> That might be why it's not being automatically decoded
<StevenK> I thought that was known
<StevenK> I just don't know what does that part of the magic
<wgrant> Probably zope.formlib
 * wgrant looks
<wgrant> hee hee
<wgrant>         for charset in self.charsets:
<wgrant>             try:
<wgrant>                 text = unicode(text, charset)
<wgrant>                 break
<wgrant>             except UnicodeError:
<wgrant>                 pass
<StevenK> OH
<StevenK> WHY
<StevenK> WHY
<StevenK> Is that in zope.formlib?
<wgrant> Nope, the base BrowserRequest
<wgrant> (which is in zope.publisher, but not actually related to the publisher)
<StevenK> Twitch
<wgrant> I wonder what the test suite will think of you if you override that to decode as UTF-8 or die
<StevenK> Remove the try and except?
<wgrant> How did we end up handling the bad unicode in PATH_INFO thing?
<StevenK> At the moment, I'm wondering why Store.of(context) is None
<wgrant> Ah, that's right
<wgrant> We decode as UTF-8 with replace
<wgrant> StevenK: Which?
<StevenK>   File "/home/steven/launchpad/lp-branches/browseswithquerylimit-invalidates/lib/lp/testing/matchers.py", line 84, in match
<StevenK>     Store.of(context).invalidate()
<wgrant> StevenK: This decoding happens later, so you might be able to raise an exception that you can turn into a 400
<StevenK> AttributeError: 'NoneType' object has no attribute 'invalidate'
<wgrant> (we couldn't do that with PATH_INFO because it was too early)
<wgrant> What is context?
<StevenK> wgrant: So inside zope.publisher, or we call into the publisher?
<StevenK> (Pdb) p context
<StevenK> <lp.registry.model.distributionsourcepackage.DistributionSourcePackage object at 0x10887fd0>
<wgrant> StevenK: DSPs aren't real objects
<wgrant> Try DSP.distribution
<wgrant> (the distributionsourcepackage table is represented by DistributionSourcePackageInDatabase, not DistributionSourcePackage)
<wgrant> StevenK: I'd override LaunchpadRequest._decode or so
<wgrant> Either make it decode('utf-8', 'replace') or catch the UnicodeDecodeError and give a 400
<StevenK> (Pdb) p context
<StevenK> <lp.registry.model.milestone.ProjectMilestone object at 0xf0a6dd0>
<wgrant> 'cause if someone uses anything other than UTF-8 then they're not worth our time :)
<wgrant> ProjectMilestone also isn't real
<wgrant> Could just invalidate all stores
<StevenK> That would work too
<StevenK> IStore.invalidate() ?
<wgrant> No
<wgrant> Interfaces don't work that way
<wgrant> lp.services.database.sqlbase.flush_database_caches()
<StevenK> Oh, nice. That branch failed to scan six hours ago, and I didn't notice.
<StevenK> wgrant: You mean LaunchpadBrowserRequest ?
<StevenK> The interface seems to be IBasicLaunchpadRequest
<wgrant> StevenK: Possibly, or something lower than that
<wgrant> I forget what the hierarchy looks like
<StevenK> I can't find a LaunchpadRequest class, that's all
<wgrant> But any of our request classes that inherit zope.publisher.browser.BrowserRequest at all want it
<wgrant> THey might all inherit LaunchpadBrowserRequest
<StevenK> class LaunchpadBrowserRequestMixin:
<StevenK>     """Provides methods used for both API and web browser requests."""
<StevenK> Haha
<StevenK> wgrant: lp.services.webapp.servers.get_query_string_params
<wgrant> StevenK: Yeah, that uses the same _decode method
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/browseswithquerylimit-invalidates/+merge/145774
<wgrant> StevenK: You'll want to flush before you register the query collector, otherwise any pending writes will get collected
<wgrant> Also, test_sprint has a flush that's now redundant
<StevenK> wgrant: http://pastebin.ubuntu.com/1592333/
<wgrant> StevenK: Seems odd to split the collector definition and registration, but otherwise fine
<StevenK> wgrant: http://pastebin.ubuntu.com/1592336/
<wgrant> Indeed
<StevenK> wgrant: That MP is now with more red and a little more green
<wgrant> StevenK: r=me, thanks
<StevenK> db-devel is obviously cursed
<wgrant> Apparently.
<adeuring> good morning
#launchpad-dev 2013-02-01
<StevenK> wgrant: Hmmm, how do I return a 400.
<wgrant> StevenK: Maybe raise a BadRequest, but I'm not sure if you can at that point.
<StevenK> I just tried with HTTPBadRequest and that OOPSes
<StevenK> wgrant: BadRequest also OOPSes
<StevenK> I might be using the wrong one, since I'm pulling it from lazr.restfulclinet
<StevenK> *restfulclient
<wgrant> StevenK: HTTPBadRequest is probably the right one
<wgrant> But the request may not be sufficiently set up by then
<wgrant> What does the traceback look like?
<StevenK> wgrant: http://pastebin.ubuntu.com/1595337/
<wgrant> StevenK: Ah, so the publisher deals with it really early
<wgrant> Might best to go the decode('utf-8', 'replace') route
<StevenK> Right, like PATH_INFO ?
<StevenK> wgrant: My test might be screwing that up
<StevenK> But given it's three lines, maybe not
<wgrant> Like PATH_INFO, yes
<wgrant> If they don't speak UTF-8 then they're not worth understanding :)
<StevenK> wgrant: http://pastebin.ubuntu.com/1595363/
<wgrant> StevenK: Heh, no
<StevenK> wgrant: Would you prefer _decode() turns into return unicode(text, 'utf-8
<StevenK> Bleh
<wgrant> StevenK: Well, think about what your diff will do
<StevenK> return unicode(text, 'utf-8', 'replace') even
<wgrant> It'll go through all the user-specified charsets
<wgrant> Decoding each with replacements
<wgrant> Then decode as UTF-8 with replacements
<wgrant> What you might want to do is try to decode as the user-specified charsets
<wgrant> Then, if they all fail, decode as UTF-8 replacements
<wgrant> *or* just go ahead and decode as UTF-8 with replace to start with
<wgrant> I'd prefer the former
<StevenK> wgrant: http://pastebin.ubuntu.com/1595366/
<wgrant> StevenK: No
<StevenK> Oh, missing a break
<wgrant> It's also wrong :)
<wgrant> That'll decode as utf-8 with replace if any decoding fails
<wgrant> You want to do it if *all* decodings fail
<wgrant> So perhaps you want to
<wgrant> def _decode(self, text):
<wgrant>     text = super(LaunchpadBrowserRequest, self)._decode(text)
<wgrant>     if isinstance(text, str):
<wgrant>         text = test.decode('utf-8', 'replace')
<wgrant>     return text
<wgrant> s/test/text/
<StevenK> Heh
<StevenK> wgrant: That sounds good. Even with an explanatory comment.
<StevenK> BrowserRequest does not love adapting LBR
<StevenK> So I'll call it directly
<wgrant> ?
<wgrant> Oh, is it not new-style?
<StevenK>     envadapter = IUserPreferredCharsets(self)
<StevenK> TypeError: ('Could not adapt', <lp.services.webapp.servers.LaunchpadBrowserRequest instance URL=http:/>, <InterfaceClass zope.i18n.interfaces.IUserPreferredCharsets>)
<wgrant> Ah
<wgrant> That's odd...
<StevenK> We don't implment IBrowserRequest
<StevenK> That might be it
<wgrant> Except that we inherit that method and it works fine
<StevenK> When I copied and pasted it, it was failing with the IUserPreferredCharsets line, but I just removed it rather than looking for the import
<wgrant> Sure, but _decode is called today and seems to work fine, right?
<StevenK> LBR doesn't have a _decode today
<StevenK> It will fall to the subclasses
<wgrant> Exactly
<wgrant> Which have the same self
<wgrant> But work fine
<StevenK> Ah, hm
<StevenK> implementing IBrowserRequest helps not
<StevenK> Neither does calling text = BrowserRequest._decode(self, text)
<wgrant> StevenK: So you're getting that crash in a browser?
<StevenK> That's from my test
<StevenK> Let me try the browser
<wgrant> Oh
<wgrant> You might not even be in the right layer
<StevenK> TestBasicLaunchpadRequest has no layer
<wgrant> That would be a problem for a test that desires to make use of the Component Architecture.
<StevenK> TestLaunchpadBrowserRequest doesn't either
<StevenK> wgrant: It works in the browser, so yeah, layers
<StevenK> None of the testcases in services/webapp/tests/test_servers use layers at all
<wgrant> Right, none of them need to at present
<StevenK> LFLayer, or is that too high?
<wgrant> FunctionalLayer should be fine
<wgrant> Don't even need DatabaseFunctionalLayer
<StevenK> wgrant: http://pastebin.ubuntu.com/1595398/
<wgrant> StevenK: Might want to extend the comment to state that we always want unicode, dammit.
<StevenK> wgrant: http://pastebin.ubuntu.com/1595412/
<wgrant> StevenK: Seems reasonable.
<wgrant> Checked that it fixes the crash?
<StevenK> It renders the page with the replaced string in the widget
<StevenK> So 'good enough'
<wgrant> Yep
<wgrant> StevenK: I'll have ~3600 lines of diff for you soon :)
<wgrant> Over 6 branches, though
<StevenK> Whimper
<wgrant> :)
<wgrant> StevenK: So, do you understand what I'm doing?
<wgrant> https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-1-populate/+merge/145541 https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-2-garbo/+merge/145542 https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-3-query/+merge/145543 https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-3.5-more-query/+merge/145819 https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-4-app-eliminate/+merge/145820
<wgrant> StevenK: They're ready for you to review at your leisure
<StevenK> wgrant: You never explained your dastardly plan
<wgrant> StevenK: I've outlined it in the MP descs
<wgrant> But can go into more detail if you desire
<StevenK> wgrant: Yeah
<wgrant> To which? :)
<StevenK> The first comment
<wgrant> Ah, good :)
<wgrant> It's conceptually simple, there's just a lot of code to change
<StevenK> wgrant: I've approved -1-populate with one niggle, but it took me a few minutes to figure out the the _new_* gubbins
<StevenK> Hopefully they lose their _new_ness
<wgrant> Yes
<wgrant> They're just there so they don't override the properties which delegate to PB/BFJ
<wgrant> So all the other callsites don't have to care
<wgrant> (since the _new_ cols obviously won't be populated when the appservers first start up with that code)
<wgrant> They'll be renamed in -5, I suspect
<StevenK> Yeah
<StevenK> -5-scorched-earth ? :-)
 * StevenK hits line of 525 of -3.5 and vomits
<wgrant> Mmm?
<StevenK> 520	+ BinaryPackageBuild, Archive).find(
<StevenK> 521	+ BinaryPackageBuild,
<StevenK> 522	SQL(query))
<StevenK> 523	resultset.order_by(
<StevenK> It's sort of disgusting
<StevenK> And needs a rewrite
<wgrant> Ah yeah, a bit, but not in this branch :)
<wgrant> It needs Stormification
<wgrant> Which should come as part of the search rewrite in -6
<StevenK> Heh
<StevenK> Which branch does DROP TABLE PackageBuild, then?
<wgrant> -7 or so, because it's not quite so urgent :)
<StevenK> Maybe -8 can make retry-depwait a garbo-frequently job
 * StevenK hides
<wgrant> No
<wgrant> It takes too long
<wgrant> It's already a tunable loop, and could maybe be in -hourly
<StevenK> Even with this change it will be too slow?
<wgrant> Yes
<wgrant> This won't affect it in any significant fashion
<StevenK> wgrant: Up to -4
<wgrant> StevenK: Right, I originally considered having a common garbo base, but the column lists and joins for each are somewhat different, and the code will be on prod for just hours
<StevenK> Right, exactly why I ended up with 'eh'
<StevenK> wgrant: I'm done, all approved. -3.5 has the most niggles
<wgrant> Thanks
<wgrant> StevenK: Can you reapprove https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-3-query/+merge/146035 (no changes other than a merge from a garbo-dropping branch, which required a resubmit)
<wgrant> Your first comment will be resolved in a later branch that rewrites the search stuff, and your second is invalid (see the next couple of lines)
<StevenK> 1013+ find_spec = find_spec + (order_by_table,)
<StevenK> OH
<StevenK> That's hideous
<wgrant> Quite!
<StevenK> wgrant: Re-approved
<wgrant> Thanks
<StevenK> wgrant: Blink. My test failed on buildbot, but passes locally.
<StevenK> 2.7 versus 2.6, at a guess?
<wgrant> StevenK: Yeah
<wgrant> 2.6 eats the whole character
<wgrant> It assumes that the size indicated by the first byte is correct.
<StevenK> Hm, not sure how to deal with this test for both 2.6 and 2.7, then. :-(
<wgrant> http://bugs.python.org/issue8271
<StevenK> wgrant: Ouch
<StevenK> wgrant: assertTrue(...['field.title'].startswith('...')) ?
<wgrant> StevenK: I'd just check if it's one of the two known values
<wgrant> With an XXX
<StevenK> Right
<StevenK> wgrant: http://pastebin.ubuntu.com/1595628/
<wgrant> StevenK: Looks good
<StevenK> wgrant: -0 is waiting for stub, and I guess -1 can't land until after a FDT?
<wgrant> StevenK: Right.
<wgrant> Most of the fun will happen after an FDT at 1pm on Monday, I suspect
<wgrant> They're all in ec2 now
<StevenK> How many indicies do you add?
<wgrant> (the runs are condemned due to your failure, though)
<wgrant> Um, not sure at this point
<wgrant> That's for working on between 2.5 and 3 on Monday
<wgrant> Since I can approve them myself and get ops to apply them now
<StevenK> Last time I looked, your DB patch said TODO: add indicies
<wgrant> I removed that while you were reviewing the rest, I think
<StevenK> Ah
<wgrant> There's no point creating them at that stage
<wgrant> Quicker to create them at the end when all the data's there
<StevenK> Indeed
<StevenK> And it's not my failure, it's all 2.6's fault.
<wgrant> True
<StevenK> wgrant: Shall we deploy in about 70 minutes?
<StevenK> Might be closer to 80, but eh
<wgrant> So, remaining changes: work out indices, clean up all the _new crap, drop PackageBuild itself, drop the old DB columns/table, apply various NOT NULL constraints, work out indices for the new D/DS/SPN/i_d_a queries, integrate the new D/DS/SPN/i_d_a queries
<wgrant> And that should be that
<wgrant> And yes, we should deploy tonight
<wgrant> Will close 3 criticals?
<StevenK> Yah
<StevenK> I need to find another
<StevenK> wgrant: How can I pull apart this checkwatches core ?
<wgrant> You may not have much luck pygdbing it post-portem
<wgrant> post-mortem
<wgrant> Ideally we'd do it in-place
<StevenK> On loganberry?
<wgrant> Yes
<wgrant> stub: Thanks. Those indices were indeed planned for a quick followup, but the DEFAULT thing slip my mind this time.
<stub> yup, I assumed the indexes would be landing soon. Just making sure those particular ones don't get lost in case you were mainly thinking about performance tuning.
<wgrant> stub: Though it doesn't matter much for librarian-gc anyway
<wgrant> As it basically seqscans everything
<wgrant> But still useful
<wgrant> It's person merges that really matter, as they are selective
<stub> mmm...
<stub> I haven't looked for ages. I was thinking there was some selectivity in there.
<wgrant> Well, consider what it has to do :)
<wgrant> It needs to find LFAs that are unreferenced
<wgrant> Which means finding a list of everything that is referenced
<wgrant> The index only helps a lot if the column is relatively sparse
<stub> That is one part of the algorithm. There used to be parts that benefited from the indexes. But TBO, I don't really know if that is still the case after a few years of tweaking.
<stub> If nothing else, deleting a single row from LFA requires looking up if that row is referenced anywhere - index lookups or table scans if the indexes don't exist.
<stub> Which is hundreds or thousands each gc run
<wgrant> Oh yeah, that bit is a good point.
<wgrant> Duh
#launchpad-dev 2013-02-03
<StevenK> wgrant: A revert? :-(
<wgrant> StevenK: The fix is not at all clear.
<StevenK> Indeed
#launchpad-dev 2014-01-29
<bigjools> Could really do with the bug reporting guidelines getting show before someone types in a bug title for dup checking
#launchpad-dev 2014-02-01
<xnox> wgrant: thanks =)
<wgrant> xnox: :)
<wgrant> xnox: You caught me just before I flew out.
<xnox> wgrant: muahaha, i'll break everything in the mean time ;-)
<wgrant> Please don't.
<wgrant> Enoug hstuff broke last week!
#launchpad-dev 2015-01-27
<thomi> good morning.
<thomi> wgrant: or cjwatson, I wonder if I could bug one of you to take a peek at https://code.launchpad.net/~thomir/launchpad/devel-add-bug-header/+merge/245921 please?
<wgrant> thomi: Morning.
<thomi> hey wgrant
<wgrant> Hi
<thomi> wgrant: I ran those tests, and I'm getting a lot of test failures, but most of them seem unrelated to my change: http://pastebin.ubuntu.com/9905467/
<thomi> the first failure is clearly related (and fixed now)
<thomi> wgrant: but "ProgrammingError: column sprint.is_physical does not exist" seems like some sort of sql schema mismatch?
<thomi> do I have to do something to keep the schema up to date?
<wgrant> thomi: make schema
<thomi> hmnmm, ok
<thomi> wgrant: there's no CI set up for launchpad branches?
<wgrant> thomi: Not until landing.
<thomi> ahh ok
<wgrant> The test suite is very expensive to run.
<wgrant> Doing it automatically over everything would require a lot of hardware.
<thomi> hmmm
<thomi> hardware is cheap :D
<wgrant> Tell that to my 7 year old DB servers :)
<blr> wgrant: any more news om the SSDs?
<blr> *on
<wgrant> The ticket for the new servers is in the queue.
<blr> is that analogous to "the cheque's in the mail"? :)
<wgrant> Pretty much, I think.
<thomi> wgrant: I'm still having issues getting a clean test run... the rocketfuel setup should have installed  all the build-deps, right? How do I make sure that's kept up to date in my lpdev lxc container?
<thomi> For example, I seem to be getting errors about Gtk...
<thomi> hmmm "RuntimeError: Gtk couldn't be initialized" - probably because it's running in an lxc container?
<wgrant> thomi: Ah yes, the JS tests require DISPLAY to be set. Try it in xvfb-run
<wgrant> But you probably haven't broken those :)
<thomi> ok
<thomi> down to one doctest failure
<wgrant> Excellent.
<thomi> hmmm, which may have been caused by my editor stripping whitespace
<thomi> *sigh*
<thomi> have I mentioned how much I dislike doctests?
<wgrant> We all loathe them :)
<wgrant> There is a universal authorisation to shoot them on sight.
<thomi> yup... looks like the doctest fails due to a whitespace change...
<wgrant> What sort of whitespace?
<thomi> can I get 'bzr diff' to print whitespace as tokens?
<wgrant> Not sure the commandline diff can do that.
<wgrant> Pipe it through tr or use a graphical one?
<thomi> wgrant: looks like a trailing space
<wgrant> Sounds easy enough.
 * wgrant lunches.
#launchpad-dev 2015-01-28
<wgrant> thomi: Did you get the space sorted?
<thomi> wgrant: oh yeah, it's all sorted
<thomi> sorry, I meant to say something, then I guess I got distracted
<wgrant> thomi: Excellent.
<cjwatson> blr: Do you need any help landing https://code.launchpad.net/~blr/launchpad/inline-comment-delint/+merge/243322 ?
<blr> cjwatson: ah no, thanks for the reminder.
<blr> cjwatson: hope you're on the mend
<thomi> morning all
<thomi> looks like I don't get to join you for a while.. *sigh*
<thomi> apparently everything that could go wrong in this transfer _has_ gone wrong
#launchpad-dev 2015-01-29
<cjwatson> blr: Best set the commit message before you lp-land next time, so that the log doesn't look like http://lpqateam.canonical.com/qa-reports/deployment-stable.html :-)
<cjwatson> blr: Yeah, still some way to go but feeling much better now, thanks
<cjwatson> I'll fix buildbot after dinner
<thomi> morning
<cjwatson> thomi: Morning
<thomi> hey cjwatson, it must be late for you?
<cjwatson> Yeah, wife and daughter out at karate, I was just settling down to some correspondence
<cjwatson> thomi: Are you able to handle your QA from http://lpqateam.canonical.com/qa-reports/deployment-stable.html ?  You might need https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/ConnectToStagingMailbox
 * thomi reads
<thomi> cjwatson: the staging mailbox is where the staging deployment sends mail to? That second link doesn't actually say what it's for :D
<cjwatson> Right, https://wiki.canonical.com/Launchpad/Instances mentions this
<cjwatson> under "Outgoing mail" for qastaging/staging
<thomi> ahh, nice
<thomi> thanks
<thomi> yes, I'll get on that now
<cjwatson> So for QA for this kind of thing you'd typically perform some actions on qastaging.launchpad.net that ought to generate the right kinds of notifications, and then check the mailbox
<thomi> yup
<cjwatson> I think I have the mailbox password lying around, unless it's been changed in the last couple of years
<cjwatson> let me know if you need it
<thomi> ok
<blr> cjwatson: ack, thanks, for some reason thought it defaulted to the commit message from the bzr rev.
<cjwatson> Ah, no, that would be too useful
<cjwatson> Happy buildbot again.  Excellent.
<thomi> cjwatson: I need that password....
<cjwatson> /msged
<thomi> cjwatson: BTW, is there an email I can subscribe to to get alerted when http://lpqateam.canonical.com/qa-reports/deployment-stable.html is blocking on me?
<thomi> ...or is it just a case of "check this page every morning"?
<cjwatson> thomi: It'll only be doing that shortly after you've landed a change, which ought to be a thing you're aware of ...
<thomi> heh, ok
<thomi> I guess I'll be more aware when I'm actually doing lp dev full-time
<cjwatson> Yeah, it becomes routine
<cjwatson> Most people need a reminder for their first few landings
<cjwatson> thomi: https://dev.launchpad.net/QA has a bunch of helpful stuff, aside from talking about the ec2 tool which nobody uses any more
<thomi> heh, ok
<cjwatson> (Also, we can afford to be a bit less formal about it with fewer people)
<thomi> heh
<cjwatson> I don't seem to have completely exploded project -> project group linkage, anyway.
<thomi> well, synchronising all this mail will take a few hours on my crappy NZ internet connection :-/
<thomi> (3571 of 176912)
<blr> cjwatson: wgrant: thinking the turnip service ports should be exported to the host envvars, rather than hardcoded (case, nagios nrpe plugins)... is that sensible?
<blr> wish the juju config supported a dict type :/
<cjwatson> blr: Which host, sorry?
<cjwatson> blr: We're going to have to hardcode at least some host/ports in lp-production-configs, although the turnip-internal ones probably don't matter for that.
<blr> cjwatson: the host running turnip
<cjwatson> It's been a while since I did any charming, but I would have expected configuration settings like this to be passed in using "juju set", and to have reasonable defaults in the charm
<blr> specifically for nrpe service checks
<cjwatson> And then bits of your environment should be able to pick them up from the juju config
<blr> cjwatson: right, ports are currently a string in the juju environment, I would have to add a juju env var for each one given the lack of dicts, but I suppose that is okay
<cjwatson> Yeah, don't see why not
<cjwatson> We're talking about a fixed set
<blr> cjwatson: the nrpe plugins run outside the juju environment however, so juju will have to make those available from the host environment - should be easy though.
<cjwatson> blr: I admit to not having a clue how subordinate charms work!
<cjwatson> But https://wiki.canonical.com/InformationInfrastructure/IS/Policies/Prodstack#Nagios_Checks_for_your_Service seems to imply that the service-specific part goes in the primary charm
<blr> yep, that's the case for the turnip charm
#launchpad-dev 2015-01-30
<thomi> half way through syncing emails
<thomi> :(
<thomi> maybe we should delete ones that are over a certain age?
<wgrant_> thomi: We?
<wgrant_> Oh, the staging mailbox
<wgrant_> ?
<wgrant_> There's a script to purge that.
<wgrant> Connecting to it without purging first is suicide.
<thomi> wgrant: *now* you tell me :D
<thomi> wgrant: where's the script?
<wgrant> Found 176826 messages.
<thomi> this will take days otherwise
<wgrant> lp:lp-dev-utils' purge-inbox.py
<thomi> 95k/176k
<wgrant> Invoke with '-u staging -w $PASSWORD -d 3' or so
<wgrant> But I'm already a good way in.
<thomi> wgrant: you're purging it now?
<wgrant> Yep
<thomi> awesome, I'll wait
<wgrant> thomi: there's now a whopping 103 emails.
<thomi> nice
<thomi> new code seems to work perfectly :D
<wgrant> thomi: You need to replace the "qa-needstesting" tag with "qa-ok"
<thomi> wgrant: ugh,t hanks
<thomi> done
<wgrant> Thanks.
<cjwatson> wgrant,blr: Could you have a quick look over https://code.launchpad.net/~cjwatson/txpkgupload/sftp-interface-oopses/+merge/247459 ?  Would be nice to de-oopsify that.
<cjwatson> (And possibly also see if the txpkgupload deployment process doesn't entirely suck this time.)
#launchpad-dev 2015-01-31
<gorille> hello
<gorille>  I've a problem, I've cancel my Ubuntu One account before desactivate my launchpad account (yep, I've not read the ubuntu one deletion page :*( ), it is possible to desactivate? (I've do nothing with it, also, it will be indexed if I put that here because the channel is logged), Can I tell an administrator directely by private message?
<gorille> (ops, topic --')
#launchpad-dev 2015-02-01
<lifeless> wgrant: I've managed to do the credentials dance w/LP - no need to fix it for me :)
<gorille> hello, where can I found an administrator?
#launchpad-dev 2016-02-05
<xnox> wgrant, cjwatson - could you please enable s390x on https://launchpad.net/~canonical-foundations/+archive/ubuntu/upstart-daily ppa? including for livefs building?
<cjwatson> xnox: s390x done.  livefs building is a separate thing - what I've done is invite canonical-foundations to join launchpad-livefs-builders, but you'll need to get Steve to accept that invitation.
<cjwatson> xnox: (once you're in that team, livefs building for a particular arch comes with the package of adding the arch in general.)
<xnox> cjwatson, cool
<cjwatson> xnox: Steve accepted that, so you're good to go.
<xnox> \o/
#launchpad-dev 2018-01-30
<vila> cjwatson, wgrant: I'm curious about the following. I realize lp builders had a "bad hangover" to begin this year. And that many bets are off about the performance impact from many recent fixes. Yet, I seem to remember lp estimated times for builds to be accurate at the hour scale. For several days now, they are completely off though. Not progressing for hours, repeating the same (obviously wrong) estimation.Do you know why ?
<wgrant> vila: The build start time estimation relies on the assumption that no new builds jump the queue in front of you. Do you have a particular build in mind?
<vila> wgrant: https://code.launchpad.net/~vila/+recipe/byot-releases
<vila> wgrant: just jumped from 17mins to 29mins
<vila> wgrant: ha right, and there are way more jumpers these days. Makes sense.
 * juliank is currently trying to add Valid-Until support to Launchpad because he thinks it's needed. Untested branch in https://code.launchpad.net/~juliank/launchpad/valid-until - diff so far in http://paste.ubuntu.com/26491591/
<juliank> I'll try to actually get a test launchpad instance set up tomorrow or later this week and run the tests.
<juliank> This mostly illustrates the idea :)
<juliank> If that actually (or eventually) works and we decide to roll it out, I'd probably start with bionic-backports as a test stage, as nobody uses that yet, so we can check weekly regeneration without affecting much :D
<juliank> or well, whatever is devel at that time :D
<juliank> cjwatson: I must say that the code is quite easy to read
<juliank> I mostly just grepped advertise_by_hash and replicated that into write_valid_until :D
<cjwatson> I'd make the interval a configuration item (see lib/lp/services/config/schema-lazr.conf) and maybe also try to work out a way to make it configurable on a per-suite rather than per-series basis
<cjwatson> "make it configurable" whether to do this at all, I mean
<juliank> cjwatson: So a set of pockets would do that, right?
<juliank> pockets_with_valid_until in distroseries, essentially
<cjwatson> I guess two configuration items, one for the Valid-Until period and one for how long before its expiry we regenerate
<cjwatson> Yes, I think something like that would be worthwhile for finer control
<juliank> Right
<cjwatson> juliank: Also initialize-distroseries needs to copy the configuration to new series
<juliank> I guess we can just define valid_until_period instead of write_valid_until in days
<juliank> it does now
<cjwatson> And a bunch of other things I imagine we'll pick up :)
<cjwatson> Ah yes, I was looking at an earlier diff
<juliank> This is the first time I looked at LP code
<juliank> So all you see happened within an hour of me first looking at it :D
<cjwatson> archivepublisher is very probably the most accessible bit for an APT developer, and for almost nobody else :-)
<juliank> It's super easy
<juliank> or well it looks super easy
<juliank> valid_until_expiry_threshold
<juliank> valid_until_period
<juliank> valid_until_pockets
<cjwatson> The tests for this general area are a bit clunky by the standards of other LP code (they're very functional-testy, if you see what I mean, lots of "set up universe then run universe for a while" kinds of things), but should be manageable
<juliank> I guess these are useful option names
<juliank> Unless you want to configure period per pocket
<cjwatson> I don't think that's necessary
<juliank> valid_until_expiry_threshold and valid_until_period in days I guess
<juliank> could make it seconds, though
<cjwatson> We have configuration items with times in seconds, minutes, days
<juliank> ah
<cjwatson> Days should be OK I think
 * juliank will take a look
<juliank> yeah
<cjwatson> Nice start, anyway - thanks for working on this
<cjwatson> isReleaseFileOutdated might want to be careful of the case where there isn't a Release file for the suite yet
<cjwatson> I have a sort of an itch about the way it parses the existing file rather than going off DB state, but it may be the most robust approach here
<juliank> ack
<juliank> cjwatson: I'm not sure date is in the db? It just generates the releasefile with datetime.now()
<juliank> um, utcnow()
<cjwatson> Yeah, it's not right now
<cjwatson> What you have is probably fine, just thought I'd mention my initial itch :)
<cjwatson> (Well - it's going to end up in the ArchiveFile table soon for InRelease-by-hash, but not in a form that's particularly useful for this)
<juliank> cjwatson: InRelease-by-hash will be epic
<cjwatson> Last stage of that is https://code.launchpad.net/~cjwatson/launchpad/inrelease-by-hash/+merge/336675
<cjwatson> I think it will just about avoid conflicting with yours
<juliank> yup seems ok
<juliank> cjwatson: I guess I'll continue tomorrow, but these are all very helpful comments :)
<juliank> cjwatson: The code in apt for checking that Date is not in the future is basically ready too, BTW. I hope it'll land for bionic :)
<juliank> If both changes land in time for that, we end up with a strict 2 week validity period for Release files
<juliank> which would be awesome, IMO
<juliank> s/2 week/<n> day/
<cjwatson> juliank: let me know when you've got near the point where you want to actually start running tests - I can help with setup, and you really don't want to be running the full suite if you don't have to, so I can offer advice on which segments to run
<juliank> cjwatson: thanks :)
<cjwatson> (full suite is 40min or so in buildbot, several hours on my laptop)
<juliank> wow
#launchpad-dev 2018-01-31
<xboxown__> heheh
<xboxown__> this channel does indeed exist
<xboxown__> it does, it does exist :D
<xboxown__> Hello
#launchpad-dev 2018-02-02
<cjwatson> OMG I just found two files in LP containing "arch-tag:"
 * cjwatson suffers flashbacks
<bladernr> hi all... question about packaging recipes... I have a PPA that is built for several architectures by default, but I have a package that is amd64 only. Is there a way in a recpipe to tell the builders to ONLY build amd64 for this one package/recipe?
<bladernr> I didn't see anything useful in the help for this, unfortunately.
<cjwatson> bladernr: Architecture: amd64 in debian/control
<bladernr> ahhh, thanks!
#launchpad-dev 2020-01-27
<tomwardill> sooooo, what did I miss? :)
<Spads> se se seventeen
<pappacena> Hey, Tom! Did you have good vacation?
<cjwatson> Could anyone review https://code.launchpad.net/~cjwatson/lazr.restfulclient/access-token-compat/+merge/378084 ?  Indirectly part of ongoing py3 work
<pappacena> Seems to be fine. I just don't have permission to top-approve it.
<cjwatson> np, will merge, thanks
<cjwatson> Also https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378025 would be good if anyone has time - that's the last bit of the Beautiful Soup 4 port
<ilasc> cjwatson: nice!
<tomwardill> cjwatson: lack-of-understanding question: I don't understand quite what an owner-default repository is?
<tomwardill> pappacena: sorry, missed that question! :)
<cjwatson> tomwardill: Does https://help.launchpad.net/Code/Git#Repository_URLs help?
<tomwardill> cjwatson: yes, yes it does!
#launchpad-dev 2020-01-28
<stub> cjwatson: Should https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1860500 be targetted at Launchpad? tldr; changing a PPA's displayname breaks automatic package updates in modern Ubuntu
<mup> Bug #1860500: consider disabling apt-secure's Label check in Ubuntu <apt (Ubuntu):New> <https://launchpad.net/bugs/1860500>
<wgrant> I wonder if we should make that more immutable for focal onwards
<wgrant> But it seems like a pretty hostile check to have in apt
<ilasc> hmmm... not sure what I did this time :) but my MP is now refusing to update diffs, anyone else seeing anything similar on their MPs ?
<ilasc> https://oops.canonical.com/?oopsid=488ee4ad9a5fe8789652551e72e1b903
<tomwardill> errr....
 * tomwardill has no idea
<ilasc> :) that makes 2 of us tomwardill
<ilasc> thanks for looking at it!
<tomwardill> unsure how you can get a 404 out of turnip like that
<ilasc> right...
<ilasc> my thoughts exactly
<ilasc> the branch is definitely there and reflecting the latest updates : https://code.launchpad.net/~ilasc/launchpad/+git/launchpad/+ref/webhook-livefs
<cjwatson> stub: Maybe an LP task.  I agree it seems hostile
<cjwatson> IIRC some of turnip's views return 404 if e.g. the commit isn't found
 * tomwardill learns that 'getopt' and 'getopts' are different things
 * tomwardill has a bit of a sad
<tomwardill> okay, I fixed: https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/377768 so it actually takes arguments
<cjwatson> ilasc: *blink* that OOPS is a bug in a place I didn't expect
<ilasc> cjwatson: landmines my friend :)
<cjwatson> ilasc: In the case where all three of the source, target, and prerequisite repositories are different, LP doesn't tell turnip the ID of the prerequisite repository, so it has no way to find the prerequisite commit ...
<cjwatson> ilasc: Could you file a bug about this quoting that OOPS ID?
<ilasc> wow! that's a good one, sure, I'll file it
<ilasc> thanks Colin!
<cjwatson> In theory turnip accepts more than two repository paths at once and will construct an ephemeral repository using all of them as alternates if need be (though I don't think there's anything that currently exercises it for more than two paths), so it should be fixable purely on the Launchpad side
<cjwatson> And probably quite easily
<ilasc> makes sense :)
<tomwardill> 2020-01-28 13:19:45+0000 [-] Build log: OCI runtime create failed: container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"rootfs_linux.go:109: jailing process inside rootfs caused \\\"permission denied\\\"\"": unknown
<tomwardill> well.
<ilasc> :(
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378169 should fix the OOPS that ilasc ran into earlier
<cjwatson> ilasc: also a workaround would be to rebase your branch onto the current state of mine (since that would cause the commit to exist in your repo too)
<ilasc> cjwatson: hmmm I think I did the before pushing remote last time (after the fix u put in on your branch for account privileges), so rebased a second time
<ilasc> but again I could be "seeing" double, been looking at macaroons all day :)
 * cjwatson checks
<cjwatson> Oh I'm sorry
<cjwatson> Your branch isn't a descendant of the current state of mine
<cjwatson> It has the second-from-last commit but not the last one
<ilasc> yes, indeed, it's only second-from-last
<cjwatson> (If you have a remote set up for my repository, then "tig webhook-livefs cjwatson/fix-webhook-visibility-check" should make this visible in a concise way)
<cjwatson> Or s/tig/gitk/ if you prefer that
<ilasc> yep, I see it "Handle DelegateAuthorization" commit only (thanks for sharing the tig command by the way!)
 * cjwatson â¥ tig
<ilasc> :) I second that
#launchpad-dev 2020-01-29
 * tomwardill watches apt output scroll past for approximately the eleventy billionth time today
 * ilasc will never feel the same about macaroons again after today :)
<tomwardill> hah
<tomwardill> yes
<tomwardill> today in developer news: tom deletes the test files to make the builds pass
<tomwardill> it lives! https://pastebin.canonical.com/p/T8KfhpZYD7/
<cjwatson> Nice
<tomwardill> now to restore those pesky test files and see how much is broken
<pappacena> Cool!
<cjwatson> 'psycopg2.ProgrammingError: schema "binarysourcereference" does not exist'   Thanks, PostgreSQL, that was an entirely obvious way to say 'You misspelled "COMMENT ON COLUMN" as "COMMENT ON TABLE"'
<SpecialK|Canon> oof
<cjwatson> (In fairness it's hard to see how it could've done better, but it took me a while to spot.)
#launchpad-dev 2020-01-30
<SpecialK|Canon> sigh
<SpecialK|Canon> tests don't work so well when you run them on the wrong branch
<ilasc> I know the feeling ...
<SpecialK|Canon> re earlier conversation, I've been meaning to look at https://github.com/asottile/pyupgrade
<SpecialK|Canon> Neat for stripping out 2-isms from pure-3 code
<SpecialK|Canon> ...it will also auto-f-string, about which I have Feelings (TM), but hey ho
<tomwardill> ... no
<tomwardill> https://code.launchpad.net/~twom/launchpad-buildd/initial-docker-build-support/+merge/369775 is ready for re-review I think
<cjwatson> tomwardill: queued up.  (you have at least one conflict marker in there ... maybe worth going over the diff yourself)
<tomwardill> ergh, thought I'd fixed that
 * tomwardill fixes again
<tomwardill> although it has just occurred to me that I've not tried it in an environment that needs a HTTP proxy for outgoing connections
 * tomwardill diverts into 'how to make a proxy'
<SpecialK|Canon> Should I expect --force-with-lease to Just Work when pushing to lp:~doismellburning/turnip? I'm getting rejected with not much context - https://pastebin.canonical.com/p/FDvkYCvpMY/
<cjwatson> I think that means that your local ref is stale for some reason
<cjwatson> Oh err that invocation is weird
<cjwatson> Normally you'd use --force-with-lease with a proper remote name, since it wants to know what the expected contents of that ref are
<cjwatson> Do you have something like a "doismellburning" remote configured to point to lp:~doismellburning/turnip ?
<cjwatson> Then you'd use git push --force-with-lease doismellburning feature/readme-rst
<cjwatson> Liberal use of tab-completion recommended there
<SpecialK|Canon> Ahhh I hadn't appreciated that you could pass a refname to fwl - that'll do it
<SpecialK|Canon> I've also managed today to inadvertently push two branches to lp:turnip - I didn't realise I could, or expect to be able to, do that, and I can't figure out how to delete them
<SpecialK|Canon> but after that I started explicitly specifying where I was pushing
<SpecialK|Canon> I've got the GH-y fork-model embedded deep in my muscle memory so I habitually just "git push" with no further qualification
<cjwatson> git push --delete origin <names of branches>
<cjwatson> Even with GH, I always give the upstream repo a remote name of "origin" and name my fork "cjwatson", so I can "git push cjwatson <branch>"
<cjwatson> We could protect everything under lp:turnip but haven't yet/currently done so
<cjwatson> If you delete those branches then I'll apply some more protection
<SpecialK|Canon> cjwatson: deleted, thanks
<cjwatson> SpecialK|Canon: And protected further (https://code.launchpad.net/~launchpad/turnip/+git/turnip/+permissions)
<cjwatson> And I've done likewise for lp:launchpad
<SpecialK|Canon> cjwatson: Yay, thank you
<SpecialK|Canon> And you were right about stale info - I'd missed that I hadn't actually ever fetched lp:~doismellburning/turnip in that clone
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378344 - buildbot fix, if somebody could review that
<pappacena> Done!
<cjwatson> thanks
#launchpad-dev 2020-01-31
<tomwardill> surprise, it's iptables!
<SpecialK|Canon> lol
<tomwardill> \\Ã¸/ finally done it
<tomwardill> for future travellers: lxd has a defualt forward accept policy that deliberatly preceeds ufw rules
<tomwardill> which is obvious, in retrospect
<SpecialK|Canon> nicely found
<SpecialK|Canon> most things are obvious in retrospect - that's how retrospect works ;)
<tomwardill> iptables -S shows the FORWARD rules, which are higher in the list than the ufw ones
<tomwardill> `lxc network set lxdbr0 ipv4.routing false` will change it to a DENY
<tomwardill> or you can manually delete the rules
<tomwardill> I think there's config somewhere, but not found it yet
<cjwatson> Sigh, first breezy regression (issue with inline comments containing unicode)
<cjwatson> Well not a regression in breezy itself, regression caused by a bit of my port
<tomwardill> Build log: sendto(ntp.buildd): Operation not permitted
 * tomwardill gradually finds all the things that are now failing
<cjwatson> tomwardill: I usually set "ntphost =" in /etc/launchpad-buildd/default for a local builder
<cjwatson> Since you probably don't have an ntp.buildd anyway
<tomwardill> I just /etc/host'd it to ntp.ubuntu.com
<cjwatson> Can't be proxied though
<cjwatson> So either allow it or change config to not use it
<tomwardill> yeah, I've also allowed it in ufw
<cjwatson> Aha, tests didn't catch this because they tried to use \u inside a str
<cjwatson> Python 2 string (bytes) literal that is
<cjwatson> Where \u1234 corresponds to the bytes \ u 1 2 3 4
<SpecialK|Canon> I...yikes
<cjwatson> Nice landmine
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378414
 * SpecialK|Canon does some obligatory Hypothesis flag-waving
<cjwatson> I've occasionally thought about it, yes.  Would need to take some care to apply it only to true unit tests though - it would probably get prohibitively slow for anything that talks to the database
<SpecialK|Canon> Oh absolutely
<tomwardill> Temporary failure resolving 'archive.ubuntu.com'
<tomwardill> no.
<tomwardill> networks.
<SpecialK|Canon> hugops
<tomwardill> stop it.
<cjwatson> (Well, maybe.  If the database tests were in the happy path that can just ROLLBACK between tests rather than having to clone a fresh template then maybe.
<cjwatson> )
<cjwatson> .oO( PITR for the test suite )
<SpecialK|Canon> ooh
<cjwatson> Would that work I wonder?  I don't know enough about how PITR works
<SpecialK|Canon> I only know of it as a concept (so sure, if we can, then yay) but it sounds like you're thinking of a specific impl?
<cjwatson> Probably not actually faster though.  I think if you're doing PITR then you have to replay WAL forwards, not backwards
<cjwatson> So the situation that requires cloning a fresh template is when a test has committed a transaction, since then you can't just roll back to get to a clean state
 * tomwardill -> EOD to somewhere that doesn't involve computers :)
<cjwatson> If we could rewind time using WAL on disk then that would be faster
<cjwatson> But I think that isn't really how it works, sadly
<SpecialK|Canon> something something time travel something
<cjwatson> https://www.postgresql.org/docs/10/app-pgrewind.html is a thing ...
<cjwatson> May be worth experimenting at some point to see if it's faster
<SpecialK|Canon> Will have a read next week - sounds neat!
 * SpecialK|Canon EOWs, take care y'all
<pappacena> See ya, Kristian
<roadmr> SpecialK|Canon ????
#launchpad-dev 2020-02-01
<cjwatson> OMG I got my hacky LP py3 branch past the point of creating a virtualenv
<cjwatson> I removed some things with a chainsaw and have merged a pile of unlanded branches into it, but still, further than I expected to be able to get yet
<cjwatson> Of course it then immediately explodes as soon as the Makefile tries to do anything else at all, but still
