Team Chat Logs

January 17, 2010

2010 0
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
<< <   > >>

[02:22:22.856341]<djszapi>Can I update a plugin on trac-hacks.org if I added a new feature to it or I fixed a bug inside it ?
[03:07:58.252810]<dino4k>Hi. I've got trac (debian, trac 0.11.6) running via wsgi for some time and yesterday it stopped working. It complains 'Unsupported database type "sqlite"'. Importing trac.db.sqlite_backend works fine from terminal. Any pointers where the cause for this could come from?
[03:09:16.343121]<dino4k>just tested, running it with tracd works fine.
[03:11:30.969860]<djszapi>weird
[03:11:44.131618]<dino4k>indeed :)
[03:11:57.349663]<TheSheep>check what python is used by your wsgi
[03:12:14.304434]<TheSheep>your mod_wsgi
[03:12:18.017962]<djszapi>what does the apache/trac log say ?
[03:13:18.431891]<dino4k>i get a traceback http://dpaste.com/146383/ which mentions python2.5
[03:13:49.100816]<dino4k>so sqlite should be included :) Just to be sure installed pysqlite on its own as well, doesn't change something
[03:16:58.917486]<dino4k> apache's error log only mentions a 404 for the favicon :-/
[03:18:49.236825]<dino4k>TheSheep: mod_python/3.3.1 Python/2.5.2 mod_wsgi/2.5
[03:19:02.936237]<TheSheep>so my theory falls
[03:22:42.829828]<djszapi>hm
[03:25:07.993659]<djszapi>http://trac-hacks.org/wiki/TracTicketDepgraphPlugin
[03:25:12.512782]<djszapi>does this plugin work by you ?
[03:25:18.674158]<djszapi>I can't reach for it to work :(
[03:25:26.760015]<djszapi>it's a simple graphviz based plugin.
[03:25:33.099265]<djszapi>graphviz plugin works fine here.
[03:25:35.400268]<djszapi>any idea ?
[03:42:31.145528]<arnotixe_>hi all any hints on removing the red border of images in jbrout? I know that the red is caused by wrong exif info in the image, but I do not care much. I'm more upset about that red color...
[03:42:34.464226]<dino4k>DatabaseManager.connectors is [], where should the modules get loaded?
[04:35:50.771902]<gbot94>trac: Ticket #8974 (error: redefinition of group name 'it_changeset' as group 29; was group 18) created - <http://trac.edgewall.org/ticket/8974>
[05:22:36.037439]<erikp>doki_pen: sorry I'm answering after so long time. Yes, I know. Trac has no knowledge of branching and a ticket is not connected to a certain branch. Thus, the user of the systems really must handle the problem in an ad-hoc manner. I'm wondering if there are any preferred way of doing this. If there isn't a way of handling this, isn't this a weakness in trac?
[06:05:51.415736]<gbot94>trac: Ticket #8974 (error: redefinition of group name 'it_changeset' as group 29; was group 18) closed - <http://trac.edgewall.org/ticket/8974#comment:1>
[08:20:03.349850]<Moggie>hi, how does trac do its pagination? Does it pull only what it needs per page from the DB and renders that? Or does it pull the full result of the query and let the template system sort it out?
[08:28:24.884749]<scfe>Moggie: http://trac.edgewall.org/browser/branches/0.11-stable/trac/ticket/query.py#L258
[08:30:53.580207]<Moggie>If I'm reading that right, it pulls only what it needs per page then. thanks.
[08:32:38.959329]<Moggie>It makes sense... would be horribly slow doing it the other way around trying to handle hundreds of rows.
[08:32:49.841937]<Moggie>Just gotta find a neat way of doing that in my app then.
[08:50:32.633222]<Sacho>Eh, tradeoff
[08:50:48.624731]<Sacho>it'd be slow for the first page, but if the user lingers and clicks around, several page refreshes and db queries may end up slower.
[08:56:05.090418]<Moggie>yeah
[08:56:15.735772]<Moggie>still use a lot less memory i'd have thought though?
[08:56:41.090173]<Moggie>guess would also only help if the data was being cached?
[08:57:47.661654]<Sacho>I actually haven't seen a paginator coded to what I said, since then you'd need a JS side to flip the pages :)
[09:05:23.141934]<Moggie>Oh do you mean like sending the query result client-side?
[09:11:37.847617]<Sacho>Yeah
[09:11:45.988850]<Sacho>That forces JS usage though.
[09:20:45.072475]<Guest43654>A little late to the party, but there's a whole bunch of JS stuff that deals with client-side pagination, in fact was one of the first things AJAX became popular for. Just google ajax pager
[10:04:56.984672]<TheUni>i'm using a mysql db with apache.. when i browse changesets the mysqld process ramps to 100% on one core. anyone seen this before?
[10:05:13.538884]<TheUni>it's a reasonably powerful (8-core xeon) machine
[10:07:03.793538]<doki_pen>erikp: I think so. Something like tigit would be nice.
[10:07:57.228882]<doki_pen>erikp: I wonder if it could be done with svn props. You could make a trac plugin for a front end to the svn tickets. It would be a major effort though, and it wouldn't translate to other scms
[10:12:41.348160]<doki_pen>@Logging
[10:12:41.365288]<evil_twin>Logging is http://trac.edgewall.org/wiki/TracLogging <-- Enable debug logging to file, ensure your environments log/ directory is writeable by your web server user, check for errors.
[10:27:20.797567]<TheUni>hmm, getting internal server errors when browsing svn revisions, though all seems fine from the website
[10:27:31.896559]<TheUni>shall i file a bug?
[10:29:41.807715]<scfe>TheUni: First, check why the exception happens. So get the exception name+stacktrace first. Maybe it's not trac's fault.
[10:30:38.563696]<TheUni>scfe: http://pastebin.ca/1754929
[10:33:02.181069]<scfe>TheUni: To me it looks like there is more behind it. trac can not write the data to Apache. How did you integrate trac? mod_python, mod_wsgi?
[10:33:10.685851]<TheUni>wsgi
[10:35:11.261500]<TheUni>scfe: it happens randomly.. maybe 1 out of every 20 times
[10:36:34.220977]<scfe>I guess that it takes too long to send the answer and wsgi does not wait long enough... I think you need to check mod_wsgi to fix that problem...
[10:36:44.476551]<scfe>search for timeouts or something like that
[10:36:57.400531]<scfe>However it can be a bug in trac, don't want to rule that out completely
[10:37:30.438405]<TheUni>scfe: is it normal when using mysql to have very high cpu usage when accessing? seems there may be some deeper underlying issue
[10:37:47.261611]<TheUni>pretty much pegs one core
[10:38:24.461809]<scfe>TheUni: I don't use trac+MySQL - actually IIRC MySQL support in trac is still declared as 'experimental'.
[10:38:45.400285]<TheUni>scfe: i thought it was official as of .11.5 or 6
[10:38:50.976785]<scfe>did you have trac+MySQL working already? Including code browsing?
[10:39:15.769603]<TheUni>scfe: yes it all works fine, just migrating to a new site because performance is so bad. trying not to get into the same situation again
[10:39:35.916840]<scfe>otherwise it could be that trac needs to resync the svn revisions into the db which can be an expensive operation-
[10:39:52.901536]<TheUni>that part seems fine
[10:41:06.115363]<TheUni>scfe: http://tractemp.xbmc.org/
[10:41:14.634696]<TheUni>everything's fully functional, just performing terribly
[10:42:09.622540]<scfe>TheUni: Doesn't look too bad to me.
[10:42:43.767704]<scfe>do you have problems for a specific page?
[10:42:56.822582]<TheUni>scfe: like i said, performance on the site is fine. but trac is one of many services that machine runs, and the resources it consumes are rather unacceptable
[10:43:36.459464]<TheUni>having mysql pegged 24/7 isn't exactly optimal
[11:03:37.166052]<TheUni>http://trac.edgewall.org/ticket/6986
[11:03:42.143103]<TheUni>that made a significant difference
[11:25:12.469592]<TheUni>is anyone still looking into that? i'm not sure if it's bad form around here to bump a ticket or not
[12:03:38.763372]<kifkif>Hi, I was wondering what trac was usinng to make side by side diff ?
[12:50:54.010659]<Tomcat>Hi all, I've a question about accessing an svn repository when I don't have the exact svn link, but google is showing me trac.site.com
[12:51:21.336277]<Tomcat>Is there a common svn link format for trac?
[12:59:45.535441]<wildintellect>svn.site.com is pretty common
[13:04:52.840019]<Tomcat>hmmn... thanks.
[13:06:58.283826]<Tomcat>I'm seeing trac.site.com... found a google result for cia.vc which seems to be a listing of open source projects (with a bad security cert) but I can't find any more info than listings of commits...
[13:07:27.827681]<Tomcat>which is why I'm now hunting for the svn repository...