[00:02] <poolie> wgrant: should i kill it in ec2?
[00:15] <wgrant> Let's see what version of python-apt is on pigeonpea/pilinut/cocoplum/germanium/cesium.
[00:15] <wgrant> LOSAs: ^^
[00:16] <hloeung> wgrant: one sec
[00:18] <hloeung> wgrant: 0.7.94.2ubuntu
[00:18] <wgrant> There are three characters missing there.
[00:18] <wgrant> And they are the critical ones :)
[00:19] <hloeung> 0.7.94.2ubuntu6.2, does that sound right?
[00:19] <wgrant> That sounds right.
[00:19] <wgrant> But also old :(
[00:19] <wgrant> poolie: ^^ we need 6.4
[00:24] <poolie> ok
[00:24] <poolie> hloeung: do those machines not get l-updates automatically?
[00:25] <poolie> well, i realize approximately no machines upgrade really automatically
[00:25] <poolie> but would it be hard to bring it in? is it seen as being available?
[00:34] <hloeung> poolie: yeah, it seems to be available.
[00:34] <poolie> i killed the ec2 land run and i'm running just a test
[00:35] <poolie> thanks haw; how would we go about getting it upgraded?
[00:35] <poolie> a request on the lp production status page?
[00:36] <hloeung> file an RT about it
[00:36] <hloeung> and we'll do it for you
[00:45] <poolie> lifeless: should i/we do this ^^?
[00:50] <lifeless> poolie: I'd rather someone involved with the bug do it
[00:50] <lifeless> the side effects of an uncoordinated change can be severe
[00:50] <poolie> mm
[00:51] <poolie> who would that be? jelmer?
[00:52] <lifeless> jelmer, wgrant, bigjools, gavin, stevenk, jtv or colin - offhand those folk should all have the experience to make reasonable predictions about side effects
[00:52] <poolie> cool
[00:53] <poolie> i'm pushing it because it has been mentioned as a udd blocker
[00:54] <lifeless> so basically the branch can't land until we've separately done the upgrades everywhere
[00:54] <lifeless> and that needs teseting and QA in its own right.
[00:54] <lifeless> e.g. start with buildbot / *staging, dogfood, check its all good, then prod, then and only then land the branch.
[00:55] <poolie> yep, thanks
[01:01] <wgrant> poolie: A UDD blocker!?
[01:05] <poolie> well, not a blocker for packaging branches, but a thing people complained about in our meeting
[01:06] <wgrant> Interesting.
[01:07] <wgrant> 'cause it's not really related at all...
[01:11] <lifeless> poolie: what trouble was it causing them ?
[01:13] <poolie> i believe it was that they wanted to sync tar.xz packages from debian
[01:13] <poolie> ?
[01:13] <poolie> the comment was basically just "can we have that xz bug fixed?"
[01:14] <lifeless> heh
[01:14] <lifeless> well, I'm glad you have an interest in it
[01:14] <lifeless> it will be good to have it fixed
[01:15] <poolie> .. and i just hate to see thing stalled, at least without a "this is waiting on" comment
[01:15] <poolie> lifeless: do you want to read https://code.launchpad.net/~mbp/launchpad/mail-scope/+merge/60281 again?
[01:15] <poolie> it has a +1
[01:15] <lifeless> sure, i can do that
[01:29] <StevenK> Has anyone seen http://paste.ubuntu.com/655990/ before?
[01:31] <poolie> i think i've seen something like that, where _testMethodName is missing
[01:31] <poolie> as the name implies its failing to load and then things are not sufficiently set up to report the faliure
[01:31] <poolie> i'd suspect a syntax error or similar
[01:31] <poolie> or an import erorr
[01:37] <StevenK> pyflakes is happy, which is the odd thing
[01:42] <poolie> i would probably bisect backwards to find something that works
[01:43] <StevenK> If I comment out a class variable "foo = PillarName.projectgroup == None" it works
[01:47] <poolie> ah, well maybe that's stopping it loading
[01:48] <poolie> perhaps projectgroup is not defined at the time that initializer runs?
[01:48] <StevenK> Hmmmm, maybe it isn't projectgroup
[01:50] <poolie> lifeless: shall i wait for you to review the mail_header patch or send it now?
[01:52] <StevenK> Rargh!
[01:52] <StevenK> PillarName has product and project
[01:52] <StevenK> Which one is projectgroup, then?
[01:53] <wgrant> project
[01:53] <wgrant> Product = Project, Project = ProjectGroup
[01:54] <lifeless> poolie: I have reviewed it now; I had to pop out to the vet before.
[01:54] <poolie> np, thanks
[01:54] <lifeless> poolie: I think its fine as is but would be smaller if you derive from Fixture
[01:55] <StevenK> wgrant: That's ... obvious :-/
[01:55] <poolie> lifeless: oh, interesting idea, even though it's not used only in testing?
[01:56] <lifeless> fixtures isn't just for testing
[01:56] <lifeless> never was
[01:59] <poolie> ok
[03:01] <nigelb> wallyworld: hi
[03:01] <poolie> o/ nigelb
[03:01] <nigelb> hey poolie!
[03:01] <wallyworld> nigelb: hello
[03:01] <wallyworld> how's the branch going?
[03:01] <nigelb> wallyworld: I was working on solving that bug last weekend and ran into doubts.  I emailed you :)
[03:02] <nigelb> ..and the branch is here -> https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking
[03:02] <wallyworld> nigelb: really? i don't recall seeing the email
[03:02] <wallyworld> let me check my inbox
[03:02] <nigelb> :)
[03:05] <wallyworld> nigelb: it was in my trash - i got a whole lot of code import email which escaped my filter arrive in my inbox and yours was right in the middle and accidentally got deleted
[03:05] <nigelb> haha
[03:05] <wallyworld> give me a few minutes to read it :-)
[03:09] <nigelb> oh. 240 critical bugs? :(
[03:09] <wallyworld> nigelb: so i see you've added the 'bug-link' class to bug links and are grabbing those to send to the back end
[03:10] <nigelb> Yeah.
[03:10] <nigelb> I got that far. Now at the javascript is where I have a few doubts on how to proceed
[03:11] <wallyworld> did you have a particular question?
[03:11] <nigelb> Yes, so in the javascript.
[03:11] <nigelb> I'm doing harvest_links(links_to_check, 'branch-short-link', 'branch_links', 'bug-link');
[03:12] <nigelb> Is that the right way, just add the css for the bug along with the branches
[03:12] <nigelb> I was wondering if they should be seprate variables
[03:13] <wallyworld> the server has one end point for processing any links extracted from the page, so it makes sense just to add a new link class to the existing variable
[03:13] <wallyworld> ie gather all links, send them to the server for processing, render the results
[03:13] <nigelb> ah, so now I have to go to the server and add stuff to the processing bit.
[03:14] <wallyworld> on the server side you can introduce a separate class for bugs vs branch links
[03:14] <nigelb> ah, ok
[03:14] <wallyworld> the reason it can be in the one data structure is that the server is just providing generic info (enabled, title text etc)
[03:15] <wallyworld> so on the client, there's no reason to distinguish between bug vs branch links
[03:15] <wallyworld> does that make sense?
[03:15] <nigelb> Yes, it does :)
[03:16] <wallyworld> excellent!
[03:16] <nigelb> I guess the next place I should be making modifications is lib/lp/app/browser/linkchecker.py
[03:16] <wallyworld> yes
[03:17] <wallyworld> or you could write some tests for the javascript side ie TDD
[03:17] <wallyworld> get that side of things sorted first
[03:17] <nigelb> ah, yes.
[03:18] <wallyworld> there may not be yui tests for that stuff
[03:19] <nigelb> there isn't.
[03:19] <wallyworld> the framework we have now was not around back when it was written
[03:19] <nigelb> so I guess I'll have to write new tests
[03:19] <wallyworld> yeah, that would be good if you had the time
[03:19] <nigelb> I'll try :)
[03:20] <nigelb> Not sure if I can get them rright.
[03:20] <wallyworld> or at least write tests for the stuff you are adding
[03:20] <wallyworld> i can help
[03:20] <nigelb> I'll push to the branch tonight and pke you tomorrow to see if I've done it right
[03:21] <wallyworld> nigelb: you could look at a simple existing test and use that to get started eg test_hide_comment.js
[03:22] <nigelb> I did look at one
[03:22] <nigelb> It looks easy enough.
[03:22] <wallyworld> also http://dev.launchpad.net/JavascriptUnitTesting
[03:22] <nigelb> (famous last words, I know :P)
[03:22] <wallyworld> yep :-)
[03:23] <nigelb> hehe, who wrote that wiki page?
[03:23] <nigelb> "Day one was horrible, there was a lot of shouting, words were said that may have hurt my computer's feelings"
[03:23] <wallyworld> not sure, but that's funny :-)
[03:23] <nigelb> yeah, heh
[03:29] <nigelb> Interesting.
[03:29] <nigelb> make run now takes only ~30s
[03:35] <nigelb> Laters! Off to work.
[03:44] <wallyworld> bye
[04:43] <jtv> StevenK, wgrant, greetings!  Continuing Q/A on the python-based publish-distro script.
[04:44] <wgrant> jtv: While we are there, it seems that publish-distro.py itself is now causing ~1500 OOPSes a day, because each WARNING spewed by CommandSpawner from a-f stderr is an OOPS now :/
[04:47] <jtv> wgrant: I imagine a lot of that simply shouldn't have been WARNING though.
[04:48] <jtv> That's assuming that this is mainly increased urgency & visibility for problems that were previously just as big.  Or have substantial new problems cropped up?
[04:48] <wgrant> jtv: apt-ftparchive's stderr output is... verbose.
[04:49] <StevenK> And 65 OOPSes per publisher run is just oh so much noise
[04:49] <wgrant> But the OutputLineHandler we give to CommandSpawner is self.log.warning
[04:49] <wgrant> Which, in a LaunchpadCronScript, causes an OOPS.
[04:49] <jtv> Then that should probably just change.
[04:49] <wgrant> Indeed.
[04:49] <wgrant> Well.
[04:49] <wgrant> Ideally we would tell a-f not to spam crap to stderr.
[04:49] <jtv> Quite.
[04:49] <wgrant> But that sounds more difficult than s/warning/info/
[04:51] <jtv> Well, be the first kid on your block to fix a thousand oopses today this week!
[04:51] <wgrant> And not hugely more rewarding.
[04:51] <wgrant> I'm not allowed to :)
[04:51] <wgrant> But maybe.
[04:51] <jtv> Borrow abentley's certificate.
[04:51] <wgrant> Heh.
[04:52] <jtv> If it's Critical and gets in the way of normal work…
[04:52] <jtv> (Which would equally be an excuse for me, so I could pick it up if you can't)
[04:52] <wgrant> Critical isn't an excuse for you.
[04:52] <wgrant> Being in scripts that you're working on is.
[04:53] <jtv> I was thinking of the "gets in the way of normal work" part, but yes.
[04:53] <jtv> Meanwhile, I need to upload test packages to the security pocket & a partner archive for further publish-ftparchive testing.
[04:53] <wgrant> Fun.
[04:53] <jtv> (Have you ever used the python version?)
[04:53] <wgrant> You can't build in security directly, so you have to copy to elsewhere.
[04:53] <wgrant> s/to/from/
[04:53] <jtv> Ah
[04:53] <jtv> that un-confuses me.  :)
[04:54] <jtv> And partner?
[04:54] <wgrant> partner you just upload with a component of partner.
[04:54] <wgrant> (that is Section: partner/SOMESECTION)
[04:54] <jtv> That's in the .dsc?
[04:55] <wgrant> Right.
[04:55] <wgrant> Well.
[04:55] <StevenK> And debian/control in the unbuilt
[04:55] <wgrant> Set it in debian/control.
[04:55] <wgrant> dpkg-buildpackage will put it in the .dsc
[04:56] <wgrant> If you edit the .dsc directly, there will be great sins to atone for.
[05:05] <StevenK> How should I search for truth in Storm? PillarName.active is True or PillarName.active == True ?
[05:06] <StevenK> Although I seem to get inactive results in either case
[05:10] <lifeless> ==True is what most of our code does
[05:10] <lifeless> this isn't good SQL
[05:10] <lifeless> but that  should be changed in storm
[05:11] <StevenK> I'm still concerned I'm getting inactive results when both inner-selects have PillarName.active == True
[05:11] <lifeless> whats the full query?
[05:12] <StevenK> lifeless: http://pastebin.ubuntu.com/656105/
[05:14] <lifeless> StevenK: why the ALL ?
[05:15] <StevenK> Without the ALL it would not return the rank 100 result sometimes
[05:17] <lifeless> the implicit distinct on a UNION is on all the columns
[05:18] <lifeless> I suspect a bug in your _filter - it could explain both situations (the current confusion and the rank 100 missing sometimes)
[05:19] <StevenK> lifeless: I have two subclasses, for one of them I want a filter
[05:20] <StevenK> lifeless: If you want the actual query that the code produces, I can get that for one of the cases
[05:21] <lifeless> StevenK: I'd like to see the actual query postgresql sees
[05:21] <StevenK> Yes, I was going to get the query from postgres's log
[05:21] <lifeless> StevenK: (or run with LP_SQL_DEBUG=1)
[05:28] <wgrant> StevenK: 'is True' can't work, '== True' does.
[05:31] <StevenK> LP_DEBUG_SQL=1 and doctests suck
[05:32] <jtv> Hah.  System death.  Just what I needed on the day I discovered I left my power supply in Europe.
[05:36] <StevenK> lifeless: http://pastebin.ubuntu.com/656113/
[05:36] <StevenK> lifeless: I don't like the look of the "AND NULL"
[05:37] <lifeless> thats your _filter; and yes, thats a little worrying ;)
[05:38] <StevenK> lifeless: I only need to filter for one case -- I suspect it is None for the other case
[05:38] <lifeless> a better way to construct things would be a list
[05:39] <lifeless> And(*clauses) [or skip the and, find's default join is AND
[05:51] <StevenK> lifeless: That looks like a better query. Sort of
[05:51] <StevenK> .contains_string() is just shit SQL
[05:52] <lifeless> you should be able to drop the ALL too
[05:52] <lifeless> (unless you specifically want it)
[05:53] <StevenK> This query is based on one that Curtis wrote for me, and that used UNION ALL
[05:55] <jtv> lifeless: the ALL in a UNION is usually something you want to keep if possible.
[05:56] <lifeless> jtv: why?
[05:56] <jtv> Saves a filtering pass.
[05:56] <jtv> (And thus, potentially a sorting pass)
[05:56] <lifeless> jtv: only if its unsorted though?
[05:57] <lifeless> jtv: and all our vocabs are sorted
[05:58] <jtv> It depends on the details, which I don't know and prefer not to get into right now; what matters is the uniqueness of entire rows, and chances are that the planner can't determine statically that that's not an issue.
[05:59] <lifeless> sure, thanks for mentioning this
[05:59] <jtv> (Chances are that it could in theory, but for it to try might significantly increase the run time of very fast and very frequent queries)
[05:59] <jtv> np
[05:59] <jtv> StevenK: what was the fs root for process-upload again?
[06:00] <wgrant> /srv/launchpad.net/ubuntu-queue
[06:00] <jtv> thx
[06:00] <jtv> Can't we make this a configuration item at some point?
[06:01] <wgrant> Not really. There are several queues in active use.
[06:01] <wgrant> The two poppy queues (there were four, now only two), the buildd-manager queue, the sync queue, the backdoor queue.
[06:02]  * jtv sobs quietly
[06:02] <jtv> "why does it all have to be so _hard_?"
[06:04] <jtv> Oh for Kibo's sake… battery critical already!?
[06:05] <wgrant> Hmm.
[06:06] <wgrant> Is lib/canonical/launchpad/webapp/templates/launchpad-model.pt used?
[06:06] <wgrant> It was added in r13548 and is buggy.
[06:06] <wgrant> But grep shows nothing.
[07:19] <rvba> Good morning.
[07:36] <adeuring> good morning
[07:37] <henninge> moin adeuring!
[07:37] <adeuring> hi henninge!
[08:35] <stub> We are going to need a report on what db patches have been applied to (production, staging, qastaging) vs. what have landed in what branch.
[08:36] <stub> Is there a smart way of seeing what files exist in the database/schema directory of lp:~launchpad-pqm/launchpad/db-devel besides checking out the tree?
[08:39] <StevenK> loggerhead
[08:39] <bigjools> StevenK: bzr ls
[08:39] <bigjools> StevenK: bzr ls
[08:39] <StevenK> Or bzr ls
[08:39] <bigjools> argh
[08:39] <StevenK> bigjools: FAIL
[08:39] <bigjools> stub: bzr ls
[08:39]  * bigjools kicks auto-complete in the spuds
[08:40] <stub> Seems to be downloading a heap, but that likely doesn't matter on the LAN.
[08:40] <stub> 1.7MB and counting...
[08:41] <stub> 4MB...
[08:42] <stub> Is this going to download the whole tree?
[08:42] <lifeless> hmm, it would be good for the qatagger to do this, roll it into the same report
[08:42] <lifeless> stub: no
[08:42] <lifeless> stub: but it will be downloading pack data, and if you are behind a broken http proxy this can get quite scattered
[08:43] <stub> Ooh... this is ssh. Wonder if HTTP goes faster locally for this sort of thing?
[08:43] <stub> finished now. should be fine on the lan. ta.
[08:44] <stub> And using the recursive option might help
[08:44] <lifeless> stub: or just ls database/schema
[08:44] <stub> bzr ls lp:~launchpad-pqm/launchpad/db-devel was what I first did, which strangely enough got me the top level directory listing.
[08:45] <lifeless> strange that
[08:47] <stub> Is there anything stopping bzr on devpad being upgraded? Missing -d, -k on that command.
[08:50] <stub>  bzr ls -v lp:~launchpad-pqm/launchpad/db-devel/database/schema seems to do what I want with the old version
[08:58] <stub> If course, if I want to show revisions changed as well I should probably jump in and use bzrlib rather than try to parse the output of bzr log
[08:59] <lifeless> nothing stopping it being upgraded
[08:59] <lifeless> stub: I'd seriously consider patching the qatagger for this
[09:00] <lifeless> stub: the only tricky bit would be knowing what patches are live; perhaps a query page for that.
[09:00] <stub> lifeless: That could be a good hook.
[09:01] <lifeless> stub: why does the garbo merge depend on the bugsummary rollup peformance patch?
[09:01] <stub> I was considering a tabular report   db | db | db | branch | branch , with the db columns boolean and the branch columns a list of revisions the patch was touched in.
[09:02] <stub> But maybe this is better solved with similar process like qa-foo tags?
[09:02] <lifeless> stub: what are we solving ? [for clarity, rather than me guessing :P]
[09:02] <stub> lifeless: Because the db patch not only attempted to optimize the stored procedure, it added an optional 'batchsize' argument to the rollup function
[09:02] <lifeless> stub: ah
[09:03] <stub> lifeless: juggling merges of code that depend on database patches being applied
[09:03] <stub> lifeless: nothing urgent in there, so I've just added that branch to my todo list. With frequent merges, it shouldn't be a problem
[09:03] <lifeless> stub: so, http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/revision/10832 looks like a hot patch
[09:04] <stub> It is, and I will be applying it live shortly with one of deryks, but the test suite won't pass for the garbo branch without that patch in the tree.
[09:04] <lifeless> cool
[09:05] <lifeless> so what I've been recommending folk do is get the patch live and then land the patch to devel, and then dependent patches
[09:05] <lifeless> this depends on us getting the latency of application down
[09:05] <lifeless> but avoids lots of cherrypicks and hard-to-qa stuff in db-devel
[09:05] <lifeless> perhaps this is wrong
[09:06] <lifeless> stub: so the report; uhm; I would hope that any code which /needs/ a db patch would fail tests without it.
[09:06] <lifeless> stub: I think a report is very useful to have.
[09:06] <stub> lifeless: agreed on both
[09:07] <lifeless> devs probably can look in a source tree easily enough for something they care about
[09:07] <lifeless> the thing devs /cannot/ do today is determine whether a patch is live without nagging a losa / gsa/ dba
[09:08] <wgrant> Should we just have a trivial view which returns the applied patches?
[09:08] <stub> yer, the important thing is what patches are on what db (which could be done with a view in Launchpad)
[09:08] <stub> snap
[09:08] <stub> The report would present all that info in one place though, as well as any interesting trivial like a db patch that was modified after landing in a particular tree.
[09:09] <wgrant> Sounds like it might belong in the deployment dashboard.
[09:09] <lifeless> well, thats why I was suggesting qatagger.
[09:09] <wgrant> Mmm.
[09:09] <lifeless> unapplied db patches
[09:09] <wgrant> I'd prefer another data provider that lpqateam.canonical.com watches.
[09:09] <wgrant> Rather than forcing it into qa-tagger.
[09:10] <wgrant> It doesn't seem to be a natural fit.
[09:10]  * lifeless shrugs
[09:11] <lifeless> the biggest ROI seems to be on a view for what-patches-are-live-on-this-server
[09:26] <bigjools> wgrant: can we talk about initialisation checks now?
[09:31] <bigjools> that scared him off
[09:56] <wgrant> bigjools: Hi.
[10:32] <wgrant> bigjools: http://jam-bazaar.blogspot.com/2009/11/memory-debugging-with-meliae.html
[11:00] <danilos> henninge, hi, do you mind reviewing https://code.launchpad.net/~danilo/launchpad/bug-814580-pre-cleanup/+merge/69980?
[11:01] <henninge> wgrant: Hi!
[11:01] <henninge> wgrant: "Needs information" on https://code.launchpad.net/~wgrant/launchpad/iseriesbugtarget/+merge/69951
[11:02] <henninge> danilos: sure
[11:02] <danilos> stub, lifeless: I've got two DB patches up for your review, one is "hot", another is "cold" (and I don't care about getting that one done "soon", since it's a table rename)
[11:02] <danilos> henninge, thanks
[11:03] <henninge> danilos: Relative packages in zcml? Are we doing that nowadays?
[11:04] <wgrant> henninge: It needs a bug?
[11:05] <henninge> wgrant: well, some information about the motivation for the chage.
[11:05] <wgrant> Indeed, but not a bug :)
[11:05] <henninge> wgrant: there must be some code in use (or in future use) where this will be used.
[11:06] <henninge> wgrant: yeah, probably, because it needs no qa.
[11:06] <wgrant> Well, there already is one case: shouldIndentTask. I thought the utility was fairly clear, regardless of future specifics. But I shall update the MP with the real intent.
[11:14] <danilos> henninge, there's a bunch of that in existing .zcml, and this makes it easier to adhere to our line length limits (though, it makes it harder to grep for stuff)
[11:14] <danilos> henninge, I am not too attached to the formatting so if you want, I can make it complete
[11:15] <henninge> danilos: I was just wondering. You can leave that as it is.
[11:17] <henninge> danilos: lines 255, 261, 303: I'd do full indentations in that case.
[11:18] <danilos> henninge, what do you mean? 4 spaces? (this is how Emacs python-mode does it by default)
[11:18] <henninge> danilos: also, shouldn't test_translationpackagingjob be renamed, too?
[11:18] <danilos> henninge, translationpackagingjob is not renamed
[11:18] <danilos> henninge, ideally, it should
[11:19] <danilos> henninge, or well, not, because that one is for the Packaging links being introduced/removed
[11:19] <danilos> (it should be renamed in my follow-up branches where I add the TemplateChangeJob)
[11:19] <henninge> oh, I mixed that up.
[11:20] <henninge> danilos: never mind about the indentations, they work for me the way they are.
[11:20] <henninge> danilos: just needed something to complain about ...
[11:20] <henninge> danilos: r=me ;-)
[11:24] <danilos> henninge, excellent, thanks
[11:32] <danilos> henninge, btw, how familiar are you with zope events and testing them? (basically, I wonder about testing IObjectModifiedEvent on potemplate, and the event doesn't fire if I just set potemplate.name to something)
[11:33] <henninge> danilos: Zope what? ;-)
[11:34] <henninge> danilos: no, I am not familiar with th em
[11:34] <danilos> henninge, ack :)
[11:34] <wgrant> danilos: You need to create a Snapshot and then notify() the ObjectModifiedEvent manually, unfortunately.
[11:35] <danilos> wgrant: really? what I find weird is that IObjectCreatedEvent and IObjectRemovedEvent are tested in the same file (albeit on a different object) and they work just fine; is this specific to the Modified event?
[11:36] <wgrant> danilos: Those two are easy.
[11:36] <wgrant> There are no field changes to take care of.
[11:36] <wgrant> ObjectModifiedEvent has to diff the objects.
[11:36] <danilos> wgrant: true, ok, just knowing that's what I've got to do is helpful enough, it kinda felt like cheating
[11:42] <jml> if you use dput to upload to a PPA that doesn't exist, when do you get the error message?
[11:42] <wgrant> jml: An email after 0-5 minutes.
[11:43] <jml> wgrant: thanks
[11:43] <wgrant> Yes, yes, this sucks :)
[11:44] <jml> And, IIRC, making it not suck requires message queues and some nebulous amount of rejiggering.
[11:44] <bigjools> it could do that check in poppy along with the GPG check
[11:44] <wgrant> To do it properly, yeah.
[11:44] <wgrant> bigjools: The amount of DB access it has now is already problematic and excessive :(
[11:45] <wgrant> We will have a message queue within months.
[11:45] <bigjools> ??? it's tiny
[11:45] <jml> for my part, I could *probably* get away with LBYL.
[11:45] <wgrant> And the world will be a better place.
[11:45] <wgrant> bigjools: Yes, but it's existent.
[11:45] <wgrant> bigjools: This makes DB upgrades harder, makes it much more fragile, leaves it stuck in our tree...
[11:46] <danilos> henninge, there's another one I need reviewed (just need to fix this problem with event firing for a single test, rest is all good): https://code.launchpad.net/~danilo/launchpad/bug-814580/+merge/69978
[11:51] <henninge> danilos: don't you have any shorter ones? ;-P
[11:53] <gary_poster> thanks for review henninge :-)
[11:53] <henninge> gary_poster: you are welcome
[11:55] <danilos> henninge, heh, I do but they are DB patches :P
[11:55] <henninge> danilos: ah, no thanks ;-)
[11:55] <henninge> danilos: I'll just do this one, then ... ;-)
[11:58] <danilos> thanks again :)
[12:01] <henninge> danilos: I remember that this kind of change used to be a DB change. Did that change? ;)
[12:01] <henninge> http://paste.ubuntu.com/656349/
[12:01] <henninge> ETOOMANYCHANGE
[12:02] <danilos> henninge, adding a new value to the enumeration isn't :)
[12:02] <wgrant> Well, it has some similar consequences.
[12:02] <wgrant> You have to be sure that various components of the system will cope with not knowing about it.
[12:02] <wgrant> Which will normally make stuff OOPS.
[12:03] <danilos> wgrant: right, that has been accounted for
[12:03] <henninge> danilos: ok, if you say so. Don't blame me if it can't be merged .... ;-)
[12:04] <wgrant> It's mergable, but it might break production :)
[12:04] <danilos> henninge, heh, fair enough
[12:04] <henninge> well, that's not that bad, then.
[12:04] <danilos> :)
[12:04] <henninge> :)
[12:05] <danilos> nah, this is a translation packaging job type, so if it breaks anything, it's going to break that, and that needs fixing anyway
[12:05] <henninge> I once tried that and PQM wouldn't merge it into devel. (I think that's where it failed)
[12:05] <henninge> but that is > 18 months ago.
[12:05] <danilos> henninge, wow, weird
[12:47] <wgrant> jml: Are you able to QA your PPA API thingy?
[12:48] <jml> wgrant: I'm in the middle of something right now. you lining up for a deploy?
[12:49] <wgrant> jml: Checking up on EU/US QA so I don't have to do much tomorrow, since I'm not allowed to.
[12:50] <jml> wgrant: essentially, I can do it, provided someone else can grant & revoke commercial admin privs for me, but I would rather not.
[12:50] <wgrant> k, I might just do it tomorrow, if nobody does it in the meantime.
[12:50] <wgrant> Since we are 30 revs behind now :/
[12:51] <jml> yikes.
[12:59] <bigjools> wgrant: is this the create-as-private thing?
[13:00] <wgrant> bigjools: Ja.
[13:12] <bigjools> wgrant, jml: qa-bad I think.  My private=False parameter is ignored.
[13:14] <wgrant> I actually don't see any logic that sets private = True...
[13:17] <StevenK> The whole point is to call it via the API
[13:17] <wgrant> I mean, there is nothing in createPPA that uses the argument.
[13:17] <bigjools> ...
[13:17] <wgrant> Except for validatePPA.
[13:18] <bigjools> yup
[13:19] <wgrant> bigjools: Can you roll it back, please?
[13:19] <bigjools> I'm sure a maintenance team can do it, I'm kinda busy
[13:19] <bigjools> anyway it can roll out, it's not a blocker
[13:20] <wgrant> Mmm. It's fairly misleading to have a 'private' argument that does nothing.
[13:20] <bigjools> affects like 7 people
[13:20] <wgrant> But I guess the set of affected users is small.
[13:20] <wgrant> Yes.
[13:20] <bigjools> oddly createPPA is only exported on version=beta
[13:21] <StevenK> If it doesn't block deployment then file a bug saying it doesn't work and move on?
[13:21] <bigjools> just re-open the old one
[13:21] <bigjools> mark it qa-ok
[13:23] <cody-somerville> wgrant, This is probably a stupid question, do you have the necessary permissions to set it private?
[13:23] <wgrant> cody-somerville: No.
[13:23] <bigjools> I do, and I tested it
[13:23] <StevenK> cody-somerville: However, wgrant did state the code didn't *do* anything with the flag.
[13:24]  * bigjools wonders what the tests look like for that change
[13:24] <StevenK> I think there is a validatePPA test only
[13:24] <wgrant> [r=julian-edwards] :P
[13:24] <StevenK> And no end-to-end test that I recall
[13:24] <bigjools> wgrant: :(
[13:24] <bigjools> not one of my best reviews
[13:25] <StevenK> Don't do that
[13:28]  * wgrant sleeps.
[13:33] <henninge> abentley: bug 819241
[13:33] <_mup_> Bug #819241: TranslationMergeJob migrates only POTMsgSets and no translations <upstream-translations-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/819241 >
[13:34] <henninge> abentley: bug 814580
[13:34] <_mup_> Bug #814580: Merge/split messages from all sharing templates <translations-handoff> <Launchpad itself:In Progress by danilo> < https://launchpad.net/bugs/814580 >
[13:51] <abentley> gary_poster: about the jsoncache, I didn't understand what you meant by : My preferred solutions might be long poll pushes, and/or MVC in client-side code (which in isolation would only address part of the "curentness" problem, but would be better than what we have)
[13:51] <abentley> gary_poster: how would MVC help?
[14:01] <gary_poster> abentley, right.  MVC in isolation--by which I mean edits change a model, and the model is updated from the server in isolation, and any connected model updates need to be explicitly connected/requested--gives you some sanity within a given page.  Multiple displays based on the same data will agree.
[14:01] <gary_poster> This will be sufficient in N% cases, where I suspect N is relatively high; and it will involve calculating a lot less data.  The tradeoff is full page correctness/timeliness with indiscriminate data loads (jsoncache + an update mechanism such as MVC) vs. possibly good-enough correctness and less cost of gathering data with specifically requested data loads (MVC "in isolation").
[14:03] <abentley> gary_poster: If "connected model updates need to be explicitly connected/requested", the only way to do that in our current web service is with one roundtrip per object, which doesn't give good performance.
[14:04] <gary_poster> abentley, sure.  you are building a new mechanism, though, so a new mechanism could be built.  And so far a single model update has been sufficient for the (limited) cases I've been involved with.
[14:07] <abentley> gary_poster: Okay, I thought you meant MVC could help without new mechanisms, which is what I didn't understand.
[14:08] <gary_poster> abentley, it can and does, if your use case is sufficiently limited, as the ones I've encountered have been.  If there is merit in what I am saying, it is in the "80/20 balance" direction--that is, we usually don't need the cost of a full data reload
[14:12] <abentley> gary_poster: From a user's perspective, I think that two roundtrips per operation (one to write, one to read) is the maximum we should tolerate, so partial updates will only be acceptable if only one or two objects are affected.
[14:17] <gary_poster> abentley, sure.  Often writes include the new version of the affected object, though, which means you only need the write.  Anyway, I think you understand where I am coming from which I think was the goal of your question.  I don't need to convince you of my position.
[14:17] <gary_poster> Hopefully what you have done will work out well, and if not, it will almost certainly be helpful in some cases at least.  If there are occasional performance problems, we can cross that bridge then, and if not, yay!
[14:18] <abentley> gary_poster: Here's an option that might please both of us: During a write operation, use server-side events to generically detect changes to the object cache,  return a delta as the result of the write operation.  What do you think?
[14:21] <gary_poster> abentley, in the abstract, yeah, I would like that--very nice.  ("in the abstract": IME we don't produce events reliably; but maybe we do it well enough that it would be nice functionality, and when it is insufficient, we can fix the event hookups.)
[14:23] <abentley> gary_poster: Cool.  Yes, I expect trailblazers would have to verify that sufficient events were generated for their use cases.
[14:23] <gary_poster> agreed abentley.
[14:23] <gary_poster> that would be nice
[14:27] <abentley> gary_poster: Can you think of a way to check whether all of our views are LaunchpadViews (or provide getCacheJSON)?
[14:32] <gary_poster> abentley, I'm afriad you'd get a lot of false negatives, but you could use the component registry I believe.  I think it might give you a lot of views that are ones you don't care about for one reason or another, but maybe not.  Lemme see if I can get you a spelling...
[14:35] <abentley> gary_poster: I'm okay with a lot of false negatives.
[14:41] <danilos> henninge, how's review coming along? (I'd be the first to admit it's not the nicest branch, and that testing leaves a bit to be desired)
[14:49] <henninge> danilos: sorry, distracted ...
[14:55] <jml> bigjools, wgrant: huh.
[14:56] <jml> thanks for the qa. I guess the test isn't doing what I thought it was.
[14:59] <bigjools> jml: and I suck at reviewing :(
[14:59] <jml> Oh. Duh.
[15:00] <jml> Is that going to get reverted? Or am I ok to just patch what's in stable now?
[15:00] <nigelb> bigjools: Didn't know you wwere big on cricket ;-)
[15:01] <bigjools> nigelb: I don't like cricket.... oh no .... I love it-a
[15:01] <bigjools> jml: it can land
[15:01] <bigjools> patch away
[15:01] <nigelb> bigjools: ha! shoulda poked you around world cup time ;)
[15:01] <jml> ta
[15:05] <bigjools> nigelb: who cares about the WC :)
[15:05] <bigjools> 50-over cricket will die
[15:05] <nigelb> T20WC? ;)
[15:06] <nigelb> Though, I don't watch cricket much personally. Its all that place in our room's TV. Got some mad fans as roommates :)
[15:08] <gary_poster> abentley: http://pastebin.ubuntu.com/656454/ .  There will be some duplication for the registratons of each layer.
[15:08] <bigjools> nigelb: we are T20 champs :)
[15:09] <abentley> gary_poster: Thanks very much.
[15:09] <gary_poster> abentley, I forgot, you should run that within bin/py, and you should start out with
[15:09] <gary_poster> >>> from canonical.launchpad import scripts
[15:09] <gary_poster> >>> scripts.execute_zcml_for_scripts()
[15:09] <gary_poster> yw
[15:09] <nigelb> bigjools: wha? when? It was us once and Pakistan next.
[15:10] <bigjools> nigelb: http://www.cricket20.com/db/t20_wc/default.asp
[15:10] <gary_poster> http://pastebin.ubuntu.com/656458/ fwiw
[15:11] <nigelb> bigjools: ha, I'm behind times apparnetly
[15:12] <bigjools> nigelb: you may keep weeping
[15:12] <nigelb> lol
[15:30] <jml> https://code.launchpad.net/~jml/launchpad/create-private-ppa-814567-2/+merge/70028
[15:31] <jml> would appreciate a review for that one
[15:31] <jml> fixes a qa-bad
[15:35] <jml> henninge: ^
[15:46] <danilos> henninge, I am off now, so if you have any questions re review, they'll have to wait until tomorrow; cheers
[15:46] <henninge> danilos: np, take care
[15:50] <henninge> jml: r=me
[15:50] <jml> henninge: thanks. can you please land it? I don't have commit privs.
[15:50] <henninge> jml: sure
[15:51] <henninge> jml: please set a commit message
[15:51] <jml> henninge: done
[15:52] <henninge> jml: I thought we had created a team for people like you. What was it called again?
[15:52] <henninge> but I guess it does not have any special privs yet.
[15:53] <jml> henninge: correct on both counts.
[15:53] <jml> canonical-launchpad-emeritus, I think
[15:53] <henninge> yes, that's what I meant
[15:55] <henninge> jml: "Use --no-qa, or link the related bugs to the branch"?
[15:55] <henninge> ec2 land wants a bug
[15:55] <jml> henninge: the latter. the bug number is in the branch name.
[15:55]  * henninge just figured that ... ;-)
[15:56] <henninge> somtimes I type faster than I think
[16:09] <benji> rvba: there are some conflict markers in https://code.launchpad.net/~rvb/launchpad/api-add-comment-bug-798522/+merge/70035
[16:10] <rvba> benji: I just pushed a revision fixing the conflict.
[16:10] <benji> cool
[16:17] <adeuring> benji: could you have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/bug-739052-2/+merge/70044 ?
[16:17] <benji> adeuring: sure
[16:17] <adeuring> thanks!
[16:19] <jml> if I have a form where a user is giving me 'ppa:foo/bar', should I parse it myself, or is there something that'll do that for me?
[16:19] <bigjools> jml: not heard of anything in LP but the dput code might
[16:22] <jml> hmm. doesn't look like it.
[16:23] <sinzui> jcsackett, ping
[16:23] <jcsackett> sinzui: pong.
[16:23] <sinzui> jcsackett, I have lost track of time. Do you have time to mumble?
[16:24] <jcsackett> sinzui: certainly.
[16:31] <benji> adeuring: I'm done with https://code.launchpad.net/~adeuring/launchpad/bug-739052-2/+merge/70044
[16:36] <adeuring> benji: thanks!
[16:36] <benji> my pleasure
[16:46] <jcsackett> benji: could i add https://code.launchpad.net/~jcsackett/launchpad/privacy-notifications-on-branches/+merge/70050 to your queue?
[16:51] <benji> jcsackett: sure; I'll look at it after lunch
[16:52] <jcsackett> benji: thanks!
[16:55] <jml> how best to check if a person is a member of a team over the API? Listing .participants is the best way I can see atm.
[17:07] <dobey> jml: looping through the team memberships is how i do it. and you also have to loop through memberships of any of those memberships which is also a team
[17:08] <dobey> becuase for some reaosn, someone though it was a brilliant idea to have team and person be the same thing… :)
[17:09] <mtaylor> dobey: zope's internal design rears its head again
[17:10] <jml> (team in list(person.super_teams)) seems to work
[17:11] <dobey> jml: does that handle membership-by-proxy case?
[17:11] <jml> dobey: docs say it traverses
[17:12] <dobey> interesting
[17:12] <jml> dobey: and it picks up a private team that I'm a member of via Landscape (of all things)
[17:13] <dobey> jml: but only becuase you're using the API as you, so you can see that, right?
[17:14] <jml> dobey: right. well, any member of that team could see it.
[17:14] <dobey> jml: right. but that doesn't help my use case for tarmac :)
[17:15] <jml> dobey: what conceivable use case could you have for seeing data that you're not allowed to see?
[17:16] <jml> you can't see members of private teams unless you yourself are a member.
[17:16] <dobey> jml: canonical is a private team, and all its members are not also members of the contributor-agreement team; and i have a tarmac plug-in that lets you check that people are legally valid contributors to a project
[17:16] <jml> otherwise, they wouldn't be private
[17:17] <dobey> and it's a pain that the bot user can't see the canonical team, since everyone in it can contribute
[17:18] <jml> dobey: well, make the bot a member of canonical, or convince sinzui to change the privacy model
[17:19] <dobey> well, the bot shouldn't be a member of canonical. it's a bot, not an employee. *shrug*
[17:19] <dobey> and i'm not sure the privacy model should change
[17:21] <sinzui> dobey, In a few months, we will have a mechanism to grant a user/team access to a project without placing the user in a role. This mechanism can and maybe added to teams. Private teams like their corporate owners to see what is happening inside them, and private teams like to subscribe non-members to archives
[17:23] <dobey> sinzui: sounds interesting. all i really care about is doing team.is_member(person) :)
[18:07] <LPCIBot> Project devel build #935: STILL FAILING in 5 hr 57 min: https://lpci.wedontsleep.org/job/devel/935/
[18:08] <benji> jcsackett: I'm a little confused.  If branches already have a "private" attribute, why not mark them as providing IPrivacy?
[18:09] <jcsackett> benji: i think the setup for the attribute in IBranch vs IPrivacy is different. honestly i read the comment where private is create in branch and decided not to tamper at this stage.
[18:10] <jcsackett> one sec and i'll double check.
[18:11] <jcsackett> benji: yeah, the IBranch interface defines it with several more parameters. is it safe to still mark branch as implementing IPrivacy, given IBranch sets it up differently?
[18:11]  * jcsackett is not up on zope interface interactions.
[18:12] <benji> jcsackett: parameters?
[18:13] <jcsackett> benji: e.g. readonly=True
[18:13] <benji> oh, are you talking about the web service API bits?  right, those are immaterial for in-process Python code
[18:14] <jcsackett> benji: it's a parameter on the Bool declaration, which comes from zope.schema, right?
[18:18] <benji> jcsackett: in the Liskov substitution sense a branch can't provide IPrivacy because IPrivacy says that "private" is read/write, so we have two... amongst our many options are: 1) be pragmatic, it'll work if we say branches provide IPrivacy and no kittens will be harmed or 2) make an (identity) adapter from IBranch to IPrivacy that just returns the branch
[18:19] <benji> my vote would be for 1; the code will be simpler (no hasattr check) and it captures the meaning of what's going on
[18:19] <benji> 2 would be a close second
[18:20] <jcsackett> ok, i'll go with 1 and remove the changes to the formatter.
[18:20] <benji> cool
[18:40] <jcsackett> benji: turns out the problem is the branch is a "DecoratedBranch" which delegates Branch, so it has the private attribute, but doesn't convert to IPrivacy; i'm thinking i need to create an adapter for IDecoratedBranch to IPrivacy that just returns the Decorated branch, which as the private attr.
[18:42] <benji> jcsackett: since the decorated branch already has a "private" attribute, why not make it provide IPrivacy?
[18:42] <jcsackett> benji is that safe since it delegates to IBranch (which it turns out already *did* implement IPrivacy?
[18:42] <jcsackett> if that's fine, i'll just do that; i always assume i'm going to break things when messing with this stuff.
[18:43] <benji> be fearless
[18:44] <benji> it should work fine, the object already has an attribute named what IPrivacy says it should be named and providing the information IPrivacy says it should provide (other than the read/write issue that we already discussed)
[18:45] <jcsackett> benji: rock on.
[18:51] <jcsackett> benji: just pushed changes up to LP.
[18:51] <benji> k, I'll take a look
[18:54] <allenap> Hi benji, got time for a medium sized uncontroversial branch?
[18:54] <benji> allenap: sure
[18:54] <allenap> benji: Thanks :) https://code.launchpad.net/~allenap/launchpad/selected-differences-vocab-bug-817408/+merge/70048
[19:32] <benji> allenap: I'm done with https://code.launchpad.net/~allenap/launchpad/selected-differences-vocab-bug-817408/+merge/70048
[19:32] <allenap> benji: Cheers.
[19:33] <benji> jcsackett: I'm done with your's too (https://code.launchpad.net/~jcsackett/launchpad/privacy-notifications-on-branches/+merge/70050)
[19:33] <jcsackett> thanks, benji!
[19:49] <jcsackett> sinzui: when doing the new privacy notification for private teams, we're only adding it to the main team page, right?
[19:50] <jcsackett> e.g. /~private-whatever/ but not /~private-whatever/+mugshots ?
[19:59] <lifeless> morning
[19:59] <lifeless> jcsackett: I would expect everywhere
[20:00] <jcsackett> lifeless: possibly, there was some talk of "primary" context in discussions. i suppose the better question is what was meant by "primary context" with regards to private teams..?
[20:54] <lifeless> jcsackett: so the question for you and sinzui is 'if someone is on <x page> and thinks its public, is it ok for them to publish the url.
[20:54] <lifeless> jcsackett: if not, then we should be pretty bold about helping them know, I think.
[20:55] <lifeless> I have to pop out - big medical day for lynne, I will be back in some hours :(
[21:34] <LPCIBot> Project db-devel build #774: STILL FAILING in 6 hr 6 min: https://lpci.wedontsleep.org/job/db-devel/774/
[22:15] <jelmer__> wgrant: hi
[22:15] <jelmer__> wgrant: Did you see my email regarding QA?
[22:18] <poolie> hi all
[22:58] <wgrant> jelmer__: I replied to the bug.
[23:02] <sinzui> StevenK, mumble?
[23:04] <jelmer__> wgrant: thanks
[23:04] <jelmer__> I guess I missed that.
[23:13] <sinzui> wallyworld, https://code.launchpad.net/~sinzui/launchpad/person-picker-expand-0/+merge/70082
[23:15] <wgrant> jelmer__: I saw the bugmail before I saw the direct one (because bugmail still goes to my personal account), so it wouldn't have gone to you directly.
[23:15] <StevenK> http://pastebin.ubuntu.com/656724/
[23:16] <wgrant> jelmer__: How confident are you that you will be able to QA this in the next 12 or so hours?
[23:17] <wgrant> jelmer__: It is getting pretty bad.
[23:29] <jelmer> wgrant: That should be possible, I can do it first thing tomorrow morning.
[23:30] <wgrant> Thanks.
[23:33] <StevenK> https://code.launchpad.net/~stevenk/launchpad/pillarname-vocab/+merge/70091
[23:46] <LPCIBot> Project devel build #936: STILL FAILING in 5 hr 39 min: https://lpci.wedontsleep.org/job/devel/936/