[12:33] <laszlok> how come rosetta doesnt have an option to translate into English (US)?
[12:44] <kiko> laszlok, well, would it really make sense? what package/product would you choose to translate?
[12:45] <laszlok> well all out strings are british english
[12:45] <laszlok> *our
[12:50] <kiko> laszlok, you can check with danilos tomorrow about it. I think there's a bug open to allow that; but for it to be really efficient you really should have a way of starting your translation off based on English (UK). you also need a way to specify your product is primarily English (UK), hmmm.
[12:55] <laszlok> cause it should be allowed for any language
[02:46] <Keybuk> lp_archive@drescher:~/syncs$ change-override.py -c universe -t ept
[02:46] <Keybuk> 00:45:26 ERROR   u'Source package ept not published in edgy'
[02:46] <Keybuk> yet
[02:46] <Keybuk>        ept | 2.0ubuntu1 |          edgy | source
[02:46] <Keybuk> ?!
[03:58] <stub> lifeless: That importd test that is hanging (actually, I think there is more than one) is baz2bzr hanging inside a pybaz call. Do you know of any debug output available to track it down further, or am I stuck stepping through with a debuggged?
[04:00] <lifeless> do you changes affect the presence/absence of twisted in the importd tests ?
[04:01] <lifeless> twisted plays silly buggers with SIGCHILD
[04:01] <lifeless> which causes pybaz to hang
[04:01] <lifeless> unnless its used with a compatability layer we created and that requires using callFromThread
[04:02] <lifeless> erm
[04:02] <lifeless> callInThread I mean
[04:02] <lifeless> (no I'm not aware of debug output in pybaz)
[04:32] <stub> What do you mean affect the presence/absence of twisted? Bits of twisted that used to be imported and are now not?
[04:33] <stub> Hmm... blechy. The test helpers have been refactored, so twisted may now be loaded where it previously wasn't (or vice versa).
[04:37] <Keybuk> lifeless: when will people learn that the only appropriate thing to do with SIGCHLD is SIG_IGN ?
[04:37] <Keybuk> or, at most, an empty function with the signal masked out except when in poll()
[04:38] <Keybuk> (so poll exits if there's a child to be reaped)
[05:14] <lifeless> Keybuk: twisted uses it to get triggered on child events
[05:15] <lifeless> Keybuk: its reasonable, but it interacts. :(
[05:15] <Keybuk> except that almost all uses of it that way have bugs
[05:16] <Keybuk> void child_reaper (int sig) {
[05:16] <Keybuk>         while (waitpid (-1, NULL, WNOHANG) > 0)
[05:16] <Keybuk>                 ;
[05:16] <Keybuk>         /* what happens if the child terminates here */
[05:16] <Keybuk> }
[05:31] <mpt_> Gooooooooooooooooood afternoon Launchpadders!
[06:17] <mpt> stub, is staging in the process of restarting?
[06:22] <stub> mpt: The automatic rebuilds of the code are broken until an RT issue is done, although the database updates are still working. A manual update had not been done after the production update, so when the database was rebuilt it was out of date with the code and wouldn't start. Fixed now.
[06:27] <laszlok> can someone tell me why two of my uploaded PO files still say "Needs Review" even though I am the registrant or the product?
[06:49] <stub> lifeless: So from what I can tell, twisted will be imported in importd tests, as lib/importd/Job.py imports stuff from it. So I'm again stumped as to why pybaz is hanging.
[06:50] <lifeless> stub: you should ping ddaa
[06:50] <stub> Would it be particularly rude to disable the seven failing tests and open a bug?
[06:50] <lifeless> hes much more cluely about pybaz's internals
[06:50] <stub> He is also (hopefully) asleep ;)
[06:50] <lifeless> for that, I suggest talking with ddaa about that
[06:50] <lifeless> -sorry
[07:25] <sivang> morning
[07:25] <ChrisOnSpeed> morning
[09:08] <SteveA> good morning
[09:08] <danilos> morning SteveA
[09:08] <SteveA> morning danilo
[09:27] <sivang> hey danilos 
[10:58] <yama_> Does anyone know of a way to remove a team in launchpad from another team?
[11:04] <SteveA> yama_: I can help.  What exactly do you want to do?
[11:04] <yama_> Thanks SteveA. The ubuntu-l10n-en-us-fargo team [https://launchpad.net/people/ubuntu-l10n-en-us-fargo]  was created as a prank. They have, without permission, been able to add the Ubuntu English (Australia) Translators team (of which I am a member) and the Ubuntu English (United Kingdom) Translators team (of which I am an admin) to their group. Can this action be reversed and prevented from recurring?
[11:05] <SteveA> yama_: I'll take a look in a couple of minutes
[11:05] <sivang> SteveA: admin_browser is also in the name space of the pagetests running environemtn right ? (I can't find it in make harness though)
[11:05] <sivang> SteveA: (through functional.py IIRC)
[11:11] <SteveA> yama_: I'm in a meeting with someone at the moment, but I'll look at this soon.  Sorry for keeping you waiting there.
[11:12] <yama_> SteveA: that's ok. Thanks for your help.
[11:20] <jamesh> yama_: there is a bug open related to this: https://launchpad.net/products/launchpad/+bug/53637
[11:20] <Ubugtu> Malone bug 53637 in launchpad "Adding team 'Foo' as a member of team 'Bar' should require confirmation from one of the administrators of 'Foo'" [Low,Confirmed]  
[11:24] <yama_> that's *exactly* what I mean. I'm actually an admin of the team mentioned in that ticket
[11:25] <jamesh> that bug addresses the prevention of the problem in the future,
[11:25] <jamesh> rather than fixing the current problem
[11:27] <yama_> True. Can a Launchpad admin fix the current problem, please? I'll cross my fingers and hope it won't happen again.
[11:28] <elmo> wow, I'm glad salgado didn't put my hypothetical example in that bug report :-P
[11:30] <jamesh> the problem doesn't just relate to teams-as-members though.
[11:31] <yama_> it has actually been detrimental to us. I applied to have a lists.ubuntu.com.au mailing address, and the lists admin initially denied us because we were a member of ubuntu-l10n-en-us-fargo
[11:31] <jamesh> you could create a team with an offensive emblem or offensive name, then add a bunch of people to the team.
[11:31] <jamesh> the emblem and team name would show up on their user page til they did something about it
[11:32] <yama_> adding people isn't as bad a problem, since they can remove themselves
[11:32] <yama_> but if you add a team, nothing can be done about it, even by admins of that team
[11:33] <jamesh> well a team admin should be able to remove their team as a member of another team (whether or not salgado's idea of requiring approval is implemented)
[11:35] <yama_> yes, that's how it should work, but it doesn't at present :(
[11:35] <yama_> I don't mind a harmless prank, but this one is actually hurting us
[11:43] <stub> yama_: Sorted
[11:51] <yama_> Brilliant. Thank you!
[12:06] <SteveA> stub: did you sort it out?
[12:06] <SteveA> I just got out of my meeting
[12:06] <stub> SteveA: yes
[12:06] <SteveA> thanks stub 
[12:08] <lucasvo> how comes that this page https://launchpad.net/products/harmony/trunk says: No revision control details recorded for trunk even though I have uploaded a branch named trunk(https://launchpad.net/people/harmony-devs/+branch/harmony/trunk)
[12:08] <lucasvo> ?
[12:09] <lucasvo> how can I link these things?
[12:09] <lucasvo> when I edit the product series, I can only enter cvs or svn but not bzr
[12:17] <ddaa> Good morning
[12:31] <lucasvo> how can one link a product series with a hosted bzr branch?
[12:33] <SteveA> hi david
[12:40] <sivang> morning ddaa 
[01:14] <stub> ddaa: So on my test suite update branch, all the tests are passing except for 7 importd ones. These seven all hang when they run baz2bzr.
[01:15] <ddaa> stub: there's a nuke-baz2bzr-tests branch on sodium
[01:15] <stub> (sftp://sodium/home/warthogs/archives/stub/launchpad/librarian-layer)
[01:15] <ddaa> stub: feel free to merge it
[01:15] <stub> Excellent - is that up for review now?
[01:15] <ddaa> it's here just for that purpose
[01:15] <ddaa> rs=SteveA
[01:43] <sabdfl> SteveA: think you can play with the dot graph size and ratio parameters to make this one fit?
[01:43] <sabdfl> https://launchpad.net/products/launchpad/+spec/ui-1.0
[01:43] <sabdfl> section 2.4 in the dot users guide
[01:43] <sabdfl> should be no wider than we have for the page body in 3-col 1024x768
[02:03] <sabdfl> stub: how's canonical pillar names looking?
[02:08] <sabdfl> stu1: ^^
[02:09] <sabdfl> also, can we discuss https://launchpad.canonical.com/LaunchpadSearch?
[02:09] <stu1> eh?
[02:09] <sabdfl> oh.
[02:09] <sabdfl> (13:03:31) sabdfl: stub: how's canonical pillar names looking?
[02:09] <stu1> Still in review. Got punted from spiv's queue to jamesh's
[02:10] <sabdfl> bradb not around?
[02:12] <sabdfl> stub_:  on the search front, i want to do some work cleaning up the UI we currently present
[02:12] <sabdfl> do you want to be involved in tying that to the backend?
[02:13] <stub> Does it involve rewriting or attempting to maintain the existing search code? The bug search code for example has mutated into an absolute nightmare :-(
[02:13] <laszlok> jordi: two PO files i just uploaded are saying and a new template are saying "Needs Review"?
[02:14] <sabdfl> i want to be able to direct searches from a single search box to one of a number of different places
[02:14] <sabdfl> so we only ever have one search box on the page
[02:14] <sabdfl> below it, a list of thing you might want to seach for
[02:14] <sabdfl> which is context dependent
[02:15] <sabdfl> a set of radio buttons to specify
[02:15] <sabdfl> Search: [                               ]  [go] 
[02:15] <sabdfl>      (o) for a project
[02:15] <sabdfl>      ( ) for bugs in Gnomebaker
[02:16] <sabdfl>      ( ) for bugs in any project
[02:16] <sabdfl> make sense?
[02:16] <stub> So this is just rewiring to the existing search routines
[02:16] <sabdfl> yes
[02:16] <sabdfl> though, of course, those could get better too
[02:16] <sabdfl> the first option is to search through project/product/distro for a match
[02:16] <sabdfl> it's a navigational tool
[02:16] <sivang> matsubara: around ?
[02:16] <stub> ok. I can give that a shot. This been specced already, or do we look at it next week?
[02:17] <sabdfl> the second is to search for bugs in the current context
[02:17] <sabdfl> the third is to search non-private bugs across all projects
[02:17] <sabdfl> i'll do a braindump now
[02:17] <sivang> sabdfl: soon to be "new" ;-)
[02:18] <sabdfl> sivang: yes, thanks much
[02:18] <sivang> sabdfl: np
[02:25] <sabdfl> stub: tricky question is where to direct the search posting. that thing will need to know how to redirect it to the relevant place
[02:49] <salgado> stub, SteveA, around?
[02:50] <stub> salgado: yes
[03:00] <salgado> stub, so, about that soyuz doctest that actually documents a bug and the fix for it...
[03:00] <SteveA> re
[03:00] <salgado> I discussed it with malcc and he has a good point that the documentation we get as a side efect when writing a doctest can be very helpful in some cases
[03:02] <salgado> I think the problem we're having today is that we start to stick lots of different things in a single doctest, making it very complex to maintain and not helpful as documentation
[03:03] <salgado> that's why I thought it could be a good idea to have smaller doctests in a directory other than the system doctests, for documenting bugs and other small things alike.
[03:04] <stub> salgado: Sure. You can stick doctests anywhere you want, not just canonical/launchpad/doc
[03:05] <sabdfl> stub: https://launchpad.canonical.com/LaunchpadSearchUserInterface
[03:05] <malcc> stub: Incidentally, I'm currently unable to get the doctest to work in another location, I'm using FunctionalDocFileSuite but it looks like I don't get a librarian, any tips?
[03:05] <sabdfl> use cases and a mockup
[03:06] <stub> malcc: Until my branch lands, you need to start up the Librarian yourself. LibrarianTestSetup().setUp() and LibrarianTestSetup().tearDown().
[03:06] <stub> Ooh... it landed
[03:06] <malcc> Cool, I'll merge.
[03:07] <salgado> stub, cool. but do we have any doctest outside of canonical/launchpad/doc/ already?  I wanted to check to make sure it's okay to do this
[03:08] <stub> malcc: Now you just need to declare your tests layer as one of LibrarianLayer, LaunchpadLayer, LaunchpadFunctionalLayer, LaunchpadZopelessLayer
[03:08] <stub> salgado: Yes - I put a pointer in that email.
[03:08] <stub> lib/canonical/database/ftests/test_doctests
[03:08] <jamesh> stub: you are reporter of one of the tasks on bug 1
[03:08] <Ubugtu> Malone bug 1 in ubuntu-desktop "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
[03:09] <stub> I am? ok.
[03:09] <stub> jamesh: Hang on - tasks don't have reporters
[03:10] <jamesh> sure they do
[03:10] <salgado> they have owners
[03:10] <salgado> no?
[03:10] <jamesh> the field is owner, but it is displayed as reporter on the +editstatus page
[03:10] <jamesh> similar to bugs
[03:15] <stub> I see
[03:23] <jamesh> stub: so each time you reject a Launchpad bug and file it against the right ubuntu source package, you become reporter of another bug task, which in turn shows up on +reportedbugs
[03:25] <jamesh> perhaps it should be doing bug owner rather than bugtask owner
[03:27] <stub> It could be argued either way.
[03:28] <SteveA> stub: how long does it take to do an update of the staging DB with production data?
[03:32] <sivang> so, my patch for #52038 now includes 2 specs story test converted to test browser, including the rquired change. any reviewer up to it or should I wait for kiko when he gets up ?
[03:32] <sivang> (hehe's he original reviewer)
[03:33] <SteveA> sivang: you should be patient.
[03:33] <SteveA> andrew is on vacation
[03:34] <sivang> SteveA: ah, sorry, I wasn't becoming impatient, just wondering if I could get some more review from someone who hadn't seen it yet. Digo already noted to me about the 79 cols thingy which was good, sorry if I sounded so.
[03:39] <jordi>  laszlok: having a look
[03:40] <jordi> laszlok: the pot file is the same as the one you uploaded the other day?
[03:57] <sivang> SteveA: btw, 'latency' was referring to my IRSSI at the remote machine latency, not about review latency :-)
[03:58] <SteveA> I see.  I misread then :-)
[03:58] <sivang> SteveA: I should use a proxy, as this hampers typing and make me type things like "hehe's he" as above
[04:01] <jordi> danilos: hey dude
[04:43] <sivang> SteveA: what's the rationale behind 79 cols max code length convention ? 
[04:43] <SteveA> it is the law
[04:43] <SteveA> read PEP-8
[04:45] <sivang> SteveA: okya, will do :-)
[04:51] <kiko> morning
[04:51] <sivang> morning kiko !
[04:51] <ddaa> sivang: shared coding standards is one of the things that makes Python a productive programming language
[04:51] <sivang> ddaa: I see.
[04:51] <ddaa> it save programmer's time from arguing on code layout and reformatting one another's code
[04:52] <ddaa> Which I have seen to be a problem in real-life C projects.
[04:52] <sivang> ddaa: yes, I've seen also coding standards issues in C and C++ actually. they should be enfocred in university projects as well.
[04:53] <ddaa> the thing with Python is that almost everyone with some experience actually abide by Guido's rules
[04:54] <ddaa> While there is not a single widely agreed upon coding standard for C or C++.
[04:54] <sivang> right
[04:55] <sivang> I guess python's already strong orientaion towards coding style (read: tabs) makes people in the good mood of keeping things even slicker
[04:55] <jamesh> ddaa: btw, I put up a branch for review yesterday that improves the BranchVocabulary
[04:56] <kiko> thanks for the email sivang 
[04:56] <kiko> I'll look at it after flacoste's and cprov's
[04:56] <jamesh> ddaa: it uses branch unique names as the tokens the user sees rather than numeric IDs ...
[04:56] <sivang> kiko: np! thank you very much for the review .
[04:58] <ddaa> jamesh: that's great, there's a bug around open about that
[04:59] <ddaa> jamesh: will you take responsibility to upgrade that bug status?
[05:01] <ddaa> btw, when you do plan reviewing the latest importd-bzr-native?
[05:01] <ddaa> I am about to put in the final commit.
[05:03] <jamesh> ddaa: the only bug I saw was https://launchpad.net/products/launchpad-bazaar/+bug/4119, which is already marked fixed
[05:03] <Ubugtu> Malone bug 4119 in launchpad-bazaar "Branch.landing_target needs a BranchVocabulary" [Medium,Fix released]  
[05:03] <jamesh> ddaa: I'll try and get a look at your branch soon.  It's the -4 branch, right?
[05:04] <ddaa> jamesh: nope
[05:04] <ddaa> it's the 'importd-bzr-native' one
[05:04] <ddaa> it's in your review queue
[05:04] <ddaa> the -4 is merged already
[05:06] <jamesh> okay.  I'll look at it after stub's branch (which I've already done part of)
[05:11] <kiko> danilos?
[05:12] <kiko> I sent you a review of your patch, did you not get it?
[05:13] <ddaa> jamesh: https://launchpad.net/products/launchpad-bazaar/+bug/43807
[05:13] <Ubugtu> Malone bug 43807 in launchpad-bazaar "ProductBranchVocabulary token should be branch.unique_name" [Medium,Confirmed]  
[05:18] <kiko> heh
[05:18] <kiko> ddaa, can you please write up release notes for bzr-native?
[05:18] <kiko> ddaa, I'd like to include that in the next LP report.
[05:18] <ddaa> "It rocks"
[05:18] <kiko> ddaa, think 2-3 paragraphs, I'll edit it for you.
[05:19] <ddaa> Something like: context, achievement, impact?
[05:19] <SteveA> bradb: will you do the "tags for use in the launchpad project" page and agenda item?
[05:20] <bradb> SteveA: I'm currently writing it. :)
[05:20] <bradb> after that, i'll add it to the agenda
[05:20] <SteveA> cool, thanks.
[05:20] <SteveA> and thanks for writing the original email with the ideas in
[05:20] <LarstiQ> jamesh: it doesn't look like you actually removed the link from Coming Soon at wiki.python.org/moin/LaunchpadTracker?
[05:32] <SteveA> stub: ping
[05:37] <SteveA> kiko: do you know how to sync the staging database to production?
[05:41] <bradb> stub: ping
[05:44] <kiko> SteveA, I have no idea.
[05:44] <kiko> SteveA, and please don't do this now as I need to test some changes stub did for me!
[05:44] <ddaa> kiko: sent you some mail
[05:45] <kiko> thanks ddaa 
[05:45] <ddaa> I tried to avoid the temptation of using too many superlatives, but it's still probably far from as straightforward as possible.
[05:45] <ddaa> In the end, it's just a very boring internal change with almost no visible effect to users.
[05:46] <ddaa> About as boring as ultrasound surgery to remove a kidney stone
[05:47] <ddaa> Nobody notices the difference, except from the patient and the surgeon.
[05:47] <ddaa> But that makes a hell of a difference to them!
[05:48] <kiko> ddaa, well, this also allows us to start using these imports more directly, right?
[05:48] <ddaa> No, that makes no visible difference on what you can do with the data.
[05:49] <SteveA> we can import python
[05:49] <ddaa> Hu.
[05:49] <ddaa> Right, probably can try...
[05:49] <ddaa> Completely forgot about that bug,
[05:49] <ddaa> kiko: note, we can now import branches with more than 32000 revisions
[05:50] <SteveA> kiko: mind if I merge a little code onto staging and then restart it?  it is just specs related
[05:51] <kiko> SteveA, sure, go ahead.
[05:51] <kiko> I am just using the DB
[05:51] <SteveA> ta
[05:51] <jamesh> LarstiQ: it isn't a link anymore, so google should hopefully stop following it
[05:51] <LarstiQ> jamesh: Aah, like so.
[05:51] <jamesh> LarstiQ: and maybe people will stop clicking on it too
[05:51] <ddaa> SteveA: Didn't python switch to SVN recently?
[05:51] <SteveA> yes
[05:52] <LarstiQ> jamesh: the url is still there, but not in a form for direct consumption, got it.
[05:52] <ddaa> i think we probably want to wait for things like "rename support" before doing such a high profile import
[05:52] <SteveA> yeah, check it out
[05:52] <SteveA> https://blueprint.staging.launchpad.net/products/launchpad/+spec/ui-1.0
[05:55] <SteveA> bradb: nice page.  https://help.launchpad.net/TaggingLaunchpadBugs
[05:55] <bradb> SteveA: thanks
[05:56] <kiko> bradb, good work my man
[05:57] <kiko> bradb, perhaps a tag-description-url would be useful for a product/project? :-)
[05:57] <stub> SteveA: pong
[05:57] <stub> bradb: pong
[05:57] <bradb> kiko: something like that, maybe
[05:58] <bradb> stub: Can you tell me 1. how many milestones we have, and 2. how many have a dateexpected not null?
[05:58] <SteveA> hi stub.  i just merged my bpgv branch into staging to check how it works.  it's with pqm right now as a [trivial] .  possible to get it into production before next week?
[05:58] <stub> bpgv?
[05:58] <SteveA> beepeegeevee
[05:59] <SteveA> it's the branch where i've been doing graphviz work
[06:00] <stub> bradb: 130, with 78 having a null dateexpected
[06:00] <bradb> stub: thanks
[06:00] <stub> SteveA: If it applies cleanly to the production branch, yes.
[06:01] <danilos> jordi: hey
[06:02] <danilos> kiko: hey
[06:02] <danilos> :)
[06:02] <kiko> ho
[06:02] <danilos> a lunch took a bit longer
[06:07] <danilos> kiko: I got your review, will go for another round later today
[06:07] <kiko> danilos, it's not a big review eh!
[06:10] <danilos> kiko: I know, but I've been working on firefox import, and get to "small" things only an hour or so during the day
[06:10] <danilos> kiko: sorry about it
[06:10] <kiko> heh, sure
[06:22] <bradb> stub: Can you tell me 1. how many distinct bugs are tagged, and 2. how many bugtag rows there are?
[06:22] <SteveA> oh FFS
[06:23] <SteveA> anyone else seen twisted test failures?
[06:23] <SteveA> when submitting to pqm
[06:30] <SteveA> stub: what happened with the "run only necessary 3rd party tests on pqm merge to launchpad" stuff?
[06:30] <kiko> SteveA, I implemented it and stub enabled it.
[06:31] <kiko> SteveA, if you don't want to run twisted tests, knock them out of this line in sourcecode/Makefile
[06:31] <kiko> launchpad_test_dirs:=buildbot gnarly pybaz pygettextpo pygpgme sqlobject twisted zope
[06:32] <SteveA> cool. thanks
[06:51] <jordi> danilos: hey dud
[06:51] <jordi> danilos: so do you know where were' up to on the xaralx front?
[07:03] <stub> bradb: 39 bugs are tagged. There are 92 bugtag rows.
[07:03] <stub> There are 72 distinct tags ;)
[07:04] <jamesh> kiko: shouldn't launchpad_test_dirs just contain submodules that depend on launchpad?
[07:04] <jamesh> (not the reverse)
[07:08] <danilos> jordi: as I said, I don't even have the carlos' emails
[07:08] <danilos> jordi: and I wouldn't know where to look to find them, but I can try to work it up from the bottom up again
[07:08] <danilos> but that would be risky
[07:14] <danilos> jordi: can you forward me last emails from carlos, and I'll get in touch with the maintainer
[07:20] <dholbach> hellas!
[07:21] <sivang> hi dholbach 
[07:21] <dholbach> i'm not sure if anybody of you read http://wiki.ubuntu.com/BzrMaintainerHowto - it mentions ubuntu-dev and ubuntu-core-dev as teams for bazaar.launchpad.net - if i (or somebody else) was about to create a new product and wanted to use it, could $TEAM be $USER as well?
[07:22] <sivang> dholbach: you mean, instead of being restricted to fokls who were approved as either -dev or core-dev ?
[07:23] <dholbach> yes, not as a package, just as using bzr on launchpad for a project
[07:25] <sivang> I'm also interested in allwoing other people to commit to the bzr branch other then ubuntu-dev for home-user-backup
[07:25] <salgado> dholbach, yes, it can be $USER, but in that case only $USER would have permission to commit to that branch
[07:26] <dholbach> salgado: as long as everybody can branch from it and have their own branch, that's cool
[07:26] <dholbach> neat-o - thanks salgado!
[07:26] <salgado> dholbach, you're welcome. :)
[07:27] <kiko> jamesh, well, what I did was remove the least amount of modules necessary to avoid spurious errors
[07:27] <kiko> jamesh, I could have removed a whole lot more but stub and I were conservative
[07:28] <danilos> jordi: ping
[07:28] <jamesh> kiko: fair enough
[07:28] <kiko> jamesh, would /any/ modules stay on that line if we weren't conservative, though?
[07:28] <jamesh> kiko: btw, I put the formlib branch that me and BjornT have been working on today up on pending-reviews as work-in-progress
[07:29] <kiko> jamesh, woot, great news, I am ecstatic
[07:29] <jamesh> kiko: I don't think anything in sourcecode/ right now should break because of changes in the main launchpad tree.
[07:30] <kiko> jamesh, yeah, me neither. we could if we wanted drop all of them. but I won't make that call myself
[07:31] <jamesh> in the formlib branch, there is a new LaunchpadFormView class that can do pretty much everything GeneralFormView can plus more
[07:31] <jamesh> you can manage multiple action buttons among other things ...
[07:32] <jamesh> and you don't end up putting so much logic in the ZCML
[07:34] <ddaa> Okay. Let's get started on some fun stuff.
[07:39] <kiko> jamesh, that's most excellent
[07:45] <ddaa> Anyone can hint me at an easy way to do sftp operations?
[07:45] <ddaa> Specifically, checking for existence of a file, downloading and uploading a single file.
[07:46] <ddaa> I might be able to abuse bzrlib transports, but I am slightly reluctant to go down that road.
[07:47] <jamesh> maybe use paramiko directly?
[07:48] <jamesh> although the code to make paramiko use openssh as a transport is in bzrlib
[07:48] <ddaa> Yeah, i need only very simple operations, and it might make sense to reuse bzrlib for that.
[07:55] <jamesh> ddaa: did that hint about using urlparse.uses_netloc / urlparse.uses_relative help?
[07:56] <ddaa> that function did not _really_ need urlappend, so I just worked around the bug to keep focus
[07:57] <ddaa> and added tests, including checks for proper support of sftp URLs
[07:58] <ddaa> initially, it was just doing string addition
[07:58] <ddaa> urlappend was an attempt at being a better launchpad citizen
[07:59] <ddaa> Weird, there does not seem to be a way to explicitly close bzrlib transport
[08:10] <ddaa> Will use bzrlib, the transport abstraction makes it tons easier to test: tests can use filesystem names, and production can use sftp with the exact same code.
[08:14] <LarstiQ> pfs?
[08:14] <LarstiQ> pseudofilesystem?
[08:14] <ddaa> yeah
[08:14] <ddaa> the transport abstraction of GNU Arch
[08:14] <bradb> kiko: do you have time to review this IBugTarget.targetname change? it's a simple patch, mostly just moving code to a better place.
[08:15] <kiko> bradb, sure.
[08:15] <ddaa> LarstiQ: most of what he said never made sense to me, but I can see hands on how a portable dumb fs abstraction is handy
[08:16] <ddaa> incidentally, only vcs that support dumb server hosting need that concept, and I think that's only Arch and bzr so far.
[08:16] <LarstiQ> ddaa: yup, it is very convenient for demo coding too ;)
[08:17] <ddaa> The baz veterans might have interesting insights about that.
[08:17] <bradb> kiko: https://sodium.ubuntu.com/~andrew/paste/filegtcDa1.html
[08:19] <kiko> bradb, would you be against calling it "bugtargetname"? what does flacoste-lunch think?
[08:19] <bradb> kiko: oh, hmm...
[08:21] <kiko> bradb, I'm just asking because targetname is pretty arbitrary eh
[08:21] <bradb> friggin' ns conflict issues...
[08:21] <bradb> this smells bad
[08:22] <bradb> i.e. reading an interface, IBugTarget, with a "bugtargetname" attribute (even a "targetname" attribute) smells bad
[08:23] <kiko> displayname_for_bugs
[08:23] <kiko> bug_specific_displayname
[08:23] <kiko> etc
[08:23] <bradb> I'm trying to imagine a solution that could use adapters, so that the object only has the attribute you need when you actually adapt it, and thus no ns conflict issues...
[08:23] <flacoste> kiko: what do I think of what? targetname vs bugtargetname?
[08:24] <kiko> bradb, can you explain to flacoste what you're doing? :)
[08:24] <bradb> flacoste: IBugTargets have a display value, for when their name is shown in bug listings, on the bug page, etc.
[08:24] <flacoste> bradb: an IDisplayName adapter could be an interesting idea
[08:25] <bradb> I was thinking if having IBugTarget.displayname, actually
[08:25] <flacoste> could even be a multi-adapter getMultiAdapter( (context, view))
[08:26] <bradb> then using adaptation. bugtarget = IBugTarget(firefox). then it's okay for bugtarget to have a displayname that is different from IProduct's displayname, because it's an IBugTarget thingy now, not a product anymore.
[08:27] <bradb> flacoste: The current problem I'm trying to solve is that this targetname value should really be on IBugTarget, rather than where it currently is, IBugTask.
[08:28] <bradb> my first approach, consistent with how we normally solve this problem right now, was to call this attribute IBugTarget.targetname (or bugtargetname, whatever). but that smells pretty bad, because when you read interface IFoo, it's unclear why the attributes need to be called fooname, foodisplayname, foothis, foothat, etc.
[08:29] <flacoste> yes, i've noticed that
[08:30] <flacoste> I think that an IDisplayName interface would be an elegant solution to this problem
[08:30] <bradb> flacoste: so, what if I called this value IBugTarget.displayname, and use adaptation in callsites?
[08:30] <flacoste> the way i would do that actually is not to put a new attribute on the interface
[08:31] <bradb> flacoste: the point being that a IBugTarget's displayname will look different than the object's displayname in other contexts.
[08:31] <flacoste> using a multi-adapter you have this for free
[08:31] <flacoste> we could have an adapter that adapts IDistribution to IDisplayName in all context
[08:32] <flacoste> but we could define another one for use only in a specific view
[08:32] <flacoste> it is very flexible
[08:32] <bradb> flexible concerns me a bit. I want something simple.
[08:33] <flacoste> well, it is simple
[08:33] <flacoste> the hard work is already done in the zope component architecture
[08:34] <bradb> flacoste: i'm confused then. what does the callsite look to get a displayname for an IProduct in a bug-related view?
[08:34] <bradb> for what i'm proposing, it would look like: bugtarget = IBugTarget(firefox); bugtarget.displayname.
[08:35] <flacoste> assuming the callsite is in a view: 
[08:35] <flacoste> displayname = zope.component.getMultiAdapter((firefox, view)).displayname
[08:35] <flacoste> (replace view by self if you are in the view)
[08:36] <flacoste> and IDisplayName would be an interface with only a displayname attribute
[08:37] <bradb> hm
[08:37] <bradb> i find that somewhat harder to understand, tbh
[08:38] <flacoste> hmm, sorry
[08:38] <bradb> kiko: which one reads more clearly to you?
[08:38] <kiko> yours
[08:38] <kiko> and yours sounds more correct as well tbh
[08:38] <flacoste> it should be displayname = zope.component.getMultiAdapter((firefox, view), IDisplayName).displayname
[08:38] <kiko> flacoste, it's not limited to a specific view.. it's for anywhere related to bugs.
[08:38] <flacoste> but that could be replaced by an helper: displayname = getDIsplayName(object,view)
[08:39] <bradb> it could even be in email
[08:39] <flacoste> kiko: you define a marker interface that is implemented by all bug views
[08:39] <flacoste> or we use something else than the view for the context element: getDisplayName(object, context)
[08:39] <kiko> flacoste, sounds like additional complication.. for something that should be simple.
[08:40] <kiko> bradb, I am in theory okay with adaptation but that sounds like a larger project than you should be taking on at this point. do you agree? if so, file bug, XXX and bugtargetname.
[08:41] <flacoste> yeah, that's really an infrastructure discussion
[08:41] <bradb> kiko: I could have the patch fixed in half an hour.
[08:41] <bradb> but i'll file a bug instead, if you prefer, and mail the list about it
[08:41] <kiko> bradb, I can't r= something which uses adaptation, though SteveA could
[08:41] <kiko> it's going a bit beyond my autonomy in deciding the architecture of this thing, and I've already been told off once today :)
[08:42] <bradb> kiko: should i just rename for now then, file a bug, and mail the list for discussion? (because it's also a more general issue about the ugly things we've been doing to avoid ns conflicts)
[08:42] <kiko> bradb, that sounds most economical. :)
[08:42] <bradb> ok, i'll do that. /me starts renaming first
[08:43] <kiko> flacoste, bradb: lest I come across as a caveman, I think adaptation is the right answer here, I just don't want to make that decision on my own
 s/on my own/in your cave/ you mean
