=== lalo [~lalo@200-102-142-102.paemt7013.dsl.brasiltelecom.net.br] has joined #launchpad === lifeless_ [~robertc@dsl-66.7.240.220.rns01-kent-syd.dsl.comindico.com.au] has joined #launchpad === lifeless_ is now known as lifeless === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === wartylog [~warthylog@port1845.ds1-khk.adsl.cybercity.dk] has joined #launchpad === Topic for #launchpad: Ok, found it. I wonder who changed that. spiv, you merged that in? === Topic (#launchpad): set by kiko at Tue Sep 21 20:51:14 2004 === stu1 [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === cprov [~cprov@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === BradB|London [~bradb@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === carlos_ [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad [10:27] morning === carlos_ is now known as carlos === limi [~limi@193.71.38.142] has joined #launchpad === debonzi [~debonzi@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === limi shakes up the room a bit [11:36] hiya! [11:36] limi: Viking, you working on Rosetta UI today? [11:36] yup [11:37] excellent :o) [11:37] spiv: ping [11:37] lulu, limi: hey [11:37] carlos :) [11:37] carlos: howzit! [11:38] fine, thanks === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad [11:51] stub: hi, have you seen my DB request on LP list ? [11:52] did we have a sqlobject change that I'm not aware of? [11:53] Traceback (most recent call last): [11:53] File "./poimport.py", line 99, in ? [11:53] options.potemplate, options.language) [11:53] File "./poimport.py", line 30, in imports [11:53] project = DBProjects()[projectName] [11:53] File "/home/carlos/Work/dists/launchpad/lib/canonical/database/doap.py", line 60, in __getitem__ [11:53] return ret[0] [11:53] File "/home/carlos/Work/dists/launchpad/lib/sqlobject/main.py", line 1194, in __getitem__ [11:53] return list(self.clone(start=start, end=start+1))[0] [11:53] File "/home/carlos/Work/dists/launchpad/lib/sqlobject/main.py", line 1198, in __iter__ [11:53] carlos: pong [11:53] return conn.iterSelect(self) [11:53] File "/home/carlos/Work/dists/launchpad/lib/sqlobject/dbconnection.py", line 507, in iterSelect [11:53] select, keepConnection=True)) [11:53] TypeError: iteration over non-sequence [11:53] spiv: the traceback :-) [11:53] that script was working this weekend [11:54] carlos: Did you grab the new SQLObject that lifeless merged in? [11:54] Oh, this is a script taht lalo changed? [11:54] spiv: Is in a new branch? [11:54] Yeah. [11:54] hmm [11:54] dists does not reflects it [11:55] carlos: It's not ready yet. [11:55] It was a question, not a suggestion :) [11:55] See lalo's post to the list. [11:55] He fixed the transaction handling in that script, but it depends on bugfixes in SQLObject. [11:55] spiv: I did a normal update of the old branch [11:55] ok === limi does the arch patch dance [11:55] so [11:55] We'll shortly have them merged in from upstream thanks to lifeless. [11:55] What should I do? [11:55] :-) [11:56] Or use lalo's branch. [11:56] See lalo's email :) [11:56] move to the other branch? [11:56] spiv: I saw it but I didn't know that rocketfuel was updated to do that [11:56] I'd use lalo's sqlobject branch until lifeless announces that the SQLObject 0.6 merge is ready -- we're still finalising which fixes we need to keep :) [11:57] ok === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === limi is still amazed at how long it takes to merge changes from arch [12:11] limi: Do you have a greedy sparse revlib/ [12:11] ? [12:11] I believe so [12:12] it's fast at some things, and slow at others [12:12] was there something I had to watch out for with regards to sqlos? [12:12] or sqlobject [12:14] limi: It is so much faster under Ubuntu - I don't think arch is at all usable except under certain Unix flavours, and OSX is unfortunately on that borderline. [12:15] Yeah, it's been painfully slow for bradb on OS X too. [12:16] well, installing ubuntu on this thing isn't trivial [12:16] It doesn't help when arch decides to some operations twice for no good reason. [12:26] cprov: ping [12:27] limi: it's a 15" pb, right?, the "only" big problem should be the airport extreme [12:28] no, the big problem is that I can't wipe my current install [12:28] oh, and the airport doesn't work? that's a no-go then, as I only have wireless at home and in the office [12:28] stub: pong [12:29] limi: airport extreme is an unsupported device under Linux, Broadcom does not give us anything to implement a driver [12:29] cprov: Your database changes are in [12:31] arch peeve of the day: if I mistype my GPG passphrase into gnome-gpg while committing, the commit fails and I have to work out which revision it has just locked, run tla lock-revision -b and do the commit again [12:31] stub: thanks, But i'm doing the deb importer tool and will work with it just at evening, anyway thank you very much :) [12:31] Bug 2035 resolved: PO parser broken (again) [12:49] $ make launchpad_test [12:49] make: *** No rule to make target `launchpad_test'. Stop. [12:50] has the command to rebuild the database changed? [12:51] daf? :) [12:51] yep [12:51] limi: you only need to execute "make" [12:51] carlos: yes? [12:51] inside database/schema [12:51] daf: yes [12:52] oh, right [12:52] make base if you don't want the sample data [12:52] or "make -C database/schema" [12:52] daf: :-) [12:52] from the Launchpad root [12:52] ok [12:52] thanks [12:52] yummy: [12:52] $ make [12:52] * launchpad-2-00-0.sql is corrupt or has been modified [12:52] make: *** [check] Error 1 [12:53] bin/sh: line 1: md5sum: command not found [12:53] limi: Heh. [12:53] limi: you need to install that command from fink (I'm not 100% sure) [12:54] why the paranoia? [12:54] darwinports doesn't seem to have it [12:54] and I don't have Fink on this box [12:55] limi: do you have Apple's development tools installed? I think they should have it there (or in their normal system) [12:55] yes I do, and no they don't ;) === limi goes for lunch and will deal with it afterwards [12:56] ok [12:56] limi: later [12:56] daf: hey, the .po file import takes only 5 minutes in my computer!! [12:58] carlos: cool! [12:58] carlos: with which changes? [12:59] daf: none from my part, only a star-merge [12:59] and the bug I found last week is fixed also [12:59] lalo's changes probably helped... it was apparently doing a commit after every sql statement (via sqlobject's autoCommit feature) [12:59] oh, right [12:59] uggghghgh [01:00] See his email to launchpad for details. [01:02] no wonder it was so slow === limi is now known as limi|lunch [01:03] spiv: so Lalo's changes depend on SQLObject 0.6, but it looks like that's going to get synced in soonish, right? [01:05] daf: sqlobject has been imported, but lifeless still needs to merge back our local mods (native datetime & Unicode, and maybe another SteveA made before I started) [01:07] daf: Yeah, or, use lalo's branch in the meantime. [01:08] ok === cprov [~cprov@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === limi|lunch is now known as limi [01:48] shower time.. === carlos away [02:21] Bug 2044 resolved: Rosetta should at the LEAST know about browser languages [02:27] New bug 2045 for Launchpad/Launchpad: Debug skin & authentication don't mix [02:29] heh, the first link I click on in Rosetta gives me an error [02:29] Module canonical.metazcml, line 148, in publishTraverse [02:29] traversed_to = getattr(self.context, self._getter)(name) [02:29] Module canonical.rosetta.domain, line 27, in product [02:29] for p in self.context.rosettaProducts(): [02:29] AttributeError: 'SoyuzProject' object has no attribute 'rosettaProducts' [02:30] http://localhost:8085/++skin++Debug/rosetta/projects/gnome/gnome-panel [02:30] and when searching: [02:30] AttributeError: 'Projects' object has no attribute 'search [02:30] daf: am I missing something here? [02:32] I think somebody broke something :) [02:32] Hmm, that's probably related to stuff I've been doing. [02:32] I'll take a look now. [02:32] thanks === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [02:38] Is the python reference guide installed with Ubuntu anywhere? === stub can't find it === cprov [~cprov@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad [03:27] spiv: any progress? [03:29] spiv: we're still scratching our heads over it [03:29] um [03:29] limi: that was for you [03:29] ok [03:29] so it isn't working for you guys either? [03:29] nope [03:44] limi: ok, we've found the bug [03:45] great [03:45] (and the fix :)) [03:48] limi: I'm mirrioringlimi: I'm imirrioring etc the fix now. [03:49] quite efficient mirroring you have there ;) [03:52] Heh === jblack [~jblack@mercury.merconline.com] has joined #launchpad [04:45] hi [04:45] so, I submitted a merge to pqm [04:45] and it looks like it is spinning in tla on chinstrap [04:45] huh. interesting. [04:45] run top to see [04:45] Yeah. I see it [04:46] so, we have james troup here [04:46] we have coders here who would like to keep sprinting [04:46] elmo: can you strace it for me please? [04:46] and I'm worried I have a broken tree [04:46] or a broken whatever [04:47] limi: PQM is broken, so perhaps you should apply the fix locally so you can get some work done :) [04:47] ouch [04:47] what is the fix? [04:47] limi: First, to figure out why tla's in a loop. [04:48] because it sucks, obviously [04:48] :] [04:48] Heh. [04:49] be nice to me. This is my day off. ;) [04:49] limi: delete a few lines from a ZCML file [04:49] limi: I can privmsg the patch to you [04:49] It's short :) [04:49] jblack: I'm being mean to Tom Lord, not you ;) [04:49] Oh, in that case, cheerio. [04:49] hehe [04:49] elmo: Ping [04:49] spiv: please do [04:50] Ok. [04:50] jblack: elmo was pingged [04:50] sorry. I thought you said he was here [04:51] he is [04:51] well... [04:51] jblack: He's a popular guy [04:51] he's talking right now with someone [04:51] Like yourself ;) [04:51] argh === elmo_ [~james@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [04:51] elmo: there's a tla binary running on cs thats in a tight loop. can you use your super awsome powers of root to strace it for me please, and see what sort of syscalls its making? [04:51] this needs to be #lunchpad [04:52] #lynchpad [04:52] #punchlad [04:53] #lynchtlapad [04:53] so, like is there likely to be anything sensitive in this trace? === jblack tries to remember the program that shows what files a binary has open [04:53] lsof [04:53] (gpg stuff, passwords) === cprov [~cprov@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [04:54] elmo_: we'll give you a list of passwords that you can grep out of the trace [04:54] Oh, no. [04:57] /home/james/steves-password === SteveA reads the trace [05:00] what are the two involved FQVNs, btw? [05:01] Which exception should be raised when we get an error that it's because the database was not populated with the default data? (it's something that should always be there) [05:01] jblack: I don't know. I just run "submit arch merge" [05:01] I can tell you my tree version, though [05:02] you can get the code from my mirror on steve.alexander@canonical.com [05:02] stevea: I've got yours. [05:02] I don't know where pqm thinks its archive is, or what revision its merging into though. .arch-params is locked down. [05:03] RuntimeError? [05:03] can you give elmo a harmless command to run to find out? [05:03] yeah... [05:03] in one of your working copies, type a tla logs --merges, and see if you can pick out a line referring to rocketfuel@canonical.com--2004/???-???-??? [05:04] I'd grep it if I were you. it'll probably be noisy [05:05] jblack: who do you want to do that ? [05:05] I don't think rf uses a --2004 on the end [05:05] I'll do it. I have access to your archive. [05:06] cool [05:07] [05:07] (speechless) [05:11] jblack: any ideas so far? === debonzi [~debonzi@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [05:11] not yet. I'm mirroing the archives onto my machine so that I can see if the merge breaks here. === SteveA waits for jblack to say "merging..." and then quit unexpectedly [05:17] stevea: is that systrace ok? [05:17] that would really help a lot. that'll tell me what the programs up to [05:18] the systrace is in ~james/steves-password [05:18] that was a joke from james [05:18] I'll punch him for you [05:25] You had done soyuz changes, correct? [05:27] Steve says he made changes in launchpad's lib/canonical [05:27] But not in lib/canonical/soyuz [05:29] Ok. I'll look at launchpad first. [05:29] I saw some ENOENTS for soyuz patches. [05:30] Oh, you mean the soyuz category? [05:30] We haven't used that for a couple of months now. [05:31] But -- it got tagged into launchpad at some point in its history. [05:31] (I might have my terminology slightly confused) === jblack hums a noisless tune as he gets both seves lp and rf's lp at the same time. [05:32] ps says the offending tla process's command line was tla star-merge steve.alexander@canonical.com/launchpad--devel--0 [05:32] s/was/is/ ;) [05:33] Yeah. I got tricked because of the earlier patchlogs. [05:36] I'm up to 50 and 369 [05:40] 411 [05:43] Ok. it was trying to take your 54-57. lets delta those [05:45] I don't see anything offhand that looks weird. [05:45] and whats more, I can perform the star-merge here. [05:47] steve, I don't know what's wrong. [05:48] I can perform the star merge that pqm's trying right here, without a problem. Even using the same binary off of cs [05:50] so your problem is definitely (checks BOFH book) cosmic rays [05:53] ok [05:53] I'll ask mark to order more lead for the machine room [05:53] in the meantime, do we keep it running to point lifeless at? [05:53] or do we kill it? [05:53] or what? [05:53] I say we take a core dump of it, and email to lifeless ;) [05:56] I'd um... [05:57] Yeah. do that. [05:57] I don't know how much good it'll do him, as the binary is stripped. === Keybuk [scott@descent.netsplit.com] has joined #launchpad === Keybuk prods random people === jblack randomly ouches [05:58] You could try hitting keybuck up. he's pretty smart. [05:58] keybuk: your favorite tool is acting up on chinstrap. [05:58] I'm shocked :p [05:59] the star-merge performs just fine on my machine, but on cs its gone crazy. [05:59] doesn't chinstrap run a jurassic version of tla? [05:59] Actually, no. [05:59] 1.2.1 [06:00] ah ok [06:00] besides. I thought of that. I even copied over cs's binary to my machine and gave it a whirl. no problem [06:01] While I could be more help to you, Steve, but with it working just fine here... [06:03] Bug 1915 resolved: Release the Alpha version of Rosetta [06:03] jblack: I was just thinking that the 500Mb of core dump would get his attention ;) [06:04] well, if tla runs long enough, that will happen. [06:04] there's probably a couple memleaks in there. [06:04] jblack: 7131 pqm 18 0 670m 670m 864 R 68.1 18.6 166:03.00 tla [06:04] Oh. Its still growing. [06:04] Yeah. Kill it. [06:04] It was under 500 when I first looked :) [06:05] OMFG [06:05] :) [06:05] "a few memory leaks" [06:05] heh [06:05] limi: they're very small ones. [06:05] when tla runs normally, it probably leaks all of 500 bytes. [06:06] I want someone to attach gdb to tla on chinstrap... [06:06] so, what's 670M / 500B? [06:06] but then again, it is stripped [06:06] arse, why is it stripped? [06:06] but if it gets stuck in a loop for a zillion loops, it can add up [06:06] stevea: you may not even get a core at all. depends on the ulimit [06:06] SteveA: things are stripped as a rule [06:06] jblack: don't want a core. want to attach gdb to the process [06:07] limi: how's it going? [06:07] you won't ge that without symbols, I'm afraid. [06:07] limi: did you manage to get Launchpad running again? [06:07] daf: good, routing around arch here for the moment, doing JS work [06:07] daf: let me quickly apply the patch spiv sent me [06:07] limi: great! [06:08] Sorry I couldn't be mroe help. is there something else I can do for you? [06:08] jblack: indeed. why is experimental code stripped? ;-) === SteveA wonders when lifeless will wake up [06:09] tla-1.2 isn't experimental. [06:09] lifeless went to be about.... [06:09] dude, tla is experimental ;-) [06:09] 3 hours ago\ [06:09] if it got installed from a Debian package, there's your answer [06:09] jblack: this broke about 3 hours ago ;) [06:09] ooh [06:11] btw, you guys will like the new tla help [06:12] is it shorter? [06:12] Oh yeah. [06:12] its broken up into categories. [06:12] is it an info style hypertext application written in a variant of scheme? [06:12] cool [06:13] nah. scheme wasn't quite right. we went with prolog this time. [06:13] yes [06:13] :D [06:13] we're using a tla from rob [06:14] have a look in my home dir, I guess [06:14] elmo: Not according to the release id? [06:14] Oh. pqm might have a different path. I didn't think of that [06:14] What's /proc/7131/exe ? [06:15] tla_1.2.2-1integration1_i386.deb [06:15] lrwxrwxrwx 1 pqm warthogs 0 Sep 28 17:15 /proc/7131/exe -> /usr/bin/tla [06:15] jblack: Hmm, you said you copied and tried that binary? [06:15] Yeah. thats the one I did [06:16] that says its 1.2.1 === Keybuk [scott@descent.netsplit.com] has left #launchpad ["Leaving"] [06:16] whatever it says, it has the same sha1sum as the binary in the .deb in my homedir [06:16] *the 1.2.1 that Tom released, not the one I released. [06:22] ok. I'm gone. [06:22] Unless there's something diffreent you guys need. for this one though, you'll need robert to get any further. [06:23] Well, I can run that star-merge in my account on rocketfuel without trouble... [06:23] yeah. same thing for me. [06:24] that was the firght thing I thought of trying. [06:24] Ah :) [06:24] jblack: Is there anything we should preserve to help robert debug this? [06:24] if that had worked, then i could have built a binary with debugging symbols, and walked the code. [06:25] I'd keep the systrace. [06:25] and if it throws core, keep it for the heck of it, though i don't think it'll do any good. [06:25] i.e. if we kill tla, maybe break a revision lock if that's needed, but otherwise get pqm going again, does that sound ok? [06:25] Oh, and um.... maybe one more thing. lemme look [06:25] Yeah. [06:25] tla will break safely. [06:25] (and what do we need to do to get pqm going again? :) [06:26] That, I'm not sure of. [06:26] I guess the pqm process will notice if tla dies... [06:26] this is my third or fourth encounter with pqm. [06:26] Fair enough :) [06:27] tla itself will be fine, other than a revision lock that you'll have to break. [06:27] the cruft that tla will leave behind should be harmless. [06:27] but if pqm isn't (or in this case can't) cleaning up after itself... [06:27] Ok. tla lock-revision -b rocketfuel@canonical.com/launchpad--devel--0--patch-434 I guess? [06:28] that should be right. [06:28] I'll make robert give me some time this week so that the next time this happens I can clean up the mess. [06:29] elmo_: Would you mind killing that tla process, and possibly running that tla command, so that we can use pqm again? [06:29] Or kill -STOP? [06:29] well, hold on. [06:29] don't break the lock if you're going to -STOP it. [06:30] jblack: Hmm, good point... [06:30] Ok, how about we kill -STOP it until lifeless sorts it out? [06:31] otherwise, when Robert CONTs it... [06:31] that would be safe. [06:31] so I shouldn't be doing any checkins right now? [06:31] And otherwise leave it alone... presumably lifeless will have pqm going again by our tomorrow morning :) [06:32] limi: Would that be possible without interfering with you guys' work too much? [06:32] no problem [06:32] limi: you can commit, but not merge [06:32] I work locally [06:32] limi: Well, pqm is busily spinning on a merge request from Steve... you're welcome to send your own merges, I guess, but they're not goign to be dealt with immediately :) [06:33] Our personal archives aren't affected. [06:33] I don't get it. I've barely left the house in two weeks, and I'm sick. [06:33] jblack: Lack of exercise, then ;) [06:33] jblack: maybe it's *because* you haven't left the house :) [06:33] nonsense. to catch a virus, you have to catch it from somebody. [06:34] or some*thing* :) [06:34] Probably nocturnal alien visitations. [06:34] no frigging fair. Its my day off, I get paid, and I come down with a cold. [06:34] I must have ripped the wings off of butterflies in my previous life. :) [06:35] Ok. Take care guys. [06:35] jblack: thanks [06:35] jblack: Thanks [06:36] jblack: thanks :) [06:36] jblack: thanks! [06:37] daf: btw, the patch worked, so I have a local copy that works now [06:37] limi: groovy [06:38] limi: if you commit, take care not to commit that fix along with your changes [06:44] I will let you know when the time comes ;) [06:45] daf: is there any sort of login thing in place now? I get: [06:45] Module zope.app.publication.browser, line 53, in getDefaultTraversal [06:45] return ob.browserDefault(request) [06:45] Unauthorized: ('browserDefault', 'launchpad.AnyPerson') [06:45] limi: in theory, you get a HTTP authentication box when you need it [06:46] limi: there is a login link on the font page [06:46] aha === limi goes to the font page [06:47] doesn't work with debug skin? [06:48] ah, right, yeah [06:48] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2045 [06:49] ;) [06:49] daf: what is the user/password we use? [06:49] locally, that is [06:50] foo.bar@canonical.com/test [06:50] wordy :) [06:51] all usernames are email addresses at the moment [06:51] yup [06:51] is there any way we can say "logged in as"? [06:51] yeah! [06:51] good idea! [06:51] ;) [06:52]