[01:02] <carlos> lifeless: hi, around?
[01:05] <lifeless> yes
[01:05] <carlos> lifeless: I'm having some problems with bzr push
[01:05] <carlos> lifeless: I just sent an email to launchpad, do you have sometime to help me?
[01:09] <lifeless> sure
[01:10] <lifeless> ok
[01:10] <lifeless> for the sftp one, please file a bug
[01:10] <lifeless> I dont want to try to solve it right now as we are not using sftp for launchpad
[01:10] <carlos> ok
[01:12] <lifeless> for the rsync one, does /home/warthogs/archives/carlos/launchpad/ exist on chinstrap ?
[01:12] <carlos> yes
[01:12] <carlos> the "trivial" branch is not a new one
[01:12] <carlos> and I'm updating it not doing a full upload
[01:13] <carlos> anyway, I checked it just in case and the path is correct
[01:17] <lifeless> try putting the path in
[01:17] <carlos> bzr push chinstrap.ubuntu.com:/... ?
[01:18] <carlos> already done, same error
[01:18] <lifeless> can you push to a new name ?
[01:18] <lifeless> .../launchpad/trivial-2
[01:19] <carlos> let me try it...
[01:20] <carlos> yes, It allows me to push to a new path
[01:20] <lifeless> ok
[01:20] <lifeless> when that finishes
[01:21] <lifeless> try pushing to that same new path again
[01:21] <carlos> ok
[01:23] <carlos> lifeless: I suppose that if that works, I just need to push again all my branches that give me errors...
[01:26] <lifeless> I'd say so
[01:31] <jblack> carlos: what's up?
[01:36] <carlos_> my network went down...
[01:36] <carlos_> lifeless: it failed because the network outage, but a new push is working now
[02:02] <mpt_> Gooooooooooooooooooood afternoon Launchpadders!
[02:02] <mpt_> BjornT, thanks for removing the attachment cruft from bug comments
[02:30] <mpt_> Kinnison, pong
[02:33] <carlos> mpt_: it's a bit late at this side of the world...
[02:33] <carlos> so I don't think Kinnison is around...
[02:36] <ajmitch> afternoon mpt_
[02:37] <mpt_> yeah, nor was I around when he pinged :-]
[03:08] <stub> spiv: ping
[03:13] <spiv> stub: pong
[03:14] <stub> spiv: Are you able to look at that librarian connection validation thing today or should I work on that?
[03:15] <spiv> stub: I can do that.  I think I can add the last-accessed feature at the same time.
[03:15] <spiv> Seeing as I'll be poking code in that area.
[03:16] <spiv> But right now, it's lunch time :)
[03:16] <stub> spiv: Ok. I'll want to push this to staging today, so ping me when you are done or if you get stuck.
[03:16] <spiv> Will do.
[03:16] <spiv> I'll start on it straight after lunch.
[03:17] <stub> Mmm... breakfast...
[03:27] <mpt_> jamesh, ping
[03:55] <dilys> Merge to devel/launchpad/: [r=stub]  Vocabulary optimizations (r3059: Guilherme Salgado, Stuart Bishop)
[03:57] <mpt_> ugh, bzr --version produces an OSError
[03:57] <lifeless> funkay
[03:58] <mpt_> ah, my terminal was in a directory that I'd since deleted and re-created
[03:58] <mpt_> so I could understand bzr diff producing that error
[03:58] <mpt_> but not bzr --version
[04:27] <jamesh> mpt_: pong
[04:29] <mpt_> jamesh, how is automating the Oops summaries going?
[04:29] <jamesh> I'll have it emailing the list today
[04:29] <mpt_> great
[04:30] <mpt_> I can clean up the error pages to discourage reporting bugs, once the summaries are doing a better job of telling us what's urgent than bug reports are
[05:31] <dilys> Merge to devel/launchpad/: [r=stub]  Add an option allowing a person to hide their email address from other Launchpad users (r3060: Stuart Bishop, Guilherme Salgado)
[06:08] <dilys> Merge to devel/launchpad/: [trivial]  Add missing comma (r3061: Stuart Bishop)
[06:55] <dilys> Merge to devel/launchpad/: [trivial]  Fix typos and lower isolation level of update-stats.py (r3062)
[07:17] <dilys> Merge to devel/launchpad/: [trivial]  More transaction isolation updates (r3063: Stuart Bishop)
[08:18] <carlos> morning
[08:26] <SteveA> morning
[08:27] <mpt_> hi SteveA
[08:28] <SteveA> hi matthew
[08:36] <jamesh> SteveA: could you check to see if a launchpad error summary got caught by the mailman filters recently?
[08:37] <SteveA> jamesh: i'll look
[08:37] <jamesh> (and if so, add the from address used as an allowed address)
[08:37] <jamesh> thanks
[08:38] <SteveA> stub: on lowering the isolation of individual cron scripts: does it work well?  i was thinking that we'd have to lower the isolation of everything else too, to get some effect.
[08:39] <stub> SteveA: It is a start. I'm still mulling over dropping the isolation level of the primary launchpad instance. I notice that the default in SVN psycopg is now read committed too.
[08:39] <stub> (I'm sorting out sessions though as that seems to be the primary source of our serialization exceptions at the moment)
[08:40] <SteveA> jamesh: i don't see anything from mailman about a summary
[08:41] <SteveA> the main constraint on isolation levels for sessions is that we don't get embarassing "i'm logged in but see his stuff" session id collissions / duplicates.
[08:42] <SteveA> anything else doesn't matter so much
[08:43] <SteveA> stub: what kind of things does an isolation level more isolated that read committed give us?
[08:43] <SteveA> i'm sure i used to know, but it is now obscure to me :-)
[08:43] <jamesh> SteveA: weird.  It should have had a subject line of "Launchpad Errors for 2006-02-01"
[08:43] <SteveA> nope
[08:43] <SteveA> jamesh: can you try sending a test mail from chinstrap yourself?
[08:44] <SteveA> it could be that chinstrap can't send mail to where it should go
[08:44] <SteveA> nothing in the mailq though
[08:44] <jamesh> SteveA: done.
[08:44] <SteveA> foo
[08:44] <stub> SteveA: It means if you select some results, and then select them again, you get the same list.
[08:44] <jamesh> "echo foo | mail -s Testing<EMAIL_ADDRESS>[08:45] <SteveA> stub: unless you had an intervening write in the same transaction?
[08:45] <SteveA> jamesh: received a foo
[08:45] <stub> SteveA: It means your transaction sees a consistant snapshot of the database for the entire transaction and you don't have to worry about interferance from other processes.
[08:45] <stub> SteveA: yes
[08:46] <SteveA> does it mean that if i select from table A
[08:46] <SteveA> and then wait a while
[08:46] <jamesh> SteveA: I'll try running the script again
[08:46] <SteveA> then another thread updates table B
[08:46] <SteveA> and then i select from table B
[08:46] <lifeless> SteveA: yes
[08:46] <SteveA> that i'll see the original state of table B
[08:46] <lifeless> erm, wrong nick sorry
[08:46] <lifeless> stub: I thought read commit allowed inconsistent reads
[08:47] <SteveA> lifeless: i'm asking stub about levels above read committed
[08:47] <stub> lifeless: yes. Steve was asking about isolation levels greater than read committed.
[08:47] <lifeless> oh right
[08:47] <spiv> stub: Btw, I have the database name check for the librarian working locally.  I'll give the code another look, then push it up.
[08:47] <lifeless> then my memory is fine ;)
[08:48] <SteveA> mpt_: how much longer are you around for?  shall we have a call sometime?
[08:49] <SteveA> jamesh: i have it
[08:49] <SteveA> actually, i see two of them in the admin interface of mailman
[08:49] <SteveA> i must have missed it before
[08:51] <jamesh> SteveA: okay.  Could you let one through, and add the sender address to the allowed senders?
[08:52] <SteveA> i thought i just did
[08:52] <SteveA> but i don't see the email
[08:53] <SteveA> it is in the archives though
[08:53] <SteveA> https://lists.ubuntu.com/mailman/private/launchpad/2006-February/007462.html
[08:54] <SteveA> jamesh: can you split the 404s into two lists:  one with any percentage refered from local sites, and one with all coming from elsewhere?
[08:54] <spiv> jamesh: Nice report.
[08:55] <SteveA> jamesh: in fact, three lists might be even better.
[08:55] <spiv> Heh, OOPS-32B440 is a bit of a doozy.
[08:55] <SteveA>  - 100% search bots
[08:55] <SteveA>  - any % local sites
[08:55] <SteveA>  - the rest (that is, no local sites, maybe some search bots)
[08:55] <spiv> "search bots" isn't quite an accurate term.
[08:56] <SteveA> the reason is, we should definitely fix the ones from local sites, either by changing the link or fixing the 404
[08:56] <spiv> There are some there that appear to be people pointing bzr at launchpad, thinking there's a bzr branch there.
[08:56] <SteveA> the search bots and such we should look into, but there may be a good reason for them wanting a 404
[08:56] <SteveA> and the rest is interesting because it is probably guessed / chopped URLs
[08:56] <SteveA> spiv: does bzr have a particular user agent string?
[08:57] <spiv> SteveA: Ask lifeless, I guess.
[08:57] <spiv> It probably says urllib or something.
[08:57] <lifeless> not at the moment
[08:57] <lifeless> it will say whatever urllib2 says
[08:57] <lifeless> the pycurl one -might- get a custom agent
[08:57] <spiv> SteveA: But they're easy to distinguish, it looks for ".bzr".
[08:57] <SteveA> one more request jamesh: copy the report onto some web page, and link to it from the emailed report
[08:58] <lifeless> and the supermirror will point at launchpad because some users are muppets
[08:58] <SteveA> this allows us to get to a version with clickable OOPSes
[08:58] <jamesh> spiv: at the moment, search bots == user agent strings matching a bunch of regexps I noticed accessing https://launchpad.net/robots.txt
[08:59] <spiv> jamesh: Hmm
[08:59] <lifeless> I dont think bzr could cause enough load to be a problem
[09:00] <spiv> jamesh: See e.g. OOPS-32A111
[09:00] <SteveA> lifeless: it's more about the noise.  and we can do stuff to the report to remove that noise, if needed
[09:00] <spiv> jamesh: Which appears to be categorised as a search bot, but looks like bzr to me.
[09:00] <lifeless> SteveA: ah yes, I see
[09:00] <spiv> (user agent of "Python-urllib/1.16")
[09:01] <mpt__> how about flipping it to, for example, "83% human"
[09:01] <mpt__> hmm, that sounds a bit macabre
[09:01] <SteveA> half man half biscuit
[09:02] <mpt__> I hear GWB has called for a ban on human-animal hybrids
[09:02] <jamesh> spiv: sure.  Do you think it is worth considering that kind of usage a bot then?
[09:02] <spiv> jamesh: Well, I think it's a human mistake.
[09:03] <spiv> jamesh: I *think* what's going on is that a user sees e.g. https://launchpad.net/products/bzr/+branches
[09:03] <lifeless> spiv: there are branches registered in lp with a url in lp
[09:03] <spiv> jamesh: And thinks those hyperlinks link to the bzr branch, rather than a page about the bzr branch
[09:03] <lifeless> spiv: if that makes sense
[09:03] <spiv> lifeless: People registering garbage, you mean?
[09:03] <lifeless> yes
[09:03] <lifeless> as I said, muppets
[09:03] <spiv> Right. :)
[09:04] <lifeless> or misguided
[09:04] <lifeless> something
[09:04] <jamesh> spiv: okay.  It is probably worth removing wget and python-urllib from the robots regexp
[09:04] <spiv> jamesh: So, I think it's possibly indicative of a UI problem, thus arguably worth bringing attention to.
[09:05] <spiv> But whether it's noise or valuable for these reports, I don't know :)
[09:05] <mpt__> jamesh, that's excellent work
[09:05] <mpt__> Is it possible to include referrers yet?
[09:05] <spiv> lifeless: You know, we could do something vile
[09:05] <jamesh> spiv: if the requests are due to direct human action (as opposed to a search engine spider that just goes through following links), then it probably should be counted the same way as mozilla, IE, etc
[09:05] <lifeless> nonoNO, I use vim.
[09:06] <spiv> lifeless: Make Launchpad issue redirects for accesses to a $branchpage/.bzr to the "correct" URL.
[09:06] <jamesh> mpt__: it is making use of the referer information to give the % of local referers
[09:06] <spiv> lifeless: You can slap me now ;)
[09:06] <lifeless> I'm not sure that thats a good thing to do
[09:06] <lifeless> its certainly been discussed
[09:06] <jamesh> mpt__: but not displaying it in the summary (the summary gets pretty large as you add more info)
[09:06] <spiv> lifeless: My gut feeling is no.
[09:06] <lifeless> think security and redirects - cross site scripting
[09:07] <spiv> lifeless: Right.  Requires careful thinking --> too hard :)
[09:07] <jamesh> lifeless: bzr should probably set the user agent string for its requests
[09:07] <lifeless> jamesh: AIUI urllib2 dont like dat
[09:07] <jamesh> really?
[09:07] <lifeless> jamesh: pycurl based transport may have us doing that, see above.
[09:07] <SteveA> urllib2 can do that
[09:07] <SteveA> it just takes more code than you'd think
[09:08] <lifeless> well, diminishing returns then ;)
[09:08] <lifeless> as we want pycurl to be the primary http client anyway
[09:08] <mpt__> jamesh, maybe the single top referrer for each NotFound
[09:08] <jamesh> lifeless: you just create a request object, set the User-Agent header, and issue the request
[09:10] <jamesh> something like: request = urllib2.Request('http://foo'); request.add_header('User-Agent', 'bzr/0.7'); response = urllib2.urlopen(request)
[09:17] <sivang> Morning all
[09:22] <SteveA> lifeless: i like this:  http://source.schooltool.org/coverage/
[09:22] <SteveA> drill down and see code not covered by tests
[09:25] <lifeless> nice
[09:26] <lifeless> well, as far as it goes. pity it doesn't seem to do if clause marking
[09:26] <SteveA> what is "if clause marking" ?
[09:27] <lifeless> if foo() or bar()
[09:27] <lifeless> we want to see if the or bar() side is being evaluated
[09:27] <SteveA> the code coverage stuff is done by hooking into the python interpreter, and checking what lines have been executed during a test run.
[09:27] <SteveA> so, it doesn't go within a single line
[09:27] <lifeless> yup
[09:27] <lifeless> AIUI its a known limit in the current coverage stuff
[09:28] <SteveA> could be fixed with pypy -- and make the tests take years to run
[09:28] <SteveA> i know the guys who set that report up, so we can chat with them about what they did / get code
[09:28] <lifeless> 'fixed'
[09:28] <lifeless> yes, that would be cool
[10:02] <SteveA> mpt__: ping
[10:02] <mpt__> SteveA, pong
[10:03] <SteveA> mpt: voice call?
[10:03] <mpt> sure
[10:13] <stub> I was just typing 'I have an electrician here so I might get disconnected at any moment' when he cut the power and I got disconnected.
[10:31] <cprov> stub: ehe, hi, how is it going ?
[10:32] <stub> good enough.
[10:39] <cprov> stub: just because you're not in london ;)
[10:40] <stub> Another beutiful sunny day in Bangkok.
[10:43] <carlos> SteveA: would you have some time today to talk with me about a zope3 feature?
[10:43] <SteveA> yes
[10:44] <stub> So SteveA - any reason for having launchpad-infrustructure CC'd on a load of bugs apart from annoying developers with two copies of bug email?
[10:44] <carlos> SteveA: then, please, ping me when you are free
[10:44] <carlos> thanks
[10:52] <kiko> good morning
[10:53] <kiko> hey SteveA
[10:53] <kiko> yo stub
[10:54] <carlos> kiko: morning
[10:57] <kiko> how's it going carlos?
[10:57] <kiko> stub, could we do a new gina run on production?
[10:57] <kiko> (on prat)
[10:57] <kiko> with updated code
[10:57] <carlos> kiko: fine, thanks. Preparing the PoMsgSetPage merge into rocketfuel before the meeting so we get it on production next week.
[10:57] <kiko> great
[10:58] <kiko> is there a scheduled gina run now?
[10:59] <stub> Yer - should be running every three hours
[10:59] <stub> (on prat)
[11:01] <kiko> stub, the logs seem to be overwriting themselves every time gina runs
[11:01] <kiko> at least they were the last time I looked
[11:01] <Kinnison> and regardless, the archive on prat is not being updated IIRC
[11:01] <kiko> stub, also, we would need an updated gina.
[11:02] <stub> Yup. I've emailed rt@ about the cron output.
[11:02] <kiko> so running RF gina (we've tested here on staging) on prat.
[11:02] <SteveA> stub: we have no keywords in malone.  daf and i want to classify "infrastructure" bugs (those where the party interested in the fix is other launchpad developers, not end users as such) separately from other bugs.
[11:02] <Keybuk> today, Launchpad, today! *grr* ;)
[11:03] <stub> kiko: Are there any particular cherry pickable patches available? I can't necessarily roll out head due to database schema changes.
[11:03] <kiko> yes.
[11:03] <SteveA> stub: mark said "I want to see people using the features of malone such as assignment / cc of teams and milestones and releases well, before we work on keywords" (paraphrased)
[11:03] <kiko> stub, r3050
[11:03] <SteveA> stub: so, this is an attempt to use the features of malone to classify bugs in this way.
[11:04] <kiko> stub, r3053 is just an additional test for that.
[11:04] <SteveA> stub: if people get more than one email for this, that strikes me as a bug in sending email.
[11:04] <stub> Well, we are now using them badly because we are getting side affects of our abuse of subscriptions to work around missing features
[11:04] <stub> SteveA: Malone has no idea that I am subscribed to launchpad-bugs@ mailing list. It is an external system.
[11:04] <SteveA> why are you subscribed to launchpad-bugs ?
[11:06] <SteveA> carlos: ping.  <voice style="mr humphries">"i'm free"</voice>
[11:06] <carlos> :-P
[11:06] <carlos> not really...
[11:06] <carlos> but it sounds funny... :-P
[11:07] <stub> SteveA: So I get bugmail that is sent to the launchpad team
[11:07] <SteveA> so, what's the zope3 question ?
[11:07] <Kinnison> SteveA: "I'm free!"
[11:08] <carlos> SteveA: from spiv's review to my POMsgsetPage, he suggested to look into any way to get records from forms
[11:08] <Kinnison> SteveA: and I'm under 30
[11:08] <carlos> SteveA: because the translation form has a set of entries that are a kind of records (msgid, translations and fuzzy state)
[11:09] <carlos> SteveA: he said that zope3 has support to do that but he was not sure we had it activated on launchpad
[11:09] <jamesh> SteveA: Malone has no way of tracking the subscription list for a mailman list.  So if a bug has<EMAIL_ADDRESS>and<EMAIL_ADDRESS>as subscribers, it has no way to tell that stub will get two emails
[11:09] <carlos> or if that would be interesting vs. the currect solution that iterates over the submitted entries and doesn't care about the order
[11:10] <SteveA> jamesh: so, obviously, we must integrate mailman into malone, rather than use keywords ;-p
[11:10] <jamesh> the problem doesn't occur for teams without a team contact email
[11:10] <carlos> SteveA: and he suggested to talk with you about it
[11:10] <jamesh> SteveA: okay.  What do we do about mail aliases on systems we don't control? :)
[11:10] <SteveA> jamesh: <evil>they should all use launchpad</evil>
[11:11] <SteveA> carlos: are you talking about processing data from a form in a better way?
[11:11] <stub> Don't click on the email address validation email that just got sent - it will just cause more trouble
[11:11] <carlos> yes
[11:11] <carlos> SteveA: following an structure
[11:12] <SteveA> stub: any cron jobs running?
[11:12] <dilys> Merge to devel/launchpad/: [trivial]  some minor updates to the log analysis script (r3064: James Henstridge)
[11:12] <jamesh> actually, provided we use the same message ID on all the mail sent out, people should be able to filter duplicate bug mail at destination
[11:12] <SteveA> does mailman preserve message id?
[11:13] <jamesh> yes
[11:13] <SteveA> carlos: there is a system to do this.  i think it would cause more problems than it solves, though.  can i take a look at the code that could benefit from this?
[11:14] <SteveA> Kinnison: you have been watching...
[11:14] <carlos> SteveA: sure, let me copy&paste it...
[11:14] <stub> SteveA: Not that I can see, but we might have had dead app servers on gangotri
[11:14] <Kinnison> SteveA: :-)
[11:16] <stub> Nah... they were fine.
[11:16] <carlos> SteveA: https://chinstrap.ubuntu.com/~dsilvers/paste/filehzuZhN.html
[11:18] <SteveA> carlos: i think that code can be simplified a bit on its own.  let's go to #c-m
[11:19] <carlos> SteveA: ok
[11:20] <mpt> SteveA, implementing {SoftwarePillarOfLaunchpad}Subscriptions should remove the need for external mailing lists to be subscribed to anything
[11:20] <mpt> but {SoftwarePillarOfLaunchpad}Subscriptions needs to be specced properly first
[11:26] <stub> jamesh: assuming you have that level of access to your mail server. Not everyone can be arsed running their own.
[11:27] <spiv> stub: procmail can do it too, but yeah.
[11:27] <stub> I'm sure google will be happy me installing procmail on the gmail servers :)
[11:28] <spiv> :)
[11:28] <spiv> It can be called gooprocmail, and be the next big story on slashdot! ;)
[11:40] <stub> spiv: Did you push your librarian branch?
[11:40] <spiv> stub: Yep
[11:40] <stub> $ bzr merge chinstrap:/home/warthogs/archives/spiv/launchpad/librarian-database-agreement
[11:40] <stub> Nothing to do.
[11:40] <stub> Hmm...
[11:40] <spiv> stub: Hmm.
[11:40] <lifeless> merge does not understand rsync paths
[11:41] <stub> Ahhh... but it is too embaressed to say anything.
[11:45] <SteveA> i prefer software to say "i don't understand" rather than to say "nothing to do"
[11:49] <lifeless> yes
[11:49] <lifeless> I'll bet there is a bug there
[11:58] <Kinnison> stub: can you can I please go through the soyuz db stuff on emperor?
[11:58] <Kinnison> stub: turn up on ##soyuz1.0 and we'll go through it
[12:03] <mpt> It must be late, I can't spell
[12:06] <Kinnison> aww
[12:06] <Kinnison> I can't spell anyway
[12:06] <Kinnison> maybe I'm always late
[12:07] <daf> maybe you're pregnant
[12:07] <kiko> there is visual confirmation on that daf
[12:07] <SteveA> daf: when matsubara arrives, please talk with him about your scrape.py script
[12:07] <kiko> Kinnison is having a baby
[12:08] <Kinnison> I am?
[12:08] <Kinnison> eww
[12:08] <kiko> yes
[12:08] <matsubara> SteveA: i'm already here.
[12:08] <daf> SteveA: matsubara has already arrived
[12:08] <SteveA> hi matsubara !
[12:08] <matsubara> hi SteveA
[12:08] <kiko> matsubara is always here
[12:08] <matsubara> hi dag
[12:08] <matsubara> ops hi daf
[12:08] <kiko> do you like dags?
[12:08] <daf> matsubara's name turned up in a dream I had last night
[12:08] <Kinnison> they make me wet
[12:09] <kiko> what the hell is happening in this channel?
[12:09] <kiko> this conversation was just surreal
[12:09] <daf> Kinnison: was a DAG the father?
[12:09] <Kinnison> daf: clearly
[12:10] <mpt> I'm sorry
[12:11] <daf> SteveA: are you thinking that this is a tool that matsubara will find helpful?
[12:11] <daf> if so, what's the use case?
[12:11] <daf> matsubara: do you have access to chinstrap HTTP yet?
[12:12] <matsubara> daf: not yet. I sent the email requesting access yesterday. I'm waiting for a reply...
[12:12] <daf> ok
[12:12] <SteveA> daf: i think you and matsubara are doing similar things
[12:13] <SteveA> matsubara: you have the password.  i gave it to you on irc
[12:13] <SteveA> daf: so, i think you can try co-ordinating around the output of that script
[12:13] <kiko> matsubara, he means http, not ssh/shell
[12:13] <SteveA> daf: matsubara doesn't have ssh access yet, but should have web access
[12:14] <matsubara> SteveA: I thought that one was just for the wiki. accessing the page. :)
[12:15] <daf> matsubara: basically, I created this page to support work that Steve and I were doing on managing Launchpad bugs
[12:15] <daf> matsubara: I wanted to filter and sort bugs in a way that Malone doesn't yet support
[12:16] <daf> so I wrote a script to screen-scrape Malone and list the bugs in the way that I wanted
[12:17] <daf> yesterday I added a couple of pages to Malone that will make this information much easier to scrape
[12:17] <daf> once that goes live, we'll be able to filter and sort bugs in many more ways
[12:18] <Keybuk> Kinnison: interesting ... launchpad still has a "hotplug" source package in ubuntu page
[12:18] <Keybuk> shouldn't that be removed along with the package?
[12:18] <Keybuk> or at least have a clear THIS DOES NOT EXIST in it
[12:18] <Kinnison> Keybuk: It will be marked removed
[12:18] <Kinnison> Keybuk: We haven't had removals processed into launchpad yet
[12:19] <Kinnison> Keybuk: check it out on staging.ubuntu.com and tell me if it's still wrong there please?
[12:19] <Keybuk> right
[12:19] <Keybuk> nothing obvious at https://staging.ubuntu.com/distros/ubuntu/+source/hotplug
[12:20] <matsubara> daf: what kind of changes?
[12:20] <Keybuk> certainly nothing in /+filebug either to say "YOU ARE FILING A BUG ON A REMOVED PACKAGE YOU FOOL"
[12:20] <daf> matsubara: well, for instance, Steve and I want to prioritise bugs that are user-visible
[12:21] <daf> matsubara: we can filter out non-user-visible bugs by checking whether the Launchpad Infrastructure team is subscribed to them
[12:21] <matsubara> daf: right
[12:22] <daf> our main task is to decide which bugs get fixed for 1.1, and which are going to have to wait
[12:22] <daf> hmm, there's a wiki page about this
[12:22] <matsubara> daf: based on what should we decide on that?
[12:23] <daf> https://wiki.launchpad.canonical.com/LaunchpadProjectMilestones
[12:23] <Kinnison> Keybuk: well, it's not in dapper, but that's about all I can suggest
[12:23] <Kinnison> Keybuk: certainly sounds like a malone UI refinement
[12:24] <daf> Kinnison: good delegation skills
[12:24] <Kinnison> daf: If I took on everything, I'd die
[12:24] <Kinnison> daf: I'm trying to offload stuff anyway 'cos I won't be working on launchpad for a month or two once soyuz is deployed
[12:25] <daf> just teasing -- I agree, it's a Malone bug and should be filed as such
[12:26] <daf> matsubara: Steve and I are keen to use milestones as the primary way of prioritising bugs
[12:26] <daf> Keybuk: are you going to file it?
[12:31] <matsubara> daf: and how do I know which bugs go to milestone 1.1 or 1.2 or future?
[12:31] <daf> good question
[12:31] <daf> so far, Steve has been making all those decisions
[12:33] <daf> SteveA: maybe we could develop a set of criteria for 1.1 bugs
[12:33] <SteveA> yes, that's a good idea
[12:33] <daf> I think it may come down to personal judgement in many cases, though
[12:33] <SteveA> i don't have any to offer right now.  maybe you and matsubara can discuss this
[12:33] <daf> sure
[12:34] <SteveA> also, we should make it so you and matsubara can talk using some voice software or other
[12:34] <SteveA> spiv: ping
[12:34] <spiv> SteveA: pong
[12:34] <SteveA> spiv: skype or phone call?
[12:35] <SteveA> hi david!
[12:35] <spiv> SteveA: I haven't installed skype on this laptop yet, so I guess phone call.
[12:35] <SteveA> okay
[12:36] <ddaa> hi SteveA, wassup?
[12:36] <SteveA> just saying "hi"
[12:37] <daf> matsubara: for voice calls, I can do Skype or SIP
[12:38] <matsubara> daf: I would have to setup things here. kiko do you have any idea?
[12:38] <daf> or, of course, the POTS
[12:38] <kiko> pots for now is easier
[12:39] <matsubara> daf, kiko ok.
[12:39] <daf> kiko: can you guys expense this stuff?
[12:39] <kiko> yes.
[12:40] <daf> cool -- my number is on the wiki
[12:40] <matsubara> ok
[12:40] <stub> spiv: Why don't we want remoteAddFile to send the database name?
[12:49] <daf> MEETING IN 10 MINUTES
[12:49] <Kinnison> urgh
[12:49] <Kinnison> hippies
[12:49] <sivang> (mint herbs one)
[12:50] <daf> like peppermint tea?
[12:52] <Kinnison> hurrah, I just got a timeout
[12:52] <sivang> daf: yep :) my favorite
[12:52] <daf> lucky you
[12:52] <daf> mm
[12:53] <Kinnison> guys, OOPS-33B332 just hit me (reassigning ownership of a team)
[12:53] <sivang> daf: I can bring you some next time we meet, although I'm sure UK's brands are bit more quality then .il ones :)
[12:53] <daf> can you get Rooibos in .il?
[12:56] <sivang> daf: that the special herb plan you once sent me a wikipedia link to?
[12:56] <cprov> daf: how is the current status of your soyuz-ui branch ? how far is it from merge in RF ?
[12:57] <daf> cprov: er, good question
[12:57] <daf> sivang: maybe, I can't remember
[12:57] <cprov> daf: I'm about to merge mine
[12:58] <ddaa> spiv: I got a new test suite failure when trying to merge buildbot-lobotomy
[12:58] <daf> cprov: I haven't looked at it for a while -- it still needs review
[12:58] <ddaa> I'd really like if you could have a loot at fixing buildbot, what do you need from me?
[12:58] <cprov> daf: if you want I can merge yours after and adopt it ;)
[12:59] <daf> cprov: sure :)
[12:59] <daf> cprov: they're pretty simple changes
[12:59] <Kinnison> MEETING TIME
[12:59] <kiko> yo
[12:59] <daf> Kinnison: you're premature
[12:59] <Kinnison> 12:01 < daf> Kinnison: you're premature
[01:00] <Kinnison>    ^^
[01:00] <daf> 11:59:45 <Kinnison> MEETING TIME
[01:00] <Kinnison> sux
[01:00] <stub> Yo
[01:00] <mpt> yo
[01:00] <stub> MEETING TIME
[01:00] <daf> echo!
[01:01] <ddaa> echo!
[01:01] <SteveA> MEETING TIME!!!!!
[01:01] <SteveA> i'm late
[01:01] <SteveA> sorry, got involved in a work phone call
[01:01] <Kinnison> I am here
[01:01] <SteveA> !!!!!!!
[01:01] <gneuman> here
[01:01] <SteveA> mpt: !!!!!!!
[01:01] <SteveA> who's here?
[01:01] <salgado> here
[01:01] <daf> me
[01:02] <stub> here
[01:02] <ddaa> Kinnison: you're premature, roll call had not started
[01:02] <matsubara> here
[01:02] <mpt> here!!!!!!!
[01:02] <niemeyer> I'm here
[01:02] <ddaa> here
[01:02] <jblack> .-=HERE=-. !!!!!!!
[01:02] <Kinnison> I am here
[01:02] <bradb> here
[01:02] <spiv> I'm here.
[01:02] <Kinnison> goddamnit
[01:02] <BjornT> i'm here
[01:02] <jamesh> here
[01:02] <cprov> here
[01:02] <kiko> HERE
[01:03] <SteveA> hurrah
[01:03] <SteveA> anyone else?
[01:03] <daf> carlos, lifeless, mpool not here
[01:03] <carlos> I'm her
[01:03] <sivang> jblack: 80's ascii art style? :)
[01:03] <carlos> ....
[01:03] <carlos> I'm here
[01:03] <carlos> ;-)
[01:03] <carlos> here
[01:03] <SteveA> lifeless: hello
[01:03] <carlos> daf: ?
[01:03] <carlos> daf: I say that I'm here twice...
[01:03] <carlos> :-)
[01:04] <jblack> If we're here twice this week, do we get to skip next week?
[01:04] <mpt> carlos, they cancelled each other out
[01:04] <SteveA> lifeless: i see you proposed items for the agenda.  are they things for discussion with the whole team, or are these things we should discuss in a smaller group?
[01:04] <carlos> mpt: :-D
[01:04] <kiko> 5 4 3 2 1 timeless time out.
[01:05] <SteveA>  * Roll call
[01:05] <SteveA>  * Agenda
[01:05] <SteveA>  * Next meeting
[01:05] <SteveA>  * Activity reports
[01:05] <SteveA>  * Items from last meeting
[01:05] <SteveA>  * Production / staging (stub)
[01:05] <SteveA>  * Keep, Bag, Change
[01:05] <SteveA>  * Three sentences
[01:05] <SteveA>
[01:05] <SteveA> next meeting -- same time, same channel, next week?
[01:05] <SteveA> it is done
[01:05] <SteveA> activity reports.  for the month of February, I'm up to date!
[01:05] <SteveA> oh, it's just the 2nd...
[01:05] <kiko> I am on a sprint
[01:05] <Kinnison> I am sprinting
[01:05] <mpt> up to date
[01:05] <spiv> I'm up to date.
[01:05] <daf> up to date
[01:05] <SteveA> who else can claim uptodateness (and not sprinting)
[01:05] <Kinnison> always lunning lunning lunning
[01:05] <jblack> Up to date.
[01:06] <carlos> I'm up to date
[01:06] <bradb> up to date
[01:06] <salgado> I'm up to date
[01:06] <matsubara> up to date
[01:06] <BjornT> i'm up to date
[01:06] <stub> up to date
[01:06] <ddaa> up to date
[01:06] <niemeyer> I'm mostly up
[01:06] <jamesh> I sent one for today.  I'll send some for the beginning of the week
[01:06] <cprov> I'm on sprint, what a good excuse ...
[01:06] <niemeyer> cprov: GOod one indeed :)
[01:06] <gneuman> up to date
[01:06] <lifeless> SteveA: I didn't propose anything
[01:06] <SteveA> lifeless: okay
[01:06] <lifeless> here, and up to date
[01:06] <SteveA> i guess the MeetingAgenda page is out of date.
[01:07] <SteveA>  * Items from last meeting
[01:07] <SteveA> * MeetingAction: Andrew and James to try Kiko's suggested time logging workflow.
[01:07] <SteveA> spiv, jamesh: did you try?
[01:07] <jblack> Not this james
[01:07] <SteveA> oh
[01:07] <SteveA> and
[01:07] <SteveA> that was from the last last meeting
[01:08] <SteveA> daf: i'm getting confused by the quoting in the meeting summary :-/  ideas on how to improve me, or the summary, welcome
[01:08] <daf> hmm
[01:08] <SteveA> MeetingAction: Steve and Carlos to meet and discuss adding an UnexpectedFormData exception.
[01:08] <SteveA> did we do that?
[01:08] <SteveA> daf: issue is, when i search for MeetingAction, i get quoted text
[01:08] <spiv> SteveA: I did.  I haven't managed to do the regular time, but I have managed to use gtimelog again -- and that's been enough to keep me up to date.
[01:08] <carlos> SteveA: yes and I have that implemented waiting for our talk today to get it merged into rocketfuel
[01:09] <SteveA> MeetingAction: James B to organise a meeting between him, Steve, David and Robert.
[01:09] <SteveA> MeetingAction: Stuart to check that launchpad-dependancies is being use on all production boxes.
[01:09] <jamesh> SteveA: I've been keeping an editor window open to note what I'm doing.  Need to get better about sending them in
[01:09] <carlos> SteveA: it's part of the same branch
[01:09] <daf> SteveA: and that's a problem?
[01:09] <SteveA>     *
[01:09] <SteveA> MeetingAction: Steve and David to discuss things David is blocked on.
[01:09] <jblack> James B: He tried, oh how he tried.
[01:09] <SteveA> jamesh: i was thinking, gtimelog would be really good if i could have a text area visible in my gnome panel
[01:10] <ddaa> Gotta admit that I have been writing plenty good doc but I'm not sure anymore what's the problem.
[01:10] <daf> SteveA: I suppose I could strip them out
[01:10] <SteveA> jblack: thanks for trying.  i think we sorted this out by other means
[01:10] <ddaa> except that this whole import stuff just makes me want to dig my head in the sand
[01:10] <daf> SteveA: or replace them with OldMeetingAction
[01:10] <mpt> that wouldn't fix the finding problem
[01:10] <mpt> MeetingOldAction would, though
[01:10] <SteveA> daf: i think directly quoting text is a bit of an issue.  of course, it is also very convenient!
[01:11] <SteveA> OldMeetingAction is fine
[01:11] <SteveA> i'd see it right away
[01:11] <SteveA> no confusion
[01:11] <SteveA> stub: ?
[01:11] <daf> I'll give it a go
[01:12] <SteveA> stub: ?
[01:12] <stub> I didn't chase up launchpad dependancies with the admins. If we want this on production, we will need a launchpad-server-depenancies or something, as recent failures have been needing an identd server and mail transport on all boxes.
[01:12] <stub> I canna type any faster!
[01:12] <SteveA> jabber is nice for that...
[01:13] <SteveA> shame irc is in the DARK AGES
[01:13] <SteveA> stub: it doesn't need to cover all eventualities
[01:13] <SteveA> i think having launchpad-dependencies on production boxes makes for a good start
[01:13] <SteveA> there are already two packages
[01:13] <kiko> SteveA, I can talk to james about this today.
[01:13] <SteveA> a server one may be a good idea too, i'm not sure though
[01:13] <SteveA> thanks kiko
[01:14] <kiko> action item for me
[01:14] <SteveA> we've had cases in the past where new dependencies from developers were missed from production on one or more machines
[01:14] <SteveA> and this caused problems
[01:14] <SteveA> i see using a package as a way to avoid such problems, and make them easily fixable
[01:14] <SteveA>   * Production / staging (stub)
[01:15] <stub> I don't know enough about how elmo or Znarl do updates to know if it will help. I mainly see it as being useful for setting up new servers.
[01:15] <stub> production update will occur as normal next Tuesday from HEAD as of andrew landing his librarian patch unless I hear about other patches that need to go out.
[01:15] <stub> Production Gina, currently running on prat, will shortly be updated with a fix.
[01:15] <stub> staging is still being used for soyuz testing. Staging database syncs are back down two 3 hours, so we can revert to daily database syncs again once soyuz testing is finished.
[01:15] <kiko> SteveA, it only is if people remember to tell devels to update the package.
[01:15] <kiko> stub, we will give you staging back from saturday on.
[01:16] <SteveA> kiko: if the devels don't update the package, then pqm shouldn't be able to merge the code
[01:16] <SteveA> stub: what's the current hard timeout?
[01:16] <carlos> stub: if staging is back to the mirror process I will not need launchpad_carlos anymore
[01:17] <kiko> on saturday, carlos
[01:17] <carlos> kiko: I don't need it until sunday
[01:17] <kiko> okay.
[01:17] <stub> Hard timeout is currently 15 seconds. I will update that to 25 seconds after the meeting and gina update.
[01:17] <kiko> stub, there will be a new production system on friday evening
[01:18] <kiko> stub, we need to sort out a process for updating it, which will require some thinking and agreeing
[01:18] <SteveA> jamesh: can you say a little about oops reports, and regular oops reports to the mailing list?
[01:18] <jamesh> okay
[01:18] <stub> kiko: Care to give any details, or is it a surprise?
[01:18] <jamesh> we'll now be getting daily reports sent to<EMAIL_ADDRESS>[01:18] <kiko> stub, it's drescher, and you already knew that.
[01:19] <kiko> so it's technically not a surprise
[01:19] <kiko> jamesh, that is a BIG report
[01:19] <stub> ok. Last I heard was Daniel would nurse it until he was happy and then whatever
[01:19] <jamesh> this is similar to the information in kiko's earlier reports, but also includes references to OOPS reports, so you can look up full information
[01:19] <kiko> jamesh, would it make sense to trim 404s or so on
[01:19] <SteveA> or maybe, put the full report on a web page
[01:19] <SteveA> and link to it from the email
[01:19] <kiko> stub, well, we still need to do rollouts together if there are changes..
[01:19] <SteveA> so we can have clickable oops links too
[01:19] <jamesh> I've got it displaying all not found errors and other errors
[01:19] <daf> the report seems to split by page, not by query
[01:20] <spiv> Clickable OOPSes would be nice for lazy information junkies like me :)
[01:20] <stub> kiko: yup. Already discussed this in principal IIRC
[01:20] <daf> is it difficult to collate timeouts of the same query?
[01:20] <mpt> If it's daily, it need only include the most common three or four
[01:20] <daf> spiv: oo
[01:20] <jamesh> it would be good to get all non-404, non-timeout errors fixed, since they indicate real bugs in our code
[01:20] <mpt> assuming people won't fix bugs faster than that :-)
[01:20] <SteveA> jamesh: +1
[01:20] <daf> yes
[01:20] <daf> though in the longer term, timeouts are bugs too
[01:20] <jamesh> some 404 errors also indicate bugs in our software, when we are the one sending them to the URL
[01:21] <jamesh> for each of the errors there is a breakdown of how many requests have local referers (currently defined as launchpad.net or *.ubuntu.com domains), which we can fix
[01:21] <SteveA> daf: i'm going to be working out a doc to say how we go about taking the OOPS reports and acting on the contents.
[01:21] <kiko> stub, yes, we did -- I just want to move this to a more practical discussion.
[01:21] <SteveA> daf: i think this will feed into the bugs kinda stuff you're doing
[01:21] <kiko> daf, SteveA: so get matsubara to be part of this work.
[01:21] <daf> SteveA: ok, let me know
[01:22] <SteveA> kiko, matsubara: +1
[01:22] <daf> matsubara and I have planned to have a phone call after this meeting
[01:22] <SteveA> lifeless: how is the asterisk stuff going?
[01:22] <SteveA> i'd like to be able to have calls with daf and matsubara
[01:23] <daf> that would be great
[01:23] <jamesh> I'll look at getting the script to generate an online and a mail version of the report
[01:23] <SteveA> thanks james
[01:23] <daf> kiko: will SIP work at your end?
[01:23] <kiko> daf, not today, but eventually.
[01:23] <matsubara> kiko: is it possible to have that here?
[01:23] <kiko> yes
[01:23] <SteveA> the production / oops related topics are drawing to a close
[01:24] <SteveA> any further comments or co-ordinations ?
[01:24] <SteveA> ok
[01:25] <SteveA> i want to ask for a quick poll: is everyone getting on okay with bzr?  please answer "yes", "no", "sometimes".  no other comments just now.
[01:25] <stub> yes
[01:25] <SteveA> (and i mean, bzr for developing launchpad, pqm, RF etc)
[01:25] <mpt> yes
[01:25] <daf> yes
[01:25] <matsubara> yes
[01:25] <spiv> "yes"
[01:25] <sivang> yes
[01:25] <jamesh> yes
[01:25] <ddaa> bzr could use upgrade on chinstrap
[01:25] <gneuman> yes
[01:25] <kiko> matsubara, but not today.
[01:25] <Kinnison> mostly
[01:25] <salgado> yes
[01:25] <ddaa> otherwise yes
[01:25] <kiko> SteveA, yes
[01:25] <kiko> for bzr
[01:26] <ddaa> pqm: no
[01:26] <kiko> I am not okay with PQM
[01:26] <sivang> is pqm here? :)
[01:26] <BjornT> yes
[01:26] <SteveA> any other polls?
[01:26] <bradb> pqm has been good lately
[01:26] <cprov> yes
[01:26] <SteveA> i mean, inputs into this poll
[01:26] <jamesh> sivang: dilys speaks for pqm
[01:26] <SteveA> not entirely different polls
[01:26] <sivang> jamesh: ah, right
[01:26] <lifeless> www.amipqmornot.com
[01:26] <SteveA> kiko, ddaa: what is the pqm issue?
[01:27] <SteveA> just buildbot test failure issues?
[01:27] <ddaa> that, and it was only the first blocker on getting cscvs merged...
[01:27] <kiko> SteveA, let me see
[01:27] <SteveA> Kinnison: your "mostly"... any particular issues?
[01:28] <Kinnison> SteveA: sometimes when I commit, it sits for *ages* spinning CPU and disk before it commits
[01:28] <Kinnison> SteveA: I think it's repeatedly rewriting its hashcache
[01:28] <jblack> define ages?
[01:28] <Kinnison> jblack: five CPU minutes
[01:28] <SteveA> jblack: can you help Kinnison diagnose this at some point?  (not right now please)
[01:28] <jblack> Yeah.
[01:28] <Kinnison> Other than that, bzr is the bomb
[01:29] <daf> diff -r ancestor: ++
[01:29] <SteveA> kiko: any other points?
[01:30] <kiko> a) it is "externally flaky" and hangs running our code b) it doesn't give us live feedback of what it's doing, so when it hangs we have no clue c) the "pqm API" is kinda unknown so for instance, I don't know if it can merge a specific bzr revision
[01:30] <daf> "how do I hate thee? let me count the ways"
[01:30] <ddaa> kiko++
[01:30] <jamesh> the external flaky bits are us :)
[01:30] <jamesh> unfortunately
[01:30] <jblack> I have some documents I wrote squirred away somewhere
[01:30] <kiko> agreed, but PQM doesn't help
[01:30] <SteveA> kiko: okay, noted.  i'll ask lifeless to consider these issues and report back later.
[01:30] <SteveA> okay lifeless ?
[01:30] <carlos> ok, I'm back
[01:31] <lifeless> sure, thought c) is a bit vague except for the specific revision thing which is a known defect
[01:31] <kiko> lifeless, I don't know what commands or syntax PQM accepts
[01:31] <lifeless> a) is already speced on the wiki PQMRobustness
[01:31] <kiko> that's what I was talking about
[01:31] <SteveA> a request for documentation
[01:31] <lifeless> and b) has been discussed before.
[01:31] <jblack> kiko: I have a wiki page here. I'll put that up.
[01:31] <carlos> kiko: it was a matter of restarting the vpn
[01:31] <SteveA> okay
[01:32] <SteveA> moving along...
[01:32] <lifeless> SteveA: the PQM README and documentation is quite comprehensive
[01:32] <SteveA> no idea where that is
[01:32] <lifeless> SteveA: if specific things are missing I'll be happy to add them
[01:32] <kiko> maybe but it isn't linked from pqm.ubuntu.com
[01:32] <kiko> so I have no idea what you are talking about
[01:32] <kiko> let's move on then
[01:33] <lifeless> kiko: http://bazaar.canonical.com/PatchQueueManager may help.
[01:33] <SteveA>  * Keep, Bag, Change
[01:33] <jblack> https://wiki.launchpad.canonical.com/PQMInstructions
[01:33] <lifeless> kiko: I'll add an advertising link to its status page
[01:33] <SteveA>  * Keep, Bag, Change
[01:33] <SteveA> any takers?
[01:33] <SteveA> Keep: bzr
[01:33] <lifeless> Change: Pyme
[01:33] <carlos> SteveA: about the poll, my answer is 'yes'
[01:34] <mpt> CHANGE: owner of <https://launchpad.net/people/debiandevelopers>
[01:34] <jblack> Change: (add?) A weekly poll on a preplanned random bzr question
[01:34] <ddaa> CHANGE: I'm writing an extensive answer to that in the bzr-launchpad doc...
[01:34] <SteveA> mpt: erk
[01:34] <daf> mpt: haha
[01:34] <SteveA> mpt: change to what though?
[01:35] <mpt> I don't know, does Branden have a Launchpad account?
[01:35] <lifeless> mpt: god no.
[01:35] <lifeless> mpt: probably should be elmo ;-)
[01:35] <kiko> I'll change it to elmo
[01:35] <daf> I'm not sure that all Debian developers would consent to being owned by Branden
[01:35] <mpt> so maybe that team should be removed/hidden
[01:35] <lifeless> daf: I'm should they would not consent in fact
[01:35] <daf> what's it used for?
[01:35] <SteveA> why do we even have that team in launchpad?
[01:35] <mpt> if it's not doing anything useful
[01:36] <lifeless> daf: mainly for security and spamming
[01:36] <daf> how so, if Mark is the only member?
[01:36] <ddaa> let's make it owned by ubuntu, for extra controverse
[01:36] <kiko> I have changed it to elmo
[01:36] <kiko> and deactivated mark's membership
[01:36] <kiko> let's move on
[01:36] <mpt> Branden does have a Launchpad account
[01:36] <kiko> if people blame elmo he will do something about it
[01:36] <SteveA> thanks kiko
[01:37] <carlos> mpt: automatically created?
[01:37] <SteveA> any more Keep Bag Change?
[01:37] <SteveA> 5
[01:37] <SteveA> 4
[01:37] <mpt> I don't know, I just want it gone
[01:37] <SteveA> 3
[01:37] <jblack> Change: (add?) A weekly poll on a preplanned random bzr question
[01:37] <SteveA> say that
[01:37] <SteveA> i saw that, i mean
[01:37] <SteveA> 2
[01:37] <SteveA> 1
[01:37] <SteveA> okay, done
[01:37] <SteveA>  * Three sentences
[01:37] <SteveA> go ahead... make my day
[01:37] <Kinnison> DONE: soyuz deployment sprint
[01:37] <Kinnison> TODO: soyuz deployment sprint
[01:37] <matsubara> DONE: read NewStaffTask and did the procedures there, fixing validators on request fix page.
[01:37] <matsubara> TODO: fix the Needs Info bugs not appearing on reports and sort out why it breaks the reports, bug triage, define a set of criteria on bug assignment to milestones.
[01:37] <matsubara> BLOCKED: Nope
[01:37] <Kinnison> BLOCKED: no
[01:37] <lifeless> DONE: Storage branch landed, branch-formats phase 1 landed
[01:37] <lifeless> TODO: PQM updates for gantry, production cherrypicking, remainder of branch formats.
[01:37] <lifeless> BLOCKED: zope3 updated landing
[01:37] <ddaa> DONE: buildd-ng partial design specs, bzr-launchpad doc, tentative buildbot fix
[01:37] <ddaa> TODO: rcs-importer doc, update bzrsyncd, feed spiv new buildbot testsuite failure
[01:37] <ddaa> BLOCKED: rcs imports make me sick
[01:37] <spiv> DONE: Reviews, SFTP -- all tests passing, all code in the one tree, Librarian database paranoia
[01:37] <mpt> DONE: LCA; FixingProjects, SimplifyingMalone, MaloneSearch, build pages
[01:37] <mpt> TODO: get those specs approved!, MaloneFrontPages, DuplicateBugHandling
[01:37] <mpt> BLOCKED: number of hours in the day
[01:38] <gneuman> DONE: fixed small bugs
[01:38] <daf> DONE: bug text pages, bug triage
[01:38] <daf> TODO: land optional-branch-title, malone upstream filtering, bug management discussion with Diogo/Steve
[01:38] <jblack> DONE: further wiki rewrites. bzr support, some other issue
[01:38] <spiv> TODO: merge SFTP into rocketfuel
[01:38] <daf> BLOCKED: no
[01:38] <spiv> BLOCKED: no
[01:38] <sivang> DONE: Successfully (minus trubecht) set up rocketfuel, noted about some more small additions and "bugs" in the RFS document, already seen by jblack. Reported some more bugs that daf triaged , some assigned and already fixed by mpt and matsubara.
[01:38] <jordi> hello; my bad, I had a real life meeting
[01:38] <jblack> BLOCKED: no
[01:38] <BjornT> DONE: fixed bugs. speced out bug watches improvements. started making checkwatches.py update more than one bug watch at a time, adding lots of tests. reviews.
[01:38] <sivang> TODO: Fix bugs, track down the GPG issue I have with signing the PQM key together with jblack, learn how to merge fixes.
[01:38] <kiko> DONE: soyuz deployment, reports, calls, management, etc
[01:38] <gneuman> BLOCKED: no
[01:38] <gneuman> TODO: finish test issues to merge those fixes
[01:38] <BjornT> TODO: finish checkwatches.py changes. start to implement BugWatches. write implementation part of BugHistory.
[01:38] <bradb> DONE: More Malone email doc updates. Bug contact reports.
[01:38] <bradb> TODO: Put the bug contact reports in code review this morning. Revisit MaloneRunsUbuntuTaskList.
[01:38] <BjornT> BLOCKED: no
[01:38] <kiko> TODO: soyuz deployment, fly home, catch up
[01:38] <bradb> BLOCKED: No.
[01:38] <jordi> My three sientences:
[01:38] <sivang> BLOCKED : ENOTIME, but am getting better at pushing the BLOCK away :).
[01:38] <kiko> BLOCKED: no
[01:38] <jblack> TODO: deb for rocketfuel docs, vacation
[01:38] <jordi> DONE: queue processing, email
[01:38] <salgado> DONE: Lots of bug fixes (including the long-awayted vocabulary one) and code review
[01:38] <jordi> TODO: more queue processing
[01:38] <salgado> TODO: More bug fixes, MirrorManagement, code review
[01:38] <salgado> BLOCKED: No
[01:39] <jordi> BLOCKED: bad import requests removals, Carlos knows the problem
[01:39] <SteveA> DONE: sent an activity report, management, code reviews, got stu's zope3 tree for final hacks
[01:39] <SteveA> TODO: hack zope3 for launchpad, management, code reviews
[01:39] <SteveA> BLOCKED: no
[01:39] <jamesh> DONE: LCA, oops summary stuff, pygpgme stuff, bring SQLObject __len__() up to date
[01:39] <jamesh> TODO: get all __len__() stuff merged, supermirror stuff with ddaa
[01:39] <jamesh> BLOCKED: no
[01:39] <carlos> DONE: Language packs, user support, POMsgSetPAge tests, AJAX testing to fix suggestions, fixed permissions for product owners
[01:39] <dilys> Merge to devel/launchpad/: [r=stub]  Fix bug 30221: Librarian should confirm it is being used from the correct database. (r3065: Andrew Bennetts)
[01:39] <jordi> SteveA: for your record, I started to catch up on activity reports, but need to check my records for what happened the first two weeks ok Jan
[01:39] <spiv> ddaa: If you could send me the buildbot test failures, I can quickly get some idea of how nasty they are.
[01:40] <carlos> TODO: Finish POMsgSetPage comments with Steve and final merge this initial branch, more language packs, finish AJAX implementation for suggestions try to fix a couple of bugs
[01:40] <ddaa> spiv: ack
[01:40] <stub> DONE: Rollout issues, performance features
[01:40] <stub> TODO: Zope3.2
[01:40] <stub> BLOCKED: Steve looking at design fault picked up from Zope3.2 migration
[01:40] <SteveA> jordi: did i ever get your spreadsheet?
[01:40] <kiko> thanks stub
[01:40] <SteveA> stub: okay, so you'll take zope3.2 back from me when i've fixed the fault?
[01:41] <kiko> thanks spiv
[01:41] <stub> SteveA: Sure. Or just an opinion on how to approach it.
[01:41] <jordi> SteveA: uh, I guess you didn't. I totally forgot
[01:41] <cprov> DONE: soyuz rollout
[01:41] <cprov> TODO: soyuz rollout + soyuz UI bugs
[01:41] <SteveA> stub: okay.  i'll look at it RSN
[01:41] <cprov> BLOCKED: None
[01:42] <jordi> SteveA: expect it during the evening
[01:42] <SteveA> ok
[01:42] <SteveA> ta
[01:42] <SteveA> any blocked issues that aren't being dealt with?
[01:42] <SteveA> 5
[01:42] <SteveA> 4
[01:42] <SteveA> 3
[01:43] <SteveA> 2
[01:43] <carlos> BLOCKED: No
[01:43] <SteveA> 1
[01:43] <SteveA> ...
[01:43] <SteveA> okay
[01:43] <SteveA> that's it
[01:43] <kiko> meeting ends thanks etc etc
[01:43] <daf> MEETING ENDS
[01:43] <daf> we finished early today
[01:43] <SteveA> daf: you'll summarize it?
[01:43] <daf> SteveA: yes
[01:43] <SteveA> thanks daf
[01:43] <jblack> Kinnison: Lets talk
[01:44] <daf> niemeyer: my script says there were no sentences from you
[01:44] <ddaa> lifeless: is the server running pqm ATM a 64bit system?
[01:44] <niemeyer> daf: Yeah.. I'm working on the G project.. :)
[01:44] <daf> niemeyer: ok :)
[01:44] <sivang> niemeyer: hehe
[01:44] <lifeless> ddaa: ues
[01:45] <lifeless> niemeyer: 'Done: something; TODO: other things; Blocked: Maybe'
[01:45] <ddaa> okay, that explains the interesting new failure... fcntl.fcntl failing with OverflowError...
[01:46] <niemeyer> lifeless: It was closed to that in the last meeting :)
[01:46] <niemeyer> s/closed/close/
[01:49] <carlos> SteveA: could we continue the review after lunch?
[01:53] <SteveA> carlos: sure.  i need to get lunch too, now
[01:53] <carlos> ok
[01:53] <carlos> see you later
[01:54] <salgado> BjornT, around?
[01:54] <BjornT> salgado: yeah
[01:55] <salgado> BjornT, do you have a few minutes? (that patch you reviewed yesterday has shown that the switch-to-advanced-search is not tested properly, and I don't know how to test it properly)
[01:56] <SteveA> daf: would you update MeetingAgenda too please
[01:56] <SteveA> fix up dates, remove old agenda items etc.
[01:56] <daf> ok
[01:56] <SteveA> when you add the summary to it
[01:56] <SteveA> thanks
[01:56] <BjornT> salgado: sure. what exactly needs to be tested better?
[01:59] <daf> kiko, stub: when was staging last updated?
[01:59] <kiko> daf, the webapp code? no idea
[02:00] <daf> sux
[02:00] <kiko> daf, could you find a way to add a file to our webapp tree that tells us what .bzr revision we are rolled out to?
[02:00] <kiko> something like launchpad.net/.version
[02:00] <kiko> or something
[02:00] <stub> daf: couple of days ago
[02:01] <daf> stub: ta
[02:01] <kiko> is it easy to do something like that? I asked stub a while back..
[02:01] <daf> kiko: ah, so the rolled out tree is not a bzr checkout?
[02:01] <kiko> yeah, there's that
[02:01] <daf> bzr revno
[02:01] <kiko> maybe stub's rollout script could touch a file somewhere
[02:01] <kiko> and write out the version
[02:01] <kiko> or revision + cherry-picks
[02:01] <kiko> etc
[02:01] <stub> Rolled out tree is a bzr checkout, but bzr isn't installed on those boxes. So it would need to use the bzr in lib/bzr
[02:02] <kiko> stub, I can get bzr installed on the boxes. do you want them?
[02:02] <stub> kiko: You can't because it is a moving target
[02:02] <Kinnison> kiko: sourcecode/bzr/bzr is easy enough to use
[02:02] <kiko> really? breezy bzr is bad? but okay..
[02:02] <kiko> this is a rather nondestructive operation querying bzr
[02:02] <stub> kiko: So I'm told
[02:02] <daf> ./sourcecode/bzr/bzr revno works
[02:03] <kiko> I would like to have a file which we could check
[02:03] <daf> you might need to use PYTHONPATH=lib
[02:03] <kiko> daf, is revno alone useful?
[02:03] <lifeless> breezy has an old bzr that cant read current bzr
[02:03] <salgado> BjornT, I thought I knew what was the problem, but I was wrong. I'll need to investigate some more
[02:03] <lifeless> we're working rapidly to get the storage stuff all done so this wont be such an issue with dapper
[02:03] <kiko> I mean, it will tell us the revno of the branch staging/production is on..
[02:03] <daf> kiko: hmm, not sure what it will do when there's cherrypicks present
[02:03] <stub> Ooh.. soucecode/bzr/bzr works
[02:03] <kiko> does revno say "rocketfuel etc"?
[02:03] <lifeless> daf: bzr sets its own python path
[02:04] <kiko> or does it say production 132 :)
[02:04] <daf> lifeless: sneaky
[02:04] <stub> Staging is r3051
[02:04] <kiko> interesting. what does that mean?
[02:04] <salgado> BjornT, anyway, there's one thing that I don't think I can test in a doctest. I'd like to test RedirectToAdvancedBugTasksView().render(), but it doesn't seem to be possible because the TestRequest() we use doesn't have everything that's needed to render a page
[02:05] <Kinnison> how about launchpad.net/.log which needs you to be logged in, and a member of admins, and it presents bzr log -r -10..-1
[02:05] <lifeless> salgado: what does render do that you want to test ?
[02:05] <Kinnison> that'd show cherrypicks etc
[02:06] <salgado> lifeless, https://chinstrap.ubuntu.com/~dsilvers/paste/file8lnkU8.html
[02:07] <lifeless> salgado: so you are saying that request is deficient ?
[02:08] <lifeless> salgado: is it hard to add in as mocks or real facilities whats needed ?
[02:08] <salgado> lifeless, well, if you use zope.publisher.browser.TestRequest you can't render a page
[02:08] <lifeless> well
[02:09] <salgado> but I think that makes sense
[02:09] <lifeless> request in that method is used three timems
[02:09] <lifeless> getView
[02:09] <lifeless> request.form.get
[02:09] <lifeless> and self.request
[02:09] <lifeless> self.request is trivially settable
[02:09] <lifeless> I'm guessing getView wont use much and thus will be happy
[02:10] <lifeless> so the true block of the if can be tested
[02:10] <salgado> but LaunchpadView.render() will call self.template(), which in turns require breadcrumbs and some other stuff, AFAICT
[02:10] <lifeless> for the false block, it depends what BugTaskSearchListingView.render needs of self.request
[02:11] <salgado> yes, that's the real problem. both the if and else blocks will end up calling LaunchpadView.render()
[02:11] <lifeless> myview.template() = lambda x:return "literal"
[02:11] <lifeless> erm, myview.template = ...
[02:12] <salgado> yes, I guess that should work
[02:15] <lifeless> basically, either fixup the TestRequest or stub out the unrelated methods we dont need functional for this test
[02:15] <lifeless> what we want to test here is that the alternative code paths are taken
[02:16] <salgado> right. and that they actually do what they want them to
[02:17] <salgado> what we want them to
[02:35] <ddaa> jordi: did someone address your "junk product" mail?
[02:36] <jordi> https://launchpad.net/products/wordpress-2 is 404
[02:36] <jordi> https://launchpad.net/projects/wordpress references it
[02:36] <jordi> which is a nice bug
[02:36] <ddaa> mh... I guess it got "disabled"
[02:37] <ddaa> *sigh*
[02:37] <jordi> (we'll later go to the "this project should not even exist dpt.)
[02:37] <dilys> Merge to devel/launchpad/: [trivial]  Even more DB perms fix for soyuz rollout (r3066: Celso Providelo)
[02:37] <jordi> ddaa: aw
[02:38] <jordi> ddaa: no dude no
[02:38] <ddaa> this inactivation stuff is a hack, deletion is the thing to do
[02:38] <jordi> if you drop out, in 4 days, this will be a junksite :)
[02:38] <jordi> yeah
[02:38] <jordi> I thought someone would do it at db level
[02:38] <jordi> we need ui to do it
[02:38] <ddaa> but people won't have it because of petty "but we cannot delete it, it's linked from other useless objects!"
[02:39] <ddaa> stub: can you make jordi happy please?
[02:39] <ddaa> jordi: as a rule, you need to address stub directly for that kind of stuff
[02:40] <stub> Or better yet file a bug on why the projects page is referencing hidden products
[02:44] <jordi> stub: why is it that we hide, not delete?
[02:44] <jordi> wordpress-2 is clearly not useful
[02:45] <ddaa> jordi: see thread "Inactivation and deletion of Registry objects"
[02:45] <ddaa> in the launchpad mailing list
[02:45] <jordi> we might find ourselves with prdocut namespace pollution in the future due to an amount of deactivated stuff
[02:45] <jordi> ddaa: date?
[02:45] <ddaa> starting dec. 9
[02:46] <jordi> here
[02:47] <ddaa> jordi: right, deactivation is a "hide under the carpet" strategy
[02:47] <jordi> the carpet will be bumpy in the longterm
[02:48] <ddaa> deactivation is only meaningful if we think we might want to reactivate the object later
[02:48] <ddaa> which means the object should still be somehow accessible in the UI
[02:52] <jordi> not wordpress-2's case
[02:54] <daf> spiv, salgado: https://launchpad.net/products/launchpad/+bug/102
[02:55] <daf> also: https://launchpad.net/products/launchpad/+bug/121
[02:55] <daf> what's happening on these bugs?
[02:55] <daf> can they be confirmed?
[02:56] <daf> ddaa: bug #378 -- is this up-to-date?
[02:56] <ddaa> Ubugtu: bug 378
[02:57] <ddaa> half outdated
[02:57] <daf> can you update it?
[02:58] <ddaa> I wrote the doc about importstatus yesterday, and half of the justification for this workflow was Arch namespace
[02:58] <daf> or close it and file a new bug
[02:58] <daf> if that's easier
[02:58] <ddaa> cannot, yet, maybe assign it to me so I'll update it
[02:59] <ddaa> I think importstatus design needs to be reassessed.
[03:00] <ddaa> That's one of the many things related to imports that are really ugly and should be reconsidered as part as the bzr transition.
[03:00] <salgado> lifeless, still around?
[03:00] <bradb> mpt: Is it sinful to use head_epilogue for a local <style>?
[03:00] <ddaa> daf: does that make sense?
[03:00] <daf> ddaa: dunno -- I'll paste this conversation to the bug and assign it to you
[03:00] <ddaa> I cannot update or refile the bug because I'm not sure what the bug should be now...
[03:01] <daf> it's your bug
[03:01] <ddaa> also, it was partially implemented
[03:01] <ddaa> now even buttsource cannot update the rcs details of a syncing import...
[03:01] <daf> I'm not too concerned with the details
[03:01] <daf> I'm trying to get the number of unconfirmed bugs down
[03:02] <ddaa> right, sorry for the rant
[03:02] <daf> no worries, I'm used to it :)
[03:03] <spiv> daf: I've updated 102, I don't have a firm opinion on 121 at this time of night.
[03:03] <daf> spiv: heh, fair enough :)
[03:03] <daf> spiv: thanks
[03:04] <spiv> daf: Something about just tossing unadulterated SelectResults at web code feels a bit wrong to me, but I'm too sleepy to figure out why :)
[03:04] <spiv> Clearly being able to batch database result sets is a sensible desire, though.
[03:04] <daf> spiv: I tought that calling list() on SelectResults was also undesirable
[03:04] <spiv> daf: Yeah, that's bad :)
[03:05] <daf> spiv: given that this is over a year old, it would appear it's not biting us too badly, though
[03:05] <spiv> daf: Yeah.
[03:06] <spiv> daf: Or maybe it's already been fixed ;)
[03:06] <daf> no, ISelectResults has no __getslice__
[03:07] <daf> (__getitem__, __iter__, __len__, __contains__)
[03:07] <SteveA> __getslice__ is kinda deprecated in python
[03:07] <spiv> Heh, __len__
[03:07] <daf> :)
[03:07] <SteveA> things should be using __getitem__ with a slice object passed in
[03:07] <daf> maybe the migration to 2.4 fixed it then
[03:08] <daf> how can we check?
[03:08] <SteveA> but, it might be an issue with security proxies providing the __getslice__ slot, so that python tries that in preference to __getitem__ for proxied SelectResults
[03:08] <SteveA> daf: by writing a test!
[03:09] <spiv> Hmm, we could probably benefit from being able to "expected failure" tests.  bzr's test stuff can now do this, thanks to Robert.
[03:09] <salgado> SteveA, this test ( https://chinstrap.ubuntu.com/~dsilvers/paste/filerZ0vIa.html) is failing with this error. is it possible to workaround that?
[03:09] <daf> will select results in a doc test be security wrapped?
[03:09] <kiko> monkeypatchers of the world unite
[03:09] <SteveA> daf: depends how you get them
[03:10] <salgado> daf, only if you use a utility to get them, I think
[03:10] <daf> ok
[03:10] <salgado> a secured utility, actually.
[03:10] <salgado> but I guess all our utilities should be secured
[03:10] <SteveA> salgado: i don't get what's happening in that test
[03:11] <daf> Brad says he made IBugTaskSet a non-secured utility to work around that bug
[03:11] <Kinnison> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/filewDegkf.html
[03:11] <SteveA> salgado: we should improve TestRequest so that it is an accurate TestRequest
[03:11] <SteveA> salgado: but, we can also use a different main_template for tests.  this is possible, if we want it
[03:11] <SteveA> although, it might be not such a good test in that case
[03:12] <SteveA> the "can't set attribute" error is to do with you trying to override the qualities that are set in a class, on an instance
[03:12] <SteveA> python won't let you do that
[03:12] <salgado> SteveA, basically, I want to test the render() method of a view, so in this case I need to either stub the template() method or fix the TestRequest
[03:12] <SteveA> template() isn't a method i think
[03:12] <SteveA> it is a property
[03:12] <salgado> oh, right
[03:12] <salgado> I thought it was a method
[03:12] <SteveA> instead of stubbing it, you can subclass the view
[03:12] <SteveA> and override what you like in the subclass
[03:13] <SteveA> so, render() uses the template attribute
[03:13] <salgado> right, do you think this is better than fixing TestRequest?
[03:13] <SteveA> (property)
[03:13] <SteveA> i think we should fix TestRequest anyway, as this issue will come up again
[03:13] <SteveA> it is commendable that you want to unit test render() at a fine level of granularity
[03:14] <SteveA> i can suggest two different ways to do that if you want to
[03:14] <SteveA> one way is to put the render() unbound method into a different class context, by hairy python hacks
[03:14] <SteveA> the other is to do the same, but by subclassing the view class
[03:14] <SteveA> and overriding the template property there
[03:15] <daf> ok, I can't seem to reproduce the bug
[03:15] <SteveA> overall, i think improving TestRequest is a better strategy, considering where we are with testing views and launchpad right now.
[03:15] <SteveA> daf: did you try both with and without a security proxy?
[03:15] <kiko> just as a random suggestion
[03:15] <kiko> can we please have something better for pagetest POSTs than the crude HTTP we use today?
[03:15] <daf> SteveA: how do I do that?
[03:15] <kiko> something that takes a dict of arguments and an optional Person
[03:15] <kiko> for auth
[03:15] <SteveA> daf: if you get it starting with getUtility(ISomeSet), then it will be security-proxied.  check this by asking for type(obj) on the selectresults
[03:16] <SteveA> kiko: yes, with zope 3.2
[03:16] <kiko> thanks
[03:16] <salgado> yes, I think I agree with you that we should improve the TestRequest (maybe even LaunchpadTestRequest)
[03:16] <SteveA> kiko: we'll take what's in zope 3.2, and improve it as needed
[03:16] <salgado> as we already have a LaunchpadTestRequest
[03:16] <SteveA> salgado: okay
[03:17] <salgado> SteveA, do you have a plan already or should I try and come up with one?
[03:17] <daf> SteveA: yes, it is security proxied, and I can slice it
[03:17] <daf> SteveA: it == SelectResults instance
[03:18] <SteveA> and can you slice a non-proxied one?
[03:18] <SteveA> if you get it by a direct database import, it is not proxied
[03:18] <SteveA> (not using getUtility)
[03:19] <SteveA> salgado: i have no plan for this right now.  i think we should improve LaunchpadTestRequest, but i'd have to look at it and think about it as for how.  maybe you have some ideas?  look at how it is used in various places now.
[03:19] <carlos> SteveA: I'm back, just ping me when you are ready
[03:21] <daf> SteveA: yes, it works both with and without the proxy
[03:21] <salgado> SteveA, okay, I'm going to check that. and no, I don't have any ideas yet
[03:23] <SteveA> daf: would be good to leave the tests in there somewhere appropriate, and then close the bug
[03:23] <daf> SteveA: ok -- I've just dumped them in selectresults.txt for now
[03:23] <daf> SteveA: any ideas for a better location?
[03:25] <SteveA> daf: ask jamesh or spiv before merging
[03:25] <SteveA> you may want to rewrite it as a unit test, and stick it with the canonical database stuff
[03:25] <SteveA> carlos: ping
[03:25] <SteveA> carlos: let's go!
[03:25] <carlos> SteveA: pong
[03:26] <carlos> ok
[03:39] <kiko> bradb, how's that report looking?
[03:40] <bradb> kiko: I'm about 80% through diff cleanup.
[03:40] <kiko> great news!
[03:40] <kiko> bradb, still needs to go through review? it would be nice to make the rollout..
[03:40] <kiko> stub, have you cut production yet?
[03:40] <stub> kiko: no
[03:40] <kiko> okay.
[03:41] <kiko> bradb, maybe you could convince BjornT to fast-track a review for you on it?
[03:41] <bradb> kiko: I'll try.
[03:45] <Kinnison> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/filezAgXsG.html
[03:48] <dilys> Merge to devel/launchpad/: [r=spiv]  Fix bug # 29659 and bug # 29687, both related to the soyuz content classes and its relation with the publishing table and added some tests. (r3067: Celso Providelo)
[03:52] <kiko> thanks Kinnison
[04:14] <dilys> Merge to devel/launchpad/: [trivial]  Config updates (r3068: Stuart Bishop)
[04:26] <bradb> BjornT: Do you have time to review the bug contacts reports branch?
[04:32] <cprov> kiko:                Bug #30326
[04:35] <kiko> thanks cprov
[04:35] <BjornT> bradb: not now, but maybe later. how big is it?
[04:35] <kiko> BjornT, give bradb a hand so we can land this sooner rather than later
[04:35] <kiko> make sure he gets the time he needs
[04:36] <bradb> BjornT: 14 files changed, 894 insertions(+), 66 deletions(-)
[04:36] <kiko> (but note that this doesn't I'm pressuring you to accept the review, just to start sooner)
[04:37] <Kinnison> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/filekfDwCq.html
[04:38] <BjornT> kiko: well, i definitely need to get something to eat first
[04:39] <kiko> BjornT, okay. I'm not asking you to starve. :)
[04:41] <BjornT> kiko: and there's a 7-hour time difference between us, so he should have plenty of time ;)
[04:41] <BjornT> bradb: sent the patch to me, and i'll have a look at it after dinner
[04:42] <bradb> thanks, sending now
[04:45] <kiko> great
[04:45] <ddaa> kiko: can we have a policy about crossposting to launchpad-dev and launcphad-users?
[04:46] <ddaa> I expect that all launchpad devs should be reading launchpad-users as well
[04:46] <ddaa> that might change if the traffic grows too high, but in the meantime I think that's a good policy to have, and that makes cross-posting redundant.
[04:49] <kiko> did I just crosspost?
[04:50] <ddaa> "Launchpad Report for 2006-01-30" was posted to both lists, but... launchpad-dev does not appears in the "To"...
[04:50] <ddaa> weird...
[04:50] <ddaa> maybe you made launchpad-dev a BCC?
[04:51] <Kinnison> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileboGell.html
[04:52] <kiko> I did
[04:52] <kiko> ddaa, I did that, though I usually don't crosspost, to ensure that EVERYBODY gets that report
[04:53] <ddaa> well, launchpad devs not reading launchpad-users deserve blame anyway...
[04:54] <ddaa> kiko: is there a list of "mailing list you must be subscribed to" for staff?
[04:54] <kiko> maybe, but I honestly can't sort that out right now :)
[04:55] <ddaa> I'm willing to, given a "yes it's over there *waves*"
[04:55] <ddaa> but nevermind
[04:58] <daf> bradb: is your privbugs branch still extant?
[04:58] <daf> bradb: re bug #2730
[04:58] <Ubugtu> malone bug 2730 in launchpad "Login redirection goes to the wrong place on my canonical_url/privbugs changes branch" [Normal,Unconfirmed]  http://launchpad.net/bugs/2730
[04:58] <carlos> kiko: what happens with the back traces now that we are not members of the admin team anymore?
[04:58] <carlos> kiko: or is it linked with the devel team?
[04:59] <bradb> daf: Not really. The conversions took to long to bother.
[04:59] <salgado> I think it's linked with the devel team, carlos
[04:59] <carlos> ok
[04:59] <daf> bradb: hmm, what should we do with the bug then?
[04:59] <salgado> carlos, why you're not a member of the admins team anymore?
[05:00] <carlos> salgado: read latest mail at launchpad mailing list
[05:00] <carlos> salgado: kiko removed most of us from it
[05:00] <salgado> ah, right
[05:00] <carlos> for security reasons
[05:00] <kiko> carlos, it's launchpad
[05:00] <kiko> launchpad-devel or something
[05:00] <kiko> not admins
[05:01] <kiko> (AIUI)
[05:01] <carlos> kiko: ok
[05:02] <bradb> daf: It's still outstanding, so we should fix it.
[05:02] <daf> a test case would be good
[05:03] <bradb> The steps to reproduce are in the bug report.
[05:04] <bradb> Though you need to use a different bug now, because it appears that recent changes have caused bug #5 rendering to raise an exception.
[05:04] <Ubugtu> malone bug 5 in rosetta "Plone Placeless Translation Service metadata missing from po files" [Wishlist,Fix committed]  http://launchpad.net/bugs/5
[05:04] <bradb> Looks like an untested code path in Soyuz, at first glance.
[05:05] <kiko> daf, bradb: tell us about the problem, cprov may have just fixed it
[05:05] <carlos> bradb: ?
[05:06] <bradb> kiko:
[05:06] <bradb> Module canonical.launchpad.database.sourcepackage, line 58, in __init__
[05:06] <bradb> package = SourcePackagePublishing.selectFirst("""
[05:06] <bradb> AttributeError: type object 'SourcePackagePublishing' has no attribute 'selectFirst'
[05:06] <Kinnison> have you updated your sqlobject recently?
[05:06] <carlos> ah, the malone rendering of that bug
[05:06] <carlos> ok
[05:06] <carlos> :-P
[05:07] <bradb> Kinnison: No, though if I saw in some obvious place that I should have, I would have.
[05:07] <SteveA> bradb: there are scripts on the RocketFuelSetup page for that
[05:11] <kiko> bradb, what Kinnison said.
[05:13] <Kinnison> bradb: My first port of call on a bizarre error is to get fresh sourcecode/
[05:13] <cpro1> selectFirst requires refuel
[05:14] <kiko> bradb, if you don't hack on the crack inside sourcecode/
[05:14] <kiko> you can just link-external-sourcecode.sh into the prebuilt tree
[05:15] <ddaa> kiko: I need launchpad admin member ship to be able to review products to be able to approve rcs imports
[05:16] <SteveA> bradb: we'll be getting the scripts standardized and added to the launchpad developers' .deb soon
[05:16] <ddaa> kiko: that or the need to have the product reviewed to run a rcs import should be removed...
[05:16] <bradb> SteveA: cool
[05:16] <kiko> ddaa, I thought you needed buttsource?
[05:16] <ddaa> buttsource is needed to approve the productseries
[05:17] <kiko> can you just change permissions to require buttsource to create/approve rcs imports?
[05:17] <ddaa> cannot approve a rcs import if the product is not reviewed
[05:17] <ddaa> that's policy
[05:17] <ddaa> I'm happy to have it changed
[05:17] <kiko> buttsource can review a product, rs=kiko
[05:17] <kiko> you can email launchpad list if you like
[05:18] <ddaa> thank you, I will not email launchpad right now, I'd like to have a discussion with others about changing the import workflow (that I'm documenting) first.
[05:19] <ddaa> there's a whole cattle of sacred cows to burn in rcs imports...
[05:20] <kiko> ddaa, just don't let the fact that I haven't OKd it stop you from changing permissions any more.
[05:21] <ddaa> okay, but in that case it might have been simpler to give membership. Anyway, this topic is closed.
[05:22] <kiko> give membership?
[05:22] <bradb> Who's responsible for RocketFuelSetup?
[05:22] <kiko> bradb, jblack last I heard
[05:22] <ddaa> kiko: admin membership, to buttsource
[05:22] <bradb> that's what I thought. jblack, around?
[05:31] <LarstiQ> ddaa: I think he went to sleep 3 hours ago
[05:32] <ddaa> ?
[05:32] <LarstiQ> jblack
[05:32] <LarstiQ> oep
[05:32] <LarstiQ> s/ddaa/bradb/
[05:32] <bradb> ok, thanks
[05:33] <Kinnison> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/file5hyPCU.html
[05:35] <daf> carlos: bug #687
[05:35] <Ubugtu> malone bug 687 in launchpad "ProductReleaseVocabulary doesn't sort correctly" [Normal,Needs info]  http://launchpad.net/bugs/687
[05:36] <carlos> daf: hi
[05:36] <daf> carlos: you filed it, it's marked Needs Info
[05:36] <carlos> daf: I saw the comment from SteveA but I was not able to answer at that time
[05:36] <carlos> let me do it now
[05:38] <daf> thanks
[05:42] <carlos> daf: done
[05:43] <daf> thanks
[05:49] <bradb> kiko: BTW, I recommend that we first test the bug contact reports on staging before production, because it bumps up the batch size to 50.
[05:50] <kiko> bradb, revert the change to batch size, then.
[05:50] <kiko> you shouldn't put those changes together anyway
[05:50] <bradb> Keybuk: I'm triaging MaloneRunsUbuntuTaskList and wanted to know: is MoM working properly with malone?
[05:51] <bradb> kiko: It's just a constant. I can easily change it.
[05:51] <kiko> bradb, do it.
[05:51] <kiko> Keybuk, also, you will be able to use the text output
[05:51] <Keybuk> bradb: mom bug filing has been disabled until dapper+1 opens now
[05:51] <bradb> ok
[05:52] <Keybuk> but it worked properly for the week or two we used ith yeaj
[05:52] <bradb> kiko: batch size set back to 20, pushed to chinstrap
[06:02] <ddaa> kiko: I think bug #29519 is what is addressed by your "bzr branch" patch
[06:02] <Ubugtu> malone bug 29519 in launchpad "+addbranch doesn't say which of baz/bzr is allowed" [Normal,Confirmed]  http://launchpad.net/bugs/29519
[06:04] <bradb> salgado: Did you have any luck with my advanced search fix?
[06:08] <kiko> thanks ddaa
[06:09] <kiko> bradb, feel free to do a separate patch that bumps up batch size
[06:09] <kiko> rs=kiko for staging-testing, so land it later maybe?
[06:18] <Kinnison> for people who like to look at text files from the librarian (e.g. build logs) https://chinstrap.ubuntu.com/~dsilvers/paste/fileFzA6JQ.html
[06:30] <kiko> ddaa, is there an ETA for auto-branch-discovery yet, or is that futured?
[06:31] <ddaa> mh... You mean the bit where you say "bzr find thing" and it asks launchpad what's the corresponding branch and checks it out?
[06:31] <kiko> sorry, no, it's when launchpad finds out branches under my "home"
[06:32] <kiko> and adds the information to data
[06:32] <kiko> in the code pages
[06:32] <salgado> bradb, in what sense?
[06:32] <ddaa> kiko: you mean the bit that involves crawling the internet for branches?
[06:32] <kiko> not mindlessly
[06:32] <ddaa> as far as I can tell, it was classified as "wont do".
[06:33] <ddaa> jblack is mastermind though
[06:33] <ddaa> generally, my opinion is that there's more than enough work to get the stuff that's already in place to work well, so shiny new features like that should all be future, but I'm not the one to decide.
[06:34] <kiko> well
[06:34] <kiko> I want to know this: will I have to go and register every new branch I make of X there, ddaa?
[06:34] <kiko> because making branches with bzr is very cheap that's high overhead
[06:35] <ddaa> point
[06:35] <ddaa> sftp server will help some
[06:35] <ddaa> I think "bzr publish" should be near future though.
[06:36] <ddaa> But there's little point for that before we have critical stuff like error reporting and a better way to organise branch listings
[06:36] <ddaa> look at the bzr branch listing and you'll see that "more branches" is not what we need right now
[06:37] <ddaa> (I mean the "bzr" product)
[06:37] <ddaa> but again, it's all my non-authoritative opinion
[06:38] <kiko> ddaa, bzr publish is the answer, right, never mind me
[06:39] <ddaa> also, the way it was specced out, bzr publish would need some new infrastructure
[06:41] <ddaa> does somebody has a few minutes to be my "bug fixing teddy bear"?
[06:42] <kiko> ddaa, a good way to improve that page would be dropping the description when there are more than 5 branches
[06:42] <kiko> do you want me to do that now?
[06:44] <ddaa> kiko: that sounds like a good short term solution, if you keep the revision count line.
[06:44] <kiko> I'll try doing that now
[06:44] <kiko> ddaa, what product in sampledata has branches registered on it?
[06:45] <ddaa> gnome-terminal
[06:45] <kiko> ENOENT
[06:45] <ddaa> hu?
[06:45] <kiko> neeeever mind me
[06:46] <ddaa> there are branches elsewhere, but they are meant to test other features
[06:47] <ddaa> Kinnison: you'll be my teddy bear
[06:48] <ddaa> so, I'm describing a cscvs bug that has important ramifications on how importd must work
[06:48] <Kinnison> not now
[06:48] <Kinnison> not ever
[06:48] <Kinnison> kthxbye
[06:49] <ddaa> :( you've harmed my feeling
[06:49] <Kinnison> you have one?
[06:49] <ddaa> feelings
[06:49] <ddaa> with an s
[06:49] <ddaa> So, cscvs bug...
[06:50] <ddaa> When a sync occurs concurrently with a group of related cvs commit
[06:50] <doko> kiko, SteveA: does launchpad rely on anthing new in zope-3.2 (changed from 3.1)? Considering a downgrade from zope-3.2 to zope-3.1 in dapper, dependent packages don't build yet with 3.2
[06:50] <ddaa> that would be grouped into one commit if the sync was run after the group is entirely comitted
[06:51] <ddaa> then the part of the commit group that's completed at the time of the sync is intepreted as a changeset
[06:51] <ddaa> and the rest is interpreted as a separate changeset on the next sync
[06:52] <ddaa> leading to a situation where rebuilding the cache from scratch would make one changeset instead of two
[06:52] <ddaa> so the cscvs cache must not be discarded otherwise the import and the cache get out of sync when rebuilding the cache.
[06:52] <ddaa> Kinnison: is that understandable?
[06:53] <kiko> doko, not yet -- we are considering moving to 3.2. but I don't think we use any system zope3.2
[06:57] <doko> kiko: ok
[06:58] <kiko> we have our own internal branch. SteveA and stub are the authoritative reference on that though.
[06:59] <Kinnison> ddaa: yes that's understandable
[06:59] <Kinnison> ddaa: Can you not say "if any part of the changeset is younger than <arbitrary time> then don't consider it yet" ?
[06:59] <ddaa> In theory, yes.
[07:00] <ddaa> In practise, when I tried doing that, my brain attempted to escape through the orifices of my skull.
[07:00] <ddaa> Now the point is moot, because we almost certainly have this data corruption in several branches.
[07:01] <ddaa> I'll send earplugs to whoever gets to try and fix that bug, that should help the brain escape problem.
[07:04] <dilys> Merge to devel/launchpad/: [r=kiko]  Cleanup +builds page: remove internal URL, use processor name, strip misleading opening paragraph, etc. (r3069: James Troup)
[07:07] <bradb> kiko: Yeah, I can do a separate patch to bump it up to 50 after the first bug contacts reports land.
[07:07] <bradb> salgado: Were you planning on landing the search fix I gave you?
[07:07] <kiko> good work guys
[07:09] <salgado> bradb, no, I was only planning to have a look at it, to check if the bug I fixed wasn't fixed there too
[07:09] <bradb> ok, I'll try and get it by pqm then
[07:11] <fabbione> hey bradb
[07:11] <bradb> hey fabbione, how's it going?
[07:11] <fabbione> bradb: i need a "dirty" batch work on malone :)
[07:11] <fabbione> bradb: pretty fine thanks
[07:11] <fabbione> bradb: http://people.ubuntu.com/~fabbione/x-src-main.list
[07:12] <fabbione> bradb: that's a lst of source package. I would like to get all the bugs assigned to these sources (and their binaries) reassigned to ubuntu-x-swat
[07:12] <fabbione> bradb: can you please do it yesterday? ;)
[07:13] <fabbione> bradb: it's quite urgent.. i know it's a short notice, but mdz said that can be done
[07:13] <fabbione> bradb: i will own you one for the next time we meet
[07:13] <ddaa> Kinnison: thank you, I found the way to explain that more clearly.
[07:14] <bradb> stub: around?
[07:14] <bradb> fabbione: I think we can make progress only if stub is around, to run the query against prod.
[07:14] <mdz> fabbione: what I said was that you should send the list to me
[07:15] <fabbione> mdz: or to a lp admin..
[07:15] <fabbione> bradb: ok i think mdz is taking over.. right?
[07:15] <mdz> and I was talking about setting bug contacts rather than reassigning bugs, though that should be doable as well
[07:16] <mdz> regardless of the reassignments you need to set the bug contacts
[07:16] <fabbione> mdz: i'd rather reassign all of them to the team
[07:16] <mdz> fabbione: and what about new bugs which are filed?
[07:16] <fabbione> and set the bug contact in one shot
[07:16] <fabbione> mdz: i assume they should get assigned to the team as well
[07:16] <mdz> fabbione: malone doesn't support that, only subscription via bug contact
[07:17] <kiko> using subscriptions is more correct.
[07:17] <kiko> assignment is for indicating who will fix/fixed the problem.
[07:18] <mdz> kiko: can someone help him?
[07:18] <kiko> but I never said that la la la la la la
[07:18] <kiko> mdz, you want mass-subscription, right?
[07:18] <mdz> kiko: mass-assignment and mass-add-bug-contact
[07:18] <mdz> or mass-subscription and mass-add-bug-contact
[07:18] <kiko> bradb, when are you going to give me the mass-subscription-when-adding-bug-contact feature? :)
[07:19] <kiko> I need to think about this
[07:19] <bradb> kiko: I can do it next, if you want.
[07:19] <kiko> mdz, fabbione: can you explain why you can't use ubuntu-bugs and then filter the packages you want? procmail got the better of you? :-)
[07:20] <mdz> kiko: don't be daft
[07:20] <kiko> ouch
[07:20] <fabbione> kiko: add +1 to my beer count
[07:20] <kiko> well, only way to do that /right now/ is to request it to stub.
[07:20] <fabbione> kiko: just to help me forget what you just said :)
[07:20] <kiko> it was a joke
[07:20] <mdz> kiko: fabio needs to be able to manage the list of open bugs related to this group of packages
[07:20] <mdz> he can't do that with ubuntu-bugs
[07:20] <kiko> you guys are trigger happy today eh
[07:21] <kiko> so short answer
[07:21] <kiko> stub
[07:21] <fabbione> kiko: READY TO KILL!
[07:21] <mdz> kiko: so fabio should send his request directly to stub?  or would one of you translate it into launchpad-speak?
[07:21] <mdz> s/request/requests/
[07:22] <kiko> medium term answer: we'll have a subscribe-to-existing-bugs UI in the bug contact page, and then we'd need a mass-bug-change form to subscribe people.
[07:22] <kiko> mdz, I think that's the only solution right now, yes
[07:22] <fabbione> kiko: consigliere.. does that mean that i need to wait for a new malone feature, or just stub to hack the db?
[07:22] <kiko> stub.
[07:22] <kiko> don't wait, just mail him
[07:23] <mdz> kiko: even if that feature existed, it wouldn't be a solution in this case
[07:23] <mdz> kiko: there are 195 packages in that list
[07:23] <bradb> I'm so glad I'm not a DBA. I HATE SQL HACKS.
[07:24] <fabbione> mdz: source packages :)
[07:24] <fabbione> in what TZ is stub?
[07:24] <mdz> thailand
[07:24] <fabbione> that means pretty much asleep
[07:25] <kiko> bradb, just a question: how do bug contacts behave in the face of bugs on sources versus bugs on binaries?
[07:25] <bradb> kiko: It's all done through the source package.
[07:26] <kiko> ok.
[07:26] <kiko> thanks.
[07:56] <SteveA> doko: launchpad will rely on zope 3.2, but we'll still be keeping our own branch of it, independently of other stuff.
[07:56] <SteveA> doko: if i were supporting zope 3 in a distro, i'd be much happier about supporting 3.2 than earlier releases
[08:04] <kiko> me too
[08:09] <SteveA> salgado: you should subscribe to specs you own, on the wiki.  i just commented on https://wiki.launchpad.canonical.com/InactiveMembershipDeletion
[08:13] <doko> SteveA: two things: schooltool/schoolbell (the only users of zope in main) do still require zope-3.1. the current zope-3.2 comes with an unreleased version of twisted and doesn't run with the released 2.1 version. both are currently installed into site-packages. The only solution I currently is to install the zope3 libs into a directory outside sys.path and ship the modified twisted version there. same with schooltool (ship it with zope-3.1 included). from
[08:13] <doko>  a maintainance view, that means to support two zope and and two twisted versions. is that really better than supporting 3.1?
[08:14] <SteveA> the twisted dependency isn't required as far as i understand
[08:14] <SteveA> when is version freeze?
[08:14] <salgado> SteveA, thanks for noting it, I'll check if there's any other specs I sould be subscribed and subscribe to them
[08:14] <SteveA> i think that if the zope3 release people get to understand the effect of their choices on getting it into distros, maybe they'll sort things out better
[08:15] <SteveA> stephan, that is
[08:15] <doko> SteveA: UVF was some days ago
[08:15] <SteveA> if i'd known about this a while ago, i could have done something.
[08:16] <SteveA> well, if people want zope 3.2, they can use backports, i guess
[08:16] <doko> well, you first have to see things break :-/
[08:17] <SteveA> it has no bearing on launchpad development, except that we have bugfixes in twisted SVN that we depend on for one thing
[08:17] <SteveA> and i don't think these have gone into any twisted release yet
[08:18] <kiko> is jamesh around yet?
[08:18] <doko> ok, I'll ping the schooltool/schoolbell project
[08:18] <SteveA> it will be several more hours i expect
[08:18] <doko> SteveA: do you know of planned twisted releases?
[08:18] <SteveA> doko: i think the core schooltool developers are busy tonight with some sysadmin / machine moving stuff
[08:18] <SteveA> tomorrow afternoon might be a better time to catch up with them
[08:19] <SteveA> i don't know about twisted releases, but spiv will do
[08:19] <SteveA> to be honest, i'd look at the version of schooltool you want to support
[08:19] <SteveA> and then base decisions from what that needs
[08:19] <SteveA> and get the latest possible twisted in there
[08:20] <SteveA> and kinda screw the rest
[08:20] <doko> yeah, I'll ask jinty first ...
[08:20] <SteveA> but then again, that's why i develop new unpackaged software, rather than work on a distro ;-)
[08:20] <SteveA> so take my opinion with large amounts of salt
[08:21] <jinty> doko: want my opinion now?
[08:21] <SteveA> hi brian!
[08:21] <jinty> Hi SteveA
[08:21] <doko> SteveA: afaik, sabdfl want's the latest and greatest schooltool anyway, so better plan ahead for this ;)
[08:21] <jinty> saw you guys having a little chat and thought I'd butt in
[08:22] <doko> jinty: didn't write to the schooltool list yet
[08:22] <jinty> that'll leave schoolbell out in the cold
[08:23] <jinty> AFAIK: you can't even build schoolbell from the latest schooltool source
[08:23] <jinty> and it's quite highly beta
[08:24] <jinty> but nobody wants to spend time/money updating the old release to 3.2
[08:24] <SteveA> jinty: do you know if the schooltool developers have a "get a good release into dapper" task?
[08:25] <jinty> th1a was thinking about it when I spoke to him about it
[08:25] <SteveA> ddaa: hi.  have you told jamesh about your supermirror systems docs?
[08:25] <jinty> the problem is known, but perhaps some prodding from people other than me is in order
[08:27] <jinty> SteveA: thanks;)
[08:27] <SteveA> doko: can you /join #schooltool ?
[08:31] <jordi> hmm.
[08:31] <jordi> who is a launchpad admin now?
[08:33] <jordi> SteveA: I guess you could do this for me, if you have two spare mins
[08:38] <jordi> SteveA: can you go here https://launchpad.net/rosetta/imports, sort by date and get rid of all the "Drupal" requests by Firat KUUK? Check all the boxes in the first column and "Remove" them
[08:38] <ddaa> SteveA: mh... no, I meant not to confuse him with documentation that had not been reviewed...
[08:39] <SteveA> ddaa: let him be a reviewer
[08:39] <SteveA> jordi: i'm doing some other stuff right now, but i'll look in a few minutes
[08:41] <carlos> Hmm, I'm getting errors from the ticket.txt doc test
[08:41] <carlos> and I didn't change anything related to it
[08:41] <carlos> is it a know issue?
[08:41] <ddaa> SteveA: okay, I'll add a couple of todo notes, put the newer stuff online and tell jamesh.
[08:41] <jordi> SteveA: k
[08:41] <ddaa> but right now I have to do dinner.
[08:42] <jordi> carlos: once SteveA gets rid of drupal, the q ueue will be mostly clean, except for the thunar request I'm waiting for a reply
[08:42] <jjesse> don't know if this is the correct place but launchpad.net doesn't display correctly in internet explorer 7 beta 2
[08:42] <carlos> jordi: don't do that, please. At least leave one or two entries
[08:43] <jjesse> plus every page gives me an alert about blocked contnet
[08:43] <carlos> to check that it's fixed as soon as I merge the fix
[08:45] <bradb> jjesse: The place to file Launchpad bugs is: https://launchpad.net/products/launchpad/+filebug . Probably your best option if you want to make sure the right person sees this problem reported.
[08:45] <jjesse> bradb: thanks
[08:45] <bradb> no prob
[08:45] <SteveA> jordi: no
[08:45] <SteveA> jordi:     *
[08:45] <SteveA> AssertionError: Ignored your request to remove some items, because they are not yours.
[08:46] <SteveA> do i need to be both admin and rosetta expert, i wonder
[08:47] <SteveA> carlos, jordi: tell me what to do
[08:48] <SteveA> interesting question from the schooltool channel
[08:48] <SteveA> -- Can we use LaunchPad now to host our releases: including Mac and Windows binaries?
[08:49] <SteveA> (of course, we don't host releases, just index them)
[08:50] <BjornT> bradb: if you haven't checked your mail yet, i've sent you the review
[08:50] <carlos> SteveA: please, remove all entries except one or two
[08:50] <bradb> BjornT: Thanks, checking now.
[08:51] <jordi> SteveA: no idea, I've never been successful there
[08:51] <jordi> carlos: you'll have plenty to remove
[08:52] <SteveA> carlos: i can't
[08:52] <SteveA> i get that assertion error
[08:52] <carlos> SteveA: aren't you a launchpad admin?
[08:52] <SteveA> SteveA AssertionError: Ignored your request to remove some items, because they are not yours.
[08:53] <SteveA> yes
[08:53] <SteveA> i have the ducky symbol
[08:53] <carlos> so that code is completely broken :-O
[08:53] <carlos> but I have tests for that!
[08:58] <zyga_> hey guys :-)
[09:04] <jordi> hey
[09:04] <jordi> zyga_: so
[09:05] <jordi>
[09:05] <jordi> If I tell you this, what do you reply? Traditional, or Simplified?
[09:05] <zyga_> jordi: simplified
[09:06] <zyga_> jordi: japanese is using those glyphs as well
[09:06] <salgado> BjornT, that patch you reviewed yesterday uncovered another bug (lots of tests failed because of that). hopefully, after I found the bug it uncovered it was an easy fix. would you review it for me?
[09:07] <zyga_> jordi: was I right?
[09:07] <jordi> zyga_: I dunno :P
[09:07] <jordi> let me check
[09:08] <jordi> zyga_: shrug
[09:08] <jordi> looks like zh_CN to me too, but who knows
[09:09] <zyga_> jordi: that's japanese just as well IMHO
[09:10] <BjornT> salgado: is it urgent? i'd rather not review it tonight, but could do it tomorrow.
[09:11] <kiko> salgado, interdiff!
[09:11] <salgado> BjornT, it's another 2lines change
[09:12] <kiko-fud> say yes BjornT and get ice cream and diabetes
[09:12] <salgado> https://chinstrap.ubuntu.com/~dsilvers/paste/filesPTHUA.html
[09:12] <lifeless> salgado: I can review it
[09:12] <kiko-fud> r=kiko salgado
[09:12] <kiko-fud> it is obviously correct
[09:12] <kiko-fud> and mutable class variables are BAD
[09:13] <lifeless> yup
[09:13] <kiko-fud> so kill whoever wrote that
[09:13] <lifeless> ++++
[09:13] <kiko-fud> with great prejudice and vengeance and oh jesus
[09:13] <kiko-fud> it was you?
[09:13] <lifeless> thats a little harsh
[09:13] <lifeless> tickle him until he asks for death
[09:13] <kiko-fud> he has broken god's law
[09:13] <kiko-fud> mutable class arguments == DEATH mmkay
[09:14] <salgado> and my reviewer didn't spot it. :p
[09:15] <kiko-fud> and omg
[09:16] <kiko-fud> navigation uses links = []  too
[09:16] <kiko-fud> and jesus
[09:16] <kiko-fud> SteveA, why does navigation use mutable class variables
[09:16] <jordi> ok
[09:16] <jordi> the import queue is empty again
[09:16] <jordi> or what's left I can't do much about
[09:17] <jordi> kiko-fud: when does the dapper import happen?
[09:17] <jordi> I get this question aaaaall the time
[09:17] <kiko-fud> wtf is dapper import?
[09:17] <kiko-fud> langpacks?
[09:18] <kiko-fud> after soyuz
[09:18] <jordi> no
[09:19] <jordi> when people can translate dapper packages
[09:19] <jordi> ie, after soyuz
[09:19] <jordi> is there a target date for soyuz?
[09:25] <carlos> jordi: dapper is not blocked anymore by soyuz
[09:25] <jordi> oh
[09:25] <carlos> jordi: I was told that the soyuz support for translations is going to take a while
[09:25] <jordi> aw
[09:25] <carlos> so I need to port the old script to the new system
[09:38] <carlos> gneuman: hi, are you able to read my private messages?
[09:41] <dilys> Merge to devel/launchpad/: Fix the switch-to-advanced-search on bug listing pages to make sure the search initially performed is the exact search performed by that page plus the text and sort columns (in case the user specifies them). r=BjornT,kiko (r3070: Guilherme Salgado)
[10:05] <matsubara> stevea, kiko-fud: is the impossibility to delete/remove/close a launchpad account a bug or a design thing?
[10:37] <ddaa> jamesh: you should have a mail that points you to some instructive reading
[10:37] <ddaa> good night guys
[10:55] <carlos> night
[11:22] <kiko> hey jamesh
[11:24] <lifeless> its 730 there
[11:24] <lifeless> dont think he'll be up yet