=== camilotelles [n=Camilo@20132194128.user.veloxzone.com.br] has joined #launchpad [12:06] jordi: pong [12:07] LarstiQ: dunno [12:09] lifeless: ok, I'll see if I can find some documentation === interalia [n=interali@adsl-60-232.swiftdsl.com.au] has joined #launchpad [12:14] https://wiki.launchpad.canonical.com/BranchActivityVisualization is the closest I get to having activity explained [12:26] LarstiQ: yah, but thats not per product :) === Virtuall[BZA] [n=virtuall@alpha.bounzza.net] has joined #launchpad [12:27] lifeless: right, and I also found activity reports on https://wiki.launchpad.canonical.com/LaunchpadTeamFAQ. Completely different, although interesting. [12:27] :) [12:27] you can see one of those in the bzr list archives === Virtuall[BZA] [i=virtuall@alpha.bounzza.net] has joined #launchpad [12:28] lifeless: yes, I remember that one [12:28] and Martin's reaction to it ;) === LarstiQ is going to give gtimelog a try === segfault [i=carlos@prognus.com.br] has joined #launchpad [12:42] segfault: we need to talk. There are way too many split files. Maybe we can do something. === netjoined: irc.freenode.net -> brown.freenode.net === interalia [n=interali@adsl-60-232.swiftdsl.com.au] has joined #launchpad === jamesh [n=james@66.103.220.207] has joined #launchpad [12:51] jordi: sure! can you tell me how? :) [12:59] jordi, yes, one potemplate can be moved from the +admin page but only by you or any Rosetta admin === carlos -> bed [01:01] night! [01:01] night carlos [01:07] What's the right way to flush the sqlobject cache? [01:07] and subsequently what's the right way to get python to GC the objects? [01:08] This is actually kinda important I think [01:10] Kinnison: flush_database_caches from canonical.database.sqlbase [01:11] Kinnison: Although, can you explain a little more about why you need this? [01:11] And why do you care about when objects are GCed? [01:11] spiv: because the domination in the publisher uses ca. 900M *per distrorelease* [01:11] 900M of sodding sqlobjects [01:12] hmm, perhaps 600M [01:12] No, 900 [01:12] Ok. To get Python to GC objects, just make sure you don't have any references to objects you don't need. [01:12] And don't define __del__ :) [01:12] so flushing the db cache should do the trick? [01:12] and python will gc merrily from there? [01:12] Perhaps. [01:12] Depends on if you have any other references to them :) [01:13] well, I'm not keeping 'em around [01:13] if there are cycles what will python do? [01:13] It will merrily collect them. [01:13] good, I know perl won't [01:13] because it's shit [01:13] *Unless* you have __del__, in which case they'll probably end up in gc.garbage instead. [01:13] do sqlobjects have __del__ ? [01:14] Nope. === spiv just double-checked. [01:15] SQLObject does define it on connections iirc, but that shouldn't matter. [01:15] Btw, how do you know that that 900MB is sqlobjects? [01:16] Well, I'm assuming it is [01:16] Ah :) [01:16] You're probably right. [01:16] because if it's not, I don't see what it can be [01:16] since the code is essentially === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #launchpad [01:16] But just to make sure, take a look at http://twistedmatrix.com/users/spiv/countrefs.py [01:16] for some_sql_object in gigantic_select_result: [01:16] do_stuff(some_sql_object) [01:17] spiv: we'd need to totally stop the sqlobject cache from running i think === Kinnison kills this 3.4G process [01:17] it's too scary [01:17] SteveA: That may be possible. [01:18] Kinnison: Also, if flushing the cache is inadequate, gc.get_referrers(some_object_I_thought_should_be_gced) may be helpful. [01:18] spiv: doesn't that kinda imply keeping a reference to it to check? [01:18] Kinnison: Well, that's the trick ;) [01:19] Kinnison: Either find the object the same way countrefs.py does (by crawling over gc.get_objects()), or keep a weakref to an object you suspect isn't gc'd. === Kinnison watches ram usage with these flushes in place [01:20] You can force a gc run with gc.collect(), btw, but that's almost certain to make no difference -- by default it runs pretty frequently already. [01:22] Okay, a distrorelease is actually taking closer to 1.2G === Kinnison is gonna have to flush per distroarchrelease === Kinnison opens publishing.py === Kinnison tries again [01:27] b === Kinnison tries that in a window where it'll work [01:28] Kinnison: tired? :-) [01:29] annoyed with sqlobject mostly [01:29] oki [01:29] takes it ages to flush its cache and that in itself doesn't appear to have helped a great deal [01:30] In fact, regardless of how much sqlobjects there are, it really seems to hammer the cache [01:30] I.E. taking upwards of 30 CPU seconds to empty a cache of the security pocket's sources [01:30] this is bad [01:31] Kinnison: in theory adding cache=False to the connectionURI for the database should help. [01:31] that does not sound healthy indeed [01:31] spiv: how do I do that? [01:31] But that code appears to be buggy. Hmm. [01:31] txn = initZopeless( dbuser='lucille' ) [01:31] Kinnison: by abusing dbname ;) [01:31] But let's not do that. [01:32] Why would flushing the cache take so long? [01:32] unless it's not really flushing the cache and is just calling .sync() on all the objects in it [01:33] argh [01:33] that's exactly what it's doing [01:33] useless [01:34] Kinnison: try "Person._connection.cache.kw['cache'] = False" at the very start of your transaction. [01:35] (s/Person/any convenient sqlobject/ if you like) === Kinnison tries [01:35] AttributeError: 'NullCache' object has no attribute 'kw' [01:36] Hah. [01:38] very odd === Kinnison tries with _clearCache() being called instead === sfeehan [n=sfeehan@pool-64-222-103-115.burl.east.verizon.net] has joined #launchpad [01:43] Kinnison: Hmm. [01:43] Kinnison: If you're seeing a NullCache, you must be doing that too soon. [01:44] Kinnison: Are you using zopeless? with or without implicitBegin? === user__ [n=user@66.103.220.208] has joined #launchpad [01:46] Ahoy [01:46] zopeless with [01:48] Kinnison: Odd. And yet Person._connection is a NullConnection? [01:50] spiv: not entirely sure [01:50] I think .cache was a NullCache [01:50] calling SQLBase.flush_database_updates() [01:50] then SQLBase._clearCache() [01:50] then gc.collect() [01:50] keeps the RAM usage at a steady half-gig [01:50] Which is still huge. [01:50] instead of climbing into the 3.5g range [01:51] each gc.collect() is collecting ca 200,000 objects [01:51] Also, _clearCache is always called when you start a new transaction. [01:51] this is mid-transaction [01:51] Ah. [01:51] I already had some txn.commit()s in there [01:51] which reduced it from >4G==explode to 3.5G==goslow [01:52] DEBUG:Dominator:Performing domination across hoary/Release (i386) [01:52] DEBUG:Dominator:Sorting binaries... [01:52] DEBUG:Dominator:Dominating binaries... [01:52] DEBUG:Dominator:Flushing SQLObject cache. [01:52] DEBUG:Dominator:GC.Collect() [01:52] DEBUG:Dominator:Returned: 244005 [01:52] yay for sqlobject [01:52] The right answer is to set the cache=False on the Cache. [01:52] but that'll make each domination much slower [01:52] won't it? [01:52] Well, maybe. [01:52] Maybe not. [01:52] It still keeps weakrefs. [01:53] So depending on other code, it may still be able to return the objects. [01:53] And how often are your queries returning the same object, anyway? [01:53] foo.bar [01:54] But it's very weird that you're getting a NullCache, but that _clearCache works. [01:54] Because they're accessing the same attribute. [01:54] I guess try s/Person/SQLBase/ to narrow it down. [01:55] Hmm, or do an explicit txn.begin(), perhaps... === Kinnison is happy to periodically flush the cache [01:56] for now [01:56] we can look at it together in montreal [01:58] Ok. [01:58] I would like to understand what's going on here. [01:59] So I'll corner you in Montreal. [02:00] cool [02:00] in the meantime, for the first time in days, a publisher run on staging will complete === Kinnison bounces [02:00] 500MB is still huge, though. === Kinnison shrugs [02:01] We'll figure it out in Montreal... there are a couple too many mysteries here :) [02:01] aye [02:01] almost certainly all my fault === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad === asw [n=asw@karuna.med.harvard.edu] has joined #launchpad === carlos [n=carlos@gandalf.pemas.net] has joined #launchpad [02:31] Hmm, 11 minutes to do a full publishing run now [02:31] much better than before === Kinnison tries a --careful run === stub [i=stub@sweep.bur.st] has joined #launchpad [02:57] hey stubbaroony === ChanServ [ChanServ@services.] has joined #launchpad === beyond [n=beyond@200-161-81-29.dsl.telesp.net.br] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad [03:46] ciao all === poningru [n=poningru@n128-227-50-19.xlate.ufl.edu] has joined #launchpad === sfeehan [n=sfeehan@pool-64-222-103-115.burl.east.verizon.net] has joined #launchpad === [DFC] EggMan [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad === Nafallo is now known as Nafallo_away === EggMan2 [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad === robitaille [n=robitail@ubuntu/member/robitaille] has joined #launchpad === EggMan2 [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad === EggMan2 [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad === sankar [n=sankar@202.144.95.245] has joined #launchpad === feehan [n=sfeehan@pool-64-222-103-115.burl.east.verizon.net] has joined #launchpad === Burgundavia [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad === poningru [n=poningru@n128-227-50-19.xlate.ufl.edu] has joined #launchpad === auth00 [i=auth@fiji.grd.sgsnet.se] has joined #launchpad === lbm [n=lbm@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #launchpad === [DFC] EggMan [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad === [DFC] EggMan [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad === [DFC] EggMan [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad === [DFC] EggMan [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad === [DFC] EggMan [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad === [DFC] EggMan [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad === sazwerx [n=sazwerx@202.152.172.1] has joined #launchpad [10:14] stub: is production running a baz branch? that is, if i want you to cherry pick something, should i branch off the production branch? === sazwerx [n=sazwerx@202.152.172.1] has left #launchpad ["Leaving"] [10:14] BjornT: production is currently running a baz branch === sankar [n=sankar@202.144.95.245] has joined #launchpad [10:15] stub: which branch? [10:15] launchpad--production--1.38 === [DFC] EggMan [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad [10:41] stub: when adding some sample data and running make newsampledata, i get >1Mb diff... any ideas of what could be wrong? [10:42] I've seen that happen before. No idea why it does that. IIRC newsampledata is supposed to be doing some sorting to minimize that sort of stuff. [10:43] BjornT, usually it implies new fields additions [10:43] BjornT, someone added new fields but no new sampledata was added so with your export you update those tables [10:45] carlos: no, that's not it [10:46] BjornT, then there are two more options [10:46] it seems like make newsampledata decided that all tables should be in alphabetical order, which wasn't the case before [10:46] 1.- If the diff has case changes, someone did a manual addition to the sampledata (IMHO is a bad way to add it) [10:46] oh [10:46] that's new === koke [n=koke@ubuntu/member/koke] has joined #launchpad === [DFC] EggMan [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad === [DFC] EggMan [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad [11:30] carlos: hi [11:30] carlos: I've created #ubuntu-hardware, who should I contact to put this into topic line at #ubuntu [11:30] zyga, don't know, perhaps jdub [11:31] carlos: thanks, I'll try === sankar [n=sankar@202.144.95.245] has joined #launchpad === looksaus [n=looksaus@ip-83-134-126-9.dsl.scarlet.be] has joined #launchpad === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad === [DFC] EggMan [n=[DFC] Egg@pool-71-241-189-196.buff.east.verizon.net] has joined #launchpad === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:04] morning guys === looksaus [n=looksaus@ip-83-134-126-9.dsl.scarlet.be] has left #launchpad ["Looksaus] [12:35] Who here is going to UBZ flying tomorrow on BA95 from LHR->YUL 17:25 -> 19:25 ? === Kinnison thinks kamion is [01:00] stub: sent you a cherry pick request === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:06] good morning! === koke_ [n=koke@169.Red-217-127-113.staticIP.rima-tde.net] has joined #launchpad [01:09] Okay, so I have a bzr branch of launchpad [01:09] I've done some work in it [01:09] and I want to push those changes to chinstrap [01:09] how do I do that? [01:12] hi [01:13] I've sent a feature request for being able to close malone bugs via debian/changelog, but havn't heard any response yet :( - did you overlook me or is this way to hard to implement or way to low priority? [01:14] It's currently low priority I imagine [01:14] We'll certainly be looking into that though [01:14] okay. thanks for considering === gneuman [n=gneuman@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:38] Kinnison: does something like 'bzr push chinstrap:/home/warthogs/archives/$yourusername/launchpad/branch-name' work? [01:38] Kinnison: (shamelessly stolen from https://wiki.launchpad.canonical.com/MoveToBazNG) === Kinnison thinks I missed out a mkdir [01:39] ssh chinstrap mkdir -p /home/warthogs/archives/$yourusername/launchpad [01:39] ;) [01:41] aye [01:41] Kinnison: did you get it to work now? [01:42] aye [01:42] sweet === koke [n=koke@ubuntu/member/koke] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad === carlos -> lunch === beyond [n=beyond@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:42] stub: ping === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:47] lifeless: pong [02:48] stub: why did you need to use trunk? I used the rollouts stuff with jamesh successfully yesterday === Nafallo_away is now known as Nafallo === heyko [n=heyko@p54842FD7.dip.t-dialin.net] has joined #launchpad [02:50] lifeless: Mirroring branches with rsync to make branches locally === JanC [n=janc@lugwv/member/JanC] has joined #launchpad [02:53] lifeless: I was about to commit a modern refuel script that creates local mirrors of branches using rsync, allowing you to update and build trees much quicker. [02:54] stub: well, three thoughts [02:54] stub: firstly, make sure .bzr/parent is set correctly. [02:55] stub: secondly, tree *building* should be a once per developer and install activity. After that it should be pull/merge/pull --overwrite. [02:56] lifeless: I have several trees open at a time in general and find I'm building trees quite often === Virtuall[BZA] [n=virtuall@alpha.bounzza.net] has joined #launchpad [02:57] stub: so, cp -a between them - thats fully supported [02:57] lifeless: Yup. But update is painful [02:57] stub: but there should be no need for full builds, in general. [02:57] stub: update of the nested trees ? [02:58] rsynced trees seem quite servicable to me. What is the issue? [02:58] its doable, no particular issue. But you need to run revert in every tree, as I explained. in email. [02:59] also it seems ugly that rsync is needed, martin and I hope to make non rsync performance as good or better for 0.7 [03:01] lifeless: Sure. This is just a temporary measure. [03:02] lifeless: But until then building a tree remotely is just impractical [03:02] stub: note that I have not said 'dont do it' [03:02] just raised some thoughts === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [03:03] Any hints on how to use bzrlib to do a revert? [03:03] yah, look in bzrlib/builtins.py and cargo cult from cmd_revert === SteveA [n=steve@66.103.220.202] has joined #launchpad [03:04] SteveA: comign down ? [03:05] sure. have you had breakfast yet? [03:05] yes [03:05] we're starting work :) [03:05] successfully? [03:05] Ahh.... bzrlib.branch.Branch.revert might be a start [03:05] no [03:17] SteveA, coming down too === jamesh [n=james@66.103.220.207] has joined #launchpad === mdz [n=mdz@66.103.220.211] has joined #launchpad === lamont [n=lamont@mib.fc.hp.com] has joined #launchpad [03:42] hi stub. [03:42] SteveA: hi [03:42] lifeless / stub: the 'trivial, steve's spec hacks in production' email from pqm seemed to include a LOT of stuff [03:43] stub: do you know what the problem with your address and shipit is? [03:44] Too many lines, lines too long. I got it in my abusing the organization field. But the issues outlined remain. [03:45] i don't think "we're losing orders because of this" is a convincing enough argument on its own [03:45] is there a way we can ask people "are you having problems entering your address into our system?" [03:46] salgado / mpt: what do you think? [03:47] Something like "If you think ShipIt should accept addresses like this, __report this as a bug__"? [03:48] where the link automagically squirts the address into the Description field of the bug report? :-) [03:48] Oh. My main issue would be why the hell are we bending over backwards to meet the demands of a company we are pumping millions of euros through when they should be the ones meeting our requirements and asking if we would like a blow job with that? [03:50] ASCII only, no commas, very restrictive fields. I recall the encoding issues gave mako a lot of headaches, and the ascii names have already given us grief. [03:51] so the company's using CSV, huh [03:51] using *shitty* csv [03:52] We could convert commas to semicolons behind the scenes, I don't think anyone would mind [03:52] mpt, I already do that [03:52] i thought we already did that [03:52] so did I [03:52] so stub is saying, why can't the shippiing company [03:52] ok [03:52] SteveA: yes, and to add insult, pqm died after sending the email, before completing the push [03:53] whither transactions? [03:53] the failure was during sending the mail [03:54] 'mail' considered the pipe closing to be 'please send.' [03:54] ah [03:54] ascii codec, failure to encode, ordinal not in range. === heyko_ [n=heyko@p54843F30.dip.t-dialin.net] has joined #launchpad === jdub [n=jdub@home.waugh.id.au] has joined #launchpad [03:57] stub: jdub wants to hassle you [03:57] HEY STUB! === stub hides under the sofa === SteveA kicks jdub from #launchpad [03:58] SteveA said i should bug you about me being JeffWaugh2 on the wiki [03:58] screw you hippy [03:58] i'm channeling stub here === Virtuall[BZA] [n=virtuall@alpha.bounzza.net] has joined #launchpad [03:59] spiv: hello [03:59] spiv: can we talk about some minor moin integration stuff? [04:00] jdub: What do you log in as? The DB says username jdub's wikiname is JeffWaugh [04:01] lifeless: the load on chinstrap goes up to 11 [04:01] actually, it goes up to 200 [04:01] but we're being nice to it right now [04:01] but 11 is louder [04:01] And JeffWaugh2 is owned by an atavism from an account merge === ruda_porto [n=Ruda@fwcpd.ufba.br] has joined #launchpad [04:06] kiko, you slack jawed hippy, what's your launchpad ID? [04:07] kiko [04:07] stub: but on the wiki, i'm logged in as JeffWaugh2 [04:07] no, numerically [04:07] heya jdub sign my gpg key! :P [04:07] (21:00:24) stub: jdub: What do you log in as? The DB says username jdub's wikiname is JeffWaugh === Virtuall[BZA] [n=virtuall@80.233.208.92] has joined #launchpad === Keybuk [n=scott@66.103.220.198] has joined #launchpad [04:08] elmo: numerically, he wont know, its in person.id [04:09] elmo: you have db access ? [04:09] I have root, that doesn't mean I go around running SQL queries on the production DB for giggles [04:10] 1387, although I'd love to know what that is being used for apart from an internal database key? [04:10] stub: yes, in launchpad, it just says JeffWaugh. when i log in to the wiki as jeff.waugh@ubuntu.com, the wiki user is JeffWaugh2 [04:11] elmo: well, you could ask 'staging' the query, which is where stub does most of his adhoc stuff, IRRC> [04:11] jdub: That is very wierd. That email address is linked to JeffWaugh [04:11] stub: moin [04:12] elmo: oh... the perferences cache? I see. [04:13] well not so much a cache as a data store, but yeah === Virtuall[BZA] [i=virtuall@80.233.208.92] has joined #launchpad [04:13] jdub: The database is correct. I think you need to hassle spiv, or maybe those files elmo is poking in right now have the answer. [04:14] (Jeff is 6727) [04:16] uws: tsk [04:23] I think you want spiv first, as it's not obvious how id maps to name, and the code to do it is square in the middle of stuff he patched [04:23] kiko: as for yours, your account doesn't say disabled... === kiko [n=kiko@66.103.220.203] has joined #launchpad [04:25] kiko: as for yours, your account doesn't say disabled... [04:26] elmo, that's odd, but it is disabled. I can't log in at least. === GoRoDeK [n=gorodek@p5083D4D9.dip.t-dialin.net] has joined #launchpad [04:38] elmo: The file name in moin for a user should be the launchpad ID, I think. [04:39] spiv: yes, it is [04:39] spiv: I more meant the mapping of launchpad ID -> wiki User Name [04:40] Oh, right. [04:40] That's from the database -- the query stub would have done earlier would be right. [04:41] i.e. select wikiname from wikiname where person = X and wiki = 'http://whatever'; [04:42] Which gives JeffWaugh, not JeffWaugh2 [04:42] Moin asks the authserver for that info, and it does (essentially) that query. === spiv tries querying the authserver directly. === lbm [n=lbm@x1-6-00-13-10-7a-d1-e4.k233.webspeed.dk] has joined #launchpad [04:43] The authserver says jeff.waugh@ubuntu.com has a wikiname of JeffWaugh. [04:44] spiv, mine is ChristianReis, right? [04:45] kiko: right [04:46] Who's lalo@canonical.com? [04:46] mpt, someone who used to work with us [04:46] jdub: https://wiki.ubuntu.com/JeffWaugh?action=info shows "JeffWaugh" in the edit history. [04:47] jdub: Where are you seeing the string JeffWaugh2? [04:47] They're the ancestor of all my branches [04:47] spiv: moin [04:47] oh, hold on [04:47] jdub: Be more specific, please :P [04:47] mpt, have you asked lifeless? [04:47] kiko, it seems to be working fine, I was just wondering [04:48] spiv: yeah, sec :) [04:48] spiv: hrm, i'll bug you when i see it === jdub [n=jdub@home.waugh.id.au] has left #launchpad [] [04:49] Heh. [04:49] mpt, sounds like a bug to me but.. [04:50] I'll just assume that means jdub can't reproduce his problem ;) [04:50] ok, lifeless: ping [04:51] I can however, spiv :) [04:51] kiko: Does that mean you have a URL for me? :) [04:53] mpt: Lalo Martins? [05:00] spiv: pending-reviews/ doesn't currently URL-decode the %2F in your branch name [05:01] jamesh: I wondered about that... I couldn't remember if the @ confused it or not. [05:02] jamesh: Although, %2f is slightly more correct, isn't it? [05:04] spiv: the '@' did confuse it at one point, but doesn't now [05:07] spiv, well, I can' t log in to the wiki, period. [05:07] spiv: if you're done with your baz branches, you can move the contents of the andrew.bennetts@canonical.com/ directory up one level too [05:07] kiko: do you get an error? [05:08] kiko: Using your launchpad login? [05:08] spiv, yep [05:08] (i.e. logging in as "kiko" not "ChristianReis") [05:08] (or with your email address) [05:08] spiv, as kiko@async.com.br [05:09] That should work. [05:09] Do you have access to macquarie? [05:09] spiv, I /think/ I once clicked on "disable my account forever" because a user had done it and I wanted to reproduce [05:09] spiv, no, I don't [05:09] Oh. [05:09] and in fact I lost it forever [05:09] Heh. [05:10] kiko: create a new launchpad account, merge your existing one into it, and use that ... [05:10] That option probably needs to die. [05:10] that'll get a new user ID [05:10] no [05:10] no? [05:11] that option should be nuked AND all disabled accounts should be reenabled [05:11] kiko: re-enabling that needs elmo or someone else with direct access to wiki files. === spiv looks at disabling disabling. [05:11] spiv, elmo is a step away from me [05:12] it's not disabled [05:12] but he apparently said that my account isn' t disabled [05:12] right [05:12] kiko: he might have been looking at your pre-launchpad user ID [05:13] elmo: you checked file 1387? [05:14] root@palmer:/srv/wiki.launchpad.canonical.com/www/data/user # grep disabled 1387 [05:14] disabled=0 [05:14] Hmm. [05:14] hmmm [05:15] hey stub, did you get my email? [05:15] kiko: Hmm. [05:15] eh? [05:17] stub, the one I sent yesterday, on gina? [05:17] kiko: On chinstrap, could you fire up a python prompt, and do: >>> import xmlrpclib; s = xmlrpclib.Server('http://macquarie:8999/v2'); print s.authUser('kiko@async.com.br', 'xxx') [05:17] i rolled out a patch of yours on staging and fired off a gina run [05:17] kiko: Only, with your actual password ;) [05:17] And tell me if it returns an empty dictionary or not. [05:18] stub, you /rock/ [05:18] whee [05:18] spiv, let me try. [05:19] spiv, it returns my data correctly. [05:19] {'wikiname': 'ChristianReis', 'emailaddresses': ['kiko@async.com.br', 'kiko@canonical.com'] , 'displayname': 'Christian Reis', 'id': 1387, 'teams': [{'displayname': 'Ubuntu Drivers', 'id': 322877, 'name': 'ubuntu-drivers'}, {'displayname': 'Christian Reis', 'id': 1387, 'name': 'kiko'}, {'displayname': 'Launchpad Developers', 'id': 15158, 'name': 'launchpad'}, {'displayname': 'Launchpad Administrators', 'id': 2794, 'name': 'admins'}, {'displayname': 'ShipIt [05:19] Administrators', 'id': 243601, 'name': 'shipit-admins'}] } [05:19] Ok, so the authserver end is working just fine. [05:19] So the problem must be in moin somewhere. [05:20] yeah, I knew it was because I can log in to any other wiki [05:21] I think the issue is related to what I suggested before [05:21] but.. I don't know for sure. [05:21] Weird. === mfuentes [n=mario@200.54.6.230] has joined #launchpad [05:21] I didn't realise it was just the one moin. That's doubly weird. [05:21] elmo: maybe diff kiko's moin user file from a working wiki? [05:21] kiko: You're seeing "Sorry, wrong password", or something else? [05:22] Sorry, wrong password. [05:23] elmo: is there a "valid=0" in kiko's user file? (there should be no valid=foo line at all, but who knows...) === matsubara is now known as matsubara-lunch [05:29] spiv: no, valid=0, and diff to a random other ID looks sane [05:29] http://people.ubuntu.com/~james/tmp/1387 [05:30] elmo: thanks [05:31] Yeah, certainly looks sane. [05:31] kiko: I've got *no* idea. Must be a browser bug ;) [05:31] The user code in moin is pretty horrible, but I can't see how it's horrible enough to muck that up. [05:32] spiv, you are very funny [05:32] Well, it is considerably past my bedtime :) [05:32] kiko: maybe you shouldn't have logged out forever [05:36] jamesh, maybe not. I was trying to help verify a problem a user reported. [05:37] Anyway, the patch to remove that option should be a simple one-liner (delete the obvious line from MoinMoin/user.py:User._checkbox_fields), but I'm not going to trust my testing of that at this time of night. === yi [i=yi@rollright.bmsc.washington.edu] has left #launchpad [] [05:43] SteveA: ping [05:43] SteveA: can we get the lp test runner to not buffer everything until the end ? [05:44] SteveA: for pqm. === Kinnison nods [05:47] my merge was "Terminated" [05:47] I assume by pqm [05:47] I dont know what that means [05:48] Well, I sent off a merge [05:48] it failed [05:48] lifeless: the point of that originally was to give no output on success, and only output on failure, because the test suite was too darn noisy. [05:48] now it is much less noisy [05:48] The end of the log was : [05:48] make: *** [check_merge] Terminated === Kinnison assumed that was pqm [05:48] oh, I stomped on a merge [05:49] there was a bug I needed to correct that would have cuased a later failure. [05:49] Oh === Kinnison resubmits then === Kinnison discovered that sshing into chinstrap and cp'ing the rocketfuel tree is a good way to start a branch [05:50] stub, where are the logs going? [05:50] kiko: Same place as always [05:50] certainly speeds up the subsequent push [05:50] Kinnison: read the MoveToBazNG page [05:50] ...hmm, my Karma has been stuck on 69 for ages [05:50] why do I think someone's hardcoded that [05:50] stub, /srv... right? [05:50] lifeless: erm, perdon? [05:51] Kinnison: its documented [05:51] oh right [05:51] Kinnison: no reason, no reason at all [05:51] /srv/launchpad.ubuntu.com/gina-logs [05:51] LarstiQ: whowhat?! [05:52] argh [05:52]