[00:04] <lifeless> wgrant: which missing revs
[00:05] <lifeless> wgrant: if you want todo that btw, its easy.
[00:05] <lifeless> after unstacking
[00:05] <lifeless> do sidbranch.repository.fetch(oldbasis.repository)
[00:06] <poolie> wgrant, i think we should leave it off just for the sake of being careful
[00:06] <poolie> i'd be happy to look at your script too
[00:06] <StevenK> wallyworld_: O hai?
[00:06] <wallyworld_> StevenK: yo
[00:07] <StevenK> wallyworld_: With your RM hat on, when do you expect PQM to re-open for srs bzns?
[00:08] <wgrant> lifeless: The revs containing versions that entered squeeze through testing-proposed-updates instead of sid.
[00:08] <wallyworld_> StevenK: i'm waiting on a branch in db-devel to make it into devel - another rc db patch occured
[00:08] <wallyworld_> StevenK: i'd say a bit after eod our time today
[00:08] <lifeless> wgrant: that one liner will ensure that any such revs are copied
[00:08] <lifeless> wgrant: and because the stack is transitive, its complete.
[00:10] <wgrant> lifeless: Perhaps we should revert the dev focus to squeeze, push up wheezy branches, then unstack sid and restack everything on top of sid next week. Otherwise we have to fetch on every child before we can unstack sid.
[00:11] <lifeless> wgrant: huh?
[00:11] <lifeless> wgrant: I think you're underestimated bzr
[00:11] <lifeless> wgrant: add that one liner I gave you above to the script; fin.
[00:12] <wgrant> lifeless: wheezy branches will reference revs that sid does not reference, but they will get them through sid's stacked-on branch.
[00:12] <lifeless> thats fine
[00:12] <lifeless> the fetch line above will copy said revisions
[00:12] <wgrant> So we cannot just unstack sid using my usual script. We first have to go through every branch stacked *on* sid, and fetch into them.
[00:14] <wgrant> This seems a lot more risky than just unstacking sid ASAP.
[00:15] <lifeless> no we don't
[00:15] <lifeless> I think we need voice
[00:15] <wgrant> Oh, you want to pull the entire contents of the squeeze repo into sid?
[00:15] <wgrant> That would work, but is a bit dirty.
[00:16] <lifeless> skype?
[00:17] <wgrant> If it ever connects.
[00:18] <wgrant> Oh good, it works.
[00:18] <wgrant> Ready when you are.
[00:31] <lifeless> poolie: the wheezy config changes to the pkg importer are being done by the bzr team ?
[00:31] <lifeless> poolie: wgrant and I agree that the importer should be started up now; we'll deal with the mechanics of changing stacking for sid next week.
[00:32] <poolie> i can do them now; i don't know of anyone doing them at the moment
[00:32] <poolie> ok
[00:32] <poolie> thanks for working that out
[00:32] <thumper> wallyworld_: I'm back now
[00:33] <wallyworld_> thumper: ok. all pumped and toned i assume
[00:33] <lifeless> the current plan for unstacking is to use the bzrlib api to unstack & fetch all revs from squeeze into sid; this will increase the size of sids repositories but its a one time hit.
[00:33] <thumper> wallyworld_: actually shaking and trying not to die
[00:33] <lifeless> we need to check there is enough space on crowberry to do that.
[00:34] <wallyworld_> thumper: mumble?
[00:34] <thumper> ok
[00:37] <lifeless> jam: btw
[00:38] <lifeless> https://code.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/+reviewer - has loggerhead-team as reviewer already
[00:38] <lifeless> the reason you get that annoying mail is that launchpad is in loggerhead-team
[00:38] <poolie> https://code.launchpad.net/~leonardr/launchpadlib/bug-714043/+merge/48842 really reminds me of the glock safety design
[00:40] <lifeless> so we could change that to be canonical-launchpad-reviewers, though that would stop considering the folk who are individually involved in loggerhead already
[00:45] <wallyworld_> thumper: https://code.launchpad.net/~wallyworld/launchpad/request-build-popup/+merge/48864
[01:06] <lifeless> flacoste: btw
[01:06] <lifeless> https://bugs.launchpad.net/apache-openid/+bug/712698/comments/2
[01:06] <_mup_> Bug #712698: No way to expire existing sessions <Apache OpenID:New> < https://launchpad.net/bugs/712698 >
[01:19] <lifeless> sinzui: around ?
[01:19] <sinzui> I am
[01:19] <lifeless> perhaps you could review https://code.launchpad.net/~lifeless/launchpad/showtimes/+merge/48754
[01:19] <lifeless> for gotchas
[01:19] <lifeless> its a developer only thing
[01:24] <sinzui> lifeless: the Mp's description does not mention changes to bug task. Are those changes unintended?
[01:25] <lifeless> oh
[01:25] <lifeless> it has a separate branch conflated with it accidentally
[01:25] <lifeless> that branch is reviewed and approved
[01:26] <lifeless> ignore the bugs/* changes
[01:28] <sinzui> lifeless: okay. This look great. I have no remarks. I will update the MP
[01:45] <wgrant> lifeless: Why is the <script> element done like that?
[01:45] <wgrant> Can't it be a real element in the TAL, with a <tal:blah replace="render_time" /> inside it?
[01:46] <lifeless> wgrant: tal evaluates as it goes.
[01:46] <mwhudson> i think it's because zpt is terrible about <script>
[01:47] <wgrant> Could you put the JS in the normal place, and just set the variable there?
[01:47] <thumper> script tags are special for TAL
[01:47] <thumper> nothing inside a script tag is executed by TAL
[01:47] <thumper> if you need expansion
[01:47] <wgrant> Keeping code XML-quoted in an attribute seems... suboptimal.
[01:47] <thumper> you do a replace="string: lots of rubbish..."
[01:47]  * wgrant lunches.
[01:48] <mwhudson> is chameleon less unhelpful abou this?
[01:48] <thumper> wgrant: look at lib/lp/app/templates/text-area-editor.pt
[01:48] <thumper> wgrant: that seems to be how we do it now
[01:49] <lifeless> so, it could be a little better. Meh, next time its touched.
[01:51] <lifeless> okies
[01:52] <lifeless> wgrant: so checkwatches
[01:55] <thumper> wallyworld_: mumble now?
[01:55] <wallyworld_> ok
[02:01] <lifeless>   Hard / Soft  Page ID
[02:01] <lifeless>      341 / 6404  Archive:+index
[02:01] <lifeless>      273 /  468  BugTask:+index
[02:01] <lifeless>      134 /  304  Distribution:+bugs
[02:32] <wgrant> lifeless: Hi.
[02:35] <lifeless> hi
[02:39] <lifeless> wgrant: so
[02:42] <wgrant> lifeless: Sorry, Unity decided to wander away for a while.
[02:42] <wgrant> Seems happy now.
[02:43] <lifeless> so
[02:43] <wgrant> What do you know about the CCW-spam?
[02:43] <lifeless> first I'm going to point you at a bug
[02:43] <lifeless> https://bugs.launchpad.net/launchpad/+bug/623199
[02:43] <_mup_> Bug #623199: scripts do not establish valid zope partiticipations <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/623199 >
[02:44] <wgrant> Ah, right, that one.
[02:44] <lifeless> many backend scripts do not create participations/run in different security model
[02:44] <lifeless> webapp.adapter therefore *duplicates* this infrastructure
[02:44] <lifeless> so we have two different 'request' concepts
[02:44] <lifeless> lib/lp/bugs/scripts/checkwatches/base.py
[02:44] <lifeless> the interaction context manager
[02:45] <lifeless> *that* gets called around each watch
[02:45] <lifeless> its buggy, per bug 623199
[02:45] <_mup_> Bug #623199: scripts do not establish valid zope partiticipations <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/623199 >
[02:45] <lifeless> fixing the CCW issue won't fix bug 623199; I just wanted to paint the larger picture
[02:45] <_mup_> Bug #623199: scripts do not establish valid zope partiticipations <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/623199 >
[02:49] <wgrant> lifeless: Interestingly, checkwatches is running with --jobs=1 at the moment...
[02:49] <lifeless> wgrant: so basically I suspect its as easy as adding, after setupInteraction
[02:51] <lifeless> either an adapter.set_request_start or lp.services.timeline.requesttimeline.set_request_timeline call
[02:51] <lifeless> and similar before the end interaction
[02:52] <lifeless> wgrant: possible, on the transaction property instead of the interaction one; I'm ambivalent there. But one or tother should do it.
[02:53] <wgrant> lifeless: I'm currently waiting for a big OOPS to load to see why it's trying to do more than one job in a single script execution.
[02:53] <wgrant> But lp-oops is very slow.
[02:54] <poolie> wgrant, it's working out if the import of wheezy works that may be harder
[02:55] <lifeless> wgrant: jobs is concurrency not length
[02:57] <wgrant> lifeless: Ah, I confused it and --batch-size.
[03:18] <wgrant> sinzui: Still around?
[03:55] <wgrant> lifeless: So, I'm not exactly sure what we want to do here, because a lot of the OOPSes happen in the batch retrieval code, which is outside the per-watch code.
[03:55] <lifeless> whats batch retrieval all about
[03:56] <wgrant> lifeless: For some tracker types it will retrieve lots of bugs in a single request.
[03:56] <wgrant> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1864CCW2202 for example.
[03:56] <lifeless> well
[03:56] <lifeless> I think we want a context no smaller than that needed to make sense of the oops
[03:57] <wgrant> Right.
[03:57] <wgrant> We could possibly wrap the batch code in one timeline.
[03:57] <lifeless> 3532642
[03:57] <wgrant> And then each watch update in another.
[03:57] <lifeless> seems larger than needed.
[03:57] <wgrant> Yes, slightly.
[03:57] <lifeless> wgrant: that sounds like a reasonable first approximation
[03:58] <wgrant> We may end up with massive timelines wrapping them, though.
[03:58] <wgrant> But I wonder how many exception happen outside there.
[03:58] <wgrant> My guess is "not many"
[03:58] <lifeless> wgrant: we can iterate
[03:59] <wgrant> So I might make a context manager than switches in a new timeline.
[03:59] <wgrant> It'll leave big gaps in the overall one, though. Hmm.
[03:59] <huwshimi> A js fix for bug #457856 if someone is available sometime to review. Thanks! https://code.launchpad.net/~huwshimi/launchpad/tag-dialogue-457856/+merge/48868
[03:59] <_mup_> Bug #457856: Tag dialog never closes <bug-page> <bugtag> <lp-bugs> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/457856 >
[04:00] <huwshimi> Nevermind, lifeless is one step ahead of me.
[04:01] <huwshimi> lifeless: Thank you :)
[04:01] <lifeless> huwshimi: anytime
[04:01] <wgrant> lifeless: Does it sound reasonable to have a catch-all timeline handle things when none of the finer-grained ones do?
[04:01] <wgrant> It's bad, but I'm not sure what else we can do.
[04:01] <lifeless> wgrant: sounds like it needs restructuring
[04:01] <lifeless> wgrant: the finer grained things do commits
[04:01] <lifeless> wgrant: generally speaking a timeline across commits is rather pointles
[04:01] <lifeless> s
[04:02] <wgrant> Ah, true.
[04:02] <wgrant> I guess.
[04:02] <wgrant> I wanted to ideally keep more state around, but with differing transactions it's probably pointless.
[04:02] <lifeless> s/pointless/buggy/
[04:03] <wgrant> Well, the previous behaviour is still potentially handy.
[04:04] <lifeless> I think there should always be a timeline when there is a participation | db queries
[04:04] <lifeless> but it should be fresh when the transaction is reset (and we shouldn't be carrying objects across transactions)
[04:33] <huwshimi> Anyone know what I need to get this branch to not fail its tests? http://paste.ubuntu.com/564218/
[04:33] <huwshimi> I think the important bit might be: Failed to create database or load sampledata.
[04:33] <huwshimi> This is with ec2 land
[04:33] <StevenK> psycopg2.ProgrammingError: type "debversion" does not exist
[04:33] <StevenK> That's the error
[04:34] <StevenK> And *awesome*, we need a new AMI
[04:34] <lifeless> I thought bigjools made one
[04:34] <lifeless> ah... probably hasn't made it public yet
[04:34] <StevenK> Yes, I just remembered
[04:34] <StevenK> I thought he did, but bin/ec2 didn't know about his ID?
[04:35]  * StevenK checks
[04:36] <StevenK> huwshimi: Which revno of devel is that branch based on?
[04:36] <lifeless> ah yes, merging in trunk should fix, if its an old(ish) branch
[04:37] <StevenK> Right
[04:37] <huwshimi> erm, how do I find out? :)
[04:37] <StevenK> r12336 of devel has the merge in it
[04:37] <StevenK> huwshimi: I use bzr log and look for the first comment message that starts with '[r=
[04:37] <huwshimi> StevenK: Maybe r12337
[04:37] <StevenK> lifeless may have a better way
[04:38] <StevenK> huwshimi: Do you still have the output from ec2 land? And you know PQM is closed, right? :-)
[04:38] <lifeless> bzr show-merge-base , bzr missing - probably bzr missing
[04:39] <StevenK> bzr missing assumes launchpad/lp-branches/devel is up to date
[04:39] <StevenK> As a caveat
[04:39] <huwshimi> StevenK: Oh, I did not.
[04:40] <StevenK> huwshimi: PQM is closed so we can nail done exactly which revision is going to be deployed -- once we're close it will re-open. Hint: PQM state is in the topic.
[04:41] <StevenK> s/done/down/
[04:41] <huwshimi> StevenK: Yeah, I just didn't think
[04:41] <StevenK> However, I'm still concerned which machine id your ec2 land used
[04:42] <StevenK> Er, s/machine id/AMI/
[04:43] <huwshimi> StevenK: Where do I need to look for that info?
[04:45] <StevenK> huwshimi: If you have the output that ec2 land dumped into your terminal, one of the first lines is "Using machine ..."
[04:45] <huwshimi> I have the terminal open, but not enough lines to show back that far
[04:46] <huwshimi> StevenK: Unless there's a way to go back further
[04:49] <StevenK> huwshimi: I don't think so, but you might be able to edit the Profile for your terminal and increase the scrollback lines. The output might be lost, though.
[04:50] <huwshimi> StevenK: No luck
[04:52] <huwshimi> StevenK: Actually I have the info from my console. What do you want? AMI ID?
[04:53] <huwshimi> StevenK: From Elasticfox console
[04:53] <wgrant> There should be an "Using machine image version 504", or something like that.
[04:53] <wgrant> Ah.
[04:53] <wgrant> Does it show the AMI owner?
[04:54] <huwshimi> wgrant: There's an owner ID, but it doesn't say anything to do with AMI... might be the same thing though
[04:56] <StevenK> huwshimi: Can you run the script in http://pastebin.ubuntu.com/564220/ in your branch root?
[04:56] <StevenK> That will tell us the machine image version your branch things is the latest
[04:56] <StevenK> *thinks
[04:56] <StevenK> huwshimi: The output is one line, so just paste it
[05:01] <huwshimi> StevenK: RuntimeError: Your version of paramiko (1.7.6 (Fanny)) is not supported.  Please use 1.7.4.
[05:02] <StevenK> Wow, I did see that when I ran it
[05:03] <StevenK> And I have 1.7.6 installed. This is strange.
[05:03] <huwshimi> You did see it or you didn't?
[05:04] <StevenK> steven@liquified:~/launchpad/lp-branches/devel% ./which_ami.py
[05:04] <StevenK> (507, [Image:ami-4209f92b])
[05:06] <huwshimi> StevenK: Well elasticfox gives me: ami-fa956493. Does that help?
[05:06] <StevenK> huwshimi: Yes, that's 504.
[05:06] <StevenK> Which is too old.
[05:07] <huwshimi> StevenK: Is that all you wanted to know?
[05:07] <StevenK> huwshimi: It means you need to merge devel into your branch and then ec2 land should work
[05:08] <huwshimi> StevenK: OK. When will PQM open again?
[05:08] <StevenK> That's up to wallyworld_.
[05:09] <huwshimi> StevenK: Like a couple of days or a week or something?
[05:09] <wallyworld_> huwshimi: another version of db-devel is being merged right now. then it needs to be deployed
[05:09] <StevenK> huwshimi: Estimates say our tonight
[05:09] <huwshimi> wallyworld_: Oh right
[05:10] <wallyworld_> huwshimi: the release is scheduled to occur in a day or so but there's been some qa issues
[05:10] <huwshimi> wallyworld_: Yeah I saw some emails.
[05:10] <wallyworld_> so hopefully this latest deployment occuring now will be The One and we can open pqm again
[05:10] <huwshimi> wallyworld_: Great :)
[05:11] <wallyworld_> huwshimi: not so great that we've had these issues :-) but i think everything's been found and fixed so that's good
[05:12] <lifeless> StevenK: you can run missing with a url
[05:12] <StevenK> Ah
[05:13] <StevenK> huwshimi: Are you good, or have you not merged devel into an existing branch before?
[05:14] <huwshimi> StevenK: All good.
[05:14] <huwshimi> StevenK: Thanks for that.
[05:14] <huwshimi> I guess I'll find out when PQM opens up again
[05:14] <StevenK> huwshimi: You're welcome
[05:46] <huwshimi> Seeing open interface bugs that were filed in 2006 hurts.
[05:51] <huwshimi> We should change the reported date format to "Reported by Foo, 5 years ago" just so that it hurts that little bit more.
[05:53] <wallyworld_> huwshimi: i didn't know you were into pain :-)
[05:54] <huwshimi> wallyworld_: :)
[05:55] <huwshimi> wallyworld_: The pain is knowing that there are users who are unhappy because we haven't fixed things.
[05:55] <wallyworld_> huwshimi: yeah. gary fixed bug 548 for this release. not sure if that's the oldest but it would have to go close
[05:55] <_mup_> Bug #548: Launchpad sends change notification updates to the person who requested the change <email> <lp-bugs> <qa-ok> <story-better-bug-notification> <story-better-notification-sending> <Launchpad itself:In Progress by yellow> < https://launchpad.net/bugs/548 >
[05:56] <lifeless> huwshimi: most bugs affect users, ui ones are privileged :)
[05:56] <lifeless> *aren't*
[05:56] <huwshimi> wallyworld_: Ouch.
[05:56] <huwshimi> lifeless: I know, but they're the ones I can fix :)
[05:57] <lifeless> I'm glad you are
[05:58] <huwshimi> lifeless: And UI bugs can make great technology horrible to use
[05:58] <lifeless> huwshimi: indeed
[05:58] <huwshimi> lifeless: Although it goes both ways
[05:58] <lifeless> huwshimi: indeed !
[05:58] <lifeless> bad technology can drive terrible UI
[05:58] <huwshimi> lifeless: You're glad I'm what?
[05:58] <lifeless> fixing
[06:00] <huwshimi> lifeless: I'm trying!
[06:04] <huwshimi> Another review if anyone feels the desire: https://code.launchpad.net/~huwshimi/launchpad/hover-row-43231/+merge/48877
[06:17]  * huwshimi is heading off, night people.
[08:40] <adeuring> good morning
[08:41] <poolie> hello abel
[09:03] <bigjools> good morning
[09:03] <jtv> morning bigjools
[09:07] <al-maisan> moin adeuring, bigjools and jtv!
[09:08] <jtv> morning al-maisan!
[09:08] <adeuring> hi al-maisan!
[09:08] <jtv> and mrevell too of course
[09:08] <mrevell> Hey there
[09:08] <mrevell> jtv, and me what? :)
[09:08] <al-maisan> hola mrevell
[09:08] <mrevell> Hello al-maisan!
[09:08] <jtv> mrevell: "moin"
[09:09] <mrevell> How is the land of Alps, skiing and low taxation?
[09:09] <jtv> And let's not forget molten cheese.
[09:09] <mrevell> Ah yes.
[09:09] <mrevell> And alp-horns.
[09:09] <bigjools> cowbell
[09:09] <al-maisan> it's great fun :)
[09:10] <mrevell> Excellent :)
[09:10] <al-maisan> once you start understanding "Schweizer Deutsch" which is the local dialect :)
[09:11] <mrevell> I visited Interlaken 20 years ago and I seem to remember they had a word other than "schloss" for castle.
[09:11] <mrevell> :)
[09:13] <al-maisan> not sure about that one .. but the Swiss do have their own vocabulary .. I came across some words I've never heard before .. "Znüni" would be one example
[09:14] <al-maisan> which is the Swiss term for "snack" :)
[09:23] <wgrant> bigjools: Did you have everything on a tmpfs?
[09:23] <bigjools> makes no difference
[09:25] <bigjools> I have huge gobs of memory anyway, everything gets cached easy
[10:09] <Ursinha> good morning
[10:55] <lifeless> jml: hi
[10:57] <jml> lifeless: hello
[10:57] <lifeless> jml: I think you may have missed https://bugs.launchpad.net/launchpad/+bug/713518
[10:57] <_mup_> Bug #713518: recipe description is mandatory <recipe> <Launchpad itself:New for jml> < https://launchpad.net/bugs/713518 >
[10:57] <jml> lifeless: I have not.
[10:57] <jml> lifeless: just haven't got around to it.
[11:01] <lifeless> jml: its the only untriaged bug we have; would be nice to have a clean slate.
[11:02] <jml> lifeless: ok.
[11:02]  * bigjools considers a Firefox patch to make ctrl-Q pop up an "are you sure" dialog
[11:03] <lifeless> bigjools: 'vimperator'
[11:09] <bigjools> lifeless: not sure I want to turn my browser into an editor
[11:09] <lifeless> him
[11:10] <lifeless> hmm
[11:10] <lifeless> there should be a foxerator then
[11:10] <bigjools> I think I tried it a year or so ago
[11:10] <bigjools> the simple solution is to warn on ctrl-q like every other browser does :)
[11:11] <LPCIBot> Yippie, build fixed!
[11:11] <LPCIBot> Project devel build (424): FIXED in 5 hr 44 min: https://hudson.wedontsleep.org/job/devel/424/
[11:23] <jml> bigjools: "every other browser" eh?
[11:23]  * bigjools waves hand
[11:23] <jml> :)
[11:23] <jml> chrome has disabled C-q
[11:24] <bigjools> "these aren't the browsers you're looking for"
[11:24] <jml> which isn't such a bad idea
[11:24] <bigjools> chrome has ctrl-shift-Q IIRC
[11:24] <bigjools> yeah
[11:24] <jml> oh, that's good to know
[11:25] <jml> tbh, I'd rather have the browser fast to start with an easy way of getting old tabs back than an Are you sure? box. Not that they're mutually exclusive.
[11:26] <bigjools> the problem is losing data in unsubmitted forms
[11:26] <bigjools> if it restored that, then fine
[11:28] <jml> bigjools: yeah, it ought to warn about that.
[11:28] <jml> or restore, as you say.
[11:28] <jml> I really want these damned driving lessons to be over.
[11:28] <bigjools> restore would be better although I imagine it'd do nothing for browser performance
[11:29] <bigjools> pass yer test then :)
[11:29] <jml> waiting for them to book the test!
[11:29] <jml> doesn't help that they went bankrupt and got bought out.
[11:31] <bigjools> !
[11:34] <lifeless> well, gnight
[11:36] <jml> bigjools: yeah. BSM went into receivership. Got bought by AA, I think.
[11:36] <bigjools> nn lifeless
[11:36] <bigjools> jml: damn, they were quite big too
[11:37] <jml> bigjools: yeah
[11:37] <jml> apparently they got bought a year or so ago by some guys who basically drove the business into the ground. (pardon the pun)
[11:37] <bigjools>  /o\
[11:37] <jml> all of the instructors are in work, but I imagine call centre & office staff might be facing probs.
[11:38] <jml> AA are going to keep the brand, because, well, they aren't stupid.
[11:38] <bigjools> I find it fun that AA can also mean something about drinking
[11:38] <jml> yeah. me too.
[11:39] <jml> grant me the serenity to get through this lesson without resenting my instructor
[11:39] <bigjools> on a more topical note, why do we get "Unknown entry URL:" all over the place when compiling wadl?
[11:41] <jml> I don't know.
[11:41] <jml> I think I used to have an idea, but if I did it has gone.
[11:41] <bigjools> I vaguely remember something in the past about having to fix stuff in lazr.restful
[11:42] <bigjools> eek, my eggs directory is busy
[11:46] <wgrant> IIRC it happens when the interface has no URL template defined.
[11:46] <wgrant> I think they might have to be defined in the XSLT..
[11:46] <wgrant> Which lives either in LP or launchpadlib.
[11:46] <wgrant> It moves around occasionally.
[11:46] <bigjools> we need to do 1 of 2 things:  1) fix it, or 2) remove the warning if it's not a problem
[11:47] <bigjools> I suspect the latter since we've lived with those warnings for as long as  I can remember
[11:47] <wgrant> Yes.
[11:48] <jml> hmm.
[11:48] <jml> I wonder if "No warning without a ratchet" is a sensible idea.
[11:55] <jtv> gmb: got a non-urgent branch for you… https://code.launchpad.net/~jtv/launchpad/bug-181368-parallelize/+merge/48903
[11:56] <gmb> jtv: Okidoke. I'll take a look at it when I come back from grazing.
[11:56] <jtv> OK
[12:00] <wgrant> jtv: !!
[12:00] <jtv> wgrant: ??
[12:00] <wgrant> Yay!
[12:00] <jtv> Yay?
[12:00] <wgrant> Parallel a-f.
[12:01] <jtv> Oh
[12:01] <jtv> Yeah that was easy.  Making sure it works is the hard part.
[12:01] <wgrant> Yeah.
[12:01] <jtv> Also, I first had to come up with some infrastructure of course.  But that's best done separately.
[12:02] <jtv> Of course the big question now is: will it help?  :-)
[12:02] <wgrant> It will.
[12:04] <deryck> Morning, all.
[12:05] <jtv> hi deryck!
[12:05] <jtv> wgrant: it will, assuming the processes don't start fighting over I/O.  Which I suppose will depend largely on FS cache.
[12:06] <wgrant> Well, yes, but I trust cocoplum to not be too shit.
[12:07] <jtv> If it is, there's one exceedingly simple fix: limit the number of parallel processes.
[12:07] <wgrant> Right.
[12:07] <jtv> Easy to do underneath the MF API.
[12:08] <jtv> And ta-daaa: you have something similar to go's thread management.
[12:09] <jtv> (Who made that insightful remark?  "You'd expect a leading search engine company to put a bit more thought into making sure people can search for their new programming language on the internet.")
[12:10] <al-maisan> sounds familiar but I can't recall who it was
[12:10] <al-maisan> agu
[12:10] <al-maisan> ooops
[12:13] <jtv> al-maisan: those last two things I imagine are sounds often heard in the land of fondu. :-)
[12:13] <al-maisan> he-he
[12:13] <al-maisan> jtv: agu = apt-get update
[12:13] <al-maisan> jtv: sorry to disappoint you ;)
[12:14] <jtv> Oh.  I thought it made a wonderful onomatopoeia but another GTF entry is good too. ☺
[12:14] <bigjools> hmmm since when did "test -1" stop working :(
[12:14] <jtv> bigjools: what did that do?
[12:15] <jtv> al-maisan: thank you for TLA number 23772.
[12:15] <al-maisan> jtv: you're welcome :)
[12:15] <bigjools> jtv: stops after first error
[12:15] <bigjools> kinda useful for pagetests
[12:15] <jtv> ah yes
[12:15] <jtv> that does sound useful
[12:16] <jtv> and I guess now it's not.
[12:17] <wgrant> So that *did* used to work.
[12:17]  * wgrant blames a zope.testing upgrade a few months ago.
[12:18] <wgrant> I'd been beginning to think it had never worked.
[12:19] <bigjools> jtv does the TLA list include TLA itself?
[12:20] <jtv> bigjools: what do _you_ think?
[12:20] <bigjools> heh
[12:20] <bigjools> you need to start an ETLA list
[12:20] <jtv> bigjools: even the name includes it… GTF stands for the GPL'ed TLA FAQ
[12:20] <jtv> Everyone keeps saying that, but everyone can do it themselves!
[12:20] <al-maisan> every self-respecting TLA list obviously needs to include "TLA" ;)
[12:20] <bigjools> I am amazed that you'd never heard of LFLs though
[12:21] <jtv> http://paste.ubuntu.com/564394/
[12:21] <jtv> bigjools: I think that's because where I come from they're called Blinkenlights.
[12:21] <bigjools> Two Letter Acronym / Three-Letter Abbreviation
[12:21] <bigjools> inconsistency!
[12:21]  * jtv was in the Computer History Museum recently and saw the real blinkenlights
[12:22] <bigjools> holy crap the ppa page tests crawl
[12:22] <jtv> Perhaps a 2-letter one should be called a bilexical acronym (BA).
[12:23] <bigjools> is "jtv" in the GTF? :)
[12:23] <jtv> $ tla jtv
[12:23] <jtv> JTV	Jeroen Thomas Vermeulen
[12:23] <jtv> JTV	Jordan TeleVision
[12:23] <bigjools> \o/
[12:23]  * jtv wonders if we need an IRC bot to answer TLA inquiries
[12:24] <bigjools> jtv: gimme your API details, I'll code it into edbot
[12:24] <jtv> urrr there's a shell script that wraps grep. :)
[12:24] <bigjools> pfff
[12:24] <jtv> Although there's also a "GTF Monitor" written in Java.
[12:26] <al-maisan> jtv: so, it is enterprise ready then ;)
[12:26] <jtv> ouch :)
[12:26] <al-maisan> sorry .. could not resist :P
[12:27] <bigjools> java gives me nightmares just thinking about it
[12:27] <al-maisan> COBOL^Wjava has a safe albeit "limited" future according to tech pundits
[12:27] <al-maisan> whatever that means
[12:33] <wallyworld> what's wrong with java?
[12:38] <bigjools> where do I start ...
[12:52] <wallyworld> well, nothing is perfect but you can't argue with java's adoption and usefulness in the enterprise
[13:01] <jtv> A lot of that, in turn, is because it supports large-scale software development by low-skill developers.
[13:01] <wallyworld> bigjools: i want to be able to nominate the rev for release. it's now on qastaging.  do you need to do any final checks to ensure the debversion functionaity if all ok?
[13:01] <jtv> Therefore, I wonder if Oracle will re-brand Java as Enterprise PHP.
[13:01] <bigjools> wallyworld: I'll take a quick wander around some pages, gimme 5 mins
[13:02] <wallyworld> jtv: hey, i was/am a java dev for 13 years. who you calling low skill :-)
[13:03] <jtv> wallyworld: having seen you with a Bushmaster including telescopic sight, I'll gladly point out the "supports" as not implying "requires."
[13:03] <jtv> Gladly, nodding politely, and grinning slightly worryingly
[13:03] <wallyworld> jtv: i know where you live :-)
[13:03] <jtv> Good.  Glad that's all settled.
[13:05] <wallyworld> gary_poster: morning to you. i would love it if you could take a couple of minutes to double check qastaging to ensure the person settings db stuff is all 100% ok so I can select the rev to deploy and hence open pqm.
[13:06]  * bigjools stabs staging
[13:06] <wallyworld> gary_poster: rev 12338 has the db patch included and is the rev running on qastaging now
[13:06] <bigjools> bloody timeouts
[13:07] <wallyworld> yeah, those timeouts sure take the "joy" out of qa :-)
[13:08] <bigjools> I can't test this change since the damn page is timing out
[13:09] <wallyworld> :-(
[13:09] <bigjools> I'll take a slightly less demanding PPA page
[13:09] <wallyworld> i find hitting refresh several times eventually makes it work
[13:09] <bigjools> not in this case :(
[13:11] <gary_poster> wallyworld: hi.  thank you, on it
[13:11] <wallyworld> awesome
[13:13] <bigjools> wallyworld: it looks ok
[13:13] <wallyworld> bigjools: thanks muchly
[13:13] <bigjools> here's hoping pqm can open
[13:14] <wallyworld> i hear you
[13:15] <bigjools> right, food time
[13:24] <gary_poster> wallyworld: qastaging is happy
[13:24] <wallyworld> gary_poster: \o/ thank you
[13:24] <gary_poster> :-) thank you
[13:37] <wallyworld> \o/ PQM is open again
[13:38] <gary_poster> yay thanks wallyworld
[13:40] <wallyworld> gary_poster: np. only just over one day till rollout. can't come soon enough  :-)
[13:40] <gary_poster> heh, I hear you :-)
[13:43] <leonardr> gmb, if you're not reviewing anything atm, can you take https://code.launchpad.net/~leonardr/launchpadlib/bug-712808/+merge/48830 ? i need it to get the new launchpadlib into natty
[13:44] <gmb> leonardr: I'm just in the middle of reviewing jtv's branch. I can take a look at it after that, though.
[13:44] <leonardr> gmb, great
[13:57] <gmb> jtv: Most of the tests in TestFTPArchiveRunApt need comments, if you please. Otherwise I'm happy with the code, but I'm not convinced that I actually have enough domain knowledge to review this - my brain seems to keep skipping off it.
[13:58] <gmb> jtv: I'll give it r=me, but you might want to get a review from someone who knows more about it than I do.
[14:03] <jtv> gmb: thanks—the tests were an attempt to make the identifiers speak for themselves, so apparently that failed.  The domain knowledge is actively being contributed by william & julian.
[14:04] <gmb> jtv: Well, you could be running up against my brain being tired today.
[14:05] <leonardr> gmb, i don't know anything about it but i'm fresh, i can take a look
[14:05] <gmb> jtv: ^^
[14:07] <gmb> leonardr: https://code.launchpad.net/~jtv/launchpad/bug-181368-parallelize/+merge/48903 is the MP in question
[14:08] <leonardr> ok
[14:13] <jtv> leonardr: appreciated!
[14:16] <leonardr> don't thank me yet...
[14:16] <jtv> uh-oh ☺
[14:17] <leonardr> actually, it's not so bad since i reviewed your CommandSpawner branch last week
[14:18] <gmb> leonardr: r=me on your branch, btw.
[14:18] <leonardr> gmb, great
[14:19] <jtv> leonardr: as I recall, the Pilfering Puppy distro release led to questions.  There's also an Ominous Okapi.
[14:20] <jml> meh. X redraw issues still present.
[14:25] <bigjools> jml: intel?
[14:30] <leonardr> jtv, test_getArchitectureTags_contains_no_duplicates would be easier to read if you created the architecture tag and processor family ahead of time. otherwise it looks like there's something special about pilfering puppy
[14:30]  * jtv looks
[14:31] <jtv> leonardr: I'm a bit worried about making the setup too long though—always a problem with Soyuz
[14:31] <leonardr> jtv: you could just assign ominous_arch.architecturetag and .processorfamily to generic-sounding variables
[14:32] <leonardr> comments would also help. that's the only test it's been difficult for me to read so far
[14:32] <jtv> What if I do that, but in a separate "give me two identical archdistroserieses but for different release series of the same distro" method?
[14:32] <jtv> Maybe even a "how many archdistroseries would you like for this distro and architecture" argument?
[14:33] <leonardr> jtv: sure. i think you'd use that in the next test as well?
[14:33] <jtv> Exactly.
[14:33] <jtv> And with the extra argument, I might be able to use the same method for creating a single archdistroseries as well.
[14:33] <jtv> Not that that's too much use though.
[14:33] <jtv> It just seems slightly easier to explain.
[14:34] <leonardr> i think your first idea was better
[14:34] <jtv> Can I play with it for a bit and get back to you?
[14:35] <leonardr> sure
[14:36] <leonardr> jtv: did the last test fail because the architecture started with --?
[14:36] <leonardr> or because you got it to use some "bogus-config"?
[14:37] <jml> bigjools: yeah
[14:37] <jtv> leonardr: frankly I don't know.  I only wanted it to break—and the other tests confirm that normally the exception does not happen.
[14:37] <bigjools> jml: same here - the intel driver is buggy as hell
[14:37] <jtv> leonardr: call it blind hatred as a testing methodology.
[14:37] <jml> bigjools: this is natty
[14:37] <jml> bigjools: worked fine in mav
[14:37] <bigjools> jml: it's been fucked since maverick
[14:37] <jtv> leonardr: I just piled on whatever I could to make it break.
[14:37] <bigjools> I guess gnome didn't prod it in the same way as kde until natty
[14:38] <bigjools> I get GPU hangs
[14:38] <jml> bigjools: I just get redraw bugs. I have to PgUp then PgDown every time someone says something on IRC
[14:39] <bigjools> jml: yeah I get that too :)
[14:39] <leonardr> jtv: i'm a little bit worried at what looks like an argument injection attack
[14:39] <jtv> leonardr: yes, that's what it is—but only our code could do that.
[14:39] <bigjools> jml: turn off compositing and see if that helps
[14:39] <jml> bigjools: done so, doesn't.
[14:39] <bigjools> :(
[14:39] <jtv> leonardr: it's basically a test attacking the regular code, and showing that it leads to the appropriate exception.
[14:40] <leonardr> jtv: you couldn't relaly create a distro arch series called --fail-for-my-test?
[14:41] <jtv> leonardr: that's an interesting point that I'll have to look into.
[14:42] <jcsackett> gmb, leonardr: when you get the chance i have an mp: https://code.launchpad.net/~jcsackett/launchpad/bugtasks-deacitvated-context-632847/+merge/48925
[14:42] <gmb> jcsackett: I'll take a look in a minute
[14:42] <jcsackett> gmb: thanks!
[14:43] <bigjools> what is wrong with this documentation:
[14:43] <bigjools> param principal: The principal for the request
[14:43] <jml> :param principal:
[14:44] <jml> also, it doesn't say what a principal is.
[14:44] <bigjools> 1 cookie to jml
[14:44] <jml> but maybe other docs around it make it clear.
[14:44] <bigjools> see lib/lp/testing/views.py
[14:44] <leonardr> jtv: r=me once you clarify the tests, especially the last one
[14:44] <bigjools> well, see most of our docstrings.... :/
[14:44] <bigjools> it drives me batty
[14:44] <jtv> leonardr: still looking into the architecture tag… bigjools, where do architecturetags come from?
[14:45] <bigjools> distroarchseries
[14:45] <jml> bigjools: not the best docs ever.
[14:45] <jtv> bigjools: Yes but who puts them there?
[14:45] <bigjools> jtv: we do, and we need to do better
[14:46] <jtv> leonardr, bigjools: how about I add some validation as part of a separate branch that can even bypass this one?
[14:46] <leonardr> jtv: i'm not sure what you mean by 'bypass this one'. the other branch will go in first?
[14:46] <jtv> leonardr: also, once I have a nice & short test setup, do you feel the tests will still need comments?
[14:47] <jtv> leonardr: that's a possibility, yes, since this branch is being held up by other things.
[14:47] <leonardr> jtv: the only ones i felt needed comments were the two i called out. i'll take another look once you refactor
[14:47] <jtv> leonardr: great!  Doing that now.
[14:50] <bigjools> jtv: what do you need to validate?  Sorry, I'm missing some context apart from the a-f branch.
[14:50] <jtv> bigjools: make sure there can't be any weirdness in the tag, so people can't blow up the apt-ftparchive call.
[14:51] <bigjools> jtv: ok I see.
[14:51] <nigelb> Hey, someone from the lp team can talk about daily builds and lp at UDW?
[14:51] <bigjools> god DAMN openid + oops page.... >:(
[14:52] <bigjools> jtv: ok now I know what you're doing, you need to use the Processor table
[14:52] <jml> nigelb: yeah, probably.
[14:52] <bigjools> see the "name" column
[14:53] <bigjools> it has all the tags
[14:53] <jtv> thanks
[14:53] <nigelb> jml: can I put you down for it? :)
[14:53] <bigjools> jtv: and this is an excellent piece of validation
[14:53] <jml> nigelb: I'm not going to volunteer right now, because I need to know times, dates and so forth
[14:53] <nigelb> jml: I can show you empty slots and you can pick one
[14:53] <jml> nigelb: could you email lp-dev?
[14:53] <nigelb> jml: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable/
[14:53] <nigelb> jml: yup, will do
[14:54] <jtv> bigjools: so the validation happens at the processor, not at the distroarchseries?
[14:54] <jml> nigelb: thanks.
[14:55] <bigjools> jtv: if you want to make sure the tag is a valid one, look it up as Processor.name
[14:55] <jtv> bigjools: isn't that ensured when the DAS is created?
[14:55] <bigjools> jtv: quite probably - I'd be surprised if this sort of thing is not checked repeatedly
[14:57] <jtv> leonardr, bigjools: also, my impression is that the scope for breaking the apt-ftparchive invocation is limited to making the invocation fail, and it can be done only by someone with the power to create an architecture tag to be used for that build.
[14:58] <leonardr> jtv: ok, so it's not a big problem
[14:58] <nigelb> jml: Mailed :)
[14:58] <bigjools> jtv: correct - it's whomever sets up the DAS
[14:58] <jtv> leonardr: I don't _think_ so, but best be careful. :)
[14:58] <jml> nigelb: thank you.
[14:58] <jtv> bigjools: is that a privileged operation?
[14:58] <bigjools> yes
[14:58] <bigjools> did Ian open PQM after the release revno was decided?
[14:59] <jtv> bigjools: then I think the risk of this particular use is acceptable.
[14:59] <bigjools> jtv: I think belt + braces is good though
[14:59] <bigjools> protecting the archive is always a good idea :)
[15:00] <jtv> bigjools: OK, then how about we add a constraint and a UI validator to the tag?
[15:00] <bigjools> jtv: you might be fighting sampledata :/
[15:01] <jtv> oh good :/
[15:01] <bigjools> which is a world of pain in soyuz
[15:01] <jtv> You're telling a Translations guy…
[15:01] <bigjools> :)
[15:02] <Ronnie> anoyone knows hoe to limit the credentials for websites that ask user to access their LP account,  with only: allow_access_levels=["WRITE_PRIVATE"]
[15:03]  * bigjools also needs to send a patch to the bazaar team so that "bzr doff" does something
[15:11] <benji> bigjools: it should show you all the lines that haven't changed
[15:11] <gmb> lol
[15:11] <bigjools> :)
[15:16] <Ronnie> im talkin about: https://help.launchpad.net/API/ThirdPartyIntegration#Website%20integration
[15:16] <leonardr> Ronnie: what website is this?
[15:17] <Ronnie> some testings for loco-directory
[15:18] <leonardr> Ronnie: can you explain in more detail what you want? are you a user of this website or are you the one setting up the integratino?
[15:18] <leonardr> we don't have a good story for website-to-website integration right now
[15:18] <allenap> gmb: Fancy a fairly trivial review? https://code.launchpad.net/~allenap/launchpad/better-caching-iterator/+merge/48927
[15:19] <gmb> I've still got to look at jcsackett's, but after that, sure (if leonardr doesn't get there first)
[15:19] <leonardr> allenap, i'll do it
[15:20] <allenap> gmb, leonardr: Thank you :)
[15:20] <Ronnie> leonardr: im a developer of the loco website. currently there is a link on the team pages (Example: http://localhost:8000/teams/ubuntu-nl (you need to login first)) (https://launchpad.net/~ubuntu-nl/+join) which results in leaving the loco-directory page. therefore i want to do this on the backend
[15:22] <Ronnie> some ubuntu teams do not use the loco-directory much, because they should register on LP and manage their profiles on LP (which in english only). As the loco-directory we try to make the interaction with LP partly invisible
[15:23] <leonardr> Ronnie: ok, when you redirect the user to launchpad.net/+authorize-token, you will add the query argument "allow_permission=WRITE_PRIVATE"
[15:23] <Ronnie> leonardr: that works, thx
[15:25] <jtv> bigjools, leonardr: I've updated my test setup.  Those two tests are much cleaner now.
[15:26] <jtv> Shall I add validation in a separate branch?  I don't think my branch particularly affects what a bad tag might or might not break.
[15:26] <leonardr> jtv, sure another branch is fine
[15:26] <jtv> Thanks.
[15:27] <gmb> jcsackett: One minor comment on your branch, but it's r=me.
[15:30] <jtv> leonardr: by the way, just the bogus config turns out to be sufficient to break the script run in the test.  So I removed the bogus option.
[15:30] <leonardr> allenap, r=me
[15:30] <bigjools> abentley: lp/services/job/tests/test_runner.py / test_timeout is failing in db_lp, would you mind having a look please?
[15:30] <leonardr> jtv: i think you should test both a failure to invoke the script and the failure of the script?
[15:30] <allenap> leonardr: Thanks.
[15:31] <abentley> bigjools, looking.
[15:31] <bigjools> thanks
[15:31] <jtv> leonardr: I don't see a difference—the question is what happens when the command returns failure.  Either way the command gets run, and breaks while processing its arguments.
[15:32] <leonardr> jtv: ah, i didn't realize the command is run either way
[15:32] <leonardr> ok, just the bogus config is fine
[15:32] <jtv> :)
[15:32] <jtv> Thanks.
[15:32] <abentley> bigjools, thumper was looking at that failure last.  I don't know what conclusions he came to.
[15:32] <bigjools> abentley: ah ok, didn't realise it was an old one, I only just saw the email pop up
[15:33] <bigjools> seems like StuckJob is not really stuck
[15:34] <abentley> bigjools, you could probably increase the length of time it waits, but I don't understand how it could fail to time out.
[15:35] <abentley> bigjools, I've never observed it locally.
[15:37] <abentley> bigjools, this is bug #681770
[15:37] <_mup_> Bug #681770: Failure in lp.services.job.tests.test_runner.TestTwistedJobRunner.test_timeout <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/681770 >
[15:37] <bigjools> aha
[15:38] <bigjools> it was reported in november!
[15:39] <abentley> bigjools, or possibly bug #505913
[15:39] <_mup_> Bug #505913: TestTwistedJobRunner.test_timeout fails intermittently <lp-foundations> <spurious-test-failure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/505913 >
[15:40] <jml> deryck: are we able to use YUI 3.3 stuff in Launchpad yet?
[15:41] <deryck> jml, not yet.  but I'm about an hour for having my upgrade branch ready for review.
[15:41] <jml> deryck: sweet. :)
[15:41] <deryck> jml, so another day or two and you can have your charts ;)
[15:43] <benji> has anyone seen "psycopg2.ProgrammingError: type "debversion" does not exist" while doing a make schema?
[15:43] <bigjools> abentley: is that really doing a sleep(30) in the middle of  test :/
[15:44] <jml> benji: yes.
[15:44] <abentley> bigjools, yes, so that it will timeout after a few seconds.
[15:44] <jml> benji: I haven't had the opportunity to chase it any further than that.
[15:45] <bigjools> abentley: we should be winding the reactor clock forwards to simulate that.... would be a lot more reliable
[15:46] <abentley> bigjools, sounds low-level and risky to me.
[15:46] <benji> jml: thanks; well I'll see what I can do
[15:47] <bigjools> abentley: it's a standard twisted testing approach, it's done like that in a few places
[15:47] <jml> there's an object that implements the same interface as the IReactorTime (spelling?) and has a special .advance() method to change the time to something in the future.
[15:47] <jml> relies on passing the reactor in.
[15:47] <bigjools> jml: Clock() :)
[15:48] <jml> bigjools: thanks. not sure if I got the interface right though.
[15:48] <bigjools> I don't know what its interface is so I didn't pick you up on that
[15:49] <abentley> bigjools, anyhow, I have trouble understaing how a job could have a timeout of 1 second, yet complete successfully after 30 seconds.
[15:49] <bigjools> abentley: yeah something is weird
[15:50] <bigjools> what is the lease_length unit?
[15:51] <jcsackett> gmb: thanks for the r. :-)
[15:52] <gmb> np
[15:52] <abentley> bigjools, seconds, IIRC.
[16:08] <benji> jtv: apt-get install postgresql-8.4-debversion
[16:09] <jtv> benji: Permission denied
[16:09] <benji> sudo make me a sandwich
[16:09] <benji> I guess I should file a bug and/or point this out on the dev list.
[16:09] <jtv> benji: No rule to make target `me'.  Stop.
[16:09] <jtv> benji: care to explain what you're talking about?
[16:10] <benji> jtv: that fixes the "psycopg2.ProgrammingError: type "debversion" does not exist"
[16:10] <jtv> benji: I have a vague recollection of hearing about that… something for bigjools maybe?
[16:11] <benji> jtv: of course, it would help if you were jml, but that's a side issue :P
[16:11] <bigjools> benji: update lp-deps
[16:11] <jtv> benji: I thought there was something along those lines… help whom though, I wonder—him, you, me, or the team?
[16:11] <benji> jtv: :)  I need all the help I can get.
[16:11] <bigjools> s/benji/jtv/
[16:12] <jtv> bigjools: now don't _you_ start!
[16:12] <jtv> bigjools: what was that about?
[16:12]  * bigjools is desperately trying to get context :)
[16:13]  * benji starts over.
[16:14] <benji> jml: apt-get install postgresql-8.4-debversion fixes the "psycopg2.ProgrammingError: type "debversion" does not exist" problem
[16:14] <jml> benji: thanks.
[16:14] <bigjools> wait
[16:14] <bigjools> just update lp-dependencies
[16:14] <bigjools> jml ^
[16:15] <jml> launchpad-developer-dependencies is already the newest version.
[16:19] <sinzui> gmb: leonardr: can either of you review https://code.launchpad.net/~sinzui/launchpad/recipe-owner-widget-1/+merge/48937
[16:20] <leonardr> sinzui, i got it
[16:20] <LPCIBot> Project db-devel build (349): FAILURE in 5 hr 36 min: https://hudson.wedontsleep.org/job/db-devel/349/
[16:22] <jml> benji: which Ubuntu are you using?
[16:23] <benji> jml: maverick
[16:27] <jml> benji: huh.
[16:28] <jml> I can understand lp-dependencies being wrong for me since I'm on natty.
[16:28] <benji> jml: my install was screwed up anyway, so I'm not surprised, launchpad-developer-dependencies wasn't even installed
[16:29] <jml> benji: ahh.
[16:37] <gary_poster> gmb or leonardr, is it still appropriate to highlight newly-created MPs, or is it now considered pushy? :-)
[16:37] <gary_poster> If not pushy, https://code.launchpad.net/~gary/launchpad/bug713392/+merge/48939 :-D
[16:37] <gmb> gary_poster: It's fine :)
[16:37] <leonardr> gary: it's fine by me
[16:37] <gary_poster> ok thanks :-)
[16:37] <gmb> gary_poster: I'll look shortly.
[16:37] <gary_poster> awesoe
[16:37] <gary_poster> m
[16:41] <leonardr> sinzui, having a bit of difficulting understanding your branch, so going to try out the code
[16:41] <sinzui> yes?
[16:42] <sinzui> leonardr: https://code.launchpad.dev/~mark/firefox/release--0.9.1/+new-recipe
[16:43] <sinzui> leonardr: and https://code.launchpad.dev/~mark/firefox/release--0.9.1/+register-merge
[16:44] <jcsackett> gary_poster: question for you about bug 623099. got a sec?
[16:44] <_mup_> Bug #623099: AttributeError filing a bug using the API <lp-foundations> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/623099 >
[16:48]  * gary_poster looks jcsackett 
[16:49] <jcsackett> i have the feeling this might be going away as the edge redirects go away, gary_poster. is that wishful thinking on my part?
[16:51] <gary_poster> I *think* it is wishful, jcsackett...I think this redirection is for old project names
[16:51] <gary_poster> and I don't think that the edge/not-edge part of it is going to affect much
[16:53] <gmb> gary_poster: r=me
[16:53] <gary_poster> thanks gmb
[16:53] <leonardr> sinzui: "if '<label' in text" is a little hacky (for instance, it won't catch "< label"). why did you choose that over "Redefine _renderItem() to so that a wrapping label is not added,"
[16:54] <jcsackett> gary_poster: ah, i had missed the project name redirect.
[16:54] <sinzui> leonardr: we will shoot any engineer who constructs markup like "< label"
[16:55]  * jcsackett is blinded by subdomains.
[16:55] <gary_poster> jcsackett: :-)
[16:55] <leonardr> sinzui: what if we shot any engineer who constructed their own <label> tag?
[16:56] <sinzui> leonardr: but I agree is a hack. We know that a label cannot cannot contact a label so any occurrence of "<label" in the text means we cannot generate a wrapping label
[16:56] <leonardr> why is it important to allow the subclass to generate its own label? it doesn't seem like anything special to me
[16:57] <sinzui> leonardr: Some are doing more than for="" attrs, they are adding scripts to them
[16:57] <leonardr> i see
[16:57] <sinzui> leonardr: other have special rules for generating the id of the for="" attr
[17:02] <leonardr> sinzui: i don't see UNSAFE_TERM used in TestSuggestionWidgetCase. are you showing that it doesn't show up at all because it's not returned by _getSuggestions?
[17:03] <leonardr> if so, why make it unsafe? i thought you would demonstrate that it was rendered properly
[17:03] <sinzui> leonardr: oops. I cargo culted that with the intention to use it in a test to veryify something waky does not happen
[17:04] <leonardr> sinzui: ok, add that test
[17:04] <sinzui> leonardr: I think I should write a test with UNSAFE_TERM to verify a bad display name does not render markup
[17:04] <leonardr> i agree
[17:08] <leonardr> sinzui: r=me with that added test and a couple other trivial changes
[17:09] <sinzui> thank you leonardr
[17:22] <jcsackett> sinzui: do you know what mechanism is responsible for redirection from old product names? e.g. ubuntufontbetatesting => ubuntu-font-family
[17:23] <sinzui> jcsackett: yes, Launchpad's root object uses pillar name lookup and if it is an alias, it gets the real pillar
[17:24] <jcsackett> sinzui: thanks.
[17:36] <jml> woot
[17:36] <jml> working IRC client.
[17:37] <jml> and emacs
[17:41] <Ronnie> leonardr: i have some problems with the Launchpad website integration. https://help.launchpad.net/API/ThirdPartyIntegration#Website%20integration . Everytime i do the request, a have to give access. im probably doing something wrong. http://paste.ubuntu.com/564580/
[17:48] <leonardr> Ronnie: are you storing the credentials in a persistent data store, and reusing them? i don't see that in your code
[17:49] <Ronnie> oh, i have to pickle the credentials and save it into the DB?
[17:51] <leonardr> Ronnie: yes, otherwise launchpad can't identify you with the client who made the previous request
[17:52] <Ronnie> leonardr: what happens when the user at some point decides to revoke the authentication?
[17:52] <leonardr> Ronnie: you'll try to use the credentials on the web service and you'll get a 401, so you'll have to redirect them to authorize new credentials
[17:52] <Ronnie> oke, thx
[17:55] <Ronnie> how much steps / user actions would it take if the user needs to create an LP account from an login.ubuntu.com openid account?
[17:59] <leonardr> Ronnie: i don't know.
[17:59] <leonardr> you'd have to do a click to https://login.launchpad.net/+new_account -- i don't know what would happen after that
[18:00] <Ronnie> leonardr: can i test this on staging without creating real new accounts?
[18:00] <Ronnie> or would this still trigger the openid server to create a new openid
[18:01] <leonardr> Ronnie: good question. maybe salgado knows
[18:04] <salgado> Ronnie, leonardr, I think you should be able to create new accounts on staging; it uses login.staging.lp.net instead of login.lp.net
[18:04] <leonardr> there you go
[18:04] <Ronnie> salgado: thx ill have a look then
[18:09] <leonardr> bigjools, i'm reviewing your branch
[18:16] <Ronnie> salgado: ah, login.staging.launchpad.net runs on django. got an error ;)
[18:17] <Ronnie> http://paste.ubuntu.com/564602/
[18:17] <Ronnie> salgado: any more information you need?
[18:19] <salgado> Ronnie, I don't know much about our openid provider; it's maintained by another team
[18:19] <Ronnie> salgado: who should i contact?
[18:19] <salgado> sinzui, do you know who Ronnie should talk to about that error on login.staging.lp.net?
[18:21] <sinzui> salgado: Not really. I think a losa + stuart metcalfe, but my knowledge is 19 months our of data
[18:21] <sinzui> salgado: ricardokirkner may have work on it in the last 6 months
[18:23] <salgado> sinzui, indeed, I've asked him
[18:35] <leonardr> bigjools, r=me with some additional thought about wording
 I think staging may be currently broken (at least login.staging.ubuntu.com is)
 because we deployed some code to staging last week which requires a db upgrade
 which was reset on monday (as it usually does)
 we have a redeploy on schedule for this week
[18:41] <salgado> Ronnie, ^
[18:42] <Ronnie> ok, good to know
[18:42] <Ronnie> the registration process did work tough, except for the error
[18:45] <salgado> Ronnie, in the future, if you have issues with login.lp.net (including the staging version), you can report it on #canonical-isd
[18:46] <Ronnie> salgado: ok, i will next time
[18:46] <Ronnie> thx for the help
[18:47] <salgado> sinzui, ^ (fyi)
[20:18] <thumper> morning
[20:18] <thumper> I'm trying to work out when to run for coffee
[20:18] <thumper> my machine is still not right :-(
[20:25]  * thumper leaves his home office in favour of shared office with coffee shop attached
[20:47] <lifeless> jml: still around ?
[20:54] <thumper> gah
[20:54] <thumper> shared office space has blocked IRC
[20:54] <thumper> running on 3g tether
[20:54] <lifeless> :(
[20:54] <lifeless> shoot em
[20:54] <mwhudson> wtf
[20:54] <thumper> I've asked him on facebook :)
[20:54] <mwhudson> freenode runs on a bunch of non-standard ports
[20:55] <thumper> I'm connecting to port 4242 at home
[20:55] <mwhudson> if they're doing packet inspection to block the irc protocol, shoot them with great force
[20:56] <thumper> mwhudson: I think they have just blocked a shed load of high ports
[20:56] <thumper> I can ssh home
[20:56] <mwhudson> ah ok
[20:56] <thumper> I wonder if mumble works
[20:57] <thumper> skype is open
[20:58] <thumper> I wonder how well mumble works over 3g
[21:00] <mwhudson> latency is the killer
[21:00] <mwhudson> (also most 3g contracts forbid voip)
[21:02] <cjohnston> so does the new squads mean that blueprints are going to be fixed?
[21:05] <abentley> cjohnston, updating blueprints is part of the plan.
[21:06] <wallyworld_> thumper: i could hear you fine, maybe you didn;t hear me
[21:06] <cjohnston> yay!
[21:06] <cjohnston> any idea as to a time frame abentley ?
[21:06] <abentley> cjohnston, I don't have that information handy.
[21:06] <thumper> wallyworld_: yeah, didn't hear you
[21:07] <wallyworld_> hmmm. stupid mic
[21:07] <lifeless> cjohnston: we're probably going to be doing the IssueTracker LEP
[21:08] <cjohnston> is there some further info on that lifeless ?
[21:08] <cjohnston> (somewhere)
[21:08] <wallyworld_> thumper: my mic is borked
[21:08] <lifeless> cjohnston: its not scheduled yet, we're currently driving our cycle time down and doing fewer things faster & better
[21:08] <thumper> wallyworld_: so fix it :)
[21:08] <wallyworld_> trying
[21:08] <cjohnston> cool
[21:08] <lifeless> cjohnston: https://dev.launchpad.net/IssueTracker
[21:08] <cjohnston> thanks
[21:08] <thumper> mwhudson: mumble works over 3g
[21:08] <thumper> mwhudson: not too bad
[21:09] <mwhudson> cool
[21:10] <abentley> lifeless, you estimated 6-12 months, right?
[21:11] <lifeless> abentley: something like that yes; AIUI this is reasonably high on jmls list
[21:12] <lifeless> high enough that the product team were doing analysis with mpt the whole epic
[21:13] <leonardr> thumper, are we having a standup?
[21:13] <thumper> leonardr: yep
[21:13] <thumper> leonardr: wally and I are in mumble
[21:13] <leonardr> ok
[21:13] <thumper> StevenK: ping
[21:24] <leonardr> thumper et al: https://code.launchpad.net/~leonardr/launchpad/use-web-link
[21:25] <thumper> StevenK: nm, just remembered where you are
[21:27] <lifeless> wallyworld_: here ?
[21:28] <thumper> w00t
[21:28] <thumper> got the ports un-firewalled
[21:28] <thumper> it's all good
[21:31] <wallyworld_> lifeless: i just have to duck out and drop the kid to school, i'll ping you when i'm back
[21:31] <lifeless> wallyworld_: ok, was just checking pqm is opened
[21:31] <wallyworld_> lifeless: yes, opened last night. i sent an email
[21:31] <lifeless> \o/
[21:31] <lifeless> the mail didn't mention pqm :)
[21:31] <wallyworld_> yeah, tell me about it
[21:32] <wallyworld_> yes it did?
[21:32]  * wallyworld_ looks
[21:32] <lifeless> hmm, perhaps I'm blind
[21:32] <lifeless> I saw 'rev selected'
[21:32] <lifeless> anyhow, you have to pop out
[21:32] <lifeless> so shoo
[21:33] <wallyworld_> agggh. i "refacroed" the email as i was writing it and cut out the bit about pqm :-(
[21:33] <wallyworld_> and i can't type
[22:02] <Ronnie> lifeless: ping
[22:02] <lifeless> hi
[22:02] <Ronnie> wow thats quick :D
[22:03] <Ronnie> i trying to implement launchpadlib (user/website access) into loco-directory
[22:03] <Ronnie> with the new approach the following steps are needed (worst case secnario): http://paste.ubuntu.com/564709/
[22:04] <Ronnie> it still pretty much
[22:04] <Ronnie> did you have tought for other ways to implement>
[22:05] <Ronnie> or can the pages seen in step 9-12 be translated?
[22:06] <Ronnie> or is it possible the change (on request) the LP openid provider from login.launchpad.net to login.ubuntu.com ?
[22:07] <Ronnie> ow, maybe i can make LD to skip step 12 and check for ourself (altough the popup should still be closed)
[22:11] <lifeless> so, is LD grabbing a launchpadlib oauth token on the users behalf?!
[22:11] <Ronnie> yes, its a possible way i think it is most userfriendly
[22:11] <Ronnie> for users who do not want it, can change their data on LP itself tough
[22:11] <lifeless> is the LD deployment area secured ?
[22:12] <Ronnie> good question
[22:12] <Ronnie> mhall119: ^
[22:12] <Ronnie> cjohnston: ^
[22:12] <lifeless> so, as long as the LD deployment is really secure, I think this is reasonable
[22:13] <lifeless> its what OAuth is all about, after all - the ability for e.g. twitter to log into gmail
[22:13] <Ronnie> the LD is (i tohught) maintained by caninical-isd
[22:13] <lifeless> It may well be, and if so thats great.
[22:13] <Ronnie> yes, with OAuth the server must really be trusted
[22:13] <wgrant> lifeless: With Launchpad's current... security... I'd say that allowing any other website to have an OAuth token on your behalf is beyond foolish.
[22:14] <lifeless> wgrant: in principle I agree, but the LD code can be vetted and is open
[22:14] <lifeless> if its deployed by losas the isn't a risk due to who is operating it :)
[22:14] <lifeless> s/the/there/
[22:18] <wgrant> :(
[22:18] <lifeless> wgrant: I'd be delighted for us to be much more granular
[22:18] <lifeless> 'LD wants permission to add you to / remove you from teams starting with ubuntu-loco-*'
[22:18] <wgrant> No, not that. IArchive['publish'] now uses "publish" to describe its function, and its description starts with 'Whether'
[22:19] <thumper> psycopg2.ProgrammingError: type "debversion" does not exist
[22:19] <lifeless> bigjools patch ?
[22:19] <thumper> on make schema
[22:19] <thumper> WTF?
[22:19] <lifeless> thumper: update your lp deps
[22:19]  * thumper sighs
[22:19] <thumper> doing that now
[22:19] <wgrant> lifeless: Yes.
[22:19] <lifeless> wgrant: why do we need disabled archives?
[22:20] <wgrant> lifeless: OEM does.
[22:20] <lifeless> not whom, why
[22:20] <wgrant> lifeless: They have approved moving the flags to +admin.
[22:20] <wgrant> I don't really know.
[22:20] <wgrant> cody-somerville would know.
[22:20] <lifeless> cody-somerville: ^
[22:20] <wgrant> lifeless: The difficulty is that Zope security is crap.
[22:21] <wgrant> So it's hard to have .publish and .enabled on +edit for copy archives, and +admin everywhere else.
[22:22] <lifeless> wgrant: what makes that hard? Is it a lack of separate types, or lack of an adapter declaring when view/edit are available
[22:23] <wgrant> lifeless: I can move the widgets easily, but I can't say that both launchpad.Edit and launchpad.Commercial can set them.
[22:24] <lifeless> so why do copy archives need .enabled ?
[22:25] <lifeless> wgrant: also, you'd just say that .edit is needed, and grant .edit to commercial admins on such objects
[22:25] <cody-somerville> lifeless, Hey. Whats your question exactly?
[22:25] <wgrant> lifeless: They should not have .Edit on such objects.
[22:25] <lifeless> cody-somerville: why do you need an enabled/disable flag for publishing
[22:25] <wgrant> lifeless: Because they start disabled so they can be tweaked (dependencies, scores) before they start building.
[22:27] <lifeless> cody-somerville: alternatively, if we said 'PPAs are always enabled', what impact would that have on you.
[22:28] <cody-somerville> lifeless, We disable PPAs in a number of circumstances such as a project freeze or for commercial reasons.
[22:29] <thumper> lifeless: :(
[22:29] <thumper> updated all dependencies
[22:29] <thumper> and I still get that error on make schema
[22:29] <wgrant> thumper: Is postgresql-8.4-debversion installed?
[22:29] <wgrant> And postgres restarted?
[22:29] <lifeless> thumper: is postgresql-8.4-debversion installed ?
[22:30] <thumper> nope
[22:30] <wgrant> Your dependencies don't seem to be updated.
[22:31] <thumper> what is pB in debian statuses?
[22:31] <thumper> pinned?
[22:31] <thumper> if so, how do I change it?
[22:31] <thumper> pB  launchpad-developer-dependencies
[22:32] <cody-somerville> lifeless, We'd be sad if we could no longer disable PPAs but I suppose it wouldn't be the end of the world if you really need to remove that feature.
[22:33]  * thumper installs   launchpad-developer-dependencies 
[22:33] <lifeless> cody-somerville: I'm questioning the value of everything :)
[22:34] <lifeless> cody-somerville: particularly things that regularly lead to foot-gun events.
[22:36] <dobey> the worst part about foot-gun events, is when there's no bandage to stop the bleeding afterward :)
[22:38] <cody-somerville> Understood. Incidentally, we actually use the ability to disable PPAs to avoid our own foot-gun events. :-)
[22:39] <huwshimi> sinzui: Not sure what happened there, ack now though
[22:39] <huwshimi> *back
[22:40] <sinzui> huwshimi: I cannot hear you
[22:41] <wgrant> huwshimi: We can hear you.
[22:41] <huwshimi> ugh
[22:41] <lifeless> cody-somerville: ok, well we'd need to figure out how to preserve your safety without encouraging other users to break stuff :)
[22:41] <wgrant> lifeless: They want to create a derivative distro and use our queue functionality.
[22:41] <huwshimi> wgrant, sinzui: I'll reconnect
[22:42] <cody-somerville> lifeless, I thought that was accomplished by moving the option to the 'Administer PPA' page?
[22:42] <dobey> lifeless: pretty much every time i click "disable ppa" what i actually want is "eradicate this ppa from the face of the internets"
[22:43] <huwshimi> sinzui: No luck, if you guys are talking I can't hear it.
[22:43] <cody-somerville> dobey, When you click the edit PPA link to get where the disable ppa option is you don't notice the delete this PPA link underneath it? :P
[22:43] <sinzui> huwshimi: :(. DO you want to talk since we hear you?
[22:43] <huwshimi> sinzui: ok, tell me when :)
[22:43] <sinzui> go
[22:44] <dobey> cody-somerville: well, ok, so i do click delete ppa i guess
[22:44] <sinzui> I hear
[22:44] <dobey> cody-somerville: but it sticks around as "Abandoned $PPANAME"
[22:44] <dobey> which is kind of eh
[22:45] <cody-somerville> dobey, yea... not sure why it doesn't get hidden all together
[22:45] <sinzui> thanks huwshimi
[22:45] <wgrant> We don't want to delete the DB records completely at the moment.
[22:45] <huwshimi> sinzui: Weird. I got sound back just as you said goodbye
[22:45] <wgrant> But I want to rename the PPA out of the usual namespace, and hide it.
[22:46] <huwshimi> sinzui: Did you want to have a look at the work I've done so far on the unification of colours sometime?
[22:49] <sinzui> huwshimi: I would love to
[22:49] <sinzui> I will be free in about 2.5 h
[22:49] <huwshimi> sinzui: Ok great
[22:50] <wgrant> huwshimi: Is this the deletion of facet colours?
[22:50] <huwshimi> wgrant: yeah
[22:50] <wgrant> Excellent.
[22:50] <wgrant> First step to merging the domains.
[22:50] <lifeless> oh man
[22:57] <wallyworld_> lifeless: the latest buildbot failure (on the db-devel branch) - seems rather random to me. TestTwistedJobRunner does appear to have a genuine failure but as to why.... ?
[23:04] <lifeless> wgrant: gary may have some ideas about the security issue you're running into
[23:09] <poolie> hi huwshimi
[23:09] <huwshimi> poolie: Hey there
[23:11] <poolie> hi huwshimi
[23:52] <wgrant> We're not still RC, are we?