[12:18] <andrewski_> what does it mean to "sign" a code of conduct?  is that like saying that you've read it?  because i know very little about OpenPGP and such, but i'm not sure if signing it is a measure of good faith or somesuch.
[12:21] <Kaiser_Sleeps> andrewski_: it means you read it and agree to abide by it, then you can downlod it, clearsign it with gpg,  and paste the output into that window
[12:21] <andrewski_> Kamping_Kaiser: ah, ok.  so i need to download it first to sign it, eh?  could that be made a bit clearer on the site?
[12:22] <Kamping_Kaiser> andrewski_: http://ubuntu.pastebin.com/541507
[12:22] <Kamping_Kaiser> yeh. i commented yesterday
[12:22] <andrewski_> Kamping_Kaiser: ah, ok. :)  cheers.
[12:23] <Kamping_Kaiser> :)
[12:23] <andrewski_> should i set up gpg first?  do i need to "personalize" it?
[12:23] <Kamping_Kaiser> you need a gpg key
[12:23] <Kamping_Kaiser> if you have that, you can sign it
[12:23] <Kamping_Kaiser> oh
[12:23] <andrewski_> ah, ok.  i think i have one on my desktop... lemme fire up ssh. :)
[12:23] <Kamping_Kaiser> you need to have your key registed with launchpad IIRC
[12:24] <andrewski_> ok, i see that page too.
[12:28] <andrewski_> Kamping_Kaiser: any idea which key i'm supposed to send with 'gpg --send-key'?
[12:29] <Kamping_Kaiser> hm? wichever you want to use in future work with launchpad/other ubuntu stuff
[12:30] <andrewski_> ok, so pubring.gpg is fine?
[12:30] <andrewski_> (like i said, i know little about gpg. :)
[12:30] <Kamping_Kaiser> andrewski_: i know little as well :) i had to get help setting this up myself :$, and i cant remember
[12:31] <andrewski_> yeah, it doesn't like pubring.gpg.  i'll check the wiki for something.  how do i go about making a suggestion for launchpad stuff?
[12:32] <Kamping_Kaiser> i commented here. 
[12:33] <Kamping_Kaiser> just a minute, I'll try find the gpg page
[12:33] <andrewski_> sounds good to me.
[12:34] <Kamping_Kaiser> https://wiki.ubuntu.com/GnuPrivacyGuardHowto - look at point 5.1 as well :)
[12:36] <andrewski_> Kamping_Kaiser: thank you much; you got to it faster than i. :)  i must be off, but i'll stick around to see if anyone backtracks to read our comments.  tsch!
[12:38] <Kamping_Kaiser> ok mate :)
[01:15] <ddaa> lifeless: I saw you just sent a mail about branch status feedback
[01:16] <ddaa> lifeless: here I just sent an update to the "runnig baz2bzr periodically" task, giving a lot of detail to implement the daily error reporting for buildbot.
[01:24] <spiv> ddaa: Did you see my mail about the buildbot tests?
[01:24] <ddaa> spiv: yes, and I wondered...
[01:25] <ddaa> spiv: did you make all the changed you mentioned?
[01:25] <spiv> ddaa: Yes, whY?
[01:26] <ddaa> it does not read very obviously
[01:26] <ddaa> "the CVS version with the SignalMixin is probably straightforward to backport, if we want it (although I'm not convinced that that's the best way either...)."
[01:26] <spiv> I made sure to run "make check" in sourcecode/buildbot before reporting my results :)
[01:26] <spiv> Oh, right.
[01:26] <spiv> No, I didn't try that.
[01:26] <ddaa> "Here's a diff, against rocketfuel"
[01:27] <ddaa> "Yeah, I think that test is totally irrelevant to us, so skip it."
[01:27] <spiv> Sorry, I sent a diff of what fixes it now (partly by skipping broken tests).
[01:27] <ddaa> So I wondered what was stopping you  from sending the changes to rocketfuel.
[01:27] <spiv> And also suggested ways to unbreak some tests.
[01:28] <spiv> I wanted to run it by you, seeing as you've been working in this area.
[01:28] <ddaa> spiv: I am currently beyond suggestions about anything not involving drugs, sex, and the importd->bzr transition :)
[01:28] <spiv> I'm happy to send the merge request right now if it all makes sense to you :)
[01:28] <spiv> Ok :)
[01:28] <sabdfl> hey all
[01:29] <sabdfl> just got a timeout on /products/gnomebaker/ which was very surprising
[01:29] <ddaa> spiv: please do whatever you think is right to let me merge my pending cscvs changes
[01:29] <sabdfl> is something going on with LP performance?
[01:31] <spiv> Not that I know of, there was a rollout yesterday though.
[01:31] <spiv> What's the OOPS id?
[01:32] <ddaa> sabdfl: I received your mail about the pybaz packaging problem
[01:32] <ddaa> sabdfl: you realize the problem is that pybaz and python-baz are just two packages for the same bit of software, don't you?
[01:32] <sabdfl> spiv: lost the OOPS ID when I reloaded, but it just happened a minute ago
[01:33] <sabdfl> ddaa: in that case, should they not Provide: the same thing? Because installing config-manager pulls in one, and something else pulls in the other.
[01:33] <spiv> sabdfl: Ok, I'll see if I can find it.
[01:34] <ddaa> sabdfl: obviously, the fact they package the same thing shows that the two packagers did not communicate...
[01:36] <ddaa> besides, it looks like only pybaz is on dapper...
[01:37] <sabdfl> ddaa: i'm running dapper
[01:37] <spiv> sabdfl: OOPS-39A13
[01:37] <sabdfl> thanks spiv. anything seem out of the ordinary?
[01:38] <spiv> All fine until a SELECT COUNT(*) with a subselect.
[01:38] <spiv> (on BugTask, Bug, subselect on Bug, BugSubscription, TeamParticipation)
[01:39] <spiv> I wonder if the offending SELECT COUNT(*) will go away next rollout with jamesh's __len__ fix.
[01:40] <spiv> But the page usually is very fast, so I guess there must have been some contention.  I'll get stub's opinion when he wakes up.
[01:43] <sabdfl> just got another timeout
[01:43] <sabdfl> OOPS-39D23
[01:43] <sabdfl> this time on a rosetta page
[01:43] <sabdfl> we need to make eliminating these timeouts amajor goal of ours
[01:43] <ddaa> I'd bet it's browser/bugtask.py:1028
[01:43] <ddaa>         tasklist = self.context.searchTasks(params)
[01:43] <ddaa>         return tasklist[:quantity] 
[01:45] <ddaa> that's run twice by the bugtarget-portlet-latestbugs.pt
[01:45] <ddaa> but spiv is right, this page is usually very fast, so it's probably a contention with something else that's really slow
[02:11] <dilys> Merge to devel/launchpad/: [r=kiko]  extend fmt:text-to-html to turn OOPS codes into links for developers (bug #30645) (r3097: Dafydd Harries)
[02:13] <Kinnison> hey sabdfl 
[02:14] <Kinnison> how's the tour?
[02:14] <sabdfl> hiya Kinnison, happy your baby is in production?
[02:14] <Kinnison> dude you have no idea how high I've been flying
[02:14] <sabdfl> tours going well, not much sleep but otherwise wonderful reception and lots of work
[02:14] <Kinnison> I think I've given C1 a run for its money
[02:14] <sabdfl> wondered what the hell that was outside the window
[02:15] <Kinnison> we did a completely smooth rollout today together
[02:15] <Kinnison> so I'm turning my notes from the process into a document for him
[02:20] <sabdfl> v cool
[02:20] <sabdfl> once we get cron.daily's equivalent back down to once per 30 minutes we will have full equivalence to dak, AIUI
[02:20] <Kinnison> Pretty much
[02:20] <Kinnison> and we're down to an average 20 minute run
[02:21] <Kinnison> James and I seriously improved the dominator's performance on Saturday
[02:34] <sabdfl> you beat the dominator into submission. i like it.
[02:57] <Kinnison> stub: I've sent you a doc
[02:58] <Kinnison> Or at least I thought I had
[02:58] <Kinnison> it has bounced
[02:58] <Kinnison> grah
[02:58] <stub> But I'm fine!
[02:58] <Kinnison> email?
[02:58] <Kinnison> what's your @canonical.com address?
[02:59] <stub> stuart.bishop@canonical.com
[03:00] <Kinnison> sent
[03:00] <Kinnison> and now I sleep
[03:00] <Kinnison> ciau
[03:03] <stub> Night
[03:29] <spiv> stub: sabdfl got OOPS-39A13, but usually that page renders quite quickly.  I guess it was just contention on the tables in the query?
[03:30] <stub> I guess
[03:31] <stub> Not the prettiest of queries
[03:33] <spiv> stub: Was the librarian upgraded in yesterday's rollout?
[03:33] <stub> spiv: Yes
[03:34] <spiv> Ok, so it now has the database name checking in it.
[03:34] <spiv> So it's a matter of upgrading all the clients :)
[03:37] <stub> Hmm... it should enforce that.
[03:38] <spiv> At the moment, it's optional, depending on the client sending the relevant header.
[03:38] <stub> All the time critical stuff is using the new code - anything else that blows up is a backend system that can afford some downtime
[03:38] <spiv> I should make it log a warning everytime a client doesn't send that header.
[03:38] <spiv> Heh.
[03:39] <stub> Logging warnings is only useful if someone is watching the logs :)
[03:41] <spiv> Well, the theory would be that we could look back at the logs to figure out if there's any unupgraded clients left. 
[03:42] <spiv> stub: But here's a 10-second, untested patch to enforce it: https://chinstrap.ubuntu.com/~dsilvers/paste/fileOMXlxG.html
[03:45] <lifeless> spiv: exponential degradataion on the warnings :)
[03:45] <lifeless> spiv: or for cuteness, have a web page on the librarian showing the old clients seen in the last day
[03:46] <spiv> lifeless: ...or, someone could grep the log files that are rsynced to chinstrap already.
[03:46] <lifeless> spiv: I did mention cute didn't I ?
[03:46] <spiv> Even if it is the boring way :)
[04:04] <stub> We don't want old clients. Bad enough tracking down bugs in uptodate clients. Just refuse to talk to them.
[04:58] <stub> lifeless: Can you install config manager into ~pqm/bin on balleny? (or tell me where to find it)
[05:49] <jamesh> stub: "bzr branch http://www.robertcollins.net/config-manager/trunk/"
[06:00] <jamesh> stub: would you be able to delete bugwatch id 353?  It should have remotebug='-42' and bug=5723
[06:11] <mpt_> jamesh, how often are the Oops reports going to be sent?
[06:12] <jamesh> mpt_: I had the script disabled while I was fixing it up to do a short summary to the list + long summary on the web
[06:13] <jamesh> mpt_: I should have that going again today
[06:13] <mpt_> great
[06:26] <stub> jamesh: Deleted
[06:26] <jamesh> stub: thanks
[06:44] <mpt_> What's up with staging?
[06:44] <mpt_> I get Bad Gateway errors for staging.ubuntu.com and staging.launchpad.net
[06:46] <jamesh> the staging config might need updating
[06:47] <jamesh> both bradb and daf added some required config keys that don't seem to be in configs/staging/launchpad.conf
[06:47] <jamesh> (or production[12] )
[07:08] <dilys> Merge to devel/launchpad/: [r=jamesh]  Export GPG fingerprints in person/$name/+rdf, to make it easier for people to e.g. create GPG keyrings for a team. (r3098: Andrew Bennetts)
[08:10] <lifeless> stub: ~/source/ has it all
[08:10] <stub> lifeless: ta
[08:10] <stub> (I've just been using ~pqm/bin)
[08:15] <SteveA> hello
[08:18] <stub> yo
[08:19] <SteveA> stub: do you recall what the conflicts were in merging jamesh's __len__ stuff?
[08:20] <stub> SteveA: Nope. I was busy trying to rollout at the time :)
[08:22] <stub> SteveA: I'll be doing some cherry picks once a patch of mine lands and will check it out then
[08:31] <carlos> morning
[08:41] <dilys> Merge to devel/launchpad/: [trivial]  Make some config sections not required to ease maintenance (r3099: Stuart Bishop)
[08:52] <lifeless> stub: for pqm I use that too
[08:58] <SteveA> spiv: OOPS-39A13 is a __nonzero__, not a __len__, but jamesh's patch converts __nonzero__ to use a select-limit query rather than a count().
[09:02] <sivang> howdy all
[09:02] <SteveA> hi sivan
[09:07] <jamesh> SteveA: I don't think the fix to make __nonzero__ not do a count might have missed the rollout
[09:08] <jamesh> SteveA: my original __nonzero__() implementation was erroneously doing a count still
[09:08] <SteveA> jamesh: yes, i think they both missed the rollout
[09:08] <SteveA> jamesh: stub said he will look at getting the rest cherrypicked later
[09:09] <lifeless> is __nonzero__ invoked on 'if foo:' ?
[09:09] <jamesh> lifeless: yes
[09:10] <jamesh> iirc, it will invoke __nonzero__ then __len__ then check if it is not None
[09:13] <SteveA> Seveas: hello
[09:21] <BjornT> SteveA: hi. do you have a minute to discuss a fix to bug 3796?
[09:21] <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
[09:27] <SteveA> BjornT: yes, after a workrave
[09:27] <BjornT> ok
[09:30] <jamesh> BjornT: I filed https://launchpad.net/products/malone/+bug/30307 a little while ago.  Does it sound like a good idea for searching?
[09:30] <Ubugtu> malone bug 30307 in malone "omit_dupes and searching" [Normal,Unconfirmed]  
[09:32] <SteveA> BjornT: for bug 3796, i agree with you
[09:32] <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
[09:33] <SteveA> BjornT: perhaps have self.status and self.display_status
[09:33] <SteveA> where the latter is a computed property
[09:38] <BjornT> SteveA: yes, that seems like a good idea. we were thinking of having self.status a property. that would avoid having to change all the call-sites, on the other hand it's more complicated.
[09:42] <SteveA> BjornT: we should keep the direct-to-database properties separately named from the computed ones
[09:43] <SteveA> you can change all the callsites in an hour or two of work.  many people can lose many hours debugging problems from a more complex system over the course of months.
[09:43] <BjornT> jamesh: yeah, matching searches on dupes sounds like a good idea. 
[09:44] <BjornT> SteveA: true
[09:50] <stub> lifeless: Where can I find the environment setup for using cm.py out of ~pqm/source ? Nothing seems setup in a sane path that I can find, and invoking cm.py directly from ~/source/config-manager can't find pybaz libraries for a start
[10:16] <Kinnison> Morning
[10:19] <Seveas> SteveA, bon giorno
[10:25] <Seveas> SteveA, I've gotta run, if it's important /msg or e-mail works too :)
[10:30] <BjornT> jamesh: does the "Launchpad Errors" mail get sent before the report has been generated? the link in the mail is a 404
[10:31] <jamesh> BjornT: I had an error in the script.  See the second email
[10:32] <BjornT> jamesh: yeah, i saw that now
[10:32] <jamesh> BjornT: should be reliable now, giving a short summary with the full HTMLised report linked
[10:32] <BjornT> yep
[10:41] <sivang> morning folkies
[10:56] <SteveA> Seveas: okay
[11:00] <SteveA> jamesh: it looks very good
[11:00] <SteveA> jamesh: i'd like you to make a couple of changes
[11:00] <SteveA> hard timeouts are far more important to fix than soft timeouts
[11:01] <jamesh> yeah.
[11:01] <jamesh> I'll split them out
[11:01] <SteveA> also, i'd like to see soft timeouts arranged not in order of how many occurred
[11:01] <SteveA> but instead in order of length of request
[11:01] <SteveA> (if that is possible)
[11:02] <SteveA> i don't know if that is how the soft timeout system works
[11:03] <SteveA> also, at the top of the html, a table of contents, with #anchor links to the various sections
[11:04] <SteveA> and perhaps a summary would be nice, like 88 timeouts, 25 soft timeouts, 87 programming errors, 1 attribute error, 4 value errors
[11:04] <jamesh> it'd also be goot to work out some regexps that could be used to help group the SQL errors
[11:05] <SteveA> we should aim to have no non-404 non-timeout errors.  it is more useful to have non-404 and non-timeout errors ordered by the error type
[11:05] <SteveA> than by frequency
[11:05] <SteveA> (or number occurred, rather)
[11:06] <jamesh> currently there is a regexp to replace the memory location used in many object's repr() with INSTANCE-ID, which helps with grouping similar OOPS reports
[11:07] <jamesh> that doesn't really help for the ones where an SQL statement is included in the exception value
[11:07] <SteveA> mpt_: please take a look at jamesh's summary report sometime, and create a stylesheet for it
[11:10] <SteveA> stub: if you made a wee script that you can stick revision ids in, and get revision ids + logmessage out of, then your emails about what revisions got into production could be more informative without much extra effort.
[11:12] <Seveas> re
[11:12] <SteveA> hi Seveas 
[11:12] <Seveas> hi
[11:13] <SteveA> i have a feature to request for Ubugtu.  it isn't very useful for anyone (including you), except launchpad developers
[11:13] <SteveA> the feature is for Ubugtu to listen for OOPS-oopscode
[11:13] <SteveA> and show a URL to jamesh's oops-viewing cgi URL for that oops code
[11:13] <Seveas> that
[11:13] <Seveas> 's doable
[11:14] <Seveas> what's the CGI url?
[11:14] <jamesh> Seveas: make OOPS-[A-Z\d] + => https://chinstrap.ubuntu.com/~jamesh/oops.cgi/$OOPSID
[11:14] <mpt_> SteveA, sure
[11:15] <carlos> lifeless: hi, could you take a look to PQM? my request is taking too long to be processed  (more than 1 hour) and when I sent it, the queue was empty
[11:16] <SteveA> jamesh: as the oops report is rather large, what do you think about splitting it into 4 or so pages?
[11:16] <SteveA>  - hard timeouts
[11:16] <SteveA>  - soft timeouts
[11:16] <SteveA>  - 404s
[11:16] <SteveA>  - errors
[11:16] <SteveA> with an index page pointing to each with a summary
[11:17] <jamesh> SteveA: I suppose so.  The alternative would be to remove some of the information
[11:17] <Seveas> jamesh, that url needs authentication
[11:17] <SteveA> i think the level of information is good
[11:17] <jamesh> Seveas: yes.
[11:18] <SteveA> Seveas: i was thinking just to display the URL, for ease of launchpad developers clicking on it from their irc client
[11:18] <Seveas> ok
[11:18] <SteveA> you're always ahead of the curve :-)
[11:19] <Seveas> @reload Bugtracker
[11:19] <jamesh> SteveA: is it useful to have the OOPS numbers categorised by URL, or do you think it would be as useful to just list them all together for the particular error?
[11:19] <Ubugtu> Error: I tried to send you an empty message.
[11:19] <Seveas> hmm
[11:20] <SteveA> jamesh: displaying the URLs helps me understand what the OOPSes are about.
[11:20] <SteveA> if the URLs are displayed, then the OOPSes may as well be categorized with them
[11:21] <jamesh> SteveA: I wasn't suggesting removing the URLs, just changing it to display the URLs, then the OOPSs
[11:21] <Seveas> OOPS-21312AD
[11:21] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/21312AD
[11:21] <SteveA> almost all have just one URL, so i don't think the change is important either way right now
[11:21] <jamesh> okay
[11:22] <Seveas> SteveA, ok this way?
[11:22] <SteveA> OOPS-39A13
[11:22] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/39A13
[11:22] <SteveA> perfect!
[11:22] <SteveA> thanks Seveas!
[11:22] <Seveas> np
[11:23] <SteveA> jamesh: the text that says "0% from search bots, 100% referred from local sites" is needed only for 404s in my opinion
[11:29] <cprov> morning, hackers
[11:30] <SteveA> good morning
[11:30] <SteveA> salgado: there's a few shipit errors in jamesh's error report.  some interesting not found errors, and some other application errors
[11:31] <SteveA> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/OOPS-38A65  <-- AttributeError
[11:31] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/38A65
[11:32] <SteveA> OOPS-38B59 <-- interesting NotFound error
[11:32] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/38B59
[11:33] <SteveA> jamesh: do you have shipit.ubuntu.com listed as a local site?
[11:35] <mpt_> cprov, hello, you wanted to talk about Soyuz?
[11:36] <SteveA> actually... mpt could put the css in his home on chinstrap, and jamesh's scripts could refer to it there in the html
[11:36] <cprov> mpt_: it was yesterday, wasn't it ?
[11:36] <cprov> mpt_: I'm happy with you decision (wait +build clean up land then discuss the content issues)
[11:37] <Kinnison> cprov: I think that getting the permission stuff sorted and the functionality sorted in the builds pages is more important than making them prettier
[11:37] <Kinnison> cprov: don't you?
[11:38] <mpt_> cprov, my cleanup is done and waiting for (re-)review. That shouldn't be blocking us talking about anything else.
[11:39] <mpt_> You can try the branch if you want.
[11:40] <cprov> Kinnison: uhm, personally I think the permission are ok, View is public, edit + cancel + mode  are Edit and admin is Admin. What am I missing ?
[11:40] <Kinnison> cprov: erm, we need to get the launchpad-buildd-admins celebrity done and made able to do the admin work
[11:40] <Kinnison> cprov: otherwise we can't hand over to adam and lamont
[11:41] <cprov> Kinnison: right, good point. I almost forget this
[11:41] <Kinnison> :-)
[11:41] <Kinnison> adam and lamont won't :-)
[11:44] <cprov> mpt_: It's hard ... we have a lot of bugs but I can define myself those who needs UI efforts, the simplest thing to do is some triage on soyuz bug recently added, would you do it for me ?
[11:47] <SteveA> cprov: we can ask daf  and matsubara to focus on soyuz bug triage for a while
[11:47] <cprov> SteveA: good idea, I'll ask them, thx
[11:48] <seb128> launchpad keep Oopsing today, is that known?
[11:48] <seb128> ie: OOPS-39A244
[11:48] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/39A244
[11:49] <SteveA> seb128: thanks.  probably a regression in the rollout.  i'll look into it
[11:49] <SteveA> seb128: did you *just now* get that oops?
[11:49] <cprov> Kinnison: bug 3580, is the begin of buildd celebrity
[11:49] <Ubugtu> malone bug 3580 in launchpad-buildd "Missed Launchpad Celebrity for Auto Build System" [Major,Unconfirmed]  http://launchpad.net/bugs/3580
[11:49] <SteveA> if so, i'll need to wait a short while until it is visible on chinstrap
[11:50] <Kinnison> cprov: right
[11:50] <seb128> yep
[11:51] <Kinnison> cprov: I've added a note to that about the team in production
[11:51] <SteveA> seb128: okay, i see it now.  this OOPS is to do with contention with people concurrently updating a bug.
[11:51] <SteveA> stub is working on a solution to that issue in general, which will be ready soon
[11:51] <seb128> I get timeout error too, like OOPS-39B202
[11:51] <cprov> Kinnison: right
[11:51] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/39B202
[11:51] <stub> eh?
[11:52] <SteveA> stub: are you not working on retries?
[11:52] <stub> Oh - serialization exceptions. es
[11:52] <stub> y
[11:52] <SteveA> exactly
[11:53] <SteveA> i didn't know the right name for it :-)
[11:54] <SteveA> salgado: the person vocabulary search stuff -- how is that going?  i think that's what OOPS-39B202 is about
[11:54] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/39B202
[11:56] <lifeless> stub: carlos would like pqm live again
[11:56] <lifeless> stub: are you finished ?
[11:56] <salgado> SteveA, yes, that's the vocab timing out. it was probably caused by contention.
[11:56] <stub> Oops. Yup.
[11:56] <salgado> SteveA, I tried it two times here. the first it timed out and the second it run pretty fast
[11:56] <stub> lifeless: reenabled
[11:56] <seb128> timeout OOPS-39B214 ...
[11:56] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/39B214
[11:57] <SteveA> salgado: timeout problems with contention are an issue.  we can't automatically retry these, because it will take 1 minute to get a response
[11:58] <SteveA> salgado: you have been working on a 2-stage query for this, right?
[11:58] <stub> serialization issues should not be confused with locks being held open by other processes. serialization issues are expected to happen and we need to cope. locks being help open by other processes are bugs that need to be dealt with individually
[12:00] <matsubara> good morning!
[12:00] <carlos> lifeless: oh, is it down? didn't know :-P
[12:00] <SteveA> stub: do you know if elmo changed the rsync of OOPS reports and other logs to be more selective about what it processes?
[12:00] <salgado> SteveA, no, what I did was to make all vocabs not fetch all the results at once, but instead fetch only the results of the batch they're displaying
[12:00] <stub> SteveA: No idea.
[12:00] <lifeless> carlos: stub disabled it during prod rollout testing
[12:01] <lifeless> carlos: and forgot to undisable 
[12:01] <SteveA> salgado: okay.  did you discuss with people an approach of making two queries, one direct and one broader?
[12:02] <SteveA> salgado: OOPS-39B214 would benefit from exactly this approach
[12:02] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/39B214
[12:02] <salgado> SteveA, something like bug 2045?
[12:02] <salgado> https://launchpad.net/products/launchpad/+bug/2045
[12:03] <SteveA> because in this case, the long query was a search for a person matching 'iwj'
[12:03] <SteveA> this could be matched instantly on person.name
[12:05] <sivang> morning matsubara :)
[12:05] <SteveA> salgado: bug 2045 is part of it, yes
[12:08] <SteveA> salgado: when we're entering names into a form, i think a launchpad-name or launchpad-email-address search would be sufficient.
[12:09] <salgado> I definitely agree
[12:09] <SteveA> what do we need to do to make this change?
[12:09] <SteveA> this would remove a whole bunch of timeouts for the distro team
[12:10] <salgado> well, I told you I was waiting for some input on that bug
[12:10] <salgado> nobody ever commented on it
[12:10] <SteveA> if that happens again, add it to the weekly meeting agenda
[12:10] <salgado> for that reason I haven't checked what's needed to make that change.
[12:11] <stub> I don't see OOPS-39B214 benefitting from doing more queries. The slow query was just a select on the person and validpersonorteamcache tables (with an unnecessary join with the emailaddress table)
[12:11] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/39B214
[12:11] <salgado> if you have some time to discuss this now, it'd be great
[12:11] <SteveA> stub, maybe you can discuss it with salgado?
[12:12] <SteveA> seeing as you already commented on the bug before
[12:12] <SteveA> and you proposed exactly "Would it make sense for the search() method to only search on exact matches for email address?"
[12:14] <dilys> Merge to devel/launchpad/: [r=spiv]  Allow admins, rosetta experts and product owners to edit translations if using CLOSED/STRUCTURED mode. (r3100: Carlos Perell Marn)
[12:14] <carlos> dilys: thanks ;-)
[12:28] <stub> salgado: For some reason, ILIKE is no longer hitting the index. Changing the query to do """ lower(email) LIKE 'iwj' || '%' """ again hits the indexes and runs fast (50ms)
[12:28] <salgado> ouch
[12:29] <stub> salgado: Want me to shove that through with a [trivial]  ? I have a branch free
[12:30] <salgado> stub, that'd be great
[12:31] <salgado> stub, do you think it's worth leaving a comment there saying that we shouldn't use ILIKE because it might not hit the index?
[12:31] <stub> salgado: Sure.
[12:37] <salgado> daf, around?
[12:38] <salgado> the link to the oops page from https://launchpad.net/products/launchpad/+bug/30807 is broken
[12:38] <Ubugtu> malone bug 30807 in launchpad "Links to a oops" [Normal,Unconfirmed]  
[12:38] <SteveA> matsubara: hi
[12:38] <SteveA> matsubara: i just had a phone call with daf about the process we will use to take OOPS reports from jamesh's report and users' reports, and process these into bugs with a particular milestone.
[12:39] <SteveA> daf is going to write this up today, and talk with you about it, a bit later
[12:39] <daf> salgado: yeah, I just noticed
[12:39] <matsubara> SteveA: ok, we scheduled a meeting every day around 16:00 utc
[12:39] <daf> stub: my code assumes that the configuration value ends with a slash
[12:39] <SteveA> two of the most important QA tasks at the moment are to respond initial bug reports in some way, and to keep on top of oopses
[12:40] <stub> daf: eh?
[12:40] <matsubara> SteveA: also cprov asked me to take special attention to soyuz bugs
[12:40] <daf> stub: the configuration value oops_root_url
[12:41] <stub> Oh - ok. I'll fix that now.
[12:41] <daf> it's a bug, but changing the config will work around it
[12:41] <SteveA> matsubara: yes.  seeing as we've just rolled out soyuz, you and daf should pay particular attention to soyuz bugs, so that cprov and others have good information about what needs fixing.
[12:42] <salgado> carlos, have you seen bug 3176? we just got two duplicates of it
[12:42] <Ubugtu> malone bug 3176 in launchpad "Error when trying to save AbiWord pt-BR translations" [Normal,Confirmed]  http://launchpad.net/bugs/3176
[12:42] <stub> daf: I generally use urllib.join
[12:42] <daf> SteveA: I'll put up a wiki page outlining what we discussed
[12:42] <stub> erm... urllib.urljoin
[12:42] <SteveA> daf: thanks
[12:42] <matsubara> SteveA: all right.
[12:43] <daf> stub: ok, I'll do a [trivial]  merge with that, assuming the tests still pass
[12:43] <SteveA> daf: ideally, this needs an additional test
[12:43] <carlos> salgado: WTF...
[12:43] <carlos> salgado: thanks, I will take a look. btw, the OPPS link you gave is broken
[12:44] <daf> SteveA: oh, good point
[12:44] <salgado> carlos, no, I didn't give any link
[12:44] <carlos> oh, is it a new malone feature?
[12:44] <salgado> carlos, it's the code that turns the oops code into a link that is broken
[12:44] <carlos> then I guess it's broken...
[12:44] <carlos> yeah
[12:44] <SteveA> carlos: yes.  will be fixed in a few minutes
[12:44] <salgado> yes, it was cherry picked today
[12:45] <daf> SteveA: did you see https://launchpad.net/products/launchpad/+bug/30746?
[12:45] <Ubugtu> malone bug 30746 in launchpad "LaunchBag.developer is not updated when ftest login() is called" [Normal,Unconfirmed]  
[12:45] <SteveA> carlos: with a config change to work around the problem
[12:45] <SteveA> daf: no, i didn't.
[12:45] <SteveA> i guess it should do
[12:45] <carlos> ok
[12:45] <SteveA> we should use events more for logging in etc.  but i'll look into that later.
[12:45] <SteveA> any reasonable fix will do for now
[12:46] <daf> well, I worked around it, it's an infrastructure thing
[12:47] <lifeless> jamesh: did you get my mail this morning ?
[12:47] <dilys> Merge to devel/launchpad/: [trivial]  improve oops analysis script to generate html too (r3101: James Henstridge)
[12:47] <carlos> salgado: that problem is already fixed at rocketfuel
[12:48] <salgado> ahhh, cool
[12:48] <carlos> salgado: I rewrote that class and the new version seems like fixed it as a side effect
[12:48] <carlos> salgado: thanks anyway, I'm going to note that on that bug report
[12:49] <carlos> salgado: which bugs are the duplicated ones that you told me?
[12:50] <salgado> carlos, don't remember, but I've marked them as dupes
[12:51] <carlos> hmm I don't see that information on the bug report you gave me..
[12:51] <carlos> Oh, sorry
[12:51] <carlos> I saw it
[12:51] <jamesh> lifeless: yeah.  I had the report script disabled while I was cleaning it up to send a short report to the list + a longer web version.  It's running daily again now.
[12:51] <lifeless> jamesh: I mean the other email :)
[12:51] <lifeless> jamesh: the one about the branch status stuf
[12:51] <lifeless> f
[12:52] <jamesh> ah.  found it
[12:54] <daf> jamesh: perhaps the OOPS web page could put hard and soft timeouts into separate categories
[12:55] <jamesh> daf: already suggested by Steve
[12:56] <daf> great
[12:56] <daf> another suggestion
[12:56] <daf> it would be great if we could group by query
[12:56] <daf> e.g. ERROR: could not serialize access due to concurrent update UPDATE SessionData SET last_accessed = CURRENT_TIMESTAMP WHERE client_id =
[12:56] <daf> that one turns up a lot in the latest report
[12:56] <daf> but they're separate because the client_id is different each time
[12:57] <daf> I imagine we could strip out constants from the queries in order to compare them
[12:57] <daf> what do you think?
[12:58] <jamesh> daf: yeah.  that'd be good.  lots of queries differ only by string or integer constants
[12:58] <daf> cool
[12:58] <jamesh> I wonder how many falst matches you'd get by replacing all digit strings with "$int" and strings with "$string" (or similar)
[01:00] <carlos> hmmm
[01:00] <carlos> I'm not able to get the Malone's 'Advanced' search form
[01:00] <daf> s/the//
[01:01] <daf> what happens?
[01:01] <carlos> daf: it does nothing
[01:01] <carlos> Well, it changes the URL
[01:01] <carlos> from https://launchpad.net/products/launchpad/+bugs
[01:01] <carlos> to https://launchpad.net/products/launchpad/+bugs?field.searchtext=&orderby=-priority%2C-severity&advanced=Advanced...&field.milestone_assignment=&field.milestone_assignment-empty-marker=1
[01:01] <carlos> but the webpage remains the same
[01:02] <daf> yes, same here
[01:02] <daf> it's a bug
[01:02] <daf> https://launchpad.net/products/launchpad/+bugs-advanced seems to still work
[01:03] <carlos> It works with a person as a context
[01:03] <spiv> daf: there's a bug about that.
[01:03] <salgado> carlos, yes, that happens only if you're in the +bugs page. brad had a fix for that a few days ago
[01:03] <salgado> I think he didn't manage to merge it. :-(
[01:03] <carlos> ok, thanks
[01:04] <spiv> daf: bug 30690 I think
[01:04] <Ubugtu> malone bug 30690 in malone "'Advanced...' button on bugs listing doesn't do anything" [Normal,Confirmed]  http://launchpad.net/bugs/30690
[01:04] <daf> cool
[01:07] <jamesh> lifeless: assuming that the two use cases are independent, then it would probably make sense to use xml-rpc for the branch-puller use case and go through the main web app for the diff URL case.
[01:08] <jamesh> lifeless: given that authserver can only be reached on our network.
[01:09] <carlos> Hmmm
[01:09] <carlos> I think Rosetta is completely broken atm..
[01:09] <carlos> And I don't really understand it as the production update doesn't have any change from my side
[01:10] <lifeless> jamesh: works for me
[01:23] <dilys> Merge to devel/launchpad/: [trivial]  Use LIKE instead of ILIKE to use indexes and tweak schema.xml defaults (r3102)
[01:24] <daf> stub: empty merge?
[01:27] <stub> Bah.
[01:45] <dilys> Merge to devel/launchpad/: [trivial]  Use LIKE instead of ILIKE to use indexes and tweak schema.xml defaults (r3103: Stuart Bishop)
[02:07] <daf> SteveA, matsubara: I've updated LaunchpadBugTriage and LaunchpadProjectMilestones to talk about oopses
[02:09] <lifeless> night all
[02:09] <daf> night Rob
[02:09] <matsubara> daf: thanks daf, I'll take a look later.
[02:22] <salgado> stub, ping
[02:23] <kiko> Kinnison, thanks for the document
[02:25] <Kinnison> kiko: You're welcome. I figured it would be best to turn my notes into a real doc otherwise I'd forget things too
[02:25] <kiko> indeed. we should wikify it -- stub, any suggestion on where to put it? I'd like to see the other rollout procedures documented as well
[02:25] <Kinnison> FYI, I'm currently working on bugs 29635 and 29639 for cprov
[02:25] <stub> salgado: pong
[02:27] <stub> I'd put it in the launchpad tree where it will be under RCS and more likely to be maintained. wikis are just where you put docs to forget about them.
[02:27] <kiko> cool
[02:27] <kiko> stub, where do such documents go?
[02:28] <stub> There is a top level 'doc' directory in the launchpad tree. The database docs I'm keeping in database/schema where I notice them (although a symlink would do just as well)
[02:29] <stub> Wow... some old docs in there :)
[02:29] <salgado> stub, is there anything wrong with https://chinstrap.ubuntu.com/~dsilvers/paste/fileQUMFzM.html ?
[02:29] <dilys> Merge to devel/launchpad/: [trivial]  make oops links work if oops_root_url config value doesn't end with slash (r3104: Dafydd Harries)
[02:30] <kiko> cool.
[02:31] <kiko> stub, so this doc/ directory is where we put docs to forget about them too?
[02:31] <kiko> perhaps the problem is more that nobody gardens any of our documentation.
[02:32] <stub> kiko: Thats why I keep my docs next to the code - I see them when changing the db scripts and can keep them up to date (or get reminded that I haven't)
[02:32] <kiko> stub, that's fine, but where should rollout docs go, then?
[02:32] <stub> kiko: I'd stick 'em in the docs directory in the root of lp
[02:35] <stub> (but am not really fussed if you have a better idea)
[02:36] <stub> salgado: that query should be fast, but isn't. I'm having a closer look.
[02:37] <salgado> stub, well, let's leave the speed aside for now
[02:37] <salgado> there's something weird going on that query
[02:38] <salgado> stub, if you run it with the sampledata from chinstrap.warthogs.hbd.com/~salgado/current.sql
[02:38] <salgado> stub, it will give you only one result. which is correct
[02:38] <salgado> but, if you join that query in a single line, it'll give you two results, which is wrong
[02:39] <stub> oh... your missing some brackets
[02:39] <salgado> I know that if I add a parenthesis around the first condition in the where clause it'll work, but I wanna know why it's failing only when I join it in a single line
[02:40] <stub> what do you mean 'join it in a single line'?
[02:40] <salgado> stub, https://chinstrap.ubuntu.com/~dsilvers/paste/fileQqjjda.html
[02:40] <salgado> stub, if you paste it like it is in the first page I gave you, it'll get me only one result
[02:41] <salgado> and if you paste it like it is in the second page, it'll give me two results
[02:41] <salgado> s/me/you
[02:42] <matsubara> SteveA, cprov: I've finished the triaging of all untriaged bugs on soyuz, would you take a look on the 4 left ones that are user requests?
[02:42] <cprov> matsubara: yes
[02:43] <salgado> stub, IOW, if it's broken into multiple lines, the parenthesis aren't needed. but we need them if it's a single line query
[02:43] <stub> salgado: There are some spurious spaces in there
[02:43] <matsubara> cprov: https://launchpad.net/products/soyuz/+bugs-untriaged
[02:43] <salgado> stub, in the single line version?
[02:43] <stub> yup
[02:43] <salgado> I thought spaces where ignored
[02:44] <stub> EmailAddres. email, david. alloche
[02:44] <matsubara> cprov: I've changed them to wishlist, so you could easily find and take care of them.
[02:44] <salgado> aha
[02:45] <salgado> stub, even if you remove that space, it'll still give two results
[02:45] <salgado> maybe not
[02:45] <salgado> no, it won't
[02:46] <salgado> bah. what a shame
[02:47] <cprov> matsubara: they are hard to solve, I'll triage them with Kinnison later today, thanks for your good job in the other bugs .
[02:48] <lamont-away> Kinnison: I don't _mind_ pestering you guys every time we need something done that requires lp-buildd-admin privs... :-)  But I think you guys might...
[02:48] <matsubara> cprov: no problem, shout if you need anything else. :)
[02:48] <cprov> matsubara: ok, dude
[02:53] <stub> salgado: I don't think we can do that efficiently on production anyway... is this for a batch job, or to be used interactively?
[02:55] <stub> Hmm... maybe not. I can get it down to 3.5 seconds once everything is in RAM
[02:55] <salgado> stub, it's for interactive use. but that's only for shipit admins
[03:05] <jbailey> What should the bug be filed against for ubugtu?
[03:05] <Kamion> Ubugtu's just a bot Seveas runs, I don't think it has a bug tracking component
[03:06] <jbailey> Ah, hmm.
[03:06] <stub> salgado: This seems to be giving the best results so far: https://chinstrap.ubuntu.com/~dsilvers/paste/filevj65AW.html
[03:09] <salgado> stub, is the speed gain worth the fix?
[03:09] <salgado> I think it should be trivial to fix. just want to make sure it's worth it
[03:10] <stub> btw. I get one line on my sampledata using both single line and multiline queries you posted before
[03:11] <salgado> stub, yes, the problem was the spurious spaces. I should've read the queries carefully before complaining
[03:13] <stub> Hmm... queries are performing equivalently now.
[03:18] <Seveas> jbailey, 'sup?
[03:20] <jbailey> Seveas: I'm just running out.  But the quick summary is that ubugtu seems to randomly pick which task to give status on, I'm wondering if there's a better way.  Bug #30621 is an example.
[03:21] <jbailey> err.
[03:21] <jbailey> bug 30621
[03:21] <Ubugtu> malone bug 30621 in malone "glibc changelog seems to list two versions and have eaten a line for the changelog" [Normal,Rejected]  http://launchpad.net/bugs/30621
[03:21] <jbailey> Seveas: Shows as rejected, even though the rejected task is simple a thing I clicked on by mistake.
[03:21] <jbailey> (I added a task that I hadn't intended to)
[03:21] <Seveas> it picks the first task listed in the /+text url
[03:21] <jbailey> Seveas: I'm not sure where to put wishlist bits for ubugtu.
[03:22] <Seveas> jbailey, in my mailbox or in here :)
[03:22] <Seveas> jbailey, what would you prefer? first non-fixed one?
[03:22] <jbailey> Seveas: I haven't got a comprehensive bit of logic worked out.
[03:22] <Seveas> or max(severity), pseudomax(status)
[03:23] <jbailey> In this case, I simply wrongly filed it against malone because I was fiddling with the URL and thought that the button was a text box.
[03:23] <jbailey> So I rejected the extra task that I Added by accident.
[03:23] <jbailey> Anyhow, appointment in 7 minutes, back in 45. =)
[03:23] <Seveas> :)
[03:23] <salgado> stub, that query I pasted to you return the two values on pqm's box
[03:24] <ddaa> "Finally a Patch that works!"
[03:24] <Seveas> hahaha
[03:25] <salgado> stub, is that box running breezy's postgres?
[03:25] <stub> ddaa: Bounce it to pqm - you might have better than your usual luck (and Launchpad could do with some performance enhancement!)
[03:25] <stub> salgado: yes
[03:25] <ddaa> stub doing
[03:26] <ddaa> stub: you think I should forward the pqm reply to launchpad if it rejects it?
[03:27] <salgado> stub, any idea what could cause that query to fail on pqm's box but not locally?
[03:27] <stub> salgado: Maybe your sample data is different to what is in the trunk?
[03:32] <salgado> stub, no. I committed and mirrored my sampledata changes
[03:32] <salgado> and I just rebuilt my db here in case I had changes in it
[03:32] <stub> And pushed the sampledata changes to chinstrap?
[03:32] <salgado> and the tests still pass here and fail on pqm
[03:33] <salgado> yes, I meant that when I said mirrored
[03:35] <stub> Have you merged rocketfuel in recently? There was a change I made last week to the text search stuff that could cause what you describe (changed how '.' is handled in text searches)
[03:35] <salgado> aha
[03:36] <salgado> it must be it, then
[03:36] <stub> You will need to rebuild the database after merging too, to ensure the updated stored procedures are in there.
[03:36] <salgado> I don't remember when was my last merge on that branch, but it wasn't this week
[03:38] <SteveA> daf, matsubara: how about we go through bug stuff in 50 mins time?
[03:44] <daf> SteveA: fine by me
[03:44] <SteveA> that's at 30 minutes past the next hour
[03:44] <SteveA> for whatever timezone you're in
[03:46] <Seveas> jbailey, when you're back, the tasks are now first ordered by status and severity (status first, severity second). The priority from low to high for status is now: ['Rejected', 'Fix Committed', 'Fix Released', 'In Progress', 'Unconfirmed', 'Needs Info', 'Confirmed']  - any thoughts on that ordering?
[03:48] <matsubara> SteveA: fine to me too.
[03:48] <SteveA> thanks matsubara, daf.
[03:50] <matsubara> I should get some lunch now then.
[03:51] <ddaa> stub: re lock metrics
[03:51] <ddaa> stub: what about some statistical profiling, taking periodic snapshots of taken locks and associated queries
[03:51] <ddaa> like, every minute
[03:53] <ddaa> anyway, the "oops" lock thing would be misleading at best, since it would actually do this sort of measurement, with no garantee that the lock that caused contention is still taken
[03:53] <kiko> bradb, how's the feedback been on the package bug contact reports?
[03:54] <bradb> kiko: Most of it was what we got from yesterday during that discussion with Kamion et al.
[03:54] <jbailey> Seveas: I'm just back.  Trying to understand wht you mean.
[03:54] <kiko> bradb, have people found it useful, annoying, excellent, hidden, a lifesaver, confusing, etc?
[03:54] <jbailey> Seveas: I don't understand how this affects the output.
[03:55] <Seveas> jbailey, what I mean is that if there is an unconfirmed low priority task and a rejected high priority one, Ubugtu will show the unconfirmed low priority one
[03:55] <daf> carlos: yo
[03:55] <carlos> daf: hi
[03:55] <daf> carlos: I just met Tim Morley
[03:55] <Seveas> ubugtu picks one task only, it's now trying to be intelligent about which task
[03:55] <bradb> kiko: Dunno, I haven't specifically asked yet. It hasn't been in production for that long.
[03:56] <daf> carlos: he says the number 1 thing stopping him from using Rosetta to translate OpenOffice is the ability to add/edit comments
[03:56] <jbailey> Seveas: So rejected is least interesting, and confirmed is most?
[03:56] <kiko> it would be nice to collect that feedback, bradb, though not mandatory
[03:56] <carlos> daf: we are aware of that
[03:56] <bradb> kiko: Definitely.
[03:56] <Seveas> yes, and I'd like to hear your comments about that ordering. For status it's less obvious than for severity
[03:57] <daf> carlos: a) do we have a bug open?
[03:57] <carlos> daf: I think so, yes
[03:57] <carlos> let me check
[03:57] <daf> carlos: b) is it a high priority for us?
[03:58] <carlos> daf: kiko asked me on December to look into it after PoMsgSetView implementation
[03:58] <kiko> daf, carlos: tell me about bug 1681, the bug that nobody wanted to kill.
[03:58] <Ubugtu> malone bug 1681 in rosetta "Viewing a translation page fails in unix2newlines" [Major,In progress]  http://launchpad.net/bugs/1681
[03:58] <kiko> carlos, and pomsgsetview, hopefully, is on the way to pqm? :)
[03:59] <carlos> kiko: I'm working on it atm now that the needed changes part of the  PoMsgSetPage spec is done
[03:59] <carlos> kiko: most of the main changes is already merged since Friday
[03:59] <kiko> yeah I saw that
[03:59] <kiko> good work
[04:00] <daf> carlos: "it"? 1681 or PoMsgSetView?
[04:00] <carlos> kiko: I just found a problem with Rosetta and had to do some checking before requestin a fast review + cherrypick of that Friday merge 
[04:00] <carlos> 1681
[04:00] <daf> cool
[04:00] <carlos> but also PoMsgSetPage, I detected a small problem
[04:00] <daf> what are your plans when #1681 is done?
[04:01] <carlos> daf: Finish the suggestions fixes using AJAX
[04:02] <carlos> I have many things open atm and want to close all them
[04:02] <carlos> as soon as that is done, If kiko agrees, I think I could take a look to the comments feature
[04:03] <daf> kiko: can we make that a priority?
[04:03] <daf> kiko: I want to make Tim happy
[04:03] <carlos> daf: I have also pending dapper imports into Rosetta
[04:04] <daf> carlos: perhaps you can make a list of all your pending tasks on the wiki
[04:04] <carlos> kiko, Kinnison: Do we know when will be ready the new system to do the imports as planned?
[04:04] <kiko> daf, the dapper imports are a lot more importan, unfortunately.
[04:04] <daf> ok
[04:04] <kiko> carlos, I have no idea on the status of that -- I thought everything just worked
[04:04] <daf> maybe after those
[04:05] <carlos> kiko: Kinnison and mdz told me that there is a missing part that would take more time than use soyuz to develop Ubuntu
[04:05] <carlos> but I don't know the details
[04:05] <kiko> find them out
[04:06] <kiko> I think that is handwaving
[04:06] <carlos> Kinnison, mdz?
[04:07] <daf> SteveA: before our meeting, could you take a look at what I wrote on the LaunchpadBugTriage page about oopses?
[04:09] <jbailey> Seveas: I'm wrestling with the placement of Confirmed and Unconfirmed.  Needs Info seems like the highest priority.
[04:09] <Kamion> jbailey: depends who's asking, really
[04:09] <jbailey> Seveas: I'm almost tempted to place Confirmed second from the left in that, aside from Rejected, its the state where something is waiting and may or may not have anything interesting happening with it.
[04:09] <kiko> carlos, make sure you find out and email launchpad with your analysis
[04:09] <jbailey> Kamion: Yeah.
[04:10] <Kamion> for a maintainer, needs info is lower than confirmed, I'd say
[04:10] <Kamion> for a submitter, it's higher
[04:10] <carlos> kiko: ok. I thought you know about that issue already...
[04:10] <kiko> carlos, I don't know any of the specifics
[04:12] <kiko> ddaa, daf: what of optional branch names, and the buildbot test suite fixes?
[04:12] <SteveA> daf: i'll take a look now
[04:12] <daf> kiko: o-b-t is needs-reply
[04:12] <jbailey> Kamion: Who do you think is more important for ubugtu to serve?  I'd guess maintainer.
[04:12] <daf> kiko: (from me)
[04:13] <kiko> daf, get on it, don't miss this week's cutoff
[04:13] <mdz> carlos: hmm?
[04:13] <mdz> carlos: I don't know what you mean
[04:13] <kiko> mdz, carlos would like to know the specifics of what needs to be done to get translation imports working again, if you know of such a thing.
[04:14] <carlos> mdz: pitti told me that he's not able to deploy the new script to extract translations
[04:14] <Kamion> jbailey: I am hopelessly biased
[04:14] <carlos> because we are missing something to include the tarball with translations as part of the build output
[04:15] <carlos> mdz: I talked with you about that and you confirmed it to me but I didn't ask for details
[04:15] <mdz> carlos: what you told me was that imports were already broken before soyuz was rolled out
[04:15] <carlos> mdz: not broken but 'disabled'
[04:15] <carlos> mdz: waiting for the soyuz roll out
[04:16] <mdz> ?
[04:16] <kiko> bradb, can you detail to me what sort of work you're doing on searching this week?
[04:16] <carlos> mdz: ok, let's start again
[04:16] <mdz> Jan 26 14:57:37 <mdz>   pitti: why aren't they being imported into rosetta anymore?
[04:16] <mdz> Jan 26 14:58:12 <carlos>        mdz, because we changed a lot the way of doing imports and instead of porting the old script I decided to wait for the new system as it was supposed to be ready earlier
[04:16] <jbailey> bug 30621
[04:16] <Ubugtu> malone bug 30621 in soyuz "glibc changelog seems to list two versions and have eaten a line for the changelog" [Major,In progress]  http://launchpad.net/bugs/30621
[04:17] <bradb> kiko: Hang on, I'll show you a picture.
[04:17] <carlos> mdz: right,  I 'disabled' it
[04:17] <carlos> not porting the old script to the new system
[04:17] <carlos> mdz: the new system relies on soyuz
[04:17] <mdz> carlos: you disabled it because it wasn't working anymore
[04:18] <Seveas> jbailey, how about ['Rejected', 'Confirmed', 'Fix Committed', 'Fix Released', 'In Progress', 'Needs Info', 'Unconfirmed'] , that looks like an interesting-to-developer-ordering to me
[04:18] <carlos> mdz: it didn't broke, I just implemented the new way.
[04:18] <Kamion> Seveas: to a developer, Confirmed is more interesting than either kind of fixed
[04:18] <carlos> mdz: Anyway, the question is... could pitti upload to the archive the new pkgstriptranslations version?
[04:19] <mdz> carlos: I don't see any reason why he shouldn't
[04:19] <carlos> mdz: if that's done, dapper translations will appear on Rosetta
[04:19] <mdz> carlos: oh really?
[04:19] <Kinnison> sorry, mortgage conversation overran
[04:19] <carlos> mdz: yes, that's why I didn't ported the script
[04:19] <mdz> carlos: how does the new pkgstriptranslations work?
[04:20] <mdz> my understanding is that it was being changed to include the translations in the upload
[04:20] <carlos> mdz: generates a new tarball with the usual binaries, source and diffs and adds it to the changes file
[04:20] <carlos> mdz: right
[04:20] <mdz> but that soyuz didn't know how to handle such uploads yet
[04:20] <mdz> Kinnison: is that inaccurate?
[04:20] <Kinnison> If carlos is happy with the code he added to distroreleasequeue then we can go for it providing carlos has ensured that the queued user has access to all the relevant tables
[04:20] <carlos> mdz: that was exactly what I'm asking for. Rosetta has the needed bits in place
[04:21] <dilys> Merge to devel/launchpad/: [trivial]  Fix a regression on shipit: untested code path was calling len() on a SelectResults object. Also changes sampledata in order to test that code path. (r3105: Guilherme Salgado)
[04:21] <carlos> Kinnison: I asked sometime ago for a way to test this functionality
[04:21] <carlos> and I was told that until soyuz deploiment we cannot test it
[04:21] <bradb> kiko: Implementing this: http://flickr.com/photos/84096161@N00/97165744/ but still fleshing out the design, namely sectionalizing the page and possibly making each criteria a bit more distinct on the page.
[04:21] <Kinnison> carlos: right
[04:21] <carlos> Kinnison: do we have a way to test it now?
[04:22] <Kinnison> carlos: so now that deployment is done we can look at testing it
[04:22] <carlos> ok
[04:22] <mdz> carlos: ok, I can't help you with rolling out the LP changes
[04:22] <mdz> updating pkgstriptranslations is trivial
[04:22] <bradb> kiko: This also means updating the linkified search filter code to understand the extra params.
[04:22] <carlos> Kinnison: could we prepare a test plan for it?
[04:23] <Kinnison> carlos: Right, so launchpad/doc/distroreleasequeue.txt is where we test the queue
[04:23] <SteveA> Seveas: is ubugtu using the new text pages now?
[04:23] <jbailey> Kamion: I wonder if that's true.  If it's a bug I know that I'm interested in, isn't it better for me to know that somewhere in the launchpad universe, someone has fixed it?
[04:23] <bradb> er, "Reporter" "Nobody", whoops
[04:23] <carlos> mdz: yeah, I didn't know the details of what's missing so I had to check, Thanks
[04:23] <Seveas> SteveA, yes
[04:23] <kiko> bradb, safari displays <select multiple> as checkbuttons?
[04:23] <Kinnison> carlos: That area has changed in our deployment branch and cprov and I are working toward getting that merged in
[04:23] <SteveA> Seveas: cool.  thanks for writing the initial spec for that!
[04:24] <bradb> kiko: No. Those <select multiple>'s are just a horrible UI. :)
[04:24] <kiko> Reporter: nobody?
[04:24] <kiko> really?
[04:24] <bradb> kiko: See previous comment. I removed that. :)
[04:24] <carlos> Kinnison: I suppose I will need to add testing for my code there as soon as you get it merged, right?
[04:24] <kiko> you will conflict with daf on Upstream Status
[04:24] <bradb> Got a little too copy and pastey there.
[04:25] <bradb> kiko: I won't. It's a totally different screen.
[04:25] <bradb> (For now.)
[04:25] <kiko> I so wish you guys actually communicated more
[04:25] <Kamion> jbailey: suppose it depends why I'm asking
[04:25] <kiko> that is crack
[04:25] <kiko> a different screen?
[04:25] <bradb> kiko: I reviewed his patch.
[04:25] <kiko> that does the same thing?
[04:25] <Kinnison> carlos: that's the ideal method, yes
[04:25] <Kinnison> carlos: It shouldn't be too much longer we hope
[04:25] <Kinnison> cprov is intending to ask kiko to do a new review as soon as we've merged in these response fixes we're doing right now
[04:26] <kiko> I also am troubled by this new wave of search forms if we have no plan for updating the existing ones.
[04:26] <carlos> Kinnison: ok, please, ping me when you are done
[04:26] <kiko> Kinnison, make sure carlos and you guys are sorted before you leave today
[04:26] <carlos> Kinnison: anyway, I will ping you again on Thursday just in case you forgot it, ok?
[04:26] <bradb> kiko: Yeah. The idea is to replace the existing advanced search screen which sucks because 1. it uses multi-selects, 2. it presents search results, even when you haven't searched for anything (which you almost surely don't intend to happen when you click "Advanced Search"), and 3. it's stuck in between portlets.
[04:26] <Kinnison> carlos: cool
[04:26] <Kinnison> kiko: Yep, we're doing our best.
[04:27] <Kinnison> carlos: it looks like it wouldn't be too hard for you to do, once we get it merged
[04:27] <kiko> Kinnison, carlos: today -- don't let this one slip, blocking Rosetta work is a big no-no
[04:27] <Kinnison> carlos: the distroreleasequeue test is pretty comprehensive thanks to cprov
[04:27] <jbailey> Kamion, Seveas: I'm not sure it's solvable without alot more complex logic.  I'm happy that Rejected isn't the highest now, given how easy it is to make a mistake where the only undo is "reject"
[04:27] <carlos> Kinnison: ok, cool
[04:27] <Kinnison> kiko: What do you suggest we do? Should carlos work on a branch of cprov's branch to get the tests written?
[04:27] <carlos> kiko: I'm blocked on get that branch merged
[04:28] <Kinnison> carlos: could you branch off our work to get your tests done?
[04:28] <carlos> Kinnison: are you changing that file?
[04:28] <Kinnison> carlos: Not currently, no
[04:28] <kiko> Kinnison, just make sure carlos knows what he needs to do -- he can wait on that branch to merge, but I don't want him to be left in a vacuum and then discover later that he needs to change his code again.
[04:28] <Kinnison> kiko: indeed
[04:28] <carlos> Kinnison: ok, then it's not a problem
[04:28] <Kinnison> carlos: I believe that lot is pretty stable
[04:29] <Kinnison> carlos: if you can get your tests done (and any fixes you need if any) off our branch then we can merge your code in at the same time
[04:29] <Kinnison> That would minimise the times I think
[04:29] <carlos> Kinnison: path?
[04:29] <kiko> bradb, I am confused, but I need to have lunch. talk to you in 30 minutes?
[04:29] <Kinnison> carlos: .../cprov/launchpad/uploader-tests
[04:29] <bradb> kiko: Sure.
[04:29] <carlos> Kinnison: ok, thanks
[04:30] <SteveA> matsubara, daf: skype?
[04:30] <Kinnison> carlos: if you have problems, bug me and/or cprov
[04:30] <carlos> ok
[04:31] <matsubara> SteveA: ok
[04:31] <kiko-fud> time for uncertainty
[04:32] <matsubara> SteveA: what's your skype username?
[04:32] <SteveA>  'implied'
[04:32] <kiko-fud> and don't ask
[04:33] <matsubara> just added
[04:33] <ddaa> yay! got my new toy
[04:33] <ddaa> I read that rockbox now works on the ipod nano, I thought I would have to check.
[04:33] <LarstiQ> heh
[04:34] <kiko-fud> ddaa, you were going to say something about pgsql locks?
[04:34] <ddaa> kiko-fud: I asked stub if I thought that statistical profiling would be more practical
[04:35] <daf> matsubara: what's your Skype username?
[04:35] <ddaa> just periodically polling the database for open locks and related transactions
[04:36] <SteveA> matsubara: ?
[04:36] <ddaa> kiko-fud: since anyway it appears that finding out locks at oops time is not reliable, I thought it would be better to avoid the temptation to misinterpret this data.
[04:36] <matsubara> SteveA, daf diogo.matsubara
[04:36] <kiko-fud> hmmmm.
[04:36] <matsubara> SteveA: added you already. it says: pending authorization
[04:37] <kiko-fud> damn
[04:37] <kiko-fud> stub sent that email too late for me
[04:37] <kiko-fud> I missed 4 cherry-picks
[04:37] <SteveA> matsubara: okay.  i need to restart skype.  then i'll make a conference call and call both you and daf
[04:38] <kiko-fud> and I wish he hadn't rolled out the __len__ changes
[04:38] <SteveA> kiko-fud: stub will be doing extras over the next day or so
[04:38] <SteveA> kiko-fud: we still have __len__ to roll out properly
[04:38] <matsubara> all right
[04:38] <kiko-fud> SteveA, I think it was rolled out -- shipit broke.
[04:40] <elmo> how do I reply to a comment in malone?  and/or is the mail interface up yet?
[04:40] <elmo> as in reply to a comment, with the original quoted for me, a la bugzilla/rt etc.
[04:41] <siretart> elmo: just answer to the email. the mailinterface for bugs works (at least for me)
[04:41] <LarstiQ> elmo: that works for me on bugs I get mailed to begin with, not sure how to do it with ones I'm not
[04:42] <elmo> thanks
[04:42] <elmo> (kinda sucks that you can't do it through the web tho)
[04:44] <LarstiQ> elmo: web has always worked?
[04:44] <siretart> cprov: you wanted to talk to me because of special workflow needed for uploading to -updates?
[04:44] <elmo> LarstiQ: how?  'add a coment to this bug' just starts from empty?
[04:45] <LarstiQ> elmo: ah hmm, I see what you mean
[04:45] <cprov> siretart: not at this time, I'm sorry, we are not ready yet 
[04:45] <siretart> cprov: so uploading to breezy-updates is not possible at all at the moment?!
[04:46] <SteveA> matsubara: https://chinstrap.ubuntu.com/~jamesh/oops-summaries/2006-02-07.html
[04:46] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/summaries
[04:46] <SteveA> thanks Ubugtu ;-)
[04:46] <cprov> elmo: ^^^, do you have any news about siretart comment ?
[04:46] <Kinnison> pocketed uploads are not permitted yet
[04:47] <Kinnison> This is mostly because I don't know what the deal is about who can upload to -updates and if there's an accepted/approved workflow on -updates
[04:48] <mdke> what seems to happen is that people upload, then Kamion/mdz have to approve it before it goes through
[04:48] <mdke> they can tell you more, I'm sure
[04:48] <Kinnison> Right, so -updates needs the approval queue working
[04:48] <mdz> correct
[04:49] <Kamion> anyone who can upload to breezy can upload to breezy-updates, subject to approval as above
[04:49] <mdz> no one can upload to breezy ;-)
[04:52] <mdke> but presumably someone can upload to breezy-updates at the moment, right?
[04:52] <Kinnison> Okay, so I need to ensure that uploads to pockets go to -unapproved basically, yes?
[04:52] <Kinnison> Once I've finished this refactor for celso I'll take a look
[04:54] <Kamion> s/can/could/ for the pedants :)
[04:54] <Kamion> I suppose "anyone who can upload to dapper" would be more accurate
[04:54] <SteveA> matsubara: https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-07/C290
[05:48] <kiko> does anyone know what was made of lifeless' story branch?
[05:50] <Kinnison> Is there a way in doctests to say "this snippet must produce these lines of output, but I don't care in what order they come" ?
[05:50] <SteveA> Kinnison: either you sort them, or use a regex or use the 'in' operator
[05:51] <Kinnison> SteveA: https://chinstrap.ubuntu.com/~dsilvers/paste/filekKBenB.html
[05:51] <SteveA> you can use '/n'.join(sorted(somestring.splitlines())) for example
[05:51] <Kinnison> SteveA: that's the bit of doctest
[05:51] <Kinnison> SteveA: but the order of those two lines is unreliable
[05:51] <Kinnison> at the whim of the db
[05:52] <SteveA> i would...
[05:52] <SteveA> create a list called L
[05:52] <SteveA> and instead of printing, append to L
[05:52] <SteveA> and then sort L, and print it out
[05:52] <SteveA> or use the 'in' operator on L
[05:53] <Kinnison> I think I'll have to order queue_items somehow
[05:53] <kiko> err
[05:53] <kiko> how did that happen
[05:53] <Kinnison> because some of the messages are generated deep in the code below set_accepted()
[05:53] <kiko> (can someone restore the topic?)
[05:54] <SteveA> ta
[05:54] <SteveA> beat me to it
[05:54] <Kinnison> no problem
[05:55] <Kinnison> it's supposed to order them just fine
[05:55] <Kinnison> unless sqlobject's .union() method is unreliable
[05:56] <kiko> salgado-afk knows all about union
[05:56] <Kinnison> poo :-(
[05:56] <Kinnison> cprov: as soon as I can get a reliable ordering out of getFancyQueueItems, I'm done fixing up this test, it's neater and more reliable
[05:56] <cprov> Kinnison: good
[05:57] <Kinnison> but currently the snippet I nopasted for stevea is unreliabl
[05:57] <Kinnison> e
[05:57] <Kinnison> it fails about one time in four for me
[05:57] <SteveA> Kinnison: i already said how to make the test reliable
[05:57] <SteveA> better to make that change, and then choose whether to sort out deeper changes later on
[05:58] <Kinnison> SteveA: okay, I figured it'd be nicer to make getFancyQueueItems ordering-stable since it clearly tries to be, but I guess for now I can short-circuit the test
[06:03] <SteveA> Kinnison: thanks for keeping indeterminately-ordered tests out of RF :-)
[06:03] <kiko> yes as a public service
[06:03] <Kinnison> https://chinstrap.ubuntu.com/~dsilvers/paste/fileyKmqjf.html
[06:03] <Kinnison> SteveA: is ^^ that okay?
[06:08] <Kinnison> 27 seconds :-(
[06:08] <niemeyer> "The following 674 words could not be found in the dictionary of 7 words and are highlighted below:"
[06:08] <Kinnison> cprov: the fix for all that is pushing now
[06:08] <niemeyer> That's *SO* useful.. :)
[06:08] <Kinnison> cprov: after you've reviewed it, let me know if you're happy for me to close those bugs
[06:08] <Kinnison> niemeyer: dictionary of seven words?
[06:08] <cprov> Kinnison: ok
[06:08] <Kinnison> cprov: pushed
[06:09] <Kinnison> cprov: i have a bug report from colin about the queue tool. Shall I investigate that now?
[06:09] <niemeyer> Kinnison: Yeah.. :)
[06:09] <Kinnison> niemeyer: how... useful
[06:09] <cprov> Kinnison: yes, in the meanwhile I can merge your changes and review
[06:09] <Kinnison> cprov: cool
[06:11] <SteveA> Kinnison: looks good to me
[06:11] <SteveA> i would add in the doc part of the doctest that the output can be in any order, hence the L and sort()
[06:20] <Kinnison> SteveA: is https://chinstrap.ubuntu.com/~dsilvers/paste/fileqCjeZE.html the result of a lack of execute_zcml_for_scripts?
[06:21] <Kinnison> SteveA: or should I be asking for IPersonSet instead of IPerson?
[06:22] <SteveA> Kinnison: without seeing code, it is hard to say
[06:22] <Kinnison> n/m I should be using the Set I'm pretty sure
[06:22] <SteveA> IPersonSet is a utility
[06:22] <SteveA> IPerson is a content object
[06:22] <Kinnison> yep
[06:22] <Kinnison> ta
[06:22] <Kinnison> I blame the mortgage people
[06:22] <Kinnison> they confused me earlier
[06:22] <Kinnison> with talk of interest rates
[06:24] <sivang> rehi all
[06:27] <Kinnison> carlos: Did you manage to get that branch okay to work on your tests?
[06:28] <carlos> Kinnison: not yet, still fixing a more urgent issue. I need to request a fast review and a cherry pick
[06:28] <Kinnison> carlos: righty, no rush from me
[06:28] <carlos> Kinnison: anyway I think I have enough information, thank you
[06:29] <Kinnison> cprov: I've fixed a bug in queue and pushed a fix along with a security.cfg change
[06:29] <cprov> Kinnison: ok
[06:29] <Kinnison> cprov: I'll mail stuart about doing the grant until we can get it merged
[06:30] <Kinnison> done, CCed to you
[06:30] <cprov> Kinnison: good, thx
[06:38] <daf> carlos: about bug #3991
[06:38] <Ubugtu> malone bug 3991 in rosetta "Timeout error on translation page (+translate)" [Normal,Confirmed]  http://launchpad.net/bugs/3991
[06:38] <daf> carlos: er, I mean bug 5751
[06:39] <carlos> daf: yes?
[06:39] <daf> Stuart asks: "It returns over 400 rows - are we actually using all of
[06:39] <daf>   these results? If not, why arn't we doing more filtering in the database?"
[06:40] <daf> could you answer that in a comment?
[06:40] <daf> also, have you implemented Steve's suggestions for code cleanup?
[06:40] <daf> if so, could you say so?
[06:41] <carlos> daf: that's not 5751...
[06:41] <carlos> at least, I don't see any comment from Stuart...
[06:41] <daf> see the description
[06:41] <Kinnison> ciau
[06:42] <salgado> Kinnison, the results of a union() are always orderred by the value of the orderBy argument of that union() call. the orderBy arguments of the SelectResults that make that union are ignored
[06:42] <daf> carlos: also: does this bug need to be private?
[06:42] <carlos> oh, right....
[06:42] <salgado> I mean, that's how it should work. if it doesn't work that way, then it's a bug and I'd be glad if you could find how to reproduce it
[06:42] <carlos> daf: it has SQL code that shows part of our DB schema
[06:43] <daf> so does #3991, and that one isn't private
[06:43] <daf> we should be consistent
[06:43] <daf> SteveA: what do you think?
[06:44] <SteveA> i think i'm on the phone
[06:44] <carlos> daf: I didn't open 3991, I filed 5751... I didn't noticied that 3991 was not private
[06:45] <daf> maybe we should just remove the traceback from the description
[06:45] <daf> they look like differenct queries
[06:46] <carlos> daf: also, malone ate my comment when I first closed that bug (5751)
[06:46] <daf> the query that goes It returns over 400 rows - are we actually using all of
[06:46] <carlos> daf: I implemented Steve's solution
[06:46] <daf> bah
[06:46] <daf> the query that goes SELECT DISTINCT POSubmission.id FROM POSubmission JOIN POMsgSet ON POSubmission.pomsgset = POMsgSet.id JOIN POFile ON ...
[06:46] <daf> also seems to time out quite a bit
[06:46] <daf> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-07/C290
[06:46] <daf> do we have a bug open on that?
[06:46] <carlos> daf: and added a new one saying that it failed and that we are going to use AJAX to solve it
[06:46] <daf> carlos: that's good, you should be proud and say so!
[06:47] <daf> :)
[06:47] <carlos> daf: it's noted on that bug already!
[06:47] <carlos> I added it this morning when I wake up
[06:47] <daf> sorry, what's noted on the bug?
[06:48] <daf> I suppose your comment could be read to imply "I implemented what Steve suggested and it's still too slow"
[06:48] <daf> but it's better to say it explicitly
[06:49] <carlos> daf: I did it but as I just told you.... malone ate that comment
[06:49] <carlos> seems like the comments when you change the status of a bug are now stored as normal comments
[06:50] <carlos> but the old ones are removed when you add another comment
[06:50] <carlos> bradb: around?
[06:50] <daf> carlos: weird
[06:50] <daf> carlos: sorry, I understand now
[06:50] <carlos> daf: don't worry
[06:51] <carlos> I will add the comment again
[06:58] <BjornT> carlos: what exactly did you do when malone ate the comment? is it reproducable?
[06:58] <carlos> BjornT: I don't know if we can reproduce it
[06:58] <carlos> but I suppose it's possible yes
[06:58] <carlos> let me look for a closed bug...
[06:59] <carlos> BjornT: ok, https://launchpad.net/products/rosetta/+bug/1604/+editstatus
[06:59] <Ubugtu> malone bug 1604 in rosetta ".tgz not recognized as tarball" [Normal,Fix committed]  
[07:00] <carlos> BjornT: that bug was set as fixed before the change that makes malone to store the status comments as a normal comment to the bug
[07:01] <carlos> BjornT: if you submit that form with a new comment, malone will store the new one and the old status message (that is not a bug comment) will disappear
[07:03] <BjornT> carlos: ah, so it's that text that disappear. i thought that the comment you added got eaten up.
[07:03] <carlos> spiv: do you have time for a really fast review? I left out some changes you requested with PoMsgSetPage review and I need to request a cherrypick of that branch + this small fix 
[07:03] <carlos> BjornT: well, that's also a comment
[07:04] <carlos> and will only happen with old bugs
[07:04] <BjornT> carlos: still kind of a bug, so you should report it.
[07:04] <carlos> ok
[07:04] <carlos> BjornT: so it's not a feature, ok ;-)
[07:05] <carlos> hmmm perhaps it's a bit early for spiv.... salgado, around?
[07:06] <salgado> carlos, yes?
[07:06] <carlos> salgado: do you have time for a really fast review?
[07:09] <salgado> carlos, if it's realy fast, I think so
[07:09] <salgado> where's the patch?
[07:09] <carlos> salgado: https://chinstrap.ubuntu.com/~dsilvers/paste/filewmAh5G.html
[07:09] <carlos> salgado: if you think it's not easy to review, just tell me and I will request a normal review
[07:14] <iwj> Am I supposed to be able to see how my builds are coming along in soyuz ?  https://launchpad.net/distros/ubuntu/dapper/+source/firefox is a bit gnomic ?
[07:16] <salgado> carlos, I don't feel confortable reviewing it because I'm not used to that part of the code and I won't have time to do it now. :-(
[07:16] <carlos> ok
[07:16] <carlos> I will wait for spiv
[07:17] <carlos> salgado: thank you anyway
[07:18] <salgado> np
[07:18] <lamont-work> bradb: so... I'm looking at the binary package page, and I want to file a bug...   how now, brown cow?
[07:19] <lamont-work> bradb: say from https://launchpad.net/distros/ubuntu/breezy/+package/libmp4v2-dev/
[07:19] <SteveA> daf: did you make public those soyuz UI things we discussed?
[07:19] <SteveA> daf: this is important for some of the questions like lamont's
[07:21] <bradb> lamont-away: For now, best to specify the bin package name at: https://launchpad.net/distros/ubuntu/+filebug .
[07:22] <bradb> Binary packages seem sadly neglected atm in Launchpad.
[07:22] <bradb> WRT to the web UI.
[07:23] <bradb> carlos: Malone eats comments?
[07:23] <carlos> bradb: I'm filing the bug atm
[07:24] <carlos> let me finish it and we comment it
[07:24] <bradb> ok
[07:24] <bradb> I know that it eats status explanations, but that's usually a good thing.
[07:26] <carlos> bradb: https://launchpad.net/products/malone/+bug/30861
[07:27] <Ubugtu> malone bug 30861 in malone "Malone ate my editstatus comment" [Normal,Unconfirmed]  
[07:27] <carlos> bradb: then is the same problem
[07:27] <carlos> bradb: why is that a good thing??
[07:28] <lamont-work> bradb: that was what he noticed... :-)
[07:28] <bradb> carlos: Malone doesn't have a status explanation field anymore.
[07:28] <carlos> bradb: the old status explanations are not migrated as comments so we are losing information
[07:28] <carlos> bradb: and that's fine, but if we migrate them as comments first....
[07:29] <bradb> carlos: Yeah. I suggested migrating them as comments, but SteveA didn't want to do that. I think his alternative suggestion (the way we do it now) is also pretty reasonable though.
[07:29] <carlos> bradb: what's the alternative suggestion?
[07:29] <carlos> is that on production?
[07:29] <bradb> carlos: The way we do it now.
[07:29] <bradb> Yeah, with the most recent comment on change, etc.
[07:30] <carlos> but we still lose data...
[07:30] <bradb> carlos: yeah, no getting around that with the decision to not turn them into comments.
[07:30] <carlos> anyway, if the field is removed, how is that we still see old explanations?
[07:30] <bradb> carlos: When a new comment on change is made, they're gone forever.
[07:31] <SteveA> carlos: we looked through all the status whiteboards.  there were very few that were significant.
[07:32] <BjornT> bradb: it could be that malone does eat comments, though. look at bug 30832. i'm not sure what's wrong, haven't looked closely at it yet.
[07:32] <carlos> SteveA: well, it's an unexpected behaviour, perhaps we should warn the users... or at least document it or something... now that I know that I can "workaround" it.
[07:33] <carlos> anyway, I suppose it's not a big deal if you checked all those comments and nothing important was found.
[07:34] <SteveA> yeah.  the issue is, if we migrated them to comments, we'd be adding to confusion
[07:34] <SteveA> adding out-of-step comments where none was before
[07:34] <bradb> BjornT: What's the issue with bug 30832?
[07:34] <Ubugtu> malone bug 30832 in rosetta "+translation page gives me an AttributeError" [Normal,Confirmed]  http://launchpad.net/bugs/30832
[07:34] <SteveA> if you're changing the status whiteboard, then you're changing the status, so you need to decide whether the old status still applies
[07:34] <carlos> SteveA: yeah, I understand the problem
[07:35] <BjornT> bradb: he added a comment, a notification was sent, but the comment wasn't added to the bug. when he tried to add it again, it worked though.
[07:35] <BjornT> bradb: oh, wrong bug number...
[07:36] <BjornT> bradb: bug 30823
[07:36] <Ubugtu> malone bug 30823 in malone "Malone swallows comments" [Normal,Unconfirmed]  http://launchpad.net/bugs/30823
[07:38] <bradb> BjornT: Hm, this one might be hard to reproduce.
[07:39] <BjornT> yeah.... does anyone have access to production db?
[07:39] <kiko> yes
[07:39] <kiko> read-only but yes
[07:39] <zyga> hello hard working friends :-)
[07:40] <BjornT> kiko: could you check if the message table contains a message with rfc822msgid: <20060208124516.11152.78792.malone@gandwana.ubuntu.com>
[07:40] <kiko-afk> if you precook the query it will help
[07:41] <bradb> TV dinner DBA!
[07:41] <kiko-afk> busted!
[07:41] <kiko-afk> L O L
[07:41] <BjornT> kiko-afk: select * from message where rfc822msgid = '<20060208124516.11152.78792.malone@gandwana.ubuntu.com>';
[07:42] <kiko-afk> 0 rows
[07:42] <BjornT> just be sure: select * from message where rfc822msgid = '<20060208124706.32277.45742.malone@gangotri.ubuntu.com>';
[07:42] <kiko-afk> 1 row
[07:43] <kiko-afk> is there anything I can do for you? I will be back in 20 minutes
[07:43] <BjornT> kiko-afk: no, not atm, thanks
[07:43] <kiko-afk> great.
[07:44] <BjornT> so it seems like the transaction got aborted, but the bug notification email was sent despite that. he didn't recall any error messages either.
[07:45] <bradb> Hard to say even if a transaction got aborted, I think. It could just be pebcak.
[07:45] <SteveA> BjornT: can we see from the web request logs?
[07:45] <bradb> If he can't reproduce it, it might not be worth spending too much time on. I followed up to the bug to get more information.
[07:45] <BjornT> SteveA: we should be able to see something, yes. are they located anywhere accessible?
[07:45] <SteveA> yes
[07:46] <SteveA> chinstrap
[07:46] <SteveA>  /srv/ and then you need to guess
[07:46] <SteveA> depending which app server it was
[07:46] <BjornT> ok
[07:47] <BjornT> isn't gandwana an app server?
[07:50] <elmo> yes, it is
[07:53] <bradb> salgado: Hm, interesting, bug 30862. I guess our vocabs don't yet understand private email addresses?
[07:54] <tseng> is anyone able to merge my accounts given gpg signed confirmation?
[07:54] <tseng> one of the email addresses involved is acting up
[07:55] <salgado> SteveA, I guess you're the only one who can help tseng here
[07:57] <salgado> bradb, yeah, that's a known problem. we (me, kiko an stub) decided that this change to the vocabs would be done in a later
[07:58] <salgado> what was urgent was to not show people's email addresses on their home page
[07:58] <SteveA> tseng: hello
[07:58] <tseng> SteveA: hi :)
[07:59] <carlos> see you later
[07:59] <bradb> salgado: ok
[07:59] <SteveA> tseng: so, you have two launchpad accounts, but cannot access the email address on one of them?
[07:59] <tseng> SteveA: yep
[07:59] <tseng> SteveA: unfortunately the one with the bad address left behind is joined to all the relevant groups
[07:59] <SteveA> i see
[07:59] <tseng> ubuntu-dev core-dev etc
[08:00] <SteveA> let's talk in private
[08:00] <tseng> np.
[08:00] <dholbach> Hello.
[08:00] <ajmitch_> hi
[08:01] <dholbach> Is an issue about Malone not displaying links to attachments known already?
[08:01] <bradb> dholbach: I don't think so. Can you describe the problem, with URLs?
[08:02] <dholbach> http://launchpad.net/malone/bugs/29253 for example is a bug that has 2 attachments (I got that from mails that were sent to me because of desktop-bugs@) - it doesn't display the links to the attachments on the page.
[08:02] <Ubugtu> malone bug 29253 in gdm "Crash on second login" [Normal,Needs info]  
[08:04] <bradb> dholbach: How were the attachments fed into malone?
[08:05] <dholbach> No idea, sorry - as you can see from the Activity Log, I was not involved.
[08:06] <ogra> https://launchpad.net/distros/ubuntu/dapper/+source/ltsp/+pots/pkgconf-ltsp/de/+translate
[08:06] <ogra> gives me an opps 
[08:07] <matsubara> ogra: known problem
[08:07] <ogra> oki
[08:07] <matsubara> ogra: bug 3176
[08:07] <Ubugtu> malone bug 3176 in launchpad "Error when trying to save AbiWord pt-BR translations" [Normal,Fix committed]  http://launchpad.net/bugs/3176
[08:07] <bradb> BjornT: The email interface doesn't know about attachments, right?
[08:07] <ogra> oh, i was only accessing it ...
[08:07] <ogra> (not saving) 
[08:08] <matsubara> ogra: but it's the same bug. lots of reports about it lately
[08:08] <BjornT> bradb: that's right. there's a bug open on that
[08:08] <ogra> oki, then i'm fine ...
[08:08] <ogra> will be patient ...
[08:08] <bradb> dholbach: So if these attachments were fed in via email, that would explain it.
[08:09] <dholbach> Oh, if it's that known bug, then it's ok for me.
[08:10] <bradb> dholbach: One thing: were the emails you received Cc desktop-bugs, and addressed to malone?
[08:10] <ogra> dholbach, seems working for the launchpad team is way easier ;) they know all their bugs in advance :)
[08:10] <bradb> Well, i.e., was the Malone submit bug address a recipient of the email
[08:11] <dholbach> bradb: I can forward them to you.
[08:11] <bradb> dholbach: sure, that'd be good. brad.bollenbach@gmail.com.
[08:11] <dholbach> ok
[08:51] <bradb> BjornT: Just so we can let dholbach know, when will that attachment junk stripper be rolled out?
[08:52] <BjornT> bradb: it has been rolled out, i think it was last week
[08:52] <bradb> ah, ok, great.
[08:54] <dholbach> Wouldn't it be more useful to just display the list of links? (as they seem to be in librarian already)
[08:54] <kiko> that is an idea
[08:58] <kiko> cprov, could you answer to siretart (Reinhard)'s email to launchpad-users?
[08:58] <cprov> kiko: will see
[08:58] <kiko> Date: Sun, 5 Feb 2006 20:10:07 +0100
[08:58] <kiko> thank you very much
[08:59] <bradb> BjornT: One thing still confuses me: why was this stored as an attachment: http://librarian.launchpad.net/1538638/unnamed ?
[09:00] <bradb> These particular attachments would be useless to show in the UI, because it's just the entire original message.
[09:00] <zyga> hi
[09:00] <zyga> FAQ: is dapper open yet 
[09:00] <kiko> matsubara, I am looking at your fix for bug 933
[09:00] <kiko> I have a question
[09:00] <zyga> I can make a wiki I'd just need a reliable answer
[09:00] <kiko> what happens if you post a second bugtracker with the same name?
[09:01] <kiko> zyga, yes, it is open for development
[09:01] <zyga> kiko: for translations
[09:01] <kiko> ah. that is a carlos question
[09:01] <zyga> carlos: ^^^
[09:01] <matsubara> kiko: BugTaskNameField enters in action, why?
[09:02] <kiko> matsubara, not BugTrackerNameField?!
[09:02] <BjornT> bradb: every email, with all its attachments, is stored in the librarian. we'll probably move away from that, and extract the parts we're interested in, but it has low priority atm.
[09:02] <matsubara> kiko: ops, yep BugTrackerNameField
[09:02] <kiko> okay.
[09:02] <kiko> thanks.
[09:03] <bradb> BjornT: That's what I thought. So the emails that I forwarded to you indicate that HMRubuntu used the email interface in these interactions with Malone, right?
[09:03] <BjornT> bradb: yes
[09:03] <bradb> riiiight. It all fits together now.
[09:05] <bradb> So, dholbach, normally we do show links for "real" bug attachments, but what happened here is that (1) HMRubuntu used the email UI to interact with Malone so (2) his emails were stored as attachments and then (3) there was a Malone bug that spewed attachment junk at the end of messages like that, which BjornT fixed. But it appears that HMRubuntu did add an attachment to this bug, per se. Does that sort of make sense?
[09:06] <bradb> s/did add an attachment/didn't add an attachment/
[09:07] <dholbach> Oh yeah, might be. What is the plan? Strip attachments off?
[09:08] <dholbach> I'd like it better for them to remain and be indexed for a portlet on the right side (as normal attachments do as well).
[09:09] <bradb> dholbach: Normal attachments are. But there were no real attachments added to this bug. It was an implementation detail of Malone (that it stores all incoming mails as attachments) that leaked up to the interface, in this case.
[09:09] <bradb> But if you were to add a patch to a bug through the web UI (because it's not possible through the email UI), it would be linked in a portlet from the bug page.
[09:09] <dholbach> Hm, how about adding it by mail?
[09:10] <bradb> Assuming we still have that portlet. :) At worst, attachments are also linked with the comment that was made when they were submitted.
[09:11] <bradb> dholbach: bug 30225
[09:11] <Ubugtu> malone bug 30225 in malone "Attach files via email" [Normal,Confirmed]  http://launchpad.net/bugs/30225
[09:11] <dholbach> ok
[09:17] <dholbach> good night.
[09:18] <bradb> see ya
[09:45] <dilys> Merge to devel/launchpad/: [trivial]  Removing obsolete changelog 'linkification' process and added tests for the remaining code. The missed author's changelog line is fixed in the Soyuz codeline. (r3106: Celso Providelo)
[10:09] <kiko> ajmitch: your link to the Launchpad firewalls spec entry is broken at https://wiki.ubuntu.com/Firewalls
[10:09] <kiko> just fyi
[10:11] <ajmitch_> no surprise, I should fix that to point to the right wiki page
[10:11] <kiko> actually the reverse link is what's broken
[10:11] <kiko> wiki to lp
[10:12] <ajmitch_> but the wiki page is wrong anyway :)
[10:17] <kiko> I love error reports
[10:17] <cprov> good night guys
[10:30] <ajmitch_> kiko: looks like it's pointing to the right wiki page (https://wiki.ubuntu.com/SoC-Firewall)
[10:30] <ajmitch_>  https://wiki.ubuntu.com/Firewalls is old, I added the lp spec link by mistake
[10:31] <kiko> aha
[10:51] <kiko> lifeless, how's the story testrunning going?
[11:15] <carlos> zyga: no, dapper is not yet open to translate but I'm working on testing the new process and if all things go well we will start importing translations.
[11:15] <lifeless> kiko: it works, I just need to do spivs review requests
[11:16] <zyga> carlos: I'd like to make a FAQ on the wiki
[11:16] <lifeless> I might ask spiv to apply them actually, bzr stuff is pretty intense for the next 3 weeks - Major release and data format stability stuff
[11:16] <zyga> carlos: can you give me any estimate (even from the top of your head?)
[11:16] <lifeless> essentially sprinting every day
[11:16] <lifeless> spiv: what do you think ?
[11:16] <zyga> it's mainly for translators that bump in and ask: 'ah, what about dapper'
[11:17] <kiko> lifeless, please hand it off to spiv.
[11:17] <lifeless> kiko: you want it bad dontcha
[11:17] <kiko> yeah :)
[11:18] <carlos> zyga: I really don't know. I will try to start doing imports next week. I suppose you could say at the end of the month and if it's earlier (I hope that) people will be more happy ;-)
[11:18] <zyga> carlos: k
[11:19] <zyga> carlos: any suggestions to translators that ask: "what do to till then?"
[11:19] <carlos> zyga: translate Hoary and Breezy
[11:19] <carlos> they are still supported
[11:19] <carlos> and the translations will be reused with dapper
[11:20] <zyga> k, thanks
[11:23] <kiko> BjornT, thanks :)
[11:23] <BjornT> np :)
[11:24] <kiko> go get some sleep!
[11:25] <BjornT> sounds like a good idea