[12:06] <dilys> New Malone bug 1358 filed on product Malone by Matthew Paul Thomas: Sort order should be indicated in Malone results
[12:06] <dilys> https://launchpad.ubuntu.com/malone/bugs/1358
[12:29] <dilys> New Malone bug 1359 filed on product Malone by Matthew Paul Thomas: Don't display unmodified bug description as a comment
[12:29] <dilys> https://launchpad.ubuntu.com/malone/bugs/1359
[12:50] <jbailey> mpt: ping
[12:50] <mpt> jbailey: pong
[12:51] <jbailey> mpt: Are you interested in my answers to the some of the questions you posed (as to what I was thinking, etc.) or is it better that I stay out of it and not think about it so that brad can use me as a test case again in a month when I've generally forgotten what I saw?
[12:51] <mpt> heh
[12:51] <mpt> um
[12:52] <mpt> Well, if you don't have to use Malone yet, my guess would be that you're more valuable as a test subject by leaving it alone
[12:52] <mpt> and not thinking about it
[12:54] <jbailey> And I don't until main gets converted over.
[12:54] <jbailey> I'll avoid reading Bjorn's message then.  Feel free to poke me with things if you need.
[12:55] <jbailey> FWIW, I can give you access to Canonical's RT system.
[02:06] <comadreja> howdy all
[02:06] <comadreja> I'm missing the version number in the bug reporting tool
[02:06] <comadreja> I mean to be able to state the version of the package that is being reported as buggy
[07:41] <dilys> New Malone bug 1365 filed on product Malone by Matthew Paul Thomas: Priority should default to a null value
[07:41] <dilys> https://launchpad.ubuntu.com/malone/bugs/1365
[07:49] <jamesh> mpt: I added a few bug linkifying examples to https://wiki.launchpad.canonical.com/DisplayingParagraphsOfText
[07:51] <mpt> jamesh: ah, I wasn't expecting bug links to be part of the same algorithm
[07:51] <mpt> but to be Malone-specific
[07:51] <jamesh> mpt: I think it needs to be done in one pass
[07:51] <jamesh> mpt: considering "http://example.com/bug#123" vs. "bug#123"
[07:51] <jamesh> one being a URL, the other being a bug link
[07:51] <mpt> Well, for example, if release notes for some Gnome app say "fix bug 27847", they're talking about bugzilla.gnome.org, not Malone.
[07:52] <mpt> Same for KDE and Mozilla and most other upstreams.
[07:52] <jamesh> mpt: okay.  The bug tracker I used in the examples is secondary -- I was mainly trying to think of corner cases for the text processing
[07:53] <jamesh> mpt: feel free to modify the examples as you see fit.
[07:54] <mpt> They all look reasonable to me, jamesh
[07:54] <mpt> Perhaps we just need a flag saying "do bug linkifying as well"
[07:54] <mpt> that can be on for Malone use, and off everywhere else
[07:54] <mpt> thanks for the examples.
[07:59] <mpt> heh, Breezy has *2* bugs in Malone
[08:08] <jamesh> mpt: for the calendar code, do you think that the links between day, week, month and year views should be using the LaunchpadMenus code?
[08:08] <mpt> yes
[08:09] <mpt> ApplicationMenu
[08:09] <jamesh> cool.  I'll look at doing that
[08:09] <mpt> thanks
[08:23] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Index required by Gina (patch-2071: stuart.bishop@canonical.com)
[09:54] <BjornT> mpt: hi. launchpad--decruftify-b--1 has conflicts. if you resolve them, I'll review it today.
[09:55] <mpt> ok, thanks BjornT
[09:55] <carlos> morning
[10:01] <sivang> morning carlos 
[10:10] <carlos> stub, could you kill all poimport scripts?
[10:10] <carlos> stub, I'm fixing that problem already, but seems like we will need to kill the script once/day until breezy is imported or the process will be stalled
[10:13] <stub> carlos: Done
[10:15] <carlos> stub, thank you
[10:16] <lifeless> carlos: can we cron the kill ?
[10:18] <morgs> stub: I've another RF patch for cherrypicking for the rollout, if that's OK... patch-2059 is a bugfix for the RDF exporting, to make the output actually RDF compliant and Edd Dumbill less sad. Not critical, but it's not a big patch IMHO and it would be nice to get into production :-)
[10:18] <morgs> stub: This is besides patch 2050 which fixes the lack of links to product releases from the product and product series pages...
[10:19] <stub> morgs: I couldn't cherry pick that patch (2050). Neither sounds critical enough to rollout today instead of tomorrow.
[10:20] <morgs> stub: I'd just like these things to go live before next Tuesday... What patch is going up to production?
[10:20] <stub> morgs: Don't know yet, but I'll make sure those two go in.
[10:21] <morgs> stub: thanks, that's fine. Just wanted to make sure it wasn't the exact patch as of the Thursday meeting...
[10:21] <stub> pqm issues made that problematic
[10:25] <carlos> lifeless, hmmm, perhaps, as the process will restart the import next time it's executed, we could kill it at anytime we want, until breezy import is done in one or two days
[10:26] <lifeless> jamesh: so did you do the equivalent of get ...366, diff rocketfuel ?
[10:26] <mpt> It seems like months since a rollout
[10:26] <SteveA>   DeprecationWarning)
[10:27] <SteveA>  /scratch/dists/launchpad/lib/canonical/launchpad/database/product.py:222: DeprecationWarning: Product.potemplates is obsolete, should be on ProductRelease
[10:27] <SteveA>   DeprecationWarning)
[10:27] <jamesh> lifeless: I used the commands at the bottom of https://wiki.launchpad.canonical.com/TipsForReviewers (which I think is the right way to get the diffs in this case)
[10:27] <SteveA> morgs: can you fix that?
[10:27] <jamesh> lifeless: i.e. diff "rocketfuel with the old rev merged" and "rocketfuel with the new rev merged"
[10:28] <morgs> SteveA: I'll take a look...
[10:28] <lifeless> jamesh: uhm
[10:29] <lifeless> jamesh: yes, that should give reasonable results, modulo merges from third party branches
[10:30] <jamesh> lifeless: is there a better way to perform that operation then?
[10:30] <lifeless> in which case, yes you picked bad patches.
[10:30] <lifeless> as the only patches that needed reviewing as new were 364,365,366
[10:31] <lifeless> I don't really mind -code quality is code quality - but it was surprising :[
[10:32] <jamesh> lifeless: if I create two rocketfuel trees of the same patch level, and merge your branch at one patch level into one, and your branch at another patch level into the other
[10:32] <jamesh> the difference between those two trees should be the changes on your branch minus rocketfuel merges, right?
[10:33] <jamesh> it would only have third party merges if they were in your branch, I think
[10:33] <lifeless> lets unmultiplex this
[10:34] <lifeless> I was complaining cause you reviewed 350-366, when you'd already done 350-363, and got different review feedback
[10:34] <jamesh> okay.  I picked the wrong revisions.
[10:35] <lifeless> actually, you'
[10:36] <lifeless> d probably done 350-362 or something, as there was a rf merge or so in there.
[10:36] <lifeless> but anyhoo.
[10:36] <lifeless> I'm not stressed - but it was surprising and somewhat confusing.
[10:36] <lifeless> I'm acting on the review now.
[10:37] <lifeless> with regards the baz gymnastics ...
[10:37] <lifeless> grabbing branch A twice, merging FROM to one copy and TO to another copy has the effect of cancelling out branch A's changes to FROM and TO
[10:38] <lifeless> but that assumes a clean triangle.
[10:38] <lifeless> if for example I imported a branch from ddaa which was being separately reviewed, you'd see that in the diff
[10:38] <jamesh> yes
[10:39] <lifeless> thats what I meant by third party branch.
[10:40] <jamesh> that happened when I was reviewing Mark's debbugs branch (which included some stuff he'd passed off to Scott)
[10:40] <lifeless> interestingly, we could import the code into a weave and generate a synthetic my-branch-only list of changes.
[10:40] <lifeless> but thats Future.
[10:40] <jamesh> of course, it does tell me what would be going into rocketfuel if the branch was merged
[10:40] <jamesh> which is one of the things I want to know when reviewing something
[10:41] <lifeless> right
[10:41] <lifeless> theres a balance there.
[10:42] <lifeless> w.r.t. performance, it might be faster to do delta rf<->rf, delta branch<->branch, and interdiff
[10:42] <lifeless> then you'd have no merges at alll
[10:43] <lifeless> baz delta --diffs first second > branch-to-merge.diff would also shave a second or two off
[10:44] <jamesh> I didn't notice that function.
[10:45] <lifeless> oh
[10:45] <lifeless> you can cp -al first second
[10:45] <lifeless> that will be much faster
[10:46] <lifeless> try this
[10:46] <lifeless> baz get rocketfuel@canonical.com/launchpad--devel--0 first
[10:46] <lifeless> baz merge -d first --star-merge branch-to-merge--patch-XXX
[10:46] <mpt> woohoo, botched invariant again
[10:46] <lifeless> cp -al first second
[10:47] <lifeless> baz merge -d second --star-merge branch-to-merge
[10:47] <lifeless> baz delta --diffs first second > branch-to-merge.diff
[10:48] <jamesh> so that'll give the minimum number of files with different inode numbers between the two trees?
[10:48] <jamesh> and speed up the diff
[10:48] <lifeless> -al makes a hardlink of the two
[10:48] <jamesh> yeah
[10:48] <lifeless> the diff won't be optimised at all with changeset
[10:48] <lifeless> it may with delta, but what you really need is baz 1.5's tree format that I'm hacking on at the moment
[10:49] <lifeless> it will optimise 
[10:51] <lifeless> oh, with -al it will skip diffing all the linked-but-not-mutated files
[10:51] <lifeless> so it should be quite a lot faster really.
[10:51] <lifeless> give it a try ;0
[10:51] <lifeless> :89
[10:51] <jamesh> that's what I was getting at
[10:52] <lifeless> yah. 
[10:52] <jamesh> doing the copy after the first merge would reduce the amount of comparisons over doing the copy before either merge
[10:52] <lifeless> right, that was one of the reasons I suggested that. It also reduces the size of the merge to do
[10:52] <lifeless> and gives a pristine tree of the relevant revision to use as the merge bases
[10:53] <lifeless> this if block :
[10:53] <lifeless>        return (len(lines) < 4
[10:53] <lifeless>                 or not lines[2] .startswith('---')
[10:53] <lifeless>                 or not lines[3] .startswith('+++'))
[10:53] <lifeless> when I write it with a not, it becomes less clear to me
[10:54] <lifeless> can you articulate why you think its more readable inversed ?
[10:54] <jamesh> I saw it as "a valid diff is at least 4 lines long, the 3rd line starting with '---' and the 4th line starting with '+++'"
[10:54] <jamesh> so you want o return the opposite of that
[10:55] <lifeless> so I see it as 'an invalid diff has less than 4 lines, or does not have a 3rd line beginning with '---' ....
[10:56] <lifeless> when I have to invert the whole thing, it doesn't make as much sense. I could invert it, remove the leading not, invert the function to isValidPatch, and then use not isValidPath
[10:56] <lifeless> w
[10:56] <jamesh> feel free to leave it as is then.
[10:56] <lifeless> k
[10:56] <morgs> --star-merge worked though
[10:57] <SteveA> it is much easier for me to think about things that include something in a set, rather than things that exlude something from a set.
[10:57] <lifeless> use --star-merge, I think there is something buggered in HEAD right now
[10:57] <SteveA> what i mean is, in jamesh's wording, i can think about it as "i'm examining a diff.  does it fit? let's see... four line long.  check.  third line starts with ---, check. etc."
[10:58] <SteveA> in lifeless's wording , i'm saying "is this diff invalid?  does it have less then four lines.  no.  otherwise, does it have the third line begining... "
[10:58] <lifeless> SteveA: right. the thing I don't like about inverting the if block in-line is that it becomes a double negatic
[10:58] <lifeless> better to invert, remove the not, invert the function name instead.
[10:58] <SteveA> rather than building up the predicates using "and" and building on the state you have built up before, you need to start again for each part of the "or"
[10:59] <SteveA> yes
[10:59] <SteveA> your wording fits better with me if i remove my python hat and put on a functional hat
[11:00] <lifeless> mmm
[11:00] <lifeless> I think isNullPatch (asis), or isValidPatch (inverted with leading not removed) are equivalent.
[11:01] <lifeless> isNullPatch (inverted) feels wrong and ugly.
[11:07] <lifeless> jamesh: so, for my sins, I've committed a fix to that, but there are now other commits (separately in the review queue)... can I impose on you to be the review for them, for simplicity ?
[11:07] <Kinnison> Application error.  Unauthenticated user POSTing to page that requires authentication.
[11:07] <Kinnison> SteveA: should we present a login page ^^ then, and when logged in, re-POST the contents?
[11:07] <jamesh> lifeless: sure.  which revs should I be looking at? :)
[11:07] <mpt> Kinnison: yes, that bug's reported
[11:08] <Kinnison> mpt: okay thanks
[11:08] <lifeless> jamesh: well, reviews page lists the specific revs for other things
[11:08] <SteveA> Kinnison: yes, kind of, there's a bug on this.  we'll design it in brazil.
[11:08] <lifeless> jamesh: and 364 -> 371 are the ones you have not reviewed to date
[11:08] <Kinnison> SteveA: okay ta
[11:08] <jamesh> lifeless: thanks
[11:08] <SteveA> Kinnison: right now, if launchpad presents you with an opportunity to get that page, there is a bug in the page that led you there.
[11:09] <mpt> morgs: Friend of sabdfl's, party photographer and purveyor of completely-JavaScript-dependent Web sites
[11:09] <morgs> mpt: Ah, purveyor of bits of launchpad.js...
[11:26] <guim> Hi
[11:29] <mpt> arg
[11:29] <mpt> BjornT: why do /malone/assigned and /people/whoever/+assignedbugs both exist?
[11:32] <jamesh> mpt: the first is probably the older.
[11:32] <mpt> Well the first has undergone major changes recently
[11:34] <BjornT> mpt: good question. personally i'd like to see them merged so that only the latter would exist. should talk to bradb-afk and salgado about it.
[11:40] <SteveA> BjornT: browser/person.py, line 200 ish
[11:40] <SteveA>     def assignedBugsToShow(self):
[11:40] <SteveA>         """Return True if there's any bug assigned to this person that match
[11:40] <SteveA>         the criteria of mostImportantBugTasks() or mostRecentBugTasks()."""
[11:40] <SteveA>         return bool(self.mostImportantBugTasks() or self.mostRecentBugTasks())
[11:40] <SteveA> 
[11:40] <SteveA> one or both of those queries lacks an orderby
[11:41] <SteveA> so, when bool is used on them, we get a warning about unpredictable order
[11:41] <dilys> New Malone bug 1367 filed on product Malone by Matthew Paul Thomas: Merge /malone/assigned and /people/whoever/+assignedbugs
[11:41] <dilys> https://launchpad.ubuntu.com/malone/bugs/1367
[11:46] <guim> hi all
[11:47] <guim> I have a problem that maybe someone can help here
[11:47] <guim> I tried to subsrcibe to the edubuntu wiki, 
[11:48] <guim> then I had to creat a launchpad account (so far, this is at least what I understood)
[11:48] <guim> but it seems like the wiki do not recognize the login/pwd it gave me
[11:49] <guim> anyone to tell me what I did wrong?
[11:50] <guim> login/pwd works on the launchpad page
[11:50] <lifeless> hmm
[11:50] <lifeless> SteveA: does anyone other than spiv grok that foo ?
[11:52] <BjornT> SteveA: ok, both lack an order by. i'll take a look at it to see if i can make it use the search interface or something, since there's some code duplication. if not, i'll make the same fix i made to the search method.
[11:53] <SteveA> BjornT: okay.  i'm on a crusade to get rid of warnings when we run tests.
[11:53] <BjornT> cool
[11:53] <lifeless> guim: I'm sorry, I can't help you ...
[11:54] <SteveA> guim: are you using exactly the same login and password as works for launchpad?
[11:54] <SteveA> that is, an email address, and the password?
[11:54] <guim> ok 
[11:55] <guim> I check again, I might have done a silly mistake
[11:55] <SteveA> thanks.  come back if it doesn't work and we'll check out other things that might be wrong.
[11:56] <guim> thanks,
[11:56] <guim> i misunderstood the fact that login is e-mail and not name
[11:57] <SteveA> what were you using?  a WikiName ?
[11:57] <guim> sorry
[11:57] <SteveA> if you misunderstood, then it is probably that our system is hard to understand.
[11:57] <SteveA> so, maybe we can fix it.
[11:57] <SteveA> did you try to log in using your WikiName ?
[11:59] <guim> i tried with a a name yes
[11:59] <guim> the name i gave in the launchpad account 
[12:00] <lifeless> oh, like 'guim' ?
[12:01] <jamesh> guim: I think you need to use one of the email addresses registered with Launchpad as the username
[12:01] <guim> yes
[12:01] <lifeless> jamesh: we're past thata already ;0
[12:01] <guim> yes jamesh 
[12:01] <jamesh> oh :)
[12:01] <lifeless> guim: thanks, that helps.
[12:01] <guim> no problem
[12:01] <jamesh> that's what worked for the main ubuntu wiki after the auth change
[12:01] <jamesh> for me
[12:01] <SteveA> lifeless: do we have zope3 in the supermirror yet?
[12:01] <lifeless> SteveA: let me see
[12:02] <SteveA> someone is sending patches to the zope.interface mailing list
[12:02] <SteveA> and asking if there's a better way to show their ongoing proposed improvements
[12:02] <mpt> SteveA: https://wiki.launchpad.canonical.com/LaunchpadHierarchyNavigation#head-eb01bf04c9a0e8a71c45816513df424f1c7ffedb
[12:02] <SteveA> working on an svn branch is one option
[12:02] <SteveA> working on a baz branch would be sweet, though, as they wouldn't need svn access
[12:03] <SteveA> thanks mpt, i'll take a look
[12:03] <lifeless> it failed
[12:03] <lifeless> I've marked it for retest
[12:03] <SteveA> they use lots of fancy stuff to do with linking many different svn areas together
[12:04] <jamesh> svn:externals, I suppose
[12:04] <SteveA> jamesh: i used to know what it was.  i cleared that space for arch stuff ;-)
[12:07] <lifeless> SteveA: we need to do each area separately.
[12:07] <lifeless> SteveA: it'll be a pain
[12:12] <mpt> carlos: ping
[12:13] <SteveA> mpt: i still need to know what to call one "breadcrumb"
[12:13] <carlos> mpt, pong
[12:14] <mpt> SteveA: a hierarchy item?
[12:14] <mpt> Not very catchy, is it...
[12:14] <SteveA> class POTemplateNavigation(Navigation):
[12:14] <SteveA>     hierarchy_item = None
[12:14] <SteveA> 
[12:14] <SteveA> for example?
[12:14] <SteveA> i had it sketched as 'breadcrumb'
[12:14] <SteveA> it will actually be a function that returns a BreadcrumbLink
[12:15] <SteveA> or a HierarchyItemLink
[12:15] <SteveA> bleh
[12:15] <mpt> Chain
[12:15] <mpt> ChainLink
[12:15] <mpt> ?
[12:15] <SteveA> can't i just call them "breadcrumbs" ?
[12:15] <mpt> sure, if you like
[12:15] <SteveA> they seem to me to be breadcrumbs, but just selectively displayed
[12:15] <SteveA> and intelligently displayed
[12:16] <jamesh> SteveA: should all the ApplicationMenu subclasses go in browser/launchpad.py, or would it be better to group them with the associated component's code?
[12:17] <SteveA> they should all go in the approprite browser/thing.py module
[12:17] <SteveA> i don't know what's in browser/launchpad.py
[12:17] <SteveA> but, perhaps the ones for the "system homes" should go in there
[12:18] <jamesh> okay.  I was just noticing that the only file in browser/ that imports ApplicationMenu is browser/launchpad.py
[12:18] <SteveA> we have few application menus yet
[12:18] <jamesh> it includes the Rosetta ApplicationMenu 
[12:18] <SteveA> right
[12:18] <SteveA> for Rosetta the "system homepage" for rosetta
[12:18] <SteveA> i should put them into "system homes" or soemthing
[12:19] <SteveA> jamesh: i want to walk up the current execution stack, looking for a particular kind of class 
[12:19] <SteveA> know any shortcuts, or should i just walk sys._getFrame, and its parent?
[12:20] <jamesh> I don't know of a shortcut
[12:20] <mpt> carlos: Do you know what sabdfl is talking about when he says "ability to switch to the alt language and correct it. perhaps also having    a persistent alt language, rather than having to select it every time"?
[12:20] <SteveA> hmm, inspect has currentFrame
[12:21] <jamesh> finding the class for the frame can probably be done using a few heuristics
[12:22] <SteveA> the inspect stuff will get me what i need
[12:22] <SteveA> ta
[12:23] <carlos> mpt, hmmm
[12:23] <carlos> mpt, from there I think the idea is to have a link as part of the suggestions
[12:23] <carlos> that lets you get the edit form for that language and string so you can edit it
[12:24] <carlos> and also a way to store a preference for every user so they can choose the main language to translate into and a list of alternative languages they want to get suggestions from
[12:25] <carlos> the first should be easy, the later, I think it's a matter of expand our current language preferences page so the user can select a "default persistent alt language"
[12:26] <carlos> and show it by default with the translation form
[12:31] <mpt> carlos: oh, multiple source languages?
[12:32] <mpt> e.g. looking at the Portugese translations while doing the Brazilian Portugese one
[12:32] <carlos> mpt, yes
[12:32] <carlos> mpt, did you see current translation form?
[12:32] <mpt> carlos: Has it changed recently?
[12:32] <carlos> mpt, yes
[12:32] <mpt> crap
[12:33] <mpt> I have a branch to clean it up, but I'm a bit stuck
[12:33] <carlos> mpt, mark added a language selector to see suggestions
[12:33] <carlos> so you choose another language to see the suggestions
[12:33] <mpt> mpt@canonical.com/launchpad--translation-cleanup--0
[12:33] <carlos> mpt, so that's done more or less already, what is missing is a link to the edit form for that language just in case you see something wrong
[12:34] <mpt> that sounds like fun
[12:34] <carlos> mpt, and a way to select by default a language so you don't need to select it every time
[12:34] <mpt> click the link, and blow away the work you were doing on that page
[12:34] <mpt> ok
[12:34] <mpt> BjornT: mpt@canonical.com/launchpad--decruftify-b--1 is ready
[12:36] <SteveA> c
[12:36] <SteveA> EWINDOW
[12:38] <BjornT> mpt: cool. i'll review it after lunch
[12:53] <SteveA> stub: does canonical.launchpad.mailnotification need to directly access database code?
[12:53] <SteveA> carlos: does canonical.rosetta need to directly access database code?
[12:54] <carlos> canonical.rosetta?
[12:54] <stub> stub: Don't know - not my baby
[12:54] <SteveA> whose?
[12:54] <stub> bradb I think
[12:54] <carlos> oh, I see what do you mean
[12:55] <carlos> SteveA, I think we can fix it easily
[12:55] <carlos> SteveA, Mark added it to get some statistics
[12:56] <carlos> but we can do it with some methods added to the objectsets instead of using the database code
[12:56] <SteveA> okay, goo
[12:56] <SteveA> d
[01:05] <Kinnison> tonight I build myself a hoary-based PVR
[01:08] <mpt> thanks BjornT
[01:39] <jamesh> SteveA: have time for an ApplicationMenu question?
[01:39] <SteveA> ok
[01:39] <jamesh> in the calendar code, I have an ICalendar object at parent/+calendar, which has child contexts for the range being displayed (a particular day, week, month or year)
[01:40] <jamesh> I was looking at doing app menus attached to the date range contexts, but that means all the relative links are like "../yyyy-mm-dd" (or similar)
[01:41] <jamesh> If I attach the app menu to the ICalendar, I don't think I have any way to tell what date range is currently being displayed
[01:41] <jamesh> (which I need to know in order to make the menus point to the relevant pages)
[01:43] <SteveA> if you attach the app menu to ICalendar, it won't be displayed for a date range in that calendar anyway
[01:43] <jamesh> okay.
[01:43] <SteveA> an app menu is chosen according to the name of the currently selected facet link, but the app menu is specific to the current context
[01:44] <SteveA> so, you need to have the app menu working with the current date range context
[01:44] <SteveA> you should be able to get the calendar from a particular date range object
[01:44] <SteveA> and then you can get the canonical_url for other date ranges, got from the calendar
[01:45] <jamesh> I'll try switching over to canonical_url() and see if that makes things work a bit nicer
[01:53] <jamesh> that seems to work better
[02:37] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  import BugSetBase from the correct place. (patch-2072: bjorn.tillenius@canonical.com)
[02:39] <carlos> lifeless, ddaa, jblack  https://chinstrap.ubuntu.com/~dsilvers/paste/filedwkhcR.html
[02:39] <carlos> I'm not able to merge from rocketfuel
[02:40] <carlos> Bazaar version 1.5~200507091049
[02:41] <Kinnison> carlos: use baz merge --star-merge
[02:42] <carlos> Kinnison, hmm, that error does not looks like that kind of error, but anyway, will try
[02:42] <carlos> thank you
[02:43] <Kinnison> carlos: it's not, but star-merge is different codepaths so it won't have the issue
[02:43] <Kinnison> mesh merge needs a lot of work
[02:44] <ddaa> carlos: trying with --star-merge is always the first thing you should do after "baz merge" failed. The second thing is reporting the problem (yadda yadda revisions yadda reproducible yadda bug report)
[02:45] <ddaa> as Kinnison said, merge does a lot of things that star-merge never even heard of.
[02:45] <ddaa> that's a lot of opportunities for bugs to creep in.
[02:46] <cprov> someone knows if Staging is sending email correctly ?
[03:05] <stub> Staging does not send emails at the moment
[03:06] <cprov> stub:?! 
[03:15] <bradb> morning
[03:15] <bradb> mpt: as for why +assignedbugs exists, you'd have to ask salgado
[03:15] <bradb> SteveA: mailnotification.py shouldn't need to directly access db code
[03:19] <bradb> mpt: do you have time to discuss menus, by any chance?
[03:19] <mpt> bradb: yes
[03:19] <bradb> great, let's do it
[03:20] <mpt> and hey, Kinnison and cprov are here for Soyuz menus too
[03:20] <mpt> bradb: arh, I was supposed to put them in the LPMenus spec, and I forgot
[03:20] <mpt> sorry
[03:21] <bradb> no worries
[03:21] <cprov> mpt: sure, no worries 
[03:22] <mpt> bradb: ok, so any page belonging to Malone has the "Bugs" facet selected
[03:22] <mpt> that includes /malone/anything
[03:23] <mpt> and /people/anyone/+bugs
[03:23] <mpt> and /people/anyone/+assignedbugs
[03:23] <mpt> and /anything/+filebug
[03:24] <mpt> ok?
[03:24] <bradb> yes
[03:24] <mpt> Then most of those pages have the Malone app tabs
[03:24] <mpt> probably the /people/something pages don't, because it doesn't make much sense to report a bug about a person
[03:24] <mpt> but all the software ones do
[03:25] <mpt> and the /malone ones do
[03:25] <mpt> and the app menus are: "<context> Bugs", "Report a Bug", "Show Reports", "Admin"
[03:26] <mpt> "<context> Bugs" is the selected tab for any page whose URL ends in +bugs
[03:26] <mpt> "Report a Bug" is any page whose URL contains +filebug
[03:26] <mpt> "Show Reports" is selected when you're displaying a search or a bug report
[03:27] <mpt> and "Admin" is ... erm ... does Malone have any admin functions?
[03:28] <bradb> sorry, was on phone again
[03:29] <bradb> so, "Show Reports" highlighted for advanced search too?
[03:29] <mpt> yep
[03:29] <bradb> Malone has no Admin functions presently
[03:29] <mpt> ok, so we don't need that tab then
[03:29] <mpt> good
[03:29] <bradb> ok
[03:30] <bradb> presumably i can hunt through the code to find some examples of how this stuff is used
[03:30] <cprov> mpt: can we move to soyuz ?
[03:30] <bradb> and, with the menu structure you've just given me, i should be able to take care of the rest
[03:30] <mpt> bradb: I did an example for /products/foo, and daf has examples for Rosetta (I'm not sure what state they are at the moment)
[03:30] <mpt> cprov: sure
[03:31] <bradb> mpt: sounds good, thanks.
[03:31] <mpt> cprov: So give me some example Soyuz URLs
[03:31] <mpt> because to be perfectly honest, I'm a bit fuzzy on what is Soyuz and what isn't
[03:32] <cprov> mpt: /distros/
[03:32] <mpt> (that's not a good way to make you feel loved, is it0
[03:32] <mpt> )
[03:32] <cprov> mpt: /distros/ubuntu
[03:32] <mpt> ok...
[03:32] <mpt> cprov: you have it easy, then
[03:33] <cprov> mpt: no, definitively I don't feel loved at all  
[03:33] <mpt> aww
[03:33] <mpt> cprov: So all you need to do for the moment, I think, is make sure the facet menus are working properly in the /distros pages
[03:34] <cprov> mpt: wait they were easy ones ... what about distros/ubuntu/hoary/i386/firefox 
[03:35] <mpt> You have the same facets as everyone else: Overview, Bugs, Translations, Bounties (eventually), Calendar
[03:35] <mpt> For /distros, /distros/ubuntu, and /distros/ubuntu/hoary/i386/firefox, "Overview" is selected
[03:35] <cprov> mpt: sure, I don't think we will have a Soyuz facet soon ... since soyuz has most read-only package browsing feature
[03:35] <mpt> and that already works in production
[03:36] <mpt> except /distros says "Launchpad" instead of "Overview", a slight bug
[03:36] <mpt> so the main job is making sure the other facets go off to the right place
[03:37] <mpt> ok, already working for /distros/ubuntu and /distros/ubuntu/hoary ...
[03:37] <cprov> mpt: yes, just one detail, /distros/ubuntu/i386 has 3 left-portles (distro, release, arch.. details) isn't it too much ?
[03:37] <mpt> already working for /distros
[03:38] <mpt>  /distros/ubuntu/i386 gives me a system error
[03:38] <bradb> * Applying 200 revisions .....................................................*falls asleep on desk*..........
[03:38] <mpt> KeyError: u'i386'
[03:38] <cprov> mpt: production wasn't rolled yet ... solved on RF 
[03:38] <lifeless> bradb: you should not ever see a 200 rev patch queue, 50 should be the maximum you see
[03:39] <cprov> mpt: debonzi did it friday
[03:39] <bradb> lifeless: http://rafb.net/paste/results/nh3isr25.html
[03:39] <mpt> cprov: This is rocketfuel as of a few hours ago
[03:40] <cprov> mpt: briefly the task for soyuz is : ensure factes are working for distros/release, distros/release/arch and so on 
[03:40] <mpt>  /distros/ubuntu/hoary/i386 works though
[03:40] <bradb> lifeless: version 1.5~200507091049
[03:40] <mpt> cprov: yup
[03:40] <debonzi> mpt,  /distros/ubuntu/i386 is wrong
[03:40] <cprov> mpt: really ? I've just got a merge and it's working .. I'll investigate 
[03:41] <mpt> debonzi: I realize that now, but it should be giving me a 404, not a system error :-)
[03:41] <lifeless> jamesh: so is that faster ?
[03:43] <cprov> mpt: yep ...is that all for soyuz ? I'd expect as result more informative (and rich) pages ...
[03:44] <mpt> cprov: It's only navigation. It's not supposed to be exciting. :-)
[03:44] <bradb> mpt: does this mean that the actions portlet is here to stay? i haven't yet heard any mention of content-level tabs/menu options
[03:46] <lifeless> bradb: hmm, mirroring is bnorked
[03:46] <bradb> lifeless: just mine?
[03:46] <lifeless> no
[03:47] <bradb> oh, ok
[03:47] <carlos> Kinnison, it worked with --star-merge, thanks for the suggestion
[03:48] <lifeless> bradb: semi-fixed
[03:48] <lifeless> bradb: dunno why its broken, but I've mirrored the cacherev
[03:48] <bradb> lifeless: would it help me for me to restart the branch operation?
[03:48] <mpt> bradb: No, you'll find that the applicaiton menu removes the need for some of the tabs in the actions portlet
[03:48] <lifeless> bradb: where is it up to ?
[03:49] <bradb> lifeless: i restarted it (completely blew away my revlib except =greedy and =sparse, but same problem)
[03:49] <Kinnison> carlos: no problem
[03:49] <lifeless> bradb: do you have a local mirror ?
[03:49] <mpt> bradb: actually, that's not true for Malone, now I look
[03:49] <lifeless> bradb: blowing away your revlib is generally a bad idea, it hurts performance.
[03:49] <bradb> mpt: it removes exactly one Malone action portlet item. there are still half a dozen others, at least (and more on the way)
[03:50] <bradb> lifeless: i do it so that i don't run out of space on my home partition
[03:50] <lifeless> bradb: ah
[03:50] <mpt> bradb: LaunchpadMenus wasn't intended as a "Death to the actions portlet!" effort, it was intended as consistent navigation
[03:50] <cprov> mpt: yes, I see .. thanks for the help
[03:50] <mpt> cprov: no problem
[03:51] <mpt> bradb: I'd rather that actions were next to the thing they're acting on
[03:51] <mpt> bradb: For example, "Subscribe"/"Add Subscribers" is at the bottom of the list of subscribers, where it belongs, so putting it in the actions portlet too is duplication
[03:51] <bradb> fair enough. the good news is that, in my observations, users seem to quickly get used to the idea of the portlet in the top right-hand corner being the place they look when they want to do stuff.
[03:52] <bradb> (of course, we're really cheating them when they find out that's *not* where you look if you want to fix or assign a task)
[03:52] <mpt> bradb: Similarly, "+ Link to other bug tracker" is at the bottom of the list of bug trackers, so having it in the actions portlet as well is duplication.
[03:54] <mpt> and "Activity Log" isn't an action, so it shouldn't be in the portlet at all.
[03:54] <bradb> mpt: "the list of bug trackers" where?
[03:54] <mpt> the list of bug trackers is underneath the actions portlet
[03:55] <bradb> only when there's an external bugwatch already added, right?
[03:55] <mpt> ah
[03:55] <mpt> well, duplicate links is still wrong
[03:55] <mpt> So, make the portlet exist all the time
[03:55] <mpt> containing only the "Add watch" link if there are no watches yet
[03:56] <bradb> 6 empty portlets existing all the time?
[03:56] <mpt> 6?
[03:56] <bradb> maybe even 7
[03:56] <mpt> bug trackers, Web links (which should die), and CVE refs. That's 3.
[03:56] <mpt> What are the other 3~4?
[03:57] <bradb> infestations, activity log (where else would we put that link?), web link (because we still have it), mark as duplicate.
[03:57] <bradb> (infestation is currently divided into upstream and package...possibly merge eventually)
[03:58] <mpt> I saw them yesterday...
[03:59] <mpt> I don't think duplicates belong in a portlet at all
[03:59] <mpt> that would turn into a skyscraper at b.m.o scales
[03:59] <bradb> i had removed them in a branch somewhere, but lost track of it (too many branches these days, without the ability to ask "which branches do i have that have patches missing from rocketfuel?" makes life difficult)
[03:59] <mpt> I keep a list of my current branches in a text fiel
[03:59] <mpt> file, even
[03:59] <bradb> mpt: easy enough to condense it
[04:00] <bradb> lifeless: branch was much quicker now, thanks
[04:04] <mpt> bradb: Well, pull out the links that are *already* duplicated
[04:04] <mpt> that would at least make the remaining items quicker to scan.
[04:05] <bradb> sure
[04:22] <bradb> mpt: btw, is changing the sidebar into a portlet on the bug listing page something you can do fairly quickly?
[04:22] <bradb> (i had opened a bug on that and given it to you; not sure if you noticed)
[04:23] <sabdfl> stuhey bradb
[04:23] <sabdfl> erk
[04:23] <sabdfl> hey bradb
[04:23] <mpt> bradb: yes, I saw, I'm just keeping in mind the number of people pestering me to make the table take up the *entire* page width
[04:23] <bradb> hey sabdfl :)
[04:23] <sabdfl> stub's retired?
[04:23] <bradb> mpt: indeed, indeed
[04:24] <mpt> anyway, it's way past my bedtime
[04:24] <sabdfl> mpt: i have a branch for you!
[04:24] <mpt> ooh, a branch
[04:24] <mpt> delicious
[04:24] <sabdfl> your inner koala?
[04:24] <mpt> perhaps
[04:24] <sabdfl> this one will make you drop
[04:25] <sabdfl> it's a guuuuurd thing
[04:25] <sabdfl> mark.shuttleworth@canonical.com/launchpad--ui-cleanup--0
[04:26] <mpt> ok, I'm switching now, I'll look at it first thing tomorrow
[04:26] <mpt> thanks sabdfl
[04:26] <sabdfl> lots of foaf stuff there for you and salgado
[04:26] <sabdfl> mpt: thank you too!
[04:26] <sabdfl> sleep tight
[04:26] <sabdfl> bradb: do you know how to check what branch is headed to production tomorrow?
[04:27] <sabdfl> my branch last merged rocketfuel at Fri Jul  8 09:06:58 BST 2005
[04:27] <sabdfl> and i'm kinda hoping to get it reviewed and landed on production directly, if stub tagged off from RF after the above date
[04:27] <bradb> sabdfl: not sure. wasn't our cutoff date thursday morning meeting?
[04:27] <sabdfl> because it has lots of nice cleanup
[04:28] <bradb> maybe SteveA could confirm
[04:28] <sabdfl> stub hadn't tagged off thursday evening, i don't know if he did it during the day on friday
[04:28] <sabdfl> mpt: do a baz update first thing in the morning, there may be extra pressies
[04:29] <sabdfl> carlos: i've put a person-translations.pt in there
[04:29] <SteveA> bradb: i do not know exactly what is going into production in this rollout
[04:29] <sabdfl> carlos: btw, people seem to really like the look of rosetta
[04:29] <carlos> sabdfl, cool, thanks
[04:30] <carlos> yeah, althougt we have some missing bits
[04:30] <carlos> sabdfl, did you implemented suggestions for textareas?
[04:30] <carlos> we got a bug about that and I want to look into it this week if the feature is not yet implemented
[04:30] <carlos> because it's confusing for non editor translations
[04:31] <sabdfl> carlos: no, i think we should only have those on a /pomsgmset/+translate page, with some fancy JS to make the page size manageable
[04:31] <sabdfl> in brazil i want to spec out a detailed page just on a single msgset
[04:32] <carlos> sabdfl, then, we should not allow non editors to submit translations into textareas because they will be lost in our db as the ui will not show them
[04:33] <sabdfl> carlos: good point
[04:33] <sabdfl> we could show (n additional suggestions, latest from Foo Bar)
[04:33] <sabdfl> as a piece of text
[04:33] <sabdfl> so they see their name and see the number go up
[04:33] <sabdfl> with a [view]  link
[04:33] <sabdfl> to ../pomsgset/+suggestions
[04:33] <sabdfl> should be easy enough
[04:34] <sabdfl> we also need to show WHO provided the current active translation
[04:34] <sabdfl> there's lots of good stuff to be done
[04:34] <carlos> yeah
[04:37] <carlos> sabdfl, what do you prefer?, lock the textarea translations until the pomsgset URL appears or show only latest suggestion if it's a textarea entry?
[04:38] <sabdfl> carlos: show "n additional suggestions, latest by Foo Bar", as link to a page which lists them all, at /path/to/pofile/potmsgsetseq/+suggestions
[04:38] <carlos> I thought you wanted to spec that at Brazil
[04:39] <sabdfl> carlos:  happy for you to do a qnd implementation before then, or just leave that bug for 1.0
[04:40] <sabdfl> carlos: did the 1.0 pre-announcement go out?
[04:40] <carlos> not yet, I pinged daf about the status of the annoucement this morning
[04:45] <bradb> mpt: what do overview and translations link to when view the bug page?
[04:45] <bradb> s/view/viewing/
[05:24] <SteveA> carlos: i think the staging server should send all email to a single address
[05:24] <SteveA> where it can be read from one of the pop3 mailboxes at the DC
[05:24] <SteveA> an extra header in the email can give the address it was meant to be sent to
[05:59] <mpt> bradb: Bug pages don't have any context, so Overview goes straight up to /, and Translations to /rosetta
[05:59] <bradb> mpt: ok, that's what i expected, thanks
[06:03] <rob^> hi. what keyserver does Lauchpad use to import gpg keys?
[06:07] <SteveA> keyserver.ubuntu.com
[06:07] <SteveA> it's on the main rotation of keyservers
[06:07] <rob^> thanks
[06:09] <rob^> hi again, one more question.
[06:10] <rob^> I'm getting this when trying to add my key to the GPG Key Management: Key was claimed, sending email to :.At least one UID should be validated to get the key imported as yours.
[06:10] <rob^> I've sent my key to keyserver.ubuntu.com
[06:11] <rob^> how can I fix this?
[06:11] <SteveA> have you already told launchpad about the email addresses on your gpg key?
[06:11] <rob^> yes
[06:12] <SteveA> cprov: around?
[06:12] <SteveA> cprov may be able to help you
[06:12] <rob^> ah ok
[06:13] <SteveA> otherwise, please file a bug on launchpad in launchpad
[06:13] <rob^> ok
[06:17] <SteveA> cprov went to lunch a little while ago.  he'll be back in a while.
[06:21] <rob^> I'm gonna hit the sack, might catch him later. Thanks for your help though
[06:23] <sabdfl> hey SteveA!
[06:23] <SteveA> hiya
[06:23] <sabdfl> is it as hot in lithuania?
[06:23] <SteveA> yes
[06:23] <SteveA> probably
[06:23] <SteveA> still... winter in brazil soon
[06:24] <sabdfl> SteveA: silicon works best when cooled ;-)
[06:30] <SteveA> so does beer
[06:32] <mgalvin> cprov, i'm also having the prob rob^ is having, any pointers would be great
[06:34] <carlos> SteveA, that's a really good idea
[06:38] <carlos> SteveA, did you tell that to stub?
[06:40] <sabdfl> carlos: are the breezy imports working now?
[06:40] <sabdfl> did we fix those import/transaction issues?
[06:41] <carlos> not yet
[06:41] <carlos> the imports work
[06:41] <carlos> but the transaction is not done
[06:41] <carlos> I fixed most of the .pot issues
[06:42] <carlos> and schooltool, gourmet and others are now fixed
[06:42] <sabdfl> fixing transactions in scripts should be easy
[06:42] <carlos> sabdfl, I'm fixing other things at the same time
[06:42] <sabdfl> just know when to ztm.commit() and ztm.begin()
[06:42] <sabdfl> ok
[06:42] <carlos> I wrote a spec about it
[06:43] <carlos> https://wiki.launchpad.canonical.com/LaunchpadPoImportFeedback
[06:43] <carlos> it's a bit difficult to read current output and our users are not getting enough feedback
[06:52] <sabdfl> carlos: my main priority for production tomorrow is to be able to show people the new distrorelease-translation-status pages
[06:53] <SteveA>  /scratch/dists/launchpad/lib/canonical/launchpad/components/poparser.py:315: POSyntaxWarning: PO file header entry has no content-type field
[06:53] <SteveA>   warnings.warn(POSyntaxWarning(msg='PO file header entry has no content-type field'))
[06:53] <SteveA> carlos: is this warning important or something we should fix code to stop?
[06:54] <cprov> SteveA: here
[06:54] <SteveA> hi cprov 
[06:54] <SteveA> some people were having trouble getting their gpg keys into launchpad
[06:55] <cprov> SteveA: yep, rob^ still arround? 
[06:55] <SteveA> it was rob^ and mgalvin 
[06:55] <mgalvin> i am here cprov
[06:55] <cprov> SteveA: I'm confident it will be solved in next production rollout ..
[06:56] <cprov> SteveA: the error was cause by the previous workflow weakness, all GPG uids were already validated in LP ..
[06:58] <cprov> mgalvin: hope the comment above fits in your case too, or not ? be patient and thank you for your feedback 
[07:01] <cprov> SteveA:  I agree with you about the need of being able to handle emails sent from Staging, otherwise all token-related features are compromised 
[07:02] <SteveA> i want us to build a full end-to-end test of bug email
[07:02] <SteveA> for running on staging
[07:02] <SteveA> anyway, --> exercise.  back later.
[07:03] <cprov> SteveA: ok, see u later
[07:03] <mgalvin> cprov, it does, thnx, i'll try again when you guys rollout the next release
[07:04] <carlos> SteveA, no, that warning is that we detected a value that is missing and it should be there
[07:05] <cprov> mgalvin: thank you, keep playing with other LP features, there still having a lot of fun apart of GPG ;)
[07:05] <carlos> sabdfl, breezy's .pot files are importe already, the part that is missing is the .po imports but it should be done between today and tomorrow
[07:06] <carlos> in about 10 minutes I will get an email that will tell me current status
[07:06] <carlos> with the number of .po files pending to be imported
[07:37] <kiko> hello hackers
[07:37] <kiko> 630 unread
[07:37] <kiko> isn't life fun
[08:48] <carlos> SteveA, lib/canonical/launchpad/scripts/rosetta.py starts growing a lot like helpers.py did, could we move it into rosetta/$script.py ?
[09:05] <kiko> heh
[09:06] <dilys> New Malone bug 1375 filed on product FOAF by Brad Bollenbach: IRC nick details don't appear to persist
[09:06] <dilys> https://launchpad.ubuntu.com/malone/bugs/1375
[09:28] <SteveA> carlos: ping
[09:28] <SteveA> kiko-afk: afk?  slacker! ;-)
[09:28] <carlos> SteveA, pong
[09:28] <SteveA> hi carlos
[09:28] <carlos> hi
[09:28] <SteveA> so, first of all, about that warning
[09:28] <SteveA> let me understand this properly
[09:29] <SteveA> so, is the test supposed to produce that warning?
[09:29] <carlos> no, we are not testing that warning
[09:30] <carlos> I suppose the sample data we use for the test produces it so it could be easily removed
[09:30] <carlos> fixing sample data
[09:30] <carlos> I fixed already a couple of related warnings, but I suppose I miss that one
[09:31] <SteveA> what do you expect to do with such warnings in production?
[09:32] <carlos> well, we can remove them if you want, it's part of our crapy po parser that I hope we substitute soon
[09:32] <carlos> they were errors sometime ago, and I moved them to warnings because real data is not so "perfect"
[09:32] <SteveA> so, is the message "here's something legitimate that the parser can't handle" ?
[09:33] <carlos> and of course is not a big issue if we don't have that information
[09:33] <SteveA> here's the story
[09:33] <carlos> no, it's just a "this po file is not perfect"
[09:33] <SteveA> i've spent some time today sorting out the warnings and other things that launchpad produces when you run the test suite
[09:33] <SteveA> the principle i'm using is, everything that is warned about should be able to be fixed
[09:33] <SteveA> and the test suite's output should tell you the information you need to fix it
[09:34] <SteveA> Keybuk: ping
[09:34] <carlos> under that point of view, those warning should be removed as it depends on the real world data we get
[09:35] <SteveA> well, another use of warnings is what should really be log messages
[09:35] <SteveA> that is, we log things in production
[09:35] <SteveA> then scan the log files for things we should do somethig about
[09:35] <SteveA> which might be looking for edge cases to improve parsers
[09:35] <SteveA> or to fix up data manually, or inform people of buggy third party software
[09:35] <SteveA> that kind of thing
[09:36] <SteveA> so, maybe you should change the warning to a log message?
[09:37] <carlos> hmm, I think I should be able now that we are using python2.4 so we don't need the logger object sent as an argument
[09:37] <carlos> and thus, I don't need to change the parser api
[09:37] <SteveA> okay, let's do that
[09:37] <SteveA> then i don't need to worry about that warning
[09:38] <kiko-afk> SteveA, yo!
[09:38] <kiko> laundry
[09:38] <carlos> ok
[09:40] <SteveA> kiko: i'm about to put on "A gesture of kindness" by The Karl Hendricks Trio.  Tom Hoffman, project manager of schooltool was the drummer.  They sound to me like husker du.
[09:42] <SteveA> ddaa: do you know much about the hct backend ?
[09:44] <ddaa> Not really.
[09:44] <ddaa> HCT is Keybuk's realm,
[09:44] <kiko> SteveA, alan moulder was a wizard
[09:44] <carlos> SteveA, did you see my comment about lib/canonical/launchpad/scripts/rosetta.py?
[09:44] <SteveA> carlos: maybe
[09:44] <SteveA> please repeat it
[09:45] <carlos> carlos SteveA, lib/canonical/launchpad/scripts/rosetta.py starts growing a lot like helpers.py did, could we move it into rosetta/$script.py ?
[09:45] <ddaa> SteveA: I sort of recall there was talking about a xml-rpc backend for use in clients, and a postgres backend for use at the DC.
[09:45] <carlos> daf did it already for new scripts but putting them inside scripts/$script.py directly
[09:45] <SteveA> well... it isn't quite like helpers.py, in that it is all focused on rosetta scripts
[09:45] <SteveA> not just on anything
[09:46] <carlos> SteveA, right, but unrelated scripts
[09:46] <SteveA> i think keeping things flatter and putting them inside /scripts/ is better
[09:46] <carlos> we are not sharing any code between scripts there
[09:46] <SteveA> just make sure the module name is clear
[09:46] <ddaa> SteveA: maybe if you asked a more pointed question, I could be more specific on my level of uselessness in answering it :)
[09:46] <carlos> ok
[09:46] <SteveA> i'd prefer /scripts/....py than /scripts/rosetta/...py
[09:46] <carlos> will do it that way
[09:46] <SteveA> great
[09:46] <carlos> thank you
[09:47] <kiko> ddaa, ping?
[09:47] <SteveA> ddaa: in my work on cleaning up the test suite output, i discovered that the launchpad hct back-end is producing a bunch of fixable warnings
[09:47] <SteveA> i want to fix them, but want to bounce it off someone who knows the code
[09:47] <ddaa> kiko: did I make any impression of being away right now? :)
[09:47] <kiko> ddaa, can you msg me your passport number and country of emission?
[09:47] <kiko> no!
[09:49] <ddaa> SteveA: AFAIK the only person that knows the code is Keybuk. He was a bit protective previously (my baby hct), so you probably want to use either soft gloves or or a big hammer when communicating about it.
[09:50] <ddaa> kikotours: ok
[09:50] <SteveA> i'm sure Keybuk will be fine with my changes.
[09:51] <ddaa> big hammer way "here are some patches, kthxbye" is also my favourite :)
[09:54] <SteveA> kiko: alan moulder?  bob mould?
[09:55] <kiko> wow, you just cleared up a decades-long confusion
[09:59] <kiko> BjornT?
[10:03] <kiko> daf?
[10:03] <SteveA> daf is @ debconf
[10:03] <carlos> see you later
[10:04] <BjornT> hi kiko 
[10:04] <kiko> aha
[10:04] <kiko> BjornT, can you msg me your passport number and country of emission?
[10:04] <kiko> or read your email :-)
[10:04] <SteveA> what does "country of emission" mean?
[10:05] <carlos> SteveA, I suppose it's the country that gave you it
[10:05] <carlos> SteveA, for instance, bradb has two of them
[10:05] <SteveA> or the country you're leaving to come to brazil?
[10:06] <carlos> SteveA, my english is not too good, but I don't think kiko means from where are we "emitted" :-P
[10:06] <kiko> the country your passport was emitted.
[10:07] <kiko> sorry for the implied context
[10:07] <SteveA> i think it is "country of issue" or "issuing country" on my passport
[10:07] <SteveA> kiko: do you need my details?
[10:07] <kiko> right
[10:07] <kiko> SteveA, nope.
[10:24] <SteveA> salgado: ping
[10:26] <salgado> hi SteveA 
[10:26] <SteveA> hi salgado
[10:26] <SteveA> do you have time to do a bit of foaf clean-up ?
[10:26] <salgado> SteveA, sure. I'm into it right now
[10:26] <SteveA> okay, great
[10:27] <SteveA> so, i've been improving the way the tests run
[10:27] <SteveA> and sorting out warnings
[10:27] <SteveA> there are a bunch of foaf queries that are used for things like displaying batched results
[10:27] <SteveA> which should have an order by clause in them
[10:27] <SteveA> but which don'e
[10:28] <SteveA> 
[10:28] <bradb> anyone know how i give a page a title if the page is using default-editform.pt?
[10:28] <SteveA> The expression: (list(bn.currentBatch())) in people-list.pt
[10:28] <SteveA> The method PeopleListView.__call__
[10:28] <SteveA> request url: http://localhost:9000/people/+peoplelist
[10:28] <SteveA> The expression: (list(bn.currentBatch())) in people-index.pt
[10:28] <SteveA> The method FOAFSearchView.__call__
[10:28] <SteveA> request url: http://localhost:9000/people/+index
[10:28] <SteveA> The method PersonView.assignedBugsToShow
[10:28] <SteveA> request url: http://localhost:9000/people/sabdfl/+assignedbugs
[10:28] <SteveA> The method PersonView.__call__
[10:28] <SteveA> request url: http://localhost:9000/people/sabdfl/+assignedbugs
[10:28] <SteveA> The expression: (list(bn.currentBatch())) in people-list.pt
[10:28] <SteveA> The method TeamListView.__call__
[10:28] <SteveA> request url: http://localhost:9000/people/+teamlist
[10:31] <SteveA> bradb: there was a way to do that a while ago.  i just looked, and it's been removed,
[10:31] <SteveA> salgado:  that's some output from my warning helper
[10:31] <bradb> SteveA: do i have to create a boiler plate template to make this possible then?
[10:32] <SteveA> salgado: check out browser/person.py, getTeamsList, getPeopleList and getUbuntitesList
[10:32] <salgado> SteveA, I see.
[10:32] <SteveA> salgado: especially getUbuntitesList, where it says list(results).  that looks wrong to me
[10:32] <SteveA> should be shortlist, or more probably, no list at all
[10:32] <salgado> no list at all, I'd say
[10:33] <salgado> I'll talk to cprov to make sure that list() is not needed
[10:33] <SteveA> also
[10:33] <SteveA>  _findPeopleByName
[10:34] <SteveA> i see no reason for this to be just method
[10:34] <SteveA> be just one method
[10:34] <SteveA> it can be split into three methods
[10:34] <salgado> almost all methods of IPersonSet already accept an orderBy argument. I'll just have to fix the callsites
[10:34] <cprov> salgado: SteveA: I suspect you're right, list() isn't necessary 
[10:34] <SteveA> why can't there be a default ordering of 'id' ?
[10:35] <SteveA> kas.selectByCategoryAndPerson(actionCategory, self.context)
[10:35] <SteveA> also, that needs an order by
[10:35] <cprov> salgado: I'm repairing it in the current [trivial]  change you requested, ok ?
[10:35] <SteveA> assignedBugsToShow too
[10:35] <salgado> cprov, I can fix it. there's some other fixes I'll have to do
[10:36] <cprov> salgado: ok, won't touch 
[10:36] <salgado> SteveA, shouldn't the Person._defaultOrder be used if I don't specify orderBy=None?
[10:36] <salgado> if I specify orderBy=None
[10:36] <SteveA> bradb: is this urgent?
[10:36] <SteveA> salgado:  i don't know
[10:36] <bradb> SteveA: no
[10:37] <SteveA> bradb: okay, maybe file a bug on it for me?
[10:37] <bradb> will do, thanks
[10:38] <SteveA> salgado: i just sent my work off to be merged.  it will conflict with your fixes a little.  so you may want to merge from RF once my work gets merged.
[10:40] <salgado> SteveA, okay. thank you
[10:47] <salgado> SteveA, still here?
[11:06] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  improved warning output for tests, and fixed a bunch of ambiguous use of select results warnings. some xxx comments left in person code. one untested codepath in hct backend. (patch-2073: steve.alexander@canonical.com)
[11:08] <kiko> carlos?
[11:20] <carlos> kiko, ?
[11:20] <SteveA> salgado: hi
[11:25] <kiko> carlos, you know about the error we're getting when running the export queue?
[11:26] <carlos> kiko, the one related with .mo files?
[11:26] <kiko> right, when compiling a pofile.
[11:27] <salgado> SteveA, by looking at the error logs, I found that a common use case we have is people clicking on the top-right login link after consuming a logintoken (i.e. validating an email, resetting the password, etc)
[11:27] <carlos> kiko, yes, I hope tomorrow will have it fixed, it's a matter of data migration 
[11:27] <jbailey> bradb: mpt suggested that since I'm not likely to use malone much in the next little bit, I might be a better test subject if I didn't follow the usability discussions.  Chances are by the time the rework is done, I might be a useful testcase again.
[11:27] <kiko> carlos, ah, is it about the newlines issue?
[11:27] <SteveA> kiko: where does that go?
[11:27] <kiko> jbailey, sounds sane.
[11:27] <carlos> kiko, yes
[11:27] <kiko> SteveA, launchpad-error-reports.
[11:27] <kiko> carlos, thanks.
[11:28] <carlos> np
[11:28] <salgado> so, I'm adding a checkbox to all logintoken pages to allow people to be automatically logged in after validating something via logintoken. (only for the cases where they provided a password, of course)
[11:28] <SteveA> i meant salgado, and i meant, where does the link go
[11:28] <jbailey> bradb: Given that, if you have questions, can you extract them for me?  I happened to notice the Jeff: at the top of the message while I was dragging it to the archive folder. =)
[11:28] <kiko> salgado, a checkbox?
[11:28] <bradb> jbailey: indeed, don't worry about following the usability discussions, but it might be useful to us if you answer the questions that would help clarify exactly what confused you.
[11:29] <bradb> jbailey: sure, one sec
[11:29] <salgado> SteveA, the link points to the right place (/token/randomstring/+login), and people can login. but after that they got redirected to the logintoken page which doesn't exist anymore
[11:29] <salgado> that's how I found it's a common use case
[11:29] <bradb> jbailey: can i paste them to you in a msg?
[11:30] <jbailey> bradb: Yup! =)
[11:30] <salgado> kiko, yes. a checkbox. is there anything wrong?
[11:30] <SteveA> salgado: i see.  we could make +login go to the root login page in that case
[11:30] <kiko> salgado, sounds kinda weird. why ask the user? why not do the right thing automatically?
[11:31] <salgado> SteveA, that would be good, but I don't think it would be a problem after my changes
[11:32] <salgado> kiko, I was going to do that, but what if you're in someone else's computer and are just following the link to validate something but you don't want to do anything else on that computer? you could endup logged in without even noticing
[11:32] <SteveA> can you file a bug on me, saying that the +login link behaviour should change for those pages, and describe exactly what URLs those pages will have
[11:32] <salgado> that's why I choosed to use a checkbox (checked by default)
[11:32] <salgado> SteveA, sure. I'll do that
[11:33] <SteveA> thanks
[11:33] <salgado> SteveA, but anyway, what I wanted to ask you is something else.
[11:33] <kiko> salgado, hmmm. why not have him log himself out?
[11:33] <kiko> salgado, can you check with mpt? I'm sure he'll have an opinion
[11:33] <salgado> he could not even notice that he was logged in
[11:33] <salgado> sure. I'll talk to mpt.
[11:34] <salgado> SteveA, so, if I can log a person in while resetting his password, I would be able to remove that removeSecurityProxy() call. (remember it?)
[11:35] <SteveA> okay, that sounds reasonable.  you have credentials in the form of the token
[11:35] <bradb> SteveA: is putting bugs in launchpad a good way to get you to look at them fairly soonish? (when's the last time you marked a bug fixed in LP?)
[11:35] <SteveA> bradb: a couple of days ago
[11:35] <bradb> ok
[11:35] <SteveA> bradb: i use bugs
[11:36] <SteveA> salgado: but, don't ask me how to do it tonight :-)
[11:36] <salgado> SteveA, but that doesn't seem to work. even if I call the login method (which does login) and after that get a person using getUtility()
[11:38] <salgado> I expect that would take care of giving me an object where I would be able to change the password
[11:38] <sabdfl> carlos: re po imports, ok cool thanks
[11:39] <SteveA> salgado: logging in is a bit complex, when you want to log in during the rendering of a page.
[11:39] <carlos> sabdfl, I found a problem importing .po files related with some changes I did last week
[11:39] <carlos> sabdfl, will try to have a patch ready tonight 
[11:39] <carlos> sabdfl, it only affects .po imports .pot imports work
[11:39] <SteveA> salgado: can you make a branch, and point out the place you want to do a login, tell me the things i need to do to use it, and i'll make sure it works.
[11:39] <SteveA> salgado: send me an email about it
[11:40] <sabdfl> carlos: ok cool
[11:40] <salgado> SteveA, sure. I'll do it. thank you again. :)
[11:40] <carlos> sabdfl, about the transaction thing... we do the commit and the abort correctly so the only issue I can think on is when we call SQLObject.sync() I need to debug it a bit just in case it does the commit...
[11:40] <sabdfl> carlos:  i hope it doesn't!
[11:40] <carlos> me too
[11:41] <SteveA> salgado: i'd like you to look at those order-by issues soon.  they'll tidy up the test output a lot
[11:41] <carlos> but it's the only thing I can think on
[11:42] <salgado> SteveA, I'll look at them today. I'm just finishing these logintoken-related changes
[11:42] <SteveA> okay.  when you merge from rf, and run the tests, you'll see some output that tells you exactly where you need to look.
[11:43] <SteveA> also, update sqlobject and sqlos
[11:44] <SteveA> for a cleaner test-run experience
[11:45] <dilys> Merge to rocketfuel@canonical.com/sqlobject--test--0.6: [trivial]  add checks to obj.expire() to suppress attribute errors when it is used during transaction __del__ (patch-25: steve.alexander@canonical.com)
[11:48] <bradb> hello? pqm? what happened to my two merge requests? *taps mic* is this thing on?
[11:50] <bradb> a little bit earlier:
[11:50] <bradb>                              PQM Queue: 2 commands
[11:50] <bradb>     1. /home/pqm/arch/queue/patch.1121115010: bradb@bbnet.ca (Brad
[11:50] <bradb>        Bollenbach), '[trivial]  de-underline release bug portlet links',
[11:50] <bradb>        -----BEGIN PGP SIGNED MESSAGE-----
[11:50] <bradb>     2. /home/pqm/arch/queue/patch.1121115977: bradb@bbnet.ca (Brad
[11:50] <bradb>        Bollenbach), '[trivial]  small title fixes', -----BEGIN PGP SIGNED
[11:50] <bradb>        MESSAGE-----
[11:50] <bradb> and now:
[11:50] <bradb> bradb@oxygen:~/launchpad $ ssh chinstrap.warthogs.hbd.com lynx --dump http://localhost:8000/
[11:51] <bradb>                              PQM Queue: 0 commands
[11:52] <bradb> maybe it's got Intelligent Delay Technology for sending my failure messages or something? still nothing in my Inbox...
[11:52] <jbailey> bradb: Need me for anything else?
[11:52] <bradb> jbailey: nope, that clarifies things, thanks
[11:52] <jbailey> Cool.  /me sails off to the sunset.
[11:53] <lifeless> bradb: small title fixes failed - two failues
[11:53] <lifeless> messaging you