gmane.comp.version-control.subversion.trac.devel

[Trac-dev] Paid Plugin Development Work

Wayne Allen — 2012-05-22T19:52:08

I've got a Trac plugin project over on oDesk -  
https://www.odesk.com/jobs/Create-Trac-Plugin-for-Clicky_~~ae45f3998704d6d5 should 
be a quick way to earn a few bucks for someone who knows how to create a 
Trac plugin.

[Trac-dev] [ANN] CodeReviewer plugin

Rob Guttman — 2012-05-16T12:58:10

Gerrit is a great idea for a code review tool but it ended up being a poor fit for our internal (non-open source project) needs.   I've used and considered others (e.g., Crucible, Review Board, GitHub), but what I really wanted for my team was something simple, lightweight and better integrated into our existing Trac ticket workflow.   So I built this plugin:

  http://trac-hacks.org/wiki/CodeReviewerPlugin

Hope others find this useful.  Feedback welcome.

Cheers.
- Rob

Re: [Trac-dev] Re: line numbers for code blocks and the BlogSpam module

Remy Blank — 2012-05-12T21:24:04

Yes indeed, they were both missing after the server upgrade. I have
installed them, and they appeared in the filter settings. Thanks for the
heads-up!

[Trac-dev] Re: line numbers for code blocks and the BlogSpam module

Dirk Stöcker — 2012-05-12T16:25:45


Don't know when I looked last. Yes. Works again.

Thought the spambayes filter is missing now and this is the most 
important one. Also the DNS based checks are missing. Maybe spambayes and 
dns-python are not installed?

The additional checks possibilities I added seem to allow a rather good 
performance even under bad conditions. Good to know :-)


Now after it is usable again, I'll have a look again. Everything I know 
is written down on the DOC page of the plugin. Basically it is important 
to keep training up-to-date. First removing any >90% (negative) and any 0% 
(positive) as they don't help. The remaining ones MAY be trained as 
ham/spam. Any wrong detection SHOULD be trained.

Ciao

Re: [Trac-dev] line numbers for code blocks and the BlogSpam module

Nelson Brown — 2012-05-12T13:50:24

Thank you very much, your suggestions worked about setting the preferences.
 It took right away, and posted both the attachment and the comment.  :)

-Nelson

On Fri, May 11, 2012 at 5:16 PM, Remy Blank <remy.blank< at >pobox.com> wrote:

Re: [Trac-dev] Re: line numbers for code blocks and the BlogSpam module

Remy Blank — 2012-05-12T12:19:20

Did you look recently? The admin pages have been fine for some time now.
But ok, I understand if you don't want to take care of it anymore. It
would be nice if you could at least teach someone how to manage the
filter, so that we can keep a good detection ratio.

[Trac-dev] Re: line numbers for code blocks and the BlogSpam module

Dirk Stöcker — 2012-05-12T11:52:03


As announced I don't care for TEO-Spam-Monitor for some time now. The 
admin pages are unusable due to missing CSS file delivery and the relevant 
ticket gets ignored.

Sorry, but if I should care again for it fix this issue first. Without 
care the detection ratio will slowly decrease over the time.

Ciao

Re: [Trac-dev] line numbers for code blocks and the BlogSpam module

Nelson Brown — 2012-05-12T00:43:17

Thank you, I'll try your suggestion about the preferences when I get home.
:)

-Nelson
On May 11, 2012 5:20 PM, "Remy Blank" <remy.blank< at >pobox.com> wrote:

Re: [Trac-dev] line numbers for code blocks and the BlogSpam module

Remy Blank — 2012-05-11T21:17:18

Oh, and if it still doesn't work, I'll post on your behalf. But that's
only a short-term solution.

Re: [Trac-dev] line numbers for code blocks and the BlogSpam module

Remy Blank — 2012-05-11T21:16:23

For some reason both StopForumSpam and BlogSpam thought your message was
spam. Your captcha verified correctly, but it wasn't enough to counter
both filters (you had a total score of 0).

