[12:05] <kiko> I don't see why uploading would be difficult -- it's a simple post to a form
[12:05] <kiko> there are actually third-party tools that post for you IIRC
[12:06] <clahey> It's a simple post to form for a tarball or do I have to post each po file?
[12:06] <clahey> Oh, third party tools is cool.
[12:06] <kiko> you can do either
[12:06] <clahey> I do like the interface.
[12:06] <kiko> tarball or pofiles
[12:06] <clahey> Oh, posting a tarball wouldn't be so bad.
[12:06] <kiko> we've got an XMLRPC UI that makes things slightly more convenient
[12:06] <kiko> err
[12:07] <kiko> a planned XMLRPC UI
[12:07] <kiko> but in your case the main issue is really automating downloads.
[12:07] <clahey> That's just downloading a tarball and expanding it, right?
[12:07] <kiko> correct.
[12:07] <clahey> Do you guys support individuals downloading and uploading po files so they can do their processing locally?
[12:07] <kiko> sure
[12:08] <kiko> that's one of the workflows rosetta supports
[12:08] <clahey> And then it intgrates with what's there?  Cool.
[12:08] <kiko> yes
[12:08] <kiko> you also get to control who decides which translations are official
[12:08] <clahey> Your UI is the nicest looking one I've seen.
[12:08] <kiko> so you can have a trusted group of translators
[12:08] <kiko> and then community translators can add suggestions for their posterior review
[12:08] <clahey> Yeah, I saw that.  Very neat.
[12:08] <kiko> thanks, it's been a lot of work to get there.
[12:09] <clahey> 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] <kiko> there are already some products that use that policy
[12:10] <clahey> 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] <kiko> jordi's the best guy to tell you because he is community ninja
[12:10] <kiko> 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] <kiko> carlos is working on a change which allows you to zoom into specific strings and see their history, and all suggestions
[12:11] <kiko> next steps from there are allowing for ajax-style navigation, and also for allowing one-click accepts
[12:17] <mpt> kiko!
[12:17] <kiko> oh-oh, what did I say!
[12:18] <mpt> kiko, don't worry, you're not in *that* much trouble
[12:18] <clahey> kiko: Cool.  We'll discuss it here.  Rosetta looks awesome.
[12:18] <kiko> clahey, great to hear. be sure to let me know if you need anything.
[12:39] <kiko> wtf is up with pqm
[12:39] <kiko> ah I know
[12:39] <kiko> it must be that lifeless is on a plane.
[12:41] <sivang> dudes, how do I see translations by a specific person ?
[12:42] <matsubara> sivang: /people/$person/+translations i think
[12:42] <kiko> sivang, you can't easily today. and +translations is rife with timeouts and it only indicates templates not actual translations
[12:43] <sivang> yes, that is what I see now
[12:43] <sivang> https://launchpad.net/people/nir78/+translations
[12:43] <sivang> when I click a template, I see alist of people that translated there
[12:44] <sivang> so we currently have no way to evaluate membership of people to translation teams...
[12:44] <sivang> I kept sending them to do work on the Hebrew wiki, some of them did, some prefer to work through rosetta
[12:44] <sivang> :-)
[12:45] <sivang> how can I see then propsed translations?
[12:45] <sivang> (by a specific person)
[12:45] <kiko> sivang, ask them which translations they contributed to?
[12:45] <sivang> I did, they did not respond. I will re-ask
[12:45] <sivang> I mean, they told me "review my work on launchpad"
[12:46] <kiko> tell them "yes, launchpad is as big as africa, so where? "
[12:46] <sivang> hehe
[12:46] <sivang> at least you don't get parasites like when you dip in african water :)
[12:46] <kiko> that's a rumor 
[12:46] <kiko> I have dipped and sipped from african water
[12:47] <kiko> I only got friendly parasites
[12:47] <sivang> and you don't have any hitch hiker with you? :)
[12:47] <kiko> I prefer to call them friends
[12:47] <sivang> some girl from here that went there, was digged a bite fly's cocon from her forehead. gross!
[12:48] <sivang> anyway, back to happy things :)
[12:48] <kiko> I got one of those in california
[12:48] <sivang> serious?
[12:49] <kiko> yeah. parasites exist even in developed countries!
[12:51] <sivang> Well, sure, but not in the same quantities probably. anyway, how was it removed eventually?
[12:52] <sivang> and what are those so called friend you say you dragged with you from their comfortable home on Africa? :)
[12:52] <lifeless> bye guys, me-> London
[12:52] <sivang> lifeless: easy flight!
[01:15] <sivang> 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] <sivang> hmm, bzr upgrade takes a while over my checkout branch
[01:27] <sivang> and the disk howls
[01:49] <sivang> hrm, still converting
[02:08] <sivang> I hate sever drop off
[02:08] <sivang> server, even
[03:04] <mpt> Gooooooooooooooooooood afternoon Launchpadders!
[04:41] <elmo> who's responsible for bzrsyncd on gandwana?
[04:53] <BehemothNet60137> question
[04:54] <Gigawatts> i have now done the beginning of the registration process to ship ubuntu cd's twice
[04:55] <Gigawatts> and i never recieve an email
[04:55] <Gigawatts> and i know the email address is correct
[05:10] <mpt> spiv / jamesh / lifeless, skype call to discuss the next stage of MaloneSimplifications?
[05:11] <mpt> hmmm, spiv and lifeless aren't here
[05:11] <jamesh> mpt: sure.
[05:12] <mpt> brb
[05:36] <stub> Gigawatts: Could it be that you or your ISP think it is spam and are dropping it?
[05:36] <stub> I can give you a gmail invite if you want to test with another account
[05:47] <mpt> 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] <jamesh> mpt: thanks
[05:52] <mpt> argh
[05:53] <mpt> stub, ETA for fixing login on staging?
[05:53] <stub> 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] <stub> mpt: Actually, I can do a quick fix. Hang on...
[05:55] <stub> mpt: Ok - that should fix it (the same way that production happens to be working fine with this bug)
[05:56] <stub> Logging into staging will probably kill your production session information though so don't try and use both at the same time
[05:56] <stub> or it might work... dunno
[05:58] <mpt> thanks stub
[06:06] <spiv> mpt: sorry, was at lunch
[06:38] <Gigawatts> opps, sorry, was away for awhile
[06:38] <Gigawatts> stub, i checked my spam box, and nothing
[06:39] <Gigawatts> it was a hotmail account
[06:39] <Gigawatts> so i dont see a reason for it to not work, although i could try my gmail account also, see if that fixes it
[06:57] <Gigawatts> ok, well it worked instantly with gmail, wierd
[06:57] <Gigawatts> wonder why it doesnt work with hotmail?
[07:08] <stub> 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] <Gigawatts> ok, well thankyou, and you might want to investigate why the emails arent going through to hotmail accounts
[07:08] <Gigawatts> adios!
[08:20] <SteveA> morning
[08:36] <troy_s> need a launchpad guru again
[08:56] <SteveA> hi troy_s.  what's up?
[09:13] <mpt_> Whenever I try to merge two of our overly-granular pages I disappear into a maze of classes and interfaces
[09:16] <stub> Welcome to Zope3!
[09:16] <stub> [09:16] <stub> You are in a maze of classes and interfaces, all alike.
[09:19] <spiv> > kill metaclass
[09:54] <carlos> morning
[10:09] <sivang> morning all
[10:12] <sivang> 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] <sivang> I did so since I wanted to workaround having to re-checkout in the knit format
[10:25] <ddaa> wow
[10:25] <ddaa> you mean knit conversion of the launchpad tree?
[10:25] <ddaa> it's expected to take a very large amount of CPU and RAM
[10:26] <sivang> I see
[10:26] <ddaa> sivang: the proper upgrade procedure is to get the new knit-based launchpad, use it to prime a repository
[10:26] <sivang> so my machines didn't even stand a chance against it?
[10:26] <ddaa> then branch your existing weave branches in that repository
[10:26] <sivang> 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] <ddaa> so you only effectively convert what code you have outstanding
[10:27] <ddaa> I do not know if your laptop stood a chance against it
[10:27] <sivang> yes, this is what RocketFuelToKnits descrbes, but since I Have not any outstanding code I thought to give it a try
[10:27] <ddaa> it is certainly possible to tweak the conversion code to change the RAM/CPU tradeoff
[10:28] <ddaa> from what you describe, you went out of RAM
[10:28] <ddaa> sivang: how much swap do you have?
[10:29] <sivang> seems so, machine became completely unresponsive
[10:29] <sivang> 1831368
[10:30] <sivang> hmm, I should probably allocate some more
[10:30] <ddaa> 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] <ddaa> sivang: nope, less swap is better
[10:30] <sivang> ah
[10:31] <ddaa> when the kernel runs out of VM, it pick and SIGABRT a process
[10:31] <ddaa> (or something like that, maybe not strictly SIGABRT)
[10:32] <sivang> ah, but when swap is too big then it won't do that? even if it gets filled?
[10:32] <ddaa> 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] <ddaa> sivang: the problem is that when the swap is too big
[10:32] <ddaa> it takes a long time to fill the VM
[10:33] <ddaa> and unless the runaway process has very good behaviour with only needing new pages, that times grows explosively with thrashing
[10:33] <sivang> ddaa: that is , substantially bigger then the physical size? I only have like twice swap as my physical ram.
[10:34] <ddaa> YMMV
[10:34] <sivang> I see
[10:34] <ddaa> in my personal experience, with 1GB RAM, 1GB of swap is a good value.
[10:34] <ddaa> though I could probably get away with less, as it's never nearly full on normal usage
[10:35] <sivang> I will reduce it to this value, but not retry converting here :)
[10:35] <ddaa> sivang: hint
[10:35] <ddaa> are you using evolution and spamassin?
[10:37] <sivang> evo yes,
[10:37] <sivang> the latter no
[10:37] <ddaa> I noticed that when Evo crashes, it tends to leave rogue spamd processes around, that slowly eat your VM
[10:37] <sivang> hmmm, interesting
[10:37] <ddaa> dunno if the problem applies with other setups
[10:39] <ddaa> 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] <sivang> 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] <sivang> 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
[11:00] <carlos> ddaa, sivang: you would need a bit more than 1GB of SWAP if you want to do suspend to disc
[11:02] <ddaa> point, I do not suspend to disc as it did not wake up when I last tried...
[11:02] <ddaa> and suspend to ram works fine
[11:04] <carlos> ddaa: yeah, I have the same problem... but it used to work ;-)
[11:05] <carlos> and i hope it will work again at some point
[11:05] <ddaa> think the distro guys could use some hardware
[11:06] <ddaa> I also had a regression in firegl accel spport in the radeon driver, needed to use the fglrx crap to get it back :(
[11:19] <mpt_> SteveA, yo
[11:20] <SteveA> hello mpt_ 
[11:21] <SteveA> are you around for a voice call, or done for the day?
[11:22] <mpt_> SteveA, a voice call would be good, since this'll be the last chance for a couple of weeks
[11:22] <SteveA> okay, let's do it
[11:22] <mpt_> ok, brb
[11:50] <sivang> 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] <ddaa> I do not use rocketfuel-get
[11:51] <sivang> ah
[11:51] <ddaa> but if it uses rsync, it should give you the same branch
[11:51] <ddaa> (a checkout is a different thing)
[11:51] <sivang> yes
[11:52] <carlos> jamesh: hi, do you owe me a review.... how's it going?
[11:53] <carlos> sivang: yeah, it should work. I use it and it works ;-)
[11:53] <carlos> sivang: first time will take a lot of time because the changes are huge
[11:55] <sivang> carlos: yes, almost like a new checkout probably :)
[11:56] <carlos> sivang: I guess
[11:58] <sivang> at least I'm downloading at 190KB/s , my net connection has stabilized a bit
[12:26] <stub> SteveA: Do I need to look into that SQLObject permissions thing?
[12:26] <ddaa> yay, third cscvs merge in 24 hours sent :)
[12:30] <stub> ddaa: I killed your last one maybe three hours ago - there was a hung 'nc' process. Seemed like old times ;)
[12:30] <ddaa> well, it succeeded
[12:31] <ddaa> it's the same old cvs server spawning crap
[12:31] <SteveA> stub: if it's something you can fix, then sure.  be nice to know what caused the problem.
[12:31] <stub> Wow... must have just been blocked waiting for all the children to be reaped, and killing the process unblocked it.
[12:32] <stub> 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] <ddaa> something about CVS sucking on cosmic magnitudes IIRC
[12:32] <stub> SteveA: I have no hope of determining the cause
[12:32] <SteveA> stub: whatever... i hope lifeless will get time to look into it when he arrives in london
[12:33] <SteveA> i don't think it is causing a serious problem now
[12:33] <stub> ok. if it isn't blocking I'll leave it.
[12:33] <ddaa> or ask lifeless to stop using that paranoid umask of his on chinstrap
[12:33] <SteveA> umask?
[12:34] <SteveA> that reminds me of an ubuntu logo idea someone came up with
[12:34] <ddaa> IIRC his DC accounts have a umask looking like 077
[12:35] <ddaa> which caused me no end of grief back when we needed to work on the same files
[12:35] <ddaa> but maybe I'm just completely off the mark
[12:37] <mpt> Wow, why is PQM taking so long
[12:38] <ddaa> 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] <ddaa> I remember looking at it in the past and concluding that it just was not fixable
[12:38] <SteveA> i'm unhappy about cscvs testsuite flakiness blocking launchpad commits to pqm
[12:39] <ddaa> SteveA: isn't pqm supposed to kill test suite runs that make no progress?
[12:40] <ddaa> that would mitigate that sort of issue
[12:40] <SteveA> i know that the idea has been discussed
[12:40] <SteveA> but i don't believe it does so right now
[12:40] <SteveA> is it possible to disable the specific cscvs tests that are causing this problem?
[12:41] <ddaa> Dunno off-hand. That might be a testing infrastructure that's needed by a lot of important tests.
[12:42] <ddaa> At least, that's needed to test the native pserver client implementation
[12:42] <ddaa> which is like a very critical piece of code
[12:42] <SteveA> is it tested on every launchpad commit to pqm?
[12:42] <ddaa> Supposedly.
[12:42] <SteveA> yet, the pserver client is independent of launchpad
[12:42] <SteveA> entirely so
[12:43] <ddaa> yes
[12:43] <ddaa> well
[12:43] <SteveA> so, let's have that *not tested* on launchpad commits
[12:43] <ddaa> not entirely
[12:43] <ddaa> it's dependent on things like symlinks in ./lib
[12:43] <ddaa> but nothing major
[12:44] <SteveA> it is dependent on no rogue "rm -rf /" in the launchpad code
[12:44] <SteveA> ddaa: are you able to make it so that the pserver client is not tested when we commit to launchpad?
[12:45] <SteveA> yet it is still tested when its code and code it actually depends on are altered
[12:45] <ddaa> that would require some action from lifeless
[12:45] <ddaa> in altering the pqm config
[12:45] <ddaa> also, I think you t
[12:45] <ddaa> should discuss the issue with him, since he knows the code
[12:46] <ddaa> so he has a handle on both ends of the problem
[12:46] <SteveA> okay.  please disable these cscvs tests for now.
[12:46] <SteveA> they are causing an immediate problem with all other launchpad developers
[12:46] <ddaa> okay, I'll look at how to separate them out of the main test suite
[12:46] <SteveA> 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] <SteveA> thanks ddaa
[01:01] <ddaa> would be nice if unittest grokked skipped tests :/
[01:23] <malcc> kiko, BjornT: Ping?
[01:23] <BjornT> hi malcc 
[01:24] <malcc> 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] <BjornT> 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] <malcc> BjornT: Thanks, I'll come back tomorrow if I still need someone.
[01:39] <ddaa> SteveA: I think I can actually fix the problem with a trivial patch
[01:42] <ddaa> 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] <ddaa> 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] <ddaa> the nc command looks like "nc -l -p 2401 -e path-to-server-script"
[01:44] <ddaa> adding a "-w 60" in here should prevent the lock up, nc sees no network activity for 60 seconds, it will terminate
[01:50] <doko_> carlos: ping
[01:50] <carlos> doko_: pong
[01:51] <doko_> carlos: can we look at the OOo translations next Tuesday afternoon?
[01:51] <carlos> look for any possible problem?
[01:51] <carlos> sure
[01:53] <carlos> doko_: what time?
[01:54] <doko_> carlos: after your fiesta^Wlunch?
[01:54] <carlos> :-P
[01:54] <carlos> ok
[01:55] <doko_> fine, which time?
[02:04] <Yannig> Hello everybody :)
[02:06] <carlos> doko_: 14:00 UTC
[02:06] <carlos> Yannig: hi
[02:07] <doko_> carlos: ok
[02:28] <stub> Thats twice in a row it looks like pqm completed but blocked waiting for one last nc process to die
[02:29] <ddaa> I'm on it
[02:29] <ddaa> There's also an obvious bug in the process reaping code
[02:29] <stub> Yup.
[02:59] <SteveA> re
[03:00] <mdz> cprov: as part of the edgy test, did you do any dapper-updates uploads?
[03:00] <mdz> cprov: we'll have several to do shortly after the release
[03:01] <ddaa> anybody remembers the magic python to quote file names in shell scripts?
[03:01] <cprov> mdz: no, but should work as we have breezy-updates currently
[03:02] <cprov> mdz: send me one of them, I can process it right now
[03:16] <ddaa> 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] <malcc> I think lsof will tell you, but I don't remember the exact dead chickens
[03:17] <ddaa> malcc: I mean, in a programmtic way that might get through into a test suite in rocketfuel
[03:18] <malcc> malcc: Oh :(
[03:18] <malcc> ddaa: Oh :(
[03:18] <malcc> malcc: Why are you talking to yourself you idiot?
[03:18] <ddaa> the specific problem is starting a nc-based server and having to wait until nc has started listening
[03:19] <ddaa> if we connect an close the connection, we have consumed the server
[03:19] <ddaa> and we cannot use the server script to signal us, because it's only execed after nc has received a connection
[03:20] <ddaa> I got it
[03:20] <ddaa> nc -l -p 1234 -v
[03:20] <ddaa> then read on stderr
[03:21] <ddaa> when it is actually listening, it will tell us
[03:23] <mdz> cprov: http://people.ubuntu.com/~mdz/dapper-updates/
[03:24] <mdz> 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] <Ubugtu> Malone bug 43012 in ubiquity "crash creating partman question dialog" [Major,Fix released]  
[03:24] <mdz> bradb: how do I find out which one and fix it?
[03:24] <bradb> 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] <bradb> mdz: i'm curious, why does ubuntu-security not want to be subscribed to the dupe target?
[03:25] <cprov> 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] <cprov> mdz: ok
[03:26] <ddaa> cprov: because it does not work there
[03:26] <ddaa> ddaa: we are setting up cvs pserver in the test suite using nc
[03:26] <ddaa> cprov:: we are setting up cvs pserver in the test suite using nc
[03:26] <cprov> ddaa: oops, then you make your point.
[03:27] <ddaa> to test that our native client can establish a TCP connection
[03:27] <ddaa> so it's a single shot gun
[03:28] <ddaa> is somebody available to review the patch to stop the cscvs test suite from blocking pqm?
[03:29] <cprov> 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] <ddaa> popen
[03:29] <ddaa> live in the 21st century
[03:29] <ddaa> use subprocess :)
[03:30] <mdz> bradb: the bug has nothing to do with security
[03:30] <ddaa> nah, I got it, we needed nc to somehow signal us once it's listening, and the -v option does just that
[03:30] <mdz> 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] <mdz> bradb: perhaps unsubscribing a team should walk the duplicates and unsubscribe there as well?
[03:34] <mdz> 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] <cprov> mdz: works, https://dogfood.ubuntu.com/distros/ubuntu/dapper/+queue
[03:37] <mdz> cprov: built and published already?
[03:37] <bradb> 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] <mdz> bradb: I'm a member of the security team
[03:37] <cprov> ddaa: popen() was just to save types, however reliying on 'nc' syscall for test is a more last century thing than popen ;)
[03:38] <ddaa> give me a better way to set up a TCP-listening cvs pserver
[03:39] <cprov> mdz: not so fast, it's only in NEW, but should flow correctly
[03:39] <ddaa> cprov: and it's not a syscall, it's the nc CLI :)
[03:40] <mdz> cprov: why new, is the archive data on dogfood old?
[03:40] <cprov> ddaa: ohh another last century feature, pserver ... nevermind, do whatever you need to do
[03:40] <cprov> mdz: it's a 18th May copy
[03:40] <ddaa> cprov: you're right
[03:41] <ddaa> I'll drop cvs support in cscvs
[03:41] <ddaa> who cares about that old stuff anyway?
[03:45] <cprov> ddaa: you started it by blaming popen, remember ? okay, let's stop the noise
[03:50] <mdz> cprov: how do we open dapper-updates?
[03:51] <mdz> cprov: (in production)
[03:51] <mdz> or is it open already?
[03:51] <cprov> mdz: by releasing dapper (setting dapper state to released)
[03:51] <mdz> cprov: we can't do it earlier?
[03:52] <cprov> mdz: let me check, probably by setting it to frozen
[03:54] <ddaa> SteveA: nc hang bugfix for review: https://chinstrap.ubuntu.com/~dsilvers/paste/fileItA9m9.html
[03:54] <cprov> mdz: no, currently you can't, EXPERIMENTAL, DEVELOPMENT and FROZEN are considered open, 
[03:55] <cprov> mdz: so you can't upload for UPDATES & SECURITY in a opened release.
[03:56] <cprov> 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] <cprov> 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] <mdz> cprov: we have some fixes that only affect upgrades, and not CD images
[03:58] <spiv> ddaa: I see cscvs stuff merged finally -- was the difference just lifeless's change to the pqm config to use check_merge?
[03:58] <mdz> 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] <mdz> and are ready when we put out the release announcement
[03:58] <cprov> mdz: I see
[03:59] <ddaa> spiv: yes, and some admin action to kill runaway processes created by the cscvs test suite...
[03:59] <spiv> ddaa: hence this change involving nc?
[03:59] <ddaa> spiv: yup
[03:59] <ddaa> spiv: SteveA wants me to disable some of the tests, but I think I can just fix the problem
[04:00] <ddaa> needed to have a closer look and actually read man nc
[04:00] <cprov> mdz: pockets concept isn't able to model such workflow as well, maybe it's an extra reason to change it soon
[04:00] <spiv> So long as the sourcecode/* checks are generally run, I don't care how it's fixed ;)
[04:01] <cprov> 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] <SteveA> ddaa: in the mid-term, i want better test dependencies
[04:03] <SteveA> so that we're running the tests that make best sense for a given merge to pqm
[04:03] <ddaa> running all the tests all the time is a feature
[04:03] <ddaa> as it allows quickly catching when environment changes break some rarely modified code
[04:04] <SteveA> it's a misfeature
[04:04] <SteveA> 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] <SteveA> but it shouldn't burden everyone with testing the code all the time, "just in case"
[04:05] <ddaa> I punt to lifeless
[04:05] <kiko> malcc, how may I help you?
[04:05] <ddaa> nothing in cscvs depends on launchpad by design
[04:06] <ddaa> in the same way as nothing in pybaz, or importd, or a number of third party libraries
[04:06] <malcc> kiko: It's ok, the ping was for a quick review but SteveA took it on
[04:15] <mdz> cprov: ok, thanks
[04:16] <ddaa> stub: it looks like pqm needs a gentle nudge again
[04:33] <ddaa> elmo: pqm ping
[04:42] <kiko> hey spiv: is there a way to pdb-step through a failing test
[04:42] <kiko> ?
[04:42] <kiko> in sqlobject?
[04:42] <spiv> kiko: with py.test?  probably.
[04:42] <kiko> oh, --pdb
[04:42] <elmo> ddaa: ?
[04:42] <kiko> spiv, do you have a moment for a drive-by sqlobject review?
[04:42] <spiv> Does putting "import pdb; pdb.set_trace()" not work? ;)
[04:43] <ddaa> elmo: pqm looks like it's stuck
[04:43] <spiv> kiko: sure.
[04:43] <ddaa> can you have a look and tell us what you do?
[04:43] <elmo> killed the nc
[04:44] <ddaa> elmo: thank you, it's unstuck now
[04:45] <ddaa> there's a patch in the queue that should tame those rogue nc
[04:52] <stub> beat me
[04:56] <kiko> spiv, can you explain to me how the "implicit ID column" works in SQLObject?
[04:57] <spiv> kiko: you mean how you don't need to do "id = IntCol()"?
[04:58] <SteveA> stub: hello
[04:58] <kiko> spiv, exactly. it then appears that the "id" column is not present in _SO_columnDict
[04:58] <kiko> which forces me to hack around it :-(
[04:58] <stub> SteveA: hi
[04:58] <SteveA> stub: niemeyer just pointed out that newInteraction() gets a stack trace on every call, in upstream Zope 3
[04:59] <SteveA> stub: removing this call should speed up ftests
[04:59] <SteveA>  lib/zope/security/management.py, line 91
[04:59] <spiv> kiko: right, it's special-cased pretty throughly.
[04:59] <SteveA> it is used only for debugging 
[04:59] <kiko> spiv, isn't that the most stupid thing ever?
[05:00] <spiv> kiko: a bit, but it is pretty fundamental to how SQLObject works.
[05:00] <stub> 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] <kiko> spiv, okay, I have a patch which does everything and includes icing on top
[05:00] <SteveA> stub: you gonna fix librarian startup/shutdown?
[05:00] <cprov> kiko: instareview on https://chinstrap.ubuntu.com/~dsilvers/paste/fileX4bXAN.html ?
[05:01] <cprov> kiko: will ask dsilvers as well, maybe he remember some issue related to this
[05:01] <stub> SteveA: Eventually, yes.
[05:01] <SteveA> please sooner rather than later
[05:01] <SteveA> faster test runs speed *everyone* up
[05:05] <stub> SteveA: My trivial fix involving stopping invalids authenticating has grown with all the fallout. Shall I stick it in your review queue or general?
[05:07] <spiv> Using malone's email interface for an extended conversation makes for some pretty ridiculous subject lines!
[05:08] <stub> spiv: You are allowed to edit the subject line ;)
[05:08] <kiko> spiv, that's a bug
[05:08] <kiko> spiv, btw: https://chinstrap.ubuntu.com/~dsilvers/paste/filemuQjOv.html                   
[05:08] <kiko> spiv, fixes prejoin for SQLRJ and SQLMJ and also fixes orderBy the RIGHT way.
[05:08] <kiko> all tests pass
[05:08] <spiv> stub: I do, but further replies keep making it silly again anyway ;)
[05:09] <spiv> Not that "all tests pass" is much guarantee of anything with SQLObject...
[05:10] <SteveA> stub: i'm not going to look at it for a couple of days, if so
[05:10] <ddaa> spiv: there must be a missing negation somewhere in that sentence
[05:10] <stub> I'll move it then
[05:10] <ddaa> spiv: nevermind ;)
[05:11] <kiko> spiv, well, orderBy is pretty fundamental I think. the special-cased if is stoopid
[05:11] <kiko> s/if/id
[05:13] <malcc> Somebody remind me where I can view the pqm queue?
[05:13] <kiko> malcc, pqm.launchpad.net
[05:13] <ddaa> watch lynx --dump http://pqm.launchpad.net/
[05:14] <ddaa> stick a -n 60 in there too
[05:14] <spiv> kiko: Rather than a sequence of "if self.feature_foo: results = results.feature_foo(self.feature_foo)", can we replace that with just passing some keyword args to the select results?
[05:14] <malcc> ddaa: Thanks
[05:14] <spiv> kiko: something like results.clone(prejoins=self.prejoins, orderBy=self.orderBy, ...)
[05:15] <spiv> kiko: I'm guessing the answer is "no, it's not quite as simple as it looks", but just in case...
[05:16] <kiko> spiv, i'll give it a go, let me check what the defaults are.
[05:17] <spiv> (I could almost imagine letting FooJoin take **kwargs that it will pass through to results.clone(**kwargs))
[05:18] <kiko> okay but that's a larger change
[05:18] <kiko> yes, it works
[05:18] <spiv> If it's more complex, it's probably not worth it.
[05:18] <spiv> It's more likely to have unexpected side effects too.
[05:19] <spiv> Ah well.
[05:19] <spiv> kiko: I'll take the rest of this review to email.
[05:20] <kiko> spiv, I'll get you a new diff
[05:20] <spiv> Heh, ok.
[05:20] <kiko> spiv, https://chinstrap.ubuntu.com/~dsilvers/paste/filetl1mio.html
[05:45] <kiko> stub, please remember to clean up the dupe shipit queries so we can have a fresh oops report tomorrow
[05:45] <kiko> spiv, looking that bad?
[05:46] <spiv> kiko: nah, I spent a bit of time going "that's wrong! rant, edit, ... oh, it's actually only slightly wrong, delete that and put small comment there instead."
[05:46] <spiv> ;)
[05:47] <kiko> nothing gives you the same pleasure as deleting bits of horrible code
[05:48] <matsubara> kiko: stub already did it. I talked to him early today.
[05:49] <kiko> ah rock on
[05:56] <spiv> kiko: review sent
[05:59] <kiko> thanks!
[06:07] <spiv> kiko: btw, when prejoin stuff going to be submitted to upstream?
[06:08] <spiv> kiko: was it prejoins or something else jdahlin was going to push upstream?
[06:09] <kiko> prejoins, yes
[06:09] <kiko> he has some nokia work to finish off this week and then he was going to do it
[06:10] <spiv> Cool.
[06:18] <ddaa> the cscvs code makes pychecker crash...
[06:18] <ddaa> how ironic
[06:19] <spiv> ddaa: that's not as unusual as it should be :(
[06:19] <spiv> pyflakes is less flaky
[06:19] <ddaa> pyflakes does not report pep8 outrages
[06:20] <ddaa> btw, nice trick: python -tt `which pyflakes` file.py
[06:20] <ddaa> checks for flakes and tabs in one command
[06:21] <elmo> pyflakes is outrageously useless
[06:21] <elmo> pylint is nice if you turn off some of the more random stylistic nitpicks
[06:22] <ddaa> python is all about stylistic nitpicks
[06:22] <spiv> And I'm sleepy!  G'night all.
[06:22] <ddaa> the more you encode style into the law, the less people waste time arguing about style
[06:22] <ddaa> pep8 is a great feature of python
[06:39] <kiko> spiv, I hate SQLObject's stupid styles crap
[07:11] <clahey> https://launchpad.net/distros/ubuntu/+translations
[07:11] <clahey> What does it mean "If Ubuntu is using launchpad for translations"?
[07:11] <clahey> Don't we know that it is?  :)
[07:25] <clahey> kiko: So, we'd like to try out rosetta.
[07:26] <clahey> kiko: Do we just register as a product in launchpad, or is there an application process?
[07:28] <clahey> kiko: Oh, does Rosetta handle plural forms properly?
[07:28] <carlos> clahey: what do you want to try?
[07:28] <carlos> rosetta usability? or translate your own project?
[07:28] <clahey> carlos: So, I work on Democracy Player and we would like to translate our project.
[07:28] <carlos> clahey: yeah, the gettext plural forms
[07:28] <clahey> Excellent on plurals.
[07:28] <carlos> clahey: I guess it uses .po files and gettext, right?
[07:28] <clahey> So, I was hoping we could create a Rosetta project and then try out the interface for a day or two before we announce it to our people.
[07:28] <clahey> Yep.
[07:29] <clahey> I know that it would show up on the Rosetta pages before we announced it.
[07:29] <carlos> clahey: you need to follow the instructions at wiki.ubuntu.com/RosettaFAQ
[07:29] <clahey> Oh, if I upload a new .pot file, does it do the msgmerge, or should I do that by hand and just upload new copies of all of the translations?
[07:30] <carlos> clahey: we do the merge
[07:30] <carlos> all .po files are updated automatically when you upload a new .pot file
[07:30] <carlos> so translators will work always with latest strings
[07:31] <clahey> Excellent.
[07:31] <clahey> Do you happen to know what happens if we accidentally delete some strings from the pot file and add them back in the next upload?
[07:32] <carlos> no translation will be removed
[07:32] <carlos> they will be hidden until you upload the fixed .pot file again
[07:34] <clahey> Perfect.
[07:34] <clahey> Oh, so the policy page says that Rosetta translators will take care of the translations.
[07:34] <clahey> What about the people we have that want to translate our app (or have already started?)
[07:35] <clahey> Do we get to create accounts for them and mark them as official for our product?
[07:35] <carlos> clahey: we encorage people to use Ubuntu translators teams
[07:35] <carlos> clahey: they would join those teams
[07:36] <carlos> and translate your product
[07:36] <carlos> another option is leave it open to anyone to do translations
[07:36] <clahey> So we can't create accounts for them, but you could?
[07:36] <clahey> Ah, so either everyone can translate or only "Ubuntu translators team"?
[07:36] <carlos> well, anyone can create their own account
[07:36] <carlos> we have a third option
[07:37] <carlos> create translation teams for your product
[07:37] <carlos> but usually, we think is better to use Ubuntu teams
[07:37] <carlos> clahey: but you have the last word on it
[07:37] <carlos> you are the owner of your product
[07:38] <clahey> Can we mark our text as translatable by either the Ubuntu translation team or our own?
[07:38] <carlos> clahey: yes
[07:38] <carlos> clahey: adding Ubuntu teams as a subteam of yours
[07:39] <clahey> Cool.
[07:39] <clahey> We can decide on which of those to do.
[07:40] <clahey> I wonder if I can get a 639 code for Pig Latin.
[07:41] <carlos> clahey: our FAQ has documented what do you need to do to get such iso code
[07:42] <clahey> I'm filling out the form right now.
[07:42] <clahey> I just need to get a source of lots of documents.
[07:44] <clahey> Bible translation should help.
[07:44] <clahey> Anyway, that's a waste of time.
[07:47] <clahey> The FAQ isn't clear to me what to do once I've "mailed the upstream maintainers", which is of course, unnecessary as that's me.
[07:47] <clahey> Well, the team I'm on...
[07:52] <SteveA> hi.  anyone want to hassle me before i make dinner and then get back into the hacking-zone ?
[07:54] <SteveA> do i know you?
[07:54] <kiko> you know who I am bru
[07:54] <clahey> carlos, kiko: How do I submit a project?  Just register it under launchpad?
[07:55] <kiko> clahey, yes. it is likely what you want is products/+new
[08:01] <clahey> kiko: I'm asking one of my coworkers, Greg Opperman to take care of applying to that.  Thanks for all the information.
[08:02] <kiko> no problem, feel free to ask further.
[08:07] <kiko> DSP is evil incarnate
[08:36] <clahey> kiko: Oh my.  I just submitted to get pgl added to ISO 639.
[08:38] <kiko> pig latin? really now
[08:38] <clahey> kiko: I use it to test translation work and it would be helpful to me if it were an official language.
[09:09] <bradb> matsubara: Is pqm hung on your branch?
[09:09] <matsubara> bradb: I don't know I sent it a couple of hours ago and I'm not following its progress
[09:09] <matsubara> bradb: doesn't seem to be hung
[09:10] <bradb> A couple, i.e. six :)
[09:10] <matsubara> hehe but there was like 5 others ahead of me on the queue
[09:11] <bradb> ok, that would make more sense
[09:11] <kiko> bradb, no, but the branch above it hung at the end
[09:11] <bradb> ah
[09:11] <kiko> and it is likely that it will hang as well
[09:11] <kiko> and it is likely that the branch after it too
[09:11] <kiko> and then maybe it will stop hanging
[09:17] <bradb> kiko: I just saw your comment on bug 47544. i already submitted the fix to pqm.
[09:17] <Ubugtu> Malone bug 47544 in malone "Malone reports that a package has no security contact...DUH!" [Normal,In progress]  http://launchpad.net/bugs/47544
[09:18] <bradb> it wasn't taken, so i took it
[09:18] <kiko> well done
[09:19] <bradb> interesting bzr message: bzr: WARNING: Conflict adding files to lib/canonical/rosetta.  Not deleting.
[09:20] <bradb> "I can't add files to this directory. Not deleting." wha?
[09:20] <kiko> the message is bad
[09:21] <bradb> I know what it really means, of course, but that was an interesting contradiction.
[09:21] <kiko> I think it means that the directory was removed but you still have some ignored files in it.
[09:21] <bradb> yeah
[09:29] <clahey> kiko: Cool.  I've uploaded our translations.  They're just waiting for an admin.  Very cool.
[09:31] <kiko> nice! carlos, jordi? can you take care of the upload?
[09:57] <kiko> carlos, do you know why we have this horrible iterable API on POTemplate?
[09:58] <kiko> carlos, I find it so completely absurdly incomprehensible
[10:06] <ddaa> elmo: Znarl: ping there's a nc in need of killing in pqm
[10:08] <ddaa> if the fix is right, it should be the last one
[10:09] <Znarl> ddaa : Done.
[10:11] <kiko> ddaa, hoping :)
[10:16] <ddaa> I'm sure other test suite will find creative ways of screwing up
[10:26] <carlos> kiko: hi, I'm back
[10:26] <carlos> kiko: are you talking about POTemplate and POTemplateSet ?
[10:27] <carlos> clahey: let me take a look...
[10:27] <kiko> POTemplate
[10:29] <carlos> POTemplate.__iter__ ?
[10:29] <kiko> yes
[10:29] <kiko> and __len__
[10:29] <kiko> and __getitem__
[10:30] <kiko> aka CRACK
[10:32] <ddaa> mmmmmh, crack
[10:32] <carlos> kiko: well...
[10:32] <SteveA> remember what leonard cohen said
[10:32] <SteveA> "give me crack and anal sex".  but remember that he also said:
[10:32] <carlos> I don't think those are perfect, but could you give me some extra information about your point?
[10:32] <SteveA> "there's a crack in everything.  that's how the light gets in"
[10:33] <ddaa> that's why banging your head against the walls helps you see the light?
[10:34] <kiko> carlos, use explicit method names. you should really only implement the iterable interface for stuff which is obviously iterable.
[10:34] <carlos> kiko: you iterate over all messages that a POTemplate has
[10:34] <kiko> carlos, that's just not a good enough reason. :)
[10:34] <carlos> kiko: why?
[10:35] <mpt_> Goooooooooooooooooooooood morning Launchpadders!
[10:35] <carlos> kiko: you can iterate a list
[10:35] <kiko> carlos, because unless there is a strong reason to /implement/ the iterable API, you shouldn't do it.
[10:35] <carlos> and a POTemplate is a list of messages...
[10:35] <kiko> and in this case, there is no strong reason.
[10:35] <SteveA> mpt_: hallo
[10:35] <kiko> you could reimplement it using normal methods
[10:35] <kiko> and you'd survive with no harm done
[10:35] <SteveA> mpt_: can i borrow you for some menus love?
[10:36] <carlos> kiko: could you explain me why there is no strong reason, or better, give me an example of what do you think it's an strong reason?
[10:36] <carlos> kiko: same thing for all __getitem__, __len__, __iter__, etc...
[10:36] <carlos> you can always do it with normal methods
[10:37] <SteveA> the main reason i can think of is
[10:37] <SteveA> the contract for a single method is simpler
[10:37] <SteveA> than remembering the interrelationships between these
[10:38] <carlos> kiko: I'm not saying that you are wrong, I just want that you are able to give me a reason about why should I change it
[10:38] <malcc> I would argue that a POTemplate is not "is" a list of messages, it "has" a list of messages, in terms of the is-a vs. has-a OO debate
[10:39] <carlos> SteveA, kiko: Following that fact (I think I agree on that), why or when should we use the __iter__ or __getitem__ methods then?
[10:39] <kiko> carlos, the convenience of using len() and iterating over it is less than the inconvenience of finding out it doesn't behave like a real iterable -- i.e. no append, indexed updating, etc.
[10:40] <kiko> carlos, it communicates a weak truth
[10:40] <SteveA> kiko: an iterable doesn't necessarily have these things
[10:40] <SteveA> that's python
[10:40] <kiko> I know
[10:40] <carlos> malcc: the format is just a list of messages, nothing more, even the metadata is a message, but with our implementation is not completely true...
[10:40] <SteveA> that's why we have interfaces and protocols
[10:41] <SteveA> so, i don't buy the "weak truth" argument
[10:41] <SteveA> i do buy malc's "is-a vs has-a"
[10:41] <carlos> kiko: so you are complaining about missing methods that are implied if we use __getitem__ and __iter__, right?
[10:41] <kiko> the potemplate is not just a box of strings
[10:41] <kiko> it is a pretty complex creature
[10:41] <kiko> saying it's an iterable implies it is a box of something
[10:42] <kiko> that's my gut feeling over it.
[10:42] <SteveA> kiko: that's the is-a vs has-a argument
[10:42] <kiko> in part yes.
[10:43] <kiko> in part what I'm saying is that iterables are/should be simple, because they imply they are simple containers, with fairly simple semantics. well, for some definition of fairly. :)
[10:43] <SteveA> the "missing methods" thing we can do *if* you write an interface for a "standard launchpad collection"
[10:43] <SteveA> and we start using that
[10:43] <kiko> I am not suggesting adding append() to POTemplate!
[10:43] <SteveA> i'll note that in my opinion, the Container protocol in Zope 3 causes more harm than good
[10:43] <SteveA> so, care needs to be taken in standardizing interfaces to collections
[10:45] <SteveA> i buy an argument of simplifying the API for potemplates etc.
[10:45] <carlos> kiko: anyway, switch to explicit methods should be easy, as you can see, those special methods call other explicit methods already (or most of them do it)
[10:45] <kiko> carlos, yeah, it should. 
[10:45] <SteveA> i do not buy that iterables should be simple or that something being iterable implies it is a simple container with simple semantics
[10:45] <kiko> it's not a priority, just something I found very confusing when reading the code.
[10:46] <SteveA> although i'm willing to be convinced sometime
[10:46] <kiko> SteveA, I maintain that complex iterables are asking for trouble, in my heart.
[10:46] <carlos> what I'm not completely sure now is when should I use those special methods
[10:46] <kiko> carlos, rule of them, never unless the class /is/ a simple container.
[10:47] <carlos> because from what you told me, most of the time if you can use __iter__ is more or less when you have a list
[10:47] <carlos> or a set
[10:47] <kiko> right
[10:47] <SteveA> ain't true
[10:47] <carlos> in those cases, why don't just use a list or a set directly?
[10:47] <SteveA> there are lots of iterators in python that aren't lists or sets
[10:47] <SteveA> that's the point of having a separate iteration protocol in python
[10:47] <kiko> wait
[10:47] <SteveA> so that you can use things in for-loops directly
[10:48] <kiko> I'm not against returning iterators
[10:48] <kiko> or using generators
[10:48] <carlos> SteveA, kiko: would TranslationImportQueue be a valid candidate for __iter__ ?
[10:48] <kiko> but I am against a complex class implementing __iter__
[10:48] <kiko> because the syntactic sugar isn't worth the confusion
[10:48] <kiko> IMO no
[10:49] <carlos> kiko: but that IS a list of elements
[10:49] <carlos> is a queue
[10:49] <carlos> and its only content is a set of elements
[10:49] <kiko> so it /has/ a set of elements
[10:49] <carlos> it fits the 'is-a' description that malcc was talking about
[10:50] <carlos> I'm really confused
[10:50] <SteveA> i think it is reasonable to __iter__ a queue
[10:50] <kiko> it also contains a truckload and a half of code and attributes that are not directly tied to its function as a queue.
[10:50] <kiko> it's not a simple queue
[10:50] <SteveA> a queue is a basic data type and so passes *everyone's* tests so far
[10:50] <kiko> not a knuth-style queue
[10:50] <malcc> Yes, but its function as a queue is clearly its main one, hence its name
[10:50] <malcc> I would be happy with a queue being iterable, unless there were issues in the ORM which made that painful
[10:51] <kiko> not really
[10:51] <kiko> the ORM is permissive!
[10:51] <SteveA> kiko: this is going to require a specification if you want to make this launchpad policy
[10:51] <kiko> anyway, I actually have a review to finish
[10:51] <SteveA> and i'll want the code review team to have input on it
[10:51] <kiko> I don't want to make it anything like that!
[10:51] <carlos> kiko: it has no attributes at all
[10:51] <carlos> kiko: only methods to operate its elements
[10:51] <SteveA> i think it make be worth doing, if you find such code confusing
[10:51] <kiko> carlos, errr, right I'm looking at TIQE :)
[10:52] <carlos> kiko: ;-)
[10:52] <kiko> SteveA, I started on this because I'm looking for len()s in our codebase that are triggering trouble, and len(self.potemplate) caught my eye
[10:52] <kiko> but now I SWEAR I will go back to reviewing
[10:52] <kiko> DND
[10:52] <malcc> kiko: You don't want to go looking for trouble. You might find it :)
[10:52] <carlos> kiko: I would be happy removing len(self.potemplate)
[10:53] <carlos> I already removed len(self.pofile)
[10:53] <kiko> malcc, yeah, jesus, SteveA and you are supposed to be in bed at this point
[10:53] <carlos> because it was completely useless
[10:53] <kiko> it was a completely harmless rant!
[10:53] <SteveA> wem
[10:53] <SteveA> i'm sure malc is cute
[10:53] <SteveA> but i'm not takeing him to bed
[10:54] <carlos> ;-)
[10:54] <SteveA> although jesus i'll make an exception for
[10:54] <SteveA> and i don't know this "yeah" character
[10:54] <kiko> fofl
[10:56] <carlos> clahey: hi, around?
[10:56] <clahey> carlos: Yep.
[10:56] <clahey> Hi.
[10:57] <carlos> clahey: could you tell me the translation domain you are using for your application?
[10:57] <carlos> the one that gettext uses to find the translations
[10:57] <clahey> One sec.
[10:58] <clahey> democracyplayer
[10:58] <clahey> Should I rename messages.pot
[10:58] <clahey> ?
[10:58] <carlos> no, don't worry
[11:00] <ddaa> it's probably to help mellowing down after the crack...
[11:02] <carlos> clahey: ok, the .pot file is now imported and the .po files will be imported in 10 minutes
[11:02] <carlos> clahey: https://launchpad.net/products/democracy/trunk/+pots/democracyplayer/
[11:03] <clahey> How would a user go about translating to a new language?
[11:04] <kiko> clahey, the list displayed is the user's default languages
[11:04] <kiko> so I see English, French, Georgian, Italian, Polish and pt_BR
[11:04] <carlos> clahey: they will get the option from their browser preferences/ languages spoken in their country or based on their preferences from https://launchpad.net/rosetta/prefs/
[11:05] <clahey> Ah, that's why it lists the 4 languages we have translated already and Russian for me.
[11:06] <carlos> clahey: right
[11:06] <kiko> clahey, just because I'm your friend I've just added 10 pt_BR strings :)
[11:07] <clahey> :)
[11:08] <clahey> Excellent.  :)
[11:08] <kiko> 109 strings is so easy 
[11:09] <carlos> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileWKtqId.html
[11:09] <clahey> Yeah, there'll be more.
[11:09] <carlos> kiko: If you are not able to answer that question yourself... you wrote bad code or you don't remember the reason you wrote it that way ;-)
[11:10] <kiko> carlos, I don't even remember my birthday
[11:10] <carlos> kiko: :-P
[11:10] <carlos> kiko: if you don't have a batch object
[11:10] <carlos> you cannot return any link
[11:10] <carlos> so you return the empty string
[11:11] <carlos> that means that you use current url
[11:11] <carlos> so if you are at http://foo.bar.com/something
[11:11] <carlos> the link will be the same page
[11:11] <carlos> I think it makes sense and thus, I'm doing exactly the same thing the parent class is doing ;-)
[11:12] <carlos> kiko: anyway, I will answer that email and that concrete question tomorrow ;-)
[11:13] <carlos> kiko: thanks for the review
[11:13] <kiko> sure no problem at all
[11:14] <carlos> clahey: all files are imported now
[11:15] <carlos> clahey: and you are getting en_GB translations already...
[11:15] <clahey> carlos: I saw that.  Crazy cool.
[11:16] <carlos> good night!!
[12:00] <clahey> Do you guys run pofilter at all?