[00:00] <mkanat> poolie: The launchpad loggerhead branch is still named devel, though, it looks like.
[00:02] <poolie> ok
[00:03] <poolie> so istm we will stick with the 1.18 branch on launchpad for the medium term
[00:03] <poolie> so i'd like you to concentrate your efforts on things that can go into that
[00:03] <mkanat> poolie: Yeah, there are no fixes on the 1.18 branch that would affect loggerhead on launchpad, right now. I can still merge it, but it's mostly stuff like test changes, NEWS updates, release stuff, etc.
[00:03] <poolie> thumper: ^^ agree?
[00:04] <mkanat> poolie: Well, I think you might need to be more specific than that.
[00:04] <poolie> perhaps i should nominate particular bugs?
[00:05] <mkanat> poolie: Well, perhaps, but are we shifting away from our original plan?
[00:05] <mkanat> poolie: See, I think that the trunk work that I'm doing is going to eliminate all of the problems in 1.18 with actually far less work than hunting down memory leaks, etc. will be.
[00:05] <mkanat> poolie: Some of these things I can backport, if in a hackish fashion, though.
[00:06] <mkanat> poolie: For example, the "don't annotate by default" thing I could backport by adding a URL parameter like ?annotate=1 to the "annotate" controller, instead of refactoring the controllers like I did for trunk.
[00:07] <mkanat> Of course, that means that trunk and 1.18 will use different URLs for the same thing, and that the default behavior of 1.18 (which is to annotate when asked for /annotate/) will change.
[00:07] <poolie> i guess this depends a bit on when we expect to do a 1.19, and how traumatic it will be
[00:07] <james_w> anybody know what's going on with http://paste.ubuntu.com/538491/ when I do a "make"?
[00:07] <mkanat> poolie: Well, in an ideal world I was hoping to be ready for 2.0 instead of 1.19.
[00:07] <mkanat> poolie: I'd like say of 2.0 "this will absolutely scale to launchpad size".
[00:08] <poolie> james_w: i haven't seen that but typically it means an  update in download-cache, and then make clean make
[00:08] <poolie> it rings a bell
[00:08] <mkanat> poolie: I'm totally with you on wanting to see these improvements on launchpad as quickly as possible, though, particularly the performance-related ones.
[00:09] <james_w> oh, if you read up there are errors further back, sorry
[00:09] <poolie> james_w: there was a thread on launchpad-dev about this last friday
[00:09] <poolie> "Fwd: failure"
[00:09] <poolie> mkanat: looking back at my mail "next steps on codebrowse" from november
[00:10] <mkanat> poolie: I think that one of the problems I'm running into is that the template code and the CSS are great, in loggerhead, but the python pieces are pretty messy, so every time I go in to make a change, it's generally much more complex to do than it ought to be.
[00:10] <poolie> :/
[00:10] <mkanat> poolie: I'm improving that as I go a bit, though.
[00:12] <mwhudson> james_w: you might need to upgrade your download-cache
[00:12] <mwhudson> (the one on lp got upgraded to 2a lately)
[00:12] <james_w> been through that one :-)
[00:12] <james_w> seems I'm missing libpq-dev
[00:12] <mwhudson> ah
[00:13] <poolie> "obviously" :-|
[00:14] <mkanat> poolie: So, re: the "next steps for codebrowse" mail, those are all still totally things I'd like to focus on.
[00:15] <mkanat> poolie: There's just a lot of technical debt, too--to the point where there often aren't really great ways to do those changes in a non-invasive way. Sometimes there are hacky ways we could do branch fixes, though.
[00:17] <lifeless> FWIW
[00:17] <lifeless> and I really don't want to get into detail
[00:17] <lifeless> I am happy with LP running off trunk.
[00:17] <lifeless> as long as the existing process and QA are followed.
[00:21] <mkanat> lifeless: Does the LP team have a QA process for loggerhead?
[00:21] <lifeless> same as all other changes
[00:21] <poolie> so trunk currently contains history-db etc
[00:21] <lifeless> which I and francis described in a thread with you a few weeks back
[00:22] <poolie> rolling that out will have some operational implications
[00:22] <poolie> ie it'll create different cache dbs
[00:22] <mkanat> lifeless: I really would be opposed to running trunk on LP, FWIW.
[00:22] <lifeless> if its ready for use
[00:22] <lifeless> then its inventory we're not benefiting from.
[00:22] <lifeless> mkanat: lp itself is vastly larger and we run trunk.
[00:23] <mkanat> lifeless: LP also has a reasonable test suite and FAR more development effort available.
[00:23] <lifeless> sure
[00:23] <mkanat> lifeless: I don't think it's as much about size as it is about how many people you have on hand who can immediately spend the next week solving a critical issue.
[00:23] <elmo> wgrant: is poppy known to spew exceptions pretty much non-stop?
[00:24] <mkanat> I'd say that it's actually easier to run trunk of a large project with excellent tests and a large development team than it is to run trunk of a small project with worse test coverage and a small team.
[00:24] <lifeless> lp teams can put time into loggerhead if needed - its something we've previously said we'll maintain. We've no feature work planned for loggerhead though, FWIW.
[00:24] <elmo> alternatively - how soon should I expect packages I upload to a PPA to appear in the webUI?
[00:24] <poolie> elmo: 5-10m
[00:24] <poolie> (unauthoritative answer)
[00:24] <elmo> k
[00:25] <mkanat> lifeless: Ultimately, I think that I am the person with the most general loggerhead knowledge (although jam is probably pretty good at it by now too), though, so one way or another, if we put trunk into production, I will be on the hook.
[00:25] <poolie> i don't think we should have non-staff on the hook
[00:25] <poolie> i talked to francis about doing a squad rotation onto loggerhead
[00:25] <lifeless> mkanat: I'm not asking for us to run trunk.
[00:26] <lifeless> mkanat: I'm being clear that I consider it an ok option.
[00:26] <mkanat> lifeless: Okay.
[00:26] <lifeless> When I get back from leave I'd be happy to discuss further.
[00:26] <lifeless> thats jan.
[00:27] <mkanat> lifeless: That's fine, I think that we have a plan that will work one way or another.
[00:27] <mkanat> lifeless: By January I'd like to see what's currently on trunk be stable, in any case.
[00:29] <mkanat> poolie: I like the idea of just having a "no annotate and other codebrowse stuff" release. It's possible that I could create a branch and cherry-pick stuff from trunk for that.
[00:29] <mkanat> poolie: And that could be 1.19.
[00:29] <poolie> in some ways that would be nice to do because it would give us an easier dry run for deploying your work to lp
[00:29] <poolie> well, semi-wet
[00:30] <poolie> and then you don't need to backport them in a hacky way
[00:30] <mkanat> poolie: Yeah. It would still be additional work, probably, because I'll have two different branches to test, there will be code differences, etc.
[00:30] <poolie> right, i was just considering the idea that in some ways doing any branches is a waste of time and effort
[00:31] <poolie> at least as far as the lp deployment
[00:31] <mkanat> poolie: Sure, except for when we are ready to actually say, "this is table".
[00:31] <mkanat> *stable
[00:31] <mkanat> poolie: For example, so far, the 1.18 branch is very little work, and I *have* landed a fix on it.
[00:32] <mkanat> poolie: (It just happened to be a fix that didn't affect LP.)
[00:32] <poolie> can we keep trunk just adequately stable all the time?
[00:32] <mkanat> poolie: Ah, I'm not sure. That's some fair bit of effort for a web app. I mean, it's possible, but I'd have to look at the test suite quite a bit, probably.
[00:33] <mkanat> There are decent-coverage tests, but I know that some of them don't even pass on 1.18 right now (although the failures don't represent bugs).
[00:33] <mkanat> poolie: Also, we'd have to be sure that all reviewers required unit tests on checkins.
[00:33] <mkanat> poolie: There would be more process involved.
[00:34] <mkanat> poolie: I don't know if adding that sort of process to a smaller project is a good idea.
[00:34] <poolie> it may not be
[00:34] <poolie> otoh having trunk always stable does avoid some kinds of churn and waste
[00:34] <mkanat> poolie: Yeah, it totally does. It's absolutely more efficient in many or most ways, it's just not necessarily *easier*. :-)
[00:35] <mkanat> poolie: I'm thinking about the ideal solution.
[00:35] <poolie> the other thing from that november thread was adding etag and http cache support
[00:36] <mkanat> poolie: Yes, although that might be less of a general win than the other improvements, since I suspect that a lot of page loads in loggerhead are things that will not be cached.
[00:37] <mkanat> poolie: I think there could be some reasonable ways to do it without too much effort, for some pages, though.
[00:38] <mkanat> poolie: What I most *want* to do is to do everything from the "next steps" email, improve performance in a few more places, get great coverage on the test suite, and *then* branch for a new release.
[00:39] <poolie> i would like that too
[00:39] <poolie> two questions:
[00:39] <poolie> 1- does that make sense to do in one block, or should we do the annotation changes separately?
[00:39] <poolie> 2- roughly how long elapsed/effort would it take?
[00:40] <mkanat> poolie: Okay. Well, re: (1), I think that with the current development model of loggerhead, and since history-db which came before was such a big change, I think we should do all the changes, then stabilize, then after that release, look into doing smaller, more rapid releases.
[00:41] <mkanat> poolie: For (2), I'd guess that we're looking at 50-75 hours, although it could be less (and of course, could be more).
[00:43] <mkanat> poolie: In terms of time, I'd like to get it done in two weeks or less--I'm focusing heavily on loggerhead work right now (and also very much enjoying doing the work).
[00:43] <poolie> good
[00:43] <poolie> i'd like to keep you in the rhythm
[00:44] <poolie> i think, even if it's a bit less efficient, i would like to do a 1.19 that's got the annotation changes and that's deployable
[00:44] <poolie> and, in fact, deployed
[00:44] <rockstar> BLUE SQUAD!
[00:44] <lifeless> mkanat: btw
[00:44] <poolie> then go on with other things later
[00:45] <lifeless> mkanat: if the loggerhead caches are k-v, you might consider moving to cassandra
[00:45] <mkanat> lifeless: Can the value be a tuple or a dict?
[00:45] <mkanat> poolie: Okay, I can totally do that.
[00:45] <lifeless> mkanat: sure; I mean it serialises.
[00:45] <mkanat> poolie: Or I could just merge the annotation changes into the LP branch.
[00:45] <lifeless> mkanat: see my posts to the lp-dev list for a summary/description
[00:45] <poolie> yeah
[00:45] <mkanat> lifeless: Is Cassandra the DB system you posted about on the list...yeah.
[00:46] <poolie> i think conceptually "here's the loggerhead branch" and "here's what lp deploys" are a bit different but it's not a big deal
[00:46] <mkanat> lifeless: I don't think we'll need that level of performance from the cache alone, at this point.
[00:46] <mkanat> lifeless: Right now we're using sqlite and it's good enough.
[00:47] <mkanat> lifeless: Although loggerhead could be a reasonable PoC for Cassandra usage, if somebody felt like doing that work.
[00:47] <lifeless> mkanat: we have no stats to show if its good enough or not
[00:48] <lifeless> mkanat: if we instrument lock latency on sqlite and various related things, then we could say that
[00:48] <mkanat> lifeless: Well, I wouldn't worry about it at this point.
[00:51] <elmo> mm
[00:51] <elmo> the publisher is deadlocking
[00:59] <poolie> mkanat: in some ways i like the idea of having a separate branch for 1.19 vs the lp deployment branch
[00:59] <poolie> if only for the reviews: "i'm fixing this bug" vs "i'm deploying this block of stuff"
[01:01] <mkanat> poolie: It's a possibility. It will be more work, but I suppose I'd be happy to do it if you'd like me to.
[01:03] <poolie> perhaps we should just be lazy there
[01:03] <mkanat> poolie: That's sort of my inclination.
[01:03] <poolie> fair enough
[01:03] <poolie> you can ping me, spiv, jam, etc, for reviews
[01:04] <mkanat> Okay, sweet.
[01:04] <poolie> the default reviewer may not be who you want
[01:05] <mkanat> poolie: Hmm, okay. Any recommendations for who to specify when making a new MP?
[01:05] <poolie> ~bzr and ~launchpad?
[01:06] <mkanat> poolie: Okay. I'll do ~bzr--I suspect that will get me the most likely reviewers.
[01:07] <mkanat> I'll do ~launchpad for the deployment merges, I suppose, yeah?
[01:12] <lifeless> mkanat: the default is appropriate there
[01:12] <mkanat> lifeless: Okay, will use the default then, for that.
[01:38] <mkanat> Is something up with LP right now?
[01:39] <mwhudson> mkanat: data centre issues it seems
[01:39] <mkanat> okay
[01:45] <wgrant> The frontends are in the other DC?
[01:46] <mwhudson> seems so
[01:46] <lifeless> apache is in one dc
[01:46] <lifeless> some appservers are in each
[03:18] <lifeless> [03:18] <lifeless>     Hard / Soft  Page ID
[03:18] <lifeless>      324 / 7217  Archive:+index
[03:18] <lifeless>      148 /  451  BugTask:+index
[03:18] <lifeless>       36 /  150  ProjectGroupSet:CollectionResource:#project_groups
[03:18] <lifeless>       19 /  296  Distribution:+bugs
[03:18] <lifeless>       18 /   13  Cve:+index
[03:18] <lifeless>       13 /  278  Distribution:+bugtarget-portlet-bugfilters-stats
[03:18] <lifeless>       11 /   38  MailingListApplication:MailingListAPIView
[03:18] <lifeless>       11 /   19  DistroSeries:+queue
[03:18] <lifeless>        9 /   16  Person:+specworkload
[03:18] <lifeless>        8 /   51  Milestone:+index
[03:19] <lifeless> wgrant: every binary build makes a:+i a little worse ;)
[06:19] <poolie> could someone please sponsor merging of https://code.launchpad.net/~mbp/launchpad/dkim/+merge/41819 for me?
[06:23] <StevenK> poolie: Sure, let me toss at ec2 for you
[06:24] <poolie> thanks
[07:36] <lifeless> poolie: I'll be in syd tomorrow through sunday early avo
[07:36] <poolie> oh, really?
[07:36] <poolie> can come over if you want
[07:37] <poolie> will just check with s
[07:37] <poolie> got to go now
[07:39] <lifeless> ciao
[08:20] <jtv> Anyone else getting test failures on db-devel?  I just saw a whole lot of tests for the ec2 script itself fail.
[08:50] <bigjools> morning all
[08:56] <adeuring> good morning
[09:11] <mrevell> Morning
[09:24] <lifeless> wgrant: http://panospace.wordpress.com/2010/11/24/thank-you-sourceforge-hello-launchpad/
[09:28] <wgrant> lifeless: I was with it until "The web interface is light"
[09:31] <lifeless> wgrant: forest for the trees ;)
[09:31] <lifeless> wgrant: have you used the SF tracker recently? or jira?
[09:33] <bigjools> anyone seen stub?
[09:33] <wgrant> lifeless: The project I worked on at uni used to use SF's tracker... we moved it to LP.
[09:33] <wgrant> lifeless: So I haven't used it in a year or so. But I recall it was pretty damn awful.
[10:09] <mkanat> I think I'd say that SF's tracker is the worst I've used.
[10:10] <mkanat> It's too bad, really. SF, I think, was probably the only site that had the potential to be THE site, where every open source project could or would have hosted their stuff.
[10:10] <mkanat> It just wasn't very good.
[10:23] <henninge> jelmer: Hi!
[10:23] <jelmer> henninge: hi
[10:24] <henninge> jelmer: last Friday night I merged our recife feature branch into db-devel
[10:24] <henninge> now we have to roll back that merge unfortunately
[10:24] <henninge> and two others that landed on db-devel after it.
[10:24] <jelmer> henninge: Ah
[10:25] <jelmer> henninge: Thanks for the heads up, you need me to reland my branch?
[10:25] <henninge> jelmer: not sure, I'd like to ask your help on the procedure.
[10:26] <henninge> This is more a bzr question, actually.
[10:26] <jelmer> henninge: ah, ok
[10:26] <henninge> jelmer: actually, I don't think anybody else's branches need to be re-landed.
[10:27] <henninge> So we'd roll back the changes by reverse-merging those revisions in db-devel.
[10:27] <henninge> but we also want to use our feature branch again.
[10:27] <henninge> the feature branch is based on db-stable and has had it merged into it regularly.
[10:28] <henninge> We'd plan to continue that while we still work on it.
[10:28] <henninge> The question is: At one point we will merge db-stable into recife and it will contain that roll-back revision.
[10:29] <henninge> I'd expect that to clean out all of our feature from the feature branch.
[10:29] <henninge> How do we get around it?
[10:29] <henninge> Would it be okay to simply not merge that revision from db-stable?
[10:29] <henninge> jelmer: can you follow? ;)
[10:30] <jelmer> henninge: yeah :)
[10:30] <henninge> (feature branch == recife branch)
[10:31] <jelmer> You can't really not merge that revision from db-stable
[10:31] <jelmer> but what you could do is mark that revision as merged but not take any of its changes ("bzr merge"; "bzr revert .")
[10:32] <henninge> ah!
[10:32] <henninge> I have done that before but thought it would remove any trace of the merge from the branch.
[10:33] <henninge> So, it leaves a "merged revision X" mark on the target branch?
[10:33] <jelmer> The "." is important because it means the pending merges are still remembered. "bzr status" should still show them.
[10:33] <henninge> so "bzr revert ." is different from "bzr revert" at that point?
[10:34] <jelmer> henninge: Yeah (arguably a bit of a UI bug in Bazaar)
[10:34] <henninge> I see. Yeah, I would have missed that.
[10:34] <henninge> jelmer: thanks, that is exactly what we need, then.
[10:43] <wgrant> bigjools: The getFileByName bug that let the dupe linux orig.tar.gz into hardy.
[10:43] <bigjools> wgrant: but only if it was deleted from disk, right
[10:44] <bigjools> wgrant: the dude has copied two versions at the same time
[10:44] <bigjools> ah, I see, his source PPA had conflicting orig files....
[10:48] <wgrant> Exactly.
[10:48] <wgrant> It can't cause a PFOE itself.
[10:48] <bigjools> yeah
[10:48] <wgrant> A new pub of the old one has to be created.
[10:48] <bigjools> did you see my fix BTW?
[10:49] <wgrant> Was there one?
[10:49] <bigjools> https://code.launchpad.net/~julian-edwards/launchpad/upload-file-conflict-bug-663562/+merge/42264
[10:51] <wgrant> bigjools: Is the archive ever None?
[10:52] <bigjools> yes, in a  very tiny corner case
[10:52] <bigjools> partner....
[10:52] <wgrant> Where partner doesn't exist?
[10:52] <bigjools> the lovely partner
[10:52] <wgrant> Kill it.
[10:53] <wgrant> That fix looks fine.
[10:53] <wgrant> Can you remove Distribution.getFileByName?
[10:53] <bigjools> not looked tbh
[10:53] <wgrant> I recall there were only a couple of callsites.
[10:53]  * wgrant looks.
[10:54] <wgrant> (I investigated on my view extermination campaign)
[10:56] <wgrant> bigjools: That same bug exists in PackageUploadSource.verifyBeforePublish.
[10:56] <wgrant> bigjools: And the only other callsite is in SyncSource, and it can be adjusted the same way.
[10:57] <bigjools> yeah
[10:59] <wgrant> I have to wonder about the sanity of triplicating that logic.
[11:01] <bigjools> wgrant: ignorance, no doubt.  And will it get any better with the team change ....
[11:01] <wgrant> :D
[11:12] <bigjools> wow, all builder queues are empty
[11:14] <wgrant> Even powerpc?
[11:14] <wgrant> Hm, indeed.
[11:14] <bigjools> doko wants to do a rebuild
[11:14] <wgrant> doit
[11:14] <bigjools> including universe
[11:14] <wgrant> We need to test.
[11:15] <wgrant> Although I'd like to get a daily builds session through the async download code first, I guess.
[11:31] <jtv> henninge: my rollback branch is still pushing at lp:~jtv/launchpad/recife-rollback-10-12.  I gather you've been able to extract the secrets from jelmer.
[12:02] <deryck> Morning, all.
[12:34] <jml> bigjools: hi. just finishing something up. won't be long.
[12:51] <jml> bigjools: re StevenK's database patch... we are building a linked list structure into SPPH?
[13:00] <wgrant> jml: It's a tree of pain, not a linked list, but yes.
[13:01] <jml> ... because many things can have the one parent, I see.
[13:01] <wgrant> In the case of a copy, yeah.
[13:12] <StevenK> jml: Has wgrant answered your questions?
[13:13] <StevenK> wgrant: Tree of pain? :-(
[13:13] <wgrant> There will be pain. But it won't be our problem any more :)
[13:37] <deryck> *sigh* I continue to have failure at landing this lazr-js upgrade.
[13:39] <deryck> gary_poster, would love a moment of your time when you're available.
[13:42] <jml> StevenK: no he has not, see the MP.
[13:51] <StevenK> jml: Commented.
[13:53] <james_w> salgado, hi. Did you look at exposing blueprint-bug links by any chance?
[13:54] <salgado> james_w, nope, do you want me to?
[13:55] <maxb> Where are the buildds supposed to get their bzr-builder for recipe builds from these days?
[13:55] <maxb> I am asking because of bug 682941
[13:55] <_mup_> Bug #682941: no such option --append-version in recipe build <Launchpad Bazaar Integration:Confirmed> <https://launchpad.net/bugs/682941>
[13:55] <bigjools> jml, sorry was at lunch.  Hope you got your questions all answered.
[13:56] <james_w> salgado, it's the only thing missing to port the current collect script to the API. If you could give it a quick look with me that would be great.
[13:56] <james_w> salgado, Specification implements(lp.bugs.interfaces.buglink.IBugLinkTarget)
[13:57] <salgado> james_w, you don't need to be able to create new links, right?  Just reading existing ones should be enough?
[13:57] <james_w> and that interface has a bugs attribute that looks like it is what we want to export, but as the interfaces aren't linked will doing the expose be enough?
[13:57] <james_w> salgado, for this use case, yes
[13:59] <salgado> james_w, what do you mean by interfaces are not linked?
[13:59] <james_w> salgado, ISpecification doesn't inherit from IBugLinkTarget
[13:59] <james_w> salgado, does the webservice code traverse the model to see what it implements too?
[13:59] <salgado> oh, good question
[13:59] <salgado> I think it does
[14:00] <salgado> but we'd need to export IBugLinkTarget
[14:00] <salgado> just like we export ISpecificationBranch
[14:03] <salgado> yeah, that should be everything needed to export .bugs
[14:05] <salgado> james_w, would you like me to do that?  should be quick
[14:06] <james_w> salgado, I have a test written, but I forgot that I hadn't set up an LP dev environment on this machine yet, so it's taking me a while to get to actually running it :-)
[14:06] <james_w> salgado, if you think it's just a few minutes I'm happy for you to take over, but I can keep plugging away at it
[14:08] <salgado> james_w, whatever you prefer.  I'd expect a bit more than a few minutes to get something landable, but it should be faster as a quick hack for you to test
[14:14] <james_w> salgado, ok, I'll keep going at this, as it will be useful for me to have a working LP dev environment again. I'll let you know if I hit any roadblocks.
[14:14] <salgado> ok
[14:15] <james_w> thanks for the help
[14:16] <salgado> np
[14:17]  * salgado breaks for lunch
[14:20] <gary_poster> deryck, hey, pong, though other things going on
[14:24] <deryck> gary_poster, hey, just finishing standup now myself
[14:25] <gary_poster> cool
[14:27] <deryck> gary_poster, off now.  So my lazr-js upgrade gets the same error again.  and it builds locally -- i.e. python setup.py build -- just fine....
[14:28] <deryck> gary_poster, however python setup.py --version reports 1.5DEV and versions.cfg expects 1.5DEV-r190.  Could this be the issue?
[14:28] <gary_poster> deryck, remind me the error please?  can't quite place it
[14:28] <deryck> gary_poster, I'll forward you an email if that's ok.  basically just "failed to build" or some such.
[14:29] <gary_poster> sure, deryck .  and yes, that sounds suspicious
[14:29] <deryck> gary_poster, mail sent
[14:29] <gary_poster> ack
[14:30] <deryck> gary_poster, is there something I can do locally to make my build *just* like what pqm tries to reproduce this?  Feels a bit hit or miss to hack a new tarball, fire off to pqm, rinse/repeat
[14:32] <gary_poster> deryck: if your download-cache is pristine and like the upstream, you should be good to go for testing locally as long as your eggs have not been messed up by hacking.  if you cd into your download-cache and run bzr status, what does it report?  Also, does bzr info look like http://pastebin.ubuntu.com/538665/
[14:33] <gary_poster> deryck: if bzr status is clean and bzr info is similar, then I suggest wiping out the lazr-js egg(s) from your eggs directory and rerunning bin/buildout
[14:33] <gary_poster> at that point, if you haven't duped, I'll be surprised
[14:33] <deryck> gary_poster, bzr st reports nothing, and yes, my bzr info reports that same as your paste.  bzr log -l 1 shows my commit to add the current lazr-js tarball.
[14:33] <deryck> gary_poster, ok, I'll try that.  thanks!
[14:34] <gary_poster> np, lemme know
[14:36] <jml> do we have an end-to-end overview of our dev process?
[14:42] <gary_poster> I don't recall ever seeing one, jml.
[14:43] <jml> gary_poster: ta, I might have to make one then.
[14:43] <gary_poster> sounds good jml :-)
[14:43] <jml> flacoste, mrevell: just making a cup of tea before the standup. will be a tiny bit late.
[14:44] <mrevell> jml, np
[14:55] <deryck> gary_poster, it worked fine.  weird.  https://pastebin.canonical.com/40332/
[14:55] <deryck> bac, appologies but I won't be able to make reviewer meeting today.
[14:58] <gary_poster> deryck: very weird.  only other possibility I can think of is that there's a built egg on pqm and lazr-js had two revisions with the same name or something...
[14:58] <gary_poster> deryck: I'll try to build locally in a min
[14:58] <deryck> gary_poster, ok, thanks!
[14:58] <gary_poster> deryck: to be clear, the pqm hypothesis seems pretty unlikely to me.  I think we wipe out built eggs on pqm
[14:59] <gary_poster> between builds
[14:59] <deryck> ah
[14:59] <deryck> hmm, yeah, that's weird.
[14:59] <jml> mrevell: http://pastebin.ubuntu.com/538678/
[14:59] <deryck> gary_poster, so I could do a hand-code version string in the setup.py and ensure that matches and try again.  if so, I can commit to lazr-js then.
[15:00] <bac> meeting ping: abentley, adeuring, allenap , bac, benji, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jcsackett, jtv, bigjools, leonard, mars
[15:00] <deryck> where, if so == it pqm build works
[15:00] <bac> deryck: ok
[15:00] <flacoste> bac: apologies from me
[15:00] <jtv> bac: anon!
[15:03] <LPCIBot> Yippie, build fixed!
[15:03] <LPCIBot> Project devel build (264): FIXED in 4 hr 2 min: https://hudson.wedontsleep.org/job/devel/264/
[15:04] <gary_poster> deryck: I have been under the impression that the lazr-js egg does some funky things (possibly because it is trying to build js resources in a Python packaging world, dunno).  In any case, buildout/setuptools/distribute typically is just fine with the -r stuff that setuptools/distribute produces
[15:05] <gary_poster> so it's worth a try, but still pretty mysterious
[15:16] <LPCIBot> Project db-devel build (179): STILL FAILING in 4 hr 5 min: https://hudson.wedontsleep.org/job/db-devel/179/
[15:26] <gary_poster> deryck, I think I have a clue
[15:26] <mars> flacoste, ping, I have a question about the simplified merge machinery tracking
[15:26] <gary_poster> deryck: (that comes after discovering that it also worked for me)
[15:26] <deryck> gary_poster, ok, awesome.  on call now....
[15:31] <gary_poster> deryck: call: ack.  Clue from your failure email: "Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.10.tar.gz".   Distribute is not included it our download-cache, and I expect that it is included on most/all dev machines but not on pqm.
[15:31] <gary_poster> Core problem IMO: lazr-js explicitly depends on distribute.  I think this is a bad idea, because it unnecessarily excludes setuptools users.  In contrast, specifying setuptools *includes* distribute.  My suggested fix is to change lazr-js's setup.py to require setuptools, not distribute.
[15:31] <gary_poster> Other possible fixes are to include distribute in the download cache or to make pqm have distribute.  Maybe those are also good ideas, but specifying distribute seems unnecessarily antagonistic to setuptools to me.
[15:31] <bigjools> abentley: I just noticed that recipe builds are ending up with a buildqueue score of 2605 on dogfood.  Is that intentional?
[15:32] <abentley> bigjools: I haven't changed anything related to that.  I expect them all to be 2505 ATM.
[15:33] <bigjools> ok
[15:39] <flacoste> mars: what's the question?
[15:45] <james_w> leonardr, hi. We have a case where we want to export bugs on IBugLinkTarget for blueprints. ISpecification doesn't inherit from that, Specification just implements() it. Just exporting IBugLinkTarget doesn't seem to be enough. Do you have any advice on how to proceed?
[15:45] <deryck> gary_poster, thank you.  A very clear analysis that helps me understand.  I'll look into why lazr-js requires distribute and fix if possible.
[15:48] <deryck> rockstar, ping.  do you know why we require distribute explicitly for lazr-js, instead of just using setuptools?
[15:53] <deryck> hmmm
[15:53] <deryck> gary_poster, so I see a merge that led to this -- https://code.launchpad.net/~sidnei/lazr-js/newer-buildout/+merge/21417
[15:54] <deryck> gary_poster, how would you feel about me temporarily adding distribute to download-cache, and opening a bug against lazr-js for this?
[15:54] <deryck> since I'm not sure why we went this way in the first place.
[15:57] <gary_poster> deryck: on call
[15:57] <deryck> ack
[16:08]  * deryck needs to eat
[16:17] <rockstar> deryck[lunch], the distribute thing is a big reason why I want to kill the build system in lazr-js.
[16:18] <rockstar> It always either Just Works for landscape or for Launchpad, but never both at the same time.
[16:25] <bigjools> jtv: can you remind me where to look to see finished translations template jobs?
[16:26] <jtv> bigjools: errr didn't they get cleaned up?
[16:26] <bigjools> jtv: I am just QAing on dogfood, I want to make sure the job finished
[16:26] <jtv> Anyway I don't have database access now so I'm falling out of touch with the schema.
[16:26] <jtv> It's job type 6 IIRC; let me check.
[16:27] <bigjools> jtv: there was a page I could go to to see the template?
[16:27] <bigjools> 4 actually
[16:27] <bigjools> jtv: I need a page, not a query :)
[16:27] <jtv> Ah.  One of the job types for this class was 4 and the other 6, and I always forget which is which.
[16:27] <jtv> Try the import queue page for the productseries.
[16:28] <jtv> https://translations.dogfood.launchpad.net/test_product/test_series/+imports
[16:28] <jtv> If the job completes successfully, you'll see a template upload appear there, owned by "VCS Imports."
[16:29] <jtv> This last bit is significant; if the branch contains a template file, that one will also show up (probably earlier) under the identity of, if I remember correctly, the person who committed to the branch.
[16:29] <bigjools> ok, thanks
[16:29] <jtv> Since there's no importer running on dogfood, the queue entry will be in Needs Review state.
[16:30] <bigjools> I see the one I did last time we talked but not the one I just did :/
[16:30] <jtv> Don't blindly trust the date on the entry; if there was already a previous upload with the same path, productseries, and uploader, it will go into the existing entry without updating its creation date.
[16:30] <jtv> So try opening the link to the file itself (<something>.pot) and reading the POT header inside the file.
[16:30] <jtv> It'll have a timestamp.
[16:33] <bigjools> jtv: aha, that's it
[16:33] <bigjools> thanks
[16:33] <jtv> no worries
[16:34] <bigjools> I was panicking for a while about competing jobs on a single builder until I realised that the translations job creation script sends them to a nonvirtual builder by default!
[16:39] <gary_poster> rockstar: do you have time for a five min call?  I'll even set a timer if you want :-)
[16:40] <gary_poster> deryck[lunch]: the distribute thing is a pain; I had completely forgotten about sidnei's branch.  If putting distribute in the download-cache works, I guess that's ok, though it makes me unhappy.  Whatever--if you can move on with this landing, it's not that big of a cost.
[16:54] <deryck> gary_poster, ok, thanks.  I'll add to download-cache to unblock me, and then follow up with a bug and discussions to see if we can fix lazr-js.
[16:54] <deryck> well, scrollback suggests rockstar is going to fix it anyway.
[16:55] <gary_poster> Cool deryck.  yeah, but rockstar has approx 1000000 things on his plate AFAIK. :-)
[16:55] <rockstar> deryck, and by fix, you mean "destroy with a firey passion"
[16:55] <rockstar> gary_poster, yes, yes I do, but lazr-js is on the official plate, rather than the unofficial plate.
[16:55] <deryck> gary_poster, yes, but see "firey passion" above ;)
[16:55] <gary_poster> :-)
[16:56] <gary_poster> rockstar: you cleverly showed up at the time when I only have four min
[16:56] <gary_poster> quick call now?
[16:56] <gary_poster> like, three min :-)
[16:56] <rockstar> gary_poster, pots?
[17:07] <lifeless> jml: hi
[17:27] <lifeless> abentley: hi
[17:27] <abentley> hi.  in TL meeting
[17:27] <lifeless> https://dev.launchpad.net/PolicyAndProcess/ReleaseManagerRotation?action=diff
[17:27] <lifeless> abentley: a tweak to your edit, FYI/clarity.
[17:27]  * lifeless goes to hop on a plane
[17:27] <lifeless> I hope its clear.
[17:27] <lifeless> ciao
[17:33] <sinzui> flacoste, benji-lunch, gary_poster ping
[17:33] <flacoste> hi sinzui
[17:34] <gary_poster> sinzui: hi
[17:35] <sinzui> IHugeVocabulary requires a displayname for the picker. I think we need to provide a step_title too since UI testing revealed users were not sure what would be matched
[17:35] <gary_poster> sinzui: I was also going to try and ping you about the question I gave you yesterday.  Trying to get it again
[17:35] <deryck> dear lazr-js, I like you, do you like me? check one.  [  ]yes  [x]no [  ]maybe
[17:35] <gary_poster> lol
[17:36] <gary_poster> sinzui: I'm not clear yet on what a step_title would be
[17:36] <sinzui> This is certainly the case with the two vocabularies I have changed. I ponder changing all implementers to provide the generic "Search" we see now, but my branch would be smaller if I could just add the attr to the vocabularies I care about
[17:36] <sinzui> I am not sure how to add a readable attr to just a few vocabs. They are secured utilities
[17:38] <sinzui> gary_poster, When you see a picker, you might read "Add a member", and the smaller text says "Search" But it does not say that only teams, or only public teams will be matched
[17:39] <sinzui> gary_poster, flacoste. I am trying to avoid duplicating the text in 3 many places in our code.
[17:39] <gary_poster> sinzui: OK, I think I understand.  I don't quite see how the term "step_title" comes from that, but not going to worry about it.  So, no, you won't be able to add titles to just a few.  I would be tempted to add "Search" to the class
[17:39] <gary_poster> expose it
[17:39] <gary_poster> override it on instance
[17:39] <gary_poster> and be done
[17:40] <gary_poster> that seems simplest on the face of it.  is there a reason that is a bad idea?
[17:40] <gary_poster> or, problematic, or whatever
[17:40] <sinzui> gary_poster, step_title is indeed bad. The picker assume there are one or more steps to complete an action.
[17:40] <gary_poster> I see
[17:42] <sinzui> gary_poster, it inflates my diff by 150 lines, and only my vocab will use it. I could expand scope to change hoe the picker works `step_title = getattr(vocab, 'step_title', 'Search')`
[17:43] <gary_poster> sinzui, but then you have to expose the attribute on security or rip off security wrappers and so on, right?
[17:44] <gary_poster> if you already have the 150 line diff, I am in favor of the additional lines.  If you don't have it already, then I can see the value of more discussion
[17:45] <sinzui> gary_poster, I /think/ that I need to add it to the interface so that the views can access the attr
[17:46] <sinzui> gary_poster, given that the is used to vocab is build javascript, I do not want to consider removing the security wrapper
[17:47] <sinzui> gary_poster, sorry about the bad typin
[17:47] <sinzui> g
[17:47] <sinzui> :(
[17:47] <gary_poster> sinzui, add to interface: right, since that's usually what we use in the zcml to specify the proxies.  But if you have to do that, conceptually that means that you are saying the attribute will exist.  Maybe that's a niggle, but I must admit that it is how I feel about it.
[17:48]  * gary_poster types poorly most of the time.  never learned how to do it properly, and now is reasonably fast the wrong way
[17:48] <gary_poster> sinzui, btw, this is what I wrote you yesterday.  I have to go to do some things over lunch at 1 PM, and we should finish this conversation now, but maybe we can talk about itthis afternoon.
[17:48] <gary_poster> could you take a look at https://bugs.launchpad.net/canonical-identity-provider/+bug/556680 for me and then talk with me?  I'm hoping you will have some brilliant insight, or at least that you will agree with Anthony's analysis and be able to help me come up with an actionable plan for his description of "let Launchpad refuse an account when it tries to sign in, it it notices it's related to a team Person."
[17:48] <_mup_> Bug #556680: attempting to create a new account with an existing email address at login.ubuntu.com oopses after you follow the email link back to create the name/password <isd-logging-sprint> <Canonical SSO provider:Incomplete by stuartmetcalfe> <Canonical ISD QA:New> <https://launchpad.net/bugs/556680>
[17:48] <sinzui> okay, I will continue on the path of exposing a new attr
[17:48] <gary_poster> ok
[17:49] <gary_poster> sinzui: the other option is an adapter, but that seems a bit heaviweight.  But it might have the characteristics you are looking for
[17:49] <gary_poster> implementation:
[17:49] <gary_poster> well, you can come up with an implementation
[17:50] <gary_poster> Maybe I have too high a barrier in my mind for when an adapter makes sense these days
[17:51] <gary_poster> it feels a little heavy
[17:51] <sinzui> gary_poster, yes. I am looking for the minimal amount to work to close a security issue
[17:51] <gary_poster> I see
[17:51] <gary_poster> then
[17:51] <sinzui> I happen to know there is a UI issue too
[17:51] <gary_poster> You could
[17:51] <gary_poster> - have the widget try to adapt the vocab to the other interface
[17:52] <gary_poster> - if it can't be adapted, use "Search"
[17:52] <gary_poster> - if it can be adapted, use the value
[17:52] <gary_poster> - make your other vocab implement the other interface directly so it is a no-op and involves no other classes and stuff for you to write
[17:53] <sinzui> gary_poster, Yes. I fear that if someone like flacoste were to review the branch, he would point out we already have an interface for that...IHugeVocabulary
[17:53] <sinzui> gary_poster, as to the other bug. We do not allow users to reuse team bugs.
[17:53] <gary_poster> sinzui, right, that's kind of why I thought an adpater was too heavy
[17:53] <sinzui> I think that is the underlying surprise in the bug
[17:54] <gary_poster> sinzui: "We do not allow users to reuse team bugs." -> "We do not allow users to reuse team emails." ?
[17:54] <sinzui> yes, I mean emails, I think our email rules are broken
[17:54] <gary_poster> I see
[17:55] <sinzui> so I typed bug
[17:55] <gary_poster> :-)
[17:55] <gary_poster> So..."let Launchpad refuse an account when it tries to sign in, it it notices it's related to a team Person." -> we do this already?
[17:55] <sinzui> gary_poster, I believe Lp
[17:56] <sinzui> gary_poster, I believe Lp's email rules account for taken addresses. Registration did too. I think the rule was lost in translation to Django
[17:59] <sinzui> gary_poster, I think the bug is making a leap issues. The bug starts by talking about ubuntu, then later I see Lp mentioned. Lp can never let someone authenticate as a team. It should never let someone authenticate if there is no preferred address
[18:00] <gary_poster> sinzui: ack.  I *think* the connection is this:
[18:00] <sinzui> gary_poster, but is Lp really an issue here? I know Ubuntu got the email address from Lp. IT might get emails from other systems...like forums.ubuntu.com. I think ubuntu needs to check that the email address is available, and inform the user that is it not
[18:01] <gary_poster> - SSO used to check with LP for used emails, and team emails
[18:01] <gary_poster> - now they don't because, as Anthony Lenton writes, "we're not receiving updates for the emailaddress table."
[18:01] <gary_poster> - or maybe they do, but the data is old
[18:02] <gary_poster> - so they want to remove those constraints entirely on their side AIUI
[18:02] <gary_poster> - And then we need to make sure that we don't allow people to authenticate if the preferred email from SSO is a team email on our side
[18:02] <gary_poster> Which seems like a really bad UI  on our side :-(
[18:03] <gary_poster> which inherently comes from the two systems being separate
[18:03] <gary_poster> I'm inclined to say that we treat the SSO email as a hint
[18:04] <gary_poster> because when we switch to accepting any openid provider, which AIUI is in the cards, we won't care about their email unless we use it as a trusted, verified email source
[18:04] <gary_poster> '
[18:05] <gary_poster> sinzui, I have to go run do lunch things.  Any quick thoughts on the above, or should we try to continue later this afternoon?
[18:06] <sinzui> gary_poster, This scenario is familiar. I think it is like debian package uploaders. We know their addresses and we might know they are teams. but some users what to *become* the team in Lp for certain operations. We reject the notion.
[18:06] <gary_poster> I see
[18:06] <gary_poster> So let me rephrase
[18:08] <sinzui> gary_poster, have lunch. ping me when you are available. I think we do care about email and we can talk on mumble
[18:09] <gary_poster> - if a user comes in with an openid we've seen before, we go to that user.  If there has been craziness and Launchpad now thinks that their preferred email is actually owned by a team, whatever, that's fine: they will never log in as that team, only as the user that we've already identified with that openid.
[18:09] <gary_poster> - if a *new* user comes in from SSO with a preferred email that is a team's, we should reject the user creation.  That's the important thing here.
[18:09] <gary_poster> OK thanks sinzui, will do
[18:09] <gary_poster> I'll ping you later
[18:09]  * gary_poster linches
[18:09] <gary_poster> heh
[18:09] <gary_poster> lunches
[18:10] <benji> gary_poster: heh
[18:50] <rockstar> matsubara, ping
[18:51] <matsubara> hi rockstar
[18:51] <rockstar> matsubara, could you join #tarmac ?
[18:58] <LPCIBot> Yippie, build fixed!
[18:58] <LPCIBot> Project db-devel build (180): FIXED in 3 hr 42 min: https://hudson.wedontsleep.org/job/db-devel/180/
[18:58] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12001,
[18:58] <LPCIBot> 12002, 12003, 12004, 12005, 12006 included.
[19:43] <gary_poster> deryck: do you object to me making a branch of lazr-js that does not depend on distribute?
[19:44] <deryck> gary_poster, not at all.  I have no objections.
[19:44] <gary_poster> deryck, then I would make a local release, and merge that.
[19:44] <deryck> gary_poster, I was hesitant to do that not knowing the impact to landscape and not having sidnei around to ask.
[19:44] <gary_poster> deryck, I would fork for now
[19:44] <deryck> gary_poster, ah, right.
[19:44] <deryck> gary_poster, sure, sounds like a good plan to me.
[19:44] <gary_poster> ok
[19:45] <deryck> gary_poster, will you submit to pqm, or just make the tarball and I will submit?
[19:45] <gary_poster> deryck: so, I just want bzr branch lp:lazr-js, right?
[19:45] <deryck> gary_poster, right
[19:45] <gary_poster> ok.  I'll submit deryck.  I'm pretty optimistic that this is the problem.
[19:46] <gary_poster> famous last words :-P
[19:47] <deryck> heh
[19:47] <deryck> gary_poster, I agree the log looks like this is it.
[19:47] <gary_poster> cool
[19:48] <deryck> gary_poster, and thanks so much for the help!
[19:48] <gary_poster> deryck, I figure somebody else should help you with the pain :-/
[19:58]  * gary_poster is confused, deryck.  I see "install_requires=['setuptools',]," in setup.py.  not clear on why distribute is included when you make an egg yet
[19:59] <deryck> gary_poster, yeah, I don't understand either.
[19:59] <mars> gary_poster, check lazr-js versions.cfg (if it has one)
[19:59] <gary_poster> lazr-js's buildout and Makefile specify distribute, but that's nothing to do with when you actually build the egg
[19:59] <deryck> gary_poster, well, there is the distribute_setup that is imported, if that's what you mean
[19:59] <gary_poster> mars, that won't be run, but deryck, that must be it!
[20:00] <gary_poster> mars, versions.cfg will affect buildout, but not when the egg is built
[20:00] <mars> right
[20:00] <deryck> setup.py imports distribute_setup
[20:00] <gary_poster> right
[20:00] <gary_poster> that might be it
[20:01] <gary_poster> meh, distribute vs setuptools is yucky :-(
[20:01] <deryck> and it just uses setuptools, so I don't see why we can't just use setuptools.
[20:01] <deryck> right, I don't get it, gary_poster  ;)
[20:12] <gary_poster> deryck: http://pastebin.ubuntu.com/538783/ ?  Do you have lazr-js review privs?  If so, want me to try to land that?
[20:12] <gary_poster> deryck, argh, my first comment is backwards
[20:13] <deryck> gary_poster, right.  we do prefer the local tools right?
[20:13] <gary_poster> deryck, the term "local" is not clear.  I did this, but it is still confusing
[20:13] <gary_poster> http://pastebin.ubuntu.com/538784/
[20:13] <gary_poster> I think it is good enough though ;-)
[20:14] <deryck> gary_poster, yup, r=me.  land away.
[20:14] <gary_poster> ok thanks deryck
[20:15] <gary_poster> deryck: meh, what's the pqm dance for this?  I can figure it out, but if you have a cheat-sheet I'll go faster :-{
[20:15] <gary_poster> :-P
[20:17] <deryck> gary_poster, I just do bzr pqm-submit from lazr-js and have my locations.conf set.
[20:17] <gary_poster> deryck, ack
[20:17] <deryck> gary_poster, I can send you my locations.conf section
[20:17] <deryck> if that helps
[20:18] <gary_poster> deryck: s'ok, I'll just use command line for now.  thank you
[20:18] <deryck> gary_poster, np
[21:09] <wallyworld> abentley: quick chat?
[21:16] <gary_poster> deryck: still here?
[21:17] <deryck> gary_poster, hey, yup.
[21:19] <gary_poster> cool deryck.  So, lazr-js merged.  I have a 191 lazr-js sdist locally.  I have a LP branch that is merged with devel and has uses the new sdist.
[21:19] <gary_poster> I don't have a review;
[21:19] <gary_poster> I am not sure about whether pqm is open
[21:19] <gary_poster> I guess it must be
[21:19] <gary_poster> I just heard mutterings that confused me
[21:20] <deryck> gary_poster, you can *not* merge with devel.  You (or I) need to merge with my branch...
[21:20] <deryck> gary_poster, lazr-js is using yui 3.2 now and requires lp changes to work.
[21:21] <gary_poster> deryck: oh...I'm confused.  I took devel, merged your branch, and committed.  That was when I was seeing if I could dupe the problem.
[21:21] <gary_poster> deryck, then I just upped the version in versions.cfg
[21:22] <deryck> ah ok
[21:22] <deryck> gary_poster, I didn't realize you had merged my branch.  That should work then.
[21:22] <gary_poster> deryck: you want to do the honors, since otherwise I have to get reviews and stuff, and I made things confused mby merging devel?
[21:22] <gary_poster> uh-oh
[21:22] <gary_poster> you have lazr-js 1.5.1DEV
[21:23] <gary_poster> I'm adding lazr-js 1.5DEV-r191
[21:23] <gary_poster> do you care?
[21:23] <gary_poster> do we care?
[21:23] <deryck> gary_poster, right, I can change to the sdist you added to download cache.  doesn't matter.
[21:23] <gary_poster> :-) ok
[21:23] <deryck> gary_poster, so to be clear... :-)
[21:23] <deryck> gary_poster, I'll update my branch with this new version of lazr-js and land it.  right?
[21:24] <deryck> update in versions.cfg, I mean
[21:24] <gary_poster> deryck: right.  Here's hoping.  lazr-js = 1.5DEV-r191.
[21:24] <deryck> alright.  thanks, gary_poster!
[21:25] <gary_poster> deryck: I'll accept the thanks if it works, deryck ;-)
[21:25] <deryck> heh, fair enough
[21:29] <deryck> sent to pqm.  we'll know shortly.
[21:29] <gary_poster> cool
[21:29] <gary_poster> sinzui: ok, until informed otherwise, I think I'm open for a call about that email thing whenever you are (but no rush also)
[21:29] <sinzui> okay
[21:32] <jcsackett> leonardr: i'm trying to create an anonymous launchpadlib connection in a test, but all my attempts come back with a server based on a newInteraction while another interaction is active.
[21:32] <jcsackett> any thoughts?
[21:32] <leonardr> jcsackett: i think you should talk to salgado, who just did a branch for this
[21:33] <jcsackett> alas, he is afk.
[21:33] <jcsackett> salgado-afk: when you return, if you have time i could use some help with the above.
[21:34] <wallyworld> abentley: http://people.canonical.com/~ianb/recipe-related-branches.png
[21:35] <leonardr> jcsackett: he ended up adding a new helper method, if that helps
[21:35] <jcsackett> leonardr: it gives me something to look for, at least. thanks!
[21:45] <salgado-afk> jcsackett, yeah, I've seen that too.  had to endInteraction() before calling my helper method
[21:49] <jcsackett> salgado-afk: what's your helper called?
[21:49] <abentley> wallyworld: https://launchpad.net/thekraken
[21:50] <salgado-afk> jcsackett, launchpadlib_for_anonymous
[21:51] <jcsackett> salgado-afk: is that merged?
[21:51] <salgado-afk> jcsackett, yes, as of a couple hours ago
[21:51] <jcsackett> well, i'll just update then--i was writing the exact same method. :-p
[21:51] <jcsackett> thanks!
[22:09] <deryck> gary_poster, success!  hurrahs heard round the world!
[22:09] <gary_poster> deryck: HURRAH!
[22:10] <deryck> and with that, I shall away. ;)
[22:10] <gary_poster> :-)
[22:10] <deryck> gary_poster, thanks again for the help today!
[22:10] <gary_poster> np deryck :-)
[22:17] <rockstar> \o/ New lazr-js has landed!
[22:20] <LPCIBot> Project devel build (266): FAILURE in 3 hr 39 min: https://hudson.wedontsleep.org/job/devel/266/
[22:20] <LPCIBot> * Launchpad Patch Queue Manager: [r=jelmer][ui=none][bug=683106] Add a launchpad.View security adapter
[22:20] <LPCIBot> for ISpecification so that collections of it can be exposed on
[22:20] <LPCIBot> the API for anonymous users.
[22:20] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=60055] Removes unused and untested parameters
[22:20] <LPCIBot> from ProjectGroup.search
[23:30] <wgrant> Grah.
[23:31] <wgrant> canonical-launchpad@l.c.c hates me :(
[23:31] <spm> wgrant: nah. that's the filter I put on for you t'other month. was feeling bored.