[12:03] <kiko> stub!
[12:03] <kiko> how's it going?
[12:11] <stub> kiko: Silently! Like warty and before it hoary, Breezy has decided that some applications should not make noise. Such as gaim.
[12:15] <segfault> that's weird. i'm marking some strings in rosetta to be reviewed, and it's not saving its state
[12:22] <salgado> 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] <kiko> segfault, really? and no system error?
[12:29] <sivang> stub: hehe, do you mean you cannot setup sound on your breezy machine?
[12:29] <sivang> kiko ! 
[12:30] <sivang> 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] <kiko> sivang, no, but yeah. :)
[12:31] <stub> sivang: Gnome sound is not working. Other sound is working just fine. It seems to be a tradition now.
[12:32] <stub> So I can happily play music and not have to listen to kiko whine ;)
[12:33] <sivang> stub: hehe :)
[12:35] <kiko> stub, did carlos' script finish running successfully?
[12:37] <sivang> stub: well, I have no problem at all on a dell laptop, weird
[12:38] <stub> kiko: First section worked fine. Second part (cleanup) died with integrity constraints.
[12:39] <sivang> kiko: has their been any discussion about the support tool ?
[12:40] <stub> bah - don't have the branch around any more
[12:41] <kiko> stub, if you can help get the script running I'd love you
[12:45] <sivang> kiko: if you can, just mail me (my email is in lp) I'm off to bed :)
[12:45] <sivang> good night all!
[12:49] <kiko> sivang, no, but you can see in staging an initial version of the ticket tracker has landed, thanks to sabdfl
[12:54] <segfault> kiko: no errors
[12:57] <segfault> product name: ubuntu-doc, but its sources are named ubuntu-docs
[12:58] <segfault> https://launchpad.net/distros/ubuntu/breezy/+sources/ubuntu-docs/+pots/aboutubuntu/pt_BR/+translate
[12:58] <kiko> segfault, could you file a bug for us? that's most unexpected.
[01:05] <segfault> yup.
[01:09] <segfault> done
[01:09] <segfault> #2242
[01:10] <kiko> thanks segfault, you da man
[01:11] <segfault> haha
[01:11] <segfault> sei..
[02:39] <sabdfl> evening all
[02:39] <sabdfl> wot's potting in launchpad land?
[02:41] <kiko-zzz> not a lot as you can see
[02:41] <kiko-zzz> I'm trying to go home
[02:41] <kiko-zzz> but the barrage of email prevents me to
[02:41] <kiko-zzz> sabdfl, there's some email from me requiring some of your attention
[02:41] <kiko-zzz> I'd be x-grateful if you could give me a few minutes of your day tomorrow to help me 
[02:42] <kiko-zzz> and now, without further ado, I adjourn this meeting
[03:08] <sabdfl> kiko-zzz: ok, willdo
[03:08] <sabdfl> night
[05:39] <jamesh> hmm. chinstrap doesn't seem to like me
[05:39] <bob2> don't take it personally
[05:41] <jamesh> seems better now
[05:41] <elmo> yeah, I think you were just unlucky
[05:41] <elmo> because it's a bastion host, we hit the "max startups" limit sometimes
[05:45] <stub> elmo: Steve said there might have been issues with Pound before?
[05:45] <elmo> stub: oh, we had lots of fun
[05:45] <stub> Is it just that Pound does not know when Launchpad is not responsive because it keeps happily accepting new connections?
[05:46] <elmo> that was the pound issue, steve said, yeah
[05:49] <stub> elmo: I also have something here about troubles having Pound only talk to one Launchpad backend. Would that be the same issue?
[05:49] <elmo> yeah, that was probably a red herring
[05:49] <elmo> sorry, it was all very hectic, and I didn't have time to debug/take notes
[05:50] <stub> ok. So the Pound setup looks fine, but we might have some tweaking with the Launchpad environment.
[05:50] <stub> 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] <elmo> well, 'initscript restart' definitely didn't kill the original suspect/hung process
[05:51] <stub> and nagios should be checking the backends as well as just the front end.
[05:51] <elmo> how do I check the backends?
[05:52] <stub> 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] <stub> re: nagios, you probably can't at the moment because the servers will be listening on the loopback address.
[05:53] <elmo> that's ok
[05:53] <elmo> the nagios checks run locally
[05:53] <elmo> I mean, do I just feed them normal http?  if so, what's a good URL?
[05:53] <stub> But if I fix that, you can test the backend servers individually on their ports (http://gangotri:9031/, http://gangotri:9032)
[05:53] <elmo> ok
[05:53] <stub> 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] <elmo> pls don't fix them, I like them on loopback only :)
[05:54] <stub> ok ;)
[05:55] <stub> Do you know what I need to add to the initscript to allow the spawned processes to dump core? 
[05:56] <elmo> 'ulimit -c somebignumber' ?
[05:56] <elmo> at the top of the script, AFAIK should affect all spawned children
[05:59] <jamesh> ulimit -c unlimited
[05:59] <stub> Just set an rt request re: the nagios stoof
[05:59] <elmo> cheers
[05:59] <jamesh> if you want to make sure the core files don't get truncated
[05:59] <spiv> UPDATE POFile SET exportfile = 356375, exporttime = CURRENT_TIMESTAMP AT TIME ZONE 'UTC' WHERE id = 92269
[05:59] <spiv> " sometimes.
[06:00] <jamesh> spiv: what else is it doing in the transaction?
[06:02] <spiv> Not sure.  The export code is pretty involved.
[06:02] <stub> spiv: It is conflicting with another process
[06:02] <stub> spiv: Those errors are expected, and in general you should retry the transaction
[06:02] <spiv> stub: Something else is updating that row?
[06:03] <jamesh> spiv: or reading that row + updating a row the first transaction read
[06:03] <spiv> 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] <stub> 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] <stub> 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] <stub> Or not run in serialized transaction isolation, which is probably overkill for most of our stuff
[06:04] <spiv> Any idea which particular process might be conflicting?  Presumably it will be getting these errors occasionally too.
[06:05] <spiv> I guess there's lots of things that hit POFile.
[06:05] <jamesh> 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] <stub> http://www.redhat.com/docs/manuals/database/RHDB-2.1-Manual/admin_user/xact-serializable.html
[06:06] <jamesh> since the database assumes that the write depends on the previous read in the transaction
[06:06] <stub> spiv: Could be anything, including the Launchpad instance.
[06:06] <stub> (well... anything Rosetta or statistician related)
[06:09] <stub> So either retry, reduce transaction isolation to 'read committed' instead of 'serializable', or lock the table
[06:10] <stub> Hmm... although I too can't see what would be causing that particular query to die this way :-/
[06:10] <spiv> It's the second one of these I've seen in recent days.
[06:20] <stub> 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] <jamesh> for a lot of scripts, switching to implicitBegin=False mode might help with those sort of problems
[06:29] <elmo> what the hell is mark doing?
[06:29] <elmo> he's the one that keeps locking up chinstrap
[06:30] <elmo> sabdfl: ping?
[08:30] <SteveA> spiv: ping
[08:43] <spiv> pong
[08:46] <SteveA> librarian rosetta issues
[08:46] <SteveA> what's it all about?
[08:50] <spiv> 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] <spiv> But only sometimes.
[08:51] <SteveA> any idea what causes it?
[08:54] <spiv> 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] <spiv> (And carlos doesn't think that's likely either)
[08:57] <SteveA> have you tried to reproduce the problem?
[08:58] <spiv> I have; it doesn't reproduce locally for me with the steps carlos suggested.
[08:58] <stub> while 1: stick_file_in_librarian(); commit(); get_file_from_librarian() ?
[08:59] <spiv> Hmm.  That sort of stress test probably isn't a bad idea.
[09:00] <SteveA> can you add some logging to the librarian
[09:00] <SteveA> to say when it has files added, when it has files requested
[09:01] <SteveA> and when files get totally written to disk and finished with
[09:01] <spiv> It already logs HTTP requests, so the "when it has files requested" is already there.
[09:01] <SteveA> 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] <SteveA> the main thing is to see in detail what's involved in writes
[09:02] <spiv> 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] <spiv> In fact, I'll write a test for that.
[09:03] <SteveA> can you make the librarian, if it gets a missing row, to wait .5 seconds and then try again?
[09:03] <SteveA> and of course log that it has done so
[09:03] <spiv> I could.  I could do the same on the client end, too.
[09:04] <SteveA> in case we have a race between the end of a rosetta transaction and postgres making the data available to other code.
[09:04] <SteveA> um, other connections
[09:04] <spiv> Another option would be to make the librarian cache information about files that were just uploaded to it.
[09:06] <stub> 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] <spiv> (Although that's adding more complexity to the system)
[09:07] <SteveA> 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] <SteveA> so, andrew, let's write up the plans on a wiki page
[09:08] <SteveA> we have a number of theories about what could be going wrong
[09:08] <SteveA>  - issues with transactions not being properly reset in twisted
[09:08] <stub> 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] <SteveA>  - a race in postgresql between one connection committing and another wanting to see the same issue
[09:08] <SteveA> stub: i don't know if it was a futex yesterday.  no core dump.
[09:09] <stub> SteveA: That isn't answering my question ;)
[09:09] <SteveA> stub: symptoms were that you can get a TCP connection, GET something, and then a hang
[09:10] <stub> Are you talking about the futex issue people have seen in the past, or what happened yesterday?
[09:10] <SteveA>  - some problem with the librarian getting stressed out
[09:10] <SteveA> 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] <SteveA> stub: what happened yesterday, and i think also what happened in the past
[09:11] <SteveA> my memory of old futex issues is hazy
[09:12] <spiv> SteveA: Hmm, I think the bug report in maloneis a better place for that than a wiki page.
[09:12] <SteveA> spiv: fine
[09:12] <spiv> But otherwise, I agree.
[09:12] <SteveA> so long as it is written up for others to see
[09:12] <stub> Ok - so there is nothing to suggest the hang had anything todo with futexes.
[09:28] <SteveA> stub: other than it requiring a kill -9
[09:30] <stub> ok. Nobody had mentioned that ;)
[09:30] <SteveA> i'm pretty sure elmo killed it -9
[09:30] <SteveA> after trying to restart it using the script
[09:30] <SteveA> and that failing
[09:31] <SteveA> i'll mail you the log
[09:32] <SteveA> mailed
[09:38] <stub> Ta. 
[09:38] <stub> 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).
[09:57] <sabdfl> moin moin
[09:59] <sabdfl> elmo: pong
[10:02] <jamesh> SteveA: just sent a possible fix for the test_reconnector.txt timeout issues
[10:02] <SteveA> cool
[10:11] <SteveA> jamesh: why did you put the after_select.set() before the  thread_result.append(cur.fetchone()[0] ) ?
[10:12] <jamesh> SteveA: looks like a mistake -- I just added the event.set() calls around the call that would hang
[10:12] <jamesh> should be afterwards
[10:13] <SteveA> it looks like a good improvement, though
[10:13] <SteveA> spiv: can you take a quick look?
[10:13] <jamesh> a bunch of the other tests under canonical/database are using time.sleep() too
[10:14] <jamesh> could probably be fixed in a similar fashion
[10:15] <SteveA> please do it
[10:15] <SteveA> it ought to speed up the test suite a bit
[10:17] <jamesh> 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] <jamesh> which can't be good
[10:44] <stub> lifeless: Can you please mirror the newly tagged rocketfuel@canonical.com/launchpad--production--1.32
[10:44] <lifeless> done
[10:51] <sivang_> morning all
[10:53] <sivang> how can I reach staging of launchpad? I want to have a first look at the new issue tracker :)
[10:54] <bob2> I'm pretty sure it's restricted to people with a special cert
[10:54] <sivang> eh..
[10:54] <sivang> I see
[10:54] <bob2> ie canonical employees
[10:54] <bob2> and it's broken atm, anyway
[10:55] <sabdfl> erk
[10:55] <sabdfl> anybody else tried to "make" launchpad on Breezy? I think there's a gcc problem
[10:55] <sabdfl> doesn't show up if you just upgrade, because the old binaries still owkr
[10:55] <SteveA> on building zope3?
[10:55] <sabdfl> work, even
[10:55] <sabdfl> yes
[10:55] <SteveA> gustavo has a patch for it
[10:55] <SteveA> taken from upstream
[10:56] <sabdfl> where can i find that?
[10:56] <SteveA> i have forwarded you two emails
[10:56] <lifeless> bob2 says staging is down
[10:56] <SteveA> one with the small patch
[10:56] <SteveA> and the other with the things gustavo had to do to get launchpad running on breezy
[10:57] <sivang> bob2: is this the same cert that you need in order to access RT?
[10:57] <SteveA> i'll apply the patch to zope now
[10:57] <SteveA> as i intend to upgrade to breezy over the weekend
[10:57] <bob2> I've never used canonical RT
[10:58] <SteveA> i wonder if we can open staging up a bit more?
[10:58] <lifeless> would be nice to do so
[10:58] <SteveA> it would help people who report bugs on launchpad to see when they've been fixed in the code
[10:58] <SteveA> stub: what do you think?
[10:59] <stub> lifeless: That GCC bug was fixed in that Z3 merge I emailed to you to do
[10:59] <lifeless> stub: will do today
[10:59] <SteveA> oh, so no point in my applying it in a branch and asking pqm to merge it?
[11:00] <lifeless> stub: unless its urgent? Is it ?
[11:00] <stub> SteveA: Nope
[11:00] <stub> lifeless: Not for me ;) People running breezy need to manually apply that patch though if they want to 'make build' launchpad
[11:00] <lifeless> its in my todo queue
[11:01] <stub> Yer... staging dead
[11:01] <sivang> 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] <sabdfl> SteveA: good idea to open up staging
[11:01] <sabdfl> it should be staging.launchpad.net
[11:02] <sabdfl> elmo: ^ kthxbye ;-)
[11:02] <stub> Hmm... probably forgot to restart it after doing a db sync earlier
[11:02] <sabdfl> sivang: it's landed, just not rolled out to production yet (prob today)
[11:02] <sabdfl> sivang: if you can see https://staging.launchpad.canonical.com then its there
[11:03] <sabdfl> 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] <SteveA> https://staging.ubuntu.com/ is where it should be right now
[11:03] <stub> 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] <SteveA> stub: people were thinking it was cert protected
[11:04] <SteveA> stub: system error on front page of staging
[11:04] <sivang> SteveA: that was the bad gateway error?
[11:04] <sivang> sabdfl: yay! thanks
[11:04] <SteveA> no, another error
[11:05] <stub> Yer - getting there
[11:05] <jamesh> dogfood is the only one not visible to the world
[11:05] <SteveA> do we have a wiki page about staging?
[11:05] <SteveA> not the mechanics of it, but what it is, what it shows, what it is for
[11:06] <sivang> sabdfl: hrm, s.l.c.m seems unreachable, s.u.c gives System Error
[11:06] <sabdfl> sivang, ok, could you ping elmo when he's online in a few hours?
[11:06] <SteveA> sivang: https://staging.ubuntu.com/  but, stu is still making it work
[11:06] <SteveA> sivang: you are seeing staging.  it is giving a system error right now.
[11:07] <SteveA> or rather, a bad gateway right at this moment.  stuart is sorting it out.
[11:08] <sivang> sabdfl: sure, unless it gets sorted before
[11:19] <stub> Staging all resynced and running
[11:22] <SteveA> stub: synced with what?
[11:22] <SteveA> i mean, what patch level is staging running?
[11:26] <stub> SteveA: trunk as of a few minutes ago
[11:26] <SteveA> thanks
[11:43] <jamesh> spiv: do you have any idea of the reason for the time.sleep() calls in canonical/lp/ftests/test_zopeless.py?
[11:46] <jamesh> it looks like 10 wasted seconds in "make check"
[01:04] <Kinnison> jamesh: mind if I cast an eye over your gpg trust importer branch?
[01:16] <jamesh> Kinnison: go for it
[01:16] <Kinnison> what is the primary script?
[01:17] <Kinnison> find-email-clusters?
[01:19] <jamesh> find-email-clusters does web of trust processing and outputs the email address clusters
[01:19] <jamesh> merge-email-clusters updates the database from those clusters
[01:24] <Kinnison> cool, thanks
[01:24] <Kinnison> I just want to check the logic for the cluster finding really
[01:25] <Kinnison> which I assume is in canonical.launchpad.scripts.keyringtrustanalyser
[01:40] <sivang> stub: hmm, new fonts, style sheet? text looks smallr 
[01:43] <stub> Could be - mpt would know details and rationale for any recent changes
[02:17] <mpt> Morning all
[02:20] <Nafallo> the update from staging is today, right?
[02:29] <jordi> Nafallo: should be
[02:29] <jordi> I hope it is :)
[02:30] <Nafallo> it haven't happen yet it seems ;-)
[02:30] <salgado> Nafallo, jordi, in fact I think it's going to be tomorrow (only this week)
[02:31] <Nafallo> hehe
[02:33] <jordi> salgado: nod
[02:37] <salgado> elmo, pqm's stuck again
[02:40] <elmo> go pwm
[02:40] <elmo> pqm too
[02:40] <elmo> kicked
[02:41] <jordi> we all live pqm
[02:41] <jordi> love, bah
[02:43] <WaterSevenUb> how do I introduce a TAB in Rosetta?:)
[02:49] <mpt> WaterSevenUb: If the source string contains a tab, Rosetta gives you instructions on how to enter a tab right underneath that field
[02:49] <mpt> WaterSevenUb: And if the source string doesn't contain a tab character, why are you wanting to use one in your translation? :-)
[02:51] <WaterSevenUb> mpt, ok ok :-D Thanks :)
[02:54] <WaterSevenUb> 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] <Kinnison> is lp out of action?
[02:58] <mpt> WaterSevenUb: It's a multi-line field, right? If so, the Enter key should work.
[02:59] <WaterSevenUb> mpt, nope... it's a one-line field.
[03:02] <mpt> WaterSevenUb: That sounds like a bug ... Could you report it, giving the URL of the page? https://launchpad.net/products/rosetta/+bugs
[03:03] <mpt> WaterSevenUb: https://launchpad.net/products/rosetta/+filebug, even
[03:03] <mpt> 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] <sivang> mpt: yeah, I noticed how smooth it works now (that smae exact feature)
[03:08] <SteveA> hi mpt 
[03:09] <sivang> mpt: oh, and hi btw :)
[03:10] <WaterSevenUb> mpt, better an example first.. https://launchpad.net/distros/ubuntu/breezy/+sources/ubuntu-docs/+pots/aboutubuntu/pt/+translate?offset=20
[03:10] <WaterSevenUb> mpt, 30.
[03:12] <dilys> 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] <mpt> WaterSevenUb: ooh, that's interesting -- Rosetta sees "translator-credits" and thinks "oh, this is just a single-line thing"
[03:16] <mpt> I think carlos talked about this before
[03:16] <SteveA> mpt: can we talk about futher menus work sometime?
[03:16] <mpt> SteveA: sure, now's good
[03:16] <SteveA> okay
[03:17] <mpt> WaterSevenUb: It's already reported: https://launchpad.net/malone/bugs/116
[03:17] <mpt> hi sivang
[03:18] <kiko> hello hello
[03:21] <WaterSevenUb> mpt, aaaah... good (and bad) :)
[03:21] <WaterSevenUb> mpt, thx.
[03:35] <sivang> mpt: I will eventually be at UBZ , so we can talk there about MSI and related 
[03:36] <mpt> Does anyone know what "test@importd.example.com" is?
[03:36] <mpt> Kinnison, is that to do with you?
[03:37] <kiko> mpt, no, to do with ddaa and jblack, mpt
[03:38] <Kinnison> not be
[03:38] <Kinnison> erm not me
[03:40] <dilys> 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)
[04:27] <kiko> uhm
[04:27] <kiko> why is the staging shipit saying that shipit is not yet ready for new orders?
[04:28] <kiko> elmo, SteveA?
[04:29] <elmo> um, no idea?  I just set up the virtual host for Steve
[04:29] <kiko> oh.
[04:29] <kiko> I know
[04:29] <kiko> :)
[05:01] <salgado> elmo, pqm seems to be stuck again. :-(
[05:04] <mpt> SteveA: What would you prefer for non-ASCII characters in pagetitles.py: "# -*- coding: utf-8 -*-", or use of \N{...} literals everywhere?
[05:04] <SteveA> the use of \N{...} literals
[05:04] <SteveA> everyone can type them
[05:04] <SteveA> what literals do you need?
[05:05] <SteveA> perhaps we can find a simple and elegant way of doing this
[05:06] <mpt> The usual suspects are quotation marks and em dashes
[05:06] <SteveA> you don't use " for quotation marks?
[05:08] <mpt> I'd prefer not to, though it's not a huge deal
[05:08] <SteveA> i'm interested; what difference does it make?
[05:08] <mpt> When I'm editing a title or string anyway I like to make it use proper quotes
[05:08] <mpt> just to make it look a little more polished and professional
[05:09] <SteveA> what are the \N{} things for quotes and em-dashes?
[05:10] <mpt> \N{left double quotation mark}, \N{right double quotation mark}, \N{em dash}
[05:11] <SteveA> the em dash looks okay, but the quotation marks are kind of verbose
[05:11] <mpt> yes, quite a bit longer than &#8220; and &#8221; (the HTML equivalents)
[05:11] <SteveA> far more readable thogh
[05:11] <SteveA> i would have no clue what 8220 and 8221 are
[05:12] <SteveA> reading some code or page template source
[05:12] <SteveA> So... do you always use these quotation marks in pairs?
[05:12] <mpt> yes, you mentioned that in your review
[05:12] <SteveA> could we say that odd-numbered ones will be left ones, and even numbered ones right ones?
[05:12] <mpt> You could, but not for apostrophes
[05:12] <SteveA> ?
[05:12] <SteveA> you didn't mention anything about apostrophes
[05:13] <mpt> "%s\N{right single quotation mark}s translation templates"
[05:13] <SteveA> we can do basic smart quotes in pagetitles.py
[05:13] <SteveA> that's wrong
[05:13] <SteveA> an apostrophe is not a quotation mark
[05:14] <mpt> blame the Unicode Consortium
[05:14] <SteveA> what is wrong with using an apostrophe there?
[05:15] <mpt> In Unicode they share a codepoint
[05:15] <SteveA> so, just use an apostrophe
[05:15] <SteveA> don't make this unnecessarily complicated
[05:16] <mpt> That's just what I was going to say
[05:16] <jbailey> Ooo, sivang just pointed out the ticket tracker on staging.lp.net to me. =)
[05:16] <mpt> Implementing smart quotes in pagetitles.py would probably be overkill
[05:16] <SteveA> okay, so are you saying you'll use just \N{em dash} ?
[05:17] <mpt> yes
[05:19] <SteveA> okay
[05:25] <Kinnison> mpt: do we not have a name-pluralising formatter?
[05:26] <Kinnison> if not, we probably ought to
[05:26] <Kinnison> because appending "'s" isn't right all the time
[05:27] <Kinnison> erm, sorry, not just pluraliser, but posessive thingy
[05:27] <mpt> Kinnison: Pluralising? You mean, possessivising
[05:27] <mpt> right \
[05:29] <Kinnison> E.g. if someone's nick is "lagos" we want "lagos' templates" don't we?
[05:29] <Kinnison> I may be wrong, and apparently it's a matter of taste at times (so says my partner)
[05:29] <Kinnison> but somehow just blindly tacking on 's seems wrong
[05:29] <mpt> Kinnison: As I was taught, we want that only if lagos is a legendary character or a deity
[05:29] <Kinnison> Hmm
[05:30] <mpt> e.g. "Zeus' wives" but "Lagos's wives"
[05:30] <mpt> I could be wrong, though
[05:30] <Kinnison> Interesting
[05:30] <Kinnison> I imagine it's a very contended point
[05:30] <Kinnison> leave it as +'s for now I guess
[05:30] <mpt> yes, probably, but also moot at the moment
[05:30] <Kinnison> unless we have someone rant at us :-)
[05:30] <mpt> Currently we don't actually have titles of that style
[05:30] <Kinnison> aah :-)
[05:31] <mpt> :)
[05:31] <mpt> We do have a heading or two in that style, though
[05:33] <SteveA> i totally suggest not using 's on these things
[05:33] <SteveA> it totally screws up l10n
[05:33] <Kinnison> Hmm, interestingly the consensus in "another place" is as follows...
[05:33] <SteveA> try to say "wives of Lagos"
[05:33] <Kinnison> append 's unless the proper noun is both plural and ends with an s in which case append '
[05:34] <Kinnison> SteveA: programmatically easier to deal with. Not as simple to read
[05:34] <Kinnison> We wouldn't say "The bugs of Daniel", we'd say "Daniel's bugs"
[05:35] <Kinnison> and actually we'd likely say "Bugs in Daniel's packages"
[05:35] <Kinnison> rather than "Bugs in the packages of Daniel"
[05:35] <Kinnison> which sounds more like bugs in packages of some software called 'Daniel'
[05:35] <Kinnison> anyway, I shall put my bag of peanuts away and get on with code
[05:38] <SteveA> 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] <SteveA> So, "Circes' sorcery did not make all that notable a change in the state of Odysseus's men."
[05:39] <Kinnison> interesting
[05:39] <SteveA> i don't know how internationalization people deal with posessives
[05:39] <mpt> I don't see how how "Bugs assigned %s" is any more l10n-friendly than "%s's bugs" is
[05:39] <mpt> +to
[05:39] <SteveA> mpt: well, consider lithuanian
[05:40] <SteveA> my bugs would be Styvo bugai
[05:40] <mpt> SteveA: Clearly, we need eez-detection.py
[05:40] <SteveA> aiste's bugs would be Aistes bugai
[05:40] <SteveA> and there are other variants for other names
[05:41] <SteveA> it all depends on the ending of the name 
[05:41] <SteveA> so, i really don't think we can do "%s's bugs" if we want that string to be localized
[05:41] <mpt> So the Lithuanian localization would need to be more awkward, so as to say the equivalent of "Bugs of %s"
[05:41] <SteveA> of course, it could be localized as "bugs of steve" translated
[05:42] <SteveA> but that's not friendly to translators :-/
[05:42] <mpt> but that doesn't mean the English localization needs to be more awkward to match.
[05:42] <SteveA> hmm, guess so
[05:42] <SteveA> in lithuanian, they'd probably do "%s-o bugai" actually
[05:43] <SteveA> as a catch-all
[05:43] <SteveA> which would be wrong in many cases
[05:54] <Kinnison> elmo: Which is more important... resilience in the face of a deb going missing from the pool by mistake, or running the publish process faster?
[05:54] <Kinnison> elmo: currently I check every published package is on disk every time we run the publisher
[06:09] <SteveA> mpt: i'm re-reviewing the spec tracker branch now
[06:30] <sabdfl> SteveA: is there an example of testing a script?
[06:31] <sabdfl> in particular, i want to be able to pass in a fake logger, and then test the resulting log messages
[06:32] <SteveA> doc/poimport.txt perhaps
[06:32] <SteveA> poexport-language-pack.txt
[06:33] <SteveA> the latter was worked on more recently
[06:33] <SteveA> so should have the best examples
[06:34] <sabdfl> ok, thanks
[06:34] <sabdfl> i'm creating a new "test" subdir of cronscripts
[06:34] <sabdfl> how do I make the test harness go in there to execute .txt files as tests?
[06:35] <SteveA> look in canonical/launchpad/ftests/test_system_documentation.txt
[06:36] <SteveA> have you considered keeping the documentation under /doc/, maybe in /doc/cronscripts/ ?
[06:39] <cprov> lifeless: PQM seems to be stalled. could you restart it ?
[06:39] <sabdfl> SteveA: why do we have ./cronscripts and canonical/launchpad/scripts ?
[06:39] <SteveA> lib/canonical/launchpad/scripts contains libraries for use only in scripts
[06:40] <SteveA> these can be imported, tested, reused etc.
[06:40] <SteveA> ./cronscripts is where scripts are run from.  they are executable programs, rather than libraries
[06:40] <SteveA> this is described in the specification about scripts and daemons
[06:41] <sabdfl> ok, thanks
[06:42] <SteveA> i think it may be clearer to have the tests of running the cronscripts (as programs) in ./cronscripts/ftests or something like that
[06:42] <SteveA> or even ./cronscripts/doc/
[06:43] <SteveA> as we like to emphasise documenting while testing
[06:44] <kiko-fud> sabdfl, ping?
[06:52] <lifeless> cprov: doesn't seem hung
[06:53] <lifeless> cprov: looks like its testing hct 
[06:53] <lifeless> sabdfl: we have 'net
[06:53] <sabdfl> kiko-fud: pong
[06:53] <sabdfl> lifeless: cool
[06:54] <lifeless> and I have missing-ancestry baz2bzr working.
[06:54] <lifeless> :)
[06:54] <cprov> lifeless: really ? salgado has a job from 13:19:17 UTC ... ok then, thank you for looking
[06:54] <lifeless> revisions 1974/2373 0:54:42
[06:54] <lifeless> cprov: ok, I'll kill it with prejuidice
[06:54] <sabdfl> tick tock, 400 to go
[06:55] <cprov> lifeless:  ok, it should not hurt more than already did
[06:58] <lifeless> down to 122 mb of space
[06:58] <Kinnison> mmm millibits
[06:59] <lifeless> fargoff
[07:27] <sabdfl> lifeless: what's it saying now about the time to go?
[07:33] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Ordering GPGKeySet base queries to avoid warnings when slicing results. (patch-2398: celso.providelo@canonical.com)
[07:45] <Kinnison> ciao dudes
[07:52] <bradb> SteveA: https://launchpad.net/malone/bugs/2265 -- looks like a bug in the login machinery; it's possible that this bug lives only on my branch, and is in some way related to the magic IBug adaptation.
[07:52] <bradb> mind you, magic IBug adaptation doesn't happen on that particular page
[07:53] <SteveA> that's interesting, brad
[07:53] <SteveA> and that's also a well-written bug report
[07:53] <SteveA> thank you
[07:53] <bradb> no prob
[07:54] <SteveA> i'll take a quick look now.  i've actually finished for the day, but randomly browsing interesting stuff... (gah... wikipedia)
[07:54] <bradb> sure, no worries. wikipedia++.
[08:00] <SteveA> jblack: the bazaar page on wikipedia could do with updating
[08:00] <SteveA> in a NPOV way of course
[08:13] <Nafallo> \sh: gajim?
[08:14] <\sh> Nafallo: yepp
[08:14] <Nafallo> \sh: didn't I send you the mail about it? :-)
[08:14] <\sh> Nafallo: when? no
[08:15] <\sh> Nafallo: I just tried it again ;)
[08:15] <sabdfl> SteveA: we are rapidly converging on a switch to bzr for rocketfuel
[08:15] <Nafallo> \sh: oki, I did sent that mail btw :-P
[08:15] <SteveA> so soon?
[08:15] <SteveA> that's awesome news
[08:16] <sabdfl> lifeless is just getting the first results from his baz-to-bzr work
[08:16] <sabdfl> tomorrow we should be able to test performance on a fully imported mainline
[08:16] <sabdfl> he also has an archive-converter which will pull out all the branches in an archive
[08:16] <sabdfl> and pqm is done
[08:17] <\sh> Nafallo: sorry..missed the attachment :(
[08:17] <sabdfl> so, UBZ is still the deadline
[08:17] <Nafallo> \sh: ah :-P
[08:18] <\sh> Nafallo: now I understand the system behind it :) and it looks like that we need to do our own head baz repos ;)
[08:19] <Nafallo> \sh: indeed :-)
[08:20] <Nafallo> \sh: or convince upstream ;-)
[08:20] <SteveA> bradb: reproduced the bug.  i'll look into it tomorrow.
[08:20] <bradb> SteveA: mercy
[08:23] <SteveA> okay -- i see exactly where the bug is in launchpad code
[08:24] <SteveA> but this is odd behaviour from the zope3 request API
[08:26] <jordi> so, does anyone know how am I supposed to get rid of the "do-not-use" and "review-breezy" templates in Rosetta?
[08:26] <jordi> I want to get started on that now
[08:28] <kiko-fud> I don't know, hmmm
[08:33] <jordi> if nobody knows how (and I don't find out without calling carlos) I probably need to postpone until he's back :(
[08:33] <jordi> I don't want to mail/phone him about rosetta during his vacation
[08:33] <jordi> bradb: that a product isn't using malone as it's official bug tracker.
[08:34] <jordi> it can probably use a better tag
[08:34] <kiko> bradb, mpt: can you fix that text to say "Primary Bugtracker: Malone" or "No primary bugtracker indicated"?
[08:34] <jordi> or maybe it can be shown only if it is.
[08:34] <kiko> that might be a good idea
[08:34] <jordi> same for rosetta
[08:36] <kiko> has anyone seen ddaa?
[08:39] <kiko> hey elmo?
[08:40] <mpt> kiko: That doesn't belong on a product's page, it belongs on /products/foo/+bugs
[08:40] <kiko> mpt, I'm not so sure -- it's interesting to know if the product uses rosetta/malone (or something else) officially, even when not looking at the bugs facet. Hmm, do you mean the +bugs facet is the place where it is most useful?
[08:41] <mpt> I mean that you're not guaranteed (or even likely) to scan a product's page before hitting its "Bugs" tab to go report a bug.
[08:41] <bradb> http://localhost:8086/products/firefox/+milestone/1.0 -- none of the tabs are linked from this page...ow. ch.
[08:43] <mpt> That whole box needs a once-over
[08:43] <mpt> e.g. it still says "perms"
[08:48] <bradb> mpt: Are you going to do something about the robotic "Malone Not Official" message, or do you want me to do it after I'm done with the URL changes?
[08:49] <bradb> t-minus 1 test failure...
[08:49] <mpt> bradb: I can't land anything until ddaa (or someone else who knows why my check_merge is failing) arrives, so you can fix it if you think it's urgent
[08:50] <bradb> I don't have time for anything until the URL changes land. If I get to it before you get to it, I'll let you know.
[08:51] <kiko> mpt, SteveA posted a suggestion, get to it.
[08:51] <mpt> kiko: I am doing that right now.
[08:54] <SteveA> mpt: i expect you'll get errors running the tests using the rocketfuel branch.
[08:54] <SteveA> the reason i expect this is that when you submit a merge to pqm, it uses the latest standard trees for the other trees.
[08:54] <SteveA> so, the problem must lie in your code.
[08:55] <SteveA> hmm, so i expect things to pass when you use rocketfuel.
[08:55] <SteveA> jim fulton's trying to switch his machine to ubuntu
[08:56] <mpt> So is there a way to say "diff me everything against rocketfuel, not just launchpad"?
[09:01] <SteveA> why do you want to do that?
[09:02] <SteveA> when i want to do that, i look at the baz tree-id of each tree
[09:02] <SteveA> that information would be useful to others trying to see what is wrong
[09:02] <SteveA> you'd need to baz diff against the appropriate rocketfuel patch level in each tree, i think
[09:02] <mpt> SteveA: You were right, I did get the same errors testing the rocketfuel branch.
[09:03] <SteveA> that's interesting
[09:03] <SteveA> i don't understand how you get errors when asking pqm to merge things, then
[09:03] <SteveA> you could try making a whitespace change in a page template file on a new branch from RF
[09:04] <SteveA> and asking pqm to merge that
[09:04] <SteveA> i'm certain that would work, if tests on pqm are working at all
[09:04] <mpt> ok
[09:04] <SteveA> so next, i think you should get the tree-id of each of your trees
[09:04] <SteveA> that's everything in ./sourcecode
[09:05] <SteveA> and also everything that's not 'canonical' and not a symlink in './lib'
[09:05] <SteveA> and mail that to the list
[09:05] <SteveA> or compare it to someone else's
[09:05] <mpt> after trying the whitespace change?
[09:05] <SteveA> i wouldn't bother with that, but you can if you like
[09:21] <sabdfl> mpt: what's the glitch?
[09:23] <mpt> sabdfl: make check_merge fails for me both locally, and at PQM
[09:23] <mpt> with errors in CVS and Taxi
[09:23] <mpt> in all my branches, and with rocketfuel direct
[09:24] <mpt> (well, I assume rocketfuel itself doesn't fail at PQM, since other people are landing stuff)
[09:25] <sabdfl> are all the branches up to date? you'e done a refuel?
[09:25] <kiko> yes
[09:25] <mpt> yes.
[09:25] <cprov> mpt: try again, it fails sometime in my machine too, some wierd race condition in CVS/taxi component
[09:26] <cprov> mpt: it won't fail in PQM
[09:26] <kiko> I said so myself
[09:29] <mpt> okie dokie
[09:30] <sabdfl> i've seen failures like that both on my machine and in pqm
[09:31] <sabdfl> CVS / taxi are doing a lot of apwning and respawning of subprocesses, and timing issues can cause this
[09:31] <mpt> agh
[09:32] <sabdfl> mpt: i'd be interested to hear of performance tests of the rf-in-bzr on your laptop when we are getting ready for the switch, prob in about 2 weeks
[09:32] <mpt> And I'm constantly getting an untagged test@importd.example.com directory in my tree too
[09:32] <kiko> rf-in-bzr will be interesting
[09:32] <kiko> particularly the pie angle ;)
[09:33] <mpt> sabdfl: As long as the setup instructions are at a Bazaar-for-Dummies level, I'd be delighted to try something faster than baz :-)
[09:33] <sabdfl> you an me both, brotha
[09:42] <bradb> sabdfl: It would be kind of evil to allow linkrot of things like /malone/bugs/1/+duplicate, /malone/bugs/1/people/+new, /malone/bugs/1/cverefs/1/+edit, etc (/malone/bugs/1 *will* of course continue to work, because just that is pretty easy to make work.) At the same time, it will take some thinking to make those links redirect to the correct place. How much do you care about ensuring that those links continue to work?
[09:43] <mpt> bradb: But nobody's going to have linked to *those*, except in bug reports
[09:43] <mpt> whereas they have linked to the bug reports themselves
[09:44] <bradb> mpt: I wouldn't be able to give an accurate assessment of if anybody's linking to any of the links I've just mentioned, but I can accurately say that all of them have been exposed to the outside world.
[09:45] <sabdfl> bradb: not at all
[09:45] <bradb> which, it would seem, puts them in linkrot orbit, at least
[09:45] <bradb> sabdfl: ok
[09:45] <bradb> purity, say hello to PRACTICALITY
[09:45] <sabdfl> the main /malone/bugs/1 should be redirectable, other than that, fuggedaboudid
[09:45] <bradb> right
[09:46] <sabdfl> although /me thinks that if you slap a smart enough redirect at /malone/bugs/ it would happily pass on the rest of the URL
[09:46] <sabdfl> and given zope3's behaviour of attaching views to objects, when we move the object, most of the views should move with it, right?
[09:47] <sabdfl>  /people/+new is toast
[09:47] <sabdfl> as is the cveref lot, with my new approach
[09:47] <sabdfl> it's all getting simpler and cleaner
[09:47] <bradb> sabdfl: not quite that simple though, there's multiple redirecting going on there. e.g. not only has the URL to a bug changed, but even within that, the URLs to adding things have changed.
[09:47] <sabdfl> kiko: https://chinstrap.ubuntu.com/~jamesh/pending-reviews/ its not as big as it looks ;-)
[09:47] <sabdfl> could i have it by thursday please? kthxbye
[09:48] <bradb> supermagicredirectnahasldjfYHICK
[09:48] <sabdfl> bradb: yah... fuggedaboudid
[09:50] <kiko> sabdfl, no winkin' from me, mate
[09:53] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Transfer team membership records when merging people. r=stub (patch-2399: guilherme.salgado@canonical.com)
[09:53] <kiko> rock on salgado 
[10:12] <sabdfl> salgado: good work
[10:30] <WaterSevenUb> items 207 and 214 of the freshly added FAQGUIDE in Rosetta seem to be broken!
[10:47] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=BjornT]  Clean up fix requests table in bug page, fixing bug 1989 (patch-2400: mpt@canonical.com)
[10:49] <mpt> aha! PQM thuggery victorious!
[11:18] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=BjornT]  Clean up fix requests table in bug page, fixing bug 1989 (patch-2401)
[11:35] <sabdfl> mpt scores again
[11:39] <salgado> and it looks like mpt is going to score 4 more times with this same branch
[11:49] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=BjornT]  Clean up fix requests table in bug page, fixing bug 1989 (patch-2402)