[12:14] <Kinnison> ciau all
[01:33] <mpt> Gooooooooooooooooooooooooood afternoon Launchpadders!
[02:27] <Mez> https://launchpad.net/+builds/+build/167652
[02:28] <Mez> why does it show "unknown" or unavailable for chnages/gpgp key
[08:17] <mpt_> Where is everyone?
[08:22] <jamesh> here
[08:33] <sivang> morning
[08:34] <ajmitch_> mpt_: shh, you'll wake people up
[08:34] <sivang> ajmitch_: lol :)
[08:47] <SteveA> morning
[08:47] <SteveA> mpt_: i'm here!
[08:50] <daf> good morning
[08:50] <daf> mpt_: how was your gardening?
[08:53] <mpt_> daf, pretty good
[08:54] <mpt_> helped remove a fence, picked tomatoes, dug a potato patch, did some weeding
[08:54] <daf> I expect it's quite warm for you right now
[08:55] <mpt_> yeah, 25-ish
[08:56] <mpt_> but now I'm back in Dunedin with the heater on
[08:56] <daf> heh
[08:56] <daf> ha, the wiki FrontPage links to https://launchpad.net/soyuz
[08:57] <daf> oh, it doesn't
[08:57] <daf> wow, there's a /bazaar
[08:58] <mpt_> jamesh, seen the latest developments in that user certificate bug?
[08:58] <mpt_> it's very odd
[08:59] <jamesh> mpt_: I've got no idea about it.
[08:59] <SteveA> mpt_: what's up?
[09:00] <jamesh> mpt_: but without any way to reproduce, it is a bit hard to do anything
[09:00] <SteveA> jamesh: do we still have __len__ in sqlobject?
[09:00] <SteveA> my email server hasn't been receiving mail since last night, so i haven't seen recent checkins
[09:00] <mpt_> SteveA, in some installations of Internet Explorer for Windows, Internet Explorer for Mac, and Safari, Launchpad apparently asks for a user certificate
[09:01] <mpt_> which makes Launchpad unusable for the latter two
[09:01] <SteveA> how does it ask for a user certificate?
[09:01] <mpt_> I don't know
[09:01] <jamesh> SteveA: I haven't merged it yet.  There were a few new occurrences of methods that sometimes return SelectResults and sometimes return a list
[09:02] <jamesh> should go in today
[09:02] <mpt_> https://launchpad.net/products/launchpad/+bug/6659
[09:02] <Ubugtu> malone bug 6659 in launchpad "Launchpad requests user certificate from Safari, MSIE/Windows, MSIE/Mac" [Normal,Unconfirmed]  
[09:02] <SteveA> jamesh: this is very important for stopping certain timeouts.  i want stu to put it into today's rollout, if that's possible
[09:03] <SteveA> mpt_: how far along did you get with adding the custom +pagetitle views for different types of object?
[09:03] <jamesh> SteveA: okay.  I think I've got the last ones, so I'm doing a final "make check"
[09:03] <mpt_> SteveA, I haven't started that, it's down about #5 on my priority list
[09:04] <mpt_> make that #8
[09:05] <jamesh> SteveA: I found that my original __nonzero__ implementation was actually issuing queries like "select count(*) from table where condition limit 1", which doesn't actually improve things
[09:05] <SteveA> ok
[09:05] <jamesh> SteveA: I've got that fixed so that it issues "select id from table where condition limit 1", which was the original intent
[09:05] <SteveA> mpt_: can we have a voice call?
[09:05] <mpt_> SteveA, sure
[09:05] <SteveA> mpt_: okay.  i'll finish my bowl of museli first, though
[09:06] <mpt_> ok, call when ready
[09:06] <sivang> hi daf , SteveA , jamesh
[09:07] <SteveA> mpt_: to diagnose 6659 we should check whether it is a basic apache config issue, or something more to do with launchpad.
[09:07] <jamesh> hi sivang 
[09:07] <SteveA> mpt_: we can do this by putting up a static HTML page, and having apache configured to serve this at /ssltestpage.html
[09:08] <SteveA> this page will include no images or style sheets.  we'll see if the reporters still have the problem then
[09:08] <mpt_> SteveA, is that a job for elmo/Znarl?
[09:08] <jamesh> mpt_: we can probably safely disable cert checking now
[09:08] <SteveA> if so, it is something for the admins to look into further, as it is out of our realm
[09:08] <SteveA> jamesh: right, we can also simplify our apache setup
[09:08] <jamesh> mpt_: since we have nothing protected by the cert in production now
[09:08] <SteveA> i wonder if Znarl is around yet, to discuss this
[09:08] <mpt_> I can reproduce the problem with MSIE/Mac myself, so that should be fairly quick
[09:09] <SteveA> mpt_: let's see if we can get some of znarl's time this morning to try simplifying the apache configuration
[09:11] <mpt_> jamesh, oh, now I remember what you're talking about
[09:12] <mpt_> from the time we used to have "Not Ready" for some things
[09:13] <jamesh> mpt_: "https://launchpad.net/errors" required that you have a client certificate installed
[09:14] <jamesh> that URL is gone now (the equivalent info being on chinstrap now), so we don't need to use a client cert
[09:14] <mpt_> ok
[09:30] <SteveA> mpt_: call?
[09:30] <mpt_> sure
[09:33] <carlos> morning
[09:43] <dilys> Merge to test/launchpad/sourcecode/sqlobject/: [trivial]  fix SelectResults.__nonzero__ to not issue a count() query (r42: James Henstridge)
[09:52] <carlos> SteveA: Hi, around?
[10:02] <Kinnison> hmm, no stub
[10:03] <Kinnison> we're meant to be doing the prod rollout in 30
[10:08] <dilys> Merge to devel/launchpad/: [trivial]  fix last few uses of SelectResults.__len__ in LP (r3095: James Henstridge)
[10:19] <carlos> spiv: hi
[10:26] <Kinnison> Has anyone seen stub?
[10:26] <elmo> Kinnison: znarl is locked out of the window and can't do the upgrade
[10:27] <elmo> err
[10:27] <elmo> s/window/building
[10:27] <Kinnison> elmo: aah
[10:27] <Kinnison> elmo: so are we postponing the entire rollout?
[10:27] <elmo> dunno where stub is - pls pass the message on
[10:27] <elmo> Kinnison: that'd be nice, if you can
[10:27] <Kinnison> elmo: well, I've not seen stub yet, so I'm guessing he'll turn up in a bit
[10:28] <elmo> ok, gone
[10:28] <elmo> (I left a note on emperor fro stub)
[10:29] <Kinnison> cool
[10:29] <dilys> Merge to test/launchpad/sourcecode/sqlobject/: [trivial]  actually remove SelectResults.__len__() now (r43: James Henstridge)
[10:36] <SteveA> yay
[10:38] <Kinnison> stub: Znarl can't make the rollout
[10:38] <Kinnison> stub: elmo has asked if we can postpone
[10:40] <SteveA> stub: for the next rollout, please consider jamesh's __len__ removal, and mpt's build-pages fix that is about to land
[10:40] <stub> Kinnison: Do the Launchpad rollout another day this week? Or postpone the librarian disk firmware upgrade thingy until next week?
[10:40] <stub> SteveA: Just looking at that now (the final __len__ patches)
[10:40] <Kinnison> stub: he didn't make it clear
[10:40] <Kinnison> stub: just that znarl can't make it
[10:41] <stub> Kinnison: How much pain is involved in shutting down and starting everything up?
[10:41] <SteveA> elmo: there seems to be some client-certificate oddness with launchpad.  i'd like to get the apache config simplified a little, while mpt is still here, so that mpt can test on the mac safari browser.
[10:42] <SteveA> elmo: do you have time to do this now?
[10:42] <Kinnison> stub: if we start in the next 10 minutes, very litle
[10:42] <Kinnison> stub: if we wait until gone 10am, we have to wait for the archive to cycle which takes ca. 30m
[10:43] <stub> Kinnison: I still have to tag the production release and run the test suite :-)
[10:43] <Kinnison> stub: okay, can we delay for 1030 UTC?
[10:43] <stub> Kinnison: I'm happy to postpone the rollout until tomorrow in case Znarl is available then. It gives people a bit of time to test the new __len__ updates for SQLObject too
[10:44] <Kinnison> stub: that's fine by me too
[10:44] <stub> In fact, since we want some of mpts code rolled out that hasn't landed yet, I think that is our best option
[10:44] <Kinnison> okay
[10:44] <Kinnison> tomorrow, 0930 UTC?
[10:44] <stub> Sounds good.
[10:44] <Kinnison> cool
[10:45] <stub> SteveA: Anyone going to cry if we leave the rollout until tomorrow?
[10:45] <SteveA> no
[10:45] <SteveA> will the rollout be a lot of downtime?
[10:46] <SteveA> if so, it should be announced in advance, seeing as we can plan it
[10:46] <Kinnison> I'll let ubuntu-devel know
[10:46] <SteveA> carlos: you should let rosetta-users know
[10:46] <SteveA> and someone should let launchpad-users know
[10:47] <carlos> ok
[10:47] <SteveA> let's get the facts straight first
[10:47] <SteveA> so, starting at 0930
[10:47] <SteveA> estimated downtime is what?
[10:48] <daf> don't we have a wiki page with a checklist of things that need doing for non-trivial downtime?
[10:51] <carlos> stub: ?
[10:53] <stub> SteveA: Downtime depends on the Librarian server maintenance if that goes ahead. So for this upgrade we need an ETA from Znarl (launchpad itself and the database will only need to be down 10 mins or so)
[10:54] <Znarl> Back in the building.
[10:54] <SteveA> hi Znarl 
[10:54] <Znarl> Hello SteveA.
[10:55] <SteveA> Znarl: there is some apache reconfiguration i'd like to try, related to launchpad, and related to an odd bug on safari and IE.  i want to try the reconfiguration while mpt is awake, so he can try it.  is it possible to try it out now?
[10:55] <SteveA> also, we're discussing the rollout / librarian maintenance tomorrow, and what kind of notification we should give to users
[10:56] <Znarl> We've moved the rollout/downtime?
[10:57] <Znarl> SteveA : I really need to focus on the firmware upgrade, it's fairly important.
[10:57] <SteveA> ok, the apache stuff can wait
[10:58] <SteveA> Znarl: can you read the scrollback from where daniel said:
[10:58] <SteveA> Kinnison stub: Znarl can't make the rollout
[10:58] <SteveA> Kinnison stub: elmo has asked if we can postpone
[10:58] <SteveA> maybe 60 lines up
[11:00] <Znarl> I was let back into the building, so I can still do the upgrade.  I'll need 20 minutes of downtime on mizuho to do the upgrade.
[11:01] <Kinnison> right, well we're stuck now for 30 minutes
[11:01] <Kinnison> because cron.daily has begin for the distro archive
[11:01] <Kinnison> so if everyone can be ready to start at ca. 10:30 we can start then
[11:01] <Znarl> OK, fine with me.
[11:01] <stub> ok
[11:01] <stub> I'll tag.
[11:01] <SteveA> how long will the downtime be?  do we need to notify people?
[11:02] <SteveA> stub: will we still be able to upgrade some code tomorrow?
[11:02] <stub> SteveA: less than an hour, so we can get away with channel notifications
[11:02] <stub> SteveA: Code only, yes.
[11:02] <Kinnison> right, so we're gonna roll out at 10:30
[11:02] <SteveA> carlos: i think notifying rosetta-users would be nice.
[11:03] <carlos> ok
[11:03] <carlos> so
[11:03] <carlos> 10:30 UTC for 1 hour or so
[11:03] <carlos> is that ok?
[11:03] <stub> I've got r3084 with cherry picks of 3086, 3091, 3093 and 3095 requested.
[11:04] <SteveA> Znarl, stub, Kinnison: starting at 10.30 UTC for 1 hour?  is that correct?
[11:04] <Kinnison> yes
[11:04] <Kinnison> I've informed #ubuntu-devel
[11:04] <Znarl> yes
[11:04] <SteveA> i'll mail launchpad-users
[11:04] <Kinnison> stub: how many db patches does that include?
[11:05] <stub> Kinnison: nfi
[11:05] <SteveA> stub: what will be the effects on the wikis?
[11:06] <stub> SteveA: read only mode while the db is down. Maybe 10 mins.
[11:07] <SteveA> stub: how long is the webapp down for?
[11:07] <carlos> sent the email to rosetta-users and ubuntu-translators mailing lists
[11:08] <stub> Ahh sod - cant cherry pick 3095 doe to conflicts
[11:08] <SteveA> what was the purpose of 3095?
[11:08] <stub> __len__ updates will need to wait
[11:08] <SteveA> oh, poo
[11:09] <carlos> SteveA: do you need anything else from me? I need to go out for an hour or so
[11:09] <SteveA> carlos: no, that's fine.
[11:09] <carlos> ok, see you later
[11:09] <SteveA> stub: how long will the webapp be down for?  10 mins again?
[11:09] <SteveA> or the full hour?
[11:10] <stub> SteveA: About 10 mins
[11:10] <SteveA> ok
[11:10] <mpt_> daf, ping
[11:11] <Kinnison> stub: did you find which db patches will be involved?
[11:11] <Kinnison> stub: I only need to know about schema changes
[11:13] <stub> Kinnison: patches 16 and 17 are new and will be going out
[11:15] <stub> Anyone know how I specify a particular bzr revision in a config manager config file now? lifeless?
[11:15] <Kinnison> stub: okay, thanks
[11:16] <SteveA> jamesh: ping
[11:19] <jamesh> SteveA: pong
[11:21] <SteveA> jamesh: stub can't cherrypick the __len__ changes due to conflicts
[11:21] <jamesh> oh?
[11:22] <jamesh> he'd probably need to pick both 42 and 43 together
[11:23] <SteveA> i thinnk this is the launchpad changes
[11:23] <SteveA> not the sqlobject changes
[11:24] <Kinnison> stub: cron.daily is still in-progress, taking a while longer than usual this time due to new kernels
[11:25] <Kinnison> stub: it's in the final phase, so it won't be more than 5 minutes (with a bit of luck)
[11:27] <jamesh> SteveA: maybe some of my changes were to fix code newer than what's on the production branch
[11:28] <Kinnison> stub: right, cron.daily finished
[11:29] <stub> Ok. Just building the tree on emperor
[11:29] <SteveA> jamesh: okay.  i guess we'll leave __len__ for now, and get it landed in the next rollout
[11:29] <jamesh> what were the conflicts in?
[11:30] <stub> Scheduled launchpad shutdown in 10 mins
[11:30] <Kinnison> ftpmaster is locked down ready
[11:30] <jamesh> it may be that the conflicts can be ignored
[11:33] <Kinnison> SteveA: are you an lp-u moderator? I've posted to it but it's being held in a queue
[11:33] <Kinnison> SteveA: I hadn't realised it would be held
[11:33] <daf> mpt_: pong
[11:33] <Kinnison> SteveA: it's about the rollout
[11:36] <SteveA> Kamion: i'll see to it
[11:36] <mpt_> daf, SteveA suggested we should talk about people vs. users, but I'm about to fall asleep
[11:36] <SteveA> mpt_: it can wait for another day
[11:36] <mpt_> daf, in how many more hours will you start work again? 22? 23?
[11:36] <SteveA> Kinnison: done
[11:37] <Kinnison> SteveA: ta
[11:38] <daf> mpt_: 23 or so, yes
[11:39] <mpt_> ok, talk to you then
[11:39] <daf> ok
[11:39] <mpt_> In the meantime, read through the WhyTheSmegAmIHere spec
[11:39] <mpt_> if you're not familiar with it
[11:39] <daf> I'm not
[11:39] <mpt_> because it partly overlaps
[11:39] <mpt_> but it's partly na?ve as well
[11:40] <daf> overlaps what?
[11:40] <mpt_> the spec SteveA says you're writing
[11:40] <mpt_> about people vs. users
[11:40] <daf> ah, right, yes
[11:40] <mpt_> 'night
[11:40] <daf> night
[11:41] <stub> launchpad and the librarian is all down down - kicking of the database update
[11:41] <daf> dive dive dive
[11:43] <mpt_> And as a result, we've gone from copyright 2004-2006 back to 2004-2005
[11:44] <cprov> morning, dudes
[11:51] <Kinnison> is Znarl doing the librarian stuff on mizuho already?
[11:54] <stub> Kinnison: yes
[11:54] <Kinnison> cool
[11:56] <Znarl> Looking good on my end.
[11:57] <Kinnison> Znarl: the firmware went on okay?
[11:58] <Znarl> Yes.  Doing final checks now.
[11:58] <Kinnison> rocktastic
[11:58] <Kinnison> stub: how's the db?
[11:59] <stub> Kinnison: I messed up the shutdown procedure a bit, so the authserver managed to reconnect and lock the person table. The upgrade is proceding again.
[11:59] <Kinnison> stub: heh
[12:02] <SteveA> jamesh: hi.  i don't see an oops report on the launchpad list.
[12:05] <Znarl> Finished!
[12:05] <Kinnison> Znarl: cool
[12:05] <Kinnison> stub: eta?
[12:07] <Kinnison> heh
[12:08] <stub> Waiting on the peope table to update. Won't know until it is done. Shouldn't be more than a few mins - there are only 150,000 or so rows
[12:08] <Kinnison> right
[12:08] <Kinnison> and emperor is def' busy?
[12:08] <Kinnison> it's not sat waiting for someone else?
[12:08] <stub> Yup. Just taking its sweet time because that table has triggers on it
[12:08] <Kinnison> heh
[12:09] <stub> And aide.real chewing away on the box isn't helping either (thats some sort of security checker, isn't it?)
[12:09] <Kinnison> yeah
[12:09] <Kinnison> intrusion detection
[12:11] <stub> Looks like the librarian disk updates have worked
[12:11] <Kinnison> excellent
[12:12] <mpt_> popes, emperors, and aides
[12:12] <mpt_> and librarians
[12:14] <stub> and a bishop
[12:14] <Kinnison> the baby eating bishop of bath and wells
[12:15] <stub> Grrrr.. hurry up... I'm hungry!
[12:16] <Kinnison> stub: bored now
[12:17] <matsubara> hey mpt_, thanks for contributing on the LaunchpadBugTriage wiki. 
[12:17] <stub> Have to remember to disable that trigger next time we add a column to Person... this sucks :-(
[12:18] <SteveA> stub: which trigger is that?
[12:18] <mpt_> matsubara, thanks for fixing lots of bugs!
[12:18] <SteveA> the one to maintain the virtual table for person vocabs?
[12:18] <stub> SteveA: Yup. The only reason for this taking this long.
[12:22] <sivang> matsubara: there's a LaunchpadBugTriage special wiki? 
[12:23] <stub> yay.
[12:23] <matsubara> sivang: https://wiki.launchpad.canonical.com/LaunchpadBugTriage
[12:23] <stub> schema update done.
[12:23] <cprov> mpt_: ping, do you have time to discuss a bit of "+builds cleanup" ?
[12:24] <stub> fti indexes refreshed
[12:24] <stub> permissions rebuild
[12:24] <Kinnison> so are we back?
[12:25] <stub> db back online.
[12:25] <stub> librarian config needs tweaking... bah.
[12:26] <Kinnison> yell when db and librarian are both up and I'll test ready to reenable ftpmaster
[12:28] <stub> librarian back online
[12:28] <stub> Kinnison: Go for it
[12:28] <Kinnison> stub: coolio
[12:29] <stub> Launchpad is back online
[12:29] <stub> That should be everything
[12:30] <mpt_> cprov, my +builds branch is up for review at the moment
[12:31] <cprov> mpt_: do you think it covers the last developers request ?
[12:31] <cprov> mpt_: cleaner and wide page layout, most of them.
[12:32] <mpt_> cprov, no
[12:32] <mpt_> That requires a higher authority
[12:32] <cprov> mpt_: ehe, how do you mean ?
[12:33] <mpt_> as in, it's not the sort of thing I can fix in the short term
[12:33] <mpt_> long term there are many pages which should have a wider layout, +builds being one of them
[12:35] <cprov> mpt_: ok, it makes sense, I'm looking forward to get it branch in RF, thank you
[12:35] <Kinnison> it's all good
[12:44] <niemeyer> Good morning!
[12:45] <cprov> well done, guys, prodution looks perfect again
[12:46] <Kinnison> cprov: thanks for your work on the UI
[12:47] <ogra> cprov, thanks for changing the order to "newest on top" ... was a bit painful to get to the last page to see the recent builds :)
[12:48] <cprov> Kinnison: my job anyway, thank you, stub and Znarl for driving the process vey well
[12:49] <cprov> ogra: you're welcome to enjoy the Soyuz pages, file bugs, make it your home ;)
[12:50] <Riddell> please disable account https://launchpad.net/people/niggerplz which has been adding wiki spam to FirefoxNewVersion
[12:50] <ogra> will do :)
[12:50] <ogra> Riddell, lets put it on the CC agenda to have a proper process ... i guess we'll face this more often in the future ...
[12:51] <Riddell> that's unnecessary burocracy
[12:53] <ogra> hmm ...
[12:53] <stub> I can disable it, but it isn't as if they can't just create a new account to annoy us with
[12:54] <Kamion> ogra: the CC is entirely uninterested in dealing with this
[12:54] <ogra> Kamion, oki
[12:55] <Kamion> spammers are obvious and can clearly be dealt with by admins rather than having to wait two freaking weeks for a CC meeting every time
[12:56] <ogra> Kamion, i dont want to bring it up on every meeting ... but it would be nice to have a definition from which point on we consider someone harmful ...
[12:56] <SteveA> Kamion: would it be CC business if the user had signed the CoC ?
[12:56] <ogra> i.e. my spam definition might differ from yours ...
[12:56] <Kamion> ogra: *shrug* it passes beneath my "don't care" threshold right now, and I think really it's obvious most of the time
[12:57] <Kamion> SteveA: no, but if they were an Ubuntu member then it would be
[12:57] <ogra> also who can request deletion of launchpad accounts ...
[12:57] <daf> SteveA: hmm, I would expect a .txt file about using configuration files
[12:57] <stub> Riddell: deactivated for what that means
[12:57] <daf> SteveA: i.e. the LP config file
[12:58] <SteveA> stub: interesting... http://dodgeit.com/run/checkmail?mailbox=niggerplz
[12:58] <SteveA> stub: we might want to ban dodgeit.com mail addresses from the signup process
[12:59] <stub> ogra: Requests like that should go to the launchpad@lists.ubuntu.com list, and I'll handle them. We can work out UI and processes if certain requests become too common
[12:59] <stub> SteveA: Sure. There are several domains like that.
[12:59] <SteveA> daf: there is a .txt file about it i think.  launchpad/configs/README.txt
[12:59] <daf> ah
[12:59] <daf> http://bugmenot.com/view.php?url=launchpad.net
[01:00] <ogra> stub, but by which value do you judge if the request is valid ? 
[01:00] <stub> SteveA: Create a bug please, and I'll add the other domains I'm aware of to the list
[01:00] <ogra> (apart from coming from a canonical employee)
[01:00] <stub> ogra: The reason a trusted user gives for the action.
[01:01] <SteveA> stub: ok
[01:01] <daf> SteveA: I mean from a code point of view
[01:02] <daf> canonical.config contains doctests
[01:02] <SteveA> daf: this is infrastructural stuff maintained mainly by stub and other infrastructure people.  i don't think we need to change it right now
[01:03] <salgado> cprov, will you ping me when you have some time to work on MirrorManagement?
[01:03] <cprov> salgado: give some min, also need your help in some regexp, 10 min ok ?
[01:03] <daf> SteveA: sure -- once I found the tests, it was clear how to use it
[01:03] <salgado> cprov, sure
[01:04] <SteveA> daf: by all means, add a pointer to them in the standard system doc directory
[01:05] <daf> ok
[01:05] <carlos> SteveA: Hi, Do you have sometime to talk about bug #4814 ?
[01:05] <SteveA> stub: adding subscriber is taking a long time
[01:06] <SteveA> stub: like 10s
[01:06] <carlos> SteveA: https://launchpad.net/products/rosetta/+bug/4814
[01:06] <SteveA> https://launchpad.net/products/launchpad/+bug/30722  <-- for anon mail boxes
[01:08] <SteveA> carlos: i'd rather not do work on that right now.  i want to land some security fixes first.  is it urgent for you?
[01:08] <carlos> SteveA: do we have the infrastructure to implement it?
[01:08] <SteveA> not yet
[01:09] <carlos> SteveA: spiv asked me to stop using that way to check the security in other parts of Rosetta as part of one review he just did for me
[01:09] <carlos> SteveA: Ok, I thought it was a matter of teach me how to do that, I will note that to spiv
[01:09] <carlos> SteveA: it's not urgent but interesting to simplify a bit our code and tests
[01:10] <SteveA> i agree, carlos
[01:10] <carlos> ok
[01:10] <carlos> SteveA: thanks
[01:10] <SteveA> we shall make this simpler, but not today.  i need to improve the infrastructure first
[01:11] <carlos> I will note that on the bug report as I thought the infrastructure was already there
[01:19] <daf> is person.hasTeamParticipation(team) the standard way to ask "is person X a member of team Y"?
[01:20] <daf> it seems to me it wouldn't check whether the membership is active or not
[01:20] <stub> The TeamParticipation table is a cache - there shouldn't be inactive memberships in it
[01:21] <daf> ok, so that's the correct thing to do?
[01:22] <daf> I suppose 'team in person.teams_participated_in' would be the other way
[01:22] <stub> Dunno the current preferred spelling :-) security.py code should have examples of the preferred spelling
[01:22] <stub> daf: That would be very inneficient
[01:22] <daf> c.l.security.py?
[01:23] <daf> hmm, that uses user.inTeam
[01:23] <daf> I'll use that
[01:25] <SteveA> yes
[01:25] <SteveA> that's the public API for checking team membership
[01:25] <SteveA> daf: also, see the error page view code
[01:26] <SteveA> daf: this shows how we check whether the logged in user is a launchpad developer.
[01:26] <daf> good idea
[01:26] <SteveA> daf:         self.specialuser = getUtility(ILaunchBag).developer
[01:27] <SteveA> webapp/error.py
[01:27] <SteveA> the advantage here is that this is checked once per request
[01:27] <SteveA> not once per paragraph-of-text
[01:27] <daf> lovely
[01:28] <daf> you're suggesting add a similar attribute to FormattersAPI?
[01:28] <SteveA> no
[01:29] <daf> hmm, no, that's instantiated each time
[01:29] <SteveA> i'm suggesting that the Formatters thing checks the launchbag
[01:29] <SteveA> to see if the logged in user is a developer
[01:29] <daf> oh
[01:29] <daf> misread that code
[01:29] <SteveA> and, it can do that as often as it likes
[01:39] <daf> stub: if I add a new required configuration option, do I then need to update all the config files by hand?
[01:40] <daf> stub: i.e. there's no inheritence mechanism and there's no way of propagating things automatically
[01:40] <stub> daf: Update staging's config. I prefer to do the production configs myself.
[01:41] <daf> ok
[01:41] <stub> daf: No inheritence mechanism, which sucks but is working well enough for noone to bother improving.
[01:41] <daf> it's justthat the test runner is complaining about missing required valud
[01:41] <stub> Need to add the options to the testrunner section of default/launchpad.conf
[01:42] <daf> ah
[01:43] <elmo> I'm getting timeouts on things like: https://launchpad.net/distros/ubuntu/dapper/+source/klogic/+pots/klogic/en_GB/+translate
[01:44] <elmo> reproducably
[01:44] <SteveA> elmo: got an oops code?
[01:44] <elmo> OOPS-38C229
[01:45] <SteveA> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-07/C229
[01:45] <SteveA> but we'll have to wait for it to rsync
[01:46] <elmo> ok, it's not actually, like, important to me, it just seemed a kind of basic page to be timeouting, so I wanted to whine in case it was part of a more generic problem
[01:46] <SteveA> the translation pages are a big problem
[01:46] <elmo> ah, ok
[01:47] <SteveA> i'm interested to see what exactly was being slow
[01:47] <kiko> hello there
[01:47] <SteveA> elmo: you can do so too: https://chinstrap.ubuntu.com/~jamesh/oops.cgi, enter the oops code there
[01:48] <elmo> SteveA: remind me why we do this on chinstrap rather than the apps servers themselves?
[01:48] <SteveA> i guess we need to wait another 2 mins
[01:48] <SteveA> elmo: on what app server would it run?
[01:48] <SteveA> do we want to rsync between app servers?
[01:48] <elmo> well, both, so you'd have to try it on two boxes
[01:48] <SteveA> right now, there is no data we need to keep on an app server
[01:48] <elmo> ah, I suppose there is that
[01:48] <SteveA> but we certainly want to keep oops reports
[01:48] <elmo> it's just the log rsync is kind of expensive is all
[01:48] <elmo> but if it's data we want to keep, fair enough
[01:48] <SteveA> we have analysis scripts that analyze the day's data
[01:49] <SteveA> and the week's oops data
[01:49] <SteveA> so we need all the reports in one place
[01:49] <kiko> I've considered that as well, but we'd either need shared storage or an rsync
[01:49] <SteveA> so, no need for it to be chinstrap as such
[01:49] <elmo> (but getting you guys a box of your own just moved up my todo list :p)
[01:49] <SteveA> but it needs to be a backed-up machine that developers only have access to that we can run scripts and cgis on
[01:51] <stub> elmo: The log rsync can be optimized by only syncing todays and yesterdays directories, and we can rotate the .logs more often
[01:52] <SteveA> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-07/C229  <-- the last statement took ages
[01:52] <daf> using -u might help if we're not already
[01:53] <kiko> YES
[01:53] <kiko> YES
[01:53] <kiko> YES!
[01:54] <kiko> librarian build logs are now viewable through the browser!
[01:54] <kiko> the end of the 5 dialogs of hell!
[01:55] <kiko> cprov, are you doing any UI work or can I help fix +build to link to the right binary?
[01:55] <SteveA> stub: we could also prune the old logs that are on the app servers
[01:56] <cprov> kiko: +build ? isn't it already fixed ? yes, you can 
[01:56] <cprov> kiko: I have bug 30621 partially fixed and i'm helping salgado with MirrorManangement
[01:56] <Ubugtu> malone bug 30621 in soyuz "glibc changelog seems to list two versions and have eaten a line for the changelog" [Major,Confirmed]  http://launchpad.net/bugs/30621
[01:57] <kiko> cprov, cool, thanks.
[02:02] <daf> elmo: there is a bug open on that OOPS
[02:02] <daf> elmo: thanks for mentioning it, though
[02:02] <elmo> clearly, what we need is turing complete system that analyzes the oops when it happens and jumps you to the malone bug if it's known
[02:03] <elmo> but until then, daf will do ;-)
[02:03] <daf> good idea
[02:03] <daf> :)
[02:03] <daf> I can then be reconfigured to work on another non-turing-complete task
[02:06] <kiko> okay let me fix these ridiculous broken links
[02:07] <kiko> hey BjornT 
[02:07] <Keybuk> ugh
[02:07] <Keybuk> where did the dapper "pybaz" package come from?!
[02:08] <kiko> you lack of faith is disturbing
[02:08] <elmo> Keybuk: how do you mean?
[02:08] <Keybuk> elmo: it conflicts with my python2.4-bazaar package
[02:08] <elmo> Keybuk: oh, well it comes from Debian
[02:09] <Keybuk> ah, the source of all that is good, evil, misguided and strange
[02:09] <elmo> it just hadn't built before 'cos python was broken
[02:09] <elmo> then python got fixed, we switched to soyuz and the build got retried
[02:09] <BjornT> hi kiko 
[02:09] <kiko> bradb, BjornT: let's talk bug 3796?
[02:09] <Ubugtu> malone bug 3796 in malone "Duplicated bugs still show up as New in a list of bugs (also affects the Latest bugs portlet)" [Normal,Confirmed]  http://launchpad.net/bugs/3796
[02:11] <bradb> kiko: Sure.
[02:12] <kiko> we discussed at some point making status be a property. how do you guys feel about that a few months down the road?
[02:13] <raphink> hi
[02:13] <raphink> I need some help
[02:13] <raphink> ;)
[02:13] <bradb> kiko: Sounds like the right idea to me.
[02:13] <raphink> my launchpad page has been bugged for a few days now
[02:13] <raphink> https://launchpad.net/people/raphink
[02:13] <raphink> I've filed a bug for that
[02:13] <raphink> assigned to jamesh 
[02:13] <raphink> is there a way this can be fixed in the db before fixing the bug more widely?
[02:14] <raphink> I kind of need my LP page to work :s
[02:14] <daf> raphink: what's the bug number?
[02:14] <raphink> daf: wait I'll find it
[02:14] <BjornT> kiko: yeah, i think a property would be a quite good idea. it's a rather easy fix, and it makes it clear that bug is a duplicate.
[02:14] <raphink> https://launchpad.net/products/launchpad/+bug/30316 daf 
[02:14] <Ubugtu> malone bug 30316 in launchpad "Launchpad Developer page won't load" [Normal,Confirmed]  
[02:15] <raphink> I guess apart from the bug in LP, there might be something in the db that have my page fail to load
[02:15] <raphink> I think it's linked to the calendar
[02:15] <kiko> BjornT, bradb: would any of you have time free to implement the change (i.e. not ruining your current priorities) or should I try and get someone else to do it?
[02:15] <raphink> so maybe my calendar stuff can be nuked in the db
[02:16] <daf> oh, right, I remember now
[02:16] <bradb> kiko: Over the next few months, sure.
[02:16] <BjornT> kiko: i don't think i'll have time to do it
[02:16] <raphink> daf: do you think something can be done?
[02:16] <kiko> next few months? it will be christmas by then!
[02:17] <raphink> lol
[02:17] <daf> raphink: hmm
[02:17] <bradb> kiko: Well, you said "how do you guys feel about that a few months down the road?" :)
[02:17] <daf> raphink: I don't understand the problem well enough, really
[02:17] <daf> jamesh: are you around?
[02:17] <kiko> bradb, a few months down the road from when WE DISCUSSED IT!
[02:17] <raphink> daf: well I have stuff in my calendar (which are passed though) that seem to make LP crash on my page
[02:17] <BjornT> kiko: yeah, within a few months i could implement it as well, but i was talking about the near future :)
[02:17] <bradb> kiko: oh, heh
[02:18] <raphink> daf: so if the bug can't be fixed fast enough in LP, maybe the calendar entries could be nuked from my profile
[02:18] <kiko> heh
[02:18] <bradb> kiko: I'm focussed on making bug listings not look like poop, so I don't have much time to do it RFN.
[02:18] <kiko> BjornT, do you think you could outline in the relevant bug a plan to fix it? that shouldn't take too long
[02:18] <kiko> bradb, that's fine
[02:19] <BjornT> kiko: sure, i'll do that today or tomorrow
[02:19] <kiko> thanks man
[02:20] <kiko> I will find a champion for that feature!
[02:20] <raphink> daf: I've tried to ping jamesh but he didn't answer :s
[02:20] <kiko> raphink, that's because some of us actually sleep sometimes :-P
[02:20] <raphink> kiko: I tried yesterday, and 2 day ago
[02:20] <raphink> kiko: I happent to sleep sometimes too ;)
[02:20] <kiko> in that case you should escalate the matter to SteveA 
[02:21] <daf> it is a nasty bug
[02:21] <raphink> I've seen other pages fail like mine around on LP
[02:21] <raphink> not a lot, since few people use the calendar
[02:21] <raphink> but still
[02:21] <raphink> the feature is there, and it crashes
[02:21] <daf> a better temporary solution in my opinion would be removign the calendar portlet from the person page
[02:22] <raphink> that's what I asked daf , as a temporary solution
[02:22] <raphink> daf: just so I can access my page :s
[02:22] <daf> I mean that I suggest that rather than deleting stuff from the DB
[02:22] <daf> kiko: what do you think?
[02:23] <raphink> hmm
[02:24] <kiko> I have a biased opinion on the calendar.
[02:24] <kiko> (I personally think it is of very limited usefulness)
[02:25] <daf> well, currently it's breaking other stuff
[02:27] <raphink> I just wanted to try the feature for fun
[02:27] <raphink> and it broke my page
[02:27] <raphink> so I hvae more than a biased opinion on it ;)
[02:27] <kiko> can we band-aid it?
[02:27] <raphink> I can't
[02:27] <raphink> closed source :p
[02:28] <kiko> shucks, you're right!
[02:28] <daf> kiko: my band aid is to remove the portlet from the person page
[02:29] <kiko> that is a rather drastic bandaid
[02:29] <daf> you said it is of very limited usefulness a minute ago :)
[02:30] <kiko> matsubara, can you keep an eye on bug 3796? if BjornT's plan isn't rocket science we might be able to pull it off in the 3rd world
[02:30] <Ubugtu> malone bug 3796 in malone "Duplicated bugs still show up as New in a list of bugs (also affects the Latest bugs portlet)" [Normal,Confirmed]  http://launchpad.net/bugs/3796
[02:30] <carlos> see you later
[02:31] <raphink> hm
[02:31] <raphink> I'm trying to access my calendar manually and remove the entries
[02:31] <raphink> might work
[02:31] <raphink> can't nuke events in the calendar!
[02:31] <matsubara> kiko: I'll take a look at it.
[02:31] <raphink> there's no option for it
[02:32] <daf> raphink: what page are you looking at now?
[02:32] <raphink> daf: I went to launchpad.net/people/raphink/+calendar manually
[02:33] <raphink> and am trying to change some stuff see if I can fix 
[02:33] <matsubara> kiko: what BjornT's been planning?
[02:34] <raphink> daf: seems the cal doesn' tlike stuff on several days
[02:34] <matsubara> kiko: nm. found out on the comments.
[02:34] <daf> https://launchpad.net/people/raphink/+calendar/events/798/+display
[02:34] <raphink> daf: changed the meeting to 1 minute long instead of 2 days, and it fixed it
[02:34] <raphink> lol
[02:34] <daf> ha
[02:34] <raphink> just doesn't like events lasting several days
[02:34] <daf> something like that
[02:34] <raphink> I'll update the bug with this info
[02:35] <daf> thanks!
[02:35] <daf> I was just about to ask you to do that :)
[02:35] <raphink> hehe ;)
[02:37] <raphink> daf: https://launchpad.net/products/launchpad/+bug/30316 clear enough?
[02:37] <Ubugtu> malone bug 30316 in launchpad "Launchpad Developer page won't load" [Normal,Confirmed]  
[02:39] <daf> raphink: looks good
[02:39] <raphink> daf: hope it helps fixing :)
[02:39] <daf> raphink: perhaps file a separate bug on not being able to delete events?
[02:39] <raphink> at leats my page works now
[02:39] <daf> yeah, I'm glad you found a workaround
[02:40] <daf> stub: it seems that when you use login(), LaunchBag.developer doesn't get updated
[02:41] <raphink> mhm
[02:45] <mdz> bradb: OOPS-38B317
[02:46] <bradb> mdz: I can't see that OOPS yet. What happened?
[02:46] <kiko> bradb, you can see it in 5 minutes.
[02:46] <bradb> yeah
[02:47] <mdz> bradb: timeout
[02:47] <mdz>  /+addsubscriber
[02:47] <mdz> the usual people selector timeout, I assume, but you did ask me yesterday
[02:48] <bradb> salgado: There are more people vocab optimizations on the way, right?
[02:53] <kiko> BjornT, tell me about your current work on watches?
[02:53] <salgado> bradb, no, everything's on production already. and that OOPS-38B317 was caused by contention, because I just tried it here and it run pretty fast
[02:53] <kiko> contention caused by what, I would like to know.
[02:54] <kiko> stub, is it possible to find out what queries lock what tables the most?
[02:54] <salgado> me too
[02:54] <kiko> perhaps a statistic of queries holding locks over time?
[02:54] <kiko> as in: this query held a lock on the person table for more than 5 seconds 381 times
[02:54] <kiko> etc
[02:56] <BjornT> kiko: https://wiki.launchpad.canonical.com/BugWatches should give a pretty good description. i've started to implement it, and will fill in the implementation part of the spec soon.
[02:57] <kiko> great
[02:57] <kiko> is there anything I can do to help you out?
[02:59] <BjornT> kiko: no, not at the moment. or maybe one thing, do you see any reason not to add 'Launchpad Usage' flags to distributions? currently only products can define whether they use malone or rosetta officially.
[03:00] <kiko> BjornT, I don't think we plan/planned on having multiple distributions any time soon
[03:00] <kiko> so I am not sure that's a priority. it is definitely useful if we find out distributions choose not to use our services
[03:00] <kiko> but being derivatives, it might make sense to.
[03:00] <kiko> are you talking about non-derivative distributions registered?
[03:00] <BjornT> kiko: well we alrady have debian and ubuntu, one usese malone, the other not.
[03:01] <kiko> I see your point.
[03:01] <BjornT> they other way would be to special case debian and assume that everyone else uses malone
[03:01] <BjornT> although by the looks of it, nexenta seems to have their own bug tracker
[03:02] <kiko> I have a bad feeling about that, so perhaps the flag is a good idea.
[03:02] <kiko> are you interested in piggybacking it on your work?
[03:03] <BjornT> yes, it makes sense for me to add it, since i want to use the flags
[03:03] <kiko> then if you think it makes sense, I can only support your effort. 
[03:03] <BjornT> cool
[03:08] <kiko> daf, you need to talk to be about this malone change that takes a month to produce, I want to know what sort of rocket science is involved in it!
[03:08] <kiko> is there anything I can do to help there?
[03:08] <cprov> SteveA: I'm leaving now, could you please take care of any requests for me ?
[03:08] <kiko> as in, mail me or ask me tomorrow, cprov? I think I can do that. :)
[03:08] <kiko> talk to be? daf I meant talk to ME!
[03:09] <daf> kiko: yo
[03:09] <kiko> yo ^5er
[03:09] <daf> kiko: I've been busy with other things
[03:09] <daf> I need to get a clean diff against RF so that the bradster can look at it
[03:09] <kiko> aha. so why not prop up what you have for review?
[03:10] <daf> I did, but Brad got conflits
[03:10] <kiko> conflicts are a normal part of life, but they are usually solvable
[03:10] <kiko> how about you get that up so we can land these changes this week?
[03:10] <seb128> grumpf
[03:11] <kiko> the other thing is that bradb can review your code even if conflicted
[03:11] <kiko> it only requires looking at a diff in principle
[03:11] <daf> well, that's what I thought :)
[03:11] <seb128> seems that http://bugzilla.ubuntu.com/show_bug.cgi?id=20183 has not been imported with the migration
[03:11] <Ubugtu> ubuntu bug 20183 in firefox "firefox 1.4.99 upgrade still have compreg.dat, creates issue" [Normal,Needinfo]  
[03:11] <kiko> daf, I agree. what should we do?
[03:11] <seb128> do you have an import feature or something like that to import it now?
[03:12] <kiko> seb128, yes, it is a trivial thing, but it will help if you email jamesh CC: launchpad-users, launchpad
[03:12] <seb128> why the Cc on the users list?
[03:12] <daf> kiko: I can merge RF and give Brad a new diff
[03:13] <kiko> so other people that have the same problem may feel motivated to speak up?
[03:13] <kiko> daf, that sounds like an excellent plan!
[03:13] <seb128> k
[03:13] <kiko> daf, i know this is going to reflect poorly on me, but remind me, what does your patch do? :)
[03:14] <kiko> is it bug 6572?
[03:14] <Ubugtu> malone bug 6572 in malone "In distribution bug searches, it should be possible to filter out bugs with upstream tasks" [Normal,Confirmed]  http://launchpad.net/bugs/6572
[03:14] <daf> yes
[03:14] <kiko> oh I so love that answer
[03:14] <bradb> kiko: When I review, I start by looking at the UI.
[03:15] <kiko> bradb, that is fine. you can start by reading the diff when the UI is momentarily unviewable, however.
[03:15] <kiko> that will make sure everybody's time is optimized.
[03:15] <kiko> (and in the bigger picture, every time you bounce something back to someone without doing at least some work on it, it costs us all -- avoid the roundtrip if you can)
[03:15] <kiko> said with the best possible intentions
[03:16] <kiko> daf, I am going to use this cool Malone feature, "assign task", to keep track of that bug. do you approve?
[03:17] <kiko> BjornT, I might like to talk to you on the phone today, would you have some time  free?
[03:18] <daf> kiko: let's give it a whirl
[03:18] <BjornT> kiko: sure. you could call me in 10 minutes if you want
[03:19] <daf> Seveas: if you haven't switched Ubugtu over yet, the new bug export interface is live
[03:19] <Seveas> daf, I'll make the switch :)
[03:19] <daf> cool
[03:20] <salgado> hey bradb, that new +packagebugs page looks really nice. 
[03:20] <kiko> daf, it works!
[03:20] <bradb> salgado: Thanks.
[03:20] <salgado> bradb, how much work do you think it is to use that same layout in the other reports?
[03:21] <daf> kiko: golly
[03:21] <bradb> salgado: The plan is to standardize it into macros once I've completed the experience. Right now, I'm working on the advanced search page.
[03:22] <salgado> ah, right. I thought that code was in macros already
[03:22] <Seveas> bug 1111
[03:22] <Ubugtu> malone bug 1111 in gst-plugins0.8 "doesn't extract last track" [Normal,Fix released]  http://launchpad.net/bugs/1111
[03:22] <Seveas> new code is live :)
[03:22] <daf> bug 1
[03:22] <Ubugtu> malone bug 1 in Ubun "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
[03:22] <daf> awesome
[03:22] <daf> is it me, or is it faster now?
[03:23] <kiko> mmmm
[03:23] <kiko> +packagebugs is interesting.
[03:23] <bradb> I know what "interesting" means :)
[03:23] <kiko> it has Open, Critical, Unassigned and In progress.
[03:23] <kiko> Critical there is a bit confusing to me.
[03:24] <Kamion> "Ubun"?
[03:24] <bradb> kiko: Why's that?
[03:24] <kiko> I am not sure if it is critical and open, critical and unassigned, critical and in progress...
[03:24] <Seveas> btw: /+text only works on launchpad.net/bugs/1/+text, not on https://launchpad.net/distros/ubuntu/+bug/1/+text
[03:24] <Ubugtu> malone bug 1 in Ubun "Microsoft has a majority market share" [Critical,Confirmed]  
[03:24] <kiko> it does not fit well in my mental model of status.
[03:25] <kiko> I like the feature, just confused by that column
[03:25] <kiko> oh
[03:26] <kiko> wow
[03:26] <bradb> BOOM
[03:26] <kiko> why did you keep navigation to the right?
[03:26] <daf> Seveas: true -- I could make that show the task if you really want
[03:26] <kiko> also
[03:26] <kiko> there could be bullet items in the "Other packages" portlet
[03:26] <kiko> it is currently a bit mishmashed
[03:26] <bradb> kiko: Because that's where the prototype showed it to be.
[03:26] <kiko> should be an easy fix
[03:26] <kiko> mmmm
[03:27] <Seveas> daf, I don't need it, I just noticed :)
[03:27] <bradb> Yeah, the packages are already marked up as a list.
[03:27] <Seveas> @reload bugtracker
[03:27] <Seveas> bug 1
[03:27] <Ubugtu> malone bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
[03:27] <kiko> I think keeping navigation to the right is a better strategy..
[03:27] <kiko> errr
[03:27] <kiko> to the left..
[03:27] <Seveas> Kamion, it's called Ubuntu again :)
[03:27] <bradb> kiko: Er, not "navigation", per se, but the actions menu.
[03:27] <bradb> I dropped the sitemap portlet, because that thing makes no sense to me.
[03:27] <kiko> I am actually trying to say that if a 2-column layout is adopted, we should put the portlets on the left.
[03:28] <kiko> the main reason for that is that it avoids layout bugs with unwrapped text.
[03:28] <Kamion> the search results on +packagebugs are really weird
[03:28] <kiko> (which will happen often with tables and links in narrower windows than 1280x1024)
[03:28] <Kamion> base-config in ubuntu    0    1    0    0
[03:28] <kiko> as I said
[03:28] <kiko> critical is weird.
[03:28] <ddaa> kiko++++++++
[03:29] <bradb> kiko: Sure, I don't mind putting it on the left.
[03:29] <kiko> I also didn't quite expect that report to be the first page
[03:29] <kiko> I think the individual per-package reports are outstanding
[03:29] <Kamion> kiko: more than just what you said; Open=0 Critical=1 makes no sense at all
[03:29] <kiko> but they are a bit hidden -- we could perhaps find a way to have a good default view and allow the user to choose later.
[03:29] <kiko> Kamion, it sort of does if it is critical and fixed. :)
[03:30] <bradb> Hm, those were intended to be Critical and Open. Must be a bug.
[03:30] <bradb> And I was planning on making the space above that table look a little less uninspiring. Not yet sure how.
[03:31] <kiko> daf, seb128: in bug 6572, should the bug summary be altered to "open upstream tasks" instead of just "upstream tasks"?
[03:31] <Ubugtu> Error: I tried to send you an empty message.
[03:31] <daf> kiko: yes
[03:31] <kiko> bradb, would there be a sensible default view?
[03:31] <bradb> I could do an even better +packagebugs table with a two-column layout, actually.
[03:31] <kiko> thank you daf.
[03:31] <daf> kiko: except that open doesn't include needsinfo (suck)
[03:32] <kiko> ah.
[03:32] <daf> kiko: but that's a different story
[03:33] <bradb> kiko: I thought a sensible default view was to give the user an overview of all the packages they're involved in. What do you think a better default view approach would be?
[03:33] <kiko> daf, what else has been going on in your world?
[03:33] <seb128> kiko: right,"open" makes sense for it :)
[03:33] <daf> kiko: meeting summary, linkification of oopses, sql results test case, test cases for optional branch title, people and users spec
[03:34] <kiko> bradb, I think offering a menu of choices is kind of 80s UI, we could probably offer him the bugs in packages with most bugs, or the package he last looked at, or something smarter
[03:34] <daf> (oh, and bug triage / bug triage tools / bug text pages)
[03:35] <kiko> bradb, a bit of handwaving there but I hope you see what I mean
[03:35] <kiko> daf, ah, you're working on linking to oops.cgi? how's that?
[03:35] <daf> kiko: done
[03:36] <daf> there's some ugliness in the test cases
[03:36] <bradb> Hm, worth pondering. I'm not sure I agree yet that that's a better approach. But I don't necessarily disagree either. (I love being vague.)
[03:38] <kiko> daf, how does it work?
[03:38] <bradb> kiko: What about, say, showing the most critical bugs assigned to you on the packages you're interested in?
[03:38] <bradb> (by default, i mean)
[03:38] <daf> kiko: extends fmt:text-to-html
[03:38] <bradb> With links to an overview and other packages from there.
[03:38] <kiko> bradb, perhaps the distro team would be a good source of suggestions
[03:38] <kiko> daf, ah, sweet
[03:38] <bradb> true
[03:39] <daf> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileJXft15.html
[03:40] <kiko> I like the indentation fix
[03:40] <daf> 'twas a tab
[03:41] <kiko> daf, the tests look fine to me.
[03:42] <daf> I don't like this setDevelore stuff
[03:42] <daf> setDeveloper
[03:42] <kiko> daf, I don't care about that /at all/
[03:42] <daf> I think login() should be updating that
[03:42] <Kamion> +packagebugs is certainly a lot better (in terms of actually being able to get at the information) than anything we had before; my main issue with the current interface is that actually doing a bug triage session involves dozens of extra clicks to get at the actual bug lists
[03:42] <kiko> you could update sampledata how...
[03:42] <daf> you think it's a sampledata thing?
[03:42] <kiko> daf, ah. so test@canonical.com is a launchpad developer already?
[03:42] <daf> yeah
[03:43] <kiko> that is an infra bug
[03:43] <kiko> file it and XXX it
[03:43] <kiko> do you want review on that code?
[03:43] <daf> yes
[03:43] <kiko> one moment then
[03:43] <daf> please
[03:43] <kiko> why two entries in launchpad.conf?
[03:43] <daf> one for default, one for testrunner
[03:44] <kiko> okay.
[03:44] <daf> duplication is evil
[03:44] <daf> stub says it's not too bad in this case
[03:44] <daf> and there's nobody to work on some funky inheritance thing
[03:44] <kiko> I guess it's okay.
[03:44] <kiko> there are bigger fish to fry
[03:44] <daf> yeah
[03:45] <daf> well, it's not me that has to update the 5 production configs, so I can't complain
[03:45] <kiko> I can't sign off on the regexp, but if it works r=kiko.
[03:45] <bradb> Kamion: You're not alone: https://wiki.launchpad.canonical.com/MatthewPaulThomas/DesignProblems (mpt kicks ass)
[03:45] <daf> kiko: that's what tests are for :)
[03:45] <bradb> We've been collecting evidence of the clickable problem. Point #2.
[03:45] <daf> bradb: https://chinstrap.ubuntu.com/~dsilvers/paste/file9YxTQc.html
[03:45] <kiko> regexps are tricky to test completely
[03:46] <daf> true
[03:46] <daf> but we can add regression tests if it goes wacky
[03:46] <bradb> s/clickable/clickage/
[03:46] <bradb> daf: Thanks, looking now...
[03:46] <kiko> BjornT, is bug 6667 part of this work, or futured?
[03:46] <Ubugtu> Error: I tried to send you an empty message.
[03:47] <kiko> daf, agreed. fine with your patch, looks nice.
[03:47] <daf> Seveas: did you see that?
[03:47] <daf> kiko: thanks
[03:47] <Kamion> bradb: my offhand suggestion would be to expand out the bug lists inline in that table
[03:47] <Kamion> (but what do I know)
[03:47] <kiko> Kamion, can you clarify?
[03:48] <BjornT> kiko: a fix for bug 6667 is in the review queue already
[03:48] <Ubugtu> Error: I tried to send you an empty message.
[03:48] <Kamion> kiko: under each package in the enormous table https://launchpad.net/people/kamion/+packagebugs, I'd like to see a list of the open bugs there so that it doesn't take 84 clicks to get at all my bugs
[03:50] <bradb> Kamion: Your idea seems sound to me. We are wrestling against the performance constraint to gradually (hopefully?) provide pages showing you as many bugs as you want to see.
[03:51] <bradb> The ultra-conservative 20 bugs per page seems really fast on staging.
[03:51] <Kamion> performance> understood
[03:51] <bradb> Today, I can make batch size a config file option.
[03:51] <bradb> To give stub a knob to play with, so to speak.
[03:54] <jbailey> Oh, hey.  My launchpad is still logged in.  Thanks for that. =)
[03:54] <bradb> jbailey: I think sessions expire after 60 days now.
[03:54] <jbailey> bradb: Cool.
[03:55] <daf> if non-explicit logouts occur, they're probably bugs
[03:55] <jbailey> I'm trying to understand the relationship between assigned bugs and subscribed to bugs.  I'm apparnetly subscribed to 300 odd bugs, which I need to reduce to a set of bugs that I actually care about.
[03:56] <jbailey> I seem to be subscribed to bugs that I reported, and I think I may be subscribed to bugs that are assigned to me.
[03:56] <bradb> jbailey: Define "bugs that I actually care about".
[03:57] <jbailey> bradb: I'm not on the distro team, but still hack on Ubuntu occasionally.  There used to be a wider scope of things that I'd follow than I do now, and I want to reduce my bug list to that set.
[03:57] <Seveas> @reload bugtracker
[03:57] <Seveas> bug 6667
[03:57] <Ubugtu> malone bug 6667 in malone (upstream) "Make watching GNOME bugs more efficient by doing just one buglist.cgi request" [Normal,In progress]  http://launchpad.net/bugs/6667
[03:57] <jbailey> So since I'm going to touch 300+ bugs, I'd like to do it right the first time. =)
[03:58] <daf> Seveas: cool
[03:58] <bradb> jbailey: Do you want to see only bugs assigned to you?
[03:58] <jbailey> bradb: Should bugs only be assigned to me when I've actually said that I will fix them?
[03:59] <bradb> jbailey: Malone doesn't enforce that constraint one way or the other.
[03:59] <jbailey> bradb: I don't know yet.  I still don't understand the semantics of subscribe to something versus assign to me.
[03:59] <bradb> jbailey: Subscribe == Cc, assign == responsible to fix.
[03:59] <jbailey> Ah, okay.  So this is probably a conversation to ask mdz then to make sure I'm consistant with others on the distro team.
[04:00] <jbailey> bradb: Am I automatically subscribed to bugs when they're assigned to me or when I report them?
[04:00] <jbailey> Or is that a separate mechanism?
[04:00] <daf> bradb: can I search for bugs by whether they're private or not?
[04:00] <bradb> jbailey: You're "implicitly" subscribed to bugs to which you're assigned, i.e., you're not "officially" in the Cc list, but you'll get the bugmail.
[04:01] <jbailey> bradb: Okay, cool.  I seem to have been subscribed to them in the past, but I'll drop that from bugs where I reported them.
[04:01] <bradb> daf: Not currently, though I can make that part of the shiny new Advanced Search UI I'm currently working on.
[04:03] <daf> bradb: cool -- in the meantime, can you think of a private bug off the top of your head?
[04:04] <daf> ah, 5751
[04:05] <daf> I looked in the channel log for a bug Ubugtu couldn't access :)
[04:06] <bradb> heh
[04:09] <Seveas> bug 1, #3, 5751
[04:09] <Ubugtu> malone bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
[04:09] <Ubugtu> malone bug 3 in rosetta "Custom links for each translation team." [Wishlist,Confirmed]  http://launchpad.net/bugs/3
[04:09] <Seveas> -Ubugtu- Error: This bug is private
[04:10] <Seveas> (Yes, ubuntu can now insta-flood any channel :))
[04:10] <Seveas> ubugtu*
[04:13] <jbailey> bradb: https://launchpad.net/distros/ubuntu/+source/glibc/+bug/20893 has a task open for Debian but doesn't seem to have noticed that the remote bug is fixed.  Is this a bug?
[04:13] <Ubugtu> malone bug 20893 in glibc libc6 "Please conflict with libterm-readline-gnu-perl << 1.15-2" [Major,Fix released]  
[04:13] <bradb> jbailey: Basically, yeah. Debian synching doesn't happen right now.
[04:13] <bradb> Known issue.
[04:13] <seb128> is there any syncing happening atm?
[04:14] <bradb> I don't know for sure, but I don't think so.
[04:15] <jbailey> bradb: 'kay, thanks.  And it seems that it correctly doesn't show up in my lists once I unsubscribe from it and resolve the task assigned to me.
[04:15] <jbailey> thanks
[04:15] <bradb> no prob
[04:16] <kiko> BjornT, I think you are a star
[04:16] <bradb> seb128: Right, according to the last comment in bug 6667, we've disabled our checkwatches.py script.
[04:16] <Ubugtu> malone bug 6667 in malone "Make watching GNOME bugs more efficient by doing just one buglist.cgi request" [Normal,In progress]  http://launchpad.net/bugs/6667
[04:17] <seb128> yeah, that's was I thought :)
[04:20] <kiko> seb128, jbailey: look to BjornT to fix the watches code to sync debian too, it's on his plate
[04:20] <jbailey> Mmmm plate.
[04:21] <kiko> indeed that is suggestive
[04:24] <BjornT> seb128, jbailey: even when the fix for 6667 lands, and the watches get updated again, there won't be any real syncing done, though. i'm currently working on that part now, https://wiki.launchpad.canonical.com/BugWatches
[04:26] <seb128> the frame on the right will display the watch status though, no?
[04:28] <BjornT> seb128: yes it should
[04:30] <jbailey> "This bug has not yet been reported in malone (upstream). Do you want to report it?" in 30621. and it has a button that looks like a text box.
[04:30] <jbailey> What does that mean? =)
[04:31] <seb128> jbailey: that your URI has an incorrect part
[04:31] <jbailey> Oops, it seems I didn't hit "stop" fast enough to keep it from sending the request when I discovered that it was a button.
[04:31] <seb128> like https://launchpad.net/distros/ubuntu/+source/pygtk/+bug/28788
[04:31] <Ubugtu> malone bug 28788 in pygtk "Run make check during package build" [Wishlist,Confirmed]  
[04:31] <seb128> it's on pygtk
[04:31] <jbailey> Oh, I see!
[04:31] <seb128> if you replace it by "gedit" it'll say the bug is not on gedit
[04:32] <jbailey> I hadn't noticed that I couldn't just randomly change the bug number in the URL before.  I guess I'd always been within the same package.
[04:32] <jbailey> Thanks. =)
[04:32] <seb128> np :)
[04:34] <bradb> daf: Amazingly, this patch still seems to be in conflict. I guess I'll just review the non-user visible bit of it.
[04:34] <daf> bradb: !!!
[04:34] <daf> wtf
[04:35] <daf> hmm, I'll try that ancestor thing
[04:38] <daf> bradb: does https://chinstrap.ubuntu.com/~dsilvers/paste/fileuq8o7U.html apply cleanly for you?
[04:39] <bradb> daf: Nope.
[04:39] <daf> meh
[04:41] <bradb> bradb@oxygen:~/canonical/malone-batch-size-config-option $ utilities/paste < patch_output 
[04:41] <bradb> Traceback (most recent call last):
[04:41] <bradb>   File "utilities/paste", line 40, in ?
[04:41] <bradb>     form = (('title', sys.argv[1] ), ('content', sys.stdin.read()))
[04:41] <bradb> IndexError: list index out of range
[04:41] <bradb> daf: Shouldn't that Just Work?
[04:41] <daf> give it a title
[04:41] <daf> or fix it to not need one :)
[04:42] <bradb> daf: https://chinstrap.ubuntu.com/~dsilvers/paste/file7VFtSB.html
[04:43] <daf> I don't understand that at allI don't understand
[04:43] <daf> yay irssi
[04:43] <daf> I'll think about it over lunch
[04:44] <bradb> daf: Do you have a few minutes for a real-time review right now?
[04:46] <daf> ok, fire away
[04:46] <bradb> +        self.form_params = form_params
[04:46] <bradb>          form_params.update(getWidgetsData(self, self.search_form_schema))
[04:47] <bradb> Maybe self.form_params could be set after the .update? It seems to read a little weird to assign a local var to an instance var, and then reference the local var again.
[04:47] <bradb> Or even drop the local var.
[04:47] <daf> I guess I could move it later on
[04:48] <daf> yeah, the local var could be dropped
[04:48] <daf> it's just a matter of the local var being shorter within the same function
[04:49] <daf> bradb: ok, I just made a new branch of RF, and my patch applied
[04:49] <daf> bradb: I'm stumped
[04:50] <bradb> Strange.
[04:50] <bradb> +                NOT EXISTS (SELECT * FROM BugTask WHERE BugTask.bug = Bug.id
[04:50] <bradb> +                AND BugTask.product IS NOT NULL)
[04:50] <bradb> You might want to check with stub on if there's a faster way to do that. (e.g. Need it be "SELECT *" instead of, say, "SELECT id"?)
[04:50] <daf> yeah, the SQL is dodgy
[04:51] <bradb> Premature optimization, root of all evil, etc., except that Launchpad's current performance is the root of all evil. :)
[04:51] <daf> heh
[04:51] <bradb> Same with:
[04:51] <bradb> +                EXISTS (SELECT * FROM BugTask WHERE BugTask.bug = Bug.id
[04:51] <bradb> +                AND BugTask.product IS NOT NULL AND BugTask.status IN (%s))
[04:51] <bradb> +                ''' % ', '.join(sqlvalues(*statuses)))
[04:52] <bradb> +    >>> params = BugTaskSearchParams(searchtext="mozilla-firefox", user=None)
[04:52] <bradb> +    >>> params.unfixed_upstream_task = True
[04:52] <bradb> unfixed_upstream_task should be added to the BTSP API
[04:53] <bradb> And passed in as an argument, instead of set as an instance variable after the fact.
[04:53] <bradb> Same with .without_upstream_task
[04:53] <daf> ah, right, makes sense
[04:55] <bradb> daf: Also, it looks like this search API will not show for /distros/ubuntu/+bugs, when it probably should.
[04:55] <bradb> s/search API/search UI/
[04:55] <daf> no, it won't, and yes, it probably should
[04:56] <daf> but you think the approach is sane?
[04:57] <bradb> Yeah, though I'd rename the UI elements. Upstream Status (*) any () fixed () not reported upstream (showing the radio buttons vertically, of course.) What do you think?
[04:58] <jbailey> Interesting.  bug 11685 shows up in my list twice when I'm looking through my subscribed to list by date order: https://launchpad.net/people/jbailey/+subscribedbugs?field.searchtext=&orderby=datecreated&search=Search&batch_start=40&batch_end=60
[04:58] <Ubugtu> malone bug 11685 in glibc "libc6: Bug (+fix) in readdir() due to getdents()" [Normal,Unconfirmed]  http://launchpad.net/bugs/11685
[04:58] <bradb> A little _(what's this?)_ link beside that filter option for extra bonus points.
[04:58] <jbailey> Ubugtu: thanks.
[04:58] <daf> bradb: sounds good to me
[04:58] <daf> bradb: maybe rather than two extra parameters on BTSP, it should be a tristate thing
[04:59] <bradb> daf: True. Mapping the API to the UI sounds like a good idea.
[05:00] <bradb> daf: You should be able to add a field to the search schema to render this widget.
[05:00] <bradb> Because it's a simple radio button widget, nothing fancy.
[05:00] <daf> search schema?
[05:01] <bradb> daf: IBugTaskSearch
[05:02] <bradb> It's the schema used for rendering search forms.
[05:02] <daf> ok, and how does the  IBugTaskSearch know how to render the widget?
[05:03] <bradb> daf: The schema is associated with the view.
[05:03] <bradb> Then in bugtask-macros-buglisting.pt, you an see the _widget references.
[05:04] <daf> ah, right
[05:04] <bradb> e.g.
[05:04] <bradb> <tal:block content="structure view/unassigned_widget" />
[05:05] <bradb> daf: Have a look at IDistroBugTaskSearch and IUpstreamBugTaskSearch to see how they're plugged in at the right moment to render appropriate search widgets.
[05:06] <bradb> There's also IPersonBugTaskSearch
[05:06] <daf> thanks for the tip
[05:06] <bradb> no prob
[05:06] <daf> hmm, would this make sense as an IDistroBugTaskSearch thing?
[05:06] <daf> since this filtering only makes sense for packages
[05:06] <bradb> daf: yes, i believe that's the right idea
[05:07] <daf> cool
[05:17] <jbailey> Oh, I see.  It shows up once in my subscribed list for each task that exists on the bug.
[05:17] <bradb> jbailey: yeah, suckage. also known issue.
[05:18] <jbailey> ah, really?  I wasn't able to find it when searching for 'subscribed' under malone.
[05:18] <bradb> I don't recall offhand if there's a bug open on it. /me checks.
[05:19] <Kamion> jbailey: (it's not specific to the subscribed bug list.)
[05:20] <jbailey> Ah, that's probably why.  Thanks.
[05:21] <jbailey> Down under 300 subscribed bugs.  I'll try to reduce by another 50 after lunch. =)
[05:21] <bradb> Hm, can't find an open bug on that problem.
[05:22] <jbailey> bradb: Do you want me to file something so that it doesn't get lost, or are you just going to make  note somewhere?
[05:22] <bradb> jbailey: Sure, can you please file a bug?
[05:23] <jbailey> Will do!
[05:23] <bradb> mercy
[05:25] <bradb> Right, I'm hungry. See you at the resto, jbailey.
[05:25] <jbailey> bradb: Yup.  See you shortly! =)
[06:52] <Kinnison> kiko: Do you know where cprov is?
[06:53] <kiko> yes, he's out on leave this afternoon. arranging to get married, I believe.
[06:56] <Kinnison> kiko: aha, I shall mail him then
[06:56] <kiko> good plan
[07:12] <kiko> salgado, how's MM shaping up?
[07:15] <ddaa> fixing them...
[07:16] <ddaa> ah, email error reporting, that would be kinda useful for importd methink
[07:16] <salgado> kiko, problems. twisted problems
[07:16] <kiko> salgado, that is disturbing
[07:16] <kiko> talk to me
[07:16] <SteveA> ddaa: it's a good place to start.  that's what we started with for launchpad, until we came up with something better suited to multiple app-servers and richer reports.
[07:16] <salgado> something is calling deferred.callback() a second time
[07:17] <SteveA> kiko: we should have a phone or skype call in a while.
[07:17] <kiko> salgado, is this something we should reconsidered
[07:17] <kiko> ah
[07:17] <kiko> salgado, code problems, or design problems, or infra problems?
[07:17] <salgado> code problems
[07:17] <ddaa> SteveA: did lifeless talk to you about getting jamesh to work on Launchpad status reporting for the Branch Puller?
[07:17] <SteveA> ddaa: yes he did
[07:18] <SteveA> ddaa: jamesh's main and most important responsibility is supporting the work you're doing on the importd infrastructure
[07:18] <kiko> salgado, solvable? what will they require?
[07:19] <kiko> SteveA, seconded. let's not distract jamesh from what is most important, please
[07:19] <SteveA> ddaa: in addition, you can call me if you want to talk over issues you're coming up against, and it is night time for jamesh and lifeless
[07:19] <salgado> kiko, well, first I need to find where the problem is
[07:19] <SteveA> kiko: yes, we're all agreeing with ddaa
[07:19] <SteveA> and lifeless
[07:19] <kiko> salgado, why has noone else run into this problem?
[07:19] <SteveA> the launchpad status reporting is a part of what the branch puller needs
[07:19] <kiko> is this a one-of-a-kind tool?>
[07:20] <salgado> kiko, because it's a problem in the code I wrote?
[07:21] <kiko> ai ai
[07:21] <kiko> salgado me mata
[07:21] <salgado> or maybe in the urlProber.py cprov wrote
[07:23] <SteveA> salgado: ping me if you want another pair of eyes
[07:23] <kiko> salgado, why don't you share your code
[07:24] <salgado> I do share with people who ask. :)
[07:25] <kiko> I'd rather you were more promiscuous
[07:25] <kiko> even if that gets me to the quotes page
[07:26] <Kinnison> you know it's going to
[07:26] <salgado> okay, okay. here it is: https://chinstrap.ubuntu.com/~dsilvers/paste/fileyXfi0m.html
[07:28] <salgado> aparently, something inside ProberFactory is calling self.deferrec.callback() before the call issued inside ProberFactory.parseResult()
[07:29] <SteveA> salgado: can you insert calls to get a traceback in each case?
[07:29] <SteveA> that will show you the stack that caused the call each time
[07:31] <salgado> right... I'll try that
[07:35] <kiko> thanks for that email, Kinnison/.
[07:35] <Kinnison> kiko: you're welcome.
[07:39] <Kinnison> I'll have my phone with me if anything is needed
[07:39] <Kinnison> Otherwise I'll see you lot tomorrow morning
[07:39] <Kinnison> ciau
[07:39] <kiko> night
[07:39] <Kinnison> night kiko
[08:18] <bradb> kiko: I've got a little patch to move batch size into the config files. Can I land it and email stub, or should I email stub before landing it?
[08:19] <kiko> stub has a week's notice, I'd land and mail.
[08:19] <bradb> will do, thanks
[08:19] <kiko> thanks for asking, most reasonable.
[08:20] <SteveA> bradb: land it and add to staging and development configs
[08:20] <SteveA> bradb: leave it out of production configs
[08:20] <bradb> ok
[08:20] <SteveA> what's the benefit of having batch size in the config file?
[08:21] <bradb> Consistency. It's a knob we need to turn to see how many bugs we can list on one page before things explode.
[08:22] <bradb> The more bugs we can list, the easier life will be for Ubuntu devs.
[08:22] <SteveA> you mean that it is tied to timeouts
[08:22] <bradb> Yeah.
[08:22] <SteveA> is this just for bug listings?
[08:23] <bradb> Yeah.
[08:24] <SteveA> ok.
[08:24] <SteveA> does the config file setting clearly indicate that it is just for bug listings?
[08:24] <bradb> it's called buglist_batch_size, so yeah
[08:24] <SteveA> ok
[08:25] <SteveA> sounds good
[08:25] <bradb> cool
[08:52] <dilys> Merge to devel/launchpad/: [trivial]  add a buglist_batch_size config option, (r3096: Brad Bollenbach)
[08:54] <bradb> Truncate me.
[09:30] <kiko> does anyone know what revision made it into production
[09:39] <ddaa> okay, the imports from savannah appear fixed
[10:24] <kiko> ddaa, when did you plan on leaving london for the march sprint?
[10:24] <kiko> has anyone booked yet?
[10:24] <ddaa> kiko: why are yoo picking at me?
[10:24] <ddaa> and no, I haven't booked yet.
[10:24] <kiko> I particularly like you 
[10:24] <kiko> bradb, have you?
[10:24] <kiko> are you planning on leaving saturday or sunday?
[10:25] <bradb> kiko: I've booked
[10:25] <kiko> tell me all about it
[10:25] <ddaa> bradb: which hotel?
[10:25] <bradb> ddaa: Same as the Distro sprint, I presume (from SteveA's email to launchpad@)
[10:25] <kiko> bradb, what dates?
[10:26] <bradb> checking
[10:26] <lifeless> kiko: ddaa will be there till the 28th
[10:26] <kiko> oh right.
[10:26] <lifeless> ddaa: I just now sent the email about the bzr planning days
[10:26] <ddaa> ha?
[10:26] <ddaa> really?
[10:26] <lifeless> which we discussed on IRC back in jan
[10:26] <ddaa> I have something planned for the 25th...
[10:26] <bradb> arriving on the 12th at 7:30AM, leaving on the 25th at 2:00PM
[10:27] <kiko> thank you bradb
[10:27] <ddaa> not terribly important though
[10:27] <bradb> no prob
[10:27] <lifeless> ddaa: read the mail, it may not be an issue
[10:30] <ddaa> read the mail
[10:31] <ddaa> I'll cancel my previous plan ("fte de l'internet" with some ubuntu-fr guys in the city of the next RMLL)...
[10:32] <ddaa> mh...
[10:32] <ddaa> maybe I can do it, if I really want...