Trac Development Google Group

Re: [Trac-dev] Test failures on buildbot

remy.bl...@pobox.com (Remy Blank) — Thu, 26 Nov 2009 01:09:57 UT

Correct, I could finally reproduce the issue by switching my timezone to
PST. Actually, any timezone different from the one used in that
particular test (which happens to be mine) reproduces the issue.
No, actually some of the changes in [8831] were wrong. The issue is
fixed with [8857]. I guess we now have enough reasons to make a second

Re: [Trac-dev] Trac0.11.6 - Cannot operate on a closed cursor

s...@boktor.net (Grzegorz Sobanski) — Wed, 25 Nov 2009 15:09:14 UT

* Christian Boos <cb...@neuf.fr> [2009-11-23 18:22]:

Great. Thanks for testing. It seems something is broken in my
environment.

I can reproduce it with just a one request, 100% of time, so it is
either something really stupid or really bad setup somewhere.
I'll debug it more next week.

Re: [Trac-dev] Test failures on buildbot

cb...@neuf.fr (Christian Boos) — Wed, 25 Nov 2009 11:28:12 UT

Right, look at time.daylight usage in the code. Tim's buildbot must live
in a non-DST timezone.
I suppose the test has to take this into account, for choosing an
appropriate expected value.

-- Christian

Re: [Trac-dev] Test failures on buildbot

remy.bl...@pobox.com (Remy Blank) — Tue, 24 Nov 2009 15:20:12 UT

That was also my guess, but I could reproduce the issue neither with nor
without pytz.
If pytz is not installed, how could two Linux platforms have different
behaviors for this, if we only use our own timezone classes (which don't
use local TZ info)? It would basically mean that the datetime module, in

Re: [Trac-dev] Test failures on buildbot

cb...@neuf.fr (Christian Boos) — Tue, 24 Nov 2009 11:18:46 UT

None I guess, as I see <FixedOffset "GMT +1:00" 1:00:00> in the test
results, which is our own tzinfo subclass.

-- Christian

Test failures on buildbot

remy.bl...@pobox.com (Remy Blank) — Mon, 23 Nov 2009 23:45:42 UT

I have noticed that Tim's buildbot fails on trunk since I merged [8831]
(the timezone fix). For example:
[link]
Unfortunately, all tests pass on all my machines (Linux + OS X), both
with and without pytz. Any ideas what could be wrong?

Re: changed sqlite requirements in 0.12dev (#8625)

felix.schw...@agile42.com (Felix Schwarz) — Mon, 23 Nov 2009 19:17:36 UT

Am 23.11.2009 10:13, schrieb Christian Boos:
In order to provide the best possible integration with the distro (and
to lower the maintenance burden), Fedora uses a custom spec file
template. However the packaging process still uses 'setup.py
build'/'setup.py install'.
This is the current trac.spec in Fedora:

Re: changed sqlite requirements in 0.12dev (#8625)

felix.schw...@agile42.com (Felix Schwarz) — Mon, 23 Nov 2009 08:47:39 UT

Am 23.11.2009 04:09, schrieb Eli:
Mostly rumors, but I'm confident that RHEL 6 will be released in Q2.
fs

recursion-safe permission policies

cwar...@xerus.org (Christian G. Warden) — Mon, 23 Nov 2009 18:28:02 UT

Is there a recommended way of implementing IPermissionPolicy such that
multiple policies don't cause infinite recursion? I'm writing a
simple policy similar to SensitiveTicketsPolicy that requires a new
permission in order to view sensitive components, and I would like to
use it in combination with PrivateTicketsPolicy.

Re: [Trac-dev] Trac0.11.6 - Cannot operate on a closed cursor

cb...@neuf.fr (Christian Boos) — Mon, 23 Nov 2009 17:21:57 UT

...

This should work... it worked for me on Windows (older SQLite and
Pysqlite versions, then same versions) and Linux (same SQLite and
Pysqlite versions as you), using Trac 0.11.6rc1.

Even with no poolable connections, that connection should normally end
up in the _active map, and stay there until the shutdown of the request.

Trac0.11.6 - Cannot operate on a closed cursor

s...@boktor.net (Grzegorz Sobanski) — Mon, 23 Nov 2009 13:19:37 UT

Hi.

I upgraded my installations to latest 0.11 stable (8846).
Unfortunately it killed my custom plugin, tracking lead me to commit
8590 that enabled connetion pooling on linux.

In my plugin I'm reusing generating ticket group stats from roadmap to
display similar progress bars.

Some simplified code is here that triggers the error:

Re: [Trac-dev] changed sqlite requirements in 0.12dev (#8625)

t...@0x1b.com (Ed - 0x1b, Inc.) — Sun, 22 Nov 2009 05:14:24 UT

don't forget...

if from a repo, it may be handy to add a PYTHONPATH entry so it can be
found - or make a .pth file in /usr/lib64/python2.5/site-pack ages/
(YDMV)
being there and being found makes it work.

thx All

Re: [Trac-dev] Re: changed sqlite requirements in 0.12dev (#8625)

cb...@neuf.fr (Christian Boos) — Mon, 23 Nov 2009 09:13:24 UT

Thank you for these detailed informations.

Now I have another question. For building the packages, do you use the
`python setup.py bdist_rpm` method?
If not, are the extra changes needed a matter of changing the setup.cfg
or the setup.py files?
In this case, we should integrate those changes, if possible.

Trac 0.11.6rc1 is available

cb...@neuf.fr (Christian Boos) — Mon, 23 Nov 2009 09:00:50 UT

Hello,

Yesterday we prepared the first release candidate for 0.11.6:
[link]

For an overview of the changes, please see
[link]

As usual, we will be going through a period of one week of testing

Re: [Trac-dev] Re: changed sqlite requirements in 0.12dev (#8625)

retrac...@gmail.com (Eli) — Mon, 23 Nov 2009 03:09:04 UT

Is RHEL6 supposed to come out in Q1 2010, or has RedHat given any guidance on
their intentions?

Eli
------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
retrac...@gmail.com `----------------------------- --------------------