[Trac-dev] Bug Tracker ontology Baetle

Hi everyone,

If you think that creating a common ontology that are compatible with
the most popular Bug Trackers would be a good idea I would like to
encourage you to take a look at http://code.google.com/p/baetle/ - and
join the discussion at the mailing list.

I think this could be great for interoperability and integration! It
could make it easier for users of other Bug Trackers to adopt Trac in
the future.

I hope it is okay to post this on this list, I really think that the
people that develop Trac should know about Baetle.

- Erling

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Correction

Some updates on the elusive #6614 bug

Jeroen Ruigrok van der Werven wrote:
>>> I mean, might it make sense to release 0.11.0 now to get the release out the
>>> door and continue to look for these more elusive cases for a 0.11.1 release?
>>>       
>> Well, it's a more a matter of fixing the Genshi issue for 0.5, then make 
>> Trac 0.11 depend on that version. As I said in the comment:38 (linked 
>> above), 0.4.x has the #G158 bug which makes Trac unreliable in 
>> multithreaded setup, so I wouldn't recommend using it.
>>     
>
> Ok, but then releasing Genshi 0.5 becomes a blocking priority before
> releasing Trac 0.11, since we need to get the eggs, especially for Windows
> with speedups, out there.
>   

Thanks to Alec who managed to write a Genshi-only test program 
exhibiting the problem, we could narrow down the specific issue about 
the memory constantly growing when an exception was raised from a 
template to a Genshi bug. Well, I have the feeling it must rather be a 
Python bug, but at least it's triggered at (and can be worked around at) 
the Genshi level. See #G190.

But that issue is not the only problem we have w.r.t. to high memory 
usage. I think it's still relatively easy to make the memory usage grow 
to a high number where it will stay forever, even with Python 2.5. That 
has to be improved further.

[Trac-dev] Re: Correction

On Mar 3, 2008, at 1:10 PM, Christian Boos wrote:

>
> Some updates on the elusive #6614 bug
>
> Jeroen Ruigrok van der Werven wrote:
>>>> I mean, might it make sense to release 0.11.0 now to get the  
>>>> release out the
>>>> door and continue to look for these more elusive cases for a  
>>>> 0.11.1 release?
>>>>
>>> Well, it's a more a matter of fixing the Genshi issue for 0.5,  
>>> then make
>>> Trac 0.11 depend on that version. As I said in the comment:38  
>>> (linked
>>> above), 0.4.x has the #G158 bug which makes Trac unreliable in
>>> multithreaded setup, so I wouldn't recommend using it.
>>>
>>
>> Ok, but then releasing Genshi 0.5 becomes a blocking priority before
>> releasing Trac 0.11, since we need to get the eggs, especially for  
>> Windows
>> with speedups, out there.
>>
>
> Thanks to Alec who managed to write a Genshi-only test program
> exhibiting the problem, we could narrow down the specific issue about
> the memory constantly growing when an exception was raised from a
> template to a Genshi bug. Well, I have the feeling it must rather be a

[Trac-dev] Re: Bug Tracker ontology Baetle

Hi,

I had a cursory look, and I think it'd make for an interesting plugin
if somebody is interested, but it's not really a good fit for core
inclusion.

Like all things of this nature, it seems to me to be only as useful as
the number of applications that include support for it.

Alec

On 3/3/08, Erling Wegger Linde <erlingwl <at> gmail.com> wrote:
>
>  Hi everyone,
>
>  If you think that creating a common ontology that are compatible with
>  the most popular Bug Trackers would be a good idea I would like to
>  encourage you to take a look at http://code.google.com/p/baetle/ - and
>  join the discussion at the mailing list.
>
>  I think this could be great for interoperability and integration! It
>  could make it easier for users of other Bug Trackers to adopt Trac in
>  the future.
>
>  I hope it is okay to post this on this list, I really think that the
>  people that develop Trac should know about Baetle.
>
>  - Erling
>

[Trac-dev] Re: Bug Tracker ontology Baetle

[Trac-dev] trac broken on postgreSQL with standard_conforming_strings

Hi trac developers :)

