[00:03]  * maxb hopes the cell towers are only metaphorically down :-)
[00:08] <lifeless> maxb: at least logically down
[00:10] <huwshimi> Anyone have any ideas why my tests failed? http://paste.ubuntu.com/570317/ (URLError: <urlopen error [Errno 111] Connection refused>)
[00:11] <wgrant> huwshimi: Both known occasional spurious failures.
[00:11] <wgrant> huwshimi: Land the branch manually.
[00:12] <lifeless> http://maps.google.co.nz/maps?f=q&source=s_q&hl=en&geocode=&q=http://magma.geonet.org.nz/services/quake/kml/2.2/search?externalRef=3468575
[00:14] <huwshimi> wgrant: You mean just 'lp-land'? Is there anything else I need to do?'
[00:14] <wgrant> huwshimi: lp-land, yeah.
[00:14] <wgrant> lifeless: 6.3?
[00:14] <lifeless> yeah
[00:14] <lifeless> but shallow
[00:14] <lifeless> so felt it more
[00:14] <lifeless> mum, down in dunedin, felt it
[00:14] <lifeless> thumper: did you ?
[00:14] <wgrant> Ah, very shallow, yes.
[00:15] <wgrant> Any major damage known yet?
[00:15] <lifeless> http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1&objectid=10707996
[00:15] <lifeless> water mains burst, some buildings down, more road cracks
[00:16] <wgrant> .au news sources haven't mentioned it yet...
[00:16] <lifeless> phone lines are down
[00:16] <wallyworld> lifeless: surely you're not asking thumper if the earth moved for him?
[00:16] <wgrant> 5km deep!?
[00:16] <wgrant> That's awfully shallow.
[00:16] <lifeless> wgrant: yup
[00:16] <lifeless> its being called an aftershock for now
[00:17] <thumper> lifeless: yes I felt it
[00:17] <spiv> Ah, I see geonet.org.nz has it as 6.3 rather than 3.1 now.
[00:17] <thumper> lifeless: quite a shaker here
[00:17] <spiv> That's quite a difference!
[00:18] <lifeless> it was felt in wellington too
[00:19] <spiv> USGS says 4km deep +/- 0.5km.
[00:26] <wgrant> lifeless: Why do you invoke PersonSet directly instead of using the utility?
[00:26]  * lifeless shrugs
[00:26] <lifeless> I think we need an object for 'group of <type>'
[00:26] <lifeless> the Sets look ideal for that, if parameterised
[00:26] <lifeless> I was heading slightly in that direction at the time
[00:26] <wgrant> Sure.
[00:27] <lifeless> feel free to do it any which way
[00:27] <lifeless> doing DI on these singletons seems fairly uninteresting
[00:28] <thumper> rumours abound in the office here that the christchurch cathedral is down
[00:28] <lifeless> yup
[00:28] <lifeless> police are saying that
[00:29] <lifeless> though the degree of down isn't clear
[00:29] <wgrant> Ah, now it's hitting the news here.
[00:29] <wgrant> 'Witnesses said there were buildings down all around Cathedral Square in the city, with the church destroyed.'
[00:29] <wgrant> Hmmm.
[00:31] <lifeless> another shock now
[00:31] <lifeless> relatively gentle
[00:36] <wgrant> Ah, the cathedral has just lost its steeple. Not tooo destroyed.
[00:38] <lifeless> the bugger of it is that we're still waiting on a plumber having time to fix some shit for us - but other folk are more badly in need
[00:40] <wallyworld> anyone know why adding @operation_returns_collection_of(Interface) to a method with an existing @export_read_operation() decorator results in:
[00:40] <wallyworld> UnknownEntryAdapter: No IEntry adapter found for Interface (web service version: 1.0).  Encountered as a result of the entry interface None, field ''.
[00:40] <wallyworld> there seems to be several other places in the code where the same pattern is used
[00:41] <wallyworld> and i can't find anywhere where adaptors are defined for those places
[00:41] <wgrant> wallyworld: You need to patch them in lib/canonical/launchpad/interfaces/_schema_circular_imports.py
[00:42]  * wallyworld looks
[00:42] <wallyworld> wgrant: ah that looks like it. thanks.
[00:43] <wallyworld> i was getting a circular import when I tried using ISourcePackageRecipe instead of Interface
[00:43] <wallyworld> wasn't sure how to fix it but now i know :-)
[00:44] <wgrant> http://www.youtube.com/watch?v=qt0iIHXFnR0
[00:44] <wgrant> That's quite a rock.
[00:44]  * thumper stabs the compressed javascript
[00:45] <wgrant> wallyworld: Yeah, it's a bit awful :(
[00:45] <wallyworld> awful is one way to describe it :-)
[00:45] <lifeless> wallyworld: thats sumner
[00:46] <lifeless> bah
[00:46] <lifeless> wgrant: thats sumner; just around the hills from where our rental property was
[00:47]  * wallyworld was wondering what sumner was :-)
[00:49] <lifeless> wallyworld: its a suburb
[00:50] <wallyworld> i know that now :-)
[00:50] <wallyworld> but had to wait for you to post a subsequent message to figure it out :-)
[00:52] <wgrant> lifeless: Congrats!
[00:53] <lifeless> wgrant: thanks
[01:18] <huwshimi> lifeless: Just saw your post: congrats!
[01:18] <lifeless> thanks
[01:20] <huwshimi> lifeless: My wife is three weeks ahead of yours.
[01:20] <lifeless> congrats
[01:20] <huwshimi> lifeless: Thanks. My first. You have others right?
[01:20] <lifeless> nope
[01:21] <lifeless> we're late to the sprogging game
[01:21] <huwshimi> lifeless: Oh, I'm thinking of someone else. Exciting times then
[01:26] <spiv> lifeless: congrats!
[01:26] <lifeless> spiv: thanks
[01:33] <wallyworld> lifeless: you are always on irc etc, don't know where you found the time for species propagation :-P
[01:34] <spiv> Multitasking, perhaps.
[01:34] <wallyworld> spiv: but python is single threaded :-)
[01:35] <lifeless> wallyworld: doesn't mean *I* am :>
[01:35] <wallyworld> lifeless: so you can type and do "other" things at the same time. must have been hard to set up your desk that way :-)
[01:39] <lifeless> no comment, keeping the workplace clean since 1436
[01:39] <lifeless> bbiab, going to try and top up our supplies before supermarket shelves run dry - we have enough but its bland fare, better to have the remainder of fresh meats etc
[02:16] <thumper> what does this do?  --> ${objects/?key/webservice:json}
[02:16] <thumper> the ?key has me wondering
[02:18] <wgrant> Literally '?key'?
[02:18] <wgrant> Ah, yes.
[02:19] <wgrant> thumper: It uses the value of the 'key' variable to continue traversal.
[02:19] <thumper> ah... ok
[02:19] <thumper> thanks
[02:19] <thumper> that makes sense
[02:55] <wallyworld> i can has review? https://code.launchpad.net/~wallyworld/launchpad/recipe-webservice-api/+merge/50684
[02:57] <wgrant> 90	def getBuilds():
[02:57] <wgrant> 91	"""Return a ResultSet of all the non-pending builds."""
[02:57] <wgrant> That's an odd method name, if the docstring is correct.
[02:59] <wallyworld> wgrant: i didn't write it, but it does make sense if you realise there's also a getPendingBuilds() method
[02:59] <wallyworld> which returns the pending builds :-)
[02:59] <wgrant> wallyworld: We should export a sane API if at all possible, and that method name is insane.
[03:00] <wgrant> Does the method need to not return pending builds?
[03:00] <wallyworld> wgrant: yes, it needs to not return the pending builds
[03:00] <wgrant> Hmm.
[03:00] <wgrant> Is that useful for API users, though?
[03:01] <wallyworld> wgrant: there was a refactoring previously which changed those method names. i can't recall the exact circumstances now since i didn't do it
[03:02] <wallyworld> i guess the method names could be changed
[03:02] <wallyworld> again
[03:02] <wgrant> We shouldn't be exposing suboptimal interfaces to people who are going to use them forever so we can never change them.
[03:02] <wgrant> We can rename just the exports if required.
[03:03] <wallyworld> wgrant: so given there's 2 methods - getPendingBuilds() and getBuilds() - is it just the getBuilds() name you have a problem with?
[03:04] <wgrant> wallyworld: I think a single method with arguments may be better. But getPendingBuilds on its own is possibly OK.
[03:04] <wallyworld> wgrant: there used to be a single method with args and the refactoring converted it to 2 methods :-)
[03:06] <wgrant> Why? TAL?
[03:07] <wallyworld> wgrant: not sure exactly. i was never involved in the decision, just noticed that it had happened
[03:07] <wallyworld> the getBuilds() method returns all builds where status != NEEDSBUILD
[03:07] <wallyworld> so that could be successful, failed, whatever
[03:08] <wgrant> Hmm.
[03:08] <wallyworld> getNonPendingBuilds() sounds a bit funny, or?
[03:09] <lifeless> getFinalisedBuilds?
[03:09] <lifeless> Terminal
[03:09] <lifeless> Complete
[03:09] <wgrant> Ahh, it's used by builds_for_recipe.
[03:09] <wallyworld> complete implies success
[03:09] <wgrant> I don't think exporting them as separate methods is useful.
[03:09] <wallyworld> i like finalised perhaps
[03:09] <lifeless> wallyworld: complete does not imply success
[03:09] <wallyworld> wgrant: so we could have an api just just gets all builds
[03:10] <wallyworld> i'll do this: getBuilds() returns everything and is exported. i'll add a getCompletedBuilds() which does what getBuilds() does now
[03:10] <wallyworld> sound ok?
[03:11] <wgrant> Maybe have getBuilds(include_pending)?
[03:11] <wallyworld> wgrant: that's what we had before the refactoring :-)
[03:12] <wgrant> lifeless: Tracebacks in OOPSes are very enlightening.
[03:12] <lifeless> yes
[03:12] <wgrant> lifeless: Could not work out where some queries were coming from... turns out they were in __storm_loaded__ in various places.
[03:12] <wgrant> Grr.
[03:12] <lifeless> wgrant: the 'is it a team' check ?
[03:13] <wgrant> lifeless: And is the distribution a derivative or not.
[03:13] <wgrant> Queries for Ubuntu on every distro load.
[03:23] <lifeless> let me just say arrrrrrrrrrrrrgh
[03:25] <wgrant> Oh?
[03:31] <wgrant> ahh, inTeam often issues two queries. That sort of sucks.
[03:31] <wgrant> It's very tempting to preload all participation IDs at the start of the request...
[03:32] <wgrant> We can get rid of a lot of queries if we just prefetch the user's participations and a few celebrities.
[03:33] <wgrant> lifeless: Have you thought about that at all?
[03:42] <lifeless> yes
[03:42] <lifeless> net loss I think
[03:42] <lifeless> getting one TP entry is very fast
[03:43] <lifeless> some users have hundreds of TP entries and we'd only be looking at 2 or 3
[03:43] <lifeless> wgrant: consider lying to objects instead.
[03:43] <lifeless> wgrant: that is, if we load an object from a context where view/edit is known a priori, grant it during the load, the way bugs _known_viewers gets data injected into it
[03:44] <lifeless> also
[03:44] <lifeless> bug 722447
[03:44] <_mup_> Bug #722447: checking 'well known' teams requires two queries at startup and in tests <Launchpad itself:Triaged> < https://launchpad.net/bugs/722447 >
[03:44] <wgrant> lifeless: Getting 200 TPs takes 200 microseconds in the DB.
[03:44] <wgrant> I tried with person=1
[03:45] <lifeless> wgrant: hot or cold
[03:45] <wgrant> That was cold.
[03:45] <lifeless> consider storm deserialisation - its not brillianrtly fast
[03:45] <wgrant> This is probably the most trivial table in the DB.
[03:45] <lifeless> wgrant: perhaps you mean milliseconds ?
[03:45] <wgrant> It's deserialising ints... it goes nowhere near Storm.
[03:45] <wgrant> No, 0.2ms.
[03:45] <lifeless> nice
[03:45] <lifeless> well, lets say I'm open to data on this
[03:45] <wgrant> I guess the table is so small that it may have been hot enough even on mawson.
[03:45] <wgrant> It is just two ints...
[03:46] <lifeless> launchpad_qastaging=> select count(*) from teamparticipation where person=1;
[03:47] <lifeless> Time: 3.323 ms
[03:48] <lifeless> wgrant: its got 1.4m rows, so fairly small
[03:48] <lifeless> and yes, a narrow table - like bugmessage
[03:48] <lifeless> wgrant: I'm not saying no, I'm saying its not a no-brainer
[03:50] <lifeless> wgrant: if you bring back team names:
[03:50] <lifeless> Time: 1694.335 ms
[03:50] <lifeless> wgrant: it becomes a lot slower
[03:51] <lifeless> that was 'select team.name from person as team, teamparticipation where teamparticipation.person=317562 and teamparticipation.team=team.id;'
[03:51] <wgrant> lifeless: Sure. But why would we want team names?
[03:51] <wgrant> Of course a join across a wideish table is going to be slow.
[03:51] <lifeless> wgrant: just bringing back ids is pretty useful.
[03:51] <lifeless> s/useful/useless/
[03:53]  * wallyworld wants to stab windmill through the heart
[03:53] <wallyworld> AttributeError: 'AppYUIUnitTestCase' object has no attribute 'client'
[03:53] <wallyworld> WTF.
[03:54] <wgrant> lifeless: It's completely sufficient for inTeam, though.
[03:54] <wgrant> Just not FF.
[03:54] <lifeless> its only sufficient for inTeam if the team id is known a priori
[03:55] <lifeless> wgrant: we can instead do an inTeam on PersonSet which would issue one fast query.
[03:57] <lifeless> interestingly, teamparticipation seems to have redundant entries for code in offspring hackers - three rows
[03:59] <lifeless> doh, bad query
[04:05] <wgrant> lifeless: But that would require restructuring huge amounts of code.
[04:06] <wgrant> If we prefetch participations then later prefetch relevant persons, we can make all of the permission checks free with very little code.
[04:07] <lifeless> wgrant: my concern is three fold:
[04:08] <lifeless>  - This sort of thing eventually becomes an albatross : its hard to undo an optimisation like you're proposal
[04:08] <lifeless>  - its not inherently scalable
[04:08] <lifeless>  - its very data set specific
[04:08] <lifeless> we should be able to get down to 4 or 5 teamparticipation checks per page without any special case
[04:09] <lifeless> I think we should do that first - thats a whole 30ms : we're dealing with 10000ms pages at the moment, so lets reserve the special cases until they are a big win, not a little win
[04:11] <wgrant> Very data set specific?
[04:12] <wgrant> The inTeam thing needs to be done in a single place, and it will optimise every permission check in the project.
[04:13] <lifeless> at the cost of loading a potentially unbounded dataset on every request
[04:13] <lifeless> thats a risky design
[04:13] <lifeless> now, if you were to load just the tps relevant to the teams you'd also preload, that addresses that scaling factor
[04:13] <lifeless> but it still doesn't address the data set specific nature
[04:14] <lifeless> by which I mean that the teams relevant to a given page depend on the pillar, the privacy settings, the bug settings etc
[04:14] <lifeless> and we should be doing *at most* 2 queries for the same stuff today
[04:14] <lifeless> so the maximum possible win is 30-40ms on a page.
[04:15] <lifeless> i don't understand - given the existing caching - how you can save more than that
[04:15] <lifeless> \o/Test results: bug-717394 => devel: SUCCESS
[04:16] <wgrant> lifeless: BugTask:+index does several for each task and nomination.
[04:17] <lifeless> so, you'll need to eager load all the /teams/ for that , right ?
[04:18] <lifeless> even if we had the persons ids, we'd still trigger - in some cases - 100 queries
[04:18] <wgrant> Right, so I could precache participations at the same time.
[04:18] <lifeless> exactly
[04:18] <wgrant> But getting all of them is *so* cheap for even our worst case right now.
[04:18] <lifeless> but its not incrementally useful given that we have to do the team eager loading anyway
[04:19] <wgrant> For this particular case, no.
[04:19] <wgrant> But it's harder to make it specific to this case, and it is less globally useful.
[04:20] <lifeless> mmm
[04:20] <lifeless> I really think its better to sneak up on this
[04:21] <wgrant> We can solve all of them ever with less work than solving this specific case, with the only risk being that someone joins a million teams, in which case we have bigger problems.
[04:21] <lifeless> perhaps I'm misunderstanding bu that sounds completely false
[04:22] <wgrant> Oh?
[04:23] <lifeless> see above under having to special case this situation anyway
[04:23] <lifeless> we've no particular reason to think that any of the late evaluation triggers would not need special casing to load their teams.
[04:23] <lifeless> And lots of reason to think that they *will*, even with a seed-at-start-tp-list-for-the-current-user
[04:25] <lifeless> its less work to write one eager-load-for-doing-a-inTeam-check helper and use it where we need it than to write a tp loader, change inTeam to be handle that extra cache, write a eager loader for groups of teams, and apply that in the same places
[04:25] <wgrant> What part of my statement above was completely false?
[04:25] <lifeless> that it was less work
[04:25] <wgrant> If we have a global one, all we need to do is preload persons every time.
[04:26] <wgrant> If we don't, we have to preload persons every time and then possibly preload participations if we think they will be necessary.
[04:26] <wgrant> We *will* need at least one participation check on edge authenticated page.
[04:27] <wgrant> I think that one check might as well do the trivial extra work that lets it fulfil *every* subsequent check.
[04:27] <lifeless> s/edge/each/ ?
[04:27] <wgrant> Uh, yes.
[04:27] <wgrant> WTF
[04:28] <lifeless> so
[04:28] <lifeless> this isn't the way I'd do it
[04:28] <lifeless> I think its a poor design
[04:28] <lifeless> if you're doing the work, you get to choose
[04:29] <lifeless> I've laid out my concerns
[04:29] <lifeless> at this point we're clearly missing each others point, or something.
[04:29] <wgrant> I think so.
[04:30] <lifeless> I *will* insist that if you do it, you instrument it
[04:30]  * StevenK suspects dogfood is now missing recipes
[04:30] <lifeless> so that we can see the overhead clearly in the PPR or a similar system
[04:31] <StevenK> Where can I see feature flags?
[04:31] <wgrant> StevenK: Watch out, DF will be a bit broken.
[04:31] <lifeless> the one guaranteed thing is that users will do crazy things with teams and memberships and so on
[04:31] <wgrant> It needs a new DB.
[04:31] <lifeless> StevenK: /+feature-rules
[04:31] <StevenK> wgrant: Rargh, I need it :-(
[04:31] <wgrant> StevenK: Add 'code.recipes_enabled default 0 true'
[04:31] <wgrant> StevenK: It should mostly work.
[04:31] <wgrant> Just bugs will do very strange things.
[04:31] <wgrant> And it can't run latest db-devel.
[04:32] <wgrant> I merged devel into it this morning, though.
[04:32] <StevenK> Heh
[04:32] <StevenK> By accident? :-)
[04:32] <wgrant> No.
[04:33] <StevenK> wgrant: Recipes enabled, let's see
[04:33] <StevenK> wgrant: We can probably sort out a new DB for it soonish.
[04:34] <lifeless> if you've still got disk space
[04:34] <wgrant> lifeless: So, I agree that unconditionally loading an unbounded and excessive dataset is a bad thing.
[04:34] <wgrant> lifeless: We still have 110GB free, with a DB dump and one full DB.
[04:34] <lifeless> wgrant: whats \l+ show
[04:35] <wgrant>  launchpad_dogfood | postgres | UTF8     | C         | C     |                       | 222 GB  | pg_default |
[04:35] <lifeless> so, you're going to lose 80GB of that 110
[04:35] <lifeless> the db is ~300GB now
[04:35] <wgrant> I was thinking it was ~260.
[04:35] <wgrant> But maybe that's old.
[04:35] <lifeless> it was
[04:35] <lifeless> it was 290GB during the last db deploy IIRC
[04:37] <StevenK> TBH, we tend to update dogfood by scorched earthing the DB and re-importing
[04:37] <StevenK> Which is a little ... brutal
[04:37] <lifeless> sure
[04:37] <lifeless> point is, you can't run a db and a dump now
[04:37] <wgrant> Hm, I wonder if I can order \d+ by size, or if I have to go querying manually...
[04:38] <StevenK> lifeless: If I'm reading what wgrant said correctly, we already have a full DB and a full DB dump on dogfood. So if we delete both, we can get another dump and import it
[04:39] <wgrant> That's how it's normally done.
[04:39] <wgrant> Since the dump compresses well.
[04:39] <StevenK> Pity it takes mawson 40 hours to import
[04:39] <lifeless> StevenK: you can get another dump, but the dump will be bigger too; if its 30GB bigger you'll run out of disk space mid import
[04:39] <lifeless> well, 90% or so
[04:40] <StevenK> lifeless: Er, we have 110GiB free?
[04:40] <wgrant> It's not 30GB bigger, fortunately.
[04:40] <StevenK> How does a 30GiB increase to both eat 110?
[04:41] <wgrant> StevenK: The dump is much smaller than the full DB.
[04:41] <wgrant> The DB itself has grown by 80GB.
[04:41] <wgrant> (how!?)
[04:41] <wgrant> The dump will also have grown by a few.
[04:41] <StevenK> Either I'm missing something or lifeless is. I'm not sure who yet.
[04:41] <wgrant> 110 - 80 - a bit is almost 0
[04:41] <lifeless> StevenK: you have 110GB free
[04:42] <lifeless> StevenK: the db is 80GB bigger, that means you'll have 30GB free for the dumps increase in size.
[04:42] <wgrant>  public | branchrevision                            | table    | postgres | 26 GB      |
[04:42] <StevenK> I think there's a good 12 or so GiB I could free in a hurry if i need to.
[04:42] <wgrant> And then there are four revision-related indices that are about 15GB each :/
[04:43] <wgrant> That's like a third of the DB.
[04:43] <StevenK> launchpad@mawson:/srv/launchpad.net$ ls -lh | head -n 2 | tail -n 1
[04:43] <StevenK> -rw-r--r--   1 launchpad launchpad  8.0K Aug 27 16:50 ,x
[04:43]  * StevenK chuckles
[04:45] <wgrant> Yeah, 100GB goes to branchrevision.
[04:45] <wgrant> Awesome.
[04:45] <StevenK> Can't we delete that monstrosity yet?
[04:45] <wgrant> Wait.
[04:46] <wgrant> That's 100GB of 222GB.
[04:46] <wgrant> Not 300GB.
[04:46] <wgrant> That is huge.
[04:46] <StevenK> lifeless: I suspect you didn't close bugs after the deploy you requested.
[04:47] <lifeless> StevenK: it was midnight. I suspect that too
[04:47] <lifeless> sigh buildbot
[04:48] <lifeless> StevenK: did you get any traction on why jenkins appeared more fragile than buildbot?
[04:48] <wgrant> Because windmill.
[04:49] <wgrant> It was fine until windmill :(
[04:49] <StevenK> It's been behaving fine this week and last, mind you.
[04:50] <StevenK> But Windmill makes me very sad.
[04:50] <lifeless> windmill makes its mother sad
[04:50] <wgrant>     "revisionnumber_branch_id_unique" UNIQUE, btree (branch, id)
[04:50] <wgrant>     "revisionnumber_branch_sequence_unique" UNIQUE, btree (branch, sequence)
[04:50] <lifeless> grrr
[04:50] <lifeless> bug 1 timeout ><
[04:50] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[04:50] <wgrant> That first index is a bit off, since id is the pkey...
[04:51] <lifeless> it may be used
[04:51] <wgrant> lifeless: Which query?
[04:51] <lifeless> alternatively we could rely on heap joins and just do single column indices
[04:51] <lifeless> dunno yet
[04:51] <lifeless> OOPS-1879G332
[04:52] <wgrant> Here too. That's a bit upsetting.
[04:53] <wgrant> Death by a couple of hundred Person queries, I guess.
[04:53] <StevenK> lifeless: Thanks for the bug closures.
[04:53] <lifeless> StevenK: thanks for the reminder; the list was at the top of LPS so easy to do (you could have done it :P)
[04:53] <StevenK> "Meh" :-)
[04:54] <wgrant> lifeless: I realise I'm blocking the QA pipeline, but I need to check with sinzui on the best way to QA the DMP.
[04:54] <wgrant> And he wasn't around yesterday.
[04:54] <lifeless> wgrant: we can't run it in staging
[04:54] <wgrant> Exactly.
[04:55] <lifeless> so, the answer is 'hope'
[04:55] <StevenK> Haha
[04:55] <wgrant> Mm, I guess.
[04:55]  * wgrant untestables.
[04:55] <lifeless> same with branch mirroring
[04:55] <wgrant> We can QA that.
[04:55] <wgrant> Just need to find a consenting victim and disable the rest.
[04:57] <lifeless> looks new: 23 /    1  BinaryPackageBuild:+retry
[04:57] <StevenK> On prod?
[04:57] <wgrant> Argh, not again.
[04:57] <wgrant> That could well have been during the fuckage last night.
[04:57] <StevenK> Could it possibly be fallout?
[04:57] <wgrant> With buildd-manager and p-u holding locks open for an hour.
[04:58]  * StevenK high fives wgrant for having the same thought.
[04:58] <lifeless> wheeee
[04:58] <StevenK> Hmmm
[04:59] <wgrant> I am really disturbed that nagios didn't notify us within a minute of the incident beginning...
[04:59] <lifeless> it was probably swapping
[05:00] <wgrant> And? A missing probe is a failed probe...
[05:00] <lifeless> actually
[05:00] <lifeless> its more nuance than that ;)
[05:00] <StevenK> wgrant: As a thought: a way to handle cancelling distro builds: add a new status: BuildStatus.REFUSED or so which process-upload will silently reject binaries. And then instruct buildd-manager to shoot the buildd in the head. Thoughts?
[05:00] <wgrant> StevenK: We can't cancel builds on the non-virt builders.
[05:00] <wgrant> lifeless: It *is*, but it shouldn't be.
[05:01] <lifeless> wgrant: talk to the netsaint designer
[05:01] <wgrant> My Nagios days are hopefully over.
[05:01] <StevenK> Nagios makes me sad, too.
[05:01] <StevenK> I used that enough at my last job.
[05:06] <wgrant> StevenK: Anyway, what were you doing to mawson?
[05:06] <StevenK> wgrant: Testing https://code.launchpad.net/~stevenk/launchpad/link-recipe-on-ppa-page/+merge/50694
[05:06] <StevenK> wgrant: Can has review? :-)
[05:08] <wgrant> StevenK: Could you QA thumper's thing while you're there?
[05:08] <StevenK> Which 'thing'?
[05:09] <wgrant> r12410
[05:09] <wgrant> Recipe FF changes.
[05:09] <wgrant> Main thing that needs testing is r-d-b
[05:10] <wgrant> OOPS syncing seems to be really slow.
[05:10] <wgrant> G332 still isn't there.
[05:10] <StevenK> wgrant: With the flag set, it runs, but there are no daily builds to build. I can reach into the db and set one if you wish
[05:10] <wgrant> StevenK: Could remove the flag and try again?
[05:11] <wgrant> It needs to run fine without it.
[05:11] <wgrant> And be able to request builds.
[05:12] <StevenK> wgrant: Same output as with the flag
[05:12] <wgrant> StevenK: Could you staleify a recipe and try without the flag?
[05:13] <lifeless> wgrant: you were interested in OOPS: https://dev.launchpad.net/LEP/OopsDisplay
[05:15] <wgrant> lifeless: Excellent, looking.
[05:15] <StevenK> Oh, bah, the recipe I forced to be stale has built recently
[05:16]  * StevenK reaches back into the db
[05:16] <wgrant> Die forster die.
[05:16] <thumper> wgrant: we need an admin for that
[05:16] <wgrant> thumper: Or a mawson.
[05:16] <wgrant> And given the lack of admins this week, it is tempting to use mawson.
[05:16] <wgrant> It's where we normally test daily builds, anyway.
[05:18] <wgrant> thumper: Also, do you plan to remove the unused key from the production configs?
[05:18] <wgrant> If you don't, it will make me sad.
[05:18] <thumper> wgrant: yes I do...
[05:18] <thumper> wgrant: it will be part of the whole release process
[05:18] <wgrant> Great. Just checking. There are lots of deprecated code keys left around from years ago.
[05:22] <StevenK> wgrant: Right, with flag disabled, and a recipe forced to be stale:
[05:22] <StevenK> 2011-02-22 05:22:32 DEBUG   Recipe stevenk/terminator-test is stale
[05:22] <StevenK> 2011-02-22 05:22:32 DEBUG    - build requested for Lucid (10.04)
[05:22] <StevenK> 2011-02-22 05:22:32 INFO    Requested 1 daily builds.
[05:23] <wgrant> StevenK: Great, both the UI and script work. qa-ok it is.
[05:23] <wgrant> Thanks.
[05:25] <StevenK> wgrant: Review? :-)
[05:26] <wgrant> StevenK: Oh, right, forgot about that.
[05:26]  * wgrant does it.
[05:26] <wgrant> StevenK: That nasty lifeless wrote a distracting LEP.
[05:26] <StevenK> Haha
[05:29] <StevenK> thumper: For the description branch, I just need the database patch?
[05:29] <StevenK> Oh, no, I don't
[05:29]  * StevenK fixes the code too
[05:29] <thumper> StevenK: primarily the flag on the storm column, and on the interface
[05:29] <thumper> that should be it
[05:30] <StevenK> thumper: Both done
[05:30] <StevenK> thumper: In the model: description = Unicode(allow_none=False)
[05:30] <StevenK> thumper: So I guess that has to change too :-)
[05:31]  * thumper nods
[05:38] <thumper> BTW, I'm done now
[05:39] <StevenK> thumper: Awww
[05:39] <StevenK> thumper: I was about to point you at the MP
[05:40] <StevenK> Hm. ENOSTUB
[05:41] <wallyworld> latest build failure - windmill timeout. can't see any obvious errors and the last reported test which timed out runs fine locally. i guess a force build is in order?
[05:41] <lifeless> StevenK: whats up ?
[05:42] <StevenK> lifeless: I was after a db number
[05:42] <StevenK> But it can wait until stub does turn up
[05:42] <lifeless> probably 49
[05:42] <lifeless> but yeah, he should be aorund soonish
[05:42] <StevenK> wallyworld: Force away
[05:42]  * wallyworld shakes fist at ec2 or windmill or someone, anyone :-(
[05:43] <lifeless> hmm
[05:43] <lifeless> branchrevision ||     136.01 tuples/sec
[05:44] <lifeless> whee, that deployment glitch really messed the stats - 4.58 99th percentile
[05:45] <lifeless> flacoste: oh, the PPR needs to exclude the haproxy status page too
[05:45] <lifeless> flacoste: as well as opstats :)
[05:49] <wgrant> StevenK: Reviewed.
[05:49]  * StevenK reads, hoping wgrant was gentle
[05:49] <wgrant> Heh. Not a chance.
[05:49] <wgrant> Sorry.
[05:49] <wgrant> lifeless: Where's the dbr?
[05:50] <lifeless> https://devpad.canonical.com/~lpqateam/dbr/last-15-mins.txt
[05:50] <wgrant> Thanks.
[05:51] <StevenK> wgrant: Hmmm. I think I will test how it behaves with deleted recipes
[05:52] <StevenK> wgrant: Second point. I wasn't sure how to get at that view directly, so I used the route I knew worked
[05:52] <wgrant> I think it may work as of this morning.
[05:52] <wgrant> But it would have last week.
[05:52] <wgrant> Er.
[05:53] <wgrant> *wouldn't* have last week.
[05:54] <StevenK> wgrant: First point: The method was a good place to start with, and did start out longer, I just didn't bump it from the model and interface into the TAL directly
[05:55] <StevenK> wgrant: Do you think it's worth the bother to move it?
[05:55] <wgrant> StevenK: I like to avoid bloating already bloated interfaces.
[05:56] <StevenK> tal:condition="context/sourcepackagerelease/source_package_recipe_build"> makes me sad.
[05:57] <wgrant> StevenK: As for getting the right view directly, canonical_url(spph, view_name='+listing-archive-extra') should do it.
[05:57] <StevenK> wgrant: Thinking it about, would it address your concerns if it moved from @property to @cachedproperty ? Since I doubt it's going to actually change
[05:57] <wgrant> StevenK: The speed is of no concern whatsoever.
[05:57] <StevenK> According to Julian, it is
[05:57] <wgrant> It is no extra queries.
[05:58] <wgrant> So it's no issue.
[05:58] <wgrant> You can have the method on the view if you really want it.
[05:58] <wgrant> But I would just have a long tal:define and base everything on that.
[05:59] <StevenK> wgrant: If you don't think it's ugly, like I wrote before, I can do that and remove it from the model and interface.
[05:59] <wgrant> StevenK: SPPH.sourcepackagerelease, SPRelease.source_package_recipe_build, and SPRB.recipe are all FKs, so subsequent invocations are not expensive at all.
[05:59] <wgrant> StevenK: It is ugly.
[05:59] <wgrant> But it's ugly hidden away in a template.
[06:00] <StevenK> And it doesn't add code to SPPH and so therefore automatically good? :-)
[06:01] <wgrant> Yes.
[06:01] <wgrant> It's also not *that* ugly.
[06:02] <StevenK> steven@liquified:~/launchpad/lp-branches/link-recipe-on-ppa-page% grep -rc '+listing-archive-extra' lib/lp/soyuz/browser/tests/* | grep -vc ':0$'
[06:02] <StevenK> 0
[06:02] <StevenK> That concerns me.
[06:02] <wgrant> StevenK: Probably all from Archive:+packages doctests.
[06:03] <StevenK> wgrant: No matches in lib/lp/soyuz/doc or lib/lp/soyuz/tests
[06:03] <wgrant> StevenK: Link-clicking, probably.
[06:03] <StevenK> wgrant: You mean, like I'm doing?
[06:03] <wgrant> StevenK: Yes.
[06:03] <wgrant> But you are not a doctest.
[06:03] <lifeless> so tal defines can (in some situations) evaluate multiple times
[06:04] <lifeless> *if* the thing is expensive, thats a concern
[06:04] <StevenK> Don't make me turn it into one.
[06:04] <StevenK> :-P
[06:04] <lifeless> julian and I didn't figure out what causes that
[06:04] <wgrant> It is three FK lookups.
[06:04] <wgrant> So it's trivial.
[06:04] <StevenK> wgrant: Besides, I couldn't come up with a fool-proof way to get at the SPPH given a BPPH I just created.
[06:05] <wgrant> StevenK: BPB.current_source_publication doesn't work?
[06:05] <wgrant> I don't remember if I fixed the factory to create it in the right context.
[06:05] <StevenK> Meh, I think I'll ignore BPPH completly and just create an SPPH
[06:05] <wgrant> Also, you don't technically need a BPPH.
[06:05] <wgrant> Right.
[06:06] <StevenK> wgrant: Anyway, I shall fix it up tomorrow morning, and ping you
[06:06] <wgrant> Thanks.
[06:06] <wgrant> Do you have any comments on the UI stuff?
[06:06] <StevenK> You want a full stop at the end of the line I ended, that's it?
[06:08] <wgrant> I'd also like you to consider linking to the build instead of or as well as the recipe.
[06:08] <wgrant> And maybe turn the person into a link.
[06:08] <StevenK> That view is already crawling with links
[06:09] <wgrant> It is.
[06:09] <wgrant> But at least the build is probably useful.
[06:09] <StevenK> I fail to see how, exactly
[06:10] <wgrant> So I can check the build logs, mostly.
[06:10] <wgrant> To see why it built strangely.
[06:10] <wgrant> And to see which revs it used.
[06:11] <StevenK> I already have the build, so I'm going to push back on turning the person into a link, but with suggested wording will look at linking the build in
[06:11] <wgrant> You could possibly link "Built" to the recipe.
[06:12] <wgrant> Er
[06:12] <wgrant> To the build, not the recipe.
[06:12] <wgrant> So we have "_Built_ from recipe _Launchpad trunk_ for William Grant"
[06:14] <StevenK> You forgot the full stop
[06:14]  * StevenK ducks
[06:14] <wgrant> SILENCE
[06:15] <lifeless> StevenK: why shouldn't the person be a link?
[06:16] <wgrant> The icon can look slightly cluttersome.
[06:16] <wgrant> But I would prefer it to be a link.
[06:16] <wgrant> Even with the icon.
[06:16] <StevenK> I wouldn't, and thumper agrees with me
[06:16] <lifeless> -why-
[06:17] <lifeless> also
[06:17] <lifeless> if its not a link
[06:17] <lifeless> you need to show the unique username, not the display name
[06:17] <lifeless> to prevent spoofing
[06:19] <StevenK> What spoofing? We're showing information from something that's already been requested?
[06:20] <lifeless> so if the user doesn't matter, why show it at all ?
[06:23] <StevenK> Because it may have requested by someone to build into their own PPA
[06:25] <lifeless> then you should show who they are, not who they claim to be, no ?
[06:25] <lifeless> StevenK: whats the /objection/ to linking
[06:28] <StevenK> lifeless: As wgrant says, the icon can make the line look cluttered
[06:29] <wgrant> StevenK: But it shouldn't be too bad here, since there are no other icons.
[06:29] <wgrant> Unless you add the recipe icon to the start.
[06:29] <wgrant> Which I might recommend.
[06:29] <lifeless> so, thats a reason to discuss iconless formatters, its not a reason to not link the person - we link person everywhere else.
[06:29] <wgrant> Exactly.
[06:30] <lifeless> I guarantee if you don't link it, day one, someone will file a bug saying 'this is not linked and I cannot figure out who the >>> it actually is'
[06:34] <wallyworld> wgrant: i've done the changes to the method names: getBuilds, getCompletedBuilds, getPendingBuilds
[06:34] <wgrant> lifeless: I suppose I should ask if you have any further comments on that MP.
[06:34] <wgrant> wallyworld: Thanks.
[06:34] <lifeless> link ?
[06:35] <wgrant> wallyworld: I'm not sure if that's better than getBuilds(completed_only, pending_only), but it's certainly better than it was before.
[06:35] <wgrant> lifeless: https://code.launchpad.net/~stevenk/launchpad/link-recipe-on-ppa-page/+merge/50694
[06:35] <wallyworld> lifeless: https://code.edge.launchpad.net/~wallyworld/launchpad/recipe-webservice-api/+merge/50684
[06:35] <wallyworld> lifeless: sorry, wrong context
[06:36] <wgrant> Sorry, I was ambiguous.
[06:36] <wallyworld> wgrant: the reason the methods were changed from getBuilds(pending_only) etc is that having code like builds = getBuilds(True) blows chunks
[06:37] <wallyworld> much better and clearer to explicitly name the methods in this case
[06:37] <wgrant> wallyworld: But we have kwargs for that purpose.
[06:37] <wgrant> lifeless: That librarian meliae analysis is intriguing... could that be ZCA internals that we are seeing there?
[06:37] <lifeless> I htink os
[06:38] <wallyworld> wgrant: yes, i see your point but it's 2 against one :-)
[06:39] <lifeless> wallyworld: is this a democracy ?:P
[06:39] <lifeless> hey
[06:39] <lifeless> whats the name of the law ab..
[06:39] <lifeless> ah, demeter I think
[06:40] <wallyworld> lifeless: well, even dictatorships can fall :-) egypt, etc
[06:40] <wallyworld> lifeless: you manage to buy some food? i read that all the Countdowns are closed
[06:40] <stub> Loving my indicator icons. It is 31℃ with a chance of bacon.
[06:40] <lifeless> wallyworld: yeah, 60 minutes in a queue though
[06:40] <lifeless> wallyworld: at least we have some shinier stuff than baked beans * forever
[06:41] <wallyworld> lifeless: when we had the floods here a month back, people paniced and bought out the whole supermarket - no bread, veges or anything like that left. even canned foos all gone
[06:43] <lifeless> yeah
[06:43] <lifeless> panic buying *after* the fact
[06:43] <lifeless> lynne is getting pissed at the 4.0 after shocks
[06:44] <lifeless> there are lots
[06:44] <lifeless> there was a block long queue at the service station for petrol
[06:44] <wgrant> The petrol station wasn't closed?
[06:44] <wgrant> I heard many were.
[06:46] <lifeless> we're in rangiora
[06:46] <lifeless> 30K NW of the cbd
[06:46] <lifeless> 40K NW of the epicentre
[06:46] <wgrant> lifeless: Oh, I thought it was more like 15km.
[06:46] <wgrant> Oops.
[06:47] <wgrant> lifeless: Scaling-wise we are already doing all the queries.
[06:47] <wgrant> To determine the uploader.
[06:47] <wallyworld> i heard that petrol was being made available to police and military only
[06:47] <wgrant> I'm not sure if that's prejoined or not.
[06:47] <wgrant> But it's already there.
[06:48] <wgrant> Oh, except those are subviews.
[06:48] <wgrant> They're separate requests.
[06:49] <wgrant> So this will cause three extra queries, but on-request and in a separate request.
[06:49] <lifeless> wgrant: it wasn't discussed, so I didn't know
[06:49] <lifeless> wgrant: its not clear to me that the source package recipe build link is dereferenced in determining the uploader
[06:50] <lifeless> stub: hey
[06:50] <lifeless> stub: so this branch of mine; I'd like to use the query I have, because its uglier to do what you suggested and use a big literal as a subquery with the reset in storm
[06:51] <lifeless> we need to bring out two separate columns
[06:51] <lifeless> so we'd need to join to it as a subquery table
[06:54] <lifeless> wallyworld: I've commented anyhow
[06:54] <wgrant> :(
[06:54] <wgrant> TeamParticipation lies.
[06:56] <lifeless> wgrant: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1879G332
[06:56] <lifeless> wgrant: how so?
[06:56] <wgrant> lifeless: You are in a team if you are in the owning team.
[06:56] <lifeless> wgrant: the owner distinction?
[06:56] <lifeless> yeah
[06:56] <wgrant> Yes.
[06:56] <lifeless> sinzui and I agree that that is a bug
[06:56] <wgrant> But there is no participation in that case.
[06:56] <wgrant> This makes it impossible to do in one query.
[06:56] <wgrant> Because you may need to recurse near-infinitely.
[06:56] <lifeless> you are /not/ meant to be in a team by virtue of owning it
[06:57] <wgrant> Right.
[06:57] <wgrant> Just have its privs.
[06:57] <lifeless> no
[06:57] <wgrant> Well.
[06:57] <wgrant> Privs over *it*
[06:57] <lifeless> right
[06:57] <wgrant> Not its privs.
[06:57] <lifeless> you should be able to add yourself to the team
[06:57] <lifeless> or kick someone off it
[06:57] <stub> lifeless: Yup. I think my query just exposed the distro id.
[06:57] <wgrant> In fact.
[06:57] <wgrant> It's already only partial.
[06:57] <lifeless> but you don't get to do what the team permits people to do.
[06:57] <lifeless> wgrant: there are some places that are confused about this
[06:57] <wgrant> Since some things look up permissions from your teams, not vice-versa.
[06:58] <lifeless> wgrant: the /intent/ is 'must be in, not own, to be granted stuff *by* a team'
[06:58] <wgrant> I think we should look towards fixing this in the immediate future.
[06:58] <lifeless> wgrant: feel free to fix in that direction
[06:58] <lifeless> stub: it just exposed the spr
[06:58] <StevenK> stub: Hi! When you have a tick, could you review https://code.launchpad.net/~stevenk/launchpad/db-recipe-description/+merge/50697
[06:58] <lifeless> stub: we'd have to rejoin lots
[06:58] <wgrant> lifeless: Can I give you a query to find affected teams?
[06:58] <lifeless> stub: which is why I want to land what I have  - it works, it passes all tests
[06:58] <lifeless> wgrant: sure, but I can't check on prod; ask stub to do that if you need comprehensive data.
[06:59] <wgrant> lifeless: Staging's newish.
[06:59] <lifeless> sure
[06:59] <wgrant> I just want a rough idea.
[06:59] <lifeless> stub: what do you think
[06:59] <wgrant> For now.
[06:59] <stub> Gah... diff still not updated on the mp. I guess we don't retry on failures :-(
[06:59] <wgrant> stub: We retry a few times, I think. At least we do with normal BranchJobs.
[07:00] <wgrant> 5 times for scans.
[07:01] <stub> lifeless: I don't really follow. You have a query that is returning SourcePacakgeReleases and Distributions. Why does more need to be returned from the Store.find()  than what you already have?
[07:04] <stub> The hack seems particularly bogus to me, and difficult to decifer with half the main query being injected in the origin(), and then relying on some magic for the DISTINCT ON to end up in the right place by inserting it in the find, and a magic column being ignored...
[07:05] <stub> (And the indentation of the SQL blocks went left, but that might be a matter of taste)
[07:06] <lifeless> stub: the variant you put on the MP doesn't work
[07:06] <lifeless> stub: to make it work we need to rejoin all the tables again
[07:06] <lifeless> stub: spr -> spph -> distroseries
[07:07] <lifeless> stub: its nearly twice as long once you fix your variant to do that
[07:07] <stub> So spr.distroseries != spr -> spph -> distroseries ?
[07:07] <lifeless> the indenting was taste, I can fix that
[07:07] <stub> Sorry - spr -> distro -> distroseries != spr -> spph -> distroseries ?
[07:08] <lifeless> spr->upload_distroseries != spr->spph->distroseries
[07:08] <lifeless> there is no spr->distroseries
[07:08] <lifeless> package copies keep the spr and make a new spph
[07:08] <lifeless> making a new series of ubuntu does the same thing
[07:08] <stub> I see
[07:09] <lifeless> so to get distroseriesID (and we need to use the ID, Reference columns have nasty compile errors - I
[07:09] <lifeless> 've filed bugs on them in storm)
[07:09] <wgrant> mawson has 244 teams with members but the owner not in the team, and 207 teams with no members at all. Odd.
[07:09] <lifeless> we need to redo all the joins in the origin query
[07:10] <lifeless> stub: the reason the diff didn't update was the librarian outage
[07:10] <lifeless> it retried but all within the downtime
[07:10] <stub> I think similar to my approach can still work - just need to reconstruct the correct query from your branch (told you it was indecipherable :)
[07:10] <lifeless> stub: I did that, but its much longer
[07:10] <lifeless> stub: the SQL("DISTINCT ON () 0 as ignored") is used elsehwere
[07:10] <stub> Nah.... sublty different construct. Hang on...
[07:12] <lifeless> wgrant: 6 seconds of python time on bug 1
[07:12] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[07:12] <lifeless> wgrant: I'll be in 2 weeks when we have 1-threaded appservers that it gets a lot better
[07:13] <wgrant> :(
[07:13] <lifeless> 6.7 seconds getting the first message out
[07:13] <lifeless> thats either a /really/ busy slave or bogus
[07:13] <lifeless> FROM BugMessage,
[07:13] <lifeless>      Message
[07:13] <lifeless> WHERE BugMessage.bug = 1
[07:13] <lifeless>   AND BugMessage.message = Message.id
[07:13] <lifeless> ORDER BY BugMessage.INDEX, Message.datecreated,
[07:13] <lifeless>                            Message.id LIMIT 1
[07:15] <wgrant> lifeless: https://pastebin.canonical.com/43694/
[07:15] <wgrant> Could you run that on staging please?
[07:15] <wgrant> Seems to be lots of OEM and DMB and loco.
[07:16] <wgrant> And not too much else.
[07:16] <lifeless> oh grrr
[07:16] <lifeless> that query (the bugmessage one) just took 9 seconds cold on staging
[07:17] <wgrant> How bad hot?
[07:17] <lifeless> 23ms
[07:17] <wgrant> :(
[07:17] <lifeless> yeah
[07:17] <wgrant> Although it is restoring.
[07:17] <wgrant> And it is asuka.
[07:17] <stub> So the branchscanner is too fast, because it does all the retries before we even notice critical systems are down :-) Think we need a better retry mechanism...
[07:17] <lifeless> :>
[07:18] <lifeless> wgrant: whats this query reporting exactly - too late ot be arsed figuring it out
[07:18] <wgrant> lifeless: Unmerged teams that have members but the owner is not a member.
[07:18] <lifeless> wgrant: why is this interesting?
[07:19] <wgrant> lifeless: Because it's teams that will be affected when inTeam no longer considers owners.
[07:19] <lifeless> 269 rows
[07:19] <lifeless> oh rihgt
[07:19] <lifeless> *folk to notify*
[07:19] <wgrant> Right, probably.
[07:19] <wgrant> We will see.
[07:19] <lifeless> it will make some delegations tricky
[07:19] <wgrant> Oh?
[07:20] <lifeless> 'I and my delegate can do this'
[07:20] <lifeless> could be done as 'I am in my delegated team'
[07:20] <wgrant> You delegate it to yourself and someone else.
[07:20] <lifeless> or with a sideways team that has the delegated team and the owning team as both members
[07:20] <wgrant> By putting you and that someone else in a team.
[07:20] <wgrant> lifeless: Can I have those rows? :)
[07:21] <lifeless> meh?
[07:21] <lifeless> nonowners.txt in devpad:~robertc
[07:21] <wgrant> Thanks.
[07:23] <lifeless> wgrant: the sort order is the problem in the query
[07:23] <lifeless> just sorting on index makes the plan simple
[07:24] <lifeless> and drops it to 2ms
[07:24] <wgrant> lifeless: Ah. That's an easy fix.
[07:24] <lifeless> I'll fix indexed_messages
[07:26] <wgrant> 29 teams are among the problematic owners. Need to work out how to contact them.
[07:26] <wgrant> Lots of them are Canonical/Ubuntu, though, which is nice and easy.
[07:27] <thumper> StevenK: I did say the person should be a link, just a link to the person who requested the build, not necessarily the recipe owner
[07:27] <lifeless> stub: so, hows it going?
[07:27] <stub> lifeless: What test should I run?
[07:28] <lifeless> stub: I've been assessing this by loading a bug from lp.dev
[07:28] <lifeless> https://bugs.launchpad.dev/ubuntu/+source/mozilla-firefox/+bug/1
[07:28] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[07:28] <lifeless> that has (for me) a spr on 'ubuntu' and on 'debian'
[07:28] <stub> So we don't have a suitable test, or we don't know which test is suitable?
[07:28] <lifeless> the latter
[07:29] <lifeless> actually
[07:29] <lifeless> which thing is this
[07:29]  * lifeless scratches head
[07:29] <lifeless> series lookups
[07:29] <lifeless> yes, that bug
[07:31] <lifeless> stub: the mozilla-firefox(ubuntu) task should highlight with a build by mark
[07:32] <lifeless> and the mozilla-firefox(debian) task should mouse over with 'no current source release ...'
[07:35] <lifeless> stub: a trivial thing that may save you some time - its DistroSeries SourcePackag... - every word capitalised
[07:35] <stub> We never could seem to decide if they were one word or two - English language vs. domain language.
[07:36] <stub> What would save me time is faster 'make build' :-)
[07:36] <stub> mailman build, css assembling....
[07:36] <stub> rebooting hamster...
[07:36] <StevenK> mailman out of the tree would make me so happy
[07:36] <wgrant> stub: I use 'make -j3 compile' now. Not enough for the appserver, but enough for tests, and it's fairly fast.
[07:36] <wgrant> More -j3 kills things :(
[07:36] <stub> Ohh.. cool. forgot about -j
[07:36] <StevenK> Barry thinks it's very doable with Mailman 3.
[07:37] <wgrant> stub: compile skips mailman and WADL and other stuff.
[07:37] <StevenK> I think he's waiting for one or two things to hit core.
[07:40] <StevenK> stub: Can haz review and db patch number? :-)
[07:41] <lifeless> wgrant: yeah, like byte support in python3 :)
[07:41] <StevenK> The thought of moving LP to Python 3 makes me sad.
[07:42] <stub> lifeless: win. pushing.
[07:42] <lifeless> stub: thanks!
[07:42] <lifeless> stub: did you change both ?
[07:44] <stub> Ah sod... forgot to commit your work before modifying... mushed together in the diff
[07:44] <stub> Is there magic to repair that 'commit changes I merged in' or 'commit changes that come from this branch over there'?
[07:45] <stub> http://paste.ubuntu.com/570442/
[07:46] <stub> I've just done one so far.
[07:48] <stub> StevenK: Are you dropping the NOT NULL to make the UI less sucky and not forcing users to enter rubbish, or is there something more subtle here?
[07:49] <StevenK> stub: I suspect the reason is most users aren't setting a description, or don't really know what to put in, so we're dropping the constraint.
[07:49] <lifeless> stub: when I merge from you it should be a clear diff
[07:49] <stub> Thought so. Approved.
[07:50] <StevenK> stub: Can has number?
[07:50] <StevenK> I daresay -99 is bad
[07:50] <stub> StevenK: 2208-49-0, which will appear on the review when this ajax request submits... yay Thai ISPs.
[07:50] <lifeless> stub: how would you feel about people grabbing their own numbers from the wiki page as a minor optimisation to their workflow
[07:51] <stub> lifeless: Sure. As long as approved status is in the same table so we can garbage collect if we want
[07:52] <StevenK> stub: Hehe, thanks
[07:52] <lifeless> stub: I was thinking just let us have holes in the sequence
[07:52] <stub> lifeless: patchnum || who || description || approved
[07:53] <lifeless> stub: is that what you track at the moment ?
[07:53] <stub> lifeless: So we either need a new baseline generated before we hit 99, or we need to hack upgrade.py and the Makefile and switch to 3 digits in the middle field.
[07:54] <lifeless> stub: re http://paste.ubuntu.com/570442/
[07:54] <stub> I don't track who at the moment, but we should if this is a shared pool.
[07:54] <lifeless> stub: you're grabbing DistroSeries.id - we need DistroSeries.distributionID
[07:55] <lifeless> oh bah
[07:55] <lifeless> nvm I had the wrong one of the two queries
[07:55] <stub> lifeless: ok. Want me to fix that and the other callsite on my branch to see if it is working?
[07:55] <stub> The technique seems to work though and I think it is clearer.
[07:55] <lifeless> I think its quite nice
[07:56] <lifeless> yes please
[07:57] <lifeless> stub: it will be less nice on the other one though
[07:57] <lifeless> stub: that bug doesn't exercise the one you've edited
[07:58] <lifeless> oh, hmm, yes it should work, little opaque at first reading
[08:03] <StevenK> wgrant: Still here?
[08:07] <wgrant> StevenK: Slightly.
[08:08] <StevenK> wgrant: I think I have it sorted out -- trying to fit tal:define in
[08:09] <lifeless> jml: WARNING: intersphinx inventory 'http://docs.python.org/objects.inv' not fetchable due to <class 'urllib2.URLError'>: <urlopen error [Errno 101] Network is unreachable>
[08:09] <lifeless> jml: from carob
[08:10] <lifeless> jml: the update-launchpad-built-code.sh stable  script - given you added the dep, and are in the right tz to liase with losas to fix, herewith I hand it to you ;)
[08:11] <StevenK> Er, why does it need a losa? The script needs to use http_proxy
[08:12] <StevenK> wgrant: <li tal:define="sprb context/sourcepackagerelease/source_package_recipe_build" tal:condition="sprb">
[08:21] <lifeless> StevenK: it runs out of cron in a losa maintained account?
[08:21] <lifeless> StevenK: that said, I'm not at all sure 'make' should -ever- need internet access.
[08:21] <lifeless> particularly not in the deployment pipeline
[08:22] <lifeless> 'fixing' it to do internet access would be bad
[08:24] <StevenK> lifeless: Ah ha. Fair enough
[08:26] <lifeless> hmmm
[08:26] <StevenK> lifeless: Is there a special testtools matcher that ignores whitespace changes?
[08:26] <lifeless> I might file a critical bug instead
[08:26] <StevenK> Since I'm trying to match HTML, and TALES is helpfully inserting linebreaks
[08:26] <lifeless> for string matching? DocTestMatches(,,,. doctest.IGNORE_WHITESPACE) or something like that.
[08:26] <lifeless> however
[08:26] <lifeless> to do html
[08:26] <StevenK> Ew
[08:26] <lifeless> import soupmaches
[08:26] <lifeless> bah
[08:26] <lifeless> jamesw's soupmatchers
[08:27] <StevenK> lifeless: Thanks, I've made a note to investigate.
[08:28] <lifeless> the doctest docs document the flags to doctest to control its behaviour
[08:28] <lifeless> ah
[08:28] <lifeless> ELLIPSIS I think is th eone
[08:28] <lifeless> then you can write ... like you do in 'page tests'
[08:31] <lifeless> jml - fyi - https://bugs.launchpad.net/launchpad/+bug/723003
[08:31] <_mup_> Bug #723003: make is trying to connect to the internet <Launchpad itself:Triaged> < https://launchpad.net/bugs/723003 >
[08:34] <wgrant> StevenK: Back.
[08:36] <lifeless> stub: I think you need to commit and push again ?
[08:36] <lifeless> :!bzr merge lp:~stub/launchpad/trivial
[08:36] <lifeless> Nothing to do.
[08:37] <stub> $ bzr push
[08:37] <stub> Using saved push location: lp:~stub/launchpad/trivial
[08:37] <stub> No new revisions to push.
[08:37] <lifeless> ah, there it goes
[08:37] <lifeless> urgh
[08:37] <lifeless> you rebased onto trunk :<
[08:38] <lifeless> stub: future ref for doing something like this: start your branch; do bzr pull --overwrite <my brancH>
[08:38] <stub> k
[08:38] <lifeless> then you're hacking directly on what I'd done, rather than merging it into trunk etc
[08:38] <lifeless> avoids that issue you had with uncommitted changes from me as well
[08:39]  * stub doesn't recall...
[08:40] <lifeless> 20:44 < stub> Ah sod... forgot to commit your work before modifying... mushed together in the diff
[08:40] <lifeless> 20:44 < stub> Is there magic to repair that 'commit changes I merged in' or 'commit changes that come from this branch over there'?
[08:40] <StevenK> wgrant: Do you think my <li tal:define... is suitable enough?
[08:40] <stub> Right
[08:40] <wgrant> StevenK: LGTM
[08:41] <StevenK> wgrant: Okay, excellent. I think I've addressed most of your concerns, except for one -- do you think I should rename the test?
[08:41] <wgrant> StevenK: Yes, the test needs to be reworked, renamed and moved.
[08:41] <stub> I've been avoiding pull --overwrite as I'm usually reusing branches and --overwrite nukes that old history
[08:43] <StevenK> wgrant: I've done the re-work, using self.getViewBrowser(spph, ... that should be the reworking done, surely?
[08:43] <wgrant> StevenK: That's great.
[08:43] <wgrant> Now rename and move, and I may be happy :)
[08:43] <StevenK> wgrant: Yes, I was going to ask for a suggestion.
[08:43] <wgrant> StevenK: test_publishing.py
[08:44] <lifeless> stub: once the branch is merged, that history becomes uninteresting
[08:44] <StevenK> wgrant: Just move the entire class into there?
[08:44] <wgrant> StevenK: Yes, and maybe rename it to TestSourcePublicationListingExtra or something like that.
[08:45] <wgrant> But I'm not so fussed about the class name, as long as it doesn't mention ArchivePackages.
[08:45] <StevenK> Yes, the test was written when I believed what needed to be changed was in ArchivePackagesView.
[08:46] <wgrant> I know.
[08:48] <StevenK> wgrant: At risk of being wrong: TestSourcePublicationListingRecipes
[08:48] <wgrant> StevenK: It depends how specific you want to make the class.
[08:48] <wgrant> Do those tests deserve their own?
[08:49] <wgrant> It's possible they do.
[08:49] <wgrant> But there are only two.
[08:49] <StevenK> There is no other BrowserTestCase in test_publishing
[08:49] <wgrant> Is there a test_publishing?
[08:49] <wgrant> I don't see one.
[08:50] <StevenK> Oh, I thought you meant tests, not browser/tests
[08:51] <wgrant> If anything in lib/lp/*/tests/ is importing from lib/lp/*/browser, we have a bug.
[08:52] <StevenK> wgrant: Fixed, it's now lib/lp/soyuz/browser/tests/test_publishing.py
[08:52] <lifeless> stub: sql quick check
[08:52] <lifeless> when you select from two tables and they aren't joined
[08:52] <StevenK> And I understand what you were talking about, so it's also TestSourcePublicationListingExtra
[08:52] <lifeless> is it an implicit cross join ?
[08:52] <wgrant> StevenK: Thanks.
[08:52] <lifeless> stub: aren't joined, and there are no constraints joining them
[08:53] <lifeless>  https://pastebin.canonical.com/43697/
[08:53] <lifeless> is what we're actually executing now
[08:56] <stub> lifeless: Its an odd sort of join. the subquery only returns the (spr.id, distroseries) we are interested in.
[08:56] <lifeless> I wnat to make sure a) it will do the right thing, b) I understand why it will do the right thing
[08:56] <adeuring> good morning
[08:58] <stub> lifeless: So without an explicit join condition between the two tables, it is a cross join. But all tuples apart from the ones with the given (spr.id, distroseries) are discarded.
[09:01] <stub> lifeless: Consider SELECT spr.*, distroseries.* FROM SourcePackageRelease AS spr, DistroSeries WHERE (spr.id, DistroSeries.id) IN (1,2)
[09:01] <stub> lifeless: Or the eqivalent SELECT spr.*, distroseries.* FROM SourcePackageRelease AS spr, DistroSeries WHERE spr.id = 1 and DistroSeries.id = 2;
[09:05] <stub> Bah... although that first one has to be written SELECT spr.*, distroseries.* FROM SourcePackageRelease AS spr, DistroSeries WHERE (spr.id, DistroSeries.id) IN (SELECT 1,2)
[09:06] <stub> https://pastebin.canonical.com/43698/
[09:10] <mrevell> Hi
[09:20] <lifeless> jml: ping
[09:21] <lifeless> stub: thankds
[09:21] <lifeless> stub: I think we can make this a little more efficient
[09:22] <lifeless> stub: by using distroseries not distribution, so distribution isn't used at all
[09:23] <stub> expanding the list of all-distroseries-for-this-distribution because we know that already?
[09:23] <lifeless> no
[09:23] <lifeless> you selected Distribution.id
[09:23] <lifeless> but we don't join to distribution in the inner query
[09:23] <lifeless> we use distroseries.distribution
[09:23] <lifeless> which is DistroSeries.distributionID outside it
[09:24] <lifeless> s/outside/ to storm/
[09:26] <stub> I'm not sure how that would speed anything up - Distribution.id and DistroSeries.distribution are just integers. DistroSeries might be slightly hotter in the cache, but Distribution is smaller. Not that it matters for those tiny tables.
[09:32] <lifeless> explain says 105 vs 108
[09:32] <lifeless> so not worth worrying about
[09:33] <lifeless> the 105 is using distroseries.distribution and a distinct on the outer (because the cross join nature permits multiple identical matching rows when we don't use something with a unique constraint)
[09:33] <lifeless> stub: sending what you had to ec2
[09:34] <lifeless> bigjools: what do you think of bug https://bugs.launchpad.net/launchpad/+bug/279513
[09:34] <_mup_> Bug #279513: Distribution source package tooltip in bugtask table shows most recent SPPH in any series <lp-bugs> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/279513 >
[09:36] <bigjools> lifeless: reading
[09:36] <bigjools> gimme 5
[09:45] <lifeless> wgrant: once hot, bug one is now 8.3 seconds to render on prod
[09:45] <lifeless> wgrant: which isn't too bad at all
[09:45] <lifeless> wgrant: given all the other improvements we have pipelined
[09:46] <bigjools> l
[09:46] <bigjools> lifeless: do we even need tooltips?
[09:46] <lifeless> bigjools: thats an interesting question. I'll note that we can generate them in about 30ms now
[09:46] <bigjools> lifeless: I have never used that tooltip :)
[09:46] <bigjools> didn't even know about it
[09:47] <wgrant> bigjools: I used to use it very often.
[09:47] <lifeless> bigjools: less if we move the 'distro.getCurrentSourceReleases' stuff to be done via distro.development_focus.getCurrentSourceReleases
[09:47] <wgrant> lifeless: That's without the description check fix?
[09:47] <lifeless> bigjools: which is how I would propose to fix that bug
[09:47] <bigjools> lifeless: +1
[09:47] <lifeless> wgrant: the bug one times - yes
[09:48] <lifeless> bigjools: ok, cool, I'm in the area, I may polish it a little
[09:49] <bigjools> turds can only be polished so much
[09:49] <wgrant> Heh.
[09:49] <wgrant> lifeless: So, you said you'd discussed the owner participation thing with sinzui?
[09:51] <lifeless> yes
[09:52] <lifeless> IIRC the idea was this:
[09:52] <lifeless>  - owner would be made visually distinct from member, and we'd squash any bugs around this - e.g. inTeam
[09:52] <lifeless>  - we'd make it really easy for an owner to become a member, and to leave again
[09:53] <wgrant> Yep.
[09:53] <wgrant> Bug #227494
[09:53] <_mup_> Bug #227494: Do not special case the owner in IPerson.inTeam() <disclosure> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/227494 >
[09:59] <stub> jtv: You might be interested in reviewing https://code.launchpad.net/~stub/launchpad/garbo/+merge/50595
[09:59] <jtv> looking
[09:59] <jtv> stub: I'll happily review it, but mind if I do after lunch?  Visa.
[10:00] <stub> jtv: Sure.
[10:00] <jtv> cool
[10:00] <stub> Its not an urgent branch
[10:01] <wgrant> lifeless: The test fallout from this could be amusing.
[10:01] <wgrant> I guess I will talk to sinzui about it tonight.
[10:35] <bigjools> jml: can I trouble you to cast an eye over my twisted ftp stuff please?
[10:36] <cody-somerville> Is there something going on with staging.l.n?
[10:37] <lifeless> by something, you mean its down?
[10:37] <cody-somerville> something like that, yea :)
[10:37] <lifeless> [its being restored at the moment, use qastaging if you need to play with something]
[10:38] <lifeless> its generally a better playground anyhow
[10:39] <cody-somerville> hrm... whats the process if it appears a legitimate person's account has been compromised by a spammer?
[10:40] <lifeless> file a question on answers.launchpad.net/launchpad
[10:40] <lifeless> CHR will talk to them, get the spam removed etc
[10:41] <cody-somerville> I assume I should escalate if for example said compromised account has upload permissions to the Ubuntu archive?
[10:42] <lifeless> most spam is javascript automation driving their browser
[10:42] <bigjools> cody-somerville: it's usually someone impersonating an email address
[10:42] <bigjools> or what rob said
[10:42] <lifeless> that won't get transparent access to ssh or gpg keys
[10:42] <lifeless> so, I don't think you necessarily need to hit the panic button
[10:42] <lifeless> if its someone that can upload, talk to them directly too - at least they will be clueful enough not to need educating
[10:45] <cody-somerville> Looking at the recent actions for the user, whatever is doing it is doing it quite quickly. ;) so most likely as you suggest lifeless
[10:46] <lifeless> whats the user
[10:46] <bigjools> lifeless: launchpad needs a sudo feature
[10:46] <lifeless> bigjools: yes
[10:46] <wgrant> I filed a few bugs about that a long time ago.
[10:47] <cody-somerville> https://launchpad.net/~nickj-fox
[10:48] <lifeless> I've suspended it
[10:48] <cody-somerville> https://answers.launchpad.net/launchpad/+question/146393
[10:49] <wgrant> Huh, ~registry can't see suspended users?
[10:49] <wgrant> That seems dangerous.
[10:49] <cody-somerville> https://answers.launchpad.net/launchpad/+question/146394 is a duplicate
[10:51] <lifeless> night
[10:52] <jml> bigjools: definitely, already flagged.
[10:53] <bigjools> jml: excellent, thanks.  https://code.launchpad.net/~julian-edwards/launchpad/twisted-ftp-poppy/+merge/50721
[10:53] <jml> lifeless: I saw the bug. dealing with it as soon as I may.
[10:53] <lifeless> jml: oh hai
[10:53] <lifeless> jml: I had an action item to talk to you
[10:53] <lifeless> about uhm
[10:54] <lifeless> bugs I think
[10:55] <jml> lifeless: I think I know what that's about.
[10:55] <jml> lifeless: I have to go very soon (I can't tell you how much I want this driving stuff to be over with)
[10:55] <lifeless> jml: its midnight
[10:55] <lifeless> perhaps tomorrow
[10:56] <jml> lifeless: but I'll be around when you are up next.
[10:56] <lifeless> that would be good.
[10:56] <lifeless> Hopefully I can remember stuff after sleeping :) - wouldn't remember much right now at all
[10:56] <lifeless> jml: oh, also - parallel testing an doops leps
[10:57] <jml> lifeless: saw them, flagged them :)
[10:57] <lifeless> one is drafted [pending other team inputs, but they don't affect our direct plans]
[10:57] <lifeless> the other is open in my browser with stuff
[10:57] <lifeless> anyhow
[10:57] <lifeless> tomorrow. Later today. Whatver ;)
[10:57] <jml> :)
[10:57]  * jml is off.
[11:02] <soren> lifeless: You know what's funny? I woke up this morning, found a notice on my phone about the quake in Christchurch and 65 people dead. I wonder if you're ok, wander over to my laptop that was left in this channel from yesterday. I search for "quake", scroll up to find the context, and this is all I find:
[11:02] <soren> 23:56 < lifeless> wow
[11:02] <soren> 23:56 < lifeless> massive quake
[11:02] <soren> That's just classic.
[11:02] <soren> 23:56 < lifeless> internet is up
[11:05] <bigjools> soren: lol
[11:05] <wgrant> Come on, that was like 5 minutes after the quake :P
[11:06]  * bigjools quotes :)
[11:06] <soren> Someone ought to put that on a certain Quotes page if it's not already there. :)
[11:06] <soren> bigjools: snap :)
[11:06] <bigjools> heh
[11:38] <jtv> danilos, henninge: yay!  Fixed the new-template approval timeouts in just about the simplest way imaginable.
[11:38] <henninge> jtv: cool!
[11:38] <danilos> jtv, marked them all as 'deleted'? :)
[11:38] <jtv> Damn.
[11:38] <jtv> *Second-simplest* way imaginable.
[11:38] <jtv> No actually, this is simpler.
[11:38] <danilos> hehe
[11:38] <jtv> It was timing out because it creates all those POFiles.
[11:39] <jtv> And specifically, computing stats for them.
[11:39] <danilos> jtv, so you just removed updateStatistics call?
[11:39] <jtv> Which doesn't make all that much sense for a freshly-created template because…
[11:39] <jtv> there's nothing in them.
[11:39] <jtv> Simpler!
[11:39] <danilos> jtv, cool stuff
[11:39] <jtv> I just made it go "if template.messageCount() == 0: return 0"
[11:40] <jtv> heh heh heh
[11:40] <danilos> jtv, ah, you optimized updateStatistics :)
[11:40] <jtv> Yup
[11:40] <danilos> and heavily at that (at least for this special case :)
[11:41] <jtv> Yup
[11:41] <henninge> sounds great ;)
[11:41] <jtv> saves something like half a second per POFile
[11:45] <danilos> jtv, now you only need to do that for other cases updateStatistics handles, and you are done :P
[11:49] <danilos> hum, "operation timed out"? :)
[11:54] <StevenK> Would someone mind reviewing https://code.launchpad.net/~stevenk/launchpad/db-recipe-description/+merge/50697 ; it's tiny, and I can't see gmb.
[12:01] <deryck> Morning, all.
[12:01] <stub> StevenK: Looks like a candidate for a self review (I would approve, but lp doesn't want a code review in addition to db review :) )
[12:02] <wgrant> stub: Mentats sadly cannot self-review.
[13:44] <benji> jml: hi, I'm the RM for this round and the wiki says that I should ask you to be added to the stakeholder's list before sending emails
[13:45] <jml> benji: done.
[13:45] <benji> jml: thanks!
[13:48] <bigjools> jml: I am off to lunch now so can't talk much but I made another branch on top of that ftp one that will veryify gpg signatures on uploaded files and send an error back to the ftp client if it's invalid.  However, I need to patch twisted :)
[13:48] <bigjools> so I'll bug you about that later
[13:49] <jml> bigjools: ok.
[13:49] <jml> I'm still swamped beneath email.
[13:49]  * bigjools hears you
[14:01] <henninge2> deryck: I cant make the stand-up right now. Can we do it in 30 min?
[14:04] <deryck> henninge2, that's fine
[14:04] <henninge2> cool
[14:13] <benji> jml: I have another RM-related query for you, the procedure says that msm (Michelle Surtees-Myers) can approve my subscription to the ubuntu-platform list, but she's out of office until the 28th; do you know of anyone else that can approve it?
[14:14] <jml> benji: my guess would be any of the Ubuntu Platform managers.
[14:14] <jml> benji: mdz, rickspencer3, robbiew etc.
[14:14] <benji> jml: thanks, that'll help
[14:25] <jcsackett> benji: you doing RM?
[14:25] <benji> jcsackett: I am.
[14:26] <jcsackett> benji: cool! let me know if you have any other issues; i see elmo already told you to just email the list with reply-to rather than await moderation. :-)
[14:26] <benji> jcsackett: thanks
[14:32] <deryck> henninge, abentley, adeuring -- shall we try the standup now?
[14:32] <adeuring> sure
[14:32] <abentley> deryck, sure.
[14:39] <EzraR> on the launchpad wiki it says "Running a stable production instance would be much harder than running a single-developer test instance, and we don't recommend it."
[14:40] <EzraR> how much harder would it be? or would it just be the usual problems with any site?
[14:41] <EzraR> my school is looking to set something up for CS students to use and wanted to use open source, i suggested LP
[14:41] <jtv> danilos, henninge: good & bad news.  The pofile stats script's been failing in production because it accesses productseries.  Turns out it doesn't need to—another easy optimization.  :)
[14:42] <henninge> deryck: when shall we have our chat? voice or type?
[14:42] <deryck> henninge, ah, crap.  should have stayed on, sorry.
[14:42] <deryck> henninge, I'll jump back in mumble.
[14:46] <henninge> deryck: https://translations.launchpad.net/ubuntu/natty/+source/gedit/+pots/gedit
[15:08] <gary_poster> EzraR, harder.  LP is not designed for it, and (the vast majority of) devs are not interested in helping because we want people using the central LP site, and satellite versions actually fight our goals.
[15:19] <maxb> EzraR: The main problems (AFAIK) are that parts of the code are specifically customized on the assumption that they are running on launchpad.net (like, linking off to the Ubuntu Shipit CD distribution site, for example), that the full documentation of all the cronjobs and various different component deployments are not public, and that there isn't really any such thing as a Launchpad release.
[15:21] <maxb> So, as much as I love Launchpad, it's not really viable to run separate instances unless you first found a project to derive a packaged version of the software
[15:21] <jml> some of these problems we are interested in solving. others less so.
[15:23] <maxb> An idea lurks in my mind that it might be a viable project to fork out the registry + core code.lp.net bits as a way to give Bazaar a realistic "Here's how you can host your company's branches internally" solution
[15:32] <deryck> henninge, do you know if bug 720673 has been deployed to lpnet yet?
[15:32] <_mup_> Bug #720673: TranslationMessage.origin field set incorrectly during import. <qa-ok> <upstream-translations-sharing> <Launchpad itself:Fix Committed by henninge> < https://launchpad.net/bugs/720673 >
[15:37] <jml> maxb: I think thumper has been working on something similarish, although not by forking registry code.
[15:38] <maxb> You'd need at least the concept of projects, teams and people, wouldn't you?
[15:39] <jml> teams are optional, really.
[15:53] <bigjools> jml: regarding that sleep - I could not figure out how to avoid it other than to try and hack some crap in like the original poppy
[15:53] <henninge> deryck: it's not. It's the next revision ready to be deployed.
[15:53] <deryck> henninge, ok, great thanks!
[15:54] <deryck> abentley, and your stuff that's in the deploy ready lane is all db-devel stuff, right?
[15:54] <jml> bigjools: yeah. I've said how I'd do it, and I think that's pretty similar to how original poppy worked.
[15:54] <henninge> deryck: I can request a deployment of revision 12410.
[15:54] <jml> we already have something hacked in to make tachandler work anyway.
[15:54] <abentley> deryck: no, some of it is devel stuff.
[15:55] <bigjools> jml: regarding the avatar, I can't return checkers.ANONYMOUS as it makes the FTP stuff go read-only
[15:55] <abentley> deryck: actually, none of it is db-devel stuff.
[15:55] <jml> bigjools: oh, I see. why do you return a different string there to the long string in the tac file?
[15:56] <deryck> abentley, and all qa-untestable, or there are bugs for any of them?
[15:57] <abentley> deryck: qa-untestable.
[15:57] <bigjools> jml: which long string?
[15:57] <deryck> abentley, ok thanks
[15:58] <deryck> I'll move the cards across then
[15:58] <jml> @$!#!@
[15:58] <jml> excuse me
[15:58] <jml> it's very hard to concentrate with this Ubuntu One bug.
[16:03] <jml> ok. my computer is usable again.
[16:05] <EzraR> thanks for the responses maxb and gary_poster
[16:44] <jml> bigjools: re "which long string", "userthatwillneverhappen"
[16:44] <bigjools> jml: IIRC, it makes the ftp server go anonymous since it matches the string
[16:44] <bigjools> or does it ...
[16:44] <bigjools> anyway, it seemed the wrong thing to do because conceptually they are not the same user
[16:45] <jml> are they not?
[16:45] <jml> oh, I see.
[16:46] <jml> bigjools: have you filed a bug about the anonymous => read-only thing?
[16:46] <bigjools> jml: no, I don't see that it's particularly wrong
[16:46] <bigjools> we just have a weird ass thing we're doing in poppy
[16:48] <jml> Twisted should probably still support that.
[16:48]  * jml is looking deeper at the code
[16:48] <bigjools> maybe - or at least let me say whether it's a r/o session without it matching the user name
[16:48] <bigjools> maybe it should be a property of the avatar
[16:49] <jml> oh, also, you can pass portal and userAnonymous to the FTPFactory constructor.
[16:50] <jml> bigjools: I can't find the code in Twisted that does the read-only bit
[16:51] <bigjools> jml: search for userAnonymous
[16:51] <bigjools> in protocols/ftp.py
[16:51] <jml> I see that.
[16:51] <jml> but not where it's used to prevent writes.
[16:51] <bigjools> ok, one sec
[16:53] <bigjools> so, 1st, notice it sets the creds to credentials.Anonymous()
[16:54] <jml> but that's ok, because you get to decide in the Realm how we handle anonymous credentials
[16:54] <bigjools> then there's a FTPAnonymousShell that FTPShell inherits from
[16:54] <bigjools> most of the former throws AnonUserDeniedError
[16:54] <jml> but you aren't using either shell, you're returning your own.
[16:54] <bigjools> I know
[16:55] <bigjools> I can't remember wtf it goes wrong now!
[16:55] <bigjools> but it does
[16:55] <bigjools> ah
[16:55] <bigjools> it was to do with the Realm
[16:56] <bigjools> I'm going to have to comment that line to see where it breaks
[16:56] <jml> yeah, I'm running the tests now against an unmodified version of your branch, in preparation for some experimentation.
[16:57] <bigjools> ok, perhaps you can do it, I'm in the middle of making your suggested changes
[16:57] <jml> thanks.
[16:58]  * bigjools works out why we have both lib/lp/poppy/server.py and lib/lp/poppy/daemon.py
[16:58] <jml> they are both cruft now, right?
[16:58] <bigjools> yeha
[16:59] <bigjools> I'll be wielding a large axe at some point
[16:59] <bigjools> but I need somewhere to put a function common to both ftp and sftp
[16:59] <bigjools> __init__ it is :)
[17:00] <jml> this ZopelessAppServerLayer had better be worth the wait.
[17:03] <jml> actually, better to reboot first get these updates out of the way.
[17:03] <bigjools> reading every single zcml file to just get at one is annoying
[17:06] <bigjools> jml: so removing my override of the anonymous user prevents anonymous from actually logging in
[17:06] <bigjools> I decided it was easier to move it out the way that bugger about with another checker
[17:06] <bigjools> than*
[17:10] <thumper> maxb: check out lp:sloecode
[17:10] <thumper> maxb: we have it installed now, and I'll be writing something up soon
[17:13] <jml> turned out ZAPL was deadlocked somehow.
[17:14] <jml> in natty, I've lost my cpu usage indicator.
[17:15] <jml> bigjools: test_full_source_upload fails for me in an unmodified version of that branch.
[17:15] <bigjools> jml: it works here
[17:15] <bigjools> maybe the 5 seconds is not enough
[17:15] <jml> as does test_single_upload, both because of mode checking failures.
[17:15] <bigjools> hmm
[17:15] <jml> Difference: 34236 != 34228
[17:16] <bigjools> yeah I fixed that
[17:16] <jml>     self.assertEqual(os.stat(wanted_path).st_mode, 0102664)
[17:16] <jml> oh, maybe I need to pull again.
[17:16] <bigjools> hmm
[17:16] <bigjools> well it was fixed before the MP went up
[17:17] <jml> that's 0102674 != 0102664
[17:17]  * bigjools scratches head
[17:17] <jml> bigjools: what's your umask?
[17:17] <bigjools> ugh
[17:18] <bigjools> 0022
[17:18] <jml> same as mine
[17:18] <bigjools> just re-running the test
[17:18] <jml> in any case, the 7 means g+s, iirc.
[17:18] <bigjools> it's failing here now....
[17:19]  * bigjools boggles
[17:19] <jml> perhaps you were only running the ftp tests?
[17:19] <jml> it fails only for sftp for me.
[17:19] <bigjools> AH
[17:19] <bigjools> yeah that's it
[17:19] <bigjools> arse
[17:19] <bigjools> it should not be setting g+x, the test is right
[17:20] <jml> +x, of course. I'm a nong.
[17:20]  * bigjools googles nong
[17:20] <bigjools> ah, Australian slang.
[17:23] <bigjools> SFTPFile.writeChunk() was wrong
[17:24] <jcsackett> any chance someone could help me figure out what's going on with a traceback/test error? http://pastebin.ubuntu.com/570668/
[17:24] <jcsackett> something to do with me adding a where clause and join to a bug search, but i can't figure out how it's related.
[17:24] <bigjools> jcsackett: diff?
[17:26] <jcsackett> bigjools: http://pastebin.ubuntu.com/570669/
[17:27] <jcsackett> the test in that diff is fine; the one failing (amongst others) is the xx-front-page-search
[17:27] <jcsackett> thought i had gotten everything sorted, and ec2 kindly let me know i was quite wrong.
[17:28] <jml> bigjools: http://pastebin.ubuntu.com/570671/ seems to work. removes the need for the literal strings.
[17:29] <bigjools> jcsackett: it's hard to tell from your diff, but I suspect you can figure it out by selectively removing diff chunks until it works
[17:30] <jml> and/or writing a test that does a more focused version of whatever xx-front-page-search does.
[17:32] <jcsackett> jml, bigjools: yeah, i've tried removing things. if i get rid of my product clause adding segment it works. which confuses me, as i don't see what the connection is.
[17:32] <jcsackett> i will continue chipping away at it. thanks.
[17:33] <jml> jcsackett: oh, you mean the commented out section?
[17:33] <bigjools> jcsackett: which clause?
[17:34] <bigjools> storm errors suck :/
[17:34] <jcsackett> jml: that's not a commented out section, that's a very large comment block before the clause i'm talking about.
[17:34] <jml> oh
[17:34] <jml> my bad. green is how I colour comments in my editor :)
[17:34] <bigjools> heh
[17:34]  * jcsackett laughs.
[17:34] <jcsackett> i could see where that would be confusing.
[17:34] <bigjools> is the extra_clauses right?
[17:35] <jcsackett> bigjools: i believe so. it seems to follow how some others do it.
[17:35] <bigjools> you quoted it
[17:35] <bigjools> ah it's literal sql rather than storm
[17:36] <jcsackett> bigjools: yes; as you roll through this section an enormous query is built here and there.
[17:36] <bigjools> I wonder if that's buggering up the bit (that's not in the diff) where it's adding extra clauses?
[17:36] <bigjools> jcsackett: in the past I've debugged these by using pdb to step into the storm compilation
[17:36] <bigjools> it would be nice if it threw decent errors
[17:36] <jcsackett> bigjools: yes.
[17:36] <jml> or you could see the failing sql
[17:37] <bigjools> it's not getting that far jml
[17:37] <jml> bigjools: yeah it is. "statement" is defined in the traceback.
[17:37] <jml> bigjools: it's just not sending it to the db.
[17:38] <jcsackett> yeah, i tried pdb diving, but didn't find anything terribly useful. couldn't even easily get through to the part where this exception bubbled up from. many executions between a sensible point and the failure.
[17:38] <bigjools> jml: ah so it is
[17:38] <bigjools> my bad, it's generating duff sql somehow
[17:39] <bigjools> jcsackett: which means you can turn on LP_DEBUG_SQL_EXTRA
[17:39] <bigjools> and see what it's trying to do
[17:39] <jcsackett> is that an environment var to set, or what?
[17:39] <gary_poster> leonardr: https://code.launchpad.net/~gary/launchpad/subscriptions_for_bug-1/+merge/50788 when you get a chance, though I plan to get a bit of lunch soon
[17:41] <leonardr> gary, sure
[17:41] <bigjools> jcsackett: yes
[17:41] <gary_poster> thank you
[17:41] <jcsackett> bigjools: thanks.
[17:41] <jcsackett> i'll give that a try.
[17:41] <bigjools> jcsackett: you need LP_DEBUG_SQL, the latter gives a traceback too
[17:41] <jcsackett> bigjools: dig. just set to true, i assume?
[17:41] <bigjools> set anything, yeah
[17:43] <jtv> grrr why can't I push my branch to staging?
[17:43] <jtv> exec request failed on channel 0
[17:43] <jtv> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[17:44] <jml> jtv: what does 'ssh bazaar.staging.launchpad.net' tell you?
[17:45] <jtv> jml: err that it tries to ssh to bazaar.staging.launchpad.net?
[17:45] <jtv> jml: No shells on this server.
[17:46] <jml> jtv: hmm. so basic connectivity & authentication is fine.
[17:46] <jml> jtv: anything interesting in your ~/.bzr.log?
[17:47] <bigjools> jml: your patch does not work
[17:47] <jml> bigjools: in what fashion?
[17:47] <bigjools> you can't log in as "anonymous"
[17:47] <jml> bigjools: no tests failed.
[17:47] <bigjools> the tests suck then!
[17:48] <jml> bigjools: seriously, are you manually testing this stuff?
[17:48] <bigjools> jml: in some cases yes, because it's loads quicker than waiting for our shitty test harness to start up
[17:48] <bigjools> I thought this had a test case
[17:49] <bigjools> obviously not :/
[17:49] <jml> maybe it's not in test_poppy
[17:49]  * jml runs all the poppy tests.
[17:49] <bigjools> jml: that will just use the *old* server
[17:49] <jtv> jml: there's the traceback, and then the next attempt shows nothing that strikes me as suspicious.
[17:49] <jml> jtv: ok. you're getting the error consistently?
[17:49] <jtv> yes—and there it is again.
[17:50] <jtv> I think the non-suspicious one was a different request.
[17:50] <jml> bigjools: I'm confused. I think I have misunderstood the point of your branch.
[17:50] <jtv> It logs the traceback.
[17:51] <jml> bigjools: you aren't changing poppy to use Twisted for ftp in this branch, are you?
[17:51] <bigjools> jml: the point is to add a new ftp service
[17:51] <jml> but not stop the old service
[17:51] <bigjools> the old one is not removed yet so we can switch over in parallel
[17:51] <jml> ok.
[17:52] <jml> that makes sense.
[17:52] <bigjools> other benefits include using your recently-landed haproxy stuff
[17:52] <bigjools> ok, what are these tests logging in with?!
[17:52] <jml> not mine
[17:52] <bigjools> oh flacoste said it was yours
[17:52] <bigjools> some tac stuff for load balancing?
[17:53] <jml> definitely not mine.
[17:53] <bigjools> oooo kay :)
[17:53] <jml> only coding I've done recently has been deleting old crap and adding sphinx doc gen stuff.
[17:53] <jml> anyway, what are these tests logging in with, I wonder.
[17:53] <leonardr> gary, review is in. i think you have some stuff you forgot to remove, but it's good otherwise
[17:55] <jml> ftp://ubuntu:@localhost:%s/
[17:56] <bigjools> jml: so the tests are using the bzrlib ftp transport
[17:56] <bigjools> ah you beat me to it
[17:56] <bigjools> sigh
[17:57] <jml> I've got to drop offline to test something. brb.
[17:59] <jml> back.
[18:00] <bigjools> jml: so making the user anonymous in the URL has the result of the test failing
[18:00] <jml> bigjools: yay
[18:01] <jml> bigjools: I guess we should have a couple of tests that try user:pass, anonymous and ubuntu w/out pass.
[18:01] <bigjools> yes
[18:02] <bigjools> poking my override back makes it pass
[18:03] <jml> that the override is needed to make them pass means there's a bug somewhere.
[18:03]  * jml keeps digging
[18:04] <bigjools> no doubt
[18:04] <bigjools> sorry I can't remember where was causing it :/
[18:04] <bigjools> I did dig deep to find it
[18:04] <bigjools> but I think it was because there's a separate checker for anonymous access
[18:05] <jml> there aren't any checkers in t/protocols/ftp.py
[18:08]  * jml really does prefer old standard_test_template
[18:11] <jml> bigjools: got it.
[18:11] <bigjools> jml: \o/
[18:11] <jml> bigjools: it was my bad. credentials.username doesn't exist for Anonymous().
[18:12] <bigjools> ok
[18:12] <jml> bigjools: and ftp.py reacts to *any* failure in the realm as an auth failure
[18:12] <bigjools> ha
[18:12] <jml> wait, no I don't.
[18:12] <jml> but that is definitely *a* bug.
[18:12] <jml> adding direct tests for some of this stuff as I go.
[18:13] <bigjools> jml: I am using credentials.username and it's fine
[18:13] <jml> bigjools: that's because you aren't logging in with the username that ftp has assigned to the anonymous user.
[18:14] <bigjools> ok
[18:14] <bigjools> yes
[18:14] <bigjools> meh
[18:14] <jml> got it for real.
[18:15] <bigjools> just pushed up fixed tests
[18:16] <jml> http://pastebin.ubuntu.com/570671/plain/
[18:16] <jml> bigjools: errr, wrong url.
[18:16] <jml> bigjools: http://pastebin.ubuntu.com/570708/
[18:18] <jml> bigjools: the actual, actual, actual issue was that the checker we'd defined was not being used for anonymous logins, because it hadn't declared that it could handle such things.
[18:21] <bigjools> \o/
[18:22] <bigjools> jml: this stuff is too complicated
[18:23] <jml> bigjools: it's certainly not easy to understand.
[18:23] <bigjools> so I see from your comments in #twisted :)
[18:23] <jml> bigjools: but I don't think that's quite the same as "too complicated". I'm not sure what I'd remove.
[18:24] <bigjools> if it's not easy to understand it must be too complicated
[18:24] <bigjools> I suspect a lot of this is down to snow blindness
[18:28] <jml> cred is actually an elegant design, and surprisingly simple. it's just hard to get one's head around at first.
[18:29] <jml> we really would have been helped here by unit tests instead of integration tests.
[18:29] <jml> (won't say it again, promise)
[18:36] <bigjools> jml: ok so I've fixed everything in the review apart from the strports stuff.  I really, really hate seeing "tcp:NNNN" in the config and I want to change that to just NNN but it means fixing production configs in parallel
[18:36] <flacoste> bigjools: i meant spiv
[18:36] <bigjools> so I will do it all as a simpler change later
[18:36] <bigjools> flacoste: heh, ok
[18:37] <jml> bigjools: ok. sounds good.
[18:37] <jml> bigjools: you've also applied the patch in the pastebin above?
[18:37] <bigjools> jml: the extra credentials?
[18:37] <bigjools> yes, if so
[18:38] <jml> bigjools: yeah, extra creds, return credentials.ANONYMOUS instead of "poppy", don't bother setting factory.userAnonymous
[18:38] <bigjools> all done
[18:39] <bigjools> now I need to so the sleep removal thing
[18:39] <bigjools> but, after sleeping myself
[18:42] <bigjools> night all
[18:42] <bigjools> thanks for the help jml
[18:42] <jml> bigjools: my pleasure.
[18:43] <bigjools> twisted is starting to make me think of regexes now :)
[18:43] <jml> the ftp server isn't its strongest point.
[18:43] <jml> spiv has spent the last ten years apologizing for it.
[18:47] <lifeless> moin
[18:47] <lifeless> jml: hi
[18:47] <jml> lifeless: hi
[18:48] <jml> lifeless: I haven't looked at your branch yet. it's third item in my queue, counting the thing I'm doing now.
[18:48] <lifeless> thats fine; its for your patch after all :)
[18:55] <lifeless> jml: how much longer are you around for this evening ?
[18:55] <jml> lifeless: probably at least another half hour to an hour
[18:55] <lifeless> jml: so, I should be ready for that call in about 10/15 if you can still spare the time
[18:55] <jml> lifeless: that would be ideal
[19:17] <jml> lifeless: hi
[19:17] <lifeless> jml: ready
[19:17] <jml> lifeless: ok
[19:48] <leonardr> i have a yui question, on the off chance anyone here knows anything about yui
[19:50] <leonardr> i'm trying to figure out why an event fired from one source file is not received by the handler in another file. is it possible they are running in different sandboxes?
[19:50] <thumper> leonardr: hi
[19:50] <leonardr> thumper:hey
[19:50] <thumper> leonardr: I've just asked that on #yui
[19:50] <leonardr> i've been poking at your branch for a while
[19:50] <leonardr> oh, great
[19:51] <leonardr> are you ok w/r/t the earthquake?
[19:51] <thumper> got my answer
[19:51] <thumper> yes, all fine here
[19:51] <thumper> no damage in Dunedin
[19:56] <leonardr> thumper: i may be doing something wrong, but changing Y.on to Y.Global.on doesn't change anything for me
[19:56] <thumper> leonardr: we need to use Y.publish(...)
[19:57] <thumper> leonardr: I'm just wondering how to pass the args through
[19:57] <leonardr> oh, we need to do the whole publisher thing
[19:58] <leonardr> thumper: maybe explicitly create the event object and assign the arguments to its attributes?
[19:58] <thumper> I think we need a fancy context
[19:58] <thumper> leonardr: aye
[19:58] <thumper> I've got a call with flacoste now, I'll continue looking after that
[20:00] <leonardr> thumper: ok, i'll hack at it a bit
[20:02] <thumper> I think I may have it...
[20:02]  * thumper makes run
[20:02] <jtv> mbarnett: no luck at all reproducing the permissions problem with that stats script… did it finish yet by the way?
[20:04] <thumper> hmm...
[20:04] <thumper> :(
[20:04] <thumper> not working yet
[20:04] <jtv> Anyone know why I can't push my branch to staging?  "exec request failed on channel 0"
[20:07] <leonardr> thumper: push what you have?
[20:09] <thumper> leonardr: done
[20:09] <leonardr> k
[20:09] <lifeless> gary_poster: hi
[20:10] <gary_poster> lifeless, hey
[20:10] <lifeless> gary_poster: I'd like to catch up a little, if you have time
[20:10] <gary_poster> lifeless, I have 20 minutes today, right now, and then I'm booked till EoD.  Tomorrow is good after team lead call (and a bit of lunch).  Which would you prefer?
[20:11] <lifeless> gary_poster: right now is best for me
[20:11] <gary_poster> ok
[20:11] <gary_poster> lifeless, I'm on mumble and draggable to where you'd like to talk (or tell me and I'll try to get there)
[20:12] <lifeless> I'll go grab a headset then
[20:12] <gary_poster> cool
[20:13] <gary_poster> I can
[20:19] <lifeless> may we switch to pots?
[20:19] <lifeless> internet voice fail - another quake going through at the moment
[20:20] <lifeless> gary_poster:
[20:20] <lifeless> gary_poster: ^
[20:25] <gary_poster> lifeless, skype?
[20:25] <gary_poster> lifeless, I can heat you fine, fwiw
[20:25] <gary_poster> hear
[20:36] <lifeless> gary_poster: I could hear you -much- better with skype, FWIW
[21:02] <jtv> leonardr: got another review for you if you're available!  https://code.launchpad.net/~jtv/launchpad/bug-723168/+merge/50808
[21:03] <leonardr> jtv, ok, it'll be a minute
[21:03] <jtv> thanks
[21:04] <deryck> Later on, everyone.
[21:13] <jtv> lifeless: any idea why I might not be able to push my branch to staging?  "exec request failed on channel 0"
[21:14] <mwhudson> jtv: sounds broken server side
[21:14] <jtv> no kidding :)
[21:14] <lifeless> jtv: I'd guess that the codehosting server is configured for the fork server but the fork server isn't
[21:14] <lifeless> (serving that is)
[21:14] <jtv> I'll pretend I understood that
[21:15] <mwhudson> without a losa around i guess that's not going to be possible to debug :/
[21:15] <jtv> :(
[21:15] <jtv> We had mbarnett earlier…
[21:42] <wgrant> sinzui: Hm, when did you ask me to do that?
[21:43] <sinzui> wgrant: ask what?
[21:45] <leonardr> jtv, r=me
[21:45] <jtv> thanks!
[21:48] <StevenK> leonardr: Hi! What's the next step with my lazr.restful branch?
[21:50] <leonardr> StevenK: it's approved, so you can merge it or i can do it for you
[21:50] <wgrant> sinzui: Me to look at what needs fixing in the person picker.
[21:51] <StevenK> leonardr: I've not done that before, but happy to merge it.
[21:51] <leonardr> StevenK: it's easy. just do a bzr co of trunk, then bzr commit with [r=leonardr]
[21:51] <leonardr> trunk being lp:lazr.restful
[21:52] <sinzui> wgrant:  oh. 1.5 weeks ago when we discussed goal. I think I cited the person-picker as something you should propose because of your experience with the issues
[21:53] <StevenK> leonardr: Ah. What about a release so I can drop about 90 lines from the LP tree? :-)
[21:54] <leonardr> StevenK: when you commit, bump the version number in src/lazr/restful/version.txt to 0.17.1, and add a summary in the NEWS.txt. then ping me and i'll run my release script
[21:55] <StevenK> leonardr: So merge my branch, adding [r=...] at the front, and then commit the version and summary information? Sounds fine
[21:55] <leonardr> y
[21:56] <StevenK> leonardr: Or I can change my move-test branch to also change the version, which would you prefer?
[21:57] <sinzui> hand up who has a IE that they can point at a dev instance
[21:57]  * sinzui expects no hands
[21:57] <leonardr> StevenK: change the move-test branch and merge the whole thing at once
[21:57] <StevenK> sinzui: I think you also need to ask "and will admit to it"
[21:58] <sinzui> StevenK: I really do not expect anyone to have windows. I don't
[21:58] <StevenK> leonardr: 0.16.1 -> 0.17.1, right?
[21:58] <leonardr> StevenK: we are now at 0.17.0, but launchpad is probably on 0.16.1
[21:59] <wgrant> sinzui: There is a machine here that I can boot into Windows if required.
[21:59] <wgrant> sinzui: I believe it has IE8.
[21:59] <sinzui> wgrant: the exact version I need.
[21:59] <wgrant> sinzui: What needs testing?
[22:00] <StevenK> leonardr: Hm, should I be concerned trunk's NEWS file has no mention of 0.17.0? :-)
[22:01] <leonardr> StevenK: what does bzr info say about your copy of trunk?
[22:01] <leonardr> you should be at revision 174
[22:01] <StevenK> leonardr: Yes, I was looking at my branch, not trunk :-(
[22:01] <sinzui> wgrant: I think I will attempt to create a simple page and script to exercise bug 500015. I hope it is a one line fix
[22:01] <_mup_> Bug #500015: IE js error in filebug <dhrb> <javascript> <lp-bugs> <oem-services> <story-ajaxify-dupe-finder> <Launchpad itself:Triaged> < https://launchpad.net/bugs/500015 >
[22:07] <StevenK> leonardr: Done. Do you need me to tag, or does your release script do that?
[22:07] <leonardr> StevenK: my script does that
[22:10] <wgrant> sinzui: Hm? Is it not easy enough to patch the page directly?
[22:11] <sinzui> wgrant: I thought so. I saved the page, but I need to do some hacking because the function is not wired to the button
[22:15] <leonardr> StevenK: all right, http://launchpad.net/lazr.restful/trunk/0.17.1/+download/lazr.restful-0.17.1.tar.gz is ready to go into launchpad dependencies
[22:16] <wgrant> sinzui: OK, I have the machine booted into Windows and explorer stopped hanging after I killed it 5 times.
[22:16] <wgrant> sinzui: It seems to connect to my LP instance OK.
[22:16] <StevenK> Haha
[22:16] <StevenK> leonardr: Thanks! If you need to go, I can work with someone else to update the download-cache and so on. Or I can keep asking you. :-)
[22:17] <wgrant> Hmm, that's not good.
[22:18] <leonardr> StevenK: copy it into lp-sourcedeps/download-cache/dist and commit it before your land your branch
[22:18] <leonardr> that's about it
[22:18] <leonardr> you'll need to update versions.cfg in launchpad
[22:18] <lifeless> flacoste: hi
[22:18] <flacoste> hi lifeless
[22:18] <lifeless> flacoste: whats the url for the haproxy status page?
[22:18] <lifeless> flacoste: the ppr needs to exclude that as well as +opstats
[22:18] <flacoste> lifeless: it does
[22:18] <flacoste> already
[22:18] <flacoste> :-)
[22:19] <flacoste> part of my initial patch
[22:19] <lifeless> hmm
[22:19] <flacoste> but for the record, the URL is /+haproxy
[22:19] <lifeless> launchpad except opstats
[22:19] <lifeless> (?<!\+opstats)$	
[22:19] <lifeless> doesn't look like it :)
[22:19] <flacoste> ???
[22:19] <wgrant> sinzui: Clicking Next on +filebug seems to just do refresh the page.
[22:19] <lifeless> https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-categories.html
[22:19] <flacoste> lifeless: All Launchpad except operational pages=(?<!\+opstats|\+haproxy)$
[22:19] <StevenK> leonardr: Yeah, that part I worked out, thanks.
[22:19] <lifeless> flacoste: ?!
[22:20] <sinzui> wgrant: excellent. The bug lives
[22:20] <flacoste> that's from from utilities/page-performance-report.ini
[22:20] <flacoste> hmm
[22:20] <lifeless> flacoste: maybe it needs to be deployed ?
[22:20] <flacoste> are we using a custom configuration on devpad...
[22:20]  * flacoste looks
[22:22] <lifeless> flacoste: should bug 451390 be 'escalated' ?
[22:22] <_mup_> Bug #451390: limited upload rights no longer give series nomination accept/decline rights <dhrb> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/451390 >
[22:22] <wgrant> Ah, there's the error.
[22:22] <flacoste> lifeless: nobody asked me for it<
[22:22] <sinzui> wgrant: Y.one('#bug_reporting_form') ?
[22:23] <flacoste> lifeless, the lpqateam launchpad tree is outdated...
[22:23]  * flacoste updates
[22:23] <lifeless> flacoste: we should get that done by nodowntime deploys
[22:23] <wgrant> sinzui: No, it's calling event.stopPropagation()
[22:23] <wgrant> sinzui: Which isn't supported by IE, AIUI.
[22:24] <sinzui> \o/
[22:24] <wgrant> Let's try cancelBubble instead.
[22:27] <wgrant> sinzui: Oh, no, this._event is undefined.
[22:27] <wgrant> How do I unminify this JS...
[22:27] <sinzui> I do not know.
[22:29] <spiv> jml: actually, the ftp server in Twisted isn't my fault, I wrote the ftp client
[22:30] <wgrant> Grar.
[22:30] <wgrant> The call stack is a dozen "JScript anonymous function"s.
[22:30] <wgrant> Not helpful.
[22:32] <flacoste> wgrant: see Deryck's email to the list
[22:32] <flacoste> wgrant: there is an env var you can set
[22:32] <flacoste> to have it build unminified
[22:32] <wgrant> flacoste: Ah, missed that one. Perfect.
[22:32] <wgrant> Thanks.
[22:32] <sinzui> wgrant: e.cancelBubble = true; is what I would have tried
[22:33] <flacoste> $ make clean_js
[22:33] <flacoste> $ make jsbuild JSFLAGS='--filetype=raw'
[22:33] <flacoste> wgrant: ^^^
[22:33] <flacoste> from 'State of lazr-js/YUI in Launchpad' email
[22:33] <flacoste> iirc, that only works for our JS
[22:33] <flacoste> not YUI itself
[22:33] <StevenK> wgrant: I've updated the screenshot for link-recipe-on-ppa-page
[22:34] <flacoste> bug 720097 tracks making it work for YUI
[22:34] <_mup_> Bug #720097: Support jsbuild's JSFLAGS filetype raw for YUI deps <javascript> <Launchpad itself:Triaged> < https://launchpad.net/bugs/720097 >
[22:34] <wgrant> StevenK: Link?
[22:34] <StevenK> wgrant: http://people.canonical.com/~stevenk/built-by-recipe.png
[22:35] <wgrant> StevenK: Could you publish that?
[22:35] <wgrant> So we can see how it looks alongside the timestamps.
[22:35] <sinzui> wgrant: mumble?
[22:36]  * StevenK tries to remember how to run the PPA publisher on mawson
[22:36] <wgrant> StevenK: ./scripts/publish-distro --ppa -vvomgbbqvvvvwefwepfiojwegfwrigwrgerg
[22:36] <wgrant> +.py
[22:37] <flacoste> for real???!???
[22:37] <StevenK> flacoste: No, wgrant is kidding :-)
[22:37] <sinzui> what that is too close to Ekke Ekke Ekke Ekke Ptang Zoo Boing Zow Zing!
[22:37] <flacoste> lol
[22:37] <flacoste> it still goes on the quotes page...
[22:38] <StevenK> sinzui: When you're undistracted, would you be able to UI review a branch of mine. wgrant has context, too.
[22:39] <sinzui> StevenK: thanks I will do it shortly
[22:41] <sinzui> wgrant: still no sound
[22:41] <wgrant> Hm.
[22:41] <wgrant> Did you hear me say hi earlier?
[22:41] <sinzui> I wish mumble let me read lips
[22:41] <sinzui> oh
[22:44] <huwshimi> sinzui: Lost internet for a second.
[22:48] <flacoste> lifeless: fixed
[22:49] <StevenK> wgrant: Running the publisher had no effect. :-(
[22:50] <lifeless> flacoste: \o/
[22:50] <wgrant> StevenK: It's not a P3A?
[22:50] <lifeless> flacoste: will it be updated by deploys?
[22:50] <flacoste> i also found out that i never commited the change i made to page-performance-daily-report.sh
[22:50] <flacoste> that's not corrected
[22:50] <StevenK> wgrant: No, it's public
[22:50] <flacoste> lifeless: nope
[22:50] <lifeless> flacoste: RT that ?
[22:50] <flacoste> lifeless: yes
[22:50] <flacoste> please
[22:50] <wgrant> StevenK: The publisher didn't crash? The publish flag isn't off?
[22:51] <StevenK> wgrant: It published the source, but not i386
[22:51] <wgrant> StevenK: I don't care about i386
[22:51] <wgrant> StevenK: But you need to run p-a to get binaries published.
[22:52] <StevenK> wgrant: Ah, if all you care about is source, then: https://code.dogfood.launchpad.net/~stevenk/+archive/daily/+packages
[22:53] <wgrant> StevenK: :(
[22:53] <StevenK> wgrant: Hm?
[22:54] <wgrant> StevenK: It looks bad next to the timestamps.
[22:54] <wgrant> It needs to be moved or rewritten.
[22:54] <wgrant> Possibly under Builds.
[22:54] <wgrant> sinzui: What do you think?
[22:55] <lifeless> timestamps ?
[22:55] <lifeless> looks like it should replace the 'Publishing details' text
[22:56] <wgrant> lifeless: The rest of that section is timestamps.
[22:56] <wgrant> So it looks out of place.
[22:57] <sinzui> sorry, I am still catching up
[22:57] <lifeless> hmm
[22:57] <lifeless> Bug 719249 needs qa
[22:57] <_mup_> Bug #719249: The new direct subscription overlay takes too long to load <qa-needstesting> <story-better-bug-notification> <Launchpad itself:Fix Committed by gmb> < https://launchpad.net/bugs/719249 >
[22:58] <wgrant> It does.
[22:58] <lifeless> I don't think anyone in yellow is still here, and gmb is out for the week
[22:58] <wgrant> I'm tempted to not-ok it for being insane.
[22:58] <wgrant> But I think it's actually ok.
[22:58] <lifeless> wgrant: its ok to go out for a few days
[22:58] <lifeless> it will get rolled back soon
[22:59] <lifeless> Bug 722568 also needs love
[22:59] <_mup_> Bug #722568: Empty TranslationMessages confuse stats <qa-needstesting> <Launchpad itself:Fix Committed by jtv> < https://launchpad.net/bugs/722568 >
[22:59] <lifeless> and Bug 720826
[22:59] <_mup_> Bug #720826: Add subscription description header for bug notifications <qa-needstesting> <story-better-bug-notification> <Launchpad itself:In Progress by danilo> < https://launchpad.net/bugs/720826 >
[22:59] <lifeless> and we can deploy everything
[23:01] <wgrant> Oh good.
[23:01] <wgrant> Even loading BugTask:+index in IE8 causes JS errors.
[23:02] <wallyworld_> wgrant: you admit to using IE? :-P
[23:03] <wgrant> wallyworld_: I'm attempting to debug +filebug in IE.
[23:04] <sinzui> wgrant: I see that pofile.js is using e.halt()
[23:04] <wgrant> I think our YUI setup is entirely broken in IE :/
[23:04]  * wallyworld_ hooks a big fisk
[23:04] <wgrant> The event facade is not being loaded.
[23:04] <wallyworld_> fish
[23:04] <wallyworld_> wgrant: i was just messing with you :-P
[23:04] <wgrant> Ah
[23:07] <lifeless> wgrant: are you in the malone beta team?
[23:08] <wgrant> lifeless: The alpha team? No.
[23:08] <lifeless> I'll join on qas and qa then
[23:08] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/less-lazr-security/+merge/50824 should make you happy
[23:09] <lifeless> oh
[23:09] <lifeless> its moderated
[23:09] <lifeless> flacoste: hey
[23:09] <wgrant> lifeless: Yes :(
[23:09] <lifeless> flacoste: can you check that Bug 719249 hasn't broken the subscription form on qastaging ?
[23:09] <_mup_> Bug #719249: The new direct subscription overlay takes too long to load <qa-needstesting> <story-better-bug-notification> <Launchpad itself:Fix Committed by gmb> < https://launchpad.net/bugs/719249 >
[23:10] <wgrant> StevenK: Yay. But what's in lazr.restful 0.17?
[23:10] <StevenK> wgrant: Something that thumper was after. I was going to wait until that lands, which should be soon.
[23:12] <flacoste> lifeless: sorry, i need to run
[23:12] <lifeless> flacoste: no worries
[23:13] <lifeless> mmm
[23:13] <lifeless> cody-somerville: ^
[23:13] <lifeless> these teams should be owned by ~launchpad
[23:13] <cody-somerville> hmm?
[23:13] <wgrant> lifeless: He's not an admin.
[23:13] <lifeless> doesn't need to be
[23:13] <wgrant> Oh.
[23:13] <wgrant> True.
[23:14] <lifeless> cody-somerville: would love it if you could help us with qa
[23:14] <cody-somerville> Sure. What do you need me to do?
[23:15] <sinzui> wgrant: StevenK: I am looking at https://code.dogfood.launchpad.net/~stevenk/+archive/daily/+packages . I got confused about what I should be looking at. Instead I just looked. found the "built by" line, then realised I do not know why there are two black bold chunks of text.
[23:15] <lifeless> cody-somerville: on qastaging
[23:15] <lifeless> visit a bug
[23:15] <lifeless> and click on the advanced subscroption thingy that you should see as a member of malone-aplha
[23:15] <lifeless> tell me that it works
[23:16] <lifeless> that is that it loads ok
[23:16] <lifeless> you don't need to actually change your subscription
[23:16] <wgrant> sinzui: The first one's boldness is not useful. The second one may be.
[23:17] <sinzui> StevenK: I suspect the chunks of text are reused, and the bold "Published" and "Pending publication" mix badly on this page
[23:17] <StevenK> I can stop it being pending :-)
[23:17] <cody-somerville> Does qastaging.launchpad.net/bugs/##### not work on qastaging?
[23:17] <sinzui> StevenK: I think the "Built by" is not important next to the "Published". I think both are is equal value
[23:18] <wgrant> cody-somerville: It works for me.
[23:18] <lifeless> cody-somerville: it should
[23:18] <lifeless> http://qastaging.launchpad.net/bugs/23 just worked for me
[23:18] <_mup_> Bug #23: baz redo should use merge3 for conflicts like most other commands do. <Baz (deprecated):Won't Fix> < https://launchpad.net/bugs/23 >
[23:18] <cody-somerville> hmm... maybe the bug I'm trying to access is too new
[23:18] <lifeless> cody-somerville: doesn't need to be an interesting bug - use 23 ;)
[23:18] <sinzui> StevenK: the <h3>s are victims of the stylesheet. I think I can fix that this week
[23:19] <wgrant> sinzui: I sort of want to remove all bold text from Launchpad, except maybe the occasional "this will kill something" warning.
[23:19] <wallyworld_> thumper: i like the stuff you did to the spr browser tests. removing the (fragile) huge text pattern matching strings
[23:19] <wgrant> It looks terrible.
[23:19] <cody-somerville> lifeless, If I click 'Subscribe' I get a modal dialogue with three options.
[23:20] <lifeless> great, thanks
[23:21] <cody-somerville> Its too bad that flexibility isn't available when subscribing someone else.
[23:21] <wgrant> cody-somerville: Yet.
[23:22] <cody-somerville> :]
[23:23] <wgrant> lp.registry.browser.person is too big.
[23:25] <wgrant> lifeless: I guess jtv was trying to QA that empty messages thing last night when he ran into the permissions issue.
[23:25] <lifeless> indeed
[23:28] <StevenK> lifeless: Are you aware if I can mix soupmatcher tags with text?
[23:28] <lifeless> I don't know
[23:35] <wgrant> sinzui: I am thinking about UI for the ownership change.
[23:35]  * sinzui look
[23:35] <wgrant> https://launchpad.net/~wgrant/+participation is going to be particularly problematic.
[23:35] <wgrant> We may need to split ownership into a separate table.
[23:36] <sinzui> Yes. That may be. I considered that too recently.
[23:36] <wgrant> It already lies.
[23:36] <sinzui> wgrant: also. I want to know what teams I own. Lp does not tell me
[23:37] <sinzui> I own more than I remember.
[23:37] <wgrant> Right.
[23:40] <thumper> wallyworld_: :-)
[23:41] <sinzui> wgrant: I was thinking I could avoid the owner column by showing "owner/admin" in membership. I want to list owned teams separately on a related page. I do not think about the teams I only own as something I participate in.
[23:41] <wallyworld_> thumper: that big blob of text was the real reason my branch failed, not the db crap i talked about this morning. i got mixed up with 2 separate issues
[23:41] <thumper> wallyworld_: ah...
[23:41] <thumper> wallyworld_: should be easier now
[23:42] <wallyworld_> but your changes mean that it wouldn't have failed if they had been done first
[23:42] <wallyworld_> so more robust moving forward :-)
[23:43] <wgrant> sinzui: Hmm. I don't like the idea of having them on separate pages, really.
[23:48] <cody-somerville> the less pages the better IMHO :-)
[23:49] <sinzui> wgrant: Adding it to a second table might work. Since non-member-owner cannot will not be able to participate (change the project the team owns for example), I think mixing these teams in a listing will lead to confusion.
[23:50] <wgrant> sinzui: That was my intention.
[23:50] <wgrant> Placing them in the same table would be very awkward.
[23:50] <cody-somerville> wait a second
[23:50] <sinzui> wgrant: consider the team that losas own. No one should think they participate in rosetta-admins or ubuntu-mirror-admins
[23:50] <cody-somerville> Are you saying that you're changing it so that being the owner of a team will no longer give you the permissions associated with said team?
[23:50] <sinzui> yes
[23:50] <sinzui> we are
[23:50] <wgrant> cody-somerville: It already gives you only a partial set.
[23:51] <cody-somerville> OEM Services *specifically* relies on this.
[23:51] <wgrant> You can add the owning team to your teams.
[23:51] <cody-somerville> Its intentional that they are not a member
[23:51] <sinzui> you can be a member, or you can just own, delegating the responsibilities to the members
[23:51] <wgrant> cody-somerville: Why?
[23:52] <wgrant> If they want the privileges of the team, they can be a member of the team...
[23:52] <cody-somerville> Membership causes bug mail
[23:52] <wgrant> Sigh,.
[23:52] <lifeless> cody-somerville: what benefit do you get by having the owner not listed as a member but getting the benefits of being a member
[23:52] <sinzui> cody-somerville: then we want to fix the bug mail case
[23:52] <wgrant> The bug mail case is actually just about fixed.
[23:52] <cody-somerville> lifeless, We have a pmteam that is able to edit and maintain all of our projects without actually being members of the individual teams
[23:52] <wgrant> Mute subscriptions are nearly here.
[23:52] <lifeless> cody-somerville: this is a pretty big issue
[23:53] <lifeless> cody-somerville: it causes lots of confusion at the moment, and reports on 'who can do X' are not possible until the ambiguity is resolved.
[23:54] <cody-somerville> I don't disagree that there is confusion. Its a huge issue for us. However, we intentionally exploit the current behavior for our benevolent needs so changing it without coordination would cause major disruption.
[23:54] <wgrant> We are not changing it wihtout coordination.
[23:54] <wgrant> We will communicate with all affected owners.
[23:55] <sinzui> cody-somerville: the pm case is a part of the project group non-sense that need fixing, probably with an axe
[23:55] <wgrant> sinzui: A Green axe, I suppose.
[23:58] <cody-somerville> wgrant, I had no doubt. I'm just doing a bit of that communicating right now to highlight that this in particular would be problematic for us ;)