[12:04] <kbrooks> sabdfl, by the way, if you would like to contact me any time for any reason, here is my e-mail: kyle@kbrooks.ath.cx
[12:16] <sabdfl> kbrooks: i think everyone is getting back to the routine after our london sprint last week
[12:20] <mpt> This time, the branch is going to LAND
[12:22] <dilys> Merge to devel/launchpad/: [trivial]  Fix sorting issues in testcases deriving from the use of os.listdir, which is inherently unsorted (r3359: kiko)
[12:44] <mpt> kiko, sure
[12:44] <mpt> now's good
[12:51] <kiko> mpt, can it be in 2h time?
[12:51] <kiko> and what number should I call you at?
[12:51] <mpt> 2 hours is fine, number in msg
[12:59] <mpt> yay, another test that passes on localhost and fails on PQM
[01:00] <kiko> which test is that?
[01:03] <mpt> xx-edit-package-bug-task-authenticated.txt
[01:06] <OdyX> Hey guys
[01:07] <OdyX> I'm on translating KDE-templates in french, but everything is ever translated in the KDE I have here at home (Dapper).
[01:07] <OdyX> So my question is: should I (or, by extension: "we") translate all kdebase again?
[01:08] <OdyX> Will that be useful in anyway?
[01:08] <mpt> "everything is ever"?
[01:08] <mpt> OdyX, do you mean your translations haven't shown up?
[01:08] <OdyX> mpt: I mean... My KDE is for most translated.
[01:08] <OdyX> only some little apps aren't
[01:09] <OdyX> kdebase templates appeared one hour ago (was informed by core-dev)
[01:09] <OdyX> two solutions: 
[01:10] <OdyX> a. copy-paste from existant but this should be made by computer
[01:10] <OdyX> b. re-translate differently
[01:11] <mpt> OdyX, according to https://launchpad.net/distros/ubuntu/dapper/+lang/fr kdebase is almost entirely translated already
[01:11] <mpt> but the translations haven't been exported to Dapper yet
[01:11] <mpt> that's why they're purple instead of green
[01:11] <OdyX> mpt: these yes .. these are the one we just made.
[01:11] <OdyX> but we have templates here
[01:12] <OdyX> https://launchpad.net/distros/ubuntu/dapper/+source/kdebase/+translations
[01:12] <OdyX> which are to be translated
[01:13] <OdyX> I began kcmaccessibility ( https://launchpad.net/distros/ubuntu/dapper/+source/kdebase/+pots/kcmaccessibility ) when I noticed I was re-inventing some existant
[01:13] <OdyX> in MY computer..
[01:13] <mpt> hmmm
[01:13] <mpt> I don't know about these details, sorry
[01:13] <mpt> You need to ask either carlos or jordi
[01:13] <mpt> jordi, are you awake?
[01:14] <jordi> OdyX: I think we're having some problems with templates like that which should not be there.
[01:14] <jordi> carlos is working on it
[01:15] <OdyX> OK.
[01:15] <OdyX> so what?
[01:15] <OdyX> could you maybe "block" them, for people not spending time on unuseful translations ??
[01:15] <OdyX> (at least before decision)
[01:17] <jordi> OdyX: yeah, that's what carlos wants to do, more or less
[01:17] <OdyX> jordi: OK. That's the answer I was expecting...
[01:17] <OdyX> :D
[01:18] <jordi> mpt: strange. Maybe because there's many templates
[01:18] <jordi> :)
[01:20] <mpt> There's fewer templates on that page than there are languages on the distro release translations page, and that has charts :-P
[01:23] <jordi> heh, yes
[01:23] <jordi> but
[01:23] <jordi> you'd need a chart for all languages for all templates
[01:23] <jordi> that's huge
[01:24] <mpt> Well, I don't understand why all those templates are appearing on a single page anyway
[01:25] <mpt> since the link I clicked on (kdebase) is just one of them
[01:25] <mpt> bbiab
[01:25] <jordi> kdebase has a looot of apps
[01:26] <OdyX> jordi: most of them translated..
[01:26] <jordi> yes
[01:27] <OdyX> adept (ept) was not and should stay
[01:29] <OdyX> (oops, not in kdebase)
[02:30] <mpt> kiko-zzz, I'm going out to get some brunch. I'll be back in about 25 minutes, otherwise my mobile number's on the Offices page
[02:51] <Kinnison> Which file is it which controls special situations for individual doctests
[02:52] <spiv> Kinnison: Which doctests?  lib/canonical/launchpad/doc?
[02:52] <Kinnison> yes
[02:52] <spiv> lib/canonical/launchpad/ftests/test_system_documentation.py
[02:52] <Kinnison> that's the doofer, ta
[02:53] <Kinnison> Hmm, that doesn't allow me to reset the DB does it?
[02:55] <spiv> Kinnison: see doc/testing.py
[02:55] <spiv> Er,
[02:55] <spiv> testing.txt
[02:56] <Kinnison> heh, ta
[02:59] <mpt> ohhhh, chocolate donut
[02:59] <OdyX> Bye guys. Thanks
[03:01] <Kinnison> mpt: *jealous*
[03:10] <Kinnison> hmm, do we not have pg 8.1 on breezy?
[03:11] <elmo> breezy-backports
[03:11] <Kinnison> aha ta
[04:18] <dilys> Merge to devel/launchpad/: [r=jamesh]  Removes heading duplication on every Launchpad page. Adds hierarchy navigation to project pages. Fixes bug 3595 ('Search Packages' shouldn't be a separate page), bug 31726 ('Edit Bug Contact' should be under 'Bugs', not 'Overview'), and fixes the titles of the various /people/\+*.list pages. Removes many unnecessary sentences. Makes the page for adding a source release to a mirror use the proper template. Makes the fallb
[04:31] <mpt> VICTORY
[04:55] <stub> lifeless: I'm going to roll out r3354 (wot was committed Monday) to production today. I was going to wait until Znarl is online so he can install some certificates into Apache at the same time.
[04:55] <stub> lifeless: I think this means the supermirror stuff can be updated as well as the bzr syncing stuff, but I'm not familiar with those setups.
[05:20] <jamesh> mpt: is that the branch you were having zcml errors with?
[05:21] <mpt> jamesh, yes
[05:21] <mpt> that was one of the problems
[05:22] <mpt> another problem was "..." matching <BLANKLINE> on localhost but not on PQM
[06:55] <mpt> stub, what are the certificates for?
[06:55] <stub> mpt: https://librarian.launchpad.net and any remaining shippit-for-dapper certs.
[06:56] <mpt> ok
[06:56] <Ubugtu> Malone bug 6659 in launchpad "Launchpad requests user certificate from Safari, MSIE/Windows, MSIE/Mac" [Major,Confirmed]  http://launchpad.net/bugs/6659
[06:57] <mpt> stub, are you updating staging at the moment?
[06:57] <stub> It might be updating itself
[06:57] <mpt> it seems to be asleep
[06:58] <stub> mpt: yes - staging is being rebuilt. Database restore currently underway.
[06:59] <mpt> ok, ta
[07:07] <jamesh> mpt: do we have an RT request for that bug?
[07:07] <jamesh> since they are the ones who can fix it
[07:08] <jamesh> yes we do
[07:10] <mpt> I suppose it wouldn't matter if it did, since that RT isn't publicly accessible
[08:52] <mdke> mpt_, which is bad
[08:56] <jamesh> mdke: private stuff gets discussed in RT
[08:56] <mdke> jamesh, that's a pity
[08:57] <SteveA> morning
[08:57] <jamesh> hi SteveA 
[08:57] <mdke> because say I notice that something is wrong, like a certificate is expired on a site or something, I think about reporting it, but I can't tell if someone already has :/
[08:58] <jamesh> mdke: well, you can report it ...
[08:59] <mdke> sure, but the price of privacy is getting potentially hundreds of dups :)
[08:59] <jamesh> yep
[09:03] <sabdfl> mpt__ ping
[09:04] <sabdfl> erk
[09:04] <sabdfl> no mpt
[09:12] <mdke> malone: when a bug gets marked as rejected on one source package, the default subscribers to that package (e.g. a team) are not removed from bug email. Is that something that could be arranged?
[09:13] <mpt__> sabdfl, pong
[09:13] <jamesh> mdke: what if the bug gets reopened?
[09:13] <mdke> jamesh, i was thinking more of the situation where it has been reported on the wrong package, and is moved to another one
[09:14] <mdke> the contact for the wrong package continues to be subscribed
[09:14] <mpt> mdke, like when ubuntu-doc continues to receive mail about non-ubuntu-doc bugs? :-)
[09:14] <mdke> mpt, maybe...
[09:14] <mdke> yes, that's what made me think of it
[09:15] <mpt> I think that should be solved by making product/package subscriptions implicit
[09:15] <mpt> and (at least defaulting to) not sending e-mail about "Not a bug" bugs
[09:16] <mdke> jamesh, for an example, see bug #36528, originally opened on ubuntu-docs and moved to yelp
[09:16] <Ubugtu> Malone bug 36528 in yelp "Changing font for displaying documentation doesn't work" [Normal,Confirmed]  http://launchpad.net/bugs/36528
[09:17] <jamesh> mdke: ideally, as a member of "ubuntu-doc", you'd be able to remove the subscription
[09:17] <jamesh> but I'm not sure auto-removing subs helps
[09:19] <mdke> jamesh, how can I manually remove it?
[09:19] <jamesh> mdke: that's a bug: you can currently only unsubscribe yourself
[09:19] <mdke> ah right
[09:19] <mdke> why wouldn't auto-unsubscribing help?
[09:19] <jamesh> not a team you are a member of
[09:20] <jamesh> okay.  It would help in this case, but there are a lot of cases where it isn't the right thing to do
[09:20] <jamesh> e.g. developer rejects a bug, then reporter posts more information about why they think it is a bug but doesn't reopen it
[09:21] <jamesh> if you unsubscribe-on-reject, then the developer doesn't see the reply
[09:21] <mpt> yeah
[09:21] <mdke> sure
[09:21] <mdke> it should be something about changing the package that triggers it, if anything
[09:22] <mdke> or allowing manual unsubscription, if the use case is pretty narrow
[09:23] <jamesh> allowing users to unsubscribe teams they are members of should be allowed
[09:28] <mdke> jamesh, is there a bug already? i'll open one if not
[09:28] <jamesh> sabdfl: btw, we got the pending-reviews script running a lot faster, so have switched it to run every 2 hours
[10:34] <dilys> Merge to devel/launchpad/: [trivial]  Moves the facet+context+actions menu to the left side consistently, as requested by Mark. Fixes bug 35160 (Merge result notification could be worded better), bug 712 (Rosetta doesn't mention gettext), and explains translation groups better. Tidies distribution source package page, person package bugs page, and product series source page. (r3361: Matthew Paul Thomas)
[10:44] <mdke> if I _decline_ a member for admission to a group, and insert a comment in the box, does it get mailed to them?
[11:00] <mdke> who can I ask about that? ^^
[11:04] <SteveA> mdke: about what?
[11:05] <mdke> oh yeah, it was just before you came in
[11:05] <mdke> if I _decline_ a member for admission to a group, and insert a comment in the box, does it get mailed to them? <-- SteveA 
[11:07] <SteveA> mdke: i don't know.  i can take a look at the code and tests to see, but better would be to ask salgado when he arrives in a couple of hours
[11:07] <SteveA> can you wait a couple of hours?
[11:07] <mdke> SteveA, of course
[11:07] <mdke> thanks
[11:19] <sabdfl> jamesh: awesome! what was the speedup?
[11:20] <jamesh> sabdfl: (a) switching to bzr 0.8, and (b) using a repository for the branches and keeping it around between runs
[11:21] <jamesh> sabdfl: (a) switching to bzr 0.8, and (b) using a repository for the branches and keeping it around between runs
[11:21] <sabdfl> nice
[11:28] <doko> hmm, it's not possible to close the debian part of a bug report in malone?
[11:28] <mpt> doko, no, that's supposed to happen by itself shortly after it happens in debbugs
[11:29] <mpt> sabdfl, I just saw on ubuntu-devel@ someone who didn't report a bug because they entered the package into the search form on the front page and it returned 0 results
[11:29] <mpt> sabdfl, so I propose that we hide the product search from the front page (leaving it on /products, of course) until we have a search function that returns results for distros+packages+products+projects+packages
[11:30] <mpt> I suspect it's being more confusing than useful in its current state.
[11:30] <sabdfl> mpt: no thanks
[11:32] <doko> mpt: but this feature is not yet deployed?
[11:32] <mpt> doko, as far as I know it is, but it might be running slowly
[11:32] <mpt> BjornT would be able to tell you
[11:33] <carlos> hi
[11:33] <sabdfl> mpt: i saw you took on the spec table sorting bug
[11:33] <sabdfl> steve implemented a dbschema.sortkey
[11:33] <jamesh> mpt,doko: I don't think debbugs synching is in production
[11:33] <sabdfl> so could you use that as the <span style="display: none;"> thing?
[11:34] <sabdfl> also, kiko and i discussed improving the javascript sorter to look for that span explicitly, turn it into an int, and sort on that
[11:34] <sabdfl> at the moment its sorting alphabetically
[11:34] <sabdfl> which gets some weird results on, for example, translation stat sorting
[11:34] <sabdfl> make sense?
[11:34] <BjornT> doko: i'm currently working on getting basic debbugs syncing working
[11:34] <sabdfl> BjornT: are you looking at the code i wrote? it brings in status, comments, etc
[11:35] <sabdfl> i'm in meetings at the moment, so can't comment furhter on the search thing mpt, other than to say please don't do that
[11:36] <BjornT> sabdfl: yes. there are some issues with importing comments and so on, so my plan is to extract the code that deals with status/severity updates and move it into an ExternalSystem. then we can think of more extensive debbugs sync later.
[11:37] <sabdfl> ok
[11:37] <sabdfl> one thing: the underlying code that talks to a debbugs repository is in perl
[11:37] <sabdfl> Debbugs.pm
[11:37] <sabdfl> we need that converted to python
[11:37] <sabdfl> it's only 130 lines, and a lot of whitespace
[11:38] <sabdfl> that will make it more reliable - right now its shelling out and sometimes it dies in unpredictable and unmeasurable ways
[11:38] <sabdfl> also, it's much more efficient, given the debbugs structure, to run through all the *debian* bugs in sequence
[11:38] <sabdfl> and filter then the data you want
[11:39] <mpt> sabdfl, if I did take a spec table sorting bug it was an accident -- I don't remember doing so
[11:39] <sabdfl> whereas external system is designed, as i understand it, to start with a list of Malone bugs and then poke into the remote systems for status
[11:39] <sabdfl> mpt: it was a day or two ago
[11:40] <sabdfl> it's just <td>New</td> needs to become <td><span style="display: none;" tal:content="context/status/sortkey">New</span></td>
[11:40] <sabdfl> i might have conflicts if you actually do that, so i don't mind if you punt that bug back to me, it was on my personal todo in any event
[11:40] <sabdfl> 'k?
[11:41] <mpt> sure
[11:42] <jamesh> you probably want both the sortkey and the title though, right?
[11:42] <mpt> bug 3910
[11:42] <Ubugtu> Malone bug 3910 in launchpad "Sorting +specs table doesn't work" [Normal,Confirmed]  http://launchpad.net/bugs/3910
[11:42] <mpt> assigned to Mr Mark Shuttleworth
[11:43] <jamesh> so <td tal:content=".../title">New</td> => <td><span style="display:none" tal:content=".../sortkey></span><span tal:replace=".../title"></span></td>
[11:43] <mpt> I marked a duplicate of that bug, which is probably what you were thinking of
[11:49] <BjornT> jamesh: i was looking at the bugzilla import code, and saw that you mapped NEW -> Unconfirmed. was there a special reason for doing so? by reading https://bugzilla.ubuntu.com/page.cgi?id=fields.html, i would think it should map to Confirmed.
[11:51] <jamesh> BjornT: when I merged that code, the statuses had different names
[11:52] <jamesh> BjornT: I think I originally had UNCONFIRMED and NEW mapping to New, and ASSIGNED to Accepted
[11:52] <jamesh> New got renamed to Unconfirmed and Accepted got changed to Confirmed
[11:52] <jamesh> then In progress got added later on
[11:52] <jamesh> (that's how I remember it, at least)
[11:52] <mpt> that seems about right
[11:53] <BjornT> jamesh: ah, i guessed that was the reason. i'll change it then, since i used that as a reference for the bugzilla bug watch syncing.
[11:54] <jamesh> I was setting unknown statuses to New too
[11:54] <jamesh> (not that there were any for the ubuntu import)
[11:55] <sladen> how do I delete/update/change a remote bug that is assigned to Ubuntu Core Dev ?  https://launchpad.net/products/hotplug/+bug/36599/+editstatus
[11:55] <Ubugtu> Malone bug 36599 in hotplug "Install Hangs on "Hotplug"" [Normal,Unconfirmed]  
[11:55] <jamesh> we probably want UNCONFIRMED => UNCONFIRMED, NEW => CONFIRMED, ASSIGNED => INPROGRESS
[11:56] <BjornT> yeah, that sounds sane.
[11:56] <mpt> ASSIGNED is less believable than INPROGRESS, but there isn't anything closer
[11:57] <sladen> because it's a remote bug, it's "automatically pulled from a remote bug tracker" and all the fields now appears as being uneditable
[11:57] <ajmitch> sladen: annoyingly it's on upstream hotplug rather than on ubuntu hotplug, so probably just the product registrant can change it?
[11:57] <jamesh> sladen: you should attach a remote bug to it
[11:59] <stub> Kinnison: ping
[12:02] <mpt> sabdfl_afk, ^^^ see? :-)
[12:03] <mpt> sladen, on https://launchpad.net/products/hotplug/+bug/36599 click "Also affects: Distribution...", and file it under the appropriate Ubuntu package
[12:03] <Ubugtu> Malone bug 36599 in hotplug "Install Hangs on "Hotplug"" [Normal,Unconfirmed]  
[12:03] <sladen> jamesh: I'd like to delete it or reject it...  It's EVALID and filed by a user, but I can't...
[12:04] <mpt> oh, it already is
[12:04] <sladen> INVALID
[12:04] <jamesh> sladen: the plan was to set tasks such as that one to UNKNOWN
[12:04] <jamesh> (waiting til their status gets synchronised from the remote bugtracker0
[12:05] <mpt> so how did that get reported on the hotplug product in the first place?
[12:05] <ajmitch> people search for hotplug on the front page
[12:05] <mpt> yeah, yeah, I know, but
[12:05] <sladen> mpt: because the user booted the CD and filed it against the last message he saw  "Starting hotplug..."
[12:05] <mpt> It was reported only five days ago, and "X doesn't use Malone"  was implemented well before then
[12:06] <mpt> to stop people from reporting bugs on upstream products that don't use Malone
[12:08] <mpt> BjornT, any ideas? https://launchpad.net/products/hotplug/+bug/36599/+activity
[12:08] <Ubugtu> Malone bug 36599 in hotplug "Install Hangs on "Hotplug"" [Normal,Unconfirmed]  
[12:08] <sladen> and since it doesn't have a link to any upstream I can't go there and mark it as rejected and have it synced back
[12:08] <jamesh> maybe the Ubuntu task was created first?
[12:09] <mpt> doesn't look like that from the activity log, though it's rather cryptic
[12:09] <mpt> but why would it matter if it was?
[12:09] <jamesh> because you can open an upstream task against a non malone-using product on an existing bug
[12:10] <mpt> oh.
[12:10] <mpt> Is that bug reported?
[12:11] <mpt> It was mentioned in bug 35646, but tangentially...
[12:11] <Ubugtu> Malone bug 35646 in malone "Can see existing bugs for a project but can't add bugs" [Normal,Unconfirmed]  http://launchpad.net/bugs/35646
[12:11] <jamesh> that isn't it though: the upstream task is from the 25th and the distro task is from the 30th
[12:14] <mpt> ah, bug 34343
[12:14] <Ubugtu> Malone bug 34343 in malone "Shouldn't allow task reassignment to an upstream that doesn't use Malone" [Normal,Confirmed]  http://launchpad.net/bugs/34343
[12:15] <jamesh> that'd be it.  It started life as a bug against products/breezy-backports
[12:15] <sabdfl_afk> mpt: i don't think that the search page on the front is the problem, in that case
[12:18] <jamesh> mpt: I guess in part this occured because you can't  assign a product bug task to a distro package bug task through the web UI
[12:20] <mpt> jamesh, if by "assign" you mean "change", that's part of it
[12:20] <jamesh> that is what I mean.
[12:28] <stub> Launchpad will be going down in 15 minutes for a code update. Estimated downtime is 10 minutes. Wikis will be in read only mode during this time.
[12:45] <ddaa> Cool, there's a real 503 page!
[12:45] <ddaa> Feels like it's lacking portlets though ;)
[12:45] <jordi> ddaa: hmm, it's been there for a while?
[12:47] <ddaa> Last time, I just had a proxy error
[12:48] <mpt> It's been there since a couple of page layouts ago, hence the double ribbon on the top
[01:01] <kbrooks> stub:
[01:01] <kbrooks> what index
[01:01] <stub> Just one of the text indexes that needs updating with the new code. I'd expected it would be faster on the new hardware.
[01:02] <kbrooks> ah
[01:04] <Kinnison> stub: pong
[01:04] <stub> Kinnison: Ahh.. just about to restart all the soyuz stuff. Feel like doing the honours?
[01:04] <stub> Kinnison: I had to kill -9 the buildd sequencer :-/
[01:10] <ddaa> hum, hum https://launchpad.net/people/+peoplelist?batch_start=0&batch_end=50
[01:11] <spiv> stub: The wikis seem happy.
[01:11] <kbrooks> up.
[01:12] <spiv> stub: Also, running 'python -c "import xmlrpclib; s = xmlrpclib.Server('http://localhost:8999/v2'); print s.getUser('kiko')"' on macquarie is a good smoke test.
[01:13] <stub> ok. everything back up including soyuz
[01:13] <stub> ddaa: That must be our new privacy policy
[01:14] <ddaa> What does that mean?
[01:14] <ddaa> I'm logged in.
[01:15] <ddaa> If anything, this page should either display something for logged in users, or just not be linked from.
[01:15] <ddaa> linked to...
[01:15] <stub> ddaa: I'm attempting humour
[01:17] <SteveA> meeting in 42 mins
[01:17] <mpt> oh, meetings are at midnight now
[01:18] <mpt> must be daylight saving
[01:19] <SteveA> we put the U in UTC
[01:20] <Kinnison> SteveA: the 'Ewww' in UTC
[01:43] <carlos> jordi: hi, around?
[01:56] <SteveA> workrave time!
[01:58] <mpt> BjornT, perhaps you could reply to Lionel Dricot's message "The support part of Launchpad?"
[01:59] <mpt> I know only a few of the answers
[01:59] <BjornT> mpt: sure, i'll do that today
[02:00] <mpt> ta
[02:00] <SteveA> and now it's...
[02:00] <SteveA> MEETING TIME
[02:00] <SteveA> welcome to the first post-sprint-in-london launchpad development meeting
[02:00] <SteveA> who is here today?
[02:00] <mpt> me
[02:00] <BjornT> i'm here
[02:00] <bradb> me
[02:00] <matsubara> me
[02:00] <spiv> I am (but a bit sleepy...)
[02:01] <carlos> me
[02:01] <mpt> ... Henceforth known as the FPSILLDM
[02:01] <spiv> mpt: and that's why you're our UI guy ;)
[02:01] <jordi> carlos: hi
[02:01] <jordi> hello
[02:01] <jamesh> me
[02:01] <SteveA> matsubara: any sign of salgado or kiko?
[02:02] <matsubara> SteveA: salgado is still on vacation. I'll call kiko
[02:02] <SteveA> ok
[02:02] <SteveA> stub: ?
[02:03] <stub> yo
[02:03] <SteveA>  * Roll call
[02:03] <SteveA>  * Agenda
[02:03] <SteveA>  * Next meeting
[02:03] <SteveA>  * Activity reports
[02:03] <SteveA>  * Items from last meeting
[02:03] <SteveA>  * Launchpad oops milestone report
[02:03] <SteveA>  * Production / staging (stub)
[02:03] <SteveA>  * Karma calculation (inc. Bug #36023)
[02:03] <matsubara> SteveA: no need to call. he just arrived.
[02:03] <SteveA>  * upgrading libgpgme in production / pqm
[02:03] <SteveA>  * errors in rosetta exports
[02:03] <SteveA>  * possibilities of spamming users from staging
[02:03] <SteveA>  * policy for urgent fixes (steve)
[02:03] <SteveA>  * how to set up a repository
[02:03] <SteveA>  * Keep, Bag, Change
[02:03] <SteveA>  * Three sentences
[02:03] <SteveA> 
[02:03] <SteveA> next meeting... how about same time next week?
[02:03] <kiko-zzz> I am
[02:03] <ddaa> Here
[02:04] <SteveA>  * activity reports
[02:04] <kiko> sorry, somewhat sick today
[02:04] <kiko> up to date
[02:04] <mpt> up to date
[02:04] <BjornT> i'm up to date
[02:04] <spiv> Up to date, aside from a gap for the sprint.
[02:04] <SteveA> my first day back , so i'm up to date, but only in a *technical* way
[02:04] <jordi> not up to date, have a batch nearly ready to send to get back in shape
[02:04] <bradb> up to date, except for gap in sprint
[02:04] <stub> up to date
[02:05] <matsubara> up to date
[02:05] <carlos> not up to date, I forgot to use gtimelog as usual before the sprint... I'm using it again since today (sorry about this...)
[02:05] <ddaa> uptodate except for 
[02:05] <ddaa> sprint
[02:05] <jamesh> not up to date.  Will send a summary for this week so far
[02:05] <matsubara> btw, except for the sprint too
[02:05] <SteveA>  * Items from last meeting
[02:05] <SteveA> there are none that i know of
[02:06] <kiko> not that I know of
[02:06] <SteveA>  * Launchpad oops milestone report
[02:06] <kiko> the oopses that remain are the tough ones
[02:06] <SteveA> we should think how best to manage the oops and timeout milestones
[02:07] <SteveA> kiko: let's talk about this on the phone a bit later
[02:07] <kiko> there's a bug in bug searching that BjornT, bradb and matsubara worked on last week, and there's the new account/password oopses, and then there are a number of obscure ones (in infrastructure?)
[02:07] <kiko> sure.
[02:07] <kiko> MeetingAction: SteveA and kiko to talk about oopses
[02:07] <SteveA> ta
[02:07] <SteveA> also, we should start using milestones to target fixes to specific planned rollouts
[02:08] <SteveA> i'd like to propose two milestones each month
[02:08] <kiko> I wonder if that's too much 
[02:08] <kiko> but then again, right now, we are still catching up 
[02:08] <kiko> which is why we're doing weeklies -- rosetta and malone keep pushing us
[02:08] <SteveA> we can start with one each month, for the first rollout of the month
[02:09] <SteveA> and increase frequency as we go
[02:09] <kiko> I'd love to only do one rollout per month
[02:09] <SteveA> milestones and rollouts don't need to be exactly linked
[02:09] <jamesh> kiko: milestone != rollout.  (or does it?)
[02:09] <kiko> but that would require at least one more month of work before we are "stable"
[02:09] <SteveA> let's start with a milestone for next week's rollout
[02:09] <kiko> well, no, but they are related
[02:09] <SteveA> and experiment on that one
[02:10] <jordi> kiko: does this mean it'd be harder to get fixes for rosetta annoyances from now on, ie wait up to one month?
[02:10] <SteveA> 2006-04w1, for example
[02:10] <jordi> depending on the issues, could be frustrating for users
[02:11] <SteveA> or even 0604w1
[02:11] <kiko> jordi, that doesn't mean it's harder, but monthly rollouts are, well, monthly
[02:11] <kiko> note as above that milestones and rollouts don't need to be connected, but it's a bit odd to treat them as totally unrelated
[02:11] <carlos> kiko: I don't think we are ready to go with a monthly update
[02:11] <kiko> carlos, what did I just say?
[02:11] <jordi> well, harder as in with weeklies, many times we don't bothers considering cherrypicks. With monthlies, *shrug*
[02:11] <jamesh> I don't think we do enough testing on staging right now to stick to monthly rollouts
[02:11] <carlos> SteveA: I like 0604w1
[02:12] <kiko> jamesh, it's not so much testing, but rather, the fact that there are critical things that are not even implemented yet
[02:12] <mpt> jamesh, would more frequent rollouts mean more testing?
[02:12] <kiko> if we did monthlies we could really focus on testing staging
[02:12] <jamesh> mpt: no; less time to get the fix out
[02:12] <kiko> but this is science fiction for the next month or two at least
[02:12] <kiko> shall we move on?
[02:13] <SteveA> we still have no *reason* to test staging, other than it needs testing
[02:13] <SteveA> so that part needs consideration
[02:13] <mpt> yes, it's nobody's job
[02:13] <mpt> and we all have better things to do
[02:13] <mpt> I wanted to test staging for one thing today, but it was down whenever I tried
[02:13] <SteveA> kiko: i'd like to add a meeting action to add a 0604w1 milestone, for bugs to be targetted at, as an experiment in using milestones to target bugs for rollouts
[02:13] <SteveA> kiko: what do you think about it?
[02:13] <kiko> not w2?
[02:14] <SteveA> we can start in w2
[02:14] <kiko> one week is a bit tight for planning and actually doing anything.
[02:14] <SteveA> ok
[02:14] <SteveA> MeetingAction: steve to add milestone for 0604w2
[02:15] <SteveA> for the launchpad project's products
[02:15] <SteveA>  * Production / staging (stub)
[02:15] <SteveA> hmm
[02:15] <kiko> stub crashed
[02:15] <SteveA> no stub.  he dropped off
[02:15] <kiko> as usual
[02:15] <SteveA>  * Karma calculation (inc. Bug #36023)
[02:15] <SteveA> there was some good discussion on the launchpad-users list
[02:15] <SteveA> i haven't caught up on it all yet
[02:16] <SteveA> is there a particular outcome?
[02:16] <kiko> not yet
[02:16] <SteveA> ok.  so the discussion continues
[02:16] <kiko> this morning there was some discussion on karma-related topics (but not specifically calculation)
[02:17] <SteveA>  * upgrading libgpgme in production / pqm
[02:17] <SteveA> jamesh noted that the version of libgpgme we're using in production can segfault
[02:17] <stub> Sorry - network died
[02:17] <jamesh> I don't think the webapp does anything that would trigger the fault
[02:18] <SteveA> jamesh: cronscripts?
[02:18] <jamesh> the test suite failure is in tests for some utility script code
[02:18] <SteveA> jamesh: if we upgrade the pqm machine, we should upgrade the production ones too.
[02:18] <SteveA> otherwise it isn't as good a test running tests on the pqm machine
[02:18] <kiko> SteveA, lifeless said he placed an RT request for this -- do you know about this?
[02:18] <jamesh> sure.
[02:18] <SteveA> kiko: i do not know about this.
[02:19] <kiko> let me see
[02:19] <SteveA> meanwhile...
[02:19] <SteveA>  * Production / staging (stub)
[02:19] <stub> Production was updated a few minutes ago with r3354.
[02:19] <stub> Staging is running happily with its two updates per day (only the early morning UTC one does a database sync).
[02:19] <stub> There won't be a rollout next week unless people notify me of features or bugs that need fixes in production.
[02:20] <SteveA> stub: would that conflict with trying out a milestone called 0604w2 for targetting bugs for a rollout?
[02:20] <mpt> heh
[02:20] <kiko> SteveA, hmmm, but I don't see it related to launchpad. maybe he didn't.
[02:20] <SteveA> i guess not, as if the milestone doesn't have many bugs...
[02:20] <carlos> stub: I'm working on some changes that I hope will be ready to land next week...
[02:20] <SteveA> then we shift them onto 0604w?
[02:20] <carlos> will tell you if it's ready and merged
[02:20] <kiko> SteveA, stub: note that the +milestone page is broken.
[02:21] <SteveA> then it is good we are using milestones, so that there is internal pressure to fix and improve it
[02:21] <stub> SteveA: The milestone can target whatever it wants, but if the fixes don't land with a suitable 'settling down' period before the rollout, the rollout needs to be delayed or the fix skipped.
[02:22] <SteveA> we'll need a rollout/milestoning process where we include revision numbers in the bugs, i think
[02:22] <stub> We could do milestone driven rollouts, where we make note of the HEAD revision when the last desired fix lands and then roll that out a few days later...
[02:22] <SteveA> yep
[02:23] <SteveA> and then bump tardy fixes to the next milestone
[02:23] <kiko> that's what I was suggesting
[02:23] <SteveA> if they're holding stuff up
[02:23] <SteveA> in which case, a different milestone name would be better
[02:23] <SteveA> rather than a date-based one
[02:23] <kiko> date-based is good, though
[02:23] <stub> I'm not sure what actual benefit there would be, but I'm not fussed personally.
[02:23] <kiko> gives us a hard target
[02:23] <SteveA> kiko: did you say that you can't see the RT issue in question in the launchpad queue?
[02:24] <kiko> SteveA, correct, I can't. I will file one now.
[02:24] <SteveA> ok
[02:24] <ddaa> if we go to monthly rollouts, it would be nice to have a policy of cherrypicking fixes, generally, not just _critical_ ones.
[02:24] <kiko> perhaps lifeless forgot
[02:24] <kiko> and being week-granular means we can adjust to a good date during the week.
[02:24] <SteveA> ddaa: we're not discussing monthly rollouts
[02:25] <SteveA> i shall move on, and discuss this more on the phone with kiko
[02:25] <SteveA>  * errors in rosetta exports
[02:25] <SteveA> carlos: i saw some discussion of this and a bug filed
[02:25] <SteveA> anything to report on what happened?
[02:25] <carlos> hmm
[02:26] <SteveA> Tim Morley
[02:26] <carlos> well, that one
[02:26] <carlos> seems to be a problem with the wrapping and HTML code
[02:26] <carlos> so it seems to be affecting only documentation
[02:27] <carlos> anyway, I'm going to fix it asasp
[02:27] <SteveA> okay
[02:27] <SteveA> do you need any help fixing it?
[02:27] <SteveA> (other than a code review)
[02:27] <carlos> don't think so, but thanks
[02:27] <SteveA> ok
[02:27] <SteveA>  * possibilities of spamming users from staging
[02:27] <carlos> I will ping you
[02:27] <carlos> if something blocks me
[02:28] <kiko> jamesh, can you update the error summary to not place NotFoundError in the Not Found section?
[02:28] <kiko> it's confusing and actually wrong
[02:28] <SteveA> i'd like to check: if some configuration goes awry on staging, is it possible that a cron script or the launchpad webapp can mail users? 
[02:28] <SteveA> if so, i wonder if we can get the admins to block this in a way that will let us know our configuration is wrong
[02:28] <SteveA> but save embarassment
[02:29] <stub> SteveA: Yes, if we screw up configuration staging can send email
[02:29] <SteveA> there are only certain email addresses that staging needs to send mail to
[02:29] <stub> The only way I could see to stop that is to turn off the MTA on that box, which would suck
[02:29] <SteveA> i was thinking more configure the MTA
[02:29] <carlos> SteveA: rosetta scripts will spam users
[02:29] <kiko> really? It should be an easy configuration to the MTA to deny relaying
[02:29] <SteveA> to send mail only to certain whitelisted addresses
[02:29] <kiko> err 
[02:30] <kiko> deny accepting email for foreign destinations
[02:30] <SteveA> we really really must not spam people from staging
[02:30] <kiko> or mawson
[02:30] <jamesh> carlos: the launchpad.conf for the staging configuration disables sending mail in zopeless mode
[02:30] <SteveA> MeetingAction: steve to discuss this with elmo
[02:30] <carlos> jamesh: is that new?
[02:30] <jamesh> carlos: no
[02:30] <SteveA> i don't want to depend on our launchpad.conf being right
[02:30] <mpt> (and maybe make it staging.launchpad.net while you have elmo's attention)
[02:30] <carlos> jamesh: stub said that it wasn't...
[02:30] <carlos> stub: ?
[02:31] <stub> eh?
[02:31] <SteveA>  * policy for urgent fixes (steve)
[02:31] <SteveA> Kinnison: around?
[02:31] <carlos> I had to disable simple_sendmail to test the poimport script on staging
[02:31] <jamesh> carlos: I think he was saying that if everything is configured properly it shouldn't send mail, but there are no countermeasures in case it does.
[02:31] <carlos> oh, I see
[02:31] <jamesh> carlos: were you running with LP_CONFIG=staging?
[02:31] <stub> carlos: Yes. I forgot that there was an option for this until Bjorn reminded me.
[02:32] <carlos> jamesh: yes
[02:32] <SteveA> sometimes there is some urgent fix needed, and producing a good test for that fix would take longer than we would like
[02:32] <carlos> stub: ok
[02:32] <SteveA> i'm talking about urgent fixes that need to be put onto some production system as soon as possible for whatever reason
[02:32] <SteveA> the general answer from reviewers and from stub for such a fix should be: no fix without a test
[02:33] <Kinnison> SteveA: hi
[02:33] <SteveA> in *exceptional* circumstances, we can allow a fix to go in without a test, but then the committer must be considered "tainted", and unable to commit anything else at all, until the test is committed
[02:33] <Kinnison> SteveA: sorry, was elsewhere, what can I do for you?
[02:33] <SteveA> hello Kinnison.
[02:34] <SteveA> i noticed the issue of making an urgent fix to soyuz on the mailing list
[02:34] <Kinnison> Yes, and mdz has agreed I have the time to write fixes too
[02:34] <SteveA> so i wanted to set a policy here about making urgent fixes, and following with tests later
[02:35] <SteveA> any questions or observations about this policy?
[02:35] <jamesh> and you don't get to get out of doing the test by moving to the distro team :)
[02:35] <Kinnison> the taint thing seems reasonable
[02:35] <Kinnison> jamesh: I wasn't trying to
[02:35] <jamesh> Kinnison: just kidding
[02:36] <SteveA>  * how to set up a repository
[02:36] <SteveA> the bzr in dapper supports repositories
[02:36] <SteveA> and it should be a neat thing to use for your launchpad trees
[02:36] <SteveA> are there instructions anywhere on how to use repositories?
[02:37] <jamesh> and pqm + pending-reviews support repositories (more importantly)
[02:37] <SteveA> BjornT: you said you'd used them, iirc
[02:37] <SteveA> what do we need to do to get people using repositories?
[02:38] <SteveA> ddaa: would you find out, and mail the launchpad list about it when you have done so?
[02:38] <spiv> Repositories sound great.  I'd really love for the bzr team to mail the launchpad list with a) instructions on how to convert things, and b) reassurances that it's ready for us :)
[02:38] <BjornT> SteveA: yeah, although i don't think it's written down anywhere how to do it. i used a combination of irc and mailing lists to find out how to do it.
[02:38] <kiko> boring
[02:38] <ddaa> SteveA: I do expect not to find any
[02:39] <SteveA> ddaa: please find out, possibly by asking mpool or lifeless, then mail us on the launchpad list with the outcome
[02:39] <SteveA> as spiv noted, the important things are
[02:39] <SteveA>  - how to start using them
[02:40] <SteveA>  - an assurance that we should use them 
[02:40] <stub> jblack might still have enough time to document things - not sure what his schedule is like these last few days.
[02:40] <SteveA>  * Keep, Bag, Change
[02:41] <SteveA> with a countdown
[02:41] <SteveA> 6
[02:41] <SteveA> 5
[02:41] <SteveA> 4
[02:41] <SteveA> 3
[02:41] <SteveA> 2
[02:41] <SteveA> 1
[02:41] <SteveA> ok
[02:41] <SteveA> let's hear your...
[02:41] <SteveA>  * Three sentences
[02:41] <mpt> DONE: Recovered from jetlag, e-mail, landed headings branch, bugfixes
[02:41] <mpt> TODO: Rosetta design stuff, Malone and projects fixes, bug 2421 etc
[02:41] <mpt> BLOCKED: no
[02:41] <Ubugtu> Malone bug 2421 in launchpad "Hackergotchi field should be on Edit Details page" [Normal,In progress]  http://launchpad.net/bugs/2421
[02:41] <stub> DONE: Updated Z3.2 branch, DBA and production bitch for sprinters, text search bug fixes
[02:41] <stub> TODO: Land Z3.2 branch, text searching improvements
[02:41] <stub> BLOCKED: SteveA looking at final 3 failing tests in Z3.2 branch and approval
[02:41] <matsubara> DONE: email catch up, fixing advanced bug search form validation;
[02:41] <matsubara> TODO: finish fixing the above bug, fix more oops bugs, fix bug counts in portlet;
[02:41] <matsubara> BLOCKED: No
[02:41] <bradb> DONE: End of London sprint. Put security teams into review queue. Some code review. Helped some devs test some issues while upgrading to dapper.
[02:41] <bradb> TODO: Talk to kiko about upcoming priorities (I'd love to focus on building unbelievably good reports.) Nag the sec teams work through review.
[02:41] <BjornT> DONE: catching up with emails. looked at various bugs. started at adding support for syncing debbugs bug watches
[02:41] <bradb> BLOCKED: No.
[02:41] <BjornT> TODO: finish debbugs bug watch support. email notifications when bug watches are updated.
[02:42] <BjornT> BLOCKED: no
[02:42] <spiv> DONE: sprint :).  Also SFTP fixes.
[02:42] <spiv> TODO: Help shrink review queue, twisted web server for PersonalPackageArchivesStageOne.
[02:42] <spiv> BLOCKED: no
[02:42] <jamesh> DONE: sprint, upgrade to dapper, pending-reviews script updates, oops script update, some work on tachandler and project-bugs branches.
[02:42] <jamesh> TODO: finish off importd error reporting, other importd stuff.
[02:42] <jamesh> BLOCKED: no
[02:42] <kiko> DONE: gotten back, rosetta spec cleanup, bugfixes, cleaned up trees, developing rosetta project
[02:42] <kiko> TODO: more of the same
[02:42] <kiko> BLOCKED: no
[02:43] <SteveA> TODO: failing tests in Z3.2 branch, land new launchpad fancy menus, look into canonical urls for librarian files, land crowd control from the magic DVD
[02:43] <SteveA> DONE: sprinting and vacating
[02:43] <SteveA> BLOCKED: no
[02:43] <jordi> DONE: discuss rosetta article, queue product series imports; email
[02:43] <jordi> TODO: FAQ updates, imports
[02:43] <jordi> BLOCKED: no
[02:44] <carlos> DONE: User support, lots of dapper import reviews, debug #32610, bug #1982, started the implementation of automatic KDE imports into Rosetta
[02:44] <Ubugtu> Malone bug 1982 in rosetta "System Error on tar.bz2 upload" [Normal,In progress]  http://launchpad.net/bugs/1982
[02:44] <carlos> TODO: finish KDE support, handle more imports for dapper, script to migrate translations from breezy to dapper, bug #36843
[02:44] <carlos> BLOCKED: no
[02:44] <Ubugtu> Malone bug 36843 in rosetta "Problem with wrapping in file ooo-help; file has errors" [Normal,Confirmed]  http://launchpad.net/bugs/36843
[02:45] <kiko> SteveA, anything else?
[02:45] <SteveA> i think.... not!
[02:45] <SteveA> MEETING ENDS.  thanks everyone
[02:45] <kiko> :)
[02:45] <SteveA> i'll do the summary
[02:45] <carlos> just in time!
[02:45] <carlos> ;-)
[02:46] <BjornT> stub: is the send-bug-notifications.py cronscript running on production?
[02:46] <ddaa> Rah sorry, wireless being very flaky
[02:46] <ddaa> did you guy got the text I typed?
[02:46] <stub> BjornT: yes, but I bumped it back to twice a day to avoid spam
[02:46] <stub> (of me - not users)
[02:47] <ddaa> Here are my three sentences:
[02:47] <ddaa> DONE: sprint + bzr meeting
[02:47] <ddaa> TODO: figure out work plan, native bzr imports
[02:47] <ddaa> BLOCKED: no
[02:47] <carlos> jordi: would you answer Tom at rosetta-users about OLPC?
[02:47] <kiko> BjornT, I'm confused. if the script runs twice a day, then.. when do we send email?
[02:47] <stub> BjornT: It needs that user created - connecting as the launchpad user is naughty
[02:48] <Kinnison> kiko: was that mail I sent about the publisher helpful?
[02:48] <SteveA> ddaa: i guess we should talk about your workplan later
[02:48] <jordi> yes
[02:48] <kiko> Kinnison, yes, very much -- will give us a good lead into starting improving performance there
[02:48] <BjornT> stub: was it really spamming you if you ran it with -q? twice a day is not good.
[02:48] <kiko> does this mean we are only sending bugmail out twice a day or not?
[02:48] <ddaa> SteveA: that would be nice
[02:48] <stub> BjornT: Ohh..... sorry. I thought you were talking about staging.
[02:48] <stub> Didn't that script fail on staging?
[02:48] <kiko> it did because of a security issue,no?
[02:49] <stub> Yes - so it will fail on production too
[02:49] <kiko> not fixable?
[02:50] <BjornT> stub: i assumed it failed due to using a copy of production's db, which didn't have the correct schema and security settings?
[02:51] <BjornT> stub: anyway, you did roll it out to production, so let's hope it works ;) can you run it and see how it works?
[02:51] <stub> BjornT: staging is using a copy of production's db, so if security stuff is incorrect there it is because it is incorrect on production. This is why we have staging - to duplicate the production environment as closely as possible.
[02:52] <stub> BjornT: Please land a fix with the correct security settings ASAP. Otherwise it will break next time I reset security on the database.
[02:53] <BjornT> stub: yes, but when the script ran on staging, production didn't have that cronscript, and thus production didn't have the relevant table and security setting.
[02:53] <stub> BjornT: When running on staging, it has nothing to do with production.
[02:54] <kiko> BjornT, the staging "rollout" pulls the database and then applies patches upon it, right?
[02:54] <stub> BjornT: Staging is a duplicate of production, upgraded with the database patches required for that code release.
[02:54] <kiko> otherwise nothing would work!
[02:55] <stub> It seems to have run, anyway, which is odd.
[02:56] <BjornT> i'm confused as well, the launchpad user has the required permissions, so i don't see how the permissions could be wrong.
[02:57] <kiko> mpt, bradb: ping?
[02:57] <kiko> https://launchpad.net/products/launchpad/+bug/30680/+index
[02:57] <Ubugtu> Malone bug 30680 in launchpad "presenting SSL client certificate from unknown CA prevents connect to https://launchpad.net" [Normal,Unconfirmed]  
[02:57] <kiko> the text saying "This report is a duplicate of bug #6659" is pretty faint
[02:57] <Ubugtu> Malone bug 6659 in launchpad "Launchpad requests user certificate from Safari, MSIE/Windows, MSIE/Mac" [Major,Fix released]  http://launchpad.net/bugs/6659
[02:57] <mpt> stub, for people who don't Shift+reload, Launchpad alert messages are going to look a bit odd for the next 22 hours until their cached copy of launchpad.css expires.
[02:58] <kiko> aha.
[02:58] <mpt> This time the problem is relatively minor, but a later time it might not be.
[02:58] <kiko> nice!
[02:58] <mpt> stub, is there an easy way to sunset the cache headers for launchpad.css when a rollout is approaching?
[02:58] <kiko> hoho
[02:59] <kiko> mpt, I have an interesting bug for you
[02:59] <mpt> launchpad.js too, I suppose
[02:59] <stub> mpt: Nope. Better option is to stick a version number in the URL.
[02:59] <kiko> what?!
[02:59] <kiko> are you serious? you can't expire the pages?
[03:00] <stub> Even if we set all the cache headers, we can't control what happens with all the proxies out there.
[03:00] <stub> So the only solution for everyone is to change the URL if it is important.
[03:00] <mpt> stub, it's HTTPS, I don't think proxies dare mess with that
[03:01] <stub> I guess. Still - we have no way of adjusting the cache control heads on the live system, or a config option that would take effect on a server restart.
[03:01] <mpt> poot.
[03:02] <kiko> oh, that's the real reason
[03:02] <stub> The stuff served via the resource directive is all Z3 code, so we might be able to add the necessary functionality in there.
[03:03] <stub> There is a bug open saying we want to set cache headers on the front page
[03:04] <mpt> Currently the front page contains nothing dynamically interesting, but eventually it will
[03:04] <stub> Cool - I'll close that bug then ;)
[03:06] <stub> BjornT: How often should send-bug-notifications run?
[03:06] <kiko> every 5 minutes
[03:06] <BjornT> stub: yeah, every 5 minutes. i'll make it connect as a different db user today.
[03:06] <stub> So it is smart enough to say 'batch and send all pending notifications if there was a pending notification older than 5 minutes'?
[03:07] <ajmitch> how often are uploads processed? I don't seem to have got notification for one done ~50 minutes ago
[03:07] <stub> Or does it just say 'batch and send all pending notifications'?
[03:08] <BjornT> stub: currently it just says 'batch and send all pending notifications'. i'm going to talk with you later about how to optimize it, currently a lot is done in python code.
[03:09] <BjornT> stub: although, it only sends them if they are more than 5 minutes old
[03:09] <kiko> spiv, stub, the buildd slave scanner is currently unable to access the librarian
[03:09] <stub> There is a badly handled edge condition there - if I do two things to a bug, one at 1:59:59 and another at 2:00:01, there will be two emails
[03:09] <stub> BjornT: Oh.. that is cool then.
[03:09] <stub> So five minutes is good ;)
[03:10] <stub> installed anyway
[03:10] <BjornT> cool
[03:10] <kiko> ajmitch, they are processed pretty frequently, but I'm not sure when you get the email -- Kinnison would know
[03:13] <kiko> mpt, ping
[03:13] <mpt> kiko, pong
[03:14] <mpt> I should not still be awake
[03:15] <kiko> mpt, could you update your last statement in bug 6081?
[03:15] <Ubugtu> Malone bug 6081 in launchpad "Launchpad is too difficult to find on the Web" [Normal,In progress]  http://launchpad.net/bugs/6081
[03:15] <kiko> it's slightly offensive and not really true.
[03:15] <kiko> BjornT, ping?
[03:16] <kiko> BjornT, uhm, kinda urgent, too
[03:18] <BjornT> kiko: pong
[03:19] <kiko> BjornT, not so urgent now that I think I understand it, but can you explain why we got mailed when doko duped bug 32610 and bug 34580
[03:19] <Ubugtu> Malone bug 32610 in openoffice.org "all untranslated messages imported from OOo are marked as translated" [Normal,Unconfirmed]  http://launchpad.net/bugs/32610
[03:19] <Ubugtu> Malone bug 34580 in ia32-libs-gtk "it cannot be installed" [Normal,Needs info]  http://launchpad.net/bugs/34580
[03:19] <mpt> kiko, whose job is it to update www.ubuntu.com other than Henrik, who's very busy with other things?
[03:20] <kiko> henrik has time to update the website when you ask him for it
[03:20] <kiko> and you never reported any problems (or escalated them) before posting that message, which is in bad form
[03:21] <BjornT> kiko: because Launchpad Developers are subscribed to bug 34084
[03:21] <Ubugtu> Malone bug 34084 in ia32-libs-gtk "ia32-libs-gtk can't be installed" [Normal,Needs info]  http://launchpad.net/bugs/34084
[03:21] <mpt> Where do I report them? Bugzilla is closed, and Malone doesn't have an "Ubuntu Web sites" product
[03:22] <kiko> mpt, at least email would be a good start, but you can IRC or email him about setting up a component
[03:22] <Kinnison> stub: ping
[03:22] <kiko> BjornT, yeah; is that a special case?
[03:22] <stub> Kinnison: poong
[03:23] <Kinnison> stub: did you apply a db patch without updating the codebase on drescher?
[03:23] <stub> I updated the codebase on drescher
[03:23] <Kinnison> stub: but not the 'current' symlink
[03:23] <Kinnison> stub: arse
[03:23] <kiko> mpt, as I am doing so in #canonical now.
[03:24] <stub> I recall doing that too
[03:24] <Kinnison> lp_archive@drescher:/srv/launchpad.net/codelines$ ls -l
[03:24] <Kinnison> lrwxrwxrwx   1 lp_archive lp_archive   42 Mar 24 16:52 current -> soyuz-production_20060324+typofix-dsilvers
[03:24] <stub> Must have missed hitting enter or something stoopid
[03:24] <Kinnison> never mind
[03:24] <Kinnison> easy to fix
[03:24] <kiko> enter is a pretty important key!
[03:24] <doko> kiko: it's not possible to add another package to an existing bug report. is this by intent?
[03:25] <kiko> doko, I believe so; what is the situation, that this bug affects multiple packages
[03:25] <kiko> ?
[03:25] <BjornT> kiko: ah, i think that previously this only happened for comments, they got sent to the duplicate bug's subscribers as well. now also status changes go to the duplicate bug's subscribers.
[03:26] <kiko> BjornT, that's great -- but I wonder if it wouldn't be easier just to add the subscribers of the duped bug to the main one. anyway, good work.
[03:28] <BjornT> kiko: they should be displayed in the subscriber portlet, but they shouldn't really be added, in case of someone duping the wrong bug and then undupes it.
[03:28] <kiko> BjornT, I see
[03:29] <BjornT> kiko: this is specified in https://wiki.launchpad.canonical.com/DuplicateBugHandling
[03:29] <doko> kiko: a fix needs modifications in two packages; normally I would do that with a meta report, that depnds on two other reports assigned to the single packages.
[03:33] <seb128> hi
[03:34] <kiko> BjornT, okay, cool -- yeah, it's a feature
[03:34] <kiko> doko, mmmmm
[03:34] <seb128> new mail format is really confusing
[03:34] <seb128> why did you change it?
[03:34] <kiko> seb128, to inconvenience you, of course! :)
[03:35] <seb128> seems so :p
[03:35] <kiko> bradb, BjornT: so we don't allow a bug that has two (ha ha can't say it) things on two different packages?
[03:35] <seb128> I can't work with those new mails, I'll have to switch to use the web UI now
[03:36] <kiko> seb128, I wonder what part is bothering you in particular
[03:36] <seb128> the format
[03:37] <seb128> there is no clear separations between categories (comment, settings change, url)
[03:37] <bradb> kiko: can't say it? "a bug that's reported in two places".
[03:37] <seb128> mails starts about a "*** This bug is a duplicate of bug 20302 ***" which 
[03:37] <Ubugtu> Malone bug 20302 in control-center "Mute key popup is odd" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/20302
[03:37] <seb128> 1- I don't care about
[03:37] <seb128> 2- makes harder to figure what the bug is about
[03:37] <seb128> you have to parse instead of just read from the top
[03:38] <seb128> having the title to the mail content is confusing too
[03:38] <seb128> I've already the mail title, it's weird to have to parse what is the new comment and what is a copy of the mail title
[03:39] <bradb> kiko: we do, of course, allow a bug to be reported on more than one package. what makes you think otherwise?
[03:39] <seb128> not to mention that gratious changes when people are used to something are confusing
[03:39] <kiko> bradb, the fact that doko is saying it isn't possible.
[03:39] <seb128> couldn't that sort of change be discussed first with some rationnal?
[03:39] <kiko> seb128, there is a rationale, even though we perhaps didn't discuss it as openly as we could have -- it was in a specification though
[03:40] <bradb> kiko: from my reading of what he's saying, he's trying to apply a different workflow he knows from some other system to Malone.
[03:40] <Kinnison> stub,kiko: we'll get the mails from the buildd sequencer until Znarl finishes updating the firewall for the buildds to the new librarian IP
[03:40] <bradb> doko: have you tried adding another package to the same bug report?
[03:40] <kiko> bradb, no, he's saying he can't have two tasks on different packages for the same bug.
[03:40] <seb128> I may have some working habits right
[03:40] <ajmitch> bradb: is it possible for bugs to be submitted by mail without GPG-signing now?
[03:41] <seb128> what is the point to break people workflow every now and then without discussing it if there is some win to do so?
[03:41] <doko> bradb: yes, by replacing the source package in the URL
[03:41] <bradb> ajmitch: not yet
[03:41] <ajmitch> ok
[03:41] <stub> Kinnison: Ahh... fallout from the SSL request.
[03:41] <bradb> doko: you have to use the "Also affects" links on the bug page to add another affected package
[03:41] <kiko> seb128, at any rate, we'll tweak the format over this week; the change is actually an improvement in many fronts -- for instance, duplicate bugs now email all the correct parties, and mail notifications are batched in 5-minute windows so you should get less bugspam.
[03:42] <stub> Kinnison: Unless you can be arsed setting the http_proxy environment variable on them to use the internal proxy.
[03:42] <Kinnison> stub: they probably don't have access to that either
[03:42] <Kinnison> stub:  the buildds are seriously locked down
[03:43] <seb128> kiko: cool, but I still think there should be some public discussion before forcing a new formatting over users like that
[03:43] <bradb> doko: does that make sense?
[03:43] <doko> bradb: ahh, ok. although the shortcut was nice
[03:43] <seb128> kiko: we have enough work without fighting with the tools because you guys change it for random reasons like that
[03:43] <kiko> seb128, yeah.
[03:45] <bradb> mpt: oh, hm: https://launchpad.net/distros/ubuntu/+source/firefox/+bug/6367
[03:45] <Ubugtu> Malone bug 6367 in grub-installer "IDE enumeration differs between docked and undocked on ThinkPad T42" [Critical,Confirmed]  
[03:45] <kiko> how interesting
[03:45] <bradb> how mangled!
[03:46] <kiko> file a bug!
[03:47] <bradb> bug 37337, for mpt
[03:47] <Ubugtu> Malone bug 37337 in malone ""Also Needs Fixing Here" area mangled" [Normal,Confirmed]  http://launchpad.net/bugs/37337
[03:48] <bradb> doko: btw, the "Also Needs Fixing Here" button should work, so if you clicked it and got an error, that's a bug
[03:50] <doko> bradb: hmm, I'm blind, where is this button?
[03:51] <bradb> doko: for example: https://launchpad.net/distros/ubuntu/+source/firefox/+bug/6367
[03:51] <Ubugtu> Malone bug 6367 in grub-installer "IDE enumeration differs between docked and undocked on ThinkPad T42" [Critical,Confirmed]  
[03:52] <bradb> doko: it's the button under the sawed-off red div at the top
[03:52] <bradb> "Also Needs Fixing Here"
[03:52] <bradb> It is hard to see though
[03:54] <bradb> hm, that div seems to be a p, which may be the problem
[03:55] <doko> bradb: but not on https://launchpad.net/distros/ubuntu/+source/openoffice.org/+bug/21204
[03:55] <Ubugtu> Malone bug 21204 in openoffice.org "ooo2 doesnt work with gnome 2.12's clipboard management" [Wishlist,Confirmed]  
[03:56] <bradb> doko: right, because you're viewing the bug in a context where it's already reported
[04:00] <kiko> bradb, funny how the context is just ignored :)
[04:01] <doko> bradb: do I have to understand that?
[04:03] <bradb> doko: no. just use the "Also affects" links if you want to report the bug in another package. :)
[04:04] <doko> waiting for "launchpad in a nutshell" and "launchpad for dummies" ;)
[04:04] <bradb> the bug page I prototyped has a "Report this bug in another Ubuntu package" link but, for now, you have to submit to "Also affects" -> "Distribution"
[04:06] <bradb> doko: i'd rather you not have to read documentation to do what should be simple things in a bug tracker
[04:20] <ploum> Hello
[04:21] <ploum> Just a question
[04:21] <ploum> Must be all "team" useful ?
[04:21] <ploum> I just tought about creating a team for my LUG in launchpad
[04:21] <ploum> but it's not really useful for Ubuntu
[04:22] <ploum> What are the recommandations about this ?
[04:24] <seb128> ploum: hi, just approved you for desktop-bugs btw :)
[04:25] <ploum> seb128: thanks :-)
[04:25] <seb128> thank *you* for the triage work ;)
[04:25] <ploum> I was not sure if I could join  bugsquad or desktop-bugs
[04:25] <ploum> you are welcome
[04:34] <bradb> ploum: Launchpad is not Ubuntu-specific. It probably makes sense to create a team in Launchpad only if you intend for that team to be fix bugs, get bugmail, do translations, write specs, etc. using Launchpad.
[04:35] <ploum> bradb: that makes sense, thanks :-)
[04:36] <seb128> bradb: is there any pointer with the rationnal of why you changed the bug mails that way?
[04:39] <bradb> seb128: We're on the same page in the book of wonder, but there's a spec, if you're really curious.
[04:39] <seb128> bradb: who decided about it?
[04:40] <bradb> seb128: the spec author, i think. :)
[04:40] <bradb> https://wiki.launchpad.canonical.com/MaloneEmailMessages
[04:41] <seb128> "#
[04:41] <seb128> Created: 2006-02-18 by MarkShuttleworth
[04:41] <seb128> "
[04:41] <seb128> hum :)
[04:42] <siretart> bradb: are there any plans to do something about the requirement for a signature on every bug submission/change?
[04:44] <bradb> siretart: I hope so. kiko, how likely is it that we'll remove the restriction to gpg-sign bugmail for anything other than operations that either toggle the bug privacy flag, or try to operate on private bugs?
[04:46] <siretart> that would be great. 
[04:47] <siretart> if this would mean that even bugsubmission could be done anonymous, then we could fix reportbug to report ubuntu bugs in malone
[04:48] <bradb> Getting reportbug and bug-buddy to work would seriously rock, though anonymous bug reporting (or figuring out how else these tools will report bugs to Malone) will require more thought.
[04:49] <siretart> I see
[05:12] <siretart> can launchpad handle svn branches as well? I'd like to have a package svn repo imported/accesible via bzr as well
[05:22] <SteveA> siretart: ddaa works on the systems that import code from svn, and makes it available as bzr branches. 
[05:22] <SteveA> please send a message to launchpad-users about what you want, and cc ddaa on it
[05:27] <siretart> SteveA: ok. will do
[05:27] <SteveA> thanks!
[05:47] <BjornT> kiko, SteveA: anyone available for a small review?
[05:50] <SteveA> hi BjornT 
[05:50] <SteveA> i can do it
[05:50] <BjornT> SteveA: thanks. https://chinstrap.ubuntu.com/~dsilvers/paste/filetQKN6g.html
[05:51] <BjornT> SteveA: it's fixing an assertion that send-bug-notifications.py triggered
[05:52] <kiko> I am
[05:55] <SteveA>              if notification.is_comment:
[05:55] <SteveA>                  if has_comment:
[05:55] <SteveA>                      yield construct_email_notification(notifications_to_send)
[05:55] <SteveA>                      notifications_to_send = [] 
[05:55] <SteveA>                  has_comment = True
[05:55] <SteveA> 
[05:55] <SteveA> that may be a little simpler
[05:55] <SteveA> what say you?
[05:55] <SteveA> you could even put the has_comment = True in an else
[05:56] <SteveA> to make it clear that this is set only once
[05:56] <BjornT> SteveA: yeah, that's clearer, i'll change it.
[05:57] <SteveA> r=me
[05:58] <BjornT> thanks
[05:58] <SteveA> BjornT: i'm not sure about the name has_comment now though
[05:59] <SteveA> it is not used for a universally true "this notification has a comment" but rather it means "have we seen a comment yet?"
[05:59] <SteveA> perhaps a name that reflects that would make the code clearer
[06:02] <BjornT> SteveA: actually, it is used as "this notification has a comment." maybe i should rewrite it to make it clearer, and add back the has_comment = False statement.
[06:02] <SteveA> ah, okay
[06:02] <SteveA> in that case, i'd do
[06:02] <SteveA>   if notification.is_comment: has_comment = True
[06:02] <SteveA>   if has_comment:
[06:02] <SteveA>    whatever
[06:03] <SteveA> that keeps it simpler
[06:05] <BjornT> it's not that simple though. if we have [change, comment, change] , only one notification should be sent.
[06:05] <SteveA> i see
[06:05] <SteveA> i guess i'd need to see the wider context than that diff
[06:06] <SteveA> anyway, i'm sure you'll make it as simple as it can get :-)
[06:25] <carlos> will be back in less than one hour
[06:57] <dilys> Merge to devel/launchpad/: [r=stevea]  fix a bug which caused send-bug-notifications.py to trigger an assertion. (r3362: Bjorn Tillenius)
[07:27] <kiko> thanks BjornT 
[08:07] <LeeJunFan> Anyone here in charge of ubuntu mirrors know that the mirrors lack the Packages files, the .gz and .bz2 are there, but not plaintext.
[08:09] <kiko> I think that was a voluntary change. Right Kinnison, elmo?
[08:10] <LeeJunFan> kiko: it breaks debmirrors ability to make mirrors. :(
[08:11] <kiko> really?
[08:11] <LeeJunFan> kiko: yeah, debmirror wants the plaintext version.
[08:21] <Surak> Hello
[08:25] <sabdfl> hi Surak
[08:26] <KurtKraut> How is able to close tickets/change status at the 'Support' session in Launchpad ?
[08:28] <Surak> One question. There are three different "portuguese" languages available in rosetta. pt_PT, pt_BR and just pt. What intrigues me is this 'pt' one. It says that there are 182694 translatable items and 182139 already translated. However, it has only one template added there - kaffeine (which is fully translated).
[08:29] <mdke> Surak, you should ignore that one
[08:29] <KurtKraut> Who is able to close tickets/change status at the 'Support' session in Launchpad ?
[08:30] <Surak> mdke: I do, even because there's nothing that can be done with it. I was just curious about it.
[08:30] <mdke> Surak, its presence is due to a bug in rosetta
[08:32] <Surak> Another question. Currently I translate for ubuntu in rosetta, and translate for fedora using manual processes. Being member of the pt_BR Fedora translation team, I proposed that we use rosetta for Fedora also. The team accepted. I already registered a project in launchpad, but I'm a little lost about what to do next to set up fedora's packages for translation.
[08:34] <Surak> Are these steps correct? Create a project, create then a branch and... ?
[08:36] <mdke> that's rather complicated.
[08:36] <Surak> Oh! another question. I read Jane's email today. Kamion reports that espresso is in rosetta already. It doesn't appear in pt_BR, though.
[08:36] <mdke> you should email the mailing list about the fedora thing
[08:37] <mdke> yeah, I don't see espresso either, another email to the list
[08:38] <Surak> mdke: I currently have r/w access to the fedora cvs. What I would like to know is how are those thing integrated. Can launchpad access the fedora's cvs automatically and sync the translations or is it up to me to manually download the PO files and upload them to fedora cvs?
[08:39] <mdke> Surak, the process will be more complicated: it's likely a new distribution will have to be created, etc
[08:41] <Surak> mdke: ok. This can be done by me or is someone from launchpad required to perform this? Remember, this is intended to be used for pt_BR only.
[08:42] <mdke> yeah. you'll need a launchpad developer to answer your question, I don't know. best to email the list
[08:43] <Surak> hum. "Translate your favorite distro using launchpad HOWTO" returned zero results in google ;-)
[08:44] <mdke> heh
[08:50] <matsubara> Surak: you can ask carlos or jordi about that.
[08:51] <carlos> Surak: mdke: pt_BR is for Brazilian Portuguese
[08:51] <carlos> pt is for Portuguese from Portugal
[08:51] <carlos> pt_PT should disappear 
[08:52] <carlos> at least that's what the Portuguese people asked
[08:53] <KurtKraut> this is a mistake. It makes looks like there is a official or better Portuguese, and the other ones are 'copies' 
[08:54] <KurtKraut> Each portuguese 'version', even pt_PT, pt_BR and others are evolving alone. They should be treated as separeted languages
[08:54] <Surak> mdke: thanks. Is there a specific mailing list for that? I could not find any launchpad-related at http://www.ubuntu.com/community/lists
[08:55] <Surak> carlos: how are the locales handled? I assume pt_PT is for portugal, isn't it?
[08:55] <carlos> Surak: yes
[08:55] <carlos> Surak: but pt also works
[08:55] <carlos> for all pt_* locales
[08:56] <carlos> KurtKraut: well, we do what translation teams ask, we can only suggest
[08:57] <carlos> and most portuguese from portugal translations (outside Ubuntu) are using the 'pt' locale
[08:57] <Surak> carlos: the argument from KurtKraut is valid. this assumes that a non-translated string from pt_BR can be brought from pt by inheritance, or fallback. Is something like that?
[08:57] <carlos> Surak: yes
[08:57] <KurtKraut> it will crack up locales.
[08:58] <KurtKraut> Many computer related terms are pretty understandable between diferent 'versions' of portuguese.
[08:58] <carlos> KurtKraut: I'm aware of all those issues, we have people from Brazil in our team
[08:59] <carlos> but as you should understand, we cannot move the whole locale just for Ubuntu
[08:59] <carlos> that's something that should be done by upstream
[08:59] <carlos> we can fix it if the amount of files is low
[08:59] <KurtKraut> how this discussion started in Ubuntu could be brought to uptstream in order to fix it ?
[09:00] <KurtKraut> because, as the times goes by, it will became a mess :P
[09:00] <carlos> but if it's high... as is the case with 'pt'... we cannot fix it easily without doing the translation merge from upstream really hard.
[09:01] <carlos> KurtKraut: talk with GNOME and KDE translation teams
[09:01] <carlos> they have the higher number of pt.po files
[09:01] <KurtKraut> carlos, ok
[09:02] <Surak> KurtKraut: the case is that portuguese is THEIR language. They are very fond of it. That's why computer terms brazilians doesn't even bother to translate (think mouse for instance) have all their own portuguese terms in pt_PT.
[09:03] <KurtKraut> Surak, portuguese is OUR, not theirs. Despite our grammar is fully based on their language, these languages are evolving alone, mainly when dealing with techy terms such as 'mouse'.
[09:04] <carlos> WTF... my ISP banned l10n-status.gnome.org page.... they say it has forbidden contents... the parental control...
[09:05] <LarstiQ> carlos: eek
[09:05] <KurtKraut> carlos, wow... crazy thing :P
[09:05] <Surak> mdke: what is the correct mailing list to discuss the the project I propose?
[09:06] <Surak> carlos: were you here when I was talking with mdke?
[09:07] <Surak> g/were/was (i never know)
[09:07] <carlos> Surak: 'were'
[09:07] <carlos> Surak: yes, just saw your request about importing Fedora
[09:07] <carlos> and expresso
[09:07] <carlos> expresso is part of the Debian installer
[09:08] <carlos> so you should translate the Debian installer to get expresso transalted too
[09:08] <carlos> about Fedora...
[09:08] <carlos> Surak: our policy says that we should not import it
[09:09] <carlos> unless the whole Fedora translation team accepts to use it or sync translations
[09:09] <carlos> I guess we could do something using our translation team infrastructure 
[09:09] <carlos> allowing only translations from your team or any other team that want to use Rosetta...
[09:10] <carlos> also, there is another problem to solve, the sync from Fedora's CVS into Rosetta...
[09:10] <carlos> we have some work done to import GNOME's CVS into Rosetta but it's not finished
[09:10] <carlos> so we cannot do it automatically atm
[09:12] <dilys> Merge to devel/launchpad/: [trivial]  Fix bug 28698 ("Fix committed" bugs are treated as "resolved" bugs) (r3363: Brad Bollenbach)
[09:12] <Surak> carlos: where do I see about this policy?
[09:14] <carlos> Surak: you should read the FAQ page https://wiki.ubuntu.com/RosettaFAQ
[09:14] <carlos> the policy is at https://wiki.launchpad.canonical.com/RosettaNewImportPolicy
[09:18] <Surak> carlos: thanks. I will read them carefully and come back to talk about it. 
[09:18] <kiko> good work bradb
[09:19] <SteveA> Surak: the main thing is that there needs to be some kind of a communication with the people who write and maintain the software.
[09:19] <carlos> Surak: sure, if I'm not around, jordi can help you too
[09:20] <SteveA> this can be that they decide to use rosetta as their main place for doing translation, or it can be that someone agrees to take translation data from rosetta, and incorporate it into their ongoing work on the software
[09:20] <SteveA> on a regular basis
[09:20] <Surak> SteveA: actually I am one of those responsible for the pt_BR translation. The team has already agreed that rosetta is the place we aim to put every pt_BR translations.
[09:21] <kiko> Surak, SteveA is talking about the people who write /the software/
[09:21] <kiko> they need to actively work with Rosetta to feed in and pull out updates
[09:23] <SteveA> Surak: do you have rights to check into the fedora CVS?
[09:23] <Surak> kiko: in what level? we can be talking about the redhat people or upstream. ie gnome.
[09:23] <Surak> SteavA: yes
[09:24] <Surak> ops: SteveA.
[09:24] <SteveA> then that is fine, i think.  if you make a commitment to regularly pull work done in rosetta into the CVS, that will make sure that people's translations will be used somewhere.
[09:24] <SteveA> what do you think carlos and kiko?
[09:28] <carlos> SteveA: I need to check somethings first
[09:28] <kiko> that's the way to go, I believe
[09:28] <SteveA> Surak: we'll have a think about how to do this, and get back to you
[09:30] <Surak> SteveA: ok. While this happens, I will keep up in touch with the rest of fedora pt_BR people, and read the links carlos just sent me. Thanks all for your attention.
[10:26] <matsubara> does anybody know what happened to staging?
[10:31] <SteveA> the main thread isn't dispatching to application threads
[10:33] <SteveA> Znarl or elmo: I want to get a package installed on staging so that i can diagnose why staging has hung
[10:34] <SteveA> matsubara: do you need staging to be working right away, or can i try to diagnose the problem while it is hung?
[10:35] <matsubara> SteveA: nothing urgent. go ahead with the diagnosis. thanks
[10:36] <matsubara> SteveA: fwiw, it's been like that for awhile.
[10:38] <SteveA> thanks elmo
[10:58] <SteveA> matsubara: i'm wondering whether to leave staging hung for the next couple of hours, until lifeless is around
[10:58] <SteveA> i can't get his instructions on getting a python backtrace to work properly
[10:59] <matsubara> SteveA: no problem for me. I'm already working in other things. 
[10:59] <matsubara> carlos: is there a bug open for OOPS-87A300 ?
[10:59] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/87A300
[10:59] <carlos> matsubara: yes, kiko filed one some months ago
[11:00] <carlos> let me look for it...
[11:01] <carlos> mpt_: https://launchpad.net/products/rosetta/+bugs
[11:01] <carlos> we have overflow there even with the two columns layout
[11:04] <carlos> matsubara: I don't find the bug report... so perhaps it was never filed...
[11:05] <carlos> see you later
[11:05] <matsubara> carlos: bug 2898
[11:05] <Ubugtu> Malone bug 2898 in rosetta "Adding the same potemplate twice causes system error" [Minor,Rejected]  http://launchpad.net/bugs/2898
[11:05] <matsubara> hmm
[11:05] <carlos> matsubara: yeah, that one
[11:05] <matsubara> actually it's not that one.
[11:06] <carlos> hmm, well, it sounds like it
[11:06] <carlos> but no, it's not that one...
[11:06] <carlos> perhaps that's why I was confused about having it already...
[11:06] <carlos> see you later
[11:06] <matsubara> no problem, I'll file a new one
[11:06] <matsubara> see ya
[11:06] <matsubara> have a nice dinner
[11:06] <carlos> matsubara: ok, thank you!
[11:18] <SteveA> lifeless: i've left staging's web app server in a hung state, for you to try to debug.  you have mail about it.
[11:41] <lifeless> moin moin
[11:41] <ajmitch> hi
[11:41] <tseng> hi.
[11:42] <tseng> i dont have that bugmail yet
[11:50] <lifeless> ajmitch: whatsup ?
[11:52] <ajmitch> just running into malone problems again
[11:53] <ajmitch> apart from that, not a lot :)
[11:57] <kbrooks> how do i get ALL (every single) bug ever filed in a project?
[11:57] <lifeless> probably via the advanced search
[11:58] <kbrooks> i click on "all bugs ever reported" - no workie
[11:58] <lifeless> hmm, I'm in the middle of something right now, perhaps you could file a bug? or perhaps mpt__ or spiv are around and can comment..
[11:58] <ajmitch> that bug is known, you have to use advanced search for now
[11:59] <kbrooks> i uncheck everything in advanced search and it doesnt work
[11:59] <ajmitch> you need to select all the statuses, I think