/srv/irclogs.ubuntu.com/2010/12/01/#launchpad-dev.txt

mkanatpoolie: The launchpad loggerhead branch is still named devel, though, it looks like.00:00
poolieok00:02
poolieso istm we will stick with the 1.18 branch on launchpad for the medium term00:03
poolieso i'd like you to concentrate your efforts on things that can go into that00:03
mkanatpoolie: 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
pooliethumper: ^^ agree?00:03
mkanatpoolie: Well, I think you might need to be more specific than that.00:04
poolieperhaps i should nominate particular bugs?00:04
mkanatpoolie: Well, perhaps, but are we shifting away from our original plan?00:05
mkanatpoolie: 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
mkanatpoolie: Some of these things I can backport, if in a hackish fashion, though.00:05
mkanatpoolie: 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:06
mkanatOf 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
pooliei guess this depends a bit on when we expect to do a 1.19, and how traumatic it will be00:07
james_wanybody know what's going on with http://paste.ubuntu.com/538491/ when I do a "make"?00:07
mkanatpoolie: Well, in an ideal world I was hoping to be ready for 2.0 instead of 1.19.00:07
mkanatpoolie: I'd like say of 2.0 "this will absolutely scale to launchpad size".00:07
pooliejames_w: i haven't seen that but typically it means an  update in download-cache, and then make clean make00:08
poolieit rings a bell00:08
mkanatpoolie: I'm totally with you on wanting to see these improvements on launchpad as quickly as possible, though, particularly the performance-related ones.00:08
james_woh, if you read up there are errors further back, sorry00:09
pooliejames_w: there was a thread on launchpad-dev about this last friday00:09
poolie"Fwd: failure"00:09
pooliemkanat: looking back at my mail "next steps on codebrowse" from november00:09
mkanatpoolie: 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
mkanatpoolie: I'm improving that as I go a bit, though.00:10
mwhudsonjames_w: you might need to upgrade your download-cache00:12
mwhudson(the one on lp got upgraded to 2a lately)00:12
james_wbeen through that one :-)00:12
james_wseems I'm missing libpq-dev00:12
mwhudsonah00:12
poolie"obviously" :-|00:13
mkanatpoolie: So, re: the "next steps for codebrowse" mail, those are all still totally things I'd like to focus on.00:14
mkanatpoolie: 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:15
lifelessFWIW00:17
lifelessand I really don't want to get into detail00:17
lifelessI am happy with LP running off trunk.00:17
lifelessas long as the existing process and QA are followed.00:17
mkanatlifeless: Does the LP team have a QA process for loggerhead?00:21
lifelesssame as all other changes00:21
poolieso trunk currently contains history-db etc00:21
lifelesswhich I and francis described in a thread with you a few weeks back00:21
poolierolling that out will have some operational implications00:22
poolieie it'll create different cache dbs00:22
mkanatlifeless: I really would be opposed to running trunk on LP, FWIW.00:22
lifelessif its ready for use00:22
lifelessthen its inventory we're not benefiting from.00:22
lifelessmkanat: lp itself is vastly larger and we run trunk.00:22
mkanatlifeless: LP also has a reasonable test suite and FAR more development effort available.00:23
lifelesssure00:23
mkanatlifeless: 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
elmowgrant: is poppy known to spew exceptions pretty much non-stop?00:23
mkanatI'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
lifelesslp 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
elmoalternatively - how soon should I expect packages I upload to a PPA to appear in the webUI?00:24
poolieelmo: 5-10m00:24
poolie(unauthoritative answer)00:24
elmok00:24
mkanatlifeless: 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
pooliei don't think we should have non-staff on the hook00:25
pooliei talked to francis about doing a squad rotation onto loggerhead00:25
lifelessmkanat: I'm not asking for us to run trunk.00:25
lifelessmkanat: I'm being clear that I consider it an ok option.00:26
mkanatlifeless: Okay.00:26
lifelessWhen I get back from leave I'd be happy to discuss further.00:26
lifelessthats jan.00:26
mkanatlifeless: That's fine, I think that we have a plan that will work one way or another.00:27
mkanatlifeless: By January I'd like to see what's currently on trunk be stable, in any case.00:27
mkanatpoolie: 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
mkanatpoolie: And that could be 1.19.00:29
pooliein some ways that would be nice to do because it would give us an easier dry run for deploying your work to lp00:29
pooliewell, semi-wet00:29
poolieand then you don't need to backport them in a hacky way00:30
mkanatpoolie: 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
poolieright, i was just considering the idea that in some ways doing any branches is a waste of time and effort00:30
poolieat least as far as the lp deployment00:31
mkanatpoolie: Sure, except for when we are ready to actually say, "this is table".00:31
mkanat*stable00:31
mkanatpoolie: For example, so far, the 1.18 branch is very little work, and I *have* landed a fix on it.00:31
mkanatpoolie: (It just happened to be a fix that didn't affect LP.)00:32
pooliecan we keep trunk just adequately stable all the time?00:32
mkanatpoolie: 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:32
mkanatThere 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
mkanatpoolie: Also, we'd have to be sure that all reviewers required unit tests on checkins.00:33
mkanatpoolie: There would be more process involved.00:33
mkanatpoolie: I don't know if adding that sort of process to a smaller project is a good idea.00:34
poolieit may not be00:34
poolieotoh having trunk always stable does avoid some kinds of churn and waste00:34
mkanatpoolie: Yeah, it totally does. It's absolutely more efficient in many or most ways, it's just not necessarily *easier*. :-)00:34
mkanatpoolie: I'm thinking about the ideal solution.00:35
pooliethe other thing from that november thread was adding etag and http cache support00:35
mkanatpoolie: 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:36
mkanatpoolie: I think there could be some reasonable ways to do it without too much effort, for some pages, though.00:37
mkanatpoolie: 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:38
pooliei would like that too00:39
poolietwo questions:00:39
poolie1- does that make sense to do in one block, or should we do the annotation changes separately?00:39
poolie2- roughly how long elapsed/effort would it take?00:39
mkanatpoolie: 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:40
mkanatpoolie: 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:41
mkanatpoolie: 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
pooliegood00:43
pooliei'd like to keep you in the rhythm00:43
pooliei 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 deployable00:44
poolieand, in fact, deployed00:44
rockstarBLUE SQUAD!00:44
lifelessmkanat: btw00:44
pooliethen go on with other things later00:44
lifelessmkanat: if the loggerhead caches are k-v, you might consider moving to cassandra00:45
mkanatlifeless: Can the value be a tuple or a dict?00:45
mkanatpoolie: Okay, I can totally do that.00:45
lifelessmkanat: sure; I mean it serialises.00:45
mkanatpoolie: Or I could just merge the annotation changes into the LP branch.00:45
lifelessmkanat: see my posts to the lp-dev list for a summary/description00:45
poolieyeah00:45
mkanatlifeless: Is Cassandra the DB system you posted about on the list...yeah.00:45
pooliei think conceptually "here's the loggerhead branch" and "here's what lp deploys" are a bit different but it's not a big deal00:46
mkanatlifeless: I don't think we'll need that level of performance from the cache alone, at this point.00:46
mkanatlifeless: Right now we're using sqlite and it's good enough.00:46
mkanatlifeless: Although loggerhead could be a reasonable PoC for Cassandra usage, if somebody felt like doing that work.00:47
lifelessmkanat: we have no stats to show if its good enough or not00:47
lifelessmkanat: if we instrument lock latency on sqlite and various related things, then we could say that00:48
mkanatlifeless: Well, I wouldn't worry about it at this point.00:48
elmomm00:51
elmothe publisher is deadlocking00:51
pooliemkanat: in some ways i like the idea of having a separate branch for 1.19 vs the lp deployment branch00:59
poolieif only for the reviews: "i'm fixing this bug" vs "i'm deploying this block of stuff"00:59
mkanatpoolie: 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:01
poolieperhaps we should just be lazy there01:03
mkanatpoolie: That's sort of my inclination.01:03
pooliefair enough01:03
poolieyou can ping me, spiv, jam, etc, for reviews01:03
mkanatOkay, sweet.01:04
pooliethe default reviewer may not be who you want01:04
mkanatpoolie: Hmm, okay. Any recommendations for who to specify when making a new MP?01:05
poolie~bzr and ~launchpad?01:05
mkanatpoolie: Okay. I'll do ~bzr--I suspect that will get me the most likely reviewers.01:06
mkanatI'll do ~launchpad for the deployment merges, I suppose, yeah?01:07
lifelessmkanat: the default is appropriate there01:12
mkanatlifeless: Okay, will use the default then, for that.01:12
mkanatIs something up with LP right now?01:38
mwhudsonmkanat: data centre issues it seems01:39
mkanatokay01:39
wgrantThe frontends are in the other DC?01:45
mwhudsonseems so01:46
lifelessapache is in one dc01:46
lifelesssome appservers are in each01:46
lifeless=== Top 10 Time Out Counts by Page ID ===03:18
lifeless    Hard / Soft  Page ID03:18
lifeless     324 / 7217  Archive:+index03:18
lifeless     148 /  451  BugTask:+index03:18
lifeless      36 /  150  ProjectGroupSet:CollectionResource:#project_groups03:18
lifeless      19 /  296  Distribution:+bugs03:18
lifeless      18 /   13  Cve:+index03:18
lifeless      13 /  278  Distribution:+bugtarget-portlet-bugfilters-stats03:18
lifeless      11 /   38  MailingListApplication:MailingListAPIView03:18
lifeless      11 /   19  DistroSeries:+queue03:18
lifeless       9 /   16  Person:+specworkload03:18
lifeless       8 /   51  Milestone:+index03:18
lifelesswgrant: every binary build makes a:+i a little worse ;)03:19
pooliecould someone please sponsor merging of https://code.launchpad.net/~mbp/launchpad/dkim/+merge/41819 for me?06:19
StevenKpoolie: Sure, let me toss at ec2 for you06:23
pooliethanks06:24
lifelesspoolie: I'll be in syd tomorrow through sunday early avo07:36
poolieoh, really?07:36
pooliecan come over if you want07:36
pooliewill just check with s07:37
pooliegot to go now07:37
lifelessciao07:39
jtvAnyone else getting test failures on db-devel?  I just saw a whole lot of tests for the ec2 script itself fail.08:20
bigjoolsmorning all08:50
adeuringgood morning08:56
mrevellMorning09:11
lifelesswgrant: http://panospace.wordpress.com/2010/11/24/thank-you-sourceforge-hello-launchpad/09:24
wgrantlifeless: I was with it until "The web interface is light"09:28
lifelesswgrant: forest for the trees ;)09:31
lifelesswgrant: have you used the SF tracker recently? or jira?09:31
bigjoolsanyone seen stub?09:33
wgrantlifeless: The project I worked on at uni used to use SF's tracker... we moved it to LP.09:33
wgrantlifeless: So I haven't used it in a year or so. But I recall it was pretty damn awful.09:33
mkanatI think I'd say that SF's tracker is the worst I've used.10:09
mkanatIt'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
mkanatIt just wasn't very good.10:10
henningejelmer: Hi!10:23
jelmerhenninge: hi10:23
henningejelmer: last Friday night I merged our recife feature branch into db-devel10:24
henningenow we have to roll back that merge unfortunately10:24
henningeand two others that landed on db-devel after it.10:24
jelmerhenninge: Ah10:24
jelmerhenninge: Thanks for the heads up, you need me to reland my branch?10:25
henningejelmer: not sure, I'd like to ask your help on the procedure.10:25
henningeThis is more a bzr question, actually.10:26
jelmerhenninge: ah, ok10:26
henningejelmer: actually, I don't think anybody else's branches need to be re-landed.10:26
henningeSo we'd roll back the changes by reverse-merging those revisions in db-devel.10:27
henningebut we also want to use our feature branch again.10:27
henningethe feature branch is based on db-stable and has had it merged into it regularly.10:27
henningeWe'd plan to continue that while we still work on it.10:28
henningeThe question is: At one point we will merge db-stable into recife and it will contain that roll-back revision.10:28
henningeI'd expect that to clean out all of our feature from the feature branch.10:29
henningeHow do we get around it?10:29
henningeWould it be okay to simply not merge that revision from db-stable?10:29
henningejelmer: can you follow? ;)10:29
jelmerhenninge: yeah :)10:30
henninge(feature branch == recife branch)10:30
jelmerYou can't really not merge that revision from db-stable10:31
jelmerbut what you could do is mark that revision as merged but not take any of its changes ("bzr merge"; "bzr revert .")10:31
henningeah!10:32
henningeI have done that before but thought it would remove any trace of the merge from the branch.10:32
henningeSo, it leaves a "merged revision X" mark on the target branch?10:33
jelmerThe "." is important because it means the pending merges are still remembered. "bzr status" should still show them.10:33
henningeso "bzr revert ." is different from "bzr revert" at that point?10:33
jelmerhenninge: Yeah (arguably a bit of a UI bug in Bazaar)10:34
henningeI see. Yeah, I would have missed that.10:34
henningejelmer: thanks, that is exactly what we need, then.10:34
wgrantbigjools: The getFileByName bug that let the dupe linux orig.tar.gz into hardy.10:43
bigjoolswgrant: but only if it was deleted from disk, right10:43
bigjoolswgrant: the dude has copied two versions at the same time10:44
bigjoolsah, I see, his source PPA had conflicting orig files....10:44
wgrantExactly.10:48
wgrantIt can't cause a PFOE itself.10:48
bigjoolsyeah10:48
wgrantA new pub of the old one has to be created.10:48
bigjoolsdid you see my fix BTW?10:48
wgrantWas there one?10:49
bigjoolshttps://code.launchpad.net/~julian-edwards/launchpad/upload-file-conflict-bug-663562/+merge/4226410:49
wgrantbigjools: Is the archive ever None?10:51
bigjoolsyes, in a  very tiny corner case10:52
bigjoolspartner....10:52
wgrantWhere partner doesn't exist?10:52
bigjoolsthe lovely partner10:52
wgrantKill it.10:52
wgrantThat fix looks fine.10:53
wgrantCan you remove Distribution.getFileByName?10:53
bigjoolsnot looked tbh10:53
wgrantI recall there were only a couple of callsites.10:53
* wgrant looks.10:53
wgrant(I investigated on my view extermination campaign)10:54
wgrantbigjools: That same bug exists in PackageUploadSource.verifyBeforePublish.10:56
wgrantbigjools: And the only other callsite is in SyncSource, and it can be adjusted the same way.10:56
bigjoolsyeah10:57
wgrantI have to wonder about the sanity of triplicating that logic.10:59
bigjoolswgrant: ignorance, no doubt.  And will it get any better with the team change ....11:01
wgrant:D11:01
bigjoolswow, all builder queues are empty11:12
wgrantEven powerpc?11:14
wgrantHm, indeed.11:14
bigjoolsdoko wants to do a rebuild11:14
wgrantdoit11:14
bigjoolsincluding universe11:14
wgrantWe need to test.11:14
wgrantAlthough I'd like to get a daily builds session through the async download code first, I guess.11:15
=== matsubara-afk is now known as matsubara
jtvhenninge: 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.11:31
deryckMorning, all.12:02
jmlbigjools: hi. just finishing something up. won't be long.12:34
jmlbigjools: re StevenK's database patch... we are building a linked list structure into SPPH?12:51
wgrantjml: It's a tree of pain, not a linked list, but yes.13:00
jml... because many things can have the one parent, I see.13:01
wgrantIn the case of a copy, yeah.13:01
=== almaisan-away is now known as al-maisan
StevenKjml: Has wgrant answered your questions?13:12
StevenKwgrant: Tree of pain? :-(13:13
wgrantThere will be pain. But it won't be our problem any more :)13:13
deryck*sigh* I continue to have failure at landing this lazr-js upgrade.13:37
deryckgary_poster, would love a moment of your time when you're available.13:39
jmlStevenK: no he has not, see the MP.13:42
StevenKjml: Commented.13:51
james_wsalgado, hi. Did you look at exposing blueprint-bug links by any chance?13:53
salgadojames_w, nope, do you want me to?13:54
maxbWhere are the buildds supposed to get their bzr-builder for recipe builds from these days?13:55
maxbI am asking because of bug 68294113:55
_mup_Bug #682941: no such option --append-version in recipe build <Launchpad Bazaar Integration:Confirmed> <https://launchpad.net/bugs/682941>13:55
bigjoolsjml, sorry was at lunch.  Hope you got your questions all answered.13:55
james_wsalgado, 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_wsalgado, Specification implements(lp.bugs.interfaces.buglink.IBugLinkTarget)13:56
salgadojames_w, you don't need to be able to create new links, right?  Just reading existing ones should be enough?13:57
james_wand 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_wsalgado, for this use case, yes13:57
salgadojames_w, what do you mean by interfaces are not linked?13:59
james_wsalgado, ISpecification doesn't inherit from IBugLinkTarget13:59
james_wsalgado, does the webservice code traverse the model to see what it implements too?13:59
salgadooh, good question13:59
salgadoI think it does13:59
salgadobut we'd need to export IBugLinkTarget14:00
salgadojust like we export ISpecificationBranch14:00
=== matsubara is now known as matsubara-lunch
salgadoyeah, that should be everything needed to export .bugs14:03
salgadojames_w, would you like me to do that?  should be quick14:05
james_wsalgado, 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_wsalgado, if you think it's just a few minutes I'm happy for you to take over, but I can keep plugging away at it14:06
salgadojames_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 test14:08
james_wsalgado, 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
salgadook14:14
james_wthanks for the help14:15
salgadonp14:16
* salgado breaks for lunch14:17
=== salgado is now known as salgado-lunch
gary_posterderyck, hey, pong, though other things going on14:20
deryckgary_poster, hey, just finishing standup now myself14:24
gary_postercool14:25
deryckgary_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:27
deryckgary_poster, however python setup.py --version reports 1.5DEV and versions.cfg expects 1.5DEV-r190.  Could this be the issue?14:28
gary_posterderyck, remind me the error please?  can't quite place it14:28
deryckgary_poster, I'll forward you an email if that's ok.  basically just "failed to build" or some such.14:28
gary_postersure, deryck .  and yes, that sounds suspicious14:29
deryckgary_poster, mail sent14:29
gary_posterack14:29
deryckgary_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/repeat14:30
gary_posterderyck: 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:32
gary_posterderyck: 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/buildout14:33
gary_posterat that point, if you haven't duped, I'll be surprised14:33
deryckgary_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
deryckgary_poster, ok, I'll try that.  thanks!14:33
gary_posternp, lemme know14:34
jmldo we have an end-to-end overview of our dev process?14:36
gary_posterI don't recall ever seeing one, jml.14:42
jmlgary_poster: ta, I might have to make one then.14:43
gary_postersounds good jml :-)14:43
jmlflacoste, mrevell: just making a cup of tea before the standup. will be a tiny bit late.14:43
mrevelljml, np14:44
deryckgary_poster, it worked fine.  weird.  https://pastebin.canonical.com/40332/14:55
deryckbac, appologies but I won't be able to make reviewer meeting today.14:55
gary_posterderyck: 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_posterderyck: I'll try to build locally in a min14:58
deryckgary_poster, ok, thanks!14:58
gary_posterderyck: to be clear, the pqm hypothesis seems pretty unlikely to me.  I think we wipe out built eggs on pqm14:58
gary_posterbetween builds14:59
deryckah14:59
deryckhmm, yeah, that's weird.14:59
jmlmrevell: http://pastebin.ubuntu.com/538678/14:59
deryckgary_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.14:59
bacmeeting ping: abentley, adeuring, allenap , bac, benji, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jcsackett, jtv, bigjools, leonard, mars15:00
deryckwhere, if so == it pqm build works15:00
bacderyck: ok15:00
flacostebac: apologies from me15:00
jtvbac: anon!15:00
=== salgado-lunch is now known as salgado
LPCIBotYippie, build fixed!15:03
LPCIBotProject devel build (264): FIXED in 4 hr 2 min: https://hudson.wedontsleep.org/job/devel/264/15:03
gary_posterderyck: 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 produces15:04
gary_posterso it's worth a try, but still pretty mysterious15:05
=== matsubara-lunch is now known as matsubara
LPCIBotProject db-devel build (179): STILL FAILING in 4 hr 5 min: https://hudson.wedontsleep.org/job/db-devel/179/15:16
gary_posterderyck, I think I have a clue15:26
marsflacoste, ping, I have a question about the simplified merge machinery tracking15:26
gary_posterderyck: (that comes after discovering that it also worked for me)15:26
deryckgary_poster, ok, awesome.  on call now....15:26
gary_posterderyck: 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_posterCore 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_posterOther 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
bigjoolsabentley: I just noticed that recipe builds are ending up with a buildqueue score of 2605 on dogfood.  Is that intentional?15:31
abentleybigjools: I haven't changed anything related to that.  I expect them all to be 2505 ATM.15:32
bigjoolsok15:33
flacostemars: what's the question?15:39
james_wleonardr, 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
deryckgary_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:45
deryckrockstar, ping.  do you know why we require distribute explicitly for lazr-js, instead of just using setuptools?15:48
deryckhmmm15:53
deryckgary_poster, so I see a merge that led to this -- https://code.launchpad.net/~sidnei/lazr-js/newer-buildout/+merge/2141715:53
deryckgary_poster, how would you feel about me temporarily adding distribute to download-cache, and opening a bug against lazr-js for this?15:54
derycksince I'm not sure why we went this way in the first place.15:54
gary_posterderyck: on call15:57
deryckack15:57
* deryck needs to eat16:08
=== deryck is now known as deryck[lunch]
rockstarderyck[lunch], the distribute thing is a big reason why I want to kill the build system in lazr-js.16:17
rockstarIt always either Just Works for landscape or for Launchpad, but never both at the same time.16:18
bigjoolsjtv: can you remind me where to look to see finished translations template jobs?16:25
jtvbigjools: errr didn't they get cleaned up?16:26
bigjoolsjtv: I am just QAing on dogfood, I want to make sure the job finished16:26
jtvAnyway I don't have database access now so I'm falling out of touch with the schema.16:26
jtvIt's job type 6 IIRC; let me check.16:26
bigjoolsjtv: there was a page I could go to to see the template?16:27
bigjools4 actually16:27
bigjoolsjtv: I need a page, not a query :)16:27
jtvAh.  One of the job types for this class was 4 and the other 6, and I always forget which is which.16:27
jtvTry the import queue page for the productseries.16:27
jtvhttps://translations.dogfood.launchpad.net/test_product/test_series/+imports16:28
jtvIf the job completes successfully, you'll see a template upload appear there, owned by "VCS Imports."16:28
jtvThis 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
bigjoolsok, thanks16:29
jtvSince there's no importer running on dogfood, the queue entry will be in Needs Review state.16:29
bigjoolsI see the one I did last time we talked but not the one I just did :/16:30
jtvDon'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
jtvSo try opening the link to the file itself (<something>.pot) and reading the POT header inside the file.16:30
jtvIt'll have a timestamp.16:30
bigjoolsjtv: aha, that's it16:33
bigjoolsthanks16:33
jtvno worries16:33
bigjoolsI 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:34
=== cr3_ is now known as cr3
=== beuno is now known as beuno-lunch
gary_posterrockstar: do you have time for a five min call?  I'll even set a timer if you want :-)16:39
gary_posterderyck[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:40
=== deryck[lunch] is now known as deryck
deryckgary_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
deryckwell, scrollback suggests rockstar is going to fix it anyway.16:54
gary_posterCool deryck.  yeah, but rockstar has approx 1000000 things on his plate AFAIK. :-)16:55
rockstarderyck, and by fix, you mean "destroy with a firey passion"16:55
rockstargary_poster, yes, yes I do, but lazr-js is on the official plate, rather than the unofficial plate.16:55
deryckgary_poster, yes, but see "firey passion" above ;)16:55
gary_poster:-)16:55
gary_posterrockstar: you cleverly showed up at the time when I only have four min16:56
gary_posterquick call now?16:56
gary_posterlike, three min :-)16:56
rockstargary_poster, pots?16:56
=== benji is now known as benji-lunch
lifelessjml: hi17:07
lifelessabentley: hi17:27
abentleyhi.  in TL meeting17:27
lifelesshttps://dev.launchpad.net/PolicyAndProcess/ReleaseManagerRotation?action=diff17:27
lifelessabentley: a tweak to your edit, FYI/clarity.17:27
* lifeless goes to hop on a plane17:27
lifelessI hope its clear.17:27
lifelessciao17:27
sinzuiflacoste, benji-lunch, gary_poster ping17:33
flacostehi sinzui17:33
gary_postersinzui: hi17:34
sinzuiIHugeVocabulary 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 matched17:35
gary_postersinzui: I was also going to try and ping you about the question I gave you yesterday.  Trying to get it again17:35
deryckdear lazr-js, I like you, do you like me? check one.  [  ]yes  [x]no [  ]maybe17:35
gary_posterlol17:35
gary_postersinzui: I'm not clear yet on what a step_title would be17:36
sinzuiThis 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 about17:36
sinzuiI am not sure how to add a readable attr to just a few vocabs. They are secured utilities17:36
sinzuigary_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 matched17:38
=== beuno-lunch is now known as beuno
sinzuigary_poster, flacoste. I am trying to avoid duplicating the text in 3 many places in our code.17:39
gary_postersinzui: 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 class17:39
gary_posterexpose it17:39
gary_posteroverride it on instance17:39
gary_posterand be done17:39
gary_posterthat seems simplest on the face of it.  is there a reason that is a bad idea?17:40
gary_posteror, problematic, or whatever17:40
sinzuigary_poster, step_title is indeed bad. The picker assume there are one or more steps to complete an action.17:40
gary_posterI see17:40
sinzuigary_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:42
gary_postersinzui, but then you have to expose the attribute on security or rip off security wrappers and so on, right?17:43
gary_posterif 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 discussion17:44
sinzuigary_poster, I /think/ that I need to add it to the interface so that the views can access the attr17:45
sinzuigary_poster, given that the is used to vocab is build javascript, I do not want to consider removing the security wrapper17:46
sinzuigary_poster, sorry about the bad typin17:47
sinzuig17:47
sinzui:(17:47
gary_postersinzui, 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:47
* gary_poster types poorly most of the time. never learned how to do it properly, and now is reasonably fast the wrong way17:48
gary_postersinzui, 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_postercould 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
sinzuiokay, I will continue on the path of exposing a new attr17:48
gary_posterok17:48
gary_postersinzui: the other option is an adapter, but that seems a bit heaviweight.  But it might have the characteristics you are looking for17:49
gary_posterimplementation:17:49
gary_posterwell, you can come up with an implementation17:49
gary_posterMaybe I have too high a barrier in my mind for when an adapter makes sense these days17:50
gary_posterit feels a little heavy17:51
sinzuigary_poster, yes. I am looking for the minimal amount to work to close a security issue17:51
gary_posterI see17:51
gary_posterthen17:51
sinzuiI happen to know there is a UI issue too17:51
gary_posterYou could17:51
gary_poster- have the widget try to adapt the vocab to the other interface17:51
gary_poster- if it can't be adapted, use "Search"17:52
gary_poster- if it can be adapted, use the value17: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 write17:52
sinzuigary_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...IHugeVocabulary17:53
sinzuigary_poster, as to the other bug. We do not allow users to reuse team bugs.17:53
gary_postersinzui, right, that's kind of why I thought an adpater was too heavy17:53
sinzuiI think that is the underlying surprise in the bug17:53
gary_postersinzui: "We do not allow users to reuse team bugs." -> "We do not allow users to reuse team emails." ?17:54
sinzuiyes, I mean emails, I think our email rules are broken17:54
gary_posterI see17:54
sinzuiso I typed bug17:55
gary_poster:-)17:55
gary_posterSo..."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
sinzuigary_poster, I believe Lp17:55
sinzuigary_poster, I believe Lp's email rules account for taken addresses. Registration did too. I think the rule was lost in translation to Django17:56
sinzuigary_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 address17:59
=== benji-lunch is now known as benji
gary_postersinzui: ack.  I *think* the connection is this:18:00
sinzuigary_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 not18:00
gary_poster- SSO used to check with LP for used emails, and team emails18: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 old18:01
gary_poster- so they want to remove those constraints entirely on their side AIUI18: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 side18:02
gary_posterWhich seems like a really bad UI  on our side :-(18:02
gary_posterwhich inherently comes from the two systems being separate18:03
gary_posterI'm inclined to say that we treat the SSO email as a hint18:03
gary_posterbecause 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 source18:04
gary_poster'18:04
gary_postersinzui, I have to go run do lunch things.  Any quick thoughts on the above, or should we try to continue later this afternoon?18:05
sinzuigary_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_posterI see18:06
gary_posterSo let me rephrase18:06
sinzuigary_poster, have lunch. ping me when you are available. I think we do care about email and we can talk on mumble18:08
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_posterOK thanks sinzui, will do18:09
gary_posterI'll ping you later18:09
* gary_poster linches18:09
gary_posterheh18:09
gary_posterlunches18:09
benjigary_poster: heh18:10
rockstarmatsubara, ping18:50
matsubarahi rockstar18:51
rockstarmatsubara, could you join #tarmac ?18:51
LPCIBotYippie, build fixed!18:58
LPCIBotProject db-devel build (180): FIXED in 3 hr 42 min: https://hudson.wedontsleep.org/job/db-devel/180/18:58
LPCIBotLaunchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12001,18:58
LPCIBot12002, 12003, 12004, 12005, 12006 included.18:58
gary_posterderyck: do you object to me making a branch of lazr-js that does not depend on distribute?19:43
deryckgary_poster, not at all.  I have no objections.19:44
gary_posterderyck, then I would make a local release, and merge that.19:44
deryckgary_poster, I was hesitant to do that not knowing the impact to landscape and not having sidnei around to ask.19:44
gary_posterderyck, I would fork for now19:44
deryckgary_poster, ah, right.19:44
deryckgary_poster, sure, sounds like a good plan to me.19:44
gary_posterok19:44
deryckgary_poster, will you submit to pqm, or just make the tarball and I will submit?19:45
gary_posterderyck: so, I just want bzr branch lp:lazr-js, right?19:45
deryckgary_poster, right19:45
gary_posterok.  I'll submit deryck.  I'm pretty optimistic that this is the problem.19:45
gary_posterfamous last words :-P19:46
deryckheh19:47
deryckgary_poster, I agree the log looks like this is it.19:47
gary_postercool19:47
deryckgary_poster, and thanks so much for the help!19:48
gary_posterderyck, I figure somebody else should help you with the pain :-/19:48
* 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 yet19:58
deryckgary_poster, yeah, I don't understand either.19:59
marsgary_poster, check lazr-js versions.cfg (if it has one)19:59
gary_posterlazr-js's buildout and Makefile specify distribute, but that's nothing to do with when you actually build the egg19:59
deryckgary_poster, well, there is the distribute_setup that is imported, if that's what you mean19:59
gary_postermars, that won't be run, but deryck, that must be it!19:59
gary_postermars, versions.cfg will affect buildout, but not when the egg is built20:00
marsright20:00
derycksetup.py imports distribute_setup20:00
gary_posterright20:00
gary_posterthat might be it20:00
gary_postermeh, distribute vs setuptools is yucky :-(20:01
deryckand it just uses setuptools, so I don't see why we can't just use setuptools.20:01
deryckright, I don't get it, gary_poster  ;)20:01
gary_posterderyck: http://pastebin.ubuntu.com/538783/ ?  Do you have lazr-js review privs?  If so, want me to try to land that?20:12
gary_posterderyck, argh, my first comment is backwards20:12
deryckgary_poster, right.  we do prefer the local tools right?20:13
gary_posterderyck, the term "local" is not clear.  I did this, but it is still confusing20:13
gary_posterhttp://pastebin.ubuntu.com/538784/20:13
gary_posterI think it is good enough though ;-)20:13
deryckgary_poster, yup, r=me.  land away.20:14
gary_posterok thanks deryck20:14
gary_posterderyck: 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:-P20:15
deryckgary_poster, I just do bzr pqm-submit from lazr-js and have my locations.conf set.20:17
gary_posterderyck, ack20:17
deryckgary_poster, I can send you my locations.conf section20:17
deryckif that helps20:17
gary_posterderyck: s'ok, I'll just use command line for now.  thank you20:18
=== salgado is now known as salgado-afk
deryckgary_poster, np20:18
=== al-maisan is now known as almaisan-away
wallyworldabentley: quick chat?21:09
gary_posterderyck: still here?21:16
deryckgary_poster, hey, yup.21:17
=== matsubara is now known as matsubara-afk
gary_postercool 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_posterI don't have a review;21:19
gary_posterI am not sure about whether pqm is open21:19
gary_posterI guess it must be21:19
gary_posterI just heard mutterings that confused me21:19
deryckgary_poster, you can *not* merge with devel.  You (or I) need to merge with my branch...21:20
deryckgary_poster, lazr-js is using yui 3.2 now and requires lp changes to work.21:20
gary_posterderyck: 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_posterderyck, then I just upped the version in versions.cfg21:21
deryckah ok21:22
deryckgary_poster, I didn't realize you had merged my branch.  That should work then.21:22
gary_posterderyck: 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_posteruh-oh21:22
gary_posteryou have lazr-js 1.5.1DEV21:22
gary_posterI'm adding lazr-js 1.5DEV-r19121:23
gary_posterdo you care?21:23
gary_posterdo we care?21:23
deryckgary_poster, right, I can change to the sdist you added to download cache.  doesn't matter.21:23
gary_poster:-) ok21:23
deryckgary_poster, so to be clear... :-)21:23
deryckgary_poster, I'll update my branch with this new version of lazr-js and land it.  right?21:23
deryckupdate in versions.cfg, I mean21:24
gary_posterderyck: right.  Here's hoping.  lazr-js = 1.5DEV-r191.21:24
deryckalright.  thanks, gary_poster!21:24
gary_posterderyck: I'll accept the thanks if it works, deryck ;-)21:25
deryckheh, fair enough21:25
derycksent to pqm.  we'll know shortly.21:29
gary_postercool21:29
gary_postersinzui: 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
sinzuiokay21:29
jcsackettleonardr: 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
jcsackettany thoughts?21:32
leonardrjcsackett: i think you should talk to salgado, who just did a branch for this21:32
jcsackettalas, he is afk.21:33
jcsackettsalgado-afk: when you return, if you have time i could use some help with the above.21:33
wallyworldabentley: http://people.canonical.com/~ianb/recipe-related-branches.png21:34
leonardrjcsackett: he ended up adding a new helper method, if that helps21:35
jcsackettleonardr: it gives me something to look for, at least. thanks!21:35
salgado-afkjcsackett, yeah, I've seen that too.  had to endInteraction() before calling my helper method21:45
jcsackettsalgado-afk: what's your helper called?21:49
abentleywallyworld: https://launchpad.net/thekraken21:49
salgado-afkjcsackett, launchpadlib_for_anonymous21:50
jcsackettsalgado-afk: is that merged?21:51
salgado-afkjcsackett, yes, as of a couple hours ago21:51
jcsackettwell, i'll just update then--i was writing the exact same method. :-p21:51
jcsackettthanks!21:51
deryckgary_poster, success!  hurrahs heard round the world!22:09
gary_posterderyck: HURRAH!22:09
deryckand with that, I shall away. ;)22:10
gary_poster:-)22:10
deryckgary_poster, thanks again for the help today!22:10
gary_posternp deryck :-)22:10
rockstar\o/ New lazr-js has landed!22:17
LPCIBotProject 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 adapter22:20
LPCIBotfor ISpecification so that collections of it can be exposed on22:20
LPCIBotthe API for anonymous users.22:20
LPCIBot* Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=60055] Removes unused and untested parameters22:20
LPCIBotfrom ProjectGroup.search22:20
wgrantGrah.23:30
wgrantcanonical-launchpad@l.c.c hates me :(23:31
spmwgrant: nah. that's the filter I put on for you t'other month. was feeling bored.23:31

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!