[00:23] <lifeless> thanks python 2.7
[00:23] <lifeless> String or Integer object expected for key, unicode found
[00:27] <wgrant> What for?
[00:27] <wgrant> Some fake dict?
[00:27] <lifeless> DBM
[00:28] <lifeless> https://bugs.launchpad.net/testrepository/+bug/775214
[00:28] <_mup_> Bug #775214: On python 2.7: String or Integer object expected for key, unicode found <Testrepository:New> < https://launchpad.net/bugs/775214 >
[00:29] <wgrant> Ah :(
[00:35] <lifeless> wgrant: the fun of it is it that one can expect python 3.x to be diametrically opposed
[00:35] <wgrant> lifeless: Surely 3.x expects bytes/int?
[00:37] <wgrant> (if not I may cry)
[00:49] <lifeless> wgrant: for a dict interface?
[00:49] <lifeless> wgrant: I haven't started a 3.x port of testrepository yet.
[00:49] <wgrant> lifeless: Yes.
[00:49] <lifeless> I may tonight or something; right now am just yak shaving my way back up to a working desktop
[00:49] <wgrant> Since Unicode makes very little sense in DBM, surely...
[00:50] <lifeless> wgrant: no less than it does in the sql interface postgresql uses
[00:50] <wgrant> lifeless: Hm? postgresql does Unicode...
[00:51] <lifeless> wgrant: yes
[00:52] <lifeless> dbm doesn't do collation
[00:52] <lifeless> so implementing unicode for a user is simply encode on the way in, decode on the way out.
[00:52] <lifeless> no good reason not to support that
[00:52] <wgrant> Mmm
[00:56] <lifeless> the only reason not to that I can think of is that its slow
[00:56] <lifeless> but thats python's choice of string model more than anything else
[02:34] <wgrant> lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=1944DQ278
[02:35] <wgrant> Heat updates are expensive.
[02:35] <wgrant> (although this seems like a particularly inefficient way to do it)
[02:35] <StevenK> There was a change for that in the deployment report I noticed
[02:36] <wgrant> Yeah, but different.
[02:36] <StevenK> Of course it is. :-)
[02:43] <lifeless> wgrant: https://lp-oops.canonical.com/oops.py/?oopsid=1944DQ278#repeatedstatements should be helped by abels change?
[02:44] <wgrant> lifeless: I thought that looked specific to Bug.markAsDuplicate.
[02:47] <lifeless> wgrant: I only read the cover letter
[02:47] <lifeless> so it may need an equivalent change
[02:49] <wgrant> lifeless: Except this is somewhat deeper :(
[03:47] <wgrant> lifeless: How well do you know Storm's codebase?
[03:49] <wgrant> I am considering digging around to see why inherited References don't have the correct class, while normal properties do.
[03:49] <wgrant> But the descriptor/metaclass stuff is not entirely clear.
[03:57] <lifeless> I can generally find what I am looking for
[03:57] <lifeless> not far enough along to have a sense of how to tackle things tastefully
[03:57] <wgrant> Ah.
[03:57] <wgrant> k
[03:57] <lifeless> so you have a reference on class A
[03:58] <lifeless> and a concrete class B
[03:58] <wgrant> Yes.
[03:58] <lifeless> and the reference cls handle when you access B.reference is A
[03:58] <wgrant> The Property descriptor handles that nicely.  But Reference does not.
[03:58] <lifeless> or
[03:59] <lifeless> is it that you have a reference into the class hierarchy ?
[03:59] <wgrant> PackageBuild.archive is inherited by BinaryPackageBuild.archive.
[03:59] <wgrant> 'BinaryPackageBuild.archive == foo' creates a query for PackageBuild instead.
[04:00] <wgrant> BinaryPackageBuild.archive_id == foo works fine.
[04:00] <wgrant> Because the descriptor recreates the column.
[04:00] <wgrant> With the correct class.
[04:01] <lifeless> now
[04:01] <lifeless> this is with sqlobject sugar right
[04:01] <lifeless> ?
[04:01] <wgrant> No.
[04:02] <wgrant> Raw Storm.
[04:02] <lifeless> PropertyPublisherMeta looks interesting
[04:02] <wgrant> Well. BinaryPackageBuild is SQLBase, but PackageBuild and SourcePackageRecipeBuild are native.
[04:03] <wgrant> And I tested it with native non-LP Storm.
[04:03] <lifeless> PropertyRegistry
[04:03] <wgrant> Mm, it's not that interesting.
[04:03] <wgrant> I think that's mostly for string property lookups.
[04:04] <wgrant> Yes.
[04:04] <wgrant> class PropertyRegistry(object): """ An object which remembers the Storm properties specified on classes, and is able to translate names to these properties. """
[04:04] <wgrant> So not relevant here.
[04:04] <wgrant> It's just the descriptors.
[04:04] <wgrant> lifeless: Compare Property.__get__ and Reference.__get__
[04:05] <wgrant> Property uses _get_column, which creates a new PropertyColumn based on the right class. Reference just returns self.
[04:05] <wgrant> (where obj is None, obviously)
[04:09] <lifeless> yes
[04:14] <LPCIBot> Project windmill build #227: STILL FAILING in 1 hr 3 min: https://lpci.wedontsleep.org/job/windmill/227/
[04:19] <wgrant> lifeless: So, BuildFarmJobSet.getBuildsForBuilder
[04:19] <wgrant> This method is The One.
[04:20] <lifeless> wgrant: you have a fix for storm ?
[04:20] <wgrant> Did you envision any particular solution to it?
[04:20] <wgrant> No, I just worked around it by using _id.
[04:20] <lifeless> wgrant: what file is that in ?
[04:20] <lifeless> wgrant: did you file a bug ?
[04:20] <wgrant> lib/lp/buildmaster/model/buildfarmjob.py
[04:20] <wgrant> I didn't.
[04:20] <lifeless> wgrant: please file one
[04:21] <wgrant> I will. I spent most of Friday afternoon dealing with this so was pretty displeased by the end, so didn't end up filing a bug.
[04:22] <wgrant> Bug #682989 is probably the same thing.
[04:22] <wgrant> Or rather similar.
[04:26] <lifeless> wgrant: so that query
[04:26] <lifeless> wgrant: one option is to union
[04:26] <wgrant> That's what I was thinking.
[04:26] <wgrant> But the sort may be slow.
[04:27] <wgrant> I was going to half-perform the migration in a transaction on DF and see what happens.
[04:27] <wgrant> But populating BPB takes forever.
[04:29] <wgrant> lifeless: Although I guess key-based offsets with a union could be done rather cheaply.
[04:29] <wgrant> s/rather/very/
[04:31] <lifeless> yes
[04:32] <lifeless> the key question is whether sql will sensibly do partial iteration on each input
[04:32] <lifeless> UNION ALL should let it do this
[04:32] <lifeless> I'm looking at uses
[04:32] <lifeless> builder.getBuildRecords is one
[04:32] <lifeless> its binary_only flag will permit a single-table lookup
[04:34] <wgrant> I believe that should be the only user.
[04:35] <lifeless> looks like it
[04:35] <lifeless> sadly getBuildRecords is used as a name for other things
[04:35] <wgrant> Yes.
[04:36] <wgrant> It's on like 5 or 6 other classes.
[04:36] <lifeless> I don't think its sensible to report back to the start of time on builders
[04:36] <wgrant> It's not essential, no.
[04:37] <wgrant> I'd considered adding a threshold if the sort was too slow.
[04:37] <wgrant> But it may not be.
[04:37] <lifeless> If we consider dynamic provisioning of builders
[04:37] <lifeless> it becomes actively undesirable
[04:41] <lifeless> hmm, no wallyworld today
[04:41] <wgrant> This week.
[04:41] <wgrant> Or next.
[04:41] <wgrant> He's in Budapest.
[04:41] <lifeless> oh right
[04:45] <lifeless> anyone know how to land stuff on oops-tools ?
[04:48] <wgrant> pqm-submit?
[05:58] <lifeless> grrr
[05:58] <lifeless> PATCH -> no idea what was changed
[05:58] <wgrant> Oh?
[05:58] <lifeless> in oops-tools
[06:02]  * wgrant vomits a bit.
[06:02] <wgrant> The old bug subscription is awful :/
[06:02] <wgrant> Not obvious how to fix without reverting and deconflicting.
[06:03] <wgrant> The old bug subscription *JS* is awful, that is.
[06:03] <wgrant>     // Determine if this is a dupe.
[06:03] <wgrant>     var is_dupe;
[06:03] <wgrant>     var icon_parent_div = icon_parent.get('parentNode');
[06:03] <wgrant>     var dupe_id = 'dupe-' + person.get('css_name');
[06:03] <wgrant>     if (icon_parent_div.get('id') [06:03] <wgrant>         is_dupe = true;
[06:03] <StevenK> LPCIBot: I'm also not sure about the recent Jenkins picture change
[06:03] <wgrant>     } else {
[06:03] <StevenK> Doh
[06:03] <wgrant>         is_dupe = false;
[06:03] <StevenK> lifeless: ^
[06:03] <wgrant>     }
[06:03] <lifeless> StevenK: the new logo?
[06:03] <wgrant> Ignoring the whole if (foo) bar = true; else bar = false; thing, that's still a bit bad.
[06:03] <StevenK> lifeless: Yah
[06:04] <lifeless> I like it
[06:04] <StevenK> The old one was mostly one colour, this is ... too red
[06:04] <wgrant> StevenK: Agreed.
[06:05] <StevenK> And French, rather than British. :-P
[06:05] <wgrant> lifeless: I don't think this needs reversion.
[06:06] <wgrant> Its only effect is minor.
[06:06] <wgrant> Everything else is still fine.
[06:06] <wgrant> And it doesn't revert cleanly.
[06:06] <wgrant> Although that's fixable...
[06:06] <lifeless> are you familiar with curtis question work?
[06:06] <lifeless> the last remaining qa item
[06:07] <wgrant> untestable, I believe, but let me check.
[06:07] <StevenK> Oh dear. The last 55 windmill builds on Jenkins have failed.
[06:07] <wgrant> StevenK: Yes, there is that one test which fails only in Windmill :(
[06:08] <wgrant> lifeless: It is unused, but there are QA instructions in the bug. I will grab spm.
[06:43] <jtv> wgrant: thanks for checking out the latest generate-contents-files... did it all work then?
[06:44] <wgrant> jtv: Yup!
[06:44] <wgrant> All looks good.
[06:45] <jtv> What a relief.
[06:47] <jtv> wgrant: maybe we should just schedule that bugger then
[06:47] <jtv> ah no, downtime
[06:51] <jtv> :(
[06:51] <wgrant> Ja.
[06:52] <jtv> Hmm that means about the same thing in all 3 Indo-European languages I can think of that have that word, so I get your drift.
[06:53] <jtv> In Spanish, however, it could be interpreted as you laughing at me which would be less than kind.
[07:00] <wgrant> :(
[07:01] <jtv> By the way, wgrant, isn't this a holiday for you?
[07:01] <jtv> Grrr this edge connection isn't very suitable for actual work.  Lightning seems to have fried my dsl modem because I was too lazy or worried about signal quality to loop the phone line through the UPS.  I'll try once more and if not successful, get a new one.
[07:02] <wgrant> jtv: No, not a holiday here.
[07:02] <wgrant> Should it be?
[07:02] <jtv> Labour Day.
[07:02] <wgrant> In the UK, maybe.
[07:02] <wgrant> Ours was in March.
[07:02] <wgrant> NSW's is in October.
[07:03] <wgrant> QLD is today, though.
[07:03] <jtv> Here, certainly.  The reasoning seems to be that there must be a day without labour specifically for the occasion of labour day, and just having the day off because it's Sunday isn't enough.
[07:04] <StevenK> It's "May Day" in the UK, isn't it?
[07:04] <jtv> Quite possibly.
[07:05] <StevenK> Northern Terrority also have a 'May Day' public holiday.
[07:05] <jtv> May Day is when pilots stop working and just let their planes drop to the ground, right?
[07:05] <wgrant> NT doesn't exist.
[07:07] <StevenK> wgrant: Wha?
[07:08] <jtv> This could be bad news for any inhabitants the NT may have.
[07:09] <jtv> Meanwhile, how can it be a national holiday for Graham and Julian but not for Gavin?
[07:09] <wgrant> It has a population of like 200000. It doesn't exist.
[07:09] <wgrant> jtv: Swap day?
[07:09] <wgrant> Maybe.
[07:09] <LPCIBot> Project windmill-devel build #1: FAILURE in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-devel/1/
[07:09] <jtv> wgrant: no, the list I'm looking at would still show a national holiday.
[07:10] <StevenK> wgrant: By your reckoning, the small towns dotted around Australia don't exist either.
[07:10] <wgrant> Perhaps he just forgot.
[07:10] <wgrant> StevenK: They're not a whole semi-state.
[07:10] <StevenK> It's a terriority!
[07:10] <wgrant> Right, it's like a state except more pathetic.
[07:11] <StevenK> We should be trying to emulate them! They have less politicans.
[07:11] <wgrant> True, true.
[07:14] <StevenK> And windmill-devel failed, surprise.
[08:10] <jtv> StevenK: I'm looking into the "synchronize updates" button for the packages diff page.  Do we have code landed to synchronize a package?
[08:11] <StevenK> The code has existed for ... eons
[08:12] <spm> Æons?
[08:13] <lifeless> night all;
[08:14] <jtv> StevenK: damn, connection bounced again... where does this code live?
[08:14] <LPCIBot> Project windmill-db-devel build #228: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/228/
[08:15]  * jtv traces through the call chain
[08:16] <StevenK> jtv: I'm not what the button calls, but likely IArchive.syncSources()
[08:16] <jtv> Ah, I thought that was a recent development.  Thanks.
[08:42] <stub> What review type is for a release critical? rc or release-critical or what?
[08:43] <StevenK> release-critical
[08:43] <StevenK> I think
[08:46] <stub> https://code.launchpad.net/~stub/launchpad/pending-db-changes/+merge/59640 if the RM is in the house. I'm out of here to enjoy this holiday :)
[08:49] <StevenK> Hm. We don't have RMs anymore?
[08:49] <wgrant> lifeless is the perma-RM.
[08:52] <StevenK> Heh
[08:52] <adeuring> good morning
[08:57] <rvba> Hi wgrant. If you get a chance, would you take a look at https://code.launchpad.net/~rvb/launchpad/change-perm-sync/+merge/59341 ? I've modified the packages copier method carefully but since the modification is rather sensitive, I'd be happy if you could take a look at this. You will see that I've solved the problem about passing a None person to the copier method by avoiding this case with code in the view code. Please also take a l
[08:57] <rvba> ook at adeuring's remark in the MP's comments.
[09:03] <wgrant> rvba: Looking.
[09:03] <rvba> wgrant: great, thank you.
[09:05] <wgrant> 405	+        :param strict_component: True if access to the specific component for
[09:05] <wgrant> 406	+            the package is needed to upload to it. If False, then access to
[09:06] <wgrant> 407	+            any package will do.
[09:06] <wgrant> Access to any *component* will do.
[09:06] <rvba> wgrant: right ... so I'll have to change the doc in the other method as well (where it came from)
[09:06] <wgrant> Ah. Indeed.
[09:07] <wgrant> rvba: Hmm, so anonymous users are prevented from doing everything by line 19 of the diff?
[09:08] <rvba> wgrant: yes, this protects the call to sync_source.
[09:09] <wgrant> rvba: That's a bit riskier than I'd like :/
[09:09] <rvba> wgrant: yeah, I confess I'm not really happy with that either.
[09:09] <wgrant> rvba: Could you make checkCopy take a check_permissions arg in addition to the person?
[09:09] <rvba> and set this to False by default?
[09:10] <wgrant> No, True. But having check_permissions=True and person=None will forbid the copy.
[09:11] <wgrant> You will have to change the existing callsites to use check_permissions=False, but then at least the dangerous action is explicit.
[09:11] <wgrant> And this is the very definition of dangerous action.
[09:11] <rvba> ok, I've done it this way to avoid having to change the call sites ... but your solution is bar better ...
[09:12] <wgrant> If there is one security hole we don't want in Launchpad, it's probably in this method.
[09:13] <rvba> all right. I'll do this.
[09:13] <wgrant> Thanks.
[09:13] <rvba> wgrant: Thank _you_ ;)
[09:56] <MonkZ> hi together, I want to setup a intranet launchpad is there a howto? with public/private projects, account management etc
[10:15] <henninge> MonkZ1: I am not aware of such a howto. It certainly is not supported "out of the box" but will require some work.
[10:16] <henninge> MonkZ1: I know that others have done it but I don't know how sucessful they were.
[10:19] <MonkZ1> henninge: there is no need for "out of the box" (mach ich gern). just need a light guideline
[10:21] <henninge> MonkZ1: I am not aware of anthing like that, at least not on offcial LP pages.
[10:23] <MonkZ1> henninge: ok thanks
[10:30] <MonkZ1> henninge: the "private project"-feature is free available?
[10:30] <henninge> MonkZ1: AFAIK we have private bugs, private branches and private teams.
[10:30] <MonkZ1> henninge: ok nice
[10:31] <henninge> MonkZ1: these are available to commercial subscriptions.
[10:31] <MonkZ1> :(
[10:32] <henninge> MonkZ1: https://launchpad.net/+tour/join-launchpad#commercial
[10:33] <MonkZ1> henninge: so i need to subscribe to get the possibility of a private * in a intranet environment on a selfhosted launchpad?
[10:33] <henninge> MonkZ1: no
[10:33] <henninge> MonkZ1: sorry, misunderstood you
[10:34] <henninge> MonkZ1: you can use your own instance as you like it.
[10:34] <henninge> MonkZ1: you get the exact same source tree that Launchpad.net is using.
[10:34] <henninge> MonkZ1: so all these features are available.
[10:34] <MonkZ1> henninge: aaah k this was the bit i need
[10:35] <MonkZ1> henninge: thx
[10:35] <henninge> bitte schön ;)
[10:35] <MonkZ1> henninge: ach dann hätten wir auch auch deutsch quatschen können ;)
[10:36] <MonkZ1> bye
[10:40] <henninge> MonkZ1: no, this is an English language channel ... :-P
[10:40] <henninge> Tschüß
[11:59] <wgrant> jtv: So ArchiveDependency would have a series at both ends?
[12:17] <jtv> wgrant: hadn't thought of that--it'd be a bit of a misnomer then wouldn't it?
[12:17] <jtv> Then again, with component & pocket already in there...
[12:18] <wgrant> jtv: You propose it has at least one series, though?
[12:18] <wgrant> And if there is one there must surely be two.
[12:19] <jtv> Then yes.
[12:19] <wgrant> Otherwise how would it work?
[12:19] <wgrant> ArchiveDependency on Ubuntu Natty... for which series?
[12:20] <jtv> Yes, I see that now.
[12:20] <wgrant> Great.
[12:20] <wgrant> Then I mostly agree with your idea of merging them.
[12:21] <jtv> Phew.  I thought that was going to be a stumbling block.  :)
[12:21] <wgrant> I haven't run through all the cases yet, but it seems like it should work...
[12:29] <jtv> wgrant: the operative question remains of course: would it make our lives any better?  There's probably enough flexibility in that schema to cause us a few headaches.
[12:31] <wgrant> jtv: I'm not sure it adds significant complication.
[12:31] <wgrant> It mostly makes things simpler.
[12:31] <wgrant> And a little less inflexible.
[12:31] <jtv> Very, very relieved to hear that.
[12:32] <jtv> Apart from the fact that it'd take actual work to implement, of course.
[12:33] <wgrant> I'm trying to think how the implicit primary archive dependency would work.
[12:33] <wgrant> I guess it would be implicit per-series.
[12:33] <jtv> What are the problems with making it explicit?
[12:33] <wgrant> ie. if there's not an explicit one for that series and the primary archive.
[12:34] <wgrant> Well, maintaining that automatically is difficult.
[12:34] <wgrant> Added a new series to Ubuntu? Need to add 20000 new ArchiveDependency rows.
[12:35] <jtv> That is rather a lot, yes.  What are all those archives?
[12:35] <wgrant> PPAs.
[12:35] <wgrant> Lots of PPAs.
[12:37] <jtv> Part of the idea though is that for the general case, an archive dependency doesn't _have_ to be restricted to a series.
[12:37] <jtv> That's where the headaches come from.
[12:37] <wgrant> Right.
[12:37] <jtv> But it might just help avoid that per-series cost.
[12:39] <wgrant> My original proposal or yours will both work fine. Yours is probably a bit cleaner. But maybe more expensive.
[12:39] <wgrant> But...; ArchiveDependency.component and ArchiveDependency.pocket really need to be series-specific anyway.
[12:39] <wgrant> So we might as well merge AD and DSP and solve everything.
[12:45] <jtv> henninge: saw the request to open Oneiric translations?  I'm on feature rotation and rather busy... are you on maintenance by any chance?
[12:45] <wgrant> Where does that go? And what's involved?
[12:45] <StevenK> wgrant: I'd suggest you reply to jtv's mail with how to merge AD and DSP?
[12:46] <wgrant> StevenK: I need to think about it.
[12:46] <wgrant> The trivial solution is sort of obvious.
[12:46] <wgrant> But it's not clear that it's perfect.
[12:47] <jtv> wgrant: you're asking about the translations opening?  It's a matter of running a script, much like init-from-parent, and it should be automated similarly.
[12:47] <StevenK> wgrant: My thought was DSP at *least* needed to grow pocket
[12:47] <wgrant> StevenK: Yes.
[12:47] <wgrant> StevenK: Julian disagrees.
[12:47] <StevenK> Or we create a Series table that maps all this crap
[12:47] <wgrant> But he's not here today, so stuff him :)
[12:47] <wgrant> jtv: Right.
[12:47] <wgrant> jtv: It's fairly cheap nowadays with sharing and stuff?
[12:48] <jtv> y
[12:48] <wgrant> jtv: Which list/address was notified?
[12:49] <StevenK> wgrant: Okay, will you at least agree to replying with "Oh, here's this trivial solution I thought of."
[12:49] <jtv> wgrant: the former translations team still has a mail alias
[12:49] <wgrant> StevenK: Add two series fkeys to ArchiveDependency. Adjust code to cope. Done!
[12:50] <wgrant> (delete DistroSeriesParent too)
[12:50] <wgrant> (bonus points for making DSD point to an ArchiveDependency)
[12:50] <wgrant> jtv: Ah. That's a bit sad.
[12:50] <StevenK> wgrant: Bah, we just added it
[12:50] <wgrant> StevenK: Yes, and that's why I argued about it.
[12:51] <wgrant> Because it was premature and ill-thought.
[12:51] <StevenK> And I wrote a 2,000 line branch to *use it*
[12:51] <wgrant> Sure. But it's mostly reusable.
[12:51] <wgrant> Just need to change the class it looks at.
[12:51] <wgrant> It's the ArchiveDependency code that needs to change significantly.
[12:51] <wgrant> DSP-using code just has to use the other class.
[12:53] <jtv> wgrant: I'm surprised to hear we were thinking along such similar lines all the time.
[12:53] <jtv> (including the "premature and ill-thought" bit)
[12:53] <wgrant> Heh.
[12:54] <wgrant> Your combined solution is better than the one I had come up with.
[12:54] <wgrant> But I knew the existing one was entirely inadequate :)
[12:56] <wgrant> This is why I like non-trivial discussion before making large changes :)
[13:00] <henninge> jtv: I was pinging you to ask you about that ... ;-)
[13:00] <jtv> Ah!
[13:01] <henninge> jtv: do we have it documented somewhere?
[13:01] <jtv> Errr yes somewhere I think...
[13:01] <wgrant> How hard is it?
[13:01] <wgrant> Can NRCP just say to poke a LOSA to do it?
[13:01] <jtv> wgrant: not hard at all.
[13:02] <jtv> It used to be a big deal where lots of things could go wrong and bugs would surface with merciless savagery.
[13:02] <wgrant> Yeah.
[13:02] <jtv> But nowadays, yes, a LOSA could do it or better yet, a job runner.
[13:02] <wgrant> And you had to take down LP for 12 hours.
[13:02] <wgrant> Those were the good old days.
[13:03] <jtv> 12 hours?  you kid had it easy
[13:03] <henninge> jtv: also, I am wondering if "Mail rosetta@..." is still a good instruction for the Ubuntu guys.
[13:03] <jtv> henninge: we were just talking about that--you're right, it isn't.
[13:04] <henninge> right
[13:04] <wgrant> I have my cursor on the NRCP edit link :)
[13:05] <wgrant> Is there a LOSA doc I can link to?
[13:05] <jtv> It should be a simple matter of running scripts/copy-translations-from-parent.py -d ubuntu -s <new series> and, once it's done, enabling imports for the series.
[13:05] <wgrant> Nothing under LPHowTo like there is for branch-distro?
[13:07] <henninge> jtv, wgrant: I can see to it that it happens this time around and wirte up a doc for it.
[13:07] <jtv> I'm searching the wikis atm
[13:07] <henninge> (which would mainly include those two instructions)
[13:08] <henninge> jtv: cool. I have to relocate right now. Please let me know what you find ... ;-)
[13:08] <jtv> OK
[13:16] <wgrant> jtv: https://answers.launchpad.net/launchpad/+question/154984 <- is that just a matter of changing the series on +admin?
[13:17] <jtv> wgrant: the great irony of the translations opening is that the code relies on DistroSeries.parent_series.
[13:17] <jtv> wgrant: looking...
[13:17] <wgrant> jtv: Of course :)
[13:38] <huwshimi> Anyone around that might be able to help me figure out why I can't get Launchpad running locally?
[13:42] <wgrant> huwshimi: What does it do?
[13:42] <wgrant> rvba: What's this -updates thing?
[13:42] <huwshimi> wgrant: I can't make a connection between the browser and the local server. At least that's what I suspect.
[13:43] <huwshimi> wgrant: launchpad.dev just times out
[13:43] <rvba> wgrant: the card says exaclty this "Synching to a released series should put packages in -updates" ... but I haven't talked to anyone yet (and Julian is only back tomorrow)
[13:43] <huwshimi> wgrant: and the server does not log any events
[13:43] <rvba> wgrant: https://code.launchpad.net/~rvb/launchpad/sync-to-updates/+merge/59653
[13:43] <wgrant> huwshimi: ping launchpad.dev
[13:43] <wgrant> Which address is it trying?
[13:43] <wgrant> rvba: I saw the diff, and I think the idea of hardcoding it like that is silly.
[13:44] <wgrant> It is probably what Julian wants.
[13:44] <wgrant> But it is still silly.
[13:44] <rvba> wgrant: :) I'll be glad to hear about any improvement you would care to suggest.
[13:44] <huwshimi> wgrant: Ah, it's trying to use my ip address at home
[13:45] <huwshimi> wgrant: I am a long way from that router :)
[13:45] <huwshimi> wgrant: I should have noticed that before
[13:45] <rvba> wgrant: not that the destination pocket was previously hardcoded to "release".
[13:46] <rvba> s/not/note/
[13:51] <wgrant> rvba: Right. We need to think how pockets are going to be handled.
[13:51] <wgrant> rvba: At the moment we handle !Release for source or destination. Hardcoding this is probably not the solution.
[13:51] <wgrant> Er.
[13:51] <wgrant> We *don't* handle !Release for source or destination.
[13:55] <lifeless> StevenK: wgrant: I'm not RM; RM role is dissolved.
[13:55] <wgrant> lifeless: But you are the effective RM, aren't you?
[13:55] <lifeless> StevenK: wgrant: rc exceptions can be handed out by reviewers as long as it *is* rc (that is we can't deploy without it)
[13:55] <wgrant> Oh. I didn't hear that.
[13:56] <lifeless> wgrant: I don't have any permission bits that I'm aware of that haven't been delegated out to be team responsibilities
[13:56] <rvba> wgrant: what do you mean exactly "we don't *handle* release for source or destination" ...?
[13:56] <lifeless> wgrant: I'll be closely involved, this is our single highest risk activity
[13:56] <jcsackett> rc also means less than it used to, since most things can go out shortly after.
[13:57] <lifeless> wgrant: did you get spm cycles for qastaging ?
[13:58] <wgrant> rvba: Different distros will want to do different things with pockets. At the moment we are hackishly hardcoded to ignore -backports and -proposed when generating DSDs. Now we're adding more hacks to map release into -updates when something has released. This is just going to become an ever-increasing stack of hacks.
[13:58] <lifeless> ugh
[13:58] <wgrant> lifeless: For which? The questions QA?
[13:58] <lifeless> how do you turn off 'desktop integration' for launchpadlib
[13:58] <rvba> wgrant: I see.
[13:59] <lifeless> wgrant: applying the db patch to qastaging
[13:59] <wgrant> lifeless: No :/
[13:59] <wgrant> lifeless: I'll grab $US_LOSA.
[13:59] <wgrant> When they appear.
[13:59] <lifeless> cool
[14:00] <deryck> Morning, all.
[14:00] <lifeless> so, desktop integration. How does one turn that off?
[14:00] <deryck> henninge, standup ping
[14:00] <lifeless> [I don't trust every python script with private access to lp]
[14:01] <rvba> wgrant: so a possibility would be to abstract the behaviour of things related to pockets (as much as possible ... and especially new things) so that whenever this pocket-thing get cleaned up properly we don't have to modify things everywhere ... correct?
[14:01] <wgrant> lifeless: Well, you have POSIX to argue with about that..
[14:01] <benji> lifeless: take a look at https://dev.launchpad.net/LandingChanges#Credential%20storage; there I describe how to force the file-based crendential storage
[14:01] <lifeless> cool
[14:01] <wgrant> rvba: Right, the ArchiveDependency rework we discussed earlier could solve this.
[14:02] <lifeless> I need to hunt down whomever wanted this carte blanche approach and determine their real needs
[14:02] <lifeless> so we can make it sane
[14:02] <wgrant> lifeless: Or do you just not trust them to not do things out of stupidity, not malice?
[14:02] <lifeless> stupidity mainly
[14:02] <lifeless> I want to know when client X is going to futz with my not-journaled webapp thank-you-very-much
[14:03] <wgrant> Maybe one day our operating systems won't suck and we can run potentially malicious code.
[14:03] <lifeless> (its why I tend not to use fat clients for most web services I use)
[14:04] <wgrant> lifeless: All protests on this front were ignored.
[14:04] <wgrant> lifeless: Well, dismissed with cries of approximately "DX! DX!"
[14:04] <wgrant> IIRC
[14:04] <lifeless> benji: thats file based, but does it restore the previous *one file per app* logic
[14:04] <lifeless> benji: because thats what I want; I want each /app/ to get oked
[14:04] <wgrant> lifeless: bwahaha.
[14:04] <wgrant> bwahahahah.
[14:04] <wgrant> You'll have to hack the code.
[14:04] <rvba> wgrant: Yeah ... but the ArchiveDependency rework will not happen tomorrow I'm afraid so we will have to figure out a way to deal with this pocket related work in a way that will make the future work easy (well, not to painful let's say ;)).
[14:04] <wgrant> And undeprecate the APIs.
[14:04] <lifeless> benji: think android
[14:05] <wgrant> rvba: Why does -updates have to be dealt with now?
[14:05] <lifeless> wgrant: we may have time for oni; the big thing is finding out *who* drove it.
[14:05] <benji> lifeless: nope, it's still one file for all; the app can force it's own store, but off the top of my head I don't know of a way for the user to do it
[14:05] <rvba> wgrant: no other reason than this being a task on the kb board with high priority
[14:05] <lifeless> Every time I spoke to a dev about it, the requirements were coming from some unspecified 'users'.
[14:05] <benji> hmm, there might be a way, let me look
[14:06] <lifeless> benji: thanks!
[14:06] <lifeless> I'm crashing, but if you find something, I should see it in backlog - or you could drop me a pointer in mail if you felt so inclined
[14:07] <wgrant> rvba: Looks like Priority: Normal to me. But hmm.
[14:07] <lifeless> night all
[14:07] <wgrant> Night lifeless.
[14:08] <rvba> wgrant: you're right ;)
[14:09] <wgrant> Anyway, we have Julian back tomorrow.
[14:09] <wgrant> It looks like the hack is done.
[14:09] <wgrant> So if he wants it it's there.
[14:10] <rvba> wgrant: sure ... but the hack itself is a one liner (sort of) so I'm very much in favour of making this more clean ... especially since, like you said, this whole pocket stuff will have to be reworked.
[14:11] <wgrant> rvba: It's not critical that this is fixed now, and we may have a proper solution soon. So I'd be a little averse to landing more hacks.
[14:11] <rvba> wgrant: I completely understand ... and I agree.
[14:11] <wgrant> If Ubuntu was complaining about this *now*, sure :)
[14:12] <wgrant> That would be the Soyuz Way™.
[14:12] <wgrant> But that is fortunately not the case right now.
[14:12] <henninge> adeuring: https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/559822
[14:12] <_mup_> Bug #559822: editra is provided by both the editra package and python-wxtools and conflicts <apport-package> <i386> <lucid> <verification-done> <editra (Ubuntu):Fix Released> <wxwidgets2.8 (Ubuntu):Fix Released by d.filoni> <editra (Ubuntu Lucid):Fix Released> <wxwidgets2.8 (Ubuntu Lucid):Fix Released> < https://launchpad.net/bugs/559822 >
[14:12] <jcsackett> wgrant: isn't the Soyuz Way mor of a patent-pending thing? :-P
[14:13] <rvba> although I'm very much in favour of figuring out a way to do things and preparing for the future at the same time. if that's possible that it :).
[14:13] <wgrant> jcsackett: Indeed.
[14:14] <rvba> wgrant: thanks for keeping an eye on my doings in the Soyuz code base though ;)
[14:15] <wgrant> rvba: Sorry about this, but I want to try to minimise the piles of hacks on top of piles of hacks that are already happening :(
[14:15] <wgrant> (and have been happening forver)
[14:15] <rvba> wgrant: no irony here ... I was about to ask you about this
[14:15] <rvba> wgrant: "Started to work on new task: syncing packages in a released series should put packages in the Updates pocket.  Will discuss with someone knowledgeable about Soyuz. "
[14:16] <wgrant> Heh
[14:16] <rvba> wgrant: from this morning call notes ... see ;)
[14:16] <rvba> anyway, I'll do something else now ... and land the other work we've been talking about ...
[14:17]  * rvba adds wgrant to *the* list
[14:17] <rvba> (of the people to whom I owe a beer)
[14:18] <wgrant> Fortunately in lots of places you won't be able to fulfil that :P
[14:21] <rvba> I reckon in Irland it's ok.
[14:34] <StevenK> rvba: wgrant doesn't drink. Perhaps you'll need to settle for warm milk or something.
[14:35] <wgrant> I do... just not where it's US-illegal :)
[14:35] <rvba> StevenK: wgrant I'm sure we will find a way to settle this :P
[14:35] <wgrant> Heh.
[14:37] <StevenK> wgrant: Actually, there is no restriction in Ireland, as long as you have guardian permission, so if you ask your mother, you should be good. :-P
[15:01] <benji> henninge: I claimed https://code.launchpad.net/~sinzui/launchpad/question-email-3/+merge/59574 but wanted to be sure you weren't working on it.
[15:02] <henninge> benji: I am not but thanks for keeping me informed. ;)
[15:02] <benji> thanks
[15:12] <sinzui> benji: I was going to beg jcsackett to review that since it contains a 900 line fix to doctest that required a lot fixes to preserve the tests since the infrastructure changed.
[15:12] <benji> sinzui: oh, ok
[15:13] <jcsackett> benji: i consider myself begged. i'll take a look at it in a moment.
[15:13] <jcsackett> er, actually, ^ sinui
[15:13] <jcsackett> ...i fail at typing.
[15:13] <sinzui> benji: The real change is very small.
[15:13] <benji> yeah, it looked like mostly test fallout
[15:24] <LPCIBot> Project windmill-db-devel build #229: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/229/
[15:24] <jcsackett> sinzui: looking at your branch now.
[15:40] <jcsackett> sinzui: approved, with a minor quibble on some classnames (as listed in my comment).
[15:40] <sinzui> okay thanks
[15:40] <jcsackett> sinzui: i am very excited to have all of this landed. :-)
[15:41] <sinzui> jcsackett: testing the the previous branch shows two failures. One I already have a fix for, and one very preplexing...
[15:41] <sinzui> At least I know I wrote a very good test for qastaging
[15:42] <adeuring> sinzui: do you see bad side effects if the result of Person.getAdministratedTeams()  would be cached? (too many call of this method are the cause of bug 768443)
[15:42] <_mup_> Bug #768443: ProductSeries:+index timeout with many releases <timeout> <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/768443 >
[15:42] <sinzui> well
[15:43] <adeuring> there are other places where we could cache the result
[15:43] <sinzui> adeuring: We want to remove that method. It forces the team owner to be a member of the team. I believe there are two call sites last month. One that can easily be factored out and one that looked tricky
[15:44] <sinzui> adeuring: I think callsites should be using team.adminmembers
[15:44] <adeuring> sinzui: ah, that would be another option. thanks!
[15:45] <sinzui> adeuring: mailing lists has one call site. It can switch to team.adminmembers. It has a test that says the owner can configure the list...we can remove that
[15:45]  * sinzui looks for the other callsite
[15:46] <adeuring> sinzui: that's in lp.bugs.browser.structuralsubscription
[15:46] <sinzui> adeuring: sorry. I am wrong. I misread the method
[15:46]  * sinzui reads the code and sips coffee
[15:50] <sinzui> adeuring: I am +1 to add caching to getAdministratedTeams. I believe the only oddness we need to think about is when the user in the interaction is was added/removed to team.owner either directly or indirectly. This same user cannot add himself, but he can remove himself. Since the operation to change yourself is separate from where we show that list. I think there is 0% chance of caching oddness today
[15:51] <adeuring> sinzui: yeah, stuff like is what concerns me too. I'll look a bit closer at thie issue
[15:52] <sinzui> adeuring: Subscriptions are only place that list your teams. I believe there is a bug reported that it is not possible to see and change the teams you admin. I think the person so fixes that bug will need to clear the cache after the change operation.
[15:54] <adeuring> right
[16:13] <adeuring> sinzui: there is alreay a method Person.clearInTeamCache() It can and should clear the new cache too, I think
[16:14] <sinzui> adeuring: may not. I am not a member of may teams I own
[16:15] <adeuring> ah, right. so I'll ignore possbile problems with the cache for now -- could not find any real issues..
[16:16] <sinzui> adeuring: InTeam() is broken because it forces the team.owner to be a member. It should not. So our choices are to add temporarily add the cache clear rule, but we would want to remove it. inTeam() should instead be changed to not include the team owner.
[16:17] <adeuring> sinzui: maybe. But that's more than I want to change for this bug ;)
[16:57] <jcsackett> is anyone else having issues with "make run" ? http://pastebin.ubuntu.com/602346/
[17:01] <jcsackett> ah, looks like memcached is gone post-update.
[18:33] <abentley> benji: Could you please review https://code.launchpad.net/~abentley/launchpad/nonascii-email/+merge/59671 ?
[18:33] <benji> abentley: gladly
[18:47] <benji> abentley: done with https://code.launchpad.net/~abentley/launchpad/nonascii-email/+merge/59671
[18:48] <abentley> benji: thanks.
[18:48] <benji> np
[18:56]  * jcsackett is down one machine.
[19:03] <sinzui> \o/ NotifcationRecipientSet.remove() has always been broken
[19:05]  * sinzui prepared an apocalyptic fix.
[19:30] <dobey> sinzui: is that like cooking heroin from brimstone and hellfire?
[19:31] <sinzui> dobey: eek
[19:32] <sinzui> dobey: apocalypse  is a tag meaning code code and tests need to moved to where people can find them. The two were separated for years so it is very difficult to discover the code has always been broken
[19:33] <jcsackett> so named, if i recall, b/c the people doing the fixing were nicknamed the four horsemen.
[19:34] <jcsackett> which invites the question, how is your horse, sinzui?
[19:35] <dobey> sinzui: it was just your choice of words :)
[19:36] <sinzui> hmm, well that has meta insinuations as well
[19:37] <sinzui> jcsackett: my wife was muling laundry down the steps this morning and fell. A child had left shoes on the steps. We pondered going to the emergency room
[19:38] <sinzui> jcsackett: so I ran up stairs where I stepped on a shovel my wife left on the steps, puncturing my foot.
[19:38] <jcsackett> sinzui: good lord! are you too relatively okay?
[19:38] <jcsackett> s/you too/you two/
[19:39] <sinzui> jcsackett: My wife tells me she had no idea I would be running up the steps to help her; she claims left the shovel on the steps as a trap for the children.
[19:39] <sinzui> She is making my open the jars and I am limping a bit
[19:42] <jcsackett> sinzui, you frequently take the cake for anti-charmed life.
[19:42] <jcsackett> and i thought nuking my macbook today was a bad day.
[19:42] <dobey> heh
[19:47] <sinzui> jcsackett: I think I can top than. On Easter day I drove my children to their grand parents. I noticed my speedometer did not work. We made jokes about how we should get their in no time at zero speed. I also noted that the the miles we were traveling were not ticking away. Near our destination the car started to chug and shake.  I had run out of fuel, though the gage was at 50%. I marched my well-dressed children to a co
[19:47] <sinzui> rner by the road to wait for a relatives to find us. ;)
[19:47]  * jcsackett can no longer tell when sinzui is joking
[19:52] <sinzui> jcsackett: I think mundane misfortunes are best expressed as humour. I make them bearable.
[19:52] <jcsackett> sinzui: fair.
[20:33] <lifeless> morning
[20:46] <jcsackett> what's the magic to run a javascript test? the usual "bin/test -t pattern" isn't doing it.
[20:50] <abentley> jcsackett: You open the html file in Firefox.
[20:53] <jcsackett> abentley: huh. okay.
[20:53] <jcsackett> abentley: so do we just have some plumbing to open all of those via windmill or something on ec2?
[20:54] <abentley> jcsackett: yes, there's a particular layer you can run.  I forget its name, but it was announced in launchpad-dev in the last month or so.
[20:54] <jcsackett> abentley: okay, thanks.
[21:36] <flacoste> lifeless: https://code.launchpad.net/~flacoste/launchpad/ppr-enhancements/+merge/59700
[21:36] <flacoste> if you care to review my collected enhancements to the ppr
[21:37] <flacoste> it's a big branch (844 lines), turned out that the trickiest part was changing the histogram resolution :-)
[21:53] <sinzui> jcsackett: do you have time to mumble?
[21:54] <jcsackett> sinzui: sure, just one moment.
[21:56] <jcsackett> sinzui: i think the problem is on my end.
[21:56] <jcsackett> i have a number of things failing today.
[21:57] <sinzui> jcsackett: I just restarted since I saw you speaking but heard nothing
[21:57] <lifeless> flacoste: hi
[21:58] <lifeless> voip/skype?
[21:58] <flacoste> lifeless: voip is good
[21:59] <lifeless> ext #?
[21:59] <flacoste> 7356
[21:59] <lifeless> currently unavailable
[22:00] <flacoste> lifeless: try again
[22:01] <jcsackett> sinzui:i have gone through the wizard again and appear to have a functioning microphone.
[22:01] <jcsackett> sinzui: hm. i'm guessing you still do not hear me?
[22:02] <jcsackett> ...sound settings have never been right on this machine...
[22:02] <sinzui> I do not, but I hear the pings from this app and music
[22:02] <jcsackett> sinzui: yeah, problem is on my end, i'm sure.
[22:02] <jcsackett> sinzui: give me a few more moments, and if we cannot get it working, just call me?
[22:02] <sinzui> jcsackett: does sound preferences show the mic working
[22:03] <sinzui> ...the input tab
[22:03] <jcsackett> sinzui: it does. i ran through the wizard and had functioning sound. :-/
[22:03] <jcsackett> er, microphone.
[22:04] <sinzui> I do not use the wizard. It died when I tried to configure it. I guess it did what it needed to. I use the pulse sound preferences panel that is found in the sound indictor.
[22:04]  * sinzui sees mumble and can adjust the volume/input of speakers and mic
[22:06] <sinzui> jcsackett: I see your status changing, but I no longer see an indication that you are speaking.
[22:07] <sinzui> maybe you can use deafen to send a morse coded message
[22:11] <lifeless> matsubara: hi; I have an oops-tools patch, how do I land it?
[22:22] <matsubara> lifeless, you need to set a commit message and set the mp as approved
[22:34] <sinzui> jcsackett: https://launchpad.net/~mactel-support/+archive/ppa
[22:37] <sinzui> jcsackett: https://help.ubuntu.com/community/MacBook5-1/Lucid
[22:37] <sinzui> https://help.ubuntu.com/community/MacBook5-1/Natty
[22:40] <lifeless> flacoste: http://developers.facebook.com/blog/post/358/
[22:56] <sinzui> jcsackett: the brightness instruction on the natty page does indeed fix bightness
[22:57] <jcsackett> sinzui: that is awesome.