=== doko [n=doko@217.205.109.249] has joined #launchpad [12:37] lifeless: Hmm, ok. [12:37] carlos: I'm very rarely around at 5am :) [12:50] spiv: that would be muchly appreciated === lfittl [n=lfittl@83-65-244-232.dynamic.xdsl-line.inode.at] has joined #launchpad [01:09] spiv: yeah, I thought it after pinging you :-P === lfittl [n=lfittl@83-65-244-232.dynamic.xdsl-line.inode.at] has joined #launchpad === doko [n=doko@217.205.109.249] has joined #launchpad === zyga [n=zyga@ubuntu/member/zyga] has joined #launchpad === poningru [n=poningru@n128-227-61-6.xlate.ufl.edu] has joined #launchpad === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad === Ubugtu [n=bugbot@ubuntu/member/seveas] has joined #launchpad === Kamion [n=cjwatson@83-216-156-196.colinw664.adsl.metronet.co.uk] has joined #launchpad === lamont-work [n=lamont@mib.fc.hp.com] has joined #launchpad === SteveA [n=steve@195.182.78.95] has joined #launchpad === mdke [n=matt@ubuntu/member/mdke] has joined #launchpad === mantiena-baltix [n=vytis@bonamens.lt] has joined #launchpad === \sh_away [n=shermann@ubuntu/member/backslash-sh] has joined #launchpad === Kinnison [n=dsilvers@haddenham.pepperfish.net] has joined #launchpad === Lathiat [i=lathiat@ubuntu/member/pdpc.basic.lathiat] has joined #launchpad === lifeless [n=robertc@static-147.29.240.220.dsl.comindico.com.au] has joined #launchpad === JanC [n=janc@lugwv/member/JanC] has joined #launchpad === dilys [n=dilys@193.28.45.42] has joined #launchpad === sivang [n=sivang@ubuntu/member/sivang] has joined #launchpad === jamesh [n=james@203-59-207-160.dyn.iinet.net.au] has joined #launchpad === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad === Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad === sevrin [n=sevrin@202.75.186.154] has joined #launchpad === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #launchpad === dooglus_ [n=dooglus@rincevent.net] has joined #launchpad === spiv_ [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad [01:35] Merge to devel/launchpad/: [r=spiv] Fixed the filtering form submission and added the missing tests. (r3107: Carlos Perell Marn) === carlos -> bed [01:45] see you tomorrow! === doko [n=doko@217.205.109.249] has joined #launchpad === mpt_ [n=mpt@222-154-182-215.jetstream.xtra.co.nz] has joined #launchpad === suodla is now known as dous [03:00] Goooooooooooooooooood afternoon Launchpadders! === doko [n=doko@217.205.109.249] has joined #launchpad === stub [n=stub@gb.ja.98.136.revip.asianet.co.th] has joined #launchpad === stub [n=stub@gb.ja.98.136.revip.asianet.co.th] has joined #launchpad === doko [n=doko@217.205.109.249] has joined #launchpad === dous [n=dous@efreet.edu.ms] has joined #launchpad [05:06] stub: I think the value of oops_root_url in the production configs is wrong [05:06] stub: missing a slash at the end. [05:06] jamesh: Yes - I didn't get around to the cherry pick I needed yesterday [05:18] spiv, jamesh: I've tracked down a bug (at least from our point of view) in SQLObject and I think identified the bits that need changing. Details are in the launchpad@ mailing list. I don't suppose either of you know if 'foo is 0' or 'foo is false' are valid under mySQL? It looks like sqlbuilder.py is attempting to generate platform agnostic SQL so fixing this for PostgreSQL will likely break mySQL. [05:22] stub: I don't know much about mysql [05:28] stub: I've only ever seen "IS" used to compare against NULL [05:28] stub: surely Postgres can tell that "=" and "IS" are equivalent for a non-NULL column though, right? [05:30] jamesh: The case we noticed this was a NULLable column. It uses three state logic (approved, not approved or pending) [05:31] stub: SQLObject is a bit of a mess here. sqlbuilder will figure out that "column==None" should be "column IS NULL", but a selectBy(column=None) produces "column = NULL". [05:31] And doesn't seem to have any special casing for booleans, as you've noticed. === spiv checks current sqlobject SVN [05:32] jamesh: I doubt the planner would bother anyway with detecting NOT NULL columns in this case. It needs to be generic, and in many cases there won't be a physical column there. [05:32] spiv: current SVN has the same behavior [05:36] stub: Well, at least SVN appears to make Foo.selectBy(bar=None) emit "bar IS NULL" now. [05:37] But again, only for None. [05:38] spiv: Can you see anyway of making sqlbuilder generate database-backend specific code? ie. fixing this so it only has an effect if you are talking to a PostgreSQL backend? I could patch it now I think, but it would mean we have effectively forked. [05:38] We've already got a painful amount of divergence from upstream :( [05:39] (__eq__ and __neq__ of sqlbuilder.SQLExpression) [05:39] jamesh: do you know how to get urllib2 to make a HEAD request ? [05:40] lifeless: no. You might have to go down to httplib [05:40] jamesh: just found that 'transport.has' in bzr is doing 'get' :[ [05:40] lifeless: actually, if you subclass urllib2.Request, you could ... [05:40] stub: Well, the place in sqlbuilder to hook db-specific stuff is in __sqlrepr__ methods [05:41] override the get_method() method [05:41] jamesh: thanks [05:41] looks like pycurl transport is better already, so I'm going to ignore it :) [05:43] stub: So, there's two parts, I think. [05:44] stub: converters.py has this atm: [05:44] def BoolConverter(value, db): [05:44] if db in ('postgres',): [05:44] if value: [05:44] return "'t'" [05:44] else: [05:44] return "'f'" [05:44] else: [05:44] Which judging from your post to launchpad@ is suboptimal. [05:44] spiv: Yes - that is the other part. But that can be done specifically for postgresql. [05:45] spiv: If I update sqlbuilder however, I don't see a way of doing it without breaking other backends. Which is fine for us, but means it can't be fixed upstream. [05:45] (without refactoring everything - urgh) [05:46] I *think* we can do it by hacking SQLOp.__sqlrepr__ [05:47] With a nasty check for "if db == 'postgres' and self.op == '=' and isinstance(self.expr2, bool):" [05:48] Ahh... [05:48] Which is hardly elegant. [05:48] But should only change behaviour for postgres. [05:48] I don't see how that expression is relevant when talking about SQLObject :-) [05:48] hardly elegant would be an improvement :) [05:48] And hope no-one is silly enough to want "False==Table.q.column" to work as well as "Table.q.column==False"... ;) [05:50] Or, just change the shipit code to not use sqlbuilder ;) [05:51] And again, this doesn't help selectBy at all :( [05:51] This will bite us elsewhere too - we have other boolean flags :) [05:51] Is upstream selectBy using the same sqlbuilder hooks now? [05:52] spiv: https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-08/B724 <- from queries #24 - #1286 look like they should have been done as a single query. Have you seen this behaviour from sqlobject before? [05:52] stub: No, not at all. [05:52] stub: selectBy invokes self.dbconn._SO_columnClause or some such on the **kwargs. [05:52] The definition of which includes this gem: [05:53] ops = {None: "IS"} [05:54] Anyway, the short answer is the logic that makes "Foo.q.column==NULL" produce "column IS NULL" is totally seperate to the logic that makes Foo.selectBy(column=NULL) produce the same (in current SVN). [05:56] stub: Sure it wouldn't be easier to just remove all boolean columns from our schema? ;) [05:57] Maybe easier to rewrite SQLObject sanely [06:00] jamesh: Yes, unfortunately. [06:02] jamesh: I can't quite remember why it does that, I'll see if I can figure it out. === doko [n=doko@217.205.109.249] has joined #launchpad [06:03] spiv: from playing around a bit, it sounds like a lazyColumns query [06:07] jamesh: That would do it, but we aren't using that feature to the best of my knowledge. [06:07] spiv: bugger. I think it is caused by a bug I just noticed in my __nonzero__ implementation a few minutes ago [06:07] jamesh: Ouch. [06:07] I've submitted the merge request [06:07] Merge to test/launchpad/sourcecode/sqlobject/: [trivial] make SelectResults.__nonzero__() correctly handle self.ops['end'] ==None (r44: James Henstridge) [06:08] there it goes [06:08] What's the 10-second summary? [06:09] spiv: the __nonzero__ implementation tries to do a select query that will return minimal data to determine if any results would be returned [06:10] it has to do some special stuff to handle offset queries, and I was assuming that SelectResults.ops['end'] would be unset if no end interval was set [06:11] instead it seems to be set to None, so the query returns a lot more rows [06:11] Ah. [06:11] I think it is filling the cache with a lot of SQLObject instances for those rows which only have their ID set [06:12] (that's just a guess though) [06:13] Sounds plausible... so long as the behaviour is correct, it shouldn't matter. [06:18] anyway, it should get the limit correct now === mpt [n=mpt@219-89-140-79.jetstart.xtra.co.nz] has joined #launchpad === mpt_ [n=mpt@219-89-157-175.jetstart.xtra.co.nz] has joined #launchpad === jsgotangco [n=jsg@210.4.38.43] has joined #launchpad === doko [n=doko@217.205.109.249] has joined #launchpad === mpt [n=mpt@219-89-148-52.jetstart.xtra.co.nz] has joined #launchpad [08:18] Merge to devel/launchpad/: [trivial] queued user database permissions (r3108: Stuart Bishop) === Mithrandir [n=tfheen@c5100BC63.inet.catch.no] has joined #launchpad [08:37] hmm; it looks like my specs page has a lot of specs which I've never seen before.. a bunch of LP specs. https://launchpad.net/people/tfheen/+specs has such specs as "Publishing morgue" and I can't understand why it's listed on my list of specs? [08:37] Merge to devel/launchpad/: [trivial] more suggested changes to analyse-error-reports.py script (r3109) === mpt [n=mpt@219-89-154-46.jetstart.xtra.co.nz] has joined #launchpad [08:43] hmm [08:43] Mithrandir: there's a dodgy query in there [08:43] thanks for pointing it out [08:44] do you want a bug about it? [08:45] I'll just point it out on the mailing list [08:45] stub: with the query you did for Person.specifications, I think the two subqueries are incorrect [08:45] ok, coolie, thanks. [08:46] stub: they select SpecificationFeedback.id and SpecificationSubscription.id respectively, when they should be selecting ....specification [08:47] yet the tests passed. yay. === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === carlos [n=carlos@84.76.255.40] has joined #launchpad [08:52] morning [08:55] hi carlos [08:55] SteveA, ping === lfittl [n=lfittl@83-65-244-232.dynamic.xdsl-line.inode.at] has joined #launchpad === doko [n=doko@217.205.109.249] has joined #launchpad [09:05] stub: I regenerated the oops summary reports to try and group timeout errors a bit better (trying to ignore integer and string constant differences in SQL queries) [09:05] what do you think? === iwj [n=ian@xenophobe.extern.relativity.greenend.org.uk] has left #launchpad [] [09:07] mpt: hello === Mithrandir [n=tfheen@c5100BC63.inet.catch.no] has left #launchpad [] [09:10] stub: since the proper rollout, have you picked any patches for shipit? [09:11] jamesh: where are the reports? [09:11] SteveA: There is one going in now [09:12] stub: okay. think it will be done in 20 mins? [09:12] 20 mins the tests will have finished running, then the rollout. So 30/40 mins. [09:12] (assuming tests still pass) === dooglus_ is now known as dooglus [09:14] SteveA, got time for a call? [09:14] stub: https://chinstrap.ubuntu.com/~jamesh/oops-summaries/2006-02-08.html <- it's linked in the mail to the list [09:14] https://chinstrap.ubuntu.com/~jamesh/oops.cgi/summaries [09:14] Ubugtu, pardon? [09:14] spiv: i'd love to rewrite sqlobject sometime... or at least refactor the selection of Converters to use multiadapters on database-type and data-type [09:15] mpt: sure. in 10 mins? [09:15] ok [09:16] oops ubugtu did it again [09:16] oops-a-daisy [09:16] https://chinstrap.ubuntu.com/~jamesh/oops.cgi/a [09:18] we could give seveas a better regex [09:18] jamesh: That looks really good [09:19] jamesh: excellent report! [09:19] mpt: how about some CSS styling love for it? [09:19] oh, and some portlets too. gotta have portlets [09:20] I could move the whole report into a portlet [09:20] jamesh: A minor tweak would be to collapse \$INT, (\s\$INT,)* \$INT to $INT [...] $INT [09:21] (second and third last hard timeouts are really the same) [09:23] what does this $INT stuff mean? [09:23] arbitrary integer [09:23] some string of digits [09:24] The oops will have the real values, but it lets james group queries nicely [09:24] oh i see [09:24] so, collapsing it is only for display [09:24] not for sorting [09:24] well, it does affect the sorting [09:25] if it causes two groups of oops reports to collapse into one, the higher count might put it further towards the top [09:25] or should i say "grouping" [09:27] Sooo.... the test suite isn't passing on our production branch :-/ [09:27] I might have to roll out HEAD [09:27] :-( [09:27] We could give Launchpad a better regex too, I just reported a bug on that [09:27] launchpad a better regex for what? [09:28] for DPOT? [09:28] 771 occurrences of AttributeError: 'POMsgSetView' object has no attribute 'context' yesterday [09:28] jamesh: That might be due to cherry picks [09:28] (One of the errors I'm seeing running the test suite) [09:28] so... tests don't pass on production, but do pass on HEAD [09:28] any database changes since? [09:29] I don't think so [09:29] nope [09:30] i reckon moving from errors to no errors is a good bet [09:32] jamesh: I saw that error and requested stub to cherrypick some code that rewrites that class and indirectly fixes it [09:32] gah [09:32] carlos: Can't cherry pick it due to conflicts [09:32] but I don't understand how is that we got that error if last production updated didn't have any change there (at least from me) [09:32] stub: oh [09:33] stub: give me the production branch and I will fix them for you [09:33] carlos: production branch is broken - the test suite doesn't pass. I'm moving it to HEAD, which will include your patch [09:33] ok [09:37] stub: would you let marilize know when the new code is running? [09:41] stub: thanks for that grant - source accepts as lp_archive@drescher work now [09:41] np [09:43] BjornT: note that we're losing "priority" from malone soon [09:43] while keeping severity, and renaming it "importance" [09:44] oh yeah, i remember that now. === mpt [n=mpt@219-89-129-190.jetstart.xtra.co.nz] has joined #launchpad [09:49] SteveA, back === mpt had Words with the router === SteveA waits for the lag to recover === SteveA waits for the lag to recover again [09:53] mpt: waiting for you to tall [09:53] mpt: waiting for you to call [09:54] SteveA, "call refused" [09:54] how odd === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has left #launchpad [] [09:58] Kinnison: Any idea what the current status of GIna running on prat is supposed to be? === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [09:59] mpt: more router problems? [09:59] SteveA, no, my connection's fine === thisfred [n=thisfred@a80-127-80-154.adsl.xs4all.nl] has joined #launchpad [10:12] oooooh man [10:12] oooooooh man [10:12] A guy [10:12] called, apparently, Pacman [10:12] sent a mail to bazaar@lists.canonical.com [10:13] with subject Ubuntu [10:13] saying: [10:13] > If this software is free why is there a guy on ebay selling copy after copy of this software? Here is a link to one of his Auctions he has lots more! [10:13] > http://cgi.ebay.com/WHY-PAY-300-for-OPERATING-SYSTEM-TRY-OUR-NEW-OS_W0QQitemZ7217957922QQcategoryZ41881QQrdZ1QQcmdZViewItem [10:13] It should be illegal to be so stupid. [10:15] We have to sell some copies or else it will be impossible to pirate it. And if it doesn't get pirated, we lose out on the 3133t users [10:15] BTW, the ebay announce would probably be illegal in many countries for lying advertisment... [10:16] since it's prominently displaying artwork that's not part of the package [10:18] ddaa: the "We are the copyright owner of this product." is probably the main problem with that auction [10:19] oh, that too... but after spending the alloted half a second thinking about it I assumed it was a meant to mean something else... [10:20] at least they don't say "shipping: 6-8 weeks", then use shipit to fulfill the order [10:20] I think this copyright claim might be worth escalating to the business folks [10:23] it also happens in ebay.ph [10:24] i asked about it too but marlize said we don't have power over what happens to a cd when it arrives to the one who ordered it === jsgotangco remembers sabdfl saying it over lunch last week that he doesn't mind [10:26] oh copyright [10:26] jsgotangco: the problem I was pointing out was them claiming copyright [10:26] yeah [10:26] reselling the CDs isn't an issue [10:26] "our" [10:26] or pressing their own and selling them [10:26] yeah that's pretty bad [10:28] also, a number of the screenshots are obviously swiped from the internet rather than being their own [10:29] maybe just write to ebay and let them know the copyright notice is wrong === doko [n=doko@217.205.109.249] has joined #launchpad === lucas [n=lucas@ubuntu/member/lucas] has joined #launchpad [10:39] I've told cvd on #canonical about the auction. [10:40] Kinnison: ping? [10:40] And replied a very polite and informative email to the helpful idiot that posted to the bazaar mailing list in the first place. [10:40] Kinnison: the last few messages on dapper-changes have some very unusual headers [10:41] mdz: I already filed https://launchpad.net/products/launchpad-upload-and-queue/+bug/30938 about that [10:41] malone bug 30938 in launchpad-upload-and-queue "manual source accepts from new result in bizarre mails" [Normal,Unconfirmed] [10:42] ah, so that's what was different about them [10:42] I probably should have tried just one and then waited to ensure the mails were sane [10:43] it seems to take a dreadfully long time for builds to be kicked off after source upload [10:43] source accept rather [10:43] language-support-te was accepted before 09:00, but there are still no builds recorded on https://launchpad.net/distros/ubuntu/+source/language-support-te/1:6.04+20060208 [10:44] I would expect it to have at least hit needs-build after the 09:00 publisher+sequencer run finished [10:47] is there a way to get a machine-readable version of https://launchpad.net/distros/ubuntu/+source/flashplugin-nonfree/+bugs ? [10:49] lucas: Not yet. We want an XML-RPC interface for that sort of thing and RSS feeds but it hasn't been implemented yet [10:50] ok [10:57] ah, language-support-te builds showed up at last [10:57] not quite sure what soyuz was doing in the meantime ... [10:57] mpt: shall we continue on irc? === dholbach [n=daniel@ubuntu/member/dholbach] has joined #launchpad [10:58] hello [10:58] dholbach: dude! [10:58] malone/bugtrackers/ubuntu-bugzilla/ seems to be oopsing [10:58] Did somebody complain already? :-) [10:58] got an oops code for me? === dholbach hugs SteveA [10:59] oops-40c305 [10:59] https://chinstrap.ubuntu.com/~jamesh/oops.cgi/40c305 [10:59] thanks Ubugtu [10:59] dholbach: will have to wait a couple of minutes for it to be rsynced [11:00] Ok. [11:00] jamesh: suggestion for oops page -- if it can't find the oops, include a single redirect to retry after the 0 or 5 minute (and a bit) time, when the rsync will be done [11:02] lucas: hello [11:02] lucas: https://launchpad.net/distros/ubuntu/+source/flashplugin-nonfree/+bugs-text [11:04] lucas: https://launchpad.net/bugs/3204/+text for an individual bug [11:04] malone bug 3204 in flashplugin-nonfree "Font missing after breezy upgrade !" [Normal,Fix released] [11:05] SteveA: where is it documented ? [11:05] lucas: it's a brand new feature, so it isn't well documented. There is a spec about it, though. [11:05] ok [11:06] but i think the feature has progressed beyond the spec [11:06] any plan to output Yaml or XML instead ? [11:06] eventually [11:06] but, this rfc-822 stuff is easy to parse [11:06] (yaml is very easy from python) [11:06] rfc822 is easy [11:06] talk with Seveas about the code he wrote for ubugtu [11:06] yeah, but yaml is easier :-) [11:07] i can't argue with that [11:07] Python YAML support has been buggy in my experience === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [11:07] dholbach: I'll look into it [11:07] jamesh: i can't see that oops report from dholbach, oddly [11:07] but it's been a while since I've used it [11:08] SteveA: it is a case sensitivity issue. I should fix the oops script to upper case what people give it [11:08] oka [11:08] try the link from http://bugzilla.ubuntu.com/11200 for example. [11:08] got it [11:08] Oh, sorry. [11:09] stub: gina should never be running on prat again (well, unless we decide to import debian) [11:09] dholbach: this is jamesh's area, so as he said, he'll look into it === pitti [n=pitti@ubuntu/member/pitti] has joined #launchpad [11:09] hi guys [11:09] hello pitti [11:09] https://launchpad.net/distros/ubuntu/+source/flex/+bug/30940 [11:10] Sorry, you don't have permission to access this page. [11:10] what's up? [11:10] mdz: I'll look into the headers [11:10] this was a security bug just filed [11:10] and I'm logged in [11:10] SteveA: any idea whether this changed recently? === SteveA looks [11:10] IIRC I could see security bugs a while ago [11:10] pitti: you (or a team you are a member of) needs to be subscribed to the bug [11:11] who is [11:11] mirko@pittschaft.net ? [11:11] jamesh: dooglus just filed that bug, but do people explicitly have to subscribe the security team? [11:11] pitti: you can see it now [11:11] but i am concerned that mirko@pittschaft.net has the launchpad name 'pitti' [11:11] i almost subscribed that person to the bug instead of you! [11:11] oouch [11:12] https://launchpad.net/people/pitti is pitti [11:12] https://launchpad.ubuntu.com/people/pitti <- me [11:12] right [11:12] interesting [11:12] i wonder why launchpad told me that mirko@pittschaft.net was pitti... [11:13] https://launchpad.net/people/mirko-pittschaft -> display name: "pitti" [11:13] BjornT: can you help answer pitti's question? [11:13] Kinnison: kamion filed a bug about it already, see slightly below that [11:13] thanks Kamion [11:13] i'll bring this up with salgado [11:13] jamesh: so, do people explicitly need to sub the security team? or will that happen automatically usually? [11:14] SteveA: ok, thanks Steve for handling that [11:14] mdz: thanks, Got that now [11:14] pitti: at the moment people need to subscribe the security team explicitly, yes [11:14] BjornT: ok, good to know for the future [11:15] BjornT: any plans to change that so that the security team for a distro is automatically subscribed to private bugs? [11:15] or something like that? [11:15] pitti: there are plans to have security teams subscribed automatically, i'll see if i can find a bug or spec that specifies it === pitti suggests ubuntu-security [11:15] that's a team I recently created [11:15] we should ask bradb about it later today [11:15] pitti: i don't think we have code to do this yet, but we'll check with brad later [11:16] ok, for now I assume that dooglus just subscribed 'pitti', which just caught the wrong person [11:16] pitti: no, dooglus didn't subscribe anyone [11:16] he just assumed it would work [11:16] I didn't subscribe anyone. [11:17] it told me I have to 'manually CC it' to the people I want to be able to see it. [11:17] that's why I asked who should see it [11:17] (which is a good assumption). it is ithat almost subscribed the wrong person [11:17] ah, ok [11:17] pitti, SteveA: https://wiki.launchpad.canonical.com/SecurityTeams, check with bradb about the status of it [11:17] I didn't assume it would work, either. I went to #ubuntu-devel asking who I needed to subscribe [11:17] Can somebody confirm, that Ubuntu bug 11200 wasn't moved over to Launchpad? At least, I can't find in searches. [11:17] malone bug 11200 in linux-source-2.6.15 "Therm modules fail to load on 1st gen powerbook G4" [Normal,Rejected] http://launchpad.net/bugs/11200 [11:17] dooglus: thanks for being a test guinea pig :) === dholbach strangles Ubu. [11:17] dooglus: okay. i would have assumed it would work :-) and been wrong. [11:17] I would never assume that anything to do with launchpad would 'just work' ;) [11:18] dooglus: harsh [11:18] just kidding [11:18] (me too) [11:18] dholbach: all better [11:18] jamesh: Woohoo! :) [11:18] Thanks. === mpt [n=mpt@219-89-129-190.jetstart.xtra.co.nz] has joined #launchpad [11:19] TimeOut. I have been unable to process your humor. Please report this failure in the form of a joke, which I will also fail to process. Code (435234). Thank you. [11:19] gargh. It recreated a bugs.gnome.org bugtracker :( [11:20] mpt: can you put a .css in your public_html on chinstrap, and ask jamesh to point the oops summaries at it. [11:20] then you can tweak the css independently. [11:21] oh, ok [11:21] i mean, an empty css file, or one containing just the css that james is currently using === mpt was just starting to tweak the Python-generated CSS [11:21] jamesh: is there a way to find out how many bug watches pointing to Ubuntu bugs were created before the migration? [11:21] dholbach: for future reference, the URL of bugzilla.gnome.org is not bugs.gnome.org [11:22] ... how do I put a file on chinstrap? [11:22] jamesh: do you think we need aliases for bugtrackers? [11:22] mpt: ssh [11:22] mpt: scp, rather [11:22] daf: there is a creation date in the BugWatch table [11:23] mpt: open a nautilus window, and choose "Connect to Server" from the file menu [11:23] SteveA, why wouldn't this CSS belong in the Launchpad tree? [11:23] jamesh: perhaps we can ask Stuart to find this out so we know how many bugs might not have been imported [11:23] mpt: because i want it to work right away [11:23] ok [11:24] james can sort it out in the launchpad tree afterwards [11:24] SteveA: aliases might be useful (especially if we start to automatically create bug watches from text more [11:25] the bug I raised and set to be 'hidden' now tells me "This bug has not yet been reported in malone (upstream). Do you want to report it?". is that asking me if I want to 'unhide' it? Or what is it really meaning? [11:25] Kinnison: ok. I guess prat can be handed back to elmo then. [11:26] SteveA: of course, having multiple URLs for a bug tracker isn't that great from the other end either. We ended up configuring http://bugs.gnome.org/ to redirect to bugzilla.g.o because of cookie issues [11:26] i see [11:28] stub: yes [11:28] jamesh: erm, wouldn't that involve changing a HUGE load of bug watches? [11:29] dooglus: it means that you looked at it from a URL that implied you were coming to it as a Malone bug, e.g. https://launchpad.net/products/malone/+bug/... [11:29] Kamion: that's exactly what I did. sorry! === stub [n=stub@gb.ja.98.136.revip.asianet.co.th] has joined #launchpad [11:29] dooglus: no need to apologise [11:29] Kamion: is there a URL I can use which implies I don't know what product or distro is it for? [11:29] dholbach: nah. I cleaned them up the majority after the migration [11:29] dooglus: since Malone bugs can be on more than one entity - so if you come at it from a URL that implies a different entity then it wonders if you might want it filed there too [11:29] dooglus: any suggestions on how we might improve the text you saw to make that clearer? [11:30] just "show me bug 12345" [11:30] jamesh: I see. [11:30] dooglus: https://launchpad.net/bugs/... [11:30] dooglus: /bugs/12345 [11:30] dholbach: the bugs I just imported referenced bugs.gnome.org again, so the duplicate bugtracker object got created again [11:30] dooglus: (yes, the UI is odd, though) [11:30] Ah, right. [11:30] that re-writes the URL [11:31] I want it to stay as "/bugs/12345" to I can easily remove the 12345 and put 23456 instead, without having to remove all that other stuff it's added to the URL [11:32] dooglus: if you are using firefox, create a bookmark to "https://launchpad.net/bugs/%s", and set the keyword to "lpbug" [11:32] dooglus: then you can just type "lpbug 1234" in the URL bar to go to the bug [11:32] I think the "This bug has not yet been reported in malone" message was particularly confusing since it *has* been reported in malone (since malone is the system which holds all the bugs). It just hasn't been reported *against* the malone *component* or some such. [11:32] jamesh, https://chinstrap.ubuntu.com/~mpt/oops.css [11:33] jamesh: good idea [11:34] dooglus: that's a good point [11:34] dooglus: could you file a bug against malone saying so? :) [11:34] SteveA, when you've finished reviewing SimplifyingMalone and FixingProjects, https://wiki.launchpad.canonical.com/DuplicateBugHandling is ready [11:37] daf: is malone an 'upstream product'? I thought it was internal? [11:37] malone is not free software, no [11:37] but we track its bugs in Launchpad [11:40] dooglus: in that specific case, "upstream" is a misnomer. But it's reasonable to expect that people filing bugs in malone know enough not to be confused by that. [11:40] s/in/on/ [11:41] "upstream" only makes sense if you happen to be downstream of the upstream === doko_ [n=doko@217.205.109.249] has joined #launchpad [11:41] jamesh: exactly [11:41] ddaa: I wouldn't make that assumption. when malone crashes it tells you to raise a bug against malone... [11:41] yeah [11:41] dooglus: we're changing that, i think [11:41] ddaa: that happens to everyone, doesn't it? or is it picking me out for regular special treatment? [11:41] there's a launchpad development meeting in 1 hour or so [11:41] mpt: thoughts on the term "upstream"? [11:41] and on the agenda is whether we should encourage people to file support requests rather than bugs [11:42] about problems with launchpad [11:42] daf, before I started working on Launchpad, I'd never heard the term "upstream" used about software [11:42] because often people really want to get on with using launchpad, and find a workaround [11:42] and as a secondary thing, want to get the underlying problem fixed [11:42] mpt: well, it's a term taken from Debian [11:42] what do you think about this, dooglus ? [11:42] mpt: it's Debian/Ubuntu jargon [11:42] daf, the question is not so much whether it's good or bad, as whether there's a better way of putting it [11:43] mpt: true -- my question should have been "can you think of a better way to put it?" [11:43] SteveA: last time I checked, the request tracker was essentially unusable. [11:43] for lack of email notifications [11:43] ddaa: and the reson for this is... [11:43] ddaa: that we don't use it! [11:44] nah, e-mail notifications are the chicken AND the egg [11:44] ddaa: but, do bring this up in the meeting [11:44] I actually suggested using it as part of the rcs import workflow at some point. [11:44] dooglus: no, it's not singling you out [11:44] dooglus: Launchpad is very egalitarian about OOPSing on people [11:44]