headers
Jeroen Ruigrok van der Werven | 1 Feb 15:32
Gravatar

[Trac-dev] default_timezone


Does default_timezone under [trac] even work currently?

I tried putting a 'Europe/Amsterdam' value there, but nothing. Yes, pytz is
installed.

This ties in with http://trac.edgewall.org/ticket/6635 where the default
timezone preference gets set to Asia/Qatar. The patch in that ticket has
some interesting ideas, but it's not quite there yet.

--

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
We have met the enemy and they are ours...

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 1 comment |
headers
John M Camara | 1 Feb 22:55
Picon

[Trac-dev] Re: default_timezone


On Feb 1, 9:32 am, Jeroen Ruigrok van der Werven <asmo...@in-
nomine.org> wrote:
> Does default_timezone under [trac] even work currently?
>
> I tried putting a 'Europe/Amsterdam' value there, but nothing. Yes, pytz is
> installed.
>
> This ties in withhttp://trac.edgewall.org/ticket/6635where the default
> timezone preference gets set to Asia/Qatar. The patch in that ticket has
> some interesting ideas, but it's not quite there yet.
>

I have had no luck myself with this feature on 0.11b1.  It hasn't been
much of a priority for me to investigate the source code to see if I
was setting the value incorrectly.  It would help though if the wiki
page for TracIni [1] would show example settings for each setting so
that there would be no ambiguity as to what a valid values looks
like.  Maybe these examples should be added as a 3rd column to the
tables.  For the default_timezone option there should also be a link
to valid options.

[1] http://trac.edgewall.org/wiki/TracIni
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
(Continue reading)

Permalink | Reply | 0 comments |
headers
rupert.thurner@gmail.com | 2 Feb 03:17
Picon
Gravatar

[Trac-dev] Re: t.e.o upgraded to 0.11 beta1


was the behaviour the same with and without speedup? i was just
thinking on http://genshi.edgewall.org/changeset/781. you also
remarked earlier "..not be surprised if it's some of the more
expensive versioncontrol pages". what change from 0.10.4 to 0.11 were
you thinking of ?

rupert.

On Jan 9, 9:22 pm, Jonas Borgström <jo...@edgewall.com> wrote:
> Jeroen Ruigrok van der Werven wrote:
>
>
>
> > -On [20080109 16:56], David Abrahams (d...@boost-consulting.com) wrote:
> >>I think we already found and submitted a patch for this problem:
> >>http://trac.edgewall.org/ticket/6581
>
> > It's in trunk now, r6385.
>
> > Perhaps Noah and Jonas can also give this latest trunk a spin and see how it
> > handles itself.
>
> Just for the record: I tested latest trunk again but didn't notice any
> improvement. This time there was more traffic on the server than last
> week so it didn't take longer than about 30 minutes for the server to
> start running out ofmemory. When I aborted this experiment each fcgi
> process was using about 3 times more residentmemory(325MB) compared to
> 0.10.x (around 100MB after running for a week).
>
(Continue reading)

Permalink | Reply | 39 comments |
headers
David Anderson | 2 Feb 05:46
Picon

[Trac-dev] 0.11b1 fails to install on Debian Etch and Lenny


Hi,

I've been trying for about 3 hours now to get 0.11b1 installed on
either of Debian Etch or Lenny, and have failed in both cases.

After much fighting, here are the latest symptoms:
 - The trac egg is created and deployed properly in site-packages
 - trac-admin and tracd are properly copied to /usr/bin
 - *no* data files are installed. That includes templates,
configurations, cgi-bin...

The last point is obviously the one messing with me. Everything seems
to work, except that the data files are never gathered and copied by
setuptools. Attempting to run install_data manually results in:

