[00:59] <wallyworld_> StevenK: why did you stab me?
[01:00] <wgrant> wallyworld_: :(
[01:00] <StevenK> wallyworld_: Run "head lib/lp/code/model/branch.py" in an up-to-date devel and spot the problem.
[01:00] <wgrant> Why is the new 'user' argument on the methods at random positions?
[01:01] <wgrant> -    def deletePillarSharee(pillar, sharee, information_types):
[01:01] <wgrant> +    def deletePillarSharee(pillar, sharee, user, information_types):
[01:01] <wgrant> -    def revokeAccessGrants(pillar, sharee, branches=None, bugs=None):
[01:01] <wgrant> +    def revokeAccessGrants(pillar, user, sharee, branches=None, bugs=None):
[01:02] <wgrant> +    def _populatePermissionsCache(cls, permissions_cache,
[01:02] <wgrant> +                                  shared_artifact_info_types, grantee_ids,
[01:02] <wgrant> +                                  policies_by_id, persons_by_id): all_permission_term = SQL("bool_or(artifact IS NULL) as all")
[01:02] <wgrant> Bah, stupid irssi
[01:02] <wgrant> But that function is doubly-indented.
[01:02] <wallyworld_> one is an internal method, so meh
[01:02] <wallyworld_> and was likely written at a different time
[01:03] <wgrant> Two Person arguments with different meanings swapped in two very similar methods is rather perilous and PHP
[01:04] <wallyworld_> StevenK: ah, sorry, will fix as a driveby
[01:04] <wgrant> The chance of someone not getting the order wrong is roughly 0
[01:04] <StevenK> wallyworld_: I have it fixed locally
[01:04] <StevenK> wallyworld_: And I need to touch IBranch anyway, so I'll sort it out
[01:04] <wallyworld_> thanks
[01:08] <StevenK> wallyworld_: Strangely, all 4 imports are not used.
[01:09] <wallyworld_> StevenK: i may have happened after devel was merged in and i was resolving merge conflicts
[01:11] <StevenK> wallyworld_, wgrant: Do I want to do the same thing as IBug.subscribe in IBranch.subscribe?
[01:11] <wallyworld_> i think so
[01:11] <wgrant> StevenK: For what? Creating grants?
[01:11] <wallyworld_> if user can't see branch they are being subscribed to, add an AAG
[01:12] <StevenK> wgrant: Yes.
[01:12] <wgrant> Yeah, sounds good.
[01:12] <StevenK> I wonder if we want the same check in IBranch.subscribe() too
[01:12] <wgrant> StevenK: Even better if you fix Branch.unsubscribe()'s new **kwargs while you're there.
[01:13] <wgrant> Which check?
[01:13] <StevenK> If it's a private bug, you can not subscribe open and delegated teams.
[01:13] <wgrant> Probably.
[01:13] <StevenK>         ignore_permissions = kwargs.get('ignore_permissions', False)
[01:13] <StevenK> *staba*
[01:14] <StevenK> s/a.$/
[01:29] <wgrant> wallyworld_: How do I set up celery to run the jobs locally?
[01:42] <lifeless> cool - http://googleonlinesecurity.blogspot.co.nz/2012/06/security-warnings-for-suspected-state.html
[01:42] <lifeless> we need a warning bar like that ;>
[01:43] <StevenK> "We suspect you are trying to do something silly" ?
[02:38] <wallyworld_> wgrant: in tests, you use CeleryLayer, for dev, start the deleryd from bin
[02:38] <wallyworld_> celeryd
[02:38] <wallyworld_> and there's a fflag you add your job class name to
[02:39] <wallyworld_> the flag takes a space separated list
[02:39] <wallyworld_> of jobs which celery should run
[04:51]  * StevenK peers at create_initialized_view()
[04:52] <StevenK> Oh, team.name, sigh
[05:14] <StevenK> Hmmm, where are the tests that make sure that a AAG is created when someone is subscribed to a bug?
[05:34] <wallyworld_> StevenK: test_bugvisibility
[05:46] <mwhudson> random buildout question
[05:46] <mwhudson> where does bin/twisted come from?
[05:47] <StevenK> mwhudson: It's created a buildout rule
[05:47] <mwhudson> StevenK: right, i got that far
[05:47] <mwhudson> which one, though?
[05:48] <mwhudson> oh
[05:48] <mwhudson> the scripts one i guess
[05:48] <mwhudson> zc.recipe.egg:scripts != z3c.recipe.scripts i guess?
[05:49] <bigjools> I really wish Python were more informative when there's an import error
[05:52] <mwhudson> no, that's not it
[05:54] <bigjools> mwhudson: setup.py?
[05:55] <StevenK> Yeah, it's setup.py
[05:55]  * StevenK rips his eyes out after reading it
[05:55] <mwhudson> bigjools: aaah
[05:55] <mwhudson> thanks
[05:55] <bigjools> it's always fun when we randomly put the same stuff in different files
[06:12] <StevenK> wallyworld_: Can you glance at https://code.launchpad.net/~stevenk/launchpad/branch-subscribe-aag/+merge/108881 ?
[06:14] <wallyworld_> yes
[06:20] <wallyworld_> StevenK: TestBranchSubscriptionAddOtherView could iterate over all types of open team and test with each one
[06:21] <wallyworld_> StevenK: also getVisibleArtifacts - you have the return tuple mixed up
[06:21] <wallyworld_> StevenK: also, there are no legacy branch triggers so that check isn't needed
[06:23] <wallyworld_> StevenK: and so the reason the test_subscribe_gives_access test passes is that the branch collection assumes subscribed = visible
[06:24] <wallyworld_> so that bit of code is sort of pointless atm
[06:24] <StevenK> wallyworld_: Do you want to put all of that into the MP?
[06:24] <wallyworld_> ok
[06:24] <StevenK> (And anything else you find)
[07:54] <adeuring> good morning
[08:04] <StevenK> stub: The index is for speeding up the findSPPHs() method of the garbo job, not the evil monster query in __call__.
[08:07] <stub> StevenK: Still not sure if that index would work :) Has it been tested, or shall we try on staging?
[08:07] <wgrant> stub: Why wouldn't it work?
[08:07] <stub> wgrant: Because the planner can be stubborn :)
[08:07] <wgrant> We're finding SPPHs without a PU, ordered by ID
[08:07] <wgrant> I'm pretty sure I tested it on DF
[08:08] <StevenK> stub: The query doesn't involve joins, it's just "SELECT id FROM spph WHERE packageupload IS NULL ORDER BY id"
[08:08] <wgrant> The index is completely perfect for it, and the query is simple.
[08:08] <stub> Oh, ordered by id should force it. If you have tested it, fine.
[08:09] <stub> So this should go live on production?
[08:10] <StevenK> Let me land it first :-)
[08:10] <wgrant> Do show me the CREATE INDEX invocation first :)
[08:13] <stub> https://code.launchpad.net/~stevenk/launchpad/spph-packageupload-index-redux/+merge/108852
[08:14] <stub> Blocked on backups atm anyway.
[08:15] <wgrant>    ->  Index Scan using sourcepackagepublishinghistory__packageupload__idx on sourcepackagepublishinghistory  (cost=0.00..52499.86 rows=11359 width=4) (actual time=0.138..0.228 rows=60 loops=1)
[08:15] <wgrant>  Total runtime: 0.369 ms
[08:15] <wgrant> :)
[08:18] <StevenK> The commit message should please both wgrant and bigjools.
[08:19] <StevenK> stub: r15367 on devel
[08:19] <StevenK> I guess the backups should be done soonish?
[08:23] <wgrant> Could be another hour
[08:36] <StevenK> wgrant: I'm going to toss the SPPH+PU garbo job at ec2.
[08:38] <wgrant> StevenK: Sounds good.
[09:00] <stub> I think the control we have for not accidently deplying in fdt a db patch that should have been deployed live is the qa-ok tag on the corresponding bug? I guess we don't always have a bug.
[09:20] <wgrant> stub: The normal control is that I don't make mistakes like that.
[09:20] <wgrant> stub: Although live patches tend to be landed on devel.
[09:20] <wgrant> So it's not an issue.
[09:31] <stub> wgrant: Which makes you a single point of failure :)
[09:32] <stub> Seems to be working well enough though, no point complicating things. Just musing.
[09:36] <wgrant> stub: Oh, it's certainly suboptimal.
[09:36] <wgrant> But quite effective for now.
[09:45] <frankban> hi, I have to land an approved branch of launchpad-buildd, how to do that? I guess I could merge it locally, commit with "[r=reviewer] ..." message and then push to trunk. Am I right?
[09:50] <wgrant> frankban: That's right.
[09:51] <frankban> cool wgrant, thank you
[10:03]  * jml resubmits branches for landing
[10:03] <jml> third time. both previous times no actual feedback.
[10:07] <lifeless> jml: that may mean they failed so spectacularly that failure mail got nommed
[10:07] <jml> lifeless: yes. or that my email config was broken. or that something else failed.
[10:13] <jml> oh actually
[10:14] <jml> my bad. hadn't quite caught up with long weekend email.
[10:14] <jml> I have a successful ec2 test run for lp:~jml/launchpad/archive-commercial-rename-support. Would someone please land it for me/
[10:22] <jml> frankban? rvba?
[10:23] <frankban> jml: ok
[10:24] <jml> frankban: thank you.
[10:40] <jml> frankban: thanks :)
[10:40] <frankban> jml: welcome
[11:03] <cjwatson> Is it just me or is WebServiceCaller.named_get busted?
[11:03] <cjwatson>         return self.get("%s?%s" % (path_or_url, data), data, headers,
[11:03] <cjwatson>                         api_version=api_version)
[11:03] <cjwatson> but:
[11:03] <cjwatson>     def get(self, path, media_type='application/json', headers=None,
[11:03] <cjwatson>             api_version=None):
[11:04] <cjwatson> I don't see how data can possibly be a sensible thing to pass as media_type
[11:05] <mgz> does look dodgy.
[11:05] <mgz> write a failing test?
[11:06] <wgrant> That indeed looks a little broken.
[11:14] <cjwatson> How do I run its test suite?  I seem to need to link in LP's download-cache somehow, but can't quite figure out how ...
[11:16] <rick_h> cjwatson:  ./utilities/link-external-sourcecode ../devel
[11:17] <rick_h> cjwatson: so I run that from a branch to link over the download cache/etc bits into my current branch
[11:17] <rick_h> cjwatson: or maybe I'm not reading enough scrollback and you're talking something different...
[11:19] <wgrant> cjwatson: Symlink ~/launchpad/lp-sourcedeps/download-cache into the tree as download-cache
[11:19] <wgrant> And, for speed, probably ~/launchpad/lp-sourcedeps/eggs as well
[11:19] <wgrant> Then python ./bootstrap.py
[11:20] <wgrant> I use './bootstrap.py --version 1.5.2 --setup-source=download-cache/ez_setup.py --download-base=download-cache/dist' to avoid slow PyPI access, but you might get away without it.
[11:23] <cjwatson> rick_h: no utilities/ in lazr.restful
[11:23] <rick_h> cjwatson: yea, gotcha. Missed that part.
[11:23] <rick_h> cjwatson: so yea, with lazr.restful I think I had to just mkdir the download-cache and then just take the first hit in downloading packages
[11:24] <cjwatson> wgrant: Yeah, that's not happy.  http://paste.ubuntu.com/1026635/
[11:24] <wgrant> Oh wow
[11:24] <wgrant> It builds its own special lxml in buildout
[11:24] <wgrant> What an odd piece of software
[11:26] <wgrant> cjwatson: Oh!
[11:26] <wgrant> You're using setup.py build
[11:26] <wgrant> You want to run bin/buildout
[11:26] <wgrant> So you get versions that work.
[11:27] <wgrant> Rather than just the latest versions of everything.
[11:27] <wgrant> Oh how I love Python distribution mechanisms.
[11:27] <cjwatson> Ah, I see
[11:28] <mgz> buildout is its own special kind of mess
[11:41] <wgrant> cjwatson: lazr.restful's tests still pass, which is odd.
[11:41] <wgrant> Surprised it hasn't bitrotten.
[11:45] <czajkowski> rick_h: hot desk is where people have a spare desk in an office and either rent out or some just leave it free so they open it up to people travelling :)
[11:46] <rick_h> czajkowski: ah, ok. That makes sense I guess.
[11:48] <czajkowski> rick_h: usually found in co-working spaces
[11:49] <cjwatson> wgrant: And the Accept header seems to make little difference (the obvious test that might fail in fact passes), so I suspect actually this media_type brokenness isn't my problem
[11:50] <cjwatson> If I could get a little more than "HTTP/1.1 400 Bad Request" out of the damn thing it might help
[11:52] <wgrant> cjwatson: What're you trying?
[11:53] <cjwatson> Trying to convert test_distroseries_dist_upgrader to use my new PU API rather than CommandRunner.  The request/response pair is http://paste.ubuntu.com/1026681/
[11:54] <wgrant> cjwatson: Huh, that's pretty useful.
[11:55] <cjwatson> Current untidy code diff is http://paste.ubuntu.com/1026682/
[11:55] <cjwatson> (I can probably go back to .named_get there; it fails the same way either way ...)
[11:56] <wgrant> Yeah, named_get would be a bit more clear.
[11:56]  * wgrant tries.
[11:56] <cjwatson> Oh, that won't be desperately useful without http://paste.ubuntu.com/1026688/ too.
[11:57] <wgrant> Well
[11:57] <wgrant> Shouldn't be relevant to that error :)
[11:57] <cjwatson> Yeah
[11:59] <wgrant> cjwatson: Does that tests actually do anything useful?
[11:59] <wgrant> It's probably because the test is not running in AppServerLayer
[11:59] <wgrant> So there's no appserver to talk to.
[12:00] <cjwatson> Aha, that would make sense
[12:00] <wgrant> But there's no point having that as a webservice test.
[12:00] <cjwatson> It's an integration test for whether dist-upgrader uploads can be accepted/rejected.  There was a bug about that once upon a time.
[12:00] <cjwatson> It's not really testing the webservice - but it's currently using stuff from soyuz/scripts/queue.py, which I want to kill
[12:01] <cjwatson> And since it's basically doing the equivalent of "queue accept", it seemed to make some sense to transfer that over to the new equivalent of the same tool
[12:02] <wgrant> cjwatson: See r3691.1.200
[12:02] <wgrant> cjwatson: The only significant changes in that rev were to the queue tool itself
[12:03] <wgrant> The formatting and such
[12:03] <wgrant> I'd delete the test.
[12:03] <cjwatson> Wait, how come say TestBuildPackageJobScore works then?  It's not running in AppServerLayer either.
[12:04] <wgrant> Hm
[12:04] <wgrant> Perhaps WebServiceCaller works in FunctionalLayer
[12:04] <wgrant> Your test is currently Zopeless
[12:05] <wgrant> FunctionalLayer calls some ancient Zope stuff which adds fake HTTP hooks and stuff like that.
[12:05] <wgrant> Anyway, that test isn't useful if the queue tool doesn't exist any more.
[12:05] <cjwatson> I guess I just feel uncomfortable about having nothing that does a straight-through test of accepting custom uploads.
[12:06] <wgrant> Ah
[12:06] <cjwatson> But you think the original bug was purely presentational in the queue tool/
[12:06] <cjwatson> ?
[12:06] <wgrant> If there's really nothing else that tests that sort of thing, replace it with a model test.
[12:07] <cjwatson> Right.  I'll have a look, maybe there is
[12:08] <wgrant> Webservice tests are slow and awkward, so they should be avoided whenever possible.
[12:08] <wgrant> And in this case the webserviceness is entirely irrelevant.
[12:13] <cjwatson> Makes sense.  Thanks.
[12:43] <bac> hi sinzui
[13:00] <czajkowski> sinzui: aloha!
[13:01] <czajkowski> sinzui: I've 2 projects being created by one person for two seperate things, however using a licence I've never heard of, would you mimnd if you get a chance having a look please?  https://launchpad.net/projects/+review-licenses
[13:04] <wgrant> czajkowski: Non-free
[13:04] <wgrant> "The user may use the work for any good purpose and he may not use it to
[13:04] <wgrant> harm others or violate the permissive principles of Islam"
[13:04] <czajkowski> wgrant: it must be sleep time for you!
[13:05] <wgrant> It's never sleep time when there are stupid, stupid licenses to tell to GTFO,.
[13:05] <czajkowski> :/
[13:06] <bac> wgrant: :)
[13:06] <wgrant> Hm
[13:07] <wgrant> Although the English version isn't binding, so that's relying on precision of the translation.
[13:07] <czajkowski> wgrant: aye it's been the strangest one I've seen so far
[13:07] <wgrant> Debian says it's non-free.
[13:07] <wgrant> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579796
[13:08]  * benji contemplates the craziest possible license he could come up with.
[13:08] <czajkowski> well I've seen the ones that are peoples own license, but they just come across as rude
[13:09] <czajkowski> the above one seemed well thought out and written but made no sense for a lp project
[13:12] <benji> I'm remninded of the ExtTLD license which includes "You agree you are not involved in or profit from the use of animals for entertainment such as circuses, hunts, rodeos and races etc."
[13:12] <benji> All the open-source-using clowns add an extra tear to their makeup when they read that.
[13:12] <nigelb> wtfpl
[13:13] <nigelb> haha
[13:13] <nigelb> I like wtfpl.
[13:13] <nigelb> "Do whatever the f you want with this code"
[13:14] <cjwatson> These licences are all basically well-intentioned but fall afoul of not everyone agreeing on general principles of "good".
[13:15] <cjwatson> And in general trying to use software licences to control things that aren't actually much to do with software.
[13:15] <stub> I recall a beer licence, which granted the user permission to buy the author a beer if they wanted.
[13:16] <nigelb> stub: I think I like that license, but it should be s/beer/booze/g
[13:17] <benji> yeah, fortunately the "field of endeavor" restrictions that used to be popular have mostly gone away.
[13:21] <wgrant> benji: That's not one I've run into before.
[13:21] <wgrant> Quite impressive.
[13:21] <wgrant> ly misguided
[13:21] <benji> heh
[13:22] <bac> czajkowski: note that the project is dual licensed with GPLv3.  it is not triggering the 'you must buy a subscription' warning.
[13:22] <bac> the two licenses are incompatible, but that's not our concern
[13:22] <wgrant> bac: Is it dual-licensed, or did they just say that?
[13:23] <bac> wgrant: the GPL 3 text file is in their branch
[13:23] <benji> wgrant: you would probably appreciate _why's "Death and Repudiation" license which states that you only have the right to use the softwre after you are dead.
[13:25] <wgrant> bac: Surprising. I find people mostly say GPL to get around the Launchpad checks, but it seems that it is indeed the case here.
[13:26] <bac> i'd be in favor of at least communicating to the owner that waqf is not OSI-approved and does not meet our "field of endeavor" restrictions.
[13:27]  * bac wonders wth the project actually does
[13:27] <benji> bac: ironically it's a guidance system for nuclear warheads
[13:28] <czajkowski> yeah...
[13:36] <sinzui> czajkowski, That license is not the first thing I want to read in the morning
[13:36] <czajkowski> sinzui: aplogies
[13:37] <czajkowski> sinzui: wasnt my cup of tea on a wednesday either :)
[13:37] <sinzui> The "good" aspect always leads to a discusion of discriminating against the evil doers of this world.
[13:38] <sinzui> Debian agrees, they accepted a package with the same license as non-free https://launchpad.net/ubuntu/quantal/+source/othman/+copyright
[13:39] <sinzui> czajkowski, I will send a license-conflict-notice to maintainer
[13:39] <czajkowski> sinzui: okie dokie thanks
[13:40] <czajkowski> sinzui: sorry for the bad start but I did want to check with folks first
[13:40] <wgrant> sinzui: bac points out that it's GPL too, so it's strange but fine.
[13:41] <sinzui> wgrant, It had to be relicensed
[13:42] <sinzui> wgrant, there was a very long thread and a bug about it. The agreement was it was non-free
[13:43] <wgrant> Hah
[13:43] <sinzui> wgrant, do disagree?
[13:43] <wgrant> http://www.ojuba.org/wiki/waqf/faq is quite hilarious.
[13:43] <wgrant> sinzui: Waqf is clearly non-free. No disagreement there.
[13:44] <sinzui> okay. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579796 and this thread are in agreement http://www.archivum.info/debian-devel@lists.debian.org/2010-07/00051/-quot-Waqf-quot-General-Public-License-in-Debian.html
[13:44] <wgrant> sinzui: Right, but it's moot since it's dual-licensed.
[13:45] <sinzui> yes indeed.
[13:46] <jml> need another branch landed: https://code.launchpad.net/~jml/launchpad/generate-ppa-logging/+merge/108040
[13:46] <jml> did a test run. three doctests failed and my last push just fixed those.
[13:46] <sinzui> czajkowski, you can approve the two projects since they are gpl. They can join the older Microsoft licenses we also have in the system.
[13:46] <jml> this is necessary to remove a cowboy so would appreciate a swift landing.
[13:47] <wgrant> jml: That cowboy has been deployed over like 4 times :)
[13:47] <wgrant> It's long gone.
[13:47] <jml> wgrant: oh ok.
[13:47] <jml> wgrant: well, the branch still needs landing :)
[13:48] <wgrant> jml: You don't have privs?
[13:48] <jml> wgrant: pqm bounced my last attempt (last week)
[13:49]  * jml tries again
[13:49] <wgrant> That's not very nice of it.
[13:49] <wgrant> Worth another try now we're not in testfix or anything.
[13:50] <jml> hmm.
[13:50] <jml> wrong key is being used :\
[13:51] <czajkowski> sinzui: bac wgrant thanks for the help with that one
[13:52] <jml> haoesuhseo
[13:53] <jml> gpg.conf has default key set to the correct key but lp-land uses the old key. wtf.
[13:54] <sinzui> wgrant, where am I going to put all the bug  you reported?
[13:54] <wgrant> jml: bazaar.conf has a gpg_signing_key setting
[13:54] <wgrant> sinzui: I'll hopefully fix most of them tomorrow.
[13:55] <jml> which I don't have set... doing so now
[13:55] <wgrant> jml: Hm, odd then.
[13:57] <jml> \o/
[13:59] <wgrant> jml: Marvellous.
[14:30] <czajkowski> sinzui: are you spring cleaning answers?
[14:31] <sinzui> czajkowski, I fulfilled my promise to let other people do answers for a year
[14:37] <czajkowski> sinzui: mrevell hangout link ?
[15:37] <cjwatson> wgrant: I didn't go as far as setting you as the only reviewer, but I think https://code.launchpad.net/~cjwatson/launchpad/queue-api/+merge/108967 could particularly use your review.
[16:10] <jcsackett> sinzui: i see that you have moved it to the backlog since this morning, but i spent a little time trying some changes to the bugstatus display for bug 997646
[16:10] <_mup_> Bug #997646: confusing colour in the same picker with different enums? <disclosure> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/997646 >
[16:10] <jcsackett> sinzui: http://people.canonical.com/~jc/images/bugstatus-color-issue.png
[16:11] <jcsackett> it's just a bit of differentiation, but i think it may be enough. gray *is* a pretty good color choice for those options.
[18:03] <sinzui> jcsackett, don't be concerned about where I moved it. It stil needs to be worked on
[18:04] <sinzui> jcsackett, I wanted to add wgrant critical and high bugs since they are the items that block the sharing beta
[18:04] <sinzui> jcsackett, +1 for the bold
[18:05] <sinzui> jcsackett, I think some of our shades of grey violate WCAG. We need more contrast
[18:07] <sinzui> jcsackett, #666 is the lightest text can be. I bet we have shades that are higher.
[18:08] <sinzui> jcsackett, sweet, PSU has a cheatsheet for us! http://accessibility.psu.edu/contrasthtml
[18:20] <sinzui> jcsackett, I see in colour.css that we use #999, #bebebe, and gray. We use these for status colours. I see in form.css that .formHelp used for descriptions is #777. I think the last must be changed to #666, and we may want the others to be #555
[20:02] <jcsackett> sinzui: sorry we keep missing each other. i've read your comments here and on the MP; i'll give some other colors a try.
[20:02] <sinzui> thank you
[21:40] <james_w> feature flag convention is None for not set right?
[21:40] <james_w> what should be done for booleans?
[21:40] <james_w> just bool() and get on with it?
[21:50] <lifeless> there is a faq on this
[21:50] <lifeless> I odn't remember if its in the code or the wiki
[21:51] <lifeless> but yeah, bool() - so unset, and "" both evaluate to 'off' and anything else to 'on'
[21:52] <wgrant> Most notably, 'off' evaluates to 'on'
[21:53] <lifeless> as does False and false
[21:53] <lifeless> and 0
[21:53] <james_w> I don't see it on https://dev.launchpad.net/FeatureFlags
[21:53] <lifeless> check the memcache flag
[21:55] <maxb> Does anyone remember what the final state of fixing branch stacking URLs to not break if branches were renamed, was?
[21:55] <maxb> I had somehow got the idea that all existing branches had been fixed up to point at +branch-id URLs, but apparently not
[21:55] <lifeless> they were
[21:55] <lifeless> branch-distro regressed it
[21:55] <lifeless> as its code isn't updated
[21:56] <maxb> *ah*
[22:03] <james_w> lifeless, https://dev.launchpad.net/FeatureFlags#Boolean_values if you care to check
[22:05] <james_w> hmm, this test is running as a different dbuser that doesn't have DELETE on featureflag
[22:05] <lifeless> you need to switch dbuser back before dropping the flag
[22:06] <james_w> implicit teardown doesn't make it that easy to switch for that bit of code
[22:06] <lifeless> so you need two context managers
[22:06] <lifeless> there is a context manager for dbuser and one for flags, should work fine
[22:06] <lifeless> if you're using useFixture, you should be able to useFixture the dbuser context manager.
[22:06] <lifeless> If its not a fixture, a trivial adapter is probably in order
[22:07] <james_w> useFixture to the non-standard user
[22:07] <james_w> or to a standard user for this one particular test?
[22:07] <lifeless> nonstandard user
[22:07] <lifeless> usefixture(a); usefixture(b); do stuff is equivalent to
[22:07] <lifeless> with a,b: dostuff
[22:07] <lifeless> a needs to do the flags
[22:08] <james_w> yes
[22:08] <lifeless> b needs to do the dbuser switch
[22:08] <james_w> but currently this TestCase just uses dbuser = config.generateppahtaccess.dbuser
[22:08] <james_w> so I'll have to unpack that, or move this test to a different TestCase
[22:11] <lifeless> what, as a class variable ?
[22:12] <james_w> ah
[22:12] <james_w> that's not a standard thing it turns out
[22:12] <lifeless> if so, yes, unpack it (personally I find that horrible: its not as flexable as resources=... and you can't express dependencies etc)
[22:21] <wgrant> lifeless, james_w: What about my dbuser context manager?
[22:21] <wgrant> from lp.testing.dbuser import dbuser
[22:21] <wgrant> with dbuser('testadmin'):
[22:21] <wgrant>     # hahah i am god
[22:21] <james_w> wgrant, I've used that
[22:21] <james_w> I couldn't just use it directly though
[22:22] <wgrant> Ohhh
[22:22] <wgrant> FeatureFixture, right
[22:22] <wgrant> That'll teach me to read more than 5 lines of scrollback
[22:29] <lifeless> :)
[22:29] <lifeless> its possible
[22:29] <lifeless> perhaps
[22:29] <lifeless> that featurefixture should auto switch as needed
[22:29] <lifeless> I'd worry about magic side effect syndrome
[22:54] <james_w> well, that's sent the diffstat the wrong way
[23:18] <StevenK> wallyworld_: http://pastebin.ubuntu.com/1027740/
[23:53] <wgrant> wallyworld_: Oh
[23:53] <wgrant>         subscribed_invisible_bugs = store.find(
[23:53] <wgrant>             Bug,
[23:53] <wgrant>             BugSubscription.bug_id == Bug.id,
[23:53] <wgrant>             BugSubscription.person == self.grantee,
[23:53] <wgrant>             bug_filter)
[23:54] <wgrant> RemoveBugSubscriptionsJob will remove members.
[23:54] <wgrant> RemoveGranteeSubscriptionsJob does not
[23:54] <wallyworld_> yes
[23:54] <wallyworld_> i think so
[23:54] <wallyworld_> will have to relook at the code
[23:55] <wallyworld_> to rehresh my memory
[23:55] <wgrant> In fact I think I said that in the bug.
[23:55] <wgrant> But that was like a day ago
[23:55] <wallyworld_> so you saying removing a team member calls the wrong job?
[23:56] <wallyworld_> wgrant: i just re-rea dthe bug report: "If I subscribe a team and then one of its members to a bug...."
[23:57] <wallyworld_> if the member is separately subscribed, then they will retain access
[23:57] <wallyworld_> even if they are removed from the team
[23:59] <wgrant> wallyworld_: Not quite