[12:33] <ddaa> Got it!
[12:33] <kiko> ddaa, time for bed mr
[12:34] <ddaa> Is there a way to stick a class attribute into a TextWidget?
[12:34] <ddaa> kiko: come on, the girl is away, and I'm having fun doing some web stuff
[12:34] <kiko> ok. just this once
[12:35] <ddaa> fixing branch/+edit is a bit more fun than doing voodoo vcs machinery stuff
[12:41] <ddaa> yay, got wide TextWidgets!
[12:42] <kiko> bradb?
[12:46] <bradb> kiko: still going. this patch is not a drive-by. :P
[12:48] <kiko> bradb, ETA?
[12:48] <bradb> kiko: 20 mins
[12:48] <kiko> bradb, okay, mail it please. ;)
[12:49] <bradb> yeah, that's what i was doing
[01:01] <sabdfl> morning ajmitch
[01:01] <ajmitch> morning
[01:05] <mpool> hi there
[01:05] <mpool> could someone help me with https://launchpad.net/products/rosetta/+ticket/529 please?
[01:05] <mpool> hi sabdfl 
[01:07] <kiko-zzz> mpool, I saw that just the other day. 
[01:07] <kiko-zzz> mmmm
[01:07] <mpool> hello sleepy kiko
[01:07] <mpool> it's not a big deal but it just looks messy every time i log in
[01:10] <LarstiQ> hmm, there is a debian bug I'd like to attach to a product, is there a way I can directly do that, or do I have to file a malone bug first, and then link?
[01:12] <sabdfl> hey mpool
[01:14] <kiko-zzz> LarstiQ, what product is it? you first file the bug on the product, then you indicate it "+ also affects distribution"
[01:14] <LarstiQ> right, feh
[01:14] <LarstiQ> kiko-zzz: I'll just have to duplicate it then
[01:14] <kiko-zzz> duplicate?
[01:15] <kiko-zzz> you can do it to the original bug
[01:15] <kiko-zzz> what bugs are we talking about anyway?
[01:16] <kiko-zzz> vai LarstiQ 
[01:17] <LarstiQ> kiko-zzz: a bug was just reported in the dbts for paramiko
[01:17] <kiko-zzz> okay so far.
[01:17] <LarstiQ> kiko-zzz: now, I'd like that to show up under the launchpad product for paramiko, without extra effort
[01:17] <kiko-zzz> aha. the opposite problem ubuntu has!
[01:18] <kiko-zzz> LarstiQ, first, you convince the debian people to use launchpad. then.. 
[01:18] <LarstiQ> kiko-zzz: haha :)
[01:18] <kiko-zzz> yeah. you will need to file the bug on paramiko first and then link it
[01:18] <LarstiQ> yeah, I just did that
[01:18] <kiko-zzz> we could offer a "import this bug and link it" feature..
[01:18] <kiko-zzz> but that's way 2.0
[01:18] <LarstiQ> ok, it would be nice
[01:19] <LarstiQ> how about watching other bugtrackers for products?
[01:19] <LarstiQ> that is
[01:19] <kiko-zzz> for new bugs you mean?
[01:19] <LarstiQ> yes
[01:19] <kiko-zzz> well.. what's the point if those trackers aren't using LP?
[01:20] <LarstiQ> me not having to propagate manually anymore
[01:20] <kiko-zzz> do you mean filing bugs in their trackers?
[01:20] <kiko-zzz> or something else?
[01:20] <LarstiQ> something else
[01:20] <kiko-zzz> what would that SE be? :)
[01:21] <LarstiQ> in this specific case, I'd like for products/paramiko to get new bugs filed at bugs.debian.org/paramiko
[01:21] <LarstiQ> now, I see some problems with that
[01:21] <kiko-zzz> LarstiQ, oh. that's... an odd use case. ;)
[01:21] <LarstiQ> kiko-zzz: anything to safe me work ;)
[01:21] <LarstiQ> save? 
[01:22] <LarstiQ> but even if I trust people filing bugs in the dbts, I don't trust them all that much
[01:22] <kiko-zzz> well, you could reject them
[01:22] <LarstiQ> so a better option would be your import and link
[01:22] <kiko-zzz> but this is really something to take up with debian if you want proactive notification of bugs
[01:22] <kiko-zzz> however if you can be troubled to add the link
[01:23] <kiko-zzz> then import and link is the future
[01:23] <LarstiQ> I'm not upstream paramiko, but I am involved on the debian side
[01:23] <kiko-zzz> anyway, I'm outta here for now
[01:23] <kiko-zzz> peace!
[01:23] <LarstiQ> k, ciao!
[01:23] <lifeless> mornification
[01:36] <mpool> lifeless: hullo
[01:37] <lifeless> ola!
[01:59] <ddaa> lifeless: sorry, I got suckered into hacking launchpad and did not rollout the importd-bzr-upgrade patch
[02:00] <ddaa> will do that first thing tomorrow
[02:00] <ddaa> unless I f*cked in extensive ways, you should have nearly all-knits imports monday
[02:00] <lifeless> sweet
[02:01] <ddaa> on the other hand, I have started a nice patch to fix several issues with the branch forms
[02:01] <ddaa> with luck, I may even get around to finish and merge it, this time!
[02:04] <ddaa> mpool: lifeless: if you something to tell me, now is a good time, because I'm not going to be able to wake up early tomorrow.
[02:04] <mpool> hi ddaa
[02:06] <mpool> nothing to tell you in particular - sleep well
[09:08] <carlos> morning
[09:16] <sabdfl> anybody else seeing an odd failure in gpg-coc?
[09:29] <carlos> sabdfl: it's already fixed on rocketfuel
[09:29] <carlos> sabdfl: the test had a timebomb
[09:37] <sabdfl> right
[09:37] <sabdfl> fixed locally, will merge
[10:05] <carlos> danilos: hi, meeting time?
[10:06] <danilos> carlos: hi, sure
[10:12] <SteveA> carlos, danilos: let's have a brief talk on irc after your meeting
[10:13] <carlos> SteveA: ok
[10:13] <danilos> SteveA: sure
[10:17] <SteveA> and, good morning carlos, danilos!
[10:17] <danilos> SteveA: yeah, good morning :)
[10:17] <carlos> SteveA: good morning :-P
[10:22] <danilos> stevea: ping
[10:22] <carlos> SteveA: we are ready
[10:49] <carlos> sabdfl: http://blogs.gnome.org/view/rodrigo/2006/08/10/0
[10:50] <carlos> sabdfl: isn't that something like the Personal Packages Archive but for multiple distros ?
[10:50] <mdke> spiv: around?
[10:52] <sabdfl> carlos: yes, which is another reason to get PPA's done as soon as possible
[10:53] <spiv> mdke: yeah
[10:53] <seb128> j #ubuntu-bugs
[10:54] <danilos> j #freepr0n
[10:54] <mdke> lol
[10:54] <danilos> woops, a missing slash
[10:54] <danilos> :)
[10:54] <mdke> comedian
[10:54] <spiv> danilos: j #freeslashpr0n?
[10:55] <danilos> haha, yeah
[10:55] <Spads>  /nick Sp0ck
[10:55] <Spads> oh sorry.
[10:55] <mdke> mayhem
[10:56] <Spads> shenanigans.
[10:56] <danilos> :)
[10:56] <mdke> spiv: we've been mooting trying to get launchpad auth on the fridge (which runs drupal). Is the launchpad side of that quite straightforward now, or is there something private that needs to be done?
[10:58] <spiv> mdke: the launchpad side of that is the same as always; there's an xml-rpc interface (accessible only from inside the data centre) that can be called to authenticate users.  It's what the wikis use.
[10:59] <spiv> We'll perhaps support something like OpenID eventually, but for now that's what we have.
[10:59] <jamesh> should be okay for use by fridge
[10:59] <jamesh> provided drupal can use it
[10:59] <spiv> So it depends on how hackable drupal is to authenticate against an XML-RPC service rather than its normal database.
[10:59] <mdke> spiv: well, I presume that the fridge runs inside the DC too. However, it would require an employee to do the work on that?
[11:00] <spiv> mdke: the interface to code to isn't sensitive, so we could easily give the specs for what needs to be done to a non-employee
[11:00] <spiv> (the interface isn't complicated, either)
[11:00] <mdke> right. That sounds good
[11:00] <mdke> Ok, I'll look around for someone interested in having a hack at that
[11:01] <mdke> thanks
[11:01] <elmo> for the record: the fridge isn't run inside the DC (as far as the auth server goes) - it's crackful PHP with an insanely bad security history, so it's in a DMZ and appears outside the DC to the authserver
[11:01] <spiv> elmo: Ah, hmm.
[11:01] <mdke> what are the consequences of that for speaking to the authserver?
[11:02] <mdke> bit more tricky, or downright impossible?
[11:02] <elmo> don't know, not my call - probably need to talk to SteveA
[11:02] <mdke> ok, thanks
[11:02] <spiv> mdke: well, basically, the problem is we have to trust the fridge to be secure, because if someone can hack it then launchpad accounts, and thus security-sensitive bugs, package uploads, all sorts of critical stuff is potentially compromised.
[11:03] <SteveA> hello elmo.  my xchat window flashed in your honour.
[11:03] <spiv> mdke: This is why OpenID would be nice.
[11:04] <mdke> ah
[11:04] <mdke> bugger
[11:04] <mdke> spiv: ok, so downright impossible for now, maybe possible in the future?
[11:04] <jamesh> mdke: sounds like it, yeah.
[11:04] <mdke> gotcha
[11:05] <mdke> any idea of timing?
[11:05] <spiv> mdke: It's probably not feasible for any service that isn't 100% trustable and 100% administered by Canonical.
[11:05] <jamesh> with OpenID, the passwords would never be sent to the fridge
[11:05] <jamesh> and if the person is already logged in to Launchpad, they wouldn't need to reenter their password
[11:05] <jamesh> just click yes to a form on Launchpad asking them if they want to authenticate themselves to fridge.ubuntu.com
[11:06] <mdke> yeah, something like that would work, because we have a fridge editor group on LP
[11:06] <Kinnison> As a user of LP myself, I vote OpenID++ Bug 1169 FTW!
[11:06] <Ubugtu> Malone bug 1169 in launchpad "Launchpad should support OpenID" [Medium,Confirmed]  http://launchpad.net/bugs/1169
[11:09] <mdke> I suppose the alternative would be to redo the fridge using different software
[11:15] <stub> Not really - the same problems apply. If a system isn't considered trusted enough to run in our dmz, it isn't trusted enough to talk to the existing authserver. We just need to bite the bullet and implement open-id instead of putting it off as a low priority, as use cases for it popup every month or so.
[11:15] <mdke> stub: that would be good. I kind of meant "different software that can be trusted to run in the lan"
[11:16] <mdke> but, obviously, implementing this open-id thing sounds good too
[11:54] <jamesh> spiv: sent a review through for your posix-shell-happy branch
[12:02] <SteveA> BjornT: ping
[12:02] <BjornT> hi SteveA 
[12:02] <SteveA> hi
[12:02] <SteveA> when you updated the http servers to use WSGIHTTPServer
[12:03] <SteveA> rather than PublisherHTTPServer
[12:03] <SteveA> did you need to do anything else for that?
[12:03] <SteveA> stu and I are updating the xmlrpc server now
[12:05] <SteveA> actually, I think we'll just get rid of it
[12:05] <SteveA> and run xmlrpc dispatched by host header on the existing wsgi server you set up
[12:07] <BjornT> SteveA: didn't have to do anything since the stuff was already set up for pagetests. i've already gotten rid of the old xmlrpc server (dispatching by the host header instead) in my xmlrpc-test-transport branch
[12:07] <SteveA> oh, cool
[12:07] <SteveA> is it done?
[12:07] <SteveA> that means stu and I don't need to do it
[12:07] <SteveA> is that branch on devpad?
[12:07] <BjornT> yeah. and it includes test, so that it's easier to see that it actually works.
[12:07] <SteveA> stu and I can try merging it
[12:08] <SteveA> although we landed something last night that will conflict
[12:08] <BjornT> SteveA: https://devpad.canonical.com/~jamesh/pending-reviews/bjorn/launchpad/xmlrpc-test-transport/full-diff
[12:08] <SteveA> ta
[12:08] <SteveA> we'll merge that and land it
[12:08] <BjornT> cool
[12:11] <sabdfl> stub: sorry, see #canonical
[12:11] <SteveA> BjornT: some questions...
[12:11] <SteveA> in HTTPCallerHTTPConnection, it looks like you're writing a transport for xmlrpclib
[12:11] <SteveA> that also sets up the interaction etc. 
[12:12] <SteveA> I find that a little odd.  I'd have expected the transport to use the standard pagetesting calls, and make POSTs into the publisher using the host xmlrpc.launchpad.dev
[12:13] <BjornT> SteveA: well, it kind of does that. it uses HTTPCaller, which the pagetests uses as well.
[12:14] <SteveA> do you mean than the http() function and also testbrowser use HTTPCaller?
[12:14] <BjornT> the yeah
[12:15] <BjornT> s/the//
[12:15] <SteveA> why do you need to set up an interaction?  doesn't the publication do that?
[12:18] <BjornT> it does. but it doesn't cope well with existing interaction. for pagetests this isn't a problem, since you usually only check the page contents. with xmlrpc tests, you usually check things directly in the db, for which you need an interaction. since HTTPCaller ends the interaction, you have to set up and end an interaction everytime you want to take a look in the db.
[12:18] <BjornT> that would add a lot of noise to the tests
[12:20] <SteveA> I think I see
[12:20] <SteveA> so, this is to support having code in doctests in between the pagetest parts
[12:20] <SteveA> by having an interaction available in between the pagetest calls
[12:20] <SteveA> a fresh interaction
[12:21] <SteveA> if that's so, we should factor this out to have an after-pagetest hook and before-pagetest hook
[12:21] <SteveA> so we can use this for all pagetests
[12:22] <BjornT> yeah, that's right. it's quite common to have code between pagetests part for xmlprc tests, so it's needed.
[12:22] <BjornT> having something to make it work for general pagetest test would be good
[12:23] <SteveA> BjornT: please file a bug on that with what you know about it from having done so for the xmlrpc tests
[12:23] <SteveA> there are various pagetests we can clean up by factoring this out and using it for all such tests
[12:23] <BjornT> ok
[12:23] <SteveA> I've reviewed the code, and it's good.  I'll merge it shortly
[12:24] <BjornT> cool, thanks.
[12:25] <SteveA> we also need to think about where xmlrpc tests should go
[12:25] <SteveA> because we can now (when this lands) write realistic xmlrpc usage tests
[12:25] <SteveA> that also test the system
[12:25] <SteveA> these can form the xmlrpc API documentation
[12:25] <SteveA> so, how about putting them in launchpad/xmlrpc/doc/
[12:26] <SteveA> what do you think BjornT ?
[12:26] <BjornT> that sounds like a good place for xmlrpc tests.
[12:29] <Znarl> stub : Carbon has run out of diskspace on /
[12:30] <SteveA> BjornT: ok.  we have some already.  will you talk with bradb and arrange moving API doc tests into there, and adding that to the standard doctest running directories ?
[12:30] <BjornT> sure
[12:31] <SteveA> Znarl: did nagios complain about demo.launchpad.net ?
[12:31] <SteveA> BjornT: thanks.  I'll merge and stuff now.
[12:31] <Znarl> SteveA : No, just complained about low diskspace on carbon.
[12:31] <SteveA> Znarl: interesting.  I don't know what happens to the app servers when they have no disk space to write logs
[12:32] <SteveA> but it is happy now
[12:32] <stub> Znarl: orted
[12:32] <stub> erm.... sorted
[12:32] <SteveA> prick up your ears?
[12:32] <Znarl> SteveA : It didn't reach 0, it got to 308M free.
[12:32] <SteveA> I see
[12:35] <SteveA> that's great, then.  no interruption in service :-)
[12:36] <sabdfl> cprov: morning
[12:36] <sabdfl> is salgado around?
[12:37] <cprov> sabdfl: morning, not yet, he starts usually at 8:30 BRT (in one hour or so)
[12:38] <sabdfl> Kinnison: sennapatch
[12:39] <sladen> spiv/jamesh: reading the log at https://lists.ubuntu.com/archives/sounder/2006-August/008444.html can we try writing an OpenID <-> XMLRPC interface, then have that run inside the firewall and have things authenicate against that?
[12:40] <Kinnison> sabdfl: :-)
[12:40] <sladen> spiv/jamesh: although it's more a case of just having a webpage hidden behind a password-authenicated webpage
[12:41] <sabdfl> :-)
[12:41] <sivang> morning
[12:41] <stub> sabdfl: db patch landing now
[12:41] <Kinnison> sladen: actually that'd probably be fairly easy, esp. given the python OpenID libraries are simple and easy
[12:42] <sabdfl> spiv: OpenID is good in principle, but i think we should set limited goal initially, because the whole hog is a true pig
[12:42] <sabdfl> verisign is the company behind it
[12:42] <sivang> sabdfl: have you merged the s/braindump/new stuff with your last weekend's blueprint branch ?
[12:42] <sabdfl> stub: thanks, will use it in due course
[12:42] <SteveA> BjornT: ping -- another question
[12:42] <SteveA> you added to zopeapp.zcml this:
[12:42] <SteveA> +  <!-- Default XMLRPC pre-marshalling. -->
[12:42] <SteveA> +  <include package="zope.publisher" />
[12:42] <sladen> sabdfl: livejournal;  verisign are just a provider---same as launchpad would be
[12:42] <sabdfl> sivang: no, i didn't see a response from you
[12:43] <SteveA> but, zope.publisher has no configure.zcml
[12:43] <sabdfl> sladen: verisign are funding the standards development, and 2.0 is very heavyweight
[12:43] <sivang> sabdfl: ah, sorry, what sort of response were you expecting?
[12:43] <sabdfl> sivang: a branch URL on PendingReviews
[12:43] <sabdfl> cprov: thanks, could you ask him to ping me as soon as he's in?
[12:44] <cprov> sabdfl: sure
[12:44] <BjornT> SteveA: right. the configure.zcml is in bjorn/zope/issue-634, which needs to be merged to our zope tree first.
[12:46] <sladen> sabdfl: things like group membership would be useful "is this user a member of %editors"
[12:47] <SteveA> BjornT: is this present upstream?
[12:47] <sabdfl> sladen: yes
[12:47] <BjornT> SteveA: yes, it's a fix pulled from upstream.
[12:48] <SteveA> ok, thanks
[12:49] <jamesh> sladen: for OpenID, you need to keep a record of the sites the user has agreed to have LP authenticate against
[12:49] <jamesh> sladen: we'd need another data store to do that outside of LP
[12:52] <sabdfl> jamesh: why outside of LP?
[12:52] <Kinnison> sabdfl: dear gods, OpenID 2.0 really is heavyweight
[12:52] <Kinnison> an XML parser? flippin eck
[12:52] <jamesh> sabdfl: sladen was suggesting doing a separate OpenID server that used the authserver to authenticate the user
[12:52] <jamesh> sabdfl: I'm saying that that has issues too
[12:55] <jamesh> sabdfl: if we do OpenID, I'd want to do it properly and integrated with LP
[12:56] <sladen> jamesh: for the start, you can hard-code the list of trusted-sites.  That way it stays an 'internal' authenication transport, rather than an external one.
[12:57] <jamesh> sladen: also, half the point of OpenID is for the user not to have to enter their password in the first place
[12:57] <sladen> jamesh: eg.  trusted_peer_sites = ['fridge.ubuntu.com']     That deals with the current use-case
[12:58] <jamesh> sladen: if they've already logged in to Launchpad, they shouldn't need to enter their password again to authenticate to fridge.ubuntu.com or livejournal.com, etc
[12:59] <sladen> jamesh: the first time, they need to enter their password to allow the other site.  Just like the first time you 'sudo' you need to identify yourself;  the fact that the authenication token is cached does not detract from the fact that the password was asked the first time (if it's wasn't, it would be a pretty useless "authenication" scheme...)
[01:00] <jamesh> sladen: the OpenID workflow is that I go to the remote site and enter my OpenID URL (which would be https://launchpad.net/people/jamesh).  That site bounces me to a URL on launchpad.net
[01:00] <jamesh> if I'm not logged in, it prompts me to log in
[01:01] <jamesh> if I am logged in, it presents a form asking if I want to authenticate to the remote site
[01:01] <sladen> jamesh: the user still needs to click "yes", otherwise I can just go along to fridge.ubuntu.com and put in my ID as 'sabdfl'
[01:01] <jamesh> if I say yes, then the I'm bounced back to the remote site
[01:02] <jamesh> it can be streamlined by allowing people to auth with a site for a month so the user doesn't notice the bounce through launchpad.net
[01:02] <jamesh> but in the general case they won't see a password prompt
[01:02] <sladen> jamesh: yes, this is my understanding on the workflow too, are we disagreeing about anything? :)
[01:02] <sabdfl> spiv: if you'd like to spec up the simplest necessary parts of OpenID that you think we could support to get Forums support, that would be great
[01:02] <sabdfl> i'll take a look at that and discuss with stevea and kiko for post-1.0
[01:02] <spiv> sabdfl: Ok, I'll do that.
[01:03] <sabdfl> when the spec is ready, mail it to Kinnison

