Team Chat Logs

May 11, 2010

2010 4
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:37:50.564578]<vlt>Hello. I didn't get an email notification for my recent changes on a ticket (#5475). Is it because I don't get notifications for changes I did myself? Or are there no notifications sent when files are attached?
[02:38:18.018059]<vlt>The latter would mean that nobody on the Cc list gets notifications, right?
[02:40:52.158682]<hasienda>vlt: hello, right, nobody gets notification about added attachments.
[03:23:14.715998]<vlt>In 0.12dev users w/o MILESTONE_VIEW get the /roadmap link anyway. Is this on purpose?
[03:57:35.342402]<luckymurali>Hi all
[03:57:53.728582]<luckymurali>Im using ubuntu 10.04
[03:58:00.976563]<luckymurali>I installed trac
[03:58:15.907422]<luckymurali>but Im not able to get the file trac.cgi
[03:59:37.025186]<luckymurali>any ideas??
[04:40:43.881495]<thm>luckymurali: trac-admin deploy will create one for you
[04:43:17.380882]<luckymurali>thm, ok thanks
[06:44:46.249233]<Wombert>hi guys
[06:44:55.710683]<Wombert>I'm seeing intermittent lags on http://trac.agavi.org/
[06:45:10.914747]<Wombert>resources like roadmap.css or query.js will take ~20s before they start downloading
[06:45:18.504468]<Wombert>it's pretty weird
[06:45:27.533613]<Wombert>the actual pages are rendered blazing fast
[06:45:35.125436]<Wombert>but related resources often don't download
[06:45:36.184475]<Wombert>any ideas?
[06:46:19.312380]<slam>Wombert: server not responding
[06:46:27.548625]<Wombert>yea...
[06:46:32.891915]<Wombert>it'll be back shortly
[06:46:35.918900]<Wombert>pretty weird overall
[06:46:42.737895]<Wombert>http://www.agavi.org/ is quick tho
[06:46:52.033602]<Wombert>running on the same box
[06:47:29.154025]<Wombert>load is also pretty low
[06:47:30.806593]<Wombert>0.2 or so
[06:49:19.478794]<Wombert>occasionally, apache2 processes will pop up, eating a little CPU time, then the whole box is back to idle
[06:49:33.093049]<Wombert>now again
[06:49:37.226848]<Wombert>it's loading forever on e.g. https://trac.agavi.org/chrome/common/dots.gif
[06:49:44.604995]<slam>yep
[06:50:00.248468]<slam>did you try to restart the database?
[06:50:17.596103]<Wombert>which mostly loads very quick, but then sometimes hangs
[06:50:20.571916]<Wombert>it's sqlite AFAIK
[06:50:27.700142]<Wombert>yea it is
[06:50:56.477638]<slam>logs telling you anything?
[06:52:08.024717]<Wombert>not really
[06:52:09.646751]<Wombert>2010-05-11 15:49:53,878 Trac[main] WARNING: HTTPNotFound: 404 Not Found (No handler matched request to /favicon.ico)
[06:52:11.514904]<Wombert>on occasion
[06:52:18.247346]<Wombert>that's probably MSIE
[06:52:42.863103]<Wombert>I already fixed that particular problem by putting a favicon.ico in chrome/site and configuring it in trac.ini
[06:52:55.231735]<Wombert>but IE always grabs the favicon from /
[06:53:09.035304]<Wombert>I suppose that *can* be a problem, since it also introduces a bit of concurrency
[06:53:15.400694]<Wombert>where a full blown trac request is dispatched
[06:53:20.794361]<Wombert>just to render the 404 page
[06:53:42.293258]<Wombert>but trac also serves all the stuff from /chrome, right?
[06:56:42.988703]<slam>right
[06:56:57.245492]<slam>this is not the source of your problem
[06:57:16.604693]*retracile grumbles something sarcastic about mornings.
[06:57:48.654303]<slam>Wombert: did you check the trac logs, too?
[06:58:01.025434]<Wombert>that was from the trac logs, slam :)
[06:58:08.235259]<slam>ah :-)
[06:58:32.911600]<Wombert>the server is virtualized
[06:58:35.718542]<Wombert>on VMWare
[06:58:45.839735]<Wombert>it used to have too little RAM assigned, so it started swapping like crazy
[06:58:50.436137]<Wombert>but that problem has been remedied
[06:59:13.364512]<Wombert>dots.gif for instance would not load, or hang forever
[06:59:23.561127]<Wombert>simply refreshing one or two times loaded it just fine
[06:59:56.007520]<Wombert>we're using mod_python, if that helps at all
[07:00:12.842359]<Wombert>and two vhosts for SSL and regular HTTP
[07:00:24.999777]<Wombert>could there be some sort of concurrency issue there?
[07:00:33.089920]<Wombert>should we instead proxy HTTPS requests or something?
[07:00:53.845478]<Wombert>although I think we've had the problems before we even enabled HTTPS...
[07:01:17.402448]<slam>sorry, need to run. hope you find help
[07:03:04.263185]<Wombert>np
[07:03:07.127960]<Wombert>bai :)
[07:09:48.710121]<Wombert>slam: found http://groups.google.com/group/trac-users/browse_thread/thread/dfbcdeb79a7db6c1
[07:09:50.572632]<Wombert>trying now...
[07:14:17.859629]<macmaN>soo...
[07:15:01.553364]<macmaN>it would appear no plugins on TH are using with_transaction yet
[07:15:06.545266]<macmaN>too new?
[08:21:15.870034]<webczat>Hey.
[08:22:24.092853]<webczat>Is it possible to configure trac with account manager plugin, and apache, so that all users with developer permission group can automatically access a git or svn repository? i meant write access.
[08:28:01.897429]<cmc>Trac doesn't control the subversion or git repo
[08:29:18.701307]<webczat>yeah
[08:29:39.026043]<webczat>but is it possible to connect apache's auth to the trac's permissions or groups or both?
[08:29:45.254835]<webczat>without code changes
[08:30:09.609514]<Sacho>you could use the same auth you use for svn for trac
[08:30:42.610016]<cmc>I don't think it's editable from within trac, then, though
[08:30:48.497926]<webczat>but i can't control who from the user list can access and who can't. i don't make all registered users have write access
[08:31:48.329980]<webczat>and i want to restrict that so that i can add permission from trac level
[08:32:14.945373]<webczat>and add an extra permission in trac config or use group name
[08:34:40.118775]<webczat>it means it can be the permission store that is somehow apache-compatible or reversed, the apache writing to the sqlite db
[08:35:12.432748]<webczat>second one doesn't have a module in apache. what about first one?
[08:35:35.210699]<webczat>is it possible with trac without making a new permission store?
[08:37:30.104092]<cmc>I'm not aware of an existing means
[08:37:52.599245]<webczat>i mean
[08:38:19.341385]<webczat>i want to have an easy repo management/repo access management from trac. i saw things trac can do with repos so i just want them instead of gitorious
[08:43:56.017610]<techtonik>It is possible to customize auth store for AccountManager that it will also write permissions that SVN understands. Or make post-commit SVN script that can make a lookup to trac DB (trac-admin envpath permission list user).
[08:44:14.785885]<webczat>it is git at first
[08:44:29.713940]<webczat>at second
[08:44:37.888912]<webczat>if i will write an update hook
[08:44:46.834919]<webczat>then how i'll know what user writes?
[08:45:02.996660]<webczat>if i'm using webdav for http
[08:46:13.070587]<techtonik>I didn't get that question.
[08:48:43.674733]<webczat>how i can know what user does update?
[08:49:26.373027]<webczat>update is git push
[08:54:08.405289]<techtonik>If it is unrelated to permissions problem, then you need to setup notification in Trac and it will notify you about new commits in configured repository.
[08:56:10.406956]<webczat>techtonik: it is related to perm problems
[09:00:27.964511]<techtonik>Then I don't get the question. Can you describe it once more from the start in more concise form.
[09:00:29.784735]<techtonik>?
[09:01:22.070801]<webczat>git has a hook script named update fcalled while doing git push.
[09:01:32.351474]<webczat>can be used for some checkings, and also for access control
[09:01:51.560931]<webczat>but how the script can determine what user does git push?
[09:13:16.127081]<techtonik>You'd better ask git folks if it is "git hook script". In SVN hook script receives all necessary information about author and other fields that you may use further to make lookups to Trac.
[09:42:19.980123]<Wombert>fixed it!
[09:42:20.581929]<Wombert>whee
[09:42:57.785826]<Wombert>using Alias /chome/(.*) to serve all static files through Apache directly
[09:43:05.834516]<Wombert>that got rid of most of the hangs
[09:43:31.391330]<Wombert>because sub-requests for images, css or js would go through mod_python
[09:43:33.139561]<Wombert>no more though
[09:43:36.799145]<Wombert>however... question
[09:43:54.082922]<Wombert>I have trac on :80 and on :443
[09:44:08.089417]<Wombert>is there anything special to pay attention to when configuring these two vhosts with mod_python?
[09:44:18.141170]<Wombert>will there be race conditions and whatnot under normal circumstances?
[09:44:27.651229]<Wombert>could this be one of the reasons why http://trac.agavi.org/ is slow occasionally?
[09:44:53.810350]<Wombert>got two vhosts with two <Location /> sections each
[09:45:14.580522]<Wombert>each has
[09:45:14.869418]<Wombert> SetHandler mod_python
[09:45:15.118098]<Wombert> PythonHandler trac.web.modpython_frontend
[09:45:15.285406]<Wombert> PythonInterpreter main_interpreter
[09:45:17.203564]<Wombert>and some other stuff
[09:45:40.186845]<Wombert>is this a problem if both the :80 and the :443 vhost are pointed at the same trac instance like that?
[09:45:46.866307]<Wombert>using sqlite if that makes any difference
[09:46:03.938093]<cmc>shouldn't be, no
[09:46:10.470012]<slam_>should be ok
[09:46:18.406661]<slam_>we do the same on several big sites
[09:46:35.245628]<Wombert>I figured that that might spawn two trac instances or something
[09:46:44.872621]<Wombert>who then get in each other's way with locks on the db or whatever
[09:47:12.912508]<Wombert>http://trac.agavi.org/ is now quick for *most* requests, but still hangs from time to time
[09:47:15.699929]<Wombert>odd :<
[09:47:37.166411]<Wombert>should I try mod_python -> fastcgi first, or sqlite -> mysql?
[12:40:55.149554]<hasienda>macmaN: arround?
[12:41:07.567385]<macmaN>yeah
[12:42:04.311063]<hasienda>macmaN: well, so I'm curious, if you had the time for looking into the i18n/l10n cookbook for plugins?
[12:42:14.567568]<macmaN>no not yet
[12:42:18.689349]<macmaN>probably no before thu
[12:42:29.448202]<macmaN>i mean ive skimmed through it
[12:43:01.597502]<macmaN>but havent gotten around to implementation
[12:43:31.968730]<hasienda>macmaN: ok, np, cboos recently did a lot of improvements, so it should serve quite well already
[12:44:11.965669]<macmaN>yes im keeping on top of that with rss
[12:45:00.667198]<hasienda>macmaN: I still see an issue with contributing translated catalogs, or better, how maintainers could organize to get their plugins localization done.
[12:46:53.604374]<hasienda>macmaN: but since I read about Trac preparing to re-organize after translation experiences made since 0.12dev, this could (should) be solved same way, I guess
[12:48:55.045669]<osimons>hasienda: big problem, really... it is the one major reason i don't feel a sense of urgency with regards to i18n. like my fullblog plugin for instance, i can translate it to Norwegian but after that who knows?
[12:50:48.028990]<osimons>- and when I get a translation i don't understand, do i just add it hoping for the best? what if the translation is like swedish chef from muppet show? or just endless streams of foul language and spam? oh, the possibilities for those really wanting to cause trouble....
[12:53:56.652569]<macmaN>:)
[12:53:58.707611]<hasienda>osimons: well, certainly valid warnings, I guess, we need to streamline this somehow, ideally use the existing language groups as for trac core
[12:54:12.988036]<macmaN>guys i have something easy for you
[12:54:25.720929]<macmaN>why i cannot put a tag.a inside add_notice
[12:54:29.853390]<macmaN>it gets sanitized
[12:54:51.109123]<osimons>macmaN: Markup(tag.a()) - if you know the content is safe, of course
[12:55:02.353655]<macmaN>i want to put a href link into add_notice
[12:55:05.314689]<macmaN>i do
[12:56:08.748688]<macmaN>osimons: hah, i knew it was easy :) thanks
[12:56:10.431424]<osimons>if content gets created just by you and not from any part of user input or creation, then by all means use Markup() to mark it as markup that should just pass through
[12:56:14.696791]<macmaN>it worx
[12:57:04.536436]<osimons>goodie.
[13:01:32.250280]<rts>hi all
[13:01:43.883845]<hasienda>osimons: translation is fun, to see even plugins getting displayed in you native language just after writing some lines into a message catalog an compile. Wonder, if we could use more of Transifex infrastructure by adding plugin POTs as Trac components i.e.
[13:02:35.973896]<hasienda>rts: hello, and great move to document extension points
[13:02:51.223734]<rts>hasienda: thanks, but still a long way to go for...
[13:03:32.549027]<rts>hasienda: what is Transifex?
[13:04:17.514627]<rts>hasienda: btw thanks for correcting the template
[13:04:54.477503]<hasienda>rts: some translation group coordination site: http://www.transifex.net/projects/p/trac/c/default/
[13:05:48.734977]<hasienda>rts: oh, the template, well had a hard time finding real bad things to improve ;-)
[13:06:20.456552]<hasienda>rts: was already quite good in the state I found it
[13:07:30.362464]<rts>hasienda: well, personally I think that before we go on documenting the extension points based on that template, we should fixate it so that we can be sure that we do not have to tough the actual documents again (sigh - my templating system is still under development...)
[13:08:27.227948]<rts>s/tough/touch/
[13:08:27.237683]<evil_twin>rts meant: hasienda: well, personally I think that before we go on documenting the extension points based on that template, we should fixate it so that we can be sure that we do not have to touch the actual documents again (sigh - my templating system is still under development...)
[13:09:18.694783]<hasienda>rts: read about this, but will have to find out more to get a clear idea about what's behind
[13:09:45.199748]<rts>hasienda: how is your extension regarding custom time fields going? is it stable by now?
[13:10:40.165067]<hasienda>rts: I'd still say beta, since there was no external review by now
[13:11:50.928915]<rts>hasienda: shame on me, too. I did not look into this after having lost the checkout (checkouts to /tmp are evil ;) - but i will definitely give it a try - have you updated the documentation in the wiki by now, so that newcomers like me get an easy start with this?
[13:12:24.918418]<hasienda>rts: however I use it in production an it seem like I have to catch only some 2-3 more little bugs while the input and storage is quite usable yet
[13:12:41.472582]<rts>hasienda: great
[13:13:25.244521]<hasienda>rts: hey the docu. no, will have to add about that findings with mercurial on ubuntu
[13:13:37.514926]<hasienda>rts: glad you remind me, so.
[13:13:53.868903]<rts>hasienda: i could do this for you, if you want me to
[13:14:27.453423]<hasienda>rts: sure, you're welcome to write it down.
[13:14:50.209776]<rts>hasienda: k, i will do
[13:15:31.662208]<hasienda>rts: that wiki page could only profit from other contributions than mine, 35+ versions just me, me, me ;-)
[13:15:54.538743]<rts>hasienda: back to transifex - just looked over the site and I still wonder how trac could benefit from it, seeing no information on how the translations will be merged back into the original repository?
[13:16:46.825551]<hasienda>rts: good point. now this is just handwork, but could be setup to go into a (dedicated) repo directly
[13:16:52.727770]<rts>hasienda: given that trac dev has its own schedule and write access to the trunk is not granted to everyone
[13:17:12.334665]<rts>hasienda: sure, more like patch delivery, or something like that, based on for example hg?
[13:18:46.181357]<rts>hasienda: perhaps the project maintainers (rblank?) could contact the site owners on how to incorporate the provided translations into the original trunk...
[13:19:41.268102]<hasienda>rts: wonder if this would be the way to go for plugins, or do on a sub-repo of trac-hacks.org i.e. for a test case
[13:20:15.714393]<hasienda>rts: this would clutter Trac repo considerably, I guess
[13:21:13.084850]<hasienda>rts: there are already quite a lot l10n related commits there, without the plugins
[13:22:22.885967]<rts>hasienda: perhaps moving out the translation stuff into a separate, hg based repository would do the trick. however, this would mean that a maintainer for the translations must be available, or rather for each translation a separate maintainer...
[13:23:28.336791]<rts>hasienda: however, that would require yet another maintainer for merging things back to trunk...
[13:23:47.593231]<hasienda>rts: I'd rather stick to a coordinator per language, like now for Trac, could even be the same, since
[13:24:24.508523]<hasienda>rts: actual translation work could be done by some others, like we do for German right now.
[13:24:41.312146]<rts>hasienda: so the coordinator would be responsible for accepting the patches coming in from the other site then...
[13:24:47.376835]<rts>hasienda: nice
[13:25:48.696687]<rts>hasienda: TransiFlex -> Patch -> Repository -> Coordinator -> accept/reject -> merge to trunk on accept or something like that?
[13:26:21.306476]<hasienda>rts: quite like that, indeed. :-)
[13:27:42.087750]<rts>hasienda: now, if the main trac project managers and committers would comment on this and find out if it is possible with TransiFlex, then trac would definitely benefit from it, as well as the distributions including trac as a default or optionally available package
[13:28:54.891179]<rts>hasienda: ups it is transifex...
[13:29:59.085650]<rts>hasienda: on the "tour" i see now that it supports a variety of repository types, so that issue can be solved with rblank and cboos both having local or public mercurial repos
[13:30:36.196911]<hasienda>rts: thinking especially about distribution, I wonder
[13:31:09.857040]<rts>hasienda: as for plugins, perhaps trac-hacks could make available that individual projects opting in for transifex, perhaps we should make a call on this, too?
[13:32:00.011560]<hasienda>rts: if it's possible to pull in all available translations on installation/update of plugins in a generic way, like easy_install for message catalogs.
[13:32:51.808685]<hasienda>rts: trac-hacks, yes, that was, what I was thinking before as well
[13:35:09.332979]<rts>hasienda: so we would have to gather a community around trac and transifex that would a) deliver required translations and b) review translation efforts... i wonder who could do that, with none of us being affiliated with the existing trac project other than by providing patches...
[13:36:20.692914]<hasienda>rts: there are translation groups with Transifex for Trac already
[13:37:13.154116]<rts>hasienda: one problem solved, transifex gathers the translation community and provably also the reviewers... but it requires trac translation coordinators to review the translations I presume
[13:37:15.075582]<hasienda>rts: and coordinators with commit access to Trac SVN, again I would support a separate repo for that, as said before
[13:38:26.147354]<rts>rblank: still on? if so, what do you think of hasiendas suggestion of out-sourcing the translation effort to Transifex? (provided that the service will be of no cost for the project in the future)
[13:43:14.245584]<rts>rblank: escpecially in regard to Xfce (on the "our work" page) having already out-sourced the translation effort to Transifex?
[13:43:46.473215]<rts>and fedora of course ;)
[13:55:28.209191]<ironi>hi
[13:55:59.834782]<ironi>i have a weird problem, it seems trac is logging to my defualt apache logfile in debug mode
[13:56:19.530034]<hasienda>@logging
[13:56:19.546221]<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.
[13:57:21.265731]<ironi>well i have set logging to a specific trac.log which works fine, if i set it to debug it does that, if i set it to warn its also ok. but for some reason trac is logging debug level to the system default apache error.log
[13:57:37.287331]<ironi>i have not set this up anywhere, its just crazy.
[14:00:51.395622]<ironi>spent hours to find the problem, i assume trac does not log in debug level by default if ntohing else is setto the system default apache log
[14:04:01.757627]<rts>ironi: basically, trac itself controls where log ouput is being written to, see the logger implementation, on my system which uses default settings for the apache site/virtual config it will work as expected
[14:04:52.542910]<ironi>rts: well it does log to the log file I have set in the global-trac.ini and in the level i have chosen, but in addition it logs in debug level to system default apache log file - it makes no sense :/
[14:05:31.009359]<rts>ironi: oh well, i see
[14:05:41.072002]<rts>ironi: lets check my log files then ;)
[14:06:16.197387]<rts>ironi: no entries of trac whatsoever
[14:07:43.363797]<rts>ironi: have you enabled PythonDebug for your location in the apache config file?
[14:08:44.332430]<ironi>rts: never used that, no.
[14:09:23.980176]<rts>ironi: beyond me, since i use a standard configuration here and it works for me
[14:09:28.971434]<ironi>the log file also seesm to tell me that it basically loads all kinds of trac modules i dont use as well
[14:09:37.795557]<ironi>postgres,mysql,sqlite for example
[14:09:40.009529]<ironi>seems crazy
[14:09:47.953212]<ironi>[Tue May 11 23:07:15 2010] [error] DEBUG:/var/moodcase/trac/template:Loading trac.db.mysql from /opt/moodcase/lib/python2.5/site-packages/Trac-0.11.4-py2.5.egg
[14:09:54.601013]<rts>ironi: in the trac.log or the apache log files?
[14:09:57.753121]<ironi>thats a loine from the log
[14:10:06.793407]<ironi>its in the system default apache error.log
[14:10:16.665859]<ironi>not in the one specified for my vhosts or in the trac.log
[14:10:38.328456]<ironi>and as you can se the debug is preceded by error
[14:10:45.535710]<ironi>so it seem slike apache thinks its an error
[14:10:52.623717]<ironi>thus logs it
[14:11:25.501138]<Aranel>Can I use trac with another language? I've found the patch, but don't know how to apply :/
[14:12:41.254738]<rts>ironi: well, afaik it simply states that the mysql backend could not be instantiated since you have no mysql installed, right? so, this is actually a python debug message that is being posted to your apache log file...
[14:13:30.131010]<ironi>hm, so python debug should be enabled somewhere? but if not in the trac.ini then where...
[14:14:17.996461]<rts>ironi: actually the PythonDebug option should be set to 'off' in your configuration. Don't know if it is 'on' by default, though
[14:15:37.917400]<rts>ironi: but then again, i have never had such an entry in the error log, so perhaps I might also be wrong in assuming that this would be the cause... perhaps you give it a shot and then report whether or not it solved your problem...
[14:19:46.075560]<ironi>nah, apache ddint even understand the directive
[14:19:49.375112]<rts>ironi: postgresql, sqlite and mysql are the only backends currently supported by trac (just read your post above), so how do you figure will trac store its wiki/ticket data?
[14:19:57.627142]<ironi>im running mod_wsgi not mod_python
[14:20:23.998770]<rts>ironi: you need at least one of the aforementioned backends being installed
[14:20:51.287984]<rts>ironi: and you will have to configure trac.ini so that it will use a database connector of the type that you have installed
[14:20:54.088585]<ironi>rts: I ma running postgresql...but it seems ot load alla backends....but that doenst matte,r the main problem is that debug level output is coming out into the apache error log as error
[14:21:21.339349]<rts>ironi: it will always load all backends, since that is the way the extension system works
[14:21:39.766982]<ironi>rts: ok
[14:21:57.476427]<rts>ironi: in your virtual server's configuration, (and i am not using mod_wsgi here) you have a location entry, do you?
[14:22:55.147017]<rts>ironi: in my configuration it states <Location />....</Location>
[14:23:30.376776]<rts>ironi: and this is where the actual handler for the python backend is declared. in here I also have PythonDebug off
[14:24:26.620379]<ironi>rts: no, i dont, i have a WSGIDaemonProcess directive n the file, thats stands alone
[14:25:04.178002]<ironi>and then some WSGI directives inside the virtualhost part
[14:25:41.337536]<rts>ironi: like I said, for now i still have not tried WSGI, so that is actually beyond my knowledge...
[14:26:17.713583]<rts>ironi: and you do not have to define a <Location..> directive?
[14:26:43.515134]<ironi>nope
[14:27:13.643074]<rts>ironi: i will look that up
[14:27:15.122885]<ironi>i have <Directory> for the static stuff only...
[14:30:36.765250]<rts>ironi: have a look at http://pyamf.org/tutorials/apache/mod_wsgi.html perhaps that will solve your issue
[14:30:58.030223]<rts>ironi: see LogLevel directive in the virtual host's config
[14:34:29.818271]<ironi>rts: its set to warn, but the weirtd logging does not log to the log files of the vhost, but the system default apache error.log
[14:34:39.657323]<ironi>rts: so whatever i set in my vhost it seems ot ignore it.
[14:35:22.873840]<rts>ironi: now, that seems to be a problem with the mod_wsgi and your overall server configuration.
[14:36:00.035170]<rts>ironi: and not a problem concerned with trac, i presume
[14:37:31.607629]<ironi>could be, but the looging only occurs form trac, not from django
[14:37:34.636878]<ironi>for example
[14:38:08.281761]<ironi>rts: which is coupled with trac in the same app,a ctuallt hte requests go through django to trac
[14:38:15.880929]<ironi>ah, its so weird.
[14:39:24.581888]<rts>ironi: so you integrated trac from your django based application?
[14:40:04.655793]<rts>ironi: and how do you call trac, by web interface or directly using the available apis?
[14:41:06.724240]<rts>ironi: or do you just route any requests to trac via django based routes?
[14:43:20.988352]<ironi>rts: the last one
[14:44:31.208661]<rts>ironi: so i reckon that this must be redirects that will then be sent out to the client, effectively requiring you to also set up a virtual host or some similar configuration for your deployed trac environment?
[14:45:10.990833]<rts>ironi: so that you can define a log level for your trac installation
[14:47:06.294605]<ironi>rts: yes I have a log level defined for the trac installation, and it works fine, but this additional debug logging is happening for some reason
[14:47:57.195716]<ironi>rts: thats for your help, really, but I don't see any way to solve this, I think its time to give up now.
[14:48:15.610611]<ironi>this is beyond ridicolous
[14:48:42.809200]<rts>ironi: yeah, the log level you defined is in the trac configuration (trac.ini), or isn't it? so, whenever django redirects your request based on your defined routing, then it maybe omits your actual LogLevel for some reason
[14:48:53.509869]<rts>s/omits/ignores/
[14:48:53.519456]<evil_twin>rts meant: ironi: yeah, the log level you defined is in the trac configuration (trac.ini), or isn't it? so, whenever django redirects your request based on your defined routing, then it maybe ignores your actual LogLevel for some reason
[14:49:23.154584]<rts>ironi: what is beyond mispelled ridiculous?
[14:49:48.151224]<ironi>rts: now that might be a reason. it does not ignore though, because if I set level to DEBUG in global-trac.ini it will log the same amount to the trac.log as well
[14:50:17.743910]<rts>ironi: yeah that is what it is meant it to be, back to start, again *sigh*
[14:50:47.588541]<ironi>but, if ignoring any directives, debug level cant be default, or can it?
[14:51:13.099764]<rts>ironi: don't know mod_wsgi, but i don't think so, no
[14:56:57.709013]<rts>ironi: have you finally resolved your problem?
[14:57:35.437159]<ironi>rts: not at all, unfortunately.
[14:58:21.234655]<rts>ironi: why not post your configuration on paste-bin so that we all can have a look at it?
[15:05:06.427424]<rts>time steal: 100%
[15:05:15.043151]<rts>gn8 all
[15:28:04.401570]<vlt>Aranel: What other language? Other than Python or other than English? What patch did you find?
[15:30:59.569401]<Aranel>vlt: other than english. Here it is: http://trac.edgewall.org/attachment/ticket/5488/trpatch.patch
[15:31:41.422287]<Aranel>vlt: there's no "locale" folder on my installation.
[15:33:32.507763]<vlt>Aranel: i18n is supported since version 0.12
[15:34:11.748020]<Aranel>vlt: is it stable enough for production?
[15:35:42.992893]<vlt>Aranel: I use it in production environment (as many others do).
[15:36:15.704227]<vlt>Aranel: There are some minor issues now and then, but no show stoppers so far
[15:36:43.665112]<Aranel>vlt: ok then :) 0.11 to 0.12 upgrade possible?
[15:37:17.659983]<Aranel>vlt: Google doesn't really help about it :/
[15:37:22.323617]<vlt>Aranel: I'd recommend installing 0.12 and then updating your trac env (the database) to 0.12.
[15:37:49.359320]<vlt>@install
[15:37:49.374510]<evil_twin>install is http://projects.edgewall.com/trac/wiki/TracInstall .. For platform specific instructions, see http://trac.edgewall.org/wiki/TracInstallPlatforms.
[15:40:37.137394]<Aranel>vlt: thanks for your help, now installing =)
[15:41:44.607192]<vlt>And please feel free to add the missing 209 turkish translations.
[15:43:58.028542]<vlt>Aranel: If you do, you can just attach a patch or your messages.po file to the trac ticket you found.
[15:44:54.634849]<Aranel>vlt: sure, I can do =)
[15:48:28.481181]<vlt>Aranel: In case you're really going to contribute I'll give you a way more current version of the messages.po file ...
[15:50:24.702141]<Aranel>vlt: consider it done, I would be happy to contribute :) 209 strings seems easy anyway, I'm translating MeeGo/Maemo too. (3000+ strings)
[15:53:19.583107]<Ac-town>Has anyone worked with MscgenPlugin on trac-hacks?
[15:57:47.892090]<vlt>Aranel: You'll find a current messages.po file here: http://trac.edgewall.org/attachment/ticket/5488/messages.po
[15:59:35.778547]<vlt>Aranel: Since tr hasn't been worked on for more than a year, there could be many, many old msgids, that don't match anymore ... Good luck
[16:02:38.154379]<Aranel>vlt: does not matter, since I'll use 0.12 too, I have plenty of time to try and see if it fits nice or not :)
[16:07:57.407483]<Aranel>vlt: "Unable to send email due to identity crisis." huh? :P
[16:08:57.200922]<vlt>Aranel: look at the following msg ,-)
[16:45:00.730334]<lazarus477>Question: If I run multiple svn repos, one per project; Do I need one Trac site setup or multiple using apache vhosts or similar?
[16:47:10.431184]<macmaN>rblank osimons, awake? is it possible to make trac not even load trac.ticket, trac.versioncontrol or whatever else component, instead of just disabling them after loading
[16:47:39.402036]<coderanger>lazarus477: Depends
[16:47:53.808124]<lazarus477>coderanger: Well I am all open for sugestions.
[16:48:15.305393]<lazarus477>I am competent at setting up vhostings, virtual machines, SAN and NAS storage, VPNs, etc.
[16:48:46.574884]<lazarus477>The time has come for me to use subversion and I want some sort of project management, bugtracking, docs etc and figure trac is well favored.
[16:49:04.587320]<lazarus477>Question is how to best make use of trac or if perhaps track is wrong for me.
[16:49:24.751355]<lazarus477>I have several smaller projects, mainly for internal use. Want to setup each one in its own repo.
[16:49:52.532401]<lazarus477>Question is does track deal well with multi repo multi project setups or should I look into alternatives, such as bugzilla or similar?
[16:55:08.588587]<coderanger>lazarus477: Multi-repo, yes, multi-project no
[16:55:18.705564]<lazarus477>Hmm
[16:55:20.553191]<coderanger>A Trac env is a project at a certain level
[16:55:30.051694]<coderanger>You would generally setup one env for each
[16:55:42.638947]<lazarus477>coderanger: One trac env, right?
[16:55:52.049096]<lazarus477>One trac env per project...
[16:56:00.781980]<coderanger>Though there is nothing preventing you from putting multiple project's worth of data in a single trac "instance"
[16:56:12.619233]<coderanger>Mostly its a question of naming conventions and how you want to use it
[16:56:30.662449]<coderanger>Should users be "per-project" or global?
[16:56:36.937982]<lazarus477>coderanger: Well would trac keep support tickets and documentation separate for each repo?
[16:56:43.052830]<lazarus477>I am guessing not...
[16:56:58.096126]<coderanger>No, but you can make a ticket component for each repo
[16:57:05.534630]<coderanger>and use a prefix on the wiki page names
[16:57:12.097889]<lazarus477>aha
[16:57:14.254851]<coderanger>wiki/proj1/Blah
[16:57:16.958591]<coderanger>Stuff like that
[16:57:25.006865]<lazarus477>I get it
[16:57:30.076821]<coderanger>It depends on how separate you want things
[16:57:36.822367]<lazarus477>Yea
[16:58:10.479955]<coderanger>A mutli-env solution via parentdir is also an option
[16:58:25.227396]<lazarus477>What about alternatives. Know any other subversion project tool which is aimed towards multiple repos and projects?
[16:58:28.691003]<coderanger>(instead of a vhost for each)
[16:58:36.876880]<lazarus477>ok
[16:58:38.907670]<coderanger>You still aren't saying what you actually want
[16:58:55.950128]<coderanger>The words "multiple projects" can mean about a million things
[16:59:20.669547]<lazarus477>Well I want one repo per project and each project to be represented indevidually by trac, or an alternative trac like solution :-)
[16:59:33.596489]<coderanger>Again, you need to be more detailed about your needs
[16:59:44.114925]<coderanger>will each repo need its own ticket workflow?
[16:59:55.429673]<lazarus477>Yes
[17:00:08.442180]<coderanger>What would two examples of such workflos be?
[17:00:33.675962]<macmaN>coderanger: why dont you just send him to wiki:MultipleProjects
[17:00:49.639692]<lazarus477>Forgive my lacking description of what I seek. I am new to the use of VCS and project management aids such as trac.
[17:01:06.015436]<macmaN>i think #130 is a must read lazarus477
[17:01:13.639393]<macmaN>if you're thinking along m.p. lines
[17:01:29.947229]<coderanger>lazarus477: If you are new to the field, I would just put everything in a single Trac instance and be done with it :)
[17:01:34.651918]<lazarus477>#130 ?
[17:01:34.716234]<coderanger>lazarus477: Much less complicated
[17:02:03.079631]<coderanger>Make a component for each "project" for tickets and thats about it
[17:02:21.303548]<macmaN>? #130
[17:02:21.350398]<lazarus477>coderanger: Yea, I read one linux mag article with your sugested aproach outlined, also discussed it with several experienced users...
[17:02:46.173847]<lazarus477>?#130
[17:02:48.136982]<coderanger>lazarus477: Anything more complicated than that is probably going to be overwhelming
[17:02:56.437602]<macmaN>? MultipleProjectSupport
[17:02:59.115214]<coderanger>lazarus477: We is talking about ticket #130 on t.e.o
[17:03:02.856163]<coderanger>er, He is
[17:03:04.171445]<macmaN>i just dont get along with this bot here :)
[17:03:16.004614]<macmaN>@multipleprojectsupport
[17:03:21.472498]*coderanger kicks evil_twin
[17:03:26.812471]<coderanger>trac #130
[17:03:34.768435]<lazarus477>Well I heared from one user who is also a close friend that he made templates to simplify setting up multiple repos and says that works like a charm.
[17:03:36.599447]<coderanger>yeah, he is napping
[17:03:54.185093]<lazarus477>As for myself, I use templates for apache vhosts, works like a charm as well, hehehe.
[17:03:57.137020]<macmaN>not a beep :)
[17:04:00.568441]<coderanger>lazarus477: Supporting multiple repos in a single trac is a new feature
[17:04:04.245234]<macmaN>lazarus477: http://trac.edgewall.org/ticket/130
[17:04:08.335703]<coderanger>lazarus477: So your friend may have been unaware of it
[17:04:12.872974]<macmaN>lazarus477: http://trac.edgewall.org/wiki/TracMultipleProjects
[17:04:26.407009]<coderanger>lazarus477: In 0.11 you needed multiple trac envs just to support each repo
[17:04:28.136102]<macmaN>those two links will tell you more than 5 coderanger could type on irc in about 2 weeks
[17:04:29.518249]<lazarus477>Yea I was reading a bit on this earlier
[17:04:55.988514]<lazarus477>I shall read up on it all and reconsider what I am about to do.
[17:05:01.393150]<coderanger>macmaN: You forget my unending hatred for the wiki docs :P
[17:05:02.699287]<macmaN>after 2 weeks, i think coderangers could type more
[17:05:07.797608]<macmaN>if theres 5 of them
[17:05:19.944749]<lazarus477>Also a question. Any major drawbacks in using one repo with subdirs for a bunch of indevidual projects?
[17:05:21.934744]<macmaN>hmm, ive not known about it yet
[17:05:26.647932]<macmaN>i guess i do now!
[17:05:34.637067]<lazarus477>I hear security is shot to hell and so is bandwidth usage. Comments?
[17:05:59.210645]<macmaN>lazarus477: not really
[17:06:10.399963]<macmaN>lazarus477: there are too many factors to consider to really have a single answer to that anyway
[17:06:16.691391]<coderanger>lazarus477: Subversion can do path-based ACLs
[17:06:16.975939]<macmaN>those are not irc questions
[17:06:45.889855]<lazarus477>I think I read I can easily setup user restrictions on a per directory bases, thats correct isn't it?
[17:07:24.264415]<coderanger>Yes, though it sounds like you are far too early in this process to have a need for such advanced features
[17:07:45.497064]<coderanger>Add complexity to your project tools only when you need it, not preemptively
[17:07:50.571386]<lazarus477>coderanger: Well that sounds like a solution to security.
[17:08:29.378040]<coderanger>If you are just starting out, I doubt you have anything in need of quite that granularity for security ;-)
[17:08:40.774780]<coderanger>Just require auth on the subversion repo and be done with it
[17:08:46.012509]<lazarus477>Well some of the advice I have received from my more experienced friend has to be taken with a pinch of salt. He is rather picky...
[19:19:57.326592]<Arc>does anyone know how to tell trac's fastcgi handler which python binary to use?
[19:20:44.274910]<Arc>my system has python 3.1 as the standard, but 2.6 also installed (which is what trac is installed for), and i specify /usr/bin/python2.6 at the top of trac.fcgi that apache is running, but the error log shows that its running python 3.1 somewhere in the process and raising an error from that
[19:21:53.762399]<coderanger>Arc: It would be the shebang on the fcgi script
[19:23:11.797088]<Arc>#!/usr/bin/python2.6
[19:23:14.807678]<Arc>already set
[19:23:20.339074]<Arc>this is whats showing up in my error log:
[19:23:27.330405]<Arc>[Tue May 11 22:22:40 2010] [error] Exception KeyError: KeyError(139929028491072,) in <module 'threading' from '/usr/lib64/python3.1/threading.py'> ignored
[19:25:00.270353]<Arc>i figured changing the executable at the top of trac.fcgi would be enough, and it did change the error thats raised, but apparently somewhere down the fcgi process its still running 3.1
[19:25:11.578271]<Arc>or at least, its env gets mucked up and 2.6 is trying to load 3.1 modules
[19:53:32.974019]<Arc> 9162 ? R 0:00 /usr/bin/python2.6 /home/pysoy/www/trac.fcgi
[19:53:37.143410]<Arc>that is what ps shows
[19:53:48.605894]<Arc>so it obviously puzzles me why its running the 3.1 threading module
[20:18:33.797574]<Arc>anyone?
[20:18:50.517382]<Arc>I don't even know where to begin debugging this
[20:35:19.250440]<Arc>anyone?
[21:21:17.044941]<coderanger>Arc: Dump sys.path for starters
[21:21:30.496671]<coderanger>Arc: See if anything in there looks like a 3.1 path
[21:41:22.321791]<Arc>updating to python 2.6.5 (from 2.6.4) fixed it?
[21:41:37.358422]<Arc>im going to chalk this up to "don't know, don't care, it works for now"
[21:49:38.032538]<Arc>thanks coderanger :-)
[21:50:06.543514]<Arc>hopefully trac is ready for python 3 sometime soon, running it under fcgi is obnoxious and prone to weird errors like this
[21:52:14.104237]<coderanger>Arc: Not for a while probably
[21:52:32.712594]<coderanger>Porting SWIG will be a hard task
[21:52:37.405046]<coderanger>and Genshi has issues on 3
[21:54:29.400635]<Arc>really? i havent run into any so far
[21:54:37.433712]<Arc>ive been using genshi with cherrypy on 3
[21:55:18.259354]<coderanger>I thought the speedups module still wasn't working
[21:56:13.604061]<Arc>is there something special you need to do to activate that module?
[21:57:53.094301]<coderanger>its internal, but it is can't be compiled there is a pure-python backup
[22:00:43.669647]<Arc>i see. ill look into it
[22:00:55.496228]<Arc>is anyone maintaining genshi at this point?
[22:02:21.386568]<Arc>i'd be more than willing to port the C code and do proper testing to ensure its actually ported correctly, but emailing patches is a PITA
[22:02:34.314812]<Arc>my previous py3 stuff did get integrated
[23:12:39.654754]<lolmaus>Hey hey ^^
[23:16:20.115733]<lolmaus>I've put my logo file to myproject/htdocs and set header_logo src = /logo.gif. I've got "No handler matched request to /logo.gif". How to fix that?
[23:21:00.220558]<wildintellect>site/logo.gif
[23:23:55.168899]<lolmaus>wildintellect, thx