[00:00] <rick_h_> that would be a good use case for the icon font, being able to make the icon significant (edit) but make the color signify action like link vs popup
[00:00] <rick_h_> and then keep the color significance with the text to be link vs popup
[00:09] <mwhudson> hah
[00:09] <mwhudson> if you change the product that a bugtask is for, the other ajax controls break
[00:09] <mwhudson> is this a known bug?
[00:10] <mwhudson> i'll search but usually asking here is faster..
[00:10] <rick_h_> probably
[00:10] <rick_h_> but yea, don't have a number off the top of my head at all
[00:12] <mwhudson> https://bugs.launchpad.net/launchpad/+bug/919369
[00:12] <_mup_> Bug #919369: acting on a bug task which has been retargeted oopses <404> <bugs> <javascript> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/919369 >
[00:21] <wgrant> mwhudson: IIRC it's usually not a problem except on multitask bugs, since changing the current context causes a refresh
[00:22] <mwhudson> wgrant: this was a multitask bug, indeed
[00:22] <mwhudson> but hm, it was the task i was accessing the bug through that i changed
[00:22] <mwhudson> should that not still refresh?
[00:22] <wgrant> Hmm
[00:22] <wgrant> I'd expect that to work
[01:00] <StevenK> wgrant: Given your mail, I hope I can avoid a DB trigger.
[01:00] <StevenK> But I suspect I have to write some manual SQL to fix up the mistakes.
[01:20] <wgrant> StevenK: Correct.
[01:21] <wgrant> StevenK: The idea of this is to avoid a DB trigger.
[01:21] <cjwatson> The fix for bug 1000570 has been deployed, but it hasn't been marked Fix Released AFAICS.  Did somebody miss a bug closure pass after an NDT?
[01:21] <_mup_> Bug #1000570: "Packageset.score" is badly named <qa-untestable> <tech-debt> <trivial> <Launchpad itself:Fix Committed by cjwatson> < https://launchpad.net/bugs/1000570 >
[01:23] <wgrant> cjwatson: Ah, I left that one because it hasn't been renamed in the DB, and doing so is awkward. Not sure what you want to do.
[01:24] <cjwatson> Ah, well either way it shouldn't stay as Fix Committed.  I'm not planning on doing anything more to it for the time being, largely because I have no idea how to do so smoothly.
[01:24] <cjwatson> Maybe -> Triaged/Low/unassigned.
[01:24] <wgrant> That would be my suggestion.
[01:24] <cjwatson> I'll do that then.
[01:24] <wgrant> We haven't done a straight column rename since fastdowntime.
[01:25] <wgrant> But I'd probably do it as a two-day trigger
[01:25] <cjwatson> Oh, I can't set Triaged.
[01:25] <wgrant> Doing
[01:26] <cjwatson> ta
[01:28] <StevenK> Bah. Dealing with both private and information_type *and* the creation rules in IBranchNamespace.createBranch() is giving me a headache.
[01:28] <StevenK> (In LaunchpadObjectFactory.makeBranch())
[01:29] <wgrant> StevenK: Both default to None. At most one can be not None.
[01:32] <StevenK> Oh, bah, it doesn't help that I overwrite the values during the course of the method.
[01:34] <StevenK> Right, that should fix it.
[01:51] <StevenK> wgrant: Can you glance over https://code.launchpad.net/~stevenk/launchpad/branch-use-information_type/+merge/106109 again?
[01:53] <wgrant> StevenK: Looking
[02:11] <wgrant> StevenK: Can't the factory just use transitionToInformationType?
[02:11] <StevenK> wgrant: Nope
[02:11] <wgrant> It can
[02:12] <wgrant> Why do you say it can't?
[02:13] <wgrant> 120	+ if (self.stacked_on and self.stacked_on.information_type !=
[02:13] <wgrant> 121	+ InformationType.PUBLIC and information_type !=
[02:13] <wgrant> 122	+ self.stacked_on.information_type):
[02:13] <wgrant> 123	+ raise BranchCannotChangeInformationType()
[02:13] <wgrant> That's wrong
[02:13] <wgrant> The indentation is still criminal
[02:13] <wgrant> And it doesn't implement the rules we defined this morning
[02:13] <wgrant> s/indentation/line-breaking/
[02:14] <wgrant> 156	+ # If the branch we are stacking on is not public, and we are,
[02:14] <wgrant> 157	+ # set our information_type to the stacked on's.
[02:14] <wgrant> 158	+ if (self.stacked_on and self.stacked_on.information_type !=
[02:14] <wgrant> 159	+ InformationType.PUBLIC and self.information_type ==
[02:14] <wgrant> 160	+ InformationType.PUBLIC):
[02:15] <wgrant> Should use PUBLIC_INFORMATION_TYPES
[02:17] <StevenK> wgrant: In terms of lines 120-123, the information_type can change, as long as it remains in PRIVATE_INFORMATION_TYPES ?
[02:18] <wgrant> StevenK: I think so.
[02:18] <wgrant> The only constraint we have now is that a newly created branch probably shouldn't be public if it's stacked on something private.
[02:18] <wgrant> Implementing the same rule on stacking changes is roughly free, so we should do that too.
[02:19] <StevenK> wgrant: That's lines 156-160 in branchChanged
[02:19] <wgrant> Right, just explaining that that's the full ruleset :)
[02:22] <StevenK> wgrant: Are those your two issues?
[02:23] <wgrant> StevenK: Mostly. Will give it another deep look-over when they're fixed.
[02:23] <wgrant> lifeless: https://lpstats.canonical.com/graphs/PPR/20110123/20120524/ <- can I delete rosetta?
[02:23] <StevenK> wgrant: I have them fixed locally, I'm just wondering if I have tests for the stacked on behaviour in transitionToInformationType
[02:24] <lifeless> wgrant: I undesrstand the temptation
[02:49] <bigjools> the quality of commit messages these days is awful :(
[02:50] <wgrant> I did like the "use a private fork of bzr" this morning
[02:50] <bigjools> no kidding
[02:51]  * bigjools composes email to list
[03:24] <lifeless> bigjools: got time for a brief call about your favourite launchpad component ?
[03:51] <bigjools> lifeless: can do 5 mins now or more later
[03:52] <StevenK> wgrant: And again?
[03:53] <StevenK> Hmmm, that's an annoying bug.
[03:53] <lifeless> bigjools: now is good
[03:53] <lifeless> bigjools: skype? hangout ?
[03:54] <StevenK> If you leave the media menu open and go to lunch, you can interact with the menu, but as soon as you close it, the screen locks.
[03:55] <wgrant> StevenK: The factory is still insane.
[03:55] <wgrant> StevenK: And it might break lots of text by already having a change event
[03:55] <StevenK> wgrant: How so?
[03:55] <wgrant> tests
[03:55] <wgrant> not text
[03:55] <wgrant> StevenK: Why doesn't it use transitionToInforationType?
[03:56] <wgrant> With proper spelling.
[03:56] <StevenK> wgrant: Because transitionToInformationType has a bunch of rules about when privacy/information_type can change, and some branches want to be created that break those rules.
[03:57] <wgrant> StevenK: No they don't.
[03:58] <wgrant> StevenK: If they really need to (eg. for testing that it's possible to fix that situation), I'd set the information_type manually in the test.
[03:58] <wgrant> I don't think it's valuable to let the factory knowingly create invalid data.
[03:59] <StevenK> wgrant: http://pastebin.ubuntu.com/1002332/
[03:59] <wgrant> (because that means tests might unknowingly do it)
[04:00] <wgrant> StevenK: Ah, I see. So there's no privacy policy?
[04:00] <wgrant> I wouldn't expect there to be too much fallout from that, and it's one line to fix each test.
[04:02] <StevenK> wgrant: It is?
[04:03] <wgrant> Create an appropriate BranchVisibilityPolicy
[04:05] <StevenK> wgrant: And the project doesn't exist until inside makeBranch()
[04:07] <wgrant> StevenK: Ah, that's less than convenient.
[04:11] <StevenK> wgrant: So I need to create a project, a team and a BranchVisibilityPolicy and then I can create a private branch just so makeBranch() can use transitionToInformationType?
[04:21] <wgrant> StevenK: Technically, yes, you should.
[04:21] <wgrant> StevenK: But perhaps that's not ideal here yet.
[04:23] <StevenK> wgrant: There are 246 occurances of private=True in the tree -- some of those are going to be for makeArchive(), but ... ouch?
[04:23] <StevenK> lib/lp/soyuz/tests/test_binarypackagebuildbehavior.py:            UPDATE archive SET private=True,buildd_secret='foo'
[04:23]  * StevenK facepalms
[04:25] <wallyworld_> wgrant: is there a trigger which updates btf.access_policies and btf.access_grants when a bug info type or bugtask target changes? if there is, i have missed finding it
[04:26] <wgrant>     z_bug_maintain_bugtaskflat_trigger AFTER UPDATE ON bug FOR EACH ROW EXECUTE PROCEDURE bug_maintain_bugtaskflat_trig()
[04:26] <wgrant>     z_bugtask_maintain_bugtaskflat_trigger AFTER INSERT OR DELETE OR UPDATE ON bugtask FOR EACH ROW EXECUTE PROCEDURE bugtask_maintain_bugtaskflat_trig()
[04:26] <wgrant> wallyworld_: ^^
[04:26] <wgrant> (z because they have to happen after the FTI updates etc :/)
[04:26] <StevenK> wgrant: So, shall I leave the information_type = call in the factory?
[04:26] <wallyworld_> wgrant: ok, thanks. something else is going wrong for me then.
[04:27] <wgrant> StevenK: I suppose.
[04:27] <StevenK> wgrant: Do you have any other issues with the MP?
[04:44] <stub> Well thats amusing. Package builds fine under i386, not amd64
[04:44] <wgrant> stub: Possibly because i386 builds arch-indep, amd64 doesn't.
[04:44] <wgrant> If it's not an obvious arch difference.
[04:45] <stub> https://launchpadlibrarian.net/105848284/buildlog_ubuntu-lucid-amd64.postgresql-9.1_9.1.3-2%2Blp4_FAILEDTOBUILD.txt.gz ?
[04:45] <wgrant> Yeah
[04:45] <wgrant> arch-indep difference
[04:45] <wgrant> i386 will be building doc packages, amd64 won't
[04:45] <wgrant> But both copy them into debian/tmp
[04:46] <wgrant> StevenK: Your linebreaking is still a criminal offence.
[04:46] <wgrant> 121	+ if (self.stacked_on and self.stacked_on.information_type in
[04:46] <wgrant> 122	+ PRIVATE_INFORMATION_TYPES and information_type in
[04:46] <wgrant> 123	+ PUBLIC_INFORMATION_TYPES):
[04:46] <StevenK> wgrant: When can I expect you over to arrest me?
[04:47] <StevenK> wgrant: What would you prefer, nested ifs? :-)
[04:51] <wgrant> StevenK: Replied
[04:55] <StevenK> wgrant: http://pastebin.ubuntu.com/1002355/
[04:56] <wgrant> StevenK: I accept your plea bargain.
[04:56] <StevenK> Haha
[04:56] <StevenK> wgrant: And the linebreak for name='branch_%s' % x, private=x > 2) is still required.
[04:56] <wgrant> Really? it didn't look that long.
[04:57] <wgrant> How far over is it?
[04:58] <StevenK> wgrant: 81
[04:58] <wgrant> StevenK: s/branch_/b/g
[04:58] <wgrant> Done
[04:58] <StevenK> branch = self.factory.makeBranch(name='branch_' + x, private=x>2)
[04:59] <wgrant> I mean, naming a branch "branch_foo" doesn't really make sense anyway.
[05:01] <StevenK> The branches do not require names, we don't test for them.
[05:01] <wgrant> Even better
[05:01] <wgrant> Remove stupid piece of test, save a line.
[05:01] <wgrant> Everybody wins.
[05:01] <wgrant> One less crime.
[05:01] <StevenK> wgrant: -4/+2
[05:06] <StevenK> steven@undermined:~/launchpad/lp-branches/branch-use-information_type% bzr log | head -n 7 | tail -n 1
[05:06] <StevenK>   Drop some useless names from a test, and fix my crimes against humanity.
[05:06] <StevenK> wgrant: ^
[05:06] <wgrant> They were merely capital offences, not crimes against humanity.
[05:08] <lifeless> which capital?
[05:08] <StevenK> lifeless: So, looks like I need some manual SQL. :-(
[05:09] <wgrant> LATER
[05:09] <wgrant> Not until this is deployed everywhere
[05:09] <StevenK> But won't that leak some branches?
[05:10] <wgrant> Don't you still respect transitively_private?
[05:10] <StevenK> Only information_type in the New World Order.
[05:10] <wgrant> Oh
[05:10] <wgrant> Indeed you don't
[05:10] <StevenK> In fact, I don't think Branch._private is even needed
[05:11] <wgrant> There's only like a dozen branches that are affected, right?
[05:11] <StevenK> 29
[05:12] <wgrant> Any created recently?
[05:13] <wgrant> Normally you'd do a 3-stage migration here, but they may be rare enough that you can get away with 2-stage with manual SQL.
[05:21] <StevenK> wgrant: I'm going to kill Branch._private, it isn't needed because the two columns are named differently.
[05:26] <wgrant> StevenK: Sounds reasonable.
[05:33]  * wgrant fixes cjwatson's test failurse
[05:49] <lifeless> 9.1 right ?
[05:49] <lifeless>      559 /  222  Distribution:+ppas
[05:49] <lifeless>      348 /   37  Builder:+history
[05:50] <wgrant> lifeless: Yes
[05:53] <StevenK> Builder:+history has a bug filed against it, at least.
[05:54] <wgrant> I believe Distribution:+ppas is similar misbehaviour on a different query, but I haven't looked in depth.
[05:55] <wgrant> Both rarely used pages, anyway.
[05:55] <wgrant> Particularly since Distribution:+ppas timed out half the time anyway
[06:10] <wallyworld_> wgrant: i have a question i'd like to ask if you have a moment. a bit of code which calls bug.subscribe() appears to mess with bug visibility checks. i have a bit of code in https://pastebin.canonical.com/66554/ to try and illustrate the issue
[06:11] <wgrant> wallyworld_: Looking
[06:11] <wallyworld_> thanks. hope it makes sense
[06:21] <wgrant> wallyworld_: What's policy_team_grantee?
[06:21] <wallyworld_> wgrant: typo, sorry
[06:21] <wallyworld_> should be policy_gantee
[06:21] <wallyworld_> argh, you know what i mean
[06:22] <StevenK> Haha
[06:22] <wallyworld_> can't type
[06:22] <wallyworld_> i cut and pasted a bit of code from a test and stripped out bits
[06:22] <StevenK> wallyworld_ is obviously so excited by the prospect of a NSW win tonight that his hands are shaking.
[06:22] <wallyworld_> StevenK: you can go and f%^@@!%^%^@ yourself
[06:22] <wallyworld_> blasphemy
[06:23]  * wallyworld_ just hope to make it home from soccer training on time not to miss any
[06:23] <wgrant> wallyworld_: You haven't disabled the triggers?
[06:23] <wallyworld_> wgrant: no. i had. but there were other issues
[06:23] <StevenK> wallyworld_: We have this thing, called a PVR. It can pause live TV.
[06:23] <wgrant> wallyworld_: Toggling the information_type on line 40 without disabling the triggers will cause the grant to be recreated due to the subscription.
[06:23] <wallyworld_> StevenK: but others will be watching
[06:24] <bigjools> it's rugby *league*, who TF watches that crap
[06:24] <wgrant> What's the difference?
[06:24] <StevenK> Bwaha
[06:24] <wallyworld_> wgrant: ah, bollocks. thanks for spotting that. i'll disable the triggers again and see if i can reproduce the issue that caused me to disable them
[06:24] <StevenK> bigjools: wallyworld_ will be *glued* to the TV.
[06:25] <wallyworld_> bigjools: it's state of origin. better than any super 16 or 6 nations stuff
[06:25] <bigjools> you can tell yourself that, yeah :)
[06:25] <StevenK> Who cares? Both rugby league and union are played by and watched by bogans.
[06:25] <wallyworld_> bigjools: it's a lot tougher. i mean what sort of rugger pussy disallows a shoulder charge
[06:26] <bigjools> wallyworld_: league is the one where after they get tackled they hump the ball for a bit right?
[06:26] <wallyworld_> StevenK: i don't consider myself a bogan
[06:26] <wgrant> wallyworld_: The thing to remember about the triggers is that they were designed to always keep the mirror in a sane state, regardless of whether it was sane to start with. Every time they're fired, they force any AAGs and APAs to match the legacy disclosure data.
[06:26] <wallyworld_> bigjools: only in your dreams
[06:26] <wgrant> wallyworld_: I couldn't just apply a delta, since the table started empty.
[06:27] <wallyworld_> wgrant: ok. i'll try and get this particular test case to work with the legacy triggers disabled from the start. the sharing jobs in question are not really meant to be run with the triggers on
[06:28] <wallyworld_> i ran into issues but can't recall what they are right now
[06:29] <wgrant> I'm happy to help if you hit trouble.
[06:29] <wallyworld_> no problem, thanks
[06:30] <stub> Is there some magic to dput to get packages build for multiple releases since I can't use the web UI to rebuild packages for a different release in the same PPA?
[06:30] <wallyworld_> wgrant: i'll send out an email maybe tonight to summarise where we are at with being able to turn off the legacy triggers. i think we will be close after i get this branch sorted. we'll have code to grant access on subscribe and also unsubscribe if access becomes verboten
[06:31] <bigjools> stub: you need >1 upload
[06:31] <bigjools> unless you want to copy the same build
[06:31] <stub> Recipes let me do it I guess.
[06:31] <bigjools> yep
[06:32] <wgrant> wallyworld_: Marvellous.
[06:33] <wgrant> stub: Right, recipes are handy for that. Or you can often build in lucid and copy up, as long as a soname bump hasn't happened.
[06:33] <wallyworld_> wgrant: main outstanding bit will be some form of garbo / celerybeats / cron job to check for inconsistencies if we feel that's necessary
[06:45] <wallyworld_> wgrant: one issue - without the legacy triggers, self.factory.makeAccessPolicyGrant does not allow the bug to be visible
[06:46] <wgrant> wallyworld_: You probably want to disable bug_mirror_legacy_access_t, bugtask_mirror_legacy_access_t, bugsubscription_mirror_legacy_access_t
[06:47] <wgrant> wallyworld_: You still want things mirrored to bugtaskflat, you just don't want the legacy sharing schema mirrored to the new one.
[06:47] <wallyworld_> wgrant: those ones are the only 3 i am disabling
[06:47] <wallyworld_> using a new fixture i wrote
[06:48] <wgrant> wallyworld_: Are you creating the APA manually?
[06:48] <wgrant> Disabling those triggers will prevent APAs from happening automatically
[06:48] <wallyworld_> no
[06:48] <wgrant> So the APG will not be effective for the bug.
[06:48] <wgrant> Because it's not linked to any policies.
[06:48] <wallyworld_> wgrant: i would have hoped that APA will be done by triggers still
[06:49] <wgrant> wallyworld_: It's all done by the one trigger right now, unfortunately.
[06:49] <wallyworld_> :-( so we need to do a new trigger
[06:49] <wallyworld_> and strip out the APA stuff
[06:49] <wallyworld_> from the legacy trggers
[06:49] <wgrant> AAG stuff
[06:49] <wgrant> Well
[06:49] <wgrant> Split them up
[06:50] <wgrant> Or we can find all the stuff that creates tasks, all the stuff that changes targets, and all the stuff that changes information types
[06:50] <wallyworld_> ok, i'll do it bt hand for now and include an xxx
[06:50] <wgrant> And make them create the APAs in the application.
[06:50] <wgrant> That's the ideal situation, and it might be doable now
[06:50] <wgrant> Since those things are reasonably well factored nowadays.
[06:50] <wallyworld_> hmm. ok. this branch is already waaay to big. might do it in the test for now and do a new branch to do it in the model
[06:50] <wgrant> Target setting is guarded, task creation is mostly factored into a single method, and information type transitioning is done by a single method.
[06:51] <wgrant> It'll certainly need to be a separate branch or three.
[06:51]  * wallyworld_ off to soccer and then straight home to watch the might maroons thrash nsw
[06:52] <wgrant> Heh
[06:52] <wgrant> Is that where bigjools heard the odd pronunciation?
[06:52] <wallyworld_> odd? it's pronounced "marown"
[06:52] <wgrant> Odd to him.
[06:53] <bigjools> you're all wrong
[07:41] <adeuring> good mmorning
[07:47] <cjwatson> wgrant: Doh.  Thanks
[07:47] <cjwatson> hate doctests
[07:52] <wgrant> That's the point :)
[08:01] <cjwatson> Confused at how that passed EC2.
[08:17] <cjwatson> Could somebody set https://code.launchpad.net/~cjwatson/launchpad/remove-distro-parts/+merge/106920 to Status: Approved (since it's had an Approve review) so I can land it?
[08:20] <czajkowski> cjwatson: done
[08:21] <cjwatson> Thanks
[11:07] <wallyworld_> wgrant: around?
[11:08] <wgrant> wallyworld_: Sure
[11:09] <wallyworld_> wgrant: 1/2 watching footy so may no be seeing it, but see https://pastebin.canonical.com/66571/ - #4 is not as i expect
[11:09] <wallyworld_> wgrant: triggers disabled
[11:10] <wgrant> wallyworld_: Recall that the triggers are disabled, so changing bug.information_type isn't going to change the APA
[11:10] <wallyworld_> wgrant: only the legacy triggers are disabked
[11:10] <wgrant> Right, and they maintain APA
[11:10] <wallyworld_> wgrant:  i thought there were separate trigers for info tpy changes
[11:10] <wgrant> That's why you had to create it manually
[11:11] <wgrant> No. Bug* -> Access* is all the legacy triggers
[11:11] <wallyworld_> hmmm.
[11:11]  * wallyworld_ sad
[11:11] <wallyworld_> i think i will need to create a db-devel branch to fix that
[11:11] <wgrant> I can reimplement all that in the app tomorrow if you want
[11:11] <wallyworld_> before i land this branch
[11:11] <wgrant> The APA stuff
[11:11] <wgrant> Why do you need a db-devel branch?
[11:11] <wallyworld_> yes, we really do need that now
[11:12] <wallyworld_> db-devel  to add the triggers
[11:12] <wgrant> We can't remove the triggers until after the appserver code is deployed.
[11:12] <wallyworld_> can't we split out the APA stuff
[11:12] <wallyworld_> still have the legacy triggers but have the APA stuff on its own
[11:12] <wallyworld_> since we will need it even when legacy triggers are gone
[11:13] <wallyworld_> oh, you want to do it in the app
[11:13] <wgrant> Yeah
[11:13] <wgrant> It's become a little less of a free-for-all in the last few months
[11:13] <wgrant> So it's easy enough to do there now
[11:13] <wallyworld_> whatever works :-)
[11:14] <wallyworld_> i really don't want to "pollute" the tests with the APA stuff
[11:14] <wgrant> Since we're going to be managing grants from the app, we might as well manage the APAs too
[11:14] <wallyworld_> yeah. the calling code should be easy to write. at the moment it isn't :-)
[11:14] <wallyworld_> well, not intuitive or transparent perhaps
[11:15] <wgrant> The task creation code is all now nicely centralised, same with information_type, and I refactored target setting, so there's basically just 3 methods that need hacking
[11:15] <wallyworld_> wgrant: we would need to use the legacy triggers removed feature flag
[11:15] <wallyworld_> so the triggers and app code don't double up
[11:16] <wallyworld_> oh, i haven't landed that flag yet
[11:16] <wallyworld_> sigh
[11:16] <wgrant> wallyworld_: They can't double up.
[11:16] <wgrant> They're idempotent.
[11:17] <wallyworld_> wgrant: i've been getting pk errors if i don't diable the triggers and have app code to do the same thing
[11:18] <wgrant> wallyworld_: The triggers won't recreate stuff that already exists.
[11:18] <wgrant> So the appserver code will just check what's there, and fix it if it's wrong.
[11:18] <wgrant> Same as the triggers.
[11:18] <wallyworld_> wgrant: yes but they fire first
[11:18] <wallyworld_> and my app code didn;t check, just assumed the stuff needed creating
[11:19] <wallyworld_> anyways, footy is back on :-)
[11:19] <wgrant> Right. My centralised app code will render that no longer necessary, and will do the check.
[11:19] <wgrant> Heh, k
[11:19] <wgrant> Thanks for sorting all this stuff out!
[11:20] <wallyworld_> np. i'll code my branch and it tests will fail and i'll merge devel when your stuff is in and tests will work
[11:20] <wgrant> Yeah
[11:20] <wgrant> I'll also grep for any makeAccessPolicyArtifact calls that are lying around
[11:20] <wgrant> And delete them.
[11:21] <wallyworld_> awesome
[11:21] <wallyworld_> it's all quite verbose atm
[11:21] <wgrant> Yeah
[11:21] <wgrant> The transition phase wasn't meant to last quite as long as it has :)
[11:21] <wgrant> Still, its end is nigh
[11:21] <wallyworld_> yep, can't wait
[11:22] <wallyworld_> and we nweed to do branches
[11:23] <wgrant> Branches are easy :)
[11:23] <wgrant> As of 12 hours ago...
[11:23] <wallyworld_> i have a few XXXs in tests etc
[11:23] <wallyworld_> waiting for it to be sorted
[11:23] <wgrant> Great
[11:24] <wallyworld_> so we need the same app code as we just discussd for bugs
[11:24] <wgrant> Branch code will be entirely app. In fact, we'll lost the transitively_private trigger shortly.
[11:24] <wgrant> But yeah
[11:25] <wgrant> StevenK is basically cleaning up the points we'll need to hook into
[11:25] <wallyworld_> cool
[12:34] <jelmer> hmm, quantal and lxc don't seem to be an ideal combination here at the moment
[12:36] <wgrant> jelmer: Oh?
[12:36] <wgrant> What's breaking?
[12:37] <jelmer> kernel panic :)
[12:37] <wgrant> Oh
[12:37] <wgrant> That's quite impressive.
[12:37] <wgrant> 3.4?
[12:37] <jelmer> yep
[12:37] <jelmer> this is the second time it's happened to me, next time I'll take a photo
[12:38] <mgz> ...you mean you don't have a serial cable hooked up?
[12:38] <mgz> I'm disappointed in you jelmer.
[12:39] <jelmer> hehe
[12:40] <wgrant> mgz: Did you get your LP instance working?
[12:41] <mgz> wgrant: yup, and forwarded via socks over chinstrap to the browser here
[12:41] <mgz> one oddness was the new bugs page wasn't in, so maybe I didn't have it setup the same way the current live version is?
[12:42] <mgz> are there more things I managed to ignore on the wiki about setting flags or similar?
[12:42] <jelmer> mgz: you probably have to be in one of the special groups for that?
[12:42] <mgz> I thought new bugs were on for everyone now?
[12:43] <StevenK> I thought it was still behind a feature flag
[12:43] <mgz> otherwise, how do you make the stub test data gain the feature flags you care about?
[12:43] <StevenK> mgz: You add it? http://launchpad.dev/+feature-rules
[12:43] <mgz> StevenK: thanks :)
[12:44] <wgrant> It's still behind a feature flag, despite being enabled everywhere for nearly 6 months
[12:44] <wgrant> The old code was never removed.
[12:44] <mgz> are there other features that are enabled live but still not on by default for the test setup?
[12:44] <StevenK> mgz: Sounds like a good learning exercise. ^ :-)
[12:44] <mgz> or is the bug listing stuff unusual...
[12:45] <StevenK> mgz: Some feature flags are supposed to be short lived
[12:45] <StevenK> I'm hoping that disclosure.show_information_type_in_ui gets ripped out next week, for instance.
[12:46] <mgz> is there somewhere that tells me what launchpad beta testers have turned on?
[12:46] <StevenK> You can have a look at the feature rules on prod
[12:48] <mgz> I can, or I can tell some poor l-osa to?
[12:56] <deryck> Morning, all.
[12:56] <StevenK> mgz: You can see them, you just can't edit.
[13:00] <mgz> StevenK: is there some documentation you can point me at? things involving 'prod' I'm nervous prodding without knowing what I'm doing.
[13:00] <mgz> am not even aware of which boxes are involved with the live launchpad setup for example.
[13:07] <StevenK> mgz: You can't change anything there, so there is no harm in looking.
[13:07] <StevenK> mgz: There is some doco around of the LP producution setup including a diagram. I can't recall where off the top of my head
[13:11] <cjwatson> mgz: are you looking for the URL?  https://launchpad.net/+feature-rules
[13:12] <mgz> ah, doh, I assumed that'd be a dev setup only thing
[13:13] <mgz> and the changelog is very informative.
[13:13] <cjwatson> It's restricted to ~admins and ~registry
[13:14] <cjwatson> Mortals like myself just get 403 :)
[13:14] <mgz> :)
[13:14] <czajkowski> cjwatson: ah thought you were a demi god myself
[13:14] <mgz> just in all other regards czajkowski :)
[13:14] <cjwatson> Only for stuff under /ubuntu :)
[13:15] <czajkowski> cjwatson: ahhh :)
[13:19] <stub> I can't find my recipe
[13:20] <stub> ahh... wrong branch
[13:35] <jam> mgz: how would you travel from the UK to NL, I'm trying to decide if Eindhoven or Utrecht is a better meeting point. Ein has a direct Stansted <=> Ein flight, but Utrecht is a more central train station.
[13:39] <mgz> jam: norwich 'international' airport has a hop to schiphol
[13:40] <mgz> stanstead isn't too hard to get to either
[13:40] <mgz> there used to be a ferry from these parts too, but I think no longer
[13:41] <jam> mgz: could you do a quick check on pricing, including train/taxi/whatever for the two routes?
[13:41] <mgz> sure
[13:41] <cjwatson> Stansted is way easier to get to than Norwich from just about anywhere except Norwich
[13:42] <cjwatson> Though I know the latter's probably more important to mgz :)
[13:42] <jam> cjwatson: yeah
[13:43] <jam> I was surprised how many people in directory.canonical.com are listed as in Norwich, though. (4)
[13:44] <mgz> and amigadave is also norfolk
[13:44] <mgz> we're doing pretty purple round here.
[13:46] <mgz> so, NOR-AMS return is £120-150 range, then need train on the dutch side which you might have a better idea on
[13:47] <mgz> heh, first web search hit is the dutch train operator, second in bbc news article about crash in april
[13:48] <mgz> looks like about 8 euros one way to utrecht from schiphol, so not expensive
[13:53] <mgz> from stansted I'm failing to find flights to eindhoven at all, but to schiphol it's £110 upwards
[13:54] <jelmer> mgz: aren't you near Harwich? How long does the boat take?
[13:54] <mgz> to get the train to eindhoven goes through utrecht, costs about another 10 euros
[13:55] <mgz> jelmer: however long it takes me to hide in a container ship without being noticed? :)
[13:56] <jelmer> mgz: hehe
[13:56] <jelmer> mgz: I thought Stena Line operated from Harwich to Hoek van Holland?
[13:57] <mgz> they do seem to, takes 6 hours, failing to find prices
[13:57] <jelmer> ouch, 6 hours is quite long :-/
[13:58] <mgz> not if you're sleeping :)
[14:00] <mgz> £36 return, plus train at...
[14:03] <mgz> less than £27 this end, plus...
[14:05] <mgz> about 14 euros one way going via rotterdam to utrecht
[14:06] <mgz> I'll send you an email later jam.
[14:06] <cjwatson> webops: I have some QA to do on https://code.launchpad.net/~cjwatson/launchpad/archive-build-score-api/+merge/106804, and need admin help.  Could somebody in ~admins run http://paste.ubuntu.com/1003094/ at an 'lp-shell qastaging devel' prompt and tell me what it says?
[14:07] <jam> mgz: http://www.ryanair.com/en
[14:07] <gnuoy> cjwatson, I'll take a look
[14:07] <jam> mgz: ams => ein is about 40 round trip
[14:08] <cjwatson> Hopefully it should give no errors and the last line should return 100.
[14:08] <jam> (40 Euros, not GBP)
[14:09] <jam> mgz: note that right now, I'm looking at the week of June 25th, for availability.
[14:09] <wallyworld_> abentley: hi. celery question. the wiki page says to add jobs to run_missing_ready(). Should that method use the feature flag to get the celery jobs to pass to find_missing_ready()? It's current just hard coded to look for branch scan jobs only.
[14:09] <jam> mgz: also note that ryanair tends to add a lot after the initial decision.
[14:10] <jam> like it is only 10.99 GBP for the return EIN => STE, but that doesn't include checking a bag, etc.
[14:10] <abentley> wallyworld_: It can't use the feature flag to get the jobs, because that does not contain enough information.
[14:10] <jam> and if you leave at 9am, vs 5pm, etc.
[14:10] <wallyworld_> abentley: the feature flag contains the job class names. is that not enough?
[14:11] <abentley> wallyworld_: Also, there's not a one-to-one relationship between job sources and job types.
[14:11] <czajkowski> jam: mgz jelmer http://www.speedcommunications.com/blogs/speed/2012/05/22/ryanair-taking-the-biscuit/
[14:11] <jam> mgz: and I swear they charge you a lot more for checking a bag. I thought it was ~20 Euro for round trip, but I'm seeing 50GBP for the first bag.
[14:11] <abentley> wallyworld_: Indeed, that is not enough.
[14:12] <cjwatson> jam: I just refuse to fly RyanAir, saves aggravation all round
[14:13] <jam> cjwatson: I've had quite good success with them, but mostly because they fly out of my city
[14:13] <jam> not a lot flies to Ein, and otherwise I have a 2hr train to AMS
[14:13] <gnuoy> cjwatson, I got this: http://paste.ubuntu.com/1003098/
[14:14] <wallyworld_> abentley: ok. so we should just create a list of jobs in the run_missing_ready() method and iterate over those? we really should set up a register method or something that jobs use to register themselves and it's all taken are of from there
[14:14] <abentley> wallyworld_: Maybe.  It didn't seem like there were any great answers, so I did the simplest thing.
[14:15] <cjwatson> gnuoy: That looks like a stale WADL cache, I think.  Could you run "find ~/.launchpadlib -name '*qastaging*devel*wadl*' | xargs rm" and try again?
[14:15] <wallyworld_> abentley: sure :-) i'm jsut mking sure i understand what i need to do for my new jobs
[14:16] <abentley> wallyworld_: So ideally, the registration is done in the same module as run_missing_ready.  If it's done in a Job-specific module, then there's the risk that the module won't be loaded.
[14:17] <abentley> wallyworld_: So a list in run_missing_ready seems as good a place as any to "register" the job sources.
[14:17] <wallyworld_> abentley: yes, same module. and this allows for any other required processing in addition to run_missing_ready to be hooked in
[14:17] <abentley> wallyworld_: YAGNI
[14:18] <gnuoy> cjwatson, still getting the same error: http://paste.ubuntu.com/1003102/
[14:18] <wallyworld_> abentley: are we expecting all celery jobs need to be handled by run_missing_ready()
[14:18] <cjwatson> gnuoy: Urr.
[14:19] <cjwatson> Any launchpadlib/lazr.restfulclient/wadllib experts want to help me out understanding the above?
[14:19] <abentley> wallyworld_: All jobs that run via celery should have sources handled by run_missing_ready.
[14:20] <wallyworld_> abentley: so in that case i think registration should be automatic so it's not missed out
[14:21] <wallyworld_> via whatever mechanism makes sense
[14:21] <wallyworld_> otherwise it's a pita to have to define a new job and remember to add it to a list somewhere else
[14:22] <wallyworld_> that would be quite fragile
[14:22] <abentley> wallyworld_: I don't think registration can be automatic, because it needs coordination between two modules, the one where the class is defined and the one where the registration needs to happen.
[14:23] <wallyworld_> why can't it be done? because thre are 2 modules inolved?
[14:23] <wallyworld_> i'm not sure i see the problem
[14:23] <abentley> wallyworld_: Yes, and because the module where the class is defined may not be loaded.
[14:24] <abentley> wallyworld_: So you can't make declaring the class simply have a side effect of registering the class.
[14:24] <wallyworld_> it would be the class which registeres itself
[14:24] <abentley> wallyworld_: See above.
[14:24] <wallyworld_> enum types seem to do that
[14:25] <abentley> wallyworld_: Code that is not executed cannot have side effects.  A module that is not loaded cannot register a class.
[14:26] <wallyworld_> right, i see what you are saying. perhaps there can be a config file where the known jobs are listed
[14:27] <wallyworld_> i guess that's what the run_missing_ready is
[14:27] <wallyworld_> or could be
[14:27] <abentley> wallyworld_: Right.
[14:27] <wallyworld_> so it seems there's a bunch of celery jobs missing from that list then
[14:28] <cjwatson> gnuoy: Perhaps I could have a look at whatever file(s) are shown by "find ~/.launchpadlib -name '*qastaging*devel*wadl*'"?
[14:28] <abentley> wallyworld_: Sure, but we also knew that we were only planning on doing BranchScanJobs for now, so I didn't add the others, because it would be a wasted of CPU.
[14:29] <wallyworld_> i thought a number of other jobs had been ported to celery?
[14:29] <abentley> wallyworld_: Right, but we're off maintenance, so we had to tie off work here.  We settled on doing BranchScanJobs as our spike.
[14:30] <wallyworld_> ok. so those other jobs will just run as normal not with celery?
[14:30] <gnuoy> cjwatson, I tried moving  ~/.launchpadlib out of the way and rerunning, seemed to get the same error. Let me get a colleague to give it a go as well to confirm its not just me
[14:30] <abentley> wallyworld_: Right.
[14:30] <wallyworld_> abentley: ok. so i have 2 new jobs written only for celery. so i'll add those to the list
[14:31] <abentley> wallyworld_: Cool.  If you're in the area, it would make sense to change find_missing_ready to take a list of job sources, so that we only have to run it once.
[14:32] <cjwatson> gnuoy: Weird.  I was hoping to look at the wadl to see if Archive.relative_build_score is there at all.
[14:32] <abentley> wallyworld_: (which means we only have to query the queue once.)
[14:32] <gnuoy> cjwatson, sure, let me get it
[14:32] <wallyworld_> abentley: yes. i'll do a branch for that and get you to review it. can i land the branches with the jobs etc before i add the jobs to run_missing_ready?
[14:33] <abentley> wallyworld_: Certainly.
[14:33] <wallyworld_> abentley: cool. will do that. i have a 8 branch pipe i need to get landed before i go too much further
[14:34] <wallyworld_> abentley: thanks for the clarifications on this stuff
[14:34] <gnuoy> cjwatson, chinstrap.canonical.com:/home/liam/api.qastaging.launchpad.net,devel,-application,vnd.sun.wadl+xml,66834a8cfcc85749a969518f3c248856
[14:34] <abentley> wallyworld_: np.
[14:36] <cjwatson> gnuoy: Weird, Archive.relative_build_score does appear to be there.
[14:36] <cjwatson> Maybe I should try myself on DF or something
[14:47] <cjwatson> gnuoy: Oh, maybe this is bug 662740
[14:47] <_mup_> Bug #662740: Setting an attribute on a shim object without first reading an attribute causes a crash <lazr.restfulclient:Triaged> < https://launchpad.net/bugs/662740 >
[14:48] <cjwatson> gnuoy: Could you try just 'archive.relative_build_score' (i.e. read the attribute) before trying to set it?
[14:48] <gnuoy> cjwatson, sure
[14:50] <gnuoy> cjwatson, I seem to be able to read it fine: >>> archive.relative_build_score
[14:50] <gnuoy> 0
[14:50] <cjwatson> gnuoy: OK, then try the rest immediately after that
[14:50] <cjwatson> Starting from 'archive.relative_build_score = 100'
[14:51] <gnuoy> cjwatson, that works: http://paste.ubuntu.com/1003122/
[14:53] <cjwatson> gnuoy: Great, that's step one then (that lazr.restfulclient bug is unrelated to my QA).  Would it be possible to add me briefly to commercial-admins so that I can do the final step?
[14:53] <cjwatson> On qas, obviously
[14:53] <gnuoy> cjwatson, sure
[14:54] <gnuoy> cjwatson, done
[14:57] <cjwatson> gnuoy: Great, thanks, that passed (i.e. commercial-admins can still write that attribute) - please remove me from that team again
[15:05] <sinzui> jcsackett, This is the bug about the privacy banner. I think the issue is really about the switch to radio buttons: https://bugs.launchpad.net/launchpad/+bug/1003482
[15:05] <_mup_> Bug #1003482: privacy banner is not shown by default when reporting a bug <disclosure> <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1003482 >
[15:06] <jcsackett> sinzui: dig. i think i can whack that in line with the other banner stuff i'm doing.
[15:08] <sinzui> jcsackett, ian and wallyworld_ believe the radio buttons are inconsistent. We are discussing changing the widget. Your fix is appreciated, we want to be sure what ever widget we choose, the banner appears
[15:08] <jcsackett> sinzui: yeah, there's no reason the banner's appearance on a private-by-default project should be dependent on the info_type selector.
[15:08] <jcsackett> or rather, on the *type* of selector.
[15:09] <jam> have a good evening everyone, I'm EOD
[15:12] <cjwatson> gnuoy: Oh, of course, I can leave a team myself.  Done
[15:13] <gnuoy> cjwatson, thanks
[15:35] <danilos> frankban, hi, can you please take a look at https://code.launchpad.net/~danilo/launchpad/bug-1000787/+merge/107041
[15:42] <frankban> sure danilos, give me a minute and I'm on it.
[16:01] <danilos> frankban, cool, thanks
[16:12] <jcsackett> rick_h_: is there way when using the combo loader and jsbuild_watch to not have minified js?
[16:12] <jcsackett> it makes hunting a bug a bit harder.
[16:13] <rick_h_> jcsackett: yea, add a filter='raw' to the config
[16:13] <rick_h_> otp atm, but can get you a paste in a sec
[16:13] <jcsackett> rick_h_: ok.
[16:43] <danilos> frankban, rvba: hi, can you perhaps get the branch landed for me if you are fine with the latest changes as per your review?
[16:43] <rvba> Hey danilos. Can you take care of it frankban?
[16:52] <danilos> mrevell, hi, any news from ubuntu people on acceptance/headline and removal of the migration script?
[16:53] <frankban> danilos: I will get your branch landed
[16:53] <danilos> frankban, cool, thanks again
[16:53] <frankban> you are welcome
[17:51] <sinzui> czajkowski, do you have the mad skillz to make a video appear in a Wordpress post?
[17:53] <czajkowski> um..........
[17:53] <czajkowski> sure pp it in and I'll have a look in a wee bit if you like
[17:53] <czajkowski> just heading out to grab some food
[17:54] <czajkowski> *pop
[18:38] <czajkowski> sinzui: hmm i dont have access to the YT account to upload the vide
[18:38] <czajkowski> and clicking on it in chrome makes it open in another tab and not play :/
[18:38] <sinzui> yes. I think chromium want webm
[18:39]  * sinzui does not want to render the video again
[18:39] <sinzui> czajkowski, We can wait for mrevell
[18:39] <czajkowski> sinzui: see -ops found the link on wiki :)
[18:39] <czajkowski> I think..
[22:28] <gary_poster> StevenK, hey.  Is there a concrete reason why you think the new bug you reported has to do with us?  Ooh!  I have an idea.  The only way I can think of that we might be responsible is the new zope.testing.  I already reverted it locally because it is broken for us.  Maybe it is broken in whatever way you need too.
[22:31] <StevenK> gary_poster: Yeah, you seemed like the most likely team implicated. :-)
[22:32] <gary_poster> StevenK, fair enough.  I'm already well past my EoD and dealing with other gigantic new baffling issues of our own, so help with this would be appreciated.  I suggest reverting r15283.  I'm 80% sure that's the cause, and I know it's broken in other ways
[22:33] <StevenK> gary_poster: r15283 has been reverted in r15293.
[22:33] <gary_poster> StevenK, and so would that correlate with your failure?
[22:33] <StevenK> gary_poster: But thank you for looking at it. :-)
[22:34] <gary_poster> 15254
[22:34] <StevenK> Oh, sorry
[22:34] <lifeless> gary_poster: hi; I've commented on the LEP itself
[22:34] <lifeless> gary_poster: rather than on the thread
[22:34] <StevenK> I reverted my branch
[22:34] <StevenK> [testfix][r=stevenk][rollback=15289] Revert r15289,
[22:34] <StevenK>  it passed ec2 and failed buildbot.
[22:34] <gary_poster> lifeless, oh ok thanks for heads up
[22:34] <lifeless> gary_poster: I'd be delight to talk via voice, e.g. tomorrow, if you want to
[22:35] <StevenK> gary_poster: Sorry, I'm a muppet. I can do a rollback of r15283 if you wish.
[22:35] <StevenK> gary_poster: What breakage have you seen, so I can write a good commit message?
[22:36] <gary_poster> lifeless, cool, thanks.  I see your gist now, and will look in more detail later.
[22:36] <gary_poster> StevenK, the subunit output is broken.
[22:36] <gary_poster> um, in particular...
[22:36] <gary_poster> I believe that errors are inserted within other errors within the stream
[22:37] <gary_poster> but I didn't look too closely beyond "broken! broken!"
[22:37] <gary_poster> StevenK, ^^
[22:37] <StevenK> gary_poster: Right, if the subunit stream is broken that would explain why ec2 didn't die horribly.
[22:38] <gary_poster> yeah
[22:41] <gary_poster> Must run.  bye all