[12:06] New Malone bug 1358 filed on product Malone by Matthew Paul Thomas: Sort order should be indicated in Malone results [12:06] https://launchpad.ubuntu.com/malone/bugs/1358 [12:29] New Malone bug 1359 filed on product Malone by Matthew Paul Thomas: Don't display unmodified bug description as a comment [12:29] https://launchpad.ubuntu.com/malone/bugs/1359 === jbailey [~jbailey@modemcable134.23-201-24.mc.videotron.ca] has joined #launchpad [12:50] mpt: ping [12:50] jbailey: pong [12:51] 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] heh [12:51] um [12:52] 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] and not thinking about it [12:54] And I don't until main gets converted over. [12:54] I'll avoid reading Bjorn's message then. Feel free to poke me with things if you need. [12:55] FWIW, I can give you access to Canonical's RT system. === comadreja [~comadreja@comadreja.active.supporter.pdpc] has joined #launchpad [02:06] howdy all [02:06] I'm missing the version number in the bug reporting tool [02:06] I mean to be able to state the version of the package that is being reported as buggy === Burgundavia [~corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad === daf [daf@muse.19inch.net] has joined #launchpad === sivang [~sivang@box79162.elkhouse.de] has joined #launchpad === lamont [~lamont@mix.mmjgroup.com] has joined #launchpad === jblack [jblack@209.158.45.74] has joined #launchpad === superted [~superted@213.167.101.222] has joined #launchpad === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad === Burgundavia [~corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad === daf [daf@muse.19inch.net] has joined #launchpad === sivang [~sivang@box79162.elkhouse.de] has joined #launchpad === lamont [~lamont@mix.mmjgroup.com] has joined #launchpad === jblack [jblack@209.158.45.74] has joined #launchpad === superted [~superted@213.167.101.222] has joined #launchpad === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad === Burgundavia [~corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad === daf [daf@muse.19inch.net] has joined #launchpad === sivang [~sivang@box79162.elkhouse.de] has joined #launchpad === lamont [~lamont@mix.mmjgroup.com] has joined #launchpad === jblack [jblack@209.158.45.74] has joined #launchpad === superted [~superted@213.167.101.222] has joined #launchpad === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad === comadreja [~comadreja@80.224.108.186] has joined #launchpad === asgeirf [~asgeirf@203-206-229-169.dyn.iinet.net.au] has joined #launchpad === stub [~stub@203-217-37-199.dyn.iinet.net.au] has joined #launchpad [07:41] New Malone bug 1365 filed on product Malone by Matthew Paul Thomas: Priority should default to a null value [07:41] https://launchpad.ubuntu.com/malone/bugs/1365 [07:49] mpt: I added a few bug linkifying examples to https://wiki.launchpad.canonical.com/DisplayingParagraphsOfText [07:51] jamesh: ah, I wasn't expecting bug links to be part of the same algorithm [07:51] but to be Malone-specific [07:51] mpt: I think it needs to be done in one pass [07:51] mpt: considering "http://example.com/bug#123" vs. "bug#123" [07:51] one being a URL, the other being a bug link [07:51] 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] Same for KDE and Mozilla and most other upstreams. [07:52] 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] mpt: feel free to modify the examples as you see fit. [07:54] They all look reasonable to me, jamesh [07:54] Perhaps we just need a flag saying "do bug linkifying as well" [07:54] that can be on for Malone use, and off everywhere else [07:54] thanks for the examples. [07:59] heh, Breezy has *2* bugs in Malone [08:08] 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] yes [08:09] ApplicationMenu [08:09] cool. I'll look at doing that [08:09] thanks [08:23] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Index required by Gina (patch-2071: stuart.bishop@canonical.com) === superted [~superted@213.167.101.222] has joined #launchpad === jblack [jblack@static-209-158-45-74.scr.east.verizon.net] has joined #launchpad === daf [daf@muse.19inch.net] has joined #launchpad === ChanServ [ChanServ@services.] has joined #launchpad === lifeless [~robertc@dsl-211.17.240.220.rns02-kent-syd.dsl.comindico.com.au] has joined #launchpad === BjornT [10183@82-135-221-189.ip.takas.lt] has joined #launchpad === Burgundavia [~corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad === lamont [~lamont@mix.mmjgroup.com] has joined #launchpad === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad === superted [~superted@213.167.101.222] has joined #launchpad === jblack [jblack@209.158.45.74] has joined #launchpad === sivang [~sivang@box79162.elkhouse.de] has joined #launchpad === Keybuk_ [~scott@amnesiac.heapspace.net] has joined #launchpad === sivang_ [~sivang@box79162.elkhouse.de] has joined #launchpad === mpt [~mpt@203-167-186-120.dsl.clear.net.nz] has joined #launchpad === JanC [~janc@JanC.member.lugwv] has joined #launchpad === jblack_ [jblack@static-209-158-45-74.scr.east.verizon.net] has joined #launchpad === Nafallo [nafallo@c-459571d5.07-44-73746f50.cust.bredbandsbolaget.se] has joined #launchpad === bob2 [~rob@crumbs.ertius.org] has joined #launchpad === comadreja [~comadreja@comadreja.active.supporter.pdpc] has joined #launchpad === jordi [~jordi@115.Red-213-96-69.pooles.rima-tde.net] has joined #launchpad === SteveA [~steve@adsl-213-190-44-43.takas.lt] has joined #launchpad === zyga [~zyga@2-mi2-1.acn.waw.pl] has joined #launchpad === bradb-afk [~bradb@modemcable082.64-130-66.mc.videotron.ca] has joined #launchpad === dand [~dand@83.103.205.136] has joined #launchpad === morgs|away [~morgan@wblv-146-236-76.telkomadsl.co.za] has joined #launchpad === asmodai [~asmodai@sakko.demon.nl] has joined #launchpad === jamesh [~james@203-59-251-126.dyn.iinet.net.au] has joined #launchpad === superted_ [~superted@213.167.101.222] has joined #launchpad === asmodai_ [~asmodai@sakko.demon.nl] has joined #Launchpad === kiko-afk [~kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === Keybuk [~scott@amnesiac.heapspace.net] has joined #launchpad === stub [~stub@203-217-37-199.dyn.iinet.net.au] has joined #launchpad === jblack [jblack@static-209-158-45-74.scr.east.verizon.net] has joined #launchpad === sivang [~sivang@box79162.elkhouse.de] has joined #launchpad === asmodai_ is now known as asmodai === Nafallo [nafallo@c-459571d5.07-44-73746f50.cust.bredbandsbolaget.se] has joined #launchpad === daf [daf@muse.19inch.net] has joined #launchpad === lifeless [~robertc@dsl-211.17.240.220.rns02-kent-syd.dsl.comindico.com.au] has joined #launchpad === SteveA [~steve@adsl-213-190-44-43.takas.lt] has joined #launchpad === comadreja [~comadreja@comadreja.active.supporter.pdpc] has joined #launchpad === BjornT [10183@82-135-221-189.ip.takas.lt] has joined #launchpad === Burgundavia [~corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad === JanC [~janc@JanC.member.lugwv] has joined #launchpad === lamont [~lamont@mix.mmjgroup.com] has joined #launchpad === mpt [~mpt@203.167.186.120] has joined #launchpad === Burgundavia [~corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad === BjornT_ [10183@82-135-221-189.ip.takas.lt] has joined #launchpad === jordi [~jordi@115.Red-213-96-69.pooles.rima-tde.net] has joined #launchpad === elmo [~james@a130-233-4-133.debconf5.hut.fi] has joined #launchpad === dilys [daf@muse.19inch.net] has joined #launchpad [09:54] mpt: hi. launchpad--decruftify-b--1 has conflicts. if you resolve them, I'll review it today. [09:55] ok, thanks BjornT === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad [09:55] morning [10:01] morning carlos [10:10] stub, could you kill all poimport scripts? [10:10] 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] carlos: Done [10:15] stub, thank you === carlos -> breakfast [10:16] carlos: can we cron the kill ? [10:18] 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] stub: This is besides patch 2050 which fixes the lack of links to product releases from the product and product series pages... [10:19] morgs: I couldn't cherry pick that patch (2050). Neither sounds critical enough to rollout today instead of tomorrow. [10:20] stub: I'd just like these things to go live before next Tuesday... What patch is going up to production? [10:20] morgs: Don't know yet, but I'll make sure those two go in. [10:21] stub: thanks, that's fine. Just wanted to make sure it wasn't the exact patch as of the Thursday meeting... [10:21] pqm issues made that problematic [10:25] 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] jamesh: so did you do the equivalent of get ...366, diff rocketfuel ? [10:26] It seems like months since a rollout [10:26] DeprecationWarning) [10:27] /scratch/dists/launchpad/lib/canonical/launchpad/database/product.py:222: DeprecationWarning: Product.potemplates is obsolete, should be on ProductRelease [10:27] DeprecationWarning) [10:27] 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] morgs: can you fix that? [10:27] lifeless: i.e. diff "rocketfuel with the old rev merged" and "rocketfuel with the new rev merged" [10:28] SteveA: I'll take a look... [10:28] jamesh: uhm [10:29] jamesh: yes, that should give reasonable results, modulo merges from third party branches [10:30] lifeless: is there a better way to perform that operation then? [10:30] in which case, yes you picked bad patches. [10:30] as the only patches that needed reviewing as new were 364,365,366 [10:31] I don't really mind -code quality is code quality - but it was surprising :[ [10:32] 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] the difference between those two trees should be the changes on your branch minus rocketfuel merges, right? [10:33] it would only have third party merges if they were in your branch, I think [10:33] lets unmultiplex this [10:34] I was complaining cause you reviewed 350-366, when you'd already done 350-363, and got different review feedback [10:34] okay. I picked the wrong revisions. [10:35] actually, you' [10:36] d probably done 350-362 or something, as there was a rf merge or so in there. [10:36] but anyhoo. [10:36] I'm not stressed - but it was surprising and somewhat confusing. [10:36] I'm acting on the review now. [10:37] with regards the baz gymnastics ... [10:37] 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] but that assumes a clean triangle. [10:38] if for example I imported a branch from ddaa which was being separately reviewed, you'd see that in the diff [10:38] yes [10:39] thats what I meant by third party branch. [10:40] that happened when I was reviewing Mark's debbugs branch (which included some stuff he'd passed off to Scott) [10:40] interestingly, we could import the code into a weave and generate a synthetic my-branch-only list of changes. [10:40] but thats Future. [10:40] of course, it does tell me what would be going into rocketfuel if the branch was merged [10:40] which is one of the things I want to know when reviewing something [10:41] right [10:41] theres a balance there. [10:42] w.r.t. performance, it might be faster to do delta rf<->rf, delta branch<->branch, and interdiff [10:42] then you'd have no merges at alll [10:43] baz delta --diffs first second > branch-to-merge.diff would also shave a second or two off [10:44] I didn't notice that function. [10:45] oh [10:45] you can cp -al first second [10:45] that will be much faster [10:46] try this [10:46] baz get rocketfuel@canonical.com/launchpad--devel--0 first [10:46] baz merge -d first --star-merge branch-to-merge--patch-XXX [10:46] woohoo, botched invariant again [10:46] cp -al first second [10:47] baz merge -d second --star-merge branch-to-merge [10:47] baz delta --diffs first second > branch-to-merge.diff [10:48] so that'll give the minimum number of files with different inode numbers between the two trees? [10:48] and speed up the diff [10:48] -al makes a hardlink of the two [10:48] yeah [10:48] the diff won't be optimised at all with changeset [10:48] 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] it will optimise === terrex [~terrex@84-122-69-8.onocable.ono.com] has joined #launchpad [10:51] oh, with -al it will skip diffing all the linked-but-not-mutated files [10:51] so it should be quite a lot faster really. [10:51] give it a try ;0 [10:51] :89 [10:51] that's what I was getting at [10:52] yah. === lifeless zombies [10:52] doing the copy after the first merge would reduce the amount of comparisons over doing the copy before either merge [10:52] right, that was one of the reasons I suggested that. It also reduces the size of the merge to do [10:52] and gives a pristine tree of the relevant revision to use as the merge bases [10:53] this if block : [10:53] return (len(lines) < 4 [10:53] or not lines[2] .startswith('---') [10:53] or not lines[3] .startswith('+++')) [10:53] when I write it with a not, it becomes less clear to me [10:54] can you articulate why you think its more readable inversed ? [10:54] 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] so you want o return the opposite of that [10:55] so I see it as 'an invalid diff has less than 4 lines, or does not have a 3rd line beginning with '---' .... [10:56] 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] w [10:56] feel free to leave it as is then. [10:56] k === morgs gets a botched invariant too [10:56] --star-merge worked though [10:57] 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] use --star-merge, I think there is something buggered in HEAD right now === morgs reaches for the --star-merges === carlos -> out [10:57] 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] 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] SteveA: right. the thing I don't like about inverting the if block in-line is that it becomes a double negatic [10:58] better to invert, remove the not, invert the function name instead. [10:58] 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] yes [10:59] your wording fits better with me if i remove my python hat and put on a functional hat [11:00] mmm [11:00] I think isNullPatch (asis), or isValidPatch (inverted with leading not removed) are equivalent. [11:01] isNullPatch (inverted) feels wrong and ugly. === SteveA proceeds to remove most of the warnings from when you run the launchpad test suite [11:07] 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] Application error. Unauthenticated user POSTing to page that requires authentication. [11:07] SteveA: should we present a login page ^^ then, and when logged in, re-POST the contents? [11:07] lifeless: sure. which revs should I be looking at? :) [11:07] Kinnison: yes, that bug's reported [11:08] mpt: okay thanks === Kinnison growls and hopes that if he presses "back" his long and complex bug comment will be retained [11:08] jamesh: well, reviews page lists the specific revs for other things === morgs wonders who Richard Braine is, inventor of crackful dhtml in the series +source page... [11:08] Kinnison: yes, kind of, there's a bug on this. we'll design it in brazil. [11:08] jamesh: and 364 -> 371 are the ones you have not reviewed to date [11:08] SteveA: okay ta [11:08] lifeless: thanks [11:08] 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. === Kinnison kicks firefox and types a shorter bug message in and hits submit [11:09] morgs: Friend of sabdfl's, party photographer and purveyor of completely-JavaScript-dependent Web sites [11:09] mpt: Ah, purveyor of bits of launchpad.js... === morgs goes out for a while... === elmo [~james@a130-233-4-133.debconf5.hut.fi] has joined #launchpad === guim [~glederer@193.190.183.237] has joined #launchpad [11:26] Hi [11:29] arg [11:29] BjornT: why do /malone/assigned and /people/whoever/+assignedbugs both exist? [11:32] mpt: the first is probably the older. [11:32] Well the first has undergone major changes recently [11:34] 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] BjornT: browser/person.py, line 200 ish [11:40] def assignedBugsToShow(self): [11:40] """Return True if there's any bug assigned to this person that match [11:40] the criteria of mostImportantBugTasks() or mostRecentBugTasks().""" [11:40] return bool(self.mostImportantBugTasks() or self.mostRecentBugTasks()) [11:40] [11:40] one or both of those queries lacks an orderby [11:41] so, when bool is used on them, we get a warning about unpredictable order [11:41] New Malone bug 1367 filed on product Malone by Matthew Paul Thomas: Merge /malone/assigned and /people/whoever/+assignedbugs [11:41] https://launchpad.ubuntu.com/malone/bugs/1367 [11:46] hi all [11:47] I have a problem that maybe someone can help here [11:47] I tried to subsrcibe to the edubuntu wiki, [11:48] then I had to creat a launchpad account (so far, this is at least what I understood) [11:48] but it seems like the wiki do not recognize the login/pwd it gave me [11:49] anyone to tell me what I did wrong? [11:50] login/pwd works on the launchpad page [11:50] hmm [11:50] SteveA: does anyone other than spiv grok that foo ? [11:52] 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] BjornT: okay. i'm on a crusade to get rid of warnings when we run tests. [11:53] cool [11:53] guim: I'm sorry, I can't help you ... [11:54] guim: are you using exactly the same login and password as works for launchpad? [11:54] that is, an email address, and the password? [11:54] ok [11:55] I check again, I might have done a silly mistake [11:55] thanks. come back if it doesn't work and we'll check out other things that might be wrong. [11:56] thanks, [11:56] i misunderstood the fact that login is e-mail and not name [11:57] what were you using? a WikiName ? [11:57] sorry [11:57] if you misunderstood, then it is probably that our system is hard to understand. [11:57] so, maybe we can fix it. [11:57] did you try to log in using your WikiName ? [11:59] i tried with a a name yes [11:59] the name i gave in the launchpad account [12:00] oh, like 'guim' ? [12:01] guim: I think you need to use one of the email addresses registered with Launchpad as the username [12:01] yes [12:01] jamesh: we're past thata already ;0 [12:01] yes jamesh [12:01] oh :) [12:01] guim: thanks, that helps. [12:01] no problem [12:01] that's what worked for the main ubuntu wiki after the auth change [12:01] for me [12:01] lifeless: do we have zope3 in the supermirror yet? [12:01] SteveA: let me see [12:02] someone is sending patches to the zope.interface mailing list [12:02] and asking if there's a better way to show their ongoing proposed improvements [12:02] SteveA: https://wiki.launchpad.canonical.com/LaunchpadHierarchyNavigation#head-eb01bf04c9a0e8a71c45816513df424f1c7ffedb [12:02] working on an svn branch is one option [12:02] working on a baz branch would be sweet, though, as they wouldn't need svn access [12:03] thanks mpt, i'll take a look [12:03] it failed [12:03] I've marked it for retest [12:03] they use lots of fancy stuff to do with linking many different svn areas together [12:04] svn:externals, I suppose [12:04] jamesh: i used to know what it was. i cleared that space for arch stuff ;-) [12:07] SteveA: we need to do each area separately. [12:07] SteveA: it'll be a pain [12:12] carlos: ping [12:13] mpt: i still need to know what to call one "breadcrumb" [12:13] mpt, pong [12:14] SteveA: a hierarchy item? [12:14] Not very catchy, is it... [12:14] class POTemplateNavigation(Navigation): [12:14] hierarchy_item = None [12:14] [12:14] for example? [12:14] i had it sketched as 'breadcrumb' [12:14] it will actually be a function that returns a BreadcrumbLink [12:15] or a HierarchyItemLink [12:15] bleh [12:15] Chain [12:15] ChainLink [12:15] ? [12:15] can't i just call them "breadcrumbs" ? [12:15] sure, if you like [12:15] they seem to me to be breadcrumbs, but just selectively displayed [12:15] and intelligently displayed [12:16] 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] they should all go in the approprite browser/thing.py module [12:17] i don't know what's in browser/launchpad.py [12:17] but, perhaps the ones for the "system homes" should go in there [12:18] okay. I was just noticing that the only file in browser/ that imports ApplicationMenu is browser/launchpad.py [12:18] we have few application menus yet [12:18] it includes the Rosetta ApplicationMenu [12:18] right [12:18] for Rosetta the "system homepage" for rosetta [12:18] i should put them into "system homes" or soemthing [12:19] jamesh: i want to walk up the current execution stack, looking for a particular kind of class [12:19] know any shortcuts, or should i just walk sys._getFrame, and its parent? [12:20] I don't know of a shortcut [12:20] 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] hmm, inspect has currentFrame [12:21] finding the class for the frame can probably be done using a few heuristics [12:22] the inspect stuff will get me what i need [12:22] ta [12:23] mpt, hmmm [12:23] mpt, from there I think the idea is to have a link as part of the suggestions [12:23] that lets you get the edit form for that language and string so you can edit it [12:24] 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] 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] and show it by default with the translation form === terrex [~terrex@84-122-69-8.onocable.ono.com] has joined #launchpad [12:31] carlos: oh, multiple source languages? [12:32] e.g. looking at the Portugese translations while doing the Brazilian Portugese one [12:32] mpt, yes [12:32] mpt, did you see current translation form? [12:32] carlos: Has it changed recently? [12:32] mpt, yes [12:32] crap [12:33] I have a branch to clean it up, but I'm a bit stuck [12:33] mpt, mark added a language selector to see suggestions [12:33] so you choose another language to see the suggestions [12:33] mpt@canonical.com/launchpad--translation-cleanup--0 [12:33] 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] that sounds like fun [12:34] mpt, and a way to select by default a language so you don't need to select it every time [12:34] click the link, and blow away the work you were doing on that page [12:34] ok [12:34] BjornT: mpt@canonical.com/launchpad--decruftify-b--1 is ready [12:36] c [12:36] EWINDOW [12:38] mpt: cool. i'll review it after lunch [12:53] stub: does canonical.launchpad.mailnotification need to directly access database code? [12:53] carlos: does canonical.rosetta need to directly access database code? [12:54] canonical.rosetta? [12:54] stub: Don't know - not my baby [12:54] whose? [12:54] bradb I think [12:54] oh, I see what do you mean === carlos checks [12:55] SteveA, I think we can fix it easily [12:55] SteveA, Mark added it to get some statistics [12:56] but we can do it with some methods added to the objectsets instead of using the database code [12:56] okay, goo [12:56] d === Kinnison 's toys have arrived [01:05] tonight I build myself a hoary-based PVR === Kinnison bounces [01:08] thanks BjornT === ddaa [~ddaa@marvin.xlii.org] has joined #launchpad === sivang [~sivang@box79162.elkhouse.de] has joined #launchpad === cprov [~cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === cprov says morning ... === dda1 [~ddaa@marvin.xlii.org] has joined #launchpad [01:39] SteveA: have time for an ApplicationMenu question? [01:39] ok === ddaa [~ddaa@marvin.xlii.org] has joined #launchpad [01:39] 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] 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] 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] (which I need to know in order to make the menus point to the relevant pages) [01:43] if you attach the app menu to ICalendar, it won't be displayed for a date range in that calendar anyway [01:43] okay. [01:43] 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] so, you need to have the app menu working with the current date range context [01:44] you should be able to get the calendar from a particular date range object [01:44] and then you can get the canonical_url for other date ranges, got from the calendar [01:45] I'll try switching over to canonical_url() and see if that makes things work a bit nicer [01:53] that seems to work better === debonzi [~debonzi@201-13-41-28.dsl.telesp.net.br] has joined #launchpad [02:37] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] import BugSetBase from the correct place. (patch-2072: bjorn.tillenius@canonical.com) [02:39] lifeless, ddaa, jblack https://chinstrap.ubuntu.com/~dsilvers/paste/filedwkhcR.html [02:39] I'm not able to merge from rocketfuel [02:40] Bazaar version 1.5~200507091049 [02:41] carlos: use baz merge --star-merge [02:42] Kinnison, hmm, that error does not looks like that kind of error, but anyway, will try [02:42] thank you === carlos -> lunch [02:43] carlos: it's not, but star-merge is different codepaths so it won't have the issue [02:43] mesh merge needs a lot of work [02:44] 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] as Kinnison said, merge does a lot of things that star-merge never even heard of. [02:45] that's a lot of opportunities for bugs to creep in. === elmo [~james@a130-233-4-133.debconf5.hut.fi] has joined #launchpad [02:46] someone knows if Staging is sending email correctly ? === ChanServ [ChanServ@services.] has joined #launchpad [03:05] Staging does not send emails at the moment [03:06] stub:?! === cprov was late ... === terrex [~terrex@84-122-69-8.onocable.ono.com] has joined #launchpad [03:15] morning [03:15] mpt: as for why +assignedbugs exists, you'd have to ask salgado [03:15] SteveA: mailnotification.py shouldn't need to directly access db code [03:19] mpt: do you have time to discuss menus, by any chance? [03:19] bradb: yes [03:19] great, let's do it [03:20] and hey, Kinnison and cprov are here for Soyuz menus too [03:20] bradb: arh, I was supposed to put them in the LPMenus spec, and I forgot [03:20] sorry [03:21] no worries [03:21] mpt: sure, no worries [03:22] bradb: ok, so any page belonging to Malone has the "Bugs" facet selected [03:22] that includes /malone/anything [03:23] and /people/anyone/+bugs [03:23] and /people/anyone/+assignedbugs [03:23] and /anything/+filebug [03:24] ok? [03:24] yes [03:24] Then most of those pages have the Malone app tabs [03:24] probably the /people/something pages don't, because it doesn't make much sense to report a bug about a person [03:24] but all the software ones do [03:25] and the /malone ones do [03:25] and the app menus are: " Bugs", "Report a Bug", "Show Reports", "Admin" [03:26] " Bugs" is the selected tab for any page whose URL ends in +bugs [03:26] "Report a Bug" is any page whose URL contains +filebug [03:26] "Show Reports" is selected when you're displaying a search or a bug report [03:27] and "Admin" is ... erm ... does Malone have any admin functions? [03:28] sorry, was on phone again [03:29] so, "Show Reports" highlighted for advanced search too? [03:29] yep [03:29] Malone has no Admin functions presently [03:29] ok, so we don't need that tab then [03:29] good [03:29] ok [03:30] presumably i can hunt through the code to find some examples of how this stuff is used [03:30] mpt: can we move to soyuz ? [03:30] and, with the menu structure you've just given me, i should be able to take care of the rest [03:30] 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] cprov: sure [03:31] mpt: sounds good, thanks. === cprov will follow bradb hunting usage examples [03:31] cprov: So give me some example Soyuz URLs [03:31] because to be perfectly honest, I'm a bit fuzzy on what is Soyuz and what isn't [03:32] mpt: /distros/ [03:32] (that's not a good way to make you feel loved, is it0 [03:32] ) [03:32] mpt: /distros/ubuntu [03:32] ok... [03:32] cprov: you have it easy, then [03:33] mpt: no, definitively I don't feel loved at all [03:33] aww === mpt gives cprov a hug [03:33] 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] mpt: wait they were easy ones ... what about distros/ubuntu/hoary/i386/firefox === cprov is pleased with a hug [03:35] You have the same facets as everyone else: Overview, Bugs, Translations, Bounties (eventually), Calendar [03:35] For /distros, /distros/ubuntu, and /distros/ubuntu/hoary/i386/firefox, "Overview" is selected [03:35] mpt: sure, I don't think we will have a Soyuz facet soon ... since soyuz has most read-only package browsing feature [03:35] and that already works in production [03:36] except /distros says "Launchpad" instead of "Overview", a slight bug [03:36]