lifelessspm: hi00:05
lifelessspm: I'm sure you have a bunch of firefighting to do [ubunet cron, *cough*]00:06
lifelessspm: but I wonder, as its 1am here, if you can do me a solid first00:06
spmlifeless: yo; sup?00:06
lifelessspm: which is, to deploy lp:~lifeless/launchpad/malone so I can see if it does make dup checking faster00:06
lifelesson staging00:06
spmoh sure, app server I assume?00:06
spmyoikes that's a big patch. it seemed to have a merge fail; but it scrolled out of my buffer. trying again to a file00:10
lifelessspm: it should be tiny00:10
lifelessspm: https://code.edge.launchpad.net/~lifeless/launchpad/malone/+merge/30904,00:10
spmbzr merge --preview  lp:~lifeless/launchpad/malone ?00:10
spmjust take the latest version then of it?00:11
lifelessspm: https://code.edge.launchpad.net/~lifeless/launchpad/malone/+merge/30904/+preview-diff/+files/preview.diff perhaps00:11
spmthat works00:11
lifelessspm: its probably other devel stuff naffing staging up, or something00:11
spmdamn. 4/4 hunks failed00:12
lifelesswhich ones00:12
lifelessoh, all00:12
spm1am, you said earlier. noted. :-)00:12
lifelesson which files00:12
lifelessthere is much more than 4 hunks in there00:12
spmyeah - that was just the most obvious00:13
lifelessspm: can you revert; then pastebin bzr missing lp:~lifeless/launchpad/malone ?00:13
spmpreview - i always preview/dry-run first00:14
spmsure sure00:14
spmlifeless: http://paste.ubuntu.com/469078/00:15
lifeless11189 should be included00:16
lifelesscan you grep slow_ lib/canonical/database/nl_search.py ?00:16
spm0 results found00:16
lifelessmerge -c 11199 lp:~lifeless/launchpad/malone ;00:17
lifelessmerge --force -c -1 lp:~lifeless/launchpad/malone00:18
lifelessshould behave better00:18
lifelessits in place ?00:21
spmis that bzr, svn or git merge?00:21
spmnot yet00:21
spm1am. trolling is too easy. sigh.00:21
spm1st went in easy00:22
lifelessvidi vici veni00:22
spmon a preview; live doing now...00:22
spmCivil Engingeering Students Association (@ Qld Uni) CESA: We Came. We Swore. We Concreted.00:23
spmcoolio, both applied; restarting00:24
spmlifeless: restarted with new shiny ponies00:25
lifelesshmm, you sure ?00:26
spmyup :-)00:27
spmthis is the app server right? not code*?00:28
spmstart time: Mon Jul 26 00:24:52 2010 (BST natch)00:28
lifelesswgrant: try this page https://bugs.staging.launchpad.net/ubuntu/+filebug00:30
lifelesswith e.g. eclipse get unmet dependency error00:30
lifelessits hitting disk a lot still00:31
lifelessbut once off disk its hell snappy for me00:31
lifelessmwhudson: ^00:32
lifelessspm: what do you think00:32
wgrantHm, not too bad.00:33
spmwhimper. can't login to staging I think...00:33
wgrantBut the results... I don't know.00:33
spmNo I lie. I'm in. wooo!00:33
lifelesswgrant: they are missing the prefilter step that was doing millions of comparisons to filter out terms; will reinstate that in a bit00:33
lifelesswgrant: other than that its ranked precisely the same way00:34
spmseemed snappy to me00:34
lifelessbombs away, I say00:34
wgrantlifeless: Isn't it returning a subset of the original results, though?00:34
lifelessbut ranking is strictly additive given the same terms as the rank function00:35
lifelessso 3 terms >> 1 term anyhow00:36
lifelessand we're not [yet] using heat or anything00:36
wgrantI guess you try the one-missing query, and then jump to two-missing, three-missing etc. queries if there aren't enough results.00:38
wgrants/you/you could/00:38
wgrantspm: Some more corrupt builds appear to have sprung up :(00:52
wgrantIf you have a moment, could you run 'SELECT buildqueue.id, builder, lastscore, buildqueue.job, job_type, processor, build FROM buildqueue JOIN job ON job.id = buildqueue.job JOIN buildpackagejob ON buildpackagejob.job = job.id WHERE buildqueue.virtualized = false AND buildqueue.processor = 1 AND job.status = 0' for me?00:52
wgrantThere are somehow 13 corrupt builds in the i386 non-virt queue, for a total of 40 seconds of buildd time, and they don't appear to actually be in the queue.00:53
spm*blink*. 0 rows?00:54
wgrantSELECT buildqueue.id, builder, lastscore, buildqueue.job, job_type, processor FROM buildqueue WHERE buildqueue.virtualized = false AND buildqueue.processor = 1;00:55
wgrantThey must be even more broken than the last lot.00:55
spmwe don't break by halves round here00:56
spm   id    | builder | lastscore |   job   | job_type | processor00:56
spm 3233211 |         |     12510 | 1941857 |        1 |         100:56
spm(1 row)00:56
spmwgrant: ^^ that last score seems... curious00:56
wgrantJust means it's in a private archive.00:56
spmis that like the 'score' we'd override a build? ahh kk.00:56
wgrantSo there's something odd going on here, and that's not it.00:56
=== Ursinha-afk is now known as Ursinha
wgrant(https://edge.launchpad.net/builders -- see the i386 non-virt build queue. that query should have returned everything in it. :()00:58
wgrantHmm. What if you say 'virtualised IS NULL' instead of 'virtualized = false'?00:59
spmnon-virt the offical builders yes/no?00:59
wgrantOfficial, yes.00:59
spmnon-virt *is* the offical builders yes/no? yes, ta00:59
spm13 rows :-)01:00
spmjobtype=4, processor=1, lastscore=100001:00
spmso curious that the = false gets something at all.01:01
spmrecognising that sql has 3 binary states - on, off, null :-/01:01
wgrantIt is somewhat odd, since it's not appearing in the queue, and is not building. But that's not the main issue.01:02
wgrantThanks for your assistance.01:02
wgrantOdd that they're not being dispatched. But they're translations jobs, so who knows what evil they are up to.01:04
spmI know people who would know what evil they're up to.....01:06
wgrantThere are another 18 properly virtual jobs floating around inappropriately, but it's just about impossible to track them down until the queue is empty.01:10
wgrantFiled bug #609904, but that doesn't explain why the builds exist in the first place.01:10
_mup_Bug #609904: BuilderSet.getBuildQueueSizes needs to consider virtualized=NULL as false <Soyuz:New> <https://launchpad.net/bugs/609904>01:10
wgrantjtv: Hi. There are 13 pending translation template build farm jobs, and they're not being dispatched. Do you know why that would be?01:12
jtvwgrant: hi.  No idea...  it's only TTBJs?01:27
wgrantjtv: There are some other non-dispatching builds around. But they're corrupt -- I'm not sure if the TTBJs are.01:30
jtvwgrant: corrupt in what way?01:31
wgrantjtv: The status of the PackageBuild is wrong.01:31
wgrantBut you only have a single status, so that's not the case.01:32
jtvwgrant: it's not one of the recent changes and us not having a Build?01:32
jtvMaybe the bad build status is a result of the same thing that's causing these jobs not to be dispatched?01:32
wgrantjtv: Unlikely. I saw some TTBJs building not even 24 hours ago, so it's not a general problem.01:32
wgrantI wonder if the branchjob is missing or something.01:32
jtvA branchjob and a job are all we have, no?01:33
wgrantAnd a buildqueue.01:33
jtvAh right01:33
jtvthat too01:33
wgrantThe buildqueue and job are present.01:33
wgrantNot sure about the branchjob.01:33
wgrantI don't trust the recent branch deletion changes, so I'll blame them for now :)01:33
jtvDeleting a branch might cause this...01:33
jtvThe recent branch changes would cause both the BJ and the BQ to be cleaned up.01:34
jtvHow old are these broken jobs?01:34
jtvThe old behaviour (still running on production afaik) would cause an incomplete cleanup.01:36
wgrantSELECT buildqueue.id, builder, lastscore, buildqueue.job, buildqueue.job_type, processor, job.date_created, job.status, branch, branchjob.job_type, json_data FROM buildqueue JOIN job ON job.id = buildqueue.job LEFT JOIN branchjob ON branchjob.job = job.id WHERE buildqueue.virtualized IS NULL AND buildqueue.processor = 1;01:36
wgrantspm: ^^01:36
jtvwgrant: no rows01:37
spmhrm that json data for those is interesting; all over the place.01:37
wgrantThose two statements conflict....01:37
jtvI ran mine on staging.01:37
wgrantstaging has buildqueue cleared.01:38
wgrantBecause it has a buildfarm now.01:38
spmjtv: https://pastebin.canonical.com/35029/ I think I can post that publicly, but can you confirm or deny?01:38
wgrantThere are no private TTBJs yet, so it /should/ be safe... but...01:38
spmyeah, juts wanted to be doubly sure01:39
spmthe sus ones are all public01:39
spmwgrant: http://paste.ubuntu.com/469098/01:40
wgrantSo they all have BranchJobs, are not deleted, and all very fresh.01:41
wgrantI don't know what's going on, unless it's trying to dispatch them but failing.01:43
jtvAnd maybe re-dispatching them?01:45
jtvwgrant, spm: it's suspicious that these are all so recent...  might it be a dispatch priority issue?01:51
spmjtv: recent as in the last 24ish hours?01:52
jtvspm: yes01:52
jtvDid we CP anything that could have done this?01:53
spmjtv: and btw, good morning! you're up early? :-)01:53
jtvspm: amsterdam01:53
spm'up early' still rings true :-)01:53
jtvup late.  :)01:53
jtvmet up with team members & an ex team member today... a good portion of the Prague attendance went to Holland next it seems.01:54
spmjtv: no CP's to the build side since the 9th, so unlikely?01:54
spmahh cool!01:54
jtvSome for holidays, others for the GNU meeting, yet more for Guadec.01:55
jtvNo CPs...  then either it's operational or it's something weird on edge.01:56
jtvThe branches I checked out weren't deleted, so I doubt it's related to branch deletion.01:56
wgrantjtv: Yeah, it's a bit odd. I guess someone needs to check buildd-manager logs at some point :/01:58
spmedge? edge gets updated regularly - so CP?01:58
spmtry again; so CP isn't as unlikely an option- it's just the normal state of affairs.01:59
wgrantHmm. I guess it's possible it's priority.01:59
jtvspm: yes, it's just that edge is less likely to have an effect on the build farm01:59
wgrantBut that would imply that the queue hasn't been empty for 24 hours.01:59
jtv...and yet we have builders sitting idle.01:59
wgrantI guess I'll just hope they disappear over the day.02:00
jtvMaybe something's bottlenecking on uploads?02:02
jtvwgrant: is the builder marked as idle while its uploads are being processed?02:04
wgrantjtv: No.02:04
jtvit'd be nice to know what dispatch queries are going out right now...02:04
wgrantIt's normal at the moment for lots of builders to be idle, because buildd-manager sucks.02:05
wgrantbut... buildd-manager is far worse than normal.02:05
wgrantIt's redispatching the same set over and over.02:05
wgrantEvery minute or so.02:05
wgrantlamont alluded to this yesterday, saying there was a rogue build causing it to abort most cycles.02:05
wgrantI'll talk to Julian tonight, I suppose.02:06
wgrant(if you click on a few of the current virtual builds, you'll see they started <30s ago.02:06
wgrantThen if you refresh in another 30 seconds, they'll still be <30s ago.02:06
wgrantAnyway, uni.02:06
wgrantProbably not much we can do now.02:06
jtvIf the builds keep getting re-dispatched, that's a familiar symptom of something...02:10
jtv...slaves breaking protocol?02:10
jtvas you say, uni.02:10
rockstarbuild farm busy02:10
jtvrockstar: would a busy build farm do that?  That'd be a pretty major and obvious bug.02:12
jtv(IIRC a job gets marked as in-progress _and committed_ before actual processing starts)02:12
rockstarjtv, well, that was supposed to go to another channel, but yes, it seems the build farm is busy right now.02:13
jtvrockstar: from what wgrant has been finding out, it appears that some jobs are being eternally re-dispatched02:13
rockstarjtv, oh wait, you thought I was following your context.02:13
jtvYes, I'm weird that way02:13
rockstarjtv, no, I haven't been reading the backchat.02:14
thumperrockstar: hey02:14
thumperrockstar: you home again?02:14
thumperrockstar: and back to normal?02:14
thumperjtv... weird... surely not02:14
rockstarthumper, well, "normal" is objective, but yeah, I'm home.02:15
thumperrockstar: objective or subjective?02:15
thumperpedantry rules02:15
jtvthumper: he means that he's normally objective.02:16
spmheya rockstar02:23
=== Ursinha is now known as Ursinha-afk
wgrantbuildd-manager is still screwed :(04:30
wgrantspm: No obvious errors in the log?04:30
spmorsum. looking.04:30
wgrantIt should try to dispatch lots of builds, then encounter some error. Every <1min, probably.04:31
spmexceptions.AssertionError: amd64 build of eclipse 3.4.1-0ubuntu2 in ubuntu karmic RELEASE (1213758) can not be built for pocket RELEASE: invalid pocket due to the series status of karmic. ??04:32
spmnot every minute, but surely not far off.04:33
wgrantThat would do it.04:33
wgrantThat's... interesting.04:34
spmit's a rather impressive stack trace too04:34
spmbeen going for ages too04:35
wgrantBug #57516504:35
_mup_Bug #575165: Buildd-manager erroneously checks COPY archives for release pocket upload permissions when dispatching <buildd-manager> <soyuz-upload> <trivial> <Soyuz:Triaged by julian-edwards> <https://launchpad.net/bugs/575165>04:35
wgrantBut that archive is disabled.04:36
wgrantSo the build shouldn't be active :/04:36
wgrantI guess we could just manually suspend it.04:42
wgrantWhy it is not already suspended I do not know.04:42
wgrantthumper: Is the porting of SPRBs from BuildBase to PackageBuild going to happen this cycle?04:48
thumperwgrant: I believe so04:48
thumperwgrant: abentley has it mostly done I think04:48
thumperhe was stuck though on where the builds get set to fully built04:48
thumperat least that is where it was on my Friday04:49
thumperhe may have solved that now04:49
wgrantYeah, there's the wonderfully-named 'findBuild' method which actually sets it to fully built...04:49
thumperthat does not sound like a mutating function04:51
thumperfix plz?04:51
wgrantHeh. Maybe once the build farm code has settled down and we've removed the four excess tables and several additional classes...04:51
mwhudsonwow, recipe builds really don't have much priority do they?05:04
wgrantWhat is their priority?05:06
wgrantI forget.05:06
wgrantAh, 900.05:06
wgrantYeah, normal PPA builds are 2510 or so.05:06
wgrantI need to convince everyone that build scores are stupid and need to die.05:07
mwhudsoni'm just experiencing the "been expected to start in 1 hour for several hours" thing05:07
wgrantWell, that's not due to the score.05:08
wgrantThat's due to everything being fucked.05:08
mwhudsoni see05:08
wgrantThe ETA takes the score into account.05:08
thumperwgrant: you have a +1 from me to kill scores05:17
thumperbut I don't hold much weight there05:17
thumperwhat we need is a way to prioritise some builds05:17
thumperand scores are an approximation for that05:17
spmif team==losa then do-losa-builds-first elseif team==ubuntu-security then do security-builds else hahahaha fi ?05:19
thumperspm: something like that05:21
wgrantthumper: A pretty ineffective approximation.05:21
thumpermwhudson: I'm deleting most of doc/branch-merge-proposals.txt05:21
thumpermwhudson: I'm rewriting it to not use sample data05:21
thumpermwhudson: and in my rewrite I realised it is a big pile of turd05:21
wgrantThere seems to be a bit of that going around lately.05:21
thumpersample data should be avoided in all tests05:22
thumperwhereever possible05:22
thumperwhich is almost everywhere05:22
mwhudsonthumper: hooray?05:24
thumpermwhudson: I'm actually writing documentation05:24
thumperthe level of executability in the doc is very small05:24
thumperI'm trying to focus on the documentation being meaningful05:25
spmthumper: !?!? bit excessive isn't it? *meaningful*!?!?! srsly?05:36
thumperwhat was I thinking05:36
* thumper replaces the doctest with "Read the freaking code bitch"05:37
spmdamn. that's almost too easy to take out of context. I shall pass. this time.05:38
thumperspm: heh05:38
thumperlifeless: hi, back in NZ?05:48
thumperlifeless: EU still??05:49
lifelessI fly out from here in 12 hours05:49
lifelessGNU Hackers Meeting was on05:49
thumperhow'd that go?05:49
lifelesspretty good05:52
lifelessI need to write it up but <so tired>05:52
lifelessthumper: did you try the staging search perf ?05:52
thumperbut I read your writeup05:52
thumperand commented on the merge proposal05:52
lifelessits because of conflation05:53
lifelessthumper: https://bugs.staging.launchpad.net/ubuntu/+filebug05:53
lifelesssadly it failed an obscure teset05:53
lifelessso I need to update some more tests with the same 'it sucks, sorry, fast-first' dialogue.05:53
=== almaisan-away is now known as al-maisan
* thumper nods05:56
lifelessthumper: I'm interested in perf for you, on that url.05:56
lifeless'folk in nz are like folk in china'05:57
thumperwhat do you want me to search on?05:57
lifelesswhatever you like05:57
thumperlifeless: "bzr transfers too much data" gave me a response in about 5 seconds, but none of them really relevant05:58
lifelessthumper: item 0 for me is bug 8230505:59
_mup_Bug #82305: push and pull on bound branches use too much network <Bazaar:Confirmed> <bzr (Ubuntu):Confirmed> <https://launchpad.net/bugs/82305>05:59
lifelesswhich is pretty relevant05:59
thumperwell... yes05:59
lifelessremember that this is in-ubuntu rather than in-bzr context - its not searching the bzr bug db05:59
thumperI suppose05:59
lifelesssame search06:00
lifelessdoesn't return any bzr bugs06:00
* thumper has to go collect people06:00
lifelessand well production simply won't answer06:04
adeuringgood morning08:15
lifelessstub: hi08:23
stubHappy Asaha Bucha Day.08:28
lifelessoh nice08:29
lifelessyou're on leave for it ?08:29
stubYer. Just ticking off a few things from my todo list first though.08:30
lifelesswell I'm travelling tonight08:30
lifelessI've done an audit of the timeout bugs in malone08:30
lifelessand there are a few which would really benefit from you casting an eye over some query<->index stuff08:31
lifelessif you had time tomorrow to just have an eyeball - just the malone stuff tagged 'timeout'08:31
lifelesstheres things like a union plan which takes 11 minutes to run !08:32
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
* flacoste is away: Gone away for now09:58
* thumper takes a look at the merge conflict10:09
jmlthumper, thanks10:11
jmlthumper, I was about to, since I last touched branch.txt10:12
thumperjml: it seems to be that we just need to delete that block again10:12
thumpersound right?10:12
jmlthumper, haven't got that far yet10:12
jmlthumper, still pulling db-devel :)10:12
thumperjml: but in the branch that you merged into devel you just deleted chunks of branch.txt?10:12
jmlthumper, pretty much.10:13
jml(note that it doesn't use branch sampledata any more)10:13
jmlthumper, yeah, delete it.10:13
jmlthumper, all of that has been moved to unit tests10:14
thumperjml: the difference on db-devel is that someone reformatted the lines to the right length10:14
* thumper deletes10:15
jmlthumper, thanks.10:18
jmlthumper, btw, I'm still progressively working through the code tests getting rid of their dependency on branch sampledata10:18
thumperjml: you should see my merge proposal that is up10:18
jmlthumper, I did!10:18
thumperI tried to focus on useful documentation10:18
thumperrather than a test10:19
jmlthumper, cool.10:19
jmlthumper, I'll review that in a moment.10:19
* thumper leaves the office to drink a cuppa10:19
lifelessadeuring: what does having sec proxies returned from the lpfactory do for us ?10:20
adeuringlifeless: I think the tests should work with the same objects as we use in real code.10:21
adeuringand we should be able to detect for example permission problems10:21
lifelessadeuring: thanks10:21
thumperjml: yes it is still running, just not under a special layer10:24
jmlthumper, ahh, thanks.10:24
thumpergah, my email client is getting my emails :(10:24
bigjoolsjml: Hope you're feeling better this week because I added you to the MP for the buildd-manager branch last week, it might make you feel sick again.10:33
jmlbigjools, thanks :)10:35
bigjoolsjml: I do feel bad and apologise profusely.  However, not *too* bad since I had to suffer when changing the damn thing :)10:35
bigjoolssome of the tests are bloody awful, so I hope you have suggestions on how to make them look better.10:36
lifelessbigjools: can you describe the awfulness ?10:46
lifelessbigjools: like - overly coupled, too sensitive, not sensitive enough, visually long, hidden setup, ?10:47
bigjoolslifeless: hideous setup10:47
bigjoolssee lib/lp/buildmaster/tests/test_manager.py, look for TestSlaveScanner.setUp()10:47
bigjoolsit stubs out half the code its testing10:48
bigjoolsand then selectively re-enables it in some tests!10:48
bigjoolsand it probably falls foul of all those other things you listed10:48
lifelessso, if different tests need different amounts stubbed10:50
lifelessI think I'd tackle that by:10:50
lifelessmoving the setup to a helper function10:50
lifelessdelete the setUp() on the test class10:51
lifelessat the top of each test call the helper with parameters appropriate to the test being run10:51
bigjoolsthe tests need re-writing, they're rubbish10:51
lifelessit will still be hideous, but less so.10:51
lifelessand it will be a cheap change to make10:51
bigjoolssort of - I'd need to work out exactly what each test is depending on10:51
bigjoolsI would not be surprised if it's masking bugs10:52
wgrantbigjools: Evening.11:08
wgrantAre you aware of the rogue karmic rebuild which is killing everything?11:08
wgrant(or was over the weekend; not sure if it's been fixed in the last few hours)11:09
bigjoolswgrant: sigh, thought it had disappeared11:14
bigjoolshow the *hell* is it even there11:14
wgrantbigjools: Yeah, it should surely have been suspended...11:18
bigjoolsI wonder if someone pocket-copied it11:21
wgrantbigjools: Within a copy archive?11:21
lifeless-> stuff11:21
bigjoolshow do you know it's a copy archive build?11:21
wgrantI thought it was build 121375811:22
bigjoolshow do you know that?11:22
bigjoolsI can see it in the logs, but...you?11:22
wgrantspm checked the logs.11:22
wgrantI'm not that good, sadly.11:22
bigjoolsthis is a test archive from 2009090911:23
bigjoolsI know the bug for this11:23
bigjoolsbut the archive is disabled...11:23
wgrantBug #57516511:24
_mup_Bug #575165: Buildd-manager erroneously checks COPY archives for release pocket upload permissions when dispatching <buildd-manager> <soyuz-upload> <trivial> <Soyuz:Triaged by julian-edwards> <https://launchpad.net/bugs/575165>11:24
wgrantBut was it disabled before build suspension was implemented?11:24
bigjoolswhy has it appeared now though?11:24
wgrantI don't quite know.11:24
wgrantMaybe it depwaited.11:24
wgrantSo wasn't suspended.11:24
wgrantAnd then somehow got retried.11:24
bigjoolsok, I'm going to re-purge disabled copy archive builds11:27
bigjoolsFWIW http://pastebin.ubuntu.com/469264/11:27
wgrant'Purge' meaning suspend, or really delete?11:27
wgrantbigjools: Any progress with PPA log parsing?11:31
bigjoolsno - but good reminder :)11:31
wgrantHeh. That query looks good, anyway.11:32
bigjoolsthat query has been used too many times already :/11:32
wgrantbigjools: How I look forward to the great purge next month...11:35
bigjoolswgrant: que?11:36
wgrantbigjools: Once SPRB and TTBJ are ported to the new BuildFarmJob infrastructure, we get to delete lots of classes and DB tables.11:36
wgrantAnd remove the opportunities for inconsistencies.11:36
wgrantbigjools: https://code.edge.launchpad.net/~wgrant/launchpad/ddeb-domination12:23
wgrantHow does that approach seem?12:24
bigjoolslooking ...12:24
bigjoolswgrant: will it look like a deb dominates a dedeb?12:26
bigjoolsddeb, even12:26
bigjoolswgrant: and will the ddeb publisher notice that a ddeb was superseded by a different publisher?12:28
bigjoolsBTW, a WIP MP would be useful to see a diff :)12:29
bigjoolswgrant: how is performance affected on the query changed in domination.py12:31
bigjools(these are all questions that you don't need to answer right now, I am just checking your approach)12:31
wgrantbigjools: Remember that BPPH.supersededby is a BinaryPackageBuild. For this sort of reason.12:35
wgrantHmm, fair point on that query. Not sure about that.12:35
wgrantAs for the publisher noticing the superseded stuff, it works fine apart from the bug I filed yesterday.12:35
wgrantAnd that's a restricted case that we can probably ignore, but I wanted to record.12:36
bigjoolswgrant: ok - I was going by one of your commit comments where you implied that ddebs live in the same archive - they don't.12:36
wgrantAh, right, yes. That's for the non-primary case, where they do live in the same archive.12:37
wgrantDo we know when Lucid is happening yet?12:43
=== mrevell is now known as mrevell-lunch
=== matsubara-afk is now known as matsubara
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
=== mrevell-lunch is now known as mrevell
=== al-maisan is now known as almaisan-away
rockstarbigjools, is the build farm overloaded right now?14:41
bigjoolsI can say yes without even looking :)14:44
wgrantIt seems to have just been hit with a wave of dh7 retries.14:44
wgrantBut that should clear soon.14:44
bigjoolsrockstar: https://edge.launchpad.net/builders <-- self service14:44
rockstarbigjools, I knew there was a URL, I just never remember what that URL is.  :)14:56
bigjoolsrockstar: unfortunately I don't have the same amnesia issue14:56
rockstarbigjools, yup.  That's why I asked you.  :)14:56
=== almaisan-away is now known as al-maisan
* flacoste is back.15:42
lifeless\o/ my librarian patch has landed15:53
lifelessmthaddon: I'm hopping on a plane now, but I'll try to get the configs branch up for you15:53
lifelessfast search will have to wait for me to get to NZ I think15:53
lifelessmthaddon: the appservers - please tell me they are not using a single oops dir, with the same oops prefix, across different processes15:54
mthaddonlifeless: I think you should be able to tell me that :) but I'm pretty sure they use different OOPS prefixes15:54
lifelessin which case its ok15:54
lifelessmthaddon: do you have enough data to move forward on rt 40480 ?15:55
lifelessmthaddon: tell me a bout librarian and librarian2 ?15:57
mthaddonlifeless: erm, so are you saying that X frontends doesn't expose us to bzr locking any more than 1 frontend?15:57
lifelessmthaddon: right15:57
mthaddonlifeless: I don't think we're blocked on you in that case (although testing this theory would be nice, and we'll certainly need to do this on staging first)15:58
lifelessmthaddon: right15:59
lifelessmthaddon: lp:~lifeless/lp-production-configs/librarian - don't merge till we do a deployment to the librarian of whats currently out on edge, cause the schema stuff is lock-step16:00
lifelessmthaddon: I only see a config for 1 librarian though - public and internal instances-of, but only one process for each role. Is that right ?16:00
mthaddonlifeless: you didn't see the librarian2 folder?16:01
lifelessI did16:01
lifelessthat appears to be the private librarian16:01
lifelessnot a redundant public librarian16:01
lifelessok, cool16:02
lifelessanyhow, I've put the change into both parts16:02
lifelessI must run and get security checked etc now.16:02
mthaddonsince it's not proposed for merging yet, we'll leave it til that happens16:02
lifelessplease do grab spiv/mwhudson/jml if the codehosting thing gets hairy - I know all of them have looked at the entire vertical stack16:03
* lifeless fades into the sunset 16:03
jmlsinzui, hi16:03
sinzuihi jml16:04
=== matsubara is now known as matsubara-lunch
jmlsinzui, want to mumble?16:05
* lifeless is in da queue16:17
leonardrthumper, are you around to talk about your web service question?16:33
leonardrotherwise i will send an email16:33
lifelessleonardr: its EEEEEARLY for him - I suggest a mail :)16:37
lifelessleonardr: 3:30am specifically.16:37
leonardrlifeless, sure, just checking16:37
rockstarabentley, we seem to be having some sort of issue with the scanner not setting branch merge proposals to "Merged"16:45
abentleyrockstar, okay, can you be more specific?16:46
rockstarabentley, no.  I'm trying to find more details now.16:47
abentleyrockstar, you don't have an example where this didn't happen or anything?16:47
rockstarabentley, actually, I can be a bit more specific.  The folks in #tarmac are complaining that Tarmac keeps trying to land things after its merged them already.16:48
abentleyrockstar, could it be a race condition?16:49
rockstarabentley, I'm not prepared to rule anything out until I see an example proposal.16:49
rockstarabentley, https://code.edge.launchpad.net/~mordred/swift/fix-pep8/+merge/3089416:50
rockstarmtaylor, :)16:50
mtaylorbeat you to it16:50
abentleymtaylor, that branch hasn't been fully merged.16:50
rockstarmtaylor, oh, I know what is.16:50
abentleymtaylor, see the "unmerged revisions" heading?16:51
rockstarmtaylor, you pushed new revisions AFTER it was approved, didn't you?16:51
mtaylorrockstar: yes. it does seem so16:51
rockstarmtaylor, yup, so the approved revision id isn't the tip of the branch.16:52
rockstarabentley, thanks for your help.16:52
abentleyrockstar, np.16:52
mtaylorrockstar: ok. but the merge proposal should still be marked as merged, no? the thing that was approved happened16:52
mtaylorI mean- something should certainly be in some state here16:52
abentleymtaylor, I don't know.  Certainly I didn't think so when I wrote it.16:53
abentleymtaylor, the fact that there are outstanding changes definitely seems like something we should represent.16:54
abentleymtaylor, because we wouldn't want those changes to get lost.16:55
mtayloryeah - it's in a weird limbo state right now ... it's still approved -so I can't really approve the new changes easily16:55
abentleymtaylor, commonly in LP code reviews, we'll say "approved, if you make these changes", and so a branch in this state isn't really merged for us.16:55
abentleymtaylor, we don't really consider what state the proposal is in when we mark it merged.  It could be rejected, approved, but when tip goes into target, we consider it merged.16:56
rockstarmtaylor, also, we don't want the proposal to disappear in cases where not all the revisions are merged.  That would lead the user to think something incorrect.16:57
* rockstar sees abentley has already said this16:58
mtayloryeah - I understand all of what you're both saying...16:58
rockstarmtaylor, it helps when we're saying the same thing.  :)16:58
abentleymtaylor, it's hard in the Launchpad workflow to get into this state, because our landing tool always lands the tip.16:58
mtaylorI'm just saying that the system does not currently lead me to think any action needs to be taken, or what action I should take16:58
rockstarabentley, with PQM you mean?16:58
abentleyrockstar, yes.16:58
rockstarmtaylor, yeah, that's a Tarmac bug more than a Launchpad bug.  I think Launchpad is acting as it should.16:59
abentleymtaylor, It seems to have gotten your attention, though.16:59
mtaylorabentley: only because of the failed tarmac job16:59
abentleymtaylor, you don't use +activereviews?16:59
mtaylorbut no, I don't think it's just a tarmac bug - because I think tarmac is doing the right thing here17:00
mtaylorI think just merging the tip rather than merging the approved revision is a terrible idea17:00
mtayloras there is no workflow support to say that the new revisions are actually good17:00
abentleymtaylor, you're welcome to your opinion, but I don't share it.  See above.17:00
mtaylorabentley: you don't think new revisions need code review?17:00
abentleymtaylor, not always.17:01
rockstarmtaylor, new revisions need code review, yes, but I think that's a user's responsibility.  Launchpad shouldn't have to know about everyone's different workflows.17:01
abentleymtaylor, we trust our contributors to not make gross changes.17:01
abentleymtaylor, and we would find it a pain to have to do another roundtrip for the trivial changes we sometimes request in a review.17:02
mtaylorok. that's all fine, we can differ in our opinion here - just tell me, in this state, how do I approve new revisions17:02
rockstarmtaylor, just unset Approved and reset it.17:02
rockstarmtaylor, we could probably do better in that regard though.17:02
mtaylor<troll>how about not setting the status to Approved until the changes have been made?</troll>17:02
mtaylorrockstar: ok. I'll just do that. seems clunky though17:03
rockstarmtaylor, in my case, that's what I do.  If I ask for changes, I'll vote "approve" but not set it to Approved.17:03
abentleymtaylor, "We would find it a pain to have to do another roundtrip for the trivial changes we sometimes request in a review".17:03
rockstarmtaylor, if you file a bug about the "clunkiness" of re-approved, I'm sure we can triage it.17:03
mtaylorrockstar: have I mentioned that we need merge queues17:04
rockstarmtaylor, yeah, I think I was the one that put that earworm in your head.  :)17:04
rockstarmtaylor, see #tarmac for a tarmac solution.17:05
mtaylorthe _real_ problem here of course being that we are encoding two different pieces of information with the same status - and abentley and I choose to overload that system in different ways17:05
abentleyrockstar, you wrote a song about merge queues?17:05
mtaylorzomg. I so want to hear rockstar's song about merge queues17:05
=== Ursinha is now known as Ursinha-lunch
rockstarabentley, earworms don't have to be songs.  :)17:05
rockstarAlthough I guess now I need to write a song about merge queues...  :)17:05
* rockstar buckles under peer pressure17:06
abentleyrockstar, http://www.wordspy.com/words/earworm.asp17:07
abentleyrockstar, send me your song about merge queues, and I will lay down some flute, cowbell, tambourine or vox-- your choice.17:09
mtaylorjml: see... we're writing songs about it now..17:09
rockstarabentley, all of the above, but always more cowbell.17:11
rockstarabentley, I regret to inform you that the build estimation code that you worked so hard on is being trampled on by builders being overwhelmed at the last second...  :)17:17
=== beuno is now known as beuno-lunch
=== matsubara-lunch is now known as matsubara
=== al-maisan is now known as almaisan-away
bdmurrayleonardr: how could I address robert's concerns in https://code.edge.launchpad.net/~brian-murray/launchpad/bug-320596/+merge/30690?17:57
leonardrbdmurray, checking18:02
leonardrbdmurray, ok, long story short, to maintain backwards compatibility you need to have two calls to @operation_parameters18:30
leonardrthis should work:18:30
leonardryou should define a list containing the parameters, then copy it and change only the parameter you want to change, so that you don't have two copies of that huge list18:31
leonardradd a doctest to the stories/webservice directory of malone, illustrating that in 1.0 the default value is True, but that in devel the default value is False18:32
leonardrdoes this make sense?18:33
leonardr(be sure to put @operation_for_version('devel') on top of all of your current annotations--it's the dividing line between 1.0 and devel18:33
bdmurraythe parameters for devel would be very search parameter?18:34
bdmurrayevery that is18:35
=== beuno-lunch is now known as beuno
leonardrbdmurray: yes, you would pass in slightly different lists for each @operation_parameters call18:43
bdmurrayleonardr: okay thanks18:54
=== Ursinha-lunch is now known as Ursinha
=== almaisan-away is now known as almaisan
gary_posterbac: hey.  didn't you have a "run the tests that failed on ec2" command?  If so, does it still work?  If so, what is it? :-)20:29
gary_posterah!  bin/retest looks promising...20:30
gary_posterexcept that the ec2 output doesn't have the kind of information we need, anymore, it seems :-/20:32
bacgary_poster: :(20:32
bacgary_poster: but you can use testr to do it20:32
gary_posterbac, ?20:32
bacgary_poster: read robert's email from last week20:32
gary_poster("oh," Gary thinks, "Robert's one email from last week!  Right!" :-) )20:33
gary_posterbac, AFAICT that only helps if you have run tests locally, not if you ran test on ec2 that you want to rerun now20:39
* gary_poster found the email20:39
benjithe person that develops a working knowledge management system that gathers data from email will make a mint20:39
bacgary_poster: i thought you could unzip the attachment that came in the failure message and pipe it into testr load, or something similar20:40
* gary_poster looks at docs again20:40
bacgary_poster: i admit i have not tried it personally20:41
bacgary_poster: perhaps as a non-expert you should write down what actually works and how to do it...assuming you are successful20:41
gary_posterbac, https://dev.launchpad.net/Testing has what has been written so far.  I see ``testr load < testrun`` in testr --help but the relationship between that and the ec2 email output is less than obvious.  I'll play around for a second, and, yes, write something down if it seems valuable20:43
gary_posterLOL, "testr load < ~/apidoc.log.gz" didn't seem useful :-)  Maybe I'm supposed to uncompress it...20:44
gary_posterFor those following along at home, uncompressing did in fact seem to allow testr to load the subunit file.  The resulting output was a bit concerning:  id: 0 tests: 8956 failures: 5 skips: 2320:52
gary_posteri.e., what about the skips?20:52
gary_posterThen there's the concern that Gavin raised on the list20:54
gary_posterabentley: hey.  If I get the output "id: 0 tests: 8956 failures: 5 skips: 23" after loading in a subunit ile to testr, what is the source of the "skipped" line?  How do I see what the skipped tests are?  How do I run them, if I need to?20:57
abentleygary_poster, I believe there are no skips in the Launchpad test suite.  testresources counts failure to tear down layers as skips.20:58
gary_posterabentley: ah, great, so, for the short term at least that means that the information about skipped stuff is ignorable?20:59
abentleygary_poster, yes.21:00
gary_postercool thanks21:00
mtaylorrockstar: here's a UI thought for you21:13
* rockstar listens21:13
mtaylorrockstar: I just had someone be confused as to why merge requests and bug reports are separate things21:13
rockstarmtaylor, yes, I've heard this joke before.21:14
mtaylorrockstar: so it just got my brain trying to wrap its head a) around the urge and b) around whether or not there is something useful in the request21:14
rockstarmtaylor, so, this is why we have branch links.21:15
mtaylorrockstar: the reference was that in JIRA, a patch is attached to a bug and then discussion ensues21:15
mtaylorI think the main thing here had to do with discussion around a thing21:15
rockstarmtaylor, I do know the landscape team was doing their code reviews on the bug report.21:15
rockstar(I think that is crazy)21:15
mtaylorme too... but I'm wondering if there isn't some way to express some sort of tighter coupling or some sort of information sharing that isn't something we think is on crack21:15
mtaylorrockstar: the specific initial comment was "It's just annoying that e.g. bug reports are separate from merge requests, and the blueprints don't have a good discussion platform built in... Just feels like I have to repeat everything two or three times to keep launchpad happy..."21:17
rockstarmtaylor, well, yeah, I've been thinking about ways to display more bug content in the merge proposal page, but I'm currently more focused on the branch page redesign currently.21:17
mtaylorrockstar: I believe I had a thought a while back about being able to pre-populate a merge request description from a blueprint,21:18
mtaylorrockstar: essentially thinking that all branches should either be related to a bug or a blueprint -but that in many cases something could be generated automatically in one directoin or another21:18
rockstarmtaylor, that would require people other than Drizzle, Ubuntu, and Wikkid (because thumper is a karma whore) use blueprints.21:19
* thumper likes karma21:19
mtaylorrockstar: well, once I fix them, I hope that they will21:20
thumperat least I don't game the system though21:20
thumpermtaylor: are you going to work on blueprints soon then?21:20
mtaylorthumper: yes21:20
rockstarmtaylor, my hat's off to you.21:20
thumpermtaylor: how soon?21:20
mtaylorrockstar: you can add openstack to the blueprint using list :)_21:20
mtaylorthumper: soon21:20
thumperreal soon now?21:21
rockstarmtaylor, I might have recruited someone to help you with that.21:21
mtaylorrockstar: excellent21:21
rockstarmtaylor, the downside is that he's 15.  :)21:21
thumpermtaylor: I'd happily have pre-impl calls about blueprints21:21
thumpermtaylor: and review changes21:21
thumpermtaylor: I'm sure sinzui would too21:21
mtaylorthumper: great. well, I _really_ need to write my list of things down21:22
thumperjelmer: could I get you to send me an email with the known good revisions of the bzr plugins?21:23
thumperjelmer: also specifically if they'll work with 2.1 and 2.2 at the same time21:23
jelmerthumper: what sort of timeframe do you have in mind for landing these?21:24
thumperjelmer: if they are simple, then we could just drop them in ASAP21:25
rockstarmtaylor, I know this awesome new site that allows your to write a todo list of things.  The call the items "bugs" and it really helps me do my work...  :)21:25
thumperjelmer: all we need to do is merge them into the launchpad branches, and update the config file21:25
thumperrockstar: but you can't order them :P21:25
mtaylorrockstar: hrm. ... relative cost of opening a bug in launchpad vs. writing a list in a file in vi...21:25
rockstarthumper, sure you can.  It's called "importance"21:25
* thumper coughs 21:26
thumperthat is pretty rough ordering21:26
mtaylorrockstar: have I mentioned that the bug opening cost in lp is still pretty high?21:26
rockstarmtaylor, blame lifeless.  That's his job.  :)21:26
mtaylorrockstar: oh, I will21:27
jelmerthumper: can I perhaps just pqm-submit to the various lp:~launchpad-pqm/ branches and then have you review the update to sourcedeps.conf ?21:28
james_was an alternative to workitems in blueprints, we were pondering last week using bugs21:34
james_wand providing an API client that allows you to just write a list of things and it will open all the bugs for you21:34
jelmerthumper: still there?21:42
thumperjelmer: yep21:43
jelmerthumper: Did you see my question earlier?21:44
thumperjelmer: sorry, rebooted due to updates21:44
thumperjelmer: yes, and yes21:44
jelmerthumper: ok, I'll that then - thanks21:44
* thumper searches for more coffee21:44
jelmerthumper: Any plans yet to have bzr-svn/bzr-git in the PPA and built as daily builds from lp:~launchpad-pqm/bzr-{git,svn}/devel rather than checkout out manually in sourcecode.conf ? :-)21:45
rockstarjelmer, that would be awesome, and I would like that.21:55
thumperjelmer: we need a way to control the plugins, and add them as we need them21:57
thumperjelmer: so as long as we can work out how to do that...21:57
thumperjelmer: should be fine21:57
=== almaisan is now known as almaisan-away
rockstarArgh, timeouts on staging make rockstar angry.22:03
rockstarYou wouldn't like me when I'm angry.22:03
jelmerthumper: what do you mean by add exactly? when to load them, when to update their version?22:05
thumperjelmer: we don't want them on all the time22:05
jelmerthumper, isn't that an issue now as well though?22:06
thumperjelmer: no22:06
james_wno bot?22:33
benjijames_w, you might like this: I added a quick search to my Firefox so I could type/paste "OOPS 1668ED4702" in the address bar and be taken to it22:34
james_wgood idea22:35
james_wcould someone confirm that https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1668ED4702 looks to be https://bugs.edge.launchpad.net/launchpad-code/+bug/518337 ?22:35
_mup_Bug #518337: timeout oopses on person page <oops> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/518337>22:35
benjimade one for "bug LP_BUG_NUMBER" too22:35
james_wI have that one, plus a bunch of others, but never thought of doing it for oopses22:36
* flacoste is away: Gone away for now22:45
=== matsubara is now known as matsubara-afk

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