[00:09] <cjwatson> Would anyone else find http://paste.ubuntu.com/991587/ useful?  Should I send that to launchpad-dev?
[00:09] <cjwatson> My bzrlib is rusty; it probably shows.
[00:10] <jelmer> cjwatson: perhaps a useful thing to stick in lp-dev-utils ?
[00:11] <cjwatson> Yeah, perhaps I should just send an MP there ...
[00:25] <wallyworld_> wgrant: the sharingdetails page for ~launchpad-security timeout cold at around 6s on qas since it is displaying ~750 bugs and that page doesn't have batching. the slowest query is the bugtask privacy filter with all those ORs, plus there's some slowish python to assemble the results. given this level of sharing will be going away and it runs ok on qas after a refresh or two, i think we can leave it go for now. the page bulk
[00:25] <wallyworld_> loads all data and query count is minimal
[00:25] <wgrant> wallyworld_: OOPS ID?
[00:26] <wallyworld_> don't have one anymore since i refresh the page with ++profile++ and it went away
[00:27] <cjwatson> https://code.launchpad.net/~cjwatson/lp-dev-utils/loc-delta/+merge/106080
[00:28] <wgrant> wallyworld_: Can you use ++oops++ to grab one?
[00:28] <wgrant> Want to see the query and just how slow it is.
[00:29] <wallyworld_> wgrant: OOPS-3ce9cad8e944ce915a7b4b967eeed405
[00:29] <wallyworld_> query is the standard bug task id search
[00:30] <wallyworld_> about 1300ms
[00:30] <wallyworld_> that's the slowest one
[00:36] <wallyworld_> StevenK: does your current work add an info_type parameter to makeBranch() in factory?
[00:45] <wgrant> wallyworld_: That query is 40ms hot on DF. I wonder if qastaging is just cold.
[00:46] <wallyworld_> wgrant: could be. there's a lot of OR's in there. the page on qas now takes around 5s to load which is pushing the friendship a bit. but it's rendering 750 entries
[00:47] <wallyworld_> and since we do not expect to see that many shared artifacts moving forward, i think it's ok
[00:47] <wallyworld_> or we need to add batching
[00:47] <wgrant> We probably will need to add batching, but we'll see.
[00:47] <wallyworld_> the core issue with regard to the number and type of queries has been addressed
[00:48] <wallyworld_> let's see what happens on prod
[00:50] <StevenK> wallyworld_: It does, yes.
[00:51] <wallyworld_> StevenK: what's the eta? i may have to put a branch up for review a bit later and then merge yours in before i land
[00:54] <StevenK> wallyworld_: I have a bunch of test failures to sort out.
[00:54] <wallyworld_> ok
[01:02] <wgrant> wallyworld_: Ahhh
[01:02] <wgrant> wallyworld_: There's so many disjunctions that the planner gets confused.
[01:03] <wallyworld_> would IN be better?
[01:03] <wgrant> wallyworld_: With <100 it's OK, but with 700 it spends a second planning and gives up.
[01:03] <wgrant> wallyworld_: So an IN is much better for huge stuff like this :(
[01:03] <wallyworld_> wgrant: i f*cking told you!
[01:03] <wgrant> You didn't say there were 770 of them :P
[01:03] <wallyworld_> i said there were "lots"
[01:03] <wallyworld_> :-P
[01:03] <wgrant> I thought we were dealing with sensible batches!
[01:04] <wallyworld_> to quote you, "but this is launchpad"
[01:04] <wgrant> Anyway, should be easy enough to convince that function to use is_in instead.
[01:04] <wallyworld_> i'll spin up a followup branch a bit later
[01:04] <wallyworld_> wgrant: i could just replace the OR with IN in all cases
[01:04] <wgrant> You'll need to special-case for when the PK is a single column.
[01:04] <wgrant> But it's like 2 lines.
[01:05] <wgrant> Since technically it can be used for composite keys now too
[01:05] <wgrant> Although you could just assert in that case :)
[01:05] <wgrant> Since it's unlikely we'll ever want it to.
[01:06] <wgrant>                 comp._relation.get_where_for_local(value)
[01:06] <wgrant>                 for value in search_value.query_values])
[01:06] <wgrant> get_where_for_local can technically return more than a simple equality.
[01:06] <wgrant> You should probably assert that it returns a simple equality.
[01:06] <wallyworld_> ok, will look into doing that
[01:06] <wallyworld_> will finish what i'm on first
[01:07] <wgrant> Sure
[01:08] <lifeless> loc - http://www.ohloh.net/p/launchpad
[01:08] <wgrant> _dbify_value and _dbify_column in lp.services.database.bulk show some of the Storm molestation you might desire.
[02:10]  * wgrant needs a reviewer for https://code.launchpad.net/~wgrant/launchpad/what-the-distromirror/+merge/106086 at some point (non-urgent now)
[02:18] <wgrant> wallyworld_: +        <div id='information-type-description' style='padding-top: 5px'>Everyone can see this information.</div>
[02:18] <wgrant> Isn't that too hardcoded?
[02:18] <wallyworld_> huh? that's template which is replaced
[02:19] <wgrant> By JavaScript.
[02:19] <wallyworld_> like we do for the rest of our TAL
[02:19] <wallyworld_> yes
[02:19] <wgrant> +      This report contains <strong id="information-type" tal:content="view/information_type"></strong> information&nbsp;
[02:19] <wgrant> +        <a class="sprite edit" id="privacy-link" tal:attributes="href link/path" tal:condition="link/enabled"></a>
[02:19] <wgrant> +        <div id='information-type-description' style='padding-top: 5px'>Everyone can see this information.</div>
[02:19] <wgrant> The information_type title will be replaced if it's non-public, but the description will not.
[02:19] <wgrant> (before the JS loads)
[02:20] <wallyworld_> hmmm. i think you are right
[02:20] <wallyworld_> i should fix that
[02:21] <wallyworld_> grumble. too many branches open
[02:23] <cjwatson> Sounds like an error message from Perforce.
[02:26]  * cjwatson eyes his branch to allow granting per-pocket upload permissions.  It's passing tests.  I'm not sure I quite believe it can be this easy.
[02:27] <wgrant> cjwatson: It's very easy.
[02:27] <wgrant> Queue perms are a bit harder.
[02:28] <wgrant> But not by much.
[02:28] <cjwatson> I wonder if this would allow nuking ubuntu-security as a celebrity.  (Probably not quite since (a) they have to move over to copyPackage and (b) I have to figure out how to save them from having to manually approve all their copies.)
[02:29] <wgrant> That was the plan.
[02:29] <wgrant> It's only a celebrity so they can have launchpad.Append on the primary archive, to use syncSource.
[02:29] <cjwatson> Oh and copyPackage probably needs to learn how to do the librarian republishing dance.
[02:29] <wgrant> It should already do that.
[02:30] <wgrant> But that needs testing.
[02:30] <cjwatson> OK, that helps.
[02:30] <wgrant> It's in the core copy infrastructure these days.
[02:30] <cjwatson> Modulo lies about the db revision, does http://paste.ubuntu.com/991705/ look plausible?  I'm concerned that the constraint modification there is wrong, but there's no MODIFY CONSTRAINT in pg.
[02:31] <wgrant> cjwatson: Seems sort of reasonable, unless you want universe queue admins.
[02:31] <wgrant> In which case you want component+pocket.
[02:32] <wgrant> s/queue admins/SRU admins/
[02:32] <cjwatson> I don't.
[02:33] <StevenK> cjwatson: COMMENTs are usually added to database/schema/comments.sql
[02:33] <cjwatson> I was more concerned whether DROP/ADD CONSTRAINT was remotely sane.
[02:33] <wgrant> cjwatson: That's fine, the table is small.
[02:33] <cjwatson> $ grep COMMENT database/schema/patch-2209-* | wc -l
[02:33] <cjwatson> 12
[02:33] <wgrant> cjwatson: It's a problem on large tables until PG 9.2
[02:33] <wgrant> StevenK: It can be either now
[02:33] <StevenK> Bleh
[02:33] <StevenK> cjwatson: grep -c ? :-)
[02:33] <cjwatson> picky picky
[02:33] <StevenK> Haha
[02:34] <cjwatson> Anyway, no, that's a per-file count
[02:35] <cjwatson> Well, in that case does anyone fancy allocating me a DB patch number for this?  I need sleep shortly but I could get at least the DB side of this going.
[02:35] <cjwatson> wgrant: the librarian privacy bits only seem to be driven from UnembargoPackage, looking at packagecopier.py
[02:36] <wgrant> cjwatson: I'll grab a patch number.
[02:36] <cjwatson> UnembargoSecurityPackage that is
[02:37] <wgrant> cjwatson: You're missing a crucial piece of information.
[02:37] <wgrant> cjwatson: Launchpad is not sensible.
[02:37] <wgrant> scripts.packagecopier is also called by model.queue
[02:37] <wgrant> When realising copies.
[02:37] <StevenK> cjwatson: You can also look at lp:~launchpad/+junk/dbpatches and ask someone to allocate you a patch number you pick.
[02:37] <wgrant> Ah, but PCJs skip that :(
[02:37] <wgrant> bigjools: !!!
[02:38] <bigjools> what
[02:38] <wgrant> DDs left us with four inconsistent copiers and it makes me sad.
[02:38] <cjwatson> Ah, I missed the call in realiseUpload
[02:39] <wgrant> cjwatson: That's how syncSource works.
[02:39] <wgrant> When it sees there are private files it produces a delayed copy.
[02:39] <wgrant> Which is actually a PackageUpload.
[02:39] <cjwatson> The direct/delayed copy nomenclature refuses to fit into my head for some reason.
[02:39] <wgrant> cjwatson: 2209-18-1
[02:39] <cjwatson> Though I can see how it makes sense.
[02:39] <StevenK> Can we destroy delayed copies yet?
[02:39] <wgrant> It doesn't make sense.
[02:40] <wgrant> StevenK: No, mostly because of this particular thing.
[02:40] <cjwatson> wgrant: I'm adding a column, is that allowed to be -1?
[02:40] <StevenK> wgrant: Yes. :-(
[02:40] <wgrant> cjwatson: Yeah, the notes on -0 have been a lie since October.
[02:40] <wgrant> cjwatson: All patches are equal.
[02:40] <wgrant> And none are more equal than others.
[02:41] <cjwatson> I've been rather confused, since the last time I asked for a patch number for ADD COLUMN lifeless allocated me a -0, and I figured he knew what he was doing.
[02:41] <wgrant> When was that?
[02:41] <wgrant> He probably just opted to start a new series.
[02:42] <cjwatson> 2012-05-08
[02:42] <wgrant> Not specifically for a -0
[02:42] <StevenK> 2209-18-0 cjwatson      Add packageset.score.
[02:42] <wgrant> 'cause I deploy -1 patches that add and drop tables and columns all the time.
[02:42] <StevenK> Heh, 19-0 is already wgrant's.
[02:52] <lifeless> we're at +4K over 5 months now, thats much better
[02:53] <lifeless> +45K for the same period a year earliy
[02:54] <wgrant> A fair bit of that will go away with the next DB refresh, too.
[02:56] <lifeless> \o/
[02:56] <lifeless> the encouraging thing is that its a whole OOM
[02:56] <lifeless> vs say 75%
[02:56] <lifeless> which would have a different and sadder explanation
[02:57] <lifeless> cjwatson: are you also in perth this weke ?
[02:57] <cjwatson> lifeless: No, just insomniac
[02:57] <cjwatson> Is there some kind of event in Perth then?
[03:04] <bigjools> that is particularly insomniac at 4am
[03:18] <wallyworld_> wgrant: the storm NEWS file seems out of date. the one in our lpwithnodatetime fork i mean. do we not need to update that if we package a release?
[03:19] <wgrant> We don't ever actually release, we just package snapshots.
[03:19] <wgrant> I think it's up to date...
[03:19] <wgrant> wallyworld_: Why are you patching Storm?
[03:20] <wallyworld_> to make get_where_for_local work more efficiently and to handle single values and lists
[03:20] <wallyworld_> so we don't have to construct an Or expr manually in the calling code
[03:21] <wallyworld_> or worry about single or composite keys
[03:21] <wallyworld_> so it reduces down to one line in the calling code
[03:21] <wallyworld_> the work is done, i just need to package
[03:21] <wgrant> Mmm, I'd just do it in our tree. There's already a couple of functions that poke the necessary bits. None of this is exposed in Storm's public API
[03:21] <wgrant> Ah
[03:22] <wgrant> What's the diff?
[03:25] <wallyworld_> wgrant: a bit easier to read a straight cut and paste https://pastebin.canonical.com/66227/
[03:27] <wgrant> wallyworld_: Won't that break if I have a composite primary key and say "Foo.bar == (Bar.pk1, Bar.pk2)"?
[03:27] <wgrant> Which IIRC works now
[03:29] <wallyworld_> hmm. might do. i'm not 100% familiar with how == is parsed
[03:29] <wallyworld_> i could add logic to handle that
[03:30] <wallyworld_> i was going to run the storm tests to see what broke
[03:30] <wgrant> I would just add a separate function
[03:30] <wgrant> Well, method if you want it in Storm itself.
[03:30] <wgrant> Rather than overloading the existing one
[03:30] <wgrant> When it can probably already take an iterable.
[03:31] <wallyworld_> the implementation uses things like self.local_keys which are internal so i think i'd prefer it to be in storm. but we could do it in our tree if we wanted
[03:32] <wgrant> Sometimes there's little choice but to poke in the internals, because there's no way to access this internally.
[03:32] <wgrant> I mean, look at the caller already :)
[03:32] <wgrant> comp._relation
[03:32] <wgrant> It already touches Storm inappropriately.
[03:32] <wgrant> No way to access this *externally*, that is
[03:33] <lifeless> we should push as much of this into storm as we can
[03:33] <lifeless> the in-tree storm stuff shouldn't be, mostly.
[03:33] <wgrant> Sure, but that involves talking to Storm and working out how to expose these private things sensibly.
[03:33] <wgrant> ... or switching to SQLAlchemy, but I digress.
[03:34] <wallyworld_> i wish we weren't on a fork of storm
[03:34] <wgrant> The fork is very small.
[03:34] <wallyworld_> so if i do this change, do i just push it to our fork, or do i also get it merged into trunk?
[03:34] <wgrant> It's just got a couple of lines of Datetime stuff removed, and the With stuff added.
[03:34] <wgrant> wallyworld_: Also merge it into trunk.
[03:35] <wgrant> We don't want to diverge any further than we have to.
[03:35] <wgrant> Which means that if Storm doesn't accept it quickly, I'd keep it in our tree instead.
[03:35] <wgrant> Although Storm development has stalled enough that conflict resolution isn't too bad.
[03:35] <wallyworld_> the issue here is that i would be adding a method which is not exposed publically which we are calling
[03:36] <wallyworld_> and so asking for it to be added to trunk would be unusual
[03:36] <wgrant> Right.
[03:36] <wgrant> Exactly.
[03:36] <wgrant> Which is why it shouldn't be in Storm, unless it's part of a larger strategy to expose this stuff.
[03:36] <wallyworld_> i really don't want to go down that path right now
[03:36] <wgrant> Which is why I did bulk.create()'s stuff in LP, not Storm.
[03:37] <wallyworld_> i might stick it with the rest of our storm stuff
[03:37] <wgrant> There's no reason to do that.
[03:37] <wallyworld_> hide it under the carpet
[03:37] <wgrant> All it does is make things more awkward.
[03:37] <wgrant> The stuff in there is only there because it has to be in core, or monkeypatching everywhere.
[03:37] <wgrant> _get_where_for_local_many can easily be implemented as an isolated function in our codebase.
[03:37] <wallyworld_> well the alternative is to continue divirging our fork
[03:38] <wgrant> 13:37:06 < wallyworld_> i might stick it with the rest of our storm stuff
[03:38] <wgrant> Isn't that what you meant?
[03:38] <wgrant> Or you mean in like lp.services.database? That's where I'd put it.
[03:38] <wgrant> I thought you meant in the fork :)
[03:38] <wallyworld_> yes, that's what i meant
[03:38] <wallyworld_> lp.services..
[03:38] <wgrant> Right.
[03:38] <wgrant> There's already very similar stuff in lp.services.database.bulk
[03:38] <wgrant> I use _relation there
[03:39] <wallyworld_> at least then also the reference to _relation is shoved off to a helper
[03:39] <wgrant> Precisely.
[03:39] <wgrant> (bulk.create() uses it to take objects and Reference columns and work out the relevant underlying columns and values -- exactly what you're doing here)
[03:40] <wallyworld_> ok, will do that. might not get it done before i have to duck out to take the kid to his occupational therapy session. but will get it done today
[03:40] <wgrant> :)
[03:40] <wallyworld_> then the performance issue should be fully squashed i hope
[03:40] <wgrant> Yup
[03:41] <wgrant> Sorry for misleading you, I forgot it was an unbatched page.
[03:41] <wallyworld_> it seems to work on prod now but is sliggish
[03:41] <wallyworld_> sluggish
[03:41] <wgrant> Thought we were talking like 75 :)
[03:41] <wgrant> Yeah
[03:41] <wallyworld_> 75 what?
[03:41] <wgrant> 75 bugs
[03:41] <wgrant> Not 770
[03:41] <wgrant> It plans 75 ORs with no trouble at all
[03:41] <wallyworld_> ah, right. no need to apologise.
[03:42] <wallyworld_> and 700+ is way too many anyway. once we get stuff cleaned up, that will surely go away
[03:42] <wallyworld_> once we move to policy grants
[03:43] <wgrant> Weeell
[03:43] <wgrant> There'll still be some big stuff, probably.
[03:44] <wallyworld_> once we find it, we can add batching :-)
[03:44] <wgrant> Heh
[03:51] <StevenK> lifeless: It's *so* handy that testr --version or -V don't work.
[03:53] <StevenK> And I think testr run --failing is running every test
[04:01] <lifeless> StevenK: dpkg -l testrepository
[04:50] <StevenK> wgrant, wallyworld_: https://code.launchpad.net/~stevenk/launchpad/branch-use-information_type/+merge/106109
[04:56] <wgrant> Aha, the LoC offenders are revealed!
[04:57] <StevenK> Hm?
[04:57] <wgrant> Linaro looks to be +3400 in total :(
[04:57] <StevenK> Is there a breakdown by squad/person?
[05:17] <StevenK> wgrant: information_type is fully populated on production, which means we can depend on it.
[05:22] <wgrant> StevenK: Oh, bah, indeed.
[05:22] <wgrant> Forgot that.
[05:22] <wgrant> StevenK: Does it respect transitively_private?
[05:22] <wgrant> I suspect not.
[05:22] <StevenK> wgrant: In terms of your other comments, http://pastebin.ubuntu.com/991832/
[05:23] <wgrant> StevenK: You untaught the factory about information_type entirely?
[05:23] <StevenK> Hm, so I did.
[05:27] <StevenK> Bah, .transistionToInformationType respects the rules in terms of branch policy. :-/
[05:35] <bigjools> packageset.score is a terrible name :(
[05:35] <StevenK> wgrant: http://pastebin.ubuntu.com/991845/
[05:41] <wgrant> StevenK: Now the factory won't set information_type if you pass private but not information_type.
[05:41] <wgrant> And information_type silently clobbers private.
[05:44] <StevenK> And if you pass in information_type=InformationType.EMBARGOEDSECURITY, private=False ? :-)
[05:47] <wgrant> StevenK: assert
[05:47] <wgrant> Don't just silently clobber.
[05:53] <StevenK> wgrant: http://pastebin.ubuntu.com/991859/
[05:54] <wgrant> StevenK: You can't spell specify, and that check doesn't handle the case above.
[05:55] <StevenK> Yes it does?
[05:55] <StevenK> In [2]: b = factory.makeBranch(information_type=InformationType.EMBARGOEDSECURITY, private=False)
[05:55] <StevenK> ---------------------------------------------------------------------------
[05:56] <StevenK> AssertionError
[05:57] <StevenK> But it doesn't complain with private=True. Strange
[05:58] <wgrant> Er, yeah, that's the case it doesn't complain in.
[05:58] <wgrant> You want both to default to none.
[05:58] <wgrant> And at most one of them to not be none.
[06:00] <StevenK> Right, fixed.
[06:01] <StevenK> wgrant: Now that we've spent 30 minutes talking about the factory, what was your concern with respecting transitively_private?
[06:19] <wgrant> StevenK: eg. transitively_private or private gets set on a stacked-on branch, it won't propagate up.
[06:22] <StevenK> wgrant: Yes, I'm not sure what happens in that case.
[06:23] <StevenK> I do wonder how many layers of stacked_on we have in prod
[06:25] <StevenK> wgrant: Shall I land it, or we can talk it over on the call tomorrow?
[06:28] <wgrant> StevenK: You need to investigate and probably test how it interacts with stacking.
[06:28] <wgrant> There's not much to discuss yet.
[06:38] <lifeless> StevenK: I think 7 is the highest
[06:39] <lifeless> anyone looked at http://optimizely.appspot.com/features - specifically whether its js will work if we self host ?
[06:42] <stub> Does a public branch stacked on a private branch leak any information? Is it possible to retrieve revisions only in the private branch via the public branch?
[06:43] <lifeless> no and no
[06:43] <lifeless> however, the public branch will be unusable
[06:43] <stub> ah, thought it was a security issue rather than an its broken issue :)
[06:50] <lifeless> stacking: an ancient african word meaning 'we made a mistake here'
[07:23] <lifeless> stub: catchup?
[07:24] <stub> lifeless: sure. let me scare up my mic
[07:29] <lifeless> stub: I should be logged into skype; if not tell me here and I'll kill-9it
[07:29] <stub> lifeless: I don't see you
[07:44] <lifeless> stub: grah, yeah its hung
[07:55] <lifeless> stub:
[07:55] <lifeless> http://reorg.projects.postgresql.org/
[07:56] <lifeless> stub: http://pgfoundry.org/projects/reorg/
[07:59] <wgrant> Omg
[07:59] <wgrant> CLUSTER, but usable?
[07:59] <wgrant> Give me it now
[08:02] <stub> CLUSTER, but scary
[08:07] <stub> actually, not that scary. Looks like it creates a holding table, adds triggers to the source table, pours data into the holding table, merges in the delta, swaps holding table into place.
[08:08] <stub> 'swapping into place' is the scary bit as it modifies the system catalog directly so all the dependencies don't notice the move (foreign key references, views etc.).
[08:08] <stub> Leading to lovely things like: Bugfix: VIEWs and FUNCTIONs could be corrupted that used a reorganized table which has a dropped column.
[08:09] <lifeless> stub: I'm back
[08:23] <lifeless> stub: http://www.pretotyping.org/
[08:37] <lifeless> ok, night all
[08:44] <StevenK> rick_h_: Oh sigh. I see what was broken in bug 1000282.
[08:44] <_mup_> Bug #1000282: Uncaught TypeError on translations series +imports <combo-loader> <javascript> <qa-needstesting> <Launchpad itself:Fix Committed by rharding> < https://launchpad.net/bugs/1000282 >
[10:10] <jamestunnicliffe> gmb: Any estimate on https://code.launchpad.net/~dooferlad/launchpad/upcomingwork_show_incomplete_bp/+merge/105846 being reviewed? If you can't get around to it today I would like to open it up to another reviewer since it is getting urgent.
[10:10] <gmb> jamestunnicliffe: I'll have an updated patch for you by 1pm.
[10:10] <jamestunnicliffe> gmb: Supurb!
[10:10] <gmb> Apologies for the delay; post-UDS stuff has been eating into my time.
[10:11] <jamestunnicliffe> gmb: superb even :-)
[10:11] <jamestunnicliffe> Oh, I can't see this morning
[10:11] <jamestunnicliffe> Good start to the day!
[10:33] <rick_h_> StevenK: yea, nothing big. I'm surprised there aren't more of those
[10:34] <rick_h_> StevenK: at some point I'll get back to that AST branch of the combo.meta that will hopefully not be as fragile with the parsing, which isn't all *that* fragile so far
[10:46] <jelmer> cjwatson: Did you have any plans to put your loc script for review? If not, I can have a stab at doing that now.
[10:55] <wallyworld_> anyone else having issues with branches not being scanned?
[11:02] <cjwatson> jelmer: https://code.launchpad.net/~cjwatson/lp-dev-utils/loc-delta/+merge/106080 (which is awaiting scanning for the latest change that renames it to the slightly more explanatory loc-contributions, c.f. wallyworld_'s comment ...)
[11:02]  * wallyworld_ has 3 branches which have not been scanned
[11:02] <wallyworld_> all within the last 45 minutes or so
[11:03] <wallyworld_> i tried forcing a rescan and also pushing to a new test branch
[11:07] <cjwatson> sounds like something to ask ops about, since that roughly coincides with the 9.1 upgrade
[11:08] <cjwatson> Anyone have thoughts on plausible things I can do with bug 1000570?
[11:09] <jelmer> bug 1000570 ?
[11:09] <cjwatson> bah, botless.  it's a column rename, which I think is reasonable; the code change that uses it has just landed but not yet been QAed or deployed
[11:10] <cjwatson> wondering if there's any more elegant approach than backing out the code change, FDTing a rename, reapplying code with rename
[11:10] <gmb> jamestunnicliffe, Can you tell me how to get something to appear in the work items for a Person in Launchpad.dev so that I can test my  solution?
[11:10] <gmb> I just want to verify it before pinging it back to you.
[11:11] <jelmer> cjwatson: I guess you could just rename it in python and leave it as is in the db.
[11:11] <cjwatson> I could, not sure that would please bigjools though :)
[11:11] <cjwatson> seems like this is probably about the best opportunity to get the naming right, and there isn't a desperate rush to get this deployed
[11:12] <jelmer> cjwatson: On the other hand, it's marked low so it might be sensible to just leave the bug open until somebody touches this bit of the code again.
[11:12] <jelmer> cjwatson: and renaming the zope bit of it at least means we don't break API users in the future.
[11:13] <cjwatson> I guess I can ask bigjools what he thinks when he's next online.  That was easier before he inconsiderately moved. :-)
[11:13] <jelmer> :-)
[11:15] <cjwatson> I mostly don't want to do renaming work in one direction to find that it's insufficient and it would've been easier to back out
[11:15] <cjwatson> IYSWIM
[11:19] <jelmer> cjwatson: fair enough; indeed best to ask bigjools what he means though, the rest of us can only speculate :)
[11:19] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/packageset-score/+merge/105915 has the other half of his comments
[11:20] <cjwatson> jelmer: did you see my loc merge request above that you were asking about?
[11:21] <jelmer> cjwatson: yep, playing with the code atm
[12:06] <wallyworld_> cjwatson: branch scanning seems ok again
[12:13] <cjwatson> wallyworld_: oh good, thanks
[12:14] <wallyworld_> np
[12:17] <cjwatson> Can somebody set https://code.launchpad.net/~cjwatson/launchpad/db-pocket-permissions/+merge/106091
[12:17] <cjwatson> to Approved so I can land it?  Looks like it has sufficient review.
[12:18] <rick_h_> cjwatson: looking
[12:19] <rick_h_> cjwatson: can you set a commmit msg please?
[12:19] <cjwatson> Oh yes, done.  Thanks, I'll go ahead and land that now then
[12:19] <rick_h_> ok
[12:39] <danilos> gmb, did you manage to get workitems to show up on upcoming work page?
[12:40] <jamestunnicliffe> gmb: Apologies, had a few things to get done over lunch and just missed you. There is a script that didn't make it into trunk to create some users with outstanding work items that I can pastebin you if you want.
[12:41] <danilos> gmb, easiest is to create a blueprint, target it to a milestone (with target date set to a date in nearby future), and then add a few workitems in the workitem box on the BP page (eg. "[gmb] Sing the song of love: TODO")
[12:47] <jamestunnicliffe> gmb: Just tested your version - it works :-)
[12:50] <salgado> jamestunnicliffe, oh, I have a script like that... it does create loads of stuff, and using WI titles from production even
[12:50] <salgado> http://paste.ubuntu.com/992291/
[12:51] <jamestunnicliffe> salgado: Cool - that is more extensive than the one I have. Thanks!
[12:52] <salgado> np :)
[12:59] <wallyworld_> sinzui: hi, i'm about to go to bed but it appears there's a timeout issue submitting mps (i have one i was hoping for you to review). seems coincident with the postgres upgrade. could you ping someone for me to see what's up?
[13:02] <wgrant> wallyworld_: OOPS ID?
[13:02] <gmb> jamestunnicliffe: Okay, so, we need to find something to offset the change with. I'll be looking this afternoon and will try to get this into EC2 for you before my EoD.
[13:02] <wallyworld_> wgrant: no oops is shown, just a simple dialog
[13:02]  * gmb -> grabbing a late lunch; bbiab.
[13:03] <jamestunnicliffe> gmb: Don't worry about LOC. danilos is going to do a big delete soon.
[13:03] <gmb> jamestunnicliffe, danilos: How soon is "soon"? I'd like to be able to point lifeless at it when he asks me...
[13:04] <danilos> gmb, https://code.launchpad.net/~danilo/launchpad/kill-feedback-requests/+merge/106119
[13:04] <danilos> gmb, I'd be happy to get a review if that works for you :)
[13:04] <danilos> gmb, (i.e. to make it "sooner" :)
[13:13] <gmb> danilos: Then I'll take a look this afternoon :)
[13:13] <danilos> gmb, thanks
[13:15] <salgado> jamestunnicliffe, I just saw that https://launchpad.net/~linaro/+upcomingwork is broken.  maybe you guys know about it already...
[13:17] <jamestunnicliffe> salgado: no, that is new to me.
[13:20] <jamestunnicliffe> salgado: is there backtrace or other info available in a log somewhere that could help me recreate it? I see that the linaro team has no blueprints, but I would hope that condition is already covered by a test.
[13:22] <salgado> jamestunnicliffe, you'll have to ask somebody from the LP team for the backtrace. I don't have the rights to see it anymore
[13:23] <jamestunnicliffe> gmb: Can you get those logs ^^ or pass the request on?
[13:25] <gmb> jamestunnicliffe: There will be something soon; I'm waiting for the OOPS data to sync so I can look at it.
[13:25] <jamestunnicliffe> gmb: Thanks.
[13:30] <wgrant>     Module lp.registry.browser.person, line 4469, in initialize
[13:30] <wgrant>     100.0 * total_done / float(total_items))
[13:30] <wgrant> ZeroDivisionError: float division<br />
[13:30] <wgrant> jamestunnicliffe, salgado: ^^
[13:31] <jamestunnicliffe> wgrant: Thanks. Should be an easy fix!
[13:36] <wgrant> jelmer: Thanks.
[13:39] <jelmer> wgrant: anytime
[13:39] <jelmer> wgrant: how are reviews generally done these days, are there still on-call reviewers?
[13:40] <mgz> ...why is wgrant still awake?
[13:41] <wgrant> jelmer: Yeah, there's an OCR schedule. But it's a bit empty sometimes, since some squads are doing other things.
[13:41] <wgrant> mgz: It's not quite midnight :)
[13:41] <wgrant> jelmer: https://dev.launchpad.net/ReviewerSchedule
[13:41] <jelmer> wgrant: thanks; I'd seen it but was curious if it was still accurate
[13:42] <wgrant> It's meant to be.
[13:42] <jelmer> I guess I should find myself a new slot.
[13:42] <czajkowski> mgz: https://dev.launchpad.net/ReviewerSchedule
[13:42] <wgrant> And is vaguely.
[13:42] <wgrant> jelmer: You may wish to strike out Orange for now
[13:42]  * czajkowski and wgrant are in competition as to who can stay up the latest 
[13:45] <jelmer> I'll take Thurs/Europe
[13:46] <wgrant> Thanks :)
[14:06]  * jelmer heads out for belated lunch and to get a new headset
[14:06] <mgz> if you want to test it when you get back I brought mine into town :)
[14:31] <czajkowski> jcsackett: any idea how you add content to the download section of a project page ?
[14:34] <jcsackett> czajkowski: i *think* your project needs to have a release, and on the release page there should be an "add download" button. but that information may be outdated.
[14:34] <jcsackett> sinzui: can you confirm/correct that? ^
[14:34] <jelmer> mgz: feel like doing some headset testing?
[14:36] <mgz> mumblin' it up now
[14:37] <czajkowski> jcsackett: thanks
[14:42] <jcsackett> czajkowski: you're welcome. hope i'm right. :-P
[14:42] <popey> czajkowski / jcsackett ok, so how does one do the release bit?
[14:44] <czajkowski> jcsackett: I was trying to find out for popey for his project
[14:44] <jcsackett> czajkowski: dig. popey, what project?
[14:45] <popey> https://launchpad.net/ubuntu-online-tour
[14:47] <jcsackett> popey: what are you trying to put up for downloads? b/c at a guess you're not trying to put up a tarball package of your code.
[14:48] <popey> i am
[14:48] <popey> ubuntu-online-tour_0.11.tar.gz <- that :D
[14:48] <jcsackett> ah, fantastic.
[14:48] <jcsackett> then let's see if i can remember all of this right from the days of the registry team. :-)
[14:49] <gmb> jamestunnicliffe, salgado: https://pastebin.canonical.com/66273/
[14:49] <gmb> (that OOPs from earlier)
[14:49] <jamestunnicliffe> gmb: I don't have access to the pastebin, but I am working on it (bug #1000787)
[14:49] <_mup_> Bug #1000787: upcomingwork page fails when there are no work items <Launchpad itself:Confirmed for dooferlad> < https://launchpad.net/bugs/1000787 >
[14:50] <gmb> jamestunnicliffe: Ok, cool.
[14:50] <jamestunnicliffe> gmb: If the backtrace doesn't contain anything sensitive, perhaps post it as a comment on the bug?
[14:50] <popey> jcsackett: thanks! help is appreciated
[14:50] <gmb> jamestunnicliffe: Way ahead of you...
[14:51] <jamestunnicliffe> gmb :-)
[14:51]  * jelmer waves to allenap 
[14:52] <allenap> \o jelmer
[14:55] <jcsackett> popey: ok, so you can add a release on the series for your project, in your case https://launchpad.net/ubuntu-online-tour/trunk.
[14:56] <jcsackett> in the "Milestones and releases" section you'll see a "+ Create release" link. that will require you to make a milestone--since you're releasing a tarball for 0.11, that's a likely name for your milestone. the option to do that will appear in the form for creating a release.
[15:01] <jcsackett> popey, once you've created the release (and i think most of the information is optional for both it and the milestone) you will find the add download button on the release's page under the Download files for this release heading.
[15:03] <popey> yay!
[15:03] <popey> awesome, thanks!
[15:10] <jcsackett> popey: you're welcome. :-)
[15:36] <cjwatson> I can't see to do what Julian's asking for in bug 1000570.  I can see how to export a property on the webservice with a different name, but I think Julian's asking for LP-internal code also to refer to this variable as relative_build_score, and only the column to be called score.  Is that possible?  I can't seem to find an example.
[15:36] <_mup_> Bug #1000570: "Packageset.score" is badly named <tech-debt> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1000570 >
[15:54] <james_w> cjwatson, you can rename the attribute on the model and specify the column to use IIRC
[15:54] <james_w> just trying to remember an example in the codebase already
[15:55] <james_w> ah, set name="score" in the constructor
[15:56] <james_w> relative_build_score = Int(name="score")
[16:09] <cjwatson> james_w: oh, cool, thanks.  name= was hard to grep for, I actually tried and thought I didn't see anything
[16:09] <cjwatson> grepping for ' [A-Z][a-z]*(name=' finds examples though
[16:30] <cjwatson> OCR: could I have a review of https://code.launchpad.net/~cjwatson/launchpad/packageset-score/+merge/106220?
[16:37] <cjwatson> hmm, jelmer and jcsackett may not have "OCR" on highlight, I guess :-)
[16:38]  * cjwatson upgrades dogfood for some QA
[16:46] <barry> gary_poster: ping
[16:53] <gary_poster> barry, pong.
[16:54] <barry> gary_poster: hi.  you probably heard about our py3 plans for 12.10, right?  i'm starting down the long arduous road of porting launchpadlib to python 3.  first stop is lazr.restfulclient.  i just wanted to coordinate to make sure i'm not duplicating effort, and so that we can eventually get releases of py3 compatible libraries.
[16:54] <barry> gary_poster: i have a few questions for you, but want to first see if you have any questions for me :)
[16:56] <gary_poster> cool, barry, yeah.  Well, I'm not sure whom you need to coordinate with, but it is probably not me.  flacoste or lifeless are the obvious candidates.  I'm happy to try and help coordinate the coordination though ;-)
[16:57] <gary_poster> (since the squad rotation, my connection with lazr.* is not much more than anyone else's, and my visibility to things related to it and plans for it are much less)
[16:57] <barry> gary_poster: cool.  i'll work with flacoste and lifeless (already working with him on testtools and testresources, via jseutter).  quick question: just how married are y'all to buildout for libraries like lazr.restfulclient?
[16:59] <gary_poster> barry, um, no idea really.  another question for lifeless.  From my perspective as long as the approach specifies the version numbers for dependencies in a python friendly way (i.e., setup declares minimal dependencies and some other file specifies dependencies for shared testing, equivalent to buildbot versions, I'm happy enough.  I think pip has had something like that for years now.
[17:00] <gary_poster> mm, the parenthetical phrase was supposed to end after "equivalent to buildbot versions" :-P
[17:01] <barry> gary_poster: cool, thanks.  i'll try to chat with lifeless when he gets online
[17:01] <gary_poster> cool, thanks for the py3 work barry
[17:01] <barry> gary_poster: np!  i'm not volunteering to port launchpad just yet :)
[17:01] <gary_poster> heh, darn :-)
[17:04] <jamestunnicliffe> salgado: Having a problem with https://pastebin.canonical.com/66273/ is I can't recreate it in a test, or on a dev instance. In fact, I have looked through the code it calls and have no idea how total_items (and, I assume, total_done) are 0.
[17:04] <jamestunnicliffe> salgado: Any inspiration appreciated :-)
[17:07] <cjwatson> barry: it had occurred to me whether it might be worthwhile to do the obvious basic porting of Launchpad (print functions and the like) and get some good practices instilled early, even if a full port is a ways off
[17:07] <barry> cjwatson: certainly making it `python2.7 -3` compatible would be a great first step
[17:08] <cjwatson> IIRC maas has tooling to use the usual __future__ imports all over the shop
[17:09] <salgado> jamestunnicliffe, not really, can't think of anything.  but you could craft a script that just calls getWorkItemsDueBefore('~linaro', ...) and get somebody to run it against the staging DB
[17:10] <salgado> jamestunnicliffe, that would only work if you get the same OOPS on staging, though
[17:11] <jamestunnicliffe> salgado: Thanks - it is something to try at least!
[17:16] <jamestunnicliffe> salgado: https://staging.launchpad.net/~linaro/+upcomingwork - works on staging :-(
[17:56] <jcsackett> cjwatson: r=me your MP. if you could you add a commit message to it, i will try to get it out to land today.
[17:59] <cjwatson> jcsackett: I have landing access these days, so I can do that, although I generally need somebody in ~launchpad to set Status to Approved first
[18:00] <jcsackett> cjwatson: i can do that, didn't realize you had landing rights or i would have already done it. :-)
[18:00] <cjwatson> I've set a commit message, thanks
[18:00] <cjwatson> I'm the weirdo who's in set(PQM - ~launchpad)
[18:00] <jcsackett> cjwatson: that is peculiar. you're all set on the MP now.
[18:00] <cjwatson> Great, thanks
[19:37] <daker-cloud> hi i am looking for easy to fix bugs(html/css) anyone can pointe me?
[19:49] <daker-cloud> czajkowski: launchpad superwomen help :)
[21:18] <rick_h_> sinzui: did you fix history? /me looks up address for the "thank you beverage"
[21:18] <sinzui> I did fix it
[21:18] <rick_h_> that will be awesome
[21:18] <sinzui> msie has a deep bug: link.pathname is relative
[21:19] <sinzui> I wish Lp believed my branch has revisions in it to generate the diff
[21:20] <rick_h_> bah, I hate it when adding a simple thing requires adding complex tests
[21:21] <sinzui> The tests were easy actually. Most of my time as in a debugger in chromium and msie to locate the point they diverge
[21:22] <rick_h_> sorry, talking about this small add to lazr.restfulclient. My issue isn't in a current set of tests so hav to add a bunch of crap
[21:22] <rick_h_> waiting for your diff to load on this one so I can peek at the changes, curious how it ended up working out
[21:24] <sinzui> rick_h_, I think I am going to repush the branch to a new location...overwrite said nothing needed to be pushed
[21:24] <sinzui> rick_h_, http://pastebin.ubuntu.com/993138/
[21:24] <rick_h_> sinzui: doh, sucky
[21:24] <rick_h_> thanks for the link, I'll peek at it tonight.
[21:32] <sinzui> jcsackett, do you have a few minutes to review https://code.launchpad.net/~sinzui/launchpad/bug-listings-urls/+merge/106266
[21:39] <barry> lifeless: ping
[21:39] <lifeless> barry: otp
[21:40] <barry> lifeless: cool.  just ping me when you're free (if in the next hour)
[21:40] <lifeless> kk
[22:13] <sinzui> ian is this a start? https://code.launchpad.net/~wallyworld/launchpad/subscribe-grants-access/+merge/106277
[22:25] <jelmer> are code import failures generally considered critical?
[22:25] <jelmer> generally that doesn't seem to be the case, but bug 932463 is
[22:25] <_mup_> Bug #932463: CVS code import failing <canonical-losa-lp> <code-import> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/932463 >
[22:54] <lifeless> barry: hi
[22:54] <lifeless> barry: I'm Off the phone
[22:54] <barry> lifeless: haha!  i just sent you an email :)
[22:54] <lifeless> jelmer: import failures per se - no; a regression in imports yes.
[22:55] <barry> literally 5 seconds before you pinged me
[22:55] <lifeless> so short answer
[22:55] <lifeless> no resources
[22:55] <lifeless> the team can and will review
[22:55] <lifeless> we need to keep python 2 compat for the next 5 years.
[22:56] <jelmer> lifeless: thanks
[22:56] <barry> lifeless: python 2.6 minimal at least?
[22:57] <lifeless> 2.6.5 (lucid) through to 2015
[22:57] <lifeless> 2017 for python 2.7
[22:57] <barry> that's fine.  nothing < 2.6 makes life much easier
[22:57] <lifeless> (basically we need to be able to do SRU's or fixes for support Ubuntu releases)
[22:58] <lifeless> if we fork into a 2 and a 3 branch that becomes harder
[22:58] <lifeless> but it may be cheaper overall; its hard to tell
[22:58] <barry> yep.  i'm not planning on dropping python 2 support.  i think we can support both with a single code base
[22:58] <jelmer> lifeless: where regression is an actual regression in the code I assume, not a code import that used to succeed but now happens to trigger a particular bug?
[22:58] <lifeless> much of our stack isn't packaged and has little reason to be
[22:59] <barry> lifeless: i only care about the parts of that stack that end up on the desktop cd images.  launchpadlib is the tip of the iceberg for that.
[22:59] <lifeless> jelmer: right, so if import A suddenly has submodules added and fails, its not a regression. If extended file modes stops working its a regression.
[22:59] <jelmer> lifeless: fair 'nough
[23:00] <barry> lifeless: of course, what makes things trickier is trying to run the test suite under python 3 also.  that usually triggers a port of all the test dependencies.  i'm personally not comfortable testing only on py2, but it does increase the porting effort.
[23:00] <lifeless> barry: yah. It would be nice if python packaging were more robust and safer to use on live systems ;)
[23:00] <barry> lifeless: and buildout/pypi is better? :)
[23:00] <lifeless> barry: hugely so
[23:01] <lifeless> barry: and its an upstream root cause :)
[23:01]  * barry sighs
[23:02] <barry> lifeless: testtools and testresources, any eta on py3 compatible releases?
[23:02] <jelmer> barry: testtools has a py3 compatible release that is packaged
[23:02] <lifeless> barry: I got busy this week, haven't gotten to the reviews.
[23:02] <lifeless> barry: other than noting the various issues and bugs :)
[23:03] <jelmer> barry: it looks like python-testtools mostly just needs a sync from Debian (it's got a custom version in Ubuntu without py3 support)
[23:03] <lifeless> barry: a note for LP things as well - please don't drop huge boilerplate in the projects; what we have is terrible enough :)
[23:03] <barry> jelmer: hmm, i guess jseutter's branch isn't strictly necessary then
[23:04] <barry> jelmer: oh, that's easy then
[23:04]  * barry can do that
[23:04] <barry> lifeless: right.  some of the packages use ez_setup.  in those cases we need to switch to distribute (or drop ez_setup).  if it doesn't use it, i won't add it
[23:05] <lifeless> cool
[23:05] <lifeless> I loath the use of ez_setup too, FWIW.
[23:05] <barry> me too
[23:05] <lifeless> LP's actual needed thing is for buildout to work.
[23:05]  * barry nods
[23:05] <lifeless> beyond that, we don't care, if you can nuke ez_setup at the same time (while retaining compat with lucid for deploys) \o/
[23:06] <lifeless> For now though, we need buildout to work on lucid precise and quantal
[23:06] <barry> fun
[23:06] <lifeless> with python 2.6.5 on lucid and 2.7.x on precise and up
[23:07] <lifeless> once we have pg9.1 behind LP, the next step is python 2.7 everywhere using the PPA for lucid
[23:07] <lifeless> we'll still need 2.6.5 compat for client libraries
[23:07] <barry> lifeless: oh, i sure hope that'll work :)
[23:08] <lifeless> barry: so do we :)
[23:09] <barry> lifeless: okay, thanks.  if there's anything else you can tell me in response to my email, that would be great.  otherwise, i'll just keep pinging you as mps stack up :)
[23:09] <lifeless> barry: hah
[23:09] <lifeless> :)
[23:10] <barry> lifeless: if you get blocked, ping me.  either i can help, or i can find other folks to chip in too.  foundations team is probably going to sprint on py3 mid-june-ish
[23:11] <lifeless> will do
[23:11] <czajkowski> daker-cloud: whats up
[23:11] <barry> thanks!
[23:12] <daker-cloud> czajkowski: i am looking for easy to fix bugs(html/css) can you pointe me to someone who can help ?
[23:13] <czajkowski> daker-cloud: um lemmie see
[23:13] <czajkowski> lifeless: any thoughts?
[23:15] <czajkowski> daker-cloud: https://bugs.launchpad.net/launchpad/+bugs?search=Search&field.tag=trivial  all those bugs are tagged trivial
[23:15] <czajkowski> perhaps there is one in there
[23:16] <daker-cloud> means those shouldn't be fixed, right ?
[23:16] <barry> jelmer: i'm going to do a sync from sid->quantal of python-testtools 0.9.14-2 which will give us py3 support.  i don't think there's anything to keep from the 0.9.14-0ubuntu1 version
[23:17] <czajkowski> daker-cloud: no they should
[23:17] <jelmer> barry: me neither - and thanks!
[23:17] <barry> jelmer: np!
[23:17] <daker-cloud> czajkowski: ah ok ok
[23:17] <StevenK> jelmer: Did you want to land cjwatson's lp-dev-utils MP?
[23:18] <jelmer> barry: can you perhaps sync subunit too while you're at it?
[23:18] <jelmer> StevenK: sorry, yes.. hadn't gotten round to that yet
[23:18] <barry> jelmer: sure, let me look
[23:19] <daker-cloud> czajkowski: thanks :)
[23:20] <czajkowski> daker-cloud: https://bugs.launchpad.net/launchpad/+bugs?field.tag=easy also that one as well
[23:20] <wallyworld_> StevenK: does any of your current work update BranchCollection to use information_type rather than private?
[23:20] <StevenK> wallyworld_: BranchCollection? Nope.
[23:20] <wallyworld_> StevenK: ok. i'll raise a separate bug for that
[23:21] <wallyworld_> i have some XXX in some tests which i'll link to that new bug
[23:21] <czajkowski> daker-cloud: if I'm not around do prod people in here they don't bite and will help you if they can ok
[23:21] <wallyworld_> czajkowski: wgrant bites sometimes if he is hungry
[23:21] <czajkowski> wallyworld_: I now owe him about 4 buckets worth of bickies!
[23:22] <wallyworld_> if we keep him well fed we are all better off
[23:22] <barry> jelmer: hahahah!  subunit's already been sync'd but it's in depwait on python3-testtools :)  that should all get unjammed when the testtools sync is processed
[23:22] <barry> jelmer: i'll keep an eye on it tho
[23:22] <czajkowski> wallyworld_: I do wonder if we fed him red bull and sugary sweets what would happen
[23:23] <wallyworld_> czajkowski: i can tell you're not american or else it would have been cookies. actually he can legally drink now so maybe a 6 pack of beer instead
[23:23] <jelmer> barry: ah, neat :) I didn't realize the automatic sync mechanism knew what 0build1 was for
[23:23] <jelmer> barry: and thanks
[23:23] <lifeless> jelmer: speaking of subunit
[23:23] <lifeless> jelmer: daily build breakage :)
[23:23] <wallyworld_> czajkowski: nooo. he would never sleep at all if he had red bull
[23:23] <barry> jelmer: yep, *build*'s are ignored as deltas by the autosync
[23:23] <daker-cloud> czajkowski: ok ok :)
[23:24] <lifeless> czajkowski: trivial is indeed a good place to start
[23:24] <czajkowski> wallyworld_: nope I'm Irish :)
[23:24] <wallyworld_> awesome. i love ireland
[23:25] <czajkowski> it rains. it's green. it rains :)
[23:25] <jelmer> lifeless: whoops, thanks for the reminder
[23:25] <jelmer> lifeless: I'll have a look this week
[23:31] <StevenK> wgrant: http://pastebin.ubuntu.com/993320/ Was that what you envisioned?
[23:32] <wgrant> StevenK: That sort of configuration, but I'm not sure what to do about branch D
[23:34] <bigjools> czajkowski: you forgot the Guinness bit
[23:35] <czajkowski> heh
[23:37] <StevenK> wgrant: Currently the test fails because D remains EMBARGOEDSECURITY.
[23:38] <StevenK> wgrant: But we all agree that EMBARGOEDSECURITY stacked on top of USERDATA makes no sense.
[23:39] <wgrant> StevenK: Right, the question is what does make sense?
[23:39] <StevenK> wgrant: Forcing all of them to USERDATA?
[23:41] <wgrant> That could disclose them inappropriately.
[23:42] <StevenK> wgrant: Note that B does exactly that as it stands.
[23:43] <wgrant> This is true.
[23:44] <rick_h_> wallyworld_: thanks for the quick review
[23:44] <wallyworld_> rick_h_: np. btw, the combo stuff on lp.net rocks. seems so much faster
[23:44] <rick_h_> wallyworld_: awesome! glad to hear it.
[23:45] <rick_h_> lots that could be done to be made better, but hopefully good start.
[23:45] <wallyworld_> rick_h_: so what's the timeframe for the additional optimisations?
[23:45] <rick_h_> don't forget to run the combo loader in dev and check out the jsbuild_watch script as well
[23:45] <rick_h_> wallyworld_: atm no idea since I'm off on something else for the next little bit
[23:45] <wallyworld_> rick_h_: yeah, on my todo list.
[23:45] <rick_h_> just working on bug fixes for the combo loader as they come up
[23:46] <wallyworld_> rick_h_: perhaps a reminder post to dev list about how to run combo loader etc locally is warranted. just to prod everyone to do it
[23:46] <rick_h_> yea, I tried to get jcsackett using it and even I forgot how to use it right.
[23:46] <rick_h_> so probably a good idea to email again
[23:47] <wallyworld_> rick_h_: it would be nice if you were allowed a bit of slack time to finish it all off 100% since otherwise it will not get done despiet best intentions
[23:47] <rick_h_> I should look to see if there's a good way to get the combo loader defaulted to on in dev mode actually, in the dev db data I guess it'd be
[23:47] <rick_h_> wallyworld_: yea, I know it. Had hoped to have some of that during maint, but got some higher priority proddings on other things
[23:47] <wallyworld_> rick_h_: yes, you need to add the flag and regenerate sample data and commit
[23:48] <wallyworld_> rick_h_: i do think we need to dogfood this so if you send the email, i can do the flag if you like
[23:48] <StevenK> wgrant: Do you think D -> USERDATA is okay and then I can land this thing?
[23:49] <rick_h_> wallyworld_: ok, will do. Working on closing up some work here at the moment and I'll do the email before I hit bed tonight
[23:49] <wallyworld_> rick_h_: ok, no hurry. next SOD is fine :-)
[23:49] <wgrant> StevenK: I don't think so.
[23:49] <rick_h_> wallyworld_: appreciate the assist with the flag bit, I think that'd help a ton.
[23:49] <wgrant> StevenK: But it may be,.
[23:49] <rick_h_> wallyworld_: heh don't worry about it, working late to get stuff done so I can go away this weekend. rush rush
[23:49] <wallyworld_> rick_h_: np, pleased to help. i'm just happy to have this all being used now. bring on yuii 3.5 i say
[23:49] <rick_h_> hah! now that would be freaking awesome
[23:50] <rick_h_> <3 3.5
[23:50] <StevenK> And then the death of YUI 2
[23:50] <rick_h_> yep, the calendar widget in 3.5 is shaping up nicely I believe
[23:50] <wallyworld_> rick_h_: otp, talk later
[23:50] <rick_h_> rgr
[23:53] <rick_h_> anyone have permissions to pypi for lazr.restfulclient ?
[23:53] <StevenK> I think wallyworld_ may.
[23:53] <rick_h_> k, I'll bug him on it later, thanks
[23:57] <wallyworld_> rick_h_: what's your pypi user name?
[23:58] <rick_h_> wallyworld_: mitechie
[23:58] <wallyworld_> rick_h_: you now owner, have fun
[23:59] <rick_h_> wallyworld_: ty much sir