[12:05] I don't see why uploading would be difficult -- it's a simple post to a form [12:05] there are actually third-party tools that post for you IIRC [12:06] It's a simple post to form for a tarball or do I have to post each po file? [12:06] Oh, third party tools is cool. [12:06] you can do either [12:06] I do like the interface. [12:06] tarball or pofiles [12:06] Oh, posting a tarball wouldn't be so bad. [12:06] we've got an XMLRPC UI that makes things slightly more convenient [12:06] err [12:07] a planned XMLRPC UI [12:07] but in your case the main issue is really automating downloads. [12:07] That's just downloading a tarball and expanding it, right? [12:07] correct. [12:07] Do you guys support individuals downloading and uploading po files so they can do their processing locally? === fabbione [n=fabbione@george.kkhotels.co.uk] has joined #launchpad [12:07] sure [12:08] that's one of the workflows rosetta supports [12:08] And then it intgrates with what's there? Cool. [12:08] yes [12:08] you also get to control who decides which translations are official [12:08] Your UI is the nicest looking one I've seen. [12:08] so you can have a trusted group of translators [12:08] and then community translators can add suggestions for their posterior review [12:08] Yeah, I saw that. Very neat. [12:08] thanks, it's been a lot of work to get there. [12:09] Actually, we could totally make it so that editing the po files from svn wasn't an option. If you want to edit a po file, you have to get it from rosetta and submit it there. [12:09] there are already some products that use that policy [12:10] I noticed there are suggestion areas. If you're an official translator, do you get a checkbox you can mark so you don't have to copy it? [12:10] jordi's the best guy to tell you because he is community ninja [12:10] clahey, not yet, but there's a patch that does it -- there are some UI concerns with the way the form works that makes it a non-straightforward decision, but we will have an expedited review UI [12:11] carlos is working on a change which allows you to zoom into specific strings and see their history, and all suggestions [12:11] next steps from there are allowing for ajax-style navigation, and also for allowing one-click accepts [12:17] kiko! [12:17] oh-oh, what did I say! [12:18] kiko, don't worry, you're not in *that* much trouble [12:18] kiko: Cool. We'll discuss it here. Rosetta looks awesome. [12:18] clahey, great to hear. be sure to let me know if you need anything. === benzai [n=zaheda@82-71-18-29.dsl.in-addr.zen.co.uk] has joined #launchpad === sabdf1 [n=mark@host217-37-231-22.in-addr.btopenworld.com] has joined #launchpad === fabbione [n=fabbione@george.kkhotels.co.uk] has joined #launchpad [12:39] wtf is up with pqm [12:39] ah I know [12:39] it must be that lifeless is on a plane. [12:41] dudes, how do I see translations by a specific person ? === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [12:42] sivang: /people/$person/+translations i think === sivang checks [12:42] sivang, you can't easily today. and +translations is rife with timeouts and it only indicates templates not actual translations [12:43] yes, that is what I see now [12:43] https://launchpad.net/people/nir78/+translations [12:43] when I click a template, I see alist of people that translated there [12:44] so we currently have no way to evaluate membership of people to translation teams... [12:44] I kept sending them to do work on the Hebrew wiki, some of them did, some prefer to work through rosetta [12:44] :-) === sivang tries to think a way to evalute. [12:45] how can I see then propsed translations? [12:45] (by a specific person) [12:45] sivang, ask them which translations they contributed to? [12:45] I did, they did not respond. I will re-ask [12:45] I mean, they told me "review my work on launchpad" [12:46] tell them "yes, launchpad is as big as africa, so where? " [12:46] hehe [12:46] at least you don't get parasites like when you dip in african water :) [12:46] that's a rumor [12:46] I have dipped and sipped from african water [12:47] I only got friendly parasites [12:47] and you don't have any hitch hiker with you? :) [12:47] I prefer to call them friends [12:47] some girl from here that went there, was digged a bite fly's cocon from her forehead. gross! [12:48] anyway, back to happy things :) [12:48] I got one of those in california [12:48] serious? [12:49] yeah. parasites exist even in developed countries! [12:51] Well, sure, but not in the same quantities probably. anyway, how was it removed eventually? [12:52] and what are those so called friend you say you dragged with you from their comfortable home on Africa? :) [12:52] bye guys, me-> London === sivang emailed the dude to send specific links of his translation suggestions. [12:52] lifeless: easy flight! === sivang goes to read about pagetests finally === sabdf1 [n=mark@host217-37-231-22.in-addr.btopenworld.com] has left #launchpad [] [01:15] kiko: do you have an idea if the pre-knits rocketfuel-get scripts are still applicable? or should I just use the instructions in RocketfuelToKnits, I don't have any branch I need to keep or so. [01:27] hmm, bzr upgrade takes a while over my checkout branch [01:27] and the disk howls [01:49] hrm, still converting === steph [i=steph@stargate-server.com] has joined #launchpad === sivang [i=sivan@muse.19inch.net] has joined #launchpad [02:08] I hate sever drop off [02:08] server, even === sivang wonders when bzr upgrade will finish === ksweeney [n=ksweeney@72-255-3-25.client.stsn.net] has joined #launchpad [03:04] Gooooooooooooooooooood afternoon Launchpadders! === stub [n=stub@ppp-58.8.7.88.revip2.asianet.co.th] has joined #launchpad === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad [04:41] who's responsible for bzrsyncd on gandwana? === BehemothNet60137 [n=gigawatt@adsl-69-208-101-32.dsl.chcgil.ameritech.net] has joined #launchpad [04:53] question === BehemothNet60137 is now known as Gigawatts [04:54] i have now done the beginning of the registration process to ship ubuntu cd's twice [04:55] and i never recieve an email [04:55] and i know the email address is correct [05:10] spiv / jamesh / lifeless, skype call to discuss the next stage of MaloneSimplifications? [05:11] hmmm, spiv and lifeless aren't here [05:11] mpt: sure. [05:12] brb === mpt [n=mpt@203.109.220.214] has joined #launchpad [05:36] Gigawatts: Could it be that you or your ISP think it is spam and are dropping it? [05:36] I can give you a gmail invite if you want to test with another account [05:47] jamesh, "The reviewer must send in a small summary of the call (no more than a paragraph or so) including the time the call took to the lp-reviews list" [05:49] mpt: thanks [05:52] argh [05:53] stub, ETA for fixing login on staging? [05:53] mpt: Today if I can get my damn branch to land (broken behavior was being relied on by a load of our tests, so fallout :-() [05:53] mpt: Actually, I can do a quick fix. Hang on... [05:55] mpt: Ok - that should fix it (the same way that production happens to be working fine with this bug) [05:56] Logging into staging will probably kill your production session information though so don't try and use both at the same time [05:56] or it might work... dunno [05:58] thanks stub === stub wonders htf he can control his music volume seperately to his gaim alert volume [06:06] mpt: sorry, was at lunch === frodon_ido [n=patrick@ip-213-49-171-219.dsl.scarlet.be] has joined #launchpad [06:38] opps, sorry, was away for awhile [06:38] stub, i checked my spam box, and nothing [06:39] it was a hotmail account [06:39] so i dont see a reason for it to not work, although i could try my gmail account also, see if that fixes it === benzai [n=zaheda@82-71-18-29.dsl.in-addr.zen.co.uk] has joined #launchpad [06:57] ok, well it worked instantly with gmail, wierd [06:57] wonder why it doesnt work with hotmail? [07:08] Maybe it is just taking time, maybe they are dropping the email outright rather than putting it into your spam folder. No idea. [07:08] ok, well thankyou, and you might want to investigate why the emails arent going through to hotmail accounts [07:08] adios! === mpt_ [n=mpt@203.109.220.214] has joined #launchpad === dsas [n=dean@host86-128-52-181.range86-128.btcentralplus.com] has joined #launchpad === mpt__ [n=mpt@203.109.220.214] has joined #launchpad [08:20] morning === mpt_ [n=mpt@203.109.220.214] has joined #launchpad [08:36] need a launchpad guru again === benzai [n=zaheda@82-71-18-29.dsl.in-addr.zen.co.uk] has left #launchpad [] === fabbione [n=fabbione@george.kkhotels.co.uk] has joined #launchpad [08:56] hi troy_s. what's up? === mpt_ sighs [09:13] Whenever I try to merge two of our overly-granular pages I disappear into a maze of classes and interfaces === latenight [n=pietern@196-47-18-33.access.uunet.co.za] has joined #launchpad [09:16] Welcome to Zope3! [09:16] ============ [09:16] You are in a maze of classes and interfaces, all alike. [09:19] > kill metaclass === spiv -> yoga === malcc [n=malcolm@host81-159-193-176.range81-159.btcentralplus.com] has joined #launchpad === fabbione [n=fabbione@217.205.109.249] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === carlos [n=carlos@13.Red-88-15-198.dynamicIP.rima-tde.net] has joined #launchpad [09:54] morning === tambaqui [n=tambaqui@200.231.107.64] has left #launchpad [] === benzai [n=zaheda@82-71-18-29.dsl.in-addr.zen.co.uk] has joined #launchpad === benzai [n=zaheda@82-71-18-29.dsl.in-addr.zen.co.uk] has left #launchpad [] [10:09] morning all [10:12] does anyone know if bzr upgrade --format=knit of a -built tree should never finish on a 1.8G laptop with 1G ram ? I left it over night to do so, seeing now it still did not finish. It basically brought the machine to a complete halt, and I had to switch to a VT to kill gdm an drestart it. (that was my only way out since X/GNOME were unresponsive) [10:12] I did so since I wanted to workaround having to re-checkout in the knit format === jamesh [n=james@203-59-208-190.dyn.iinet.net.au] has joined #launchpad === doko_ [n=doko@dslb-088-073-103-049.pools.arcor-ip.net] has joined #launchpad [10:25] wow [10:25] you mean knit conversion of the launchpad tree? [10:25] it's expected to take a very large amount of CPU and RAM [10:26] I see [10:26] sivang: the proper upgrade procedure is to get the new knit-based launchpad, use it to prime a repository [10:26] so my machines didn't even stand a chance against it? [10:26] then branch your existing weave branches in that repository [10:26] yes, I will do that now, but since my net connection is so crappy over the last couple of days,I figured to convert it on this laptop :) [10:27] so you only effectively convert what code you have outstanding [10:27] I do not know if your laptop stood a chance against it [10:27] yes, this is what RocketFuelToKnits descrbes, but since I Have not any outstanding code I thought to give it a try [10:27] it is certainly possible to tweak the conversion code to change the RAM/CPU tradeoff === sivang notes laptop got hot to the point it could not be touched in either the upper or back part of the left kbd part where the CPU lies [10:28] from what you describe, you went out of RAM [10:28] sivang: how much swap do you have? [10:29] seems so, machine became completely unresponsive [10:29] 1831368 [10:30] hmm, I should probably allocate some more [10:30] too much swap prevents the OOM killer from kicking in, which can lead to severe thrashing even if the runaway code does to have very good cache behaviour [10:30] sivang: nope, less swap is better [10:30] ah [10:31] when the kernel runs out of VM, it pick and SIGABRT a process [10:31] (or something like that, maybe not strictly SIGABRT) [10:32] ah, but when swap is too big then it won't do that? even if it gets filled? [10:32] Here, I have 1GB of RAM and roughly as much swap, and I never run out of VM unless something is quite wrong. [10:32] sivang: the problem is that when the swap is too big [10:32] it takes a long time to fill the VM [10:33] and unless the runaway process has very good behaviour with only needing new pages, that times grows explosively with thrashing [10:33] ddaa: that is , substantially bigger then the physical size? I only have like twice swap as my physical ram. [10:34] YMMV [10:34] I see [10:34] in my personal experience, with 1GB RAM, 1GB of swap is a good value. [10:34] though I could probably get away with less, as it's never nearly full on normal usage [10:35] I will reduce it to this value, but not retry converting here :) [10:35] sivang: hint [10:35] are you using evolution and spamassin? [10:37] evo yes, [10:37] the latter no [10:37] I noticed that when Evo crashes, it tends to leave rogue spamd processes around, that slowly eat your VM [10:37] hmmm, interesting [10:37] dunno if the problem applies with other setups [10:39] slowly, as in a few MB for each rogue spamd. That become quite significant after a week (and a dozen crashes) of normal use... [10:40] hmm, what is port 48064 and port 46454 ? I did netstat before I stop that trashy process to see if something is connecting to the machine , and found those too [10:41] ddaa: Well, I usually tend to shut off my machine after finishing, so I don't think I will have too much opportunity to run into this === SteveA wonders if mpt_ is still around === sivang [i=sivan@muse.19inch.net] has joined #launchpad === Keybuk [n=scott@217.205.109.249] has joined #launchpad [11:00] ddaa, sivang: you would need a bit more than 1GB of SWAP if you want to do suspend to disc [11:02] point, I do not suspend to disc as it did not wake up when I last tried... [11:02] and suspend to ram works fine [11:04] ddaa: yeah, I have the same problem... but it used to work ;-) [11:05] and i hope it will work again at some point [11:05] think the distro guys could use some hardware [11:06] I also had a regression in firegl accel spport in the radeon driver, needed to use the fglrx crap to get it back :( === AlinuxOS [n=AlinuxOS@d83-176-116-69.cust.tele2.it] has joined #launchpad [11:19] SteveA, yo [11:20] hello mpt_ [11:21] are you around for a voice call, or done for the day? [11:22] SteveA, a voice call would be good, since this'll be the last chance for a couple of weeks [11:22] okay, let's do it [11:22] ok, brb === mpt [n=mpt@203.109.220.214] has joined #launchpad === sivang -> back [11:50] ddaa: using rocketfuel-get should still be okay for getting the knitted checkout? as its just rsync out, should not be affected by it right? [11:51] I do not use rocketfuel-get [11:51] ah [11:51] but if it uses rsync, it should give you the same branch [11:51] (a checkout is a different thing) [11:51] yes [11:52] jamesh: hi, do you owe me a review.... how's it going? [11:53] sivang: yeah, it should work. I use it and it works ;-) [11:53] sivang: first time will take a lot of time because the changes are huge [11:55] carlos: yes, almost like a new checkout probably :) [11:56] sivang: I guess [11:58] at least I'm downloading at 190KB/s , my net connection has stabilized a bit === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad === Kamping_Kaiser [n=kgoetz@ppp218-91.lns1.adl2.internode.on.net] has joined #launchpad [12:26] SteveA: Do I need to look into that SQLObject permissions thing? [12:26] yay, third cscvs merge in 24 hours sent :) [12:30] ddaa: I killed your last one maybe three hours ago - there was a hung 'nc' process. Seemed like old times ;) [12:30] well, it succeeded [12:31] it's the same old cvs server spawning crap [12:31] stub: if it's something you can fix, then sure. be nice to know what caused the problem. [12:31] Wow... must have just been blocked waiting for all the children to be reaped, and killing the process unblocked it. [12:32] SteveA: I might fix it, or I might make it worse. Imagine lifeless as the technician and me a monkey with a large wrench to belt things with. [12:32] something about CVS sucking on cosmic magnitudes IIRC [12:32] SteveA: I have no hope of determining the cause [12:32] stub: whatever... i hope lifeless will get time to look into it when he arrives in london [12:33] i don't think it is causing a serious problem now [12:33] ok. if it isn't blocking I'll leave it. [12:33] or ask lifeless to stop using that paranoid umask of his on chinstrap [12:33] umask? [12:34] that reminds me of an ubuntu logo idea someone came up with [12:34] IIRC his DC accounts have a umask looking like 077 [12:35] which caused me no end of grief back when we needed to work on the same files [12:35] but maybe I'm just completely off the mark [12:37] Wow, why is PQM taking so long [12:38] stub: if the nc hangs keep causing problems, the issue is the local pserver spawning in the cscvs test suite. But I have no off-hand idea how to fix it. [12:38] I remember looking at it in the past and concluding that it just was not fixable [12:38] i'm unhappy about cscvs testsuite flakiness blocking launchpad commits to pqm === Kinnison [n=dsilvers@spoo.flarn.net] has joined #launchpad [12:39] SteveA: isn't pqm supposed to kill test suite runs that make no progress? [12:40] that would mitigate that sort of issue [12:40] i know that the idea has been discussed [12:40] but i don't believe it does so right now [12:40] is it possible to disable the specific cscvs tests that are causing this problem? [12:41] Dunno off-hand. That might be a testing infrastructure that's needed by a lot of important tests. [12:42] At least, that's needed to test the native pserver client implementation [12:42] which is like a very critical piece of code [12:42] is it tested on every launchpad commit to pqm? [12:42] Supposedly. [12:42] yet, the pserver client is independent of launchpad [12:42] entirely so [12:43] yes [12:43] well [12:43] so, let's have that *not tested* on launchpad commits [12:43] not entirely [12:43] it's dependent on things like symlinks in ./lib [12:43] but nothing major [12:44] it is dependent on no rogue "rm -rf /" in the launchpad code [12:44] ddaa: are you able to make it so that the pserver client is not tested when we commit to launchpad? [12:45] yet it is still tested when its code and code it actually depends on are altered [12:45] that would require some action from lifeless [12:45] in altering the pqm config === sabdf1 [n=mark@217.205.109.249] has joined #launchpad [12:45] also, I think you t [12:45] should discuss the issue with him, since he knows the code [12:46] so he has a handle on both ends of the problem [12:46] okay. please disable these cscvs tests for now. [12:46] they are causing an immediate problem with all other launchpad developers [12:46] okay, I'll look at how to separate them out of the main test suite [12:46] tests are good. but in order to be enabled, they must not cause a bad effect on the rest of the processes, particularly, they must not have any effect on stuff they don't depend on [12:47] thanks ddaa === mp1 [n=mpt@203.109.220.214] has joined #launchpad === mp1 [n=mpt@203.109.220.214] has left #launchpad [] [01:01] would be nice if unittest grokked skipped tests :/ === cprov [i=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === SteveA --> lunch [01:23] kiko, BjornT: Ping? [01:23] hi malcc === AlinuxOS [n=AlinuxOS@d83-176-116-69.cust.tele2.it] has joined #launchpad [01:24] BjornT: I'm hoping to get a review today on malcolmcleaton/launchpad/soyuz-pagetests-update, SteveA is tied up and suggested one of you guys might be able to help [01:27] malcc: hmm, i don't think i have time to do it today. i'm on vacation today, and i have some other things planned. i'd be happy to do it tomorrow, though. [01:27] BjornT: Thanks, I'll come back tomorrow if I still need someone. === benzai [n=zaheda@82-71-18-29.dsl.in-addr.zen.co.uk] has joined #launchpad === benzai [n=zaheda@82-71-18-29.dsl.in-addr.zen.co.uk] has left #launchpad [] [01:39] SteveA: I think I can actually fix the problem with a trivial patch [01:42] the nc invokation is used to setup a network-listening cvs server, needed for the tests that test that the native client can actually setup a TCP connection, as opposed to the protocol tests that pipe to a local server (which already has TERM-then-KILL cleanup, that was needed in the past) [01:43] There's a wait in the code to let the test suite sleep some time until nc had the time to run. I think the breakage happens when the sleep is too short and the connection attempt fails, then nc sits waiting for a connection, and the test suite sits waiting for nc. [01:44] the nc command looks like "nc -l -p 2401 -e path-to-server-script" [01:44] adding a "-w 60" in here should prevent the lock up, nc sees no network activity for 60 seconds, it will terminate [01:50] carlos: ping [01:50] doko_: pong [01:51] carlos: can we look at the OOo translations next Tuesday afternoon? [01:51] look for any possible problem? [01:51] sure [01:53] doko_: what time? [01:54] carlos: after your fiesta^Wlunch? [01:54] :-P [01:54] ok [01:55] fine, which time? === Yannig [n=yannick@AToulouse-254-1-89-128.w86-207.abo.wanadoo.fr] has joined #launchpad [02:04] Hello everybody :) [02:06] doko_: 14:00 UTC [02:06] Yannig: hi [02:07] carlos: ok === niemeyer [n=niemeyer@200.181.175.75] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === beyond [n=beyond@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:28] Thats twice in a row it looks like pqm completed but blocked waiting for one last nc process to die [02:29] I'm on it [02:29] There's also an obvious bug in the process reaping code [02:29] Yup. === cprov [i=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === carlos -> lunch === spiv [n=andrew@218-214-66-203.people.net.au] has joined #launchpad === Kinnison [n=dsilvers@spoo.flarn.net] has joined #launchpad === sabdfl [n=mark@host217-37-231-22.in-addr.btopenworld.com] has joined #launchpad [02:59] re === bradb wakes up [03:00] cprov: as part of the edgy test, did you do any dapper-updates uploads? [03:00] cprov: we'll have several to do shortly after the release [03:01] anybody remembers the magic python to quote file names in shell scripts? === mpt_ [n=mpt@203.109.220.214] has joined #launchpad [03:01] mdz: no, but should work as we have breezy-updates currently [03:02] mdz: send me one of them, I can process it right now [03:16] another silly question, is there an reliable way of telling that a process is listening to a port without actually opening a connection? [03:17] I think lsof will tell you, but I don't remember the exact dead chickens [03:17] malcc: I mean, in a programmtic way that might get through into a test suite in rocketfuel [03:18] malcc: Oh :( [03:18] ddaa: Oh :( [03:18] malcc: Why are you talking to yourself you idiot? [03:18] the specific problem is starting a nc-based server and having to wait until nc has started listening [03:19] if we connect an close the connection, we have consumed the server [03:19] and we cannot use the server script to signal us, because it's only execed after nc has received a connection [03:20] I got it [03:20] nc -l -p 1234 -v [03:20] then read on stderr [03:21] when it is actually listening, it will tell us [03:23] cprov: http://people.ubuntu.com/~mdz/dapper-updates/ [03:24] bradb: ubuntu-security is subscribed to this bug via one or more of its duplicates: https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/43012 [03:24] Malone bug 43012 in ubiquity "crash creating partman question dialog" [Major,Fix released] [03:24] bradb: how do I find out which one and fix it? [03:24] mdz: there's no automatic way. you'd have to click each dupe in the dupes portlet to find out. but teams can't be unsubscribed from bugs, unfortunately. [03:25] mdz: i'm curious, why does ubuntu-security not want to be subscribed to the dupe target? [03:25] ddaa: why not the usual approach ? if you want to test a server, probe it with the client. Not sure if your goal is to test the system "bind" or other system connection framework. [03:25] mdz: ok [03:26] cprov: because it does not work there === bradb guesses it was a non-security security bug or something [03:26] ddaa: we are setting up cvs pserver in the test suite using nc [03:26] cprov:: we are setting up cvs pserver in the test suite using nc [03:26] ddaa: oops, then you make your point. [03:27] to test that our native client can establish a TCP connection [03:27] so it's a single shot gun [03:28] is somebody available to review the patch to stop the cscvs test suite from blocking pqm? [03:29] ddaa: yes, i guess the popen('nc') can, at least, probe something is listening the socket in question, however doesn't ensure things will work as expected. [03:29] popen [03:29] live in the 21st century [03:29] use subprocess :) [03:30] bradb: the bug has nothing to do with security [03:30] nah, I got it, we needed nc to somehow signal us once it's listening, and the -v option does just that [03:30] bradb: they can be unsubscribed via the mail interface, which you can see in the comments I tried to do, but I didn't realize it was implicitly subscribed [03:31] bradb: perhaps unsubscribing a team should walk the duplicates and unsubscribe there as well? === bradb didn't know you could unsubscribe others via the email UI. that's sort of a bug, maybe. as for a solution to this specific problem, i'll have to put some thought into it. [03:34] bradb: when we are inconvenienced by a bug for months, and then discover a workaround, it is discouraging for that workaround to be referred to as a bug :-P [03:35] mdz: works, https://dogfood.ubuntu.com/distros/ubuntu/dapper/+queue [03:37] cprov: built and published already? [03:37] mdz: it's kind of a bug, IMHO, but my initial thought is that both the web ui and the email ui should allow you to unsubscribe yourself or teams of which you're a member, like the bug contacts ui. [03:37] bradb: I'm a member of the security team [03:37] ddaa: popen() was just to save types, however reliying on 'nc' syscall for test is a more last century thing than popen ;) [03:38] give me a better way to set up a TCP-listening cvs pserver [03:39] mdz: not so fast, it's only in NEW, but should flow correctly [03:39] cprov: and it's not a syscall, it's the nc CLI :) [03:40] cprov: why new, is the archive data on dogfood old? [03:40] ddaa: ohh another last century feature, pserver ... nevermind, do whatever you need to do [03:40] mdz: it's a 18th May copy [03:40] cprov: you're right [03:41] I'll drop cvs support in cscvs [03:41] who cares about that old stuff anyway? [03:45] ddaa: you started it by blaming popen, remember ? okay, let's stop the noise [03:50] cprov: how do we open dapper-updates? [03:51] cprov: (in production) [03:51] or is it open already? [03:51] mdz: by releasing dapper (setting dapper state to released) [03:51] cprov: we can't do it earlier? [03:52] mdz: let me check, probably by setting it to frozen [03:54] SteveA: nc hang bugfix for review: https://chinstrap.ubuntu.com/~dsilvers/paste/fileItA9m9.html [03:54] mdz: no, currently you can't, EXPERIMENTAL, DEVELOPMENT and FROZEN are considered open, [03:55] mdz: so you can't upload for UPDATES & SECURITY in a opened release. [03:56] mdz: you can try to fix it for next releases (for this is too late I guess), adding an intermediate state, but I'm not sure about the use-case, can you describe it to me ? [03:57] mdz: why can't we ship the changes that we alredy have in RELEASE ? does it happen any release or is a special case for dapper ? [03:57] cprov: we have some fixes that only affect upgrades, and not CD images [03:58] ddaa: I see cscvs stuff merged finally -- was the difference just lifeless's change to the pqm config to use check_merge? [03:58] cprov: we want to put them into dapper-updates now, rather than waiting until after we release CD images, so they have time to build etc. [03:58] and are ready when we put out the release announcement [03:58] mdz: I see [03:59] spiv: yes, and some admin action to kill runaway processes created by the cscvs test suite... [03:59] ddaa: hence this change involving nc? [03:59] spiv: yup [03:59] spiv: SteveA wants me to disable some of the tests, but I think I can just fix the problem [04:00] needed to have a closer look and actually read man nc [04:00] mdz: pockets concept isn't able to model such workflow as well, maybe it's an extra reason to change it soon [04:00] So long as the sourcecode/* checks are generally run, I don't care how it's fixed ;) [04:01] mdz: I'll add a note about this issue to be discussed in Paris, unfortunatelly it's the best we can do right now [04:03] ddaa: in the mid-term, i want better test dependencies [04:03] so that we're running the tests that make best sense for a given merge to pqm [04:03] running all the tests all the time is a feature [04:03] as it allows quickly catching when environment changes break some rarely modified code [04:04] it's a misfeature [04:04] if you're concerned about rarely modified code like that, then a special cron-job should submit requests to pqm weekly to test it [04:04] but it shouldn't burden everyone with testing the code all the time, "just in case" [04:05] I punt to lifeless [04:05] malcc, how may I help you? [04:05] nothing in cscvs depends on launchpad by design [04:06] in the same way as nothing in pybaz, or importd, or a number of third party libraries [04:06] kiko: It's ok, the ping was for a quick review but SteveA took it on [04:15] cprov: ok, thanks [04:16] stub: it looks like pqm needs a gentle nudge again === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has left #launchpad [] === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad === geforcex [n=geforcex@220.202.38.131] has joined #launchpad [04:33] elmo: pqm ping [04:42] hey spiv: is there a way to pdb-step through a failing test [04:42] ? [04:42] in sqlobject? [04:42] kiko: with py.test? probably. [04:42] oh, --pdb [04:42] ddaa: ? [04:42] spiv, do you have a moment for a drive-by sqlobject review? [04:42] Does putting "import pdb; pdb.set_trace()" not work? ;) [04:43] elmo: pqm looks like it's stuck [04:43] kiko: sure. [04:43] can you have a look and tell us what you do? [04:43] killed the nc [04:44] elmo: thank you, it's unstuck now [04:45] there's a patch in the queue that should tame those rogue nc [04:52] beat me [04:56] spiv, can you explain to me how the "implicit ID column" works in SQLObject? [04:57] kiko: you mean how you don't need to do "id = IntCol()"? [04:58] stub: hello [04:58] spiv, exactly. it then appears that the "id" column is not present in _SO_columnDict [04:58] which forces me to hack around it :-( [04:58] SteveA: hi [04:58] stub: niemeyer just pointed out that newInteraction() gets a stack trace on every call, in upstream Zope 3 [04:59] stub: removing this call should speed up ftests [04:59] lib/zope/security/management.py, line 91 [04:59] kiko: right, it's special-cased pretty throughly. [04:59] it is used only for debugging [04:59] spiv, isn't that the most stupid thing ever? [05:00] kiko: a bit, but it is pretty fundamental to how SQLObject works. [05:00] Maybe. I suspect it won't be terribly noticeable though for launchpad as it will be overshadowed by db access, librarian startup/shutdown etc. [05:00] spiv, okay, I have a patch which does everything and includes icing on top [05:00] stub: you gonna fix librarian startup/shutdown? [05:00]