[12:16] <Yannig> Hello everybody
[01:41] <looksaus> I'm an administrator for a team in launchpad
[01:41] <looksaus> (not the owner)
[01:41] <looksaus> is it normal that I can't add an event?
[04:51] <lifeless> spiv: reviews for you
[04:51] <lifeless> jamesh: reviews for you
[05:20] <lifeless> jamesh: can you run pending reviews every 30 minutes now ? load seems to be quite low
[05:22] <jamesh> lifeless: increasing the frequency is probably a good idea, but 30 minutes might be a bit too frequent
[05:23] <lifeless> well, 45 perhaps ?
[05:23] <lifeless> it seems to take 12 minutes
[05:23] <jamesh> that's when it doesn't need to pull any new revisions from anywhere
[05:24] <jamesh> and for a weekend run when no one else is doing anything
[05:26] <lifeless> meep
[05:27] <jamesh> meep?
[05:33] <mpt_> Goooooooooooooooood afternoon Launchpadders!
[05:33] <lifeless> jamesh: the amount of time we spend making knits in commit
[05:33] <lifeless> jamesh: its rather insane.
[05:35] <jamesh> lifeless: I've dropped it down to once every 2 hours.  I noticed that if the script ate up too much of chinstrap's IO bandwidth, it would cause other processes to stall
[05:35] <jamesh> so having time when it is not running seems important
[05:44] <jamesh> lifeless: btw, I applied my bzr diff output improvement patches to the copy of bzrlib that the pending-reviews script uses -- it seems to be working quite well
[06:16] <mpt_> lifeless, can you tell me what's going wrong in https://chinstrap.warthogs.hbd.com/~dsilvers/paste/filepmZ0EO.html ?
[06:23] <mpt_> hmm
[06:24] <jamesh> mpt_: if you run "ssh-add ~/.ssh/id_dsa", you should be able to get rid of those passphrase prompts
[06:24] <jamesh> not sure about the lock error
[06:25] <jamesh> might be easiest to manually delete the stale locks
[06:41] <lifeless> mpt_: upgrade your branch on chinstrap
[06:42] <lifeless> mpt_: we had this discussion on friday IIRC
[06:44] <mpt_> oh!
[06:44] <mpt_> I thought I'd already done that
[06:46] <mpt_> sorry
[08:15] <sivang> morning all
[08:16] <`6og> hey sivang :)
[08:17] <sivang> hey kgoetz 
[09:09] <stub> Where does the oops code live?
[09:10] <stub> found it
[09:16] <ddaa> Blue pint
[09:16] <ddaa> the Launchpad drafting system
[09:16] <mpt__> the Launchpad coping mechanism?
[09:17] <mpt> Good morning carlos
[09:17] <ddaa> mpt: come on, it's not _that_ horrible
[09:19] <carlos> morning
[09:21] <SteveA> morning
[09:24] <carlos> SteveA: hi, I have a small problem with mawson, and I wonder if you know if there was any change on it recently (new packages installed/removed)
[09:24] <carlos> https://chinstrap.ubuntu.com/~dsilvers/paste/fileHxz177.html
[09:24] <stub> jamesh: Is the only code that ever needs to parse an oops report all contained in errorlog.py?
[09:25] <carlos> stub: ^^^
[09:25] <jamesh> stub: nope.
[09:25] <SteveA> carlos: i'm not sure why importing apt should try to import PIL
[09:25] <jamesh> stub: at the moment there is code in oops.cgi and analyse-error-reports.py
[09:25] <SteveA> carlos: but i also know of no changes to these things
[09:25] <stub> carlos: No idea
[09:26] <SteveA> the only change i'd expect would be for security updates
[09:26] <carlos> elmo: hi, around?
[09:27] <spiv> SteveA: PIL is a red-herring: https://launchpad.net/distros/ubuntu/+source/python-imaging/+bug/31646
[09:27] <Ubugtu> Malone bug 31646 in python-imaging "python-imaging puts a "__init__" module in the top-level module namespace" [Normal,Confirmed]  
[09:28] <SteveA> spiv: eew, gross
[09:32] <carlos> the question is... how is that we got it installed last week? or why wasn't it failing until last week?
[09:37] <SteveA> carlos: if it was a security update, then that would explain ir
[09:38] <dilys> Merge to devel/launchpad/: [r=spiv]  move supermirror branch-pull-list to authserver (r3581: James Henstridge)
[09:39] <carlos> SteveA: should I file a sysadmin request about it?
[09:39] <spiv> carlos: it appears installing the libapt-pkg-libc6.3-6-3.9 package would fix it.
[09:49] <ddaa> SteveA: are we still having the bazaar meeting today?
[09:50] <SteveA> ddaa: it's *your* meeting :-)
[09:50] <SteveA> i'm available
[09:50] <ddaa> okay
[09:50] <ddaa> SteveA: spiv: jamesh: mpool: lifeless: meeting in 10 mins in #launchpad-meeting
[09:52] <stub> bzr: ERROR: exceptions.ImportError: No module named tests.stub_sftp
[09:52] <stub>   at /usr/lib/python2.4/site-packages/bzrlib/transport/sftp.py line 889
[09:52] <stub>   in ?
[09:54] <spiv> stub: Downgrade your bzr, or wait for the new package.
[10:04] <cprov> good morning, hackers
[10:09] <looksaus> hi, I'm an administrator for https://launchpad.net/people/ubuntu-be/
[10:10] <looksaus> but I can't seem to add any event to its calendar
[10:10] <looksaus> https://launchpad.net/people/ubuntu-be/+calendar/+add gives me a "forbidden not allowed here sorry you don't have permission to"
[10:11] <looksaus> is there anything I overlooked or that I could try to solve this problem
[10:11] <looksaus> ?
[10:14] <spiv> jamesh: any thoughts on looksaus' problem? ^
[10:17] <jamesh> looksaus: looks like the perms only currently let the team owner add events, which is a bug
[10:18] <looksaus> ok, would it be helpful if I made a bug report?
[10:18] <jamesh> looksaus: yeah.
[10:22] <looksaus> done
[10:25] <looksaus> jamesh, https://launchpad.net/products/launchpad/+bug/45964
[10:25] <Ubugtu> Malone bug 45964 in launchpad "administrator can't add event to launchpad team calendar" [Normal,Unconfirmed]  
[10:25] <looksaus> thx for your great work, all!
[10:25] <looksaus> really appreciate it
[10:37] <carlos> stub: hi, I have a set of potemplates that we should remove from launchpad, I know their potemplatenames and I already requested a tarball with all those translations to have a backup
[10:38] <Keybuk> lifeless: ping?
[10:38] <carlos> stub: could you remove them with the potemplatename as the only input or would you need the .id values?
[10:38] <carlos> cprov: hi, are you using dogfood server?
[10:40] <stub> carlos: My existing script uses the id as input
[10:40] <carlos> stub: ok, I will give you it
[10:40] <lifeless> Keybuk: jo
[10:40] <Keybuk> lifeless: bzr dropped dependency on paramiko
[10:40] <Keybuk> is that no longer needed?
[10:41] <lifeless> thats wrong
[10:41] <lifeless> its still needed for sftp
[10:41] <Keybuk> sftp is "optional", no?
[10:42] <mpt__> bother
[10:42] <carlos> karl: Hi, I'm having a problem with mawson: https://chinstrap.ubuntu.com/~dsilvers/paste/fileHxz177.html
[10:42] <lifeless> Keybuk: 'optional'
[10:42] <lifeless> yes
[10:42] <carlos> karl: and Andrew says: <spiv> carlos: it appears installing the libapt-pkg-libc6.3-6-3.9 package would fix it.
[10:42] <lifeless> but theres no good reason not to install it by default.
[10:42] <cprov> carlos: yes
[10:42] <carlos> cprov: and is it working?
[10:43] <carlos> cprov: I had a problem there "ImportError: libapt-pkg-libc6.3-5.so.3.9: cannot open shared object file: No such file or directory"
[10:43] <cprov> carlos: code is old, I'm updating it 
[10:43] <carlos> well, I don't think that's a new dependency...
[10:44] <cprov> carlos: wow, maybe karl upgraded apt
[10:44] <Keybuk> lifeless: you'll have to take that up with jbailey I guess
[10:44] <Keybuk> lifeless: I've stopped paramiko going to universe though
[10:45] <lifeless> Keybuk: he merged dilingers patches from debian
[10:45] <lifeless> I think that dilinger would have been wise to discuss more with us
[10:52] <carlos> Znarl: morning, did you see my comments about mawson?
[10:52] <lifeless> ddaa: so, mock objects
[10:52] <lifeless> ddaa: I've written a comprehensive email I hope. 
[10:53] <lifeless> Keybuk: thanks!
[10:53] <ddaa> lifeless: I've looked at it yesterday
[10:53] <ddaa> not sure what to answer
[10:53] <ddaa> I find uses for mock object in my programming, so maybe you should review the code and suggest some simple ways to get the same testing quality
[10:54] <ddaa> lifeless: OTOH the new code that uses mock object is very much on the non-critical path to bzr-native, so I cannot spend much time rewriting it.
[10:55] <lifeless> ddaa: I've taken the relevant branch to review
[10:55] <lifeless> ddaa: I will be thinking about this as I do it. I do suggest that you think through the ramifications though
[10:56] <ddaa> IME the best way to think through ramifications of a methodology so far is to try it and see how it works.
[10:56] <lifeless> mock objects significantly increase the bar for refactoring safely. I'm pretty convinced they are a net loss.
[10:56] <ddaa> I realise that mock objects are an issue for refactoring
[10:56] <ddaa> but you were the one to talk me into doing more unit testing and less functional testing
[10:57] <lifeless> yes
[10:57] <lifeless> And I stand by that
[10:57] <lifeless> one of the techniques I still use is stub objects, rather than mock objects.
[10:57] <ddaa> So, I think that's a great idea. But if not with mock objects, it's not very clear for me how.
[10:57] <lifeless> stubs give you a single place to change when the api changes, rather than N
[10:58] <aa_> sounds interesting, I always forget to refactor my Mocks
[10:58] <lifeless> I'm going to do a simple scenario tester library I think during this qc period
[10:58] <lifeless> aa_: hi, yes.
[10:58] <ddaa> lifeless: : but that does not allow you to check for proper interactions...
[10:59] <lifeless> ddaa: its no less powerful than mocks for checking interactions
[10:59] <aa_> lifeless: hi
[10:59] <aa_> (hi everyone)
[10:59] <ddaa> I like the idea of "check that METHOD calls the right other methods in that and this condition, as unit test" then check that individual methods actually do the right thing as functional tests...
[11:00] <ddaa> lifeless: I must be missing something. When you check interactions, you need to spread the knowledge of the behaviour in each test...
[11:01] <ddaa> the only difference I can see between what you suggest and what I understantd of mock-object programming is that you want more explicitness and more factorisation.
[11:03] <ddaa> SteveA: is your "create mocks from interfaces" idea something related to pushing the duplicate logic for test back to the main code to help prevent skew?
[11:29] <lifeless> ddaa: I think creating mocks from interfaces, for trivial mocks, is a good start as it makes the skew marginally less dangerous
[11:30] <lifeless> ddaa: what I am proposing is full blown small implementations rather than mocks at all. These implementations record the actions done on the them, so you can do the 'what was called' tests 
[11:57] <carlos> stub: I just sent you an email with the set of potemplate and pofile  ids that you should remove
[11:57] <carlos> stub: would be possible to get that done today?
[11:58] <stub> ok
[12:01] <carlos> stub: thanks
[12:01] <carlos> spiv: hi
[12:01] <carlos> spiv: do you have some time to help me with a librarian question I have?
[12:04] <ddaa> lifeless: to summarise, you advocate using simulator objects instead of mocks?
[12:05] <ddaa> on the basis that there should be _at most_ one simulator class per interface being tested
[12:06] <ddaa> to make it manageable to evolve API without going into shotgun surgery on the test cases
[12:08] <mpt> gah, now I *really* can't bzr push
[12:10] <mpt> mpool, bug 45973
[12:10] <Ubugtu> Malone bug 45973 in bzr "bzr push to SFTP crashes with "No module named tests.stub_sftp"" [Normal,Unconfirmed]  http://launchpad.net/bugs/45973
[12:14] <BjornT> mpt: stub sent a mail to the list about it, and lifeless said it has been fixed. not sure if a new package has been uploaded yet, though.
[12:15] <mpt> serves me right for only reading the list once a day :-)
[12:15] <mpt> thanks BjornT 
[12:16] <mpt> no upload yet
[12:19] <SteveA> lifeless: when is the reviewers' meeting?
[12:21] <carlos> Znarl: thanks for fixing mawson's problem (I guess you did it)
[12:22] <Znarl> carlos : I did, yes.
[12:22] <carlos> BjornT: my dapper update got a new bzr today
[12:23] <BjornT> carlos: i think that's the one that is broken
[12:23] <carlos> 0.8.2-1ubuntu2
[12:37] <lifeless> SteveA: in 24 minutes
[12:38] <lifeless> BjornT: jbailey uploaded several hours ago
[12:38] <SteveA> thanks
[12:40] <stub> BjornT: Can you please confirm https://chinstrap.ubuntu.com/~dsilvers/paste/fileytcGfK.html before I apply it to production. I've already applied it to staging. It affected 83 bugtasks.
[12:41] <cprov-afk> Znarl: priv
[12:57] <lifeless> review meeting in 5
[01:00] <lifeless> meeting time
[01:00] <lifeless> roll call for the reviewers meeting please
[01:00] <lifeless> spiv: 
[01:00] <lifeless> jamesh: 
[01:00] <lifeless> stub: 
[01:00] <lifeless> erm
[01:00] <lifeless> SteveA: 
[01:00] <spiv> here
[01:00] <SteveA> hi
[01:01] <jamesh> hi
[01:01] <lifeless>  * Agenda
[01:01] <lifeless>  * Next meeting
[01:01] <lifeless>  * Queue status.
[01:02] <lifeless> same bat-time, same bat-channel ?
[01:02] <spiv> sure.
[01:02] <spiv> (WHAM!  KA-POW!)
[01:02] <lifeless> BIFF!
[01:02] <lifeless> 2006-05-29 at 1100 UTC.
[01:02] <lifeless> queue status
[01:03] <lifeless> work in progress is getting used.
[01:03] <lifeless> I like this :)
[01:03] <lifeless> BjornT: review meeting time
[01:03] <lifeless> there are 5 branches in needs-review
[01:04] <lifeless> 2 for jamesh, 1 each for spiv, me, BjornT 
[01:04] <BjornT> cool, i'm here
[01:04] <jamesh> lifeless: reload
[01:04] <lifeless> jamesh: heh, thanks!
[01:04] <spiv> lifeless: I reviewed mine a short while ago.
[01:05] <lifeless> ok. so oldest branch is 3 days, and as todays monday, thats fine.
[01:05] <lifeless> spiv: cool
[01:05] <lifeless> so I'm happy. Do you guys have any comments, feelings about recent reviews ?
[01:07] <jamesh> btw, the pending-reviews page is now being generated once every 2 hours.  Depending on how things perform, that might get reduced further
[01:07] <lifeless> jamesh: excellent. thank you
[01:07] <lifeless> any new business ?
[01:07] <jamesh> things seem to be performing well, to the credit of the bzr guys
[01:08] <stub> lifeless: Looks like my merge has hung pqm. It should have failed a few hours ago (the tests won't pass).
[01:08] <lifeless> SteveA: are you happy with our performance as a review team ?
[01:09] <SteveA> yes
[01:09] <lifeless> SteveA: whats your sense of the lp teams happiness with the review process these days ?
[01:09] <lifeless> stub: looking
[01:09] <SteveA> i think people are happy with the reviews and the turnaround time
[01:09] <SteveA> one ongoing challenge is to work out how to get reviews of designs, not just code
[01:10] <lifeless> stub: strace of process 25818 shows it hung
[01:10] <lifeless> stub: blocked on 'write'
[01:11] <lifeless> stub: looks like a bug in test_on_merge.py to me
[01:11] <stub> Is the blocked write to stdout or stderr?
[01:11] <lifeless> 1
[01:11] <lifeless> (out)
[01:11] <stub> ok. bug in test_on_merge likely culprit
[01:11] <lifeless> test_on_merge is blocked on wait4
[01:11] <lifeless> waiting for the process to finish
[01:12] <lifeless> killed it
[01:12] <stub> ta
[01:12] <BjornT> stub: the queries look good, didn't find anything odd on staging. i forgot one thing, though, the severity should be reset as well: https://chinstrap.ubuntu.com/~dsilvers/paste/filePfHsNc.html
[01:12] <lifeless> SteveA: yes. I'm not sure how to improve that for the current reviews. It might be good to get earlier review involvement
[01:13] <stub> BjornT: Erm... did you remove the SET bugwatch=NULL deliberately?
[01:13] <SteveA> lifeless: maybe a voip call with a reviewer to discuss designs at the start of coding
[01:14] <BjornT> stub: well, i was thinking of running two set of queries. the severity should be reset only if it's Unknown.
[01:14] <stub> ok
[01:14] <lifeless> SteveA: yes, that sort of thing.
[01:14] <lifeless> SteveA: an Item in the lp meeting for this would be good.
[01:15] <lifeless> ok, meeting ends in ...
[01:16] <lifeless> .. 
[01:16] <lifeless> . .
[01:16] <lifeless> .  
[01:16] <lifeless>  ..
[01:16] <lifeless>  . 
[01:16] <lifeless>   .
[01:16] <lifeless> meeting implodes
[01:16] <lifeless> thanks guys
[02:09] <ddaa> mpt: ping
[02:09] <ddaa> mpt: unping
[02:16] <stub> carlos: I've done the potemplate/pofile removal on staging. Can you please give rosetta a once over to ensure that things that should have been deleted have been and things that shouldn't have been deleted are still there?
[02:17] <carlos> sure, although on staging some extra potemplates were deleted due the changes I did on production to prevent those removals, I didn't apply those changes to stagin
[02:17] <carlos> (talking about the SELECT id ... query)
[02:26] <carlos> stub: I need to increase the timeout value for staging
[02:26] <stub> sure
[02:26] <carlos> to get a web page that will allow me to do that check really easy
[02:26] <carlos> ok
[02:26] <stub> carlos: I got a list of ids from production and deleted them on staging
[02:27] <carlos> oh, ok
[02:28] <carlos> is that ok?
[02:28] <carlos> will be a few seconds, nothing will be updated
[02:29] <carlos> done
[02:39] <carlos> stub: ok, seems like all was correct
[02:40] <carlos> stub: btw, I'm preparin some SQL updates for production, would you ping me 30 minutes or so before you leave to give you what I have to get those changes on production and leave the ones I'm working on for tomorrow?
[02:50] <kiko> morning
[02:51] <BjornT> stub, lifeless: my merge requests to pqm are failing since /var/lock/launchpad-checkwatches.lock seems to exist. can someone take a look at it and delete it if it's there?
[02:52] <stub> BjornT: removed
[02:52] <BjornT> thanks
[03:00] <lifeless> night all
[03:02] <sivang> night lifeless 
[03:14] <dilys> Merge to devel/launchpad/: [rs=kiko, trivial]  Remove spurious sourcepackagename creation when processing binary packages, remove unecessary checks for queue-ui view code and remove database imports from ftpmaster script library. (r3582: Celso Providelo)
[03:23] <kiko> hey cprov 
[03:25] <cprov> kiko: hi, it's still pending mark's points about queue-ui, will do it until evening
[03:26] <kiko> okay, thanks.
[03:31] <carlos> stub: mail sent with the updates I need on production
[03:32] <carlos> stub: would be really good if you could execute them before leaving today, not sure if it's already too late...
[03:33] <carlos> later
[03:35] <carlos> stub: If you need anything from me, just ping my nick and I will listen the ping.
[03:47] <dilys> Merge to devel/launchpad/: [trivial]  Add connection instance info to OOPS report (Bug #44032) and make session cookie name configurable (Bug #44192) (r3583: Stuart Bishop)
[03:47] <Ubugtu> Malone bug 44032 in launchpad "Out of order SQL queries triggering foreign key constraints" [Normal,In progress]  http://launchpad.net/bugs/44032
[03:47] <Ubugtu> 'Malone bug 44192 in launchpad "Need to configure session cookie name to avoid staging and production\n conflicts" [Normal,In progress]  http://launchpad.net/bugs/44192'
[04:01] <kiko> ah, good work stub 
[04:28] <mdz> cprov: BenC has a kernel upload for edgy prepared if you want a nice test case
[04:30] <cprov> mdz: it'd be great, send it to me 
[04:31] <cprov> mdz: btw check for mistakes or issue you want me to fix before open real edgy
[04:31] <mdz> cprov: i wish I had the time...
[04:32] <cprov> mdz: uhm, who do you suggest to play around ?
[04:43] <Yannig> Hello everybody :)
[04:43] <Yannig> Anyone could explain me how to set Occitan as default language AND French as alternative?
[04:44] <Yannig> I have LANGUAGE="oc_FR:oc:fr_FR:fr:en_GB:en"
[04:44] <Yannig> LANG=oc_FR.UTF-8 in /etc/environment but it seems it's not enough because I have many programs in English now :p
[04:47] <dilys> Merge to devel/launchpad/: [trivial]  add bug number to an XXX comment. (r3584: Bjorn Tillenius)
[04:50] <ploum> oups, I just saw that there was a comment to my Google SoC
[04:50] <ploum> I replied, I hope that I'm not too late
[04:51] <mdz> cprov: I asked BenC to send it to you; follow up with him if you haven't heard from him already
[04:51] <ploum> (from Sivan Greenberg)
[04:51] <cprov> mdz: ok, thx
[04:53] <carlos> Yannig: What's the content of your ~/.dmrc file?
[04:53] <carlos> Yannig: let's move this to the right channel... #ubuntu
[05:25] <dilys> Merge to devel/launchpad/: [r=jamesh]  make it possible to create a new bug watch from +editstatus. add some javascript to the widgets used for creating and linking bug watches. (r3585: Bjorn Tillenius)
[05:30] <kiko> good work BjornT 
[06:15] <ddaa> cya launchpadders
[06:15] <ddaa> going to restaurant and movies
[06:34] <pygi> Hi
[06:34] <pygi> do we have a xml-rpc interface in LP?
[06:34] <mdz> pygi: yes, I'm told that it does
[06:35] <pygi> mdz, yes, on one application you did, on other you said we don't :)
[06:35] <pygi> which obviously changed in one day :P
[06:35] <mdz> pygi: I learned new information between those two points in time
[06:35] <pygi> thanks :)
[06:35] <mdz> it changed quite recently
[06:35] <pygi> mdz, ok
[06:36] <pygi> what do you think is more important? that glaunchpad thingy or Smart Bug reporting?
[06:36] <mdz> the latter
[06:37] <dilys> Merge to devel/launchpad/: [r=spiv]  importd test cleanups (r3586: David Allouche)
[06:37] <pygi> mdz, ok, I'll drop the glaunchpad and accept smart bug reporting
[06:38] <pygi> any possible mentors for that?
[06:38] <mdz> perhaps bradb or bjornt
[06:38] <mdz> kiko might have an opinion
[06:39] <pygi> ok, but we should handle that fast, because mentors have to be assigned in max. like 6 hours from now
[06:39] <jsgotangco> go pygi :)
[06:39] <jsgotangco> \o/
[06:39] <pygi> hey jsgotangco :)
[06:40] <pygi> what I did this time? :)
[06:40] <pygi> mdz, can you do me a favor, talk to them, and say who of them will mentor? :)
[06:42] <kiko> pygi, what's up?
[06:42] <mdz> pygi: I don't have time for it right now
[06:42] <mdz> kiko: google summer of code
[06:42] <mdz> kiko: someone wants to write our client-side bug reporting tool for malone
[06:42] <mdz> needs a mentor
[06:42] <pygi> mdz, ok, thanks anyway :)
[06:43] <Keybuk> ok, that's weird
[06:43] <kiko> pygi, so sure, BjornT could be a mentor. you'll need some help with the XML-RPC server interface so that's why I'd recommend him.
[06:43] <Keybuk> launchpad threw away my overrides
[06:43] <Keybuk> 14:47:46 INFO    'mozilla-thunderbird-locale-el/main/web/OPTIONAL' binary overridden in dapper/amd64
[06:43] <Keybuk> etc.
[06:43] <Keybuk> yet it's still in main
[06:43] <Keybuk> 14:47:46 INFO    Override Component to: 'universe'
[06:43] <pygi> kiko, oki, thanks :)
[06:44] <BjornT> kiko, pygi: i'm not registered as a mentor, though. not sure if that will be problem or not.
[06:44] <kiko> Keybuk, that's odd indeed. 
[06:45] <aa_> nothing to do with mentoring, but I am interested in helping with the bug report tool
[06:45] <pygi> BjornT, please apply for mentor right now
[06:45] <kiko> pygi, that's a good point, because aa_ has written a basic tool that does just that.
[06:45] <pygi> BjornT, I hope you know how to do it? :)
[06:46] <aa_> (but not over XMLRPC)
[06:46] <BjornT> pygi: not really :), but i should have an email somewhere about it.
[06:46] <pygi> BjornT, oki, please hurry :)
[06:47] <BjornT> pygi: found the link, doing it now
[06:47] <pygi> BjornT, thanks :)
[06:48] <Keybuk> kiko: there's no way to look up the "current" override for a package, is there?
[06:49] <kiko> Keybuk, it's the information attached to the most recent publishing entry
[06:49] <Keybuk> why don't they show up until a publish run?
[06:49] <Keybuk> is it just because that adjusts the actual ftp view?
[06:51] <kiko> Keybuk, don't whow up where?
[06:51] <kiko> show, arch.
[06:51] <Keybuk> when you run change-override
[06:52] <Keybuk> the log always says main/*
[06:59] <kiko-fud> Keybuk, hmmm, I'm not sure. perhaps change-override doesn't look at the publishing history tables properly.
[07:00] <kiko-fud> Keybuk, can you file a bug and/or pester cprov to check on the SQL when he has a moment?
[07:01] <Keybuk>       version       | status | component
[07:01] <Keybuk> --------------------+--------+-----------
[07:01] <Keybuk>  1:1.5.0.2ubuntu1-3 |      1 |         3
[07:01] <Keybuk>  1:1.5.0.2ubuntu1-3 |      2 |         1
[07:02] <Keybuk> so, I guess change-override just adds a PENDING publishing record which gets processed into a PUBLISHED each publisher run?
[07:05] <cprov> Keybuk: yes, that's the way to override a publication
[07:05] <Keybuk> cprov: so why hasn't it happened?
[07:06] <cprov> Keybuk: did the publisher run ?
[07:06] <Keybuk> cprov: I assume it's run a few times since
[07:07] <cprov> Keybuk: uhm ..let me check, maybe a case of same filename and different content
[07:07] <cprov> Keybuk: sourcepackagename ?
[07:07] <Keybuk> thunderbird-locales
[07:12] <Keybuk> (though this is a binary override, the binary I'm looking at right now is mozilla-thunderbird-locale-nb)
[07:12] <Keybuk> it seems to have worked this run ... any idea why it didn't earlier?
[07:12] <cprov> Keybuk: afff, let me check the pub log 
[07:21] <cprov> Keybuk: no clue and if you look to the source (https://launchpad.net/distros/ubuntu/+source/mozilla-thunderbird-locale-nb/) things get more obscure.
[07:26] <cprov> Keybuk: the UI isn't even able to point to the right SP (https://launchpad.net/distros/ubuntu/+source/thunderbird-locales)
[07:27] <Keybuk> hmm
[07:27] <Keybuk> the mozilla-thunderbird-locale-nb package WAS created by a source of the same name
[07:27] <Keybuk> but is now created by thunderbird-locales
[07:28] <cprov> Keybuk: see https://launchpad.net/distros/ubuntu/dapper/i386/mozilla-thunderbird-locale-nb
[07:28] <cprov> Keybuk: something sane
[07:29] <Keybuk> interesting
[07:29] <Keybuk>  dapper i386 Release: PendingRemoval version 1:1.5.0.2ubuntu1-3 in component main and section web on 2006-05-22 16:10:34 BST and superseded on 2006-05-22 18:10:09 BST by i386 build of thunderbird-locales 1:1.5.0.2ubuntu1-3 in ubuntu dapper
[07:30] <Keybuk>  	 Requested 2006-05-22 14:37:48 BST in pocket RELEASE
[07:30] <Keybuk> 	Built 2006-05-22 15:37:35 BST by rothera (i386) in two minutes  log
[07:30] <Keybuk> maybe my original override attempt got applied to the PendingRemoval package
[07:30] <LarstiQ> hey Keybuk 
[07:32] <Keybuk> and the one I actually intended it to apply to hadn't been built and published yet
[07:32] <Keybuk> I did the override because it showed up in anastacia in the wrong place ... however germinate matches the Sources file with the Packages file, and the new source would have been published at that point
[07:37] <Keybuk> LarstiQ: hey, s'up?
[07:37] <SteveA> salgado: code review?
[07:40] <LarstiQ> Keybuk: resting today and bzr-gtk later this week
[07:45] <cprov> Keybuk: it might be a very specific corner-case, a new publication [-3]  and an override at the same publisher run, it used the new publication to supersed both (the override and old version [-2] )
[07:45] <cprov> Keybuk: it stayed with the -3 version (main/web) for a while, than you applied a new override, which lasts til now
[07:49] <Keybuk> I guess the fix there is that change-override should be able to change the component of a pending, rather than adding a new pending
[08:04] <salgado> SteveA, I just found an issue that is going to take me some time to fix. I don't think it's going to be ready for review before you leave. sorry
[08:05] <SteveA> salgado: i can do an initial review if you like
[08:09] <salgado> SteveA, yeah, it might be a good idea, I think. https://chinstrap.ubuntu.com/~dsilvers/paste/fileZRTkP4.html
[10:03] <glatzor> hi, who is responsible for the language pack uploads? it would be nice to have a new package for the German translations.
[10:30] <kiko> glatzor, not sure, but a combination of carlos and pitti knows!
[10:49] <dilys> Merge to devel/launchpad/: [r=kiko]  Fix +bugcontact broken link on distro and product portlet details (r3587: Diogo Matsubara)
[11:55] <lifeless> moining
[12:12] <sivang> hey lifeless , what's up? :)
[12:13] <lifeless> 'stuff' ;)
[12:19] <sivang> heh
[01:01] <sivang> night all
[01:04] <lifeless> gnight
[03:18] <lifeless> spiv: how are you going with the bzr update. Do you need to talk through anything in it ?
[03:18] <spiv> lifeless: I have tests passing (so long as they don't run in a tty with more than 80 columns...)
[03:19] <lifeless> spiv: bzr.dev should have that fully fixed now
[03:19] <spiv> Oh, and there's a bzrtools test that fails, but fails upstream too.
[03:19] <lifeless> spiv: really? what one
[03:19] <spiv> upstream_import's test_tar
[03:20] <lifeless> meep. thats new from aaron
[05:02] <mpt> Gooooooooooooooooooooood afternoon Launchpadders!
[09:26] <SteveA> hi
[09:27] <sivang> hi SteveA 
[09:28] <SteveA> morning sivan
[09:39] <SteveA> jamesh: skype call soon?
[09:41] <SteveA> jamesh, spiv, stub, mpt_: i want to queue up skype calls with each of you
[09:41] <stub> ok
[09:42] <spiv> Ok.
[09:42] <SteveA> stub: 0800 UTC
[09:42] <SteveA> spiv: 0830 UTC
[09:43] <spiv> SteveA: ok.
[09:43] <jamesh> SteveA: okay
[09:44] <SteveA> jamesh: 0915 UTC
[09:58] <SteveA> mornin malc
[09:58] <malcc> Morning
[09:58] <SteveA> morning cprov 
[09:58] <SteveA> cprov: had a good trip?
[10:00] <SteveA> stub: ping
[10:00] <stub> Yo
[10:05] <cprov> SteveA: morning, yes I had, thank you, first spring in London ;) 
[10:31] <spiv> SteveA: I'm ready for a call.
[10:33] <SteveA> spiv: okay.  restarting skype.
[10:33] <spiv> Restarting?  I guess skype isn't so different from shtoom after all...
[10:38] <spiv> SteveA: you seem to have dropped out?
[10:38] <SteveA> yes
[10:38] <SteveA> just a sec
[10:40] <Kinnison> Hi
[10:40] <Kinnison> How do I add a new bugtracker type?
[10:40] <lifeless> 'type' like bugzilla etc ?
[10:40] <Kinnison> I want to add an upstream bug watch into Savannah
[10:40] <Kinnison> lifeless: aye
[10:40] <lifeless> IIRC it needs a new dbschema item
[10:40] <Kinnison> oh
[10:40] <Kinnison> it's not just a table?
[10:41] <Kinnison> yergh
[10:41] <lifeless> *from memory*
[10:42] <spiv> Kinnison: lifeless is correct.
[10:42] <Kinnison> Okay
[10:43] <jamesh> Kinnison: depending on how much they've diverged, the SF bug tracker type may be appropriate
[10:43] <Kinnison> jamesh: I don't think it is, unfortunately. I think the query-string parameter names have changed
[10:45] <jamesh> Kinnison: things like the remote bug status synchronisation need to special case each bug tracker type, so it is not trivial to add new types and have all features work
[10:45] <Kinnison> I see
[10:45] <mdke> we're having some problems on the wiki with a user randomly renaming important pages and replacing them with unrelated things 
[10:45] <Kinnison> Makes sense
[10:45] <mdke> can the account be disabled until it can be sorted out with the individual concerned?
[10:45] <lifeless> mdke: sure.
[10:45] <lifeless> mdke: account name?
[10:46] <mdke> wikiname is Ruwan5
[10:46] <lifeless> spiv: will disabling the lp account immediately take effect ?
[10:47] <mdke> if you can give me his email addy too, i'll mail him
[10:47] <lifeless> interesting
[10:48] <SteveA> you'd need to kill his session too
[10:49] <mdke> please do, the mayhem is already going to be hard to roll back
[10:49] <lifeless> I can't find the name !
[10:49] <SteveA> maybe stub can help
[10:49] <lifeless> oh foo. unclosed "
[10:50] <lifeless> got it
[10:50] <SteveA> we probably should build an admin page for managing users/sessions
[10:50] <lifeless> ruwan
[10:50] <lifeless> SteveA++
[10:51] <lifeless> https://launchpad.net/people/ruwan is the account afaict
[10:51] <stub> I landed a fix yesterday so you can't auth if your account is no longer valid, but it isn't live yet.
[10:51] <lifeless> oh foo
[10:51] <lifeless> there are 5 of this guy
[10:52] <lifeless> https://launchpad.net/people/ruwanredhat is the one
[10:52] <lifeless> how do we disbable an account then ?
[10:52] <mdke> blimey
[10:52] <stub> I think disabling the lp account will immediately affect wiki auth though
[10:53] <lifeless> stub:  is there an admin gui, or should I port the db for that ?
[10:53] <lifeless> stub: I dont see a valid field in the db
[10:53] <lifeless> mdke: ruwanredhat@yahoo.com
[10:54] <spiv> I *think* disabling the authserver account will kill the wiki auth immediately.
[10:54] <stub> lifeless: setting the password to NULL will work
[10:54] <mdke> lifeless: thanks
[10:54] <lifeless> done
[10:55] <BjornT__> cprov: ping
[10:55] <spiv> (maybe it will cause tracebacks or something for that user, but it probably will stop them being logged in)
[10:55] <mdke> lifeless: did you disactivate all of them, or just one?
[10:55] <lifeless> spiv: what does 'disabled' mean for the authserver ?
[10:55] <spiv> lifeless: Hmm.
[10:56] <lifeless> mdke: I'm only sure that one is him
[10:56] <mdke> lifeless: ok. mailing now
[10:56] <lifeless> the rest may be other people with a similar name for instance.
[10:56] <spiv> I don't think password IS NULL is checked by the authserver.
[10:56] <spiv> Having no emailaddresses would do it...
[10:56] <SteveA> if we get more abuse, we should have an explicit flag for "disabled by admin"
[10:56] <lifeless> spiv: bounce the authserver perhaps ?
[10:56] <SteveA> that way, we can re-enabled wrongly disabled accounts
[10:56] <lifeless> SteveA: and have that immediately kick the session
[10:57] <SteveA> without losing state
[10:57] <spiv> lifeless: doesn't help, the authserver is stateless.
[10:57] <SteveA> yes, have that immediately stop things
[10:57] <spiv> lifeless: the state is the user's cookie + the database.
[10:57] <SteveA> i feel a spec in the works...
[10:57] <lifeless> SteveA: take a laxitive
[10:57] <mdke> i think for the new documentation wiki we might disable renaming pages, it's hard to roll them back... stupid moin
[10:58] <SteveA> if only moin had a bzrlib backend
[10:58] <spiv> Yeah, the authserver's opinion about users is based on having valid email addresses.
[10:58] <lifeless> mdke: if you visit the old page at ?action=edit it might let you in.
[10:58] <lifeless> mdke: is he still doing it ?
[10:58] <mdke> lifeless: nothing else yet
[10:58] <lifeless> if he is, ping stub or I and we'll delete the email address
[10:59] <lifeless> spiv: would changing it work ? or a delete ?
[10:59] <jamesh> mdke: iirc you can limit features like rename to a particular group of users
[10:59] <mdke> yes, that's what I mean
[10:59] <spiv> lifeless: setting all users' emails to e.g. state = NEW rather than VALIDATED would work, I think...
[10:59] <spiv> Although it would let them reclaim the account, still.
[11:00] <lifeless> SteveA: another thing a disabled flag does is better error feedback to the user
[11:00] <SteveA> yes
[11:00] <lifeless> SteveA: 'see an admin' rather than 'my account stopped working suddenly'
[11:01] <lifeless> spiv: 'all users'' can be parsed wrongly in an amusing way
[11:01] <spiv> I'd be happy to update the authserver to check a disabled flag.
[11:01] <spiv> lifeless: Heh "all *the* users'" :)
[11:01] <SteveA> spiv: we'd want to update moin too, to give an appropriate message
[11:01] <spiv> SteveA: Right.
[11:02] <jamesh> I assume this disabled flag should also affect https://launchpad.net too?
[11:02] <SteveA> yes
[11:02] <jamesh> if a user is enough of a twit on the wiki to get their account disabled, we probably don't want them creating products on LP ...
[11:02] <SteveA> yes
[11:03] <SteveA> also
[11:03] <SteveA> someone may have had their credentials stolen
[11:03] <SteveA> so we should disable the account until the issue is cleared up
[11:03] <jamesh> any kind of error message should give clear directions on who to ask to get it reenabled
[11:06] <mdke> spiv: btw since you're here - did you see Karl's email about the wiki migration script?
[11:06] <mdke> lifeless: seems to have stopped it. I'll ping you if he emails me back and promises to stop :)
[11:08] <spiv> mdke: Yep -- when I next see him online (probably very soon) I'll help him run that script.  It ran smoothly on my local copy, so it ought to be painless.
[11:09] <mdke> spiv: yay. thanks
[11:09] <mdke> spiv: the last thing was doing the pages which redirect to the relevant pages as well. is that already in the script?
[11:10] <spiv> mdke: Yep, that's there.
[11:10] <spiv> Oh, pardon me.
[11:11] <spiv> You mean the pages that redirect to the moved pages...
[11:11] <mdke> yeah
[11:12] <spiv> That isn't done, I'm just doing a search on the live wiki to see how many there are.
[11:13] <spiv> A few hundred, maybe less.
[11:14] <mdke> i would have thought not too many
[11:14] <spiv> mdke: https://wiki.ubuntu.com/?action=fullsearch&context=180&value=%23redirect&fullsearch=Text
[11:15] <spiv> Not all of those are redirects to doc pages necessarily.
[11:15] <mdke> yeah, what we need are the pages that redirect to pages tagged with CategoryDocumentation
[11:15] <SteveA> mpt: ping
[11:15] <mdke> for example https://wiki.ubuntu.com/mdke shouldn't get moved, but https://wiki.ubuntu.com/Java should
[11:16] <spiv> mdke: It's a bit of a pain, but I'll take a stab at it.
[11:16] <SteveA> jamesh: ping
[11:17] <mdke> spiv: hang on tho
[11:17] <mdke> spiv: if Java redirects to RestrictedFormats, which then refreshes to the new wiki, it'll be ok. Does moin handle these sort of bounce refreshes?
[11:18] <spiv> mdke: I would expect so.
[11:18] <mdke> spiv: in that case moving them too won't be necessary
[11:18] <spiv> Ah, great.
[11:18] <jamesh> SteveA: pong
[11:19] <spiv> That's what I was hoping to hear ;)
[11:19] <mdke> spiv: we'll get refresh activated on the main wiki and test it
[11:19] <spiv> mdke: Sounds like a plan.
[11:19] <jamesh> SteveA: I'm not getting any sound
[11:19] <SteveA> me neither
[11:20] <SteveA> let's both try the echo123 test
[11:20] <SteveA> echo test worked for me
[11:24] <jamesh> SteveA: it was a problem at my end.  I moved my headset over to a USB hub, and things seemed to break
[11:24] <jamesh> should be fine now
[11:26] <SteveA> jamesh: i ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
[11:27] <jamesh> ?
[11:27] <SteveA> jamesh: i tried calling you, but got an error
[11:27] <jamesh> I'll try calling you
[11:33] <mpt> SteveA, pong
[11:34] <SteveA> hi mpt 
[11:34] <SteveA> i'd like to have a call soon
[11:34] <mpt> sure
[11:39] <SteveA> ddaa: ping
[11:39] <ddaa> SteveA: pong
[11:39] <SteveA> ddaa: do you have anything that you want jamesh to work on?
[11:40] <ddaa> hell, yes!
[11:40] <ddaa> let me check
[11:40] <SteveA> ddaa, jamesh: i propose you two meet tomorrow
[11:40] <SteveA> to discuss these things
[11:40] <ddaa> that's fine
[11:40] <SteveA> what time?
[11:40] <ddaa> remember that I'm on leave thursday and friday
[11:41] <SteveA> i want to be involved too
[11:41] <jamesh> ddaa: the supermirror branch pull list stuff got merged to rocketfuel yesterday, btw.
[11:41] <ddaa> 1000UTC would be fine for me
[11:41] <SteveA> kinda late
[11:42] <ddaa> 0800UTC is a bit early for me
[11:43] <ddaa> but if anything later would be inconvenient, I can be there
[11:43] <SteveA> 0900 is okay for me
[11:43] <SteveA> it means i can get lunch after the meeting
[11:43] <ddaa> jamesh: is 0900 okay?
[11:43] <jamesh> 0900 or 1000 are fine for me
[11:43] <jamesh> yeah
[11:43] <ddaa> 0900 it is then
[11:43] <SteveA> ok
[11:44] <ddaa> btw, I had a chat with Kinnison and celso yesterday
[11:45] <ddaa> to get in sync about what we'll talk about in Paris
[11:45] <ddaa> I realised that only have fuzzy ideas about how I want to change the vcs-imports systems after bzr-native
[11:45] <ddaa> it would be nice if I could have a few days to sit down and lay out plans
[11:46] <ddaa> so I would have a better idea of the environment of importd-ng
[11:47] <ddaa> I made an agenda item about it
[11:48] <ddaa> SteveA: so I would like if on the next bazaar meeting we have decided about when to set out time in my schedule for this.
[11:53] <ddaa> jamesh: I noticed it got merged, I sent you an email saying "thank you" :)
[12:00] <jamesh> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/28840 <- that's the bug that was causing the audio problems initially
[12:00] <Ubugtu> Malone bug 28840 in linux-source-2.6.15 "CONFIG_USB_EHCI_SPLIT_ISO not being set causes errors when attempting to play audio through a usb sound device connected via hub" [Wishlist,Confirmed]  
[12:08] <SteveA> jamesh: did you see the meeting notes i /msg-ed to you?
[12:14] <SteveA> mpt: call now?
[12:21] <ddaa> SteveA: is any action required from lifeless and I about Europython room booking?
[12:21] <SteveA> thanks for asking
[12:21] <SteveA> i'm hassling people
[12:21] <SteveA> i have had no response yet
[12:21] <SteveA> i'll let you know if things go any more pear-shaped
[12:21] <ddaa> okay, the URGENT tag suggested we should take some action, but your message did not specify what
[12:21] <ddaa> duh
[12:22] <ddaa> one user says "hello, I'm a newbie, how do I sync Evo and Groupwise" on launchpad-users
[12:22] <ddaa> then another user says "hello, I'm a newbie, and I do not use Evolution, but look on Novell's website", on launchpad-users too
[12:22] <ddaa> helpful and friendly, but... disturbing...
[12:23] <mpt> SteveA, ok
[12:24] <mpt> SteveA, you just went offline
[12:25] <OdyX> Heyah. CoC 1.0.1 seems unsignable...
[12:25] <SteveA> mpt: yeah
[12:25] <SteveA> mpt: i think you need to restart skype
[12:26] <mpt> OdyX, yes, that is a bug that is being fixed
[12:26] <OdyX> mpt: OK. Good. Thanks
[12:26] <mpt> In the meantime, you can sign version 1.0
[12:26] <lifeless> ddaa: :)
[12:26] <ddaa> hey lifeless
[12:26] <ddaa> how's the sourcecode/ fixage going?
[12:27] <ddaa> can you review my launchpad/importd-cvs-tests branch soon, I'm about to start building on it
[12:27] <lifeless> ddaa: had a bug with bzrtools today
[12:27] <mpt> SteveA, my Skype password has expired somehow, I'll be a few minutes
[12:27] <lifeless> thats fixed, and I'm waiting with bated fingers for spiv to ask me to try merging from his branches again.
[12:27] <OdyX> mpt: I ever did... months ago... just wondering
[12:27] <OdyX> :D
[12:28] <ddaa> lifeless: it would be real nice to get that fixed very soon, so I can merge my cscvs work before going on leave
[12:28] <lifeless> ddaa: its not exactly in my hands
[12:28] <ddaa> sure, but your are my volunteer proxy to spiv
[12:29] <lifeless> ddaa: but I can appreciate that. I shall review that branch tomorrow, I have been stuck inside commits guts today
[12:29] <ddaa> so I nag you instead of spiv :)
[12:29] <ddaa> reminds me... abentley asked me to nag him about something...
[12:30] <lifeless> is there any better way to chain iterators than
[12:30] <lifeless> yield foo
[12:31] <lifeless> for stuff in foo.bar():
[12:31] <lifeless>     yield stuff
[12:31] <SteveA> you can look at itertools
[12:31] <ddaa> streams
[12:31] <lifeless> by better I mean 'faster'
[12:31] <SteveA> faster in what sense?
[12:31] <SteveA> faster to write code for?
[12:31] <ddaa> python lack streams :(
[12:31] <lifeless> SteveA: wall clock time
[12:32] <ddaa> SteveA: I think lifeless is concerned that the yield loop causes function call overhead
[12:32] <lifeless> SteveA: we're yielding 10K items spread over 800 containers
[12:32] <SteveA> http://docs.python.org/lib/itertools-functions.html
[12:32] <SteveA> i don't know if any are written in C
[12:32] <SteveA> but writing such iterator chaining in C isn't hard
[12:32] <lifeless> SteveA: so while iterators only cost a single frame to setup, there would still appear to be overhead yielding each child
[12:33] <ddaa> lifeless++
[12:33] <ddaa> my measurements suggested the same
[12:33] <lifeless> I'm considering flatting the entire thing into a list or some such
[12:33] <ddaa> it look like it's cheaper to use lists long sequences of small objects
[12:33] <lifeless> ddaa: this is iter_entries
[12:34] <ddaa> while iterators are great for relatively short sequences of large objects
[12:34] <lifeless> ddaa: which you tuned, and then lost the patch for
[12:34] <mdke> spiv: the bouncing works
[12:34] <SteveA> changing things into lists is usually quicker in python, if you don't care about holding it all in memory
[12:34] <SteveA> converting to tuples cheaper still
[12:34] <lifeless> SteveA: total size is only a few Mb
[12:34] <SteveA> tuples are about the cheapest thing you can get
[12:34] <SteveA> if you know the size up front
[12:34] <SteveA> and will reduce your memory requirement too
[12:35] <lifeless> SteveA: its a tree made up of dicts
[12:35] <lifeless> SteveA: (thats a lie, but a good one)
[12:35] <SteveA> what is a tree made up of dicts?
[12:35] <lifeless> is it likely to be better to build a list and append, or a tuple and create new tuples as we establish the value of new entries
[12:35] <ddaa> the structure he's traversing
[12:35] <lifeless> SteveA: the data structure we are working from
[12:36] <lifeless> {'foo':{'bar':{'gam':'quux'}}}
[12:36] <lifeless> gives use foo/bar/gam/quux in the output
[12:36] <SteveA> and what kind of walk do you want to do over that structure?
[12:36] <lifeless> s/use/us/
[12:37] <lifeless> SteveA: transform it to the full path to every value  - so 'foo','foo/bar','foo/bar/gam','foo/bar/gam/quux' in the example above
[12:37] <ddaa> lifeless: one way you could do it with iterators: first traverse the structure to get all the directories, then use itertools.chain to build the listing.
[12:38] <SteveA> do you have a 10k long path?
[12:38] <SteveA> or many such paths?
[12:38] <ddaa> as many paths as version controlled files
[12:38] <SteveA> so, do you have a list of such dicts?
[12:38] <lifeless> SteveA: the total number of nodes in the tree is 10826
[12:39] <lifeless> SteveA: of those, 826 are dicts, 10000 are terminal
[12:39] <SteveA>  {'foo':{'bar':{'gam':'quux'}}}
[12:39] <SteveA> so you could provide an example with more branches
[12:39] <SteveA> there is just one branch there
[12:39] <SteveA> so it is all dicts
[12:39] <SteveA> and you want to get out of it every possible branch?
[12:40] <SteveA> i will also need to announce the forthcoming change to the launchpad list
[12:40] <SteveA> and coordinate the changing of various scripts, such as the "pending reviews" scripts
[12:40] <SteveA> that pull data from pages on the wiki
[12:42] <SteveA> EWINDOW
[12:42] <lifeless> SteveA: heh. yes
[12:42] <SteveA> anyway
[12:42] <lifeless> {'foo':{'bar':{'gam':'quux'}}, 'wham':'blech}
[12:42] <SteveA> you want to get each branch out as a path
[12:42] <lifeless> meh
[12:42] <lifeless> yes
[12:43] <SteveA> so, in that example, you want to get
[12:43] <SteveA> 1. 'foo/bar/gam/quux'
[12:43] <SteveA> 2. 'wham/blech'
[12:43] <lifeless> foo, foo/bar, foo/bar/gam, foo/bar/gam/quux, wham, wham/blech
[12:43] <lifeless> in that order
[12:43] <SteveA> ah
[12:43] <SteveA> well
[12:43] <SteveA> the order could be:
[12:44] <SteveA>  wham, wham/blech, foo, foo/bar, foo/bar/gam, foo/bar/gam/quux
[12:44] <lifeless> no
[12:44] <SteveA> why?
[12:44] <SteveA> dicts are unordered
[12:44] <lifeless> we sort
[12:44] <SteveA> aha
[12:44] <SteveA> what do you do with the paths afterwards?
[12:44] <lifeless> after yielding ?
[12:45] <SteveA> lets say i gave you a list of these paths
[12:45] <SteveA> what do you do next with that list?
[12:46] <lifeless> SteveA: callers of this function use the list to do operations like 'commit' and 'status'
[12:46] <lifeless> SteveA: the paths are typically passed to os functions like 'stat' and 'open' once, and then discarded
[12:47] <lifeless> give me a sec
[12:47] <SteveA> i want to think about this for a moment
[12:53] <jamesh> lifeless: perhaps this is an area where a small C extension would be appropriate?
[12:54] <lifeless> jamesh: I think there are deeper changes we can make which are more useful. 
[12:54] <lifeless> jamesh: having made those, C might be a good bet to make it faster still.
[12:55] <ddaa> duh, my two pass suggestion does not work
[12:55] <jamesh> fair enough
[12:56] <lifeless> but I see no reason it should not be blindingly fast without C for this.
[12:56] <ddaa> it's equivalent to building a list
[12:56] <SteveA> it's good that you have a data structure made of dicts and strings
[12:56] <SteveA> you can do stuff in C that avoids lots of python overhead for this
[12:56] <lifeless> SteveA: its not quite that simple, which is why I said its a lie.
[12:56] <SteveA> i don't think you'd be able to approach that in python
[12:56] <SteveA> unless you find a clever way to use a builtin to do it
[12:57] <jamesh> lifeless: all the functions in the itertools module are C, so if any of those functions cover what you are doing they may provide a speed boost
[12:57] <SteveA> so, D.iteritems()
[12:57] <SteveA> as a good start
[12:57] <ddaa> jamesh: by any chance, is there something like C "stream" facility, similar to what C# does, in python?
[12:58] <lifeless> SteveA: there are objects which have the dicts, and the dicts hold those objects.
[12:58] <jamesh> ddaa: got a pointer to the c# api?
[12:58] <ddaa> python generators are nice, but they suck to traverse tree structures
[12:58] <jamesh> ddaa: I'm not sure what a C# stream is
[12:58] <ddaa> jamesh: I can try to find it
[12:59] <jamesh> ddaa: it is possible that Python 2.5 generators are an equivalent
[01:00] <jamesh> ddaa: or do you just mean file-like objects
[01:00] <jamesh> ?
[01:00] <ddaa> the basic idea is to be able to "yield" an iterable, and the consumer sees the iterable items instead of the iterable itself
[01:01] <jamesh> ah.
[01:01] <spiv> jamesh: The annoying thing about recursive generators is the need to do "for x in g(...): yield x" rather than having a way to say "yield all x" or something.
[01:01] <jamesh> I don't think there is an equivalent of that
[01:01] <ddaa> typically what you need when you want e.g. to serialise a dom.
[01:01] <spiv> Which isn't *that* annoying.
[01:02] <ddaa> spiv: it's annoying because it can become a performance problem in some cases
[01:02] <spiv> ddaa: Having all the extra layers of bytecode interpretation?
[01:02] <ddaa> once the tree is a bit deep, yielding an item involves calling back into a bunch of generators
[01:02] <jamesh> spiv: I wonder if the Python compiler could detect and optimise "for x in iterable: yield x" loops?
[01:02] <lifeless> spiv: N^2
[01:03] <jamesh> it sounds simple ...
[01:03] <spiv> lifeless: I don't see how having a "yield all x" syntax helps the O() cost, if that's what you're saying, it's a function of the algorithm.
[01:03] <lifeless> what we were doing in that routine was pathjoining every item
[01:04] <lifeless> spiv: say you have a tree if iterators 10 deep
[01:04] <ddaa> spiv: it flattens the call tree
[01:04] <lifeless> spiv: with 1000 items at the bottom
[01:05] <spiv> ddaa: Not really, the recursion still has to happen, even if the interpreter is able to tear down the frame sooner it still has to be there to evaluate the inner generator.
[01:05] <lifeless> spiv: hmm, may be mistaken.... at the top level, you see 1000 items to yield. one down (this is a non-splitting tree to the bottom), you have to yield 1000 things, the next 1000 and so on, to the bottom which actually yields the 1000 things
[01:05] <ddaa> spiv: but it does not have to call through the intermediate generators to yield from the inner one
[01:06] <spiv> jamesh: It sounds possible for the compiler to detect and optimise, though I bet the improvement would be pretty modest.
[01:06] <lifeless> spiv: in which case it is linear reduction in cost
[01:07] <ddaa> jamesh: I think it would still be a very useful hint to the compiler to make it explicit that "here, I'm yielding all the elements of that iterable without touching them"
[01:07] <jamesh> spiv: well, the improvement should be the same as that given by using a "yield all iterable" statement
[01:07] <spiv> jamesh: Right, which is why I'm guessing it would be pretty modest.
[01:08] <jamesh> ddaa: sure.  And if you have a loop of the form "for x in iterable: yield x", the compiler could know that
[01:08] <jamesh> the loop couldn't be doing anything else
[01:08] <ddaa> function call overhead is not that modest in python, and I believe that calling into a generator has the usual expensive python function call cost.
[01:09] <spiv> ddaa: There's precisely one python-level call involved in "for x in somegenerator(args): yield x"
[01:09] <ddaa> multiply that by the depth of each item you are yielding
[01:09] <spiv> ddaa: Or more exactly, the expensive part of python calls is the frame setup.
[01:09] <ddaa> that can quickly becomes several millions
[01:10] <spiv> ddaa: Re-entering a generator doesn't incur that cost.
[01:10] <lifeless> where does lsprof assign frame setup costs? to the caller ?
[01:11] <mpt> SteveA, Skype still hasn't sent me my new password -- we could chat on IRC, or Skype tomorrow
[01:11] <jamesh> ddaa: if I have an iterator implemented in C, and am iterating it with PyIter_Next() from some other bit of C code, there are no Python stack frames created
[01:11] <ddaa> mh, I might have been mistaken
[01:12] <spiv> jamesh: And generators are interators implemented in C, sort of :)
[01:12] <ddaa> for one thing, this optimisation was driven by hotshot timings, which I found later to be less than entirely reliable
[01:12] <jamesh> ddaa: so if the compiler could optimise "for x in iterable: yield x" into a special instruction, the generator implementation could pass back values without executing Python code
[01:12] <lifeless> spiv: nice typo
[01:12] <ddaa> jamesh: yes, I think there's a strict equivalence there
[01:12] <spiv> lifeless: Ta :)
[01:13] <SteveA> mpt: let's do a bit of irc then
[01:13] <ddaa> anything else in the for loop would prevent the use of that optimisation, and the use of the hypothetical "yield all" syntax as well
[01:14] <spiv> jamesh: Unless the interpreter could somehow cleverly chain multiple nestings of these together efficiently, I think it would be only a small improvement.
[01:14] <lifeless> different question, is stringobj + '/' + stringobj slower than '/'.join((stringobj, stringobj)) ?
[01:15] <spiv> lifeless: hmm, I'd guess it would be faster.
[01:15] <spiv> Because operators of builtin types are much faster than function calls.
[01:16] <jamesh> you end up creating a temporary string though
[01:16] <SteveA> what about '%s/%s' ?
[01:16] <lifeless> jamesh: right, thats what I was thinking
[01:16] <lifeless> SteveA: could do. I should bench them :). 
[01:16] <SteveA> creating strings is cheap
[01:17] <spiv> jamesh: Yeah, possibly for large enough strings it's more expensive, but with recent optimisations to string addition I'm not sure that even then it's true.
[01:17] <ddaa> >>> timeit.Timer("'a' + '/' + 'b'").repeat()
[01:17] <ddaa> [0.96357202529907227, 1.05560302734375, 0.39551806449890137] 
[01:17] <ddaa> >>> timeit.Timer("'/'.join(('a', 'b'))").repeat()
[01:17] <ddaa> [1.3867409229278564, 1.3909780979156494, 0.99723100662231445] 
[01:18] <spiv> jamesh: Python now tries to resize strings inplace on BINARY_ADD, if there are no other references to it.
[01:18] <ddaa> in that specific case, the former is a tad bit faster
[01:19] <spiv> jamesh: So the repeated-addition idiom isn't O(n**2) anymore, in most cases.  It depends on the bytecode a little, though.
[01:19] <lifeless> bzrlib.benchmarks.bench_commit.CommitBenchmark.test_slash_add                                                                                                                                  OK          51ms
[01:20] <lifeless> bzrlib.benchmarks.bench_commit.CommitBenchmark.test_slash_join                                                                                                                                 OK          15ms
[01:20] <lifeless> bzrlib.benchmarks.bench_commit.CommitBenchmark.test_slash_percent                                                                                                                              OK          16ms
[01:20] <lifeless> these are consistent
[01:20] <lifeless> string add is slowest
[01:20] <lifeless> percent joining is a little slower than doing a join
[01:21] <spiv> lifeless: probably the tuple allocation is the difference with percent joining.
[01:21] <lifeless> http://pastebin.ca/58331
[01:22] <spiv> lifeless: learn to love timeit.
[01:22] <spiv> python -m timeit -s "a, b = 'a', 'b'" "a + '/' + b"
[01:22] <lifeless> I have a handy hammer dagnammit
[01:22] <ddaa> >>> timeit.Timer("a + '/' + b", setup="a, b = 'aaaaaaaaaaaaaaaaaaaa', 'bbbbb'").repeat()
[01:22] <ddaa> [1.2092900276184082, 1.2048490047454834, 0.83875298500061035] 
[01:22] <ddaa> >>> timeit.Timer("'/'.join((a,b))", setup="a, b = 'aaaaaaaaaaaaaaaaaaaa', 'bbbbb'").repeat()
[01:22] <ddaa> [1.6951849460601807, 1.1019880771636963, 0.58829784393310547] 
[01:23] <ddaa> it does look like addition is a bit faster
[01:23] <jamesh> spiv: there is one more tuple created in '/'.join((a,b)) compared to 
[01:23] <spiv> ddaa: And you should learn to love the timeit command line :P
[01:23] <jamesh> '%s/%s' % (a,b)
[01:23] <lifeless> well
[01:23] <spiv> jamesh: Is there?  Oh, the function argument?
[01:23] <jamesh> spiv: yeah args are passed to the function as a tuple
[01:23] <spiv> jamesh: I would have thought the join method would use METH_O?
[01:24] <lifeless> at 100,000 calls, slash joining is still faster for me.
[01:24] <spiv> jamesh: Yeah, it does... I thought that would avoid the tuple construction?
[01:24] <jamesh> spiv: that just causes the C code to verify that there is one item in the args tuple and pass that to the C function
[01:24] <jamesh> (iirc)
[01:25] <lifeless> I'm not sure what timeit is doing here, but I'm more confident in my real-world benchmark here than timeit.
[01:26] <jamesh> spiv: I tell a lie.  there is PyCFunction special casing in ceval.c
[01:26] <lifeless> ah, interesting, at 500000 calls, it has changed.
[01:26] <spiv> jamesh: I was about to say :)
[01:27] <spiv> lifeless: the number of calls should not be a factor.  Possibly your use of range() is causing oddness?
[01:28] <spiv> i.e. the 100th evaluation of "a + '/' + b" and the millionth call of it should be just as fast or slow as each other, give or take noise.
[01:30] <lifeless> ok, convinthed
[01:32] <ddaa> spiv: in previous tests, I found the python timing noise to have very weird characteristics
[01:32] <ddaa> it did not seem to average out with increased numbers of iterations
[01:34] <ddaa> another interesting datum, the string addition is optimised by psyco much much better than the '/'.join.
[01:35] <spiv> ddaa: "python -m timeit -v ..." is pretty consistent for me -- the first set of N iterations is always a bit slow, but the other two are always very close.
[01:35] <ddaa> with psyco, string addition is 20x faster
[01:36] <ddaa> spiv: that's not how it behaves in my experience (even looking at my new timings right here)
[01:37] <ddaa> lifeless: if you are in micro-optimisation mood, I think it would be worth trying transforming the recursive algorithm into an iterative one
[01:38] <lifeless> ddaa: function overhead is not much of an issue here
[01:38] <lifeless> ddaa: only 800 function calls
[01:38] <lifeless> and max depth is 3
[01:38] <ddaa> well, I would give it a try. That said, I'm going to back to what I'm paid for :)
[01:40] <lifeless> ddaa: I've already beaten into acceptable
[01:40] <lifeless>       +10825            0    491.6700    124.3990   +bzrlib.inventory:871(iter_entries)
[01:40] <lifeless> 491ms under lsprof is not an issue when the total time taken is 140072ms
[01:41] <ddaa> well, modulo profiler biases...
[01:41] <jamesh> what was the before figure?
[01:41] <spiv> ddaa: If I use the -n arg to "python -m timeit" to force the number of iterations below it's default threshold, I get different results, but at its threshold or higher it's consistent.
[01:41] <lifeless> jamesh: I dont have it handy. I can generate it, be a few minutes
[01:42] <lifeless> over the whole test run is
[01:42] <ddaa> but there are likely more to be gained in other parts of the code
[01:42] <lifeless>       259309       194352   2749.8370   2645.2650   bzrlib.inventory:871(iter_entries)
[01:42] <lifeless> so its very much in the 'not a problem basket'
[01:43] <spiv> ddaa: (the nice thing about "python -m timeit" is it automatically picks a number of loops that takes between 0.2 and 2s, which seems to give reliable results, smaller times are more susceptible to noise)
[01:44] <mpt> lifeless, "bzr diff -r branch:../rocketfuel" returns a lot of changes that were made by other people, as well as the changes I've made in this branch. But "bzr merge ../rocketfuel" returns "Nothing to do". Should I be concerned?
[01:44] <lifeless> I'm still concerned by        10832            0  31236.6910    499.2190   bzrlib.store.versioned:187(get_weave_or_empty)
[01:45] <lifeless> which is IMNSHO way to slow
[01:45] <lifeless> but the open() call is probably not something we can improve much on
[01:46] <lifeless> what we have planned, but haven't done yet, is getting lsprof output for just a timed call area.
[02:06] <spiv> SteveA: Btw, I saw eurovision, and I think Lithuania were robbed.
[02:07] <SteveA> many people here have been talking about it
[02:07] <SteveA> i think i heard the song... it was self-referential
[02:07] <SteveA> but for me, finnish doom metal wins anytime 
[02:08] <spiv> I admit the song with the "arockalypse" was my second choice.
[02:09] <spiv> And the "day of rockoning".
[02:14] <ddaa> mpt: what you describe does not sound normal
[02:14] <ddaa> mpt: what does "bzr update" do?
[02:16] <mpt> ddaa, "Tree is up to date."
[02:16] <ddaa> mpt: what does merging your branch into rocketfuel do?
[02:18] <mpt> ddaa, merging it *in* to rocketfuel?
[02:18] <mpt> Or merging from rocketfuel into it?
[02:18] <ddaa> merging into rocketfuel
[02:18] <ddaa> as opposed to merging rocketfuel into your branch
[02:18] <lifeless> jamesh: previous total ime
[02:19] <lifeless>       259309       194352   9903.7670   3989.2800   bzrlib.inventory:875(iter_entries)
[02:19] <lifeless> of which
[02:19] <lifeless>      +190848            0   5787.7500   3580.9870   +posixpath:56(join)
[02:19] <mpt> ddaa, I've never merged anything into rocketfuel before
[02:19] <mpt> (there would be no point, except for debugging)
[02:20] <mpt> ddaa, that gives me a pile of changes and pending merges
[02:20] <ddaa> that's quite useful to see what diff merging a branch would introduce
[02:20] <ddaa> mpt: are those changes all yours?
[02:20] <mpt> despite the fact that I just updated my rocketfuel copy
[02:20] <mpt> No, most of them are bradbs
[02:20] <mpt> ok, half of them are bradb's, along with some Mark and some Stuart etc
[02:21] <ddaa> are these the actual changes, or are they reversed?
[02:21] <mpt> How do I tell? They're ellipsized commit messages
[02:21] <mpt> elided, even
[02:21] <ddaa> I asked you which changes, not which pending merges...
[02:21] <ddaa> anyway
[02:22] <mpt> There are three db schema patches added, and none removed
[02:22] <ddaa> apparently your branch merged some branch which is not yet in rocketfuel
[02:22] <mpt> So I'm guessing they're actual changes
[02:22] <mpt> Was there a rollback recently?
[02:22] <ddaa> none that I'm aware of
[02:23] <ddaa> mpt: you could tell
[02:23] <ddaa> if the pending merges you get when merging show a pqm commit
[02:24] <mpt> ah! yes, there are six of those
[02:24] <ddaa> that suggest that the rocketfuel branch you are checking against is out of date
[02:24] <ddaa> and that your branch is more up to date
[02:25] <ddaa> _or_ that something amazingly bad happened that caused 6 rocketfuel commits to disappear
[02:25] <ddaa> so I'd rather lean towards the user error
[02:25] <mpt> The only way, that I can think of, that that could have happened is if chinstrap's rocketfuel has regressed
[02:26] <ddaa> try reverting your merge from your rocketfuel branch, then pull from chinstrap's rocketfuel
[02:26] <mpt> or, more likely, there's an error in my update-my-rocketfuel script
[02:26] <mpt> rsync -aP --delete chinstrap:/home/warthogs/archives/rocketfuel-built/launchpad/ ~/hacking/lp/rocketfuel
[02:26] <mpt> Is that correct?
[02:27] <ddaa> looks right
[02:27] <ddaa> I guess that you merged rocketfuel from chinstrap (through sftp) into your personal branch
[02:27] <ddaa> that would explain your branch being more up to date than your local rocketfuel
[02:28] <mpt> I never do that
[02:29] <mpt> Is there a difference between /home/warthogs/archives/rocketfuel-built/launchpad and /home/warthogs/archives/rocketfuel/launchpad/devel ?
[02:29] <ddaa> in principle, not
[02:29] <ddaa> but there might be some skew
[02:31] <spiv> They look to be in sync to me.
[02:32] <mpt> geh
[02:32] <mpt> Now, relative to rocketfuel, my branch removes a lot of recent work
[02:32] <ddaa> well, that means it's out of date
[02:33] <ddaa> which is normal since you have just rsynced
[02:33] <mpt> oh, that's branch:
[02:33] <mpt> I thought I was looking at ancestor:
[02:33] <mpt> hooray, all working now
[02:34] <mpt> thanks ddaa
[02:34] <ddaa> mpt: no problem, apparently you were just confused
[02:34] <ddaa> and everything was working as it should
[02:35] <mpt> I got results different from what I'd ever got before
[02:35] <mpt> I had a right to be confused :-P
[02:35] <ddaa> the fact you were confused suggest that something is not as obvious as it should
[02:41] <jordi> mpt: hey
[02:42] <jordi> mpt: so, I'm getting somewhat annoyed and disturbed about the growing amount of junk/bogus products getting registered in LP
[02:42] <jordi> do you think we can think about a strategy to alleviate this?
[02:42] <jordi> The usual "Report this as a bogus product" button comes to mind
[02:43] <jordi> I can raise this on the list, I guess that'll be better
[02:47] <mpt> yes
[02:47] <mpt> The closest related spec is probably https://wiki.launchpad.canonical.com/RemovingObjects
[02:47] <mpt> jordi ^
[02:49] <jordi> mpt: aha
[02:49] <jordi> thx
[03:06] <dilys> Merge to devel/launchpad/: [r=SteveA]  Tweaks wording, and reorders form elements, on bug reporting form. (r3588: Matthew Paul Thomas)
[03:18] <stub> carlos: Can you please generate one or two oopses on staging?
[03:19] <carlos> stub: should they be timeouts? or any opps is valid?
[03:19] <stub> Timeouts
[03:19] <stub> You seem to know the right pages ;)
[03:20] <stub> Ahh... got one
[03:20] <carlos> stub: OOPS-143S2 and OOPS-143S1
[03:20] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/143S2
[03:20] <carlos> ;-)
[03:20] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/143S1
[03:20] <stub> ta
[03:20] <carlos> stub: https://staging.launchpad.net/distros/ubuntu/dapper/+lang/es
[03:20] <carlos> that page timouts always in staging
[03:20] <carlos> it's near 1MB....
[03:21] <carlos> I think we should move it to use batching....
[03:21] <stub> Yup. Sending a page that size is just plain rude.
[03:24] <stub> SteveA: https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-05-23/S1 - the id of the connection instance is in a comment at the start of the SQL (hack, I know) and rollback and commit statements are being logged too.
[03:26] <SteveA> cool
[03:29] <spiv> stub: wonderful
[03:30] <stub> staging only atm - we should be able to get it on production with the next shipit update (Thu?)
[03:31] <SteveA> when we do more work on the oops system, defining a filesystem-level protocol, then we'll add an explicit place for the connection id
[03:32] <SteveA> can we link this connection id to something in the postgres logs?
[03:32] <SteveA> or, is it possible to add a statement that will be logged saying "connection id in zope is this in postgres" ?
[03:36] <stub> We could emit a message to the PostgreSQL logs
[03:36] <stub> We can match things up anyway using the timestamp
[03:37] <SteveA> assuming the app server is synched very closely to the database
[03:37] <stub> Just a little slower and more manual
[03:37] <stub> It is
[04:25] <iwj> Subject: [Bug 46110]  Re: [Bug 46110]  Re: [Bug 46110]  Re: [Bug 46110]  Re: Segmentation fault while trying to install package "puredata"
[04:25] <Ubugtu> Malone bug 46110 in dpkg "Segmentation fault while trying to install package "puredata"" [Normal,Unconfirmed]  http://launchpad.net/bugs/46110
[04:25] <Ubugtu> Malone bug 46110 in dpkg "Segmentation fault while trying to install package "puredata"" [Normal,Unconfirmed]  http://launchpad.net/bugs/46110
[04:25] <Ubugtu> Malone bug 46110 in dpkg "Segmentation fault while trying to install package "puredata"" [Normal,Unconfirmed]  http://launchpad.net/bugs/46110
[04:25] <Ubugtu> Malone bug 46110 in dpkg "Segmentation fault while trying to install package "puredata"" [Normal,Unconfirmed]  http://launchpad.net/bugs/46110
[04:25] <iwj> Oh, and a nice bug in Ubugtu too.
[04:28] <sfllaw> Seveas isn't here to see it.
[04:29] <sfllaw> If only there were a bug tracker for Ubugtu...
[04:46] <kiko-zzz> salgado, which attached patch?
[04:47] <kiko> salgado, also, I was curious to see if tal:attributes="selected" would actually work.
[04:49] <stub> kiko, salgado: Do either of you know if shipit-reports should be reenabled for a run tomorrow, or should it remain off for a while longer?
[04:49] <kiko> stub, let me clear that with salgado, 5m
[04:49] <stub> erm... shipit-exports I mean
[04:50] <kiko> exports definitely yes, stub 
[04:50] <stub> ok
[04:52] <salgado> kiko, sorry, I forgot to attach it. just sent it, though
[04:52] <SteveA> salgado: hi
[04:52] <SteveA> salgado: i'm confused as to what i should review for you
[04:52] <SteveA> i have three emails with diffs.  one supercedes one other
[04:52] <SteveA> so i have two left
[04:52] <salgado> kiko, yes, the thing you suggested does work
[04:53] <salgado> SteveA, one is that you did a review already?
[04:53] <kiko> > +                    selected option/is_selected">
[04:53] <kiko> bah
[04:54] <SteveA> one is "shipit trivialities"
[04:54] <SteveA> one is "initial review: new shipit pages"
[04:54] <salgado> SteveA, oh, sorry for that
[04:54] <SteveA> what should i review next?
[04:54] <salgado> the shipit trivialities I should have sent to kiko
[04:55] <SteveA> so i should review the "initial review: new shipit pages"
[04:56] <kiko> SteveA, yeppoolas
[04:56] <kiko> hey BjornT 
[04:56] <salgado> SteveA, yes!
[04:56] <kiko> salgado is telling me what appears to be a tall tale
[04:56] <kiko> :-)
[04:56] <BjornT> hi kiko 
[04:56] <kiko> BjornT, observe this line of TAL:
[04:57] <kiko>  > +                    selected option/is_selected">
[04:57] <kiko> oh bummer
[04:57] <salgado> this is inside a tal:attributes
[04:57] <kiko> right
[04:57] <SteveA> we have a TALES namespace for doing "selected" kinda things
[04:58] <salgado> SteveA, do you have the subject of the message where I sent the shipit-trivialities patch? (I can't seem to find it here)
[04:58] <SteveA> i don't know how useful it is in practice
[04:58] <SteveA> perhaps "Shipit trivialities"
[04:59] <BjornT__> kiko: you'll have to show me that TAL again, my main internet connection is flaky atm, and i got disconnected.
[05:02] <SteveA> salgado: I'd like to get the behaviour of shipit for shipit admins changed sometime
[05:02] <SteveA> salgado: i find it very awkward that the main "ordering" pages behave differently for admins.
[05:02] <kiko> BjornT, here:
[05:02] <kiko> >          <option tal:repeat="option view/release_options"
[05:02] <kiko> >                    tal:attributes="
[05:02] <kiko> >                    value option/name;
[05:02] <kiko> >                    selected option/is_selected">
[05:02] <kiko> BjornT, is_selected is a bool (True/False
[05:02] <kiko> )
[05:04] <salgado> SteveA, you mean, the redirect?
[05:04] <kiko> BjornT, what does the option HTML look like when is_selected is True, and what does it look like when is_selected is False?
[05:04] <SteveA> salgado: i guess so
[05:04] <sfllaw> kiko: Under https://launchpad.net/distros/, why is fedora not read-only?
[05:05] <SteveA> salgado: the UI for ordering should behave for admins exactly as it does for requesters
[05:05] <kiko> sfllaw, to be honest..  I don't know what that flag does :)
[05:05] <sfllaw> Neither do I!
[05:05] <SteveA> salgado: this allows admins to get a realistic experience, and also provides fewer special paths through the system.
[05:05] <sfllaw> I just recall that you added that distro.
[05:05] <kiko> sfllaw, hey, I just press the buttons, dude. :)
[05:05] <sfllaw> kiko: Gotcha.  :)
[05:05] <BjornT> kiko: i'm not quite sure, but i'd guess it's selected="True" and selected="False"
[05:05] <kiko> BjornT, salgado tells me there is some sort of magic that is producing selected="selected"
[05:06] <kiko> BjornT, I find that /very/ hard to believe
[05:06] <salgado> SteveA, that was a requirement of the new shipit, so that the admins could make requests containing CDs of all flavours in a single place
[05:06] <kiko> in fact I think he is testing in the wrong tree
[05:07] <salgado> SteveA, it's not the main ordering page that behaves differently. the shipit admins have a separate page for that. they still can have the realistic experience by accessing the page for normal users
[05:07] <salgado> kiko, dude, you don't trust me?
[05:07] <kiko> salgado, SMTC
[05:07] <SteveA> salgado: every time i have tried to test the normal user interface, i get redirected elsewhere.
[05:07] <SteveA> salgado: i haven't looked into why, but i find it annoying.
[05:08] <SteveA> salgado: the admins can have a separate page, but the standard workflow should still work normally, from going to shipit.ubuntu.com onwards
[05:09] <salgado> SteveA, I tried to optimize the workflow for Marilize, as she doesn't want to see the user-visible page every time she logs in
[05:09] <kiko> SteveA, for the record I think salgado is right, and that's how the admins expect it works
[05:10] <SteveA> she can have a button in her browser to log in elsewhere
[05:10] <salgado> I can add a link to the user-visible page on the portlet, and I think that's a good idea. 
[05:10] <BjornT> kiko: could be. i didn't know about it, but a quick google search shows that it might be possible to do so.
[05:10] <kiko> BjornT, I guess I'll just have to discover myself :-)
[05:11] <SteveA> salgado: that's a helpful compromise.  i disagree with the UI / workflow design that you and kiko are in favour of.
[05:11] <SteveA> how often does marilize go to the shipit front page?
[05:12] <SteveA> she can have either a button in her browser's toolbar to go to an admin page, and / or have a special link on the front page
[05:12] <BjornT> kiko: yeah :) although personally i would have used a SelectWidget instead...
[05:12] <SteveA> the front page of shipit appears in advertising materials, and users' descriptions in support requests and bug reports
[05:13] <SteveA> if the admins don't get a genuine user experience, or as near to it as possible, then they can't well appreciate the system from the users' point of view.
[05:14] <salgado> yes, that is true. but only when they're testing a new feature or something like that. not on they day-to-day work, I think
[05:15] <kiko> salgado, is BjornT right>
[05:19] <salgado> kiko, probably, but that's not a GFV, and I'd prefer to convert it to a GFV and do what BjornT suggested after the mirror prober changes I need to do
[05:20] <kiko> salgado, yeah.
[05:20] <kiko> okay.
[05:21] <kiko> give me 10m and I will come up to see this for myself
[05:21] <BjornT> salgado: you don't have to use a GFV in order to use widgets. but it depends on if you use other widgets on the page or not.
[05:22] <SteveA> salgado: review sent
[05:23] <SteveA> salgado and kiko: the general principle is this: a URL (or a page) should generally not change radically in behaviour depending on who you are.  if it does, there should be a really good reason for it to do so.
[05:24] <salgado> SteveA, agreed. I just thought that optimizing it for Marilize's work was a good reason
[05:25] <SteveA> there's an assumption about marilize's work that i think isn't true
[05:25] <salgado> if she goes to https://shipit.ubuntu.com/ once a day, then I think the change in the behaviour is not necessary
[05:25] <SteveA> that she needs to repeatedly type in "shipit.ubuntu.com"
[05:25] <SteveA> if she goes 200 times a day, it is still not necessary
[05:25] <SteveA> because she uses the same webbrowser software to do so
[05:26] <salgado> BjornT, right. I was just trying to point that I'd prefer to do that change later
[05:26] <jordi> heh
[05:26] <salgado> SteveA, if she has a bookmark to https://shipit.ubuntu.com/ and uses it lots of times a day, then it might be needed, I think
[05:27] <jordi> I just approved a pot file which had been submitted around 30 seconds earlier
[05:27] <SteveA> so, i'd be in favour of simplifying shipit that tiny bit, and telling marilize about how to add a bookmark-button to her browser
[05:27] <salgado> sounds like a plan
[05:27] <SteveA> salgado: not really.  she can change the bookmark, or add one
[05:27] <SteveA> it takes zero effort to maintain a bookmark on one person's machine
[05:27] <SteveA> and noticable effort to maintain a feature in software
[05:32] <jordi> carlos: ping
[05:33] <carlos> jordi: pong
[05:33] <jordi> carlos: so I imported a good 50 tuxpaint files
[05:33] <jordi> and now I don't see where they are
[05:34] <jordi> tuxpaint-stamps in dapper
[05:34] <jordi> they were in the approved queue, now I don't see them anywhere
[05:36] <carlos> jordi: https://launchpad.net/rosetta/imports/+index?status=FAILED&type=all&start=400&batch=75
[05:36] <carlos> jordi: I guess they have the same problem the .pot file has
[05:37] <carlos> duplicated msgids
[05:37] <jordi> oh no
[05:38] <jordi> msgfmt: tuxpaint-stamps-ca.po: manca el camp de capalera PO-Revision-Date en la capalera
[05:38] <jordi> msgfmt: tuxpaint-stamps-ca.po: manca el camp de capalera Last-Translator en la capalera
[05:38] <jordi> msgfmt: tuxpaint-stamps-ca.po: manca el camp de capalera Language-Team en la capalera
[05:38] <jordi> are these fatal?
[05:39] <carlos> jordi: did you see the announcement review I asked? could you take a look today before leaving?
[05:39] <carlos> jordi: well, a header is mandatory, if it lacks such fields, I think it's ok
[05:39] <jordi> carlos: it's not those
[05:39] <jordi> it's tuxpaint-stamps what have gone missing
[05:40] <jordi> carlos: ugh, my mail is down for some reason
[05:40] <jordi> can you resend to my gva.es address?
[05:40] <jordi> jmallach@
[05:40] <jordi> wait
[05:40] <jordi> wait, won't be necessary I hope
[05:40] <jordi> I'll tell you in am in
[06:20] <carlos> see you later!
[07:00] <salgado> SteveA, around?
[07:00] <SteveA> yes, but going to the gym shortly
[08:14] <bradb> mpt: Why did you remove the DesignProblems document? I thought it had lots of useful advice for LP devs to consider.
[08:28] <dilys> Merge to devel/launchpad/: A lot of small fixes to the new shipit. r=kiko (r3589: Guilherme Salgado)
[08:31] <salgado> BjornT, around?
[08:31] <BjornT> salgado: yeah
[08:32] <salgado> BjornT, nevermind. while writing the question I realized the answer. sorry
[08:33] <kiko> BjornT, you still get paid though ;)
[08:33] <BjornT> cool :)
[09:18] <salgado> hey kiko. up for another quick review?
[09:20] <salgado> if you say yes: https://chinstrap.ubuntu.com/~dsilvers/paste/file6MsvhJ.html
[09:47] <cprov> good night guys, see you tomorrow
[10:08] <bradb> kiko: http://66.130.66.92:8086/products/firefox/+bug/1
[10:19] <kiko> bradb, I don't quite like Direct and Indirect
[10:20] <bradb> kiko: Can you think of a better way to differentiate subscribers that have a row in BS vs. those that don't?
[10:21] <bradb> (since that is the only difference that can be guaranteed between the two lists)
[10:21] <kiko> yeah
[10:21] <kiko> thinking
[10:23] <bradb> I agree that it's not terribly descriptive, but the only other solutions I've though of involve writing some help text, linked from a (_What's this?_) or something.
[10:24] <kiko> I'm also on the phone, btw
[10:25] <bradb> ok
[10:38] <kiko> bradb, give me 20m
[10:38] <bradb> ok
[10:38] <kiko> but mmm
[10:38] <kiko> how about removing the Direct heading
[10:39] <kiko> and using something else for Indirect
[10:39] <kiko> perhaps
[10:39] <kiko> "Also being notified:"
[10:39] <kiko> or "Also notifying:"
[10:39] <kiko> or "Also being messaged"
[10:39] <kiko> or something like that?
[10:40] <kiko> or "Implicit subscribers"  even
[10:40] <kiko> though that's rather obscure
[10:40] <kiko> bradb, does mpt have an opinion?
[10:40] <bradb> "Also notifying:" seems more human-readable
[10:40] <bradb> well, it was either you or him who suggested direct/indirect, so it must have been him
[10:48] <bradb> for all these suggestions, i think the only way the user will /understand/ what they're being shown is with some kind of help link in the portlet, pointing to a page that explains more about direct/indirect subs (whatever the portlet calls them)
[10:55] <SteveA> salgado: ping
[10:56] <salgado> SteveA, pong
[11:10] <bradb> SteveA: ping
[11:15] <kiko> bradb, well, maybe I agree. but most users won't read anything
[11:15] <kiko> and just move ahead not really knowing the difference 
[11:15] <kiko> Other subscribers:
[11:16] <bradb> i agree that most won't read
[11:16] <kiko> Other people notified:
[11:16] <bradb> might as well just do "Also notifying:"?
[11:17] <SteveA> bradb: i'm kinda going to sleep now
[11:17] <kiko> or Also notified:
[11:17] <bradb> SteveA: ok, no worries
[11:17] <kiko> bradb, yeah, I think I like that.
[11:17] <kiko> bradb, the help link can go to help.launchpad.net, eventually <wink>
[11:17] <bradb> a3 n6d:
[11:20] <kiko> mmm
[11:53] <lifeless> morning
[11:53] <kiko> morning morning
[12:02] <lifeless> have we switched wikis yet ?
[12:03] <mdke> you're switching wikis too?
[12:03] <mdke> everyone is switching
[12:04] <bradb> We hadn't switched last I checked about an hour ago
[12:04] <lifeless> cool
[12:04] <mdke> lifeless: btw that guy didn't get back to me yet
[12:11] <jordi> carlos: ping?
[12:11] <jordi> I guess he's out
[12:11] <jordi> this queue is nearly empty.
[12:12] <jordi> 76   134  of 134 results
[12:12] <jordi> just 134 files in the import quue
[12:31] <kiko> hey bradb 
[12:31] <bradb> kiko: hi
[12:31] <kiko> you know, the subscribe me as I comment feature in Malone is really nice.
[12:31] <kiko> I just missed it in Bugzilla. :)
[12:31] <bradb> it's not so bad, hey
[12:31] <kiko> no, indeed it isn't
[12:32] <kiko> one day we will get rid of that ridiculous third column
[12:32] <kiko> and then the world will be shiny
[12:32] <kiko> :)
[12:32] <bradb> "one day"...!
[12:32] <kiko> I should say that if you browse in 1024px wide it is not so bad
[12:33] <kiko> but for me @ 640px 
[12:33] <kiko> it is terrible
[12:33] <bradb> There might be a chance if I do a user survey approach again, with prototypes
[12:33] <kiko> yeah, maybe
[12:44] <matsubara> man this new bzr is beautiful
[12:44] <matsubara> ultra fast!
[12:44] <bradb> indeed
[12:56] <kiko> it burns jiffies
[01:06] <lifeless> matsubara: which one ?
[01:06] <kiko-zzz> the one the bzr team produces
[01:06] <kiko-zzz> high quality piece of code if I ever saw one
[01:07] <kiko-zzz> see how it is? when it works you're an angel. when it breaks you're the devil!
[01:09] <matsubara> lifeless: I meant the latest version with this knits thing
[01:09] <lifeless> kiko-zzz: ha!
[01:09] <kiko-zzz> welcome to userland!
[03:37] <sabdfl> night night all
[05:02] <mpt_> Goooooooooooooooooooooooooood afternoon Launchpadders!
[06:30] <spiv> lifeless: Could you merge /home/warthogs/archives/spiv/launchpad/importd-bzr-0.8/ /home/warthogs/archives/spiv/bzr/update-to-0.8/ /home/warthogs/archives/spiv/bzrtools/dev/ for me? :)
[06:40] <lifeless> spiv: three branches ?
[06:40] <lifeless> spiv: oh, lp, bzr and bzrtools. sure, will do tonight.
[06:40] <spiv> lifeless: launchpad (to fix importd tests), bzr and bzrtools.  Right.
[06:40] <lifeless> can the lp one merge in early or does it require all at once ?
[06:40] <spiv> All at once, unfortunately :(
[06:41] <spiv> check_merge passes locally, but it would be worth double-checking that it also passes on balleny.
[08:35] <distanceisdeath> hello
[08:36] <distanceisdeath> anybody there?
[08:39] <carlos> morning
[08:39] <distanceisdeath> haha
[08:39] <distanceisdeath> its 2:39 AM at my house
[08:39] <carlos> 08:39 here
[08:40] <distanceisdeath> nixew
[08:40] <distanceisdeath> nice*
[08:40] <distanceisdeath> well you wanna help me?
[08:41] <jsgotangco> distanceisdeath: would be nice if you just ask away
[08:41] <distanceisdeath> okay
[08:41] <distanceisdeath> im trying to install linux on the same hard drive
[08:41] <distanceisdeath> is this possible?
[08:41] <jsgotangco> distanceisdeath: #ubuntu should be able to help, but yes
[08:41] <distanceisdeath> okay
[08:42] <distanceisdeath> thank you
[09:36] <SteveA> carlos: hello
[09:37] <carlos> SteveA: hi
[09:37] <SteveA> i spoke wiwth mark last night about the translation priorities
[09:37] <SteveA> the priorities were set to just 0, 50 or 100 or somethingn like that
[09:37] <SteveA> which, while a decent start, didn't really direct people to translate the very most important things
[09:38] <SteveA> so mark has gone in and set some priorities to be different
[09:38] <carlos> SteveA: ok
[09:38] <SteveA> please, with jordi, take a look at what mark has done
[09:38] <carlos> SteveA: jordi has in his task list to change them
[09:38] <SteveA> and see if anything else needs doing there
[09:38] <carlos> ok
[09:39] <SteveA> this was quite urgent, because of dapper being released soon
[09:39] <SteveA> so that's why mark went and changed them sooner
[09:40] <carlos> right
[09:40] <carlos> jordi: around?
[09:46] <carlos> SteveA: did mark finish the other code changes related with priorities?
[09:46] <SteveA> well...
[09:46] <SteveA> it turns out that you fixed up the code in almost exactly the same way mark did
[09:46] <SteveA> so mark was left with a one line diff
[09:46] <SteveA> and so didn't do the merge, because it was really no difference
[09:47] <SteveA> so, thanks carlos for getting the priorities landed well
[09:47] <carlos> oh, so those were bug fixes. :-P
[09:54] <SteveA> yes
[09:57] <jordi> carlos, here
[09:58] <carlos> jordi: would you have time tonight to take a look to the templates priorities ?
[09:58] <jordi> yes
[09:58] <jordi> I have been working mainly on the import queue
[09:59] <jordi> I didn't know the priorities was urgent for dapper
[09:59] <jordi> I for some reason understood it was a longer term plan for edgy
[10:01] <carlos> jordi: I need to leave today early in the afternoon today and will be back at home around 21:30 CEST
[10:01] <carlos> jordi: would 22:00 work for you?
[10:01] <jordi> I have dentist at 3:30, I don't know at what time I'll be finished.
[10:02] <jordi> carlos: ugh, possibly too late
[10:02] <carlos> hmmm
[10:03] <carlos> jordi: ok, will you be available by phone? (no more than 15 minutes)
[10:13] <jordi> carlos: yup
[10:17] <carlos> jordi: ok, then, let's do it this way. Review the priorities this afternoon and I will call you at 22:00 and we comment it. I will take a look also before calling you
[10:17] <carlos> jordi: does it work for you?
[10:17] <jordi> sure
[10:17] <cprov> good morning, hackers
[10:17] <jordi> yeah
[10:17] <jordi> carlos: the last few entries in the queue I have some questions about
[10:18] <carlos> cprov: morning
[10:18] <carlos> jordi: I just approved amarok
[10:18] <jordi> carlos: we need to support "nso" in Rsoetta
[10:18] <cprov> carlos: hey, dude. how is it going ?
[10:18] <carlos> jordi: do you want to talk about the others now, or tonight?
[10:18] <jordi> there's at least one translation to that languages in the queue
[10:18] <carlos> jordi: isn't it already visible?
[10:18] <jordi> maybe not now
[10:18] <jordi> but if I see I can sneak out of this task here, I can ping youi
[10:19] <carlos> cprov: rocking ;-)
[10:19] <jordi> carlos: I didn't see it last night
[10:19] <carlos> jordi: ok
[10:19] <jordi> Unless it's not called Northern Sotho
[10:19] <carlos> jordi: nso or nds ?
[10:19] <cprov> carlos: very good ;)
[10:19] <jordi> nso, iirc?
[10:19] <carlos> jordi: it's called Sotho, Northern
[10:19] <carlos> jordi: and it's already visible
[10:20] <jordi> doh
[10:20] <jordi> no wonder I didn't find it
[10:20] <carlos> jordi: do you think we should rename it?
[10:20] <jordi> I'll approve that one now.
[10:20] <jordi> Probably not.
[10:20] <carlos> ok
[10:20] <jordi> Well, what does isocodes say?
[10:20] <carlos> feel free to suggest any change
[10:20] <carlos> jordi: we got those names from isocodes
[10:20] <jordi> wtf, 176 entries
[10:21] <jordi> I will kill someone.
[10:21] <carlos> could be that they rename it later....
[10:21] <carlos> jordi: OO.org is being imported
[10:21] <carlos> so no new entries are being approved automatically
[10:21] <carlos> until that's done
[10:21] <jordi> oh I see
[10:22] <jordi> what else
[10:22] <jordi> there are two GTK+2.0 entries
[10:22] <jordi> build-tree/gtk+-2.8.17/po/az_IR.po in gtk+2.0 in Ubuntu Dapper
[10:22] <jordi> what about these?
[10:23] <jordi> is that just az?
[10:23] <carlos> jordi: yes
[10:23] <jordi> weird, why isn't it in the db already?
[10:23] <jordi> done
[10:24] <jordi> and then there's Vim64
[10:24] <jordi> which is really weird
[10:24] <jordi> and this help/de/de.po in gnome-app-install in Ubuntu Dapper
[10:24] <jordi> is that one BLOCK?
[10:24] <carlos> jordi: the remaining files for vim should be accepted manually
[10:25] <jordi> but they make little sense
[10:25] <jordi> vim64/src/po/zh_CN.cp936.po in vim in Ubuntu Dapper
[10:25] <jordi> vim64/src/po/zh_CN.UTF-8.po in vim in Ubuntu Dapper
[10:25] <carlos> jordi: if there is a help translation domain, it should be imported
[10:25] <jordi> for example.
[10:25] <carlos> jordi: import the UTF-8 and ignore the other
[10:25] <jordi> what about the others?
[10:26] <jordi> vim64/src/po/sk.cp1250.po in vim in Ubuntu Dapper
[10:26] <jordi> I mean, how do I know there's no sk.UTF-8 already imported?
[10:27] <carlos> jordi: sk.UTF-8 is not being imported automatically
[10:27] <carlos> just check its language status
[10:27] <carlos> jordi: just a minute I'm on the phone
[10:30] <carlos> jordi: ok, I'm back
[10:30] <jordi> carlos: ok, I did that
[10:30] <jordi> I did go to the source package page and see if there was a sk translation already
[10:30] <carlos> jordi: check tha language list and if there is already an import done for that language, block the .UTF-8 or .whatever one
[10:31] <jordi> but, how can I know it's not a sk.UTF-8 fuile that has been imported manually before?
[10:31] <jordi> I don't know if you understand what I'm trying to say
[10:31] <jordi> if I had a way to see the "path" of the imported template, that'd be good
[10:32] <carlos> jordi: well, I can tell you that I didn't do it
[10:32] <jordi> for example, in the queue we have two zh_CN
[10:32] <carlos> jordi: anyway, as a general rule
[10:32] <jordi> but there's already a zh_CN file in https://launchpad.net/distros/ubuntu/dapper/+source/vim/+translations
[10:33] <jordi> that puzzled me last night and made me stop just in case.
[10:33] <carlos> if the encoding is the only difference (I think it's broken that they store two encodings for the same language)
[10:33] <carlos> jordi: upload both if you want
[10:33] <jordi> really?
[10:33] <carlos> jordi: I'm going to add a +admin page for .po files like the one we have for .pot files
[10:33] <jordi> cool
[10:33] <carlos> so you can see the header 
[10:34] <carlos> and other useful information to take that kind of decissions
[10:34] <jordi> so yes, after unpacking vim, I see there's: zh_CN.cp936.po zh_CN.po zh_CN.UTF-8.po
[10:34] <jordi> so in this case we probably can block them
[10:35] <jordi> this is maddness anyway
[10:35] <carlos> jordi: yeah, since I started with Rosetta.. I have seen a bunch of broken i18n/l10n setups ...
[10:36] <jordi> the contents seem to be exact, except for encoding
[10:36] <carlos> jordi: that's more broken then...
[10:36] <jordi> yeh
[10:36] <jordi> the three files are just muissing 3 strings
[10:36] <jordi> and hve the same Po-Revision-Date, etc
[10:37] <jordi> I think these are great examples of blocked pos :)
[10:37] <carlos> ;-)
[10:38] <mpt> Vim, for all your blocked po needs.
[10:39] <jordi> "blocked pos" as in "blocked po files", not to confuse with a great acronym
[10:39] <carlos> SteveA: I need to update https://wiki.launchpad.canonical.com/CarlosPerelloMarin, should I wait for the new wiki or could I edit it there?
[10:40] <jordi> carlos: if I didn't misscount, there are 15 entries in the queue. :)
[10:41] <carlos> jordi: counting the OO.org ones?
[10:41] <carlos> sh-YU
[10:41] <jordi> yes
[10:41] <carlos> that's soooo cool ;-)
[10:42] <jordi> finally, yes :)
[10:44] <carlos> jordi: good work!
[10:51] <ddaa> SteveA: jamesh: meeting in 10 mins
[10:52] <SteveA> i'd better stretch and get some tea, then
[10:54] <ploum> hello : arf ! I will have to work this summer..
[10:54] <ploum> I will make the glaunchpad frontend SoC
[11:06] <jordi> carlos: to import this a pot file, how can I do it? https://launchpad.net/rosetta/imports/69039
[11:07] <carlos> jordi: select the templatename and rename it using the path field to end with .pot
[11:07] <carlos> ploum: ;-)
[11:08] <jordi> carlos: no language?
[11:09] <carlos> jordi: right, no language
[11:10] <jordi> aha, cool.
[11:11] <jordi> I want to see the empty queue
[11:11] <jordi> what do these mean?
[11:11] <jordi> po/hr.po in gdm in Ubuntu Dapper
[11:12] <jordi> Uploaded by Rosetta Administrators  on 2006-03-24 16:03:04 CET
[11:12] <jordi> Will be imported into Croatian (hr) translation of gdm in Ubuntu Dapper package "gdm"
[11:12] <jordi> but it's Needs Review
[11:16] <mpt> select {border: none;}
[11:16] <mpt> wtfcopter
[11:22] <carlos> jordi: is part of the automatic approval, first we associate it, next run will approve it
[11:23] <carlos> jordi: but the import queue is a bit busy atm with oo.org
[11:24] <jordi> nod
[11:56] <Yannig> Hello everybody :)
[12:01] <Yannig> May I ask another dumb question? :D
[12:01] <malcc> Yannig: Go crazy, ask two :)
[12:02] <Yannig> Do you know how the translation memory works? Some repeated strings (translators credits, yes, no, general, etc.) are sometimes proposed as "Used elsewhere" and sometimes not
[12:04] <Yannig> One should be enough for now :D
[12:09] <ddaa> Yannig: actually, I count two questions?
[12:09] <ddaa> One dumb, and one probably quite interesting but way too advanced for me to answer :)
[12:09] <Yannig> ddaa> :)
[12:22] <SteveA> carlos: i see a rosetta bug on the launchpad front page
[12:22] <SteveA> ----
[12:23] <SteveA> Translating applications:
[12:23] <SteveA> Rosetta is a Web-based translation system. You can easily collaborate with translators for your software through Rosetta.
[12:23] <SteveA> Dapper Translations:
[12:23] <SteveA> ----
[12:23] <SteveA> there's a box like that
[12:23] <SteveA> and that's all it says
[12:23] <SteveA> it is odd that it says "Dapper Translations:" and nothing more
[12:23] <carlos> you should get a statistics graph
[12:24] <SteveA> i've had problems with no graphs turning up in other parts of rosetta before
[12:24] <carlos> I will debug it to see if there is any case when we show nothing
[12:24] <carlos> ok
[12:24] <carlos> I would need the language header that your browser is sending to the server
[12:24] <carlos> a pagetest would give you the exact string
[12:29] <SteveA> HTTP_ACCEPT_LANGUAGE	'en-us,en;q=0.5'
[12:40] <carlos> SteveA: and your IP address ? (to check geoip information)
[12:40] <carlos> hmm, I guess is the one you are using to connect to IRC...
[12:41] <SteveA> yes
[12:41] <SteveA> idea:
[12:41] <SteveA>   for debugging, set a cooke that launchpad looks at for "fake" geoip and browser language info
[12:41] <SteveA> that would allow you to trivially pretend to be from elsewhere, and have a different browser language config
[12:43] <carlos> SteveA: where could I get info about such cookie creation? I haven't done anything with cookies before
[12:44] <SteveA> there's an API on a response
[12:44] <SteveA> response.setCookie or addCookie
[12:44] <SteveA> i think you need to do encoding yourself
[12:44] <carlos> SteveA: ok, thanks
[12:44] <carlos> that's enough to start
[12:45] <SteveA> so, i imaging a page at /rosetta/+fakeit
[12:45] <SteveA> that has a form to either:
[12:45] <SteveA>  - clear the cookie
[12:45] <SteveA>  - show current details of cookie
[12:45] <SteveA>  - allow editing the details
[12:46] <SteveA> the page can be public
[12:46] <SteveA> we'd make the cookie actually work only on staging / development setups
[12:46] <SteveA> not in production
[12:47] <carlos> ok, sounds good
[12:48] <carlos> SteveA: thanks
[12:57] <mpt_> eh
[12:57] <mpt_> I asked the test suite to just run the shipit tests, but it's running all of them
[12:57] <mpt_> no wonder it was taking so long
[12:58] <mpt_> What's the magic incantation for running a single story?
[12:58] <mpt_> I thought it was ./test.py -f canonical name-of-story
[01:00] <Yannig> carlos> Would you have any idea about my question above? :)
[01:00] <carlos> Yannig: sorry, I didn't see it
[01:00] <Yannig> Do you know how the translation memory works? Some repeated strings (translators credits, yes, no, general, etc.) are sometimes proposed as "Used elsewhere" and sometimes not
[01:00] <carlos> Yannig: it works taking the msgid
[01:01] <carlos> and looking for any translation for that msgid in other places
[01:01] <carlos> Yannig: if you are sure we should show a suggestion but we aren't doing it, file a bug
[01:02] <Yannig> Sorry but I have no idea what a msgid is :(
[01:02] <carlos> sorry, I went too deep in our technical terms
[01:02] <Yannig> Fair enough, I'll collect information to report a "supposed bug", thanks :)
[01:02] <carlos> Yannig: the english sntring
[01:02] <carlos> s/sntring/string/
[01:02] <carlos> Yannig: thanks
[01:03] <Yannig> And how can I look for any translation for an string?
[01:03] <carlos> Yannig: take into account that 'Yes ' and 'Yes' are different, the first has an extra white space
[01:03] <Yannig> Yes, I understand this :)
[01:03] <carlos> Yannig: we don't have such feature
[01:03] <aa_> hi guys, small usability thing. One of my developers actually read the "Launchpad could not mirror this branch at 2006-05-24 10:53:19 UTC.  The error was: [Errno 21]  Is a directory " to mean "The repo is broken".
[01:04] <BjornT_> mpt_: that should work. what command line did you use to try to run only the shipit tests?
[01:05] <mpt_> BjornT_: ./test.py -f -vv canonical shipit 2>&1 | less
[01:05] <mpt_> and it started spitting out names of non-shipit-related doctests
[01:07] <BjornT_> mpt_: what's the name of the directory you're in?
[01:09] <mpt_> BjornT_, the root directory of the branch
[01:09] <BjornT_> mpt_: i've noticed similar behaviour before, and it seems like the test runner is matching using the absolute path of the tests. so if you're in a directory which has 'shipit' in its name, all tests will be run.
[01:09] <mpt_> oh.
[01:09] <mpt_> e.g., ~mpt/hacking/lp/2006-05-shipit :-)
[01:11] <BjornT_> mpt_: yeah :) i can't find an existing bug about this, could you file one?
[01:12] <mpt_> ok
[01:27] <mpt_> bug 46324
[01:27] <Ubugtu> Malone bug 46324 in launchpad "test.py runs all tests if working directory contains name of desired story" [Normal,Unconfirmed]  http://launchpad.net/bugs/46324
[01:30] <SteveA> mpt_: hello
[01:31] <SteveA> there's a problem with malone simplifications on staging
[01:31] <SteveA> if i file a bug and do not enter a summary, the error i get is just "an error occurred"
[01:31] <SteveA> https://staging.launchpad.net/products/launchpad/+filebug
[01:31] <SteveA> also, i'm having mixed feelings about asking for the summary second
[01:31] <SteveA> yet displaying it first
[01:32] <ddaa> SteveA++
[01:32] <ddaa> it's a bit like writing an email
[01:32] <SteveA> it feels wrong that the order is changed on the bug reporting page
[01:32] <SteveA> so, i think you should change it back to having the summary above the description
[01:32] <SteveA> because although it would be better if *everyone* changed their data input forms that way
[01:32] <SteveA> we are harmed by doing things differently than everyone else
[01:34] <SteveA> there may be another way around this
[01:34] <SteveA> but the problem of the change in order of fields needs to be addressed somehow
[01:37] <mpt_> SteveA, +filebug is a custom form and I didn't change the error-handling
[01:37] <SteveA> it is more noticeable now that the summary is underneath
[01:37] <SteveA> with the summary field on top, it is the first thing people enter text into
[01:37] <mpt_> ok, I'll fix the error-handling
[01:37] <SteveA> with it underneath, it is easy to ignore it
[01:38] <SteveA> particularly as it is smaller
[01:38] <SteveA> fwiw, i just didn't *see* the instructions about
[01:38] <SteveA> 1. write a description
[01:38] <SteveA> 2. now summarize it
[01:38] <SteveA> i think it's a fine experiement.  i do not think it actually works.
[01:38] <mpt_> I disagree that doing things the same as everyone else is a design goal for Malone
[01:39] <SteveA> you're disagreeing with something that i have not said
[01:39] <mpt_> "we are harmed by doing things differently than everyone else"
[01:39] <SteveA> there is a principle of usability that you suffer if you do things differently than people expect
[01:39] <SteveA> usability is a design goal for malone
[01:39] <SteveA> check out jakob neilsen on where a site's menu / actions should appear
[01:40] <SteveA> although his results of user agility showed it should be on the right
[01:40] <SteveA> he recommends you put it on the left, because that is where users expect to see it
[01:40] <SteveA> i think the same holds true of "subject then body" or "summary then description"
[01:40] <carlos> stub: https://launchpad.net/products/rosetta/+bug/46325 <- The bug for the RSS feed feature
[01:40] <Ubugtu> Malone bug 46325 in rosetta "Implement a RSS feed feature to see the updated .pot files" [Normal,Confirmed]  
[01:40] <SteveA> we are reinforcing this through displaying the summary above the description on bug view pages
[01:40] <SteveA> and people view bugs many many times more often than they file them
[01:41] <SteveA> therefore, the bug filing page should conform to the expectations set by the rest of malone, and also by the world at large
[01:41] <SteveA> otherwise people will make the same mistake as i did, and omit the summary
[01:41] <mpt_> SteveA, and then someone actually did empirical research on menus on the left vs. the right, to check Jakob's assertion, and found it made no difference
[01:41] <SteveA> and not see the workflow suggested
[01:41] <mpt_> http://jodi.tamu.edu/Articles/v04/i01/Kalbach/
[01:42] <mpt_> So, I'd rather try it for a few weeks
[01:42] <mpt_> and see what happens
[01:43] <mpt_> Maybe we can somehow log people turning up on the form error page?
[01:43] <mpt_> to see how common it is
[01:44] <SteveA> mpt_: imagine if we had some pages in launchpad with navigation on the left, and some with navigation on the right
[01:44] <SteveA> and then decided to leave it like that for a few weeks to see whether people got confused with the exceptional pages that have navigation on the right
[01:44] <SteveA> it doesn't sound a compelling plan to me
[01:44] <mpt_> But there would be no reason to do that
[01:44] <mpt_> Whereas I gave two reasons for this change
[01:45] <SteveA> the change has the assumption that people read the text on the bug reporting page
[01:45] <SteveA> rather than just type in the boxes
[01:45] <mpt_> And a much closer analogy is that we *already do* have dozens of pages in Launchpad where the form for entering the data is laid out differently from the resulting layout.
[01:45] <mpt_> from the resulting data presentation, I mean.
[01:45] <SteveA> if the boxes had grey text in saying "detailed description goes here" and "write a summary here" that disappeared on focusing, that would improve matters
[01:46] <mpt_> There are some problems that make the field labels less noticable than they could be, but those problems apply to every page in Launchpad, not just this one
[01:47] <mpt_> For example, less than half the page real estate being spent on the form, making it scroll more horizontally
[01:47] <SteveA> my overall point is that i think the current filebug page on staging is a step backwards in usability
[01:48] <SteveA> i understand the reason for asking for a summary after a description
[01:48] <SteveA> and i think the great majority of launchpad users will be too accustomed to having a summary before a description to find this comfortable
[01:49] <SteveA> let's ask kiko and brad for opinions when they arrive
[01:49] <SteveA> oh, bradb is here now
[01:49] <mpt_> Is there a way we can log the frequency of people arriving at pages in particular conditions?
[02:01] <SteveA> mpt_: depends what the conditions are
[02:01] <SteveA> if they're reflected in the URL then yes
[02:01] <mpt_> No, this would be a tal:condition
[02:02] <SteveA> you would need to add logging code to what the tal:condition was checking
[02:02] <carlos> SteveA: I'm getting this error every time I try to run tests: https://chinstrap.ubuntu.com/~dsilvers/paste/fileB2oc6n.html
[02:02] <carlos> SteveA: I got latest code from rocketfuel already
[02:02] <SteveA> do you have the latest zope tree?
[02:02] <SteveA> i mailed the launchpad list about this
[02:03] <carlos> SteveA: I execute rocketfuel-refresh and it should get latest version of everything under sourcecode
[02:03] <SteveA> i don't know
[02:05] <carlos> Hmm, seems like I don't have latest version or you did the commit on 11th May
[02:05] <carlos> revno: 32
[02:05] <carlos> committer: Canonical.com Patch Queue Manager<pqm@pqm.ubuntu.com>
[02:05] <carlos> branch nick: 3.2
[02:05] <carlos> timestamp: Thu 2006-05-11 12:25:40 +0100
[02:05] <carlos> message:
[02:05] <carlos>   Add missing __init__.py's identified by spiv
[02:05] <carlos> right, I'm missing latest version
[02:08] <SteveA> or, just do a rocketfuel-get
[02:08] <SteveA> and then branch from your launchpad working tree into launchpad in your new tree
[02:08] <SteveA> then you'll certainly have everything up to date
[02:08] <SteveA> carlos: that cookie-debug thing i mentioned.  are you considering that for one of your 2-hour quick fix slots?
[02:09] <carlos> the problem is with the sourcecode directory, seems like I'm using the wrong parent
[02:09] <carlos> for zope
[02:09] <carlos> SteveA: yes, but not for today, I have already a task for today
[02:09] <SteveA> sure
[02:10] <carlos> at least it sounds like a task for my 1-2 hours slot
[02:16] <SteveA> ddaa: ping
[02:16] <salgado> stub, around?
[02:16] <stub> salgado: yes
[02:16] <ddaa> SteveA: at lunch
[02:16] <ddaa> back in 20 mins
[02:16] <SteveA> ddaa: did you register for EP already?
[02:17] <salgado> stub, is the export still running?
[02:17] <stub> salgado: yes
[02:18] <stub> salgado: High priority was done, but I suspect that did nothing since we won't have any high priority orders at this stage (?)
[02:21] <salgado> yes, we shouldn't
[02:22] <salgado> stub, do you know if it's actually doing something or just hung?
[02:22] <stub> Its doing something
[02:24] <stub> Maybe ;)
[02:25] <carlos> later
[02:29] <stub> salgado: It is still doing the big select :-/
[02:30] <salgado> ouch. I guess we'll need to fix it ASAP, then
[02:31] <ddaa> SteveA: I have not taken any personal action so far.
[02:32] <SteveA> ddaa: you need to register as a speaker right away
[02:32] <SteveA> ddaa: it means i have arranged the room under false pretences!"
[02:32] <SteveA> ddaa: also, you need to register right away to get the early bird rate
[02:33] <SteveA> http://indico.cern.ch/confRegistrationFormDisplay.py/display?confId=44
[02:33] <SteveA> do it now
[02:33] <salgado> stub, if you have the big select, can you paste it in privmsg for me? (I only have outgoing IRC right now)
[02:34] <SteveA> ddaa: for accommodation, select "hotel in the area"
[02:34] <ddaa> ok, doing
[02:34] <SteveA> lifeless and i are registered for both the conference dinner and the cern tour
[02:39] <ddaa> SteveA: done
[02:39] <ddaa> thank you for reminding me
[02:39] <SteveA> thanks
[02:40] <ddaa> nice setting up the bulk payment and accomodation
[02:49] <bradb> SteveA, mpt_: I agree that summary is better-placed before description. I'm used to subject, then body.
[02:52] <mpt_> oh dear
[02:52] <mpt_> I was going to copy the custom error-handling code from +editstatus
[02:53] <mpt_> but the custom error-handling code from +editstatus doesn't work even on +editstatus
[02:53] <mpt_> "There are 1 problems with the information you entered. Please fix them and try again." ...
[02:53] <mpt_> ... "('product', u'Product', )"
[02:54] <SteveA> mpt_: BjornT_ knows about how these things work
[02:54] <bradb> Malone's custom error handling, like LP's, is terrible.
[02:56] <BjornT_> mpt_: i think i've fixed that already on +editstatus. on the file bug i'd think it would be better to use the widget macros to render the widgets, i'll take a look at the template.
[02:57] <mpt_> BjornT_, how recently did you fix it?
[02:59] <mpt_> It's broken for me on localhost
[02:59] <BjornT_> mpt_: the patch is in the review queue, so it's not in rf yet. the fix is far from perfect, though, i have to to fix it properly later (there's currently no connection between the error message and the widget).
[03:00] <BjornT_> that's why it'd be better to use the widget macros, to make the error appear next to the widget.
[03:00] <mpt_> true
[03:10] <salgado> SteveA, up for a quick review?
[03:11] <SteveA> maybe.  let me see how big the diff is
[03:12] <BjornT_> mpt_: btw, in case you didn't know, in order to use the launchpad_widget_row macro standalone, you have to use tal:define="widget nocall:view/title_widget" before calling the macro.
[03:12] <mpt_> BjornT_, thanks, I'll look at it again when I wake up
[03:13] <salgado> SteveA, really small. it's to fix the exports
[03:13] <SteveA> show me the diff
[03:13] <salgado> SteveA, I sent it by email. (right now I have no outgoing HTTP)
[03:14] <salgado> brb
[03:15] <SteveA> salgado: looks okay to me, although i haven't scrutinized the SQL
[03:15] <salgado> SteveA, stub did that. :)
[03:16] <SteveA> ok
[03:16] <SteveA> r=me
[03:28] <klichota> Hello
[03:29] <klichota> I am looking for someone taking care of OpenOffice translations in Rosetta
[03:37] <carlos> klichota: hi
[03:38] <carlos> klichota: what do you need?
[03:38] <klichota> I have noticed there is no Polish help for OpenOffice
[03:38] <klichota> Although the translation is surely done (sponsored by Polish government) :)
[03:39] <carlos> let me check
[03:39] <klichota> Where are the help packages imported from?
[03:39] <carlos> from OO.org source packages
[03:39] <klichota> And where can I find these packages?
[03:39] <carlos> klichota: are you talking about guides too, or just the help?
[03:39] <klichota> Just help
[03:40] <klichota> I think
[03:42] <carlos> klichota: I see translations for the help
[03:42] <carlos> it's not fully translated
[03:42] <carlos> some are near full translation and others lack a lot of translations
[03:42] <klichota> Yes, the ones in Rosetta are not done
[03:42] <carlos> klichota: that means we are importing what we got from the source packages
[03:43] <klichota> So where these source packages come from?
[03:43] <carlos> from upstream
[03:43] <carlos> I think it's 2.0.2
[03:43] <klichota> Yes, I know :)
[03:43] <carlos> klichota: could be that the full translation was done with 2.0.3 ?
[03:43] <klichota> No, it was done for 2.0.0
[03:44] <carlos> klichota: then you will need to talk with doko
[03:44] <klichota> Where should I look for these "upstream" translations?
[03:44] <klichota> Who is "doko"?
[03:44] <carlos> he's the one that extracts the translations from the source code and feeds Rosetta with translations
[03:44] <carlos> if there is a problem with that procedure, he's the one that can fix it
[03:44] <klichota> OK, does he appear on this IRC channel?
[03:45] <carlos> klichota: Matthias Klose <doko@ubuntu.com>
[03:45] <klichota> OK, thanks, I will send him an e-mail
[03:45] <klichota> Bye
[03:45] <carlos> klichota: sometimes he comes here, but you would  get him at #ubuntu-devel
[03:45] <klichota> OK, I will try there
[03:45] <carlos> klichota: please, add me to the CC
[03:45] <klichota> Thanks again
[03:45] <carlos> klichota: carlos.perello@canonical.com
[03:50] <kiko> morning!
[03:54] <mpt_> I shouldn't still be awake, but: What should I do when PQM gives me a "Could not acquire lock LockDir" error?
[03:56] <CarlFK> how do I attach a file to a bug?
[03:56] <CarlFK> "add a..."
[03:56] <mpt_> CarlFK, yes
[03:57] <CarlFK> missed it the first 2 times
[03:57] <mpt_> you're not alone :-)
[03:58] <CarlFK> did it move in the last month or 2?
[04:02] <stub> What package is py.test in again?
[04:03] <mpt_> CarlFK, no, it's just hard to find
[04:04] <CarlFK> huh - thought it was in the center section near "add comment"
[04:05] <mpt_> CarlFK, it's never been there yet, but it will be eventually :-)
[04:09] <CarlFK> which would explain my difficultly working in the present 
[04:19] <carlos> will be back later tonight
[04:20] <salgado> stub, python-codespeak-lib
[04:20] <stub> ta
[04:59] <ddaa> how do I edit PendingReviews now?
[04:59] <ddaa> it's read-only on both l.c.c and w.l.c.c
[05:00] <kiko> ddaa, did you log in?
[05:00] <ddaa> Yes, it claims "Immutable Page"
[05:00] <ddaa> when not logged in it, says "log in to edit page"
[05:02] <mpt_> Where's dilys?
[05:03] <mpt_> ddaa, I can edit it
[05:04] <mpt_> (Not that that's helpful, except in narrowing down the problem)
[05:05] <kiko> wonder if we have what are they called? acls turned on.
[05:05] <ddaa> mpt_: well, you can help, in my "david/cscvs/test-cleanups" branch, in the "includes" section, add "david/cscvs/cvs-repo-lazy-protocol"
[05:06] <ddaa> got to keep track in which order I must merge all those branches
[05:07] <jordi> there's no way we'll see an empty queue at this pace
[05:07] <mpt_> ddaa, it already does include that
[05:07] <ddaa> mh
[05:08] <ddaa> I mean "david/cscvs/test-deletedadapter"
[05:09] <ddaa> when that particular pipe will be unclogged, I'll make pqm run cscvs merges for a full week 24/7 ;)
[05:10] <mpt_> "The authentication database is temporarily unavailable. Anonymous access only. You are not allowed to edit this page."
[05:10] <ddaa> duh
[05:10] <ddaa> this explains that
[05:10] <mpt_> indeed
[05:10] <mpt_> cue Nelson Muntz!
[05:12] <jordi> carlos: debian/po/sv.po in lilo-installer in Ubuntu Dapper << I blocked this
[05:13] <kiko> jordi, because swedish sucks?
[05:13] <kiko> they will complain
[05:14] <jordi> no, because lilo-installer sucks
[05:14] <jordi> everyone uses grub these days
[05:14] <kiko> hey malcc 
[05:14] <kiko> hey cprov 
[05:14] <malcc> Hey kiko
[05:14] <jordi> no, seriously, because those should be blocked: those strings appear in a big "debian-installer" pot file
[05:37] <salgado> is there a librarian sampledata? 
[05:42] <kiko> I'm not sure
[05:45] <stub> salgado: There is after you add it in your test's setup
[05:46] <kiko> stub, bug 29227 is really inconveniencing the distro team. would it be possible for you to take a look at it in the short term?
[05:46] <Ubugtu> Malone bug 29227 in malone "Searching for "pmu" doesn't find "/dev/pmu"" [Critical,In progress]  http://launchpad.net/bugs/29227
[05:49] <kiko> heh
[05:49] <kiko> stu1, bug 29227 is really inconveniencing the distro team. would it be possible for you to take a look at it in the short term?
[05:49] <Ubugtu> Malone bug 29227 in malone "Searching for "pmu" doesn't find "/dev/pmu"" [Critical,In progress]  http://launchpad.net/bugs/29227
[05:50] <kiko> wth
[05:51] <kiko-fud> stu1, syn?
[05:51] <stu1> eh?
[05:51] <kiko-fud> that's an ack
[05:51] <kiko-fud> stu1, bug 29227 is really inconveniencing the distro team. would it be possible for you to take a look at it in the short term?
[05:51] <Ubugtu> Malone bug 29227 in malone "Searching for "pmu" doesn't find "/dev/pmu"" [Critical,In progress]  http://launchpad.net/bugs/29227
[05:52] <stu1> I can't get that done for next week. Hopefully the week after.
[05:52] <kiko-fud> stub, oh. is it complicated?
[05:52] <stub> Yes
[05:52] <kiko-fud> argh, okay.
[05:52] <kiko-fud> thanks
[05:52] <stub> I know what to do - I just need to doit.
[05:53] <stub> It also involves updating the full text indexing maintenance scripts as we can't afford a four hour downtime window to rebuild all the indexes, so I have to fix that so it works live.
[05:53] <kiko-fud> I thought you had optimized that already
[05:53] <kiko-fud> but okay, thanks for the input.
[05:57] <stub> kiko-fud: I optimized it so it doesn't rebuild the indexes unless necessary. However, fixing that bug will involve it being necessary to update all of the indexes.
[05:57] <stub> Which is doable live - just need to split fti.py into two
[05:57] <stub> and a bit of refactoring
[06:57] <kiko-fud> thanks for the reply salgado 
[06:57] <kiko-fud> bradb, should that be "Most recently changed"?
[07:31] <salgado> stub, do you have a dump of the production db handy so that I can apply it on mawson?
[07:43] <bradb> kiko-phone: I think "recently changed" is clear enough.
[08:16] <kmr>  could someone confirm I'm using launchpad correctly? I reported a serious bug 2 weeks along with a simple patch along with links to a test case, but launchpad still shows the bug as unconfirmed. I wonder if I should be doing something more: https://launchpad.net/distros/ubuntu/+source/imagemagick/+bug/44307
[08:16] <Ubugtu> Malone bug 44307 in imagemagick "Assertion failure processing ICC profiles with perlmagick" [Major,Unconfirmed]  
[08:24] <salgado> kmr, a bug is usually marked confirmed when one of the package/product developers review it and ack that it's a bug
[08:24] <bradb> kmr: There's nothing wrong with how you're using LP, AFAICS. I can't speak for the distro team's policy, but I know they're insanely busy preparing to release Dapper atm.
[08:24] <salgado> in your case it could be that nobody had time to review it yet
[08:30] <kiko> bradb, the problem is that it's not true. you are not displaying only recently changed bugs -- you are displaying them in order of last changed date. right?
[08:31] <bradb> yeah. I'm also not displaying only most recently changed bugs either though :)
[08:32] <bradb> The most confusing change to that UI, to me, was that "Sort by: " was removed.
[08:36] <kiko> hmmm
[08:36] <kiko> I'll have to review that!
[08:37] <ddaa> okay, guys, I'm out for a long week-end
[08:37] <ddaa> see you monday
[08:37] <ddaa> provided I do not meet my fate on the highway or something like that
[08:38] <kiko> laters david
[08:40] <kmr> bradb, salgado: thanks very much for your confirmation of the process and your thoughts  
[08:41] <bradb> kmr: anytime
[08:41] <salgado> kiko, http://canario:8086/distros/ubuntu/+mirror/archive-mirror
[08:42] <kiko> nice!
[08:42] <salgado> and http://canario:8086/distros/ubuntu/+mirror/releases-mirror
[08:42] <kiko> very nice!
[08:42] <kiko> salgado, what about the general listings?
[08:43] <salgado> the list of mirrors?
[08:43] <salgado> http://canario:8086/distros/ubuntu/+archivemirrors
[08:47] <kiko> what about ordering by up-to-dateness?
[08:47] <salgado> by default, you mean?
[08:50] <kiko> well, does that happen?
[08:50] <salgado> I think I see what you mean
[08:50] <salgado> ordering http://canario:8086/distros/ubuntu/+archivemirrors by up-to-dateness?
[08:50] <kiko> that list only hhas two mirrors
[08:50] <kiko> and it doesn't say if they are up to date or not
[08:50] <kiko> so..
[08:51] <salgado> well, first we need to define how to rank a mirror by up-to-dateness, as that's a status of the content and not the mirror itself
[08:51] <Wolf> hey I am wondering if there is an API for Launchpad calendar? is it possible to post/view events from a third party app?
[08:51] <kiko> Wolf, not currently, but it's something we should work on.
[08:52] <Wolf> kiko ok, because I am currently working on a gnome panel applet that syncs and integrates your evolution/system calendar with google calendar
[08:52] <kiko> Wolf, yeah, it'd be a cool enhancement
[08:52] <Wolf> kiko and thought it would be great if this applet also worked with launchpad
[08:53] <Wolf> kiko that way all of your events could be synced across all calendars - any way you want them to be
[09:03] <cprov> carlos: ping ping 
[09:27] <kiko> jordi, ping?
[09:41] <carlos> cprov: pong pong
[09:42] <malcc> carlos: He wanted to ask about a concurrency problem updating translations, but it seems to have gone now.
[09:42] <carlos> malcc: do you have more details?
[09:43] <salgado> SteveA, have two minutes for a trivial review?
[09:46] <cprov> carlos: this query was locked for a while:
[09:46] <cprov> UPDATE TranslationImportQueueEntry SET content = 2881693, date_status_changed = CURRENT_TIMESTAMP AT TIME ZONE 'UTC', is_published = 't' WHERE id = 98989
[09:47] <cprov> carlos: different IDs each time, was something from rosetta was running last hour ?
[09:47] <carlos> cprov: I guess it conflicted with the poimport process 
[09:48] <cprov> carlos: we should think about a common lock or something like this ... do you think it's possible ?
[09:48] <jordi> kiko: pong
[09:48] <carlos> cprov: a common lock?
[09:48] <carlos> cprov: why?
[09:48] <carlos> cprov: the poimport could be running all time
[09:49] <jordi> ok, so I have a few questions about priorities
[09:49] <jordi> And they are a bit hairy.
[09:49] <kiko> jordi, are you by any chance doing anything with the translation queue?
[09:49] <jordi> not right now
[09:49] <jordi> I was waiting for it to clear a bit so we get a clean picture again
[09:49] <cprov> carlos: someone needs to wait instead of exploding 
[09:49] <carlos> cprov: but it locks the table once per entry so I guess you need to wait for that entry (atm we are importing huge .po files and it takes 3-5minutes each entry)
[09:49] <carlos> cprov: oh, was it failing?
[09:50] <jordi> mate even
[09:50] <carlos> cprov: I thought it was just being slow
[09:50] <cprov> carlos: yes, exploding, literally, with psycopg error
[09:50] <carlos> cprov: the problem is that the poimport script needs that table all time it's running
[09:50] <jordi> carlos, kiko: #l-m?
[09:51] <carlos> and for instance, latest run has been running since yesterday night
[09:51] <cprov> carlos: I'd rather wait some minutes, instead of exploding ;)
[09:51] <kiko> jordi, is now a good time? we're kinda busy busy busy
[09:51] <carlos> cprov: if that's possible, is ok for me...
[09:51] <jordi> oh
[09:51] <jordi> it'll be quick but anyway, it can wait
[09:52] <carlos> jordi: which subject?
[09:52] <jordi> it's about translation prioritues, which I should be working on rsn
[09:52] <carlos> oh, about that
[09:52] <cprov> carlos: good, will find out what we can do, thanks for being available ...
[09:52] <carlos> cprov: usually, you should not have problems
[09:52] <carlos> cprov: the problem comes with monsters like OpenOffice or evolution
[09:53] <carlos> the others are fast enough to prevent you from breaking your script
[09:55] <cprov> carlos: the world is full of monsters right now :(
[09:56] <carlos> cprov: does your script retry the build? or it just fail completely and you need to do something by hand?
[09:57] <cprov> carlos: need to retry by hand
[10:00] <Yannig> Hello :)
[10:00] <Yannig> Me again for another dumb question :D
[10:01] <Yannig> Do you know why nobody answers me about the creation of a mailing list for the Occitan translation team?
[10:01] <pvdvyve> no
[10:01] <Yannig> I don't even know if my mail was received or if it was asked to the good people
[10:02] <carlos> Yannig: where did you send it?
[10:03] <pvdvyve> sorry me too busy bye
[10:03] <carlos> jordi: where do you want to have the meeting about priorities? here or by phone?
[10:04] <Yannig> I don't really remember, I followed https://wiki.launchpad.canonical.com/ instructions
[10:06] <SteveA> salgado: yes
[10:08] <salgado> SteveA, the last changes Jane requested: https://chinstrap.ubuntu.com/~dsilvers/paste/fileHBgiso.html
[10:08] <salgado> (mostly trivial changes)
 well, first we need to define how to rank a mirror by up-to-dateness, as that's a status of the content and not the mirror itself
[10:09] <kiko> salgado, so if any of its contents is not up-to-date, it's not up-to-date.
[10:09] <kiko> the mirror's up-to-dateness is the lowest value of up-to-dateness of all its contents
[10:09] <salgado> fair enough
[10:10] <kiko> wonderful
[10:10] <salgado> that should be easily doable
[10:10] <kiko> if this needs tweaking we can change it later.
[10:11] <carlos> Yannig: ping jdub on irc about your mailing list, perhaps he missed the request
[10:11] <Yannig> Thanks :)
[10:15] <kiko> salgado, do that in a separate landing, though, please
[10:15] <kiko> otherwise you sandbag my review
[10:15] <salgado> sure
[10:20] <carlos> jordi: ?
[10:21] <jordi> yeah
[10:27] <carlos> jordi: irc or phone?
[10:28] <jordi> irc can do
[10:28] <jordi> will it take long?
[10:28] <jordi> or phone if you prefer
[10:28] <carlos> I think it would be faster...
[10:29] <jordi> ok
[10:29] <jordi> 1   75  of 1487 results
[10:29] <jordi> jesus
[10:29] <jordi> what did they do to my clean queue
[10:29] <kiko> it's those crazy distro guys
[10:29] <jordi> let's strike
[10:29] <carlos> jordi: ;-)
[10:30] <carlos> jordi: phone?
[10:30] <jordi> sure
[10:30] <carlos> calling
[10:33] <salgado> kiko, I'm not sure displaying the overall status of a mirror is a good idea if we don't say what content is there
[10:33] <kiko> salgado, why do you say that? if the mirror is old, it's a good idea to make it clear that it's old, no?
[10:33] <salgado> I mean, together with the status
[10:34] <kiko> that's hard because the content is.. well.. "wide".
[10:34] <salgado> I can be saying that a mirror is up to date but it might contain only warty
[10:34] <kiko> does that actually happen though?
[10:34] <salgado> I hope not
[10:35] <kiko> I bet 90% of mirrors mirror everything
[10:35] <kiko> so you can order by len(content) and then freshness, what dya think?
[10:36] <salgado> yeah, I think it's possible. what if we start with the freshness? :)
[10:37] <kiko> len(content) should be a one-liner!
[10:37] <salgado> yes, there is a one-line solution
[10:37] <SteveA> salgado: reviewing now
[10:38] <salgado> kiko, but this could lead to time outs on a page that lists lots of mirrors
[10:38] <salgado> SteveA, thanks!
[10:38] <kiko> salgado, I doubt it -- if you precache contents you will be fine
[10:39] <kiko> to precache contents you need to do something smart though
[10:39] <salgado> the distributionmirror table has no link to the content
[10:40] <kiko> the content does though
[10:40] <salgado> yes
[10:40] <kiko> you can do a reverse precache 
[10:40] <kiko> it is a technique developed by the ancient mayans
[10:41] <SteveA> jeff healey rocks
[10:42] <kiko> he wasn't an an ancient mayan last I checked
[10:57] <bradb> SteveA, BjornT: Is there a better way for testing xmlrpc APIs in LP right now than using http()?
[10:58] <SteveA> i don't believe you can use http() to test them
[10:58] <bradb> The zope tests I'm reading are doing that.
[10:58] <SteveA> bjorn and i discussed a better way to test them, but it takes some work on the functional test setup
[10:58] <SteveA> we don't do xmlrpc exactly the same way zope does
[11:00] <SteveA> so what we do right now is to use a system doctest
[11:00] <SteveA> and test the API
[11:00] <SteveA> but not functionally test the whole xmlrpc publication thing
[11:00] <bradb> I'm confused about the difference. ISTM that it should still work ok from the outside, i.e., encoding method calls in xml and posting them to a URL.
[11:01] <bradb> Even if, underneath, we've made infrastructure changes.
[11:03] <SteveA> about what difference exactly?
[11:04] <SteveA> the issue is that Zope by default accepts xmlrpc POSTs and regular browser HTTP on the same port
[11:04] <bradb> SteveA: I'm confused about what changes we could have made from the way Z3 does things that would prevent an http() post to a URL with some XML not work.
[11:04] <SteveA> we don't
[11:04] <SteveA> we use a different server for each
[11:05] <bradb> SteveA: right, so that main issue is getting a test xmlrpc server running as part of the test suite?
[11:06] <SteveA> not really
[11:06] <SteveA> it is about dispatching to the correct server from an http() call
[11:06] <SteveA> the way i want to do that is by dispatching based on the host specified
[11:07] <SteveA> this will make the pagetests clear, and is required for when we start doing more stuff with hosts like malone.launchpad.net or bugs.launchpad.net
[11:08] <bradb> SteveA: for something that works right now, should posting to http://localhost:9000/... with some xml work?
[11:08] <bradb> (in a test)
[11:08] <SteveA> it is a bug if it works
[11:09] <SteveA> sorry
[11:10] <bradb> SteveA: what naming standard and file layout do you suggest for xmlrpc views?
[11:11] <SteveA> what do you see in launchpad/xmlrpc ?
[11:11] <bradb> right. I noticed there was a view called BranchSetAPI. I was expecting BranchSetXMLRPCView
[11:13] <bradb> or, in my case, FileBugXMLRPCView
[11:13] <SteveA> the thing is, it represents an external API
[11:13] <SteveA> we know it is a view
[11:13] <SteveA> we know it is xmlrpc
[11:13] <SteveA> because it is in launchpad/xmlrpc/
[11:14] <SteveA> you'll be asking for FileBugXMLRPCViewPythonClassInASCII next ;-)
[11:14] <bradb> bah!
[11:14] <SteveA> or hungarian style...
[11:15] <SteveA>   ACPVXFileBug
[11:15] <bradb> it seems like the same argument could be made for browser views
[11:15] <bradb> we know it is a view
[11:15] <bradb> we know it is browser
[11:15] <bradb> because it is in launchpad/browser/
[11:15] <SteveA> we don't call them WhateverBrowser
[11:16] <SteveA> we might consider not calling them WhateverView
[11:16] <SteveA> although, it is good to distinguish them from just Whatever
[11:18] <bradb> yeah. z3 doesn't seem to have many examples to look for guidance on the naming either, but I'll just go with canonical.launchpad.xmlrpc.FileBugAPI then
[11:19] <SteveA> thank you
[11:20] <bradb> np, thanks for the guidance
[12:51] <sabdfl> kikoman... go home!
[12:55] <kiko> never!
[12:56] <kiko> I have an interview report to write
[12:56] <kiko> I have THIRTY-FIVE emails from you in my inbox
[12:58] <kiko> sabdfl, btw, call tomorrow post-launchpad-meeting, check?
[12:59] <sabdfl> yes, i have 3pm UTC +1
[01:00] <kiko> oh, wonderful, that's even better.
[01:00] <kiko> I was expecting 2pm UTC+1
[01:00] <kiko> sabdfl, you have email from jordi, btw -- he'd appreciate your input there
[01:01] <SteveA> kiko: you need to read the mail from claire re-arranging the times
[01:01] <kiko> I just read it and had been confused.
[01:01] <kiko> re-read
[01:01] <kiko> I had read it before
[01:05] <SteveA> see you tomorrow.
[01:05] <kiko> l8z
[01:14] <marcin_> hi all
[01:14] <kiko> hello marcin_ 
[01:15] <marcin_> kiko: hi
[01:15] <marcin_> I woud like to talk about some change/improvement in bug management in LP
[01:16] <marcin_> could you tell me what do you think about an idea to separate hardware related bugs from other usability/feature request/bad code etc. bugs?
[01:17] <kiko> marcin_, basically classifying bugs, right?
[01:17] <kiko> marcin_, so there are some strategies you can use for this today
[01:17] <marcin_> we have a very long list of hardware related bugs that are unconfirmed for a long time simple because they are related to some hardware specific issues
[01:17] <kiko> first, you can add to the bug summary or description a simple keyword which you can then use to search 
[01:17] <kiko> for instance
[01:18] <kiko> [!ubuntu-hardware!] 
[01:18] <marcin_> and since bug-squad don't have an access to specific hardware they cannot solve or confirm these bugs
[01:18] <kiko> and then doing a serch for that.
[01:18] <kiko> right
[01:18] <kiko> the other thing you can do is define a hardware-bug-squad team
[01:18] <kiko> and subscribe that team to the relevant bugs
[01:18] <kiko> then use that team's subscribed bugs listing
[01:19] <kiko> the third way that could be done is through a feature which malone does not yet possess -- a form of classifying bugs using a string attribute.
[01:19] <marcin_> kiko: right...
[01:19] <marcin_> another question is - how many bugs are reported with mail?
[01:20] <marcin_> and how many with Malone - launchpad web application?
[01:20] <kiko> marcin_, that is an excellent question, and I don't know the answer to it! I am humbled!
[01:21] <kiko> marcin_, I'm putting a question out and I'll try getting you an answer soon.
[01:21] <marcin_> well because the problem is that if for example 90% bug reports goes from Malone than maybe simple solution is to add additional button to form
[01:21] <kiko> what sort of button>
[01:22] <marcin_> but if most of bug reports goes by mail than [ubuntu-hardware]  in summary could be usefull
[01:22] <marcin_> well button 'mark this bug as hardware related' or something like this
[01:22] <kiko> that proposal is controversial
[01:23] <kiko> because it is really specific to ubuntu and to hardware-related software
[01:23] <kiko> which is not as generic as malone would like to be
[01:23] <marcin_> well we currently got "This bug is a security issue" 
[01:24] <marcin_> why not add another?
[01:24] <kiko> all software can present security issues, though. 
[01:24] <kiko> hardware-related is a lot more specific.
[01:24] <kiko> and note also that we are trying to find a way of getting rid of that option too!
[01:24] <marcin_> hmm why?
[01:24] <kiko> because it is often misused.
[01:27] <marcin_> ok I understand - but is there any reason why Malone doesn't have any 'wizard' that could help to report bugs and then make these reports more friendly to bug-squad ppl?
[01:27] <marcin_> if you got some buttons in single form then they really can be missed very often
[01:28] <kiko> marcin_, what do you mean by a wizard?
[01:28] <marcin_> but you always can add some js code to split form to two or more steps
[01:29] <marcin_> 'wizdard' or 'druid' propably in Linux world - a kind of form that has more than 1 step
[01:29] <kiko> right, but what would the steps be?
[01:30] <marcin_> and then user can provide some information in each step - click 'next' and then provide some more info
[01:31] <marcin_> well for example: 1. select package, 2. is this hardware related bug?, 3. is this secutity issue?, 4. what version of ubuntu you use, 5. provide bug description
[01:31] <marcin_> etc.
[01:37] <kiko> that is really a custom workflow for ubuntu
[01:38] <kiko> which is interesting but difficult to do with our current generic UI
[01:40] <carlos> night!!
[01:49] <marcin_> kiko: is there any reason why you cannot improve this UI?
[01:49] <marcin_> kiko:  and make this more web2.0 than it currently is?
[01:50] <kiko> marcin_, we can improve the UI in many ways, including making it more dynamic "web2.0", but we need to take care to ensure that Malone remains generic and not Ubuntu-specific.
[01:50] <kiko> such a wizard as you are suggesting violates that second constraint. but there are other ways of addressing that!
[01:51] <marcin_> hmm I can agree with you but only partially
[01:51] <marcin_> because I think that if you got a lot of informations from user in well organized way
[01:51] <kiko> there's also an implementation difficulty, because what you say would require special code inside Launchpad to handle Ubuntu (and potentially other products/distros that wanted a custom workflow)
[01:51] <marcin_> you can always parse/transform this to simple txt message that could fit 'generic' malone
[01:52] <kiko> indeed that can be done in any front-end, including a web front-end that reposts information to launchpad.
[01:53] <marcin_> if you got 'Launchpad integration' package in Ubuntu
[01:53] <marcin_> and you add links to Rosetta in 'Help' menu 
[01:53] <marcin_> then I think that this URL should be ubuntu-specific
[01:55] <marcin_> and for example - I can see very often this in Malone or in support requests
[01:55] <marcin_> I see bug report - than answer from some admin/bug triager "please provide ubuntu version you use"
[01:55] <marcin_> this question is a waste of time
[01:56] <marcin_> because I agree that Malone should be generic - but also there is no reason why it cannot have information about ubuntu version inside?
[01:56] <kiko> well
[01:56] <kiko> there is a proposal to capture that version in a text field and attach that to the description
[01:57] <kiko> just hasn't been done
[01:57] <kiko> we're considering it
[01:58] <marcin_> hmm stupid question then - is Malone/LP open source?
[01:58] <kiko> nope :)
[01:58] <marcin_> (afair it is not)
[01:58] <kiko> however
[01:58] <kiko> I am listening to your concerns
[01:58] <marcin_> right :)
[01:59] <kiko> even if we can't do exactly the solution you are proposing, I am aware of the issues you are raising and we are trying to find good ways of solving them 
[01:59] <kiko> we're working on xml-rpc interfaces to various parts of launchpad
[01:59] <kiko> which would allow custom bug-filing apps to work easily
[01:59] <kiko> we're working on a guided bug form, which could include some of the information that you are citing
[02:00] <kiko> we are attempting to get work started on using AJAX more extensively in launchpad
[02:00] <marcin_> really nice...
[02:00] <marcin_> ajax is my hobby from few months ;)
[02:00] <kiko> and finally, we will eventually have some support for custom keywords, though the form in which that will be implemented is yet undefined
[02:00] <kiko> yeah, it is pretty cool ain't it
[02:00] <marcin_> do you work for Canonical?
[02:01] <kiko> indeed I do!
[02:02] <marcin_> I can see information on ubuntu.com that Canonical needs webmaster...
[02:03] <kiko> indeed we are looking
[02:03] <marcin_> I thought about it but unfortunately I'm just a beginner in Python development
[02:04] <kiko> are you interested in applying?
[02:04] <kiko> why don't you give it a shot anyway?
[02:04] <marcin_> well maybe I should try
[02:05] <marcin_> I'm not sure about requirements, about time and of course about money
[02:06] <marcin_> and another thing is that I got job so... not sure if I want to change...
[02:06] <kiko> right
[02:07] <kiko> that's something to consider always. :)
[02:07] <marcin_> but I'm also do a lot of things with Ubuntu
[02:07] <marcin_> s /I'm/I
[02:07] <marcin_> so it could be nice to work directly for Canonical
[02:08] <marcin_> do you know if this is a full time job?
[02:11] <marcin_> kiko: and if you would like than take a look at my specification I added to LP: https://launchpad.net/distros/ubuntu/+spec/webuntu
[02:11] <kiko> marcin_, I believe it is, but you'll need to submit a request to find out.
[02:12] <kiko> marcin_, ah interesting. so you are suggesting a set of web apps for managing ubuntu with a common look-n-feel?
[02:12] <marcin_> kiko: it's only draft but I will add better integration with LP as something to TODO list :)
[02:12] <kiko> heh
[02:12] <kiko> good point
[02:12] <marcin_> (tomorrow - it's 2:12 am here and I'm pretty tired)
[02:13] <marcin_> yes I think that linux is excellend 'server' system
[02:13] <marcin_> s/ excellend/excellent
[02:13] <marcin_> so it could be nice to use it's potential
[02:14] <kiko> yeah, managing it is really only for console ninjas today :)
[02:14] <marcin_> and with modern browsers we can do magic things with UI
[02:15] <marcin_> so ubuntu could work as something like 'Media Center' replacement etc.
[02:15] <marcin_> propably it could be easier and faster to develop web UI than wait for Gnome/KDE folks ;)
[02:17] <kiko> yeah
[02:17] <marcin_> maybe I will start to work on this project and then I will submit request to Canonical :-)
[02:17] <kiko> okay, time for me to roll zzzwards
[02:17] <kiko> good luck with your application
[02:17] <kiko> and feel free to ask if you need any help
[02:17] <marcin_> kiko: ok thanks
[02:19] <lifeless> jamesh: ping, your reviews are getting old
[02:46] <jamesh> lifeless: yeah.  I'll sort them out today
[03:14] <lifeless> spiv: new reviews por vous
[03:15] <spiv> lifeless: thanks
[03:15] <spiv> lifeless: any luck with the triple-branch merge?
[03:18] <lifeless> spiv: doing it after I finish ddaa's branch.
[03:19] <spiv> lifeless: Woo!
[03:29] <jamesh> lifeless: is the new wiki immutable for you?
[03:29] <lifeless> jamesh: fixed now
[03:29] <lifeless> jamesh: it was.
[03:29] <jamesh> so it is.
[04:30] <mpt__> Goooooooooooooooooooooooood afternoon Launchpadders!
[04:30] <ajmitch> hi
[05:49] <lifeless> spiv: these are merges of bzr and bzrtools right ?
[05:55] <lifeless> spiv: tests running
[06:20] <mpt> stub, staging won't let me log in
[06:21] <stub> works for me....
[06:23] <stub> mpt: Make sure you are using https://staging.launchpad.net/. Also, the cookie name changed recently for staging so if you have some sort of wierd cookie privacy thing setup you might have trouble.
[06:23] <lifeless> stub: are we using zope 3.2 in prod now ?
[06:23] <stub> Yes
[06:23] <lifeless> stub: the production tree on balleny still has 3.0 in sourcecode
[06:23] <lifeless> stub: should I fix that ?
[06:23] <stub> Hmm.... mpt is right.
[06:24] <mpt> I cleared my cookies half an hour ago and hadn't tried it since, so that can't be the problem
[06:24] <stub> lifeless: That is synced from rocketfuel built - how would that have happened?
[06:24] <stub> lifeless: And I don't see how the tests would pass either... are you sure?
[06:24] <lifeless> bzr info sourcecode/zope/
[06:24] <lifeless> ...
[06:25] <lifeless>       parent branch: sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/zope/3.0/test
[06:26] <lifeless> stub: how are you syncing it ? rsync ?
[06:26] <lifeless> spiv: two failures
[06:26] <stub> mpt: Looks like we are setting the correct cookie on login, but not checking the correct one for authentication purposes. Thankfully this only bites us on staging.
[06:26] <stub> lifeless: rsync
[06:27] <lifeless> and we are talking about ~/production/launchpad for pqm on balleny ?
[06:27] <lifeless> morning stub 
[06:27] <lifeless> bem
[06:27] <lifeless> meh
[06:27] <lifeless> morning SteveA 
[06:29] <stub> lifeless: Yes
[06:30] <lifeless> stub: ok, I'm checking 
[06:31] <lifeless> stub: your rsync is faulty
[06:32] <lifeless> stub: its clearly not the content of chinstrap:/home/warthogs/archives/rocketfuel-built/launchpad
[06:32] <stub> ------------------------------------------------------------
[06:32] <stub> revno: 32
[06:32] <stub> committer: Canonical.com Patch Queue Manager<pqm@pqm.ubuntu.com>
[06:32] <stub> branch nick: 3.2
[06:32] <stub> timestamp: Thu 2006-05-11 12:25:40 +0100
[06:32] <stub> message:
[06:32] <stub>   Add missing __init__.py's identified by spiv
[06:32] <stub> It is *a* 3.2 branch
[06:33] <lifeless> intruiging
[06:34] <stub> And test.py is definitely the 3.2 one
[06:34] <lifeless> anyhow, I'll finish these merges and look closer
[06:38] <stub> mpt: I've found the problem and will commit it
[06:41] <stub> mpt: If you log onto production, you should find you are also logged onto staging if you don't want to wait ;)
[06:41] <stub> Hmm... maybe.
[07:24] <lifeless> stub: 
[07:24] <lifeless> File "/home/pqm/production/bzr/lib/canonical/database/sqlbase.py", line 371, in canonical.database.sqlbase.quote
[07:24] <lifeless> Failed example: quote("'hello'")
[07:24] <lifeless> Expected: "'\\'hello\\''"
[07:24] <lifeless> Got: "'''hello'''"
[07:24] <lifeless> is that indicative of skew between sqlobject and launchpad ?
[07:26] <jamesh> lifeless: sounds like it is (see stub's message about the quoting change)
[07:26] <lifeless> jamesh: yes, thats why I'm asking ;)
[07:26] <lifeless> spiv: ping
[07:27] <jamesh> lifeless: btw, the pending-reviews page is working again (had to add some code to pass the appropriate http auth header when grabbing the wiki page)
[07:27] <spiv> lifeless: pong
[07:28] <stub> lifeless: That test should have been updated. Maybe I neglected to push?
[07:30] <lifeless> spiv: what commit message do you want ?
[07:30] <lifeless> jamesh: grazzi
[07:30] <spiv> lifeless: for the launchpad/bzr/bzrtools branches?
[07:31] <lifeless> spiv: yes
[07:32] <spiv> lifeless: Something along the lines of "Update importd tests for bzr 0.8" for lp and "Update to recent upstream bzr.dev/bzrtools" for bzr/bzrtools.
[07:32] <lifeless> spiv: reviewed by ? or trivial ?
[07:32] <spiv> Unreviewed, so I guess it's trivial ;)
[07:32] <lifeless> muhaha
[07:33] <spiv> rs=spiv might be more accurate ;)
[07:33] <lifeless> and self referential
[07:34] <spiv> They aren't huge changes, but I really really want them in so I can stop sourcecode/* tests failing (I will do the merge to re-enable that as soon as this lands), and to unblock a bunch of other things for me and ddaa.
[07:34] <lifeless> spiv: me too
[07:37] <lifeless> spiv: its in
[07:37] <spiv> lifeless: many thanks!
[07:40] <lifeless> stub: production (pqm@balleny:~/production/launchpad/sourcecode) subbranches are out of date with respect to the chinstrap rocketfuel-built. 
[07:40] <lifeless> stub: including zope
[07:40] <lifeless> stub: what command are you using when you sync them ?
[07:41] <stub> Erm.... you would have been the last person to rebuild it with the 1.63 rollout
[07:41] <lifeless> stub: I didn't rebuild it, I updated it. This would explain it as 1.62 was pre-knit
[07:41] <stub> Only cherry picks since then, and I don't update the subbranches for that unless necessary
[07:41] <stub> ok
[07:42] <stub> Man bzr push takes ages (when you have bittorrent running)
[07:42] <lifeless> bt uses all bandwidth, news at 11.
[07:45] <lifeless> stub: bpqm@balleny:~/production/sqlobjectupdate/sourcecode/sqlobject$ bzr merge sftp://chinstrap/home/warthogs/archives/stub/sqlobject/quotingfix
[07:45] <lifeless> Nothing to do.       
[07:45] <stub> Still pushing...
[07:49] <lifeless> stub: conflicts:
[07:50] <lifeless> bzr merge sftp://chinstrap/home/warthogs/archives/stub/launchpad/trivial
[07:50] <lifeless> bzr: WARNING: Text conflict in database/sampledata/current.sql                                                                                                                                                    
[07:50] <lifeless> bzr: WARNING: Text conflict in lib/canonical/launchpad/interfaces/potemplate.py                                                                                                                                   
[07:50] <lifeless> bzr: WARNING: Text conflict in lib/canonical/launchpad/scripts/bugnotification.py                                                                                                                                 
[07:50] <lifeless> bzr: WARNING: Text conflict in lib/canonical/launchpad/zcml/potemplate.zcml                                                                                                                                       
[07:50] <stub> I'm still pushing
[07:50] <lifeless> 4 conflicts encountered.                         
[07:50] <lifeless> stub: garh, ok
[07:51] <stub> I killed the sftp push and rspush is underway
[07:51] <lifeless> stub: well, say when you want me to do this
[07:53] <stub> lifeless: done
[07:59] <lifeless> stub: I still get
[07:59] <lifeless> pqm@balleny:~/production/sqlobjectupdate/sourcecode/sqlobject$ bzr merge sftp://chinstrap/home/warthogs/archives/stub/sqlobject/quotingfix
[07:59] <lifeless> Nothing to do.                                                                                                                                                                                                    
[07:59] <lifeless> stub: is it possible you merged that in already to some branch ?
[08:00] <stub> Nope, because the tests won't pass without the SQLObject fix being landed. The only change on that branch should be the docstrings in sqlbase.py :-/
[08:00] <lifeless> did you update production ?
[08:01] <stub> https://chinstrap.ubuntu.com/~dsilvers/paste/filecuFtP1.html
[08:02] <stub> lifeless: No - the production branch I just updated sourcecode/SQLObject
[08:02] <stub> I think
[08:02] <lifeless> stub: that will be it.
[08:03] <lifeless> ok, merge test running
[08:10] <stub> lifeless: If I did something like push changes to ~/archives/rocketfuel/launchpad/production/1.63 on balleny, could I trigger PQM errors like mpt reported?
[08:13] <lifeless> stub: no
[08:14] <lifeless> stub: there was an sftp glitch, something killed pqm ? or something like that.
[08:14] <lifeless> that left the branch on chinstrap locked.
[08:14] <lifeless> someone else came along and unlocked it
[08:14] <lifeless> stub: not though, please dont use rsync between the rocketfuel archives
[08:14] <stub> ok. I was wondering if I needed to disable pqm when doing that sort of operation now things seem to be using repositories
[08:15] <lifeless> as long as you use 'bzr push', not 'bzr rspush', no, it will all just work.
[08:15] <stub> lifeless: ok.
[08:16] <lifeless> stub: worst case it might fail to grab the lock, but if it does that, and you get an error, tell me - its a condition we should handle anyway
[08:20] <lifeless> jamesh: ping
[08:20] <lifeless> jamesh: what did you think of the europython abstract discussion?
[08:20] <lifeless> spiv: you too ^
[08:28] <spiv> lifeless: I don't have any new insights to offer.  Pretending to be an attendee, I'm not sure if you're focusing on making plugins in python or a specific way of testing, so I'm not really sure what to expect.  It sort of sounds like two different talks put together.
[08:29] <lifeless> spiv: I just got a test failure from importd tests
[08:29] <lifeless> test_pty_output (importd.tests.test_baz2bzr.TestBaz2bzrPublishFeature)
[08:29] <spiv> lifeless: crud.  What test?
[08:29] <lifeless> Output:
[08:29] <lifeless> 'importing importd@example.com/test--branch--0 into bzrworking\r'
[08:29] <lifeless> '0/2 revisions\r'
[08:29] <lifeless> '1/2 revisions\r'
[08:29] <lifeless> '2/2 revisions\r'
[08:29] <lifeless> 'Cleaning up\r'
[08:29] <lifeless> 'Import complete.\r'
[08:29] <lifeless> '0/1 read knit index\r'
[08:29] <lifeless> '1/1 read knit index\r'
[08:29] <lifeless> '0/1 read knit index\r'
[08:29] <lifeless> '1/1 read knit index\r'
[08:29] <lifeless> '0/1 read knit index\r'
[08:29] <lifeless> '1/1 read knit index\r'
[08:29] <lifeless> '0/1 read knit index\r'
[08:31] <lifeless> running it again
[08:31] <spiv> I've never seen that locally.  I wonder what's different...
[08:32] <lifeless> 'make check_merge 2>&1 | less'
[08:43] <jamesh> lifeless: the talk sounds interesting.  I agree with Steve about emphasising plugins over testing
[08:46] <spiv> lifeless: I cannot reproduce that locally :/
[08:57] <lifeless> spiv: mleep
[08:58] <lifeless> spiv: fails again
[08:58] <lifeless> spiv: the expect value for the test is :
[08:58] <lifeless> Expected:
[08:58] <lifeless> 'importing importd@example.com/test--branch--0 into bzrworking\r'
[08:58] <lifeless> '0/2 revisions\r'
[08:58] <lifeless> '1/2 revisions\r'
[08:58] <lifeless> '2/2 revisions\r'
[08:59] <lifeless> 'Cleaning up\r'
[08:59] <lifeless> 'Import complete.\r'
[08:59] <lifeless> ''
[08:59] <lifeless> failing tests are:
[08:59] <lifeless> test_pipe_output (importd.tests.test_baz2bzr.TestBaz2bzrPublishFeature
[08:59] <lifeless> test_pty_output (importd.tests.test_baz2bzr.TestBaz2bzrPublishFeature
[09:00] <lifeless> sqlobjectupdate$ bzr revno
[09:00] <lifeless> 3600
[09:00] <lifeless> pqm@balleny:~/production/sqlobjectupdate$ bzr revno sourcecode/bzr
[09:00] <lifeless> 1370
[09:00] <lifeless> pqm@balleny:~/production/sqlobjectupdate$ bzr revno sourcecode/bzrtools
[09:00] <lifeless> 216
[09:02] <lifeless> rf-built is up to date on chinstrap
[09:06] <spiv> lifeless: does just "make importdcheck" fail?  (I'm pretty sure it should be the same, but let's be certain)
[09:20] <lifeless> spiv: checking
[09:25] <lifeless> fails
[09:33] <spiv> Well that's something at least ;)
[09:37] <spiv> lifeless: all of a sudden I can reproduce, I'm not sure why.
[09:37] <lifeless> yay
[09:38] <lifeless> so rf is borked until this is fixed.
[09:38] <lifeless> should I rollback, or are you on it ?
[09:39] <spiv> lifeless: I'm on it.  The "fix" is just to extend the expected output; this actually lines up better with how it was before I updated it.  The way these tests work needs rethinking though, because this is a very fragile way to test whatever it's trying to test...
[09:39] <lifeless> regex matching ?
[09:39] <lifeless> (i agree)
[09:39] <spiv> Something like that, first we need to figure out precisely what we're trying to test for.
[09:40] <lifeless> david needs output
[09:40] <spiv> Tests without a clear purpose are something I'm increasingly uncomfortable with...
[09:40] <lifeless> otherwise the job is considered 'hung' and get skilled
[09:40] <lifeless> s/skill/kill/
[09:40] <spiv> I see.  I'll file a bug on the subject after I fix, push and merge.
[09:42] <cprov> good morning, hackers
[09:42] <lifeless> spiv: pqm is disabled
[09:42] <lifeless> spiv: fix, push, tell me :)
[09:43] <spiv> lifeless: thanks (and thanks for bearing with me!)
[09:44] <SteveA> lifeless: morning
[09:44] <lifeless> hi SteveA 
[09:46] <spiv> (and I still have no idea why the another, supposedly equivalent, tree I have for this behaves differently, but first things first...)
[09:48] <lifeless> echo $PYTHONPATH
[09:55] <spiv> lifeless: pushed: sftp://chinstrap.ubuntu.com/home/warthogs/archives/spiv/launchpad/importd-pty-test-fix/
[10:09] <lifeless> spiv: I think it might be a race condition on stderr
[10:11] <lifeless> spiv: so I expect this will toggle and fart around. We'll want a pattern based test soon IMO.
[10:13] <spiv> lifeless: Hmm, I don't think it's a stderr issue.  test_pipe_output uses stdout=PIPE, stderr=STDOUT but fails anyway.
[10:13] <lifeless> spiv: well, its done and pushed
[10:13] <spiv> (pity, because it's a good theory!)
[10:13] <lifeless> may the farce be with you
[10:14] <spiv> Heh.
[10:14] <spiv> lifeless: Let's find out... :)
[10:14] <lifeless> I got my batteries today
[10:14] <SteveA> spiv, jamesh, stub: i'd like to arrange a skype call tomorrow, either individually, or we can try a conference, to talk over some issues about the ORM for launchpad, project "L" and the other project "L".
[10:15] <lifeless> I now have ~12 hours real world run-time on batter
[10:15] <SteveA> deep fried electrons
[10:15] <spiv> lifeless: whee
[10:16] <spiv> SteveA: Sounds good.  I'd guess that roughly this time (i.e. 0800 UTC) is probably good for everyone.
[10:16] <SteveA> okay, that suits me well too.
[10:20] <stub> yer
[10:23] <stub> I might not be the brightest spark though - I seem to have flu or tonsillitis or other nasty.
[10:25] <jamesh> SteveA: okay
[10:45] <spiv> lifeless: is pqm running again?
[11:23] <lifeless> https://launchpad.net/ | developer meeting: Thu 25 May, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39
[11:59] <carlos> jordi: ping
[11:59] <jordi> pong
[11:59] <carlos> jordi: could you send the Rosetta announcement?
[11:59] <carlos> I think you should do it as our public face
[12:00] <jordi> I can, yes
[12:00] <jordi> should I take it from the wiki?
[12:00] <carlos> yes
[12:14] <sabdfl> BjornT: is https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc up to date?
[12:19] <SteveA> bjorn is out running some errands
[12:21] <SteveA> also, that page should be moved over to help.launchpad.net
[12:24] <carlos> SteveA: should we move now all Rosetta pages from wiki.ubuntu.com to help.launchpad.net ?
[12:24] <carlos> SteveA: if the answer is 'yes', do we have a standard way to name the pages there?
[12:26] <SteveA> there's two things we're doing with help.ubuntu.com
[12:26] <SteveA> one of them is that we're going to have a mapping from types of pages in launchpad to pages on the wiki
[12:26] <SteveA> so, for example, a person's edit gpg keys page will get a page on the wiki, where help on that page can be written down
[12:26] <SteveA> the other thing we're going to do with help.launchpad.net
[12:26] <carlos> right
[12:27] <SteveA> (argh... read help.ubuntu.com and help.launchpad.net earlier)
[12:27] <SteveA> is to have documentation explaining things users need to know about, like how to use the email UI 
[12:27] <SteveA> and how to use rosetta effectively
[12:27] <SteveA> now, to answer your question
[12:28] <SteveA> we need to keep in mind that right now, Rosetta is most focused on ubuntu
[12:28] <SteveA> on making ubuntu translated well
[12:28] <SteveA> so we must be careful to provide information and docs to people who want to help with ubuntu, if those docs will help in that case
[12:30] <carlos> well, the FAQ page is not ubuntu specific
[12:30] <carlos> and I think it's a general rule about how to handle translations in Ubuntu and other distros/products
[12:31] <carlos> so I guess the FAQ page could be moved
[12:32] <SteveA> okay
[12:32] <SteveA> but make sure that ubuntu people aren't lost for help
[12:32] <SteveA> so, leave pointers to the new pages when those pages are moved
[12:33] <mpt_> bah, Internet Explorer is stupid
[12:33] <BjornT> sabdfl: yeah, MaloneEmailInterfaceUserDoc should be up to date.
[12:34] <carlos> SteveA: yeah, the idea was to note the movement
[12:34] <carlos> SteveA: there are links on launchpad that should be updated too
[12:34] <SteveA> BjornT: is that page referred to from launchpad anywhere?
[12:35] <BjornT> SteveA: yeah, i think so. in some about box.
[12:35] <BjornT> SteveA: https://launchpad.net/malone, on the left.
[12:35] <SteveA> okay.  i'd like you to change the link to help.launchpad.net/UsingMaloneEmail and move that doc there
[12:36] <SteveA> unless your or mpt_ can think of a better page name
[12:37] <SteveA> also, i wonder if the email interface should have a version number 
[12:37] <SteveA> so we can note the version number in the docs
[12:37] <SteveA> and we'll know that things are kept up to date
[12:43] <BjornT> yeah, could be worth having a version number
[12:48] <sabdfl> thanks BjornT
[12:51] <mpt_> hmmm
[12:56] <SteveA> hmm ?
[12:57] <mpt_> SteveA, how might I do ++debug++source on the 404 page?
[12:57] <mpt_>  /fqhwgads/++debug++source doesn't work
[12:57] <SteveA> you put that first
[12:57] <SteveA>  /++debug++source/asdasd
[12:58] <mpt_> ah, beautiful, thanks
[12:58] <SteveA> Znarl: ping
[12:58] <Znarl> SteveA : Pong?
[12:58] <SteveA> hi.  bjorn and i are having trouble editing pages on help.launchpad.net
[12:58] <SteveA> any idea what might be up
[12:58] <SteveA> we're both logged in to it
[12:59] <Znarl> SteveA : Do you have an example page that doesn't work for you?
[12:59] <SteveA> https://help.launchpad.net/UsingMaloneEmail
[01:00] <Keybuk> hi guys,
[01:00] <Keybuk> do we have any stats on the number of people who've used "Translate this Application" or "Get Help Online" ?
[01:01] <Znarl> SteveA : Ok, fixed.
[01:01] <SteveA> thanks, what was wrong?
[01:01] <SteveA> Keybuk: the apache logs will tell.  no stats though.
[01:02] <Keybuk> SteveA: any chance of a quick guess?
[01:02] <mpt_> Get Help Online has never been implemented
[01:03] <SteveA> mpt_: what does "implemented" mean?
[01:04] <mpt_> SteveA, I mean even roughly following Mark's idea of having and editable list of support options for each distribution or product
[01:05] <mpt_> Kiko and I put in a dummy page just before the Breezy release, and iirc it hasn't been changed since
[01:05] <mpt_> the spec is LaunchpadIntegrationHelpPage
[01:06] <SteveA> Keybuk: i think all the apache access goes via gangotri, so the steps for any kind of guess are to get access to the apache logs, and then do a grep | wc -l on them
[01:06] <mpt_> though iirc the current spec is a *bit* more complex than it should be, in that it should just be a set of (link, title, description)
[01:06] <Keybuk> SteveA: do you not have anybody on your staff with access? :(
[01:07] <SteveA> sure, various people have access to gangotri, including me.  i haven't looked at apache logs on there though, i only know where the launchpad stuff is
[01:07] <SteveA> maybe Znarl can offer advice on where apache logs live
[01:14] <SteveA> Keybuk: okay, i have the logs
[01:20] <salgado> stub, around?
[01:20] <stub> salgado: yes
[01:21] <salgado> stub, do you have a dump of the production db handy, for me to apply it on mawson?
[01:21] <stub> There is one a few days old in ~stub on mawson
[01:22] <stub> lifeless: Did that SQLObject/launchpad landing work?
[01:24] <salgado> stub, I think it should be fine... can you remind me how to apply it?
[01:26] <stub> salgado: pg_restore --no-acl --no-owner --dbname=mynewlycreateddb thefile.dump
[01:28] <salgado> stub, cool. /me notes that somewhere so he won't forget anymore
[01:28] <salgado> cprov, around?
[01:32] <salgado> spiv, ping
[01:32] <spiv> salgado: pong
[01:32] <salgado> hi spiv
[01:33] <salgado> spiv, kiko reviewed my mirror-management2 branch, and he asked me to check with you if you could review one test
[01:33] <salgado> it's one of those twisted tests
[01:33] <spiv> Sure, got a link/pastebin?
[01:34] <salgado> spiv, it's the test_distributionmirror_prober.py on https://chinstrap.ubuntu.com/~jamesh/pending-reviews/salgado/launchpad/mirror-management2/full-diff
[01:34] <salgado> I added more tests on that file, to test the prober for release mirrors
[01:35] <Yannig> Other dumb questions :p
[01:35] <Yannig> Do I really need to be in https://launchpad.net/distros/ubuntu/dapper/+source/debian-installer/+pots/debian-installer/oc/+translate to upload the debian-installer po file or is it detected automatically?
[01:35] <Yannig> If not, would it be possible to rename the oc.po file into debian_installer_oc.po for example?
[01:36] <spiv> salgado: why bother with the "except Exception, e: self.fail(...)"?  Why not just let the test error?
[01:37] <Yannig> Poor carlos, I take all his time with my dumb questions :p
[01:37] <carlos> Yannig: where do you want to import it?
[01:38] <Yannig> I just fear to make a mistake importing the file into the wrong location
[01:38] <spiv> salgado: is there any Twisted IO involved?  It doesn't look like it, but I'd like to be sure that you don't intend that.
[01:38] <Yannig> I have so many oc.po files... :(
[01:40] <carlos> you need to upload them to the right pofile
[01:40] <spiv> salgado: So, you have a problem.
[01:40] <mpt_> woo
[01:40] <carlos> Yannig: no way to do a single tarball upload
[01:40] <salgado> spiv, about the exception, I think it's nicer to have a proper message and a failure than an error with no clear explanation
[01:40] <mpt_> SteveA, just finished the portlet trimming and the Internet Explorer layout fixes
[01:40] <spiv> salgado: if got_result in test_failure_propagation is wrongly triggered, the self.fail it calls won't have the desired effect.
[01:40] <Yannig> Fair enough, thanks
[01:40] <SteveA> mpt_: cool
[01:41] <spiv> salgado: I think it's nicer to get a full traceback from the source of the error, with an unmangled error message...
[01:41] <Yannig> And would it be possible to rename the oc.po file into debian_installer_oc.po for example?
[01:41] <salgado> spiv, the TestMirrorCDImageProberCallbacks indeed doesn't have IO, it's just for testing that the callbacks do what they're expected
[01:42] <spiv> salgado: Comments in the test with those messages instead would server the same purpose.
[01:42] <salgado> IIRC, the tests for IO are in the TestProberProtocol
[01:42] <Yannig> It would be easier to download several po files
[01:42] <spiv> Anyway, back on got_result: Deferreds catch *all* errors from callbacks (to turn into errbacks).
[01:42] <carlos> Yannig: yes, we don't care about the filename
[01:42] <salgado> spiv, fair enough, I'll remove the try/except and leave a comment
[01:43] <Yannig> Great :)
[01:43] <carlos> Yannig: oh, you mean for downloading it with that name?
[01:43] <carlos> Yannig: yes, I guess it's doable too, please file a bug
[01:43] <lifeless> when is the meeting ?
[01:43] <lifeless> 15 minutes ?
[01:43] <spiv> Your test would still fail correctly because the self.assertEqual([1] , ok).
[01:43] <spiv> Which basically means the got_result part is redundant.
[01:44] <spiv> (If things work, the test will pass without it, and if things don't work, the test will fail without it)
[01:44] <spiv> It's useful to have it for debugging, though...
[01:45] <spiv> Actually, it's definitely useless.
[01:46] <spiv> Twisted already unit tests that d.errback(<a failure>) will fire the first errback.
[01:46] <spiv> You don't need to cover that in your own test.
[01:47] <SteveA> mpt: did you get to talk with kiko about the filebug page?
[01:47] <spiv> So given that you're doing d.errback(Failure(ZeroDivisionError())), adding a callback to d in the test is definitely just a distraction.
[01:47] <mpt> SteveA, no, I haven't seen him awake for several days
[01:47] <SteveA> okay, we should discuss this after the lp meeting
[01:47] <spiv> salgado: Also, dl is totally unused in that test.
[01:48] <Yannig> carlos> Ups, I think I didn't post where it was supposed to (https://launchpad.net/distros/ubuntu/+source/debian-installer/+bug/46552) :(
[01:48] <Ubugtu> Malone bug 46552 in debian-installer "po files names" [Normal,Unconfirmed]  
[01:48] <spiv> salgado: and the errback added in the "d.addErrback(self.callbacks.ensureOrDeleteMirrorCDImageRelease)" line is never used.
[01:48] <Yannig> Sorry :(
[01:50] <SteveA> meeting in 10 mins
[01:50] <spiv> salgado: does the first half of test_failure_propagation ("Make sure that ensureOrDeleteMirrorCDImageRelease() does not propagate ProberTimeOut or BadResponseCode failures.") actually affect the second half ("Any failure that is not a ProberTimeout or BadResponseCode should be propagated because that is probably a bug in our code.") at all?  It looks like two seperate tests.
[01:50] <SteveA> take a workrave now if you need it
[01:50] <salgado> spiv, that's true. the first two tests already make sure that my callbacks don't propagate timeouts and badresponsecodes. I think I just need to add a third test to make sure they propagate any other exception
[01:50] <lifeless> I have a small ELYNNE
[01:50] <SteveA> me, i'm going to rest my wrists and flex my fingers on some honking blues licks in the style of jeff healey
[01:50] <carlos> Yannig: don't worry, I fixed it
[01:51] <lifeless> I will be back in a few minutes, but may miss the start
[01:51] <spiv> salgado: and make them into three seperate test methods, please.
[01:51] <spiv> salgado: small tests with a clear, specific purpose are better than big rambling tests that try to do a bit of everything.
[01:56] <lifeless> spiv: this ties in with my distaste for many doctest style tests actually.
[01:56] <spiv> lifeless: Yeah, I know what you mean.
[02:01] <salgado> it's time!
[02:01] <kiko-zzz> me
[02:01] <lifeless> you!
[02:01] <SteveA> Welcome to today's launchpad meeting
[02:01] <SteveA> a thunderstorm has just started in vilnius
[02:01] <SteveA> MEETING STARTS
[02:01] <SteveA> who's present today?
[02:01] <mpt> Please return to your seats and fasten your seatbelts
[02:01] <malcc> me
[02:01] <cprov> me
[02:01] <carlos> me
[02:01] <mpt> me
[02:01] <kiko> him
[02:01] <salgado> me
[02:01] <BjornT> me
[02:01] <matsubara> me
[02:02] <stub> me
[02:02] <sivang> me
[02:02] <lifeless> me
[02:02] <SteveA> kiko: his infernal majesty?  surely now
[02:02] <SteveA> kiko: his infernal majesty?  surely not
[02:02] <spiv> me
[02:02] <kiko> the royal him!
[02:02] <jamesh> me
[02:02] <SteveA> ddaa sends apologie
[02:02] <SteveA> s
[02:03] <SteveA> he's on public holidays / vacations, and will be back monday
[02:03] <malcc> This thunderstorm isn't doing your typing any favours Steve
[02:03] <kiko> apologies for being on holiday!
[02:03] <SteveA> malcc: must be the nervous tension
[02:03] <SteveA> either that or too much string-bending just prior to the meeting
[02:03] <SteveA> == Agenda ==
[02:03] <SteveA>  * Roll call
[02:03] <SteveA>  * Agenda
[02:03] <SteveA>  * Next meeting
[02:03] <SteveA>  * Activity reports
[02:03] <SteveA>  * Actions from last meeting
[02:03] <SteveA>  * Launchpad oops milestone report
[02:03] <SteveA>  * Outstanding sysadmin requests
[02:03] <SteveA>  * Production and staging (stub)
[02:03] <SteveA> ----
[02:03] <SteveA>  * (other items)
[02:03] <SteveA>  * launchpad bzr development workflow (robert/jamesh)
[02:03] <SteveA>  * Design discussion with reviewer by voip (Steve)
[02:03] <SteveA>  * Discuss a solution for the Retry exceptions (matsubara, kiko)
[02:03] <SteveA> ----
[02:03] <SteveA>  * Keep, Bag, Change
[02:03] <SteveA>  * Three sentences
[02:03] <SteveA> 
[02:03] <SteveA> next meeting: i propose the same time next week
[02:04] <kiko> why not
[02:04] <cprov> yup
[02:04] <SteveA> it is done
[02:04] <SteveA>  * Activity reports
[02:04] <lifeless> godlike
[02:04] <malcc> Dude next month is June
[02:04] <SteveA> after a decent performance last week, this week i suck
[02:04] <salgado> up to date
[02:05] <kiko> I'm there
[02:05] <stub> up to date
[02:05] <BjornT> up to date
[02:05] <jamesh> I suck, but am putting together another summary
[02:05] <malcc> Up to date after a lame summary today
[02:05] <mpt> up to date
[02:05] <SteveA> thanks mpt
[02:05] <spiv> up to date.
[02:05] <matsubara> up to date
[02:05] <SteveA> thanks malcc 
[02:05] <carlos> up to date
[02:05] <cprov> i suck, will send a summary for this week, I'm in a sprint anyway
[02:05] <mpt> (but, I batched the last three)
[02:05] <matsubara> I'm also guilty of batching.
[02:05] <SteveA> cprov: sprinters are excused from daily reports, summaries are appreciated
[02:06] <SteveA>  * Actions from last meeting
[02:06] <malcc> We got a last-one-wins concurrency error on the topic, next meeting is still in August
[02:06] <SteveA> there were none
[02:06] <cprov> SteveA: I know, I will do a descent summary this time ;)
[02:07] <SteveA>  * Launchpad oops milestone report
[02:07] <SteveA> matsubara: hit it!
[02:07] <matsubara> Top exceptions are on shipit which are all assigned to Salgado.
[02:07] <matsubara> He has been working on them. Bugs 45601 and 5812
[02:07] <Ubugtu> Malone bug 45601 in shipit "OOPS trying to Cancel the same request on two different tabs" [Normal,In progress]  http://launchpad.net/bugs/45601
[02:07] <matsubara> Another outstanding exception is the Retry one, which I added a item to the
[02:07] <matsubara> MeetingAgenda. Do you want to discuss it now or leave it to later?
[02:07] <mpt> Now we'll never have another meeting
[02:07] <matsubara> as later I mean the Proposed items section
[02:07] <matsubara> let's do it now then
[02:08] <SteveA> yeah, do it now
[02:08] <matsubara> We're seeing lots of Retry exceptions, caused by the session machinery, and
[02:08] <matsubara> stub advised that to debug it properly identify the cause we need bug 31479 fixed..
[02:08] <matsubara> spiv is assigned to it, and said in the last meeting that he would work on it at.
[02:08] <matsubara> the end of this week.
[02:08] <Ubugtu> Malone bug 31479 in launchpad "Retry exceptions should include information about the original query" [Critical,Confirmed]  http://launchpad.net/bugs/31479
[02:08] <stub> I was also going to refactor the session machinery again to make it even friendlier
[02:08] <SteveA> i believe we also have some concurrency improvements in the session machinery landing or landed soon
[02:08] <SteveA> stub: eta ?
[02:08] <stub> I noticed, however, that the number of exceptions dropped from hundreds to two in the last error report, which is very unusual
[02:09] <stub> eta Tuesday
[02:09] <spiv> matsubara: Yeah, that's right near the top of my todo list finally.
[02:09] <matsubara> I think we're good then. kiko, anything else?
[02:09] <SteveA> any idea why the exceptions would drop to two?
[02:09] <SteveA> is there some kind of fault in error reporting?
[02:09] <SteveA> or has some evil DOS attack stopped hitting us?
[02:09] <kiko> I'm not sure. Could be the Shipit DOS :)
[02:10] <stub> Or the condition that was triggering the number of Retrys stopped. Possibly a DOS we didn't notice.
[02:10] <stub> Shipit is as busy as ever
[02:10] <SteveA> stub: would you check the other launchpad logs, just to make sure there isn't an error that somehow isn't sending oopses?
[02:10] <stub> ok
[02:11] <SteveA> thx
[02:11] <matsubara> Top timeouts are the same. Most of them assigned to kiko. kiko, any news about it?
[02:11] <kiko> I've worked on a relatedjoin fix that appears to improve many of them
[02:11] <kiko> I'm also working on adding prejoins to multiple and relatedjoin
[02:11] <kiko> it's going slow because I'm overloaded
[02:11] <kiko> might get in by tomorrow
[02:12] <kiko> spiv will need to review at some point
[02:12] <matsubara> ok
[02:12] <matsubara> Would help a lot the QA job to solve bug 30670. It's currently assigned to stub. Is it feasible?
[02:12] <Ubugtu> Malone bug 30670 in launchpad "Launchpad developers should have admin privileges on staging" [Normal,Confirmed]  http://launchpad.net/bugs/30670
[02:12] <bradb> Uh, I'm on crack. I'm here and up-to-date on activity reports. /me lost track of the time while answering email.
[02:13] <SteveA> i'm not sure about that one
[02:13] <stub> matsubara: It is feasable, but also limits the ability of developers to test stuff. 
[02:13] <SteveA> matsubara: an issue there is that it means launchpad developers get to see private bugs
[02:13] <SteveA> and private bugs are mirrored to staging each day
[02:13] <stub> matsubara: A better approach might be to insert superuser accounts using different names/email addresses after the database update, giving you two accounts on staging.
[02:13] <SteveA> stub: i need to implement hats...
[02:13] <stub> SteveA: yup
[02:13] <matsubara> stub: that would do
[02:13] <lifeless> SteveA: pull it off the cdrom
[02:14] <SteveA> i don't want all launchpad developers to have admin access on staging
[02:14] <matsubara> stub: i think it's even easier to do right?
[02:14] <SteveA> i'm happy with just certain people who need it to have such access
[02:14] <stub> matsubara: Yes
[02:14] <lifeless> SteveA: I may be missing something, but dont all developers have db access to staging ?
[02:14] <salgado> lifeless, no
[02:14] <matsubara> lifeless: not the db, but to the web UI
[02:14] <SteveA> lifeless: i'd be not in favour of that either
[02:14] <stub> lifeless: nope. We control it, because it is a full production mirror including security sensitive stuff.
[02:15] <kiko> meneeder
[02:15] <lifeless> stub: yes, aware of that :). Must be mis-recalling.
[02:15] <stub> It generally gets granted on need though
[02:16] <SteveA> matsubara: for what qa purposes do you want admin access on staging?
[02:16] <matsubara> SteveA: sometimes I need to reproduce some bug
[02:16] <matsubara> and it's easier to use staging
[02:16] <mpt> to reproduce bugs in things like source imports
[02:17] <SteveA> okay.  i'm fine with launchpad admins plus matsubara having admin access on staging
[02:17] <SteveA> but not all launchpad devs
[02:17] <SteveA> if stu can rig up something to make that so, that's fine
[02:18] <matsubara> SteveA: ok, I'll update the bug description
[02:18] <matsubara> And as a final note, I'd like to ask developers to use the in-progress status and to append the bug number to your commit messages.
[02:18] <SteveA> matsubara: please give an example of a commit message that is good in this regard
[02:19] <matsubara> Fix bug url (bug summary)
[02:19] <mpt> matsubara, perhaps many of the bugs for which you might need staging are also bugs of insufficient sampledata
[02:19] <SteveA> and, do you mean pqm merge messages, or any old commit messages?
[02:19] <matsubara> SteveA: I mean pqm merge messages
[02:19] <jamesh> so you're interested in mainline log messages
[02:20] <SteveA> i've been talking with jamesh and others about our pqm email messages
[02:20] <matsubara> mpt: yes, that's it. can't think of a real life example right now, though
[02:20] <SteveA> i think developers should be able to say in a "local" commit "fixed bug URL SUMMARY"
[02:20] <mpt> matsubara, an example is that localhost doesn't have anything in the translation import queue
[02:20] <SteveA> and the email should pull these out of the sub-commits
[02:20] <mpt> sampledata doesn't, rather
[02:20] <jamesh> (which makes sense when trying to match up which bugs are fixed in a given rollout)
[02:20] <SteveA> and display them prominently in the email from pqm
[02:20] <SteveA> that way, a developer can focus on one commit at a time
[02:20] <SteveA> and not need to repeat things for pqm
[02:21] <SteveA> but, until we have implemented that, i ask everyone to do as matsubara asks
[02:21] <SteveA> and add "fix bug URL SUMMARY" to pqm messages
[02:21] <bradb> +1
[02:21] <jamesh> full URL rather than just number?
[02:22] <stub> tests can always insert more data into the database in their setup - sampledata should really only be used for data common across many tests and to get the basic app up and running.
[02:22] <Ubugtu> Malone bug 42 in malone "Bug description listed in task is not the correct description" [Normal,Fix released]  http://launchpad.net/bugs/42
[02:22] <SteveA> matsubara: are you okay with just the number?
[02:22] <matsubara> URL helps, but I'm ok with the numbers and the summary
[02:22] <matsubara> s/numbers/number/
[02:22] <SteveA> matsubara: you can write a script that gives you URLs for "bug NNN" patterns
[02:22] <bradb> The /bugs/... URL is good for this.
[02:23] <SteveA> okay, so number and summary, not URL
[02:23] <matsubara> that's it, I'm done. Thanks guys.
[02:23] <SteveA> matsubara: please send an email to the launchpad list clearly stating the requirements we've agreed
[02:23] <SteveA> thanks matsubara 
[02:23] <matsubara> ok
[02:23] <lifeless> SteveA: please file a bug with what you would like on launchpad-development-infrastructure.
[02:23] <SteveA> ok
[02:23] <SteveA>  * Production and staging (stub)
[02:23] <kiko> LDI
[02:23] <stub> Production and staging are both running happily. PostgreSQL security issues are under control - nothing further to add over what has already been mentioned on the mailing list and I'm not going to repeat it in a public channel.
[02:23] <stub> Until dapper release, please let me know via the mailing list about cherry pick requests sooner rather than later, as we have to avoid disrupting the distro team during the final stage of getting Dapper out of the door. Regular rollouts may also become irregular too, or skipped entirely - if we miss anything urgent (eg. shipit updates) we can discuss it with mdz.
[02:24] <lifeless> stub: we have one update that is important, soon, which is the supermirror update for bzr 0.8
[02:24] <kiko> stub, we're supposed to roll out the shipit modifications, but they do not involve database changes.
[02:24] <kiko> (right salgado?)
[02:24] <lifeless> stub: spiv knows where that is at in more detail.
[02:24] <stub> Stuff that doesn't involve db changes is easy
[02:25] <salgado> right
[02:25] <spiv> lifeless, stub: I have a bunch of branches related to that I want to land, but I expect to land them tonight.  After that, I'm happy.
[02:25] <SteveA>  * launchpad bzr development workflow (robert/jamesh)
[02:25] <salgado> it'd be good if we could roll out the new mirror prober (which does include db changes), so we can have nice listings of mirrors when dapper is released
[02:25] <SteveA> i don't remember what this is about.  lifeless, jamesh ?
[02:26] <lifeless> you asked for a documented best practice on setup and process for lp development
[02:26] <kiko> salgado, mirror prober for next week, I guess
[02:26] <lifeless> I spoke with jamesh about it, but did not follow up - sorry.
[02:26] <SteveA> okay.  we can defer this to the next meeting
[02:26] <lifeless> (Its in my TODO list, 3rd from the top)
[02:26] <SteveA> i do want to get everyone on the same page with this
[02:26] <spiv> lifeless: just one thing -- what's the URL for the pqm-submit plugin?
[02:26] <SteveA>  * Design discussion with reviewer by voip (Steve)
[02:27] <spiv> (I'm still hand-crafting my pqm messages, when I really shouldn't be...)
[02:27] <lifeless> spiv: bzr.j-a-meinel.org or some such
[02:27] <SteveA> i propose that before starting work on a feature, the person who will develop the feature arranges a voip call with a reviewer
[02:27] <SteveA> to discuss the design approach
[02:27] <jamesh> spiv: there are some details on setting it up on the WorkingWithSharedRepositories page
[02:27] <lifeless> spiv: see james's repository-usage wiki page
[02:27] <spiv> jamesh: thanks
[02:27] <jamesh> spiv: should answer your questions even if you aren't using shared repos yet
[02:27] <SteveA> are reviewers happy to have such conversations?
[02:27] <lifeless> talking with a reviewer about the proposed approach should give you a design review before code is done
[02:28] <mpt> SteveA, does that apply only to those features that aren't covered by specs with Implementation sections?
[02:28] <lifeless> SteveA: yes we are, we talked this over last review meeting.
[02:28] <SteveA> mpt: no
[02:28] <SteveA> lifeless: thanks
[02:28] <spiv> I am, although I fear I won't be available at the right times for most other developers.
[02:28] <spiv> (due to timezones)
[02:28] <jamesh> same here
[02:29] <SteveA> why not bradb ?
[02:29] <bradb> Reviewers will become bottlenecks.
[02:29] <SteveA> are you criticising my choice of necktie?
[02:30] <SteveA> like with code-reviews, i'd like us to try this out
[02:30] <bradb> It's already hard to find their time for a review. Finding their time for a voip call will be equally challenging, I imagine, and add more process than benefit, IMHO.
[02:30] <SteveA> thanks for the naysaying, brad.  let's suck it and see.
[02:30] <bradb> ok
[02:30] <kiko> bradb, well, there is a lot of benefit in discussing design beforehand
[02:30] <bradb> kiko: I agree 100%. I just don't think it should be required to discuss with a code reviewer.
[02:30] <kiko> it should be more or less high-level -- i.e. this class does this part, this does this, etc.
[02:30] <stub> This will move discussions off the mailing list
[02:31] <jamesh> it can potentially reduce the time to review the code after it is done
[02:31] <kiko> bradb, well, who are you going to discuss it with?
[02:31] <bradb> kiko: you, mpt, etc.
[02:31] <jamesh> if it helps avoid issues that would come up during review
[02:31] <bradb> maybe SteveA or BjornT for zopish things
[02:31] <bradb> various other people as appropriatae
[02:31] <mpt> Maybe there's a disconnect here over what "design" means
[02:31] <spiv> bradb: three out of four of those people are reviewers ;)
[02:32] <SteveA> i have had a positive experience discussing designs and implementation approaches pre-implementation for rosetta, previously
[02:32] <SteveA> i believe carlos and daf shared the positive experience
[02:32] <SteveA> and it generally cut time off the implementation
[02:32] <bradb> I'm not arguing against design discussion, of course.
[02:32] <carlos> SteveA: right, but I share the concerns bradb has
[02:32] <bradb> Design discussion is important and informative.
[02:32] <carlos> SteveA: If we have it as a rule
[02:33] <carlos> the overload of our reviewers will be too high
[02:33] <SteveA> i think an attempt should be made to arrange such a call
[02:33] <SteveA> if it isn't possible, that's fine
[02:33] <cprov> SteveA: I had experiences with kiko in Soyuz as well
[02:33] <cprov> good experiences
[02:33] <SteveA> but i want to make it the coder's responsibility to attempt to arrange such a call
[02:33] <kiko> so bradb, to help, you can always consider me for a phone call
[02:33] <SteveA> and report to the list the success or failure of having such a call
[02:33] <lifeless> theres a lot of concern here about reviewer load
[02:33] <kiko> I am in your timezone and you can either bother me on IRC or on the phone, no problem
[02:33] <SteveA> then we'll be able to see how practical it is
[02:33] <mpt> So, what is the relationship between these calls and the Implementation section of the relevant spec?
[02:34] <SteveA> if reviewers say "no, too busy" so be it
[02:34] <mpt> Will they be more detailed? More up to date?
[02:34] <SteveA> mpt: it's a good question.  let's see how the calls pan out.
[02:34] <lifeless> I'd like to note that the review team is coping just fine with load right now, and we are short 3 reviewers - steve, kiko & salgado are all very busy
[02:34] <bradb> kiko: that would help
[02:34] <bradb> if we can move on after a "no, too busy", that's a bit better too :)
[02:34] <SteveA> okay, we've had a lot of good points raised here.
[02:34] <lifeless> a 15 minute phone call before a branch is started will (IME) save far more than 15 minutes at the end of the branch
[02:34] <SteveA> thanks everyone for that
[02:35] <SteveA> here's what we'll do:
[02:35] <lifeless> so the reviewers will actually become *less loaded*, not more. 
[02:35] <SteveA>  - before starting on a feature, the coder responsible will contact a suitable reviewer and ask for a pre-implementation call
[02:35] <cprov> lifeless: good point ;)
[02:35] <SteveA>  - the reviewer may reject, or may pass to another reviewer, or accept
[02:36] <SteveA>  - the coder responsible must report to the launchpad list if the call actually happens or not
[02:36] <SteveA>  - the reviewer should summarize the call (in a paragraph only perhaps) to the reviewers list after the call
[02:36] <SteveA> let's try this out for a few weeks, and see what happens
[02:37] <SteveA> please keep up to date with sending the emails.  it's the only way we'll be able to judge how the system is working.
[02:37] <lifeless> can I ask for the reviewer summary to include the call length.
[02:37] <SteveA> you can
[02:37] <carlos> SteveA: should it affects bug fixing too?
[02:37] <SteveA> lifeless: would you be willing to write this up on the wiki?
[02:37] <lifeless> I want to understand the impact on the reviewers of this. So I'm also going to ask that reviewers note how long a branch review takes from now on too. 
[02:37] <SteveA> carlos: for a small obvious bug, no.  for something tougher, or with questions, sure, do.
[02:37] <bradb> SteveA: you mean we should send emails like "I tried to arrange a call with spiv, but he was busy. kthxbye."?
[02:37] <carlos> ok
[02:37] <lifeless> reviewers - does that sound ok ?
[02:38] <SteveA> bradb: "and he said he was too busy" sure.
[02:38] <lifeless> SteveA: yes, make an action for me, I'll be happy do to the writeup
[02:38] <SteveA> okay
[02:38] <SteveA> MeetingAction: lifeless to write up pre-implementation voip reviews policy
[02:38] <SteveA> we gotta move it on
[02:38] <SteveA>  * Discuss a solution for the Retry exceptions (matsubara, kiko)
[02:38] <SteveA> has this already been addressed?
[02:39] <matsubara> I think so.
[02:39] <SteveA> okay, thanks
[02:39] <matsubara> unless kiko wants to add something else
[02:39] <SteveA>  * Outstanding sysadmin requests
[02:39] <SteveA> (i forgot from earlier)
[02:39] <SteveA> spiv: i still have that issue outstanding from you
[02:39] <malcc> Yeah I've got one, one sec
[02:39] <SteveA> and i need to talk with elmo about it, as there are some firewalling policy issues to be solved, apparently
[02:39] <kiko> not really matsubara 
[02:39] <spiv> SteveA: yep.  I presume the impending dapper release is eating the admins lives atm...
[02:40] <SteveA> it's keeping elmo busy
[02:40] <spiv> SteveA: In the short term, lifeless has provided me a tarball of the logs to date.
[02:40] <malcc> rt #9117, request for access to accounts on drescher cprov tells me I need
[02:40] <SteveA> ah, okay
[02:40] <SteveA> spiv: so i won't push it this week
[02:40] <spiv> SteveA: so it's not urgent atm.
[02:40] <SteveA> malcc: when do you need these?
[02:40] <malcc> SteveA: As soon as possible, so I can start helping to trace live issues
[02:41] <SteveA> please always try to include an estimated due date in RT reports, by the way.  it helps me and sysadmins plan things
[02:41] <SteveA> malcc: okay, noted.  thanks.
[02:41] <SteveA>  * Keep, Bag, Change
[02:41] <SteveA> with a countdown
[02:41] <SteveA> 6
[02:41] <SteveA> 5
[02:41] <mpt> CHANGE: Each week, make the Oops report the last agenda item. Immediately afterward, use whatever time remains to crack the whip on the oldest Critical Launchpad bugs. Crashes are not the only awful failures Launchpad can have; arguably they're less bad than bugs where people think the failure is their fault.
[02:41] <stub> KEEP: zope.testbrowser. Pagetest testing a cookie auth edge case worked first time - I didn't believe it was actually being run.
[02:41] <SteveA> 4
[02:41] <SteveA> 3
[02:41] <mpt> KEEP: stub. He's doing an awesome job.
[02:41] <malcc> stub++, testbrowser rocks
[02:42] <SteveA> 2
[02:42] <salgado> new bzr!
[02:42] <SteveA> 1
[02:42] <spiv> KEEP: matsubara's error report summaries/bug triaging.
[02:42] <salgado> KEEP ^
[02:42] <bradb> indeed
[02:42] <SteveA> ...
[02:42] <SteveA> 0.5
[02:42] <SteveA> PI
[02:42] <matsubara> salgado++
[02:42] <sivang> heh
[02:42] <SteveA> 2
[02:42] <sivang> (re PI)
[02:42] <SteveA> 1
[02:42] <lifeless> sqrt(-1)
[02:42] <SteveA> 0
[02:42] <SteveA> okay done
[02:42] <SteveA> three sentences please
[02:42] <SteveA> post them now
[02:42] <lifeless> DONE: make bzr add take 1/5 the previous time, make bzr commit 10% faster, improve benchmarking facilities to allow lsprofile output of individual portions.
[02:42] <mpt> DONE: MaloneSimplifications, ShipIt fixes, CSS fixes, administrivia
[02:42] <mpt> TODO: DescriptionMarkup + LaunchpadLoginService specs, bugfixes
[02:42] <mpt> BLOCKED: no
[02:42] <lifeless> TODO: WORM proof of concept with martin, make commit faster, study hg for meeting.
[02:42] <malcc> DONE: Learnt more about Soyuz, sprinted with Celso.
[02:42] <malcc> TODO: Finish sprint, fix Soyuz.
[02:42] <malcc> BLOCKED: No
[02:43] <matsubara> DONE: fixed +bugcontact broken link, distro mirror validation, oops report
[02:43] <lifeless> BLOCKED: Nada
[02:43] <matsubara> analysis;
[02:43] <matsubara> TODO: fix oops bugs and more triage;
[02:43] <matsubara> BLOCKED: no
[02:43] <kiko> DONE: interviews, performance patches, many reviews and design discussions
[02:43] <carlos> DONE: Merged and fixed mark's potemplate priority branch, discussion about potemplate RSS, migration to knits, POMsgSetPage UI discussion, Changes to the batching code, Fixed .pot exports, prepared Rosetta and Dapper announcement and a bunch of translation domains fixed to get full translations from Rosetta
[02:43] <carlos> TODO: Finish Karma testing, Fix all test for POMsgSetPage, add more filtering options to the translation import queue (bug #40550), Add a debug page to see how Rosetta behaves with different Browser language selections or IP address that we use to select some content statistics
[02:43] <carlos> BLOCKED: no
[02:43] <Ubugtu> Malone bug 40550 in rosetta "Further filtering options for the Queue" [Normal,Unconfirmed]  http://launchpad.net/bugs/40550
[02:43] <BjornT> DONE: bug fixes. landed a few branches. reviews.
[02:43] <BjornT> TODO: make products have bugtrackers. huge comments -> attachments.
[02:43] <BjornT> reviews. have vacation.
[02:43] <BjornT> BLOCKED: no
[02:43] <spiv> DONE: reviews, got bzr 0.8 merged into rocketfuel AT LAST, ubuntu wiki stuff
[02:43] <spiv> TODO: merge various branches unblocked by bzr 0.8 merge, retry info (bug 31479), research bug 33223
[02:43] <spiv> BLOCKED: no.
[02:43] <salgado> DONE: improvements to the new shipit (including the new custom request page) and finished the mirror prober for release mirrors; 
[02:43] <salgado> TODO: land the changes to the mirror prober and the new custom request page for shipit
[02:43] <salgado> BLOCKED: no
[02:43] <Ubugtu> Malone bug 31479 in launchpad "Retry exceptions should include information about the original query" [Critical,Confirmed]  http://launchpad.net/bugs/31479
[02:43] <cprov> DONE: soyuz sprint with malcc, fix on publisher and upload land (malcc tour)
[02:43] <cprov> TODO: reduce the publication turnaround, redesign upload land
[02:43] <cprov> BLOCKED: None
[02:43] <jamesh> DONE: pending-review updates, scheduler work, code reviews
[02:43] <Ubugtu> Malone bug 33223 in launchpad-bazaar "SFTP server should give human-friendly errors for name restrictions" [Normal,Confirmed]  http://launchpad.net/bugs/33223
[02:43] <jamesh> TODO: get scheduler polished and ready to use, launchpad-bazaar stuff as discussed with ddaa, code reviews
[02:43] <jamesh> BLOCKED: no
[02:43] <bradb> DONE: Put implicit subs in review. Long weekend. Fixed a few OOPS and other bugs. Started on release bug management and xmlrpc.
[02:43] <bradb> TODO: Release bug management and xmlrpc. Fix various high priority bugs.
[02:43] <bradb> BLOCKED: No.
[02:43] <kiko> TODO: unload patches in my tree into PQM dammit, review and assist anyone else needing that
[02:43] <SteveA> DONE: various flavours of management stuff, code reviews, phone calls
[02:43] <SteveA> TODO: menus menus menus
[02:43] <SteveA> BLOCKED: my time and focus on code
[02:43] <stub> DONE: Odds and sods.
[02:43] <stub> TODO: Session updates, searching updates
[02:43] <stub> BLOCKED: lifeless to land SQLObject/launchpad fix to rocketfuel
[02:43] <lifeless> stub: thats done
[02:44] <stub> lifeless: ta
[02:44] <stub> BLOCKED: Nope
[02:44] <SteveA> i see no further blockers to be dealt with
[02:44] <kiko> BLOCKED: jamesh still hasn't gotten us a weekly OOPS report, SteveA needs to confirm carlos' travel suggestion
[02:44] <SteveA> thanks kiko
[02:44] <SteveA> jamesh: ?
[02:44] <kiko> I had others but I lost them
[02:45] <stub> BAG: This virus I've come down with :/
[02:45] <jamesh> kiko: gar.  I'll get a manual OOPS report ready for this week and make sure the cron job running for next week
[02:45] <SteveA> MEETING ENDS
[02:45] <SteveA> thanks for your attention everyone
[02:45] <jordi> doh
[02:45] <kiko> jamesh, I thought it was just a matter of running the cronjob with a set of directories instead of a single one?
[02:45] <jordi> Just in time for tthe MEETING ENDS token
[02:45] <jordi> sorry  guys, hectic stuff at work
[02:46] <jordi> SteveA: want my details my msg?
[02:46] <lifeless> bradb: what sort of trouble are you ahving finding reviewers ?
[02:46] <lifeless> bradb: I see one branch of yours in needs-review, which is one day old
[02:46] <bradb> lifeless: Small sample size. :)
[02:47] <bradb> The average review response time for me is about a week.
[02:47] <lifeless> bradb: not really. you have a 15 day old branch in merge-conditional, and no branches in w-i-p
[02:47] <SteveA> oh, i didn't mention w-i-p
[02:47] <SteveA> i'll have to mention that next week
[02:47] <jamesh> kiko: yeah.  Just get it to run the right date commands to work out which directories to scan
[02:47] <lifeless> bradb: We haven't reached a week for any reviews for about 2 weeks.
[02:47] <mpt> Can someone explain to me the point of w-i-p?
[02:47] <mpt> oh, ok, next week
[02:48] <lifeless> bradb: ever since kiko cleaned up cprovs branches in fact.
[02:48] <kiko> lifeless, that's just because I suck, generally reviewers have been timely enough
[02:48] <stub> Oh - I lied. Staging authentication is buggered. I'm landing a fix now. If you are logged in, don't log out until I get to update it.
[02:48] <lifeless> we are aiming for 48 hour turnaround on all reviews at the moment
[02:49] <lifeless> and with very few exceptions we're reaching that
[02:49] <lifeless> (not counting weekends)
[02:49] <kiko> bradb, and instareviews you have asked have been done, hopefully?
[02:49] <SteveA> mpt: i updated the MeetingAgenda page.  i want to move the agenda and meeting summaries to help.launchpad.net
[02:49] <bradb> kiko: yeah, instareviews have been good lately
[02:49] <kiko> bradb, so STOP COMPLAINING :-P
[02:49] <BjornT> lifeless: please reassign carlos' branch, i won't have time to review it before next Thursday.
[02:50] <lifeless> BjornT: ok
[02:50] <mpt> SteveA, not that I think help.launchpad.net should exist in the first place, but why would meeting agendas be on it?
[02:50] <kiko> mpt, it's out public wiki.
[02:50] <kiko> our, gah
[02:50] <SteveA> kiko, mpt: sometime during the next 30 mins i'd like us to discuss some usability questions about the new filebug page
[02:50] <lifeless> BjornT: you have time for brads though ?
[02:51] <mpt> Next ten minutes, please, I have a breakfast appointment
[02:51] <bradb> I think reviewer response time is /improving/ at any rate. I'm guessing the average response time is coming into focus around 3-4 days now.
[02:51] <SteveA> kiko, mpt: this can wait until tomorrow, if preferred
[02:51] <kiko> SteveA, uhhh, "new filebug page"?
[02:51] <SteveA> kiko, mpt: but i *do* want us to discuss it this week.  before a rollout.
[02:51] <mpt> sure
[02:51] <kiko> I strongly recommend any "new filebug page" is presented to distro users before it has a chance of affecting anybody!
[02:51] <bradb> LAND IT
[02:52] <SteveA> well, i'm in favour of rolling it back, actually
[02:52] <BjornT> lifeless: yeah, i'll do bradb's and mpt's today.
[02:52] <SteveA> but, that's for the discussion
[02:52] <kiko> +1 for rolling back any change that doesn't have distro team approval
[02:52] <lifeless> thanks BjornT 
[02:52] <lifeless> jamesh: I'm giving you carlos branch
[02:53] <carlos> it shouldn't be too difficult
[02:53] <carlos> it's really small
[02:53] <lifeless> carlos: instareview for you - not enough tests
[02:54] <lifeless> carlos: if you look here - https://chinstrap.ubuntu.com/~jamesh/pending-reviews/carlos/launchpad/bug-46459/full-diff
[02:54] <lifeless> you can see there are 4 lines of test changes
[02:54] <lifeless> and 375 lines of non test changes.
[02:55] <lifeless> this ratio suggests that you have added 375 lines of untested code :(
[02:55] <lifeless> carlos: do you think its well tested ? [I may be missing something] 
[02:56] <carlos> lifeless: 4 lines of test changes?
[02:56] <lifeless> lib/canonical/launchpad/ftests/test_system_documentation.py |    4 
[02:56] <lifeless> 
[02:56] <lifeless> oh, I missed
[02:56] <lifeless> lib/canonical/launchpad/doc/po_export_queue.txt             |   43 +++
[02:56] <bradb> i think 3/4's of my implicit subs additions were tests :)
[02:56] <lifeless> but still, 43:330 is a fairly low ratio.
[02:57] <carlos> lifeless: anyway, I think I could add more tests
[02:57] <lifeless> carlos: looking at your test, it seems to soley test the pass condition
[02:58] <carlos> the pass condition?
[02:59] <carlos> lifeless: I'm not sure that rate would be a good way to see if it's well tested this branch, I'm adding a new view and thus new interfaces and many attributes
[03:00] <carlos> I agree that I can improve the tests, but I hope you don't expect that I get a 1:1 rate...
[03:00] <lifeless> carlos: well, I'm off to bed. I expect jamesh' review will say something similar.
[03:01] <lifeless> carlos: there are tests that test the 'normal' behaviour of a routine
[03:01] <carlos> jamesh: let me do some changes after lunch and leave the review until tomorrow to improve the tests so your review would be more easy
[03:01] <lifeless> and there are tests that test error conditions.
[03:02] <carlos> lifeless: oh, I see what you mean
[03:02] <lifeless> code that has few or no tests of either sort, is often prone to undetected defects in that area.
[03:02] <carlos> right
[03:02] <lifeless> gnight all
[03:03] <carlos> lifeless: night and thanks
[03:03] <spiv> carlos: A rough guideline can be to use the --coverage option of test.py, and see if there's any lines of code you've added that aren't executed.
[03:03] <spiv> s/added/added or changed/
[03:04] <carlos> spiv: do we have such feature??
[03:04] <carlos> wow
[03:04] <carlos> spiv: how does it know what was added or changed?
[03:04] <spiv> carlos: it doesn't, but you should :P
[03:05] <carlos> oh, I see
[03:05] <carlos> that would help me also to improve our current tests, right?
[03:05] <spiv> (but if it did, that would be sweet!)
[03:05] <spiv> Yep.
[03:09] <spiv> carlos: I haven't actually played with --coverage much, so I'm not certain it works properly with code invoked from doctests and other odd stuff.  I expect it's actually fine, but let me know if you have any questions about the results it generates.
[03:09] <carlos> spiv: sure. Thank you
[03:12] <carlos> later
[03:21] <SteveA> lifeless: your recent email about knits for SM landing shortly...
[03:21] <SteveA> lifeless: does that mean the issues with bzr test failures in sourcecode/ are fixed?
[03:26] <spiv> SteveA: Yes, that landed a few hours ago.
[03:26] <SteveA> way cool
[03:26] <spiv> Yeah!
[03:26] <SteveA> high five to bzr-related-to-launchpad folks
[03:28] <spiv> I've done a trivial merge to gnarly, doing a trivial merge to pybaz, probably will need a trivial merge to cscvs, then I can re-enable the sourcecode/* checks!
[03:35] <stub> copy_to_zlog is set to false on the production systems, but the launchpad logs are full of noise
[03:58] <cprov> carlos: ping, have a look at bug 46559
[04:13] <salgado> carlos, cprov, is any of you guys dogfood at the moment?
[04:15] <cprov> salgado: yes
[04:18] <cprov> salgado: I'd say 'depends', what do you need ?  currently I'm publishing stuff in dogfood, I've updated the DB to a 18th May copy of production ...
[04:18] <salgado> cprov, will you be using it the whole day or can I kill it for a code/db update at some point?
[04:19] <salgado> oh, great. that's the one I'm restoring
[04:19] <salgado> so, that means I only need a code update
[04:19] <cprov> salgado: ehe
[04:19] <cprov> salgado: I've kept you tree in place
[04:20] <cprov> salgado: I mean, "your" tree, sorry 
[04:20] <salgado> which one is mine?
[04:20] <salgado> hmmm. actually there's a db patch that I'd need to apply
[04:22] <cprov> salgado: shipit-for-dapper, maybe ?
[04:23] <cprov> salgado: you can apply it in the current launchpad_dogfood, might be harmless to the soyuz stuff I'm using, right ?
[04:24] <salgado> it's another branch, actually
[04:28] <carlos> cprov: done and answered
[04:35] <salgado> cprov, yes, it should be harmless; it's just a new table
[04:37] <cprov> carlos: thank you 
[04:37] <carlos> np
[04:37] <cprov> salgado: go for it then
[04:47] <spiv> Ah crud pybaz fails with rocketfuel's twisted.
[04:47] <spiv> fails and *hangs*!
[04:47] <spiv> stub, lifeless: pqm seems to be hung :(
[04:56] <spiv> lifeless/stub: please kill the current pqm merge that's hung.  The next merge in the queue fixes the problem.
[04:56] <spiv> Does anyone who's actually awake have access to balleny?
[04:57] <spiv> elmo/Znarl: the current PQM job is hung, could you kill it please?
[04:59] <Yannig> Great: tomorrow, Occitan to-do translations will go under 99 % :D
[04:59] <malcc> Yannig: Nearly done then :)
[04:59] <Yannig> "Nearly", yes :D
[05:00] <Yannig> I just have to recruit some help :p
[05:00] <elmo> stub: done
[05:00] <elmo> spiv even
[05:00] <spiv> elmo: thanks!
[05:00] <Yannig> (for productivity and above all quality...)
[05:00] <spiv> lifeless, stub: elmo sorted me out.
[05:02] <carlos> Yannig: ;-)
[05:05] <lucasvo> is rosetta something like a gettext gui?
[05:10] <mdke> lucasvo: it is like an online poedit/gtranslator/kbabel
[05:10] <mdke> except collaborative
[05:12] <lucasvo> mdke: and how can one add the pofiles?
[05:13] <mdke> lucasvo: they are there already. You add to them by editing online. It is also possible to download one, translate it offline, and upload it
[05:15] <lucasvo> mdke: I don't want to translate
[05:15] <lucasvo> I want to register my project there so other peope can translate
[05:17] <mdke> lucasvo: https://wiki.launchpad.net/RosettaNewImportPolicy
[05:18] <mdke> then you use the "Request Translation Upload" button
[05:20] <lucasvo> hm, so rosetta isn't meant for non ubuntu projects?
[05:21] <mdke> lucasvo: certainly it is
[05:21] <lucasvo> it looks quite complicated 
[05:22] <mdke> lucasvo: no, it's easy. You just read that page and then if you are the upstream project maintainer, you can request to use rosetta with "Request Translation Upload"
[05:22] <lucasvo> where is the link?
[05:23] <mdke> lucasvo: https://launchpad.net/products/yourproduct/yourrelease/+translations-upload
[05:28] <lucasvo> oh crap
[05:28] <lucasvo> so I need to register a product and not a project?
[05:29] <lucasvo> what is the difference?
[05:30] <mdke> that is a question that I am not able to help with
[05:30] <mdke> I don't understand it either
[05:30] <spiv> lucasvo: roughly, a project is a group of related products.
[05:31] <lucasvo> crap
[05:31] <lucasvo> can I delete a project?
[05:31] <spiv> lucasvo: that needs an admin, unfortunately :(
[05:31] <spiv> lucasvo: file a support request or mail the launchpad-users list.
[05:31] <mdke> heya spiv
[05:32] <spiv> mdke: hey :)
[05:32] <lucasvo> anybody here who can do it?
[05:32] <mdke> spiv: get my email about the page cache thing? Is that trivial to include?
[05:32] <spiv> mdke: I did. It's trivial to fix up after the script runs.
[05:33] <mdke> spiv: ah, that won't go in the script itself?
[05:34] <spiv> So I think we may as well leave the script alone (seeing as I managed to make one that worked first time for once ;), and get the admins to run a simple find + rm after it runs.
[05:34] <mdke> ok, whatever you prefer
[05:34] <lucasvo> can projects and products have the same nam?
[05:34] <spiv> (or however it was fixed last time)
[05:34] <lucasvo> *name
[05:34] <mdke> spiv: last time?
[05:34] <spiv> lucasvo: yeah, I think so.
[05:35] <mdke> spiv: oh, cachecleaner.py might do the trick
[05:35] <mdke> :)
[05:35] <spiv> oh, if it's already written, even better :)
[05:35] <mdke> just saw it now
[05:39] <spiv> Ok, pybaz fix merged ok, let's see how this merge goes this time...
[06:07] <bradb> mpool: What LP xmlrpc doc did you read to write the register-branch plugin? (Assuming you were the one that wrote it.)
[06:19] <BjornT> bradb: http://bazaar-vcs.org/Specs/BranchRegistrationTool
[06:33] <spiv> YES
[06:33] <spiv> "make check_merge" is back at full strength.
[06:50] <mantiena> hi all
[06:51] <mantiena> SteveA, labas
[07:11] <bradb> BjornT: ah, thanks
[07:13] <mantiena> SteveA, alive ?
[07:33] <SteveA> hi mantiena.  i'm in a phone call
[07:58] <SteveA> hi mantiena 
[07:58] <SteveA> i'm about to finish for the day
[07:58] <SteveA> what's up?
[08:15] <kiko> SteveA, ping?
[09:01] <_chaOS_> hello room
[09:02] <_chaOS_> does ubuntu base installation support rpm packages?
[09:02] <_chaOS_> Or what package management program does ubuntu use??
[09:02] <_chaOS_> any one plz?
[09:05] <mdke> _chaOS_: you need #ubuntu
[09:08] <_chaOS_> thank you mdke.
[10:03] <bradb> BjornT: I responded to your review. Do you have time to check it out?
[10:09] <BjornT> bradb: yeah, i might have time to take a look at it soon.
[10:11] <bradb> cool, thanks. /me heads out to pick up a fixed laptop.
[10:16] <mantiena> SteveA, I have few questions about [planned]  rosetta features :)
[10:25] <SteveA> mantiena: you can try the rosetta mailing list
[10:25] <SteveA> then if others have the same questions, everyone can read the discussion and answers
[10:42] <kiko> yay bradb 
[10:42] <kiko> good work
[11:02] <mantiena> SteveA, but I more like talk with you directly ?
[11:04] <mantiena> ;)
[11:04] <mdke> I'd like to see more Klingon translations in Rosetta
[11:05] <mdke> jordi: so, if rosetta now prioritises, do we get to compete to get our templates promoted up the list? Do you take bribes?
[11:06] <jordi> mdke: I do!
[11:06] <jordi> no, I actualyl have a grand plan
[11:06] <jordi> I plan to make a wiki page, with a table awith the full list
[11:06] <jordi> so people can input and we can fine-grain this
[11:06] <mdke> cool
[11:06] <jordi> But, when people do a change, it must be explained in the changelog
[11:07] <mdke> changelog?
[11:07] <jordi> a rationale and so
[11:07] <jordi> in the wiki page changes thingy
[11:07] <mdke> which changelog?
[11:07] <mdke> oh right
[11:08] <jordi> and every now and then we can diff last apply against current and apply the changes to rosetta
[11:36] <mantiena> guys, it's normal when my .po files aren't imported in rosetta more than 24 hours ?
[11:37] <jordi> mantiena: it could be. Which po?
[11:37] <jordi> mantiena: Openoffice is being imported, and that takes long
[11:42] <mantiena> jordi, several *-lt.po files
[11:45] <mantiena> for example replaced-gtk-lt.po and eel-lt.po. I exported several files about 26-27 hours ago, fixed some strings and imported again into rosetta after ~2 hours, but they still aren't imported into rosetta and I didn't get email from rosetta about successful import :(
[11:46] <jordi> https://launchpad.net/rosetta/imports/+index?status=APPROVED&type=po&start=700&batch=75
[11:46] <jordi> they are approved, but behind OpenOffice in the queue
[11:48] <kiko> meaning they will be imported AFTER XMAS!
[11:50] <mantiena> :(((((
[11:50] <lifeless> moining
[12:04] <mantiena> jordi, maybe you know aproximatly how much time openoffice will be imported ? I need to fix some more translations before ubuntu dapper, but langpack translation deadline is May 25 ...
[12:05] <zyga> jordi: interesting issue
[12:09] <jordi> zyga?
[12:09] <jordi> mantiena: takes 2 days or so, according to carlos
[12:10] <jordi> I'm not sure, I can't tell you about the dates, but you maybe safe, langpacks will be updated every now and then
[12:10] <jordi> monthly at least
[12:10] <carlos> mantiena: it has been running for a whole day already
[12:10] <jordi> so even if you miss the dapper debut, they'll appear in the next
[12:10] <carlos> I guess on Saturday, it will be done and all pending entries will be imported
[12:10] <jordi> I also have files around the place :)
[12:10] <mdke> mantiena: if the deadline is 25th, that means that it is passed. However, carlos said in his email today that language packs will be regenerated on sunday
[12:10] <zyga> jordi: 99% vs 100%
[12:10] <jordi> zyga: ah yeah
[12:10] <carlos> mdke: yeah, the deadline was moved
[12:10] <jordi> carlos: saw that bug I filed?
[12:11] <jordi> zyga: I think just using a brighter colour would do
[12:11] <carlos> jordi: which one ?
[12:11] <zyga> jordi: I attached a comment
[12:11] <jordi> but I'm sure there'll be some kind of problem with visually impaired people
[12:11] <zyga> it's a pretty simple solution
[12:11] <zyga> jordi: use stripes
[12:11] <jordi> https://launchpad.net/products/rosetta/+bug/46653
[12:11] <Ubugtu> Malone bug 46653 in rosetta "100% vs 99% translations done for a language team" [Normal,Unconfirmed]  
[12:12] <zyga> 100% is trivially distinguished when it is displayed with stripes :)
[12:12] <zyga> (waves, ubuntu logos or whatever - any non solid color with high constrast pattern will do)
[12:12] <carlos> mantiena: but if you import them now, your import will be done earlier
[12:12] <jordi> that's true
[12:13] <mantiena> carlos, thanks, so, if I do some fixes in lt.po files this morning (after ~7 hours), will these fixes go in sunday's langpacks ?
[12:13] <jordi> mantiena: yeah, keep them coming, they'll be in the line
[12:13] <carlos> I guess, yes
[12:13] <jordi> mantiena: we hope
[12:13] <carlos> mantiena: I don't think OO.org will be still around on Sunday...
[12:14] <mantiena> fine, then I can go sleep now instead of fixing ;)
[12:14] <carlos> mdke, jordi: You should talk with mpt about that bug
[12:14] <jordi> yah
[12:14] <jordi> should I subscribe him?
[12:15] <carlos> mantiena: that's only true if you do it uploading .po files
[12:15] <mdke> me?
[12:15] <jordi> zyga :)
[12:15] <carlos> if you use the translation form, your translations will be there _now_
[12:15] <carlos> jordi: oh... right...
[12:15] <carlos> mdke: sorry ;-)
[12:15] <carlos> It's a bit late here...
[12:16] <jordi> carlos: another feature for the future is, related to that bug I filed, is that stuff submitted by a human goes to the top of the queue by dfefault
[12:16] <jordi> so it can bypass edgy uploads etc
[12:17] <zyga> carlos: is there any plan to add ubuntu icon to templates from packages in the main archive?
[12:17] <carlos> zyga: well... atm Dapper only has packages in main (for translations)
[12:18] <carlos> we didn't import universe
[12:18] <zyga> oh
[12:18] <zyga> I didn't know
[12:18] <carlos> and Edgy will have a feature (or at least we will try to have it in time) to use something like language packs for universe
[12:19] <zyga> hmm :)
[12:19] <zyga> souns familiar
[12:19] <zyga> I had similar ideas about a year ago
[12:19] <carlos> zyga: will you go to Paris ?
[12:19] <zyga> carlos: paris?
[12:19] <zyga> next ubuntu conn is in paris?
[12:19] <carlos> the Ubuntu sprint
[12:20] <carlos> yes
[12:20] <zyga> unlikely :/
[12:20] <zyga> when will it happen BTW?
[12:20] <carlos> next month
[12:20] <zyga> then absolutely not :/
[12:20] <zyga> marriage, house, kid on the way :)
[12:20] <zyga> no time atm
[12:20] <carlos> I guess I will write something about it there
[12:20] <carlos> zyga: congratulations!
[12:21] <zyga> I look forward to that :)
[12:21] <zyga> carlos: I had an idea about per-package non-deb package
[12:21] <zyga> per-deb-package-i18n-package-with-small-footprint
[12:23] <carlos> yeah, the main idea is not use .deb packages
[12:24] <zyga> basically a .mo file would do
[12:24] <zyga> that, coupled with a custom namespace
[12:26] <mantiena> carlos, hehe, but how I can search for some words in translations if using web translation tool ?
[12:27] <carlos> mantiena: no way.. sorry :-(
[12:28] <mantiena> carlos, I have idea - are there a way to see not 10, but for example 100 translations in page during translation ?
[12:28] <kiko> heh. 
[12:28] <mantiena> then I could use simple text search with firefox browser ;)
[12:29] <kiko> carlos, there is a way, right? :)
[12:29] <carlos> yes
[12:29] <carlos> mantiena: use count=100 as an extra argument in the URL
[12:30] <carlos> mantiena: it will change soon, but should work for you at least one more week
[12:30] <carlos> mantiena: something like +translate?count=100
[12:30] <mantiena> carlos, thanks, for me one day will be enough no need for one week ;)
[12:31] <carlos> mantiena: that option will be there, but with another name, that's all
[12:34] <mantiena> hehe, It's working will not sleep for at least 30 min - new fixing with web translation tool is faster, than downloading file from rosetta, fixing and uploading again ;)
[12:34] <kiko> cool. :)
[12:34] <mantiena> carlos, btw, will rosetta have ability to search/replace in web translation more in future ?
[12:35] <carlos> mantiena: yes, we have a high priority functionality that includes a search feature
[12:37] <carlos> kiko: zyga just remembered me another spec I would need to work next month at Ubuntu submit, the one about language packs like feature for universe
[12:40] <kiko> carlos, sounds like you're going to have a busy 3 days :)
[12:40] <carlos> one spec/day
[12:41] <carlos> I need to talk with pitti to schedule sometime before the meeting to talk about the ways to implement this new spec so we have some previous discussion
[12:42] <carlos> but I think he's not around until next Monday, I will call him on Monday
[12:43] <kiko> yeah, I'd do planning up-front definitely
[12:43] <kiko> so you don't waste time there
[12:43] <carlos> right
[12:43] <carlos> good night!
[12:45] <kiko> carlos, still here?
[12:45] <mantiena> mdke, hehe, sometimes find/replace is very good way for fixing translations, sometimes there are typical errors, which can be fixed automatically
[12:46] <carlos> kiko: yes
[12:46] <kiko> carlos, did the rosetta announcement not hit rosetta-users?
[12:46] <mantiena> good night carlos, it was nice to meet you ;)
[12:46] <mdke> mantiena: but words often occur in different context. I agree for spelling errors it might help
[12:46] <kiko> oh, just found it.
[12:46] <kiko> thanks!
[12:47] <carlos> kiko: ;-)
[12:47] <kiko> sorry!
[12:47] <carlos> mantiena: :-P
[12:47] <carlos> see you tomorrow!
[12:48] <mantiena> mdke, I know about context, I use find/replace very rarely, but tonight most my translation fixes can be done by find/replace and then manual review ;)
[01:25] <lifeless> spiv: ping
[02:04] <lifeless> SteveA: ping
[02:27] <Rounin> Hello, I have a question... With regards to the bounty functionality of launchpad, is it possible to change the amount pledged after a bounty is posted? And if so, how is it done?
[02:37] <Rounin> I was just wondering, because I was thinking of creating a bounty for further development of XIM (namely switching of input methods within programs and without the use of env vars + better stability), but it would require a lot more people than me to pledge money
[02:44] <stub> Rounin: Doesn't look like it. The Bounty system is still fairly primative as we have been concentrating on other areas. It currently needs an admin to change the amount for some reason (looks like it was done deliberately but I don't know the rationale)
[02:45] <Rounin> Ah... That's a shame... I guess there needs to be some sort of centralised control to prevent false pledges, but one would need to be able to increase the sum
[02:47] <lifeless> I believe some work is being done on it at the moment, but not sure when that will land
[02:49] <Rounin> I see... THanks, both of you
[03:07] <marcin_ant> I also would like to add that there is currently no way to control bounties and verify if they are closed or not  etc....
[03:24] <spiv> lifeless: pong
[03:30] <mpt__> Gooooooooooooooooooood afternoon Launchpadders!
[03:37] <lifeless> spiv: reviewed your branch
[03:37] <spiv> lifeless: thanks
[03:40] <spiv> lifeless: So, I have a problem with testing other formats than just the repository.  At the moment (i.e. with the current set of formats bzr 0.8 has), if branch format or bzrdir format changes, then the repo format changes anyway, afaict.
[03:41] <spiv> lifeless: which makes constructing a test to exercise the checks tricky.
[03:41] <lifeless> spiv: if/when we bump bzrdir format, I dont expect we'll bump the branch format again, for instance. Nor the repository format.
[03:41] <spiv> (I actually have an comment I forgot to commit and push stating this in the relevant spot in the code :/ )
[03:41] <lifeless> spiv: factor the test into a function identical_formats()
[03:42] <spiv> Right, I'm sure the situation will change in future.
[03:42] <lifeless> then call identical formats with any object that wont match to test the != branch
[03:42] <lifeless> and call with equal objects in each of the three spots to test the == branch of the test
[03:42] <spiv> Just at the moment that testing repository is effectively enough, but clearly not future-proof.
[03:42] <spiv> Hmm, that's a good idea.
[03:43] <spiv> Thanks!
[03:43] <lifeless> I'd rather we had correct and untested code than incorrect and tested, but I think its easy to do correct and tested.
[04:32] <spiv> lifeless: btw, did you see that check_merge is unbuggered?
[04:39] <spiv> lifeless: Hmm, bzrdir.clone looks like it would do too much with e.g. shared repositories to me.
[04:46] <lifeless> spiv: ah yes.
[04:46] <lifeless> spiv: sprout then is the right one
[04:46] <lifeless> spiv: still preserves format
[04:46] <spiv> Ooh, I'll take a look at that.
[04:48] <spiv> lifeless: you mean bzrdir.sprout not branch.sprout?
[04:49] <lifeless> spiv: yes
[04:51] <spiv> I guess I have to pass in the revision_id.  It takes the exact same arguments as clone...
[04:51] <spiv> Anyway, I need to go to lunch.  Back in a while.
[04:51] <mpt_> stub, did you recently fix bug 43983?
[05:23] <stub> mpt_: I think so, yes
[06:22] <mpt_> spiv / jamesh, ping
[06:22] <jamesh> mpt_: yeah?
[06:24] <mpt__> jamesh, I need to revert a series of three revisions to a branch, but they do not include the most recent revision
[06:24] <mpt__> So I've used bzr diff -r to generate the diff of the changes I made that I want to revert
[06:24] <mpt__> I tried using patch -Ru to apply it, but it looks like patch works only for one file
[06:25] <mpt__> and bzr patch doesn't appear to have an "in reverse" option
[06:25] <jamesh> if you want to revert revs 42..45 for instance, "bzr merge -r 45..41 ." might do it
[06:25] <jamesh> "patch -R -p0 < patchfile" would also work if you've got a diff of the changes you want to revert
[06:26] <mpt__> ok, thanks
[06:26] <mpt__> I can't use bzr merge, because my more recent revision is up for review
[06:26] <jamesh> the first option should handle revs that add/delete/move files too
[06:26] <mpt__> whereas I have rs= for the reversion
[06:27] <jamesh> mpt__: the bzr merge command I gave is a self merge
[06:27] <mpt__> I mean, I could use it, but then I wouldn't be able to submit to PQM, because that would still include the more recent revision that hasn't been reviewed yet
[06:27] <mpt__> so I need to apply the diff in reverse to a fresh branch
[06:39] <mpt> jamesh, sorry to bother you again, but how do I push a new standalone knit branch to chinstrap?
[06:40] <mpt> "bzr push --remember --overwrite sftp://chinstrap.warthogs.hbd.com/home/warthogs/archives/mpt/launchpad/2006-05-bug-reporting-form/" returns "bzr: ERROR: No repository present"
[06:40] <mpt> and I'm not using a repository
[06:40] <jamesh> mpt: what was in that location before you ran push?
[06:41] <mpt> jamesh, a copy of /home/warthogs/archives/rocketfuel/launchpad/devel (to minimize rsyncing time)
[06:41] <jamesh> mpt: okay.  /home/warthogs/archives/rocketfuel/launchpad/devel is actually a branch inside a repository
[06:41] <jamesh> the repo being at /home/warthogs/archives/rocketfuel/launchpad
[06:42] <mpt> oh
[06:42] <jamesh> so when you copied it, you missed the repo information
[06:42] <mpt> So is there any fast way to push a standalone branch, or do I just have to upload the whole thing?
[06:42] <jamesh> you could try copying one of your existing knit format branches
[06:43] <jamesh> that should give similar speed to taking a copy of rocketfuel
[06:43] <mpt> ok, ta
[06:46] <jamesh> if you had a shared repo on chinstrap, you'd be getting the speed benefits for initial pushes
[06:46] <jamesh> even if you keep with standalone branches locally
[07:03] <spiv> mpt: don't "cp" the branch from rocketfuel, "bzr branch" it.
[07:07] <mpt> spiv, would that be why PQM just told me "Sender not authorised to commit to branch sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel/"?
[07:07] <spiv> mpt: no, that's because PQM doesn't like the trailing /
[07:08] <mpt> so, my new-branch script should contain
[07:09] <mpt> ssh chinstrap bzr branch /home/warthogs/archives/rocketfuel/launchpad/devel /home/warthogs/archives/mpt/launchpad/$1
[07:09] <spiv> Looks sane.
[07:10] <mpt> and bzr branch gets me out of repository-land
[07:27] <mpt> grrr
[07:28] <mpt> spiv, after using the bzr branch method, and re-pushing, I got the same error from PQM
[07:28] <spiv> mpt: how are you generating the PQM request?
[07:29] <spiv> mpt: the request needs ask to merge to "sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel", with no trailing slash.
[07:30] <mpt> I haven't changed this script in ages
[07:30] <mpt> except for changing .bzr/parent to .bzr/branch/parent
[07:30] <mpt> echo star-merge ${MYURL} $(cat .bzr/branch/parent) | gnome-gpg --clearsign | mail -s "$1" "$2"
[07:30] <mpt> hmmmm
[07:31] <mpt> ah, so parent has a slash in it and shouldn't
[07:32] <spiv> Yeah.  I guess you could replace "$(cat .bzr/branch/parent)" with "$(cat .bzr/branch/parent | sed -e s=/$==)"
[07:33] <spiv> But it'd be nice if the branches in rocketfuel had their parents set to something that PQM accepted...
[07:34] <mpt> I'm using cp -a from my copy of rocketfuel to create new branches
[07:34] <mpt> so I need to write in the .bzr/branch/parent manually
[07:35] <mpt> and I'll put that in the script without a trailing slash
[07:36] <mpt> then it should work :-)
[09:13] <jamesh> spiv: did you manage to get the pqm-submit plugin working?
[09:13] <spiv> jamesh: Haven't tried yet...
[09:33] <SteveA> lifeless: hello
[09:45] <carlos> morning
[09:45] <sivang> morning
[09:57] <spiv> SteveA: you wanted a conference call at about this time?
[09:57] <SteveA> yep
[09:57] <SteveA> jamesh, stub: around?
[09:57] <jamesh> yeah
[09:57] <stub> yup
[09:58] <SteveA> stub: what's your internet connection like?
[09:58] <stub> Fine
[09:58] <SteveA> is it fat?
[09:59] <SteveA> i'm thinking that as you're geographically in the middle, it might work better for you to be the conference convener on skype
[09:59] <fabbione> SteveA: if you need i have spare bw
[10:00] <SteveA> thanks fabbione.  not sure how we'd use it though
[10:00] <fabbione> SteveA: no problem
[10:00] <SteveA> what a shame you can't send bandwidth as an email attachment
[10:00] <fabbione> ehehe
[10:00] <stub> SteveA: Geographically maybe, but I suspect I'm going via Europe or the US to get to AU
[10:01] <SteveA> can you do an mtr to see?
[10:01] <stub> So how do I setup a skype conference call?
[10:01] <spiv> I see a "Tools -> Create conference" option.
[10:01] <SteveA> everyone must be running skype
[10:01] <SteveA> then select all their names
[10:01] <SteveA> then right click or something to create hte conference
[10:01] <SteveA> or do what spiv said
[10:03] <stub> Thailands international bandwidth isn't great, but then again neither is Lithuania's I guess
[10:03] <SteveA> using asterisk in the DC would be better
[10:03] <jamesh> I take it that that's not an option yet?
[10:04] <stub> Yay - workiing without killing esd
[10:05] <stub> jamesh, spiv: I don't have your skype numbers
[10:05] <spiv> stub: "spivvo"
[10:05] <jamesh> stub: jamesh-42
[10:06] <SteveA> everyone should run the echo test first too
[10:06] <jordi> hiya
[10:06] <SteveA> call echo123
[10:06] <stub> Have you changed your number steve? Your icon says you are offline
[10:06] <stub> Oops... green now
[10:07] <spiv> echo test fine here.
[10:09] <stub> Everyone here except da Steve
[10:09] <SteveA> my wired headset is broken
[10:09] <SteveA> i need to get the BT one going...
[10:10] <spiv> SteveA: we'll just talk about you behind your back then ;)
[10:15] <stub> Bored now!
[10:18] <stub> SteveA: Should I courier you a headset over?
[10:18] <SteveA> yes please
[10:21] <SteveA> yay, works
[10:21] <SteveA> how do i join the conference now?
[10:22] <jamesh> did you just kill the conference?
[10:22] <SteveA> now i need to restart skype...
[10:22] <stub> Nope - you dropped
[10:22] <spiv> jamesh: I'm still here.
[10:22] <SteveA> cos it got confused about the sound device
[10:22] <stub> You killed James! You bastard!
[10:25] <fabbione> what's going on with LP???
[10:25] <fabbione> i keep getting 502 Proxy Error
[10:26] <spiv> fabbione: stub's looking at it now...
[10:27] <SteveA> Znarl: pingping
[10:28] <Znarl> SteveA : Pong?
[10:28] <SteveA> hi.  so, it seems that all 4 launchpad app servers have failed
[10:28] <SteveA> probably
[10:28] <SteveA> plan is to kick the ones on gangotri in the arse
[10:28] <SteveA> but leave the other 2 dead for diagnosis
[10:28] <SteveA> that requires some pound config
[10:29] <SteveA> and stu says that needs you to do it
[10:29] <Znarl> SteveA : Understand.
[10:30] <Znarl> same for XMLRPC too?
[10:30] <seb128> hi
[10:30] <seb128> is launchpad known to be broken? ("Proxy Error")?
[10:30] <spiv> seb128: yep, fabbione reported it 5 min ago, we're looking atm
[10:30] <seb128> ok, thank you
[10:31] <SteveA> Znarl: yes please
[10:31] <Znarl> Done.
[10:41] <stub> SteveA: I've diagnosed the problem. The good news is that my planned session updates should fix it. The bad news is I write crappy code in the first place.
[10:42] <stub> SteveA: And you have dropped from the conference again
[10:42] <SteveA> hi
[10:42] <SteveA> yeah, skype dropped
[10:42] <SteveA> but launchpad is still not really working
[10:43] <SteveA> yay launchpad working
[10:44] <stub> SteveA: Sorry - I didn't realize that was an international number and hung up
[10:50] <seb128> grraa
[10:50] <seb128> "OperationalError
[10:50] <seb128> A server error occurred."
[10:50] <seb128> and there is no "previous page" possible
[10:51] <seb128> ah, it applied the change anyway, good
[10:52] <SteveA> are things okay now seb128 ?
[10:53] <seb128> yep, works again, thank you
[10:53] <seb128> and my change got applied when it displayed that OperationalError
[10:53] <SteveA> stub: "blahblahblah welcome to callback service"
[10:53] <seb128> weird but nicer than having to do the change again ;)
[10:53] <stub> SteveA: I'm trying to have a conference call!
[10:54] <SteveA> actually, let me extemporize on #c-m while i call karl
[11:02] <Znarl> gangotri : Launchpad Apps Server [1/2]  down.
[11:03] <Znarl> Oh, ignore that.  Just went clear.
[11:09] <seb128> I get OperationalError pages again
[11:17] <mdke> no worky!
[11:17] <lifeless> SteveA: hi
[11:19] <seb128> k, not point to try working with it, /me goes for some coffee
[11:29] <imbrandon> someone working on the site atm ?
[11:31] <imbrandon> looks like OperationsError every few page loads , and css not loading sometimes ...... etc , i have screen shots and others in #kubuntu-devel experincing same issues
[11:31] <imbrandon> just wondering if someone was aware of the issue
[11:31] <mantiena> Hi all
[11:32] <imbrandon> 'ello
[11:33] <lucasvo> imbrandon: yes they are
[11:34] <imbrandon> ok cool, just wanted to make sure SOMEONE was aware of it ;)
[11:34] <lucasvo> stub: are you still working on fixing LP?
[11:44] <stub> lucasvo: It was fixed last we looked...
[11:44] <lifeless> stub: could it be an out of date appserver?
[11:45] <stub> No code updates for the last few days that I'm aware of
[11:45] <SteveA> maybe a stuck app server with broken db connections
[11:46] <stub> I only have 18 database connections from the appservers and there should be (4*4*2)
[11:46] <stub> 32
[11:47] <stub> Maybe me killing connections and Steve bouncing was done out of sync
[11:47] <lucasvo> stub: atm, the toolbar isn't working
[11:49] <lucasvo> ok, now it's down
[11:50] <stub> Its up again - gangotri restarted cleanly for sure.
[11:50] <SteveA> looks good from here
[11:51] <stub> Znarl, SteveA: Is gandwana being load balanced to at the moment?
[11:51] <stub> I'm going to bounce the launchpads there - nothing more to diagnose as far as I can see (?)
[11:51] <Znarl> No.  gandwana Apps servers are down.  They're removed from pound.
[11:53] <stub> Znarl: You can put gandwana back in the pool now. I've bounced them cleanly and the only reason to leave them out is to slow things down.
[11:54] <Znarl> stub : Done and done for XMLRPC too.
[12:32] <sabdfl> do we measure and report on downtime for LP?
[12:32] <Znarl> sabdfl : Yes, within nagios monitoring system downtime is measured.
[12:33] <`6og> hi all. i have been looking around but haven't found any reference to launchads `xmlrpc` interface. is that open (ie in an ubuntu package) or still closed?
[12:39] <SteveA> kgoetz: we're experimenting with some xmlrpc interfaces, but we haven't released any as a supported service in launchpad yet
[12:40] <kgoetz> SteveA: thanks, i was just curious after seeing some comment referring to it. thanks for that :)
[12:40] <mdke> can anyone merge teams?
[12:41] <SteveA> mdke: interesting question.  stub, what do you think?
[12:41] <mdke> SteveA: it would be nice to get bug #29177 fixed
[12:41] <Ubugtu> Malone bug 29177 in launchpad "Allow merging of teams (and specifically merge ubuntu-doc and ubuntu-doc-lists)" [Major,Confirmed]  http://launchpad.net/bugs/29177
[12:41] <stub> I'm not sure if the admin screen lets us do it. Technically, there would be nothing wrong with using the existing people merge code to merge teams.
[12:42] <SteveA> stub: would it merge team membership records too?
[12:42] <mantiena> SteveA, labas
[12:42] <SteveA> sveikas mantiena
[12:42] <stub> SteveA: That would be why it isn't enabled. It would need to be a little smarter.
[12:43] <SteveA> mantiena: actually, i have no idea how to say that in lithuanian properly.  you have a female irc nick
[12:43] <mantiena> SteveA, ;)
[12:43] <SteveA> sveika mantiena :-p
[12:44] <mdke> SteveA: for that particular bug team membership records don't matter, ubuntu-doc-lists was just created when bugs were imported from bugzilla, we don't need it
[12:44] <mantiena> SteveA, you also have a female nick, if looking from Lithuanian side ;)
[12:44] <SteveA> it's just a poorly spelled vocative: styvai
[12:46] <mantiena> so, styvai, could you tell me, if we (Lithuanian GNOME/KDE translation teams) could use rosetta as main translation/colaboration tool for translating upstream (not ubuntu's) KDE/GNOME ?
[12:47] <SteveA> i don't see why not.  the main issue is if you have someone who will regularly take the upstream translations from rosetta, and put them whereever gnome and kde store them.
[12:48] <SteveA> if you don't do that, then we get problems of duplicated work upstream and in rosetta
[12:48] <SteveA> so the connection has to be regularly made
[12:48] <SteveA> jordi can give you more detailed advice
[12:49] <SteveA> i think KDE is more of a challenge
[12:49] <SteveA> but i think we deal with KDE-style translations now
[12:49] <mdke> mantiena: you only need to do it in one direction: rosetta -> cvs/svn
[12:49] <mdke> if everyone works in rosetta, and one person is in charge of doing that move, it will work, assuming rosetta has the infrastructure
[12:50] <SteveA> right now, translating ubuntu gets the translations out to the widest audience, because we're just coming up to a release
[12:50] <mantiena> mdke, why ? there are no GNOME 2.16 translations in rosetta now
[12:50] <mdke> mantiena: right, as I said, "assuming rosetta has the infrastructure"
[12:50] <mantiena> mdke, ;)
[12:50] <SteveA> mantiena: are you on the rosetta-users mailing list?
[12:50] <mdke> working at the same time in gnome cvs and in rosetta would be really difficult
[12:51] <mdke> nay, impossible
[12:51] <SteveA> that's a good place for a discussion of these issues, as it lets jordi and carlos contribute even if the discussion happens at a time when they're not on irc
[12:51] <mantiena> SteveA, no, I didn't have free time for mailing list :(
[12:51] <SteveA> it has quite low traffic
[12:51] <SteveA> but otherwise, try and catch up with jordi or carlos here
[12:52] <jordi> heeella
[12:52] <mantiena> mdke, we don't want to work on translations in gnome cvs if there are the posibillity to use rosetta as main translation/colaboration tool for upstream GNOME/KDE translations
[12:52] <mantiena> SteveA, thanks
[12:52] <mantiena> jordi, sorry for disturbing ;)
[12:53] <carlos> mantiena: hi
[12:53] <mdke> mantiena: yeah. that would work well, if rosetta can set up the infrastructure for translating all the gnome/kde modules on an upstream basis, and ensuring that it is done on a specific language basis
[12:53] <jordi> so, we currently have no setup to merge GNOME upstream (cvs) to rosetta and let "GNOME translation teams" do this via rosetta
[12:53] <carlos> mdke: we can do it
[12:53] <jordi> but carlos does have plans to do this in the future. I don't know how hard would that be
[12:53] <carlos> mdke: the missing bits is the sync path from GNOME to launchpad
[12:53] <mantiena> hi carlos, my translations were accepted this morning, it seems launchpad is faster, than you think ;)
[12:53] <mdke> carlos: you'd envisage teams committing to both?
[12:53] <carlos> it should be done automatically and it's 100% doable, the upload to GNOME's CVS should be done by translators
[12:54] <carlos> mantiena: ;-)
[12:54] <jordi> mantiena: ther'es a number of features planned but not yet there which would help: ie, allowing to translate both on Ubuntu's GNOME and upstream's at the same time, and making the export to upstream's svn/bzr repos easy
[12:54] <carlos> mdke: to cvs and Rosetta?
[12:54] <mdke> yeah
[12:55] <carlos> mdke: yes, it should work too, perhaps we should do small changes to improve that use case
[12:55] <jordi> mdke: per language would be easy as the GNOME Translators group exists.
[12:55] <carlos> but it's doable
[12:55] <jordi> We just need to have the GNOME translations imported into the relevant products.
[12:56] <carlos> right
[12:56] <carlos> zyga did some work on that task
[12:57] <mdke> jordi: but you have to make sure languages that don't use rosetta are totally closed
[12:57] <carlos> but I still need to get some time to expend on it to be integrated into launchpad
[12:57] <mdke> otherwise people will start making suggestions
[12:57] <carlos> mdke: we have that already done
[12:57] <mdke> oh, nice
[12:57] <jordi> mdke: yes, translation permissions are closed, of course
[12:57] <mantiena> jordi, carlos: I think our (Lithuanian GNOME translations) case would be easier, because we could use only launchpad/rosetta for translating, so from GNOME CVS we should get only newly appeared (untranslated) and fuzzy strings in .po files, also new .pot files, we don't need to merge translated strings :)
[12:57] <carlos> mdke: we have OPEN, CLOSE and STRUCTURED modes
[12:57] <carlos> mdke: Ubuntu uses STRUCTURED, GNOME would use CLOSE
[12:57] <mdke> right
[12:58] <mdke> i would say that working contemporaneously in gnome cvs and in rosetta, would be really difficult. Better if a team works in rosetta, then one member commits to cvs to get the translations in the tarballs
[12:58] <mdke> and new translations aren't added to cvs unless they come from rosetta
[12:58] <carlos> mantiena: I guess you will upload your translations into GNOME's CVS from Rosetta, right?
[12:59] <mantiena> carlos, yes, I think this would be best decision
[12:59] <carlos> mdke: that's a team choice, we cannot force that
[12:59] <carlos> mantiena: yeah
[12:59] <mdke> carlos: ah. well, you'll have fun synching from upstream then ;p
[12:59] <jordi> mdke: the teams problem
[01:00] <jordi> we would only allow GNOME teams if it's the same peopple as the official GTP teams, I hope
[01:00] <jordi> carlos can correct me, but this is my idea
[01:00] <carlos> mdke: we do it already for Ubuntu
[01:00] <mdke> well, if you want to give them the possibility of uploading non-rosetta translations to cvs, you'll need to have robust synching from cvs
[01:00] <mantiena> carlos, but main problem with rosetta now is, that rosetta don't gets unstable GNOME .po/pot's from GNOME CVS automatically
[01:00] <mdke> carlos: true
[01:00] <carlos> jordi: right
[01:00] <jordi> if not, it'll be a disaster for sure
[01:00] <carlos> jordi: the gnome coordinator will be the one allowed to add more people to the launchpad team
[01:01] <jordi> ok, so: the Spanish team doesn't want to use rosetta? No GNOME will be translated to Spanish in rosetta, only via CVS
[01:01] <carlos> mantiena: yeah, we have some code developed for that, but nothing finished yet
[01:01] <carlos> jordi: right
[01:01] <carlos> we will have it imported anyway
[01:01] <jordi> the LT team wants to use Rosetta? They will do via rosetta, and if someone uploads a lt file to cvs outside the rosetta sutff, it'll be their problem
[01:01] <carlos> but no one will be able to translate into it
[01:01] <mantiena> carlos, are there any plans, when this could be finished ?
[01:01] <carlos> jordi: well, we will import that file from cvs anyway
[01:02] <jordi> right
[01:02] <mdke> jordi: as long as it gets synched
[01:02] <carlos> mantiena: no dates set
[01:02] <jordi> mdke: we would take it from cvs in the next pull of course
[01:02] <carlos> mantiena: but I think it starts being high priority
[01:02] <jordi> but that's a problem of messy teams
[01:03] <mantiena> jordi, Now there is only one person, who can upload translations to GNOME CVS - Lithuanian GNOME translations project leader ;)
[01:03] <carlos> mantiena: I think I will get some extra help with Rosetta development soon, that will allow us to plan this feature better and give a date for it
[01:03] <mdke> spiv: do you know if there is any infrastructure for controlling moin acls by reference to a LP team?
[01:26] <SteveA> mdke: there isn't, but i'd like to add such sometime.
[01:32] <mdke> SteveA: the acl thing? It would be a very nice feature. We could use it on so many wikis :)
[01:32] <mdke> SteveA: please lemme know if there is a spec I can watch
[01:33] <SteveA> not on the radar for a while i'm afraid
[01:33] <mdke> ok
[01:33] <mdke> maybe some kind of "mass upgrade to moin 1.5" would come higher up ;)
[01:51] <jordi> woot
[01:52] <jordi> major deadline over her at lliurex
[01:57] <carlos> jordi: congratulations
[01:58] <jordi> carlos: do you know why adept has more priority than gnome-panel or kdebase?
[01:59] <jordi> does that make sense at all?
[01:59] <jordi> carlos: yeah, things will be easier at work now
[01:59] <carlos> jordi: mark set it that way
[01:59] <carlos> jordi: I guess gnome-panel and kdebase should have higher priority
[02:02] <jordi> yes
[02:02] <jordi> I'm going thrtough
[02:35] <sabdf1> carlos: https://launchpad.net/bugs/46730
[02:35] <Ubugtu> Malone bug 46730 in ubuntu-artwork "The ubuntu-artwork translation template is not installed" [Normal,Unconfirmed]  
[02:35] <sabdf1> any idea?
[02:36] <carlos> sabdf1 I think we don't support it as part of the language packs
[02:36] <carlos> sabdf1:  the package needs to be rebuilt with the .po files from rosetta
[02:37] <carlos> sabdf1: those translations are integrated inside an XML file on build time and are not using gettext at all
[02:39] <carlos> bug updated
[02:39] <sabdf1> ok
[02:39] <looksaus> in which channel should I bug you good ubuntu people about dapper bugs? #ubuntu+1
[02:39] <looksaus> ?
[02:40] <looksaus> I reported a showstopper bug in firefox on ppc about six weeks ago and might not have made enough noise around it
[02:41] <lifeless> #ubuntu-bugs
[02:41] <looksaus> ok, thx
[02:57] <salgado> great. one more 30-mergepeople.txt failure. :-(
[02:59] <kiko> SteveA, it is still there. :-/
[03:20] <kiko> bradb, 30-mergepeople or something?
[03:21] <bradb> no. eight others.
[03:22] <bradb> it's nice they're listed at the bottom of the email though. no more ctrl-f'ing the email required.
[03:22] <matsubara> bradb: is there any failure on soyuz/26-queue-pages.txt ?
[03:23] <bradb> matsubara: nope, it's all goot.
[03:25] <kiko> bradb, they are? 
[03:26] <bradb> Tests with failures:
[03:26] <bradb>    /home/pqm/arch/queue/workdir/home/---devel/launchpad/lib/canonical/launchpad/doc/bug.txt
[03:26] <bradb>    /home/pqm/arch/queue/workdir/home/---devel/launchpad/lib/canonical/launchpad/doc/bugzilla-import.txt
[03:26] <bradb> ...
[03:28] <kiko> sounds like they are all your fault. :)
[03:28] <bradb> yep
[03:33] <spiv> mdke: the team membership info gets passed to moin, but currently moin just discards that information.  It would be interesting, and probably not too hard, to hook that up to Moin's ACL stuff, but I haven't looked at the ACL code at all.
[03:36] <Kinnison> spiv: has thom contacted you about the brokenness of dapper's sqlobject?
[03:36] <spiv> Kinnison: I have a ping from him from three hours ago, but I only just got back to my keyboard to pong...
[03:37] <mdke> spiv: that would be _so_ cool
[03:37] <Kinnison> spiv: aah
[03:37] <spiv> Kinnison: he says he's figured it out
[03:38] <carlos> see you later
[03:39] <Kinnison> spiv: cool
[03:41] <sivang> spiv: oh, nice, then we could have certain pages that belong to certain team, and only approved team members could edit those?
[03:41] <spiv> sivang: Right.
[03:43] <kiko> matsubara, can you file an RT request for bug 42125? otherwise we can run her from async.
[03:43] <Ubugtu> Malone bug 42125 in dilys "Dilys should be run from one of the Canonical servers" [Normal,Unconfirmed]  http://launchpad.net/bugs/42125
[03:44] <matsubara> kiko: ok, I'll do that.
[03:46] <kiko> salgado, can you pull in mpt's branch?
[03:46] <kiko> I'll be happy to review it
[03:47] <salgado> kiko, I tried to merge rocketfuel into my branch first, but got 4 spurious conflicts
[03:47] <kiko> try star-merge. :)
[03:49] <mdke> sivang: well, you can do that now, just not with launchpad groups
[03:50] <sivang> mdke: you mean through moin's current ACL mechanism ?
[03:53] <mdke> sivang: quite
[03:53] <Yannig> Hello :)
[03:54] <sivang> hey Yannig 
[03:54] <Yannig> Do you know if there are problems with the upload queue? I uploaded about 10 po files yesterday and no news from them :(
[03:54] <sivang> carlos: ^^
[03:56] <kiko> Yannig, we were importing OOO yesterday which is known to take time to process
[03:56] <kiko> I'm not sure
[03:56] <Yannig> OK :)
[03:56] <Yannig> But we are still supposed to be notified when our file is uploaded, right? Just have to wait then :)
[03:58] <kiko> yep
[03:58] <kiko> Yannig, you can check /rosetta/imports
[03:59] <Yannig> Yes but there are so many files and I don't know how to find mines :D
[03:59] <kiko> hmmm
[03:59] <kiko> there's a search feature now but it isn't in production yet
[04:00] <Yannig> Don't worry, I can wait :)
[04:01] <Yannig> I'm the only one on my language, not so difficult to agree with myself not to translate the files to be uploaded :)
[04:01] <salgado> cprov, carlos, any of you guys using mawson now?
[04:01] <cprov> salgado: yes, I am 
[04:02] <salgado> cprov, do you depend on the running launchpad or just the database? (I'm wondering if I could kill and restart it using a more recent branch)
[04:04] <cprov> salgado: I depend on librarian
[04:04] <salgado> I see
[04:04] <cprov> salgado: wait some minutes until the current publisher run finish
[04:05] <cprov> salgado:  I'll start my own librarian and you can use the UI (w/o starting librarian, tweak the lp.conf)
[04:06] <salgado> cprov, cool, thanks.
[04:06] <salgado> but even so, I think I need to wait for carlos. he has a script running there
[04:07] <cprov> salgado: he doens't use lp_dogfood, he uses staging or prod, don't know
[04:07] <cprov> salgado: you only depend on me
[04:16] <peza> hi all, i'd like to log a bug in dapper - just a typo in the example content files. Is launchpad the place to do this (very small) bug?
[04:18] <mdke> peza: yes
[04:19] <peza> mdke, cheers
[04:33] <sivang> oh, joy, my branch is already mirroed at bazaar.lp.net , last time I checked it wasn't so
[04:43] <carlos> salgado: hi, my script uses asuka so don't worry about it
[04:43] <carlos> kiko: do we?
[04:44] <kiko> carlos, guess not, but we're supposed to move it to production soon
[04:52] <aa_> does the mirroring facility ever work?
[04:53] <spiv> aa_: it doesn't yet support knit branches, but will next week if that's what you're wondering.
[04:54] <aa_> oh I see, yes, I think all my branches are knit
[04:54] <spiv> Yeah, sorry about that :(
[04:54] <aa_> not at all :)
[04:54] <aa_> just wondering
[04:54] <spiv> But it'll be fixed with the next rollout.
[04:54] <aa_> one of my users read it to mean "the branch is not available from the supermirror"
[05:34] <cprov> salgado: you can restart dogfood UI, just don't rename the 'current' neither starts a new librarian
[06:00] <salgado> cprov, cool. thank you!
[06:16] <kiko-fud> hello hello
[06:46] <salgado> so, if I send an email to nnn@bugs.launchpad.net containing only commands, should the commands show up as comments on that bug?
[06:47] <bradb> BjornT: ping
[06:52] <bradb> salgado: I believe so, but BjornT would have to confirm.
[06:55] <BjornT> salgado: yeah, that's right. you can send a mail to edit@bugs in order to edit a bug without adding a comment (indicating the bug with ' bug 42').
[06:55] <Ubugtu> Malone bug 42 in malone "Bug description listed in task is not the correct description" [Normal,Fix released]  http://launchpad.net/bugs/42
[06:55] <BjornT> bradb: pong
[06:56] <bradb> BjornT: I'm getting this error from bugnotification-sending.txt:
[06:56] <bradb> ...
[06:56] <bradb> ProgrammingError: ERROR:  permission denied for relation packagebugcontact
[06:56] <bradb> ...
[06:57] <bradb> My guess is that something in this test is being run as a different database user, and is now tripping up on the implicit sub lookups.
[06:57] <bradb> BjornT: Does that sound like the problem?
[06:58] <salgado> BjornT, ahh, good to know that. thanks!
[06:58] <BjornT> bradb: exactly. you need to give the 'bugnotification' user SELECT permissions on the packagebugcontact table in database/schema/security.cfg
[07:00] <cprov> salgado: are you going to start the dogfood UI soon or not ? 
[07:03] <salgado> cprov, simply changing "launch yes" to "launch no" on dogfood's launchpad.conf should prevent a librarian to be started, right?
[07:06] <bradb> BjornT: that worked, thanks!
[07:07] <cprov> salgado: right
[07:10] <salgado> cprov, running, and without librarian. :)
[07:20] <cprov> salgado: good, thank you 
[07:24] <salgado> kiko, yay!! https://dogfood.ubuntu.com/distros/ubuntu/+mirror/crap/
[07:24] <kiko> k-rad!!
[07:24] <kiko> awesome!
[07:25] <kiko> salgado, I'm not going to comment that the releases are not ordered <wink>
[07:25] <kiko> salgado, why didn't we just use the strings to index into DistroRelease, btw?
[07:25] <kiko> flavors aren't in our DB, but the releases are
[07:25] <salgado> don't worry, it's still time to fix all you want
[07:25] <kiko> yeah, true
[07:26] <kiko> that'd be ideal
[07:26] <salgado> pqm is not willing to merge this branch anyway
[07:26] <kiko> lol
[07:27] <salgado> anyway, there's another pqm failure I need to deal with first
[07:45] <salgado> kiko, I didn't understand your question about using strings to index into DistroRelease
[07:52] <kiko> salgado, okay. 
[07:52] <kiko> well
[07:52] <kiko> answer me first:
[07:52] <kiko> is it possible to order that page by the distribution release release date?
[07:53] <salgado> not easily, but yes, it is
[07:54] <kiko> why not easily?
[07:54] <salgado> not so easily
[07:55] <salgado> I was right
[07:55] <salgado> not easily
[07:58] <salgado> it'll either require some python: usage on templates, or a class to store the rows of the table temporarily
[07:59] <salgado> it's easy, actually
[08:00] <kiko> that's better.
[08:00] <kiko> show me the diff!
[08:01] <salgado> I'd love if there was a better way of handling lists of lits using TAL
[08:01] <salgado> and lists of lists too
[08:01] <kiko> yeah lists of lits are not so bad
[08:02] <kiko> lists of lists are really annoying thoughh
[08:36] <salgado> kiko, https://chinstrap.ubuntu.com/~dsilvers/paste/fileAvh0Dp.html
[08:37] <kiko> salgado, what a hack. I think we should change the DB schema instead.
[08:38] <kiko> instead of constructing on the fly
[08:38] <kiko> are you radically opposed to that?
[08:38] <salgado> at this point, yes
[08:38] <kiko> but the DB patch hasn't even landed yet
[08:39] <salgado> this change is going to be anything but trivial
[08:39] <kiko> well, let's think about it.
[08:39] <kiko> the /only/ differences I can see are:
[08:39] <kiko> - when adding content rows you look up the distro release by name
[08:39] <kiko> - when displaying them you display release/name
[08:40] <kiko> - the DB schema has a different column
[08:40] <kiko> what else is complicated, salgado?
[08:40] <salgado> I didn't understand your suggestion
[08:40] <kiko> I'll hop up.
[08:55] <salgado> kiko, there's no datecreated on distrorelease. :/
[08:56] <sigurdga> sorry if I am not the first one to say, but is launchpad.net having problems?
[09:01] <Kinnison> s'being a touch broken right now no?
[09:01] <salgado> sigurdga, it seems to be down
[09:01] <sigurdga> ok
[09:01] <seb128> re
[09:02] <seb128> is launchpad known to be broken atm? :)
[09:02] <SteveA> yes
[09:02] <seb128> k
[09:02] <kiko> salgado, IT SUCKS. it's a bug
[09:02] <Kinnison> :-)
[09:03] <SteveA> stu will be around in 10 mins
[09:03] <SteveA> meanwhile, i'm going to do what i can
[09:04] <salgado> kiko, https://dogfood.ubuntu.com/distros/ubuntu/+mirror/crap/
[09:05] <salgado> kiko, warty and hoary ids are swapped. :)
[09:06] <salgado> IOW, you just sandbagged my by asking this damn feature. we can't reliably sort distroreleases in order of release
[09:07] <kiko> @#!@!#$
[09:07] <SteveA> launchpad appears to be alive again
[09:08] <sigurdga> thanks!
[09:18] <bradb> salgado: why can't you use datereleased?
[09:26] <salgado> bradb, because it's None for non-released 
[09:29] <bradb> I'd imagine as much. :) I just wondered if a datecreated would be of much practical use for sorting anyway. More important seems to be knowing when a distrorelease was put into a certain state, but maybe not.
[10:08] <salgado> we have distrorelease.version, obviously. :)
[10:26] <kiko> salgado, yeah. do you know how to order them? use apt_pkg
[10:26] <salgado> apt_pkg? they use sourcerer.deb.version.Version() in other places
[10:28] <kiko> hmmm
[10:28] <kiko> maybe it's safe for distorelease versions
[03:33] <sigurdga> Anyone knowing if or how I as an administrator of a translator team can accept a suggested translation?
[03:35] <mdke> sigurdga: you copy and paste it
[03:36] <sigurdga> i will not copy and paste 1000 single string translations, if that is what you meant
[03:36] <mdke> sigurdga: I don't mind
[03:36] <mdke> I'm just saying, that is how you can do it
[03:37] <sigurdga> ... there must be another way, so that I can accept the whole translation of the package
[03:37] <mdke> fraid not.
[03:37] <mdke> but that might have advantages: you might be tempted to approve translations without reading them
[03:37] <mdke> this way, you don't have that problem
[03:38] <sigurdga> yes, i know
[03:39] <sigurdga> our problem, that I am up to fight, is that until now, we are accepting all new members, and by that allowing the translation of ubuntu to be really crappy
[03:40] <mdke> sigurdga: yeah, that's a very common problem, unfortunately. Recently lots of translation teams have been tightening up in order to avoid that
[03:40] <sigurdga> I _could_ maybe have clicked in 601 checkboxes for this particular translation, but copy paste is too much work...
[03:41] <sigurdga> And I think it is useless to discard some of the newest translations
[03:41] <mdke> but you have to read them, right? so copy/paste isn't much extra time over that
[03:42] <mdke> well, it is, but it's not _too_ bad
[03:43] <mdke> ok... so you have stopped accepting new members now?
[03:43] <mdke> or you have removed people?
[03:43] <sigurdga> I have to do both
[03:43] <sigurdga> and I do not like it
[03:44] <mdke> why not?
[03:44] <sigurdga> but going over retranslating is frustrating
[03:44] <mdke> they get upset?
[03:45] <mdke> if you remove a team member, you shouldn't lose their translations that they did before they were removed...
[03:45] <sigurdga> I am in the process of tidying up right now, they have not had the time to get upset yet...
[03:45] <sigurdga> I knwo
[03:46] <sigurdga> I wish I could comment on the users translations in general (I can by sending a mail) and get them to correct their errors themselves
[03:47] <mdke> so you are reviewing the existing translations?
[03:47] <sigurdga> I do not want do be a schoolteacher doing almost the same amount of work as doing it myself
[03:47] <sigurdga> yes, from the latest days
[03:48] <mdke> I'm not quite sure what your technical problem is. Are you reviewing suggestions for translations which are empty, or existing translations from old team members? 
[03:48] <sigurdga> the activiti kind of exploded, in contrast to the usual lazyness
[03:48] <sigurdga> I am trying to (reactively) fight our problem of crappy translations done by helpful users...
[03:49] <mdke> yeah, I understand the general aim
[03:49] <sigurdga> ... some are old users which I have do deactivate, and clean up after
[03:49] <mdke> but not the specific technical problem that you have
[03:50] <sigurdga> ... and some new that translated some hundered strings before I woke up
[03:50] <mdke> ok. and the last bit is your technical problem with Rosetta?
[03:51] <sigurdga> ... and only half of the translated packages (by the same user) are of high quality
[03:52] <mdke> yeah, it sounds like a big job
[03:52] <mdke> wow, 70 team members
[03:53] <sigurdga> it is seems to be too much work (for something that could be done easyly) to have to cut and paste every string on 60 pages for one package
[03:53] <sigurdga> yes, and I think about 20 of the 70 needs guiding before translating too much
[03:54] <mdke> sigurdga: well, there is no better way, I'm afraid, as I explained. Even if there was a better way (like a checkbox), it sounds like you would have a massive job anyway, reading all the translations
[03:54] <mdke> but I'm sure that you will have help
[03:54] <sigurdga> is it usual to test the members with grammar test before they get approved?
[03:55] <sigurdga> yes, I am afraid so
[03:55] <mdke> sigurdga: my personal view is that it is useful to read people's suggestions before approving them, and ensure they comply with the gnome and other upstream translation project guidelines
[03:55] <sigurdga> I think we will get the wannabes to download the po-files and send them to a mailinglist for reviews
[03:56] <mdke> in fact, I wrote a blog post about that.
[03:56] <sigurdga> that would be easy to fix and upload for us admins too
[03:56] <mdke> http://www.mdke.org/blog/Ubuntu_Translation___Quality_Assurance.html
[03:56] <mdke> yeah, that sounds like a very good idea
[03:56] <mdke> looks like you have some guidelines already :) http://www.ubuntu.no/oversettelse
[03:56] <sigurdga> I read some of your thoughts on rosetta users just now
[03:57] <mdke> ah
[03:57] <sigurdga> some sort of, yes (I was a co-writer of the old guildelines)
[03:58] <mdke> actually, I can't see anything on the page having clicked on it
[03:58] <sigurdga> I did connect the name to your nick, though
[03:58] <mdke> it's moved I guess
[03:59] <sigurdga> The link is url is case sensitive, there should have been a uppercase O
[03:59] <sigurdga> Oversettelse
[04:00] <mdke> ah
[04:00] <sigurdga> The page does not say much useful about quality, I am working on a new version
[04:00] <mdke> looks like a good start
[04:01] <mdke> sigurdga: well good luck, I'm going to sleep. Catch you on ubuntu-translators some time hopefully!
[04:01] <sigurdga> yes, and by your help, I have come a bit longer, thanks
[09:31] <robitaille> it seems LP is totally  unresponsive right now.  Server problems?
[09:42] <neutrinomass_> Launchpad is down... I guess you know this though. Just making sure ....
[09:43] <dooglus> do you know that launchpad.net isn't working at the moment?
[09:44] <neutrinomass_> dooglus: Probably, I said so just before you came. They're probably working on it ....
[09:44] <Lathiat> i take it from that comment LP isnt broken just for me? :)
[09:44] <robitaille> Lathiat:  nah, you're not special :)
[09:45] <Lathiat> aww :(
[09:45] <robitaille> sorry to disapoint you
[09:45] <Lathiat> i had my hopes
[09:45] <dooglus> Lathiat: don't believe then.  you are very special.
[09:45] <Lathiat> :)
[09:46] <dooglus> you are a beautiful and unique snowflake.
[09:47] <robitaille> but don't forget your sunscreen when you go outside
[09:47] <dooglus> :)
[09:57] <mvo> is it known problem that I get "Proxy Error" when connecting?
[09:58] <neutrinomass_> mvo: Yes, everybody is having it ...
[10:39] <infinity> Are the proxy errors at https://launchpad.net/ known and being resolved?
[10:42] <dsas> infinity: They've been mentioned by many, not saw any launchpad devs ack though.
[10:51] <lucasvo> LP should be more redundant :)
[10:52] <Yannig> Hello everybody :)
[10:52] <Yannig> I guess you already know about the website being down?
[10:53] <lucasvo> yes
[10:53] <lucasvo> one should put it into the topic
[11:07] <seaLne> sorry to probably be the millionth person to ask but is there any idea when launchpad will be working again?
[11:11] <ploum> seaLne: fill a bug
[11:27] <seb128> hi
[11:28] <seb128> is launchpad known to be broken (again)?
[11:30] <ploum> seb128: fill a bug
[11:30] <ploum> (shame... twice the same joke)
[11:30] <seaLne> :)
[11:30] <ploum> I couldn't resist
[11:30] <seb128> ploum: oh wait, I'll get that back during the SoC, we will see who will laugh then :p
[11:30] <Yannig> ploum> Why don't you script a bot for answering this? ;)
[11:32] <ploum> ok ok you won...
[11:32] <seb128> :)
[11:32] <Yannig> Snirf, I cannot see if Occitan translations ran below 99 % undone :p
[11:33] <ploum> yesterday night, I had error with launchpad, I had to refresh each page several times before having the content instead of the error
[11:33] <seb128> ploum: yeah, I complained several time yesterday
[11:34] <seb128> bradb, kiko-afk: ping
[11:35] <Micksa> WHY IS LAUNCHPAD BROKEN YOU ALL SUCK RAGRHGR
[11:35] <Micksa> heh, you know what'd be funnny
[11:36] <Micksa> if this channel turned out to be for a completely different topic with the same name
[11:42] <aa_> the supermirror is up thank-goodness
[11:50] <lifeless> Micksa: dude, not helpful
[11:50] <lifeless> Micksa: what specifically is wrong
[11:52] <seb128> "Proxy Error
[11:52] <seb128> The proxy server received an invalid response from an upstream server.
[11:52] <seb128> The proxy server could not handle the request GET /bugs/46866.
[11:52] <seb128> Reason: Error reading from remote server"
[11:52] <seb128> lifeless: it does that on any bug I try to open
[11:53] <seb128> and it seems to do that for everybody, I got pinged about it on different chans about it already
[11:55] <ploum> even / doesn't reply
[11:55] <seaLne> yeah proxies don't seem to be able to talk to the zope servers
[11:58] <seaLne> but then i imagine you'd know way more about that than me
[11:58] <lifeless> seb128: huh ? proxies work fine. but the service might be down, checking.
[11:58] <seaLne> lifeless: try any page
[11:58] <seb128> lifeless: that's just the page I get, dunno about what's going on
[11:59] <seb128> lifeless: did you try to open a page?
[12:00] <lifeless> seb128: am investigating
[12:01] <seb128> thank you
[12:02] <lifeless> seb128: I think we need a sysadmin to check pount
[12:03] <seb128> lifeless: right, could you ping one please?
[12:03] <seb128> it's saturday, I'm not sure of who we should bother about that :)
[12:03] <seaLne> the problem seems to have been happening for about 3 hours if that helps
[12:03] <lifeless> seb128: I'm going to try an appserver bounce first
[12:06] <Micksa> lifeless: sorry, I thought it was already known :)
[12:13] <lifeless> ok
[12:13] <lifeless> back up 
[12:13] <lifeless> seb128: ^^ Micksa ^^ seaLne ^^
[12:14] <seaLne> cool
[12:14] <seaLne> thanks
[12:14] <seb128> lifeless: works fine now, thank you
[12:14] <seb128> lifeless: what was the issue?
[12:15] <lifeless> deadlock of some sort
[12:15] <lifeless> maybe related to rosetta 
[12:15] <lifeless> or maybe to some session machinery issues we have
[12:16] <ploum> thanks for making it available again :-)
[12:48] <hugelmopf> any rosetta people here? scribus translations (german) are 0% in rosetta for dapper, while it is completely translated upstream (at least the versions i tried). does that mean, these translations will be missing for dapper? can you add them?
[12:52] <aa_> nice one guys, thank-you very much
[12:53] <aa_> (we all love launchpad and appreciate everything you do)
[01:37] <Yannig> Do someone know the name of the package where I can find the day names that are shown the GNOME clock/calendar?
[01:37] <mdke> Yannig: I think it is gnome-panel
[01:37] <mdke> not 100% sure though
[01:37] <Yannig> Thanks :)
[02:02] <Yannig> Back luck, it's not in gnome-panel-2.0
[02:02] <Yannig> Bad luck :p
[02:04] <seb128> it's a GTK widget so it probably comes from GTK itself
[02:05] <seb128> hum, apparently not
[02:05] <seb128> maybe it's asked to the glib directly
[02:09] <Yannig> Let's have a look :)
[02:10] <Yannig> I don't think: I haven't translated anything from glib
[02:10] <hugelmopf> can anybody answer my question about scribus translations?
[02:11] <Yannig> hugelmopf> I'm unable to, soryr ;(
[02:11] <seb128> Yannig: what is your issue with it?
[02:12] <Yannig> seb128> I mistranslated one day name and forgot the others ones and I think it could be interesting to have them all translated :)
[02:12] <seb128> ah
[02:14] <Yannig> Maybe gnome-applets...
[02:15] <seb128> no
[02:15] <seb128> what locale do you use?
[02:15] <Yannig> oc
[02:15] <seb128> are you sure you translated those labels using rosetta?
[02:16] <Yannig> No
[02:16] <Yannig> But I'm the only translator on this language on Ubuntu and I don't see where else it could have been translated
[02:17] <seb128> from upstream?
[02:17] <Yannig> upstream = po imported?
[02:17] <seb128> yep
[02:18] <Yannig> Maybe
[02:18] <Yannig> But don't the uploaded po also update the only translations?
[02:21] <seb128> ?
[02:22] <seb128> Yannig: is your locale "oc_FR"?
[02:22] <Yannig> Yep
[02:22] <seb128> Yannig: I think the names come from /usr/share/i18n/locales/oc_FR
[02:22] <seb128> "abday   "<U0064><U0069><U006D>";"<U006C><U0075><U006E>";/
[02:22] <seb128>         "<U006D><U0061><U0072>";"<U006D><U0065><U0063>";/
[02:22] <seb128>         "<U006A><U00F3><U0075>";"<U0076><U0065><U006E>";/
[02:22] <seb128>         "<U0073><U0061><U0062>""
[02:22] <seb128> 
[02:22] <seb128> those are the char number
[02:22] <seb128> like 64 is d
[02:22] <seb128> 69 = i
[02:22] <seb128> 6D = m
[02:22] <seb128> dim
[02:23] <seb128> 6c 75 6e = lun
[02:23] <seb128> etc
[02:23] <Yannig> Hum, easy :)
[02:23] <seb128> those are the french abreviations and correct
[02:23] <seb128> dunno if oc is supposed to have different names for them
[02:23] <Yannig> Yes
[02:24] <seb128> those datas are not language-packable I think
[02:24] <kiko-afk> lifeless, bummer, second time this has happened
[02:24] <seb128> the best you can do is to open a bug on locales with a patch probably 
[02:24] <seb128> so it get forwarded upstream and changed with next upload
[02:25] <Yannig> What is strange is that it seems that it was changed
[02:26] <seb128> what do you mean?
[02:26] <Yannig> dim => dimenge / lun => diluns / mar => dimars / mec => dimcres, etc.
[02:26] <Yannig> jc for dijus, sab for disabte
[02:26] <seb128> hum
[02:27] <seb128> that's not changed
[02:27] <Yannig> I don't know how but it's neither French nor English or Spanish abbreviations
[02:27] <lifeless> kiko-afk: yup
[02:27] <seb128> atm it uses lun mar mer jeu ven sam dim
[02:27] <seb128> ie: standard french
[02:27] <Yannig> No, it's not the same as French
[02:28] <kiko-afk> lifeless, it happened yesterday evening (my time)
[02:28] <Yannig> I have lun mar mec ju ven sab dim
[02:28] <Yannig> I have lun mar mec ju ven sab dim
[02:28] <kiko-afk> lifeless, from the amount of Retry exceptions it may very well be related to the session machinery
[02:30] <seb128> Yannig: ah, right, I just looked quickly ... may people don't agree of the abreviations for it? or maybe the guy who made the previous list did errors on it
[02:31] <Yannig> I began the translation for Occitan Ubuntu, there are very very very very few other contribuations
[02:32] <seb128> Yannig: it's not likely you wrote /usr/share/i18n/locales/oc_FR if you didn't know about it
[02:32] <seb128> Yannig: that's something coming from the glibc itself and not available on launchpad
[02:32] <seb128> Yannig: that's the locale definition, not a translation
[02:33] <Yannig> So impossible to translate for people who wish to install Ubuntu in Occitan :$
[02:33] <seb128> not impossible to translate
[02:34] <seb128> you just have to get the source package patched
[02:34] <lifeless> kiko-afk: was rosetta running the last time ?
[02:34] <kiko-afk> lifeless, I'm not sure, I wasn't on -- but SteveA did the restart
[02:34] <lifeless> SteveA: was rosetta-imports running during the last hang ?
[02:34] <SteveA> the rosetta import script was running each time
[02:35] <SteveA> however, because of the db user involved, stub strongly suspects the session machinery
[02:35] <Yannig> seb128> Don't know how to do :p
[02:36] <seb128> Yannig: basically modify /usr/share/i18n/locales/oc_FR to use the correct lettres for your abbreviations and open a bug on locales with your changes described
[02:37] <Yannig> Great :p
[02:37] <lifeless> SteveA: we should try killing the rosetta script as a first step next time
[02:37] <SteveA> well...
[02:37] <SteveA> that's a pisser
[02:38] <SteveA> because it is kind of critical
[02:38] <lifeless> SteveA: indeed. If killing it unwedges things, we will have isolated it. 
[02:38] <lifeless> SteveA: if it does not, then at least we've eliminated it
[02:39] <Yannig> Thanks for trying seb128 but I think I'll see that much later (despite the importance) :$
[02:39] <seb128> Yannig: np
[02:40] <SteveA> lifeless: i'd like an opinion from carlos before we do such a thing
[02:42] <lifeless> SteveA: please get one then :)
[02:43] <lifeless> SteveA: I think its important we eliminate variables.
[02:47] <SteveA> carlos says it is fine to kill it
[02:49] <SteveA> kiko-afk: 3rd time
[02:49] <kiko-afk> sucks
[02:51] <SteveA> kiko-afk: i mailed allhands.  robert and i are carrying a notional pager for the next few days
[02:52] <kiko-afk> mmmm. okay. I should request access to the server via RT so I can help as well
[02:54] <SteveA> you need access with launchpad user to gandwana and gangotri for that
[03:58] <dc0de> gotta say, easyubuntu ROCKS!
[04:33] <carlos> hi
[04:36] <dc0de> good morning...
[04:41] <phanatic> hi people
[04:41] <dc0de> good morning
[04:42] <phanatic> i try to create a bzr branch on lp, but it fails
[04:43] <phanatic> ssh: connect to host launchpad.net port 22: Connection timed out
[04:43] <phanatic> i use the command:
[04:43] <phanatic> bzr push --create-prefix sftp://phanatic@launchpad.net/~phanatic/olive/main
[04:43] <phanatic> what could be the problem?
[04:43] <olive> ^^
[04:43] <pygi> lol, olive :)
[04:43] <phanatic> (using latest bzr dapper package)
[04:44] <phanatic> olive: :)
[04:45] <phanatic> the funny thing is that pygi succeeded with the same command...
[04:46] <pygi> replacing "phanatic" with "pygi" ofcourse
[04:48] <phanatic> http://paste.ubuntu-nl.org/14733
[04:50] <phanatic> maybe paramiko is causing the error?
[04:56] <phanatic> after removing paramiko, it worked
[07:13] <glatzor> Hi, some time ago we had a problem that the German translation of kde were not imported in Rosetta. The same issue happened also with koffice but hasn't been noticed until now.
[07:14] <glatzor> Since there are no string changes by Ubuntu in koffice I would like to upload the current translations from the kde l10n de team.
[07:15] <glatzor> I have to do this as user upload, since I want to overwrite all Rosetta translations?
[07:22] <mdke> glatzor: yeah, i think so
[08:01] <shenki> hello. I'm getting a 502 error when trying to get to launchpad, is it down?
[08:04] <shenki> is anyone about?
[08:12] <jordi> damn
[08:12] <jordi> shenki: yeah, I'll try to see if anyone that can fix this is around
[08:13] <shenki> jordi: thanks
[08:14] <jordi> They are working on it, I hope it'll be fixed in the next minutes
[08:15] <shenki> cool. thankyou
[08:26] <slux> &det
[09:22] <glatzor> hi, I have got an urgent question about the translations of kde.
[09:23] <glatzor> the koffice files templates are in koffice, but the translations are part of the koffice-i18n package
[10:41] <Seveas> well, there are no 502 errors anymore, there's simply nothing 
[10:41] <pygi> Seveas, eh
[10:45] <Seveas> ah, there's the 502 error 
[10:50] <pygi> why doing that weird  char all the time? :-/
[10:51] <mdke> launchpad seems to be working here
[10:52] <pygi> mdke, here as well
[11:24] <SteveA> 2 out of four app servers are stuck
[11:29] <SteveA> they're all back now
[11:30] <pygi> SteveA, nice, what happened? :-/
[11:30] <SteveA> we're having a problem with launchpad servers getting into a deadlock situation with database connections
[11:31] <SteveA> we're looking into what's going on, but meanwhile, launchpad is locking up occassionally
[11:31] <SteveA> and requires administrative intervention to get it unstuck
[11:36] <pygi> ah :-/
[11:43] <lifeless> morning
[11:44] <pygi> hey lifeless 
[11:44] <lifeless> SteveA: I have some social committments today that may make it hard to reboot stuff if needed.
[11:44] <lifeless> elmo: what TZ are you running on at the moment ?
[11:45] <SteveA> lifeless: i'm going to be taking a guest out to see a castle tomorrow morning.  i'm planning to bring laptop + gprs with me, just in case
[11:45] <lifeless> SteveA: yah. I'll have the laptop, but I dont have gprs
[11:46] <lifeless> I will be able to run into starbucks or something for most of the time, except for the movie
[11:46] <SteveA> well... it's a sunday.  we'll do what we can.
[11:46] <SteveA> seeing as you're around already, i'm going to head off to sleep
[11:48] <lifeless> gnight
[11:48] <SteveA> i just mailed some pretty useless analysis in reply to carlos' observation
[11:48] <SteveA> we need to look at the apache / pound logs to really see what pages are producing hangs
[11:48] <SteveA> or gdb into the hung process
[11:49] <lifeless> I will do that the next hang that occurs, and also get the pg activity
[11:49] <lifeless> the next time it hangs, please also grab the pg activity : 
[11:49] <ozamosi> Ok, everyone: GO AWAY! Stop stealing launchpads bandwith!
[11:50] <ozamosi> ...or CPU-time or whatever it is that's lacking..
[11:50] <SteveA> it's not lacking anything
[11:50] <SteveA> it's getting deadlocked
[11:50] <lifeless> SteveA: do you know how to grab the pg activity ?
[11:50] <SteveA> in what sense?
[11:51] <SteveA> in the database end, no idea
[11:51] <lifeless> I'll msg you, one second
[11:51] <SteveA> we can easily stick some code into the database adapter to spool it out to a file
[11:51] <SteveA> and flush on every statement
[11:51] <SteveA> do a per app server log file
[11:51] <SteveA> then tail it when it is hung
[11:52] <SteveA> what would be more useful is to send the app server some kind of signal, and get it to dump out the OOPS log for each app thread
[11:53] <SteveA> including the time since the thread started
[11:53] <lifeless> I agree - automation of error stat gather would me useful
[11:54] <lifeless> meh, missing privileges, sow we wont get full data when you grab the stats.
[11:55] <SteveA> yeah
[11:55] <lifeless> however, it will give us a hint, which is better than nothing
[11:55] <SteveA> lifeless: is it a holiday on monday down under?
[11:55] <lifeless> nope
[11:55] <SteveA> ok
[11:55] <SteveA> it is in the UK, apparently
[11:56] <SteveA> anyway, i think jamesh would be able to figure out a way to send a singnal of some kind to an app server
[11:56] <SteveA> and get it to dump out the OOPS log state of each app thread
[11:56] <lifeless> as long as python isn't borked, sending a signal is really quite easy
[11:57] <SteveA> the OOPS report stuff is stored in a thread.local
[11:57] <SteveA> so there would need to be a way of enumerating the app threads
[11:57] <SteveA> or enumerating the thread.locals used for this purpose
[11:57] <lifeless> well
[11:57] <lifeless> we could put those in a global as we create them
[11:58] <SteveA> indeed
[11:58] <SteveA> worthwhile diagnostic hack, i reckon
[11:58] <lifeless> then walk the dict, key is threadid, value is the report stuff
[12:00] <SteveA> lifeless: if you see jamesh around, would you mention this to him please
[12:04] <lifeless> SteveA: sure. I'll send a mail now as well
[12:04] <SteveA> ta