[08:44] <sabdfl> newz2000: nice work, it's getting there
[08:44] <kiko> ;)
[08:44] <newz2000> I've got a new idea for the top that's looking nice
[08:44] <newz2000> I'm hashing out the search box and will send another rev to you.
[08:45] <bradb> kiko: right, it's not a decision to make lightly
[09:13] <matsubara> ddaa: ping
[09:13] <ddaa> matsubara: pong
[09:13] <matsubara> ddaa: have you seen this: https://lists.ubuntu.com/mailman/private/launchpad-error-reports/Week-of-Mon-20060731/032475.html ?
[09:14] <matsubara> bzrsync.py is spamming the lp-errors@
[09:14] <ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/53825
[09:14] <Ubugtu> Malone bug 53825 in launchpad-bazaar "branch puller does not properly sanity checks branch data" [High,Confirmed]  
[09:15] <ddaa> It's a tad bit hard to fix a problem
[09:15] <ddaa> And not terribly high priority.
[09:15] <ddaa> I should update the bug
[09:15] <ddaa> I discussed it with lifeless
[09:15] <ddaa> The resolution is twofold
[09:15] <ddaa> (microbreak)
[09:17] <ddaa> 1. bzr should be fixed to check for this kind of invalid data in the fetcher
[09:17] <ddaa> so it would not end up visible by the branch scanner
[09:17] <ddaa> then we would remove that branch's data from the supermirror
[09:18] <ddaa> 2. the branch scanner should be upgraded to catche BzrError when accessing revision data and
[09:18] <ddaa> * file a oops
[09:18] <vinayy> can I get Ubuntu DVDs from shipit?
[09:19] <LarstiQ> ddaa: your microbreak prompts me to paste http://base0.net/archives/213-Work-and-Procrastination-A-six-hour-study-of-the-10+25-hack..html . It looked good, but I haven't tried it
[09:19] <mdke> vinayy: no, just cds. Ask in #ubuntu for more information
[09:19] <matsubara> thanks ddaa 
[09:19] <ddaa> * point to the oops from the branch page and say "this branch was mirrored successfully, but appears to be corrupt (OOPS-xyz)"
[09:19] <vinayy> thanks
[09:19] <ddaa> matsubara: Then it will spam the oops system...
[09:20] <ddaa> but I guess you are better equipped to deal with that.
[09:31] <stammi> hi, can i change my launchpad nick? i registered with a non WikiName.
[09:32] <kiko> stammi, sure you can
[09:32] <kiko> just +edit
[09:33] <bradb> kiko: https://sodium.ubuntu.com/~andrew/paste/fileADCDXJ.html with the rename, bug filed, and emailing the list now...
[09:34] <stammi> kiko what does +edit mean? 
[09:34] <kiko> stammi, edit your personal details on your page in launchpad
[09:42] <stammi> thanks kiko. i got it now
[09:42] <kiko> rock on
[09:42] <stammi> :)
[09:44] <laszlok> jordi: ping
[10:14] <jordi> laszlok: pong
[10:15] <jordi> danilos: will do
[10:17] <laszlok> jordi: the new POT file is the updated version with many more strings
[10:17] <laszlok> jordi: they are approved now but still waiting to be uploaded
[10:17] <jordi> laszlok: ok.
[10:18] <jordi> laszlok: it'll happen in a few hours, as the other time
[10:18] <laszlok> jordi: any reason why it waits almost 24 hours before becoming approved?
[10:29] <lucasvo> is there a bug filed about the userinterface, that huge dependency trees overlapp to the right panel.(e.g.: https://launchpad.net/distros/ubuntu/+spec/ltsp-convergence)
[10:32] <salgado> lucasvo, it seems to have been fixed already: https://staging.launchpad.net/distros/ubuntu/+spec/ltsp-convergence
[10:33] <lucasvo> lol
[10:33] <lucasvo> well, I wasn't hallucinating for sure
[10:33] <lucasvo> :;)
[10:33] <danilos> jordi: thanks
[10:49] <jordi> laszlok: not sure, normally it's not so slow (except when the queue is very busy)
[10:50] <jordi> danilos: what msgs do you need exactly?
[10:50] <jordi> apparently what needs to be done is to exec the script that deletes the offendign translations
[10:54] <sabdfl> kiko: quick phone call?
[11:08] <kiko> sabdfl, sure, but I am VERY busy today!
[11:08] <sabdfl> calling...
[11:08] <sabdfl> office number?
[11:08] <kiko> sure
[11:11] <danilos> jordi: well, I don't know where we are at; and I don't think I have the latest version of the queries carlos used to use
[11:11] <danilos> jordi: I need to know which users we want to delete translations from
[11:12] <danilos> jordi: and the last I understood from carlos was that initial list we have had was not correct
[11:12] <danilos> (or something; anyway, I don't even have that initial list)
[11:13] <danilos> jordi: btw, we also need to ask stub about it (he was the one executing queries for carlos on production; carlos only did it on staging)
[11:24] <kiko> SteveA, ommmm
[11:29] <sabdfl> mpt_: very cool competitive analysis - superb work
[11:31] <sabdfl> newz2000: http://technorati.com/discover/ is another tab style
[11:31] <newz2000> That looks sharp
[11:32] <newz2000> I think I can incorporate some of that into a combination of the one you sent 20 min ago and the one we worked on prior to that
[11:38] <jordi> danilos: I'll forward you all I can find
[11:40] <jordi> danilos: sent
[11:54] <robertj> sabdfl: has there been any more discussion about what must happen before launchpad can be opensourced?