lifelessthere shouldn't be00:02
lifelessits a gpg config dir00:02
pooliegpg might make a symlink as a lock, but it looks like we're not actually running gpg in this test00:16
pooliei've been running it for a while and it has not failed00:16
poolielifeless: how about https://code.launchpad.net/~mbp/launchpad/882324-mtime-test/+merge/80521 then00:32
lifelesscommented. Three times.00:36
poolieyou'd do it that way because it will automatically give a clear message?00:40
poolieare you saying that you want me to keep the 'floor()' call, or do you want to have another attempt? ;-)00:41
lifelessdropping the floor is fine00:44
lifelessyes, it will automatically give a clearer message, and it eliminates another use of a poor primitive (assertTrue)00:44
=== Ursinha is now known as Ursinha-afk
pooliegreat, thanks00:51
pooliegood idea in fact00:51
poolieis there a link from the ppa to the recipe?00:53
pooliei guess it's only off the branch00:53
StevenKpoolie: If an upload was created by a recipe, the package will link back to it01:00
StevenKpoolie: For example, https://launchpad.net/~launchpad/+archive/ppa/+packages and then expand any of the launchpad-dependancies01:01
poolieok thanks01:02
lifelessit would be nice to link back recipes that are autobuilding separately from successful builds01:45
wgrantlifeless: Huh?01:48
lifelessauto builds build into specific ppas01:54
lifelessif they haven't successfully built, there is no link from the ppa01:54
lifelessthe package has to build for the link to show up01:54
wgrantAh, daily builds?01:54
StevenKlifeless: If the *recipe* built, but the packages resulting didn't, the link should still be there.02:10
=== lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 266
lifelessStevenK: indeed, I'm saying that waiting for that much success is still less clear than we could be02:11
lifelessStevenK: can has review, as you are here?02:13
lifelessor is it wgrants turn as wictum02:13
* lifeless consults the oracle02:13
lifelessthursday. Its me!02:13
lifeless-> bah02:13
lifelessStevenK: wgrant: ^02:14
* wgrant blames wallyworld_.02:14
=== lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: me | Critical bugtasks: 266
wgrantpoolie: https://staging.launchpad.net/~wgrant/+archive/experimental/+recipebuild/8780402:20
wgrantbzr: ERROR: Cannot commit directly to a stacked branch in pre-2a formats. See https://bugs.launchpad.net/bzr/+bug/375013 for details.02:21
_mup_Bug #375013: Cannot commit directly to a stacked branch <commit> <launchpad> <lp-translations> <qa-ok> <rodeo2011> <stacking> <Bazaar:Fix Released by jameinel> <bzr-builder:Fix Released by jelmer> <Launchpad itself:Fix Released by jtv> < https://launchpad.net/bugs/375013 >02:21
wgrantIs that new?02:21
wgrantI haven't used this recipe in more than a year, but it used to work...02:21
lifelesslooks like fallout from fixing commit to stacked branches in 2a; possibly due to a previously undocumented failure more02:22
lifelessbah https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-2126AT1002:22
wgrantlifeless: BranchRevision timeout...02:24
StevenKwallyworld_: Can you update the kanban board? I think the cards in Review and Landing can move02:32
* wallyworld_ looks02:32
wallyworld_StevenK: the one in landing, i'm fixing tests. makeBug, makeBugTask need a bit of work to make them compatible with the new disclosure rules02:34
lifelesswgrant: looks like it wasn't safe for 1.9 either according to comments inline02:34
lifelesse.g. that the only reason things worked on 1.9 was it being a no-change commit02:41
lifelessa change commit wouldn't be able to delta correctly in all cases in 1.902:41
lifelessI need a review - any volunteerS?02:43
lifelessStevenK: can I beg a review off you?02:56
StevenKlifeless: I suppose.02:57
StevenKlifeless: r=me03:00
pooliewgrant: pre-2a formats are kinda deprecated now03:09
pooliei don't think that failure is very conclusive either way for qa03:09
jelmerwgrant: is this about recipes using stacking and falling over when there is a pre-2a branch involved?03:11
wgrantjelmer: Well, I was trying to QA the new bzr-builder, and my test recipe happened to fall into that category.03:11
jelmerwgrant: that's not a new regression FWIW03:12
wgrantDoes someone have a less archaic recipe that they can reasonably test on staging?03:12
jelmerwgrant: python-fastimport is one of my usual test recipes03:13
jelmerI can have a look at adding that on staging, but not before dinner...03:13
wgrantAh, you're still in the US?03:14
wgrantStevenK: Yay, p-d-r back down to 8 minutes.03:15
wgrantStill sucks, but a bit better.03:15
jelmerwgrant: yeah03:15
poolieo/ jelmer03:16
pooliewgrant:  i can try mine on bzr03:16
poolieboth should be modern formats03:16
wgrantpoolie: That works.03:16
poolieok doing it now03:23
poolieok https://code.staging.launchpad.net/~mbp/+recipe/bzr-daily exists03:29
pooliequeued for build03:29
StevenKwgrant: 8 minutes sounds pretty good to me.03:42
wgrantStevenK: It is LP good.03:43
wgrantIt is not good.03:43
StevenKwgrant: Pretty good compared to the 1.5 hour transactions we were having03:43
wgrantIt's considering less than 1500 items. There's no reason for it to take more than 30 seconds, and that's being generous.03:44
pooliewhat's p-d-r?03:44
StevenKDeletes superseded publications03:44
pooliefailed: https://staging.launchpadlibrarian.net/80692680/buildlog.txt.gz03:45
wgrantIt's the pool cleaner.03:45
pooliei guess because of dpkg-deb: error: control directory has bad permissions 700 (must be >=0755 and <=0775)03:45
wgrantpoolie: sudo breakage03:45
wgrantlamont: ^^03:45
pooliewhich control directory is it talking about? the ./debian in the build area?03:45
wgrantprobably ./DEBIAN.03:46
lifelesswgrant: that yuixhr thing is still booming03:54
wgrantlifeless: :/03:57
lifelessI found a think in my OopsHandler change03:57
lifeless(is not None) s/not // to fix03:57
* StevenK kicks Person:+index for being stupid03:58
lifelessanyhow, that *might* be it, if yuixhr is logging warnings or something03:58
lifelessoh ugh04:03
pooliehas anyone seen a test fail with "error: pid file was not removed"?04:03
lifelessso I just realised, if we want different vhosts for txlongpoll, I'll need separate config for oops-amqp04:03
lifelesspoolie: nope04:04
lifelesswgrant: do you happen to know an ETA on txlongpoll being unbroken ?04:04
pooliei see muharem hit it in 200904:05
pooliejust bad luck i guess04:05
StevenKwgrant: So, where should I start digging for this +index madness?04:05
lifelessStevenK: queries ?04:05
StevenKlifeless: Hm?04:05
lifelessStevenK: what sort of madness04:06
StevenKlifeless: create_initialized_view(<person>, '+index') doesn't work04:06
lifelessStevenK: it does too04:08
lifelesssee TestPersonIndexView04:08
wgrantDoes that render the view?04:08
lifelessoh, rendering doesn't work?04:09
wgrantDoesn't seem to.04:09
lifelessthats odd04:10
lifelessuhm, there are additional parameters04:10
pooliewell https://bugs.launchpad.net/launchpad/+bug/88237004:10
_mup_Bug #882370: spurious failure in pidfile.txt: "pid file was not removed" <Launchpad itself:Triaged> < https://launchpad.net/bugs/882370 >04:10
lifelesspoolie: again, what makes this spurious? Do you know that the thing actually stopped and didn't get lost?04:11
mwhudsonwgrant: didn't you work on ddebs for ppas a bit ages ago?04:11
pooliewhat does "actually stopped and didn't get lost" mean?04:11
lifelesspoolie: we have a recurring issue with test helpers going awol and not shutting down04:11
wgrantmwhudson: I did.04:12
mwhudsonwgrant: did that ever get anywhere?04:12
lifelessa pid file not being deleted is often also a symptom04:12
wgrantmwhudson: For PPAs? It's believe to be finished, with a small fix Julian made last week.04:12
mwhudsonwgrant: also if i say "ddebs" and "derived distros" in the same sentence, will the result be hollow laughter?04:12
mwhudsonwgrant: oh cool04:12
wgrantmwhudson: Not fully tested, and can't be at the moment, because DF is screwed.04:12
wgrantPrimary archives are another matter.04:12
wgrantThey have an implementation constraint that I consider to be false.04:13
poolieperhaps we have different meanings of 'spurious'04:13
wgrantA very onerous implementation constraint.04:13
mwhudsonwgrant: i'm looking at https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-ubuntu-leb-dbg-pkgs-support you see04:13
pooliethese tests failed when i didn't (afaik) touch anything related to that test04:13
wgrantIt is said that ddebs must live in a separate archive.04:13
poolieand they're not consistently failing04:13
lifelesspoolie: that still fits the symptoms we've experienced.04:13
wgrantmwhudson: Well, the Soyuz team can probably fix that oh wait.04:13
mwhudsonwgrant: ok04:13
StevenKNow now04:13
poolieare you saying this is not a bug, or are you saying it's a dupe of a known bug?04:13
lifelesspoolie: that said, the test helper has timing code all over it04:14
wgrantmwhudson: So, PPA ddebs are probably a couple of months away.04:14
lifelesspoolie: I was investigating to assess that, yes.04:14
wgrantmwhudson: Primary archive ddebs are an undefined period of time and convincement of IS and Julian away.04:14
mwhudsonwgrant: thanks04:14
mwhudsonwgrant: is there a LEP or anything for PPA ddebs?04:15
poolieso on the face of it, it seems spurious that this test would fail based off this change04:15
mwhudsonor anything i can link to, for that matter04:15
lifelesspoolie: oh, I don't think your change provoked it04:15
pooliei can't see any known bug about this test04:15
poolieare you saying you didn't want me to file a bug?04:15
wgrantBug #74755804:15
_mup_Bug #747558: PPAs should create backtracable packages <escalated> <ppa> <qa-ok> <Launchpad itself:In Progress by julian-edwards> < https://launchpad.net/bugs/747558 >04:15
lifelesspoolie: the question was whether it was related to the test reliability issues we've been having on and off, or a different low-frequency issue all of its own.04:15
lifelesspoolie: I think its all of its own and I've commented in the bug04:15
lifelesspoolie: filing the bug was the right thing to do04:15
poolieany test that has the line 'time.sleep(0.1)' is prima facie a critical bug ;)04:16
lifelesspoolie: tests that break in buildbot and cause 4 to 8 hour team stalls are, and for all that its low frequency this may well fit that04:17
pooliethis bug and the previous one caused ~5h stalls for me04:18
poolieif it had happened in bb it could have been worse of course04:18
StevenKlifeless: So, initializing the view gives the output as ""04:18
mwhudsonwgrant: i just read your explanation of how ddebs.ubuntu.com works04:18
poolielifeless: i wonder if AWS is having some kind of underlying issue that is provoking more timing bugs04:18
wgrantStevenK: No, *rendering* the view does.04:18
StevenKlifeless: wgrant thinks that there is METAL madness involved.04:18
wgrantmwhudson: Sorry, I should have warned you.04:18
wgrantStevenK: sinzui's theory is possibly more relevant for this view.04:18
poolieeg something in the virtualization layer is making the machine clock irregular04:18
mwhudsonwgrant: yeah, i may not sleep properly tonight04:19
lifelessmwhudson: :)04:19
poolietwo failures in a row seems suspicuous04:19
lifelesspoolie: that would be epic win wouldn't it ;)04:19
poolieor, perhaps they're just bogging down sometimes04:19
poolieeg this test waits only 2s for the thing to complete04:20
poolieor possibly even less04:20
poolieit's pretty plausible you could get >2s lag on a very loaded host04:20
lifelessI need a rabbit sanity check04:20
lifelessis it *possible* for rabbit to buffer messages in an exchange and send them to a queue that is subsequently bound to it ?04:21
StevenKwgrant: My brain has melted, what was his theory?04:21
wgrantlifeless: I imagine that such a race would be possible in rare circumstances.04:21
lifelesswgrant: I have one nonreproducable failure.04:22
wgrantStevenK: XRDS04:22
lifelesswgrant: test_rosteta_branches_script_oops gets 7 oopses included some with storm DisconnectionError and similar in it04:22
lifelesswgrant: my only theory is that having the exchange with -no- queue at all (e.g. tests in a too-low-layer) actually buffers04:22
StevenKwgrant: eXtensible Resource Descriptor Sequence? Srsly?04:23
wgrantStevenK: Correct.04:27
poolieew doctests04:27
StevenKwgrant: So where do I start?04:29
wgrantStevenK: Work out what's returning ""04:29
lifelesshttp://www.rabbitmq.com/tutorials/tutorial-three-python.html says 'The messages will be lost if no queue is bound to the exchange yet'04:30
lifelessso that rules out that scenario04:30
wgrantIt doesn't.04:30
lifelesswgrant: how so ? stale appserver helper s?04:30
StevenKwgrant: So create_initialized_view() ; view() should be enough in the usual case, right?04:30
wgrant1) It's a tutorial.04:30
lifelesswgrant: on the rabbitmq site04:30
wgrant2) It probably just means "You can't rely on messages not being lost"04:30
wgrantStevenK: Yes.04:31
lifelessI find reading what is written usually works.04:31
poolielifeless:  i realize it's intermittent but it offends me04:31
wgrantlifeless: Not in a tutorial, and not from rabbitmq.04:31
poolieshall i just bump it up to waiting 20s?04:31
lifelesspoolie: I take it you also cannot see a cause04:31
pooliei've looked for races and i don't see any04:31
lifelesssounds like a (painful) workaround04:32
pooliethe fact that it's been there for >2 years but hit only intermittently suggests it timing related04:32
poolieespecially as i  had another perhaps timing related thing today04:32
pooliei was wondering about making it also report if the process still exists04:32
lifelessthat might help with diagnostics04:33
StevenKwgrant: I think lib/canonical/launchpad/webapp/publisher.py, line 296 is to blam.05:01
StevenK"Oh, Person:+index is a redirect, return u''"05:02
lifelessStevenK: you may need to pass in a layer (not test layer)05:02
wgrantStevenK: pdb will tell you...05:02
wgrantBut I doubt it.05:02
lifelessStevenK: this is one of the extra params IIRC. Or something.05:02
StevenKwgrant: I discovered it because of pdf05:03
StevenKI've been tracing for a while05:03
StevenKHm, or not.05:03
StevenKreturn self.render()05:03
wgrantIt's probably feeds or XRDS interacting badly, but step through in pdb and find out.05:04
poolielifeless: https://code.launchpad.net/~mbp/launchpad/882370-pidfile/+merge/8053605:06
poolienot the most satisfying series of patches05:06
pooliei'm going to run some errands05:06
=== almaisan-away is now known as al-maisan
StevenKwgrant: I'm in the middle of zope.tales, so it must be doing useful stuff05:13
wgrantWhich suggests that it may in fact be METAL.05:16
StevenK        if current_url != expected_url:05:18
StevenK            self.request.response.redirect(expected_url)05:18
StevenK            return ''05:18
wgrantI found that within 5 seconds of you.05:19
StevenKIn lib/lp/services/openid/browser/openiddiscovery.py05:19
wgrantWas just switching over to paste that same thing.05:19
wgrantAlthough I was 3 seconds later than you :(05:20
StevenKI'm on my laptop due to my desktop being busy with this evil program called dd, so I was a little slower than pasting05:21
wgrantSo, that would do it.05:21
StevenKCurrent URL:
StevenKExpected URL: http://launchpad.dev/~team-name-15089805:23
wgrantRight, the fake request (LaunchpadTestRequest, probably) used by create_initialized_view doesn't have a sensible URL.05:24
wgrantBecause most things are sensible enough to not require one.05:24
StevenKRight, I was just thinking that LTR is probably implicated.05:24
StevenKCan't we create a request and toss that into create_initialized_view()?05:25
StevenKI have this feeling I've seen that done. *Where* ...05:26
wgrantYou could also change create_initialized_view to set the URL to canonical_url(obj, view_name)05:29
StevenKcreate_initialized_view takes a server_url param05:30
poolielifeless: thanks05:30
lifelesswgrant: I'm not going to move the lp_sitecustomise line; I worry its order dependent because its doing monkey patching.05:31
lifelesswgrant: or am I wrong ?05:31
lifelesswgrant: ah, I'm wrong.05:31
wgrantlifeless: I thought that as well, but it's in the sort of file where that would surely not be well-placed.05:32
StevenKCurrent URL: http://launchpad.dev/~team-name-333852/05:35
StevenKExpected URL: http://launchpad.dev/~team-name-33385205:35
StevenKThey both call canonical_url, why does one have a slash and the other doesn't ... :-(05:37
wgrantThe / will be because you asked for the +index view.05:37
wgrantI suspect the other one just asks for the object.05:37
StevenK    if not server_url:05:39
StevenK        server_url = canonical_url(context)05:39
StevenK        expected_url = canonical_url(self.context)05:39
StevenKIf both contexts are the same, the URLs should be equal05:41
lifelesswgrant: I've just pushed rev 14150 if you want to do an incremental review. I've added autosync to the attachOopses() call, which will hopefully result in these naughty oopses being sucked up earlier.05:41
lifelesswgrant: I've added de-duplication of oops ids to accomodate that05:42
wgrantlifeless: I considered asking for that, but it sounds like it could be slow.05:44
wgrantAlthough I guess it shouldn't be.05:44
lifelesswgrant: if it passes ec2, I should have some timing data06:12
lifelesswgrant: so we can assess, and we'll know06:12
wgrantlifeless: To an extent.06:12
wgrantBut yes.06:12
wgrantThe security declarations for Bug are... special.06:13
wgrantNotably, there are some attributes listed that I've never heard of.06:14
wgrantAnd they are in no order whatsoever.06:14
=== al-maisan is now known as almaisan-away
jtvAny reviewers in the house?  https://code.launchpad.net/~jtv/launchpad/pre-876594/+merge/8053707:11
nigelb"me" is new.07:13
nigelbhah, ok, lifeless.07:13
jtvThanks for figuring that out, Nigel.  :)07:15
jtvlifeless: could I trouble you for a review?  It's this one: https://code.launchpad.net/~jtv/launchpad/pre-876594/+merge/8053707:15
jtvNot very exciting stuff, I'm afraid.07:15
=== lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 266
jtvYou had me there for a moment.07:16
lifelesswell, its 8pm, well past EOD07:16
lifelesseven for extended-batteries-lifeless07:16
lifelessI'd forgotten to update the topic07:16
lifelessjtv: done07:27
jtvthanks lifeless07:34
=== rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba* (allenap) | Critical bugtasks: 266
jtvmorning rvba07:37
rvbaHey jtv.07:37
jtvrvba: I didn't make very much progress on your query, except to find a sort of rock-bottom reason why it's slow.07:38
jtvSee email.07:38
rvbaSaw your email, with many more details, your reach the same conclusion I did: rows=336922, that's a huge number.07:38
jtvYou may be wondering why I said it's not worth counting if the owner owns as little 1% of the branches.07:39
rvbaSo I suppose the comment that lifeless put on the bug itself (that the is a way to use StormRangeFactory (tweaking involved)) is the only way to go.07:40
rvbajtv: Yes I do.07:40
jtvIt's because with 1% of the branches, you could still end up touching a large portion of the table pages.07:40
jtvWorst case, you need to touch 1 branch per page.07:40
jtvIf you can skip the count, great.07:41
rvbaWell, using StormRangeFactory would avoid the count, I suspect the perf of the page would be dramatically improved.07:41
jtvProbably, yes.07:41
jtvYou'd also be rid of the OFFSET.07:42
jtvWhich could matter if we just grew a few hundred thousand branches recently.07:42
lifelessprivate branches will be getting overhauled by disclosure07:43
lifelessI suggest talking to them about the schema changes planned - the schema drives performance here in fairly significant ways07:43
jtvThe 300K branches were private on dogfood but public on staging.  They're only a problem when they're public, but I assumed they'd be public in production.07:45
jtvThe private-branches part isn't much of a performance problem, apart from a lot of repetitive querying.07:45
rvbaAll the explains I've done are on production.07:45
jtvSo this isn't tied to branch privacy.07:46
lifelessjtv: I did a previous optimisation pass in june or so, because its a problem :)07:46
lifelessjtv: but if you've newer data than I, great.07:46
jtvNot for what rvba is looking at.  In other words, you probably solved the problem as far as private branches are concerned and we're left with public branches as the bottleneck.07:47
rvbaThe small improvement I did with counting private branch (simply caching the results) will help a little.07:47
rvbaBut like jtv said, the main problem is counting the public branches.07:48
jtvIt got a bit faster when I omitted the "transitively_private is false" condition from the public-branch count,07:48
jtvbut still not as fast as counting public and private branches separately & adding up the numbers afterwards.07:48
lifelessrvba: just a style thing - I'd hesitate to use a cached property on GenericBranchCollection07:50
lifelessrvba: I suspect it could easily lead to incorrect behaviour07:50
lifelessrvba: its really a fancy query builder; any caching should be done on the resulting query07:50
rvbalifeless: my goal was to cache the results of a subquery that is repeated more than 10 times.07:51
lifelessrvba: why is it repeated 10 times?07:52
lifelessrvba: also are you aware that passing in long IN clauses can trigger inappropriate sequential scans ?07:52
lifelessrvba: [so if you expect thousands of entries in an IN clause you may need to move to a temp table, insert, analyze, then query]07:52
lifelessrvba: I certainly agree with jtv's suggestion that a union may be better here07:53
rvbaRight, I still need to make sure that the worse that can happen with the IN query is a few thousands.07:53
rvbaI've not used a with query because I wanted to improve lots of queries at once.07:54
lifelessas a data point, the last time I touched this code I fixed one page and broke another07:54
lifelessqa on this will be tricky07:54
lifelessah, ubuntu-branches, \o/07:55
rvbaAnd I confess I'm not sure why I have so many different queries using this subquery, I must say that this code is a little bit spaghetti like, but anyway, this was just a first attempt I made before jtv & I realised this was really not where the improvement should be done.07:55
lifelessso the plan issue is the hashed SubPlan 1, I think07:56
rvbaI think the potential problems of this IN query optimisation are probably not worth the improvement it brings … I shall see if stormrangefactory can be applied.07:56
lifelessselect count(*) from branch where owner=2866082;07:56
lifeless count07:56
lifeless 33801607:56
lifeless(1 row)07:56
lifelessTime: 284.695 ms07:56
lifeless343ms with the lifecycle status07:57
rvbai've only touched the surface of if so far, but this stormrangefactory is a very, very nice piece of work I must say.07:57
lifelessthis is consistent with my previous memory07:57
jtvThat's a lot faster than on the test servers.07:57
lifelessthe public branch is not the issue07:57
rvbaThat's a typical 1s query that the page is doing:07:58
lifeless710ms with the transitively_private check added, which is odd.07:58
rvbaThe related explain: https://pastebin.canonical.com/54886/07:58
rvbaI suspect if you add the lifecycle_status check it will take 1sec.07:59
lifeless743ms with owner + lifecycle_status + transitively_priate08:00
jtvlifeless: the slowdown from the privacy check may be something to do with access patterns within the page.  Do you know off the top of your head where a tuple's visibility-related info is stored?  Maybe it's a compact blob at the beginning of the page.08:00
rvbaI said typical because like I said earlier, many similar count queries are generated by this page (https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-2124AO73)08:00
lifelessjtv: you thinking a repack or something ?08:00
jtvWasn't, but always a nice thought.  :)08:01
jtvOh, I think I know.08:01
lifelessjtv: I don't know that bit of the layout, no.08:01
lifelesschecking private (the old column) isn't visibly faster08:01
adeuringgood morning08:02
rvbaMorning adeuring!08:02
lifeless480k branches in total08:02
adeuringhi rvba!08:02
lifelessso this is getting 66% or so of pages08:02
jtvlifeless: IIRC there's a shortcut for determining that all tuples in a page are visible.  We won't make full use of that without index-only scans, but it probably still means that the liveness check has better locality than actual tuple data check.08:02
jtvhi adeuring08:02
adeuringhi jtv08:03
jtvOnce you start looking at the actual data, you do need to look at the tuple's data.08:03
jtvUntil then, just visibility metadata.08:03
lifelessanyhow, given we're getting 2/3rds of the data, the seq scan is appropriate08:03
jtvEven for a few % of the data it would be appropriate.08:04
jtvWhy aren't we ever discussing clustering?08:04
jtvNot that I know what to cluster _on_…08:05
lifelesswell, partly because it needs downtime :)08:05
lifelessalso its not maintained by vacuum08:05
jtvWhy does it need downtime?08:05
lifelessand the online adding scares me ;)08:05
lifelessjtv: 'When a table is being clustered, an ACCESS EXCLUSIVE lock is acquired on it. This prevents any other database operations (both reads and writes) from operating on the table until the CLUSTER is finished. '08:06
jtvThat's no good.  :/08:06
jtvI thought vacuum maintained clustering, if you assigned a clustering index.08:06
lifelesswell, let me be precise08:07
lifelessI know that autovacuum does not08:07
lifelessI believe that vacuum also does not. IMBW on this one.08:07
lifelessrvba: so looking at that oops08:07
lifelessslowest query is the BMP one08:07
lifelesssecond slowest is is the count of branches08:08
lifelessthird is the retreival of the branches batch08:08
rvbaYes, again, a count(*), and you can see the repeated In subquery, hence my first idea to cache the result of this subquery.08:08
lifelessrvba: yes, I get that... note though that that the fact you're querying in against so many public branches will reduce that impact ;)08:11
lifelessrvba: which you already know08:11
lifelessrvba: so I suggest a different tack on the analysis08:12
lifelessrvba: lets ask what would be the fastest way to implement the slowest part of the page08:12
lifelessrvba: and then fix that08:12
lifelessrvba: (one fast way is to not do something at all)08:13
lifelessrvba: the branch mergeproposal count isn't in a batch08:13
lifelessrvba: and we'll cut 3.7 seconds out if we stop showing it; 1.8 if we get a 50% improvement there.08:13
rvbaNote that the total sql time is ~10s so we have a long way to go ;)08:14
lifelessrvba: fixing 30% of that would be a pretty good start :)08:15
rvbaI suppose that there is one count for the batch, and the rest is to display the numbers in the right hand side portlet.08:15
rvbaThat is a costly portlet :)08:16
=== almaisan-away is now known as al-maisan
lifelessworking page: https://code.launchpad.net/~rvb/+branches08:16
lifelessrvba: yes, note that https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-2124AO73#longstatements top-N 508:16
rvbaYes, that's precisely the one I'm looking at.08:16
lifeless5. 948.0 1 SQL-main-master 08:17
lifelessSELECT BranchMergeProposal.commit_message,08:17
lifeless       BranchMergeProposal.date_created,08:17
lifeless       BranchMergeProposal.date_merged,08:17
lifeless       BranchMergeProposal.date...08:17
lifelessthat seems total waste08:17
lifelessas the reviews are not show.08:17
lifelessso you can save 1 second by fixing htat bug.08:17
lifelesswork not done is cheap :)08:17
nigelbI never knew there would be a day I'd be reviewing danilos' code :P08:17
rvbalifeless: Very true :)08:18
lifelessrvba: I have to wonder if showing a count of subscribed branches is needed08:20
lifelessrvba: e.g. perhaps we shouldn't show random users how many branches someone is subscribed too, nor what they are subscribed to. Perhaps we should.08:22
lifelessits consistent with what we do to bugs, so I wouldn't arbitrarily change it08:22
rvbaAlso, maybe the numbers are not that important, but maybe the links are for some workflows, maybe we could remove the numbers and keep the links.08:23
rvbaLots of 'maybe' :)08:23
lifelesscontrast with https://bugs.launchpad.net/~rvb/08:23
lifelessno numbers there08:24
lifelessthat is perhaps a sensible first step; get us some headroom08:25
lifelessmore consistent with the bugs application08:26
bigjoolsmorning all08:26
nigelbMorning bigjools08:26
nigelb*snicker* English cricket team.08:27
rvbalifeless: That's a good idea, and an easy fix :). Should we run this past someone first?08:27
StevenKEnglish "cricket" team.08:28
bigjoolsnigelb: you mean the #1 test team?08:28
lifelessrvba: up to you :) - I'm one of the people it would be run past :P; secondly you'll need to convince a reviewer that its reasonable, and they can always suggest you seek UI discussion too08:29
nigelbbigjools: Yeah, the one that didn't win a single match :P08:29
bigjoolsnigelb: that'd be you guys over here then?08:30
nigelbApparently our respective teams perform only in their home country.08:30
rvbalifeless: ok, I think the argument will depend on the perf improvement it brings, I'll do it, have it reviewed, and the will we evaluate the benefit it brings on staging. As this time we could have the UI vs. performance arguement08:30
nigelb(Not like I watched either set of matches)08:30
lifelessrvba: you can feature flag it08:31
lifelessrvba: makes the decision to flip the flag separate to the coding aspect08:31
rvbalifeless: Good idea, this way we can test it on production.08:32
bigjoolsnigelb: yes, for someone who doesn't like cricket, you seem to spend a lot of time talking about it :)08:32
nigelbbigjools: I follow StevenK's principle about cricket :D08:32
=== jtv is now known as jtv-eat
lifelessallenap: you are added now09:14
allenaplifeless: Thanks, I saw that, and uploaded 0.0.6 last night.09:15
nigelbrvba: Congrats!10:00
rvbanigelb: thanks ;).10:04
=== jtv-eat is now known as jtv
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
rvbanigelb: brutal reviews…?10:43
nigelbrvba: where you nitpick every line.10:44
rvbarvba: There are a few "fascists reviewers" out there.  But I'm not one of them ;).10:44
nigelbrvba: You should be.10:44
rvbaI follow another way to do things, no brutality involved :)10:45
rvbaIt's called the Panella style.10:45
nigelbI'm too used to the jv/fascist style.10:46
bigjoolsthe best reviews are the ones that make me think about what I am actually doing10:46
nigelbA lot of times I see my code evolve from "this works" to "this works and looks pretty neat as well" during code review.10:47
=== Ursinha-afk is now known as Ursinha
=== rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba | Critical bugtasks: 266
=== al-maisan is now known as almaisan-away
=== jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba, jcsackett | Critical bugtasks: 266
rvbaMorning jcsackett.13:06
jcsackettmorning, rvba. thought you were on monday shifts now?13:06
rvbajcsackett: yeah, but I'm finishing today's shift since I'll be off on Monday.13:07
jcsackettAh, dig.13:07
deryckMorning, all.13:08
jcsackettMorning, deryck.13:17
deryckrvba or jcsackett -- I have a js branch for review if either of you care to review it.13:20
rvbaderyck: sure.13:20
deryckrvba, thanks!  https://code.launchpad.net/~deryck/launchpad/buglists-orderby-widget/+merge/8056313:21
flacostemorning deryck!13:31
rvbaderyck: just checking: the code in the demo is in sync with the code in the MP?14:10
deryckrvba, on call, sorry, just a sec.14:14
deryckrvba, ok, off now, sorry.  by demo do you mean the html stuff at people.canonical.com?14:20
rvbaderyck: I'm asking because if I click on 'Importance' then on 'Bug heat' and then repeat the operation, I get this: http://people.canonical.com/~rvb/big_button.png. Looks a space somewhere is not removed.14:20
rvbaderyck: yes14:20
=== almaisan-away is now known as al-maisan
rvbas/Looks/Looks like/14:21
deryckrvba, yeah, so the demo version was just a proof to get the interaction down.  The widget doesn't copy it exactly, and that particular issue should be fixed in the widget.14:21
rvbaderyck: Ok.14:21
deryckrvba, it's due to popping a span on the li for the arrows, and in the final version you're reviewing the span is always there.14:21
rvbaderyck: Right, I saw the code was not exactly the same but if you're aware of the issue in the demo that's fine.14:22
deryckrvba, gotcha.14:22
=== al-maisan is now known as almaisan-away
flacostervba: congratulations on achieving reviewerhood!14:26
rvbaThanks flacoste!14:26
deryckrvba, thanks for the review!  I've no issues with anything you mention and will take your suggestions up before landing.14:29
deryckoh rvba, I did like the suggestion for the tearDown destroy, but the one place it's not used is not needed because that's an error test.  The render never completes.14:42
rvbaderyck: ah ok.14:43
rvbaderyck: I also suggested that because of http://bazaar.launchpad.net/~deryck/launchpad/buglists-orderby-widget/revision/1421214:46
deryckrvba, yup, it's a good suggestion.14:46
=== salgado is now known as salgado-brb
cr3hi folks, what's the difference between documentation under doc/ in the source tree and dev.launchpad.net?15:00
sinzuijcsackett, pinf15:01
sinzuijcsackett, ping15:01
jcsackettsinzui: ponf/g.15:02
sinzuijcsackett, I have a data fixing script that needs review. I want to talk to you about it since it is not a branch15:02
jcsackettsure, one moment.15:02
bigjoolscr3: hi15:05
bigjoolscr3: the stuff under doc/ is generated and shown at readthedocs. I'm currently looking into sorting the documentation mess out, so bear with me.15:06
cr3bigjools: what's "readthedocs"?15:07
bigjoolscr3: http://launchpad.readthedocs.org/en/latest/15:07
sinzuijcsackett, http://pastebin.ubuntu.com/720766/ and http://pastebin.ubuntu.com/720768/15:09
cr3bigjools: I'm adding documentation to the launchpad-results project which tries to follow launchpad practices as closely as possible, any suggestions for me?15:09
bigjoolscr3: not really :(  I've not started sorting this out yet, it's a fledgling initiative. My main aim is to get low-level API info in the Sphinx stuff so that it lives with the code, and the wiki should contain more higher-level stuff.15:10
cr3bigjools: no worries, since I won't have much documentation for a while, it shouldn't be too difficult to migrate later15:11
bigjoolscr3: I'd use reST markup as well15:12
bigjoolsit's rather flexible15:12
cr3bigjools: I thought about that but then I figured that using text under doc/ the same as the doctests throughout the code might be beneficial, rather than having two formats15:12
bigjoolscr3: doctests suck15:13
bigjoolscr3: the stuff under doc/ is reST15:14
cr3bigjools: I know, I know, but some might be useful. I think the problem is that launchpad has been using them too much and for the wrong purpose, like unit testing in doctests, but I'm not convinced they're all bad15:14
bigjoolscr3: maybe - LP's use is teh suck for sure, but they can get unwieldy very fast IME15:15
cr3bigjools: so, ultimately, the objective would be to have no doctests at all?15:15
bigjoolscr3: that's the majority consensus in the LP team, yes15:16
jcsackettsinzui: r=me on the sql, looks good.15:18
sinzuithank you15:19
jcsackettsinzui: one note on the script. there are two exceptions in which you log, but since those are both errors don't you want to pass in error=true to the log function?15:27
sinzuijcsackett,  no for unauthorized, yes for the WTF !!15:28
jcsackettI figured a comment like "Something went very wrong" implied error logging should be enabled. :-P15:28
sinzuijcsackett, Since I did not get any !! in the log, I did not catch that I needed to report the super error15:28
jcsackettsinzui: otherwise, this looks good to me. r=jcsackett.15:29
sinzuithank you15:29
flacostebigjools: well, there's a disagreement in the sense that some people (at least stub) argues that documentation should be tested15:35
flacosteso a kind of doctest (even if doctest tool isn't used) could be used15:36
flacostei think manuel was suggested15:36
flacosteas it integrates with sphinx15:36
bigjoolsflacoste: well he was the lone dissenter, hence my phrase "majority consensus"15:36
bigjoolsflacoste: right - I need to investigate all this manuel/sphinx etc15:37
bigjoolsabentley: hey do you have a brief moment to talk about canonistack + LP?15:42
abentleybigjools: sure.15:43
bigjoolsabentley: I've got it such that I have the same 9 tests failing every time, and they are a bunch of them in test_lpserve15:43
bigjoolsbecause bzr is outputting:15:43
bigjoolsbzr: warning: unsupported locale setting\n'15:43
bigjoolsIf I can figure out why it does that, we've got a winner15:43
abentleybigjools: I'm not optimistic about using openstack for running tests, because they still haven't fixed my RT about instances not starting properly.15:44
bigjoolsright - I've kept the same one up for a week :)15:45
abentleybigjools: But I would imagine the complaint about locale setting is related to LANG.15:45
bigjoolsabentley: yes - I've tried setting it to en_US.UTF8 and I get the same error15:47
abentleybigjools: And it fails when you run the test by itself?15:48
bigjoolsabentley: tell a lie - it's working now15:48
bigjoolsonly one test failing now!15:48
abentleybigjools: Let's hope it stays that way :-)15:48
bigjoolsabentley: http://pastebin.ubuntu.com/720814/15:49
abentleybigjools: Since it's in an assertRaises, I guess it's raising the wrong exception?15:50
rvbabigjools: I remember having this one failing too!15:50
rvbaabentley: exactly15:50
bigjoolswhich is odd15:52
=== rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugtasks: 266
=== beuno is now known as beuno-lunch
flacostederyck: yesterday on the TL call, in the feature checkpoint when i mentioned that you guys were going to look at multi-sort next16:05
flacostelifeless pointed out that you might hit some performance problems16:06
flacosteas all our bug queries are optimized including the sort order16:06
flacosteyou might encounter case that don't perform well16:06
flacosteso it's something you'll have to be wary of16:06
=== salgado-brb is now known as salgado
deryckflacoste, ah, ok.  Good to know.  adeuring, see ^^16:21
adeuringderyck, flacoste: yeah, that's what I was thinking too...16:22
deryckabentley, ok, I have my head around your branch now.  Can we dialog about this review now?16:48
elmois there a tool for caching Launchpad bugs for offline use?17:01
=== beuno-lunch is now known as beuno
abentleyderyck: I'm free when you are.17:17
deryckabentley, ok.  Let's mumble to make it quicker.17:19
abentleyderyck: sure.17:19
flacosteelmo: i think rick spencer had a LP bugs GUI at some point that was doing something like that17:36
jelmerflacoste, elmo: lp:bughugger17:45
flacosteyep, that sounds like a rick_spencer project name!17:46
jelmerthat's Rick's LP bugs GUI, not sure how much offline support it has though17:46
flacostethanks jelmer17:46
jelmerflacoste: :)17:46
flacostei know it was downloading the bugs api representation in a local cache and then was operating the gui from that17:46
nigelbflacoste: brian murray had something like that. Maybe its the same project.17:57
elmoflacoste, jelmer: thanks - that's trying to install desktopcouch and stuff and looks dead upstream18:04
elmoI guess it'll be easy to do a dumb cache with launchpadlib18:04
flacostewow, yeah, that's dead18:05
flacostethe hug of death18:05
nigelbdesktopcouch is dead?18:07
nigelbDoesn't Ubuntu use it in a lot of places?18:07
nigelbOr is it couchdb.18:08
nigelbelmo: james_w had some API demo that did some offline stuff.18:08
nigelbAt Belgium.18:08
james_wI assume that elmo wants something that works18:08
nigelbjames_w: A common feature of your lightning talks :P18:09
elmonigelb: desktopcouch may or may not be dead - I just don't want (any more of) it installed on my machine if I can avoid it.  my 'dead' comment referred to the fact there haven't been any code changes to bughugger in almost a year18:11
sinzuijcsackett, ping18:11
nigelbelmo: Ah, right. Its unloved.18:14
elmo The Launchpad API is currently in beta, and may well change in ways18:16
elmo incompatible with this library.18:16
elmois that still true?18:16
deryckelmo, depends on which version of the api you're using.  there is a beta, a 1.0, and a devel.18:24
deryckor maybe I just inserted myself in a conversation without context. :)18:25
elmowell, that comes from the package description for python-launchpadlib18:26
deryckI would guess launchpadlib uses the 1.0 api now.18:26
jcsackettsinzui: sorry, didn't see your highlight an hour ago.19:11
sinzuijcsackett, I reported https://bugs.launchpad.net/launchpad/+bug/882714 and attached the script that I have used.19:12
sinzuijcsackett, please review the script, I want an admin to run it once to retire it19:12
jcsackettsinzui: happily. :-)19:13
jcsackettsinzui: big script, eh? may take a bit.19:15
sinzuijcsackett, you do not need to know every project in the dict. that is what I collected in the evening reviewing projects one January19:16
jcsackettyeah, i just realized that the dicts could be skipped.19:16
jcsackettquite a bit shorter without that. :-P19:17
jcsackettsinzui: you say you've been using this script before?19:22
flacostederyck: yes, it does, we should update the package description19:22
flacosteor the Ubuntu maintainer should19:22
sinzuijcsackett, I run it once a month19:22
jcsackettsinzui: i see nothing i can add about or too this script, looks good.19:23
jcsackettr=me, sinzui.19:23
sinzuiit fixes about 1 project every other run because the user gave ~registry the project19:23
deryckabentley, I have bug listings reordering now.  it all works with very few lines changed.20:34
deryckabentley, http://pastebin.ubuntu.com/721063/20:34
abentleyderyck: Awesome!20:34
benjihi jcsackett, do you have time to review this for me?  https://code.launchpad.net/~benji/launchpad/bug-877195-code/+merge/8061720:35
jcsackettbenji: sure thing.20:35
deryckabentley, I still need to setup the widget correctly, to match actual sort orders we use.  And then some css and we're good.20:35
abentleyderyck: Cool.  I've got the polish basically done.  It now updates the batch info "1 → 5 of 256", the actions are green if active, and the actions are greyed out if not applicable.20:37
deryckabentley, very nice.20:37
jcsackettbenji: just checking, is there any reason you didn't set the pre-req branch as the pre-req in the MP?20:38
benjijcsackett: heh, I just realized that I should do that20:39
jcsackettcool, if you could resubmit with that i'll pick up that MP, so i know what i should be looking at. :-)20:39
jcsackettbenji: i've got it now. thanks.20:42
mwhudsonso the launchpad thing that kills idle transactions... is that reusable at all?20:42
lifelessisd and u1 use it already20:43
lifelessshould ust be a matter of asking losa to configure it up20:44
pooliehi all20:45
benjimorning, lifeless; I left a present on your doorstep (or stubs, but I figure he's somewhat distracted right now): https://code.launchpad.net/~benji/launchpad/bug-877195-db/+merge/8061820:50
lifelessbenji: you're a good cat. Miaow.20:51
lifelessbenji: what are lines 54 and 55 for ?20:52
lifelessbenji: or is it just a confusing diff ?20:52
benjilifeless: they are to make something unrelated to my change stop barfing.  when I run "cronscripts/run_jobs.py pofile_stats" without those lines I get exceptions about them being missing20:53
lifelessbenji: if you copy lines 61 and 62 up, then bzr may anchor the diff better20:54
lifelessits a confusing diff basically.20:54
mwhudsonlifeless: ta20:54
benjilifeless: will do20:54
lifelessbenji: more importantly, you need to bzr add your schema change20:54
benjilifeless: ooh, indeed20:54
lifelessbenji: also, this should be in two pastches20:54
lifelessbenji: a) schema only20:55
lifelessbenji: b) the lazr.conf and any other code things20:55
lifelessbenji: because we don't deploy from db-devel20:55
benjilifeless: oh, so I should move the schema-lazr.conf changes to the code branch; ok20:56
lifelessbenji: yah, db-schema != config-schema20:56
jcsackettbenji: r=me on the code changes as is. i gather from the above you'll have another branch with the schema changes? :-P21:00
benjijcsackett: yep; thanks!21:00
jcsackettsinzui: the post-oneiric-install script you pointed me at last week is somewhat frightening in all that it does. :-P21:01
sinzuiyes, but you should consider that that script is very similar to what many deb packaging scripts to at build and install phases21:02
flacostebenji: i think you code as tiny but (i think benigh) race condition21:02
flacostebenji: it could still end up creating two POFile job21:02
flacostesince there is no constraint preventing two from existing at the same time21:03
lifelessflacoste: uhm hi21:03
flacostebut i think we don't care about that, right?21:03
sinzuiI image that a a tuning script framework could be written to get the most out of several lines of computers. I have a sony that also needs special drivers configured to the the keyboard tor rock21:03
benjiflacoste: hmm, you may be right21:03
lifelessflacoste: I've just replied to your new RT - I think we need to coordinate on that a bit more :)21:03
flacosteit would simply waste some CPU cycle21:03
flacostelifeless: that last statement was adressed to benji, just in case, you got hit by paranoia overnight21:04
lifelessflacoste: :)21:04
lifelessno paranoia, I *know* they are out to get me!21:04
flacostethat's why i tell myself whenever i see an (american) football scrum!21:05
flacostethey are plotting against me!21:05
flacostelifeless: so basically, the DB load problem isn't for the normal situation, but for the fail-over one?21:06
lifelessflacoste: theres a few interlocking things21:07
lifelesslet me just pull up some rports21:07
lifelessflacoste: this might be easier in voice21:10
flacostelifeless: then let's skype, there are a couple of things to cathc-up on from the LP/IS call21:11
benjiflacoste: yeah, there is a race there (well, it's not technically a race, but the opportunity for the same POFile to be scheduled for an update multiple times); since updates take 20 or 30 seconds and they could be scheduled tens of times in a particular update window) I'm inclined to collapse them if you don't object21:11
flacostebenji: sure21:11
flacostebenji: you mean at processing time?21:11
jcsackettsinzui: that seems reasonable. i'm just trying to sort out what differs between macbook5,1 and macbookair4,2.21:11
benjiflacoste: I figured I'd do it at job creation time, but in a simple, actually racy way that would eliminate the vast majority of duplicate jobs but still be very straightforward21:12
flacostebenji: makes sense21:13
flacostesoviet enginerring21:13
flacostethe Launchapd way :-)21:13
benjiflacoste: makes me think of the US SR-71 spy plane, it got so hot during flight that it was built with gaps, so when they fueled it up on the ground it would leak until it got into the air and the gaps would close21:16
benjilifeless: https://code.launchpad.net/~benji/launchpad/bug-877195-db/+merge/80618 looks better now21:21
lifelessbenji: are you intending to address bug 781274 as pat of your arc?21:56
jcsackettsinzui: i'll be a few minutes late to standup.21:58
lifelessbenji: reviewed22:04
benjilifeless: thanks; I'll take a look at that bug tomorrow and see what I can do with it22:05
pooliebenji: istr lots of people got cancer from dealing with the consequences of that design22:09
pooliehow naive would it be to want to move some build jobs onto ec2 instances (not necc AWS ec2)22:10
poolieactually that might be too big of a question for irc22:10
benjipoolie: well, that's quite a symptom for trying to make a change to software, but I like a challenge22:11
lifelesspoolie: build jobs?22:13
pooliesr-71 leaking fuel22:13
lifelesspoolie: '11:10 < poolie> how naive would it be to want to move some build jobs onto ec2 instances (not necc AWS ec2)22:15
poolieoh, yes, build jbos22:15
lifelesswhat do you mean by build jobs, specifically.22:15
=== jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 266
pooliethe work done by buildds22:15
poolieto accommodate people who want more or larger buildders22:15
pooliei realize there are trust issues about running some jobs on hardware we don't specifically control22:15
lifelessso, buildds are trusted machines, because their output runs as root on other peoples machines.22:15
pooliebut perhaps for other jobs it would be an ok tradeoff22:15
lifelessec2 is very expensive in lots of ways22:16
lifelessso even if we handwave the trust aspect away22:16
lifelessI doubt it would make financial sense22:16
lifelessinternal cloud, perhaps.22:16
pooliewell, at the moment the price is infinite :)22:17
lifeless(but thats what the builders basically are anyhow, except they have a -very- tuned image-start process (we can bring up a slave in a second or so)22:17
poolieanyhow, so the answer is basically:22:18
poolietrust, and cost?22:18
lifelessthose are the nontechnical bits yes22:19
jmlpoolie: people have asked for that though22:19
jmlpoolie: openstack, notably22:19
lifelesstechnically, we'd need some fairly deep changes to the idea of a builder (ephemeral vs static), and obviously the implementation of protocols to deal with ec222:19
pooliejml, right, it seems like trust and cost is something that a user can make their own decision about22:20
jmlwho really dislike the fact that their development process can be disrupted by the whims of Ubuntu22:20
poolieassuming it's technically feasible for them to pay the financial cost22:20
jmlpoolie: and also financially feasible :D22:20
StevenKjml: But it can be anyway -- if they are building against precise, library changes can impact them.22:20
lifelessThe way I would address trust and cost is to allow a ppa to choose to use our cloud (existing builders) or supply their own cloud credentials22:20
jmlStevenK: but again, that's something they can choose22:21
poolieso my question was really how deep that is22:21
jmllifeless: you might also want info about that choice on the PPA page for prospective downloaders.22:21
lifelesspoolie: a couple man-weeks + review deployment and friction22:21
lifelessjml: yes, and/or even in the archive metadata22:22
lifelessjml: I don't think the thinking about it is complete yet22:22
pooliejml, info for prospective downloaders about where it was built?22:22
lifelesspoolie: about whether its trustable like things built on our cloud22:22
lifelesspoolie: e.g. was it actually built from the source we think it was.22:22
lifelesspoolie: for something out of our control the answer has to be 'unknown'22:23
pooliei suppose there is a channel there whereby running on aws gives them a chance to inject things not visible in the source22:23
pooliethough, this is a little academic if you're already trusting the author to provide all the source22:23
lifelessperhaps :)22:23
lifelesssee under reflections on trust22:23
poolie'on trusting trust'22:24
lifelessyes, that one :)22:25
pooliei'm just saying that's a bit academic compared to the way people treat ppas today22:25
lifelesse.g. if openstack point at a rackspace cloud because they trust it22:25
lifelesspoolie: there are folk in the distro deeply concerned about the way people treat ppas today ;)22:25
pooliefor instance that every ppa can upgrade any package22:26
lifeless-> because it installs as root22:26
lifeless-> and can change anything22:26
pooliesure, i sympathize with them, i just don't think the idea that AWS is malicious or subverted would be very high on the list22:26
lifelessThere is a 'any unnecessary risk is too much' mentality, which to a large extent I agree with.22:27
lifelessin this area22:27
poolieit's true this is opening up some new risks22:28
pooliethat would be a tradeoff against allowing these people to use the system at all, vs not building packages, or building them on entirely separate machinery22:28
poolieor not getting a good quality of service22:28
lifelessyes, but that doesn't mean we should do it :) - the tradeoff may not be worth it.22:45
poolieyes :)22:50
pooliecan i navigate back to previous builds from https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk23:20
wgrantI don't believe so.23:28
wgrantMore string interpolation to generate HTML.23:36
wgrantWithout escaping.23:36
pooliewgrant:  at least one build has passed of a package that was previously reported to be failing23:43
wgrantThat's an odd place to build it into :)23:44
pooliegar, unix copy and paste again23:45
poolieno, actually23:46
pooliei was fooled by the 'request builds' having an interesting default23:46
wgrantYeah, the alphabetically first PPA by display name.23:47
pooliecan i cancel it?23:48
wgrantIt depwaited.23:48
wgrantOh, the new build in ppa:mbp?23:49
wgrantI can cancel it if you want.23:49
poolieah which does not actually mean "i'm waiting" but "i'm not waiting"23:49
poolieno, the new build into my ppa is fine23:49
wgrantFor binary builds it means "i'm waiting".23:49
wgrantBut not for recipe builds.23:49
poolieah ok23:57
poolieok, so on a later attempt, the build into ~mbp failed, but i think after all the bzr work completed23:58
poolieand just because of an actual build problem in the source23:58
poolieso, it's a good sign23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!