[00:00] <wgrant> "bzr diff --diff-options='-C 10' -rancestor:../devel" seems to work fine.
[00:00] <StevenK> wgrant: Ooh, thanks!
[00:01] <huwshimi> sinzui: Great, thanks!
[00:04] <huwshimi> sinzui: How do I manually position that sprite (it always sticks it in the top right of the container right)?
[00:04] <sinzui> huwshimi: you cannot :(
[00:04] <huwshimi> sinzui: oh
[00:05] <sinzui> however maybe we can change the generation rules to create more white space to offset when the colour starts
[00:05] <huwshimi> sinzui: so should I create an html element to contain the sprite and position that?
[00:05] <sinzui> That will look right, but I think we have a line-height issue
[00:06] <huwshimi> sinzui: This seems like a pretty fundamental issue with our sprite generator :(
[00:06] <huwshimi> sinzui: you can't even right/center align or anything then.
[00:07] <sinzui> huwshimi: you are over thinking this. We have something that makes the sprite. We have rules in .sprite that does the basic offset. the other items in the css are non-negitiable
[00:07] <sinzui> huwshimi: that is because the image is a background
[00:08] <lifeless> wgrant: whats up with qas codebrowse?
[00:08] <wgrant> lifeless: qas http codehosting is broken.
[00:08]  * StevenK kills hudson
[00:08]  * sinzui looks for the sprite generation rules
[00:09] <wgrant> lifeless: I am hoping that codebrowse will magically unbreak once HTTP in general works.
[00:09] <lifeless> 301 look
[00:09] <lifeless> 301 loop
[00:09] <wgrant> Or that buildbot will not explode this time, will update db-stable, and then allow me to QA on staging instead.
[00:09] <wgrant> Yes.
[00:09] <lifeless> wgrant: is there an RT open ?
[00:09] <wgrant> lifeless: No.
[00:09] <wgrant> But spm was working on it before.
[00:12] <lifeless> win
[00:13] <lifeless> oracle kicked kohsuke from the java.net project for hudson
[00:13] <StevenK> That's a bit rude
[00:13] <lifeless> yes
[00:14] <lifeless> http://java.net/projects/hudson/lists/dev/archive/2011-02/message/15
[00:18] <StevenK> lifeless: To be frank, I'm disgusted at ORA for their handling of this
[00:18] <wgrant> Oh, awesome.
[00:19]  * StevenK is fixing Hudson to actually run a build
[00:19] <StevenK> Which wasn't helped by the cloud controller going off into lala-land
[00:21] <lifeless> StevenK: yeah, ditto
[00:22] <wgrant> Is anyone not disgusted about Oracle's handling of anything recently?
[00:23] <lifeless> oracle?
[00:26] <StevenK> Haha
[00:27] <lifeless> StevenK: want to review https://code.launchpad.net/~wgrant/launchpad/bug-654585-linkify-bug-acknowledgement/+merge/48254 ?
[00:27] <lifeless> flacoste: still around ?
[00:32] <StevenK> wgrant, lifeless: Reviewed
[00:32] <lifeless> StevenK: you still need a mentor right ?
[00:32] <StevenK> lifeless: Right
[00:32] <lifeless> thumper: ^ :)
[00:33] <thumper> ah?
[00:33] <lifeless> thumper: you're StevenK's mentor, right ?
[00:33] <thumper> yup
[00:33]  * thumper looks
[00:33] <thumper> StevenK: do you realise that wallyworld_ is waiting on a review from you?
[00:34] <StevenK> Oh, argh
[00:34]  * StevenK looks at that
[00:34] <StevenK> Got distracted by Hudson being broken
[00:41] <wgrant> StevenK: :( zip is awesome
[00:42] <StevenK> wallyworld_: Ugh, 960 lines.
[00:42] <StevenK> wgrant: Why :( ?
[00:43] <wallyworld_> StevenK: it's mostly tests etc
[00:43] <wgrant> StevenK: You said you hadn't seen it before.
[00:43] <StevenK> wgrant: No, I use map() for that sort of thing, but zip() looks good.
[00:44] <StevenK> The map() in Perl is scarier
[00:46] <wallyworld_> StevenK: thanks for review. You completely happy the code used to find the related package branches is ok?
[00:46] <StevenK> wallyworld_: Yes, it looks fine, providing your tests exercise it all.
[00:47] <thumper> StevenK, wgrant: commented
[00:47] <wallyworld_> StevenK: i think they do but i'm not 100% familiar with that part of the domain model so am a little nervous that i have missed something
[00:50] <wgrant> thumper: I initially added the class unconditionally, but it seems redundant, may be a lie (when text_to_html is inserted in the middle of some other text), and breaks dozens of tests.
[00:51] <thumper> wgrant: hmm...
[00:51] <thumper> wgrant: I'm flexible on the conditionalness of the css class, but I think the code needs tweaks
[00:51] <thumper> wgrant: it is unfortunate that it breaks so many tests
[00:51] <wgrant> And yes, your proposal is much easier to understand. The current one evolved from when it was unconditional.
[00:52] <mwhudson> wgrant, StevenK, lifeless: well, at least oracle's behaviour means that everyone should immediately jump ship to jenkins on github, i guess?
[00:53] <StevenK> That'd be nice.
[00:53] <lifeless> mwhudson: its not that simple ;)
[00:53] <StevenK> lifeless: It isn't?
[00:53] <lifeless> mwhudson: sonatype are following oracle; various corporate users have expressed concerns about the discussion with *their* mgmt
[00:54] <mwhudson> urgh
[00:54] <wgrant> well, let's hope that Oracle keeps blundering around destroying things.
[00:56] <StevenK> TBH, it seems more like controlled destruction rather than blundering
[00:56] <wgrant> They surely can't want the entire community to evacuate.
[00:58] <StevenK> They haven't been entirely clear and open about what they do want, either.
[00:58] <lifeless> they have
[00:58] <StevenK> Last I read, they were still discussing, have things moved on?
[00:59] <lifeless> they want the trademark, the core infrastructure libraries changed to ones with contributor agreements, compulsory contributor agreements for plugin authors
[00:59] <lifeless> strict process
[00:59] <StevenK> And this while they swear they don't have any customers using Hudson?
[01:00] <lifeless> the have support customers of hudson inherited from sun; they ak'd that. they don't have a hudson /product/ that they sell
[01:04] <thumper> rockstar: ping
[01:05] <thumper> or anyone else who is familiar with the lazr-js tests
[01:10] <wallyworld_> thumper: when you have a spare moment, can you rubber stamp (or not) that related bracnhes mp? i'm still a little nervous that the algorithm used to find the related branches is correct. it looks ok but...
[01:11] <thumper> wallyworld_: ok
[01:27] <StevenK> thumper: Seems like moveBranch is used by branch.setOwner, which will rename if necessary, but it wants a user to do the move as, and I don't feel comfortable just randomly grabbing at an admin
[01:27] <thumper> StevenK: ah... whut?
[01:28] <thumper> StevenK: perhaps we should talk this through
[01:28] <StevenK> thumper: Sure
[01:28] <thumper> StevenK: but give me a few minutes
[02:11]  * wallyworld_ thinks it's interesting that +linkbug on a branch page pops up an ajax form whereas +linkbug on an answer page goes to a separate page. would have expected some consistency there
[02:16] <thumper> wgrant: hey, can I throw a bug your way? https://bugs.launchpad.net/launchpad-buildd/+bug/693524
[02:16] <_mup_> Bug #693524: java failure in recipe builders <recipe> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/693524 >
[02:16] <thumper> wgrant: I was discussing with flacoste and we agreed it is an operational thing
[02:16] <thumper> wgrant: seems like an intermittent failure of some kind
[02:16] <thumper> wgrant: most likely needs input from lamont
[02:22] <thumper> mwhudson: hi, got a minute?
[02:22] <mwhudson> thumper: sure
[02:24] <thumper> mwhudson: otp now
[02:25] <lifeless> poolie: https://launchpad.net/~ubuntu-branches/+members#active
[02:26] <poolie> yes, i see
[02:26] <thumper> mwhudson: mumble or skype?
[02:26] <mwhudson> thumper: skype is usually more reliable
[02:26] <thumper> ok
[02:27] <mwhudson> logging in now
[02:27] <mwhudson> thumper: i can hear you!
[02:27] <mwhudson> let me play with alsamixer
[02:28] <thumper> mwhudson: what? no pulse?
[02:28] <mwhudson> thumper: can you hear me now?
[02:31] <lifeless>     Hard / Soft  Page ID
[02:31] <lifeless>      832 / 8921  Archive:+index
[02:33] <wgrant> lifeless: We have a winner.
[02:33] <lifeless> \i/
[02:33] <wgrant> 13:31:23 < lifeless>     Hard / Soft  Page ID
[02:33] <wgrant> 13:31:24 < lifeless>      832 / 8921  Archive:+index
[02:33] <wgrant> 13:33:12 < wgrant> lifeless: We have a winner.
[02:36] <wgrant> lifeless: Do we have a pattern for caching SQLMultipleJoins?
[02:37] <lifeless> gimme a sec
[02:38] <wgrant> I think I can probably turn it into a cachedproperty that returns a list. But I am hoping there is a less bad way that I've missed.
[02:39] <lifeless> Sorry was otp
[02:39] <lifeless> whats the join you're looking at ?
[02:40] <lifeless> wgrant: are you talking about caching the collection on a domain object ?
[02:41] <wgrant> lifeless: BinaryPackageRelease.files
[02:41] <wgrant> I need to prepopulate and cache that.
[02:41] <wgrant> Apart from iteration its users are fortunately few.
[02:41] <lifeless> wgrant: the simplest answer is don't use the .files attributes
[02:42] <wgrant> lifeless: Replacing it with what?
[02:42] <lifeless> wgrant: actually, lets step back
[02:42] <lifeless> wgrant: whats the service point you're optimising ?
[02:42] <wgrant> lifeless: CopyChecker.checkCopy and PublishingSet.copyBinariesTo
[02:43] <wgrant> This particular case applies to both, but mostly the former right now.
[02:43] <lifeless> they are internal apis
[02:43] <wgrant> Ah.
[02:43] <wgrant> Archive:+copy-packages and Archive.syncSource.
[02:43] <lifeless> whats the *service* point: LP API or pageid
[02:43] <lifeless> ok
[02:43] <wgrant> Both.
[02:43] <lifeless> do they deal with > 1 BinaryPackageRelease ?
[02:44] <wgrant> Yes.
[02:45] <lifeless> wgrant: ok, so we need to eager load for some N b-p-r the releated binary package files
[02:45] <lifeless> wgrant: we're going to want decorated result set's pre_iter_hook for this
[02:46] <lifeless> wgrant: in terms of exposing it, cached property is completely correct
[02:46] <lifeless> wgrant: If I was doing it I would:
[02:46] <lifeless> changes 'files = SQLM...'
[02:46] <lifeless> to '_files = SQLM...'
[02:46] <lifeless> create a cachedproperty for files which returns self._files
[02:46] <lifeless>  - not listified =
[02:47] <lifeless> and then eager load from where needed
[02:47] <lifeless> wgrant: do you see why not listified ?
[02:48] <wgrant> lifeless: No.
[02:48] <lifeless> its a collection; adding to a list wouldn't DTRT
[02:48] <wgrant> Right, but we never add to the collection, except with addFile.
[02:48] <wgrant> And the collection will be lazy.
[02:48] <lifeless> so perhaps that doesn't matter
[02:48] <wgrant> So we have to return a list.
[02:49] <lifeless> the service pointyou're optimising won't ever access the SQMLMultipleJoin anyway
[02:49] <lifeless> because you're going to be eager loading
[02:49] <wgrant> So it is going to sometimes return a list and sometimes a ResultSet?
[02:50] <wgrant> Er, SQLMultipleJoin, not ResultSet, but same thing.
[02:50] <lifeless> not the same, though similar ;)
[02:50] <lifeless> yes, thats correct, because result sets don't cache
[02:50] <wgrant> Same problems.
[02:50] <wgrant> eg. .count() works on one, but not the other.
[02:51] <lifeless> SQLMultipleJoin is  SQLObjectResultSet
[02:51] <wgrant> (oh how I wish we used SQLAlchemy...)
[02:51] <lifeless> wgrant: do you need to do counts() ?
[02:51] <wgrant> lifeless: Some places do.
[02:51] <wgrant> But I will make them use len.
[02:51] <lifeless> wgrant: in which case, back to my prior statement - stop using .files
[02:51] <wgrant> Because files will be a list very shortly.
[02:52] <lifeless> create a new thing - e.g. getFiles, have *that* always return a list and cache, and eager load it for the service point.
[02:52] <lifeless> or, migrate completely to lists if you like
[02:52] <wgrant> That seems like overkill for something that is an iteration-only attribute anyway.
[02:52] <wgrant> Right.
[02:52] <lifeless> wgrant: well, its not iteration only from what you say ;)
[02:52] <wgrant> Or we could use SQLAlchemy :D
[02:52] <wgrant> iteration and counting, no mutation or indexing, then.
[02:54] <lifeless> shiny http://www.thinq.co.uk/2011/2/1/new-it-announces-dreamplug-arm-box/
[02:54] <wgrant> Is Sheeva ARMv7?
[02:55] <wgrant> I thought it was Kirkwood.
[02:56] <thumper> [15:16:22] <thumper> wgrant: I was discussing with flacoste and we agreed it is an operational thing
[02:56] <thumper> [15:16:36] <thumper> wgrant: seems like an intermittent failure of some kind
[02:56] <thumper> [15:16:42] <thumper> wgrant: most likely needs input from lamont
[02:56] <thumper> wgrant: not sure if you saw those
[02:57] <wgrant> thumper: I didn't. I don't even know what they reference.
[02:57] <thumper> wgrant: sorry, I missed the earlier bits
[02:57] <wgrant> Sorry, my connection was out for 5 minutes or so.
[02:57] <thumper> [15:16:07] <thumper> wgrant: hey, can I throw a bug your way? https://bugs.launchpad.net/launchpad-buildd/+bug/693524
[02:57] <_mup_> Bug #693524: java failure in recipe builders <recipe> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/693524 >
[02:57] <wgrant> Ah, right, that bug.
[02:57] <wgrant> Yay.
[02:57] <wgrant> bigjools poked lamont about it a couple of days back, IIRC.
[02:57] <wgrant> He said he didn't know of anything.
[02:58] <thumper> hmm...
[02:58] <lifeless> we really need some trigram support in the namecache
[02:58] <wgrant> It sounds like it's running out of RAM, though.
[02:59] <wgrant> lifeless: namecache? targetnamecache, or is there another one?
[02:59] <lifeless> only one
[03:00] <lifeless> its a little noddy; we might be better off to move the target dereferences into it
[03:01] <wgrant> thumper: Hmmm, that's really odd.
[03:03] <wgrant> It's definitely a lamont sort of thing, unless someone else can hijack a virt builder and check it out.
[03:03]  * wgrant wanders out for a while.
[03:07] <stub> There is trigram support in postgresql-contrib. I've not bothered with it yet as it was part of the whole search story and unclear what our goal is.
[03:10] <stub> 'for sale in the UK' but the power plug in the picture is US. That might be my future media centre.
[03:10] <lifeless> stub: I think broadly we want to bring lucene/lucandra in
[03:10] <lifeless> stub: but we need stopgaps along the way
[03:10] <lifeless> stub: are you able to look at the scripts that restore [qa]staging ?
[03:11] <stub> whats up with them?
[03:11] <StevenK> qastaging's database is a few months out of date
[03:12] <lifeless> stub: as StevenK says, the qastaging db, while its schema is ok, has very stale data.
[03:13] <stub> We don't have a script to rebuild it?
[03:14] <stub> There seems to be a restore_launchpad_qa.sh in ~postgres/scripts on sourcherry
[03:15] <stub> So I guess a losa needs to run that.
[03:17] <lifeless> stub: hmm, I thought the plan was:
[03:17] <lifeless>  - restore to a temp db; clone that for staging (and patch); clone it for qastaging
[03:17] <lifeless> so both would restore at the same time.
[03:17] <lifeless> stub: could you run 'explain analyze select count(*) from bug join bugtask on bugtask.bug=bug.id where ftq('kpassgen') @@ BugTask.fti;
[03:17] <lifeless> '
[03:17] <lifeless> on the prod instances for me ?
[03:19] <stub> http://paste.ubuntu.com/561236/
[03:20] <lifeless> stub: thanks; thats very interesting
[03:21] <StevenK> Anyone available to review a branch of mine?
[03:21] <lifeless> apparently our full text index is sufficiently poor that a seqscan of all bugtasks is better than an index scan
[03:21] <lifeless> for a search returning one row
[03:23] <lifeless> StevenK: shoot
[03:23] <StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/merge-recipes-during-merge/+merge/48264
[03:23] <lifeless> wgrant: want some review practice?
[03:23] <stub> I can redo the 'build _new databases' and 'swap into place' processes, which is in database/replication/Makefile in the lp tree. The losa scripts will then need tweaking.
[03:23] <lifeless> stub: if you have the time, this would be nice to sort out
[03:25] <stub> I'll try and get something to test at the start of the next cycle. If we are desperate this cycle, we should rebuild with the existing process.
[03:29] <stub> I'm not sure now why this speeds things up.
[03:30] <stub> We only rebuild staging once per week at the moment because it is replicated, and the bulk of the time is building the replica.
[03:31] <stub> And rebuilding qastaging is faster with the existing process (restore dump, swap into place) than (restore dump, copy to new db, swap into place)
[03:32] <lifeless> stub: not desparate
[03:32] <lifeless> stub: whatever is faster is fine; I had an incomplete understanding
[03:32] <stub> It will speed things up if we go to Slony-I 2.0, because then we can use a new feature to build two replicated databases quickly.
[03:32] <lifeless> stub: the goal is weekly qastaging rebuilds
[03:32] <lifeless> stub: question for you on slony 1.x - with 2 slaves, are transactions done in parallel on the slaves?
[03:32] <stub> (restore a db, clone it, set up replication but tell slony the data is already good so no need to copy it from master -> slave)
[03:33] <lifeless> e.g. N time on master and then ~N on each slave, but the slaves don't wait for each other
[03:33] <stub> Its done in parallel.
[03:33] <lifeless> cool
[03:33] <lifeless> stub: in which case I think you confused yourself analysing the time for julians type change patch
[03:33] <stub> Otherwise replication would stop if any one slave fell over or was down.
[03:34] <stub> Oh... DDL.
[03:34] <lifeless> stub: its the same, surely?
[03:34] <stub> I think it is done master then all slaves in parallel. What is the formula on the wiki?
[03:34] <lifeless> stub: not sure; just saw you add another 50% for the second slave in backlog here the other day
[03:35] <stub> We tested this and worked out the correct formula  for DDL, but now I'm fuzzy on the actual empirical results :)(
[03:37] <lifeless> stub: uhm
[03:37] <lifeless> stub: help me out here; where is the bugtask.fti index
[03:38] <lifeless> stub: I see a gist index for bug.fti, but none for bugtask.fti
[03:38] <stub> For DDL, it could be either. Depends if Slony's EXECUTE SCRIPT runs the script on all nodes one in series, or all nodes in parallel, or creates an event that goes through the normal replication channels, or runs on the master then creates an event so changes propagate to the slaves per normal replication.
[03:38] <stub> Think the latter.
[03:40] <stub> Whoops. I guess we lost the index somewhere. They get created by fti.py.
[03:40] <stub> Perhaps when experimenting with GIN indexes a few years ago?
[03:41] <stub> Or fti.py might be broken and the index never got created...
[03:42] <lifeless> stub: could you create it on qastaging?
[03:42] <lifeless> I'm looking at this 7 second query, and 4 seconds of it seems to be text search
[03:45] <lifeless> wallyworld_: whats the bug you're working on that bug 711619 is a dup of ?
[03:45] <_mup_> Bug #711619: "Merged at revision" in merge proposal pages doesn't link to the revision <Launchpad itself:New> < https://launchpad.net/bugs/711619 >
[03:46] <stub> lifeless: its building now
[03:46] <lifeless> stub: wicked, thanks.
[03:46] <wallyworld_> lifeless: i'll look
[03:46] <lifeless> wallyworld_: perhaps its not a dup; but it seemed to be offhand to me.
[03:49] <stub> lifeless: Created
[03:49] <lifeless> stub: \o/
[03:49] <wallyworld_> lifeless: i'm landing bug 334336
[03:49] <_mup_> Bug #334336: Show which branch and bug are related to a revision <bugjam2010> <lp-code> <qa-ok> <Launchpad itself:Fix Committed by wallyworld> < https://launchpad.net/bugs/334336 >
[03:50] <wallyworld_> i'm only doing the extended reision listing on the branch index page though
[03:50] <wallyworld_> the merge proposal page is unchanged
[03:50] <lifeless> stub: drops the queries I was trying from 800ms to 50ms
[03:51] <stub> I'm creating the indexes on production (Bug #711632)
[03:51] <_mup_> Bug #711632: BugTask.fti missing an index <Launchpad itself:Triaged by stub> < https://launchpad.net/bugs/711632 >
[03:51] <lifeless> stub: thanks!
[03:51] <lifeless>          ->  Seq Scan on bugtask  (cost=0.00..52921.26 rows=158774 width=152) (actual time=0.022..550.938 rows=184186 loops=1)
[03:51] <lifeless>                Filter: ((distribution = 1) AND ((status = 10) OR ((date_incomplete IS NOT NULL) AND (status = 15)) OR (status = 15) OR (status = 20) OR (status = 21) OR (status = 22) OR (status = 25)))
[03:52] <lifeless> ><
[03:52]  * wallyworld_ hates qastaging timing out all the time :-(
[03:53] <wallyworld_> lifeless: if you want to see what it looks like: https://code.qastaging.launchpad.net/~bzr-pqm/bzr/bzr.dev
[03:53] <wallyworld_> bear in mind most bzr revs have linked branches
[03:53] <wallyworld_> many other series don't and only one or two revs will have those links
[03:54] <poolie> hi ian
[03:54] <wallyworld_> hi poolie
[03:54] <poolie> wallyworld_, oh, wow, that is nice
[03:55] <wallyworld_> makes it easier to get to stuff, that's why i picked up that branch during the bug jam - thought it would add value
[03:55] <wallyworld_> had to out it on hold while i was on leave, but landing now :-)
[03:55] <poolie> it would be nice if the bug icon was colored and the status/importance was shown
[03:55] <wallyworld_> s/branch/bug
[03:55] <poolie> i guess if this is already landed that could be done as a follow on
[03:56] <wallyworld_> hmmm. i just use the default rendering.
[03:56] <wallyworld_> perhaps if a bug is fixed it is always grey
[03:56] <wallyworld_> but i could show the importance
[03:57] <wgrant> wallyworld_: That requires identifying the task.
[03:57] <wgrant> MPs and branches already have code to do that, though.
[03:57] <wallyworld_> that would have to be another branch though, since this one is already qa-ok
[03:57] <lifeless> wallyworld_: ui thought; 'with linked bugs' is prose-like, but this isn't prose
[03:58] <lifeless> wallyworld_: just having the indented table of bugs is pretty self explanatory
[03:58] <wallyworld_> poolie: raise a bug if you want anything extra added :-)
[03:58] <wallyworld_> lifeless: i agree now that you point it out :-)
[03:58] <lifeless> At least 178 queries/external actions issued in 2.18 seconds
[03:58] <stub> lifeless: You might want to add input to https://code.edge.launchpad.net/~gary/launchpad/bug548-db/+merge/48263 , which is adding a boolean flag to Person.
[03:58] <lifeless>  thats reasonably snappy; could reduce the qquery count a little
[03:58] <lifeless> wallyworld_: nice work
[03:59] <lifeless> stub: is there a better place to add it?
[03:59] <wallyworld_> ta
[04:00] <lifeless> stub: ah, I see
[04:00] <stub> lifeless: New table maybe. At the moment, personal settings like this just got tacked onto Person (like the existing verbose_bugnotifications flag)
[04:00] <stub> and mailing list subscription policies
[04:03] <lifeless> commented
[04:04]  * wallyworld_ wonders why fields on ajax popup render in different order to when a separate page is rendered for the no script usage?
[04:04] <StevenK> lifeless: O hai, did my review fall off your radar?
[04:04] <lifeless> StevenK: I'm mentoring wgrant
[04:04] <lifeless> StevenK: and hes awol (lunch I guess)
[04:04] <wgrant> Oh, sorry, forgot about that.
[04:04]  * wgrant looks.
[04:05]  * StevenK reads scrollback
[04:05] <StevenK> Oh, now I see the prod. Sorry.
[04:05] <StevenK> lifeless: As a 'yes, this is a good idea' or 'no, this idea sucks' re bug 711636
[04:05] <_mup_> Bug #711636: Support linking bugs directly from the MP <Launchpad itself:New> < https://launchpad.net/bugs/711636 >
[04:07] <lifeless> StevenK: nice idea
[04:08] <poolie> wallyworld_, what tags should such a bug have?
[04:09] <wallyworld_> perhaps just ui?
[04:09] <wallyworld_> i don't think it's confusing-ui
[04:09] <poolie> no, i was wondering if it was 'code' or something
[04:09] <poolie> but perhaps that's irrelevant now
[04:09] <wallyworld_> that's what i was thinking
[04:10] <wallyworld_> poolie: could you also add a comment to remove the "with linked bugs" prose pretty please as per a comment a few lines back :-)
[04:10] <wallyworld_> it can be done as the one branch then
[04:10] <poolie> sure
[04:10] <wallyworld_> thanks
[04:10] <poolie> i agree with that too
[04:11] <poolie> is it just me or is that font especially tiny?
[04:11] <wallyworld_> i made it small (but hopefully readable) to ensure the rev listing didn't require so much page space with all the new info shown
[04:12] <wallyworld_> i can read it ok. do you think it's too small? it passed a proper ui review
[04:12] <poolie> oh ok
[04:12] <poolie> i can _read_ it
[04:12] <poolie> it just kind of jars
[04:12] <poolie> it's something like 50% of the size of the regular body text
[04:12] <poolie> and it's not really fine-print informaiton
[04:13] <wallyworld_> i like it because it still allows you eye to scan the individual revision lines easier
[04:13] <poolie> for instance it's 50% smaller than the copyright notice, and i care much more about the bugs
[04:13] <poolie> well, i just thought i'd mention it
[04:13] <wallyworld_> i can see your point too though
[04:13] <poolie> not a showstopper
[04:13] <wallyworld_> maybe we could let the dust settle so to speak and see if there are many complaints
[04:14] <wallyworld_> easy to change if required
[04:14] <poolie> wallyworld_, what happens if the bug was directly fixed in that revision rather than by a merge?
[04:14] <poolie> it's still shown, but not indented?
[04:14] <poolie> sure
[04:14] <wallyworld_> the bugs which are shown are those linked to the merged branch. so no branch = no bugs
[04:15] <stub> lifeless: For design, I'm leaning towards PersonSettings and TeamSettings. Columns not filtered on and the appserver doesn't need when dealing with lists of people can be moved into one of those two. So Person.displayname stays, but mail_resumption_date goes to PersonSettings and renewal_policy, mailinglist_* goes to TeamSettings.
[04:15] <wallyworld_> that's the current behaviour
[04:15] <wallyworld_> poolie: perhaps something else to add to your bug report?
[04:16] <stub> We start getting explicit separation of team/person then too, while keeping Person as PersonOrTeam which has been useful and will be hard to change.
[04:18] <poolie> wallyworld_, https://bugs.launchpad.net/launchpad/+bug/711641
[04:19] <_mup_> Bug #711641: bugs directly fixed in a revision aren't shown in branch view <Launchpad itself:New> < https://launchpad.net/bugs/711641 >
[04:19] <thumper> lifeless: should we be doing "except Foo, e" or "except Foo as e" ?
[04:19] <poolie> to me that's more of an actual bug (if true) not just a tweak
[04:19] <wallyworld_> poolie: agree. i'll look at it and do a fix sooner rather than later if there's a problem there
[04:20] <poolie> https://bugs.launchpad.net/launchpad/+bug/711643 for the nits
[04:20] <_mup_> Bug #711643: tweaks to branch merged-revisions view <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/711643 >
[04:20] <lifeless> thumper: either
[04:20] <poolie> thanks for adding it though
[04:20] <wallyworld_> poolie: will likely be next week after 11.02 rollout
[04:20] <lifeless> thumper: I'd write as e for things which are in lp core; things which bzr may want, for instance, we'll want python 2.4 compat
[04:21] <wallyworld_> poolie: np. spiv was interested as well in this feature i think
[04:21] <poolie> wallyworld_, btw, i'll help you and spm roll out the forking lp-serve changes next week
[04:21] <poolie> it's on the LPS page as an unusual deployment task
[04:21] <thumper> ok
[04:21] <StevenK> thumper: No mail from Aaron?
[04:22] <lifeless> stub: could you look at my last comment in bug 661988 - is there anything else we can /should do? and would a union like that be useful or nuts.
[04:22] <_mup_> Bug #661988: Timeout on Distribution:+bugs search <lp-bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/661988 >
[04:22] <thumper> StevenK: yes actually
[04:22] <wallyworld_> poolie: thanks. i hadn't yet followed up with that stuff
[04:22] <thumper> StevenK: I'll forward it to you
[04:22] <lifeless> stub: lastly, why do we bother having a bugtask fti column at all?
[04:22] <StevenK> thumper: Thanks
[04:23] <stub> lifeless: Full text search on targetnamecache?
[04:25] <stub> and statusexplanation (dunno why we want to search on that)
[04:25] <stub>  kde-guidance (Ubuntu)                    | 'back':70C 'bug':9C,45C,53C 'chang':67C 'click':57C 'close':7C 'column':65C 'comment':27C 'current':60C 'describ':23C 'futur':49C 'give':34C 'guidanc':3B 'hesit':42C 'inform':15C,38C 'investig':19C 'kde':2B 'kde-guid':1B 'lack':13C 'miss':37C 'need':17C 'new':72C 'pleas':28C 'previous':26C 'problem':21C 'reopen':29C,51C 'report':10C,46C,54C 'status':61C,64C,69C 'submit':44C 'thank':73C 'ubuntu':4B 'us'
[04:25] <stub>  update-manager-core (Ubuntu)             | 'core':4B 'manag':3B 'ubuntu':5B 'updat':2B 'update-manager-cor':1B
[04:25] <stub>  mozilla-firefox (Ubuntu)                 | 'around':26C 'b':31C 'back':37C 'check':50C 'complet':45C 'disabl':46C 'experi':41C 'firefox':3B 'flash':10C,22C,48C 'flash-play':21C 'float':25C 'folder':30C 'home':29C 'incompat':20C 'inde':8C 'left':58C 'ly':32C 'mozilla':2B 'mozilla-firefox':1B 'ok':5C 'old':16C 'player':23C 'pleas':35C 'plugin':49C,53C 'presum':19C 'problem':42C 'report':36C 'still':24C,40C 'ubuntu':4B
[04:27] <lifeless> thumper: is monday a pub hoiday?
[04:28] <thumper> lifeless: do you want it to be?
[04:28] <lifeless> would be nice :P
[04:28] <thumper> that it would
[04:28] <thumper> I think if all NZers agree, then it should be
[04:28] <thumper> we only have to convince mwhudson and pjdc
[04:28] <thumper> :)
[04:28] <lifeless> waitangi day is feb 6
[04:28] <thumper> yes
[04:28] <thumper> it is also the weekend
[04:28] <mwhudson> sadly it is not a holiday
[04:29] <poolie> wallyworld_, oh also https://bugs.launchpad.net/launchpad/+bug/711647
[04:29] <_mup_> Bug #711647: link from branch page to merge proposals <code-review> <easy> <ui> <Launchpad itself:Confirmed> < https://launchpad.net/bugs/711647 >
[04:29] <StevenK> lifeless: But you don't know what 'holiday' means?
[04:29] <thumper> mwhudson: if enough of us agree it could be
[04:30] <thumper> mwhudson: who'd tell them?
[04:30] <thumper> them being people and culture :)
[04:30] <mwhudson> http://www.stuff.co.nz/the-press/news/4593872/Labour-offers-to-Mondayise-public-holidays
[04:30] <mwhudson> well, this is a fair point
[04:30] <thumper> mwhudson: oh I know the current news
[04:30] <lifeless> ah
[04:31] <StevenK> wgrant: Thanks for the review. I'll fix all of the points.
[04:31] <lifeless> unlike christmas its not moved
[04:31] <lifeless> http://www.ers.dol.govt.nz/holidays_act_2003/dates/2010_13.html
[04:31] <wgrant> StevenK: Not pushed yet, or is LP being stupid?
[04:31] <stub> lifeless: LEFT JOIN is LEFT OUTER JOIN, unnecessary since all BugTasks have a corresponding Bug.
[04:32] <wallyworld_> poolie: those links in the revision listing are to the merge proposal
[04:32] <wallyworld_> but they render as the source branch name
[04:32] <lifeless> stub: yes, I've been testing with inner joins, no impact
[04:32] <poolie> ah, doh
[04:32] <poolie> they're all 404 on qastaging so i didn't realize that
[04:32] <poolie> what if there is no mp then?
[04:32] <wallyworld_> i think the data on qastaging is way old
[04:33] <poolie> to be precise, 500 not 404
[04:33] <poolie> sure
[04:33] <poolie> it doesn't have all branches
[04:33] <poolie> wallyworld_, in some ways it's weird to have a link with just the branch name go to the mp
[04:33] <poolie> it's inconsistent with almost everywhere else
[04:33] <wallyworld_> if there's no mp, then nothing is shown, the idea being (for launchpad at least) that all merged must come as a result of a mp
[04:33] <poolie> i agree it's the most useful link to have
[04:34] <lifeless> there is bug with the librarian on [qa]staging
[04:34] <lifeless> it doesn't have all the data
[04:34] <lifeless> and doesn't forward to the main librarian consistently
[04:34] <wallyworld_> the text you want to see is typically the branch, but the link goes through to the mp so you can see what was done etc
[04:36] <wgrant> lifeless: It forwards consistently. Except restricted files, which it doesn't do at all.
[04:36] <lifeless> right
[04:36] <lifeless> so its inconsistent :P
[04:36] <lifeless> fixable
[04:36] <lifeless> just need tuits
[04:37] <wgrant> Yeah.
[04:37] <poolie> ah, actually https://code.qastaging.launchpad.net/~nmb/bzr/239523-quiet-tag/+merge/37555 is a timeout error
[04:37] <poolie> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1859QS7
[04:38] <poolie> wallyworld_, i do think there's a ui bug here somewhere
[04:38] <poolie> perhaps it can be fixed as simply as just extending the link region to be
[04:38] <poolie> over the wards 'merged branch' too
[04:38] <poolie> maybe it doesn't matter
[04:40] <wallyworld_> poolie: pooliethat oops link doesn't work for me
[04:41] <wallyworld_> is it just the timeout?
[04:41] <StevenK> wgrant: TypeError: 'GenericBranchCollection' object is not iterable :-(
[04:41] <wallyworld_> not sure about including 'merged branch' in the link though
[04:42] <wgrant> lifeless: Why always use the ID columns?
[04:42] <wgrant> StevenK: Is there an obvious method to materialise it?
[04:42] <wgrant> .getBranches()
[04:43] <StevenK> wgrant: Oh, call .getBranches() on the collection?
[04:43] <wgrant> StevenK: Yes.
[04:43] <wgrant> StevenK: the collection can also be used to get MPs and stuff, so it's not directly iterable.
[04:43] <poolie> wallyworld_, try the oops again now; there is some flakiness
[04:44] <wallyworld_> poolie: that's just qastaging timing out as has been its want of late :-(
[04:45] <poolie> sure
[04:45] <wallyworld_> most times lately i've had to hit refresh several times for each new page i want to load
[04:45] <wallyworld_> seems to have gotten worse
[04:45] <poolie> just thought i'd mention it, seemed quite persitent
[04:45] <StevenK> wgrant: Which makes my tests break :-(
[04:46] <wallyworld_> poolie:  yeah, np.  quite frustrating
[04:46] <StevenK> Oh, I know why
[04:46] <StevenK> The objects from the store aren't security proxied
[04:46] <wallyworld_> poolie: i'm told it the server for qastaging "only" has 32GB of memory or something like that
[04:46] <StevenK> wallyworld_: The *db* server
[04:47] <StevenK> And it's shared with staging
[04:47] <wallyworld_> oh, yes. sorry. misremembered
[04:47] <StevenK> wgrant: Your choices are: 1) Use removeSecurityProxy, 2) Go back to using IMasterStore. Which of those two bad opinions do you like?
[04:48] <wgrant> StevenK: For what?
[04:48] <wgrant> Oh.
[04:48] <wgrant> Hm.
[04:48] <wgrant> No, for what?
[04:48] <StevenK> wgrant: _mergeBranches
[04:48] <wgrant> Why?
[04:49] <StevenK> wgrant: getUtility(IBranchCollection).ownedBy(from_person)
[04:49] <StevenK> wgrant: That returns security-proxied objects, using the Store doesn't.
[04:49]  * thumper EODs
[04:49] <wgrant> StevenK: rSP is better.
[04:49] <wgrant> More explicit.
[04:52] <wallyworld_> thumper: that failed ec2 land (the smtp error) - i ran the test via ec2 keeping the console open and they all passed. so i'm stuffed if i know why 2 ec2 land attempts failed. should i just lp-land directly?
[04:54] <lifeless> wgrant: avoids a few failure modes
[04:54] <lifeless> wgrant: Reference == Reference -> BOOM (bug filed on storm)
[04:54] <lifeless> wgrant: Reference == object -> late evaluation
[04:55] <StevenK> lifeless: I've stopped doing that anyway, based on wgrant's suggestions.
[04:56] <lifeless> StevenK: sure; I'm documenting why the suggestion per wgrant's query
[04:58] <lifeless> http://techcrunch.com/2011/02/01/bing-google-fight/ is hilarious
[05:00] <StevenK> wgrant: Changes pushed, diff updated
[05:02] <wgrant> lifeless: Could you please mentor that?
[05:02] <lifeless> sure
[05:02] <wgrant> StevenK: I am quite a fan of your _mergeBranches reduction.
[05:03] <StevenK> I know, it's awesome!
[05:03] <StevenK> Picking apart direct SQL, one cur at a time?
[05:04] <StevenK> wgrant: I can drop the cur argument from _mergeBranches and _mergeSPRecipes; or you don't care?
[05:05] <wgrant> StevenK: Missed that. Please do.
[05:07] <lifeless> oh
[05:07] <lifeless> hang on
[05:07] <lifeless> why are you changing from using UPDATE?
[05:07] <lifeless> doing this in python is a sure fire way to make it crawl to a halt
[05:07] <wgrant> It already iterated over all branches.
[05:07] <lifeless> wgrant: that sfine
[05:08] <wgrant> Ah, because we're now getting the actual branch objects, where we weren't before?
[05:08] <lifeless> no
[05:08] <lifeless> because we're issueing one update per branch
[05:09] <lifeless> rather than one update.
[05:09] <wgrant> We always were.
[05:09]  * lifeless rereads
[05:09] <wgrant> I had to read it a couple of times, yeah.
[05:09] <wgrant> It looks like it uses SQL to batch it.
[05:09] <wgrant> But no.
[05:09] <wgrant> It just uses it to be awkward.
[05:16] <lifeless> reviewed
[05:16] <lifeless> I think it needs  alittle more work, sorry.
[05:17] <StevenK> lifeless: nr is naked recipe
[05:17] <lifeless> poolie: do you have permission to set bugs to 'triaged' ?
[05:17] <lifeless> poolie: if not, I'd like to get you such permission so you can do triage :)
[05:18] <wgrant> rSP is inevitable in this sort of code.
[05:18] <lifeless> (in bugs about launchpad itself)
[05:18] <lifeless> StevenK: nr is very much a wtf variable name.
[05:18] <lifeless> StevenK: pep 8 says it would be n_r at minimum
[05:19] <StevenK> lifeless: How is possible that the merge operation would ever be permissible? You're effectively forcibly changing the owner out from under the current owner
[05:19] <StevenK> And ew, I like n_r even less
[05:19] <lifeless> StevenK: then perhaps naked_recipe :)
[05:19] <lifeless> letters are free
[05:19] <StevenK> I was trying to avoid that
[05:19] <wgrant> StevenK: I think we are tainted by Soyuz, where acronyms are inevitable.
[05:19] <lifeless> no charge
[05:20] <lifeless> StevenK: the person delete is the last step to occur, permission checks should pass trivially.
[05:20] <StevenK> They don't
[05:20] <StevenK> lifeless: And I can't think of a way to do a mass update -- how does that handle name conflicts?
[05:20] <StevenK> Aside from bailing :-)
[05:20] <wgrant> How should they pass trivially?
[05:20] <wgrant> We are stealing someone else's objects.
[05:20] <lifeless> one thing at a time
[05:21] <lifeless> wgrant: we should be running in the context of the user handing the objects over
[05:21] <wgrant> lifeless: Heh.
[05:21] <StevenK> And they still don't have permission to edit someone elses objects?
[05:22] <lifeless> StevenK: they don't need it? they edit their own object to be acceptable, then hand it over.
[05:22] <wgrant> They shouldn't be able to do that.
[05:22] <wgrant> They can, but it's a bug.
[05:22] <StevenK> Actually, merge code is called from the person *recieving* the objects
[05:22] <StevenK> It's *merge* *into*
[05:22] <lifeless> so, if thats the case, we will need rsp, but its a *bug* that we need it.
[05:23] <wgrant> You can't reassign a recipe to someone else, only one of your teams.
[05:23] <lifeless> wgrant: I would solve this by establishing a temporary team binding the two accounts together, both in admin roles
[05:23] <wgrant> Perhaps merge needs to adopt both security contexts.
[05:23] <lifeless> right
[05:23] <poolie> lifeless, i have permission to triage bugs in lp
[05:24] <wgrant> But that sounds somewhere between difficult and OMGZOPEKILLMENOW
[05:24] <lifeless> wgrant: StevenK: rsp will be ok, but please add #fuglywhy notes where it is used.
[05:24] <poolie> i thought i triaged the ones i filed now
[05:24] <poolie> i might have missed on
[05:24] <lifeless> poolie: you marked them confirmed
[05:24] <lifeless> poolie: rather than triaged
[05:24] <lifeless> poolie: (or at least one of them)
[05:24] <poolie> just a slip
[05:24] <lifeless> no worries
[05:25] <StevenK> lifeless: rSP comment added, smaller comment addressed.
[05:26] <StevenK> lifeless: The two three line comments make sense to me, and obviously made sense to wgrant
[05:26] <lifeless> so the from person has a recipe with the same name as the to person
[05:26] <lifeless> type(left) == recipe
[05:26] <lifeless> type(right) == person
[05:27] <StevenK> Right
[05:27] <lifeless> which is bogus
[05:27] <StevenK> How is it bogus?
[05:27] <StevenK> Users are free to name recipes whatever they want
[05:27] <lifeless> but the name of the person doesn't matter, does it ?
[05:28] <StevenK> No, the name of the recipe is utterly seperate
[05:28] <StevenK> Just like the name of a branch
[05:28] <lifeless> Right, but the comment talks about the name of the *to person*
[05:28] <lifeless> I think we can rephrase it to avoid that :)
[05:28] <StevenK> if the from person has a recipe with
[05:28] <StevenK>         # the same name as the to person,
[05:28] <StevenK> I thought the 'has' would encompass both?
[05:29] <StevenK> That was the intent
[05:29]  * poolie wonders if it would be faster to write a non-email client than to get through all jelmer's bugspam :/
[05:29] <lifeless> Perhaps this:
[05:30] <lifeless> If both the from and to people have recipes with the same name, merging renames the duplicate from the from person's side.
[05:30] <wgrant> I thought the new policy was not to nitpick this sort of thing? I am happy to, but I thought we'd decided to avoid it.
[05:30] <lifeless> wgrant: its to only deal with things that cause confusion
[05:31] <lifeless> wgrant: I read it and my brain exploded
[05:31] <StevenK> Mission accomplished
[05:31] <StevenK> When Sarah asks me what I did at work today, I can tell her I made lifeless' brain explode.
[05:31] <lifeless> wgrant: when its a 'you say tomato' problem, theres no real benefit in trying to make everyone happy; when its unclear or wrong, it will cause wtfs on reading.
[05:32] <lifeless> wgrant: I've not been arguing for permissive, I've been arguing for functional.
[05:33] <wgrant> lifeless: Sure.
[05:33] <wgrant> I will do so in future.
[05:33] <lifeless> StevenK: so the problem (for me) with what you wrote was 'same (name as the to person)' - changing that to 'same name (as a recipe of the to person)' [() for clarity] would avoid the brain boom
[05:33] <lifeless> StevenK: that said, what do you think of my total rephrase?
[05:33] <lifeless> 18:30 < lifeless> If both the from and to people have recipes with the same name, merging renames the duplicate from the from person's side.
[05:34] <StevenK> lifeless: I liked it, so I've used it
[05:34] <lifeless> cool
[05:34] <StevenK> lifeless: Changes pushed.
[05:37] <lifeless> StevenK: +    def test_merge_moves_branches(self):
[05:37] <lifeless> 121	+        # When person/teams are merged, branches owned by the from person
[05:37] <lifeless> 122	+        # are copied.
[05:37] <lifeless> StevenK: and similarly in test_merge_moves_recipes
[05:37] <lifeless> StevenK: is it copy, or merge.
[05:37] <lifeless> I mentioned this in my review
[05:38] <lifeless> as it stands, noone can determine your intent
[05:38] <StevenK> The diff hasn't updated
[05:39] <lifeless> oh
[05:39] <lifeless> fooey
[05:40] <StevenK> lifeless: *Now* it has updated.
[05:49] <StevenK> lifeless: :-(
[05:50] <StevenK> lifeless: I'd hope the WTFPM is zero
[05:51] <lifeless> StevenK: can't be, we haven't solved the root cause
[05:51] <lifeless> (security context craziness)
[05:52] <StevenK> rm -rf zope
[05:54] <lifeless> stub: would nuking the nametargetcache and instead searching on the targets (20K vs 400K) help ?
[05:56] <stub> We used to do that IIRC... and targetnamecache was the 'solution'
[05:57] <lifeless> solutions are often moving targets ;)
[05:57] <lifeless> or really stopgaps (like prejoin)
[05:57] <lifeless> and sometimes genuine problems themselves ;)
[05:57] <stub> targetnamecache contains quite a bit - I'd have to check the script to see all the sources.
[06:02] <stub> So minimal impact would be working out trigrams and making the substring search fast. Next option would be turning off substring search (changing search behavior, but not sure how many people will notice). Next option dropping targetnamecache and doing substring search (or trigram) on pillarname.name (searching on less information, but people want fewer bugs rather than more don't they? :) )
[06:03] <stub> I'd go for dropping the ILIKE personally, but then I don't generally hear the screams of annoyance from our users ;)
[06:04] <stub> Leaving dropping targetnamecache altogether for our Search Solution™
[06:04] <lifeless> I'll mail ubuntu-devel about that
[06:05] <stub> The answer will be 'noooo', but most of that will be because people won't know things will work without it or know if they are making use right now.
[06:06] <stub> Perhaps drop the ILIKE if a feature flag is set so we can point people at the faster but more limited version?
[06:09] <lifeless> mailed
[06:09] <lifeless> stub: that would be a good way to experiment
[07:01] <LPCIBot> Project devel build (409): STILL FAILING in 6 hr 33 min: https://hudson.wedontsleep.org/job/devel/409/
[07:02] <wgrant> Can I knock windmill out of the test suite again? Plllllease?
[07:57] <wgrant> Is there more to making a custom egg than hacking the version in setup.py and running sdist?
[08:06] <lifeless> shouldn't be
[08:06] <lifeless> check __version__ matches
[08:11] <wgrant> Sigh.
[08:14] <lifeless> wgrant: so
[08:14] <lifeless> rev 12290
[08:14] <lifeless> is it qa bad?
[08:14] <wgrant> lifeless: I marked it as such a couple of minutes back.
[08:15] <lifeless> kk
[08:15] <lifeless> was just eyeballing deployment-stable
[08:15] <lifeless> I might get 12289 deployed
[08:15] <lifeless> BugMessage.index ftw
[08:16] <wgrant> I still have a 12293 deployment request sitting in a text editor.
[08:16] <wgrant> You might want to grab its bug numbers, unless you want to reharvest them yourself.
[08:16] <lifeless> oh foo, can only doo 12276
[08:17] <wgrant> Oh, right, yes.
[08:17] <lifeless> 90 being fixed would let 93 be goodd
[08:17] <lifeless> I'll add the security.py to unusual rollout nodes
[08:43] <lifeless> wgrant: fyi I've qa'd all the other revs
[08:55] <adeuring> good morning
[08:58] <allenap> Morning adeuring :)
[08:58] <adeuring> hi allenap!
[09:08] <wgrant> OMG
[09:08] <wgrant> lucid_db_lp passed!
[09:15] <mrevell> Hello
[09:17] <jtv> hi mrevell!
[09:17] <mrevell> Hey there jtv
[09:22] <wgrant> Uh.
[09:22] <wgrant> Massive devel failure.
[09:22] <bigjools> helleau
[09:23] <lifeless> wgrant: ?
[09:23] <wgrant> lifeless: r12302 (the SQL parameter logging thing) appears to be spectacularly broken.
[09:23] <wgrant> buildbot should fail shortly.
[09:24] <wgrant> Hmm, maybe not. It says <1 min left, but it's only done a couple of thousand tests (with 80ish failures).
[09:30] <lifeless> wallyworld: you did ec2 land that, right ?
[09:33] <wgrant> I guess I won't throw that openid thing at ec2 just yet.
[09:43] <wgrant> lifeless: Should we roll that back?
[09:44] <wgrant> It's not obvious what exactly is wrong, so fixing it sounds less trivial than I would hope.
[09:45] <lifeless> where are you seeing the fail ?
[09:45] <wgrant> lifeless: lucid_lp
[09:45] <wgrant> https://lpbuildbot.canonical.com/builders/lucid_lp/builds/581/steps/shell_6/logs/summary
[09:45] <lifeless> let me wait for openid....ok
[09:46] <lifeless> yeah thats borked
[09:46] <lifeless> rollback
[09:46] <wgrant> k
[09:46] <lifeless> wallyworld: we're rolling it back, its naffed.
[09:51] <wgrant> It's a couple back in the queue now.
[09:51]  * wgrant wanders off for a while.
[09:54]  * bigjools waits before ec2 landing stuff then
[10:10] <lifeless> allenap: hi
[10:10] <lifeless> actually, nvm.
[10:11] <allenap> lifeless: Hi anyway :)
[10:11] <lifeless> hi :)
[10:11] <lifeless> <- slightly batty today
[10:15] <lifeless> night all
[10:35] <bigjools> wgrant: are you working on the remaining log parser errors?  (or is it a pending-landing fix you already did?)
[10:37] <wgrant> bigjools: Pending deployment.
[10:37] <wgrant> I believe they're all fixed.
[10:37] <bigjools> awesome
[10:37] <bigjools> now, where has my daily soyuz report gone....
[10:38] <wgrant> mpt wants to make our database explode :(
[10:38] <bigjools> :)
[10:38] <bigjools> it would be a great change
[10:38] <wgrant> It would.
[10:39] <wgrant> I've wanted it for a while. But it's going to be a biggish table.
[10:39] <bigjools> resorting to dpkg -S sucks
[10:39] <bigjools> yeah, will need some interesting fti work
[10:40] <bigjools> oh man I can't wait for this debversion column to come in
[10:40] <bigjools> it's going to speed up so much stuff
[10:40] <wgrant> We can hope.
[10:40] <bigjools> no hoping, I know!
[10:40] <bigjools> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1858B2816
[10:40] <bigjools> look at the top query
[10:41] <bigjools> 2nd one makes me cry but for entirely different reasons
[10:41] <wgrant> It still needs cross-table indices to be not slow.
[10:41] <wgrant> This will make it less slow.
[10:42] <wgrant> But it will still be slow.
[10:42] <bigjools> debversion_sort_key is 90%+ of the time
[10:45] <wgrant> Hmm.
[10:45] <wgrant> It would still be nice to have indices :)
[10:47] <wgrant> Come on PQM, unbreak devel faster.
[10:51] <bigjools> yeah, they'll come in time but one thing at a time
[10:56] <wallyworld> lifeless: wgrant: i ec2 tested it and it all passed, 12000+ tests
[10:57] <wallyworld> i have the email to prove it :-)
[10:57] <bigjools> stub: so where are we at with the debversion stuff?
[10:58] <wgrant> wallyworld: Huh.
[10:58] <wallyworld> wgrant: the branch that's being rolled back - the sql logging one
[10:59] <wallyworld> just got back to my computer and saw some chatter about issues with that branch
[11:00] <wallyworld> wgrant: how did it show up as borked? given all ec2 tests passed i'd like to know what happened
[11:02] <stub> bigjools: If you merged back my branch, ready to land as far as I'm aware - apart maybe from getting launchpad-database-dependencies installed on various boxes. But I suspect we don't want it this cycle as we won't have enough time for testing.
[11:02] <bigjools> stub: it's been on dogfood for a week, I'm happy with it
[11:04] <bigjools> I'll chat to lifeless and see what he thinks
[11:04] <stub> Then I guess its full steam ahead from my pov.
[11:04] <wgrant> wallyworld: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/581/steps/shell_6/logs/summary
[11:05] <bigjools> stub: ok cool, I'll land it
[11:05] <wgrant> wallyworld: The change looks reasonable, too :/
[11:05] <bigjools> well when I've talked to rob
[11:05] <lifeless> bigjools: you're in luck, I was just about to really turn in
[11:05] <wgrant> wallyworld: But I can reproduce it locally
[11:05] <bigjools> lifeless: woohoo
[11:05] <wgrant> wallyworld: nascentupload.txt is the one I just tried.
[11:05] <stub> Shouldn't be an hour to apply either - 20-30 mins.
[11:06] <wallyworld> wgrant: thanks, i'll take a look. i also want to find out how my ec2 test run passed everything
[11:06] <wgrant> wallyworld: Could you forward the email?
[11:06] <lifeless> bigjools: so be quick :)
[11:06] <lifeless> bigjools: whats up?
[11:06] <bigjools> stub: right, 2* what staging took minus fudge factor is what I though
[11:06] <bigjools> t
[11:06] <bigjools> lifeless: I want to land the debversion change
[11:07] <bigjools> lifeless: and wondered what your thoughts are
[11:07] <lifeless> bigjools: What day is the releasE?
[11:07] <lifeless> db deploy
[11:07] <lifeless> thingy
[11:07] <wallyworld> wgrant: when i tried to ec2 land it, i got an email complaining an smtp attachment was too big, so i did an ec2 test run instead with the console held open to see if any failures would show up and everything passed
[11:07] <bigjools> uhrm
[11:07] <bigjools> next week
[11:08] <lifeless> yeah, thursday I think
[11:08] <lifeless> so
[11:08] <lifeless> if it:
[11:08] <lifeless>  - passes tests
[11:08] <wallyworld> lifeless: 9th feb
[11:08] <bigjools> it's been on dogfood for a week and seems fine
[11:08] <bigjools> I've hammered various bits with it
[11:08] <lifeless>  - is measurably faster in the case we're working on
[11:08] <wallyworld> wednesday utc
[11:08] <lifeless>  - and has stubs blessing
[11:08] <lifeless> then I think we're in decent shape to do it
[11:08] <bigjools> schweet
[11:08] <bigjools> lifeless: I'm just worried about package dependencies
[11:09] <lifeless> bigjools: I think you nede to build a new AMI
[11:09] <lifeless> or something
[11:09] <lifeless> for buildbot
[11:09] <bigjools> lifeless: that's fucking insane :/
[11:09] <lifeless> bigjools: AIUI it doesn't auto upgrade its package
[11:09] <wgrant> wallyworld: Oh, it was that branch?
[11:09] <wgrant> wallyworld: Hmm.
[11:10] <bigjools> lifeless: we need to fix that
[11:10] <wallyworld> wgrant: just look at the email now - i want to check something first
[11:10] <wallyworld> s/look/looking
[11:10] <lifeless> bigjools: we're nuking buildbot
[11:10] <bigjools> lifeless: I suppose I need to fix buildbot as well?
[11:10] <lifeless> bigjools: that will go a long way :)
[11:10]  * bigjools hunts for desctructions
[11:11] <lifeless> bigjools: the losas have installed the dependency on all db machines; worth checking with mthaddon about whether he updated bb instances too
[11:11] <bigjools> ok thanks lifeless, go to bed now
[11:11] <lifeless> wallyworld: whats this thing about mpt ?
[11:11] <wgrant> wallyworld: It is rather disturbing, although not at all unbelievable, that ec2 has some horrible bug here.
[11:11] <wallyworld> lifeless: what does mpt mean?
[11:11] <lifeless> wallyworld: matthew paul thomas
[11:11] <mpt> Many people have asked that question
[11:11] <bigjools> wgrant: or we have different packages installed ....
[11:12] <wallyworld> wgrant: i'd blame me before ec2. i had to have dome something wrong i'd say
[11:12] <wgrant> lifeless: I think you meant me.
[11:12] <lifeless> i did
[11:12] <wallyworld> lifeless: why you asking? now sure what you mean?
[11:12] <lifeless> darn
[11:13] <lifeless> wgrant: whats this thing ..
[11:13] <wgrant> lifeless: mpt (hi mpt) wants to put Contents in the DB.
[11:13] <wgrant> A good idea.
[11:13] <wgrant> But slightly scary.
[11:13] <lifeless> wgrant: thats the binary file mapping ?
[11:13] <bigjools> we eat scary for breakfast in soyuz
[11:13] <mpt> wgrant, is it a problem that I don't know what you're talking about? :-)
[11:13] <lifeless> wgrant: its only a few GB for all uploads ever to Ubuntu
[11:13] <lifeless> wgrant: I've  readyt made schema with fast queries we can use in the conflictchecker.
[11:14] <wgrant> lifeless: Yes.
[11:14] <lifeless> bigjools: ok, you're unblocked?
[11:14] <wgrant> But it's still quite a few rows.
[11:15] <lifeless> wgrant: 4M or something small like that
[11:15] <wgrant> lifeless: +ppa
[11:15] <bigjools> lifeless: yarp, thanks
[11:15] <lifeless> wgrant: files are pretty much statick
[11:15] <lifeless> wgrant: the join table is rather larger, but it has excellent selectivity
[11:15] <wgrant> True.
[11:16] <lifeless> wgrant: is there a LEP ?
[11:16] <wgrant> No.
[11:16] <lifeless> so, lets have one
[11:16]  * wgrant throws the codebrowse fix at ec2.
[11:16] <lifeless> we'll want use cases for schema design, the cases conflictchecker does may not match.
[11:16] <lifeless> sayonara
[11:16] <wgrant> Night.
[11:16] <bigjools> night
[11:17] <lifeless> oh
[11:17] <lifeless> one more thing
[11:18] <wgrant> Hmm.
[11:18] <lifeless> mpt: how do you feel about 'to use new features you must have javascript' being a default position for LP development ?
[11:18] <wgrant> Do I want to land this with rollback=?
[11:18] <lifeless> wgrant: yes, that tells qatagger where the bad-commit is fixed
[11:18] <lifeless> wgrant: also I think you haven't tagged it bad-commit yet
[11:18] <lifeless> mpt: food for thought, ciao
[11:19] <wgrant> I only worked out what bad-commit-* does this morning.
[11:19] <mpt> lifeless, I don't know how many current or potential users use script-less browsers for accessibility reasons, or are in corporate environments which disallow untrusted JavaScript
[11:20] <mpt> That's probably a research job for mrevell
[11:26] <wgrant> wallyworld: that's a bit special. The email body gives the right branch's revno, but the subunit log shows that the branch was not merged; the tests were run against devel itself.
[11:27] <wallyworld> hmmm.
[11:27] <wallyworld> wonder why i couldn't see the doc test in the logs?
[11:31] <wgrant> wallyworld: Try looking for nascentupload_txt instead.
[11:31] <wgrant> I'll look in a sec.
[11:31] <wallyworld> wgrant:  pretty sure i tried that but i am tired
[11:31] <wgrant> But natty's X stack is in league with ec2test; my kernel hung moments after I accused ec2 of being buggy.
[11:33] <wallyworld> wgrant: it was there.  cme can't type
[11:34] <wallyworld> wgrant: just looks like i managed to get it to run the tests against devel even though it thought it was using my branch
[11:34] <wgrant> Heh
[11:34] <wgrant> Yes.
[11:34] <wgrant> That is slightly odd.
[11:34] <wallyworld> wgrant: reason i did that in the first place was that when i did an ec2 land, it tried to email me the results and complained about the attachment being too big
[11:35] <jml> ?
[11:35] <wallyworld> so i thought i run the tests manually
[11:35] <jml> 300k attachments are blocked for you?
[11:36] <wallyworld> jml: not sure, never had an issue before
[11:36] <wallyworld> i'm sure i've had larger attachments than that
[11:36] <wallyworld> even with ec2 landings which ended up having lots of errors
[11:37] <jml> wallyworld: interesting. I think uncompressed the maximum output under 3MB. I guess if the test run crashes somehow you might get an attachment that big.
[11:37] <wallyworld> yeah guess so.
[11:38] <jml> anyway, I'd better get coffee & so forth.
[11:38] <wallyworld> now i need to figure out how i tricked ec2 to give me misleading info :-)
[11:44] <danilos> jtv, hi Jeroen, I'd love to get a review from you :)
[11:44] <jtv> danilos: oh, didn't see that on the system yesterday…
[11:45] <danilos> jtv, I am sure you didn't :)
[11:46] <danilos> jtv, https://code.launchpad.net/~danilo/launchpad/lifecycle-subscription/+merge/48185
[11:47] <jtv> danilos: I'll have to do it after lunch.
[11:47] <danilos> jtv, sorry, I think lunch is bad for you, so please do it now :)
[11:47] <danilos> jtv, anyway, sure, but if you think you'll take long, I might find a different reviewer
[11:47] <jtv-eat> There's a conflict by the way.
[11:48] <jtv-eat> I have to go get some stuff, so a different reviewer may be better.  Unlucky timing.
[11:48] <danilos> jtv-eat, indeed, thanks :)
[11:48] <danilos> jtv-eat, oh, btw, I am also OCR today :)
[11:48] <danilos> forgot about that ;)
[11:48] <danilos> gmb: hi, how do you feel taking a review of my LIFECYCLE change?
[11:49] <gmb> danilos: Well, I'm about to grab lunch, but once I've eaten I'll take a look.
[11:49] <danilos> heh, everybody runs for lunch when I ask for a review :)
[11:49] <danilos> gmb: sure thing, if jtv doesn't get to it first :)
[11:49] <gmb> Reviewing your code is obviously only possible after a significant intake of calories.
[11:50] <gmb> danilos: Okay, cool.
[11:50]  * gmb -> lunch
[11:58] <danilos> allenap, hi, I am taking a look at your https://code.launchpad.net/~allenap/launchpad/subscribe-to-tag-bug-151129-6/+merge/48295
[11:58] <danilos> allenap, can you tell me more about it? (it kind of scares me as well, since we are touching roughly the same stuff :)
[12:00] <allenap> danilos: I have to give my kids some food now. Can we talk in about 1h?
[12:00] <allenap> But sure, let's talk about it :)
[12:00] <danilos> allenap, sure, I'll try to review it in that time
[12:00] <danilos> allenap, perhaps coming up with more questions :)
[12:00] <allenap> danilos: Cool :)
[12:03] <deryck> Morning, all.
[12:50] <gmb> jtv-eat: I'm going to assume that you've not yet got to danilos's branch, so I'm going to grab it.
[12:50] <danilos> gmb: woohoo, thanks :)
[12:50] <gmb> :) np
[12:54] <allenap> danilos: Thanks for the review... I think you've uncovered a bug or two :) I'll reply now.
[12:54] <jtv> gmb: and since you've done that, it is now safe for me to return and find your message.  :)
[12:55] <gmb> :)
[12:55] <jtv> (Seriously, just got back—wasn't sitting here waiting ☺ )
[12:58] <LPCIBot> Project devel build (410): STILL FAILING in 5 hr 56 min: https://hudson.wedontsleep.org/job/devel/410/
[12:58] <LPCIBot> * Launchpad Patch Queue Manager: [r=abentley][ui=none][bug=702024] Expose a status page for haproxy on
[12:58] <LPCIBot> codehosting.
[12:58] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][no-qa] Include sql bind variables in the oops
[12:58] <LPCIBot> sql statements.
[12:58] <LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=435779] Changed "Get Started" text to make
[12:58] <LPCIBot> it a little more engaging (bug #435779). Also changed the
[12:58] <LPCIBot> sandbox link to point to http://quastaging.launchpad.net
[12:58] <LPCIBot> instead of http://staging.launchpad.net.
[12:58] <_mup_> Bug #435779: "Get started" text anti-climactic <lp-web> <post-3-ui-cleanup> <qa-needstesting> <Launchpad itself:Fix Committed by huwshimi> < https://launchpad.net/bugs/435779 >
[12:58] <LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=181368] CommandSpawner.
[13:13] <gary_poster> stub, thank you for the personsettings code!  Am I right that to get that landable I'll need to get new sampledata, or will that not really be necessary because it is a new table?  Also, I assume that your intent is that, for now, we don't remove verbose_bugnotifications from Person because that would make the ISD replication code more annoying?  So, we change the Person class to use personsettings for that flag,
[13:13] <gary_poster> worry about removing it from the Person table till later
[13:13] <gary_poster> truncated, I'm guessing
[13:13] <gary_poster> So, we change the Person class to use personsettings for that flag, but don't worry about removing it from the Person table till later
[13:15] <jtv> bigjools: parallel runs of apt-ftparchive seem to be passing all existing tests, plus what new ones I could come up with.  Now how do I see whether it's _really_ producing exactly the expected results?
[13:15] <jtv> I'm tempted to say I don't have enough of a "feel" for soyuz test coverage, but…
[13:16] <jtv> danilos: sorry about the review—I later realized you meant MP, not HRA, in your initial question.
[13:16] <jtv> Or as it's also known: "oh dear Kibo no, what do I need to countersign now?"
[13:17] <danilos> jtv, heh, no worries
[13:19] <bigjools> jtv: we run it on dogfood after uploading a package and make sure that we see the expected changes in the Packages file
[13:20] <jtv> bigjools: neither of my branches has hit db-devel yet, alas.  But it'd be really good to eyeball the changes _before_ I go into review.
[13:20] <jtv> Maybe I should ask wgrant to have a look.
[13:22] <bigjools> jtv: I can merge your branch into DF
[13:22] <bigjools> I can look too
[13:22] <jtv> bigjools: but you need at least db-devel for that, right?
[13:22] <bigjools> no, I can merge devel branches
[13:23] <jtv> oh great!  In that case, it's lp:~jtv/launchpad/bug-181368-parallelize
[13:24]  * bigjools mergerates
[13:25]  * jtv cheers the mergerati
[13:27] <jtv> bigjools: meanwhile, want me to take on those loggerhead oopses?
[13:27] <jtv> bug 701329
[13:27] <_mup_> Bug #701329: loggerhead OOPS - error: [Errno 32] Broken pipe <oops> <Launchpad itself:Triaged> <loggerhead:Invalid> < https://launchpad.net/bugs/701329 >
[13:27] <bigjools> jtv: I think someone analysed it already, have a look
[13:29] <stub> gary_poster: Yes, it needs new sample data generated. I forgot to remove the old Person.verbose_bugnotifications in the db patch and twiddle the trigger to do the right thing. hang on.
[13:29] <gary_poster> oh, k, thanks stub
[13:29] <stub> gary_poster: Or since you wanted this landed soon...
[13:30] <stub> I guess we do need to keep the old column around until the code is updated?
[13:30] <gary_poster> yeah
[13:30] <gary_poster> I could do that today
[13:30] <jtv> bigjools: alternatively, I could work on the patch to drop BranchRevision.id.
[13:31] <stub> gary_poster: Can you put in a code update so when Person.verbose_bugnotifications is set, PersonSettings.verbose_bugnotifications is also set? Or do I need to do that in a trigger?
[13:31] <bigjools> jtv: see if you can do a simple fix for loggerhead, I reckon it was just a case of swallowing the pipe error, so to speak
[13:31] <allenap> danilos: I've replied to your review. Let me know if you want to talk about BugSubscriptionInfo in general. I'm keen on promoting the idea (the implementation is okay, but I'm less concerned about that).
[13:31] <danilos> allenap, sure, otp now, so back to you in 10
[13:34] <jtv> bigjools: looking into it.  Lots of stuff that's not familiar but I see that as a good thing.
[13:34] <bigjools> jtv: indeed
[13:35] <gary_poster> stub, on call now, off call in 5
[13:42] <leonardr> jtv, danilos, i'd like a review of https://code.launchpad.net/~leonardr/lazr.restful/example-service-has-web-link/+merge/48313
[13:42] <leonardr> i can walk you through it if you have any questions
[13:42] <jtv> leonardr: I'll take it
[13:42] <gary_poster> stub, back.  If I put in that code, why don't I just change the code to look at personsettings instead?
[13:42] <gary_poster> Then we won't care about verbose_bugnotifications
[13:42] <stub> gary_poster: Sure. I suspect it will be minor.
[13:43] <gary_poster> Exactly
[13:45] <gary_poster> OK, stub, I'll work from your existing branch.  I assume your EoD is very soon.  Is this a plan?
[13:45] <gary_poster> - You make the change to "remove the old Person.verbose_bugnotifications in the db patch and twiddle the trigger to do the right thing".  Tell me when you are done with that, and I'll merge it into my branch, and MP it only asking for a db review initially.
[13:45] <jtv> leonardr: wasn't web_link something that came up in feeds?
[13:45] <leonardr> gary, i think we were going to do some work on lazr.restfulclient's bootstrap code and it got dropped on the floor
[13:45] <gary_poster> - I'll work on the other code.  I might be done when you are; if not, no problem, because you will have already approved the db parts, and I can get another reviewer to do the small code bits, and then land it
[13:46] <leonardr> jtv: can you be more specific?
[13:46] <leonardr> it might be a different feature with the same name
[13:46] <gary_poster> (stub: end)
[13:46] <leonardr> or it might be a client that woudl benefit from the feature
[13:46] <jtv> leonardr: I'm asking what web_link is, and I think I came across the term in the context of feeds recently.
[13:46] <danilos> allenap, all good, r=me
[13:47] <gary_poster> leonardr: yeah, that rings a vague bell.  I know lazr.restful couldn't make the update because zc.recipe.cmmi did not have a new version
[13:47] <allenap> danilos: Thanks :)
[13:47] <gary_poster> but restfulclient probably can
[13:47] <leonardr> jtv: i think it's another feature with the same name
[13:47] <leonardr> to give you an example,
[13:47] <leonardr> the web_link of https://api.launchpad.net/devel/~leonardr is https://launchpad.net/~leonardr
[13:47] <leonardr> does that make sense?
[13:47] <leonardr> it's the same object but on the website rather than the web service
[13:48] <jtv> ah
[13:48] <danilos> allenap, also, the branch itself seems to only be a relatively straightforward refactoring, so it didn't raise any concerns for me :)
[13:48] <stub> gary_poster: Yup. I'm finalizing the db stuff now.
[13:48] <allenap> danilos: Tip top.
[13:48] <gary_poster> awesome thanks stub
[13:48] <jtv> leonardr: thanks, that helps.  Different question: interested in the reason for moving your adapter registration from code to zcml.
[13:49] <leonardr> jtv: i didn't move it, those are new registrations
[13:49] <jtv> ah
[13:49] <leonardr> i can try to put them in code
[13:49] <jtv> No particular need (apart from I Hate ZCML), just asking.
[13:50] <leonardr> i didn't do them in code in the first place because the classes they register are not all defined within the example web servie
[13:50] <jtv> We need a structural improvement for that stuff, not two tags less.  :-)
[13:50] <leonardr> and i wanted all the definitions in one place
[13:50] <danilos> allenap, generally, I think add_bug_change_notifications should make better use of BugSubscriptionInfo instead of calling methods on the bug directly, but that'd be a long discussion that we wouldn't be doing anything on right now, so let's not have it :)
[13:51] <jtv> leonardr: thanks for explaining.
[13:51] <allenap> danilos: My plan at first was to make all of the subscription methods on Bug shells around BugSubscriptionInfo. Then it's easy to change call-sites.
[13:51] <allenap> Or easier at least.
[13:51] <danilos> allenap, agreed
[13:52] <leonardr> gary: depending on how much time you have, can you help me upgrade restfulclient or remind me what i need to do? i remember trying to just copy in bootstrap.py from launchpadlib
[13:52] <jtv> leonardr: in lines 62—63 of the diff, why the zope.interface.Interface in the "for" attribute that also has lazr.restful.interfaces.IWebBrowserOriginatingRequest?
[13:52] <gary_poster> leonardr: afternoon?
[13:53] <leonardr> jtv: it's a multi-adapter of a model object + a request
[13:53] <leonardr> i can try to make it a little more specific
[13:53] <jtv> If there is a fitting interface, that'd be nice.
[13:53] <leonardr> gary: earlier would be better, but i'll take what i can get
[13:53] <jtv> If there isn't, probably not worth it though maybe a comment would be nice.
[13:53] <gary_poster> leonardr: understood.  I'll ping earlier if I can
[13:54] <leonardr> jtv: i can use ILocation, but that's not really "more specific"
[13:55] <leonardr> it just happens to be the base interface of all these interfaces
[13:55] <jtv> leonardr: the name seems slightly more specific to me though… would it be an appropriate choice?
[13:56] <leonardr> i'll go ahead and do it. i'm a little worried it might be misleading
[13:59] <allenap> bigjools: Have you got a branch to add your AWS ID to VALID_AMI_OWNERS?
[14:00] <bigjools> allenap: yes
[14:00] <allenap> bigjools: Okay, I'll shut up.
[14:00] <allenap> :)
[14:00] <jtv> leonardr: at the risk of revealing my stupidity: might IHasLocation be appropriate?
[14:01] <leonardr> jtv: checking...
[14:01] <bigjools> allenap: just sent it to the gatekeeper...
[14:02] <leonardr> jtv: i believe IHasLocation is a launchpad interface, so i can't use it
[14:02] <jtv> ah, yes it probably is…
[14:02] <leonardr> i could define something similar but it would only exist to make that bit of zcml more readable
[14:02] <jtv> Not worth that then.
[14:06] <jtv> leonardr: moving right along, I read the name WebBrowserOriginatingRequest as meaning that the request either originated with a browser or originates a browser.  I can't make sense of the latter, and isn't the former the opposite of what it is?
[14:07] <jtv> Hmm I'm not being very clear myself.
[14:07] <leonardr> jtv: i understand what you're saying
[14:07] <leonardr> *as far as lazr.restful is concerned*, that request originated with a browser
[14:07] <jtv> I mean: isn't WebBrowserOriginatingRequest an adapter for requests that _didn't_ originate as a normal web browser request?
[14:07] <jtv> Ah.
[14:07] <stub> gary_poster: I think that is all done
[14:07] <leonardr> it turns requests that didn't come from a browser into requests that "did"
[14:08] <gary_poster> stub, awesome, thank you.  I'll merge and push up to a new branch for a db review then?
[14:08] <jtv> leonardr: but instances of its base class (probably) really did originate from a browser, right?
[14:08] <leonardr> jtv: in launchpad, yes
[14:09] <leonardr> you'd only do this if you were also handling real web browser requests
[14:09] <stub> bah... still pushing
[14:09] <stub> done
[14:09] <gary_poster> :-) k
[14:09] <jtv> leonardr: what I'm then wondering is: is "web-browser-originating" a good characterization of how this class differs from its base class?
[14:10] <leonardr> jtv: how about calling it SimulatedWebsiteRequest?
[14:10] <jtv> leonardr: that would be crystal clear to me, and match the description.  I like it.
[14:11] <jtv> Thanks also for cleaning up those old-style import lines, by the way.
[14:16] <jtv> leonardr: you have my vote.
[14:16] <leonardr> jtv: thanks
[14:16] <jtv> np
[14:21] <leonardr> gary, i've upgraded bootstrap.py. buildout.cfg looks like it was already changed. when i run bin/py i get the right code, but when i run bin/test it runs the wrong tests
[14:23] <bigjools> jtv: looks like you already did the parallisation unless I am misreading the diff?
[14:23] <jtv> bigjools: yup
[14:23] <bigjools> jtv: and it's landed?
[14:23] <jtv> Nope
[14:23] <gary_poster> leonardr: be with you as soon as I can
[14:23] <bigjools> heh ok
[14:23] <bigjools> just about to test it
[14:23] <leonardr> gary: np, just writing it down so it doesn't get lost
[14:23] <gary_poster> cool
[14:24] <jtv> bigjools: the landed version uses the CommandSpawner (a.k.a. MF) but still only runs one big process.
[14:24] <bigjools> jtv: I should probably be QAing that then, but later
[14:25] <jtv> bigjools: I was hoping to learn whether it's really still producing the right files.
[14:25] <jtv> It just runs separate apt-ftpserver instances all with a different --arch argument.
[14:25] <jtv> I _think_ that generates separate files without clashing, but it'd be nice to be sure. :)
[14:25] <jtv> (Note that "source" is an architecture for this purpose)
[14:29] <gary_poster> stub: https://code.launchpad.net/~gary/launchpad/bug548-db-2/+merge/48318
[14:29] <bigjools> allenap: how does one delete ami images?
[14:30] <allenap> bigjools: I used to know... let me try and figure it out again.
[14:30] <bigjools> allenap: when you do so can you update https://dev.launchpad.net/EC2Test/Image :)
[14:31] <allenap> bigjools: http://pastebin.ubuntu.com/561412/ -- and okay.
[14:31] <gary_poster> I use that in-browser console thingy
[14:31] <gary_poster> Amazon provides
[14:31] <bigjools> ahhh
[14:31] <gary_poster> yeah, what Gavin said
[14:32] <bigjools> shame theres no way of letting the scripts delete old ones
[14:32] <bigjools> we probably only need to keep the last 3
[14:35] <bigjools> "Unintrusize" - wth? :)
[14:35] <jtv> jam, got time to discuss bug 701329?
[14:35] <_mup_> Bug #701329: loggerhead OOPS - error: [Errno 32] Broken pipe <oops> <Launchpad itself:Triaged> <loggerhead:Invalid> < https://launchpad.net/bugs/701329 >
[14:45] <bigjools> abentley: your fix for recipe build mail landed on the 27th is breaking scripts
[14:45] <bigjools> they now need access to sourcepackagerecipebuild and are blowing up where they don't have it
[14:46] <abentley> bigjools, I added permissions to the script that failed tests because it needed it.    I got this: https://pastebin.canonical.com/42725/
[14:47] <gary_poster> That looks like something I might need your help with...or someone else with experience in those permissions
[14:48] <abentley> bigjools, doesn't that use the "queued" user?  I added sourcepackagerecipebuild = SELECT to that user.
[14:50] <bigjools> abentley: yeah that's right - this might be my bad then, one sec
[14:50] <stub> gary_poster: That just needs some tweaking in security.cfg
[14:50] <gary_poster> stub, I'm trying adding INSERT
[14:51] <gary_poster> to the table
[14:51] <gary_poster> in security.cfg
[14:51] <stub> Shouldn't need insert given the table is populated by a trigger...
[14:51] <gary_poster> yeah, that didn't help
[14:52] <stub> I don't have enough traceback to deduce further
[14:52] <gary_poster> any other suggestions?  ok one sec
[14:52] <stub> You need to make schema once you twiddle security.cfg of course
[14:52] <gary_poster> yeah, I did.  Here's the fuller context: https://pastebin.canonical.com/42727/
[14:53] <stub> gary_poster: So the user that script connects as needs permissions
[14:54] <gary_poster> oh!
[14:54] <danilos> allenap, deryck: hi, anyone has some spare minutes to pre-imp discuss bug 548? :)
[14:54] <_mup_> Bug #548: Launchpad sends change notification updates to the person who requested the change <email> <lp-bugs> <story-better-bug-notification> <story-better-notification-sending> <Launchpad itself:In Progress by yellow> < https://launchpad.net/bugs/548 >
[14:56] <allenap> danilos: In a few minutes?
[14:57] <danilos> allenap, sure thing
[14:57] <deryck> danilos, I'm jumping on another call now.  but I see allenap has you :-)
[14:58] <danilos> deryck, yeah, go on jumping about, thanks :)
[15:00] <bigjools> abentley: indeed it was my bad, apologies
[15:01] <flacoste> jml: mumble?
[15:02] <abentley> bigjools, no problem.
[15:02]  * bigjools needs to remember to run security.py
[15:04] <jml> flacoste: yep
[15:06] <gary_poster> OK, stub, I got that working.  I do have two test failures though, which increased a concern I was already wondering about.  The problem is that stuff like this fails
[15:06] <gary_poster>     >>> concise_team = factory.makeTeam(
[15:06] <gary_poster>     ...     name='conciseteam', displayname='Concise Team')
[15:06] <gary_poster>     >>> concise_team.verbose_bugnotifications = False
[15:06] <gary_poster> because the trigger fires at transaction commit, I assume
[15:07] <gary_poster> so the settings is not around yet. Should I just change the Python code to make a PythonSettings object if needed?
[15:07] <gary_poster> (Will that upset the trigger?)
[15:09] <gary_poster> (Or does that mean we should forgo the trigger entirely in favor of some Person.__init__ code?
[15:09] <gary_poster> )
[15:09]  * danilos has learned to hate triggers implementing any application logic in translations ;)
[15:10] <gary_poster> :-)
[15:10] <allenap> danilos: Mumble or Skype?
[15:11] <danilos> allenap, "yes" :) mumble
[15:11]  * danilos tries to find allenap's colour
[15:12] <abentley> allenap, I'm looking at the test you wrote for mrevell, and surprised to see monkey-patching.  Why not just use pop_notifications like we do in so many other tests?  Here's how I'd change it: http://pastebin.ubuntu.com/561431/
[15:14] <allenap> danilos: Bug 711910.
[15:14] <_mup_> Bug #711910: Move remaining subscription methods from Bug to sets on BugSubscriptionInfo <Launchpad itself:Triaged> < https://launchpad.net/bugs/711910 >
[15:20] <stub> gary_poster: The trigger fires when completing the statement. The problem will be that Storm might not notice?
[15:20] <gary_poster> oh! :-/
[15:20] <stub> gary_poster: or the trigger hasn't fired because Storm hasn't flushed changes yet.
[15:21] <gary_poster> stub, FWIW, I got a change that made the problem go away
[15:21] <stub> gary_poster: We can drop the trigger and maintain this in Python if it is easier - I'm not fussed.
[15:21] <gary_poster> I don't know if it is a good change
[15:21] <gary_poster> here's what I did:
[15:22] <gary_poster> lines 8-9, 125-130 in http://pastebin.ubuntu.com/561443/
[15:23] <gary_poster> I'd be fine with moving that to an __init__ and removing the trigger too; I'm too inexperienced with these bits to have an opinion.
[15:24] <stub> gary_poster: That will make things explode when the trigger gets fired, as it doesn't look before it leaps
[15:25] <gary_poster> stub, ack.  OK, the only easy solution I see is to rip out the trigger and put that logic in the __init__.  agree?
[15:25] <stub> gary_poster: Easy solution I see is to make _person_settings flush the Store before attempting to retrieve the PersonSettings
[15:25] <gary_poster> oh ok
[15:27] <stub> If that doesn't work, rip out the trigger. Or rip it out anyway if you develop a stronger opinion :) I put the trigger in simply because I thought it was less effort than tracking down everywhere Person objects get created (although I guess that should pretty much be covered by Person.__init__).
[15:29] <gary_poster> ack.  I am trying the test run with a flush, and removing the creation code
[15:29] <deryck> bac, hey, I'm about to look at that accordion stuff again, if that helps.  Had lots of YUI questions and work since we chatted....
[15:29] <gary_poster> nope, that fails
[15:29] <deryck> bac, so not able to look again until now
[15:29] <danilos> food, finally
[15:30] <stub> gary_poster: ok. you ok pulling out the trigger? Just needs the statement removed from the patch.sql and the function from trusted.sql
[15:30] <gary_poster> stub, yeah, I think I can do it
[15:35] <bigjools> jtv: http://pastebin.ubuntu.com/561451/
[15:36] <jtv> bugger
[15:36] <jtv> On a side note, like the error reporting?
[15:36] <bigjools> bt is always nice
[15:36] <jtv> I wonder why the existing tests don't reveal this.
[15:37] <jtv> I added script return values per architecture.
[15:37] <jtv> Is --arch a newer option perhaps?
[15:37] <allenap> abentley: Sorry I missed your ping. I was otp and forgot about it when I was done. I like your improvements :) mrevell, do you want to merge abentley's patch?
[15:37] <mrevell> Sure, will do
[15:37] <bigjools> jtv: check what versions of a-f are in lucid vs maverick
[15:37] <jtv> checking…
[15:38] <abentley> mrevell, please use the version in my MP comment; it is slightly improved.
[15:38] <mrevell> Will do abentley
[15:38] <abentley> allenap, cool.
[15:38] <mrevell> Thanks both
[15:38] <jtv> bigjools: big difference—0.7.25 vs 0.8.3.
[15:38] <bigjools> there you go
[15:39] <jtv> The lucid version doesn't have --arch. ☹
[15:39] <bigjools> our servers are all on lucid
[15:39] <bac> hi deryck.
[15:39] <bigjools> jtv: you could see if there's a backport
[15:39] <jtv> worth trying!
[15:39] <bigjools> look in -backports
[15:42] <jtv> excrement
[15:42] <jtv> Don't see it.
[15:48] <jcsackett|afk> deryck: any chance i could chat with you today about bug 421901 (particularly some refactoring ideas)?
[15:48] <_mup_> Bug #421901: Person:+bugs timeouts <lp-bugs> <timeout> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/421901 >
[15:48]  * jcsackett wonders when his nick changed to afk...
[15:48] <jtv> bigjools: on the bright side, the lucid version does have the _configuration item_ for architecture.
[15:49] <gary_poster> stub, my smoketest passes now.  I have pushed the branch, and diff is http://pastebin.ubuntu.com/561454/ (good bits starting line 1055)
[15:49] <bigjools> jtv: can we poke differently that in multiple parallel runs?
[15:49] <bigjools> edit fail
[15:50] <jtv> I thought you were just being funny.
[15:50] <bigjools> normally, yes
[15:51] <deryck> jcsackett, yeah, sure.  I'm trying to look into some YUI issues for bac now. then I want to eat.  Then we could chat.  cool?
[15:51] <jcsackett> deryck: sure. any chance at an approx time?
[15:51] <deryck> hmmm, you try to ping me down! ;)
[15:52]  * deryck looks at calendar/clock
[15:53] <deryck> jcsackett, forgot about team lead call, too.  Somewhere just after 1800 UTC work for you?
[15:53]  * jcsackett tries to do tz conversion...
[15:53] <jcsackett> that's like noon your time, 1pm my time, yeah?
[15:54] <jcsackett> deryck ^
[15:54] <deryck> jcsackett, yes
[15:54] <jcsackett> deryck: that would be great. thanks. :-)
[15:54] <deryck> jcsackett, google calendar can do dual time zones now, if that helps you :-)
[15:55] <jcsackett> deryck: that may very well help, thanks.
[15:55]  * deryck can teach you how to quickly convert TZs, win friends and influence people
[15:55]  * jcsackett laughs
[15:56] <stub> gary_poster: Looks fine.
[15:56] <gary_poster> Thank you very much stub
[15:56] <abentley> henninge, ping
[15:57] <henninge> abentley: Hi
[15:57] <henninge> abentley: sorry, got held up. Your review is next. Really.
[15:57] <henninge> ;-)
[15:57] <stub> gary_poster: Oh... your Python generates a PersonSettings for all Person records created, even teams.
[15:57] <abentley> henninge, can we mumble about how to share messages when new links are created?
[15:58] <gary_poster> stub, ah.  I forgot about that.  And I'm not even entirely sure how to distinguish.  But assuing you actually want to get off the computer, I'll try to find someone else to bother about that.  Thank you for the warning
[15:59] <henninge> abentley: sure
[15:59] <stub> if self.teamownerID is None: settings = PersonSettings()...
[15:59] <gary_poster> ah, easy enough
[15:59] <henninge> abentley: will be there in 30 sec ;)
[16:01] <bigjools> jtv: mvo says that we can backport maverick's a-f to lucid
[16:01] <jtv> bigjools: if that's easier/safer than writing separate config files…
[16:02] <bigjools> jtv: well I don't know how hard the latter would be, so you can make the call
[16:02] <bigjools> but it sounds like we should use --arch if we can
[16:03] <jtv> For the config file I'd have to figure out what else might rely on that config file.
[16:03] <jtv> I'll see how easy the backport would be.  I happen to have a lucid machine handy.
[16:04] <sinzui> mrevell: can you review the text and UI of my branch: https://code.launchpad.net/~sinzui/launchpad/team-membership-policy-1/+merge/48203 . You can also see/edit that same text at https://help.launchpad.net/Teams/CreatingAndRunning#Subscription%20policies
[16:05]  * mrevell looks
[16:09] <bigjools> jtv: mvo can help you, he's the package maintainer, have a word with him.
[16:09] <jtv> bigjools: thanks, I was just typing.  :)
[16:09] <bigjools> jtv: huh, didn't see you were on that channel :)
[16:48] <lifeless> moin
[16:55] <deryck> oh good holy internet gods it can't be so simple!
[16:55] <deryck> bac, gah!
[16:55] <deryck> bac, the script has to be inline on the page *after* the html elements. :-)
[16:56] <deryck> or defer all the stuff until domready
[16:56] <bac> deryck: really?
[16:56] <deryck> bac, *really*
[16:57] <deryck> the complexity of YUI makes us overlook the obvious
[16:57] <deryck> it's trying to render a widget based on html it doesn't know about yet
[16:57] <bac> deryck: doh.  cool, i'll play with it more after lunch.  thanks.
[16:57] <deryck> bac, np
[17:02] <lifeless> gary_poster: you can use self.is_team IIRC, which is specialised during __storm_load__ or whatever the hook it
[17:03] <deryck> adeuring, just reminder to update that bug status and delete card on the board. :-)
[17:03] <gary_poster> lifeless, yes, thank you. I found that and switched to it :-)
[17:03] <lifeless> \o/
[17:03] <adeuring> deryck: well... after my talk with Henning we decided that a bit work on the bug is reasonable ;)
[17:04] <deryck> adeuring, ah, ok.  I'll catch up about that after this call if you're still around
[17:04] <adeuring> ok
[17:10] <lifeless> allenap: oh, right - ih
[17:10] <lifeless> allenap: using one bug for several landings interacts poorly with our QA
[17:10] <lifeless> allenap: you might like to not do that :>
[17:10] <lifeless> allenap: (because you'll be fighting with the qa tagger robot otherwise)
[17:10] <allenap> lifeless: Okay, sure. Using bugs for managing QA interacts badly with my development process ;)
[17:11] <lifeless> allenap: yes, its a bit of a nuisance, and eventually we should decouple this more
[17:12] <allenap> lifeless: Cool. I'll file separate bugs in future.
[17:14] <lifeless> allenap: what I do is this; if I'm building up to something, I don't link to that bug until I'm there; I either land unqaable (if there isn't a user impact) or land with new bugs that focus the exact thing I'm changing rather than the user request
[17:14] <lifeless> allenap: this is a bit hit n miss
[17:15] <allenap> lifeless: Okay, that would work for me.
[17:15] <lifeless> allenap: anyhow, whatever works for you is fine; I only mentioned this cause I saw you starting to haggle over bug status with the qabot :)
[17:19] <allenap> lifeless: I keep forgetting to use the --incremental flag which, aiui, would dtrt for me.
[17:44] <lifeless> flacoste: so, 21utc you say ?
[17:44] <deryck> jcsackett, I'm off early.... wanna chat in mumble in 5?
[17:44] <jcsackett> deryck: sure.
[17:44] <lifeless> flacoste: which is what, 3.25 hrs ??
[17:44] <jcsackett> deryck: mano-a-mano in Green?
[17:45] <deryck> sure
[17:46] <lifeless> allenap: --incremental generats qa-untestable commits
[17:46] <allenap> lifeless: Ah, okay. I'll go with the multiple bugs then.
[17:46] <lifeless> allenap: so if you are confident they are deployable w/out qa, then yes, its what you want.
[17:47] <allenap> lifeless: Mmm, not normally :)
[17:47] <lifeless> :)
[17:47] <bigjools> lifeless: http://pastebin.ubuntu.com/561519/
[17:47] <bigjools> lifeless: any idea why my new ami does that when I start an instance?!  missing postgres.... wtf
[17:48] <lifeless> bigjools: pg 8.2
[17:48] <bigjools> lifeless: not even 8.2 is there
[17:48] <bigjools> the script is bong
[17:48] <maxb> The 8.2 is because the script is busted if no pg exists at all
[17:48] <lifeless> what ubuntu baseline did you use ?
[17:48]  * lifeless takes wild guesses
[17:49] <bigjools> lifeless: the one in the wiki page telling you how to do this stuff
[17:49] <lifeless> I love line 43
[17:49] <bigjools> https://dev.launchpad.net/EC2Test/Image
[17:49] <maxb> Does this AMI have launchpad-dependencies installed?
[17:49] <bigjools> lifeless: that's exactly why I pasted it :)
[17:49] <lifeless> blank lucid is right
[17:49] <bigjools> maxb: well that's interesting because I patched that package to include the new dependency
[17:50] <lifeless> bigjools: IIRC there is an issue with the metapackage
[17:50] <bigjools> ah crapola, I wonder if the dependency is on lucid
[17:50] <lifeless> something about v3, but that may be the CAT dependencies
[17:50] <bigjools> if only I had the output from the creation session
[17:51] <lifeless> postgresql-8.4-debversion |    1.0.3-1 | lucid/universe | amd64, i386
[17:51] <lifeless> postgresql-8.4-debversion | 1.0.3-1build1 | maverick/universe | amd64, i386
[17:51] <lifeless> postgresql-8.4-debversion | 1.0.4-1ubuntu1 | natty/universe | amd64, i386
[17:51] <lifeless> its on lucid
[17:54] <bigjools> I'll have to make a new image and watch where it fails.  Unless you have a better idea?
[17:59] <deryck[lunch]> adeuring, I must needs eat.  So we can chat tomorrow in the standup about this.  No big deal.
[17:59] <deryck[lunch]> just curious about what's happening
[17:59] <adeuring> deryck[lunch]: ok, no problem. Need to start lunch too ;)
[18:00] <adeuring> deryck[lunch]: ...and enjoy lunch
[18:24] <leonardr> danilos, please review this easy branch: https://code.launchpad.net/~leonardr/lazr.restful/bug-619180/+merge/48355
[18:27] <danilos> leonardr, hi, is .encode(utf-8) safe to do for URLs?
[18:27] <lifeless> if it is a url, then it must be a subset of ascii
[18:28] <lifeless> by definition
[18:29] <leonardr> danilos: what specific case are you thinking of?
[18:29] <danilos> ok, let me rephrase that... leonardr, is .encode('utf-8') safe to do before passing to webservice.get() [i.e. does it do escaping as appropriate, and is it documented that our webservice works with UTF-8]
[18:29] <danilos> leonardr, line 48
[18:30] <leonardr> danilos: well, the test works... that's a good question, though
[18:30] <danilos> leonardr, heh, ok, fair enough
[18:30] <danilos> leonardr, how do we answer that question?
[18:31] <leonardr> danilos: i'll take a look at the incoming request
[18:31] <jam> jtv: are you still around? I got stuck shoveling snow for a couple of hours this morning, but I'm around now
[18:31] <danilos> leonardr, cool, thanks... even if it might be a problem already, it doesn't have much to do with this branch I suppose, so r=me
[18:32] <danilos> leonardr, please do file a bug if you find it is, though
[18:32] <leonardr> danilos: actually, i know it works in reality, because ursula's test request went through properly (and once this fix is applied, it works everywhere)
[18:32] <leonardr> so i think httplib2 percent-encodes the utf-8, and that's how it works
[18:32] <danilos> leonardr, right, makes sense, thanks
[18:33] <danilos> leonardr, nice simple branch, thanks for the fix :)
[18:34] <leonardr> np
[18:35]  * danilos wanders off...
[18:56] <abentley> sinzui, I notice that Packaging is a many-to-many relationship.  Is this commonly used?  Our modeling of translation sharing assumes that there is at most one product per sourcepackage and vice versa.
[18:56] <sinzui> abentley: depends on the direction actually
[18:57] <abentley> sinzui, it's really one-to-many, then?  Which way?
[18:57] <LPCIBot> Project devel build (411): STILL FAILING in 5 hr 59 min: https://hudson.wedontsleep.org/job/devel/411/
[18:57] <LPCIBot> * Launchpad Patch Queue Manager: [rs=wgrant][rollback=12302] Revert r12302, which caused test failures.
[18:57] <LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=698032] When a recipe build has been
[18:57] <LPCIBot> removed since a recipe build was started,
[18:57] <LPCIBot> ensure the archive uploader does not fall over.
[18:58] <sinzui> abentley: a product series can provide many packages, but *at this time* a distroseries can have only one package
[18:58] <abentley> sinzui, thanks.
[19:00] <sinzui> abentley: That describes PRIMARY. There is hidden packaging type INCLUDES that makes the relationship very complex by stating a that implies a distroseries could have multiple sources. We are not allowing users to select that
[19:01] <abentley> sinzui, I don't understand "by stating a that implies a distroseries could have multiple sources"
[19:03] <abentley> sinzui, do you mean "by stating that implies a distroseries could have multiple sources"?
[19:03] <abentley> actually, I wouldn't understand that either.
[19:03] <sinzui> PackagingType.INCLUDES implies that a package for a distroseries is provided by many product series. This relationship really does happen, but it is much abused, and very confusing. We are not using it now, but I believe there is historical data using it
[19:04] <abentley> sinzui, okay, thanks.
[19:04] <sinzui> We never solved how to show multiple distroseries->packages in the UI, so no one knows we removed the kind of relationship
[19:05] <sinzui> abentley: I mention this because historical data could cause issues if you build something that requires distroseries(1) -> packaging -> (1) productseries
[19:08] <abentley> sinzui, I appreciate your completeness.  I'll discuss this with the Orange Mafia.
[19:13] <lifeless> sinzui: more than historical no? once we get buildfrombranchtomain underway?
[19:14] <sinzui> lifeless: no, There is no code using INCLUDES, and has not for more than a year
[19:14] <lifeless> sinzui: ok
[19:14] <sinzui> a lot of the uses were bogus because product owners do not understand packaging
[19:14] <lifeless> sinzui: we may get pushback on that in the future
[19:15] <sinzui> I understand. That is why I did not remove the type. We just need to ensure the people who need it have access to it
[19:15] <lifeless> ack
[19:16] <abentley> deryck, around?
[19:17] <deryck> hi abentley
[19:17] <abentley> deryck, mumble?
[19:18] <deryck> sure.  let me fire it up.
[19:34] <abentley> henninge, mumble?
[19:34] <deryck> henninge, can you join abentley and I?
[19:35] <henninge> deryck: 2 minutes
[19:35] <deryck> henninge, cool
[19:42] <thumper> deryck: hi
[19:42] <thumper> deryck: how would I know if all the of the tests for lazr-js worked?
[19:43] <deryck> thumper, install a jre and run ./bin/test
[19:43] <leonardr> gary, gentle ping
[19:43] <thumper> deryck: well, bin/test did run tests
[19:43] <thumper> deryck: I have a jre from libre office
[19:43] <deryck> thumper, and did it report x passed, x failed, etc.?
[19:43]  * thumper is running them again
[19:44] <thumper> deryck: one of the problems is that it left a firefox window open
[19:44] <thumper> deryck: it didn't look finished, even though it reported success
[19:44] <thumper> Total: 221 tests, 0 failures, 0 errors in 16.997 seconds.
[19:44] <thumper> deryck: is that the right number?
[19:44] <deryck> thumper, yeah, it doesn't close the browser
[19:44] <deryck> yes
[19:44] <thumper> deryck: that kinda sucks
[19:45] <deryck> what sucks?
[19:45] <sinzui> jcsackett: I have an call at 3:00. We can talk later today or tomorrow
[19:46] <thumper> deryck: that it doesn't close the browser window
[19:47] <jcsackett> sinzui: tomorrow morning sound good?
[19:48] <deryck> thumper, why is that a bad thing?  for having them run automatically you mean?
[19:48] <thumper> deryck: the open window left me wondering if it was done, broken, or what
[19:49] <thumper> deryck: it doesn't seem to be documented that it leaves it open
[19:49] <deryck> thumper, well it's not documented at all, if we're honest ;)
[19:49] <deryck> it's magic, luck, and/or smarts that allow you to even get it running.
[19:50] <thumper> heh
[20:02] <abentley> henninge, deryck: http://packages.ubuntu.com/dapper/bazaar
[20:21] <lifeless> hi
[20:22] <lifeless> anyone have pqm swallow a merge recently?
[20:22] <lifeless> if so, the problem should be fixed now on praseodymium (thanks lamont); but we need to throw something that was broken at it again to see it fixed
[20:27] <abentley> sinzui, is it possible for two source packages with the same name in different Ubuntu series to contain entirely different software?
[20:38] <sinzui> abentley: I am not sure I can answer your question. Since a SPN is being linked to a distrroseries productseries pairs, and user can make mistakes...Lp thinks they can be different. BUT distros use SPN to mean a package that has only only evolving line of software.
[20:40] <abentley> sinzui, I remember with bazaar, we renamed it to "baz" so that we could later provide a "bazaar" that would be bzr.
[20:41] <sinzui> oh, abentley, distros often create parallel versions of packages, like glade (version 2) and glade3, when 2 is unsupported, glade3 becomes a migration package to glade (latest version)
[20:41] <sinzui> These are considered to be the same line of development though
[20:41] <abentley> sinzui, right.
[20:42] <abentley> sinzui, we're currently sharing translations among sourcepackages with the same name and distribution.  I'm trying to assess whether that's a bad thing.
[20:42] <lifeless> abentley: yes, it is possible.
[20:43] <lifeless> abentley: I'm not sure it worries translations though, as long as the pot modelling still generates the right set of strings to be translated
[20:43] <abentley> lifeless, it worries hennninge.
[20:44] <lifeless> abentley: then it may be an issue ;)
[20:44] <lifeless> abentley: I don't have any particular view, FWIW.
[20:45] <sinzui> abentley: this will be a problem when users do something stupid like claim that app provides firefox because it *depends on* firefox
[20:46] <sinzui> abentley: but the problem is not about translations or Ubuntu. it is about users providing bad data
[20:46] <abentley> sinzui, heh, okay.
[20:49] <abentley> sinzui, well, it points to the importance of being able to unshare translations when packaging links go away...
[20:49] <sinzui> abentley: I looked at packaging link differences between natty and maverick a few months ago. I saw about 20 links that were wrong so I deleted them
[20:55] <mwhudson> yay for the haproxy-for-twisted-services branch
[21:01]  * thumper fires up mumble
[21:01] <lifeless> flacoste: hai
[21:01] <flacoste> lifeless: hi
[21:01] <lifeless> is now when you meant?
[21:01] <flacoste> lifeless: i skype you in 5 minutes?
[21:01] <lifeless> sounds great
[21:01] <flacoste> ttys
[21:03] <StevenK> RARGH, Windmill!
[21:03] <lifeless> StevenK: wgrant: oh hai .au
[21:03] <StevenK> lifeless: O hai. Not sure about wgrant, but I have a call
[21:04] <thumper> StevenK: mumble?
[21:04] <lifeless> StevenK: wgrant: at the team lead meeting we talked hudson; the idea of less issues than buildbot has is very intruiging, but as in the short term we'd be bucking the default for losa involvement.
[21:04] <StevenK> thumper: Sure, one sec
[21:04] <thumper> leonardr: mumble?
[21:04] <leonardr> thumper:on my way
[21:04] <lifeless> StevenK: wgrant: having a report/graph/whathaveyou - actual empirical data - about when bb fails and hudson doesn't (and vice verca) would make the discussion a lot more straight forward.
[21:05] <StevenK> Why does this feel like pushing uphill?
[21:06] <lifeless> StevenK: current status is this: if hudson was packaged - no brainer; if its not packaged we either need losas to operate the linode, or we need to run the war/external deb in the datacentre
[21:07] <lifeless> StevenK: we (the lp team) can push for one of those two alternatives, and will, but given the scare resources... it needs a little more incentive for flacoste to get out and push ;)
[21:07] <StevenK> lifeless: In the shortish term, the war sounds fine
[21:07] <lifeless> StevenK: right, but its /not the default/ for the losas to run an externally built binary.
[21:08] <StevenK> I'm well aware
[21:08] <StevenK> You know exactly how much work it is to package it
[21:08] <lifeless> StevenK: which is why francis wants a bit more backing about the benefits
[21:10] <StevenK> lifeless: 1) No more slave lost crap. 2) Cancelling builds doesn't mean that the LOSAs spend an hour fixing it. 3) Windmill tests can be run seperately under a windmill plugin for Hudson if we wish. 4) subunit support?
[21:10] <StevenK> lifeless: I wonder why Francis didn't bring any of this up at the epic? :-(
[21:11] <lifeless> StevenK: I'm otp now too sorry; will talk more in a bit
[21:11] <leonardr> benji, is there any chance you can help me figure out the problem with the lazr.restfulclient build environment?
[21:17] <wgrant> Grar.
[21:21] <StevenK> http://pastebin.ubuntu.com/561626/ :-(
[21:28] <lifeless> flacoste: btw bug 712108
[21:28] <_mup_> Bug #712108: shared ssl session cache support not possible out of the box <apache2 (Ubuntu):New> < https://launchpad.net/bugs/712108 >
[21:36] <wgrant> Why did buildbot poller request two identical stable -> db-devel merges four minutes apart? :/
[21:36] <StevenK> Awesome
[21:37] <StevenK> Ugh, apparently it's going to be 37 today
[21:59] <huwshimi> StevenK: You have aircon right?
[21:59] <StevenK> huwshimi: Nope
[22:00] <huwshimi> StevenK: Ouch
[22:08] <StevenK> lifeless: Still on the phone?
[22:08] <lifeless> yep
[22:09] <huwshimi> Anyone able to review  a UI change? https://code.launchpad.net/~huwshimi/launchpad/tag-list-wrapping-708436/+merge/48393
[22:12] <sinzui> huwshimi: I understand the change you made, but I have a few questions
[22:13] <huwshimi> sinzui: Sure
[22:13] <sinzui> huwshimi: style.css is deprecated. Do we want to move .tags-container to style-3.0? Can this be generalised? I do not see anything tag specific in it
[22:14] <sinzui> Is there a better name, does it overlap with other styles
[22:15] <sinzui> I wonder if the text-align instruction is required
[22:15] <huwshimi> sinzui: ok, let me have a look.
[22:19] <sinzui> huwshimi: I think div.left could be just .left and it will do the right thing
[22:19] <sinzui> huwshimi: acutally. I think changing the page to use .left and deleting the class also works
[22:19] <huwshimi> sinzui: Actually I wonder if we need any of that.
[22:20] <sinzui> what is it floating from? Is that your question?
[22:21] <huwshimi> sinzui: yeah the float doesn't seem to be doing anything... well that I can tell initially
[22:21] <sinzui> huwshimi: I wonder if it was once in a two column layout. I think we are looking at an obsolete rule
[22:22] <huwshimi> sinzui: yeah that might make sense of why it was set to 45% width as well
[22:24] <sinzui> I see a test looks for it but it is not important. The template does two odd things with it to make a composite class
[22:25] <wgrant> StevenK: Can I steal DF for a few hours to QA r12300?
[22:25] <lifeless> poolie: hi
[22:25] <lifeless> poolie: got a few minutes?
[22:26] <huwshimi> sinzui: So would you be happy for the fix to be removing the tags-container rules from style.css?
[22:27] <sinzui> I would be happy with that
[22:28] <huwshimi> sinzui: Thanks I will commit the new changes.
[22:29] <lifeless> StevenK: hi, I'm off the phone for a bit; would you like a brief voice call about hudson? wgrant too, if you're interested?
[22:31] <wgrant> StevenK: I'm not sure I have much to add.
[22:31] <wgrant> Er, lifeless too ^^
[22:31] <sinzui> wgrant: mumble
[22:32] <poolie> lifeless, hi, yes, but stephane's on the phone atm
[22:32] <lifeless> sinzui: thanks for spotting that dupe
[22:32] <lifeless> poolie: skype?
[22:32] <lifeless> poolie: or same room ?
[22:38] <sinzui> huwshimi: https://bugs.launchpad.net/launchpad-help-moin-theme/+bug/488241
[22:43] <wgrant> Er
[22:43] <wgrant> launchpad@mawson:/srv/launchpad.net/codelines/current$ ./scripts/publish-distro.py -A -s natty-proposed
[22:43] <wgrant> 2011-02-02 22:39:45 INFO    Processing ubuntu Primary Archive for Ubuntu
[22:43] <wgrant> 2011-02-02 22:41:43 WARNING a-f: E: Command line option --arch is not understood
[22:44] <wgrant> Oh, it's a local change.
[22:46] <huwshimi> sinzui: in that template (for the bug tags) what does this line do?  tal:attributes="class python: ('tags-container ' +...
[22:48] <sinzui> huwshimi: it is concatenating classes to "tags-container '
[22:48] <wgrant> And putting it in the class attribute of the tag.
[22:49] <huwshimi> Ah ok right
[22:50] <sinzui> huwshimi: I need to take my daughter to a class. I will be back in 30 minutes
[22:50] <huwshimi> sinzui: Sure, thanks for your help
[23:38] <huwshimi> wgrant: What were you saying the other day about how feature flags are implemented now?
[23:40] <wgrant> huwshimi: There's documentation and admin UI for them, so you should define them in lib/lp/services/features/flags.py. There are also a few different ways of testing them, so you might have to look around.
[23:41] <StevenK> lifeless: I'm free now if you are.
[23:44] <huwshimi> wgrant: Thanks, taking a look