/srv/irclogs.ubuntu.com/2012/05/04/#launchpad-dev.txt

StevenKwgrant: Good enough, or you'd prefer other changes?00:01
wgrantLooks quite reasonable to me.00:02
wgrantDoes it work?00:02
StevenKThe tests all pass00:02
StevenKAnd I think I wrote enough of them. :-)00:02
StevenKwgrant: https://code.launchpad.net/~stevenk/launchpad/bugs-information_type-mail/+merge/104483 has been updated.00:09
wgrantStevenK: r=me00:14
mwhudsonjcsackett, benji: ayt?00:59
mwhudsonoh never mind01:02
=== matsubara is now known as matsubara-afk
wallyworldwgrant: when do you expect use_flat to be ripped out?01:45
wgrantwallyworld: Of get_bug_privacy_filter? Undefined.01:46
wgrantHopefully within a week, but it's a bit hard to tell.01:46
wallyworldwgrant: ok. i want to use get_bug_privacy_filter() but it has no use_flat paparm; i'll add one01:46
wgrantwallyworld: I have one added in one of my local branches, but it's like two lines and your branch will probably land before mine, so go ahead.01:48
wallyworldrightio01:48
wallyworldor if yours lands first, i'll deal with it. i have a few more branches to go yet01:48
wgrantYeah01:49
wgrantIt's going to be a pretty trivial conflict.01:49
wallyworldwgrant: it seems the gbpf doesn't have a term which queries on bugtaskflat.access_policies, only access_grants01:52
wgrantwallyworld: Right, at present it doesn't use access_policies, because there are no policy grants.01:53
wgrantThere's a card in Next about making it do that01:53
wgrantIt's 3 lines of code, and if that function's used everywhere it'll apply everywhere01:53
wallyworldare there really no policy grants?01:54
wgrantThere are no policy grants yet.01:54
wgrantThat's an All permission01:54
wallyworldon qas there are :-)01:54
wgrantWhich don't exist on prod, because the UI isn't write-enabled.01:54
wgrantTrue01:55
wallyworldwgrant:  so if i want to use gpbf i will need that extra functionality. so i will have to pick up that card from the board and do that01:55
wgrantwallyworld: Why?01:55
wallyworldi need it for the remove subscriptions job01:55
wgrantNo.01:56
wgrantThe current definition of access to bugs doesn't currently include policy grants.01:56
wallyworldyes, it was even in the query you pasted01:56
wgrantIt was, yes.01:56
wgrantThat'll be the final thing.01:56
wallyworldsure, but it's still correct to use it01:56
wgrantBut if you're going to use the existing function, you don't have to care about that stuff.01:56
wallyworldi will be writing tests which require it or else trhey will fail01:56
wgrantAh, right, it could make tests slightly awkward, indeed.01:57
wgrantYou can steal the clause pretty much verbatim from the query I pasted yesterday.01:57
wgrantAnd stick it into the function.01:57
wallyworldyep01:57
wgrantAnd it will Just Work™01:57
wallyworldshould do01:57
wallyworldhopefully01:57
wallyworldwgrant: is there a bug number?01:59
wgrantDon't think so02:00
wallyworldok, will raise one02:01
wgrantYou can probably find a bug search test to extend to cover APGs.02:01
wallyworldhope so :-)02:02
wallyworldwgrant: i can't find any bug search tests which create an artifact grant to give visibility; all the current tests seem to use subscription and reply on the triggers to update the artifact grant table. is that correct?02:17
wgrantwallyworld: That's correct. Everything still assumes that subscriptions are the only things that confer access to bugs.02:37
wgrantNow that legacy search is gone that can start to change.02:37
wallyworldwgrant: ok. i've found a doc test in bugtask.txt which i can add to i think02:37
wgrant(there was no performant way to respect grants/policies in legacy search, so flat search was a prereq for all this)02:38
wallyworld_wgrant: can you see why this test isn't working? the new one is the one at the bottom https://pastebin.canonical.com/65516/04:46
wallyworld_it fails because it still returns just the 3 bugs. perhaps it's not using the flat search?04:48
wgrantwallyworld_: Non-flat search doesn't exist any more.04:54
wgrantSo it's probably using flat search.04:54
wgrantwallyworld_: The bug isn't PROPRIETARY04:54
wgrantwallyworld_: So the grant doesn't grant access to anything.04:54
wallyworld_ah, USERDATA04:54
wallyworld_doh04:55
wallyworld_thanks04:55
wgrantYou'll want to ensure/find that, rather than create.04:55
wgrantBut yes.04:55
wgrantUSERDATA04:55
wallyworld_yep04:55
StevenKwallyworld_: Are you reviewing today?04:58
wallyworld_StevenK: yes04:58
StevenKwallyworld_: I have an MP up04:58
StevenKIt's only 221 lines, disappointing.04:58
wallyworld_StevenK: sorry, wasn't running thunderbird04:58
StevenKwallyworld_: Given your recent RAM issues ... :-P04:59
wallyworld_yep :-(04:59
StevenKI don't see why.04:59
wallyworld_StevenK: i have to run out for 30mins to get kid from school04:59
wallyworld_and buy ram on the way home05:00
StevenKI have 4GiB of RAM with 64-bit, and I'm only 300MiB into swap with firefox, thunderbird, quod libet, gvim05:00
StevenKwallyworld_: Given wgrant has wedged the deployment pipeline, it's not urgent.05:01
wallyworld_ok. back soon.05:01
StevenKI don't think I'll finish the garbo job this afternoon, sadly.05:01
StevenKI wonder if the branch garbo job is doable using set05:02
wgrantIt should be, es.05:11
wgrantyes05:11
wgrantSince everything will just go to USERDATA05:11
StevenKEverything?05:11
StevenKIt's either PUBLIC or USERDATA05:12
wgrantAlthough I don't know if set() respects limits these days05:12
wgrantEverything private.05:12
wgrantHm.05:12
wgrantThere may be few enough branches that a manual UPDATE is quick enough, too.05:12
StevenK500k on DF when I checked05:12
StevenKAnd lifeless will smack us05:12
StevenKNot sure how to use .set() against what I get back :-(05:14
StevenKwgrant: Is "CASE WHEN Branch.explicity_private IS NOT NULL OR Branch.transitelvy_private IS NOT NULL THEN USERDATA ELSE PUBLIC" expressible in Storm?05:21
wgrantStevenK: No, use an SQL().05:22
wgrantAlso, that's redundant.05:22
StevenKOh?05:22
wgrantexplicitly_private implies transitively_private05:22
wgrantAnd they're not likely to be NULL05:22
wgrantThey're boolean.05:22
StevenKOh, so just check transitively_private IS TRUE ?05:22
wgrants/ IS TRUE//05:23
StevenKSo if I need to use SQL, I need the entire statement. Bleh.05:24
=== danhg_ is now known as danhg
wallyworld_StevenK: you will export IBranch.transitionToInformationType() later?05:46
StevenKwallyworld_: After it does more than just blindly setting the information_type, yes.05:46
wallyworld_ok05:46
wallyworld_StevenK: i'm wondering if there needs to be a test like test_information_type_private_team to check that info type = public when required05:55
StevenKwallyworld_: There is, that's why there is a few self.assertEqual(InformationType.PUBLIC, ...) scattered around the place.05:56
wallyworld_ok05:56
wallyworld_r=me, thanks05:57
* wallyworld_ sighs. sometimes lp is so slow at updating diffs :-(05:57
StevenK528? When did that happen?05:58
wgrantMine, last night.05:59
wgrant526 527 were already taken05:59
StevenKAh05:59
wgrantI suspect by stub test images, but that's merely a guess05:59
stubdidn't one of them go live?05:59
StevenKwgrant: Do you think it's worthwhile adding self.log.debug() to the garbo job about progress?06:00
wgrantStevenK: The looptuner should be enough output06:00
wgrantAt DEBUG206:00
wgrantI think we run it at DEBUG2, too06:00
StevenKRight, then I'll bug wallyworld_ again. :-)06:00
wgrantstub: Your 525 was live.06:00
wgrantwallyworld_: r=me06:03
wallyworld_thanks!06:03
StevenKHaha, 3 underscore Ian06:09
StevenKwallyworld_{,__}: I have another one for you.06:09
wgrantwallyworld_: A pretty quick dev-only one for you, if you still have time: https://code.launchpad.net/~wgrant/launchpad/easier-remote-access/+merge/10468406:09
wgrantHeh06:09
wallyworld___me finds a screwdriver to add extra ramyou're so kind06:09
wallyworld___sure06:09
StevenKwgrant: You can review the garbo job branch, if you wish, it's +3806:10
wgrantI don't want to steal wallyworld________'s new non-swapping thunder.06:11
wgrantBut I might anyway.06:11
StevenKHahaha06:11
wgrantStevenK: Your linebreaks are criminal, sqlvalues is evil, and you don't test public.06:11
wgrantAlso self.transaction wut?06:11
wallyworld___wgrant: the branch looks ok but i'm not really sure i know enough to give it a proper +106:12
wgrantThe worst it can do is break new dev installations :)06:12
wgrantAnd it doesn't break new dev installations.06:12
wallyworld___WCPGW06:12
wallyworld___r=me06:13
wgrantThanks.06:13
wallyworld___np06:13
StevenKwgrant: Without sqlvalues, it puts in 'User Data' which doesn't help06:13
wgrantStevenK: Use the ?06:13
wgrantSQL("foo ? bar ?", params=('whatever', 'oh look something else unsafe'))06:13
wgrantHm06:14
wgrantAlthough it's possible that won't work for a dbenum06:14
wgrantIn which case I guess sqlvalues will have to do.06:14
StevenKI can try ? if you wish06:14
wgrantOr you could just use params= with .value directly. That's probably best.06:14
wgrantOh good06:16
wgrantThere's a third copy of those hostnames in lp-dev-utils06:16
StevenKHahaha06:17
StevenKwgrant: http://pastebin.ubuntu.com/966263/06:17
StevenKwgrant: If it isn't duplicated it might be forgotten!06:17
wgrantStevenK: Your linebreaking in the first hunk is still likely to draw criminal charges.06:19
StevenKwgrant: http://pastebin.ubuntu.com/966266/06:19
wgrantDeindent line 13 and you're good06:20
StevenKwgrant: Diff updated, please have a look.06:31
wgrantStevenK: Branch.information_type is unindexed.06:34
StevenKHmmm06:34
wgrantI sense a 2-statement DB patch in your fu=ture06:34
StevenKHaha06:34
StevenKwgrant: Two?06:35
lifelessindex + metadata06:36
wgrantCREATE INDEX and INSERT INTO LDR06:36
StevenKYah06:36
jtvI think devel's versions.cfg still relies on some zope versions that are too old for Precise or something.  I can't build on Precise, without bumping a bunch of versions in versions.cfg to the ones I actually have.06:41
wgrantjtv: What's the error?06:44
wgrantjtv: Perhaps it breaks if you have some old versions installed through apt (for maas)?06:44
wgrantOtherwise you should use LXC.06:44
jtvError: Couldn't find a distribution for 'zope.publisher==3.12.0'06:44
jtvetc.06:44
wgrantSure your download-cache is up to date?06:45
jtvNo06:45
jtvI only have newer versions than what's in devel's versions.cfg.06:45
wgrantwgrant@lamuella:~/launchpad/lp-branches/devel$ bzr ls download-cache/dist | grep zope.publisher06:46
wgrantdownload-cache/dist/zope.publisher-3.12.0.zip06:46
wgrantdownload-cache/dist/zope.publisher-3.12.1.tar.gz06:46
wgrantwgrant@lamuella:~/launchpad/lp-branches/devel$ bzr ls download-cache/dist | grep zope.publisher06:46
wgrantdownload-cache/dist/zope.publisher-3.12.0.zip06:46
wgrantdownload-cache/dist/zope.publisher-3.12.1.tar.gz06:46
wgrantYour download-cache must be bad06:46
jtvBad in what way?06:46
jtvBear in mind that I've been running Precise since January, and so haven't been able to run any Launchpad setup since then.06:46
jtvBut I seem to get past this if I edit versions.cfg and bump z3c.ptcompat from 0.5.3 to 0.5.5; zope.app.component from 3.8.3 to 3.8.4; and so on.06:47
StevenKstub: Can you have a look at https://code.launchpad.net/~stevenk/launchpad/db-branch-information_type-index/+merge/104689 ?06:47
StevenKI can't seem to request a review of lifeless, but it's one index.06:48
wgrantjtv: Which zope.publisher is in download-cache/dist in the branch you're trying to build?06:48
wgrantjtv: Perhaps try make clean06:48
wgrantjtv: It may still think it's using 2.6 or something06:48
jtvCrap — even “make clean” fails06:49
jtvrm: cannot remove `sourcecode/pygpgme/gpgme/*.so': Too many levels of symbolic links06:49
stubStevenK: r=stub. That should go live?06:49
wgrantjtv: I think your download-cache, eggs, sourcecode etc. symlinks might be a little screwed.06:49
StevenKstub: As long as backups aren't in our way, yup.06:50
jtvThey may well be.  I haven't been able to run the rocketfuel scripts for so long.06:50
wgrantThey haven't changed since 2009, but maybe.06:50
jtvThe scripts maybe, but I'm sure the data has!06:51
jtvload_cache fails: No JSON object could be decoded06:51
* StevenK stabs Level306:51
jtvTrying more make clean & version bumps.06:52
StevenKjtv: make clean and then cd into your download-cache and bzr up06:53
jtvThe download-cache in the branch?06:53
StevenKWhich is a symlink06:53
jtv$ bzr up06:55
jtvTree is up to date at revision 465 of branch bzr+ssh://bazaar.launchpad.net/%2Bbranch/lp-source-dependencies06:55
jtvLet's see what “make” does now.06:56
StevenKstub: DB patch is on db-devel r11569.06:56
stubta. I've added it to my todo for when the backups complete06:56
StevenKstub: Thanks.06:56
StevenKwgrant: ^ Can haz approve for garbo job *now*? :-)06:56
jtvWow, I managed to have a conflict in sourcedeps.cache.06:58
StevenKUnsurprising06:58
jtvReally?  And I was so proud.06:58
wgrantStevenK: Why db-devel?06:58
wgrantStevenK: Live patches go to devel06:58
StevenKBleh06:59
StevenKwgrant: Merge it after Ian's FDT, then?06:59
wgrantI guess.06:59
jtv\o/ I can “make.”  Thanks guys.07:00
wgrantIt's the first step toward recovery :)07:00
jtvOur Makefile really needs work again.  I had it doing parallel tasks, and not rebuilding mailman and css/js every time you rebuild the db schema at one point.  :(07:01
StevenKjtv: wallyworld___ has added things to prevent mailman building07:01
jtvI so hope I wasn't wrong in bug 994410.07:02
=== almaisan-away is now known as al-maisan
wallyworld___StevenK: what did i do?07:26
wgrantHmm07:26
wgrantDo I want to teach ec2 to preserve the buildout egg cache?07:26
noodles785Hi people, is a tag added to an LP bug as soon as it is deployed to staging or qastaging? (we'd like to do integration testing as soon as bug 992691 lands on staging).07:27
_mup_Bug #992691: Special permissions for 'Archive.commercial' are not needed <tech-debt> <Launchpad itself:In Progress by jml> < https://launchpad.net/bugs/992691 >07:27
wgrantnoodles785: Yes, it will have qa-needstesting added a few minutes after it's on either qastaging or staging. In this case you'll need to wait up to 12 more hours for it to hit staging, since it'll be on qastaging first.07:28
noodles785wgrant: the egg cache is left pristine isn't it? I don't see why not.07:28
noodles785wgrant: perfect, thanks!07:28
wgrantHowever, the branch failed ec2 a couple of hours back. It's trivial to fix.07:28
wgrantAlso, you've been incremented by 10?07:28
noodles78510? 10 credits?07:29
wgrantYpi07:29
wgrantBah07:29
wgrantYou've traditionally been noodles77507:29
noodles785Hah, oh.07:29
=== noodles785 is now known as noodles775
wgrantnoodles775: So, hopefully jml will be around to fix the test failure tonight. If not, I'll do it. Either way I'll reland it this evening, and it will be on staging when you start on Monday.07:30
noodles775wgrant: great, thanks!07:30
wgrantIt's about 7-12 hours from landing to qastaging, and then another 13-20 after that until staging.07:30
wgrantThis'll hopefully be down to 90 minutes and 120 minutes once parallel testing is complete.07:31
adeuringgood morning07:45
czajkowskialoha07:51
cjwatsonjtv: was bug 994410 supposed to be on LP rather than MAAS?07:51
jtvcjwatson: absolutely07:56
jtvAnd I work so hard to catch chromium at that.07:56
jtvThanks.07:56
jtvReviewer needed!  https://code.launchpad.net/~jtv/launchpad/bug-994410-stop-using-latest_message/+merge/10470310:12
czajkowskijtv: is there anything we need to be aware of when adding a new language in Ubuntu/lp10:13
jtvYes: there are several very different things that people call “adding a language.”10:13
czajkowskihttps://answers.launchpad.net/launchpad/+question/19597010:14
czajkowskiwanted to add BRX10:14
jtvczajkowski: these people have really done their research.  It answers all questions I might have; you're ready to go.10:16
czajkowskiso the next bit is I've not added a langauge before and don't know where in lp I do this10:17
czajkowskiso not sure I can  also :/10:17
jtvI don't think there's an ISO 639-2 code, so the 639-3 is fine.  It's an Individual language code, not a Collective which we can't accept.10:17
jtvThis is properly "adding a language" in Launchpad.  Do you see the option just under “Available languages in Launchpad”?  https://translations.launchpad.net/+languages10:18
czajkowskijtv: yes10:19
jtvWell there you go then.  You've got the plural expression, language code, English name…10:19
czajkowskithank you10:20
jtvPlease convey to them my appreciation for the care and effort they put into this request.10:21
jmlhello10:21
jmlI'm around to fix the test failure.10:21
wgrantjml: Did you get the email?10:21
jmlwgrant: I think so.10:21
wgrantI didn't realise my suggestion was so offensive to the test suite :(10:21
czajkowskijtv: thank for the help.10:24
jtvno worries10:25
jtvczajkowski: don't forget to enter the plural-form data!10:25
jmlwgrant: yeah.10:25
jmlwgrant: I like that we have auto-generated tests for IPersonRole, but that we don't auto-generate it ourselves.10:26
jtvczajkowski: there's 2 plural forms, and the formula is “n != 1” (I think entering it in that form will work)10:26
wgrantjml: That is pretty cool, yeah.10:26
=== al-maisan is now known as almaisan-away
jtvstub: I want to drop a column from POFileTranslator, and stop the TranslationMessage trigger from writing it.  Would it be best to do that in one patch?  Or a sequence of smaller steps?10:28
czajkowskijtv: am trying but I keep getting an oops10:29
jtvThen I suppose the format isn't quite right.  Have a look at other languages; see if you can crib the format.10:29
wgrantjtv: One patch is fine, as long as the appservers have already stopped going near it.10:29
jtvOK thanks10:30
jtvSpeaking of which, here's my MP for achieving that.  :)  https://code.launchpad.net/~jtv/launchpad/bug-994410-stop-using-latest_message/+merge/10470310:30
stubjtv: There is no problem doing both the column drop and the trigger change in one patch. Both are fast operations.10:32
jtvThanks.  Just wondering if there were multi-server rollout implications.10:33
* jml fixes now10:33
stubjtv: We *might* be able to twiddle the trigger live. The column drop has to go through fast downtime. Easier for everyone if it can go in one patch.10:34
czajkowskijtv: done10:34
jtvstub: very well10:34
jtvczajkowski: looking good10:35
czajkowskijtv: sorry about that peksy oops :)10:35
jtvOh, the code change?  Didn't take long to figure out.  :)10:35
jtvstub: I suspect https://dev.launchpad.net/Database/LivePatching is far out of date10:36
jmlhey10:37
jmlare there any webservice tests written as unit tests?10:37
jmlis there any non-historical reason for writing them as doctests?10:38
jmlthey clearly don't function as documentation for the actual users of the webservice.10:38
stubjtv: Was this an example of a CRITICAL (genuine) bug drowned out by CRITICAL (policy) bugs?10:38
cjwatsonjml: lib/lp/soyuz/browser/tests/test_archive_webservice.py comes to mind10:39
cjwatson(Quite a few others, 'find -name \*webservice\*')10:39
jmlcjwatson: thanks.10:39
jtvstub: arguably — in any case, we never actually seem to have made a decision to drive critical bugs to zero; we made a decision to allocate them some time, we announced that that would drive them to zero, and then we instated a policy for creating new ones at a faster rate.  :)10:40
jml:(10:40
wgrantcjwatson, jml: Note that those tests use launchpadlib, and launchpadlib tests are *very* slow.10:40
wgrantMost of the doctests avoid launchpadlib. I'm not sure if there are non-doctests that do.10:41
jmlHmm.10:41
stubJust thinking we knew this was a timebomb and we let it explode creating more work (cleanup)10:41
jtvstub: absolutely.10:41
jtvAnd the flood of policy-critical bugs gave us easier things to fix instead.10:42
jtvIf you want to fill a bucket of dirty water with clean water, you can pour it out first and then refill it; or you can put it under the tap.  But the latter is something you only do if you can't stand to be without a full bucket for a while.10:44
jmlwgrant: ok, that's fixed. r1520310:44
stubjtv: Are these tests you removing going to have to be rewritten when we maintain the latest translator asynchronously?10:44
jtvThere will be other tests, but much simpler.10:44
jtvThere won't be any complications from how data got where it is; it's either there or not there.10:45
jtvDragging the data through the same changes as other data is what makes it difficult.10:45
wgrantjml: It's in devel.10:50
jmlwgrant: oh, you just landed it directly?10:50
wgrantjml: Yeah10:50
wgrantNo point re-ec2ing it10:50
jmlwgrant: I guess not.10:51
jtvThanks for the review stub10:55
StevenKBah. Forgot the --incremental for r15204. :-(10:56
jtvEr… what's the current landing procedure?  I've been away for a while.10:56
wgrantjtv: bin/ec2 is now in lp:lp-dev-utils10:57
wgrantSo grab that, put it in your PATH, 'ec2 land'10:57
jtvThanks.10:57
=== Ursinha is now known as Guest7047
=== adam_ is now known as aspiers
=== Ursinha_ is now known as Guest96131
=== Ursinha__ is now known as Ursula
=== Ursula is now known as Ursinha
=== Ursinha is now known as Guest69236
jtvGrar.  The bugs that come out of the woodwork when you start simplifying POFileTranslator.  Should've done it years ago.11:41
jmljtv: I know what you mean.11:54
jtvYou've looked at it?  Or seen the same thing elsewhere?11:54
jmljtv: I don't think I've ever thought, "man, I'm glad I postponed cleaning that up, that made everything go so much better and faster"11:54
jmljtv: same thing elsewhere.11:54
jtvHeh.11:54
jtvTo be honest, I think by nature _not_ cleaning up pays off beforehand, unlike cleaning up which pays off afterwards.11:55
jtvBut I don't think we've been sorry about having cleaned things up very often.  :)11:56
jmljtv: well, practically every time I've got some code and my understanding doesn't quite match it (or there's a clean up I can see), whenever I do finally fix it up, I *always* think I should have done it earlier.11:58
jmlmostly because it would have made everything between the realization and the cleanup easier.11:58
jtvThen I wonder: if you adjust to that and clean up earlier, what would be the signal that you've overshot?  Or is there no such thing?11:59
jtv(I'm not entirely un-selfish in asking)12:03
cjwatsonSometimes cleanup is blocked on something else, and waiting means the cleanup is "delete big pile of stuff" rather than "spend two weeks fixing other stuff and then delete stuff".12:04
jtv My current situation in a nutshell.  :)12:05
jtvBut with a twist: I found a kind of circular dependency.12:05
jtvWhich reminds me that I should keep dpm and Deryck updated.12:05
jmljtv: hmm.12:06
dpmheya jtv, what's up?12:07
jtvSpeak of the  :)12:07
jmljtv: perhaps decreased certainty about what to clean up?12:07
jtvdpm: I'm just dealing with some breakage during the Quantal opening.12:07
jtvjml: something to keep an eye out for next time.  :)12:07
jtvdpm: no worries, we'll get it done.  But I've gone off on a bit of a tangent cleaning things up that made it hard to fix these problems we've been having.  And I found some things.12:08
jmljtv: sometimes I get a certain circular mental motion / paralysis when I'm trying to clean things up when I really should just solve the damn problem.12:09
* dpm worries that "things" are not "good things"12:09
jtvdpm: Well the bad things have already happened and now we can work on fixing them.  Some deeply obscure PLPSQL code looks to me like this would happen:12:09
jtvjml: also a good thing to keep an eye out for then.  I'll try to remember.12:10
jtvdpm: say you have two POFiles that share.12:10
jmlsorry, figuring this out myself now12:10
jtvAnd there's a record of your latest translation in one of them, but not in the other.12:10
jmlI think the tighter the loop, the less cost in overshooting either way12:11
jtvProbably.12:11
jtvdpm: now you enter a new translation, in either of them.12:11
jtvdpm: the obscure code is the code that keeps track of who's contributed to which POFiles.12:11
jtvAnd it says “oh good, I've just updated an existing contribution record (POFileTranslator is the actual table); that means I don't need to create a new one.  I'm done.”12:12
jtvAnd so it never creates a similar record for that other POFile — even if that was the one you were translating in in the first plcae!12:12
jtv*place12:12
jtvdpm: sound familiar?12:12
jtvThis is what users have been complaining about that we just couldn't figure out.12:13
=== bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: bac | Firefighting: - | Critical bugs: 3.47*10^2
dpmjtv, oh, so if I understand it correctly that's the bug we recently talked about?12:27
jtvdpm: I think it just might be.12:27
=== Ursula is now known as Ursinha
=== matsubara-afk is now known as matsubara
rick_h_anyone know what's up with Error: Couldn't find a distribution for 'pytz==2012c'.12:59
rick_h_?12:59
rick_h_pulled source-deps, not there, reran buildout but can't find it12:59
rick_h_anyone know where I'm supposed to have gotten it from?12:59
wgrantrick_h_: download-cache12:59
wgrantbzr up it12:59
rick_h_hmm, did but said it was up to date12:59
rick_h_Tree is up to date at revision 465 of branch bzr+ssh://bazaar.launchpad.net/+branch/lp-source-dependencies13:00
rick_h_?13:00
wgrant2012c is in there for 2.6 and 2.713:01
rick_h_ok, yea see it there, just buildout/make hating on me I guess.13:01
rick_h_ok, thanks for verifying it's where it should be13:01
rick_h_wgrant: doh, sorry was updating download-cache in ~/launchpad/ not realizing it wasn't symlinked into devel but was it's own copy13:04
wgrantrick_h_: Hm, that's meant to be symlinked.13:04
rick_h_yea, that's what I thought. I know I did some hackery due to precise install fun so probably my fault13:05
wgrantThe default setup is that devel/download-cache is symlinked to ~/launchpad/lp-sourcedeps/download-cache, and all the other branches have theirs symlinked to devel13:05
rick_h_right13:05
jmltabs :(13:18
wgrantjml: Ew, where?13:18
jmlwgrant: soyuz/configure.zcml13:18
wgrantJust the one.13:19
wgrantStill, destroy.13:19
jmlwgrant: with enthusiasm13:21
deryckallenap, hi. You around?13:22
deryckah, see the lunch afk message now.  sorry, catch you later.13:22
allenapderyck: Hi.13:23
allenapderyck: I forgot to update my status.13:23
deryckadeuring, rick_h_ -- sorry, got busy chatting and missed it was standup time.13:32
deryckadeuring, rick_h_ -- be right there.13:32
=== almaisan-away is now known as al-maisan
jmlhttps://code.launchpad.net/~jml/launchpad/commercial-means-shut-up/+merge/10473913:39
jmlpatch to rename IArchive.commercial13:39
rick_h_deryck: https://code.launchpad.net/~rharding/launchpad/editstatus_timeout_874250/+merge/10391213:44
bacjml: looking13:47
jmlbac: thanks.13:47
=== kirkland` is now known as kirkland
deryckrick_h_, just ping me when that MP is good to go.  I'm not watching it, so will need the reminder.13:53
wgrantrick_h_: It's midnight on Friday so I can't really give a proper review, but the _init_new_task thing strikes me as more than a little awkward. Have you considered merging that into createManyTasks, and having createTask just delegate to createManyTasks? That's the pattern we use elsewhere.13:54
rick_h_deryck: all good13:58
rick_h_wgrant: ah, good point. I can take a peek at that once I find why my MP isn't working right13:59
wgrantIt should remove a lot of duplicated default stuff, and eliminate the reasonably hideous getattr stuff that this structure requires14:00
rick_h_yea, gotcha. started out smaller but grew over time, curse of taking too long14:04
wgrantYeah, that often happens, particularly when setifying ancient code.14:05
rick_h_ok, need bzr help, I removed lib/lp/bugs/doc/bugtask.txt14:05
rick_h_so the file is gone, but hte MP says there's conflicts in it14:05
rick_h_and doesn't show the file deleted14:05
rick_h_my bzr branch shows no conflicts, file is gone, push and push --overwrite no helpy, any other ideas?14:06
rick_h_ah, sec...see this in the MP diff  renamed file 'lib/lp/bugs/doc/bugtask.txt' => 'lib/lp/bugs/doc/bugtask.txt.THIS'14:07
jtvShould downtime database branches still branch off db-devel?14:28
rick_h_jtv: I've yet to do one, but I do believe so14:31
wgrantjtv: Yes, but it doesn't really matter since there's rarely more than in progress at a time.14:33
jtvNaturally.  Thanks.14:33
wgrantfastdowntime patches -> db-devel, live -> devel14:33
bachi jml -- your branch looks mostly good but i have a policy question about changing the signature of 'createPPA' and removing 'commercial' from being exported.  since those items were introduced in beta, we need to continue supporting them in beta and 1.0.14:33
* wgrant sleeps.14:33
jtvnn wgrant14:33
rick_h_see wgrant14:33
jmlbac: we (consumer-apps) are the only users permitted to do that14:33
jmlbac: I myself added the 'commercial' parameter a week or two ago.14:33
wgrantYeah, API stability is not a concern here.14:34
wgrantPossibly for reading Archive.commercial, but meh.14:34
wgrantThat flag wasn't even around when 1.0 was released, I'm pretty sure14:34
wgrantNobody but CA has any cause to use it.14:34
jmlbac: and we're OK with the compat break, so I don't think it's a practical concern14:34
jmlwgrant: thanks :)14:34
jmlwgrant: sleep well & have a good weekend.14:34
wgrantjml, rick_h_: Thanks, you too.14:35
czajkowskirick_h_: please read all tweets today laced with thick irish accent - will make it funny for you , and hair pulling experience for me :)14:35
rick_h_czajkowski: :)14:35
bacjml: ok, so the createPPA signature change since beta was to add an optional parameter...so removing it is a-ok.  sounds reasonable14:35
jmlbac: thanks.14:37
wgrantgary_poster: Argh, sorry. That cookie-authentication.txt failure is my fault.14:40
wgrantgary_poster: I missed a space when I updated the domain list in setuplxc14:40
bacjml: approved but your test is slightly broken14:41
jmlbac: oh?14:41
gary_posterwgrant, oh cool.  good to know thx14:44
gary_posterwill look after babysitting/lunch time, starting now :-)14:44
wgrantHeh14:44
wgrantpqm-submitting a fix14:44
jmlbac: have pushed a fix for the test, as well as doc fixes that james_w recommended. Can you please land?14:55
jmlnote, I expect test failures.14:55
bacjml: would you set the commit message on the MP please.14:56
jmlbac: done.14:57
bacjml: so you want me to 'ec2 land' but you don't think it'll make it?14:57
jmlbac: pretty much. renames in Launchpad never work the first time.14:58
bacjml: alrighty14:58
jmlbac: I've done what I can, but grep only takes one so farr.14:58
bacjml: is there a bug for this work ?15:11
jmlHmm.15:11
jmlNo. I can file one if you'd like.15:11
* jml wishes lp had rev-based QA15:11
bacjml: where i guess there should be some qa, to ensure the UI doesn't break.  so a bug would be needed.15:12
bacs/where/well15:12
jmlhttps://bugs.launchpad.net/launchpad/+bug/99464415:13
_mup_Bug #994644: IArchive.commercial is misleading name  <Launchpad itself:New> < https://launchpad.net/bugs/994644 >15:13
jmllinked up15:13
rick_h_ok, going to take bzr out back and shoot it...any masters around know how to trick bzr into removing the THIS file it's creating for it's own evil puposes?15:18
rick_h_https://code.launchpad.net/~rharding/launchpad/editstatus_timeout_874250/+merge/10391215:18
rick_h_tried creating a new branch and merging the old in, creating and removing the file itself,15:18
rick_h_nothing in the conflict docs in bzr land is pointing me at any hints I can tell15:19
jmlrick_h_: there's only a .THIS? no .OTHER?15:21
rick_h_jml: yea, I did at one point have a conflict I resolved there15:21
rick_h_but that .THIS isn't in tree anywhere, it's only in LP's MP head for some reason15:21
rick_h_so I can't do any sort of force delete, etc15:21
jmlrick_h_: so the current head on LP has got most recent devel merged in & conflicts resolved?15:22
=== al-maisan is now known as almaisan-away
rick_h_jml: rgr15:22
rick_h_if I try to merge with devel is says nothing to do, push, nothing to push, pull my branch, nothing to pull15:22
jmlrick_h_: what happens when you change into devel and merge your branch in to that?15:22
jmli.e. manually on your own system15:22
rick_h_but the MP says there's a conflict and refuses to delete the file15:22
rick_h_hmm, haven't tried that, what I did do was create a fresh branch off of devel, and merge these changes into that new branch15:23
rick_h_as soon as I pushed it up to create a new MP...it had this same problem15:23
rick_h_so I'd wager that merging into devel itself would have this issue15:23
jmlrick_h_: because merging into devel is exactly what LP does, AIUI15:24
jmlrick_h_: that rename is *really weird*15:25
rick_h_right, so figuring by some bzr voodoo I need to get rid of that .THIS which should never have been there after I did the bzr resolve on my conflicted file15:25
rick_h_but that voodoo is escaping me15:25
cjwatsonPerhaps the file-ids for that file differ in the two branches15:26
cjwatsonbzr ls --show-ids would tell you15:26
rick_h_looking15:26
jmlthat would account for the original conflict but wouldn't account for committing the rename15:26
cjwatsonWell, it would suggest the simplest fix which would be to 'bzr rm --keep' the file with the wrong file-id and 'bzr add --file-ids-from=../devel' it with the same contents15:27
cjwatson(If true)15:27
rick_h_right, but the fiel isn't there at all, so I can't rm anything with it15:28
rick_h_file that is15:28
rick_h_there is no bugtask.txt.THIS15:28
cjwatsonOh, hmm15:28
jmlunderscores. sheesh.15:29
cjwatsonI'm stumped then.  If it were me, at some point I'd probably give up, make a fresh branch, and apply the patch ...15:29
rick_h_so just manual diff/manually patch the trees vs trying to merge them with bzr itself15:30
rick_h_yea, guess that makes sense, the commit history isn't important with this atm so works for me15:30
* jml tries.15:30
stubgary_poster: That nl_  helper occasional failure is special.15:30
* rick_h_ cheers on jml15:30
gary_posterstub, heh, yeah. :-)  benji is looking at it15:31
jmlwatch this space: https://code.launchpad.net/~jml/launchpad/editstatus_timeout_874250/+merge/10476315:31
rick_h_will do15:32
benjistub: when I repeatedly run the test it fails about 1 in 30 times, when I edit the doctest that it's in to just include the failing test I can't get it to fail at all (in more than 100 runs)15:32
stubbenji: Is this with PG 9.1 or 8.4?15:33
benjistub: 8.415:33
jmlok same prob.15:34
rick_h_jml: ok thanks for trying. I'll feel better knowing it's not me just having a case of fridays not 'getting' something and work around it15:34
benjistub: I have some reason to believe that the bad behavior is generated in these two lines:15:34
benji        p = plpy.prepare("SELECT to_tsquery('default', $1) AS x", ["text"])15:34
benji        query = plpy.execute(p, [query], 1)[0]["x"]15:34
stubbenji: I'd consider trying PG 9.1. If the problem goes away, we can blame plpythonu. It received significant updates in 9.0 and 9.115:35
stubbenji: If there is some sort of memory allocation area, bind variables like you point out would be where they are at.15:35
stubc/area/error/15:35
benjistub: I quake in fear of doing a postgres upgrade15:36
stubIts trivial really, and I just emailed saying devs will need to upgrade soon anyway :)15:36
benjionce more into the breach15:37
stubbenji: Have you managed to get debug information about what 'query' is being passed into plpy.execute from a failed run?15:37
benjistub: yep, I couldn't figure out how to enable/locate the output of plby.debug so I just transmuted those calls to write to a file; everything looks good (even when the tests fail) through the "15" debug output (just before the lines I quoted earlier) so I added a "16" line just after and when I got a failure the logged query was messed up as you would expect15:40
stubIf the query string going in is correct, but the results from plpy.execute wrong, then I think we must be triggering a bug in plpythonu or tsearch2.15:42
abentleyrick_h_: So the conflict makes sense to me.  This is a case where one side wants to modify a file, and the other side wants to delete it.  It's a "contents conflict" rather than a "text conflict", because the file was deleted.15:42
stubjtv: The 'IF EXISTS' clauses are likely 9.0 specific syntax15:43
stub(and are unnecessary)15:43
abentleyrick_h_: Bazaar keeps the file around in case you choose to resurrect it.  But it renames it to foo.THIS because it's part of a conflict.15:43
jtvstub: they are probably unnecessary, yes.  They're more to avoid development hassle than anything else.15:44
benjistub: I'll try upgrading PG and see what happens15:44
stubjtv: yer, I like them too (but I'm currently writing 9.1 specific code ;) )15:44
jtvGrr.  Can't land: pqm says it can't verify my gpg sig.15:45
stubec2 land or bzr lp-land ?15:46
abentleyrick_h_: You can do diff -u lib/lp/bugs/doc/bugtask.txt.BASE lib/lp/bugs/doc/bugtask.txt.THIS to see what changes were made.15:46
jtvstub: I did pqm-submit.15:47
jtv(After ec2 land had the same problem)15:47
jtvMeanwhile, looks like “IF EXISTS” is 9.x only for the ALTER TABLE DROP COLUMN part of my patch.15:48
jtvbenji: if you're still on PG 8.4, maybe you could try out a “make schema” on my branch?15:50
jtvI'd sleep easier knowing that that worked.  :)15:51
jtvIt's lp:~jtv/launchpad/db-99441015:51
rick_h_abentley: right, but I marked it as resolved so I have no files in tree named bugtest.txt*15:54
rick_h_and I can't 'get' the file so I can see it by pulling/merging15:54
jtvDefinitely time to go home.15:55
abentleyrick_h_: Right, when you mark a conflict resolved, it deletes any files you had hanging around to help you resolve your conflict.15:55
benjijtv: I'm trying your branch now.15:56
jtvThanks!15:56
rick_h_abentley: right, so I follow the 'usual' process and thought I did it right from that standpoint, but no idea how to make the MP 'happy' at this point from this state15:56
abentleyrick_h_: You can retrieve the THIS version with "bzr cat lib/lp/bugs/doc/bugtask.txt"15:56
rick_h_bzr: ERROR: u'lib/lp/bugs/doc/bugtask.txt' is not present in revision rick.harding@canonical.com-20120504145817-vw1o8a0212a8olkv15:57
jtvbenji: if it's not too much to ask, maybe run some arbitrary lp.translations tests to see if the trigger blows up on 8.4?15:57
benjijtv: will do15:57
abentleyrick_h_: That would work in a devel branch, not in the editstatus_timeout branch.15:58
rick_h_ah ok15:58
abentleyrick_h_: I don't think you'd have THIS in the editstatus_timeout.  It out to be OTHER in that case.15:58
abentleyrick_h_: And to retrieve BASE,  bzr cat -r ancestor:lp:~jml/launchpad/editstatus_timeout_874250 lib/lp/bugs/doc/bugtask.txt15:59
abentleyrick_h_: To make the mp "happy", you need to merge devel into editstatus_timeout_874250, fix the conflict, push.16:00
abentleyrick_h_: Since you can't push into jml's copy of the branch, you need to push your own copy, and resubmit the merge proposal to use your copy.16:01
rick_h_abentley: right, but his branch is a copy of my branch which is already merged with devel, conflict resolved, and pushed16:02
abentleyrick_h_: When I merge his branch into devel, I get a conflict, so I don't think the conflict was resolved.16:02
=== salgado is now known as salgado-lunch
rick_h_ok, I merged devel with my branch and resolved it there16:03
rick_h_but gotcha, it's still unhappy. I'll rework it and carry on. Thanks for looking into it abentley16:03
benjijtv: no test failures in about 100 tests; unless you want me to run more I'll kill it now16:10
jtvbenji: fantastic.  Thanks.  Feel free to stop it.16:10
jtvAnd with that, I'm off.  Have a good weekend everyone!16:10
benjicool16:10
abentleyrick_h_: So, you merged 15195, but the file was changed in 15207.  That's why your merge didn't fix the conflict.16:10
=== matsubara is now known as matsubara-lunch
=== deryck is now known as deryck[lunch]
=== salgado-lunch is now known as salgado
=== Ursinha is now known as Guest78578
=== matsubara-lunch is now known as matsubara
=== deryck[lunch] is now known as deryck
dratonehi all.17:58
=== Ursinha- is now known as Ursinha
=== Ursinha is now known as Guest84854
=== Guest84854 is now known as Ursula
=== Ursula is now known as Ursinha
benjirick_h_: so, how did you fix http://paste.mitechie.com/raw/606/?  I'm upgrading to postgres 9.1 and have the same problem19:16
lifelessbenji: you need to enable the fti procedures, which is done as part of rocketfuel setup IIRC19:18
lifelessbenji: basically running the db setup part again19:18
benjilifeless: thanks19:19
lifeless(Thats a WAG, but I'm fairly sure about it)19:19

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