You should set your name and email address in the preferences of the
site, that will give you some more positive karma, and end up at 6 (the
threshold is 3).


I'm not sure about that, I don't see a trace of the upload in the spam
monitoring. Dirk, any insights?

[Trac-dev] line numbers for code blocks and the BlogSpam module

Nelson Brown — 2012-05-11T13:23:44

Hi,

  What procedures do you guys have in place to un-spam yourself?  :)

  I was working on some analysis for a bitesized ticket, because I wanted
to contribute to my first open source project.  But every time I tried to
submit something it was caught in the spam filter.  I was only given one
shot at the captchas, and I couldn't even tell if I put them in correctly
or not...  And then my IP address was cached, so what should I do?

  Specifically, I was working on http://trac.edgewall.org/ticket/3275

  I tried to also add the following image as an attachment :
http://i.imgur.com/lNBoB.jpg

  The text of my comment is below, and I kept getting the error.

Submission rejected as potential spam (StopForumSpam says this is spam
(ip), BlogSpam says content is spam (Cached from stopforumspam.com))

===================================


So this is my first crack at contributing to an open source project.  I
basically read the recommendation that you bite into a bitesized ticket and
this was the first one I saw.  So what follows is some analysis, and I'd
like to get a recommendation from anyone interested.

The current mechanism for parsing arguments to WikiProcessors is the
parse_processor_args method in trac.wiki.parser module.  These currently
get stored into {{{self.args}}} as a dictionary of key value paris in the
form of {{{processorarg=processorargvalue}}}.  So utilizing the existing
syntax for passing processor arguments, an example code block with
annotated line numbers might look like this:

!{{{#!python annotations=lineno
import something
something.somethingelse()
}}}

This currently renders (with the arguments ignored) as:

{{{#!python annotations=lineno
import something
something.somethingelse()
}}}

But with the following change to source:trunk/trac/wiki/formatter.py< at >10919
#L345

{{{
#!diff
--- formatter.py (revision 10865)
+++ formatter.py (working copy)
< at >< at > -321,8 +321,19 < at >< at >
                                                     text)

     def _mimeview_processor(self, text):
-        return Mimeview(self.env).render(self.formatter.context,
-                                         self.name, text)
+        annotations = self.args['annotations'] \
+        if 'annotations' in self.args and \
+        self.args['annotations'] in ['lineno'] \
+        else None
+
+
+        if annotations:
+            return Mimeview(self.env).render(self.formatter.context,
+                                             self.name, text,
+                                             annotations=[annotations])
+        else:
+            return Mimeview(self.env).render(self.formatter.context,
+                                             self.name, text)
     # TODO: use convert('text/html') instead of render

     def process(self, text, in_paragraph=False):
}}}

It would render as follows (attached image):
(The spam bot prevented me from uploading the file, so here is a link on
imgur)

[http://i.imgur.com/lNBoB.jpg An example of what code blocks with annotated
line numbers can look in a wiki block with some other content around it for
context.]

So this is nice, but there are some issues with it.  The anchors need to be
provided with more context.  The line number annoatator was designed for
the display of single files, but the anchor needs to know not just the URL,
but the comment # / description # / code block # / etc.  The link to the
eighth line in the fourth code block on the fifth comment might look
something like this: #comment:5:codeblock:4:L8.  Or something shorter?
#c5:cb4:L8

This would mean analyzing the way arguments are passed around to annotator
objects, and how to provide that contextual information.  This would
increase the risk associated with the change as it would be broader.  Also,
with possible (?) changes to the WikiParser, I don't know if that is wise?
Although this is much less a parsing issue in my (limited) view, but more
of a message passing issue.

I'd be happy to start researching passing that contextual information, and
providing a patch with included tests.  Any feedback on that?

[Trac-dev] Re: request to contribute/edgewall account

Franz — 2012-05-07T09:38:59

Hi Hans-Peter,

