Team Chat Logs

March 25, 2010

2010 2
Mo Tu We Th Fr Sa Su
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
<< <   > >>

[00:00:14.075674]<wildintellect>can you do an svn checkout to see if svn throws any erros
[00:01:40.695699]<gregcoit>wildintellect: good question
[00:04:04.718669]<gregcoit>no errors - but it checked out version 549 and trac is complaining about 550 - can;t be a co-oincidence - I bet I need to import a new svn dump
[00:04:44.538203]<wildintellect>ya sounds like something went missing or a counter if off
[00:05:01.235065]<gregcoit>yeah
[00:05:05.147614]<gregcoit>trying that now
[00:07:04.663932]<wildintellect>worst case, try copying the svn directory verbatim with something like rsync don't even bother with svn dump
[00:08:39.135555]<gregcoit>kk
[00:11:21.756576]<gregcoit>wildintellect: we have a winner! Thanks for all the help!
[00:11:51.391778]<gregcoit>it was just saying that the svn version 550 was missing - must have read it in the attachments or something
[00:12:02.587101]<gregcoit>er, revision 550
[00:13:38.420436]<gregcoit>wildintellect: kk - past my bedtime - thanks again!
[00:14:06.805153]<wildintellect>so what was the fix?
[01:17:58.837863]<Sacho>from the tracupgrade wiki, trac-admin /path/to/projenv resync <-- there doesn't seem to be such a command
[01:18:15.782325]<Sacho>should it be repository resync?
[01:19:17.377279]<Sacho>oh, sorry, I was reading the wrong upgrade. :|
[01:26:32.205792]<otaku42>moin
[01:28:15.948497]<macmaN>coffee otaku?
[01:28:23.399821]<macmaN>we just got a new #trac cappuccino machine
[01:28:36.600099]<macmaN>TraccucinoPlugin will soon be on th
[01:28:57.900824]<macmaN>you will have timelineprovider for coffee beans level
[01:29:17.603696]<macmaN>patches welcome for milk and water levels
[01:29:43.344611]<otaku42>lol
[01:30:01.045195]<otaku42>macmaN: thanks, just got a coffee here, but will keep that option in mind for the afternoon
[01:42:40.789002]<Sacho>is there a script like the 0.11 that will add comments to tickets based on revisions?
[02:19:43.495027]<nascentmind>hi. when i put some macrofile.py in the plugins directory and when i use that macro i get an error no macro or processor. how can i fix it?
[02:22:15.801777]<kirean>nascentmind: depends on how the macrofile.py looks and in what plugins directory you put it in
[02:30:17.914782]<lelit>hi all
[02:32:15.028704]<lelit>does anybody have access to the t.e.o. errorlog? I'd like to know the details of an error I get when visiting random tickets, that I guess is related to me browsing the page with the italian language...
[02:32:43.186955]<lelit>it does not happen when I fetch the same page with wget...
[02:33:25.806193]<lelit>All I get is an InternalError, "IndexError: list index out of range"
[02:34:31.916473]<lelit>one example of it is on http://trac.edgewall.org/ticket/6353
[02:37:02.807692]<nascentmind>i had some errors in the macro which i fixed now.
[02:37:25.738383]<nascentmind>now i get it in the admin module and shows as enabled. but in the wiki i still get the same error.
[02:38:47.113327]<nascentmind>i checked the logs and i am not finding any problems
[02:48:34.084760]<nascentmind>can somebody help?
[02:50:50.130889]<lelit>oh, nice: following the adviced button to create a new ticket I get the traceback nicely formatted! Trac rocks :)
[02:54:31.733868]<kirean>nascentmind: can you pastebin the macrofile.py maybe?
[03:39:14.326991]<nascentmind>kirean, its the same as timestampmacro at the bottom http://trac.edgewall.org/wiki/WikiMacros
[03:39:34.882105]<nascentmind>kirean, http://trac.edgewall.org/wiki/WikiMacros#Macrowithoutarguments
[03:46:00.915298]<osimons>nascentmind: and [[TimeStamp]] won't then work? and trac debug loading shows that it loads the plugin, right?
[03:48:27.610367]<osimons>restarted web server to load the new code?
[03:55:34.470438]<nascentmind>osimons, yes
[03:55:43.114239]<nascentmind>osimons, i restarted my machine too :)
[03:56:43.196410]<osimons>nascentmind: heh. better safe than sorry... if it does not work, then there really should be some message from debug logging your trac project - you have enabled that, i presume? and can't find anything in your logs?
[03:56:44.297929]<nascentmind>osimons, i should be doing [[TimeStampMacro]] right?
[03:56:59.805505]<osimons>no. [[TimeStamp]]
[03:57:16.234547]<nascentmind>osimons, shouldn't it be the name of the module?
[03:57:28.978963]<osimons>The WikiMacroBase abstract helper class removes that before reporting
[03:57:55.297958]<osimons>nascentmind: so, yes you are correct. only the base performs some magic when the class ends with Macro
[03:59:01.098596]<osimons>been some time since i looked at the code, but it is in there somewhere - the base class is quite simple, so should be easy to follow what it does when you layer your timestamp macro code on top via inheritance
[03:59:11.729570]<nascentmind>ah ok. I had named my macro as TimeStampTestMacro. now i changed it to TimeStampTest. works now. thanks a lot.
[03:59:33.707578]<nascentmind>osimons, yes. was reading the code here and there. did not concentrate on this.
[04:00:13.827068]<osimons>nascentmind: no probs.
[04:02:57.875659]<osimons>nascentmind: http://trac.edgewall.org/browser/branches/0.11-stable/trac/wiki/macros.py#L41 - in your timestamp you can of course also override the name by implementing get_macros yourself - like def get_macros(self): yield 'NascentMind'
[04:05:32.972685]<nascentmind>osimons, i see the removal of the 'Macro' name alright :)
[04:06:20.382708]<osimons>simple mechanisms - once you are aware of them of course :-) good luck.
[04:37:04.689172]<nascentmind>osimons, where did the api docs go. I am not able to find it.
[04:39:41.383790]<nascentmind>want to see the details of formatter
[04:59:09.265693]<osimons>nascentmind: source and debugging - no api docs available, really. raise TracError(dir(formatter)) :-)
[05:00:16.043888]<nascentmind>:) hehe
[05:02:23.964069]<osimons>nascentmind: use self.log.debug() to print things to trac.log as you develop - usually the simplest.
[05:50:21.680322]<TinoW>hi
[05:50:28.079426]<TinoW>hmm: http://trac.edgewall.org/
[05:50:37.103404]<TinoW>(500 Server Error)
[06:14:21.073068]<otaku42>TinoW: works fine here.
[06:15:16.907904]<TinoW>otaku42: yes, now
[06:16:06.490084]<otaku42>TinoW: probably cboos was tweaking something again
[06:16:35.286686]<TinoW>otaku42: ok I see... actually I experienced this from time to time
[06:26:14.590696]<otaku42>trac-hacks.org is currently down, some issue with the server. i'm investigating
[06:27:01.223705]<jbergstroem>w
[06:27:04.174312]<jbergstroem>sry
[06:27:45.835914]<TinoW>otaku42: ok thx
[06:44:43.879249]<retracile>otaku42: good luck
[06:44:59.091374]<Sacho>Error: Failed to load processor CommitTicketReference <-- I get this error as a comment when using the ticket updater
[06:45:06.454566]<Sacho>Not sure what I messed up :|
[06:51:54.863574]<otaku42>retracile: thx
[07:56:43.727758]<rts>hi, good day everybody
[07:57:34.664498]<rts>I was currently looking into a plugin that would provide a new WikiSyntax using the IWikiSyntax provider and I have some problems with that
[08:00:22.183748]<bionoid>rts: What's your problem?
[08:00:57.000482]<rts>bionoid: well, basically, the plugin seems to be working fine but the output it generates is not in rendered representation of the page
[08:01:54.439482]<rts>bionoid: i added some logging to trac.wiki.formatter._markup_to_unicode and to HTMLFormatter as well as soon as the Formatter.format is through, the generated output is no longer there
[08:03:23.255604]<bionoid>rts: Show code
[08:03:28.458104]<bionoid>ie plugin
[08:04:04.277392]<rts>class ExternalLinkSystemWikiSyntaxProvider( Component ) :
[08:04:04.491281]<rts> implements( IWikiSyntaxProvider )
[08:04:04.517280]<rts> # IWikiSyntaxProvider methods
[08:04:05.348070]<rts> def get_link_resolvers( self ) :
[08:04:06.164857]<rts> return [ ( "ext", self._format_link ) ]
[08:04:07.145258]<rts> def get_wiki_syntax( self ) :
[08:04:07.347075]<rts> yield ( None, None )
[08:04:08.365555]<rts> def _format_link( self, formatter, ns, target, label, fullmatch = None ) :
[08:04:09.204525]<rts> buffer = StringIO()
[08:04:12.373359]<bionoid>Jesus christ, on pastebin
[08:04:20.504506]<rts>ups, sorry
[08:04:28.803389]<bionoid>;-)
[08:04:41.682791]<rts>bionoid: how would i do that? do i need an account for that?
[08:04:59.543454]<bionoid>rts: Well strictly you don't have to. Your problem is yield (None, None)
[08:05:24.276707]<bionoid>ie get_wiki_syntax should yield (regex to match, what to return)
[08:05:28.014612]<rts>bionoid: so i do have to provide a regular expression that would match the link syntax?
[08:06:30.233625]<bionoid>or at least I assume that is your issue ;-) However I have to run, will pastebin you a working wiki plugin first, one sec.
[08:06:32.005439]<rts>bionoid: it is basically an extended link syntax, such as [ext:wiki:FooPage]
[08:06:53.908910]<rts>bionoid: one moment i will give you a working template, one sec
[08:07:23.693544]<rts>bionoid: http://pastebin.com/9Pi6ZW1L
[08:08:21.989041]<otaku42>trac-hacks.org is back online again
[08:09:02.085441]<rts>great, was there a problem or did you a server update?
[08:10:41.633219]<bionoid>rts: ahh return should probably be yield though
[08:11:04.719536]<rts>bionoid: i will try that, ty!
[08:11:06.645264]<bionoid>I've never used the link resolvers, so don't really have a handy example for that. I'm sure you'll find some on t-h.o though
[08:15:09.585143]<rts>bionoid: i found a similar plugin on tho, and replaced yield (None,None) by return [] but still to no avail, will have to look more closer at the way the formatter works, ty!
[08:15:38.085791]<otaku42>rts: server was overloaded for more than 1 hour and was not accessible during that time
[08:16:16.504128]<rts>otaku42: did the bing bot rescan every page thrice a minute *g ?
[08:18:39.334905]<bionoid>rts: I mean replace return [ ("ext", self._format_link ) ] with yield ('ext', self._format_link)
[08:19:06.595136]<rts>bionoid: i give it a shot, thanks
[08:20:09.441372]<rts>bionoid: still same behaviour here, actually the _format_link method is being called and the debug log states that the formatter.format() also got a result from the link resolver but it will not write it into the output
[08:21:47.768106]<retracile>otaku42: :)
[08:23:56.012902]<rts>bionoid: odd, actually the log information for the output of the link resolver is written twice to the log file, will have to look into that further, hell just three lines of code and it takes me hours to get it working ;)))
[08:31:56.315050]<rts>bionoid: i think i found it, the formatter that is called in the plugin will output valid and well-formed html, however, when the original formatter is through, the closing </p> tag is removed from the output and so will the opening <p> tag and any elements below that
[08:44:22.626115]<rts>bionoid: it is now working, it seems that one must not use the Formatter.format or reuse the formatter argument for formatting the link, but instead must use LinkFormatter
[08:46:57.420864]<rts>bionoid: i've uploaded a corrected version on pastebin, see http://pastebin.com/AeJYYrKp
[09:05:54.698000]<gregcoit>wildintellect: the fix was that I had an hour old svn copy but a 1 minute old attachments dir - someone made a svn co in the period of time. :) that was the 550 error. As for getting trac working at all, I ended up doing easy_install - the rpm had some issue. thanks again for your help! i was a bit frantic. :/
[10:03:23.569329]<otaku42>FYI: xml-rpc access to trac-hacks.org is currently disabled, due to abuse by a spammer.
[11:39:23.940119]<exarkun>So, constant segfaults from trac
[11:39:29.439039]<exarkun>Just par for the course these days?
[11:39:52.630459]<exarkun>There was like one good week there when the upgraded version was basically working okay
[11:39:56.258664]<exarkun>Now, not so much.
[14:36:50.038173]<rts>is there a wsgi framework that would work in exact the same way as for example a jee container, perhaps we could move trac to something like that? as of now, every request will instantiate all the instances of the objects anew, any suggestions?
[14:37:56.912245]<rts>by instances of the objects i mean - main request handlers and extension point interface implementations and so on
[14:41:05.559774]<rts>i mean, that way we could be able to speed up trac's performance a lot, don't you think?
[14:47:13.749349]<osimons>rts: all new instances for every request? are you running plain CGI?
[14:47:52.414964]<rts>osimons: actually mod_python on apache, but according to the logs, everything will be rescanned and reinstantiated
[14:48:59.461320]<osimons>it shouldn't. must be your apache/mod config
[14:49:21.893676]<rts>osimons: any hints? i will post the current config on pastebin ;)
[14:49:47.995791]<osimons>pastebin, and i'll scan it quickly
[14:51:35.834846]<osimons>rts: actually, got another reason: are you on a recent trac version? does your trac log say why project gets restarted? when you said "according to logs" above, did you mean apache error.log or trac trac.log?
[14:52:21.509359]<rts>osimons: trac.log actually
[14:52:38.919218]<osimons>rts: then i suspect your apache is fine - here is what i think...:
[14:52:47.744513]<rts>osimons: http://paste.lisp.org/+22RN
[14:53:26.538308]<osimons>yeah, looks good. problem isn't there.
[14:54:08.128229]<osimons>some plugin or custom code you have touches the trac.ini (i suspect) - could you just follow timestamps on trac.ini and see if it updates last modified in line with new requests?
[14:55:23.730157]<osimons>badly written code that writes to config after environment reload, which subsequently causes a new reload, which prompts writing config again, and so on...
[14:55:40.388370]<rts>osimons: well i have the tracfullblog plugin and tracbacks plugin installed, but it will also reload the core trac wiki plugins and macros on every request
[14:56:08.970098]<osimons>it reloads the environment - which basically means all plugins available for the project
[14:56:46.776855]<osimons>however, the actual code is persisted in memory (mod_python persistence) so it is not as expensive as it sounds
[14:56:52.436119]<rts>osimons: yes, but that should be a one timer for the application, and not on every request
[14:57:04.069109]<osimons>rts: it certainly isn't fullblog plugin ;-)
[14:57:10.827374]<rts>;)
[14:57:49.659346]<rts>osimons: actually, there are some more, ctxtnavadd, keywordsuggest, themeengine, and that's it
[14:58:12.121939]<osimons>rts: did you read what i said above? some piece of code you have installed writes to config, and trac is hardwired to reload itsself (the "env" variable) whenever trac.ini is touched
[14:58:26.861381]<osimons>what is the timestamp on your trac.ini file?
[14:58:35.088099]<rts>osimons: yes I have read it, wait i will check
[14:58:38.241093]<osimons>and does it update itself automatically?
[14:59:02.910387]<osimons>(ie. as new requests are made?)
[15:00:02.128244]<rts>osimons: sry, but the time stamp remains the same: 2010-03-12 19:44 (prior to request) and 2010-03-12 19:44 (after request) - i waited a few seconds
[15:00:29.085265]<osimons>rts: do you have an inherited trac.ini (shared config)?
[15:01:01.651727]<rts>osimons: no, all instances have their own configuration and do not inherit from a shared configuration
[15:01:31.273615]<osimons>rts: i suggest disabling all plugins for the project, and then start selectively enabling them (or vice versa)
[15:02:31.000041]<osimons>make sure to restart apache between each test to clear everything before each test
[15:02:48.904043]<rts>osimons: the same thing happens when there is no third party plugin, trac will rescan all available extension point interfaces for the extension points on every request, perhaps the problem lies within the core.MetaComponent thingy?
[15:03:06.087393]<osimons>rts: what trac version?
[15:03:33.546199]<rts>osimons: 0.12dev latest rev from trunk from approx. 2010-03-23 or so
[15:04:03.025103]<rts>osimons: ups, not my currently installed trac, this is ubuntu with a few patches - lets seee
[15:04:40.976084]<rts>osimons: wrong, it was a late 0.12dev rev 0
[15:05:07.459025]<rts>osimons: installed via easy_install directly from the official repository
[15:05:37.784938]<osimons>rev 0 suggests setuptools/svn mismatch so that svn can't parse the repos revision, so can't really say which version you have.
[15:06:13.960217]<rts>osimons: anyhow, i noticed the same behaviour also with trac0.11 and previous versions
[15:06:56.962276]<rts>osimons: i think that the problem lies with the request dispatched which will reinstantiate the application on every request, or does it not?
[15:06:59.255771]<osimons>rts: so strange. it really, really shouldn't. and certainly not with 0.11.x (trunk i can't always vouche for)
[15:07:42.292263]<osimons>rts: perhaps "PythonDebug on" does that?
[15:08:37.011606]<osimons>nope - not important. it only passes errors to client.
[15:09:39.651801]<rts>osimons: well, i will deactivate that but i think that python webapps somewhat behave like for example php webapps or perl webapps...
[15:10:58.975239]<osimons>rts: nope, mod_python persists for the duration of the apache process. so the natural next check is your apache config, and if it somehow forks a new process for every single request?
[15:12:35.543090]<rts>osimons: heck, this increased response times in my local setting a lot, thanks for the hint. apart from that, trac.log still states (i have enabled debugging output on trac.ini) that it will reinstantiate all available plugins, i.e. loading them and so on
[15:12:50.626969]<rts>osimons: could this not be cached or something similar?
[15:12:58.446358]<rts>osimons: ty!
[15:17:28.776555]<rts>osimons: just rechecking: with debugging disabled at the apache config level, the reloading of plugins is also gone, thanks a lot
[15:17:50.172431]<osimons>rts: oh. goodie.
[15:18:49.246054]<osimons>i can't remember the details of that debug option anymore - been to long since i read mod_python docs...
[15:18:58.180431]<rts>osimons: so you are actually the author of the fullblogplugin ;)
[15:19:06.288204]<osimons>rts: indeed.
[15:19:17.667233]<osimons>isn't it just the best?!
[15:20:01.048523]<rts>osimons: well, i have a few usability issues with it and i actually do not blog, but otherwise it seems quite *erm* functional ;)
[15:20:19.362255]<rts>osimons: how about themeing individual articles or categories?
[15:21:02.941508]<rts>osimons: how about hierarchical categories, and what about a calendar view with individual dates being displayed as hyper links if an entry for that date exists?...
[15:21:16.258820]*osimons sighs... users...
[15:21:22.540664]<rts>osimons: lol
[15:22:18.907531]<osimons>categories are much like tags, and no hierarchy implied or expressed. calendar i rejected a long time ago - it is not a useful feature, trust me...
[15:23:17.354290]<osimons>rts: anyway, "patches welcome" as the open source mantra goes... :-)
[15:23:55.631264]<rts>osimons: categories, yes, they are much like tags, but what about rant/microsoft, rant/bashemall - which, when clicking on rant would list all of rant and when clicking on rant/bashemall would only list the articles in that subcategory?
[15:25:02.210170]<osimons>rts: think there is an open ticket for someone wanting to list more than one category at a time; like "/...../rant+microsoft"
[15:25:03.971139]<rts>osimons: uh, yes, if i would blog, i would definitely provide a patch ;) - just throwing in some ideas
[15:26:28.326896]<osimons>but then again, i also provide a tags provider plugin, so for those wanting advanced tag features and queries can just get that there - including the associated blog posts
[15:27:40.820772]<rts>osimons: i see that you are also the author of the xmlrpc plugin, ever considered sql injections?
[15:30:20.338181]<osimons>rts: "maintainer" - i kind of inherited it. but yes, it should be safe i think? at least newer (0.11) that I maintain use only common trac ways of doing things, so should be as safe as any web input.
[15:31:22.243697]<rts>osimons: i mean, in tracrpc/wiki.getPage the pagename is passed to the underlying WikiPage without checking whether there is some malicious sql statement in that string. or does WikiPage already prevent such malicious requests?
[15:32:07.237203]<osimons>rts: yes, the escaping happes at db level - when it looks for the corresponding db data
[15:32:56.233823]<osimons>and all db access is variable placement only - there is no direct string representation of the statement that gets executed
[15:33:21.387977]<rts>osimons: ok, then it should be safe - the reason for asking is that another rpc plugin on t-h-o did the queries all by itself and was open to sql injection
[15:34:05.886382]<osimons>got a reference?
[15:34:43.453498]<rts>cursor.execute("SELECT version,time,author,text,comment,readonly "
[15:34:43.656719]<rts> "FROM wiki "
[15:34:43.669577]<rts> "WHERE name=%s AND version=%s",
[15:34:43.682432]<rts> (name, int(version)))
[15:35:16.317919]<rts>so it would be possible for a malicous attack to delete everything in the database
[15:36:22.207971]<cmc>I thought cursor.execute cleaned that
[15:36:40.827745]<osimons>rts: not really. it is (stmt, args) - not (stmt % args)
[15:36:55.745388]<osimons>the db layer will join them in a safe manner
[15:37:51.853211]<rts>does sqlite and every other backend implemented for python actually prevent sql injections?
[15:38:07.426862]<rts>i don't know, i am a newby here
[15:38:14.477075]<osimons>if you find instances of stmt % args (ie. pure string substitution) you are correct though - that is not safe, and should be avoided if any part of the args can come from user input
[15:38:24.005289]<cmc>I think parameterized queries are standard
[15:38:51.188039]<osimons>yes, all trac db backends perform queries using parameters in a safe manner
[15:39:33.351666]<rts>ok, well, then a pagename like for example '';DELETE FROM wiki WHERE 1=1;SELECT FROM WIKI WHERE name='' would do no harm?
[15:40:13.711944]<cmc>should be fine
[15:40:21.994602]<cmc>bobby tables
[15:42:29.946872]<cmc>related: https://homebank.sactocu.org/UA2004/faq-mfa.htm#pp6
[15:43:28.462661]<rts>cmc: I do not see what this has to do with the rpc interface?
[15:43:40.236704]<cmc>sql injection
[15:44:42.459008]<cmc>"The answers to your Security Questions are case sensitive and cannot contain special characters like an apostrophe, or the words insert, delete, drop, update, null, or select."
[15:45:04.683644]<osimons>rts: would not be suprised if some of the code on trac-hacks use cursor.execute(statement % args) instead of (statement, args). the xmlrpc plugin should not (as far as i know), and nor should the trac code it uses.
[15:45:25.768318]<rts>cmc: yes, but this is about an online banking interface with a real user interface and human machine interaction, not about machine to machine interaction
[15:45:53.273020]<rts>osimons: so the answer is, actually, yes, that all db backends available will escape and filter?
[15:46:16.099233]<osimons>yes - if used correctly by plugins calling cursor.execute()
[15:46:32.322451]<rts>osimons: ok, i will try this at home;)
[15:46:40.881251]<osimons>rts: by all means do!
[15:47:34.777577]<rts>actually, if that is so, I am beginning to like python even a lot more
[15:48:00.614817]<cmc>(most languages have parameterized queries in their database drivers)
[15:48:39.123174]<osimons>rts: for the background, it is a design decision from early on in Trac: it should not be left to developer or user to escape/sanitize, it should be done automatically. same with html rendering in genshi - you never need to escape things yourself, all is automatically escaped by the templating engine
[15:49:10.948623]<rts>cmc: yeah, i remember java also provides parameterized queries, this remembers me of some of the optimizations i made for a current project of mine, will have to rethink ;)
[15:49:29.998396]<osimons>rts: python is great actually. and trac is very well designed, particularly the component infrastructure makes it a joy to work with.
[15:49:45.349251]<cmc>here here!
[15:50:06.934945]<rts>osimons: yeah I thought so from ground up, trac has a great code base, and a great architecture
[15:51:29.197886]<talley>I can only agree
[15:56:21.890723]<rts>osimons: for reference: it was http://trac-hacks.org/browser/tracdependencyplugin/0.11/tracdependency/xmlrpc.py
[15:57:31.406266]<osimons>right. that is wrong. see the string % substitution pattern? not good...
[15:58:24.668518]<rts>osimons: yeah, and the author then deactivated the code, perhaps we should go and provide him a hint on how to do it correctly?
[15:58:50.008660]<osimons>rts - nothing in a ticket for that?
[15:59:00.678280]<rts>osimons: http://trac-hacks.org/ticket/6381
[15:59:48.731963]<rts>osimons: actually, i suggested, not knowing that the db backends would prevent this, to filter any sql statements ;)
[16:04:22.302083]<osimons>rts: well, if you come from a java background then fire up a python console and you're an easy target... here is how to test what we just discussed - create a clean new trac environement/directory (trac-admin ./myenv initenv) and fire up python:
[16:04:32.996717]<osimons>>>> from trac.env import Environment
[16:04:48.807211]<osimons>>>> myenv = Environment('./myenv')
[16:04:55.885779]<osimons>>>> cnx = myenv.get_db_cnx()
[16:05:02.269712]<osimons>>>> cursor = cnx.cursor()
[16:05:29.465465]<osimons>>>> cursor.execute("select count(*) from wiki").fetchone() => (result: (111,))
[16:05:43.973863]<osimons>>>> cursor.execute("select * from wiki where name=%s", [";delete from wiki where 1=1"])
[16:06:06.978933]<osimons>- and running the count again should give you the same number of pages
[16:06:19.760092]<rts>osimons: thx i will try this
[16:06:47.480881]<osimons>try anything you like - except change the comma to %.... that should blast the table i guess.
[16:07:54.568243]<rts>osimons: ups, i made a patch to trac that is now preventing me from creating new environments, will have to rethink the patch once more, thanks for pointing out the bug ;))
[16:09:21.996252]<osimons>rts: patching trac will only get you in trouble...
[16:09:22.327669]<osimons>
[16:16:02.744039]<rts>osimons: just tried, works great, no data loss, sry for bothering you, but i learned a lot, thx
[16:18:01.787225]<rts>osimons: yeah patching trac - this patch was about preventing an exception being thrown when there is no valid environment, seems like that it requires some more work...
[16:18:11.465648]<osimons>rts: no probs. another simplifying aspect of substitution is that type does not matter - %s is used for everything, and the backend will convert it according to however the db defines the field
[16:18:29.938805]<osimons>>>> cursor.execute("select * from wiki where version=%s", [1]).fetchone()
[16:19:11.978068]<osimons>no need put %s in special '' containers or anything, all done as if by magic (which is how i consider it at least)
[16:19:36.115056]<rts>osimons: nice thing, i will redo existing plugins currently in work and will omit all ''
[16:25:35.073710]<osimons>rts: added my input to the ticket.
[16:26:01.019621]<rts>osimons: thanks!
[16:33:49.007522]<rts>gn8 everbody, nice talking to you, learned a lot, cya
[17:56:42.103094]<adam_vollrath>So we've got a Trac 0.9.3 install on RHEL 4 we'd like to migrate to a newer version of both Trac, Python, and OS. How far forward should we go?
[18:02:10.292650]<retracile>adam_vollrath: at work, we're running Trac 0.11.x on CentOS 5.4
[18:02:35.186132]<adam_vollrath>Well yeah that's the goal. I'm asking what the upgrade process will be like.
[18:08:00.314419]<retracile>adam_vollrath: It should be a trac-admin ... upgrade && trac-admin ... wiki upgrade. Emphasis on "should".
[18:08:27.744689]<adam_vollrath>should it be done in two stages, to 0.10 then to 0.11?
[18:08:58.643572]<adam_vollrath>I've skimmed the upgrade guides, that's the impression I've got.
[18:09:01.422668]<retracile>adam_vollrath: I don't think that should be necessary, but then again, 0.9 pre-dates my involvement with Trac.
[18:14:59.509136]<retracile>adam_vollrath: If I were in your shoes, I'd fire up a VM with RHEL5.4, Trac 0.11.7, and copy the Trac environment to it, try the upgrade, and test.
[18:15:31.525100]<adam_vollrath>Yes we're using VM's, and that's the plan.
[18:15:39.365075]<adam_vollrath>Thank y'all for your time.
[18:15:53.766744]<retracile>adam_vollrath: np; feel free to ask questions here
[18:16:09.700876]<retracile>adam_vollrath: I also try to monitor trac questions on SOFU.
[18:16:17.739929]<adam_vollrath>wats that?
[18:16:36.119302]<retracile>adam_vollrath: stackoverflow/serverfault/superuser
[18:16:41.502806]<adam_vollrath>ah rite
[21:34:57.080165]<tty1>hey guys
[21:35:54.856163]<tty1>so i just got spam attacked on my trac tickets..they left about 200 tickets in a matter of a day, way too much to delete by hand.. so i have two questions.. 1. how do i delete a range of tickets (the plugin im using right now does one at a time) and 2. how do i prevent such spam in the future?
[21:57:30.063864]<tty1>darn i guess you guys are EST/EDT people
[21:57:38.200839]<tty1>i was really hopping to reach someone today :(
[22:05:56.470632]<jesstess>tty1: is this useful: http://panyasan.wordpress.com/2008/05/23/how-to-batch-remove-spam-in-trac/ ?
[22:06:19.345086]<tty1>jesstess, let me check..
[22:11:00.166337]<tty1>jesstess, so far so good.. ill let ya know when its done
[22:12:55.225758]<tty1>jesstess, that worked, thanks
[22:17:18.019170]<jesstess>tty1: great!
[22:17:42.831526]<tty1>jesstess, i had 25,000 spam tickets waiting for me on one project i havent touched in a while
[22:17:52.485906]<jesstess>ouch
[22:18:16.114979]<tty1>jesstess, yea its gonna take over an hour to process that project id imagine