[05:02] <jamesh> lifeless: fyi: my cron jobs on chinstrap aren't firing so the pending-reviews page will only update when I do it manually
[05:22] <lifeless> jamesh: oh :(
[05:22] <lifeless> is crond running ?
[05:23] <jamesh> seems to be
[05:24] <lifeless> can you add 'ssh chinstrap run-pending-merge' to a cron job on your desktop ?
[05:25] <jamesh> I've submitted an RT request about the problem but haven't received the auto-reply yet
[05:26] <jamesh> I did an update of the page this morning, and am doing another now
[06:58] <stub> Launchpad will be going down in 15 minutes for its regular code update. Estimated down time is 10 minutes.
[07:28] <raphink> hi there
[07:28] <raphink> I need to request the sync of the clucene-core package from Debian to Ubuntu
[07:28] <raphink> but this package is not in Ubuntu yet
[07:28] <raphink> is it possible to add the package to Ubuntu so I can request sync?
[07:34] <stub> No idea - this is the Launchpad channel. Sounds like you need to talk to an Ubuntu developer.
[07:39] <lifeless> raphink: how do you normally request a sync - a bug on the package ?
[07:39] <raphink> yes lifeless
[07:39] <raphink> well now I've requested a bug on ubuntu in general
[07:39] <raphink> so it should work
[07:40] <raphink> hopefully
[07:40] <lifeless> raphink: can you please file a wishlist bug, OR, a specification, on the product 'malone' describing your use case ('request a sync of a package not in ubuntu') so that we can get someone to make it easier in the future ?
[07:40] <raphink> I don't have time for that right now
[07:41] <raphink> but I'll try to do that today
[07:49] <mpt> yay, Internet
[08:05] <sivang> morning
[08:34] <jenda> ajmitch: wtf, how did you get a cloak like that? :-D
[08:43] <sivang> jenda: ties in the right places :)
[08:44] <jenda> hehe ;)
[08:49] <SteveA> morning
[08:49] <SteveA> jamesh: I've almost finished work on that specs branch.  Will you be able to review it a bit later today?
[08:49] <SteveA> I think it's about 400 lines of dif, inc tests
[08:50] <jamesh> SteveA: okay.
[08:50] <jamesh> SteveA: my cron jobs aren't running on chinstrap at the moment, so if you need pending-reviews updated ping me
[08:51] <SteveA> ok
[08:51] <jamesh> I guess it has something to do with the login problems from yesterday
[08:52] <jenda> Can I access stuff put in launchpad/bzr through http/https?
[08:53] <jamesh> jenda: details for accessing your branch should be on the your branch's page on Launchpad
[08:54] <jamesh> jenda: branches are published with URLs like http://bazaar.launchpad.net/~userid/product/branchname
[08:54] <jenda> Yes, I have that URL
[08:54] <jenda> but when I open it in my browser, it shows empty
[08:54] <jenda> https://launchpad.net/people/ubuntu-marketing/+branch/spreadubuntu/spreadubuntu
[08:55] <jamesh> jenda: the URL is intended for use with bzr, which stores all the data in a ".bzr" dir
[08:55] <jenda> So will only bazaar be able to check that out...
[08:55] <jenda> OK
[08:55] <jamesh> see http://bazaar.launchpad.net/~ubuntu-marketing/spreadubuntu/spreadubuntu/.bzr/
[08:55] <jenda> Ah ;)
[08:56] <jenda> Thanks. Now, BTW, is anyone able to checkout that branch, or only the people of ubuntu-marketing?
[08:56] <jamesh> anyone can grab the branch by HTTP
[08:56] <stub> Anyone - this is for open source development.
[08:56] <jamesh> only people in the ubuntu-marketing team can get it via SFTP
[08:57] <jamesh> and you can only make commits by sftp
[08:57] <jenda> yes, OK
[08:57] <jenda> how does 'grabbing by http' work?
[08:57] <jenda> bzr checkout http...?
[08:58] <jamesh> "bzr get http://bazaar.launchpad.net/..."
[08:58] <jenda> ah
[08:58] <jenda> OK, thanks
[08:58] <jamesh> I don't think checkout will work (it doesn't work with readonly repos)
[08:58] <jenda> OK
[08:58] <jamesh> it might work with a future version of bzr though ...
[08:58] <jenda> OK
[08:58] <jenda> Thanks 
[09:00] <stub> get and checkout doing different things is confusing, as other systems consider them aliases :-/
[09:00] <spiv> Yeah, "get" is an alias of "branch" for bzr.
[09:01] <stub> Mmm... I'd call that a wart. I can understand how it happened though.
[09:03] <jamesh> well, svn doesn't have get, iirc
[09:03] <SteveA> I always find get vs pull confusing when I want a new tree in my filesystem
[09:03] <SteveA> if I just want to track someone's branch, the sequence of commands goes:
[09:03] <SteveA>  - first get (or branch)
[09:03] <SteveA>  - next, don't change anything
[09:03] <SteveA>  - next, pull to get changes
[09:04] <jamesh> the other annoying thing is pull vs. update
[09:04] <SteveA>  - thereafter, pull to get changes
[09:04] <jamesh> if you created your local branch with get/branch you need to pull
[09:04] <jamesh> if you created it with checkout you need update
[09:05] <SteveA> jamesh: what happens if you get them the wrong way around?
[09:05] <jamesh> SteveA: "update" means make the working tree match the head of the branch
[09:05] <SteveA> jenda: iirc, "jenda" is mandarin for "really?!"
[09:06] <SteveA> isn't that what "pull" means?
[09:06] <jamesh> SteveA: a local branch created with "bzr get" will always be up to date though (unless you push to it via sftp from some other box) so is generally a no-op
[09:06] <jamesh> pull means "grab any changes from the parent branch"
[09:07] <jamesh> for a checkout, that would be the parent of the remote branch
[09:10] <jenda> SteveA: iirc, it's my name... but I might be wrong... 
[09:11] <SteveA> really?
[09:11] <jenda> Yes, really ;) And it has nothing to do with mandarin, either. I'm Czech, and the name is Jan == Jenda
[09:14] <carlos> morning
[09:18] <carlos> stub: hi, did you have time to check the fix to the posubmission migration script ?
[09:24] <stub> carlos: Not yet
[09:24] <carlos> ok
[09:33] <stub> lifeless: rocketfuel-built is several revisions out of date. Commits are landing in the branches on balleny and chinstrap though.
[09:33] <jamesh> SteveA: have you had a chance to look at my move-bzrsync branch?
[09:34] <SteveA> jamesh: no
[09:34] <jamesh> okay
[09:36] <SteveA>          randomownerid = 1   <--- should be "arbitraryownerid"
[09:37] <SteveA> either that, or use: random.choice([1] )
[09:38] <jamesh> I'll change it to arbitraryownerid
[09:39] <SteveA> one other comment:
[09:39] <SteveA>      def parent_ids(self):
[09:40] <SteveA> this method gives you ids in response to querying on a revision id
[09:40] <SteveA> in between, it loads objects for all the parent revisions
[09:40] <SteveA> and then iterates over them to get their ids
[09:40] <SteveA> I wonder if there's a way to do it that doesn't involve actually making revision objects for all the parents, and isn't icky in the code
[09:41] <SteveA> other than all that, looks great. r=me
[09:41] <jamesh> I don't think there is an obvious way to do it with sqlobject
[09:42] <jamesh> a revisionparent object is not particularly heavyweight though
[09:42] <jamesh> 4 fields
[09:43] <jamesh> and most revisions in bzr only have 1 or 2 parents
[09:43] <jamesh> (most have 1)
[09:43] <SteveA> ok
[09:43] <jamesh> thanks
[09:46] <SteveA> does close() imply flush() for a stream?
[09:49] <jamesh> it should.
[10:12] <lifeless> stub: its updated by cron
[10:12] <lifeless> stub: there is something wrong with cron. jamesh has filed an RT request.
[10:13] <jamesh> I don't know if the RT request got through though.  I haven't gotten the auto-reply giving the number
[10:13] <lifeless> elmo: Znarl: ^^ is mail having trouble too?
[10:17] <elmo> cron is already fixed, and I've just fixed RT mail, thanks
[10:19] <lifeless> thank you
[10:30] <jamesh> elmo: thanks for fixing the cron problem
[10:52] <SteveA> jamesh: I /msg-ed you details of the branch to review
[10:52] <jamesh> SteveA: yeah.  I'll look at it in a sec (just fixing a test failure in my branch)
[10:55] <SteveA> jamesh: thanks.  With freenode, I'm never sure whether priv messages get through
[10:55] <SteveA> for that reason, I always respond with an "ok" or something, to show I received the message
[10:57] <jamesh> SteveA: yeah.  I turned off the privmsg filtering because of that (never really suffered from privmsg spam)
[11:00] <carlos> jamesh: oh, are we able to disable it?
[11:00] <SteveA> malcc: hi
[11:00] <jamesh> carlos: yep.  You can send some command to NickServ to do it
[11:01] <SteveA> malcc: just noticed on your activity report that you've been having trouble landing the trivial change to __all__.
[11:01] <SteveA> malcc: is that the same pqm issues kiko has been having?
[11:02] <malcc> SteveA: I got an error from sourcecode/bzr/bzrlib/tests/workingtree_implementations/test_workingtree.py, AssertionError: 'a test\n' == 'a test\n'
[11:02] <SteveA> ew
[11:02] <malcc> SteveA: I wasn't following closely enough the exact details of kiko's issue to know if that's the same
[11:02] <SteveA> mpool / lifeless: do you know about this particular issue?
[11:03] <SteveA> malcc: did you mail the launchpad list about it?
[11:03] <stub> I'll disable the bzr and cscvs tests on launchpad merge right now - kiko has landed the relevant makefile changes.
[11:04] <SteveA> cool
[11:04] <SteveA> malcc: when you get unrelated pqm failures, always email the launchpad list
[11:04] <malcc> SteveA: Ok
[11:04] <SteveA> malcc: otherwise, I and others don't know that it's a general problem
[11:05] <SteveA> mpool: I'm available for a call, if you still want one
[11:12] <jamesh> looks like spiv did a merge to our copy of bzr today to fix the hashcache failures
[11:13] <jamesh> that would have been after malcc's failure though
[11:17] <SteveA> carlos: does danilo know about the meeting today?
[11:17] <carlos> SteveA: yes
[11:17] <carlos> he told me that he would start early today... not sure if he had any problem...
[11:20] <stub> launchpad commits should no longer run cscvs and bzr tests. Ping me if you get a pqm bounce - the new config is yet to be tested.
[11:21] <stub> James' should be the first branch to use it
[11:29] <carlos> danilos: good morning
[11:29] <danilos> carlos: yeah, g'day actually :)
[11:37] <carlos> danilos: did you push your branch?
[11:38] <danilos> carlos: yeah, I think I did
[11:38] <carlos> danilos: the Pending reviews page shows it as already merged...
[11:38] <danilos> unless I messed something up
[11:38] <lifeless> you have not pushed it after doing your commits most probably.
[11:38] <carlos> danilos: https://chinstrap.ubuntu.com/~jamesh/pending-reviews/
[11:38] <lifeless> I assumed it was merged, but is it in fact not ?
[11:39] <carlos> lifeless: he copied another branch that I guess is already merged to initialize that new branch
[11:39] <jamesh> danilos: the head revision of that branch on chinstrap is a pqm commit
[11:39] <danilos> jamesh: you're already loosing me :) I am all too new to bzr stuff and our pqm procedure :)
[11:39] <danilos> s/loosing/losing/
[11:40] <jamesh> danilos: okay.  The copy of the branch on chinstrap.ubuntu.com does not contain any commits by you (only commits from the mainline)
[11:40] <carlos> danilos: it's just that latest commit on your branch is already merged into our development tree
[11:40] <danilos> ah, ok, got it
[11:41] <carlos> danilos: check that you don't have any pending change to commit (bzr status)
[11:41] <danilos> ok, will do that
[11:41] <carlos> danilos: and that bzr push says that you need to push 0 revisions
[11:42] <carlos> in which case, I think you are in the wrong directory ;-)
[11:42] <carlos> or that you lose your fix
[11:42] <danilos> ok :)
[11:47] <jamesh> carlos: btw, "/msg NickServ set unfiltered on" should allow unregistered users to /msg you again
[11:48] <carlos> jamesh: yeah, I saw it, but thanks ;-)
[12:10] <carlos> lifeless, SteveA, kiko-afk: Shouldn't you start approving/rejecting specs for the London sprint?
[01:12] <mdke> I'm trying to get a branch from launchpad, i get this message from bzr checkout - bzr: ERROR: Not a branch: /home/matt/sftp:/bazaar.launchpad.net/~etc, any ideas?
[01:13] <jsgotangco> do you have paramiko installed?
[01:14] <carlos> mdke: I think you miss one '/' after sftp:/
[01:14] <jsgotangco> yeah
[01:17] <mdke> haha, thanks carlos 
[01:17] <mdke> oh no
[01:17] <mdke> the command is alright
[01:17] <mdke> bzr checkout sftp://bazaar.launchpad.net/~ubuntu-marketing/spreadubuntu/spreadubuntu
[01:17] <mdke> just the error message is missing a slash >_<
[01:18] <mdke> works with http://
[01:19] <spiv> mdke: you need paramiko installed (python2.4-paramiko)
[01:19] <carlos> hmm I don't know then...
[01:19] <spiv> mdke: the confusing error message is a bug in that version of bzr
[01:20] <mdke> spiv: trying, thanks
[01:22] <mdke> aha, another error
[01:23] <mdke> http://paste.ubuntu-nl.org/17920
[01:24] <spiv> mdke: It failed to authenticate
[01:25] <mdke> do I need to be in a particular team to get a branch like that?
[01:25] <spiv> Yes, but that's not the cause of that error.
[01:25] <spiv> Ah, I bet I know.
[01:25] <spiv> Give me a sec to check the logs
[01:26] <mdke> well, I'm not in ubuntu-marketing
[01:26] <spiv> mdke: You're trying to log in as the user 'matt', I think, but your launchpad name is 'mdke'.
[01:27] <mdke> ah, k
[01:27] <spiv> Either use "sftp://mdke@bazaar.launchpad.net/..." as your URL, or adjust your .ssh/config
[01:27] <spiv> (adding "Host bazaar.launchpad.net\n    User mdke" would do it.)
[01:28] <mdke> right, another error
[01:28] <spiv> It'd be good if bzr reported the user name it's trying in the error.
[01:28] <mdke> agreed
[01:28] <mdke> http://paste.ubuntu-nl.org/17921
[01:29] <jamesh> spiv: if using openssh, it won't know the username being tried
[01:29] <SteveA> bradb, BjornT: 
[01:29] <SteveA> You should not import build_comments_from_chunks from canonical.launchpad.browser.bugcomment:
[01:29] <SteveA>     canonical.launchpad.browser.bugtask
[01:29] <spiv> jamesh: That's true I guess.  Still a shame, and worth filing a bug about, even if it can't be fixed easily atm.
[01:29] <jamesh> spiv: if no username is in the URL, it doesn't pass one to openssh, leaving it to pick the username
[01:29] <jamesh> spiv: it could be fixed, but it'd be in openssh
[01:29] <spiv> jamesh: Exactly.
[01:30] <BjornT> SteveA: it was kiko that added that function
[01:30] <bradb> SteveA: that would be kiko
[01:30] <spiv> jamesh: But it's enough of a usability issue to be worth a bug report anyway :)
[01:30] <mdke> so is the new error due to me not being in the right team?
[01:30] <SteveA> BjornT, bradb: so, kiko caused the problem.  However, it is a problem in malone code. 
[01:30] <spiv> mdke: Right, you cannot access that branch over sftp, because you're not in that team.
[01:30] <SteveA> who will fix it?
[01:31] <spiv> mdke: If you login with the openssh sftp client and look around interactively, you'll see you can only access directories for yourself and the teams you're a member of.
[01:31] <mdke> spiv: that error message could be a bit more userfriendly too :)
[01:31] <mdke> strange tho that I can't grab a branch without being in that team
[01:31] <BjornT> SteveA: i can fix it.
[01:31] <jamesh> mdke: you can grab it via http
[01:31] <SteveA> thanks BjornT 
[01:32] <spiv> mdke: Yeah, I think I'd expect something like "directory not found: ...", rather than the rather vague "not a branch" message.
[01:32] <spiv> mdke: "not a branch" makes it sound like there's something there that's not a branch, rather than there's nothing there at all.
[01:33] <mdke> jamesh: I had some errors from that too :)
[01:34] <mdke> http://paste.ubuntu-nl.org/17922
[01:34] <mdke> I ought to get a more recent version maybe
[01:35] <jamesh> mdke: ah.  you can't use "bzr checkout" on readonly branches (as the error says)
[01:35] <jamesh> mdke: you can do "bzr get http://bazaar.launchpad.net/..." though
[01:36] <jamesh> mdke: there has been talk about supporting read-only bound branches (which would allow "bzr checkout" over http), but it isn't in 0.8
[01:36] <mdke> ah, ok
[01:37] <mdke> that's worked, thanks jamesh 
[01:41] <jsgotangco> if in doubt, the product homepage has the http branch and should work
[02:01] <kiko-afk> me
[02:01] <Kinnison> kiko: pardon?
[02:01] <mpt> kiko needs to tweak his "pretend you're at the meeting" macros too
[02:02] <carlos> kiko: the meeting didn't start yet ;-)
[02:02] <kiko> then we're late.
[02:02] <carlos> yeah
[02:02] <Kinnison> who is meant to be running the meeting today? kiko or stevea?
[02:02] <kiko> SteveA AFAIK
[02:02] <kiko> but perhaps we should start without him
[02:02] <Kinnison> maybe he got caught by a workrave
[02:02] <jamesh> wait for someone to say "meeting" and then send a "me" message a random interval later
[02:02] <carlos> I think Steve is dealing with some changes in the meeting agenda
[02:02] <malcc> me
[02:03] <kiko> meeee
[02:03] <SteveA> hey
[02:03] <stub> me
[02:03] <SteveA> welcome to the launchpad meeting
[02:03] <SteveA> who's here
[02:03] <SteveA> ?
[02:03] <stub> me
[02:03] <spiv> me
[02:03] <Kinnison> me
[02:03] <carlos> me
[02:03] <mpt> me
[02:03] <malcc> me
[02:03] <cprov> me
[02:03] <BjornT> me
[02:03] <matsubara> me
[02:03] <bradb> me
[02:03] <jamesh> me
[02:03] <flacoste> me
[02:03] <salgado> me
[02:03] <stub> me
[02:03] <kiko> me
[02:03] <danilos> me
[02:04] <SteveA> me
[02:04] <SteveA> == Agenda ==
[02:04] <SteveA>  * Next meeting
[02:04] <SteveA>  * Activity reports
[02:04] <SteveA>  * Actions from last meeting
[02:04] <SteveA>  * Oops report (Matsubara)
[02:04] <SteveA>  * Bug report report (mpt)
[02:04] <SteveA>  * Sysadmin requests
[02:04] <SteveA>  * Production and staging (Stuart)
[02:04] <SteveA> ----
[02:04] <SteveA>  * browser unit tests (ddaa/salgado)
[02:04] <SteveA>  * (other items)
[02:04] <SteveA> ----
[02:04] <SteveA>  * Keep, Bag, Change
[02:04] <SteveA>  * Three sentences
[02:04] <SteveA> 
[02:04] <SteveA> um
[02:04] <SteveA> the roll call is missing from the agenda
[02:04] <SteveA> how did that happen?
[02:05] <SteveA> mpt: any ideas?
[02:05] <Kinnison> magic
[02:05] <SteveA> oh, it was moved above the heading
[02:05] <SteveA> weird
[02:06] <SteveA> 
[02:06] <SteveA> == Agenda ==
[02:06] <SteveA>  * Roll call
[02:06] <SteveA>  * Agenda
[02:06] <SteveA>  * Next meeting
[02:06] <SteveA>  * Activity reports
[02:06] <SteveA>  * Actions from last meeting
[02:06] <SteveA>  * Oops report (Matsubara)
[02:06] <SteveA>  * Bug report report (mpt)
[02:06] <SteveA>  * Sysadmin requests
[02:06] <SteveA>  * Production and staging (Stuart)
[02:06] <SteveA> ----
[02:06] <SteveA>  * browser unit tests (ddaa/salgado)
[02:06] <SteveA>  * (other items)
[02:06] <SteveA> ----
[02:06] <SteveA>  * Keep, Bag, Change
[02:06] <SteveA>  * Three sentences
[02:06] <SteveA> 
[02:06] <SteveA> that's better
[02:06] <mpt> SteveA, I did that because you always cover those two before reading the agenda anyway
[02:06] <SteveA> next meeting...
[02:06] <SteveA> kiko and I will be at management meetings
[02:06] <SteveA> next thursday
[02:07] <SteveA> kiko: what do you think... do you think we'll be able to have a meeting?
[02:07] <kiko> yes, I think so.
[02:08] <SteveA> cool
[02:08] <SteveA> so, same time next week
[02:08] <SteveA>  * Activity reports
[02:08] <matsubara> up to date
[02:08] <SteveA> I sent some this week.
[02:08] <mpt> up to date
[02:08] <danilos> up to date
[02:08] <bradb> up to date
[02:08] <BjornT> up to date
[02:09] <jamesh> not up to date
[02:09] <danilos> (even if I was late with a couple)
[02:09] <Kinnison> I am not up to date.
[02:09] <cprov> up to date
[02:09] <salgado> I lost track. not up to date
[02:09] <carlos> Started again this week
[02:09] <kiko> I am up to date, but have a report to send off for yesterday
[02:09] <stub> up to date
[02:09] <carlos> I will try to send previous reports and keep sending the new ones
[02:09] <spiv> I'm up to date for this last week, but haven't filled in the missing weeks before that.
[02:11] <SteveA>   * Actions from last meeting
[02:11] <SteveA> there were none
[02:11] <SteveA>   * Oops report (Matsubara)
[02:11] <matsubara> Today's oops report is about bugs 44860, 40494, OOPS-186D559, OOPS-186D560 and staging timeout limit.
[02:11] <Ubugtu> Malone bug 44860 in rosetta "Crash when we try to pass a query string to a POFile that doesn't exist yet." [Medium,Confirmed]  http://launchpad.net/bugs/44860
[02:11] <Ubugtu> Malone bug 40494 in launchpad "Launchpad crashes badly if the client says it doesn't accept 'utf-8'" [Medium,Confirmed]  http://launchpad.net/bugs/40494
[02:11] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/186D559
[02:11] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/186D560
[02:11] <matsubara> Carlos, how's 44860 going?
[02:11] <matsubara> BjornT, could you prioritize bug 40494? It was triggered quite a few times this week.
[02:11] <Ubugtu> Malone bug 40494 in launchpad "Launchpad crashes badly if the client says it doesn't accept 'utf-8'" [Medium,Confirmed]  http://launchpad.net/bugs/40494
[02:11] <carlos> matsubara: not started yet
[02:12] <BjornT> matsubara: sure, i'll fix it either today or tomorrow.
[02:12] <matsubara> carlos: any chance of working on that one this week?
[02:12] <kiko> matsubara, carlos: I have some extra work to do but I plan on working on the rosetta views again soon.
[02:12] <matsubara> thanks BjornT 
[02:12] <matsubara> On oops report (2006-07-05) I wrote about an possible bug on the oops infrastructure. The two oopses were recorded because one AssertionError (OOPS-186D559) was triggered on the xmlrpc server. Could someone comment on that?
[02:12] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/186D559
[02:12] <carlos> kiko: feel free to give me the branch and I will take a look and try to finish it, if you want
[02:13] <carlos> matsubara: well, kiko's patch already fixes that one....
[02:13] <carlos> matsubara: not sure if we should fix it twice
[02:13] <carlos> at least I think I saw a way to fix it with the diff that kiko show me a couple of weeks ago
[02:14] <kiko> carlos, I don't quite see how my patch solved that!
[02:14] <matsubara> well, kiko's going for the mgmt meeting next week
[02:14] <SteveA> matsubara: that's an interesting xmlrpc OOPS report
[02:14] <carlos> kiko: the way the views work
[02:14] <matsubara> carlos: if you could take that one and land it would be great
[02:15] <carlos> matsubara: ok, I will try to work on it either on Friday or Monday
[02:15] <kiko> matsubara, it's not even close to ready to be landed.
[02:15] <carlos> (I need to finish Edgy translations opening)
[02:15] <kiko> I can work on it over the trip.
[02:15] <matsubara> SteveA: indeed, I wrote about it on the daily oops report, but no answer so far. That's  why I'm bring the subject here.
[02:15] <SteveA> matsubara: so, the code in question does this:
[02:15] <SteveA>         return canonical_url(branch)
[02:16] <SteveA> that would appear to be the problem
[02:16] <matsubara> thanks carlos 
[02:16] <SteveA> but I'm confused as to why that doesn't work
[02:17] <SteveA> matsubara: let's talk about this after the meeting
[02:17] <matsubara> SteveA: ok
[02:17] <matsubara> last topic: Why staging has a so low time out limit?
[02:17] <SteveA> so that we bump into timeouts there, rather than in production
[02:17] <matsubara> sometimes it's impossible to test things there because of this low time out limit
[02:18] <jamesh> to catch slow pages there before they become a problem on production
[02:18] <carlos> SteveA: that timeout limit makes staging useless for Rosetta testing
[02:18] <stub> matsubara: To provoke trouble. I can increase it if you want - suggest a value.
[02:18] <carlos> SteveA: the translation form timeouts always
[02:18] <matsubara> SteveA, carlos that's exactly my point
[02:18] <spiv> Perhaps staging should only have a lower soft timeout?
[02:19] <carlos> matsubara: when I do debugging tasks on Rosetta I increase the timeout, but that's tricky
[02:19] <stub> (In fact anyone can increase the staging timeouts - just change staging/launchpad.conf and wait until the next update)
[02:21] <matsubara> I like spiv's suggestion
[02:21] <carlos> me too
[02:21] <matsubara> could that cause any trouble?
[02:21] <SteveA> about oops reports for xmlrpc... what do you think about using xmlrpclib.loads() on the POSTed value and adding that to oops reports?
[02:21] <SteveA> pprinting it too
[02:21] <stub> matsubara: I'm happy for you to tweak the values. You are probably the most qualified now to make the educated guesses required.
[02:22] <SteveA> I suspect the issue with https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-07-05/D559 is the fault instance being returned.  It may be security proxied, or something.
[02:22] <SteveA> BjornT: I recall you said something about this a while back.  Any ideas?
[02:22] <matsubara> stub: ok. the most annonying pages are the rosetta ones. I'll talk to carlos and find out a good value.
[02:22] <jamesh> SteveA: I think having unparsed data would be useful forr the OOPS reports -- e.g. we won't be able to parse an invalid XML-RPC request but might want to diagnose it
[02:23] <kiko> (stub, did you finish the PQM config change, btw?)
[02:23] <stub> (kiko: yes)
[02:23] <SteveA> jamesh: well, that depends.  I mean, if the data can be parsed, I'd rather have the python pprinted data.
[02:23] <kiko> thanks!
[02:23] <carlos> matsubara: I can change it directly on asuka so we can try to find a good value without wait until next code update
[02:23] <BjornT> SteveA: yeah, there's a bug open on it. it has partly been fixed upstream, and i'll try to fix it in launchpad soon.
[02:23] <SteveA> jamesh: if it can't then sure, I'd like the raw data.  Although POST data can get pretty large
[02:23] <SteveA> BjornT: okay, then please talk with matsubara about getting a suitable bug filed
[02:23] <matsubara> carlos: ok, let's talk about it after the meeting then.
[02:24] <SteveA> BjornT: or point matsubara to the bug
[02:24] <jamesh> SteveA: okay.  This would be a lot easier to implement with a new OOPS format (using multiple files)
[02:24] <carlos> matsubara: I would prefer to delay it after I have lunch... ;-)
[02:24] <jamesh> (and does sound useful)
[02:24] <spiv> SteveA: It wouldn't be hard to copy and paste the raw data into a local python and run it through pprint(xmlrpclib.loads(...)) as needed.
[02:24] <matsubara> carlos: np, just ping me when you're ready.
[02:24] <SteveA> meanwhile, maybe we should be replacing the Fault instances by factories that return just a plain Fault 
[02:25] <SteveA> seeing as things plainly don't work now
[02:25] <carlos> matsubara: ok
[02:26] <SteveA> matsubara: anything else?
[02:26] <matsubara> SteveA: I'm done. thanks.
[02:26] <matsubara> thanks guys
[02:26] <SteveA> thanks matsubara.  well delivered report.
[02:26] <SteveA>  * Bug report report (mpt)
[02:26] <mpt> Today's oldest open important bugs:
[02:26] <mpt> Bug 1294 (Filing a private bug requires the ability to Cc the maintainer), confirmed, critical, bradb
[02:26] <Ubugtu> Malone bug 1294 in malone "Filing a private bug requires the ability to Cc the maintainer" [Critical,Confirmed]  http://launchpad.net/bugs/1294
[02:26] <mpt> Bug 2497 (/people/*/+translations times out for prolific translators), confirmed, critical, kiko
[02:27] <Ubugtu> Malone bug 2497 in rosetta "/people/*/+translations times out for prolific translators" [Critical,Confirmed]  http://launchpad.net/bugs/2497
[02:27] <mpt> Bug 31609 (buildd maintainers need to be informed of build failures), confirmed, critical, cprov
[02:27] <Ubugtu> Malone bug 31609 in soyuz "buildd maintainers need to be informed of build failures" [Critical,Confirmed]  http://launchpad.net/bugs/31609
[02:27] <mpt> Bug 35965 (exceptions in process-upload not communicated to uploader), confirmed, critical, cprov
[02:27] <Ubugtu> Malone bug 35965 in qprocd "exceptions in process-upload not communicated to uploader" [Critical,Confirmed]  http://launchpad.net/bugs/35965
[02:27] <mpt> Bug 37897 (renaming project, product or series breaks vcs imports), confirmed, critical, ddaa, who's not here
[02:27] <Ubugtu> Malone bug 37897 in launchpad-bazaar "renaming project, product or series breaks vcs imports" [Critical,Confirmed]  http://launchpad.net/bugs/37897
[02:27] <mpt> Bug 42573 (Look in the debbugs archive when syncing bug watches), confirmed, critical, kiko
[02:27] <Ubugtu> Malone bug 42573 in malone "Look in the debbugs archive when syncing bug watches" [Critical,Confirmed]  http://launchpad.net/bugs/42573
[02:27] <BjornT> SteveA: i think hanging it to return plain Fault instances will be just as much work as fixing it properly.
[02:27] <SteveA> yay.... only two four-digit critical bugs
[02:27] <mpt> Is that last one really critical, BjornT/bradb?
[02:27] <bradb> kiko started reviewing my patch for bug 1294 yesterday
[02:27] <Ubugtu> Malone bug 1294 in malone "Filing a private bug requires the ability to Cc the maintainer" [Critical,Confirmed]  http://launchpad.net/bugs/1294
[02:27] <kiko> mpt, not really really critical.
[02:28] <mpt> bradb, great
[02:28] <mpt> cprov, should malcc take one of yours?
[02:28] <mpt> And kiko, do you need to give either of yours to someone else?
[02:28] <stub> I suspect bugwatches to debbugs are not being updated due to it (?). And the cron output is annoying ;)
[02:28] <kiko> mpt, I'm going to work on them shortly
[02:28] <cprov> mpt: not really, he is already busy
[02:29] <mpt> ok, then that's all, except to remind you to verify your Fix Committed bugs after stub announces the rollout
[02:29] <mpt> SteveA, done
[02:30] <SteveA> thanks mpt.   I think we can cope with checking a few more important bugs next time too.
[02:30] <SteveA>  * Sysadmin requests
[02:30] <mpt> ok.
[02:30] <SteveA> 5
[02:30] <SteveA> 4
[02:30] <SteveA> 3
[02:30] <SteveA> 2
[02:30] <SteveA> 1
[02:30] <stub> 13853
[02:31] <SteveA> that's an RT number?
[02:31] <SteveA> seems kinda high
[02:31] <stub> Only opened today, but it the rt job requesting the outbound email whitelist
[02:31] <stub> Yes, it is an rt job number
[02:31] <danilos> 13966 (from today as well)
[02:31] <SteveA> what's the danilo?
[02:31] <danilos> it's about being added to rosetta@launchpad.net alias
[02:31] <SteveA> stub: what machine is that for?  the competition demo machine... ?
[02:31] <stub> SteveA: Yes
[02:32] <BjornT> stub: if the bugwatch points to an old, closed, debbugs bug it won't get updated. if the bug is open (or closed but not moved to the archive yet) we will sync the status properly.
[02:32] <SteveA> ok.
[02:32] <SteveA>  * Production and staging (Stuart)
[02:32] <stub> Production was updated this morning (r3766). The update was delayed two days, firstly because I got distracted on other things and yesterday due to problems on the LAN.
[02:32] <stub> Staging is running as normal. The staging server will hopefully be getting a hardware boost soon.
[02:32] <stub> The test environment for the Python community is slowly going up. Various small sysadmin stuff to do but I think I'm on top of everything there. I need to know the domain name we want to use for it to organize redirects (test.launchpad.net?)
[02:33] <kiko> (mpt, what happened to the description of bug 1188?)
[02:34] <mpt> (kiko, nothing, why?)
[02:34] <kiko> (mpt, read it)
[02:35] <mpt> (kiko, I did that before answering)
[02:35] <SteveA> stub: the important features of it are: it is staging data, and it's for invited people to try email out (although others can use the web too)
[02:35] <kiko> (mpt, why is it stuttering?)
[02:35] <SteveA> by "staging data" I mean "not production data"
[02:35] <SteveA> how about demo.launchpad.net ?
[02:35] <stub> Sounds fine
[02:36] <stub> I'll run with that.
[02:36] <SteveA> cool
[02:36] <SteveA> thanks
[02:36] <SteveA>  * browser unit tests (ddaa/salgado)
[02:36] <SteveA> ddaa isn't here
[02:36] <SteveA> so, salgado 
[02:36] <salgado> so, ddaa asked yesterday why we don't have any unit tests for browser code and if it'd be reasonable to have them. he asked that because he has some hairy view code that he wanted to thoroughly test, and for that it'd be better to write unit tests than to have a pagetest for each possible case.
[02:36] <salgado> I agreed with him that unit tests would probably be better in this case and told him that we didn't make any explicit choice for not writing unit tests for browser code; instead, what I think that happened is that because it's a lot easier to write pagetests than unit tests, we've been using the former in some cases that we should be using the latter.
[02:36] <salgado> so, we (me and ddaa) would like to have a policy saying whether it's desirable or not to have unit tests for browser code and, if desirable, in which cases we should be using them instead of pagetests.
[02:36] <SteveA> we do have some system doc tests for view classes in browser code
[02:37] <kiko> I was about to say that.
[02:37] <SteveA> we even have a naming convention for them
[02:37] <salgado> right, the <foo>-pages.txt
[02:37] <spiv> Also, see https://launchpad.canonical.com/BasicTestCoverage -- it briefly discusses testing of view classes.
[02:37] <SteveA> the thing is that these are generally not "unit tests"
[02:38] <salgado> but those are doctests. ddaa said he'd like doctests to be used mainly for documentation
[02:38] <SteveA> these are functional tests, with the entry-point being the view code
[02:38] <SteveA> ddaa would like a lot of things
[02:38] <SteveA> and, I think we should document our browser view classes
[02:38] <salgado> although I'm not sure I agree with him about the doctests, I think we're overusing them in some cases
[02:38] <salgado> (a lot of cases, actually)
[02:38] <salgado> they're becoming very hard to maintain
[02:39] <stub> Out doc directory has grown too much, making it useless for documentation
[02:39] <SteveA> so I see a couple of different points here
[02:39] <salgado> and a lot of them don't make sense anymore, when read as a document
[02:39] <SteveA> 1. we use doc tests for API documentation and also for other functional and unit tests, all in the same place
[02:40] <SteveA> 2. we use doc tests format in preference to other formats because experience showed that people wrote opaque python-code-only tests before (if they wrote tests at all).
[02:40] <SteveA> 3. we should test view code
[02:40] <SteveA> to address these...
[02:40] <SteveA> 3. yes, we should
[02:40] <SteveA> 1. we should split API and use documentation from "I'm documenting how this fits together and its edge cases" documentation
[02:41] <kiko> I much prefer the doc test format to any other.
[02:41] <flacoste> kiko: the problem with doc test is that it's not reusable
[02:41] <spiv> kiko: It really depends on the tests.
[02:41] <stub> I find it depends on what you are testing
[02:41] <flacoste> kiko: for example, to write an Interface test
[02:41] <SteveA> 2. people should discuss with their reviewers using other forms of tests
[02:42] <SteveA> for interface tests, I'd like to see a mechanism for testing the interface with a .txt file
[02:42] <SteveA> and having instances constructed and run through that txt file
[02:42] <SteveA> that provides an interface documentation and test
[02:42] <SteveA> we are out of time for this discussion.  thank you salgado (and ddaa in absence) for bringing this up, and preparing the text beforehand
[02:42] <flacoste> SteveA: i thought about that, but what when some cases needs modification for a particular implementation
[02:42] <mpt> (kiko, it's from before autogeneration of shortdesc from description ceased, which was before description and shortdesc merged. The resulting stuttering in old almost-entirely-Launchpad bug reports is what I referred to in MaloneSimplifications as "taking one for the team".)
[02:42] <SteveA>  * Keep, Bag, Change
[02:42] <SteveA> 7
[02:42] <SteveA> 6
[02:43] <SteveA> 5
[02:43] <SteveA> 4
[02:43] <jamesh> kiko: with doctests you often end up concatenating a bunch of tests that should be independent, which can be a problem
[02:43] <SteveA> 3
[02:43] <SteveA> 2
[02:43] <SteveA> 1
[02:43] <SteveA> ok
[02:43] <kiko> (mpt, ah, I thought it was that. thanks!)
[02:43] <SteveA>  * Three sentences
[02:43] <SteveA> please paste them now
[02:43] <mpt> DONE: landed Rosetta fixes; LaunchpadLoginService; bug fixes
[02:43] <mpt> TODO: Internet Explorer debugging; MaloneSimplifications; bug fixes
[02:43] <mpt> BLOCKED: no
[02:43] <malcc> DONE: Peer review of process-upload-tidy, initial completion and testing of publish-distro-optimization. Working towards clear decks for PPA.
[02:43] <malcc> TODO: Land both these branches and hence finish clearing decks for PPA.
[02:43] <malcc> BLOCKED: No
[02:43] <flacoste> DONE: Specs writing, searchTickets() method, improved ITicketTarget test coverage
[02:43] <flacoste> TODO: Added UI for searchTickets, implement SupportTrackerWorkflowSpec
[02:43] <flacoste> BLOCKED: no
[02:43] <spiv> DONE: Reviews, work on spurious merge failures, work on "bzr webserve" for branches in launchpad (bug 49991), muck about with voip.
[02:43] <Ubugtu> Malone bug 49991 in launchpad-bazaar "browse supermirror branches with bzr server" [High,Confirmed]  http://launchpad.net/bugs/49991
[02:43] <cprov> DONE: soyuz bug fixing, PPA discussion, drescher madness troubleshooting
[02:43] <cprov> TODO: high priority bug triage/fixing, review/merging pending branches and PPA real world
[02:43] <cprov> BLOCKED: None
[02:43] <spiv> TODO: bug 49991, land david/launchpad/bazaar-ui
[02:43] <Ubugtu> Malone bug 49991 in launchpad-bazaar "browse supermirror branches with bzr server" [High,Confirmed]  http://launchpad.net/bugs/49991
[02:43] <BjornT> DONE: made it possible to search bugs depending on their upstream status. started with SimpleBugKeywords, finishing the spec, start implementing. reviews.
[02:43] <spiv> BLOCKED: no
[02:43] <Kinnison> DONE: Lots of discussion with malcc and cprov about PPA including a skype call or two. Helped resolve some other bits and bobs with builds etc. Preparing real specification for PPA
[02:43] <BjornT> TODO: Finish the first phase of SimpleBugKeywords. reviews.
[02:43] <danilos> DONE: Started with accounts and docs, visa and travel arrangements, fix for bug #1788, commented on others.
[02:43] <bradb> DONE: Put security/privacy cb collapse up for review. The Landscape Hack (TM). A whack of discussion. Fixing xmlrpc API based on updates from the Paris sprint.
[02:43] <danilos> TODO: Fix remaining bugs from initial Carlos list and select/evaluate other specs/features/bugs to work on.
[02:43] <danilos> BLOCKED: By my learning better self-organization.
[02:43] <BjornT> BLOCKED: no
[02:43] <Ubugtu> Malone bug 1788 in rosetta "Saving preferred languages looks like it does nothing" [Medium,In progress]  http://launchpad.net/bugs/1788
[02:43] <Kinnison> TODO: Have pre-impl PPA meeting with malcc/cprov. Begin implementation of PPA and delegate tasks to malcc/cprov as discussed in our meeting.
[02:43] <bradb> TODO: Nag reviewers. Wrap up filebug xmlrpc, then go more into release management.
[02:43] <kiko> DONE: performance improvements, spec reviewing, code reviewing, management
[02:43] <Kinnison> BLOCKED: None.
[02:43] <salgado> DONE: Finished implementation of KarmaContext, lots of small bug fixes/tweaks, code review
[02:43] <salgado> TODO: More random fixes, code review
[02:43] <salgado> BLOCKED: No
[02:43] <bradb> BLOCKED: No.
[02:43] <jamesh> DONE: code review, get a few branches merged, implement SF tracker import for Py
[02:43] <jamesh> thon CallForTrackers competition
[02:43] <jamesh> TODO: code reviews, finnish off Dyson robustness fixes, hopefully get a live Pyt
[02:43] <jamesh> hon SF tracker import going.
[02:43] <jamesh> BLOCKED: Python tracker stuff is blocked, but I have other stuff to work on.
[02:44] <carlos> DONE: vacation, bug #6459 review comments and merge, POSubmission duplicates debugging and fix, Translation migrations between distroreleases, introduce danilo to Canonical/Launchpad development, Help XaraXL maintainers to contact their translations to ask them to sign a copyright assignment
[02:44] <Ubugtu> Malone bug 6459 in rosetta "Timeout error on distribution release language page" [Critical,Fix committed]  http://launchpad.net/bugs/6459
[02:44] <carlos> TODO: Finish translation migration, keep helping danilo, fix bug #44860, Open Edgy for translations and implement new automatic ways to import .po files for Edgy.
[02:44] <carlos> BLOCKED: No
[02:44] <Ubugtu> Malone bug 44860 in rosetta "Crash when we try to pass a query string to a POFile that doesn't exist yet." [High,Confirmed]  http://launchpad.net/bugs/44860
[02:44] <matsubara> DONE: oops report analysis, fixed oops bugs, ownership reassignment bug.
[02:44] <matsubara> TODO: more oops bugs and triage
[02:44] <matsubara> BLOCKED: no
[02:44] <kiko> TODO: rosetta browser code work. potentially debbugs and +translations fix.
[02:44] <kiko> BLOCKED: no
[02:44] <stub> TODO: Land test suite updates, PillarNames, test server setup
[02:44] <stub> DONE: test suite work, pillarnames work
[02:44] <stub> BLOCKED: No
[02:44] <SteveA> DONE: preparing mark's spec code for landing
[02:44] <SteveA> TODO: finish landing it, management meetings
[02:44] <SteveA> BLOCKED: on graphviz packages from the distro team
[02:45] <SteveA> jamesh: how is the python tracker stuff blocked?
[02:45] <mpt> implementation of keywords?
[02:45] <jamesh> SteveA: getting the live import up is blocked on having the demo environment sorted.
[02:45] <SteveA> ok
[02:45] <SteveA> I think that's it
[02:46] <SteveA> thanks everyone!
[02:46] <SteveA> MEETING ENDS
[02:46] <bradb> jamesh: who's need to unblock that, and are they working on it?
[02:46] <danilos> ok, a nice first timer, thank you SteveA as well ;)
[02:46] <bradb> s/need/needed/
[02:46] <SteveA> oh, welcome to danilo
[02:46] <jamesh> bradb: sounds like stub is on top of it
[02:46] <bradb> cool
[02:47] <SteveA> danilo is working with carlos on rosetta, in case anyone didn't know
[02:47] <carlos> see you later!
[02:47] <stub> jamesh: Once I get the DB setup are you able to take it from there? I'll request the HTTP redirects, but we can work without them for a little while.
[02:47] <jamesh> bradb: as far as code goes, the only bit missing is the keywords
[02:48] <jamesh> stub: I suppose so.  Is there much to do different to running LP locally?
[02:49] <stub> jamesh: Nope.
[02:49] <flacoste> kiko: did you read mpt comments on SupportTrackerWorkflow?
[02:49] <jamesh> stub: okay.  cool
[02:49] <bradb> jamesh: It may be best to proceed in lieu of keywords, since we've only got a few weeks left (technically about 3, but mythical-man-monthly, about 1.5)
[02:50] <jamesh> bradb: there may be some issues that turn up when running the importer on the full Python dataset, but I don't think they'll pose much of a problem.
[02:50] <stub> mpt: Is there a reason you are maintaining the spec -> bug mapping in the wiki when we can do this on the Launchpad side of things?
[02:50] <kiko> flacoste, I did. I am musing about the checkboxes.. I don't quite know if I agree with that.
[02:50] <jamesh> I should be able to start testing some aspects of that before the DB is ready
[02:51] <flacoste> kiko: the major changes is that we would need to track multiple best answers
[02:51] <stub> jamesh: db will be ready in an hour or two
[02:51] <flacoste> kiko: whereas we only track one now
[02:51] <BjornT> jamesh, bradb: i plan to have the first phase of the keywords implementation ready for review tomorrow or on monday.
[02:51] <jamesh> stub: cool!
[02:51] <kiko> flacoste, yeah, I realized that. I don't like that idea very much
[02:51] <bradb> BjornT: cool
[02:52] <stub> jamesh: and you have sudo access to the 'launchpad' user.
[02:52] <flacoste> kiko: me neither
[02:53] <flacoste> kiko: what do you think of Satisfied instead of Answered_confirmed?
[02:53] <kiko> flacoste, were you suggesting /displaying/ Answered_confirmed?!
[02:53] <mpt> stub, that way (a) it's much easier to check that a spec is designed to resolve a bug, (b) I can say why a particular bug should be rejected rather than fixed, (c) it's faster, and (d) I can do it for specs whether or not they're on software entities that are registered in Launchpad
[02:54] <mpt> stub, reasons (c) and (d) probably will go away once specs are edited in LP itself
[02:54] <flacoste> kiko: not necessarly, in fact, if you look at the new mockups, you'll see the label 'The user confirmed this answer solved his problem' around the answer
[02:54] <bradb> BjornT: what's the status of the TestTransport and all that?
[02:54] <flacoste> kiko: so probably something along that in listings
[02:55] <mpt> Bugs are just use cases with added realism
[02:55] <stub> mpt: Ta. So it looks like spec tracker features were implemented in the wrong order, as edit-within-launchpad would have been more useful than all the other knobs.
[02:56] <mpt> stub, definitely
[02:56] <BjornT> bradb: i plan to take a look at it again when i'm finished with the keywords stuff.
[02:56] <bradb> BjornT: ok, thanks
[02:57] <mpt> stub, I may have forgotten to hit the "Trivial" checkbox for a couple of bug reports added to specs today, sorry about that.
[02:58] <stub> mpt: I'm not worried about that. Its just frustrating when we can't dogfood our own product ;)
[02:59] <stub> It happens too often
[02:59] <kiko> flacoste, I'm unsure about Satisfied, too
[02:59] <kiko> but...
[02:59] <flacoste> kiko: in a listing, probably Confirmed Answer would be ok
[03:00] <flacoste> kiko: we would have 'Answered' and 'Confirmed Answer'
[03:00] <kiko> flacoste, other ideas are: Fulfilled, Responded, Endorsed, Ratified..
[03:00] <kiko> yeah, Confirmed Answer sound ok to me.
[03:01] <SteveA> BjornT: 
[03:01] <SteveA>     def __new__(cls, *args, **kw):
[03:01] <SteveA>         obj = super(LaunchpadFault, cls).__new__(cls, *args, **kw)
[03:01] <SteveA>         obj.__init__(*args, **kw)
[03:01] <SteveA>         return xmlrpclib.Fault(obj.faultCode, obj.faultString)
[03:01] <SteveA> 
[03:02] <SteveA> add that to LaunchpadFault for a quick fix
[03:03] <SteveA> along with a docstring saying "XXX: ensure all launchpad faults are of type xmlrpc.Fault"
[03:05] <BjornT> SteveA: do you think it's important enough to fix it ASAP? i was planning to fix it properly next week.
[03:05] <SteveA> flacoste: you said "i thought about that, but what when some cases needs modification for a particular implementation"
[03:05] <flacoste> SteveA: yes, Monday I wrote an Interface test for ITicketTarget
[03:06] <SteveA> that's an interesting point.  I think that for an interface test, the .txt file portion should remain the same always -- it is the part that is testing the interface.  The "harness" part should provide implementations of the interface, and also individual "harnesses" for each implementation
[03:06] <flacoste> SteveA: I agree in theory
[03:06] <SteveA> I think something like that would allow us to retain the benefits of documenting what an interface does, and account for differences in how implementations need to be set up
[03:07] <SteveA> if you want to experiment with these ideas sometime, please do so.  maybe in one of those 1-2 hour slots for quick experiements and fixes.
[03:08] <SteveA> BjornT: I think a quick fix would be nice to get in next week's rollout.
[03:08] <SteveA> a full fix would be even better.
[03:09] <SteveA> people are starting to use the xmlrpc stuff, and I'd like to greet them with nice faults rather than crashes
[03:09] <SteveA> BjornT: I can add this code as a [trivial]  if you'll r= it
[03:09] <SteveA> or even as r=you... no need for [trivial]  in that case
[03:10] <kiko> bradb, can you give me a URL to your patch again?
[03:10] <flacoste> SteveA: the problem I had with ITicketTarget is that the semantics of the interface are somewhat different in SourcePackage than Product and Distribution
[03:11] <SteveA> how do you mean?
[03:11] <SteveA> can you give an example of what is different?
[03:11] <flacoste> SteveA: yes...
[03:12] <bradb> kiko: https://chinstrap.ubuntu.com/~jamesh/pending-reviews/bradb/launchpad/malone-smallfixes/full-diff
[03:12] <flacoste> SteveA: I had to override two tests (on the 8 found in TicketTargetInterfaceTest) in the SourcePackage case
[03:13] <SteveA> I mean, please explain in english what the semantic difference between a SP ticket target and a Product ticket target is
[03:13] <SteveA> if there's a semantic difference, then perhaps one interface definition is not sufficient to cover both cases
[03:13] <BjornT> SteveA: sure, r=me
[03:13] <SteveA> thanks BjornT 
[03:14] <flacoste> SteveA: in the SourcePackage case, for example, ticket.target = sourcepackage.distribution.target
[03:14] <bradb> we need an [airplane]  tag
[03:14] <LarstiQ> bradb: ooh that will be fun to review
[03:14] <flacoste> SteveA: and the initial subscription list is ITicketTarget(sourcepackage).support_contact + ITicketTarget(sourcepackage.distribution).support_contacts
[03:14] <SteveA> that's a difference in the implementation, not a semantic difference
[03:15] <flacoste> SteveA: I agree, but these differences in implementation would make the base interface test fails
[03:15] <SteveA> the plan I sketched about having a harness for each implementation yet the same .txt test would still work
[03:16] <flacoste> for me the harness would only create an instance and make it available in the globs of the *.txt doctest
[03:17] <flacoste> to solve the ITicketTarget case, some checks would also needed to be made by the harness
[03:17] <flacoste> so that different implementations can have different checks in some cases
[03:18] <flacoste> that would be feasible, but I'm not sure it would look pretty
[03:19] <SteveA> I agree.  It would take some work to get such a system working elegantly.
[03:20] <SteveA> but then again, that's not really an interface test
[03:20] <SteveA> what I mean is this
[03:20] <SteveA> an interface test is something you can run against any valid implementation of the interface
[03:21] <flacoste> i agree, that I'm mixing a little bit unit test and interface test here, but not that much
[03:21] <SteveA> in this case, the test would be that the target is some valid database object, or that the subscription list contains some team or something like that
[03:21] <SteveA> the other more specific things are tests of that particular implementation of the interface
[03:21] <SteveA> and I think it is best to keep these separate
[03:21] <SteveA> in the sense that one is an interface test that applies all over and it "bound" to that interface
[03:22] <SteveA> and the other is "bound" to a particular implementation
[03:22] <SteveA> so, no special harness needed for each implementation
[03:22] <SteveA> just an interface test .txt file, and something that sets up the instances for being tested
[03:22] <SteveA> maybe a harness to put the instances into particular states for testing
[03:24] <flacoste> SteveA: i can agree with that rationale
[03:36] <bradb> BjornT: Any idea about this error? https://chinstrap.canonical.com/~dsilvers/paste/fileeVO0BP.html
[03:37] <bradb> I was trying a basic sanity check from the cmd line.
[03:37] <bradb> I don't understand why that AttributeError is being raised, since I assume that xmlrpc requests are working fine for bzr.
[03:37] <SteveA> bradb: the answer is simple
[03:37] <BjornT> bradb: you're trying to access the web interface, not the xmlrpc one
[03:37] <SteveA> bradb: xmlrpc.launchpad.whatever
[03:38] <SteveA> we only enable the xmlrpc service on specific hosts
[03:38] <SteveA> it isn't available on the same host as for normal web requests
[03:38] <SteveA> also...
[03:38] <SteveA> when you use xmlrpclib.Server()
[03:38] <SteveA> make sure the URL ends in a /
[03:38] <SteveA> otherwise you get different xmlrpc behaviour
[03:39] <BjornT> bradb, SteveA: the xmlrpc server is still running on a separate port, though.
[03:39] <SteveA> yeah, the default zope one is
[03:39] <SteveA> which is why it doesn't have an oops id
[03:39] <SteveA> an oopsid attribute
[03:40] <bradb> ah, /that/ explains it
[03:40] <SteveA> that'll be something we should turn off
[03:41] <bradb> SteveA: I have some xmlrpc code that I think is ready for review, except that I don't know if it works, because I've only been able to test the view, not the xmlrpenis. What should I do with this code?
[03:42] <SteveA> 1. test it manually to see if it works
[03:42] <SteveA> 2. ask bjorn for advice
[03:42] <SteveA> I'm not going to be able to look at this for a while, as I'm busy with other stuff right now
[03:42] <bradb> BjornT: is there a simple fix to make this manually testable?
[03:43] <SteveA> well
[03:43] <SteveA> okay
[03:44] <SteveA> here's how it goes
[03:44] <SteveA> on your development setup
[03:44] <SteveA> the xmlrpc server is running on some port
[03:44] <SteveA> 8081
[03:44] <bradb> 8081
[03:44] <bradb> yeah
[03:44] <SteveA> so, use xmlrpclib.Server('http://localhost:8081/')
[03:45] <bradb> i assumed that was the default zope one that wouldn't work, but i guess not
[03:45] <SteveA> this will be changing to xmlrpc.launchpad.dev when we include the xmlrpc stuff into the rest of the vhosting configuration
[03:45] <SteveA> that's our special one
[03:45] <carlos> matsubara: ping
[03:45] <SteveA> bradb: btw, you said "xmlrpenis" earlier.  That's a unique invention according to google.
[03:46] <matsubara> hey carlos 
[03:46] <bradb> SteveA: that might be good news
[03:46] <carlos> matsubara: hey
[03:46] <carlos> do you have time now to play with staging?
[03:47] <kiko> I hope xmlrpenis does not become a real word
[03:47] <SteveA> it's in public irc logs now
[03:47] <SteveA> so, it'll be on google soon
[03:47] <matsubara> carlos: sure
[03:47] <BjornT> SteveA: speaking of which, do you see any problems with adding the xmlrpc stuff to the vhosting configuration? i have a branch which is half-way there (for testing xmlrpc properly)
[03:47] <malcc> I think it's surprising the internet has come this far without any kind of remote penis protocol
[03:47] <carlos> malcc: ;-)
[03:47] <matsubara> carlos: so, usually what are the values that you use when debugging rosetta pages there?
[03:47] <malcc> Another victory for xml
[03:48] <SteveA> BjornT: I don't see a problem.  We just need to be careful when rolling it out, to change the apache config, and also to tell people what local config needs amending.
[03:48] <carlos> matsubara: those values are not useful at all because I use to put there an extra zero of what we have on production....
[03:48] <SteveA> BjornT: it will be a good thing, as we'll be able to test xmlrpc views using a server transport implementation that talks to the publisher.
[03:48] <carlos> matsubara: my debugging is not for timeouts but for functionality
[03:48] <SteveA> or something like that
[03:48] <SteveA> i think you know it better than me :-)
[03:48] <matsubara> carlos: I see.
[03:49] <carlos> matsubara: staging is slower than production so we need something higher than on production
[03:49] <BjornT> SteveA: right. i'll try to land that branch next week then.
[03:49] <SteveA> cool
[03:54] <danilos> off to lunch
[04:04] <salgado> stub, ping?
[04:04] <stub> salgado: pong
[04:12] <Keybuk> SteveA: you will be appalled to know that Dragostea Din Tei was voted #5 in the "Worst Ever Pop Song" chart on TV just now :-/
[04:16] <SteveA> Keybuk: obviously the voters don't appreciate camp moldovan airplane dancing
[04:18] <Keybuk> SteveA: did you know one of the former members of O-Zone sung at the Eurovision this year?
[04:18] <SteveA> I did not know that.  But I can believe it.
[04:21] <SteveA> Keybuk: what were the four worse songs?
[04:22] <Keybuk> SteveA: I didn't stay around to watch ;)
[04:23] <SteveA> (a late late lunch)
[05:24] <stub> Don't worry - that song is really popular with the bargirls over here.
[05:31] <sivang> stub: where you are currently? :)
[05:49] <SteveA> re
[05:54] <kalosaurusrex> any admins on?  need some assistance..
[05:55] <SteveA> hi kalosaurusrex 
[05:55] <SteveA> what's up?
[05:56] <kalosaurusrex> SteveA: hey sorry.  I'm trying to figure out why my project isn't showing up under my "member of projects page..
[05:57] <kalosaurusrex> SteveA: and I can't change the project maintainer, says I don't have access.
[05:57] <kalosaurusrex> https://launchpad.net/products/hplip/
[05:57] <kalosaurusrex> sure I'm just doing something wrong.
[05:57] <kalosaurusrex> as well I want people to be able to join the project.
[05:58] <SteveA> what's your username in launchpad?
[05:58] <SteveA> BjornT: enjoying the storm? :-)
[05:58] <kalosaurusrex> kalosaurusrex
[05:58] <kalosaurusrex> :)
[05:59] <kalosaurusrex> er
[05:59] <kalosaurusrex> wait
[05:59] <SteveA> that project was registered by ke7ezt
[05:59] <kalosaurusrex> no sorry I'm wrong it's ke7ezt
[06:02] <kalosaurusrex> SteveA: any thoughts?
[06:02] <kalosaurusrex> brb afk 5 min
[06:04] <BjornT> SteveA: nah, i'm just trying to get asterisk running on my router
[06:07] <SteveA> actually, I meant "are you enjoying the storm", not "did the storm kick you offline" :-)   but I can see how it could be read both ways
[06:15] <kalosaurusrex> back
[06:15] <kalosaurusrex> any ideas on what I'm doing wrong here?
[06:16] <kalosaurusrex> I want to pitch to the team to use launchpad as our support entry point, but I need to fix this..
[06:19] <mpt> kalosaurusrex, a product isn't something that people join
[06:19] <kalosaurusrex> hmm okay.  
[06:20] <mpt> kalosaurusrex, there are already support requests for it
[06:21] <mpt> which ... all appear to be Aaron Albright talking to himself
[06:21] <kalosaurusrex> mpt:  yes but they are old, and I had to enter them manually.  
[06:21] <kalosaurusrex> I wanted to use them to track our email support requests.  but I'd rather just have the team use launchpad as our support forum.  instead of the mailing lists.
[06:21] <kalosaurusrex> which are really hard to keep track of.
[06:22] <kalosaurusrex> I'd rather like to clear all those out and start clean if possible.
[06:22] <mpt> ok
[06:22] <mpt> So, our UI for deleting stuff is "find the DBA on IRC"
[06:22] <matsubara-lunch> kalosaurusrex: about the "can't change product maintainer" that's bug 41639, it's already fixed and will be rolled out on the next production update
[06:22] <Ubugtu> Malone bug 41639 in launchpad "Product owner should be able to reassign ownership to another user." [High,Fix committed]  http://launchpad.net/bugs/41639
[06:23] <kalosaurusrex> ahh okay
[06:23] <mpt> kalosaurusrex, either talk to stub when he wakes up, or e-mail launchpad-users@ with your request for deletion
[06:24] <kalosaurusrex> mpt: okay will do.  thanks.  so sorry if I'm being dense here, there are other developers that would use it for the HPLIP project.  how do they associate with the product?
[06:24] <kalosaurusrex> I'm used to using sourceforge and it's a tad different.  better..mind you.
[06:24] <kalosaurusrex> launchpad is better I mean
[06:24] <kalosaurusrex> imv
[06:25] <mpt> kalosaurusrex, they don't need to really, but if you want to you could make a team to be the "driver" of the product
[06:25] <mpt> https://launchpad.net/people/+newteam
[06:26] <mpt> then https://launchpad.net/products/hplip/+driver
[06:35] <SteveA> BjornT / matsubara-lunch: what is the xmlrpc "faults must be Faults" bug?
[06:36] <SteveA> I can't find it in malone
[06:39] <BjornT> SteveA: bug 52033 (the summary and description could be better...)
[06:39] <Ubugtu> Malone bug 52033 in launchpad-bazaar "register-branch --author without email address" [Medium,Confirmed]  http://launchpad.net/bugs/52033
[06:49] <kalosaurusrex> mpt: sorry what's the full email address for the launchpad-users@..
[06:52] <bradb> kalosaurusrex: See the channel topic.
[06:54] <kalosaurusrex> eh dur
[06:54] <kalosaurusrex> thanks 
[06:57] <bradb> and it includes snippets of the Jackson Five
[07:20] <SteveA> kiko: hi
[07:43] <kiko> SteveA!
[07:43] <flacoste> SteveA: I rewrote my interface test as a doctestfile, it works nicely!
[07:43] <SteveA> cool
[07:44] <kiko> what's up stever
[07:44] <salgado> kiko, https://chinstrap.ubuntu.com/~dsilvers/paste/fileFAD0lJ.html
[09:19] <salgado> kiko, https://chinstrap.ubuntu.com/~dsilvers/paste/filedfENS5.html
[09:19] <salgado> would you review it for me, or should I use pending-reviews?
[09:20] <kiko> salgado, I'll review it.
[09:22] <salgado> cool!
[10:28] <kalosaurusrex> I need to pitch launchpad to my management--and I was hoping that you guys may be able to give me some good pointers to hit on..
[10:28] <LarstiQ> kalosaurusrex: well, why do you need to pitch it?
[10:29] <kalosaurusrex> LarstiQ: because we just recently switched from using the sourceforge forums to a mailing list for support.  but it's a HUGE pain to keep track of the status of each support request.
[10:29] <kalosaurusrex> so they may hesitate on doing another change so recently.
[10:30] <LarstiQ> ah, I'm not familiar with the support tracker side of launchpad
[10:32] <kalosaurusrex> ahh that's cool.
[10:32] <kalosaurusrex> I wish we could just move away from sourceforge all together.
[10:32] <kalosaurusrex> and just use launchpad. but that won't happen.
[10:37] <LarstiQ> how so?
[10:39] <kalosaurusrex> our website is hosted by them, at least currently.  I figured the first step would be to use launchpad as our support forum.  and slowly try and convert everyone :)
[10:44] <LarstiQ> what is that you do?
[10:45] <kalosaurusrex> oh, http://hplip.sourceforge.net
[10:48] <LarstiQ> oooh, hplip
[10:49] <kalosaurusrex> yes sir
[10:49] <LarstiQ> Where does development of that live?
[10:49] <kalosaurusrex> what do you mean?
[10:50] <LarstiQ> cvs/svn?
[10:50] <LarstiQ> on sourceforge?
[10:50] <kalosaurusrex> oh.  it's on sourceforge.
[10:51] <kalosaurusrex> but the dev side isn't open.  all in house until we release.
[10:52] <LarstiQ> I guess most of the expertise is in house anyway.
[10:56] <kalosaurusrex> yeah.  it's not the most interesting project. but I get a lot of linux experience!
[10:58] <kiko> bradb, mpt: care to review: https://chinstrap.ubuntu.com/~dsilvers/paste/fileMZiYZj.html -- ?
[11:00] <flacoste> kalosaurusrex: expect some changes in the support request forum in the coming months
[11:00] <flacoste> kalosaurusrex: you might want to look at https://launchpad.net/products/launchpad-support-tracker/+specs to see what is coming up
[11:01] <flacoste> kalosaurusrex: the 1.0 milestone
[11:03] <flacoste> kalosaurusrex: and btw, thanks! I'm a happy hplip user :-)
[11:03] <bradb> kiko: the lateste bugs portlet should probably be updated then too, right?
[11:04] <kiko> bradb, how would I do that?
[11:04] <kiko> I don't think so...
[11:05] <kiko> and if so, then I should probably change the bug's fmt:icon
[11:05] <kalosaurusrex> flacoste: thank you!  I'll look over it.  and your welcome lol :)
[11:06] <kalosaurusrex> I really only do the primary testing and support.  as well as other side projects and such.  good fun
[11:06] <bradb> kiko: hm, maybe updating the portlet is unnecessary
[11:07] <kiko> yeah, was thinking so too
[11:08] <bradb> kiko: the patch looks good to me.
[11:08] <bradb> oh, one thing
[11:09] <kiko> yeah?
[11:09] <bradb> hiding this behind a bug/fmt:icon might be nice, because it's easy to test
[11:09] <bradb> if that's doable
[11:09] <kiko> well
[11:09] <kiko> where is that used?
[11:10] <bradb> i don't know that there is a fmt:icon for bug atm. it doesn't look like there is.
[11:10] <kiko> there's one for bugtask though
[11:10] <kiko> that should be enough
[11:11] <kiko> I'll do that
[11:11] <bradb> another option is to put it behind bugtask's
[11:11] <bradb> yeah
[11:13] <kiko> doing so now..
[11:13] <kiko> bradb, are the bugtask-macros-tableview unused now?
[11:16] <bradb> kiko: that stuff should be being used, but i'm not sure that the whole file is used. your asking makes me want to verify though...
[11:17] <bradb> kiko: at least the advanced search form is used from there
[11:19] <bradb> it could be that that's the only thing being used from that file.
[11:19] <bradb> i should context switch back to responding to the security/privacy code review
[11:24] <kiko> sure
[11:31] <kalosaurusrex> hey can I have users submit support requests via emial?
[11:31] <kalosaurusrex> meial
[11:31] <kalosaurusrex> eh email
[11:33] <kiko> kalosaurusrex, yes, you certainly can.
[11:33] <LarstiQ> kalosaurusrex: it is possible with bugs, so I'd think with support requests too
[11:33] <kiko> IIRC you have them write to new@support.launchpad.net
[11:33] <kiko> or hmm, flacoste or BjornT will tell you :)
[11:34] <kalosaurusrex> hmm awesome!
[11:34] <kalosaurusrex> kiko: not clear on that, I just have them email new@support.launchpad.net and it will go to my project support db?
[11:34] <kiko> kalosaurusrex, yes, but I don't know the exact address. hang on.
[11:35] <kalosaurusrex> kiko: thank you so much!!
[11:35] <kiko> kalosaurusrex, okay, so far I can confirm you can reply to support requests via email.
[11:37] <kiko> kalosaurusrex, and I believe new@support.launchpad.net also works.
[11:37] <kiko> kalosaurusrex, just remember to include an affects line
[11:39] <matsubara> kiko: I don't think that works atm
[11:41] <kiko> matsubara, awwwwa
[11:41] <kalosaurusrex> well that sucks lol
[11:42] <LarstiQ> matsubara: how far is it from working/
[11:42] <matsubara> well you can use the email interface
[11:42] <matsubara> but AFAICS it doesn't support commands in the same way malone does
[11:43] <matsubara> LarstiQ: flacoste or BjornT could answer that.
[11:43] <kiko> you mean you can't file new bugs, matsubara?
[11:44] <matsubara> bugs? of course you can
[11:44] <matsubara> I think we're talking about tickets
[11:46] <matsubara> kiko: I just glance at the code but it doesn't look like, the ticket email interface supports any kind of commands.
[11:46] <LarstiQ> matsubara: soo, how would you get the support ticket to the right place? Not at all?
[11:47] <matsubara> $ticket_number@support.launchpad.net does work
[11:47] <matsubara> LarstiQ: what doesn't work is the new@support.launchpad.net thing
[11:48] <LarstiQ> matsubara: right, which is important for kalosaurusrex 
[11:49] <kiko> I meant tickets.
[11:50] <LarstiQ> is there a way for the bugs search to restrict to the summary?
[11:51] <kiko> LarstiQ, not currently.
[11:51] <kiko> (but it's planned)
[11:51] <LarstiQ> kiko: I hope so, trying to see if a debian bug is already present in lp is driving me crazy atm
[11:53] <kiko> LarstiQ, what bug?
[11:54] <LarstiQ> 374673
[11:55] <LarstiQ>  kiko: if the issue is already known I'd like to link the debian bug to it, otherwise report a new one
[11:55] <LarstiQ> well, known to lp at least
[11:55] <kiko> how are you searching?
[11:57] <LarstiQ> just plugging variations of 'read only' into https://launchpad.net/products/bzr/+bugs
[12:08] <kalosaurusrex> LarstiQ: thanks for trying to work something out.  I really do appreciate it.
[12:10] <LarstiQ> np, one day I might need the functionality myself :)