[01:03] <spiv> Heh.
[01:04] <sladen> jamesh: yup, again, it's cacheing (cacheing of the launchpad auth token in a cookie) that allows that to work sans-password dialogue
[01:05] <jamesh> sladen: so if we do an external system, it either (a) needs its own session machinary, (b) requires the user to enter their password each time or (c) can use LP's session machinary (in which case it is probably zope specific, and is probably easier to integrate directly)
[01:07] <sladen> jamesh: I had in mind (b) for the moment.  Based on (b), the end site eg. forums/fridge can set its own cookie (for 1 month), which is what currently already happens, had the user authenicated using the local password database
[01:10] <sladen> jamesh: all of the forums-style crack uses hash-cookies for this already, so the changes required at that end are minimal.  Just where the 'yah' or 'nay' happens moves.
[01:18] <sivang> sabdfl: patch sent
[01:23] <stub> carlos, danilos: re: the copy-missing-translations stuff, can the statistics be updated later online?
[01:24] <carlos> stub: the ones for distrorelease, yes
[01:24] <carlos> stub: the ones for pofile would be possible, but we don't have any other script to do it
[01:28] <stub> pofile stats were quick anyway. 
[01:28] <carlos> ok
[01:28] <carlos> then disable the distrorelease ones
[01:28] <stub> distro stats are still running (12 mins so far)
[01:28] <carlos> and you will need to execute the usual update-statistics.py script
[01:28] <carlos> later
[01:29] <stub> Creating the dapper translations took 20 mins to do everything up to the distrorelease stats on real hardware.
[01:29] <carlos> really?
[01:29] <carlos> wow
[01:29] <carlos> staging is really, really slow!
[01:29] <stub> Nah - productions is just insanely overpowered.
[01:30] <stub> (and thats the way I like it, u-huh)
[01:30] <carlos> :-P
[01:34] <danilos> stub: wow, cool :)
[01:45] <sabdfl> SteveA: is there a spec for the privilege escalation idea, wearing admin hat when needed etc?
[01:53] <webben> Is there a launchpad administrator here who could delete a message i accidentally sent to a bug report. It was supposed to be a quick word of thanks to someone who submitted a workaround, and unfortunately contained my email address in the sig.
[01:53] <webben> (or if it's easier to edit it, just a confirmation that the workaround works would be good)
[01:54] <sabdfl> webben: i dont believe we currently support changing comments
[01:55] <sabdfl> i imagine we'll have to do something in future
[01:55] <webben> sabdfl: really? not even the admins can change them?
[01:55] <webben> what do you do about malicious content?
[01:55] <sabdfl> well, the DBA can, but that's because he's a Pillar of society
[01:55] <sabdfl> hey stub
[01:55] <sabdfl> webben: sshhhh...
[01:56] <sabdfl> if you don't get any joy, please file a bug on LP regarding that, and subscribe yourself, so you'll be notified when its possible and can ask again
[01:57] <webben> oh dear, okay
[01:57] <sabdfl> thanks
[02:13] <lifeless> webben: how concerned are you ?
[02:14] <webben> lifeless: well, the sky will not fall on my head tomorrow if my email address ends up in clear text
[02:14] <webben> lifeless: but otoh i've worked very hard to keep it out of clear text
[02:15] <lifeless> do a google search for it, betcha its all over the place :)
[02:15] <webben> lifeless: it's not
[02:15] <lifeless> ok
[02:15] <lifeless> well you can mark that bug as private as a temporary work around
[02:15] <lifeless> whats the bug number ?
[02:15] <webben> lifeless: 52534
[02:16] <webben> so i just tick visible only to subscribers
[02:16] <webben> doesn't that rather reduce the chance of it getting fixed?
[02:17] <webben> or can certain devs still see it?
[02:17] <lifeless> is it the last comment ?
[02:17] <webben> yep
[02:19] <lifeless> I've had a quick look
[02:20] <lifeless> theres fti indexes I'd need to update, and I'm not fully up to speed on them - not enough to diddle production data.
[02:20] <webben> lifeless: what's fti?
[02:20] <lifeless> please file a bug as sabdfl suggested on the requirement, also email stub and I with the bug number and message you need sanitised
[02:21] <lifeless> full text indexes
[02:21] <webben> ah
[02:21] <webben> i reported it soon as sabdfl said: https://launchpad.net/products/launchpad/+bug/56022 
[02:21] <Ubugtu> Malone bug 56022 in launchpad "No way to delete or edit your own bug comments" [Untriaged,Unconfirmed]  
[02:22] <webben> the irony that editing the description to make something clear seems to have duplicated the description is not lost on me
[02:22] <webben> perhaps i shouldn't try interacting any more with launchpad today ... the stars seem against it
[02:24] <salgado> sabdfl, ping
[02:25] <webben> you'd like me to email both of you? stub is stuart bishop, right?
[02:29] <salgado> BjornT, any idea why I don't have permission to see bug 55041?
[02:33] <BjornT> salgado: because i filed it as a private bug and didn't subscribe anyone... fixed now.
[02:33] <salgado> BjornT, ah, ok.  ta
[02:53] <SteveA> lifeless: https://sodium.ubuntu.com/~andrew/paste/fileWEVa1d.html
[02:53] <SteveA> lifeless: got this error when trying to merge into the zope branch
[03:27] <sabdfl> webben: the original description is preserved as the first comment if you edit it, in that way we always know how it was originally reported
[03:27] <sabdfl> if you make a minor change, it *looks* like it's duplicated
[03:27] <sabdfl> that's confusing, and the UI should make it more clear, please take it up with bradb
[03:29] <webben> that doesn't happen with subsequent edits, is that right?
[03:37] <BjornT> webben: right, it happens only with the first edit. we do plan on making the ui clearer, by providing a link to see the original description if it has been edited.
[03:38] <webben> that would be good
[04:02] <ddaa> BjornT: I'd like that. Recently I filed a bug a very short description, and then modified it into the long description. So a minor adjustment later would not cause the whole braindump to be duplicated on screen.
[04:22] <carlos> kiko: hi, what's the status of your branch to change POFile and POMsgSet views ?
[04:22] <kiko> blocked
[04:22] <carlos> kiko: I'm starting with https://launchpad.net/products/rosetta/+spec/translation-review
[04:22] <kiko> yay
[04:22] <carlos> and I think we could have a lot of conflicts there
[04:23] <carlos> kiko: anything I can do to unblock you?
[04:23] <kiko> mmm
[04:49] <flacoste> BjornT: ping
[04:49] <BjornT> hi flacoste 
[04:50] <flacoste> hi BjornT, I've hit a problem with schema validation
[04:50] <flacoste> i had a field defined as Object(schema=IBug) and its fails to validate when the value is a bug instance
[04:50] <flacoste> there are two problems
[04:51] <flacoste> the first one is the Bug.displayname returns a string whereas it is defined as a TextLine (so it expects a unicode string)
[04:51] <flacoste> the second is more tricky and involves a problem in the Zope schema validation per se
[04:52] <flacoste> the other that fails is tags, it fails because zope.schema.List doesn't recognise our list as a valid list because it is security proxied
[04:52] <flacoste> so my question is: where should I report the bug? in Zope collector, in Launchpad or both?
[04:53] <flacoste> BjornT: it's not a blocker btw since I switch to using BugField which works because it doesn't define any constraints on its value :-)
[04:53] <flacoste> (that may also be considered a bug)
[04:54] <BjornT> flacoste: hmm, the List thing might already be fixed. it'd be good if you filed a bug in launchpad. then i'll either pull in the fix, or forward the bug upstream.
[04:55] <flacoste> BjornT: ok, thanks, should I also file bug for the BugField issue?
[04:55] <BjornT> flacoste: yeah, BugField should have some sort of constraint. it should at least check that IBug is provided by the object.
[04:55] <flacoste> exactly my point
[05:25] <bradb> BjornT: pingaroo
[05:53] <ddaa> crap, importd-bzr-upgrade blows up
[05:53] <ddaa> https://chinstrap.ubuntu.com/~dsilvers/paste/fileURhZlT.html
[05:53] <ddaa> apparently, it's looking for Arch-1:a52dec@arch.ubuntu.com\xa52dec--MAIN--0--patch-199.sig
[05:54] <ddaa> while the file is actually named Arch-1:a52dec@arch.ubuntu.com%a52dec--MAIN--0--patch-199.sig
[05:54] <jamesh> maybe you need to run an upgrade with an older version of bzr?
[05:55] <ddaa> nah, it's failing in _backup_control_dir / copy_tree
[05:55] <ddaa> it's not even doing the upgrade yet
[05:55] <ddaa> it looks like a plain sftp transport bug
[06:09] <ddaa> found it
[06:09] <ddaa> list_dir and stat do not agree on whether the given file name is urlencoded
[06:10] <ddaa> jamesh: do you remember what's the policy for transports?
[06:10] <kiko> ddaa,   [r=jamesh]  svn_oo tests use Arch and bzr, remove superceded shell tests dependent on baz
[06:10] <ddaa> do they treat relative names as url encoded, or not?
[06:10] <kiko> ddaa, to english now?
[06:11] <ddaa> kiko: complete the conversion of cscvs test suite so that all tests, as far as I could tell, that depend on baz have a counterpart that uses bzr instead.
[06:11] <jamesh> ddaa: I don't know.  Maybe ask j-a-meinel?
[06:11] <kiko> thanks.
[06:12] <ddaa> kiko: the next logical step there is to remove baz tests and Arch support.
[06:12] <kiko> cool.
[06:17] <BjornT> bradb: pong
[06:17] <sivang> re
[07:14] <htraki> hello to all
[08:01] <kiko> stub, would you have a moment to deal with https://launchpad.net/products/rosetta/+ticket/529 -- ?
[08:01] <kiko> it's not urgent but it /has/ been open for like 5 months..
[08:17] <salgado> kiko, mpool will be able to remove that language once danilos' bug-1788 branch lands
[08:17] <salgado> danilos, btw, have you forgotten that branch?
[08:18] <kiko> oh
[08:18] <kiko> didn't know that salgado 
[08:19] <salgado> that branch makes all preferred languages to show up, whether it's disabled or not
[08:20] <kiko> oh
[08:20] <kiko> ok.
[08:21] <kiko> salgado, how come you know these things?
[08:21] <salgado> kiko, I reviewed his branch
[08:21] <kiko> :)
[08:23] <bradb> BjornT: ping
[08:35] <jamesh> kiko: I renamed bugzilla-importer on demo.launchpad.net to bug-importer
[08:36] <danilos> salgado: nope, my gpg key is not in pqm
[08:36] <danilos> salgado: and this morning it was already to late for lifeless to add it
[08:37] <danilos> salgado: basically, I've got 2 branches (bug-44860 as well) ready for merge, and one almost there (bug-2237)
[08:37] <danilos> s/to late/too late/
[08:37] <salgado> that's bad... being blocked because pqm doesn't have your key
[08:37] <danilos> salgado: yeah, I know :(
[08:38] <danilos> salgado: but I blame the docs and getting lost in them (there's nothing about it on WorkingWithSharedRepositories, and that's the only important bit from PQMSetup in the new setup)
[08:38] <salgado> danilos, anyway, I've assigned a bug to you, which is fixed by your branch.  I marked it as in-progress, so you only need to mark it fixed once you land your branch
[08:38] <danilos> salgado: ah, no problem
[08:38] <danilos> salgado: more karma for me :)
[08:39] <salgado> indeed! :)
[08:53] <danilos> anyway, out now ;)
[08:55] <ddaa> Yay, I think  I nailed the bzr upgrade problem.
[08:56] <ddaa> It would only bite people trying to "bzr upgrade" a baz-import branch through sftp.
[08:56] <ddaa> Which I admit is a fairly uncommon scenario...
[09:07] <BjornT> bradb: pong
[09:08] <bradb> BjornT: hi, i asked you a question a little while ago in a /query window, curious to hear your response
[09:10] <BjornT> bradb: oh, i thought i answered that. what was the question again?
[09:10] <bradb> repasting in /query...
[09:12] <BjornT> ah... not registered...
[09:21] <ddaa> crap... another bug :(
[10:02] <kiko> guys
[10:02] <kiko> is there a carlos_browser? are the different test browsers defined anywhere?
[10:05] <WebMaven> Is this the channel for users of launchpad.net, or developers of it?
[10:06] <kiko> both!
[10:06] <kiko> users are welcome!
[10:06] <WebMaven> I am a Zope developer, is any part of Launchpad released as source?
[10:07] <kiko> WebMaven, that's an interesting question. I know that some parts have been, and that some are intended to be in the short term. are you looking to contribute?
[10:08] <WebMaven> I would be willing to contribute, for anythiong that was FLOSS.
[10:08] <mdke> there's a short explanation on launchpad.net/faq, dunno if it will assist you much
[10:08] <WebMaven> I am a very experienced Zope2 dev, somewhat of a Zope3 newbie.
[10:09] <WebMaven> SteveA showed a very interesting chunk called oops at PyCon.
[10:09] <WebMaven> in general, I'd be most interested in the stuff that was lowest-level infrastructure.
[10:10] <WebMaven> Anything that would be generally applicable to building large scall hosted apps on Zope3.
[10:11] <kiko> WebMaven, so, you're actually coming in at an interesting moment. I suggest you talk to SteveA because he is just coming back from a sprint and will have some interesting news related to exactly that.
[10:11] <WebMaven> Really? OK!
[10:11] <kiko> I think SteveA's kinda idling but you can either ping him tomorrow or monday, or, if you're that sort of person, email steve@canonical.com
[10:11] <WebMaven> SteveA: AYT?
[10:12] <kiko-afk> catch you guys tomorrow, going underwater
[10:13] <WebMaven> kiko-afk: thanks for the info.
[10:13] <kiko-afk> you're more than welcome. thanks for your inquiry
[10:15] <WebMaven> kiko-afk: which sprint was it?
[10:16] <kiko-afk> I'm not sure I'm allowed to tell you the name :) ask SteveA!
[10:16] <WebMaven> A secret sprint?
[10:16] <kiko-afk> indeed! the sprint of sprints!
[10:16] <kiko-afk> but now I am gone
[10:16] <WebMaven> ok.
[10:16] <kiko-afk> I was not here
[10:17] <kiko-afk> this meeting did not occur
[11:08] <bluefoxicy> heh, I quantified a hypothesis page
[11:28] <SteveA> hi WebMaven 
[11:32] <sabdfl> salgado: ping
[11:32] <salgado> sabdfl, pong
[11:33] <sabdfl> thanks for the review!
[11:33] <sabdfl> i have a little bit more if you don't mind
[11:33] <sabdfl> can i send it to you as a diff?
[11:34] <salgado> sabdfl, sure, but I can't do it today --I have some classes now.  I'll try and review tomorrow morning
[11:34] <salgado> is that okay?
[11:34] <sabdfl> when is the cutoff?
[11:35] <salgado> sabdfl, usually Thursday after the meeting
[11:35] <sabdfl> in this case, i think kiko said saturday, he was planning to land some other bits which would be rolled out
[11:36] <sabdfl> gpg-coc stuff, and others
[11:36] <sabdfl> kiko-afk: ?
[11:36] <salgado> he left already, but I've seen his landing today
[11:36] <salgado> sabdfl, how big is the remaining patch?
[11:37] <sabdfl> not as big as it looks
[11:38] <sabdfl> it cleans up some of the issues you raised in your review (like the return values of updateCompletionBy)
[11:38] <sabdfl> and it uses the table columns you noticed were not used in the previous patch
[11:38] <sabdfl> though in the previous patch, they were in pending/foo.sql
[11:38] <sabdfl> 90% of it re-uses the pattern established for managing date_completed and completer, just adding date_started and starter
[11:39] <sabdfl> i think you will see it's super quick
[11:39] <sabdfl> can i talk you through it on the phone? 20 mins?
[11:39] <salgado> sure
[11:40] <sabdfl> number?
[11:40] <salgado> did you mail it already?
[11:40] <sabdfl> no, just generated the diff
[11:40] <salgado> +55 16 3376 0125
[11:41] <sabdfl> https://sodium.ubuntu.com/~andrew/paste/file916Xl4.html
[11:41] <sabdfl> calling
[11:43] <WebMaven> SteveA: Hi!
[11:44] <SteveA> hi michael
[11:44] <WebMaven> SteveA: I just PM'd you.