Team Chat Logs

April 26, 2010

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

[00:24:11.770535]<Sumpen>Hi guys! Trac wont decode UTF-8 chars properly. Any thing except forcing Apache to use UTF-8 and setting default_charset = utf-8 in trac.ini that i can do?
[02:06:51.306239]<xelister>hello, wy trac uses retarded date format? and how to change that to sane yyyy-mm-dd ?
[02:46:42.445931]<bionoid>xelister: Date format is determined by server's locale, so you'll have to change that to one that uses your preferred format.
[02:47:08.749770]<bionoid>Sumpen: You need to show exact errors from log
[02:49:34.703416]<Sumpen>bionoid, thx mate but i solved it. I had to use --default-character-set=utf8 when i loaded the database back in to my trac db.
[02:50:45.872366]<bionoid>Sumpen: Great ;-)
[02:52:38.803922]<Sumpen>Im thinking of writing a document for svn and trac migration from sqlite to MySQL with Swedish chars. There are some things to consider before you get it right :/
[03:08:11.310836]<xelister>bionoid: that is no so good :/
[03:10:31.385140]<czr>hi there. is there an easy way to trigger an external program/script to be run when tickets are modified?
[03:10:54.925313]<czr>(I'd like to implement IRC notification really, but I need a way to trigger the notifications from trac)
[03:13:19.872676]<czr>I'd also like to get some kind of triggers on wiki changes if that's possible (using 0.11 here)
[03:22:52.457373]<dunk_>you can poll the RSS feed
[03:23:03.314554]<dunk_>put polltime at 1 min or so
[03:24:04.774347]<czr>I'd like a realtime solution if at all possible
[03:24:46.919426]<czr>(this is for our internal development only, not global irc)
[03:26:06.173117]<dunk_>well the RSS can also work for wiki edits etc
[03:26:23.761582]<dunk_>but there are post commit hooks and stuff in trac .. never used it myself though
[03:28:34.828756]<xelister>dunk_: your solution blows
[03:28:38.824732]<czr>that's for integrating svn commit events into trac. so it's for svn (or vcs).
[03:28:48.666393]<dunk_>why is that xelister ? ;]
[03:28:49.374641]<xelister>czr: there are .pl scripts, I tried well hmm it seem to work
[03:28:57.619101]<xelister>dunk_: it's an ugly hack
[03:29:03.338577]<czr>xelister, link?
[03:29:13.408674]<dunk_>i think the commit hooks are ugly but hee ;]
[03:29:14.263347]<xelister>czr: bing svn commit hooks
[03:29:40.335975]<czr>argh. I don't need svn commit hooks. I need trac wiki/ticket hooks.
[03:29:49.574743]<xelister>dunk_: they are the correct way, and bussy-waiting is by design retarded work around, because it uses much more resources, and still it will not be as fast
[03:29:53.696077]<czr>(I already have a working svn -> irc hooking done)
[03:30:15.590854]<xelister>ah wait, trac. well.. bing trac hooks? I did't did it myself
[03:30:30.168120]<dunk_>xelister: yes thats true but you need access to the machine your running trac on
[03:30:36.064143]<czr>well, I'm pulling blanks, that's why I'm asking here
[03:30:36.494190]<dunk_>RSS can work from where ever
[03:39:29.525587]<xelister>rss hack sounds possible, as a workaround
[03:42:27.437792]<czr>well, I'll just wait for someone more experienced to answer then :-). the RSS hack is ugly.
[03:54:39.131086]<vlt>Hello. When browsing the timeline I can't enter more than 90 days to show events from the past anymore. Is this intenional behaviour?
[03:56:32.263828]<xelister>vlt: yes
[03:56:41.710120]<xelister>vlt: this is configurable, as max days history or something like that
[03:56:47.944294]<xelister>in trac.ini
[04:20:25.562622]<vlt>xelister: Thank you.
[04:30:48.263526]<xelister>no problem :)
[05:05:29.132795]<Sumpen>Hi gain guys! I'm working on a Trac migration project. This time, I'm having trouble with Ticket System specifications, Priorities, Resolutions etc. They dont seem to be migrated with the rest of the db. I even copied the trac.ini file and edited db connections and stuff. Are theese things stored in trac.ini or in the db?
[06:17:12.970012]<bionoid>xelister: Yeah just wait till you're moving an env between servers with different OS... that's when the real fun begins ;-)
[06:17:49.464074]<bionoid>czr: Your best bet might be to fork Announcer
[06:28:40.204236]<czr>hmm. I guess that means upgrading to 0.12 first then and a lot of work.
[06:28:54.490209]<czr>thanks bionoid. I'll just postpone this for a year again and see what happens after that :-)
[06:38:46.501883]<bionoid>czr not really, announcer is .11 and bridging it with irc is probably not that difficult. but it will involve some coding for sure ;)
[06:40:04.482741]<czr>well yes. I've never done any trac coding or even installed any optional plugin, so .. :-).
[06:43:20.435552]<John_B>Anyone able to help with suggestions why my Trac won't load a particular system-wide Trac plugin?
[06:44:20.975785]<John_B>It loads it fine if it's put in a particular installation's plugins dir
[06:44:59.979746]<bionoid>czr gotta start somewhere ;)
[06:46:14.891578]<bionoid>John_B enable debug logging to file, should show some info. possibly the global plugin is built with different python version than what trac is running with..
[06:46:38.182874]<czr>bionoid, I'm 100% sure that I won't get the permission on working on this for more than 1 day anyway, so.. it's unlikely :-).
[06:46:44.412016]<John_B>Nothing in debug log file, no mention of the plugin. I build the egg myself - same Python
[06:46:58.165005]<czr>bionoid, thanks anyway though
[06:47:42.249953]<bionoid>John_B what plugin is it, and what trac version?
[06:48:22.038368]<John_B>TracWikiToPdfPlugin - Trac 0.11.7
[06:48:53.947291]<John_B>I've got other system-installed plugins that work fine
[06:49:04.570237]<bionoid>hm and of course you did manually enable it im trac.ini?
[06:49:52.789820]<John_B>Yeah
[06:50:45.467883]<John_B>$ grep pdf test/conf/trac.ini
[06:50:45.697902]<John_B>wikitopdf.* = enabled
[06:52:22.204351]<bionoid>hmm ok, thats strange.. check the plugin code and verify that name..
[06:52:41.895841]<John_B>I was wondering about case-sensitivity
[06:52:50.247465]<John_B>Where do I check the plugin name?
[06:53:28.079209]<bionoid>i will be at puter in an hour or sth, currently on n900.. will check in with you
[06:53:38.265195]<bionoid>hmmm in the toplevel py iirc
[06:54:11.511876]<John_B>hmm: $ cat TracWikiToPdfPlugin.egg-info/entry_points.txt
[06:54:11.784244]<John_B>[trac.plugins]
[06:54:11.797299]<John_B>wikitopdf.web_ui = wikitopdf.web_ui
[06:54:11.809237]<John_B>wikitopdf.formats = wikitopdf.formats
[06:54:11.821771]<John_B>wikitopdf.wikitopdf = wikitopdf.wikitopdf
[06:55:35.000373]<John_B>Ah yes, "packages = ['wikitopdf'" in the setup.py
[06:56:46.437097]*John_B tries standalone trac server
[06:58:22.865731]<John_B>Seemingly the same
[07:06:28.074833]*John_B submits a bug to the plugin
[07:40:02.789528]*retracile croaks something derogatory about mornings.
[07:43:08.035878]<artisan>hi, I have little annoyance, because we have a user used for submitting tickets (best and so far only solid way to get rid of ticketspam) and all ticketnotifications are bcc'd to our mailing list via the prefs of that user.
[07:43:53.391993]<artisan>now, it is via bcc settings and without a clear TO: header mailman always stops those mails, because of 'to: undisclosed recipients;' ..
[07:44:29.503090]<artisan>is there any way to set the notification as TO: instead of BCC: ?
[07:47:00.472666]<artisan>ah, I stand corrected
[07:47:47.494585]<artisan>it is the mailadresse of the user. but trac doesn't write a correct TO: header ..
[07:47:59.551508]<artisan>any idea how to achieve that?
[07:49:28.896586]<artisan>in the trac.ini I see settings for default cc and bcc, but no TO ..
[07:56:06.436594]<xelister>artisan: TO depends on the action. In example if you reply in bob's ticket, he will probably get to: bob@test.com
[07:56:13.341716]<xelister>afair
[08:00:02.286698]<artisan>xelister: any chance to get a TO: for every ticket action? (new, edit, del, comment)
[08:01:07.872463]<xelister>artisan: I don't know...
[08:01:36.773479]<artisan>hm
[08:12:52.002220]<artisan>ok, I gonna tweak mailman, seems easier :)
[08:15:28.752061]<bionoid>artisan: May not solve your exact use case, but in general, AnnouncerPlugin is much nicer than the standard notifications. Worth checking out.
[08:15:49.598572]<bionoid>John_B Oh ok, good, hope the author gets back to you ;)
[08:18:34.829424]<artisan>bionoid: thanx alot, I check that out!
[12:48:55.960396]<slinkp>gah. anybody have tips on finding the cause of apparent interpreter crashes under mod_wsgi?
[12:50:18.353068]<slinkp>hard to know what's up when all you can get apache to tell you is "premature end of headers"... and google turns up lots of hits that basically tell you "your interpreter probably crashed, blindly try random solution X"
[12:53:06.830381]<lukasg>slinkp, do you have a WSGIApplicationGroup %{GLOBAL} directive for you trac env as described in http://trac.edgewall.org/wiki/TracModWSGI ?
[12:54:59.057050]<slinkp>lukasg: no i didn't. holy crap that worked! thank you!
[12:55:11.998508]<cboos>hello
[12:55:46.896064]<hasienda>hello :-)
[12:56:29.145489]<lukasg>slinkp, you're welcome ;)
[12:57:18.536069]<slinkp>lukasg: I had been looking at http://trac.edgewall.org/wiki/TracDev/AlternativeFrontends#Alternativefrontend:mod_wsgi which has WSGIApplicationGroup %{SERVER}
[12:58:49.038338]<hasienda>cboos: did something on getting better code into #9209 for replacing multiple list comprehensions as you suggested
[12:59:05.646131]<cboos>slinkp: oh, that's bad, should always be %{GLOBAL}
[12:59:34.371014]<cboos>hasienda: yes, I've seen it - been refraining myself from testing and committing it actually ;-)
[12:59:46.560643]<cboos>... as we /really/ need to get 0.12b1 out of the door now
[12:59:54.569757]<hasienda>cboos: np
[13:00:02.390311]<hasienda>cboos: take your time
[13:00:06.849400]<cboos>so regarding 0.12b1 ...
[13:00:09.033301]<cboos>regarding my 9268-commit-after-upgrade-step.patch I sent on Trac-dev today, I'd feel better before committing it if someone else would test it (take old 0.10 or 0.11 env, upgrade it to trunk+patch; preferably an environment with a cached repository)
[13:00:35.990599]<slinkp>cboos: i'd be happy to update the bad wiki page, but i'd rather not take responsibilty for it as i don't really understand what those alternatives mean :)
[13:05:21.923270]<cboos>slinkp: you can always add a link to the authoritative document which explains the tricky bits ;-) (http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac)
[13:05:44.082985]<cboos>look for %{GLOBAL} there
[13:14:30.800269]<rblank>cboos: Meanwhile, I can reproduce the issue on #9268. Got a fix, too.
[13:14:38.634623]<slinkp>cboos: done, thanks
[13:15:56.340618]<cboos>rblank: yes, I suppose that for some database_version, youngest_rev was not set (e.g. http://trac.edgewall.org/ticket/5522)
[13:16:17.015646]<cboos>or he did some direct db manipulation
[13:17:02.676485]<cboos>slinkp: good! thanks
[13:34:53.146742]<doki_pen>cboos: what do you say, I have ~2-3 yrs to finish up announcer integration?
[13:35:04.613381]<doki_pen>cboos: ;-)
[13:36:37.644636]<doki_pen>gotta run, that was a drive by
[14:02:04.472562]<rblank>cboos: Your upgrade patch works fine here for 0.11.7 -> 0.12dev (Linux, SQLite)
[14:03:52.799781]<cboos>with a cached repository?
[14:04:01.468057]<cboos>(I didn't test that case)
[14:04:41.961542]<rblank>cboos: Yes, a cached SVN repository.
[14:05:24.768404]<cboos>perfect .... I'm currently testing your patch for 9268 on top of it, so I'll apply my patch after that
[14:05:53.765803]<cboos>and btw, we need to document with_transaction in API changes, and env.get_read_db and the deprecation of get_db_cnx
[14:06:47.460901]<cboos>this evening I'll also try to finish my resources_exists patch
[14:08:35.857258]<rblank>cboos: Bah, documentation...
[14:09:14.137854]<cboos>... this one is quite important, everybody uses get_db_cnx ;-)
[14:09:27.420432]<rblank>cboos: Can't we outsource this? :)
[14:10:07.427609]<cboos>aat: ? (sorry, too bad for you, you're the first in the list)
[14:11:43.115720]<cboos>rblank: I'm also cleaning up my bookmarks ... in the process you might see a few unrelated tickets being flagged as worksforme or wontfix
[14:12:01.015129]<cboos>or other random milestones changes ;-)
[14:12:27.866649]<cboos>speaking of milestones ... got any idea?
[14:13:37.308256]<cboos>+ related to that, I wonder if I should assign #130 to 0.13, to show we're getting serious about it
[14:14:25.987723]<rblank>cboos: Haven't had time to think about it more. Assigning #130 to 0.13 sounds good.
[14:14:38.414750]<cboos>good!
[14:14:42.515625]<cboos>btw, "make bigtest" succeeded ;-)
[14:14:46.549540]<rblank>cboos: When will we branch 0.12-stable? Before or after beta1?
[14:15:09.630511]<rblank>What's "make bigtest"?
[14:15:28.471082]<cboos>$ make -n bigtest
[14:15:30.483849]<cboos>make python=24 test
[14:15:32.489276]<cboos>make db=postgres test
[14:15:34.503958]<cboos>make db=mysql test
[14:15:35.942841]<cboos>;-)
[14:15:46.963550]<rblank>Don't have that in my Makefile.
[14:15:57.508307]<rblank>Must be your custom rules :
[14:16:00.947311]<rblank>:)
[14:16:10.441988]<cboos>you have it in your Makefile.cfg.sample
[14:16:12.714514]<cboos>;-)
[14:16:38.378028]<cboos>which is a sanitized version of my own Makefile.cfg, of course
[14:16:45.734720]<rblank>Right. Wouldn't work too well here, I don't have a single machine that has all the variants.
[14:19:23.363552]<cboos>so for 0.12-stable, I've been wondering as well; problem is that we still have 0.11-stable "opened"
[14:19:58.554880]<cboos>once I finish resource_exists and we backport it, is there anything else to do for 0.11.7.1?
[14:21:19.747741]<rblank>cboos: Not on my side.
[14:21:45.606683]<rblank>cboos: The reason I ask is that I will get bored if I can't hack while we wait for 0.12rc1 :)
[14:22:27.617020]<cboos>... the solution would be to not have to wait too long for 0.12rc ;-)
[14:22:35.324964]<cboos>rc1
[14:23:02.124765]<rblank>Sure. You still wanted 1-2 weeks, didn't you?
[14:23:09.105722]<cboos>yes
[14:23:26.050779]<cboos>I wonder if during that period 0.12b1 - 0.12rc1 I will not try to finish the translation for workflows
[14:23:27.188442]<rblank>But even if we branch pre-beta1, merging from 0.11-stable should be pretty painless, with svn:mergeinfo.
[14:23:46.713930]<cboos>pre-rc1 you mean
[14:24:02.220867]<rblank>No, I did mean pre-beta1. Or shortly thereafter.
[14:24:13.286824]<retracile>cboos: (tangent: I didn't manage to look at the strace "later", sorry. I'll try to deal with it tonight.)
[14:24:23.805765]<rblank>retracile!
[14:24:30.829424]<retracile>rblank! :)
[14:25:05.587331]<cboos>retracile: that would be nice, thanks! look also at the #trac backlog of sunday, where I exposed my theories about #8443, feel free to shoot that down ;-)
[14:26:04.962445]<cboos>rblank: I'm getting annoyed to see "leave statut à new" etc. in tickets ... so I'll likely try to fix it before 0.12 proper
[14:26:22.431562]<retracile>cboos: ok, I added that to my todo list.
[14:26:32.994711]<cboos>at the top?
[14:26:59.155946]<retracile>cboos: after "look @ cboos's strace", which is, in fact, at the top.
[14:27:03.304337]<rblank>cboos: Any idea yet how you're going to do that? Add the translations in trac.ini? leave.name.fr = laisser
[14:27:12.719681]<cboos>retracile: great ;-)
[14:27:27.973516]<retracile>cboos: (Such things as "eat, sleep, work" aren't exactly on the list, and tend to get in the way much too regularly though. :( )
[14:28:40.834521]<retracile>Hm. I'm not sure I know enough about translations to see how workflow plugins will fit into the picture either.
[14:28:47.244171]<cboos>rblank: I was initially thinking about a trac.ini.fr, but maybe that would be too much overhead (especially considering the impact on check for being up-to-date)
[14:29:10.837902]<cboos>rblank: so yes, presumably sub keys, or a dedicated section
[14:29:55.907586]<cboos>[ticket-workflow.fr] ?
[14:29:56.267813]<rblank>cboos: There's still currently the limitation that the action is at the beginning of the line, which might not work too well in some languages.
[14:31:05.456075]<rblank>Wouldn't a per-language section put too much distance between the workflow and the translation? In the spirit of keeping things together that go together.
[14:31:44.103061]<cboos>(action at beginning) any chance this could get swallowed by the rest as part of an %(action)s param?
[14:32:39.673249]<cboos>well, a [ticket-workflow] is usually already quite populated - adding all the translations inside would probably make it even less readable than it currently is
[14:33:39.374663]<cboos>but well, a few more lines <action>.name.fr = ... why not?
[14:34:22.674898]<rblank>cboos: (action at beginning) Didn't get that.
[14:35:01.795379]<retracile>regarding the 'action at the beginning' thing, I believe you will find a lot of people will want more flexibility in how it is presented, even within the confines of English. Exactly what a solution would look like though, I'm not certain. I think we rapidly approach a point where what people want to accomplish requires a turing complete language. :/
[14:35:16.741475]<rblank>cboos: Oh, now I got it. Yes, this could probably be done.
[14:36:34.845031]<rblank>Anyone knows which headers have to be set for a download not to be cached? Expires? Cache-Control? Pragma: no-cache? All three?
[14:36:50.693469]<rblank>(Working on #9264)
[14:38:14.312701]<cboos>retracile: regarding english/english variations, the current trac/locale/en_GB really needs fixing... lots of duplication inside. Messages that shouldn't be "translated" (i.e. no stupid color -> colour mapping) should really be left alone.
[14:38:31.207160]<cboos>retracile: but you're not a brit, so you don't care, I suppose ;-)
[14:39:18.381235]<cboos>rblank: I think we already set them in one place, grep for Cache-Control
[14:39:57.282666]<cboos>for a redirect
[14:40:24.620024]<cboos>and send_header('Cache-Control', 'must-revalidate') for a "send"
[14:40:29.320884]<rblank>cboos: Yes, but differently in different locations. The redirect has all three, the error page the first two.
[14:41:01.204781]<rblank>... and send() has only the second.
[14:41:31.649490]<rblank>So I'm a bit confused. I guess I won't have another choice than to look at the HTTP spec. :(
[14:41:52.251166]<cboos>right ;-) but IIRC, all 3 is best
[14:42:12.307587]<cboos>covers the most browsers / agents
[14:51:23.780560]<rblank>cboos: Actually, are you sure we *don't* want to allow caching for rev='HEAD'? The "Last-Modified" header is set from the node time, so if youngest changes, the header should, too.
[14:52:31.010090]<cboos>in theory yes, but you've seen the report - it seems some browsers don't care (wouldn't be surprised if that would be some IE version ...)
[14:53:07.017450]<cboos>but OK if it worksforus, we could then blame the browsers
[14:53:08.396586]<rblank>Or maybe a broken proxy?
[14:53:37.068863]<rblank>I still have to check if I can reproduce the caching issue.
[14:53:47.519253]<cboos>right, we should check ourselves
[15:00:14.831359]<rblank>cboos: Ok, caching *is* an issue :(
[15:02:10.423469]<cboos>that's bad indeed
[15:02:37.959518]*cboos has been trying meanwhile to enroll two more translation coordinators ;-)
[15:05:01.058327]<cboos>wow, and one more translation at 100% (Itamar for he!)
[15:54:38.047076]*rblank -> bed
[19:45:30.822660]<BarnacleBob>in the trunk version of track. how the heck do you get it so that commit messages update tickets? the faq page is just wrong about it now and several other pages/commit logs i've found reference a comment in the trac-svn-hook script but there is no such comment
[19:48:40.851977]<BarnacleBob>ohhhhh
[19:48:48.205856]<BarnacleBob>there is options to the main plugin
[21:16:34.607380]<judge-->Hello all.. Do you know what's the channel for help with Dolphin CMS?