there's a page, which explains how to contribute:
http://trac.edgewall.org/wiki/HowToContribute#CodeContributions

As far as I know, best entry point is to create some patches for
bitesized tickets (tickets, which have keyword "bitesized").

Best regards,
Franz


On 26 Apr., 08:54, Hans-Peter Locher <locher.hanspe...< at >googlemail.com>
wrote:

Re: [Trac-dev] request to contribute/edgewall account

Hans-Peter Locher — 2012-04-26T06:54:35

Hi Christian,
I'm fine with contributing to tickets and submiting patches

( I've updated the patch for http://trac.edgewall.org/ticket/7339  )

I recognized that there are some very long running tickets,

Is there something one can do,
despite contributing patches / tickets / voting for tickets to 

get some tickets done?

Maybe some fundraising for a particular feature or stuff like that?

Best regards

Hans-Peter



 
Am 25.04.2012 um 23:09 schrieb Christian Boos:

Re: [Trac-dev] request to contribute/edgewall account

Christian Boos — 2012-04-25T21:09:31

Hello Hans-Peter,

On 4/25/2012 10:24 AM, mrsavage wrote:

You're more than welcome! These days, there's not much activity on the 
Trac-dev mailing list, but don't worry, there's always something 
interesting happening on the t.e.o Trac itself.

We're currently slowly but surely shaping trunk to become 0.13 (err, 
1.0), so there's a lot of polishing and finishing touches to do.

If you have any general question, or anything else to discuss, don't 
hesitate to engage a discussion on this mailing list.


Well, the current policy is that only the committers have an account 
there. The usual graduation path leading to being a committer is to 
contribute some interesting patches and show some commitment to the 
project. IOW, just start hacking away ;-)

[Trac-dev] request to contribute/edgewall account

mrsavage — 2012-04-25T08:24:24

Hi Trac Team,
first of all - trac is awesome, thank's to all involved developers.

I'm a software developer developing trac based web applications since
1,5 years.
We 're using trac much inside the company I work for (http://
www.inquant.de).
I'm coding python since 4 years, mostly Plone, lately more trac and
some django.

I like to contribute (tickets / patches maybe more in the future) to
trac.

Would you grant me an account (mrsavage) on trac.edgewall.org
I couldn't find any "join-form" on the site.

Best regards

Hans-Peter Locher

github: mrsavage
irc: mr_savage

[Trac-dev] Re: SubversionException "SQLite is required to be compiled and run in thread-safe mode"

victoria — 2012-04-18T14:08:49

Although in your case the problem is not with mod_dav_svn the same
solution should work for you, compiling PHP with an external sqlite
(threadsafe compiled) should work. If when you disable php works, then
it seems that the issue you are finding is very similar to the one we
found.

Other things you could try/investigate:
- If you are getting the error when you are trying to execute any
specific action (not when starting a apache) you may try to configure
which environment is loaded from your wsgi script (I'm not sure it
will work though)
- Another option that may work could be to compile subversion
statically
- Try BitNami Trac stack :) it uses it own environment (Apache with
mod_wsgi, python 2.6.5, subversion and Trac 0.12 and will not
interfere with your current environment)

[Trac-dev] Re: SubversionException "SQLite is required to be compiled and run in thread-safe mode"

yoni shalom — 2012-04-17T06:21:22

I don't think I'm using mod_dav_svn or mod_authz_svn, and the error happens 
even if I move  libphp5  to the very end of the module list, 
because of the lazy (dynamically loaded) nature of python dependencies (I'm 
using WSGI)

So I don't see an option other than either compiling apache by myself, or 
turning off php.

On Monday, April 16, 2012 11:29:45 AM UTC+3, victoria wrote:
On Monday, April 16, 2012 11:29:45 AM UTC+3, victoria wrote:

[Trac-dev] Re: SubversionException "SQLite is required to be compiled and run in thread-safe mode"

victoria — 2012-04-16T08:29:45


On Apr 15, 11:00 pm, yoni shalom <silve...< at >gmail.com> wrote:

