Team Chat Logs

March 8, 2010

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

[00:06:01.545067]<otaku42>macmaN: please post your idea as a feature request ticket on t-h.o. i may consider that at some time, but most probably it not "today or tomorrow"
[00:06:15.282506]<otaku42>moin all, btw
[00:06:43.210546]<macmaN>howdy
[00:06:58.340560]<macmaN>looking to find out if its worth posting
[00:07:02.734068]<macmaN>i guess it is
[00:08:13.426850]<macmaN>component TracHacks right
[00:09:01.028341]<otaku42>macmaN: aye
[00:18:38.049053]<gozerbot>trac: Ticket #9117 (AttributeError: 'TicketSystem' object has no attribute ...) created - <http://trac.edgewall.org/ticket/9117>
[00:48:38.926678]<gozerbot>trac: Ticket #9117 (AttributeError: 'TicketSystem' object has no attribute ...) closed - <http://trac.edgewall.org/ticket/9117#comment:1> || Ticket #9118 (embedded .xls or .doc files) created - <http://trac.edgewall.org/ticket/9118> || Ticket #9115 (hide cc: email-address better from other users) closed - <http://trac.edgewall.org/ticket/9115#comment:1> || Ticket #9114
[00:48:43.878387]<gozerbot> (cc: offer username instead of email-address when log in) closed - <http://trac.edgewall.org/ticket/9114#comment:1>
[01:18:39.096841]<gozerbot>trac: Ticket #9118 (embedded .xls or .doc files) closed - <http://trac.edgewall.org/ticket/9118#comment:1>
[01:23:20.484169]<unregistered>where can I find out what's coming in version 0.12?
[01:24:59.644843]<kirean>unregistered: http://trac.edgewall.org/milestone/0.12
[01:25:30.484796]<unregistered>kirean: hah doh of course
[01:25:33.180870]<unregistered>kirean: thanks
[01:25:49.542577]<kirean>unregistered: np, good luck
[02:35:37.349969]<otaku42>RaceCondition: to answer your earlier question: "svn co http://trac-hacks.org/svn" would do the trick. but please keep in mind that this causes a fair amount of traffic, so you shouldn't do that on a regular basis (unless you want find yourself banned from accessing the subversion repository at all)
[02:36:14.631278]<macmaN>whats the size of the repo?
[02:36:18.430785]<RaceCondition>otaku42: yup, I actually figure it out *already* :D but yeah, no plans to regularly keep doing that
[02:36:36.212013]<RaceCondition>otaku42: I did that to be able to conveniently browse the existing code for examples
[02:36:56.694495]<RaceCondition>i.e. grep for "filter_stream" to see how ITemplateStreamFilter should be used, etc
[02:37:24.915844]<otaku42>macmaN: on the server's hdd the whole repository has 321mb
[02:38:12.425783]<macmaN>ok not too bad
[02:52:20.262798]<Tobias|>With the priorities for tickets, whats blocker?
[02:52:43.103637]<macmaN>otaku42: has anyone give any plugin provisioning interface thoughts? some better way to manage your plugin installation inside trac, check for updates, browse for new etc
[02:53:07.439665]<macmaN>otaku42: i.e. are you aware of specific tickets, discussions etc or should i go search for them
[02:59:03.920280]<otaku42>macmaN: i vaguely remember that there was some discussion about means to make plugin installation and updates easier. but i don't recall where it took place.
[02:59:11.377983]<RaceCondition>is Alec Thomas (sometimes) here?
[02:59:25.288643]<macmaN>!seen athomas
[02:59:25.298756]<evil_twin>no logs for athomas
[02:59:38.497553]<macmaN>what was his nick
[02:59:43.414439]<otaku42>RaceCondition: rarely.
[02:59:49.959696]<otaku42>!seen aat
[02:59:49.967443]<evil_twin>aat was last seen on irc.freenode.net at Wed, 03 Mar 2010 11:49:42 +0100, joining #trac
[03:00:00.545043]<otaku42>macmaN: ^^^^
[03:00:05.246566]<RaceCondition>otaku42: OK, I'll just contact him via e-mail
[03:00:11.898557]<macmaN>werd
[03:02:25.167271]<RaceCondition>...there are 43 Alec Thomases on Skype
[03:02:32.730918]<macmaN>!seen avr
[03:02:32.741132]<evil_twin>no logs for avr
[03:02:38.600661]<macmaN>!seen hvr
[03:02:38.608511]<evil_twin>hvr was last seen on irc.freenode.net at Tue, 16 Feb 2010 08:21:38 +0100, joining #trac
[03:05:05.379817]<macmaN>hvr knows stuff about GitPlugin, instantly key guy
[03:05:16.924368]<macmaN>:)
[03:18:38.334119]<gozerbot>trac: Changeset [9333]: css: .trac-nav and .trac-topnav links shouldn't appear on print. - <http://trac.edgewall.org/changeset/9333>
[05:54:02.759697]<macmaN>otaku42: where's the t-h.o upgrade strategy described? it would appear 0.11 upgrade has been planned forever, but it never gets done, i'm wondering why
[05:55:30.952416]<otaku42>macmaN: there is no description available.
[05:56:09.309205]<otaku42>macmaN: i'm working on the upgrade, and came pretty far. however, before fixing the last few outstanding issues a new heap of work in the office came over me, so i had to postpone the upgrade.
[05:57:28.624302]<macmaN>okay, thought i maybe could help in some way
[05:58:06.124177]<otaku42>macmaN: thanks for the offer, but i fear it will be hard for any third-party to help with the remaining issues.
[05:58:25.728286]<macmaN>right
[06:29:58.623785]<eto>hello i am new to this but would like to know
[06:30:33.348023]<eto>whether trac needs to unix socket path specified somewhere?
[06:30:39.961497]<eto>*have
[06:30:58.434913]<eto>i am using lighttpd
[06:31:38.236485]<eto>and i want /tmp/trac-fastcgi.sock reside in /var/run/lighttpd/trac-fastcgi.socket
[06:31:42.620352]<eto>is that possbile?
[06:45:47.516484]<eto>anybody please?
[06:53:51.021765]<macmaN>im doing mod_wsgi
[06:56:24.364488]<kirean>eto: I'm also on mod_wsgi
[07:17:09.135206]<exarkun>This isn't how you should load data from a database: http://dpaste.com/169462/
[07:17:34.416375]<eto>thx guys
[07:17:49.048558]<eto>at least some interaction
[07:18:39.319769]<gozerbot>trac: 0.12/TracGuide edited - <http://trac.edgewall.org/wiki/0.12/TracGuide?version=2> || 0.12/TracGuide created - <http://trac.edgewall.org/wiki/0.12/TracGuide?version=1>
[07:19:32.333076]<kirean>eto: people here are really helpful, you've just have to wait until they are available
[07:26:34.613256]*retracile mumbles something incontrovertible about mornings.
[07:50:49.011543]<tenaglia>anyone using RPMs to manage plugin installations ?
[07:51:15.115558]<macmaN>nope
[07:51:33.003368]<macmaN>although i cant probably speak for this anyone
[07:51:39.637311]<tenaglia>is it a suggested way to proceed ? I have to keep multiple load balanced servers in sync
[08:34:13.724648]<heavy>just installed trac 0.11.5 and I'm seeing the logout issue (where it doesn't log you out). is there a plugin or documented way to fix this for this version?
[08:36:01.045444]<retracile>heavy: I assume you're using http auth; in that case the browser caches the credentials so you can't really logout unless you close the browser. Look into the AccountManagerPlugin's form-based login to get a true logout.
[08:36:59.621845]<heavy>retracile: i see a note on the plugin page saying it doesn't work with 0.11.4, does that mean it will work with 0.11.5?
[08:37:46.634457]<retracile>I'm using it with 0.11.5 here.
[08:38:02.335178]<retracile>(Hadn't seen anything about it not working with 0.11.4 though)
[08:47:18.186346]<macmaN>whats the solution for auth and rss
[08:47:51.204126]<macmaN>afaik only way to get stable auth for everything is to use http auth
[08:48:17.170958]<macmaN>if you use form auth, then you cannot hide timeline
[08:48:39.200349]<gozerbot>trac: Ticket #9110 (display of eligible changesets is broken when source newer than target) closed - <http://trac.edgewall.org/ticket/9110#comment:2> || Changeset [9334]: TracBrowser: pick correct version for the source context, needed among ... - <http://trac.edgewall.org/changeset/9334>
[08:53:56.116531]<heavy>stupid question, but where is trac.ini on ubuntu?
[08:54:40.593910]<retracile>heavy: in the conf subdirectory of the trac environment you created.
[08:54:46.285143]<jhammel>heavy: do you know where the projects directory is? (i don't on ubuntu, i install by source)
[08:55:11.456738]<heavy>found it, didn't realize it was specific to the project
[08:56:13.074166]<heavy>the empty /etc/trac dir threw me off
[08:56:32.888047]<heavy>arg, can't get http auth to turn off
[08:59:42.692908]<heavy>i put trac.web.auth.loginmodule = disabled into trac.ini but i'm still getting the http auth
[08:59:56.060432]<heavy>after restarting apache and my browser
[09:00:08.367069]<Spec>heavy: that'd probably be in the apache configurations
[09:00:40.095725]<heavy>hmmm, methinks you may be right
[09:02:32.025758]<heavy>ok, i'm at the form login now, but my password doesn't work :)
[09:03:37.118290]<retracile>heavy: you'll need to configure the account manager stuff. there should be docs on the plugin's page.
[09:04:29.044191]<heavy>the docs are good, its just kind of all over the place
[09:05:53.264619]<jhammel>yeah
[09:06:06.029876]<jhammel>i'd love to see more docs/effort into common configuration scenarios
[09:06:07.460585]<jhammel>recipes
[09:18:37.257239]<macmaN>has anyone looked at http://trac.edgewall.org/report/25 lastmodified column
[09:18:39.273039]<gozerbot>trac: TracOnWindowsIisAjp edited - <http://trac.edgewall.org/wiki/TracOnWindowsIisAjp?version=28>
[09:32:15.997973]<retracile>macmaN: heh. nice.
[10:01:13.992323]<DaMato>is there a known problem with AccountManagerPlugin and email verification? my users are not getting the verification email until they press "resend email verification"?!?!
[11:12:10.364863]<cboos>osimons: hello, did you have some time to test 0.11.7rc1 yet? (well, anyone can answer actually ;-) )
[11:12:51.770311]<osimons>hi cboos. no, i haven't installed it. let me check what rev i'm acutally on.
[11:13:55.835853]<osimons>cboos: i'm on 0.11.7stable-r8997 - and have been for some time. anything major i'm missing?
[11:14:01.054725]*osimons checks revision log...
[11:15:37.300743]<cboos>nothing that critical, but still a few changes in some sensible areas
[11:16:19.923458]<cboos>r9203, r9252
[11:16:34.653701]<osimons>perm cache, i suppose. yeah 9203
[11:17:05.943920]<cboos>and I'd like to get some feedback on two patches before committing them...
[11:17:19.061620]<cboos>those for #9103 and #9104
[11:17:32.807214]<cboos>http://trac.edgewall.org/ticket/9103#comment:3
[11:18:17.641936]<cboos>and for #9104, while I prefer the second patch, I wonder if there could be some unexpected errors with it
[11:19:19.323435]<cboos>so maybe the first patch for 0.11.7dev and the second for trunk ...
[11:20:55.650505]<osimons>about t9104, why do we need to catch this? isn't the explicit error better? they aren't allowed to be used anyway?
[11:21:57.063908]<cboos>IIRC, the error could simply sometimes happen, in case of concurrent requests
[11:22:48.949670]<cboos>(in a way that can't be easily avoided)
[11:22:54.938427]<cboos>cf. http://trac.edgewall.org/ticket/3563
[11:24:46.891945]<osimons>and t9103, i think i've only seen systematically on fcgi? i have no preference there, but i suppose it is to late in the cycle to leave the handling "user-configured" in the server/entry script?
[11:25:23.121793]<osimons>- seeing all logging would be done etc. right.
[11:25:46.548140]<cboos>what do you mean? to allow for logging that error?
[11:25:59.311663]<cboos>isn't such an error always "noise"?
[11:26:12.372067]<cboos>(i.e. you can't do anything about client disconnects)
[11:28:15.433233]<osimons>cboos: yeah, it is noise. i meant it has to be fixed inside the dispatcher so that we can avoid logging.
[11:28:48.936264]<Spec>So, anyone use any templating in trac? If so, which templating module is best? :)
[11:29:25.402827]<cmc>what do you mean?
[11:29:32.728748]<cboos>osimons: ah, catch that in the lower layers... but what if it's not fcgi specific? Couldn't that happen with tracd also,for example?
[11:29:38.459511]<cmc>Spec: genshi does most everything
[11:30:09.867039]<Spec>cmc: I mean, templates for trac tickets. Like, select->"User Password Reset Request" and it auto-fills some variables, and puts some boilerplate text into the ticket field that the user can then edit, that sort of thing.
[11:31:05.163848]<cmc>ah. I have not used those
[11:32:05.046726]<osimons>cboos: can't say really. can't recall seeing it in my Apache logs, and my project-logging is rather minimal so i don't have anything there...
[11:34:56.155197]<osimons>cboos: i'll try to get production updated later tonight. got a few other things pending there too, so about time really.
[11:35:27.070715]<cboos>ok, thanks for the feedback... now I'm really wondering if I should not just move those to 0.12dev and leave 0.11.7 as it is, and make the release
[11:36:04.796440]<cboos>I'm always a bit hesitant about this kind of last minute change ;-)
[11:36:27.094256]<cboos>(call me chicken)
[11:36:51.084863]<cboos>... but I really don't want to hear about 0.11.8 :-)
[11:37:20.702112]<osimons>yeah. see that. but why then rush out 0.11.7 now? i don't quite see the urgency?
[11:40:06.958514]<osimons>well, 3 months since 0.11.6. however, i am quite sure there will be a next 0.11.x release seeing 0.12 is not out the door yet...
[11:40:29.537232]<cboos>well, no real urgency, but just "normal" release schedule, those little bugs are merely annoyances, not real issues and the 0.11.7rc1 testing period is over
[11:40:51.180441]<cboos>it's really time to make that last 0.11.x release, so that we can fully focus on 0.12
[11:41:25.293884]<osimons>we released 0.10.5 at ~ same time as 0.11.0
[11:41:43.358249]<osimons>(beta + rc periods of 0.11 was completed)
[11:42:34.487759]<osimons>i am certain there will be issues popping up in 0.11.x as well once we start with beta + rc runs and production upgrades for 0.12...
[11:42:48.037882]<cboos>well, that was just a coincidence, there's no need to have such paired release
[11:43:30.860344]<cboos>I'm not really sure there's anything we'll want to fix in 0.11 after 0.11.7 (knowing I was already saying that for 0.11.6 ...)
[11:43:55.459816]<cboos>... unless someone steps up as a maintainer that is (and you're welcome to do that!)
[11:45:18.150818]<cboos>the point is that I'm now eager to get started with 0.13, so I'd like to wrap up 0.12 (and even more so 0.11, you can imagine)
[11:45:58.977484]<cboos>and I'm quite sure Remy feels the same ;-)
[11:46:15.981717]<cboos>0.12 has again taken a tad bit too much time
[11:52:37.504845]*retracile wishes he could have contributed more to 0.12 :/
[11:53:00.811129]<cboos>well, just pretend you don't like even numbered release numbers ...
[11:53:07.675732]<cboos>and start contributing again for 0.13 ;-)
[11:54:46.158645]<retracile>cboos: heh :) I intend to try. :) The ticket workflow + preview stuff needs some rework, and I hope to make time to do it.
[11:56:25.258641]<cboos>retracile: ... and with an eye on generalizing the workflow stuff, would be even better ;-) So that we could have milestone workflow and wiki workflow.
[11:57:54.079831]<retracile>cboos: the heart of the problem with the ticket workflow preview is that we aren't tracking the workflow changes separate from the user's changes; they get mashed together for the preview, and then we can't separate them out later. So I don't really see the changes there working toward generalizing the workflow to milestones and wiki.
[11:58:31.586071]<cboos>Well, no, that was not necessarily related
[11:58:33.938308]<cboos>though...
[11:59:02.050882]<cboos>if you consider status changes to be something independent from any other change...
[11:59:26.830855]<retracile>cboos: I don't really think they are...
[12:02:32.463631]<cboos>well, IIRC the problems come when you do some changes, which in turn trigger secondary changes, eventually in contradiction from the initial user changes. Maybe making explicit the two levels is the key to the solution.
[12:02:52.222468]<cboos>i.e. the preview will show the first set of user changes, then the follow-up changes
[12:03:05.821359]<cboos>and the user can anticipate the eventual conflict
[12:03:41.229150]<cboos>but if he really wants to apply them, then there are just two sets of changes happening
[12:03:57.501339]<retracile>cboos: Well, the data structure behind the scenes must keep them separate, even if the presentation combines them. Right now, we combine them in the data structures, leaving us unable to separate them out later (such as when the user chooses a different workflow action from what he previewed the first time.)
[12:04:03.479527]<cboos>the first user initiated ones, followed by the "automatic" changes.
[12:04:47.885618]<retracile>I'd like the preview to show the final result of the ticket, including workflow changes, if I can manage it.
[12:06:50.131260]<osimons>cboos: if so, more important than "final" releases of 0.11.x is getting 0.12 to beta/rc so that we can recommend upgrading.
[12:07:11.337131]<osimons>- lots of tickets for 0.10.x were closed with "upgrade" as recommended solution....
[12:18:41.980454]<gozerbot>trac: Ticket #9119 (import svn. I just click on import) closed - <http://trac.edgewall.org/ticket/9119#comment:1> || Ticket #9104 (reuse of a closed cursor) closed - <http://trac.edgewall.org/ticket/9104#comment:3> || Changeset [9336]: web: avoid using a cursor after the connection from which it depends has ... - <http://trac.edgewall.org/changeset/9336> || Ticket
[12:18:47.021007]<gozerbot> #9103 (req.write can trigger spurious errors related to client disconnects) closed - <http://trac.edgewall.org/ticket/9103#comment:4> || Changeset [9335]: Trap socket errors in case of client disconnects during calls to ... - <http://trac.edgewall.org/changeset/9335> || Ticket #9119 (import svn. I just click on import) created - <http://trac.edgewall.org/ticket/9119>
[12:29:16.389298]<jdingman>does trac require that svn is installed?
[12:30:24.920608]<cmc>no
[12:30:36.133678]<cmc>you don't need any versioning system
[12:30:42.881624]<cmc>or you could use one of: http://trac.edgewall.org/wiki/VersioningSystemBackend
[12:31:01.899079]<jdingman>thanks
[12:32:39.320457]<DaMato>re
[12:34:38.345430]<DaMato>anyone here having an insight view on the AccountManagerPlugin? I am having a problem with it where email notifications are not sent out :(
[12:36:23.811179]<cmc>pacopablo maintains it, but I don't know if (s)he is available
[12:37:49.449859]<DaMato>I am getting errors like:
[12:37:50.953712]<DaMato>2010-03-08 21:35:01,325 Trac[api] INFO: Email verification requested user: test
[12:37:51.080052]<DaMato>2010-03-08 21:35:01,340 Trac[notification] INFO: Email address w/o domain: test
[12:37:51.147872]<DaMato>2010-03-08 21:35:01,341 Trac[notification] INFO: no recipient for a ticket notification
[13:07:31.376070]<DaMato>ah ok. accountmanagerplugin seems to interfere with the usermanagerplugin.. damn
[13:36:15.457963]<Spec>damn ... the template plugin is for new tickets, ... it doesn't template comments for tickets :(
[13:37:30.897080]<groogs>Trac pegs out apache for me when accessing changesets, and takes a long time to respond. If I do a diff across a couple changesets, it effectively hangs (i've never had the patience to wait for it, 10+ minutes anyways). Otherwise it's pretty snappy. (PentiumD 3.0 ghz, 2GB ram, ubuntu 9.10, only trac+svn run on this). only thing I can think of is there's about 12k revisions, and though i have...
[13:37:32.371178]<groogs>...fsfs, sharding is not on. Should sharding improve this, or is there something else to try?
[13:38:02.842286]<groogs>oh yeah.. mod_python, apache 2.2, sqlite3, trac 0.11.6
[13:51:39.124334]<kisielk>groogs: how big are your changesets?
[13:52:07.404594]<kisielk>I've seen it choke on really large changesets
[13:52:33.380557]<bionoid>groogs a 0.12 upgrade would probably do you good, 0.11 syncs the repo for every single web client request (0.12 it's done exclusively in post commit)
[13:52:51.613140]<kisielk>hm interesting
[13:53:09.375966]<bionoid>groogs An aside, my mod_python setup absolutely crawls compared to wsgi, but that's probably not your issue.
[14:10:37.248513]<groogs>kisielk: they vary, some are one liners, some are 40 files and a couple hundred lines
[14:11:09.022746]<groogs>actually, i think in particular, it's looking at merged revisions that's really slow. svn puts its merge-info stuff on several hundred files in that case
[14:11:44.709694]<groogs>bionoid: thats good to know, thanks.. though 0.12 isn't stable yet..
[14:15:46.951918]<bionoid>groogs well, strictly speaking neither is 0.11 ;-)
[14:16:38.200907]<groogs>ok, quick check, 1868 source files in the full project (which is comprised of several apps). so each merge revision will set merge-info on at least that many files
[14:17:15.300463]<groogs>bionoid: fair enough. though i'd say its "more stable" for whatever that is worth :)
[14:18:13.218794]<bionoid>groogs 0.11 stability is inveresely propotional to the number of installed plugins.. ;-)
[14:19:15.271512]<bionoid>if you don't run any (or they have .12 support) you should consider it :)
[14:19:45.237575]<groogs>i have quite a few
[14:21:35.486751]<bionoid>yeah me too, and a lot of custom hacks to the source, so I just run .12 in a local test env for now. It works well with what I've tried, but not going to switch any time soon..
[14:22:05.293886]<groogs>heres a bit more concrete example actually.. just pulling up a merge: 433 files modified, basically all of which were svn:mergeinfo. i actually can't find any source changes in this, but it's not clear, this may have just been a 'marked-as-merged' type change
[14:22:55.753249]<groogs>took 9m 1s to load according to firebug, all of which was spent 'waiting'
[14:24:43.328819]<groogs>i can't tell how big the response was, but i think about 85kb
[14:27:06.114798]<groogs>to contrast that, average load time for a ticket page is <2s
[14:30:01.681040]<Mitar>how can i reconstruct full url to a trac page in a plugin without req object?
[14:30:45.896295]<scfe>Mitar: you can't.
[14:30:47.728216]<bionoid>groogs Did you try to serve the env with tracd? It's usually worth a try to see if you can gain something with server config :-)
[14:31:44.869052]<groogs>bionoid: no, but i'll try that. i kind of hope it doesn't work, because i use apache auth_ldap, and i'll have to do some reverse proxy trickery if it does. :)
[14:31:54.410724]<groogs>i'll also check out wsgi, i have never tried that
[14:32:29.322151]<groogs>though, i have this feeling that i saw a huge speed increase a few years ago when i went the other way -- from tracd to mod_python
[14:32:44.444592]<bionoid>groogs Well tracd works, a switch to mod_wsgi might work too ;-)
[14:32:59.834367]<groogs>yeah, it's worth a shot
[14:33:20.260248]<groogs>i'm also going to try doing the svn sharding change, as it doesn't seem to have any negatives
[14:33:49.563882]<groogs>and the svn release notes say it starts to improve performance around "10000 to 15000 files.. I'm right in the middle of that number for revisions
[15:00:00.724151]<Spec>gah
[15:00:05.805114]<Spec>documentation for site.html (template) sucks :(
[15:03:50.208890]<cmc>what's the problem?
[15:04:13.492557]<Spec>I'm trying to add a javascript file to the <head> of the /ticket/ page
[15:04:27.862794]<Spec>and, what I have works ... but it repeats what I add twice, instead of just the once.
[15:04:52.031691]<Spec>http://trac.pastebin.com/BK7Wd6fi
[15:04:57.736244]<Spec>is what I have in site.html now
[15:05:23.203786]<Spec>but it says "TESTER TESTER TESTER TESTER" at the top of my '/ticket/#' pages
[15:08:44.134057]<Spec>and, all the documentation examples for site.html's crazy xml/genshi magic also end up repeating whatever-they-do twice
[15:09:20.715046]<cmc>Hm. They don't for me. Perhaps you have a plugin which is adding something funny?
[15:09:43.575216]<osimons>Spec: most likely something on your side that affects this double output
[15:10:06.081319]<Spec>well
[15:10:25.296000]<osimons>haven't look at the details of why it may happen, but there is a handy once="true" attribute that you could add to your py:match. it is useful to make sure things don't catch more than once, and also optimizes somewhat the rendering (speed)
[15:10:31.445727]<Spec>If i take out the text() part of ${select, it doesn't repeat it
[15:10:43.121616]<Spec>but then I lose various other things
[15:10:49.975368]<osimons><head py:match="head" py:attrs="select('@*')" once="true">
[15:10:54.234676]<cmc>osimons: nice
[15:11:07.474206]<Spec>yeap, tried that, it's not matching <head> twice
[15:12:13.604158]<Spec>Well, is there another way to add a javascript file to the <head> section of the /ticket/## page?
[15:13:33.012096]<cmc>would be pretty simple with a plugin. also, why not put the js in a file and link to it in the header
[15:13:43.092119]<cmc>then, if that link were repeated 100 times it wouldn't matter
[15:14:50.036471]<osimons>site.html really should work fine, Spec...
[15:15:12.677546]<Spec>so is it that I'm using select() wrong?
[15:15:42.286071]<cmc>there's also http://trac-hacks.org/wiki/AddStaticResourcesPlugin
[15:16:13.311318]<Spec>ah, well, that seems easier than site.html
[15:20:33.482500]<osimons>Spec: i only get TESTER TESTER once when trying your snippet
[15:20:52.156082]<Spec>could it be a theme-related-thing?
[15:21:42.705405]<Spec>hrm.....is AddStaticResourceComponent supposed to work with trac0.11? :)
[15:21:45.079949]<osimons>Spec: perhaps. don't know what you have, but i'm testing on plain trac installs (0.11 and 0.12dev)
[15:21:47.695485]<Spec>ERROR: Skipping "addstaticresourcesplugin = addstaticresourcesplugin": (can't import "cannot import name AddStaticResourceComponent")
[15:22:12.071236]<osimons>Spec: no clue. don't know that plugin. check tickets for it.
[15:23:36.510365]<Spec>heh, enabling it through admin side worked
[15:23:47.412357]<Spec>using documentation on plugin page to manually edit trac.ini didn't
[15:24:00.804957]<Spec>well, at least it's working. thanks for the pointers, i'll test theme/etc and track down the site.html issues myself, although, it's unneeded now
[15:24:09.594849]<Spec>it'd be nice to know what's causing that proble
[16:18:41.352667]<gozerbot>trac: Ticket #9120 (Documentation link to trac-post-commit-hook broken) created - <http://trac.edgewall.org/ticket/9120>
[18:18:46.872412]<gozerbot>trac: Ticket #9121 (bug report) created - <http://trac.edgewall.org/ticket/9121> || 222.jpg attached to TracFaq - <http://trac.edgewall.org/attachment/wiki/TracFaq/222.jpg> || 111.jpg attached to TracFaq - <http://trac.edgewall.org/attachment/wiki/TracFaq/111.jpg>
[22:18:42.691076]<gozerbot>trac: Ticket #9122 (Cannot create any ticket) created - <http://trac.edgewall.org/ticket/9122>
[23:18:44.033014]<gozerbot>trac: TortoiseSvn edited - <http://trac.edgewall.org/wiki/TortoiseSvn?version=16>
[23:49:54.219487]<cboos>coderanger: hello Noah, when joining #trac, I still see "#trac http://projects.edgewall.com/trac/", any idea how to change that to t.e.o?
[23:57:52.417616]<pacopablo>cboos: I think we need to get jonas to change that
[23:58:14.426689]<pacopablo>I think he's the only one with perms to change the welcome message