[12:03] stub! [12:03] how's it going? [12:11] kiko: Silently! Like warty and before it hoary, Breezy has decided that some applications should not make noise. Such as gaim. [12:15] that's weird. i'm marking some strings in rosetta to be reviewed, and it's not saving its state [12:22] stub, I have a patch here to transfer team membership records when merging accounts. can I mail it to you and you tell me if it is okay? [12:29] segfault, really? and no system error? [12:29] stub: hehe, do you mean you cannot setup sound on your breezy machine? [12:29] kiko ! [12:30] kiko: you recall you told me that if I need anything out from the launchpad devel mailing list you might be able to grab? [12:30] sivang, no, but yeah. :) [12:31] sivang: Gnome sound is not working. Other sound is working just fine. It seems to be a tradition now. [12:32] So I can happily play music and not have to listen to kiko whine ;) [12:33] stub: hehe :) [12:35] stub, did carlos' script finish running successfully? [12:37] stub: well, I have no problem at all on a dell laptop, weird [12:38] kiko: First section worked fine. Second part (cleanup) died with integrity constraints. === stub checks to see if his fixes were in carlos' branch [12:39] kiko: has their been any discussion about the support tool ? [12:40] bah - don't have the branch around any more === stub reboots [12:41] stub, if you can help get the script running I'd love you === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad [12:45] kiko: if you can, just mail me (my email is in lp) I'm off to bed :) [12:45] good night all! [12:49] sivang, no, but you can see in staging an initial version of the ticket tracker has landed, thanks to sabdfl [12:54] kiko: no errors [12:57] product name: ubuntu-doc, but its sources are named ubuntu-docs [12:58] https://launchpad.net/distros/ubuntu/breezy/+sources/ubuntu-docs/+pots/aboutubuntu/pt_BR/+translate [12:58] segfault, could you file a bug for us? that's most unexpected. [01:05] yup. [01:09] done [01:09] #2242 [01:10] thanks segfault, you da man [01:11] haha [01:11] sei.. === stub [n=stub@203.214.4.72] has joined #launchpad === rbelem-sun4u [n=rodrigo@200.231.242.135] has joined #launchpad === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad === sabdfl [n=mark@host217-37-231-22.in-addr.btopenworld.com] has joined #launchpad [02:39] evening all [02:39] wot's potting in launchpad land? [02:41] not a lot as you can see [02:41] I'm trying to go home [02:41] but the barrage of email prevents me to [02:41] sabdfl, there's some email from me requiring some of your attention [02:41] I'd be x-grateful if you could give me a few minutes of your day tomorrow to help me [02:42] and now, without further ado, I adjourn this meeting [03:08] kiko-zzz: ok, willdo [03:08] night === JanC [n=janc@lugwv/member/JanC] has joined #launchpad === sivang [n=sivang@box79162.elkhouse.de] has joined #launchpad === sladen [i=paul@starsky.19inch.net] has joined #launchpad === jblack [i=jblack@static-209-158-45-74.scr.east.verizon.net] has joined #launchpad === sivang_ [n=sivang@box79162.elkhouse.de] has joined #launchpad === JanC [n=janc@dD5E086DA.access.telenet.be] has joined #launchpad === rbelem-sun4u is now known as rbelem-zzz === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad [05:39] hmm. chinstrap doesn't seem to like me [05:39] don't take it personally [05:41] seems better now [05:41] yeah, I think you were just unlucky [05:41] because it's a bastion host, we hit the "max startups" limit sometimes [05:45] elmo: Steve said there might have been issues with Pound before? [05:45] stub: oh, we had lots of fun [05:45] Is it just that Pound does not know when Launchpad is not responsive because it keeps happily accepting new connections? [05:46] that was the pound issue, steve said, yeah [05:49] elmo: I also have something here about troubles having Pound only talk to one Launchpad backend. Would that be the same issue? [05:49] yeah, that was probably a red herring [05:49] sorry, it was all very hectic, and I didn't have time to debug/take notes [05:50] ok. So the Pound setup looks fine, but we might have some tweaking with the Launchpad environment. [05:50] I've got here: restart script didn't restart because the rogue process was keeping the port open, and no core dumps because ulimit is 0 [05:51] well, 'initscript restart' definitely didn't kill the original suspect/hung process [05:51] and nagios should be checking the backends as well as just the front end. [05:51] how do I check the backends? [05:52] It is supposed to, although it looks for pid files rather than scanning the process table. I thought it was solid enough, but might need work. [05:52] re: nagios, you probably can't at the moment because the servers will be listening on the loopback address. [05:53] that's ok [05:53] the nagios checks run locally [05:53] I mean, do I just feed them normal http? if so, what's a good URL? [05:53] But if I fix that, you can test the backend servers individually on their ports (http://gangotri:9031/, http://gangotri:9032) [05:53] ok [05:53] Yer - just the root should be fine. We can make a special page at some point, but for now the root page will do. [05:53] pls don't fix them, I like them on loopback only :) [05:54] ok ;) [05:55] Do you know what I need to add to the initscript to allow the spawned processes to dump core? [05:56] 'ulimit -c somebignumber' ? [05:56] at the top of the script, AFAIK should affect all spawned children [05:59] ulimit -c unlimited [05:59] Just set an rt request re: the nagios stoof [05:59] cheers [05:59] if you want to make sure the core files don't get truncated === spiv wonders why rosetta-export-queue.py is getting "ProgrammingError: ERROR: could not serialize access due to concurrent update [05:59] UPDATE POFile SET exportfile = 356375, exporttime = CURRENT_TIMESTAMP AT TIME ZONE 'UTC' WHERE id = 92269 [05:59] " sometimes. [06:00] spiv: what else is it doing in the transaction? [06:02] Not sure. The export code is pretty involved. [06:02] spiv: It is conflicting with another process [06:02] spiv: Those errors are expected, and in general you should retry the transaction [06:02] stub: Something else is updating that row? [06:03] spiv: or reading that row + updating a row the first transaction read [06:03] The other cute thing is that then it tries to email the user to tell them there was a problem, but can't because it can't get the email address any more because the transaction is buggered :) [06:03] spiv: Something else *has* updated that row, making the select results the process saw previously now invalid. So serializable transaction isolation has been violated and it is saying 'try again' [06:04] I need to make the Z3 server retry the request when it is raised. Scripts should do similar, or just die and wait until the next time their cronjob kicks in. [06:04] Or not run in serialized transaction isolation, which is probably overkill for most of our stuff [06:04] Any idea which particular process might be conflicting? Presumably it will be getting these errors occasionally too. [06:05] I guess there's lots of things that hit POFile. [06:05] if transaction 1 reads row A and writes to row B, while transaction 2 reads row B and writes to row A, one of the transactions will fail [06:05] http://www.redhat.com/docs/manuals/database/RHDB-2.1-Manual/admin_user/xact-serializable.html [06:06] since the database assumes that the write depends on the previous read in the transaction [06:06] spiv: Could be anything, including the Launchpad instance. [06:06] (well... anything Rosetta or statistician related) === spiv nods [06:09] So either retry, reduce transaction isolation to 'read committed' instead of 'serializable', or lock the table [06:10] Hmm... although I too can't see what would be causing that particular query to die this way :-/ [06:10] It's the second one of these I've seen in recent days. [06:20] I suspect reducing the transaction isolation would be the best bet where retrying isn't possible or appropriate. Stuff like the statistician or karma updater really don't need that sort of protection. [06:25] for a lot of scripts, switching to implicitBegin=False mode might help with those sort of problems [06:29] what the hell is mark doing? [06:29] he's the one that keeps locking up chinstrap [06:30] sabdfl: ping? === _Rappy_ [n=hunt-pre@dsl-253-122.monet.no] has joined #launchpad === superted [n=superted@213.167.101.222] has joined #launchpad === segfault [i=carlos@prognus.com.br] has joined #launchpad === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad === ddaa [n=ddaa@ordo.xlii.org] has joined #launchpad [08:30] spiv: ping [08:43] pong [08:46] librarian rosetta issues [08:46] what's it all about? === ddaa [n=ddaa@ordo.xlii.org] has joined #launchpad [08:50] The rosetta exporter adds files the librarian, commits, and then shortly afterwards hits the librarian for the same file, and the librarian says 404, which means that for some reason the transaction the librarian started for the web request didn't see the newly added row. [08:50] But only sometimes. [08:51] any idea what causes it? [08:54] Perhaps the exporter trying to export the same file twice in the same transaction. That doesn't appear to be the case, although it's hard to tell because the export logic is fairly involved. [08:56] (And carlos doesn't think that's likely either) [08:57] have you tried to reproduce the problem? [08:58] I have; it doesn't reproduce locally for me with the steps carlos suggested. [08:58] while 1: stick_file_in_librarian(); commit(); get_file_from_librarian() ? [08:59] Hmm. That sort of stress test probably isn't a bad idea. [09:00] can you add some logging to the librarian [09:00] to say when it has files added, when it has files requested [09:01] and when files get totally written to disk and finished with [09:01] It already logs HTTP requests, so the "when it has files requested" is already there. [09:01] maybe there's a buffer somewhere that is making some process think it has finished, and fully put the file on the filesystem, but it has not [09:02] the main thing is to see in detail what's involved in writes [09:02] I'll double-check, but 404 should only mean "not in database". If it's in the database and not on the filesystem, that's a more serious error. [09:02] In fact, I'll write a test for that. [09:03] can you make the librarian, if it gets a missing row, to wait .5 seconds and then try again? [09:03] and of course log that it has done so [09:03] I could. I could do the same on the client end, too. [09:04] in case we have a race between the end of a rosetta transaction and postgres making the data available to other code. [09:04] um, other connections [09:04] Another option would be to make the librarian cache information about files that were just uploaded to it. [09:06] Doing con.set_transaction_isolation(1) would be a good diagnosis on if this is a transactional issue (possibly twisted not resetting database connections properly for example), and should be a minimal change we can test quickly [09:06] (Although that's adding more complexity to the system) [09:07] well, keeping a cache of information about files recently uploaded, and doing diagnostics / race avoidence on a 404 for those, would work to track this all down [09:07] so, andrew, let's write up the plans on a wiki page [09:08] we have a number of theories about what could be going wrong [09:08] - issues with transactions not being properly reset in twisted [09:08] SteveA: When the futex issue hits (which I have still to personally see), does the process lock or just one of the threads? [09:08] - a race in postgresql between one connection committing and another wanting to see the same issue [09:08] stub: i don't know if it was a futex yesterday. no core dump. [09:09] SteveA: That isn't answering my question ;) [09:09] stub: symptoms were that you can get a TCP connection, GET something, and then a hang [09:10] Are you talking about the futex issue people have seen in the past, or what happened yesterday? [09:10] - some problem with the librarian getting stressed out === stub is interested in the futex issue people have seen in the past, in case that tells him something about the hang yesterday [09:10] spiv: so, we have discussed ways to diagnose the problem, and progressively confirm or reject the theories of what might be going wrong [09:11] stub: what happened yesterday, and i think also what happened in the past [09:11] my memory of old futex issues is hazy [09:12] SteveA: Hmm, I think the bug report in maloneis a better place for that than a wiki page. [09:12] spiv: fine [09:12] But otherwise, I agree. [09:12] so long as it is written up for others to see === spiv nods [09:12] Ok - so there is nothing to suggest the hang had anything todo with futexes. === spiv waits for baz switch to give him his system back [09:28] stub: other than it requiring a kill -9 [09:30] ok. Nobody had mentioned that ;) [09:30] i'm pretty sure elmo killed it -9 [09:30] after trying to restart it using the script [09:30] and that failing [09:31] i'll mail you the log [09:32] mailed [09:38] Ta. [09:38] I need to tell elmo he can be more viscious - it doesn't matter if he kills any of the cronscripts (they will respawn again later). === Keybuk [n=scott@217.205.109.249] has joined #launchpad === dand [n=dand@gw.datagroup.ro] has joined #launchpad [09:57] moin moin [09:59] elmo: pong === sabdfl [n=mark@pdpc/supporter/silver/sabdfl] has left #launchpad [] [10:02] SteveA: just sent a possible fix for the test_reconnector.txt timeout issues [10:02] cool === niemeyer [n=niemeyer@217.205.109.249] has joined #launchpad [10:11] jamesh: why did you put the after_select.set() before the thread_result.append(cur.fetchone()[0] ) ? [10:12] SteveA: looks like a mistake -- I just added the event.set() calls around the call that would hang [10:12] should be afterwards [10:13] it looks like a good improvement, though [10:13] spiv: can you take a quick look? [10:13] a bunch of the other tests under canonical/database are using time.sleep() too [10:14] could probably be fixed in a similar fashion [10:15] please do it [10:15] it ought to speed up the test suite a bit [10:17] it also looks like the wait_until_proxy_is_ready() and wait_until_proxy_is_stopped() functions in that test busy-wait too [10:17] which can't be good [10:44] lifeless: Can you please mirror the newly tagged rocketfuel@canonical.com/launchpad--production--1.32 [10:44] done [10:51] morning all [10:53] how can I reach staging of launchpad? I want to have a first look at the new issue tracker :) === Seveas [n=seveas@dyn127.roaming.few.vu.nl] has joined #launchpad [10:54] I'm pretty sure it's restricted to people with a special cert [10:54] eh.. [10:54] I see [10:54] ie canonical employees === sabdfl [n=mark@217.205.109.249] has joined #launchpad [10:54] and it's broken atm, anyway [10:55] erk [10:55] anybody else tried to "make" launchpad on Breezy? I think there's a gcc problem [10:55] doesn't show up if you just upgrade, because the old binaries still owkr [10:55] on building zope3? [10:55] work, even [10:55] yes [10:55] gustavo has a patch for it [10:55] taken from upstream [10:56] where can i find that? [10:56] i have forwarded you two emails [10:56] bob2 says staging is down [10:56] one with the small patch [10:56] and the other with the things gustavo had to do to get launchpad running on breezy [10:57] bob2: is this the same cert that you need in order to access RT? [10:57] i'll apply the patch to zope now [10:57] as i intend to upgrade to breezy over the weekend [10:57] I've never used canonical RT [10:58] i wonder if we can open staging up a bit more? [10:58] would be nice to do so [10:58] it would help people who report bugs on launchpad to see when they've been fixed in the code [10:58] stub: what do you think? [10:59] lifeless: That GCC bug was fixed in that Z3 merge I emailed to you to do [10:59] stub: will do today [10:59] oh, so no point in my applying it in a branch and asking pqm to merge it? [11:00] stub: unless its urgent? Is it ? [11:00] SteveA: Nope [11:00] lifeless: Not for me ;) People running breezy need to manually apply that patch though if they want to 'make build' launchpad [11:00] its in my todo queue [11:01] Yer... staging dead [11:01] sabdfl: is there anyway you could let me see the new issue tracker? you recall our talk about abstraction levels for an issue tracker (some of them are now in MaloneSupportIntegration) , to make report issue --> bug report result with as most useful data etc.. , I'd like to see where this can be possibly integrated in the tracker :) [11:01] SteveA: good idea to open up staging [11:01] it should be staging.launchpad.net [11:02] elmo: ^ kthxbye ;-) [11:02] Hmm... probably forgot to restart it after doing a db sync earlier [11:02] sivang: it's landed, just not rolled out to production yet (prob today) [11:02] sivang: if you can see https://staging.launchpad.canonical.com then its there [11:03] we should open staging up to general viewing, it has yesterday's code + data so is a good way to see what just landed [11:03] https://staging.ubuntu.com/ is where it should be right now [11:03] What do people mean by 'open up staging'? It is already world accessible (we had to install a robots.txt to ensure it doesn't end up in google) [11:03] stub: people were thinking it was cert protected [11:04] stub: system error on front page of staging [11:04] SteveA: that was the bad gateway error? [11:04] sabdfl: yay! thanks [11:04] no, another error [11:05] Yer - getting there [11:05] dogfood is the only one not visible to the world [11:05] do we have a wiki page about staging? [11:05] not the mechanics of it, but what it is, what it shows, what it is for [11:06] sabdfl: hrm, s.l.c.m seems unreachable, s.u.c gives System Error [11:06] sivang, ok, could you ping elmo when he's online in a few hours? [11:06] sivang: https://staging.ubuntu.com/ but, stu is still making it work [11:06] sivang: you are seeing staging. it is giving a system error right now. [11:07] or rather, a bad gateway right at this moment. stuart is sorting it out. [11:08] sabdfl: sure, unless it gets sorted before === BjornT [i=10183@82-135-221-189.ip.takas.lt] has joined #launchpad === Seveas [n=seveas@dyn127.roaming.few.vu.nl] has joined #launchpad [11:19] Staging all resynced and running [11:22] stub: synced with what? [11:22] i mean, what patch level is staging running? [11:26] SteveA: trunk as of a few minutes ago [11:26] thanks === jinty [n=jinty@205.134.224.215] has joined #launchpad === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [11:43] spiv: do you have any idea of the reason for the time.sleep() calls in canonical/lp/ftests/test_zopeless.py? [11:46] it looks like 10 wasted seconds in "make check" === rbelem-zzz [n=rodrigo@200.231.242.135] has joined #launchpad === terrex [n=terrex@84-122-83-29.onocable.ono.com] has joined #launchpad === terrex [n=terrex@84-122-83-29.onocable.ono.com] has joined #launchpad === terrex [n=terrex@84-122-83-29.onocable.ono.com] has left #launchpad ["Hasta] === terrex [n=terrex@84-122-83-29.onocable.ono.com] has joined #launchpad [01:04] jamesh: mind if I cast an eye over your gpg trust importer branch? === stub [n=stub@203.214.4.72] has joined #launchpad [01:16] Kinnison: go for it [01:16] what is the primary script? [01:17] find-email-clusters? [01:19] find-email-clusters does web of trust processing and outputs the email address clusters [01:19] merge-email-clusters updates the database from those clusters [01:24] cool, thanks [01:24] I just want to check the logic for the cluster finding really [01:25] which I assume is in canonical.launchpad.scripts.keyringtrustanalyser === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:40] stub: hmm, new fonts, style sheet? text looks smallr [01:43] Could be - mpt would know details and rationale for any recent changes === Lovechild [n=dnielsen@love-sources/Lovechild] has joined #launchpad === BjornT heads out for a while === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:17] Morning all === mpt pokes kiko-zzz === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:20] the update from staging is today, right? === gneuman [n=guest@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:29] Nafallo: should be [02:29] I hope it is :) [02:30] it haven't happen yet it seems ;-) [02:30] Nafallo, jordi, in fact I think it's going to be tomorrow (only this week) [02:31] hehe [02:33] salgado: nod [02:37] elmo, pqm's stuck again [02:40] go pwm [02:40] pqm too [02:40] kicked [02:41] we all live pqm [02:41] love, bah [02:43] how do I introduce a TAB in Rosetta?:) [02:49] WaterSevenUb: If the source string contains a tab, Rosetta gives you instructions on how to enter a tab right underneath that field [02:49] WaterSevenUb: And if the source string doesn't contain a tab character, why are you wanting to use one in your translation? :-) [02:51] mpt, ok ok :-D Thanks :) [02:54] mpt, and when appears a translation_credits string to translate, the note says to include the name of the translator one per line, but you shouldn't do that, right? If you should, how do you make a new line?:) [02:56] is lp out of action? [02:58] WaterSevenUb: It's a multi-line field, right? If so, the Enter key should work. [02:59] mpt, nope... it's a one-line field. [03:02] WaterSevenUb: That sounds like a bug ... Could you report it, giving the URL of the page? https://launchpad.net/products/rosetta/+bugs [03:03] WaterSevenUb: https://launchpad.net/products/rosetta/+filebug, even [03:03] If it's not a bug in Rosetta, it'll be a bug in the product you're translating, and we can use the same bug report to ask for a fix there (Malone's cool like that) [03:06] mpt: yeah, I noticed how smooth it works now (that smae exact feature) [03:08] hi mpt [03:09] mpt: oh, and hi btw :) [03:10] mpt, better an example first.. https://launchpad.net/distros/ubuntu/breezy/+sources/ubuntu-docs/+pots/aboutubuntu/pt/+translate?offset=20 [03:10] mpt, 30. [03:12] Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=SteveA,BjornT] Fix bug 1585: returning unconfirmed email addresses from the authserver. (patch-2396: andrew.bennetts@canonical.com, orrect* tests ) [03:15] WaterSevenUb: ooh, that's interesting -- Rosetta sees "translator-credits" and thinks "oh, this is just a single-line thing" [03:16] I think carlos talked about this before [03:16] mpt: can we talk about futher menus work sometime? [03:16] SteveA: sure, now's good [03:16] okay [03:17] WaterSevenUb: It's already reported: https://launchpad.net/malone/bugs/116 [03:17] hi sivang [03:18] hello hello [03:21] mpt, aaaah... good (and bad) :) [03:21] mpt, thx. === bradb_ [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad === Virtuall[BZA] is now known as Virtuall === bob2 [n=rob@crumbs.ertius.org] has joined #launchpad [03:35] mpt: I will eventually be at UBZ , so we can talk there about MSI and related [03:36] Does anyone know what "test@importd.example.com" is? [03:36] Kinnison, is that to do with you? [03:37] mpt, no, to do with ddaa and jblack, mpt [03:38] not be [03:38] erm not me [03:40] Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=SteveA,BjornT] Make the Twisted daemon runner more reliably fail when the daemon fails, e.g. if it cannot listen on a port. (patch-2397: andrew.bennetts@canonical.com) === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [04:27] uhm [04:27] why is the staging shipit saying that shipit is not yet ready for new orders? [04:28] elmo, SteveA? [04:29] um, no idea? I just set up the virtual host for Steve [04:29] oh. [04:29] I know [04:29] :) === Virtuall is now known as Virtuall[BZA] === Virtuall[BZA] is now known as Virtuall [05:01] elmo, pqm seems to be stuck again. :-( [05:04] SteveA: What would you prefer for non-ASCII characters in pagetitles.py: "# -*- coding: utf-8 -*-", or use of \N{...} literals everywhere? [05:04] the use of \N{...} literals [05:04] everyone can type them [05:04] what literals do you need? [05:05] perhaps we can find a simple and elegant way of doing this [05:06] The usual suspects are quotation marks and em dashes [05:06] you don't use " for quotation marks? [05:08] I'd prefer not to, though it's not a huge deal [05:08] i'm interested; what difference does it make? [05:08] When I'm editing a title or string anyway I like to make it use proper quotes [05:08] just to make it look a little more polished and professional [05:09] what are the \N{} things for quotes and em-dashes? [05:10] \N{left double quotation mark}, \N{right double quotation mark}, \N{em dash} [05:11] the em dash looks okay, but the quotation marks are kind of verbose [05:11] yes, quite a bit longer than “ and ” (the HTML equivalents) [05:11] far more readable thogh [05:11] i would have no clue what 8220 and 8221 are [05:12] reading some code or page template source [05:12] So... do you always use these quotation marks in pairs? [05:12] yes, you mentioned that in your review [05:12] could we say that odd-numbered ones will be left ones, and even numbered ones right ones? [05:12] You could, but not for apostrophes [05:12] ? [05:12] you didn't mention anything about apostrophes [05:13] "%s\N{right single quotation mark}s translation templates" [05:13] we can do basic smart quotes in pagetitles.py [05:13] that's wrong [05:13] an apostrophe is not a quotation mark [05:14] blame the Unicode Consortium [05:14] what is wrong with using an apostrophe there? [05:15] In Unicode they share a codepoint [05:15] so, just use an apostrophe [05:15] don't make this unnecessarily complicated [05:16] That's just what I was going to say [05:16] Ooo, sivang just pointed out the ticket tracker on staging.lp.net to me. =) [05:16] Implementing smart quotes in pagetitles.py would probably be overkill [05:16] okay, so are you saying you'll use just \N{em dash} ? [05:17] yes [05:19] okay [05:25] mpt: do we not have a name-pluralising formatter? [05:26] if not, we probably ought to [05:26] because appending "'s" isn't right all the time [05:27] erm, sorry, not just pluraliser, but posessive thingy [05:27] Kinnison: Pluralising? You mean, possessivising [05:27] right \ [05:29] E.g. if someone's nick is "lagos" we want "lagos' templates" don't we? [05:29] I may be wrong, and apparently it's a matter of taste at times (so says my partner) [05:29] but somehow just blindly tacking on 's seems wrong [05:29] Kinnison: As I was taught, we want that only if lagos is a legendary character or a deity [05:29] Hmm [05:30] e.g. "Zeus' wives" but "Lagos's wives" [05:30] I could be wrong, though [05:30] Interesting [05:30] I imagine it's a very contended point [05:30] leave it as +'s for now I guess [05:30] yes, probably, but also moot at the moment [05:30] unless we have someone rant at us :-) [05:30] Currently we don't actually have titles of that style [05:30] aah :-) === Kinnison tickles mpt [05:31] :) [05:31] We do have a heading or two in that style, though [05:33] i totally suggest not using 's on these things [05:33] it totally screws up l10n [05:33] Hmm, interestingly the consensus in "another place" is as follows... [05:33] try to say "wives of Lagos" [05:33] append 's unless the proper noun is both plural and ends with an s in which case append ' [05:34] SteveA: programmatically easier to deal with. Not as simple to read === SteveA checks bugs in writing [05:34] We wouldn't say "The bugs of Daniel", we'd say "Daniel's bugs" [05:35] and actually we'd likely say "Bugs in Daniel's packages" [05:35] rather than "Bugs in the packages of Daniel" === sabdfl [n=mark@host217-37-231-22.in-addr.btopenworld.com] has joined #launchpad [05:35] which sounds more like bugs in packages of some software called 'Daniel' [05:35] anyway, I shall put my bag of peanuts away and get on with code [05:38] Kinnison: i have here the rule you quoted, with one modification: "When the creature who is the owner has a name ending in the sound /eez/, you should use only the apostrophe, just as you would not pronounce the possessive /eezes/." [05:39] So, "Circes' sorcery did not make all that notable a change in the state of Odysseus's men." [05:39] interesting [05:39] i don't know how internationalization people deal with posessives [05:39] I don't see how how "Bugs assigned %s" is any more l10n-friendly than "%s's bugs" is [05:39] +to [05:39] mpt: well, consider lithuanian [05:40] my bugs would be Styvo bugai [05:40] SteveA: Clearly, we need eez-detection.py [05:40] aiste's bugs would be Aistes bugai [05:40] and there are other variants for other names [05:41] it all depends on the ending of the name [05:41] so, i really don't think we can do "%s's bugs" if we want that string to be localized [05:41] So the Lithuanian localization would need to be more awkward, so as to say the equivalent of "Bugs of %s" [05:41] of course, it could be localized as "bugs of steve" translated [05:42] but that's not friendly to translators :-/ [05:42]