# python2.5 setup.py install_data
running install_data
Traceback (most recent call last):
  File "setup.py", line 89, in <module>
    """,
  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.5/distutils/dist.py", line 974, in
run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in
run_command
    cmd_obj.run()
  File "/usr/lib/python2.5/distutils/command/install_data.py", line
(Continue reading)

Permalink | Reply | 2 comments |
headers
Matt Good | 2 Feb 07:33
Gravatar

[Trac-dev] Re: 0.11b1 fails to install on Debian Etch and Lenny


On Feb 1, 8:46 pm, David Anderson <david.jc.ander...@gmail.com> wrote:
> I've been trying for about 3 hours now to get 0.11b1 installed on
> either of Debian Etch or Lenny, and have failed in both cases.
>
> After much fighting, here are the latest symptoms:
>  - The trac egg is created and deployed properly in site-packages
>  - trac-admin and tracd are properly copied to /usr/bin
>  - *no* data files are installed. That includes templates,
> configurations, cgi-bin...

For now use "sudo python setup.py develop"

It appears that the setup.py file has not been updated since the
templates were moved from the top-level into the Python package.
Sorry for the confusion, but thanks for catching this.  Obviously this
needs fixed before the release.

-- Matt
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Alec Thomas | 2 Feb 10:05
Gravatar

[Trac-dev] Re: 0.11b1 fails to install on Debian Etch and Lenny


On 02/02/2008, David Anderson <david.jc.anderson <at> gmail.com> wrote:
> I've been trying for about 3 hours now to get 0.11b1 installed on
> either of Debian Etch or Lenny, and have failed in both cases.
>
> After much fighting, here are the latest symptoms:
>  - The trac egg is created and deployed properly in site-packages
>  - trac-admin and tracd are properly copied to /usr/bin
>  - *no* data files are installed. That includes templates,
> configurations, cgi-bin...

Are you sure? Moving the core of Trac to setuptools has changed the way
data is installed, and it is now bundled with the Trac egg. For example,
after doing python setup.py install I get this:

  [root <at> cavern:~]find
/usr/lib/python2.5/site-packages/Trac-0.11dev_r6402-py2.5.egg/ -regex
'.*.\(html\|css\|png\)'  | wc -l
  94

This was always how plugins worked, and now Trac itself uses the same mechanism.

Obviously, mapping this data through your web server is quite annoying
though, so we also now have the copystatic trac-admin command. This
dumps all static resources for Trac and any plugins in the environment,
into a directory:

*[athomas <at> cavern:~/p/trac/trunk]trac-admin ../env/trunk help copystatic
copystatic <directory>
  -- Extract static resources from Trac and all plugins.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Bray | 4 Feb 17:36
Picon

[Trac-dev] Re: t.e.o upgraded to 0.11 beta1

I was just going through _speedups.c line by line just out of
curiosity.  The only thing I could find was a missing
Py_DECREF(format) at the end of Markup_repr(), which I'm pretty sure
should be there.  But I hardly think that's anywhere near related to
THE memory leak.

Erik

On Feb 1, 2008 9:17 PM, rupert.thurner <at> gmail.com
<rupert.thurner <at> gmail.com> wrote:
>
> was the behaviour the same with and without speedup? i was just
> thinking on http://genshi.edgewall.org/changeset/781. you also
> remarked earlier "..not be surprised if it's some of the more
> expensive versioncontrol pages". what change from 0.10.4 to 0.11 were
> you thinking of ?
>
> rupert.
>
> On Jan 9, 9:22 pm, Jonas Borgstr�m <jo...@edgewall.com> wrote:
> > Jeroen Ruigrok van der Werven wrote:
> >
> >
> >
> > > -On [20080109 16:56], David Abrahams (d...@boost-consulting.com) wrote:
> > >>I think we already found and submitted a patch for this problem:
> > >>http://trac.edgewall.org/ticket/6581
> >
> > > It's in trunk now, r6385.
> >
(Continue reading)

Permalink | Reply | 38 comments |
headers
Christian Boos | 4 Feb 20:06
Picon

[Trac-dev] Re: t.e.o upgraded to 0.11 beta1


Erik Bray wrote:
> I was just going through _speedups.c line by line just out of
> curiosity.  The only thing I could find was a missing
> Py_DECREF(format) at the end of Markup_repr(), which I'm pretty sure
> should be there.  But I hardly think that's anywhere near related to
> THE memory leak.

You're right on both points. Maybe you could reopen #G166, for 
completeness, so that this format leak can be fixed as well. But in my 
tests, I've been careful to disable the _speedups extension, so it's not 
related to THE leak ;-)

By the way, I'm not sure I found THE leak, but at least an important 
one. I'm still trying to get my way through the generator chain in 
Genshi to understand more precisely what the problem is, but things go 
really bad memory wise once an exception is raised from an expression 
evaluation (and it doesn't seem to be related to what we do with that 
exception later at the Trac level). I'll update #6614 when I have new 
findings.

-- 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
-~----------~----~----~----~------~----~------~--~---
(Continue reading)

Permalink | Reply | 37 comments |
headers
Christian Boos | 4 Feb 20:18
Picon

[Trac-dev] [RFC] multirepos branch (support for multiple repositories per environment)


Hello,

It's been a long standing issue and I've really become tired of 
switching my repository_dir setting manually in order to browse for my 
local changesets in the many local branches I have, so ...

I've taken a shot at implementing multiple repository support. Things 
went surprisingly smooth, mainly because I decided to keep the 
repository cache topic completely aside for now. But if you want to 
directly browse many Subversion and/or Mercurial repositories, within 
one big virtual namespace (repository names are used as disambiguation 
prefixes for paths and as suffixes for changesets), you will surely be 
interested by this branch.

More information in http://trac.edgewall.org/wiki/MultipleRepositorySupport

-- 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
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 3 comments |
headers
Jeroen Ruigrok van der Werven | 5 Feb 07:13
Gravatar

[Trac-dev] Re: t.e.o upgraded to 0.11 beta1


-On [20080204 20:07], Christian Boos (cboos <at> neuf.fr) wrote:
>By the way, I'm not sure I found THE leak, but at least an important 
>one. I'm still trying to get my way through the generator chain in 
>Genshi to understand more precisely what the problem is, but things go 
>really bad memory wise once an exception is raised from an expression 
>evaluation (and it doesn't seem to be related to what we do with that 
>exception later at the Trac level). I'll update #6614 when I have new 
>findings.

I think I read somewhere that using yield and getting exceptions might be
problematic when it comes to leaving around stray references. Perhaps this
might help you?

--

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
We have met the enemy and they are ours...

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |

Gmane