[12:04] though it would be useful in some instances [12:05] mdz, do you use it in bugzilla? [12:05] occasionally [12:05] as a secondary sort key for severity [12:05] e.g., to prioritize among bugs of the same severity [12:05] ok, so is a bug with major severity that's P4 more important than a bug with normal severity that's P1? [12:06] yes [12:06] That makes priority by itself pretty useless for searching, I guess [12:06] so priority is useful only as a secondary sort after the primary sort of severity [12:06] I don't think I've ever searched by priority, no [12:06] well, that's how I use it [12:07] I don't know what bugzilla.mozilla.org or others do [12:08] So would dumping severity work if there was an increased number of priority values available? [12:09] e.g. 10 instead of 5 [12:11] or would even that be unnecessary? [12:13] severity generally has a useful definition [12:13] whereas priority is just an ordered sequence [12:13] so it's better to have severity and not priority, than the reverse [12:14] severity has an implicit priority because, in general, more severe bugs are more important to fix [12:14] to my mind anyway [12:14] yes [12:15] I think that 10 severities is too many to choose from [12:15] agreed [12:15] I'm (a) wanting Malone to be as simple as possible (and yeah, I know it's horribly complicated elsewhere, but every bit helps) [12:16] and (b) wanting to avoid bunfights over what a bug's severity should be, as happens occasionally in Bugzilla, and even in Malone's bug 1 [12:17] the idea was that priority is what the assignee plans [12:17] malone currently has severity and not priority, right? [12:17] severity is what Management Think [12:17] like debbugs and unlike bugzilla [12:18] mdz: Malone has both [12:18] sabdfl: to me, severity is inherent in the nature of the bug [12:18] Malone currently has both, like Bugzilla [12:18] and unlike debbugs and plone collector and jira and fogbuz [12:18] mdz: fair enough, but the same bug affects different users differently [12:18] sabdfl: while priority is subjective and may change depending on circumstances === interalia [n=interali@adsl-60-232.swiftdsl.com.au] has joined #launchpad [12:19] sort order, to a certain extent, should depend on whether or not you are looking at your bugs [12:19] i want to see *my* priority bugs first [12:19] and then in severity order [12:19] I see. the priority is not visible in the summary table, but is on the bug task page [12:19] so things I've said are high priority, and within that in severity order, would be my order [12:19] but i would be ok if we dropped priority altogether [12:19] are you suggesting that a bug should have multiple priorities? [12:20] me too (dropped priority) [12:20] and allowed admin and assignee to fight over one knob, so to speak [12:20] I like the idea of being able to bump a priority of a bug without lying about its severity [12:20] but in practice, I don't think it really works today in bugzilla [12:21] and it's not clear to me how it would work in malone [12:21] ok [12:22] if priority were to trump severity, then I'd say that severity would no longer be useful [12:22] it would become informational, and informationally it isn't very interesting [12:22] rather than a sortish thing [12:24] would renaming severity to "Importance" mean you weren't lying if you raised it? [12:24] Plone Collector calls it Importance [12:26] mpt: as long as the reporter cannot arbitrarily change this, i don't mind [12:26] one knob is better, unless we can really justify the second [12:26] right, neither severity nor priority are on the bug reporting form currently anyway [12:27] i would be happy to hide priority for now, and resurrect it when we have a strong idea of what would change with it [12:27] ok, great [12:27] thanks for your time mdz [12:27] mpt: they should be able to change it after reporting it, unless they assign it to themselves [12:28] yes, we can leave it wiki-mode just as we do with the rest of the bug fields [12:28] and restrict that later only if it's really necessary [12:29] mpt, you are welcome to my time too. and your salary. [12:29] heh [12:30] thanks [12:33] mpt: and indeed they shouldn't be on the bug reporting form, except perhaps for users with established clue [12:33] users in general have funny ideas about severity/priority/importance of their own bugs [12:33] in fact I don't like the idea of them being able to change them later, either [12:34] yes, cognitive biases [12:35] (a) getting emotional about losing data/time, (b) over-estimating the bug's prevalence because of their personal experience, and (c) the CC list for the bug becomes a mini-mailing-list of people reinforcing each other's senses of the bug's importance [12:37] lifeless: ping [12:37] pong [12:37] You asked me to get ahold of you? [12:37] yes [12:37] the +branches/xxxxxxxx url - we tested those [12:37] there should be no need for you to change *anything* [12:37] why do you think there is such a need ? [12:38] No changes made. [12:38] I see two rewrite rules [12:38] RewriteRule ^/(~[^/] +/[^/] +/[^/] +)/(.*) /${branch-list:$1}/$2 [L] [12:38] RewriteRule ^/\+branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/(.*) /$1/$2/$3/$4/$5 [12:38] right, the second handles +branches/xxxxxxxx [12:38] Oh! Silly me [12:38] which is for the launchpad branch scanner to use. [12:38] I read it wrong [12:40] np. might like to add a comment inyour config there, to help ;) [12:40] Good idea === rbelem [n=rodrigo@ubuntu/member/rbelem] has joined #launchpad [02:18] @#$%! Launchpad logging me out === Keybuk [n=scott@descent.netsplit.com] has joined #launchpad [02:58] mpt: it's saying "time to get outside and get some fresh air" ;-) === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has left #launchpad [] === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad [03:05] I just came back from lunch, I don't need another break that quickly :-) [03:14] mpt: ah, are you home? summer in nz must be awesome. looking forward to lca. === Hobbsee [n=Hobbsee@CPE-144-136-118-222.nsw.bigpond.net.au] has joined #launchpad === poningru [n=poningru@pool-68-238-172-220.tampfl.fios.verizon.net] has joined #launchpad === ti83smaster [n=andrewmi@ppp-70-236-184-189.dsl.sfldmi.ameritech.net] has joined #launchpad === Hobbsee [n=Hobbsee@CPE-144-136-118-222.nsw.bigpond.net.au] has left #launchpad ["So] [03:45] yo [03:45] whats up === ti83smaster [n=andrewmi@ppp-70-236-184-189.dsl.sfldmi.ameritech.net] has left #launchpad [] === lbm [n=lbm@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #launchpad === lisardhjo [n=lisardal@80.68.123.146] has joined #launchpad [08:18] Merge to devel/launchpad: [trivial] add custom rules for mapping the package name "linux" in bugzilla import (r2952: James Henstridge) [09:16] guys is it known that the editing of team members is all broken? [09:16] (urls are messed up) [09:19] what's up fabbione ? can you show me an example? [09:19] SteveA: sure.. [09:19] https://launchpad.net/people/ubuntu-server/+members/ [09:19] start from there [09:19] ok [09:19] click edit on one of the user awaiting approval [09:19] that page is still ok [09:20] k [09:20] approve or decline will push you to a 404 [09:20] https://launchpad.net/people/ubuntu-server/+member/sivan/+members [09:21] note that it should have removed +memeber/sivan and add +memebers/ to get back to the correct page [09:21] The reference for this error is OOPS-B195. Please include it in any related bug report or [09:21] for sivan, should i approve or decline? [09:21] i just approved [09:21] maybe i'll try on staging... [09:21] we can do the next one [09:21] no problem [09:21] just a sec.. [09:22] TomShwaller [09:22] it's okay. i'm doing it on staging. [09:22] decline with this reason: [09:22] Before applying to Ubuntu-Server team membership, [09:22] please create a wiki page where you describe [09:22] what are your interestes in the project and how [09:22] you plan to contribute. Thanks. [09:25] fabbione: i can reproduce this on the staging server now. i can't fix it right away, but i'll file a bug report for salgado to look at when he arrives. we'll have it fixed for the rollout on tuesday [09:25] thanks for telling me about the bug [09:25] ok [09:25] no problem === carlos [n=carlos@237.Red-83-59-153.dynamicIP.rima-tde.net] has joined #launchpad [09:27] morning [09:29] SteveA: isn't salgado on leave still? [09:30] BjornT: you're right, he is, in bolivia. I'll look to see when he comes back. [09:30] https://launchpad.net/products/launchpad/+bug/6453 [09:30] Malone bug 6453: "admin team membership redirect error" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Guilherme Salgado, Status: Accepted http://launchpad.net/bugs/6453 === Keybuk [n=scott@descent.netsplit.com] has joined #launchpad [09:55] morning all === Nafallo_away is now known as Nafallo === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === koke [n=koke@ubuntu/member/koke] has joined #launchpad [10:04] BjornT: did you accidentally put an LP checkout at /home/warthogs/archives/rocketfuel-built/launchpad/TicketTrackerEmailInterface ? [10:04] or maybe someone else moved it there? === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [10:05] jamesh: hmm, it was probably me, then. i'll check what went wrong. thanks. [10:06] the files are owned by you, which means you created them, but anyone could have moved the directory there due to the permissions [10:12] yeah, it seems that my brain wasn't functioning when i updated my scripts for creating new branches... [10:17] hmm [10:17] there is no reason why people should be able to write to rocketfuel-built [10:17] lifeless: can you tighten up those permissions please? [10:18] SteveA: probably because the parent directory was setgid [10:18] so rocketfuel-built inherited the group ownership [10:18] SteveA: ? [10:19] lifeless: anyone on the warthogs team can write to the LP tree in /home/warthogs/archives/rocketfuel-built [10:20] probably needs elmo to chgrp it then [10:20] to the pqm group. only root can do that [10:20] the pqm user should be able to [10:20] no [10:21] unix chgrping is a restricted operation [10:21] chmod isn't, chgrp is [10:22] if the pqm user is in the warthogs and pqm groups then it should be able to change the ownership [10:23] jamesh: not on linux. [10:23] jamesh: I've just tested in case I was confused, and it failed. [10:23] I seem to be able to do so on my box [10:24] change the group of files I own between groups I am a member of [10:24] anyway, I can trim the permissions, but that will allow new files to be confused. the right thing is a chgroup. [10:32] SteveA: meeting agenda says next meeting is dec 22nd? [10:34] the agenda is old === mpt [n=mpt@210-246-37-59.paradise.net.nz] has joined #launchpad [10:37] hi mpt [10:38] hi jamesh [10:39] mpt: yesterday SteveA was suggesting striking out automatic bug links for closed bugs, similar to what Bugzilla does [10:40] mpt: however, in Launchpad it is possible to have a bug that has both open and closed bug tasks [10:40] mpt: do you have any opinion on how to handle that case? [10:42] ooo [10:42] jamesh: maybe it beneficial to monitor a bug after it's been closed, in case it's re-discovered upstream? (if I understood right, automatic bug links will get wiped once the bug is closed?) [10:42] crossing them out had occurred to me, but the tasks problem hadn't [10:43] sivang, why would bug links get wiped? [10:43] sivang: what we are talking about is the way "bug NNNN" text in bug comments gets turned into a hyperlink to the associated bug [10:43] oh! [10:43] eh, my bad - sorry. [10:44] sivang: as an additional visual cue, bugzilla strikes out the "bug NNNN" text if the linked bug has been closed === mpt misunderstood sivang's misunderstanding [10:44] mpt: lol :) [10:44] How's hacking, sivang? [10:44] Getting your head around the codebase? [10:45] mpt: Well, actually, more of waiting for rocketfuel-get to be ready, after I've worked some bits on the RFS wiki page, and daf, jblack and SteveA commented. It appears to be coming nicely, but no yet real hacking on the codebase , I'm afraid. [10:45] mpt: one of the suggestions was to only strike out the text if all tasks are closed. The alternative is to try and decide which task the user cares about [10:45] once it's ready, I wish to use to get a checkout. [10:46] I think striking out if all tasks are closed is a good compromise [10:46] mpt: and the "check if all bug tasks are closed" heuristic works quite well in the common case of a single bug task :) [10:46] Well, that would be a 90% solution [10:47] trying to be magic would likely just be confusing and difficult to maintain [10:47] but eventually, daf, we'll have some derivatives that are really really slow about fixing bugs [10:47] hmm, true [10:47] Treaclinux [10:47] another heuristic would be "fixed in the thing it was originally reported against" [10:47] mpt: you finshed you're share of HUB drawings ? ;-) (joking, I know you're *very* busy) === mpt cries [10:48] but you need to deal with cases like it being reassigned after being filed [10:48] if we do this, we should have a very simple rule to start with [10:48] agreed [10:48] and then choose as we go on to either remove it entirely, or to make the rule better [10:48] sivang, it's been on my to-do list each day for the past several weeks [10:48] how about "if it has one bug task, and that bug task is fixed, strike i tout" [10:48] another way to do it.. fancier [10:48] ok === sivang hugs mpt [10:49] is with a div that contains bug metadata that becomes visible when hovering over the bug link [10:49] if 50% of the tasks are closed, strike out 50% of the characters in "bug NNNN" [10:49] so let's start with, if all are fixed, strike it out [10:49] haha [10:49] jamesh: lol [10:49] most bugs now have only one task anyway [10:49] Well, I was thinking of a dotted strikethrough [10:49] mpt: bjorn said that he thought striking out would mean invalid / rejected [10:50] so, there is a risk that this is meaningful only to people who used bugzilla a lot before [10:50] SteveA, yeah, that causes me occasional confusion in Bugzilla too [10:50] so maybe this is something to be solved with the bug's icon [10:50] yes [10:50] good idea [10:50] let us not do striking out now [10:50] in EntityPresentation or whatever it's called [10:51] although I find myself getting confused with the different bug icons we have already [10:51] I usually think of the strikeout similar to striking something off a todo list [10:51] currently we have: [10:51] * colors for priorities [10:51] a variety of subtly different;y-coloured insects [10:51] * blue for external bug watches [10:51] that's all. [10:51] it is useful in the bug dependency lists of tracker bugs like https://bugs.freedesktop.org/show_bug.cgi?id=5041 [10:51] Freedesktop bug 5041: "7.1 Release Tracker" Product: xorg, Component: Release, Severity: blocker, Assigned to: xorg-team@lists.x.org, Status: NEW https://bugs.freedesktop.org/show_bug.cgi?id=5041 [10:52] yes, it makes such lists easier to scan [10:52] though, greying out could do a similar job [10:52] but then, Bugzilla uses grey for Unconfirmed [10:53] this needs a spec! [10:53] mpt: maybe not different colours of the same icon, but the same icon *glowing* more brightly in a different colour [10:53] so someone looking in b/w can see the distinction still [10:53] from the glow [10:53] maybe instead of a strikeout we can have an exclemeation mark, that links to a list of how many of the related bug tasks are still open? and have a color ranging from red->>green indicating the 'shape' the bug is? [10:53] red meaning still a way to go, greener meaing getting there.. [10:53] SteveA, the current bugs have different numbers of dots on their backs for that purpose [10:53] 1 dot = low [10:53] 2 dots = medium [10:54] 3 dots = high [10:54] high what? severity? [10:54] remember that this is going to be inline with the bug comment, so it shouldn't be too distracting. [10:54] aliveness? [10:54] i had not noticed at all [10:54] priority [10:54] it should provide some important information at a glance without interrupting you as you read the comment [10:55] maybe major bugs should be scarier [10:55] mothra-like [10:55] cockroaches vs. moths === sivang tries to fidn the dots. [10:55] bbiab === dayyan_hbb [n=habiblaw@202.63.231.193] has joined #launchpad [10:59] hallo [10:59] anyone can tell me? [11:00] i ve visited and fill the form from shipit.ubuntu.com...to send me the copy of ubuntu [11:00] hello dayyan_hbb [11:00] but it has been 3 month i've got nothing [11:00] what country are you in? [11:00] indonesia [11:01] can you help me?... i'll try ubuntu in my school [11:02] i can look into it. but also, you can request some more CDs anyway. [11:02] i will ask for your details in a private message [11:02] yes .. [11:03] or may i send u email... now? [11:03] ah... i think freenode might be stopping you from seeing my message [11:08] ups... i'm forget.. if it's OK, May i have about 20 - 30 CDs.. because i've promote ubuntu to my friends in other school and they are interested in installing ubuntu in their school [11:17] sabdfl: "manage our personal APT branches in Launchpad"? === dayyan_hbb [n=habiblaw@202.63.231.193] has left #launchpad [] === mpt [n=mpt@210-246-37-38.paradise.net.nz] has joined #launchpad === carlos [n=carlos@120.Red-83-53-68.dynamicIP.rima-tde.net] has joined #launchpad [11:47] ddaa: hct ? [11:48] you mean s/APT/HCT/ ? [11:48] yeah [11:48] apt is binary [11:48] but there will be personal apt repos driven by hct [11:49] yes, but I do not think that ubuntu is THAT MUCH fork and forget that they have multiple APT branches... [11:49] haaa, oooookay! [11:49] is there some way to get __module__ from a function? [11:51] I vaguely recall that epydoc was using inspect for that [11:51] so I needed to monkey patch it so it would do what I tell it to. [11:51] inspect.getmodule(foo) - right [11:52] But some people say that inspect is evil [11:52] meh, in the stdlib - will do for me [11:52] and it's downright confused (broken) by symlinked situations [11:52] if you try to get source code [11:52] well, it may not be available [11:52] for example, you may have only .pyc files [11:53] it should not need that to do get_module() thought [11:53] correct [11:53] also, we dont support shipping bzr as .pyc, so that should not be much of a concern [11:53] neither should it need to to tell me on which line some func was defined [11:53] this is library symbol deprecation decoration [11:54] btw, it seems that functions do have __module__ attribute [11:54] do they ? ah phew [11:55] actually... the thing with epydoc is that I was cloberring it to control epydoc, and epydoc insisted on inspect [11:55] using inspect ought to be fine [11:55] what I actually want is the fully qualified python name for the thing [11:55] and is clearer than getting __thing__ attrs directly [11:55] so I had to make it more stupid so it would do what I wanted [11:55] but that does not seem to be trivially accessible. [12:05] I'd love to have the subscribe actions in the subscribers portlet [12:06] I'm frustrated every time I want to subscribe a bug, here's how my brain works: [12:06] 1. find the subscribers portlet [12:06] 2. look for my name in the subscribers [12:06] 3. not me, want to subscribe... where's the link??? [12:06] 4. panic [12:07] 5. ha... yes that's an action, that's on the other column bummer [12:08] 6. okay, that block here is action... "Link to CVE", "Mark as Duplicate"... "Subscribe"! [12:08] 7. Click [12:08] Steps 4, 5 and 6 and entirely uncessary [12:10] you panic too easily :) [12:10] No, seriously, if just one person says "me too", I'll file that as a bug. [12:11] what's the bug -- "subscribe link is too hard to find?" [12:13] once there was a subscribe link in the portlet, not sure why it was removed. i think it would be good to have a subscribe link near the subscribers list. [12:13] Something like that. [12:13] I suppose it wouldn't be bad to have a duplicate link in the portlet [12:13] here's another UI issue (already filed a bug about it): [12:13] let's ask mpt when he comes back [12:14] Also, I guess, action portlet is too hard to read. [12:14] 1. try to link a URL to a bug that already has URLs linked to it [12:14] 2. now try to do the same to a bug that doesn't have URLs linked to it [12:14] Could probably use some more vertical space. [12:15] jamesh: what does "link a URL to a bug"? [12:15] what does that mean? [12:15] ddaa: you can associate a URL with a bug [12:16] let me find an example [12:16] use case! [12:16] tell me a story uncle james! [12:18] https://launchpad.net/bugs/1662 has a URL associated with it (see the portlet on the right) [12:18] Malone bug 1662: "CVE numbering changes" Fix req. for: malone (upstream), Severity: Normal, Assigned to: Mark Shuttleworth, Status: Fixed http://launchpad.net/bugs/1662 [12:18] Soyuz took all the vertical space, that's why there's none in Launchpad. [12:18] there is an "Add" link in the portlet to add extra URL references, but the whole portlet goes away if there are none. [12:20] Duh... the "related web links" portlet is also on the wrong column! [12:21] jamesh: presumably these URLs were added before the bug was born [12:21] jamesh: well, i think that's because someone thought that adding URL to bugs was crack ;) even if there was a subscribe link in the portlet, i would still expect to find it in the actions portlet. [12:22] there is an argument that you can just add URLs in a comment [12:22] BjornT: Agreed, it's useless. The same effect is achieved by putting the link in the description. === GoRoDeK [n=gorodek@p5083E87D.dip.t-dialin.net] has joined #launchpad === zyga [n=zyga@ubuntu/member/zyga] has joined #launchpad [12:26] carlos: hello [12:26] zyga, hi [12:27] carlos: I plan to do some catch up in the next few days regarding the gnome sync [12:27] has there been any progress with that? [12:27] zyga, no, sorry [12:27] holidays and other critical fixes... [12:27] exactly :-) [12:28] carlos: has there been any progress on implementing search in rosetta? [12:28] zyga, nothing outside the spec we wrote [12:29] carlos: are the exports working properly/ === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:30] good morning! [12:30] zyga, they should work, yes, but there are some bugs still around [12:31] carlos: are you planning any export soon? [12:31] BTW is there any reason, besides "it's not done yet", why the "subscribe link" does not use JS to POST the subscription form? [12:32] I understand why subscription should be done by post, and why it should look like a link, but I think the extra click is just annoying. [12:33] not to mention the extra page loading [12:33] hmm [12:33] carlos: the package list distro/lang is corrputed :/ [12:33] ddaa: I think that is an excellent idea, and certainly worth filing a bug about [12:33] zyga, ? [12:34] carlos: https://launchpad.net/distros/ubuntu/dapper/+lang/pl [12:34] daf: one caveat is that I'm not really sure that you can do that sort of thing with JS (out of sheer ignorance). [12:34] I can make a screenshot if you'd like [12:34] the right float corrupts the list [12:35] zyga, yeah, we are fixing those pages to fit inside the new layout [12:35] ddaa: yes, you can [12:35] carlos: ok, great [12:35] Launchpad doesn't use any stuff like this yet, but we should [12:36] daf: okay, will file a bug === mpt [n=mpt@210-246-37-59.paradise.net.nz] has joined #launchpad === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:45] morning [12:45] carlos: hum, what is a translator supposed to do when the msgid contains an entity and that entity is not escaped, thus, hard to type (unless you know the entity in question)? [12:45] carlos: I'm looking at the ™ sign that got displayed as small 'tm' [12:46] zyga, copy and paste? [12:46] mpt: i'm finishing off FormLayout. can you give an example of a field which is automatically converted to lowercase? [12:46] mpt: not good [12:46] jamesh: did you say you'd fixed the tests that had 2005 hardcoded into them? [12:46] BjornT, any of the "this will be used in an URL" fields, e.g. product name, project name, distro name [12:46] mpt: the msgstr should contain ™ not the unicode character that corresponds to this character [12:47] s/character$/entity/ [12:47] zyga, so the "English:" row should be showing "™" but it's showing TM instead? [12:47] that's a problem with the original package, not Rosetta, I think [12:47] mpt: exactly [12:47] that's a bug [12:48] Rosetta escapes entities, I'm pretty sure [12:48] hmm [12:48] I'll check the source [12:48] iirc I ran past the bugmail from that bug today, closed due to lack of reproducability === gneuman [n=gneuman@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:50] SteveA: how does pydoc generate the text for the right hand side of functions it lists: [12:50] bzrlib.get_bzr_revision = decorated_function(*args, **kwargs) [12:50] seems ugly, and an unintended side effect of function decoration [12:50] daf: yeah. There was only one that caused a problem. [12:51] bug 6457 [12:51] Malone bug 6457: "Subscribe should work in one click" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/bugs/6457 [12:51] jamesh: cool [12:51] also bug 6456 [12:51] #6456 [12:51] bug 6456 [12:51] Malone bug 6456: "Subscribe actions are too hard to find" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/bugs/6456 [12:51] ddaa: doesn't amazon have a patent on one click stuff? :) [12:52] zyga: we are not e-commerce, Amazon does not give shit about us. [12:52] ddaa, I think zyga was joking [12:52] :-) [12:53] mpt: it's not a bug the original template does contain 'tm' [12:53] sorry, I fail to find patents funny... [12:53] I'm not sure US patent law would apply to us [12:53] mpt: ok, it seems that no conversion is done today, though. i'll take a look at how to do it. [12:54] BjornT, there was one I remember, Morgan Collett implemented a back-end validator for it === stub [n=stub@ppp-58.10.74.67.revip2.asianet.co.th] has joined #launchpad [12:55] zyga, so it's a bug in the original package? [12:55] heya stub [12:56] mpt: I think that text might come from glade, someone probably copied the 'tm' from the char palette [12:56] zyga, if characters like that should never appear in templates, report a bug that Rosetta should ignore strings containing them on import [12:57] (so that people can still translate the other strings while the developers fix the wonky characters) [12:57] mpt: it works okay but you need to manually copy-paste :/ [12:57] Yo [12:57] (and by "ignore" I mean "ignore and whine", not "silently ignore") [12:57] yo stub [12:57] how's it going man === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad [12:58] mpt: ah, now i found it. nothing that can be used, though :( and actually, i think the validator will complain on the capital letters before it gets converted... [12:58]