we have just wasted a day of our deploy manager time :)

so I decided to let you know, that trac is broken under following
conditions:

- using postgresql 8.2 or later with configuration setting
standard_conforming_strings = on

symptoms:

'\r\n' inside wiki text, and all multiline text inside database...

solution:  do NOt use standard_conforming_strings, OR use some other
(SQL standards conformant) method of inserting newlines with SQL

preferred method would be to use E'string' escape syntax

links:
http://www.postgresql.org/docs/8.3/static/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS
http://www.postgresql.org/docs/8.3/static/runtime-config-compatible.html

cheers!

Filip Rembiałkowski
eo Networks
Warsaw, Poland

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Correction

on Mon Mar 03 2008, Brad Anderson <brad-AT-dsource.org> wrote:

> We didn't figure out what part of Trac triggered this within Python,  
> but I thought I'd mention it for this thread.  I had always assumed it  
> was my use of a CentralDatabaseManager customization that I've made to  
> the Trac code base.  You're talking about high memory usage, and not  
> so much CPU, so I don't know if it's related or not...

We've also had periodic runaway Trac processes.  I just had to kill this
one:

    PID USERNAME   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
  84924 www          4  20    0   116M  2848K kserel 0  40.0H 98.73% python

This is with 0.11-dev.

--

-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Correction

David Abrahams wrote:
> on Mon Mar 03 2008, Brad Anderson <brad-AT-dsource.org> wrote:
>
>   
>> We didn't figure out what part of Trac triggered this within Python,  
>> but I thought I'd mention it for this thread.  I had always assumed it  
>> was my use of a CentralDatabaseManager customization that I've made to  
>> the Trac code base.  You're talking about high memory usage, and not  
>> so much CPU, so I don't know if it's related or not...
>>     
>
> We've also had periodic runaway Trac processes.  I just had to kill this
> one:
>
>     PID USERNAME   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
>   84924 www          4  20    0   116M  2848K kserel 0  40.0H 98.73% python
>
> This is with 0.11-dev.
>
>   

If this happens again, please attach to the process with gdb before 
killing it.
The backtrace could give a hint about what's going on.

-- Christian

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: trac broken on postgreSQL with standard_conforming_strings

Filip Rembiałkowski wrote:
> 
> Hi trac developers :)
> 
> we have just wasted a day of our deploy manager time :)
> 
> so I decided to let you know, that trac is broken under following
> conditions:
> 
> - using postgresql 8.2 or later with configuration setting
> standard_conforming_strings = on
> 
> symptoms:
> 
> '\r\n' inside wiki text, and all multiline text inside database...

Hi Filip,

You're using the pyPgSQL module right?
I was able to reproduce this issue with pyPgSQL but not with psycopg2. 
As far as I can tell this is bug in pyPgSQL and not in Trac, since Trac 
passes all string values as bind parameters to the driver which is 
supposed to escape them correctly.

So right now psycopg2 is your only choice if you want to set 
"standard_comforming_strings" to "on".

http://pypi.python.org/pypi/psycopg2

Cheers,
Jonas

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Correction

on Wed Mar 05 2008, Christian Boos <cboos-AT-neuf.fr> wrote:

> David Abrahams wrote:
>> on Mon Mar 03 2008, Brad Anderson <brad-AT-dsource.org> wrote:
>>
>>   
>>> We didn't figure out what part of Trac triggered this within Python,  
>>> but I thought I'd mention it for this thread.  I had always assumed it  
>>> was my use of a CentralDatabaseManager customization that I've made to  
>>> the Trac code base.  You're talking about high memory usage, and not  
>>> so much CPU, so I don't know if it's related or not...
>>>     
>>
>> We've also had periodic runaway Trac processes.  I just had to kill this
>> one:
>>
>>     PID USERNAME   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
>>   84924 www          4  20    0   116M  2848K kserel 0  40.0H 98.73% python
>>
>> This is with 0.11-dev.
>>
>>   
>
> If this happens again, please attach to the process with gdb before 
> killing it.
> The backtrace could give a hint about what's going on.

Will do.

--

-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---