Team Chat Logs

March 4, 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:49.246269]<otaku42>moin
[00:38:45.414159]<macmaN>otaku42: yo
[00:39:00.519896]<macmaN>can i msg u a bit
[00:44:04.312854]<otaku42>macmaN: shoot - but be aware that i'll be pretty slow in answering, due to a lot of work in the office today
[00:46:56.835492]<DaMato>hi
[00:48:55.508311]<DaMato>anyone in having an idea why I get a "ProgrammingError: Cannot operate on a closed cursor." when installing the "TracHackergotchi" plugin?
[01:10:12.191871]<macmaN>im pretty sure that depends on trac version
[01:14:55.598433]<DaMato>macmaN: I am using trac 0.11.6 which AFAIK should work with Hackergotchi?!?
[01:16:09.770629]<macmaN>i believe so
[01:16:18.555062]<macmaN>google this closed cursor thing
[01:16:35.955301]<macmaN>ive ran into it with pastebin plugin afair
[01:16:40.470654]<macmaN>and it's a generic issue
[01:17:00.549912]<macmaN>which is usually remedied with a one line change
[01:17:30.656473]<macmaN>but at the same time i remember my hackergotchi working fine, so not entirely sure either
[01:18:04.576953]<macmaN>now i'm running 0.12 trunk so unable to look into 0.11
[01:19:21.295641]<DaMato>ok, thanks anyway for the help.
[01:19:58.883692]<DaMato>well, I already tried to google for that error but there weren't any easy solution for that.
[01:20:26.738721]<DaMato>also the SubscriberListPlugin seems to be affected by the same problem.
[01:43:59.316325]<kirean>DaMato: did you see: http://groups.google.com/group/trac-dev/browse_frm/thread/b6b46dcefe706a84/1f4d61c0d6533d53?#1f4d61c0d6533d53
[01:49:19.757050]<DaMato>kirean: thx for the hint, I am currently trying to apply that patch. after modifying roadmap.py how can I ensure the roadmap.pyc file is regenerated?
[02:12:25.068686]<kirean>DaMato: delete it and restart your frontend
[02:15:03.404592]<DaMato>kirean: still getting the same error with the hackergotchi plugin. seems the fix to roadmap.py didn't solve it.
[02:16:56.421570]<macmaN>you are trying to fix hackergotchi by modifying roadmap.py...?
[02:17:29.784852]<osimons>DaMato: nope, i'd be surprised if it did fix it... likely the plugin uses the same (wrong) pattern and needs to be fixed in a similar way.
[02:17:32.007322]<DaMato>macmaN: yes, that was what the link of kirean suggested..
[02:18:16.596937]<osimons>anyway 8878 is not an actual error - it is just a wrong pattern to show in our code
[02:18:22.043464]<macmaN>DaMato: that link actually described the same error for another plugin
[02:19:41.655207]<DaMato>well, I can find the same kind of db.cursor() thing in the hackergotchi plugin:
[02:19:43.565297]<DaMato> db = self.env.get_db_cnx()
[02:19:43.692025]<DaMato> cursor = db.cursor()
[02:20:11.866433]<osimons>DaMato: a very fresh take on this issue: http://trac.edgewall.org/ticket/9077#comment:6
[02:22:07.826624]<osimons>DaMato: that isn't a problem - that is the correct usage. somehow the cursor is closed, and new ticket suggests either a rollback() happens that somehow closes cursors, or alternatively because the mentioned pattern where a db= is not defined which may cause the connection to be garbage collected and put back into the pool while connections are still in use
[02:22:35.806255]<osimons>- which may well be the same issue, as we do a rollback() to clean the connection before returning it to the pool
[02:23:08.329696]<DaMato>well, than I am out of ideas why the hackergotchi plugin won't work for me with 0.11.6
[02:28:51.479361]<osimons>DaMato: interesting... in lines 32+33 it contains your pasted code. which is fine. however, the cursor created is used inside the f(stream) closure.
[02:30:37.826777]<DaMato>osimons: yes, I spotted that, so it seems the cursor is closed in between that..
[02:31:27.310589]<osimons>yeah. due to the connection being returned/dereferenced somehow. may well be that some of cboos' code is too agressive here.
[02:32:13.311983]<osimons>same with the _get_info() call that happens inside there that passes it into the internal method for detailed handling
[02:33:22.392341]<osimons>=> try to move line 32+33 into the closuse instead
[02:34:18.772139]<osimons>DaMato: ^^ may not be ideal as i don't know the code, but at least it should ensure that the connection is still held (and thereby keeping cursors in context)
[02:36:31.037261]<DaMato>osimos: that worked indeed!
[02:38:27.004746]<DaMato>osimos: now I have the same issue with the SubscriberListPlugin. I think it is from the same author
[02:39:15.823579]<DaMato>there the author uses "cursor = env.get_db_cnx().cursor()"
[02:40:49.723206]<gozerbot>trac: Ticket #9109 (Invalid character code page in FwVol.c) closed - <http://trac.edgewall.org/ticket/9109#comment:1> || Ticket #9109 (Invalid character code page in FwVol.c) created - <http://trac.edgewall.org/ticket/9109>
[02:41:38.912206]<DaMato>osimos: after replaying that one with the correct way of getting the cursor also SubscriberListPlugin works.
[02:52:53.620549]<osimons>DaMato: right, that is the same pattern as roadmap.py (ie. no 'db' variable to keep the connection referenced and it gets garbage collected)
[02:53:28.800337]<DaMato>osimos: yes, now both plugins work fine as it seems. I also already submitted bug reports to their authors with hints to the fix. thanks again.
[02:54:17.656642]<macmaN>osimons: this fix will be backwards compatible too? or is that even important
[02:54:24.656026]<macmaN>backwards from 0.11.6
[02:54:43.600147]<osimons>sure.
[02:55:08.773765]<osimons>DaMato: what is the ticket number for the closure fix?
[02:55:44.755353]<DaMato>osimons: I filed them on trac-hacks.org and the other authors website.
[02:56:35.246946]<osimons>i'll find the number - i'm adding it to the trac bug tracker too as it is "suspicious"...
[02:57:54.524710]<DaMato>osimons: ok.
[02:59:07.234139]<DaMato>osimons: now I still wonder why the hackergotchiplugin doesn't show the respective images taken from gravatar?!? hmmm
[03:01:18.057465]<DaMato>osimos: that's the link to the bug of SubscriberListPlugin: http://trac-hacks.org/ticket/6765
[03:02:43.834788]<osimons>don't know the plugin at all, DaMato... just interested in the db code :-) added a note about this at http://trac.edgewall.org/ticket/9077#comment:9
[03:03:09.565067]<DaMato>osimons: ok, no problem... I will investigate :)
[03:03:10.749711]<osimons>DaMato: no, that was the hackergotchi link
[03:13:52.457716]<DaMato>osimons: got it, another bug in the hackergotchi plugin ;)
[03:15:51.325224]<osimons>DaMato: when working with plugins, you may want to look at pre-existing tickets...: http://trac-hacks.org/report/9?COMPONENT=HackergotchiPlugin
[03:16:46.142503]<osimons>see ticket 6302 for instance...
[03:19:14.596171]<DaMato>osimons: yeah, that was exactly the bug I found ;)
[03:19:59.584424]<osimons>before filing your new bug, DaMato?
[03:20:47.369904]<DaMato>osimons: no, unfortunately not.
[03:21:02.370279]<DaMato>sorry for the duplicate
[03:21:12.905934]<osimons>oki. good habit though to always check pre-existing tickets first :-)
[03:21:22.941018]<osimons>i'll close the old one
[03:22:26.390354]<DaMato>osimons: yes, I know, sorry again.
[03:22:37.263704]<osimons>no probs. happens :-)
[03:24:07.365072]<DaMato>osimons: btw. do you have an idea how the provider of this trac did it that the "View Ticket" links to a special query instead to report? https://svn.mayastudios.de/mtpp
[03:24:16.108366]<DaMato>osimons: i want to do the same for my trac
[03:24:44.532877]<DaMato>osimons: also the "My Tickets" thingy seems to be interesting for me.
[03:26:17.341460]<osimons>huh. never seen that. you can edit the query link according to http://trac.edgewall.org/wiki/TracNavigation
[03:27:34.640736]<osimons>ugh. https://svn.mayastudios.de/mtpp/wiki/TracPatches
[03:27:41.927679]<DaMato>osimons: ok, nice to know. But do you have an idea how he prepared a custom query like that?
[03:29:07.051593]<osimons>sure, you can for instance save the query as a report, and then change report.href = /report/N (where N is your report)
[03:29:25.283068]<osimons>=> you basically modify the navigation links through trac.ini
[03:30:17.656873]<osimons>(or write the query as the url, report.href = /query?status=!closed&group=milestone
[03:30:27.772642]<osimons>)... or whatever you like
[03:30:50.115536]<DaMato>osimons: ah, ok. and the "My Tickets" is a navadd thing, I think with another link to a custom query to $USER ?
[03:31:39.126541]<osimons>oh. perhaps. $USER works in any trac - so you can in your url add owner=$user
[04:01:01.410405]<kirean>DaMato: there is a navaddplugin: http://trac-hacks.org/wiki/NavAddPlugin
[04:02:20.729922]<kirean>osimons: is that the way to go?
[04:03:22.662073]<osimons>don't think trac can add nav items, so i guess (it can only change the reference and labels of existing items, iirc)
[04:07:29.147402]<gamla_kossan>hi people!
[04:08:54.529260]<gamla_kossan>having a problem here; I'm trying to connect my trac installation to my svn repo, but the the svn repo isn't local; it's mounted on a nfs share. however, when I try to access my trac url, I get this:
[04:09:27.577503]<gamla_kossan>oh wait, the error has changed
[04:09:33.174819]<gamla_kossan>TracError: The 'repository_dir' has changed, a 'trac-admin resync' operation is needed.
[04:09:36.073191]<gamla_kossan>is what I get now
[04:11:50.277348]<gamla_kossan>resyncing now..
[04:11:58.715069]*gamla_kossan holds his thumbs
[04:12:24.544719]<gamla_kossan>wohoo!
[04:12:26.033354]<gamla_kossan>it works!
[04:12:26.768861]<gamla_kossan>:D
[05:16:45.864794]<DaMato>osimons: do you have any idea why it is not possible to change the text of "View tickets" with adding "report.label = yeah" in [mainnav] ?
[05:22:50.395064]<osimons>DaMato: the key is from the internals of trac - the key used to store the navigational elements. that key seems to be called "tickets"
[05:23:01.215085]<osimons>=> could you try tickets.label and tickets.href instead?
[05:24:09.279938]<osimons>right, "tickets" and "newticket" seems to be the two entries added by the ticket sub-system
[05:24:20.625462]<DaMato>osimons: yes, that works. thanks. is that documented somewhere? because that seems to be the only case where it doesn't match the url path
[05:25:24.461181]<osimons>DaMato: it is used as an example here ("tickets.href"): http://trac.edgewall.org/wiki/TracNavigation
[05:25:46.626316]<DaMato>ah ok. thx
[05:26:34.713440]<DaMato>still I fail to see how the guys at https://svn.mayastudios.de/mtpp did it that their "View Tickets" links to /query only but shows a custom query with things selected already.
[05:31:04.738535]<osimons>DaMato: you link tickets.href to /query, and then you set your default queries: http://trac.edgewall.org/wiki/TracIni#query-section
[05:31:35.734990]<DaMato>ah, that makes sense.. great!
[05:37:22.484240]<DaMato>osimons: hmm, doesn't seem to work.. put "default_query = status!=closed&group=severity&owner=$USER" there but still group is unselected in the default query
[05:38:11.674011]<osimons>and you are authenticated when testing that query?
[05:39:01.648401]<DaMato>yes.
[05:39:14.656103]<DaMato>but also the anonymous query doesn't work with group
[05:40:31.693844]<osimons>huh. it should, i believe. strange. make a query in query editor just like you want it, and add the ?<query-here> to the setting
[05:40:51.022777]<osimons>don't have time to look at this now, unfortunately. work to do.
[05:43:21.032129]<DaMato>osimos: just tried that, but it doesn't seem to work. group and col is not respected in the default query settings
[05:51:34.691599]<DaMato>osimons: ah, seems to be the solution: http://trac.edgewall.org/ticket/7821
[05:53:11.676323]<osimons>DaMato: right - the alternative syntax I suggested too with "?<query-here>". perhaps not too clearly, i suppose :-)
[05:53:55.971442]<DaMato>osimons: ok, but here I can now see a "$USER" in the combobox instead of my real username. But i think that's still ok
[06:08:36.283231]<DaMato>osimons: ok, but here I can now see a "$USER" in the combobox instead of my real username. But i think that's still ok
[06:08:44.151642]<DaMato>ups
[06:08:47.798878]<osimons>heh
[06:08:51.883123]<osimons>read it now :-)
[06:09:28.014806]<DaMato>osimons: sorry, didn't want to double post. I was about to say that I got everything working now as I wanted. thanks again for all the help
[06:10:15.865990]<DaMato>osimons: see here if you want to know what my trac is all about :) http://trac.yam.ch/
[06:10:57.338161]<cmc>nice layout
[06:11:37.179341]<cmc>the menu bar gets cut unexpectedly if your browser width is pretty small
[06:12:08.532454]<osimons>heh. amiga... it just won't die, will it...
[06:12:42.153729]<DaMato>cmc: that's the layout of the trac systems at sand-labs.org actually.. perhaps I have to make the font in the navbar smaller to fit more browser widths.
[06:12:53.968262]<DaMato>osimons: no, they will never die! :)
[06:14:56.894797]<osimons>DaMato: i'm pre-amiga, so i skipped that in my computer-evolution. i was on mac by then...
[06:15:40.161224]<DaMato>osimons: too bad ;)
[06:16:11.573694]*osimons got his vic-20 in 1981... time flies...
[06:18:44.115884]<DaMato>cmc: ok, made the font of the navbar smaller :)
[06:19:28.784672]<cmc>it is a really nice looking UI
[06:29:02.691633]<macmaN>cmc: you still playing with oforge?
[06:29:27.832481]<cmc>not I. someone asked a question about it yesterday so I looked at it a little
[06:29:58.815381]<macmaN>ok right, im confusing nicks
[06:30:23.937911]<macmaN>it downloaded the appliance, i didnt even know such a thorough product had been assembled based on trac
[06:30:26.827214]<macmaN>s/it/i
[06:30:26.837067]<evil_twin>macman meant: downloaded the appliance, i didnt even know such a thorough product had been assembled based on trac
[06:44:00.013793]*retracile sighs something irreverent about mornings.
[06:48:39.404288]<cmc>yeah, oforge did look pretty nice, assuming you could set it up
[06:49:57.748487]<macmaN>the appliance works ootb
[06:50:17.476044]<cmc>huh. wonder what the guy's issue with it was, then
[06:50:38.500297]<cmc>he couldn't get the setup script to do whatever it needed to do
[06:50:39.907419]<macmaN>well he wanted to install it himself
[06:50:46.015805]<macmaN>i downloaded virtual machine
[06:50:50.276351]<cmc>ah
[07:29:39.125037]<DaMato>anyone is using "SimpleTicketPlugin" and knows how this thing actually works?
[07:34:45.548774]<osimons>DaMato: http://trac.edgewall.org/ticket/8708#comment:9
[08:26:07.912391]<macmaN>osimons: ReposReadmePlugin only works with svn?
[08:26:23.188097]<macmaN>my README in a git repo is definitely not getting displayed
[08:27:44.042179]<osimons>macmaN: no idea :-) untested, but thought i used standard ways of accessing repos?
[08:28:11.591027]<osimons>what trac version, and if you answer 0.12dev then "unsupported" is my default answer....
[08:29:08.066337]<macmaN>:)
[08:30:23.170163]<osimons>all my production stuff - and plugin development - remains at 0.11.x for the time being. that will likely need to change soon with 0.12 around the corner... perhaps...
[09:09:22.985890]<macmaN>0.12 has some stuff that make me not look back
[09:09:29.940670]<macmaN>incl. multirepos
[09:09:46.772442]<macmaN>osimons: did you know about oforge before?
[09:14:27.513032]<osimons>know it exists, but no, don't know details and haven't tested it - rolled my own many, many years ago...
[09:14:44.255405]*osimons heads out with the kids. later.
[09:41:12.592174]<DaMato>hmm. is there any way to have a kind of "hidden CC" for the tickets notification? I would like to send ticket change/create notifications to a specific mailing list without showing the cc address in the ticket itself at all times?!?!
[09:44:15.461409]<Sacho>is there a way to bulk update revisions from one milestone to another?
[09:44:33.768017]<Sacho>or like, bulk update revisions period
[09:44:34.261203]<aruntomar>i successfully have setup trac+svn on the same machine, what happens when svn is on one machine accessible via https and trac is on another machine? would giving the https url while setting up the trac project suffice?
[09:44:40.544041]<Sacho>err, not revisions. tickets.
[09:44:57.778787]<aruntomar>Sacho: there is a plugin for bulk updates
[09:45:44.899546]<Sacho>thanks!
[09:46:02.520255]<aruntomar>Sacho: http://trac-hacks.org/wiki/BatchModifyPlugin
[09:46:08.623636]<aruntomar>may be this would help
[09:51:14.437177]<Sacho>awesome, it works :D
[09:57:08.226950]<coderanger>aruntomar: No
[09:57:12.703473]<coderanger>Nor will it ever be
[09:58:11.612690]<aruntomar>coderanger: i googled a lot, but there is no mention of how to integrate svn over https + trac
[09:58:24.084945]<coderanger>because there is no way
[09:58:38.022578]<coderanger>The SVN API requires local access to the repo
[09:59:50.468699]<coderanger>The best you can do is to use svnsync to mirror it
[09:59:54.917072]<aruntomar>coderanger: the situation is the client already has svn setup and it's accessible via https, now they want to setup another server for trac and wants to integrate svn with it, i'll tell them we need the svn+trac on the same machine
[10:00:16.267849]<coderanger>but yeah, I can imagine no possible reason to not run it on the same machine
[10:00:56.883427]<aruntomar>coderanger: svn data is huge and svnsync will not suffice that
[10:01:16.204818]<aruntomar>i'll have to install trac on the svn server itself
[10:01:35.129973]<coderanger>that would be best
[10:04:44.281658]<aruntomar>coderanger: thanx
[10:07:56.628151]<macmaN>!seen cbalan
[10:07:56.634807]<evil_twin>cbalan was last seen on irc.freenode.net at Thu, 04 Mar 2010 09:57:53 +0100, quitting: Remote host closed the connection
[10:08:40.290825]<macmaN>crap, how did i miss him
[10:08:59.624153]<macmaN>!note
[10:10:55.472535]<gozerbot>trac: Ticket #9110 (display of eligible changesets is broken when source newer than target) created - <http://trac.edgewall.org/ticket/9110> || Changeset [9326]: 0.11.7dev: update release notes, from ChangeLog@61 - <http://trac.edgewall.org/changeset/9326> || SeaChange/WhatUsersWant edited - <http://trac.edgewall.org/wiki/SeaChange/WhatUsersWant?version=113>
[10:29:59.414889]<DaMato>is it really not possible to have a hidden cc for ticket notifications ?? strange.
[10:30:57.338453]<coderanger>DaMato: Nothing specific, though you can block viewing email addresses in general, or there is the ticket_always_cc
[10:31:02.070589]*coderanger -> work
[10:32:14.099295]<DaMato>coderanger: really? where is this documented? can't find any reference to that ticket_always_cc ?
[10:55:11.364083]<TiN>I do not see my mistake.
[10:55:25.086886]<TiN>I'm trying add a row in the database
[10:55:26.619958]<TiN>http://paste.debian.net/62443/
[10:56:17.878842]<cmc>Tin, try VALUES (%s, %s, %s, %s)
[10:58:36.442227]<TiN>cmc: it works :-), this means that trac does not use sqlite3 API directly?
[10:59:10.969404]<coderanger>@tracini
[10:59:11.323524]<evil_twin>tracini is http://trac.edgewall.org/wiki/TracIni
[10:59:15.302958]<coderanger>DaMato: ^^
[10:59:46.353488]<coderanger>TiN: Indeed, we have to force all the DB backends to look the same
[10:59:51.846884]<cmc>Trac works across multiple RDBMSs
[10:59:57.929691]<coderanger>so they all use %s as the parastyle
[11:00:05.628486]<coderanger>and they take/produce unicode()
[11:01:32.959401]<TiN>great, thanks both
[11:01:39.119239]<cmc>:)
[11:10:53.316595]<DaMato>coderanger: there is only an "smtp_always_cc" but not only for tickets..
[12:25:52.455401]<Spec>Heya again! I'm trying to customize what information gets sent with trac tickets, but it seems this is controlled by a template (trac/ticket/templates/ticket_notify_email.txt), and there doesn't seem to be a way to override which template is used on a per-trac-instance basis, is this true? :(
[13:05:18.364554]<cmc>it is not true :)
[13:06:00.719516]<cmc>Spec: just place a new copy of ticket_notify_email.txt in path/to/your/project/templates
[13:06:22.003605]<cmc>you may need to restart trac afterwards
[13:07:36.626893]<Spec>magic!
[13:07:52.913015]<Spec>cmc: i was so close to changing notify.py to read config variables from trac.ini for this :(
[13:08:19.020265]<Spec>is that documented anywhere? .... this doesn't claim you can do so: http://trac.edgewall.org/wiki/TracNotification
[13:08:26.445710]<Spec>it only seems to imply you have to change the global template
[13:10:47.490243]<cmc>refresh ;)
[13:10:57.945665]<gozerbot>trac: TracNotification edited - <http://trac.edgewall.org/wiki/TracNotification?version=57> || 0.11/TracIni edited - <http://trac.edgewall.org/wiki/0.11/TracIni?version=5> || TracAdmin edited - <http://trac.edgewall.org/wiki/TracAdmin?version=35> || 0.11/TracAdmin edited - <http://trac.edgewall.org/wiki/0.11/TracAdmin?version=2>
[13:40:59.473911]<gozerbot>trac: TracProject/DefaultWikiPages edited - <http://trac.edgewall.org/wiki/TracProject/DefaultWikiPages?version=32> || 0.11/TracMacros edited - <http://trac.edgewall.org/wiki/0.11/TracMacros?version=16>
[14:32:48.747121]<TiN>I need a list of projects by date, I will use the date attribute trac folder for the filesystem, some method/module that can reuse?
[14:33:36.251692]<cmc>not one that I've heard of
[14:33:44.756802]<cmc>suppose you could use the date of the first ticket
[14:33:50.260246]<cmc>or first milestone
[14:42:13.295057]<TiN>ok, this sound better, thanks
[14:43:17.741826]<cmc>np
[15:26:20.557061]<rts>hi, anybody in for a chat about trac and plugin development?
[15:28:46.278153]<rts>hi, anybody in for a chat about trac and plugin development?
[15:29:59.977369]<cmc>what's up?
[15:30:02.361499]<cmc>what's up?
[15:31:46.865879]<rts>i wonder if there was a requirement or need for a new redirection plugin that would allow other plugins' resource managers to plug into that system?
[15:32:24.665601]<cmc>howso?
[15:32:29.852663]<cmc>or rather, to what end?
[15:33:15.713345]<rts>in order to install arbitrary redirections into the system that would for example redirect deleted wiki pages to newly defined / renamed to wiki pages and the likes
[15:33:29.267403]<cmc>also, look at trac/web/api.py: add_redirect_listener()
[15:33:57.802499]<rts>i know that there already exists a wikirename plugin on track hacks which will preserve all page history btw
[15:34:26.284106]<rts>but i do not know if it was capable of installing the required redirections to the newly defined page
[15:35:27.653298]<cmc>I'd think you could create such a plugin
[15:35:40.072193]<rts>yeah, i already done that, but the redirect listener is called when the redirect() request was already issued, for my part i resolved on the request filter extension point
[15:37:47.779214]<rts>does anyone know how far the GenericTrac has grown so far, is there already some development in that area? I mean, trac definitely needs a common resource abstraction and by that also a common db access layer
[15:38:11.792342]<doki_pen>rts: not far at all
[15:38:18.043425]<doki_pen>rts: planning phase
[15:38:25.015361]*doki_pen thinks
[15:38:32.231238]<doki_pen>you should ask on trac-dev
[15:38:49.309387]<rts>ok, i will, thanks for the hint
[15:38:51.568622]<doki_pen>I know that cboos was asking about how resource changelistner should work
[15:39:10.909593]<rts>great i would have some ideas for that, i will look into trac-dev
[15:39:13.368384]<doki_pen>is that what you want?
[15:39:19.980742]<doki_pen>there is a ticket
[15:39:24.207200]<rts>exactly
[15:39:26.926072]<rts>bye bye
[15:39:38.357510]<doki_pen>mingya
[15:39:45.992498]<doki_pen>he got me all revved up for nothing
[15:39:52.128681]<cmc>awe
[15:39:56.491580]<cmc>go back to sleep ;)
[15:40:13.462463]<rts>wb - *g - nobody on trac-dev
[15:40:16.468490]<doki_pen>haha
[15:40:27.533317]<doki_pen>trac-dev mailinglist
[15:40:35.178874]<doki_pen>you can discuss trac-dev in here too
[15:41:09.212909]<doki_pen>it's just that everyone is usually on in the morning
[15:41:09.427276]<rts>yeah, i already subscribed i thing but there is not much on that list so i thought i would join the irc to find out if there is an active community still
[15:41:41.385376]<rts>in the morning? hell, here it is very early in the morning (gmt+1)
[15:42:16.314716]<doki_pen>haha, at night for you
[15:42:31.701457]<doki_pen>http://trac.edgewall.org/ticket/8834
[15:42:36.992740]<doki_pen>please add any thoughts
[15:42:56.753825]<doki_pen>and if you are feeling hackish, start hacking
[15:43:07.779193]<rts>thanks for the link
[15:43:10.580124]<doki_pen>I'm working on announcer integration with trac, so I may be able to lend a hand
[15:43:37.185930]<doki_pen>maybe as a first step, we should just do the resourcechangelistener impl
[15:43:43.553790]<doki_pen>it probably won't be too difficult
[15:43:49.956237]<rts>about feeling hackish - i already started implementing the redirection system as part of a patch to trac, but rblank told me that it would be best to implement it as a plugin - and
[15:43:57.538861]<rts>eventually it turned out best ;)
[15:44:20.333039]<doki_pen>for sure, but something like resourcechangelistener should go in core
[15:44:28.022205]<doki_pen>it has too many uses
[15:44:48.667411]<doki_pen>and probably makes the code smaller
[15:45:36.820524]<rts>of course, i had in mind that the redirection system would be more like a framework, where plugins could opt into for being redirected and so on, eventually also publishing the resources that they would like to have automatically redirected by the system in case of lifecycle change, for example rename-mode or delete
[15:45:44.463354]<rts>rename-move that is
[15:46:22.819518]<rts>and that definitely cries for a common resource management and abstraction layer in trac
[15:46:43.840803]<rts>-common +unified
[15:47:42.437251]<rts>absolutely, the resourcechangelistener must be in core or at least trac.resource with the resource system being completely overhauled
[15:48:47.531059]<rts>for now it is more or less a resource descriptive rather than a resource access provisioning system
[15:49:19.839964]<doki_pen>I think I agree
[15:49:43.811930]<doki_pen>yes yes, as a first step
[15:49:56.272277]<rts>i wonder if we could have something like for example the OSX resource approach (the old MAC OS resource approach), where the resource manager is a central piece in the system
[15:50:22.659943]<rts>however, that would require a major overhaul in the system and will make all available plugins incompatible
[15:50:50.490514]<rts>well, doing GenericTrac would also lead to that state
[15:51:06.499557]<doki_pen>yeah, I think you have to take an iterative approach
[15:51:12.315337]<doki_pen>trac is pretty old and stable now
[15:51:21.103099]<doki_pen>it doesn't change really quickly
[15:51:42.270221]<rts>i think so, yes, development/evolution is going pretty slow now
[15:51:55.367177]<doki_pen>one thought I was having, is I wonder what would happen if I made a trac-dev mailinglist like git's or linux's
[15:52:14.112168]<doki_pen>where all patches where sent to mailing list
[15:52:29.824994]<rts>maintenance hell? automation hell?
[15:52:48.550135]<doki_pen>and then I kept a central git repo with a branch in svn that I sync
[15:53:14.845039]<doki_pen>one of the problems is that getting patches to trac isn't easy enough
[15:53:15.983852]<rts>oh, patch management would be nicer i agree absolutely
[15:53:41.644843]<doki_pen>i'd just like to have an anarchy branch to see what happens
[15:54:16.988631]<rts>svn diffs are also not the very best for applying patches, i reckon, i once committed a unified patch for adding regexp support to the db backends but that patch cannot be applied
[15:54:33.357408]<doki_pen>yes, it sucks
[15:54:42.498242]<rts>^^
[15:54:52.849914]<doki_pen>it may eventually convince the guys to go to something like hg or git
[15:55:29.976392]<rts>personally i would go for hg because it is python, but then again all of the world is going for git, hell knows why ;)
[15:55:31.043408]<doki_pen>I have a theory that it would increase contributions, and I'ld love to prove it
[15:55:58.138291]<doki_pen>i prefer git, but it's a stupid battle, they are both very good
[15:56:07.155966]<doki_pen>trac integration is better with hg
[15:56:14.428737]<doki_pen>so I would recommend that too
[15:56:45.072846]<rts>rblank made a statement about the current trac.web and trac.core being fully defined as to extensions and so on, i believe that he would object such a notion (seems to be a very cautious guy)
[15:57:21.480782]<rts>oh he must have read that ;)
[15:57:35.323453]<doki_pen>lol
[15:57:40.066616]<doki_pen>he is watching
[15:57:50.357888]<doki_pen>my connection is crap, so I may dissapear
[15:58:35.925339]<rts>but he is right, keeping trac stable is first parameter, but making it perform better in terms of evolution of the platform, as you want it to, would also be great
[15:59:02.170092]<doki_pen>I'm afraid it's already looking like an old dog
[15:59:41.389201]<rts>well, i am new to python and some of the concepts still puzzle me (python ways that is) - the meta component part is great
[16:00:42.365230]<doki_pen>sometimes..
[16:03:09.856055]<rts>so you are into getting the open process right, i.e. allowing more persons to commit patches to trac and establishing an authority that then would test and merge in those patches from a central staging repository back into the main line?
[16:04:51.972245]<doki_pen>yes
[16:05:12.387643]<rts>but i wonder if some similar process to python PEPs would be required?
[16:05:14.778854]<doki_pen>I wonder if it works in smaller communities
[16:05:29.396184]<doki_pen>PEPs? what do you mean?
[16:05:31.279700]<exarkun>Hey why is trac so incredibly slooooooooooooooooooooooooooooooooooooooooow
[16:05:47.844230]<rts>;) running under apache?
[16:05:56.155886]<doki_pen>exarkun: @Frontend
[16:06:00.599325]<doki_pen>@Frontend
[16:06:00.704735]<evil_twin>Frontend is CGI, FastCGI, mod_python, tracd, or mod_wsgi
[16:06:08.343340]<exarkun>none of the above
[16:06:13.976468]<exarkun>Twisted Web2
[16:06:19.090755]<doki_pen>exarkun: orly?
[16:06:23.811521]<doki_pen>exarkun: sounds fun
[16:06:33.160456]<doki_pen>exarkun: did you try comparing perf to tracd?
[16:06:36.619816]<exarkun>no
[16:06:41.069613]<doki_pen>exarkun: I would try it
[16:06:42.981110]<exarkun>no
[16:06:52.800103]<exarkun>The problem is not Twisted Web2.
[16:07:01.983448]<doki_pen>do you have many users?
[16:07:03.710337]<exarkun>And the last time I came in here using tracd, everyone shouted "stop doing that, it's not supported"
[16:07:13.376346]<exarkun>doki_pen: Um. Yes.
[16:07:16.652177]<doki_pen>exarkun: that's dumb
[16:07:24.999765]<doki_pen>exarkun: are you using postgres?
[16:07:30.199330]<exarkun>doki_pen: yes
[16:07:41.634069]<exarkun>By the way, when I say slow, I mean it takes 4 seconds to render a simple ticket page.
[16:07:44.187384]<doki_pen>exarkun: how many concurrent users?
[16:07:52.288007]<exarkun>That's with no concurrent access at all.
[16:07:59.049823]<doki_pen>exarkun: there is a problem
[16:08:01.168748]<doki_pen>lol
[16:08:06.304851]<exarkun>That's what I was thinking.
[16:08:06.887886]*doki_pen is mr. obvious
[16:08:12.852445]<exarkun>What is it?
[16:08:20.225574]<doki_pen>do the logs say anything?
[16:08:29.733137]<doki_pen>do you have commit hooks?
[16:08:40.767550]<doki_pen>also, if you don't mind, paste list of plugins
[16:08:44.046297]<exarkun>There's nothing being committed at the moment.
[16:08:46.764729]<exarkun>I'll look at the logs.
[16:08:59.996916]<doki_pen>exarkun: I'm sorry, but I may disappear soon
[16:09:13.765598]<doki_pen>I'm on the train and wife wants me when I get home
[16:09:23.754442]<doki_pen>but for the next 10 minutes I can help
[16:09:24.405726]<exarkun>doki_pen: I can complain more later.
[16:09:32.147477]<exarkun>The logs are full of stuff, none of which means much to me.
[16:09:38.638855]<doki_pen>any stacks?
[16:09:52.735283]<exarkun>nope, just DEBUG: ... stuff
[16:09:57.505172]<doki_pen>exarkun: oh!
[16:10:01.317696]<doki_pen>exarkun: shut that off!
[16:10:02.348921]<doki_pen>lol
[16:10:09.808175]<doki_pen>what type of filesystem?
[16:10:19.072830]<exarkun>ext3
[16:10:26.561181]<doki_pen>should be fine
[16:10:48.692771]<doki_pen>is cpu pegged?
[16:10:59.768957]<exarkun>Okay, the log level is "ERROR" now.
[16:11:16.255557]<exarkun>no noticable change in page render times
[16:11:24.072529]<doki_pen>what about cpu?
[16:11:30.094633]<doki_pen>can you hit it with ab and look at cpu?
[16:11:43.038923]<exarkun>cpu usage is about 70% for the web server, about 20% for postgres
[16:11:52.107917]<exarkun>(with curl in a loop, not ab, close enough right?)
[16:12:04.411299]<doki_pen>that's a lot, yeah,, close enough
[16:12:13.604081]<exarkun>so, plugin list...
[16:12:36.792462]<exarkun>TracAccountManager, STractistics, IRC-REPORT-TICKET-MAN, Trac 0.11.6
[16:12:41.757319]<doki_pen>so we are definitely cpu bound
[16:12:51.794060]<exarkun>STractistics is actually broken on this version of trac, so I can disable it; I doubt it will make any difference.
[16:12:57.965658]<doki_pen>if it's only 3 plugins, I would try disabling them
[16:13:09.199998]<doki_pen>just to make troubleshooting easier
[16:13:13.771478]<exarkun>Sure
[16:13:32.009391]<doki_pen>not accountmanager, of course
[16:13:55.590060]<exarkun>okay, everything disabled except account manager
[16:14:00.250774]<exarkun>do I need to restart the web server or something?
[16:14:00.940681]<doki_pen>also, there is something about connection poooling and postgres
[16:14:55.375454]<doki_pen>google it, I forget
[16:15:02.146385]<doki_pen>do you still have bad perf without plugins?
[16:15:23.601013]<exarkun>yep
[16:15:37.567863]<doki_pen>but the cpu would indicate that connections are not the issue, right?
[16:16:02.461773]<exarkun>I don't know much about the performance characteristics of postgres or the particular db adapter trac uses
[16:16:26.168710]<rts>do a ps -aef | grep postgres to see how many concurrent connections to the server are currently alive
[16:16:28.750874]<exarkun>I guess it indicates that? The web server and postgres server are on the same machine, so it's not like connection setup has a whole lot of network latency to contend with.
[16:16:33.548417]<doki_pen>I'm almost home, so look at this: http://trac.edgewall.org/wiki/TracPerformance
[16:16:54.285047]<exarkun>looks like two
[16:16:56.828782]<doki_pen>exarkun: yeah, but if it's blocking on connection
[16:17:01.729737]<exarkun>doki_pen: thanks for the help so far, by the way
[16:17:09.454143]<doki_pen>exarkun: even if you spin up curl, you still only have 2?
[16:17:23.499754]<rts>two is great so this should not be the bottleneck
[16:17:43.789397]<doki_pen>also, make sure that static resources aren't being served by trac
[16:17:45.233169]<exarkun>doki_pen: yep
[16:17:55.836220]<exarkun>mostly "idle" or "idle in transaction"
[16:18:09.214737]<doki_pen>you should deploy them somewhere and let the web server serve them
[16:18:29.997825]<exarkun>curl doesn't follow image/css/js links anyway, but that's a good point
[16:18:36.563725]<rts>any background processes like for example updatedb or something that would cut down i/o performance on the server?
[16:18:37.667062]<doki_pen>all chrome should be mapped to a static file system
[16:18:55.478862]<exarkun>rts: there's other stuff on the system, but nothing is particularly active right now
[16:19:12.157069]<rts>exarkun: ok
[16:19:24.609621]<doki_pen>exarkun: do you have restrict_owner= true?
[16:19:31.576179]<doki_pen>is it just tickets, or the entire system?
[16:19:41.839527]<exarkun>That's the one that makes a dropdown for assignees right? yea that's set.
[16:19:49.253622]*exarkun tries a wiki page
[16:19:52.435452]<rts>exarkun: is python interpreted or precompiled?
[16:20:16.529854]<doki_pen>exarkun: that is a known issue, shut it off
[16:20:24.921197]<doki_pen>exarkun: see if it helps
[16:20:38.254271]<exarkun>Ahhh
[16:20:44.563761]<exarkun>Yes, wiki pages are fast.
[16:20:55.375946]<doki_pen>exarkun: nice!
[16:21:03.111396]<doki_pen>exarkun: you can hack up a plugin to do it
[16:21:08.064407]<doki_pen>and just in time, I'm at my stop!
[16:21:08.604820]<exarkun>(well, .3s, not fast, but tolerable)
[16:21:11.649586]<doki_pen>see yeah
[16:21:14.138898]<doki_pen>see ya
[16:21:14.820135]<exarkun>doki_pen: thanks again
[16:21:19.562939]<rts>bye
[16:21:26.576137]<exarkun>rts: That's a weird question.
[16:22:15.475277]<rts>exarkun: i saw such a suggestion once on the internet where the python compiler could not compile the sources into .pyc because of access restrictions to the system, sort of
[16:22:29.811459]<exarkun>Ah.
[16:22:35.439786]<exarkun>That makes a bit more sense, then.
[16:22:52.133033]<exarkun>Since this server is long-running, it wouldn't make much difference. .pyc files are mostly about startup time.
[16:22:57.757018]<rts>exarkun: and now what made you perform better, was it that setting? and where would i set this?
[16:23:20.620625]<exarkun>rts: I haven't actually tried changing it yet, just about to now.
[16:23:34.887778]<rts>exarkun: uhm, well, lol
[16:23:50.900119]<exarkun>It's a setting in trac.ini, though
[16:24:29.612615]<rts>exarkun: thanks, because here in my local workstation/apache/mod_python environment it also is performing terribly
[16:24:30.775841]<exarkun>And yea... just tested, ~8x speedup for ticket page rendering.
[16:24:48.216111]<exarkun>The more user accounts in your system, the bigger difference it will make.
[16:25:12.073279]<exarkun>I had actually fixed this locally before, but I'm testing an upgraded install now, which clearly lacks the fix...
[16:26:10.563135]<rts>exarkun: thanks for coming up with this, i will look into TracPerformance now
[16:26:50.411016]<exarkun>np. hope it helps you out. :)
[16:26:53.591382]<exarkun>dinner time for me now
[16:26:59.071075]<rts>hm, restrict owner is set to false here
[16:27:05.184522]<rts>happy mealing ;)
[16:28:01.129018]<rts>but i will give Twisted a shot, looks nice
[18:14:56.450615]<exarkun>I'm looking at http://trac.edgewall.org/browser/trunk/trac/ticket/api.py#L388 and wondering why it checks to see if each user has the 'TICKET_MODIFY' permission after using get_users_with_permission('TICKET_MODIFY'). It seems redundant.
[19:11:07.100560]<gozerbot>trac: Ticket #9111 (TimeoutError: Unable to get database connection within 20 seconds) created - <http://trac.edgewall.org/ticket/9111>
[19:53:56.690029]<delfick>hello, I'm trying to install trac 0.12 (so I can have latest mercurial plugin) and I've installed it from svn and I've installed genshi from svn, however trac-admin still tells me pkg_resources.DistributionNotFound: Genshi>=0.6dev-r1072. Does anyone know what I need to do to fix this situation ?
[23:41:53.948595]<DaMato>hi guys.
[23:42:34.017914]<DaMato>is there a way that by entering e.g. "fixed bug #XXX" in the SVN checkin message trac automatically closes the ticket and puts a comment in the ticket with a link to the svn revision that fixed that bug?
[23:44:34.709039]<DaMato>hi kirean
[23:44:50.832547]<kirean>morning
[23:46:35.989716]<wildintellect>DaMato, usually if you say ticket:### fixed in revision:### those will be links - I think you'd have to script something to watch those messages to close the ticket for you
[23:46:57.150711]<wildintellect>I believe they call them post commit hooks in svn lingo
[23:47:23.140800]<kirean>wildintellect: there is a svn post-commit that handles such stuff included in trac
[23:47:31.225353]<DaMato>isn't there a trac plugin that does the job of automatically closing the ticket in case something like "fixed bug #XXX" is found in the svn checkin message?
[23:47:42.299498]<kirean>that's the trac-post-commit-hook
[23:48:15.608677]<wildintellect>dunno, check trac-hacks there might be a plugin for it
[23:48:29.355743]<kirean>http://trac.edgewall.org/browser/branches/0.11-stable/contrib
[23:49:13.403092]<kirean>http://trac.edgewall.org/browser/branches/0.11-stable/contrib/trac-post-commit-hook
[23:49:18.470000]<DaMato>kirean: that does handle that checkin of the svn message and eventually closing the ticket with putting a comment to the ticket with a link to the svn revision?
[23:49:18.633325]<DaMato>kirean: that does the job of watching the svn commit message and in case something like "fixed bug #xxx" is found will automatically close the ticket and put a comment in the ticket with a link to the SVN revision that fixed that thing?
[23:49:26.844336]<DaMato>argh, damn XChat. sorry.
[23:49:29.335908]<Sacho>yes, exactly
[23:49:30.313792]<kirean>DaMato: yes
[23:49:35.886188]<DaMato>ah fine.
[23:49:48.774580]<Sacho>well, you'd need to type fixed #123
[23:49:56.276433]<Sacho>but you could probably toy around with the syntax and regexp
[23:50:03.066570]<DaMato>I thought that post-commit hook is only required in case you use the 0.12 multirepos trac version.
[23:50:38.815550]<DaMato>Sacho: is there a description of the syntax it accepts?
[23:50:41.661672]<Sacho>it's not required at any point
[23:51:34.389956]<DaMato>Sacho: ? I thought I now need to put it into the post-commit script in my SVN repo?
[23:51:43.179666]<Sacho>I mean, it's not "required".
[23:51:55.586543]<Sacho>yes, your post-commit needs to run the hook
[23:52:50.509272]<DaMato>ah ok. and is there a web page with documentation on the syntax? I want to link my developers to it.
[23:53:25.672745]<Sacho>There's a good description in the script itself
[23:54:26.247159]<Sacho>apparently it works with "fixed bug 123"
[23:58:01.315222]<DaMato>Sacho: but with "This fixes bug ticket #118." it didn't work?!?
[23:58:21.310811]<Sacho>with that specific wording, no
[23:58:35.694295]<Sacho>you can see the script itself for what it matches
[23:58:41.776939]<Sacho>and nothing is stopping you from modifying the matching regex