[12:45] <jordi> hannosch: oi
[12:45] <hannosch> jordi: hi
[12:46] <hannosch> jordi: I still have a duplicate pot in here: https://launchpad.net/products/plonesoftwarecenter/+translations :(
[12:47] <jordi> bleh
[12:47] <jordi> I'll nag people again :/
[12:48] <hannosch> The import was f**ked up somehow, but carlos couldn't fix it, so I added all entries manually to the right pot
[12:56] <ddaa> lifeless: will it be possible to run baz2bzr on bzr checkouts in importd?
[12:57] <ddaa> possible as in "technically feasible" and "a new enough bzrlib will be there"
[12:57] <jordi> hannosch: yeah, I fsckd when I imported to the wrong product
[12:57] <jordi> doh
[12:58] <hannosch> jordi: no problem as long as it is fixed sometime :)
[01:05] <jordi> hannosch: hopefully :)
[01:07] <hannosch> jordi: Could you point me to the current documentation for Rosetta? I'll guess I have to write some myself to explain how-to use Rosetta for my existing translators. So I would like to point them to some existing docs, or write some new if there's lacking some.
[01:09] <ddaa> lifeless: ping, want to talk about you about potential need for special handling of "not quite atomic" behaviour of bzr commit compared to baz commit.
[01:09] <jordi> hannosch: basically, what there is is the FAQ. When I have time (heh) I will write a manual under at least two points of view: upstream maintainer and translator
[01:09] <ddaa> unping for the checkout thing, it's not going to help anyway
[01:09] <jordi> hannosch: mail me, and lets coordinate about writing sometihng
[01:10] <hannosch> jordi: will do, there is a new alpha release of Plone up this weekend, so I'll probably mail you next week ;)
[01:11] <jordi> ok :)
[01:14] <lifeless> ddaa: what not quite atomic behaviour ?
[01:15] <ddaa> commit, push, etc. works roughly like that: 1. add texts in the store 2. add revision entry in store 3. add revision to inventory 4. update head
[01:16] <lifeless> roughly. you have the order wrong but close.
[01:16] <ddaa> please correct me, I wish to learn
[01:16] <lifeless> add texts
[01:16] <lifeless> add inventory
[01:16] <lifeless> add revision
[01:16] <lifeless> update branch head
[01:16] <lifeless> update working tree last revision
[01:17] <lifeless> unlock everything
[01:17] <ddaa> maybe I'm confused, but what happens if the commit is killed after adding the inventory. You get an inventory that references a revision that's not here... right?
[01:18] <lifeless> inventories do not reference revisions
[01:18] <ddaa> mh?
[01:18] <lifeless> inventories reference fileid:revisionid pairs
[01:19] <lifeless> revisions reference inventories
[01:19] <lifeless> in the near future that will change to revisions reference fileid:revisionid pairs too - for the root node, and that root node will be the inventory
[01:20] <ddaa> okay, I'm completely confuddled now... some internals documentation would be great...
[01:20] <ddaa> nevermind
[01:21] <ddaa> also, ids "update branch head" and "update working tree last revision" the same thing for a self-contained tree?
[01:21] <ddaa> (that's relevant to the issue at hand)
[01:22] <lifeless> the reference order is Revision owns an inventory owns file texts
[01:22] <lifeless> EPARSE on 'ids "update branch head" and "update working tree last revision" the same thing for a self-contained tree'
[01:23] <ddaa> s/ids/is/
[01:23] <lifeless> no, its not the same thing for a standalone branch
[01:23] <lifeless> it is the same thing for a format 6 bzrdir
[01:24] <lifeless> meta-format 1, available for use from 0.8 makes it different
[01:24] <ddaa> that opens a new sort of confusing race on commit...
[01:24] <lifeless> theres no race. There is a power-fail consistency issue
[01:25] <lifeless> but we can journal that if we care to
[01:25] <ddaa> if the commit is killed after updating the branch head and before updating the tree revision, you get an out of date tree that you need to revert and pull to unbreak... revert is totally not what you want to try in such a situation...
[01:25] <lifeless> no
[01:26] <lifeless> 'bzr update' will correct it and should never have issues as 3 way merge will see one side unchanged
[01:26] <ddaa> okay, I will ask SteveA for alloted time to keep up with the bzr mailing list. I cannot work at my best in this situation :(
[01:26] <ddaa> right... update...
[01:27] <lifeless> also note that to kill commit there you will need to  be very very fast off the mark, as its literally 2 disk operations apart
[01:27] <ddaa> shit happens, in importd especially
[01:27] <lifeless> and finally as I say, we can journal this: we can say 'pending commit $revid' in a file
[01:27] <lifeless> and write that after everything is locked, before the branch head is updated.
[01:28] <ddaa> can do it, and actually doing it is something different :)
[01:28] <ddaa> Thanks for the explanations. So the issue I wanted to talk about is:
[01:28] <lifeless> and when we start up if there are stale tree locks we can look for that and if the revid is in the branch just do it
[01:29] <ddaa> ATM there are no stale tree locks. That would probably make things easier in the short term for importd if there are.
[01:29] <lifeless> thats also a 0.8 feature
[01:30] <ddaa> The general idea, is that commit puts a bunch of stuff in the store, that's not actually used until the branch head is updated. Usually, that's not a problem, the following commit will create stuff with different ids.
[01:30] <ddaa> It creates some junk data, but it's usually not a big deal.
[01:30] <ddaa> The issue I have, is how that pans out with baz2bzr in importd.
[01:31] <lifeless> I dont see an issue. run baz2bzr after the mirror step in the current process
[01:31] <lifeless> the data is consistent then with what is committed - arch gives you the same data each time.
[01:31] <ddaa> Yeah, then what if baz2bzr is interrupted?
[01:31] <lifeless> then run it again
[01:31] <ddaa> For one thing, we use fixed revision ids, so I'm concerned that maybe the subsequent commit is going to cry conflict.
[01:32] <lifeless> its designed for this. I'm not sure what your concern is
[01:32] <ddaa> I'm not sure anymore either.
[01:32] <lifeless> are you saying 'will baz2bzr work'
[01:32] <ddaa> I think I should stop working on this stuff for today.
[01:32] <lifeless> or are you saying 'I have tested it and it breaks'
[01:32] <lifeless> if the latter - tell me and aaron as its a bug
[01:33] <lifeless> if the former, treat it like a black box mmkmary
[01:33] <ddaa> I'm asking will it work with sufficient shit-proofness for importd.
[01:33] <lifeless> it should
[01:34] <lifeless> it does not have specific tests, but I can't think of any expected fallout except in a very narrow range of circumstances. baz2bzr actually does its work semi atomically anyway with a temporary directory.
[01:35] <lifeless> and the worst case situation is redoing a single branch over, which while not ideal does not seem hugely problematic to me given the plan
[01:35] <ddaa> Initially, I was concerned about putting junk data in importd branches.
[01:36] <ddaa> but as you said, it's not going to happen, because of predictable ids and data.
[01:36] <ddaa> okay, I'm satisfied that there's no problem there :)
[01:37] <ddaa> just exercising stone-turning skills to look for potential trouble.
[01:37] <ddaa> lifeless: thank you
[01:37] <lifeless> np
[01:43] <spiv> lifeless: Still no buildbot love.
[01:43] <spiv> "No module named testresources", same as before I think.
[01:45] <lifeless> spiv: damn damn damn
[02:38] <ddaa> Wow, were you guys aware of that? http://developer.yahoo.net/yui/
[02:50] <jamesh_> ddaa: the calendar widget looks good for date entry
[02:51] <ddaa> I'm looking at the patterns now
[02:51] <jamesh> e.g. http://developer.yahoo.net/yui/calendar/examples/default_2up/index.html
[02:52] <ddaa> lovely
[02:55] <ddaa> The menu portlet probably benefit from a treeview too, to hide the more rarely used items.
[02:57] <ddaa> wow, rgb color picker! http://developer.yahoo.net/yui/slider/examples/slider.html
[02:57] <ddaa> not terribly useful, but soooooo sexy
[02:59] <Lathiat> that yui stuff seems to be doing the rounds today
[02:59] <Lathiat> is it a new launch?
[02:59] <ddaa> dunno, a relative of mine sent me a pointer...
[02:59] <ddaa> I guess he read about it on some blog.
[02:59] <Lathiat> pff, that calendar widget doesnt work in konqueror :)
[02:59] <Lathiat> ddaa: friend of mine did the same :)
[03:00] <ddaa> Lathiat: then fix it! It's BSD licensed!
[03:00] <Lathiat> i wouldnt have the slightest about javascript :)
[03:01] <ddaa> Love it when companies get free software thing so right. BSD is just the right kind of license.
[03:02] <Lathiat> personally, i hate licensing :)
[03:02] <Lathiat> its too much effort to think about
[03:03] <ddaa> It's like breathing.
[03:03] <ddaa> you don't have to like it, you have no choice
[03:05] <Lathiat> indeed
[03:13] <ulinskie> hey anybody can help me with this
[03:13] <ulinskie> ttps://launchpad.net/malone/bugs/3987
[03:13] <ulinskie> ulinskie    - Changed attachments:
[03:13] <ulinskie> ulinskie        Added: Patch to remove password field from UserPreferences
[03:13] <ulinskie> ulinskie           http://librarian.launchpad.net/1569015/mo
[03:15] <ddaa> what's your problem?
[03:15] <ulinskie> I can't edit out my wiki page and change the theme..
[03:16] <ulinskie> coz everytime I change something..it says password did not match even if I gave already the correct password
[03:16] <spiv> ulinskie: don't enter your password in the form.
[03:16] <spiv> That should work around the issue.
[03:17] <ulinskie> ok
[03:17] <ulinskie> will do
[03:17] <ddaa> ulinskie: the patch needs to be applied on the server
[03:17] <ulinskie> I'll tyr again
[03:22] <ulinskie> spiv, thanks
[03:22] <ulinskie> spiv, it already worked
[03:22] <ulinskie> spiv, god bless u
[03:23] <spiv> ulinskie: you're welcome :)
[03:23] <jsgotangco> bless me too!
[03:25] <ulinskie> jsgotangco, god bless u too... although I know God had been showering you a lot this past year hehehehe
[04:10] <stub> WTF  does py.test think it is special and makes be jump through svn installation hoops and PYTHONPATH munging to use it?
[04:19] <jamesh> stub: to install the python2.4-pylib package, I needed to delete the syntax_error.py file and rerun "apt-get install python2.4-pylib"
[04:20] <jamesh> stub: and then edit /usr/bin/py.test2.4 and change "from _findpy import py" to "import py"
[04:22] <lifeless> spiv: buildbot bombs away
[04:30] <spiv> lifeless: A new error, in your mail.
[04:47] <stub> Ta. py.test works. Now I discover it sucks. I just want a traceback, not a damn essay!
[04:53] <lifeless> stub: whats using py.text? sqlobject ?
[04:53] <stub> Yup
[04:53] <lifeless> how do you find it ?
[04:54] <lifeless> is it as crufty as it looks ?
[04:54] <stub> From the sqlobject.org web site
[04:54] <lifeless> nono, I know where the code is
[04:54] <lifeless> I meant whats your user experience
[04:54] <stub> Although I gave up on the SVN installation (they don't release distutils) and used Universe
[04:55] <stub> Installation is a major negative. You just have to use distutils until something better comes along - not make your developers jump through pointless (to the developer) hoops.
[04:55] <lifeless> Ran 1355 tests in 144.843s
[04:55] <lifeless> bzr test suite is slowly growing
[04:55] <stub> Output is way too verbose to be useful. The exploded tracebacks are not helpful to me and I can't turn them off
[04:56] <stub> (ie. my tracebacks are spread over several screens intertwined with the source code)
[04:56] <lifeless> are tests objects? can you manipulate (report/decorate/inject dependencies) them ?
[04:56] <jamesh> stub: there is a --verbose flag if you want more output
[04:56] <lifeless> jamesh: he wants --without-verbose
[04:57] <stub> It does seem to find and run tests however
[04:57] <jamesh> lifeless: tests are functions or methods with names beginning with test_*, containing assert statements
[04:57] <stub> No idea if it supports doctests
[04:57] <jamesh> it seems to do some interpreter tricks to provide useful error messages for "assert x == y"
[04:58] <lifeless> jamesh: IIRC running py.test tests with -O disables all the tests
[04:58] <lifeless> jamesh: which seems freakily whack to me
[04:58] <stub> Options like '--nomagic' are not helpful and indicate deeper problems to me
[04:58] <stub> Running with -O is freakily whack
[04:59] <lifeless> stub: I have serious doubts about py.tests goals, to me they seem to want to make testing les useful rather than easier to use. They dont claim that, its just my observation
[04:59] <lifeless> of the net outcome
[05:00] <stub> Indeed. Here I am wondering if I can be arsed making sure my altered SQLObject tests pass.
[05:00] <stub> (although part of that is that the tests were not passing to begin with)
[05:04] <jamesh> lifeless: I suppose that running "py.test -O" is an optimisation then
[05:06] <lifeless> jamesh: indeed
[05:13] <stub> Yay for useless py.test output! https://chinstrap.ubuntu.com/~dsilvers/paste/fileBK6vBc.html
[05:15] <stub> Module imports fine from the command line, yet the output says 'failed to load'. And the traceback is mainly from the test machinery and suddenly jumping to the line that raised the exception with no context!
[05:18] <lifeless> go libpy
[05:23] <jamesh> stub: maybe you'll get a different answer if you tell it to use less magic
[05:24] <stub> Nup.
[05:25] <lifeless> jamesh: whats the public url for your new gpgme wrapper ?
[05:25] <spiv> stub: --tb short
[05:26] <spiv> stub: But yeah, the defaults are annoying.
[05:26] <stub> There is no --tb in my version
[05:27] <spiv> stub: Ah, I'm looking at SVN.
[05:27] <stub> Yay for 'just pull it from SVN' and a release mechanism for creating obsolete packages
[05:27] <spiv> (And the SVN version doesn't work properly with SQLObject anyway...)
[06:18] <Alinux> someone in states ?
[06:19] <Alinux> http://l10n-status.gnome.org/gnome-2.14/ka/index.html I would like to download all files from this place ? is it possible?
[06:19] <Alinux> or how can I donwload all po files from here?
[06:26] <spiv> lifeless: Want to do a quick review of a fix for standalone page tests? https://chinstrap.ubuntu.com/~dsilvers/paste/fileKYQh2d.html
[06:26] <spiv> lifeless: Your one-liner wasn't sufficient.
[07:11] <stub> spiv: Ok for me to merge in my SQLObject branch?
[07:12] <spiv> stub: Yep.
[07:12] <spiv> (I thought my mail said so?)
[07:12] <spiv> stub: Btw, I was surprised you wrote tests, given what a PITA the SQLObject test suite is :)
[07:13] <spiv> I'm certainly not complaining, though...
[07:20] <stub> Gah! Now my testing is showing the boolean indexes are being used for '=true' lookups but not 'is true' lookups, which is the opposite to what my tests with partial indexes showed :-|
[07:31] <lifeless> spiv: oh right, *thats* the local fix I have for zope
[07:31] <lifeless> spiv: I've forgotten what it was :)
[07:31] <spiv> lifeless: Heh.
[07:31] <spiv> lifeless: Well, I don't mind fixing zope if you prefer.
[07:31] <lifeless> this is easier, given we still have z3.2 incoming
[07:32] <spiv> lifeless: Right now though I'm off to yoga :)
[07:32] <lifeless> wont that break the tests I wrote ?
[07:32] <lifeless> or do I fudge on checking the id ?
[07:32] <lifeless> anyway looks good
[07:32] <lifeless> r=lifeless
[07:32] <spiv> I didn't run your tests... I just checked that test.py did what I expected :)
[07:32] <spiv> Ok, thanks, I'll double-check and merge after dinner.
[07:32] <lifeless> ./test.py lib test_test_pages
[07:55] <SteveA> hi
[07:55] <SteveA> mpt: how's the network today?
[07:56] <mpt> SteveA: I'm using the pretend-to-be-the-Mac trick, and it's working so far
[07:57] <mpt> My current trouble is remembering how to rebuild sourcecode/ for my 2006-01-build-pages/ branch
[07:57] <mpt> or how to update it, rather
[07:58] <mpt> File "/home/mpt/hacking/lp/2006-01-build-pages/lib/canonical/lp/__init__.py", line 69, in registerTypes
[07:58] <mpt>     psycopgda.adapter.registerTypes(psycopgda.adapter.PG_ENCODING)
[07:58] <mpt> TypeError: registerTypes() takes no arguments (1 given)
[07:58] <mpt> because of the psycopgda update
[07:58] <mpt> which I had to merge in because there was one other conflict in the branch.
[07:59] <mpt> kiko told me how to do it before but I don't seem to have the log
[07:59] <mpt> it was something to do with link-source-code.sh ...
[08:01] <stub> mpt: Update your sourcecode/psycopgda as per mailing list instructions
[08:02] <stub> cd sourcecode/psycopgda; bzr pull
[08:02] <SteveA> jblack: around?
[08:02] <stub> mpt: cm.py can be used to update trees too
[08:04] <mpt> thanks stub -- I had your message open in front of me but all it said was "Update your psycopgda"
[08:05] <stub> You need to configure your email client to display the fine print
[08:05] <mpt> yes, or get a hackitude implant
[08:11] <jblack> stevea: What are you doing up?
[08:14] <stub> Thats wierd. I merge  r3139 from launchpad/devel into launchpad/production/1.49 and I end up with an added file database/schema/patch-40-18-0.sql.moved instead of database/schema/patch-40-18-0.sql
[08:16] <stub> Yet in the trunk it is patch-40-18-0.sql and no subsequent patches have renamed it that I can find
[08:16] <stub> lifeless: ^^^ might want a look
[08:17] <lifeless> stub: .moved happens on conflicts of a certain sort
[08:17] <stub> Ahh... looks like a conflict. The contents of the file on the trunk is not what I expected
[08:18] <lifeless> if it was deleted and add that would cause that 
[08:19] <stub> Yer - celso landed it with a different patch number than I told him to :-/
[08:19] <SteveA> jblack: well... it is 9:20 am
[08:19] <jblack> Ahh. Whats on your mind?
[08:21] <SteveA> i sent a merge request to pqm yesterday, and didn't receive a response.  lifeless told me that it had caused a new kind of error, and so he got the error report, and will add handling of this kind of error.  the error was to do with the ssh command failing.  lifeless speculated that it was because pqm couldn't get to the place where the branch is.
[08:22] <SteveA> i think i was following the RocketfuelSetup instructions for this.  i'd like to try merging again, with you around, so that we can see if i can reproduce the problem.
[08:23] <SteveA> jblack: does the submit-bzr-merge uses .bzr/x-push-data
[08:24] <jblack>  looking
[08:24] <SteveA> for this branch, .bzr/x-push-data contains stevea@chinstrap.ubuntu.com:/home/warthogs/archives/stevea/sqlos/devel/
[08:24] <SteveA> i wonder if submit-bzr-merge isn't cutting off the "stevea@" part?
[08:24] <jblack> Yes, it does.
[08:24] <jblack> Yes, it does use x-push-data
[08:24] <jblack> MYURL=$(cat .bzr/x-push-data | sed -e 's|^\(.*\):/|sftp://\1/|g') \ || (echo FAILED to get published location && exit 1)
[08:25] <jblack> This is the line that uses it. Thats a complicated regex, so its possible.
[08:25] <SteveA> sftp://stevea@chinstrap.ubuntu.com/home/warthogs/archives/stevea/sqlos/devel/
[08:25] <SteveA> that is the result
[08:25] <SteveA> so, i guess pqm would have problems with that
[08:31] <jblack> Ok. thats fixable.
[08:31] <jblack> I'll introduce a second regex to turn my url into a fqdn into something like $branchurl
[08:35] <jblack> stevea: is this blocking you?
[08:38] <dooglus> jblack: change .* to [^:] *
[08:38] <SteveA> jblack: it isn't blocking me
[08:40] <jblack> dooglus: You may be missing context. This is used for actual sftp pushing too
[08:40] <dooglus> jblack: I'm missing everything :)  sorry I didn't notice where I was.
[08:40] <dooglus> I thought I was in #ubuntu, where people answer questions before reading them ;)
[08:40] <jblack> Heh. :)
[08:41] <dooglus> try rebooting!
[08:43] <SteveA> cat .bzr/x-push-data | sed -e 's|^\([^@] *@\)\(.*\):/|sftp://\2/|g'
[08:44] <sivang> morning 
[08:44] <sivang> hey jblack , how you bee?
[08:44] <sivang> err, been even
[08:44] <SteveA> jblack: do you think that would be okay?
[08:44] <SteveA> it seems to work for me
[08:44] <SteveA> but i'm don't really know sed
[08:45] <dooglus> SteveA: are you wanting to throw away the part before the @ ?
[08:45] <SteveA> if the script were written in python, then this replacement could have a simple doctest :-)
[08:45] <SteveA> dooglus: yes
[08:45] <SteveA> if there is a part before the @
[08:45] <SteveA> there may or may not be
[08:45] <dooglus> SteveA: looks good then.  is there always an '@'?  'cos if there isn't, your sed script won't change anything
[08:46] <SteveA> there isn't 
[08:46] <SteveA> do that's a problem
[08:46] <jblack> SteveA: if it works for you, then I'll put that up
[08:46] <SteveA> jblack: it works for me, but will fail for others, as dooglus pointed out
[08:46] <dooglus> SteveA: test it on an input without either an "sftp://" prefix or an embedded '@'
[08:46] <SteveA> cat .bzr/x-push-data | sed -e 's|^\([^@] *@\)\?\(.*\):/|sftp://\2/|g'
[08:47] <jblack> I think the easiest thing is to generate a second regex for the merge request.
[08:47] <SteveA> what i just posted works well for me
[08:47] <dooglus> SteveA: what if there's no @ apart from in the filename to copy?
[08:47] <lifeless> SteveA: I'm in a meeting with jblack 
[08:47] <lifeless> SteveA: can you pick this up in say 15 ?
[08:47] <SteveA> sure
[08:47] <lifeless> thanks
[08:48] <carlos> morning
[08:48] <SteveA> hi carlos 
[08:51] <SteveA> spiv: ping?
[08:52] <lifeless> spiv is at yoga
[08:52] <lifeless> he may be up for a call afterwards
[08:53] <lifeless> failing that tomorrow
[08:53] <lifeless> and I can fill you in myself later
[09:02] <SteveA> okay, cool
[09:06] <SteveA> stub: has anyone talked with you about getting the changes to +translate pages into production soon?
[09:07] <dilys> Merge to devel/launchpad/: [trivial]  ShippingRequest index and fix build.pocket db patch (r3143: Stuart Bishop)
[09:08] <stub> SteveA: Nope
[09:08] <jblack> stevea: Ok. Where were we? 
[09:08] <jblack> I was highly lossy while we were talking. Can we just start over?
[09:08] <SteveA> stub: carlos and daf made translate pages not try to re-render on a redirect
[09:09] <SteveA> it ought to be an unintrusive browser-code-only patch, that may cut out a bunch of hard timeouts
[09:09] <SteveA> jblack: cat .bzr/x-push-data | sed -e 's|^\([^@] *@\)\?\(.*\):/|sftp://\2/|g'
[09:09] <SteveA> that appears to work for both cases with and without a name@ at the start
[09:10] <jblack> You've tested?
[09:10] <SteveA> i've asked pqm to merge stuff
[09:10] <SteveA> it isn't a real test
[09:10] <SteveA> a real test would involve factoring out the conversion of text that is expected to be in x-push-data, and testing that conversion in a variety of cases
[09:10] <jblack> I don't mean a test of the whole process, but a test of that regex.
[09:11] <jblack> Ahh. I understand
[09:11] <SteveA> jblack: the regex works for me.  as the maintainer of the scripts, now you should check that it works for the cases you can think of
[09:11] <carlos> stub: that's rev 3141
[09:11] <jblack> I think that there may be an easier way to do this.
[09:11] <SteveA> also, a comment in the script describing what the transformation is, would help those maintaining the script
[09:12] <carlos> SteveA: I didn't know it should be cherrypicked
[09:12] <SteveA> carlos: it is a simple change that may have a big effect in reducing timeouts
[09:12] <SteveA> but, let's see what stub thinks about it
[09:12] <jblack> If we make sure the ssh config stuff docs are in both PQMsetup and rocketfuelsetup, then the user never needs to set the username
[09:12] <carlos> SteveA: ok
[09:12] <stub> I'll run the tests and see what happens
[09:13] <stub> (after my swim)
[09:13] <jblack> Stevea: what do you think about it?
[09:13] <SteveA> jblack: okay.  although i think it would still be good for the submit-bzr-merge script to deal elegantly with having username@ in x-push-data
[09:13] <SteveA> beacuse otherwise, it has a failure mode that takes a long time to discover, and is quite obscure
[09:14] <SteveA> the submit script could either: deal with having username@ in x-push-data, or, give a comprehensible error and fail early if there is username@ in the x-push-data
[09:18] <jblack> This is getting a little long for a bash script. :(
[09:19] <SteveA> this coming from an arch hacker!
[09:21] <jblack> https://wiki.launchpad.canonical.com/PQMSetup?action=diff&rev2=22&rev1=20
[09:21] <jblack> Heh. I fought my fair share with Tom about larch being in bash. He later admitted that the group was right. =)
[09:23] <SteveA> jblack: i think you can remove the <!>work in progress, do not use<!> marker now
[09:24] <jblack> As you wish. done
[09:26] <stub> bzr is a python script, so there is nothing wrong with making submit-bzr-merge into a python script too. Its not like Python won't be installed or anything.
[09:26] <stub> or a plugin might be better
[09:28] <jblack> stub: Thats about what I'm thinking
[09:28] <jblack> They're in bash today because they were initially bash. 
[10:29] <mpt_> rock, a 1.5 MB failure message
[10:34] <jblack> I need to write a couple large documents. Is there anything I can do for anyone before I disapear for a few hours?
[10:38] <carlos> mpt hi, do you have some minutes to help me with javascript?
[10:39] <mpt> carlos, I don't really know JavaScript yet, you'd be better off asking kiko
[10:39] <mpt> (I'm trying to study it an hour each day, but haven't got that far yet :-)
[10:40] <carlos> ok
[10:40] <carlos> kiko-zzz: please, ping me when you are awake
[10:40] <carlos> mpt: thanks anyway
[10:47] <stub> pqm is down for a bit while I run tests on balleny. Should be back in 30 mins if I remember ;)
[10:59] <daf> good morning
[11:00] <mpt> hi daf
[11:01] <daf> hi mpt 
[11:01] <daf> did you get your router sorted?
[11:03] <mpt> not really
[11:03] <mpt> I have Internet on my Ubuntu box now in "I'm pretending to be Matthew's iBook" mode
[11:03] <mpt> i.e. having the same MAC address and IP number
[11:03] <mpt> so they can't be connected simultaneously
[11:05] <daf> very odd
[11:11] <daf> mpt: bug #30002: confirm or reject?
[11:11] <Ubugtu> malone bug 30002 in launchpad "Cannot add HTML (or other formatting) in descriptions" [Normal,Unconfirmed]  http://launchpad.net/bugs/30002
[11:12] <mpt> daf, reject I think
[11:13] <daf> right, thought so
[11:13] <daf> can you do that?
[11:13] <mpt> sure
[11:13] <daf> I think you'd do better than I at explaining the rationale
[11:15] <daf> jamesh: ping
[11:18] <mpt> stub, pqm back up yet?
[11:19] <stub> mpt: yes
[11:19] <mpt> ta
[11:22] <stub> SteveA, carlos, daf: r3141 has been cherrypicked
[11:22] <carlos> stub: thank you
[11:23] <SteveA> stub: thanks!
[11:23] <carlos> jordi: btw, you should be able to remove entries from the translation import queue
[11:23] <carlos> jordi: I already removed the drupal ones to test it
[11:24] <daf> stub: great, I'll update the status
[11:28] <daf> lifeless: ping
[11:31] <mpt> AssertionError: 1 != 2
[11:31] <cprov> morning hackers
[11:31] <mpt> dang this reality-based mathematics
[11:32] <daf> spiv: ping
[11:36] <seb128> hi
[11:36] <seb128> is launchpad known to have issues today?
[11:36] <seb128> it returns some "500 Internal Server Error" when trying to change settings of a bug
[11:37] <mjg59> Hi - I uploaded a package last night, but launchpad shows no sign of it and I don't seem to have got an acknowledgement mail?
[11:38] <seb128> OOPS-46D173 now
[11:38] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/46D173
[11:38] <mjg59> The .upload file suggests that it all went up successfully
[11:40] <mjg59> 7.0.0-0ubuntu1 was in NEW at the time when I uploaded 7.0.0-0ubuntu2, which may have something to do with it?
[11:40] <mjg59> (Should I just file a bug?)
[11:40] <Kinnison> the .upload wouldn't know much more than it went to the ftpserver okay
[11:40] <mjg59> Kinnison: Yeah
[11:40] <Kinnison> the drop on the floor will be that it couldn't find the orig in the distro (known bug)
[11:41] <mjg59> Kinnison: Ah, right
[11:42] <Kinnison> The path of least resisitance is to get the first accepted into ubuntu and processed into the archive before trying to upload the second
[11:43] <cprov> mjg59: I can have a look for you,one sec
[11:43] <Kinnison> stub: is librarian gc running regularly?
[11:43] <mjg59> Yeah, but I discovered the first was broken
[11:44] <mjg59> (Missing build-depend that didn't show up because I had a stale copy of the library sitting around anyway)
[11:44] <Kinnison> upload the second having prepared it -sa ?
[11:44] <seb128> OOPS-46C178
[11:44] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/46C178
[11:44] <seb128> grumpf, I'm trying to update that bug for like 10 times now ... somebody fancy to look on what those oops are? :)
[11:45] <cprov> mjg59: xserver-xgl_7.0.0-0ubuntu1_source.changes REJECTED -> UploadError made it out to the main loop: Unable to find distrorelease: unstable
[11:45] <mjg59> cprov: Yeah. I fixed that and then uploaded.
[11:45] <cprov> mjg59: didn't you receive the email ?
[11:45] <mjg59> cprov: No, I got that one
[11:45] <mjg59> I then got a "is NEW" mail
[11:45] <mjg59> And then I uploaded a new version
[11:46] <mjg59> The one that went into NEW first got built (with resulting broken binaries that people are now bitching about), and the second one vanished :)
[11:46] <cprov> mjg59: uhm .. will see
[11:47] <daf> stub: do you know about these "Retry" exceptions appearing in the OOPS summaries?
[11:47] <daf> e.g. OOPS-45A331
[11:47] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/45A331
[11:47] <mjg59> cprov: I've just uploaded it again and it's been accepted
[11:48] <mjg59> So it sounds like kinnison's suggestion
[11:48] <stub> daf: In theory you will see that if the retry fails three times. I would have through that extremely unlikely though.
[11:48] <seb128> daf: OOPS-46C178 ... do you know about that?
[11:48] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/46C178
[11:48] <cprov> mjg59: good, anyway we need to be sure about what happened
[11:49] <daf> stub: it happened 49 times yesterday :/
[11:49] <daf> stub: er, 39
[11:49] <daf> seb128: it's still syncing
[11:49] <seb128> OOPS-46D173 maybe?
[11:49] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/46D173
[11:49] <seb128> daf: thanks for replying something :p
[11:49] <daf> seb128: that timeout looks familiar
[11:50] <seb128> launchpad i unusable for me today
[11:50] <seb128> I've to retry 10 times to update a bug, and I've hundreds of bug to triage ....
[11:51] <daf> stub: do you know what's happening about these 25-second queries on Person?
[11:51] <jordi> carlos: oh carlos, I love you
[11:51] <seb128> OOPS-46D184 now
[11:51] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/46D184
[11:51] <stub> daf: nup
[11:51] <daf> I'll ask Salgado when he turns up
[11:52] <cprov> stub: any news about that DB patch and mawson upgrade ?
[11:52] <carlos> jordi: ;-)
[11:53] <stub> cprov: Znarl should be doing the PostgreSQL package install soon
[11:53] <cprov> stub: good, thx 
[11:53] <daf> stub: hmm, annoyingly, these Retry OOPSes don't seem to include information about what the query that failed was
[11:54] <seb128> daf: launchpad is sloooow too, like it takes 1 min to load a page
[11:54] <daf> and I'm getting several 500 errors today
[11:54] <stub> daf: Retry wraps the original exception. We can improve the repr() of it to include the details of the wrapped exception.
[11:55] <Znarl> stub : Yep, in the next 10 minutes I'll be doing the upgrade.
[11:55] <daf> stub: good idea: I'll file a bug on that
[11:55] <stub> One of the four appservers had locked for some reason. I've restarted it. Launchpad seems snappy to me at the moment.
[11:56] <daf> seb128: 46C178 looks the same
[11:57] <stub> cprov: Your db patch is on production btw.
[11:57] <seb128> works fine again for me now
[11:57] <seb128> thank you
[11:58] <stub> Evil. Multiple app servers should be improving reliability :-/
[11:59] <daf> that is weird
[11:59] <cprov> stub: that's nice, do you have a DB copy after applying it ? 
[11:59] <SteveA> stub: we should look at applying something to the new twisted front end that definitely refuses new connections when the connection queue is too high
[11:59] <stub> cprov: No. I'll reapply it when building the database on mawson
[12:00] <cprov> stub: up to you, thx
[12:13] <seb128> daf: just got OOPS-46C199 
[12:13] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/46C199
[12:14] <daf> seb128: ok, waiting for it to sync...
[12:17] <Lathiat> mm amarok is much more stable now, its been playing a stream for 24 hours and hasnt crashed :)
[12:17] <Lathiat> -ECHAN
[12:17] <matsubara> good morning!
[12:18] <daf> dom dia matsubara 
[12:18] <daf> *bom
[12:19] <seb128> OOPS-46B338 while trying to figure a contact for a bug that time
[12:19] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/46B338
[12:19] <mpt> Gift Day to you, daf :-)
[12:20] <daf> :)
[12:21] <daf> seb128: 46C199 is the same as the others
[12:21] <daf> seb128: don't worry, I'll make sure this gets attention
[12:21] <seb128> thank you
[12:22] <daf> I wonder if using email addresses instead of nicknames would be a workaround
[12:22] <seb128> I don't know emails adress like that
[12:22] <daf> yeah :(
[12:22] <seb128> but I do know the IRC nickname of most of distro team :p
[12:23] <Kinnison> jblack: I just fixed up the markup on the london workshop page
[12:23] <seb128> like pitti, mvo, kamion, iwj, etc use the same nickname on launchpad
[12:23] <seb128> makes easy to reassign bugs for me
[12:23] <Kinnison> jblack: you may want to start again for adding your flights
[12:23] <daf> salgado!
[12:23] <salgado> morning daf
[12:24] <jblack> kinnison: Did you just walk on top of my edit?
[12:24] <daf> good morning
[12:24] <Kinnison> jblack: possibly, I only noticed your edit lock after I hit submit but before the page refreshed
[12:24] <daf> salgado: queries on Person/ValidPersonOrTeamCache seem to be timing out a lot today
[12:24] <daf> salgado: e.g. https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-15/C199
[12:25] <jblack> Its cool.
[12:25] <jblack> You did what I did anyways
[12:25] <jblack> :)
[12:25] <salgado> daf, is it always reproducible?
[12:26] <daf> salgado: it seems to be happening to seb128 more times than not
[12:26] <stub> Kinnison, cprov: Any data in the PostgreSQL 7.4 databases that we want to keep?
[12:26] <Kinnison> stub: on mawson? not for me
[12:26] <cprov> stub: no, throw it away ;)
[12:26] <stub> Cool. No need to migrate :)
[12:28] <salgado> stub, is there any script running on production now that could hold the lock on the person/emailaddress/ValidPersonOrTeamCache for too long?
[12:29] <daf> 36 seconds -- that's a record!
[12:29] <SteveA> salgado: another page that writes could hold the lock for a while 
[12:29] <stub> salgado: Not on gangotri. Perhaps the publishing stuff on drescher?
[12:30] <daf> do locks slow down reads?
[12:30] <jblack> SteveA: self added.
[12:30] <jblack> SteveA: I presume we're staying at KK and meeting at the flat?
[12:30] <stub> just the authserver, launchpad and importd bzr syncs
[12:31] <SteveA> no
[12:31] <SteveA> we're staying at the novotel excel and meeting there
[12:31] <jblack> ok
[12:32] <jblack> Its right there on the top of the page
[12:32] <SteveA> jblack: can you arrive on the sunday, not the saturday?
[12:33] <jblack> I can ask him if he can change it. 
[12:33] <SteveA> please
[12:34] <jblack> The last time I came to London I asked if I could come a day early because of the time change.
[12:36] <SteveA> please come on sunday this time
[12:36] <mpt> When I run "make check" locally I get no errors, but PQM reports 594 errors
[12:37] <SteveA> mpt: have you pushed stuff?
[12:37] <mpt> yes
[12:37] <mpt> Most of the errors are of the form "ConfigurationConflictError: Conflicting configuration actions For: ('protectName', <class 'sqlobject.main.SelectResults'>, u'count')"
[12:37] <SteveA> hmm
[12:37] <SteveA> maybe i messed something up here
[12:38] <SteveA> mpt: this is probably from me merging a trivial change to sqlos.  perhaps the test suite isn't run when sqlos is merged.
[12:39] <mpt> thanks
[12:40] <mpt> A warning that may or may not be relevant: "/home/pqm/arch/queue/workdir/home/---devel/launchpad/lib/canonical/lp/__init__.py:107: UserWarning: A ZopelessTransactionManager with these settings is already installed.  This is probably caused by calling initZopeless twice."
[12:40] <SteveA> i think it was me
[12:40] <SteveA> i'm just testing it locally
[12:41] <SteveA> although, it is bad that the merge into sqlos didn't run tests to catch this
[12:41] <SteveA> at least, that's what i assume happened
[12:41] <mpt> So merges to different modules run different sets of tests?
[12:41] <SteveA> not sure
[12:42] <SteveA> mpt: can you do the following:
[12:42] <SteveA> in lib/canonical/configure.zcml, remove from the top:
[12:42] <SteveA>     <!-- Hack to allow 'count' method of sqlobject's SelectResults -->
[12:42] <SteveA>     <class class="sqlobject.main.SelectResults">
[12:42] <SteveA>       <require
[12:42] <SteveA>           permission="zope.Public"
[12:42] <SteveA>           attributes="count"
[12:42] <SteveA>           />
[12:42] <SteveA>     </class>
[12:42] <SteveA> 
[12:42] <SteveA> commit, push, submit another merge
[12:45] <mpt> ok
[12:46] <SteveA> and i expect andrew's forthcoming merge will fail too 
[12:46] <SteveA> for the same reason
[12:46] <SteveA> spiv: ^^^^
[12:47] <SteveA> mpt: can you send me (put on chinstrap perhaps) some pictures of the "bad designs" for navigation sometime?
[12:47] <mpt> ok
[12:50] <daf> salgado: do we have a bug open on the vocabulary timeout problem?
[12:57] <salgado> daf, according to the error report for yesterday, we had only 4 timeouts on that query, and I'm pretty sure it's used at least a few hundreds times a day 
[12:58] <salgado> also, stub reported that running it on production is actually fast, so I think the problem is on something else that is holding the lock for too long
[12:58] <daf> ok
[12:58] <daf> so the problem is working what's causing the contention?
[12:58] <SteveA> it could be any other long write query
[12:58] <daf> 36 seconds is a long time to be holding a lock
[12:58] <salgado> for instance, we had 65 timeouts trying to insert a person row
[12:58] <salgado> (yesterday)
[12:58] <SteveA> because all queries use the Person table
[12:59] <SteveA> and given the isolation level we're using, that would be locked for other writes
[12:59] <SteveA> a 36 second timeout could be two locks
[12:59] <daf> literally all?
[12:59] <SteveA> or more
[12:59] <SteveA> all queries use the person table
[12:59] <SteveA> um
[12:59] <SteveA> all requests, i mean
[12:59] <SteveA> all transactions
[01:00] <daf> but not all queries write to it
[01:00] <daf> but not all requests write to it
[01:00] <SteveA> i think any transaction in which there is a write will end up having an effect on contention for the Person table
[01:00] <SteveA> unless we run less isolated
[01:01] <daf> hmm, nasty
[01:01] <SteveA> or at least, on the TeamParticipation table
[01:01] <SteveA> so, we must fix other timeouts
[01:01] <daf> does this mean that fixing other slow pages will fix this?
[01:01] <daf> ok
[01:01] <SteveA> and these areas of contention will improve
[01:01] <SteveA> also, postgresql 8.whatever may improve this
[01:02] <SteveA> with better locking strategies at high levels of isolation
[01:02] <daf> IIRC, we're using 8.0 and we're considering upgrading to 8.1
[01:03] <jblack> dunno
[01:07] <daf> salgado: https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-15/B338 -- this seems to be executing the same query 4 times, except with three of them being SELECT COUNT(*)
[01:07] <cprov> carlos: ping
[01:07] <carlos> cprov: pong
[01:07] <daf> salgado: not the that the last three take very long, but it seems odd
[01:08] <cprov> carlos: are you interesting in test real translation life-cycle in mawson today ?
[01:09] <carlos> cprov: that would be good
[01:09] <cprov> carlos: if you provide me an real upload we can manage to reproduce the entire cycle in mawson before i do the rollout, this evening (my time)
[01:09] <carlos> cprov: do you control the content of the chroot?
[01:09] <cprov> carlos: right, work on this package
[01:10] <carlos> cprov: we need an update of pkgstriptranslations from Martin Pitt
[01:10] <cprov> carlos: uhm .. yes, I think we still having 2 i386 builds for mawson
[01:11] <cprov> carlos: uhm ... sort of annoying, but it'd be ok
[01:11] <carlos> cprov: that's the only way to get the tarball with the translations included
[01:11] <carlos> as part of the .changes file
[01:12] <cprov> carlos: as you described in that test ... I see
[01:13] <carlos> cprov: In fact, you will need that update too on production
[01:13] <carlos> or my code will not be executed
[01:13] <carlos> but I guess it's just a matter of doing a normal upload of that package update
[01:13] <carlos> just like any other Ubuntu upload
[01:14] <carlos> so Martin would do that
[01:14] <salgado> daf, that's odd, indeed. I'll find where are these count queries issued and see if I can fix it
[01:15] <cprov> carlos: if it's already in dapper it will get updated before build anything
[01:16] <sivang> jblack: right, but wasn't sure this issue could be a #lp matter :)
[01:16] <carlos> cprov: it's not yet in dapper, he's waiting for us 
[01:16] <jblack> Oh, its just a bzr one?
[01:16] <carlos> cprov: when you move your branch into production, he will do the upload
[01:17] <cprov> carlos: uhm .. interesting, the update would have some colateral effect ?
[01:17] <carlos> cprov: your update?
[01:17] <cprov> carlos: no, the pitti tool update
[01:17] <carlos> yes
[01:17] <carlos> when that update is done
[01:18] <carlos> all packages with translations will start producing a new tarball with translations as part of the list of files inside the .changes file
[01:18] <cprov> eck, it's not backward compatible ...
[01:19] <carlos> cprov: ?
[01:19] <cprov> carlos: we need to coodenate this update too 
[01:19] <carlos> cprov: 
[01:19] <carlos> cprov: if you update your branch
[01:20] <carlos> the old packages will be valid 
[01:20] <cprov> carlos: IMO, the best thing to do would be activate the new behaviour via some cmdline option or similar
[01:20] <carlos> and you will know what to do with translations
[01:20] <cprov> carlos: if you say so, I'm happy
[01:21] <carlos> cprov: the .changes file format is not changing at all
[01:21] <carlos> it's just adding a new file
[01:21] <carlos> anyway, you should talk with pitti about your compatibility concerns, just in case I'm missing something
[01:21] <cprov> carlos: I'm just a little bit concerned by the fact of we have many many things depending on a branch which is very slow to review 
[01:22] <carlos> cprov: hmmm, did you talk with kiko about that?
[01:23] <cprov> carlos: sure the .changes format will be the same, but the way rosetta work with it will change a lot, AFAICS
[01:23] <carlos> cprov: I had to leave yesterday so I don't know if you alreay talked about it
[01:23] <cprov> carlos: yes, he is aware
[01:23] <carlos> cprov: Rosetta is not using those files atm
[01:24] <carlos> cprov: Rosetta is "stalled" until this is "fixed"
[01:24] <carlos> I mean, Ubuntu imports into Rosetta are "stalled"
[01:24] <pitti> hi guys
[01:24] <carlos> pitti: hi
[01:25] <cprov> carlos: really ? rosetta is stalled ... shhhhh 
[01:25] <carlos> pitti: do you think that your update to pkgstriptranslations would produce any kind of incompability with old tools?
[01:25] <cprov> carlos: when is the maximum ETA ?
[01:26] <carlos> cprov: alreday passed?
[01:26] <carlos> that's ASAP
[01:26] <cprov> carlos: aff
[01:26] <pitti> carlos: which tools do you mean?
[01:26] <pitti> carlos: the only change is that it adds the translation tarball to the .changes file
[01:27] <pitti> carlos: i. e. it doesn't change the format of tarballs, etc.
[01:27] <carlos> pitti: I know, but the standard debian tools will be able to handle that change without problems?
[01:27] <carlos> pitti: or old versions of soyuz
[01:27] <cprov> pitti: hi, what will be the consequences of an imediatte upload of pkgstriptrans.. in dapper ?
[01:27] <carlos> I suppose they will ignore that new file from the .changes file, right?
[01:28] <pitti> carlos: no idea; they might choke on the auxiliary upload in the raw-translations section
[01:28] <Kinnison> older soyuz will fail the uploads most likely
[01:28] <pitti> carlos: but that's more of a Kinnison/elmo question
[01:29] <pitti> cprov: no idea, sorry; that entirely depends on LP upload processing, and how the tarballs are fed to Rosetta; nothing else cares about the change
[01:29] <carlos> cprov: is that a problem? is there any possibility that you need to roll back your changes?
[01:29] <cprov> Kinnison: not my current branch, I suppose. It will invoke rosetta code to properly import translation files, is that right ?
[01:29] <dilys> Merge to devel/launchpad/: [r=spiv]  Clean up build listings, with icons for each state (bug 3839) (r3144: Matthew Paul Thomas)
[01:30] <pitti> carlos: with that switch, will the translation tarballs still be available in a public place? so that I can fall back to my old scripts in an emergency?
[01:31] <Kinnison> cprov: if you and carlos are satisfied then yes
[01:31] <cprov> Kinnison: yes, we have a good test and will test stuff end-to-end in mawson before rollout 
[01:31] <carlos> pitti: I suppose they will be available just like any other file referenced by the .changes one
[01:32] <carlos> Kinnison: ^^^ Could you confirm it?
[01:32] <Kinnison> cprov: I'd suggest that once the codeline is in place, pitti should find a way to do a single package upload using dpkg-distaddfile (perhaps manually) to see if it works end-to-end
[01:32] <Kinnison> cprov: then if end-to-end seems fine in production he can upload a new pkgstriptranslations
[01:32] <cprov> pitti: I'm concerned about how the things will work when I rollout soyuz and we didn't update pkgstriptranslations
[01:33] <carlos> cprov: that's not a problem
[01:33] <Kinnison> cprov: a non-updated pkgstriptranslations behaves as now, and isn't an issue
[01:33] <carlos> old .changes file will still work. We handle them as packages without translations
[01:33] <cprov> carlos: right, we continue to be able to grab the translations directly from the builder
[01:33] <pitti> cprov: I can upload a new pkgstriptranslations with the dpkg-distaddfile call within 2 minutes, just tell me when I should
[01:34] <pitti> Kinnison: sure, that's no problem
[01:34] <cprov> pitti: rollout will be tomorrow mornign I think, we need to setup the sandbox first 
[01:34] <pitti> Kinnison: if you allow me to do a binary-only upload (since that's what the buildds will do)
[01:35] <cprov> okay okay, if I can rollout w/o break rosetta, I'm satisfied 
[01:35] <Kinnison> pitti: That's a bit hard to do without you being a buildd :-) I was thinking you could modify a small source package appropriately, but perhaps that's not going to be needed once cprov/carlos have done their tests
[01:35] <carlos> cprov: I confirm it to you, you can rollout now your code without breaking Rosetta at all
[01:36] <pitti> Kinnison: well, source uploads will never have a translation tarball usually, but if you need that, I can certainly construct one
[01:36] <Kinnison> pitti: that was what I was thinking
[01:36] <Kinnison> pitti: but obviously not until cprov gives you the go-ahead
[01:36] <cprov> pitti: it won't be necessary, when I rollout new soyuz, I will let you know, then you can upload your pkg and we will handle the remaining translations 
[01:36] <Kinnison> pitti: listen to cprov, he's the man :-)
[01:37] <carlos> ;-)
[01:37] <pitti> cprov: sounds good :)
[01:37] <pitti> carlos: what will happen with the tarballs that are generated until tomorrow? can you fetch them from lamont's home dir and manually import them?
[01:37] <cprov> pitti: yes, expect some ping tomorrow morning tops
[01:37] <carlos> pitti: yes, I will need to write a script to do that
[01:38] <carlos> hmmm
[01:38] <pitti> carlos: alternatively, if it's easier for you, I can give you a tarball with all current translations
[01:38] <pitti> carlos: which has the same format as the rosetta output
[01:38] <carlos> pitti: no, I need it splitted by sourcepackage
[01:38] <pitti> carlos: but I guess just importing the original tarballs should work (that's what rosetta needs to do anyway :) )
[01:38] <pitti> carlos: ok, fine
[01:39] <carlos> so It's just a matter of upload it
[01:39] <pitti> great to see progress here
[01:39] <carlos> cprov: I will need an extra code change
[01:39] <pitti> we need to settle and stabilize that langpack building process
[01:39] <carlos> to block any translation tarball that isn't for 'main' section
[01:39] <cprov> carlos: no problem, grab my mine and send me yours
[01:40] <carlos> pitti: I suppose it's better to block the tarballs at the import point instead of being part of pkgstriptranslations...
[01:40] <carlos> pitti: what do you think?
[01:40] <carlos> pitti: we are going to import only packages in main
[01:41] <carlos> as universe will not have language packs neither have the resources to get translations updates from Rosetta 
[01:41] <carlos> at least until we link Rosetta with bzr
[01:42] <SteveA> daf: would you show pitti the scrape.py and oops pages you use for launchpad's own bug triage?
[01:43] <daf> SteveA: sure
[01:43] <pitti> carlos: fine for me
[01:43] <pitti> hi daf :)
[01:43] <daf> hi pitti!
[01:43] <daf> I've developed a tool for querying bugs in ways Malone doesn't allow yet
[01:43] <daf> https://chinstrap.ubuntu.com/~daf/bugs/scrape.py
[01:44] <daf> it uses a simple API to fetch data from Launchpad
[01:44] <carlos> pitti: Well, I was asking more if you think is useful to generate the translation tarball always and filterout the imports vs. generate only it for packages in main.
[01:44] <SteveA> daf: now that we have the rfc-822 bug pages, it needn't be called "scrape" anymore
[01:44] <daf> SteveA: true -- do you have a better name in mind?
[01:44] <pitti> carlos: that already happens - we already have translation tarballs for all packages (also universe)
[01:44] <pitti> carlos: pkgstriptranslation just doesn't strip the translations out of universe .debs
[01:45] <SteveA> daf: it's mostly a milestone report, but with some other things too
[01:45] <SteveA> daf: it is to support the launchpad bug triage process
[01:45] <carlos> pitti: and what do you think it's the best solution? keep producing the tarballs or just ignore its creation if the package is not in main?
[01:46] <pitti> carlos: I would keep the tarballs somewhere and eventually import them into Rosetta
[01:46] <carlos> ok
[01:46] <pitti> carlos: since upstreams might want to use Rosetta, too, the MOTUs might want to pull new translations, etc
[01:46] <pitti> carlos: so I'd like to keep current pkgstriptranslation's semantics, if that's fine for you
[01:47] <carlos> it's ok
[01:47] <carlos> pitti: anyway, Daniel told me that they are not able to handle translations from Rosetta
[01:47] <pitti> they don't?
[01:47] <carlos> pitti: so even when upstream uses Rosetta, the sourcepackage translations will not be there
[01:48] <SteveA> daf: there are a lot of confirmed bugs listed on scrape.py that are about infrastructure
[01:48] <daf> SteveA: yes
[01:48] <siretart> launchpad.net down? (me cannot ping)
[01:48] <carlos> pitti: he said that until we get bzr integration, they don't have the resources to fetch manually the .po files and do a new upload with the translation updates just before the release
[01:49] <daf> SteveA: I'll add code to filter by subscriber
[01:49] <SteveA> siretart: works for me
[01:49] <siretart> hm. ok
[01:49] <daf> same here
[01:49] <siretart> ah, works again
[01:49] <pitti> daf: nice; showing all of my bugs on just one page would already save me a lot of headaches
[01:50] <siretart> From 82.211.81.76 icmp_seq=4 Destination Host Unreachable
[01:50] <siretart> 64 bytes from gangotri.ubuntu.com (82.211.81.179): icmp_seq=5 ttl=53 time=75.3 ms
[01:50] <siretart> *shrug*
[01:50] <siretart> some dns foo
[01:51] <seb128> Ubugtu:  bug #31487
[01:51] <Ubugtu> malone bug 31487 in synaptic "Synaptic opens behind other windows" [Normal,Unconfirmed]  http://launchpad.net/bugs/31487
[01:51] <seb128> hum, works here
[01:51] <seb128> it just did a "-Ubugtu- Error: Could not parse data returned by Malone: Connection to Malone bugtracker failed: (113, 'No route to host')" before
[01:52] <stratus> I'm writing a library (in python) to provide some launchpad access methods for external applications...
[01:53] <stratus> I've some problems with authentication (cookielib + urllib2), i think it's because in the login page there are two forms.
[01:53] <Znarl> Short network outage for gangotri was caused by network reconfiguration.  It is now working fine.
[01:53] <SteveA> stratus: launchpad understands basic auth headers
[01:53] <stratus> SteveA: oh!
[01:53] <SteveA> it doesn't challenge ever, though
[01:54] <stratus> hmm
[01:54] <SteveA> so, it is a bit hidden
[01:54] <SteveA> it also isn't a "supported" feature
[01:54] <daf> stratus: I have Python code for authenticating against Launchpad
[01:54] <SteveA> so, please let me know what you're doing with it, so it makes it worth keeping around :-)
[01:54] <stratus> daf: my bzr repo is in http://people.debian.org/~stratus/bzr/launchme--main
[01:54] <daf> SteveA: scrape.py uses Basic auth headers
[01:54] <stratus> SteveA: my first goals are products rdf and download the entire tarball from rosetta (due to upstream integration and review)
[01:55] <daf> stratus: I'm afraid I don't have time to look at your code right now
[01:55] <daf> stratus: I used to do cookie login using mechanize, so it can work
[01:55] <stratus> daf: no problem, really. it's in early stages (i think i started this weekend)
[01:55] <daf> stratus: but using Basic auth is simpler
[01:55] <stratus> daf: sure it's, i missed the basic auth stuff, i didn't know that it was supported
[01:56] <stratus> SteveA: btw, thanks.
[01:56] <SteveA> stratus: one other thing. daf too.
[01:56] <SteveA> consider using a unique user-agent for each of your external tools
[01:57] <daf> good idea -- I'll add one now
[01:57] <SteveA> as this will help us see what you're doing with it, and help with a diagnosis if we change things that makes what you're doing break
[01:57] <stratus> SteveA: i was using the urllib2 user-agent, but i changed it for a browser, to test. I'll opt for 'launchme', because it's the library name anyway.
[01:58] <SteveA> okay, cool
[02:03] <dilys> Merge to devel/launchpad/: [trivial]  Fix https://launchpad.net/products/launchpad/+bugs/31114 (Searching for unknown person causes an oops) (r3145: Guilherme Salgado)
[02:04] <daf> weird, https://launchpad.net/products/launchpad/+bugs/31114 is a 404
[02:04] <Ubugtu> malone bug 31114 in launchpad "Searching for unknown person causes an oops (len() of unsigned object)" [Normal,Confirmed]  
[02:04] <salgado> daf, s/bugs/bug/
[02:04] <salgado> my bad, sorry
[02:05] <daf> oh, right
[02:05] <daf> there should probably be a redirect there
[02:05] <salgado> indeed. and I think I've seen a bug for that already
[02:07] <Kinnison> daf: it's not clear how to switch scrape.py to asking about a different product
[02:08] <daf> different to what?
[02:09] <Kinnison> launchpad
[02:09] <daf> it doesn't filter by product by default
[02:09] <daf> use e.g. "product:launchpad-buildd" to filter
[02:09] <Kinnison> It'd be nice to see it against other things
[02:09] <Kinnison> Eg. product:libgfshare
[02:09] <daf> ah
[02:09] <Kinnison> or package:ubuntu/gnome-power-manager
[02:09] <daf> it doesn't have libgsfshare in its cache
[02:10] <daf> I suppose I could make it update the cache on demand
[02:10] <Kinnison> :-)
[02:10] <daf> I wanted to get rid of the cache entirely but that turned out to be too slow
[02:26] <daf> stub: 
[02:26] <daf>     TODO: Including the single quotes was a stupid decision.
[02:26] <daf>     -- StuartBishop 2004/11/24
[02:28] <SteveA> what's that from, daf?
[02:28] <daf> quote_like()
[02:28] <SteveA> it this implicated in an oops?
[02:29] <daf> no
[02:29] <daf> it is implicated in a code review
[02:29] <SteveA> then probably not important for now
[02:31] <daf> it would be a pain to fix because of all the code that uses it, I think
[02:31] <daf> but we could do def quote_like(x): return "'%s'" % quote_like_without(quotes(x))
[02:34] <SteveA> it is not used much
[02:34] <SteveA> 18 times perhaps
[02:34] <SteveA> maybe 27
[02:34] <SteveA> but even so
[02:34] <SteveA> not too much
[02:35] <daf> right-o
[02:36] <daf> well, as it turns out, the use case for having it without quotes just went away
[02:37] <daf> how do I recover my password for lists.ubuntu.com?
[02:37] <SteveA> you may have many passwords
[02:37] <SteveA> but there is a mailman page for that
[02:38] <daf> ah, found it
[02:38] <daf> https://lists.ubuntu.com/mailman/options/launchpad
[02:44] <spiv> daf: pong
[02:44] <spiv> SteveA: pong
[02:45] <SteveA> hello spiv
[02:45] <SteveA> i originally pingged you for a phone call, but it's probably extremely late in sydney now
[02:45] <SteveA> then i pinged you to tell you that i had broken RF temporarily, and one of your merges would most likely fail
[02:46] <SteveA> i broke it by merging something into sqlos
[02:46] <spiv> Yeah, it is.  Life keeps taking over my evenings...
[02:46] <SteveA> so, it seems that sqlos merges don't run launchpad tests
[02:46] <SteveA> but they should do
[02:47] <spiv> I know that buildbot merges do run bzr tests, because that's what keeps failing my buildbot merge :)
[02:47] <spiv> lifeless is busily fixing that, though.
[02:47] <spiv> I'll resubmit my lp merge, as it appears the sqlos issue has been fixed (or at least reverted)?
[02:48] <SteveA> fixed
[02:48] <SteveA> i gave mpt the zcml stanza to remove in launchpad
[02:48] <SteveA> we were allowing ISelectResults.count in launchpad
[02:48] <spiv> (Or I will, once this one-line commit gets pushed -- the fix revealed a bug in a standalone page test, now that they are being isolated from each other)
[02:48] <SteveA> we're now doing so in sqlos, because I added 'count' to ISelectResults
[02:49] <SteveA> and removed a __len__ that had been left around in ISelectResults
[02:55] <daf> SteveA: mailman is taking a long time mailing me my password
[02:58] <SteveA> try again perhaps
[03:03] <jbailey> daf: I've found it really nice to  be on the CAnonical imap server.
[03:03] <jbailey> daf: It seems that sometimes things take a bit to mail externally that show up just about instantly on it.
[03:06] <daf> hmm
[03:06] <daf> SteveA: should we have a policy on using __used_for__ for view classes?
[03:07] <daf> SteveA: it's ad-hoc at the moment
[03:07] <daf> SteveA: I think all or nothing would be better
[03:07] <SteveA> yes it is
[03:07] <SteveA> we'll change it to using something else, that also eases up the zcml, when we have the new zope
[03:07] <SteveA> which i expect will be sometime later this week...
[03:08] <daf> I see
[03:08] <daf> I gather that Zope 3.2 will bring many benefits
[03:08] <SteveA> so, don't worry about it right now
[03:08] <SteveA> yes
[03:08] <daf> ok, I'll make a note of it for alter
[03:18] <SteveA> daf, carlos: is updateStatistics from lib/canonical/rosetta/__init.py:RosettaApplication even used?
[03:19] <daf> I don't know
[03:19] <SteveA> i can't find a place that it is used
[03:19] <daf> removing lib/canonical/rosetta is something I worked on in July
[03:19] <daf> there's a bug assigned to me on it
[03:19] <SteveA> i'm going to remove it now
[03:19] <daf> ok
[03:20] <daf> bug #28996
[03:20] <Ubugtu> malone bug 28996 in rosetta "canonical.rosetta's death sentence" [Normal,Confirmed]  http://launchpad.net/bugs/28996
[03:20] <carlos> SteveA: isn't it used to update the cached values for the main page?
[03:20] <SteveA> not that i can see
[03:22] <daf> remove it, submit a merge, see if tests fail
[03:22] <SteveA> ddaa: what is lib/SCM ?
[03:23] <ddaa> that's a Scheme implementation
[03:23] <SteveA> daf, carlos: the front pages work
[03:23] <SteveA> ddaa: it has mixed tabs and spaces for indentation
[03:23] <SteveA> which is kinda worrying
[03:23] <SteveA> why do we need a scheme implementation?
[03:23] <ddaa> You know Arch guys are fond of putting interpreters in their tools.
[03:23] <ddaa> I'm joking.
[03:24] <SteveA> it's really a forth implementation..
[03:24] <daf> SteveA: it's a cron script that would fail, I think
[03:24] <ddaa> It's an abstract SCM interface, that's providing the basis for common CVS and SVN and Arch support.
[03:24] <ddaa> lifeless' crack
[03:24] <daf> SteveA: (if anything)
[03:24] <ddaa> (I do not mean that in a derogatory way)
[03:24] <cprov> SteveA: mpt: seems that r3144 is broken, see:
[03:24] <cprov>   Module canonical.launchpad.browser.build, line 110, in setupBuildList
[03:24] <cprov>     self.batch = Batch(builds, start)    Module canonical.lp.z3batching, line 41, in __init__
[03:24] <cprov>     listlength = list.count()  ForbiddenAttribute: ('count', <sqlobject.main.SelectResults object at 0xb529824c>)
[03:25] <SteveA> daf: so it is
[03:25] <SteveA> cprov: update sqlos
[03:25] <ddaa> SteveA: lifeless had some trouble with pep8 at first, and there was nobody to enforce it on him.
[03:25] <cprov> SteveA: right, it should not be done yet in the built lp tree
[03:26] <SteveA> cprov: pardon
[03:26] <cprov> SteveA: thanks 
[03:26] <SteveA> daf: yes, it is used in a cron script
[03:26] <SteveA> which is crack
[03:26] <SteveA> why would a cron script use anything from an object that represents the rosetta homepage?
[03:26] <cprov> SteveA: I use the launchpad pre-built tree and it looks old yet, just a matter of time 
[03:27] <SteveA> cprov: ok
[03:27] <daf> SteveA: the code is clearly in the wrong place
[03:27] <carlos> SteveA: I suppose that when Mark added it to the cached infrastructure he didn't move it outside the Rosetta object
[03:27] <SteveA> crack
[03:29] <dilys> Merge to devel/launchpad/: [r=lifeless]  Allow running single standalone page tests with e.g. "./test.py lib xx-bug-index" (r3146: Andrew Bennetts)
[03:43] <lamont> cprov-lunch: do we have a buildd-mgmt ui yet?>
[03:43] <cprov-lunch> lamont: no, not yet
[03:44] <lamont> ok.  just holler when, eh?
[03:44] <cprov-lunch> lamont: we have a cmdline tool scripts/buildd-monitor.py
[03:44] <stub> cprov-lunch: What account do you need to connect to the database from on mawson? launchpad? cprov?
[03:44] <cprov-lunch> lamont: any hints/suggestions are welcome, file a bug on this 
[03:45] <cprov-lunch> stub: since we don't have facist permission in mawson, launchpad & cprov would be fine 
[03:45] <lamont> cprov-lunch: little things are needed like "clear this depwait (because the autodepwait stuff got it wrong)", etc.
[03:46] <cprov-lunch> lamont: this action is called "reset build" and can be done in the build page by LP admin
[03:47] <cprov-lunch> lamont: but we do need actions like: reset builder, abort current build, etc
[03:47] <ddaa> SteveA: importd-bzr plan drafting is complete. Now waiting for resolution of open issues.
[03:47] <SteveA> ok, great
[03:49] <cprov-lunch> lamont: currently we can only change builder mode (MANUAL/AUTO) and mark a builder as fail
[03:53] <stub> cprov-lunch: There is now a new launchpad_dogfood on mawson for you
[03:53] <SteveA> stub: the update-stats.py script apparently has no tests
[03:53] <SteveA> i ran it manually and i don't think i've broken it
[03:55] <stub> It runs on production
[03:55] <SteveA> what i mean is, i'm making a modification to it now
[03:56] <stub> ./lib/canonical/launchpad/ftests/test_update_stats.py
[03:56] <SteveA> ah, thanks
[03:57] <SteveA> i didn't expect to find the test there
[03:57] <stub> I think I threw that together - just minimal - last time I played with it.
[03:57] <stub> Well, Mark wrote it so that is understandable :-)
[03:57] <dilys> Merge to devel/launchpad/: [trivial]  fix karma for bug task modification, so that karma is credited on FIXRELEASED, instead of FIXCOMMITTED (r3147: Brad Bollenbach)
[03:57] <SteveA> it passed
[03:57] <SteveA> hurrah
[04:18] <raketti> how do i kill gdm so, that it doesn't restart?
[04:18] <raketti> oops! :D
[04:18] <jbailey> raketti: ECHAN, but /etc/init.d/gdm stop
[04:19] <raketti> thanks :)
[04:40] <kiko> go salgado-lunch go
[05:48] <kiko> salgado, I just reassigned 3 bugs on shipit from mako to you
[05:49] <kiko> and check out the reporter's name in bug 29172
[05:49] <Ubugtu> malone bug 29172 in shipit "Page width changing" [Normal,Unconfirmed]  http://launchpad.net/bugs/29172
[05:49] <salgado> kiko, ahhh, that came from the bugzilla import?
[05:49] <kiko> yep.
[05:49] <salgado> I was wondering why I didn't get notified about these bugs
[05:51] <kiko> salgado, how's MM looking?
[05:51] <salgado> kiko, well, that's his launchpad displayname. he'd need to provide another one containing only ASCII characters on shipit. I have no idea how his name would look like in plain ASCII, though
[05:52] <kiko> me neither, but I'm curious
[05:54] <salgado> so, MM has gotten a lot more tests. now I'm going to clean it up, review it quickly and add to the review queue
[05:54] <kiko> DO IT
[05:54] <kiko> did you manage to try and run it on mawson?
[05:54] <kiko> carlos, how's PoMsgSetPage?
[05:55] <carlos> kiko: working on #5751
[05:55] <carlos> well, finishing it
[05:55] <kiko> the ajax stuff
[05:55] <kiko> ?
[05:55] <carlos> yes
[05:56] <kiko> isn't it better to finish off PMSP first?
[05:56] <kiko> given it's been in-progress for months
[05:56] <carlos> I have it working after some problems with javascript
[05:56] <carlos> kiko: the ajax stuff should reduce the number of OPPs 
[05:56] <carlos> kiko: I think it's more urgent
[05:57] <kiko> carlos, I think that may be underestimating the 2500 queries I listed in email the other day.
[05:58] <carlos> kiko: the suggestions are not being loaded by default
[05:58] <carlos> only if the translator selects it
[05:59] <carlos> kiko: anyway I will request a UI review by mpt when the branch is ready
[05:59] <kiko> carlos, of those 2500 queries, how many were actually related to suggestions?
[05:59] <SteveA> carlos: i want to review any ajax-related or js-related UI changes
[06:00] <carlos> SteveA: sure, should I add it to your queue directly when it's ready?
[06:00] <kiko> I wouldn't change +translate to being ajax, either, at least not at first
[06:00] <kiko> I would offer it as a +translate-ajax or something
[06:00] <kiko> it's something that will very possibly have cross-browser impact
[06:00] <SteveA> kiko is right.  we must be very careful changing stuff like this
[06:00] <kiko> aaanyway
[06:01] <kiko> I want to see PMSP fixed
[06:01] <kiko> and bug 1681 too
[06:01] <Ubugtu> malone bug 1681 in rosetta "Viewing a translation page fails in unix2newlines" [Major,In progress]  http://launchpad.net/bugs/1681
[06:01] <carlos> SteveA: I'm confused... didn't you suggest that change?
[06:01] <SteveA> carlos: i suggested it as an idea for the future
[06:01] <SteveA> not for doing right now
[06:01] <carlos> ok
[06:01] <kiko> carlos, if you do a careful query analysis of the OOPSes I posted 
[06:01] <kiko> you might find out that suggestions are not the enemy
[06:02] <salgado> kiko, no, I haven't tested it on mawson yet
[06:02] <kiko> salgado, I'd like to see the results of that
[06:02] <SteveA> carlos: btw, i'm working on CrowdControl code, and I think I'll be moving the permissions checks into the security code, as in bug 4814
[06:03] <carlos> SteveA: cool
[06:03] <salgado> btw, Znarl, what's the status of rt#2939?
[06:03] <kiko> salgado, took the words out of my mouth
[06:05] <kiko> carlos, when can you get back to me on the OOPS analysis?
[06:05] <carlos> kiko: I'm looking at it atm
[06:05] <kiko> okay, thanks
[06:05] <kiko> it's a LOT of queries..
[06:10] <kiko> salgado, can you close out bug 31390, then?
[06:10] <Ubugtu> malone bug 31390 in pylib python2.4-pylib "post installation script failing by attempting to compile stuff it shouldn't" [Normal,Unconfirmed]  http://launchpad.net/bugs/31390
[06:14] <kiko> salgado, we also have updated CoC text.. fun :)
[06:14] <salgado> kiko, but the problem still occurs in breezy. should I mark it fixed for dapper?
[06:14] <kiko> the bug is fix released
[06:14] <kiko> it is not a backport bug
[06:14] <kiko> so no need to concern yourself whether it still occurs in breezy
[06:15] <kiko> the only reason to use distrorelease tasks is for backports.
[06:15] <Mez> backpoets?
[06:15] <kiko> that too
[06:15] <carlos> kiko: your log with sampledata is not a good way to debug the sql queries
[06:16] <carlos> kiko: sampledata doesn't have too many examples for suggestions
[06:16] <kiko> carlos, perhaps we need better sampledata.
[06:16] <carlos> kiko: yes, we need better sampledata
[06:16] <kiko> or perhaps you want to run the profiler code on a tree against staging
[06:17] <carlos> kiko: well, perhaps the same test you did with the evolution's POTemplate would be more helpful
[06:17] <carlos> kiko: but staging is much better to test it
[06:17] <carlos> kiko: how did you do it
[06:17] <carlos> ?
[06:17] <kiko> I can re-run against evolution if you like
[06:18] <carlos> kiko: yes, please
[06:18] <kiko> I used the patch I sent to the launchpad list
[06:18] <kiko> but it is easy for me to re-run
[06:18] <carlos> there are more than one .pot file for evolution so we would get more queries
[06:18] <kiko> carlos, can you give me a path against localhost?
[06:18] <kiko> or paths
[06:18] <carlos> sure
[06:18] <carlos> kiko: http://localhost:8086/distros/ubuntu/hoary/+source/evolution/+pots/evolution-2.2/es/+translate
[06:18] <carlos> that should be enough
[06:19] <kiko> ddaa, did you notice the uncaught ConnectionError exception in update-branches.py yesterday?
[06:19] <carlos> at least it has a second template to look suggestions at
[06:19] <kiko> great
[06:19] <ddaa> kiko: nope
[06:20] <kiko> ddaa, msged you on traceback
[06:20] <kiko> carlos, nice reduction of failures in rosetta-poimport
[06:20] <kiko> you should really get the getPORevisionDate bug fixed
[06:20] <ddaa> kiko: generally, there are a few things I'd like to fix in that script, like improving logging, supporting database bounces, etc. But as long as it's working most of he time there are more urgent issues for me to work on.
[06:20] <kiko> okay
[06:20] <carlos> yeah, that's the next step
[06:21] <kiko> I was just suggesting a try/except, ddaa, not the eiffel tower IYKWIM :)
[06:21] <ddaa> kiko: but thanks for telling me
[06:21] <kiko> sure
[06:22] <ddaa> kiko: I might actually get a few idle cycles this week. I'll try to look at it.
[06:22] <kiko> okay, cool
[06:25] <carlos> cprov: hi, how is going that mawson test?
[06:26] <cprov> carlos: bad, have no DB login yet, but current pgsql is already 8
[06:26] <carlos> ok
[06:26] <carlos> cprov: please, ping me if you get it ready today
[06:26] <cprov> carlos: sure
[06:27] <carlos> cprov: thanks
[06:28] <cprov> carlos: unfortunatelly, stub left me with no information about the current state of the task, we may need to wait til tomorrow morning
[06:28] <kiko> ARGH
[06:28] <carlos> ok
[06:28] <kiko> I HATE HEARING THAT
[06:29] <kiko> salgado, read my reply to your question above, sorry for not saying your name
[06:31] <salgado> kiko, the one about fixing 31390?
[06:31] <salgado> or rather, marking it fixed
[06:38] <kiko> right
[06:38] <kiko> probably package-reassigning it too
[06:44] <kiko> matsubara, I'm confused by bug 31364.
[06:44] <Ubugtu> malone bug 31364 in launchpad "BinaryPackageRelease is either unused or untested" [Normal,Needs info]  http://launchpad.net/bugs/31364
[06:44] <kiko> matsubara, did you explain to mpt what the exact problem we were having was?
[06:45] <kiko> or is the problem caused by null right portlets some other bug?
[06:46] <matsubara> kiko: nope. I just pointed him to the page that uses binarypackagerelease.pt
[06:47] <kiko> matsubara, well, you didn't help him very much then.
[06:47] <kiko> can you please follow-up through email and explain the actual problem?
[06:48] <kiko> I've commented on the bug clarifying
[06:49] <matsubara> kiko: I think you're confused
[06:50] <kiko> am I?
[06:51] <kiko> matsubara, are we not talking about the bug where the page layout blows up when you remove the right portlet?
[06:51] <matsubara> kiko: the bug you explained to him is bug 31342
[06:51] <Ubugtu> malone bug 31342 in launchpad "Launchpad main_template is broken when there's no actions portlet" [Normal,Confirmed]  http://launchpad.net/bugs/31342
[06:51] <kiko> oh. doh.
[06:51] <kiko> I am confused.
[06:51] <matsubara> indeed
[06:52] <kiko> NEVER MIND MEEEE
[06:53] <kiko> matsubara, daf: what is the bug used for +translate timeouts?
[06:54] <kiko> because bug 31406 and bug 31410 are dupes of it
[06:54] <Ubugtu> malone bug 31406 in launchpad "OOPS-45C507 when trying to add source package openoffice.org2 to a bug report" [Normal,Unconfirmed]  http://launchpad.net/bugs/31406
[06:54] <Ubugtu> malone bug 31410 in rosetta "OOPS-45A501 Timeout opening translation page" [Normal,Confirmed]  http://launchpad.net/bugs/31410
[06:55] <matsubara> kiko: bug 31406 is a dupe of 4845 and it's already duped.
[06:55] <Ubugtu> malone bug 31406 in launchpad "OOPS-45C507 when trying to add source package openoffice.org2 to a bug report" [Normal,Unconfirmed]  http://launchpad.net/bugs/31406
[06:58] <matsubara> kiko: and I thought bug 31410 was a dupe of bug 31333, but daf was explaining to me the issue, but had to leave. we'll sort this out late when he comes back.
[06:58] <Ubugtu> malone bug 31410 in rosetta "OOPS-45A501 Timeout opening translation page" [Normal,Confirmed]  http://launchpad.net/bugs/31410
[06:58] <Ubugtu> malone bug 31333 in rosetta "Separate update in POST from rendering of form via redirect()" [Normal,Fix released]  http://launchpad.net/bugs/31333
[06:58] <matsubara> s/late/later/
[06:59] <kiko> hmmm
[06:59] <kiko> matsubara, I think both are dupes of the same bug, but...
[06:59] <kiko> bug 4845
[06:59] <Ubugtu> malone bug 4845 in malone "assigning of package bug targets needs input validation" [Normal,In progress]  http://launchpad.net/bugs/4845
[06:59] <kiko> matsubara, I don't think bug 4845 is what you meant. :)
[06:59] <Ubugtu> malone bug 4845 in malone "assigning of package bug targets needs input validation" [Normal,In progress]  http://launchpad.net/bugs/4845
[07:00] <matsubara> check out the oops for bug 31406
[07:00] <Ubugtu> malone bug 31406 in launchpad "OOPS-45C507 when trying to add source package openoffice.org2 to a bug report" [Normal,Unconfirmed]  http://launchpad.net/bugs/31406
[07:00] <matsubara> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-14/C507
[07:01] <kiko> I typod
[07:19] <kiko> bradb, are you planning on fixing bug 31414?
[07:19] <Ubugtu> malone bug 31414 in malone "Source and Binary Package Name on the +editstatus page are confusing" [Normal,Unconfirmed]  http://launchpad.net/bugs/31414
[07:19] <kiko> bradb, could it be fixed by dropping binary package name from the schema entirely?
[07:21] <bradb> kiko: Maybe though dropping binary package will (1) lose information and (2) make the UI a bit more confusing, i.e. the user might wonder why, after setting package name to "foo-doc" it got "changed" to "foo"
[07:22] <bradb> And there's no way to workaround it, if we're not storing foo-doc anywhere.
[07:22] <kiko> we can add it to the initial comment/description.
[07:22] <kiko> (strawman)
[07:23] <bradb> I can imagine that it could be useful to know the exact bp as well, in the case of weird apt-get install errors.
[07:23] <bradb> kiko: If we would store it in the comment/description, we might as well just store leave it in the schema.
[07:24] <bradb> s/store leave/leave/
[07:24] <kiko> no
[07:24] <kiko> we could say "Initially reported against binary package name: XXX"
[07:24] <carlos> SteveA, kiko: I have the AJAX thing working now with some hardcoded values
[07:24] <kiko> and then you wouldn't need to take care of editing/changing/fixing it as we go
[07:24] <carlos> it lacks tests but if you want to take a look...
[07:24] <kiko> carlos, have a URL for testing?
[07:25] <carlos> to my local launchpad installation?
[07:25] <carlos> let me open the port
[07:25] <bradb> kiko: That wouldn't be useful information, IMHO. When a developer comes along and changes the bug to be on the correct source package, the "Initially reported on ..." just pollutes the comment.
[07:26] <bradb> Best to ask the Ubuntu devs though.
[07:26] <ddaa> kiko: !!!
[07:26] <kiko> bradb, then drop the field completely -- mdz has said so already
[07:26] <kiko> ddaa, I'll be your huckleberry
[07:26] <ddaa> how can that ConnectionError possibly happen in the first place???
[07:26] <ddaa> "No route to host" !?!?!
[07:26] <bradb> kiko: Why did he want to drop it?
[07:26] <kiko> ddaa, datacenter migration maybe?
[07:26] <kiko> bradb, because it's useless complexity?
[07:26] <kiko> that's what I recall at least
[07:27] <ddaa> kiko: nothing was migrated on tuesday...
[07:27] <bradb> kiko: It is now, but it needn't be.
[07:27] <bradb> kiko: And it's definitely not useless.
[07:27] <kiko> bradb, make your case, but I'd be in favor of dropping it and doing what I suggest above.
[07:28] <bradb> e.g. jbailey sometimes knows the binary package that a bugtask should be reported on, and can't be arsed to look up the source package. if he sets the task on "foo-doc" and the page returns with simply "foo", that's confusing.
[07:28] <bradb> (this use case comes from a chat yesterday with jbailey)
[07:28] <kiko> I'll talk to jbailey, but even risking repeating myself, I WANT TO DROP THAT FIELD :)
[07:29] <jbailey> (three nick highlights in a row is actually enough to get my attention...)
[07:29] <bradb> kiko: Yeah, I knew you weren't /really/ "asking" me if it should be dropped. :)
[07:29] <jbailey> bradb: It's less a case of "can't be arsed" as to "you're a computer, you figure it out."
[07:29] <bradb> jbailey: Absolutely.
[07:30] <kiko> bradb, I asked if it "could be dropped".
[07:30] <bradb> 98% of my interactions with software fall into that category
[07:30] <kiko> jbailey, note that you would still retain that, with the advantage of not needing to maintain the field later.
[07:30] <bradb> kiko: It needn't be maintained if we fix the bug.
[07:30] <jbailey> kiko: Sounds like the right solution.  That way I can just type "libc6" in and have it automatically know the right thing/
[07:31] <jbailey> I shouldn't have to care that the source package might be different.
[07:31] <bradb> indeed
[07:31] <bradb> I believe having only one editable field on that form makes sense.
[07:31] <jbailey> Right.
[07:31] <jbailey> "package"
[07:31] <bradb> (i.e. one "package name" field)
[07:31] <bradb> yeah
[07:31] <jbailey> source or binary, either way.
[07:31] <carlos> kiko: So, should I stop the AJAX task for the moment or finish it?
[07:32] <kiko> jbailey, exactly -- you'd be allowed to enter the binary package, the filed-a-bug message would say "Filing bug against glibc-devel (implied from binary package libc6)"
[07:32] <carlos> kiko: If you think there are other high priority tasks I don't have any problem to leave it for a while and finish it later
[07:32] <kiko> jbailey, I just don't want us to lug around the extra binary package name field
[07:32] <kiko> jbailey, and now have to add constraints to make it make sense
[07:32] <kiko> carlos, I think it's nice to put the branch up for review as-is
[07:32] <kiko> and then focus on other stuff
[07:33] <bradb> jbailey: Is it never useful to know about the specific bin pkg for a bug? e.g. with weird installation or config errors?
[07:33] <carlos> kiko: It lacks tests or old tests fixes
[07:33] <jbailey> kiko: It's probably worth double checking with two heavy debbugs users to ask them if there's ever a case where the binary package is needed.
[07:33] <kiko> jbailey, bradb, OIthe information would be 
[07:33] <kiko>  errr
[07:33] <kiko> jbailey, bradb, Othe information would be 
[07:33] <kiko> jbailey, bradb, I'm proposing the information would be stored in the initial description
[07:33] <carlos> kiko: is that ok? I suppose if I warn the reviewer it should not be a problem (I'm not going to merge the branch until it's finished)
[07:33] <kiko> Initially filed against binary package foo
[07:34] <kiko> so you would know the name
[07:34] <jbailey> bradb: I haven't come across a need for it, but I'm not a heavy debugs user.  The only thing I generally get from the binary package name is infered arch information.
[07:34] <jbailey> kiko, bradb: Kamion and seb128 are the two I'd probably check with on that.
[07:34] <kiko> right
[07:35] <carlos> see you tomorrow!
[07:35] <kiko> carlos, no problem at all
[07:35] <jbailey> Both of them have experience with debbugs which keeps them separate and would probably be able to tell you their use cases for that information.
[07:35] <bradb> jbailey: If you guys never have a need to keep the binary package name around, then I agree it should be dropped. If there's any need for it though, storing it in the description would mean even more clicks and page loads to look at and maintain that information.
[07:35] <carlos> kiko: ok
[07:35] <carlos> cheers
[07:35] <bradb> but yeah, seb and Kamion 
[07:35] <jbailey> MMmm
[07:35] <kiko> bradb, again, the information is only marginally useful, probably in rare cases
[07:36] <jbailey> The kernel folks, maybe, too, since their binary package information actually encodes the ABI information.
[07:36] <jbailey> But possibly growing the ability to associate bugs with versions that Soyuz knows about would solve that, too.
[07:36] <kiko> that is infestations 
[07:36] <kiko> but I never said that
[07:37] <jbailey> Yeah, I keep forgetting what the name for it is.
[07:38] <bradb> Kamion: Do you have any reason to want to know specific binary packages that a bug affects?
[07:39] <bradb> Or lamont?
[07:39] <kiko> bradb, you will know the specific binary package, that's not the right question.
[07:40] <kiko> question is whether you want to filter, sort or group by it
[07:40] <bradb> kiko: If we store it in the description, sure, but I think I've already given reasons for why that's not a good idea.
[07:41] <kiko> I haven't agreed with them.
[07:42] <bradb> I was already getting complaints about maintaining that information on the +editstatus page, I can't imagine that having to force people to click over to +edit, change, and Save, is a way to make it easier to maintain that information. (And, as I say, I agree that only one "package name" field should be on the +editstatus page, just that we should also show bp there, if useful.)
[07:42] <kiko> bradb, what do you mean, change?
[07:42] <kiko> I think you're confused.
[07:43] <kiko> I am only suggesting allowing entering a binary package when /filing/ a bug
[07:43] <kiko> looking up the source package for it
[07:43] <kiko> and indicating the binary package in the inital description
[07:43] <kiko> period
[07:45] <bradb> kiko: If bp pkg name is sometimes important, than maintaining that information becomes a burden because, when important, it means going to +edit and changing it there, instead of just editing the "Package Name" field on +editstatus, and seeing info about the bp (if we know it) right up with the other task info. Also, desc is bug-wide.
[07:45] <bradb> s/than/then/
[07:46] <kiko> bradb, I said INITIAL.
[07:46] <kiko> the binary package information is not important. they didn't even have it in bugzilla
[07:47] <jbailey> kiko: bugzilla is not the pinnacle of bug tracking.
[07:48] <jbailey> It's a feature that debbugs does have - that's why I think it's worth asking some of the heavy users of it to figure out how it gets used.
[07:50] <kiko> this has nothing to do with how good or bad bugzilla is
[07:50] <kiko> I'm just pointing out it was something the previous bug tracker lacked and that hasn't come up as a bug malone feature we're lacking
[07:50] <kiko> anyway, I GIVE UP
[07:50] <jbailey> Right, I'm simply challenging your assertion that its inexistance in bugzilla proves its unimportance.
[07:50] <kiko> damned bilkeshedders
[07:51] <kiko> can't type today either for some reason
[07:57] <mdz> its presence in bugzilla is nothing but a pain in the ass for me
[07:57] <mdz> er, in debbugs
[07:58] <mdz> the binary package is only interesting as a convenience to the user
[07:58] <mdz> who may not know the source package name but only the binary package name
[08:00] <bradb> If the binary package is pretty much never useful then I agree that it should be removed.
[08:00] <bradb> We'd have to accept the tradeoff that this will sometimes confuse users (e.g. when they edit the "package name" to "foo" and it changes to "bar", because "bar" is the package name.)
[08:01] <bradb> s/the package name/the source package name/
[08:13] <jbailey> bradb: Is it trivial to just list the binary packages next to the source name?
[08:14] <jbailey> Or is that another 70,000 row query with SQLObject? =)
[08:15] <kiko> it's another join
[08:15] <bradb> jbailey: Do you mean that if I enter "foo", and the sp is "bar", that the "Package Name" (editable) field would say "bar", and "foo" would be shown somewhere beside that?
[08:15] <kiko> not sqlobject's fault
[08:15] <jbailey> bradb: Right.  Like Package: glibc (libc6, libc6.1, libc6-dev, libc6.1-dev, glibc-docs, nscd)
[08:16] <bradb> jbailey: ah, showing all the bp's. I don't think we have room for that, tbh.
[08:16] <jbailey> Then no worries.
[08:16] <jbailey> Actually, glibc's probably among the nastier ones: 
[08:16] <jbailey> Binary: libc6-dev, libc1-udeb, libc6-amd64, libc6-dev-i386, nscd, libc0.3-dbg, libc6.1-dev, libc6-s390x, libc1-dbg, libc6.1-pic, libc0.3-dev, libc6-ppc64, libc0.3-prof, libnss-files-udeb, libc6.1, libc6-prof, libc6, libc0.3-pic, libc0.3-udeb, libc0.3, libc1-pic, libc6-dev-s390x, libc6-pic, libnss-dns-udeb, zoneinfo-udeb, libc6.1-udeb, libc6-dbg, libc6-i386, libc6-sparc64, libc1-dev, libc6-sparcv9b, libc6-dev-ppc64, libc1, li
[08:16] <jbailey> bc6.1-prof, libc6-udeb, libc6-dev-amd64, libc6-i686, libc6-dev-sparc64, libc6.1-dbg, libc1-prof, glibc-doc
[08:23] <dilys> Merge to devel/launchpad/: Fix OOPS-45D553 and add test for it. r=kiko (r3148: Diogo Matsubara)
[08:24] <kiko> that's me and matsubara rocking the boat
[08:24] <jbailey> "The motion of the ocean:
[08:24] <jbailey> "
[08:25] <kiko> matsubara, next time, include a description of what you are fixing in your commit message
[08:25] <kiko> it makes it very hard to report the commit later
[08:25] <kiko> thanks
[08:27] <matsubara> kiko: ok, I usually put the bug title, since that doesn't have one, I forgot.
[08:27] <kiko> I know
[08:54] <dilys> Merge to devel/launchpad/: [trivial]  Fixes to link-external-sourcecode, the slacker's best friend: sanity check invocation and paths, force linking (r3149: kiko)
[08:54] <kiko> yes!
[08:54] <kiko> yes!
[08:54] <kiko> take THAT pqm
[08:58] <lifeless> moin
[08:58] <lifeless> SteveA: thats why I want to run the all the tests on every commit again
[09:08] <cprov> see you tomorrow, guys
[09:15] <kiko> matsubara, remind me -- isn't bug 31398 a dupe?
[09:15] <Ubugtu> malone bug 31398 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Normal,Unconfirmed]  http://launchpad.net/bugs/31398
[09:19] <johnl> hi, can anyone provide any more information on the launchpad source code situation?  I know it's not open...
[09:19] <kiko> johnl, it's not, indeed. what other information can I provide you?
[09:21] <johnl> hi kiko
[09:21] <johnl> well I'm wondering what the plan is.  what the motivations are etc.
[09:21] <johnl> i can't seem to find much info
[09:21] <johnl> other than the launchpad faq
[09:21] <kiko> the plan is to eventually open-source it.
[09:22] <matsubara> kiko: duped it. it's a dupe of bug 30605
[09:22] <Ubugtu> malone bug 30605 in rosetta "Timeout at +translate page" [Normal,Unconfirmed]  http://launchpad.net/bugs/30605
[09:22] <kiko> right now it is still too much in heavy design work to be usefully open-sourced
[09:22] <kiko> matsubara, I think it's a dupe of a much earlier bug
[09:24] <kiko> matsubara, what about bug 30602?
[09:24] <Ubugtu> malone bug 30602 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Normal,Unconfirmed]  http://launchpad.net/bugs/30602
[09:24] <kiko> and 30604?
[09:24] <kiko> and 30605?
[09:24] <kiko> matsubara, I think those are all dupes of the same bug
[09:24] <johnl> kiko: cool.  has it not been commented on officially anywhere? a mail from the spaceman perhaps?  (no offence, I don't know who you are)
[09:25] <kiko> bug 30607 too
[09:25] <Ubugtu> malone bug 30607 in rosetta "Timeout Error" [Normal,Unconfirmed]  http://launchpad.net/bugs/30607
[09:25] <matsubara> kiko: the query expiring is different
[09:25] <kiko> johnl, no publically-archived mail from the spaceman, unfortunately, but he has made it clear that he wants to OSS it when the time is right.
[09:25] <kiko> matsubara, it is the same problem I suspect
[09:25] <kiko> too many queries in +translate
[09:26] <kiko> you can study the oops logs if you like
[09:26] <kiko> but then give us a report on what is a problem
[09:26] <johnl> kiko: ok thanks.  I'd suggest putting that in the faq.  put a few minds at rest :)
[09:27] <kiko> I'll do that this week, sure.
[09:27] <kiko> thanks for the feedback
[09:33] <kiko> matsubara, bug 30610
[09:33] <Ubugtu> malone bug 30610 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Normal,Unconfirmed]  http://launchpad.net/bugs/30610
[09:34] <matsubara> kiko: it's marked as a dupe of 30602
[09:34] <kiko> I think they are all dupes
[09:35] <matsubara> bug 30605 follows a different code path than bug 30602
[09:35] <Ubugtu> malone bug 30605 in rosetta "Timeout at +translate page" [Normal,Unconfirmed]  http://launchpad.net/bugs/30605
[09:35] <Ubugtu> malone bug 30602 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Normal,Unconfirmed]  http://launchpad.net/bugs/30602
[09:35] <kiko> does anyone have a lot of scrollback from this channel?
[09:35] <kiko> I needed a URL carlos posted to me a while back
[09:36] <matsubara> how long?
[09:36] <kiko> I found it
[09:43] <dholbach> hell
[09:43] <dholbach> hello :)
[09:43] <dholbach> Is the infrastructure for giving back source packages in place already?
[09:57] <kiko> matsubara, if all those pages are more than 2000 queries, they are all dupes
[09:58] <kiko> the bug summary is +translate issues MIND-BOGGLING number of queries
[09:59] <matsubara> kiko: one is 148 queries and another is 275, is this unusual?
[09:59] <kiko> that's quite low actually
[09:59] <kiko> they are potentially not dupes then
[09:59] <kiko> have you seen any of these multi-million-query oops?
[10:00] <matsubara> nope
[10:00] <kiko> look at the launchpad list for some email I sent on monday or tuesday
[10:02] <matsubara> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-09/A547
[10:04] <kiko> right
[10:04] <kiko> matsubara, if you see one of those flag it
[10:04] <kiko> and try and improve the summary of bugs you are duping
[10:04] <kiko> to make sure the dupe targets are clearer
[10:05] <matsubara> ok
[10:13] <Kamion> bradb: the chief reason I've found for wanting binary packages is rough categorisation: for example, the bug reports against dpkg source that are on the dselect binary package can very productively be grouped separately, since they're basically an entirely separate set of bugs
[10:13] <Kamion> bradb: there may be better ways to achieve that categorisation than grouping by binary packages; I'm not saying that's the only way or even the best way to do that
[10:13] <Kamion> locales bugs against the glibc source are another example
[10:13] <Kamion> (although no longer applicable in Ubuntu dapper, I guess)
[10:14] <Kamion> comparing http://bugs.debian.org/src:dpkg with http://bugs.debian.org/dselect should provide a relatively good use case
[10:17] <bradb> Kamion: Do you have many packages where binary-package-related bug categorization would be helpful?
[10:19] <Kamion> personally?
[10:21] <bradb> Kamion: You, or others that you know would benefit from this.
[10:22] <Kamion> a few - in the past I've found it useful in cdebconf, debian-installer-utils, groff, openssh
[10:22] <Kamion> but it's not really crucial in any of those cases
[10:22] <Kamion> it seems to be a matter of personal taste so I don't know that I'd want to speak for other maintainers
[10:23] <Kamion> some kind of fairly arbitrary user-controllable categorisation where you can attach keywords of your choice to bugs and search by those would do just as well, for example
[10:23] <Kamion> the usertags stuff added to debbugs recently seems popular, although it's not exactly easy to use
[10:24] <Kamion> to set up, that is
[10:24] <bradb> ok, thanks for the info
[10:53] <daf> matsubara: I'm back if you still have stuff you want to talk about
[11:18] <SteveA> kiko: 
[11:19] <SteveA> kiko: read the launchpad list.  i've done some analysis on rosetta queries.
[11:21] <ddaa> Hey SteveA (or kiko), who do you think should be assigned bug 31106 ?
[11:21] <Ubugtu> malone bug 31106 in launchpad "Show URL of launchpad branch mirrors" [Normal,Confirmed]  http://launchpad.net/bugs/31106
[11:22] <ddaa> I'd be happy to take ownership of it, but I'm notoriously bad at getting around to  fixing bugs.
[11:23] <ddaa> (also, it cannot be fixed right now because it would conflict with daf's patch)
[11:26] <SteveA> jamesh: around?
[11:26] <SteveA> ddaa: you could ask daf about it
[11:26] <ddaa> daf: ^
[11:26] <SteveA> it's a bit late at night, though
[11:27] <SteveA> an email to the mailing list might be better
[11:27] <ddaa> he was around less than 30 mins ago
[11:29] <daf> hi
[11:29] <SteveA> daf: go to sleep! :-)
[11:29] <daf> which page(s) do the URLs need to be shown on?
[11:29] <daf> SteveA: isn't it 00:30 for you?
[11:30] <SteveA> yes it is
[11:30] <SteveA> i've been doing some very exciting query analysis
[11:30] <SteveA> we can trivially cut +translate page times in half
[11:30] <daf> so exciting that it's keeping you awake, evidently
[11:30] <daf> oh, that *is* exciting
[11:31] <daf> how?
[11:31] <ddaa> daf: the $branch/+index page
[11:31] <ddaa> daf: I think you are familiar with that page :)
[11:31] <daf> indeed :)
[11:31] <daf> ddaa: assign the bug to me
[11:31] <SteveA> it is conceivable that we can get a +translate page down from 12 seconds to just 2.5 seconds
[11:31] <daf> that would make me very happy
[11:32] <SteveA> although, that involves more work.
[11:32] <SteveA> but we can see it is possible
[11:32] <daf> +translate is one of the biggest sources of OOPSes
[11:32] <SteveA> but, cutting it in half would be a big gain
[11:32] <daf> absolutely
[11:32] <daf> presumably this involves the big query on POSubmission
[11:33] <SteveA> look at the spreadsheet i attached
[11:33] <SteveA> it speaks for itself
[11:34] <daf> ah, email; I'll read it in the morning
[11:34] <SteveA> yes
[11:34] <SteveA> me too
[11:37] <daf> good night SteveA