Team Chat Logs

December 14, 2009

2009 11
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:17:31.449413]<otaku42>moin
[00:18:39.344166]<otaku42>osimons: just 0.10 => 0.11. :80 and :81 run on the same server (hardware and container).
[00:21:40.195194]<osimons>otaku42: hmm. big difference.
[00:23:20.188425]<otaku42>osimons: indeed. there is a bit we can do, though, such as porting the performance tweaks from 0.10 to 0.11 (the tweaks i've applied against the trac 0.10 instance t-h.o is running on now)
[00:26:03.895040]<osimons>otaku42: it is really just the front-page that i see are substantially slower - all other wiki pages are just about ~50% slower... perhaps have the listing macro do some agressive caching?
[00:30:03.896323]<otaku42>osimons: for the listhacks macro i plan to implement some improvements, such as reducing the amount of database queries. i also thought about caching, but am not sure how to best implement that.
[00:30:16.283871]<osimons>that will no doubt help a bit
[00:31:02.716376]<osimons>file or database?
[00:31:29.575143]<osimons>or just memory for that matter - keep it there for 15-30 minutes in each process
[00:31:58.138126]<osimons>front-page listings rarely change - a 1 hour lag likely will not make much difference either
[00:35:03.825483]<otaku42>osimons: i also intend to rework the front page a bit, moving the hacks listing to a different page. see also my posting to th-users this morning
[00:47:00.106571]<cboos>otaku42: welcome to the wonderful world of Genshi, trading flexibility for speed...
[00:47:25.242981]<cboos>what are those performance improvements you're talking about? Anything we could retrofit in core?
[00:49:26.676138]<otaku42>cboos: query improvements, additional inidices, stuff like that. not sure which of them are actually applicable for 0.11 or later, will have to recheck that.
[00:54:39.707775]<cboos>ok, just make them public somewhere, so I can have a look
[01:01:26.753756]<cboos>cmlenz: hello!
[01:01:39.081680]<cmlenz>morning
[01:01:42.602385]<cboos>I had a hard time with Genshi/Babel this week end ...
[01:02:02.982431]<cboos>fighting with <i18n:choose>, which doesn't work exactly as I expected
[01:02:19.003553]<cboos>I ended up using ${ngettext(...)} :-(
[01:02:47.704897]<cmlenz>bah
[01:03:01.172376]<cmlenz>did you ask s0undt3ch about the problem?
[01:03:11.043441]<cboos>he wasn't on IRC
[01:03:43.202726]<cboos>but I could file a few issues, though he doesn't have commit privs on Genshi trunk
[01:03:54.070041]<cmlenz>so what was the difference between expectation and reality
[01:04:07.492478]<cmlenz>well, I'd be okay adding the commit bit
[01:05:28.529485]<cboos>mainly when you just want to use choose/ngettext for discriminating between singular vs. plural (you know the 0 and other fancy situations), but the translation text is the same (or looks the same: e.g. "${title} ${unit}: " or "Total ${unit}:")
[01:06:26.522025]<cboos>then only one text is picked
[01:07:15.281651]<cboos>well, it's a bit hard to explain, but try to use i18n:choose on the milestoen progress_bar, and all the trouble becomes clear ;-)
[01:08:03.536269]<cmlenz>sounds like you should file a bug for that
[01:09:50.300734]<cboos>yeah, now I could do that, this w.e. I was just determined to make.it.work at any cost, so I used ngettext in the end ;-)
[01:59:21.940559]<gozerbot>trac: Ticket #7287 ('ascii' codec can't decode byte 0xe5 in position 0: ordinal not in ...) closed - <http://trac.edgewall.org/ticket/7287#comment:5> || Ticket #7287 ('ascii' codec can't decode byte 0xe5 in position 0: ordinal not in ...) reopened - <http://trac.edgewall.org/ticket/7287#comment:4> || Ticket #6874 ([patch] i18n branch, Argentinian Spanish localization)
[01:59:26.928411]<gozerbot> closed - <http://trac.edgewall.org/ticket/6874#comment:6> || Ticket #6874 ([patch] i18n branch, Argentinian Spanish localization) reopened - <http://trac.edgewall.org/ticket/6874#comment:5> || Ticket #7440 ([PATCH] Polish translation file.) closed - <http://trac.edgewall.org/ticket/7440#comment:7> || Ticket #7440 ([PATCH] Polish translation file.) reopened - <http://trac.edgewall.org/ticket/7440#comment:6> (+1)
[02:04:27.322335]<otaku42>cboos: i still wonder about the right way to have some text being rendered through pygments in trac 0.11.
[02:05:10.120286]<otaku42>cboos: the tracpygmentsplugin had a bunch of macros for various types, but that plugin collides with trac 0.11's native pygments support
[02:06:01.298577]<otaku42>cboos: i thought that {{{#!<mime-type>}}} was the trick (with mime-type being one of the types that pygments recognizes), but it seems i was wrong.
[02:06:11.788200]<otaku42>cboos: any hints?
[02:21:19.071155]<cboos>otaku42: I need to check that, I remember there's a problem
[02:22:10.588524]<cboos>(sorry people, small paste coming ...)
[02:22:16.653311]<cboos>{{{
[02:22:18.645680]<cboos>#!ini
[02:22:20.620827]<cboos>[test]
[02:22:22.025899]<cboos>option = value
[02:22:23.155820]<cboos>}}}
[02:22:29.011238]<cboos>try this ... for me it works
[02:22:51.707599]<cboos>i.e. pygments highlights it
[02:23:09.583845]<cboos>on t.e.o also
[02:25:13.216982]<cboos>... so maybe the problem was simply that t.e.o didn't have a recent enough pygments version, I'm not sure anymore.
[02:28:17.965049]<otaku42>cboos: #!ini works, so does #!html and some others. however, tracpygmentsplugin had #!apache (for apache configuration), which is not available on trac 0.11
[02:28:59.109635]<cboos>hm, !html is builtin ;-) you meant !xml I suppose
[02:29:46.205345]<cboos>otaku42: you should ping Tim about that, he should know the difference ini vs. apache
[02:31:10.336084]<otaku42>cboos: tim?
[02:32:05.593367]<otaku42>cboos: i get "no macro or processor named 'apache' found" in such cases, by the way
[02:32:30.219333]<cboos>otaku42: thatch
[02:32:40.664834]<cboos>== Tim Hatch
[02:33:08.635699]<cboos>or put otherwise, TracTeam /\ PygmentsTeam == { thatch }
[02:34:01.056952]<otaku42>cboos: ok :)
[02:34:13.169183]<otaku42>thatch: ping
[02:35:10.824193]<cboos>(and he's living in the us, so you should ping him this afternoon if you don't want to wake him up in the middle of the night ;-) )
[02:36:04.396146]<otaku42>cboos: too late :) but i'll be patient.
[02:39:26.379552]<otaku42>cboos: one difference in class PygmentsRenderer between 0.10+plugin and 0.11 is, that the implementation in 0.11 lacks the implementation of IWikiMacroProvider
[02:40:15.326634]<otaku42>cboos: which seems to explain why the many macros that the plugin implemented are not visible without the plugin on 0.11 (in /wiki/WikiMacros, for example)
[02:59:22.309770]<gozerbot>trac: PySqlite edited - <http://trac.edgewall.org/wiki/PySqlite?version=48>
[03:02:28.450717]<macmaN>haw cboos
[03:03:08.175436]<cboos>hello
[03:03:31.260805]<macmaN>i remember you said you were going to put a quickcomment on th:6296
[03:03:38.173191]<macmaN>th:#6296
[03:11:31.323300]<macmaN>haw cboos
[03:11:45.523907]<macmaN>how about making the Custom Query filters panel nice and collapsible like Ticket sections
[03:11:54.279101]<macmaN>good idea?
[03:12:42.170637]<cboos>well that's already done for the columns selector, and for the filters themselves for saved queries
[03:12:44.081359]<macmaN>wait im running this on 0.11.6, i should check 0.12
[03:13:08.502768]<cboos>(this didn't change between 0.11 and 0.12)
[03:13:31.613647]<macmaN>yes, i can see its done for column selectors
[03:13:36.770479]<cboos>... but of course, /many/ other things changed for the custom queries in 0.12 ;-)
[03:14:03.535553]<cboos>most notably AND/OR filters and filtering on date fields
[03:14:04.981525]<macmaN>if i really really want to modify this and you dont think its trunk worthy, what mechanism does this
[03:14:35.868589]<cboos>easy, just check the difference between the filters and columns fieldsets...
[03:14:53.483879]<macmaN>this is css-able?
[03:15:11.907676]<cboos>maybe it's just a js call after load
[03:15:35.575585]<macmaN>oo .collapsed .foldable
[03:15:38.231797]<macmaN>seckzee
[03:15:42.704064]<cboos>$("#columns").toggleClass("collapsed");
[03:15:48.758579]<cboos>is done after load
[03:16:24.236607]<macmaN>thanks
[03:18:38.877089]<macmaN>hmm, my initial thought is div #content .query would have enclose only the control panel
[03:18:53.433609]<macmaN>query results should be separate divvy
[03:19:27.281127]<macmaN>im noticing BatchModify plugin could also use this
[03:24:17.374870]<macmaN>aah th:#6195 already does this
[03:29:22.625244]<gozerbot>trac: PySqlite edited - <http://trac.edgewall.org/wiki/PySqlite?version=49>
[03:55:49.455835]<osimons>cboos: think you forgot to reset 0.11-stable to 0.11.7 development mode - or is it because you consider it EOL??? :-) basically these adjustments are missing: http://trac.edgewall.org/changeset/8364
[03:59:22.838948]<gozerbot>trac: Changeset [8905]: MultiRepos: merge changes from 0.12dev [8883:8904/trunk] - <http://trac.edgewall.org/changeset/8905>
[04:00:35.720696]<osimons>cboos: i'd fix it, but better that you also get it into your release checklist and remember it next time :-)
[04:11:46.052485]<cboos>osimons: I actually left like that on purpose.
[04:12:00.277423]<cboos>osimons: I think we need a /really good reason/ (tm) to make a 0.11.7
[04:12:26.129274]<cboos>and then, it will still be time to change the tag back to devel
[04:12:36.049393]<cboos>or -stable
[04:12:43.311962]<osimons>i see - it is End-Of-Line then...
[04:13:25.070511]<cboos>Well, yeah, it's about time to get everyone to focus on 0.12 ;-)
[04:13:30.996190]<osimons>figured it would be like our other 0.x branches, that may have changesets/fixes but without cutting releases
[04:13:40.537135]<osimons>it kind of just trails off...
[04:15:26.768980]<cboos>I'd rather see it the opposite way, /if/ we think there must be some follow-up milestone, then we put it back to -stable, if we're unsure, we leave it until the need for the next minor release becomes clear.
[04:16:03.006340]<cboos>For example, I'm pretty sure we'll get 0.12.1, but would prefer to have 0.13 rather than 0.12.2 and a long series of minor updates...
[04:17:25.643280]<osimons>well, change in dependencies, breaking apis and db updates is usually what forces that transition
[04:19:23.124881]<cboos>yeah, it's a balance, keeping "long" release cycle has some advantages in terms of API stabilization, but that prevents to address bigger issues in a timely manner
[04:27:41.684183]<siebo|NL>how do I figure out what user should own the <trac-env>/attachments folder so that web users can upload files?
[04:39:31.041991]<osimons>siebo|NL: the user that runs apache or tracd need write for that directory - somehow. use perm for owner, group or other depending on your setup and security needs
[04:39:50.612825]<siebo|NL>osimons: cool, thanks, I changed it over to the apache user :)
[04:40:04.898793]<osimons>goodie
[05:00:48.027822]<noccy>ah, people alive now? :)
[05:01:02.293173]<hylje>it's monday
[05:01:51.871564]<noccy>that's true :) hehe
[05:02:32.171602]<noccy>i have got a cron script creating nightly builds etc and then updating one of my trac sites with the updated build urls etc
[05:02:47.696161]<noccy>only problem is it shows up in the timeline, under the user "Trac", for each day lol
[05:03:11.837962]<noccy>is it possible to hide this user completely? so all changes from the trac-admin tool are hidden?
[05:09:48.035660]<noccy>like a "hidden in timeline" setting for what users should be excluded
[05:15:53.209366]<osimons>noccy: not really, people will see all updates
[05:16:54.369095]<osimons>noccy: your script could of course update the info saved in the db without making a new version of the page... hackish, but if timeline is very important then that is the way to go is suppose
[05:17:30.690989]<osimons>ie. find latest version of page, update body text and re-save the row.
[05:18:58.439103]<cboos>osimons: have a look at http://trac.edgewall.org/attachment/ticket/7902/trac-sqlite-extensions.2.patch
[05:19:27.079546]<cboos>osimons: see, how people adopt naturally the "path relative to env" thinking ;-)
[05:22:13.324840]<osimons>cboos: we have all sorts, including repository_dir that isn't a PathOption - it is other types of options where each may have a special handling...
[05:23:37.006455]<noccy>osimons: that would be jumping through hoops :) there is more i want to do, but my scripts would end up spamming the timeline
[05:24:36.152829]<osimons>cboos: i suppose you want a PathListOption as well then for that attachment? :-)
[05:26:56.978271]<osimons>trac isn't consistent, plugin developers even less so. paths and options are a bit messy across a typical trac installation
[05:27:28.486566]<cboos>osimons: yes, I think we discussed the PathListOption in the past, and that would obviously be useful here. And certainly simpler to implement as the parent .ini relative path (but we should ask Remy for confirmation ;-) )
[05:29:18.162309]<cboos>And the fact option related paths are not consistent can be seen as a motivation to clean-up things in core. I doubt that any plugin currently implements something as complex as the latest installment of #5525 on its own...
[05:29:24.611991]<gozerbot>trac: Ticket #8889 (error: (111, 'Connection refused')) created - <http://trac.edgewall.org/ticket/8889>
[05:32:32.562287]<otaku42>quick question: "new style" macros, implemented via expand_macro, get a formatter passed as parameter. what needs to be done to get that formatter when implementing an "old style" macro (with render_macro)?
[05:33:28.035759]<osimons>formatter is more a collection of the things you need - req, context and so on. are you working on an old-style macro, otaku42 ?
[05:34:19.407188]<otaku42>osimons: more or less. i'm trying to implement some missing bits that on Trac 0.10 were provided by the TracPygmentsPlugin.
[05:34:39.438835]<otaku42>osimons: that plugin implemented a bunch of macros/processors for formatting stuff via pygments
[05:34:40.789697]<cboos>why don't you just use the expand_macro method?
[05:34:58.589373]<osimons>otaku42: exactly what is missing? processors?
[05:35:06.513238]<otaku42>osimons: yes
[05:35:15.112169]<otaku42>cboos: good question... let me check :)
[05:35:16.130483]<osimons>can't you use a config setting for that and map them up?
[05:36:55.346840]<osimons>in [mimeviewer] mime_map you can add mappings and file extensions
[05:38:55.398302]<osimons>otaku42: like mime_map = text/x-common-lisp:cl:lisp => will make #!lisp work, and also files ending with .lisp will be rendered as such
[05:39:27.862188]<osimons>here is my current mime_map setting btw, configured to handle some things i need that are currently missing from default trac:
[05:39:34.489590]<osimons>mime_map = text/xml:aspx:ascx:master:xml:resx:config:sitemap:wsdl:disco:map:asmx:mxml:csproj, text/x-actionscript:as, text/x-erlang:erl:hrl, text/x-common-lisp:cl:lisp, text/x-trac-wiki:wiki
[05:40:36.998345]<otaku42>osimons: sorry, i was on the phone.
[05:40:51.152694]<osimons>cboos: remember that pretty much every option is already written to file (trac.ini) - changing resolving of existing options will be also be... messy...
[05:41:13.366880]<otaku42>osimons: that would work for rendering attachments or stuff in the browser. what i'm looking for is a bunch of processors used in the wiki, for rendering code blocks with syntax highlighting.
[05:42:08.893388]<osimons>same thing - should make it work both places.
[05:44:38.907230]<osimons>otaku42: what is the apache mime-type in pygments?
[05:44:59.263669]<otaku42>osimons: phone again *sigh*
[05:45:33.915605]<osimons>otaku42: there is also the pygments_modes setting where you can linke types and renderers
[05:45:51.645506]<osimons>s/linke/link
[05:45:51.693613]<evil_twin>osimons meant: otaku42: there is also the pygments_modes setting where you can link types and renderers
[05:45:59.992408]<cboos>osimons: that's what major updates are for - the only 5 minutes time span in a year where you can get people's attention to read the upgrade notes ;-) Seriously, if the change is for more simplicity and homogeneity, it's perhaps worth it. I admit I'm a bit scared by that last attachment on #5525. I trust Remy to know the code is correct and probably as minimal as it can get, to implement...
[05:46:01.869716]<cboos>...that relative-to-parent-ini feature. That's why I'm still undecided (and leaning again to the "mere textual inclusion" side ;-) ).
[05:46:21.611282]<otaku42>osimons: apache conf mimetype in pygments is text/x-apacheconf
[05:48:00.451314]<osimons>otaku42: well, text/x-apacheconf:apache in mime_map will make #!apache work
[05:48:08.618945]<osimons>settings should be all you need
[05:51:09.938371]<osimons>cboos: most of that patch is non-path related - related to change from inheriting one file => inheriting arbitrary number of files
[05:52:52.589462]<cboos>well, most of the *complexity* of the patch is related to keeping track of the original path of each of the included files, information that could completely go away if we were to do "inclusion logic".
[05:59:24.219019]<gozerbot>trac: Ticket #8889 (error: (111, 'Connection refused')) closed - <http://trac.edgewall.org/ticket/8889#comment:1>
[06:12:13.083721]<otaku42>osimons: back from another phonecall. thanks for the explanation about mime_map, will give that a try.
[06:18:49.465317]<osimons>cboos: could you help me understand why getpath cannot (reasonably) be cached as rblank says?
[06:19:04.712110]<otaku42>osimons: yay, it works!
[06:19:20.327097]<osimons>otaku42: of course it works :-)
[06:36:53.662325]<cboos>osimons: haven't looked at the details, but I guess it's related to invalidation (though a change in inherit should actually imply a full reload) - ask him on the ticket ;-)
[06:38:29.197246]<osimons>cboos: previewing now :-)
[06:39:51.200322]<cboos>you mean 0.12 previewing?
[06:39:56.418641]<cboos>wiki / ticket?
[06:45:37.002971]<osimons>cboos: previewing ticket - submitted now :-)
[06:46:13.385310]<cboos>ah, I thought you were playing with the new fancy wiki preview on trunk ;-)
[06:47:18.976056]<osimons>nah - seen it though, but other than getting things up and running (with some of my plugins) i haven't really had time to start reviewing features. yet.
[06:47:40.347870]<osimons>cool stuff though.
[06:48:12.425543]<cboos>hint: 0.12 fullblog with automatic preview :-) should be pretty easy to do (see #8855)
[06:48:42.607242]<osimons>yeah - i know. just the nicer expanding textarea would be nice :-)
[06:50:16.501826]<osimons>cboos: do you use my plugin btw?
[06:51:20.141580]<osimons>i'm somewhat more overwhelmed by how to start getting i18n/l10n going on that plugin.... at some stage... when i get inspiration....
[07:03:28.626442]<cboos>osimons: no, sorry I don't use it - but I might get you started on the i18n stuff, if you want (not now, but one of these days / evenings)
[07:03:52.209227]<osimons>yeah. no rush. thanks.
[07:08:54.191898]<macmaN>osimons: can i help with that?
[07:09:14.480236]<osimons>macmaN: patches welcome, of course :-)
[07:09:16.973589]<macmaN>i am about to start some plugins of my own and will have to dig deep into that anyhow
[07:09:49.146644]<macmaN>well, i could use some discussion etc what to do :)
[07:10:47.426349]<macmaN>have you opened some tickets on this already?
[07:10:59.736823]<macmaN>or should we perhaps schedule some /msg session for some time
[07:11:08.288158]<osimons>cboos has done it for the 0.12 mercurial plugin in the trac repos - was planning to review that to get a head start on what once things settle. could use another plugin as a proof-of-concept for trunk before 0.12 release though
[07:12:41.001634]<macmaN>i registered for transifex but that's only useful for setting up your own project translation right
[07:24:59.135348]<cboos>macmaN: looks like we're going to use transifex as well - at least try it out
[07:27:21.038127]<macmaN>can you just click on a language file and do work?
[07:27:38.908377]<macmaN>im not seeing that anywhere
[07:33:44.710413]<cboos>macmaN: not that simple; first we need to activate it ("allow submissions"), then we need to setup some dvcs backend to accept transifex changesets
[07:35:56.299078]<macmaN>ok
[07:36:11.784532]<macmaN>so just check out the po and commit back
[07:36:19.555408]<macmaN>in trac trunk
[07:53:33.875695]<cboos>macmaN: what's your target language?
[08:05:04.822308]<Sidnicious>How can I format a CamelCase word to bypass the wiki-linkage?
[08:06:05.455258]<cmc>backquotes should do it, though it'd also make the text monospace
[08:06:20.090367]<cmc>`CamelCase`
[08:07:03.645833]<cmc>oh, found it
[08:07:14.788812]<cmc>"You may avoid making hyperlinks out of TracLinks by preceding an expression with a single "!" (exclamation mark). "
[08:07:23.037826]<cmc>example: !NoHyperLink
[08:07:31.073933]<Sidnicious>cmc: Oh, awesome.
[08:07:38.453404]<cmc>:)
[08:07:41.788621]<Sidnicious>Thanks.
[08:10:26.625288]<macmaN>cboos: et_ee
[08:18:38.408110]<nicomen>hm, tried to use virtualenv as described in the dev setup but it overwrote my root site_packages when installing it :-(
[08:24:16.318697]<macmaN>installing what
[08:24:22.840090]<macmaN>did you do source bin/activate
[08:26:51.976226]<cboos>macmaN: ok, seems you'll be the first to contribute translations there; is everything clear in the L10N or do you think some parts could be clarified?
[08:29:25.663511]<gozerbot>trac: Changeset [8906]: 0.12dev: Ensure that only `POST` requests makes it to the new auto-preview ... - <http://trac.edgewall.org/changeset/8906>
[08:39:19.000118]<osimons>^^ yes, i have made a commit again :-)
[08:41:10.021254]<cboos>congrats for 12 ;-)
[08:41:22.184874]<cboos>(sounds better than for 0.12)
[08:41:48.712922]<osimons>are there perhaps any open tickets as well, cboos?
[08:42:24.461575]<cboos>you mean for the issue you just fixed? there was some discussion in #8855, but I failed to see that problem
[08:42:33.876507]<cboos>you could update the ticket with a note
[08:43:08.378587]<cboos>I don't dare imagine you were actually asking for some work to do :P)
[08:43:27.517121]<osimons>no - just a badly worded joke. in the vein of "if there was anything else i could do" :-)
[08:43:53.334231]<cboos>no, sorry, nothing currently...
[08:44:02.978931]<cboos>we're done
[08:44:08.534276]<osimons>cool
[08:44:10.004916]<cboos>everything works as it should
[08:44:12.460552]<jhammel>0.12?!?
[08:44:13.654131]<cboos>if not better ;-)
[08:44:38.081043]<cboos>jhammel: we're in still in <sarcastic> mode ;-)
[08:44:57.393925]<jhammel>cboos: oh, sorry, forgot to check modes
[08:45:15.814592]*jhammel sets mode -sarcasm cboos, osimons
[08:45:30.103827]<cboos>:-(
[08:46:13.030757]<cboos>reality looks less brittle ... if we can still get a beta1 this year, I'll be happy ...
[08:46:54.444522]<cboos>s/brittle/bright/
[08:46:54.456448]<evil_twin>cboos meant: reality looks less bright ... if we can still get a beta1 this year, I'll be happy ...
[08:47:08.546468]<cboos>(my english is still far from ideal ;-) )
[08:48:02.435569]<macmaN>cboos: right, im lkraav from et_ee ticket, forgot the #
[08:48:28.845690]<macmaN>cboos: i think L10N is pretty clear, my understanding is i just take the .po and whip up new lines
[08:49:25.280047]<cboos>macmaN: well, once you generate the new .po that is, don't start with the old one, the one currently checked in!
[08:49:33.736337]<cboos>hello Remy
[08:49:39.040675]<rblank>osimons: Quick question: could you explain why http://trac.edgewall.org/changeset/8906 was necessary?
[08:49:50.761154]<macmaN>cboos: okey, i think i need refocus on the L10N page then :)
[08:49:56.436164]<macmaN>i just said that off the top of my head
[08:49:58.223459]<rblank>cboos: Hi Christian!
[08:50:03.756225]<macmaN>ill finish patching the custom query panel
[08:50:09.111279]<macmaN>then take a look
[08:50:33.444207]<osimons>rblank: even if user has no permission for that trac, he/she can still render wiki formatting from it - execute macros++
[08:50:50.197312]<cboos>yes we both discussed that (r8906) together and thought that it wouldn't be good to open the wiki rendering to any anonymous ...
[08:51:09.695732]<rblank>But shouldn't that be a permission check, then'
[08:51:11.146704]<rblank>?
[08:51:19.849646]<cboos>there's no proper permission that came up to my mind...
[08:51:26.226330]<rblank>Thing is, allowing GET was useful for testing in the browser.
[08:51:34.677597]<osimons>well, if you have a form and a token, then that means you have some rendered page
[08:51:40.836420]<rblank>Is there a generic permission for POST?
[08:51:43.469109]<cboos>so I thought that limiting to POSTs would already limit the damages (re CSRF token)
[08:51:48.828194]<rblank>s/permission/permission check/
[08:51:48.840953]<evil_twin>rblank meant: Is there a generic permission check for POST?
[08:52:11.552509]<rblank>Ah, got it.
[08:52:12.956902]<osimons>token more important - to avoid abuse from non-trac context
[08:52:15.651886]<osimons>yup
[08:52:17.643701]<cboos>no, well except the check for the token
[08:52:41.125481]*osimons takes kids to training. later.
[08:53:08.213232]<rblank>And the check for the token is done for all POSTs, right?
[08:53:19.197183]<cboos>yes, I think so
[08:53:23.097000]<cboos>... but you could add a line checking for TRAC_ADMIN, like we do for the hdfdump (same idea of a debug mode)
[08:53:27.242221]<rblank>(Don't have the sources at hand)
[08:53:54.492518]<rblank>Ah, good idea. Allow GET only if TRAC_ADMIN.
[08:53:59.602569]<cboos>i.e. something like: ... and (req.method == 'POST' or 'TRAC_ADMIN' in req.perm)
[08:54:01.614722]<cboos>yes
[08:55:15.035988]<cboos>macmaN: you can skip the extract step, as the current messages.pot (as of today) is up-to-date, but you definitely need to update the et messages.po file
[08:55:22.953445]<mbuf>does anyone have any documentation/tutorial on setting up trac wiki on Fedora 12?
[08:55:32.481105]<rblank>Cool. But the permission check should be done in process_request(), not in match_request(), right? For better performance.
[08:55:47.146447]<macmaN>mbuf: trac web is filled with setup instructions
[08:55:50.250551]<rblank>...in the case where the path is not /wiki_render
[08:55:55.195565]<macmaN>mbuf: it cannot be bested here
[08:55:59.552679]<mbuf>macmaN, ok
[08:56:53.492302]<cboos>rblank: it's not critical in this case, I think
[08:57:46.422315]<rblank>Gotta go. Catch you later!
[08:57:48.192967]<cboos>rblank: we've already past the match for /wiki_renderer, so presumably no other request processor will have to take it ;-)
[08:57:58.110249]<cboos>ok see you this evening - maybe
[09:00:06.004631]<bionoid>cboos: Doing some work on the model tonight, may publish it today. I'm having some performance problems with the merged revisions view though, about 10 seconds runtime looking at 300k rows. But I guess you should move to postgres in this case anyway ;-)
[09:02:04.810388]<cboos>hello bionoid, sounds interesting, but what's the "merged revisions view"? revisions as in changesets, or history page of wiki, or... ?
[09:03:00.404993]<bionoid>cboos: Oh, guess that needs explanation :P It's modelled similar to your GenericTrac so there is a revisions_$datatype, ie text, numeric, list, dict, .. and the VIEW simply UNION's all those tables.
[09:03:44.848026]<bionoid>The obvious optimization is of course to not use the view and query the tables directly for each datatype, which is much faster, but also less practical.
[09:04:24.459622]<cboos>ah - but that will get you heterogeneous datatype if you do an UNION in sql ... is that what you do?
[09:04:48.817757]<bionoid>To clarify, that would be revisions for all resource types, so ticket, milestone, wiki, etc.
[09:05:06.123888]<cboos>I rather had in mind the second option you mentioned, several queries and merge the results in memory, in the python object model
[09:05:07.826052]<bionoid>Yes you get it in "atomic" format, limited to keyname+value
[09:05:34.720994]<bionoid>If the datatype (like forum) implements more columns, it is represented in some smart way, like post number + post revision for comments.
[09:06:17.005845]<bionoid>cboos: In general I would choose to do that in a VIEW over code any day of the week.
[09:06:54.036620]<bionoid>But SQLite has some trouble with JOIN performance for large datasets, it seems. It's plenty fast enough for a small set.
[09:07:29.939967]<cboos>yes, that works OK in SQLite (except maybe perf for lots of rows), but isn't that much trouble in the other more strict backend (vs. the heterogenous types)?
[09:07:37.755914]<macmaN>mod_wsgi Q: if i have python setup.py develop for trac-src and i alter templates, do i still have to manually reload apache for each change to show up?
[09:07:54.939267]<cboos>[trac] reload_templates = true
[09:08:00.442090]<macmaN>thx
[09:08:06.402196]<macmaN>hadnt noticed that
[09:08:53.067102]<cboos>macmaN: wait...
[09:08:56.533617]<bionoid>cboos: Well, view or no view, I will clean up some other stuff and try to get it out :)
[09:09:01.255970]<macmaN>cboos: is it a big performance hit to leave on?
[09:09:13.703633]<macmaN>and i notice it didnt work
[09:09:19.450475]<cboos>no, not really, but it looks like it's not that name (got it from memory)
[09:09:34.866386]<cboos>[trac] auto_reload = true
[09:09:38.090207]<macmaN>auto_reload yes
[09:09:40.460569]<cboos>that's the correct one
[09:09:41.599831]<macmaN>just looked myself
[09:09:43.031358]<cboos>yes ;-)
[09:12:16.296171]*retracile grunts something derogatory about mornings.
[09:12:48.819732]<macmaN>is this <span> inside <h1 class="foldable"> that is stopping this
[09:13:04.269837]<macmaN>collapsing action. i have the $ call in js
[09:13:14.763997]<mbuf>macmaN, got it! yum install trac mod_python; trac-admin project initenv; tracd --port 8000 project
[09:13:33.373294]<macmaN>mbuf: u iz geniuz
[09:13:52.558806]<mbuf>later
[09:14:04.565840]<jhammel>hah!
[09:17:12.056888]<macmaN>crap. its not the span.
[09:17:43.527680]<jhammel>macmaN: are you including the folding.js (or whatever the JS file is called)?
[09:18:43.178503]<macmaN>or maybe it is, for some reason it refuses to move out of h1
[09:18:51.344134]<macmaN>there are other blocks on the page collapsing
[09:18:56.566852]<macmaN>so foldable works for sure
[09:19:15.623026]<macmaN>i have the <span class="numrows">(10 matches)</span>
[09:19:19.976127]<macmaN>inside the h1 right now
[09:19:23.422139]<macmaN>ticket modify doesnt have that
[09:19:41.949278]<macmaN>maybe thats why foldable pukes
[09:23:05.142308]<macmaN>got span out, but custom query h1 does not get the folding action
[09:25:32.827637]<macmaN>hmm, there is some enableFolding call also
[09:38:17.199244]<macmaN>wtf how the heck do you do this
[09:41:02.117849]<macmaN>there isnt a restriction of collapsing collapsable fieldsets is there
[09:41:58.564132]<jhammel>macmaN: quite possibly....not sure
[09:42:17.278876]<jhammel>macmaN: i've only used folding fieldsets, FWIW
[09:42:30.748129]<macmaN>well Modify Ticket is a folding div
[09:42:34.836144]<macmaN>in 0.12
[09:42:43.489153]<macmaN>no nm its 0.11 too
[09:43:12.552590]<macmaN>or.. hrm
[10:25:22.909313]<macmaN>ok auto_reload doesnt seem to have any effect in 0.12dev-r8877
[10:36:58.416985]<macmaN>nm, configuration issue
[10:50:14.420472]<macmaN>ok i have a working foldable div in 0.12
[10:50:29.081520]<macmaN>for some reason it doesnt want to be initially collapsed tho
[10:51:23.364654]<jhammel>macmaN: IIRC, you have to call a function for that (can't recall the details)
[10:51:39.571940]<macmaN>$("#querypanel").toggleClass("collapsed");
[10:51:39.764618]<macmaN>im doing it
[10:52:01.046987]<macmaN>#columns fieldset does that and sits there collapsed like it supposed to
[10:53:16.015321]<macmaN>http://dpaste.com/133302/
[10:53:21.845206]<macmaN>if you have a moment, id appreciate it
[10:53:27.805274]<macmaN>its the diff
[10:54:10.243520]<macmaN>im not sure if i have to put class="collapsed" on div
[10:54:24.366816]<macmaN>ticket modify box doesnt
[10:55:21.231113]<macmaN>did 0.12 center ticket editing?
[10:55:28.107812]<macmaN>um, i mean the latest revs
[10:55:32.890448]<jhammel>god, i hope not!
[10:55:38.174095]<macmaN>all of a sudden ticket editor is centered
[10:55:47.291992]<macmaN>went from 8877 -> 8905
[10:55:59.479859]<macmaN>cboos and them worked on the live previews
[10:56:14.254852]<macmaN>and i read the ticket discussions, but i cant remember if they ended up centering this
[10:56:26.957834]<jhammel>bah, that would be awful
[10:58:45.833386]<macmaN>ahh lovely, i fixed it
[10:58:56.730839]<macmaN>needed that .parent() on toggleClass
[11:09:01.881803]<macmaN>trac web doesnt run xmlrpcplugin?
[11:12:17.941172]<macmaN>i am not entirely sure why the table header is displayed for each component
[11:12:28.124309]<macmaN>cluttery imho
[12:29:28.539841]<gozerbot>trac: Ticket #8890 (Can't add BROWSER_VIEW with blank repository_dir in trac.ini) created - <http://trac.edgewall.org/ticket/8890>
[12:46:28.710963]<macmaN>jhammel: div #content .ticket has been auto-margined indeed
[12:47:00.370601]<macmaN>after years of align-left it's uhhhhh.
[12:47:04.229410]<macmaN>a strange feeling.
[12:48:01.905294]<macmaN>r8891 is the source
[12:49:27.174520]<macmaN>i dont see this in #8721 discussion at all, not sure when cboos came up with it
[12:51:18.990776]<jhammel>macmaN: :(
[12:51:33.603240]<jhammel>that will not make my TicketSidebarProvider happy :(
[12:53:50.060155]<macmaN>allright im done for the night
[12:54:47.501433]<lisppaste5>milmazz pasted "trac bitten svn-authz" at http://paste.lisp.org/display/92099
[13:03:29.789210]<milmazz>Hi, i'm trying to use bitten + trac, but i got "Permission denied" messages.
[13:04:22.766160]<milmazz>if i disabled svn authentication (digest) everything works fine.
[13:12:09.187685]<lisppaste5>milmazz pasted "bitten recipe" at http://paste.lisp.org/display/92104
[13:13:08.618920]<osimons>milmazz: one channel is enough, please. stop pasting and writing here and let's do this in bitten channel
[13:20:19.815063]<lie2815>hi. is there any way to integrate a php script into a trac template? i want to integrate trac into my php site...
[16:14:43.112762]<sgrover>I'm getting odd behavior reported. One of my dev's says he is getting "to many redirect" errors when trying to login. I can log in with no issues. Only difference between our setup's is that he is coming across the Internet, and I'm on the local network.
[16:14:50.643836]<sgrover>Any thoughts how to diagnose/fix this?
[16:15:15.136256]<rorsini>is there a way to ignore displaying files with a certain extension in changesets? my use case is that someone check in a pickled python file (which it sounds like they "need" in svn) but trying to display changes to it with Trac brings Firefox to its knees. looking for any ideas or constructive input. thanks!
[16:15:49.583627]<rorsini>*"...someone checkED in..."
[16:21:49.570888]<sgrover>regarding the login issue for my dev. I'm seeing a lot of this entry in the logs: WARNING: Attributes for session dev2 already updated: Error binding parameter 3 - probably unsupported type.
[16:23:04.458297]<sgrover>I've since set logging to DEBUG, but am waiting for him to try again.
[16:31:29.493088]<kisielk>you can try deleting his session from the database
[16:31:35.784331]<kisielk>if it still doesn't work
[16:35:30.603586]<sgrover>kisielk: I was just looking at the database. The error seems to originate in the session.py file (http://svn.edgewall.org/repos/trac/trunk/trac/web/session.py - search for 'Attributes for session').
[16:35:52.987995]<sgrover>so took a look at the related "session_attribute" table and discovered two things.
[16:36:03.169533]<sgrover>first, I didn't have sqlite 3 installed on my server.
[16:36:18.114373]<sgrover>second, it was trying to force him to reset his password.
[16:36:31.100623]<kisielk>interesting
[16:36:39.041943]<kisielk>so you use the internal auth mechanism?
[16:36:44.753189]<sgrover>I just changed his password manually, and will get him to try again.
[16:36:55.386583]<sgrover>htpasswd, and AccountManager
[16:37:53.397713]<sgrover>AccountManager has caused problems for me before if notifications are enabled. I'm "assuming" for now that this is a related issue.
[16:41:20.155988]<kisielk>could be
[16:41:34.350132]<kisielk>sounds like something is trying to update the sessions table incorrectly
[16:51:44.852094]<sgrover>found the problem. Got another account to work through this with me.
[16:52:36.962392]<sgrover>Turns out that if you use the "Forgot My Password" option on the AccountManager login page triggers this problem.
[16:52:44.384986]<sgrover>The email goes out, but then login fails.
[16:53:25.407033]<sgrover>it gets into a redirection loop.
[16:53:43.639826]<sgrover>But, changing password through the Preferences link, works fine.
[16:57:09.345370]<sgrover>I know how to get him over the hurdle now though. I'll look at the AccountManager page and see if I can add a bug ticket.
[17:00:26.193224]<sgrover>bug already exists for this. http://trac-hacks.org/ticket/3233
[22:50:22.795885]<macmaN>ulllallaaaaa