In BitNami we found that in our BitNami Subversion Stack. The problem
is that Apache is loading the implementation of libsqlite included in
libphp5 which conflicts with subversion.

One (easiest) solution is to load the apache php module after the
mod_dav_svn and mod_authz_svn modules in apache (http://
answers.bitnami.org/questions/1951/sqlite-is-required-to-be-compiled-
and-run-in-thread-safe-mode).

The other solution is to compile apache yourself running the configure
script with the options --with-pdo_sqlite=/path/to/sqlite --with-
sqlite3=/path/to/sqlite

[Trac-dev] SubversionException "SQLite is required to be compiled and run in thread-safe mode"

yoni shalom — 2012-04-15T21:00:14

Hi, 
after a long while trying to debug this, it seems like php5 is making 
new subversion installs not able to talk to trac repository browser. 

see : http://www.snowbotic.com/archives/61 regarding dav_svn, which 
seems to have a similar problem. 

The problem looks like it relates to php5 and libsvn where php5's 
bundled sqlite library has a version that doesn't work with newer 
subversion repo's, and it gets loaded before the one python tries to 
load dynamically via its swig interface. 

I'm not sure this is actually the case, just that as a fact when I 
disable the php5 module in my apache, the problem goes away. 

Ideas ?

[Trac-dev] genshi can't select xpath element based on its contents

Chad Phillips — 2012-04-15T08:25:40

cross-posting http://genshi.edgewall.org/ticket/521

 While customizing my Trac installation, I ran across a particularly sticky 
problem: it does not seem possible to use the contains() xpath function in 
genshi in a way that allows conditionally selecting an element based on its 
contents. 

The particular example are labels in the change history for Trac. These are 
inside strong tags, but have no tag metadata to use for the xpath selector, 
so matching on the contents of the strong tag is the only way to alter the 
ones I want. 

The non-working code that I believe should work: 

{{{#!html 

 <!-- 

 Rewrite labels in the change history. This is busted but *should* work The 
error I get is: 

 File 
"/usr/lib/python2.6/site-packages/Genshi-0.6-py2.6.egg/genshi/path.py", 

 line 932, in as_float return float(as_scalar(value)) ValueError?<http://genshi.edgewall.org/wiki/ValueError>: 
invalid literal for float(): . 

  --> 

 <strong py:match="ul[< at >class='changes']/li/strong[contains(.,'Reporter')]" 

 py:attrs="select('< at >*')"> 

 Champion: 

 </strong> 

 }}} 

Also tried *text()* instead of *.* in contains(), that also errors out. 

Here is the code I finally got to work, after literally hours of screwing 
around and research: 

{{{#!html 

 <!-- 

 Rewrite labels in the change history. 

  --> 

 <strong py:match="ul[< at >class='changes']/li/strong" 

 py:attrs="select('< at >*')"> 

 <py:with vars="text=select('text()').render();"> 

 <py:choose test="text"> 

 <py:when test="'Owner'">Liaison</py:when> <py:when 
test="'Reporter'">Champion</py:when> <py:when 
test="'Milestone'">Target</py:when> <py:otherwise>$text</py:otherwise> 

 </py:choose> 

 </py:with> 

 </strong> 

 }}} 

If I hadn't eventually realized that select() is represented as a stream 
instead of a string, I never would have gotten this working, either. 
Thankfully the documentation at 
http://genshi.edgewall.org/wiki/Documentation/0.5.x/streams.html#serializationprovided me with the render() method so I could finally compare strings in 
py:choose. 

I'd like to strongly advocate that contains() be fixed to work properly, as 
it shouldn't be necessary to jump through all these hoops in order to match 
on an element's contents.

[Trac-dev] Re: Trac-Upgrade: Error while deleting old attachments directory

Franz — 2012-04-13T07:03:32

Found out that I just have to delete attachments folder manually, as
commented in http://trac.edgewall.org/ticket/10313#comment:57