[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:<IP_ADDRESS>ubuntu1-3 |      1 |         3
[07:01] <Keybuk>  1:<IP_ADDRESS>ubuntu1-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:<IP_ADDRESS>ubuntu1-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:<IP_ADDRESS>ubuntu1-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<EMAIL_ADDRESS>[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://<IP_ADDRESS>: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<EMAIL_ADDRESS>[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<EMAIL_ADDRESS>[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<EMAIL_ADDRESS>[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