Thanks. I have just been updating along 1.0.x with zero issues,
although I realize that minor version bumps really ought to be uneventful.
trac is in pkgsrc proper, and there are plugins in a 2nd-tier repo.
Many of these are tracking revision numbers in svn, and probably should
be updated as wel
Assuming I updated the pkgsrc entry from 1.0 to 1.2, would it be
generally safe for some machine with a trac install to have the package
updated and a reboot? Do most plugins that worked with 1.0 work with
1.2? (I am talking about a trac install that is clean and working well,
with an admin who
The most straightforward thing, and what the instructions assume, is
that you have a repository on the same machine that runs trac. I
recommend that you be comfortable adminsistering git by itself before
integrating with trac.
--
You received this message because you are subscribed to the Googl
RjOllos writes:
>> What is the highest version of pgsql that anyone has working well with
>> trac 1.0.12?
>
> I develop and run the test with 9.5.3 on Mac OSX, so Trac should be fine.
Trac 1.0.12 with 9.5.3 (NetBSD 6) seems to work fine. Upgrading was
uneventful.
>> What is the highes
I am upgrading some servers from old branches of pgsql to newer ones.
I know in the past there have been problems with newer pgsql being
stricter about quoting etc. and not working well with trac.
So, I wonder:
What is the highest version of pgsql that anyone has working well with
trac 1.0.1
Greg Troxel writes:
> However, the display of the field shows "True" or "False", and I find
> this unhelpful in quickly scanning the list. I'd like it to say "yes"
> or "", meaning that the display would have a blank cell if it weren'
I just created a custom field with name "customer" and label "Customer
Visible" to denote certain tickets, in order to prepare views for
customer discussion, excluding lots of bugfix tickets. That all works
fine following the directions at
https://trac.edgewall.org/wiki/TracTicketsCustomFields
Roger Oberholtzer writes:
> I have a Trac instance that uses an SQLite database. All is working
> fine. I may need to change the domain name of the site from
> http://www.old.se/systems to http://www.new.se/systems. 'systems' is
> the Trac instance, which will retain the same name.
>
> I know th
In pkgsrc, we have a separate ja-trac, dating from a time when
localization was hard, at least for Japanese. There is a proposal to
remove it as no longer useful.
I am curious about the experiences of people useing trac localized in
Japanese. Does the current release just work fine assuming loc
David Cozens writes:
> sudo -u www-data trac-admin /var/trac/projects/play repository resync "play"
>
> This gives the following error
>
> TracError: Unsupported version control system "svn":
> /usr/lib/python2.7/dist-packages/libsvn/_core.so: undefined symbol:
> svn_uri__is_child
That looks
RjOllos writes:
> I'm sorry for the inconvenience caused by the package name. 1.0.6 and
> 1.0.6post1 were never made available due to packaging errors. The post1 and
> post2 were necessary because packages on PyPI can't be overwritten. So we
> followed the conventions recommended in the Pytho
Is there a 1.0.6? There are release notes:
http://trac.edgewall.org/wiki/TracChangeLog
but in the download dir:
http://ftp.edgewall.org/pub/trac/
no file with the right name, and lots of "post" stuff.
--
You received this message because you are subscribed to the Google Groups "Trac
Us
I have updated trac in pkgsrc to 1.0.3.
There is a stray patch in pkgsrc. Perhaps this is already in 1.1, but
it at least used to be needed in 1.0.
$NetBSD: patch-tracopt_versioncontrol_git_PyGIT.py,v 1.1 2014/03/11 17:41:44
gdt Exp $
The git browser can fail if the git log process has already
"anna-maria.kotulla" writes:
> I have to migrate Trac from one server to another one. I could not find a
> method to transfer the milestones, can you suggest me a solution?
Did you move the entire database? Is the list of milestones stored
someplace else?
pgpnCl7nyOSnB.pgp
Description: PGP
For what it's worth, I have been running several trac instances with
postgresql (on NetBSD) starting around late 2007. Generally things have
been fine, and occasionally updating to a newer postgresql version has
exposed bugs in trac's SQL code, typically type sloppiness.
I have not tried subtick
I recently cleaned up a trac (1.0 branch) install that still had the
gitplugin. This was fairly simple, as I just enabled builtin git and
disabled the plugin. However, I have some sync lines in trac.ini left
over, and it seems I'm not set up for best practices. This message is
really a request
Henrik Granlund writes:
> [trac]
> repository_dir = /opt/git/sc2genetics2/.git
> repository_type = git
Also, it's unusual to have a bare repository with that kind of path (but
not wrong or non-functional). The typical path would be
/opt/git/sc2genetics2.git
which is a clue that the directory
Keith Fetterman writes:
> What is the most effective way to use "accepted" versus "owned", and rank
> the lists in the order you plan to work on them? One thought I had was to
> mark the tickets I am currently working on as "accepted". The other
> tickets that I will be working on in the futur
Robert Mottishaw writes:
> On> I'm also migrating to MySQL from SQLite. When I try to load the SQL from
> the SQLite dump, the import fails because there are only 4 parameters in
> the INSERT statements into the 'revisions' table, when the schema shows
> that there are 5 parameters and then the
hidalgo writes:
> I have trac 0.12 installed with python 2.4. everythings working fine
python 2.4 is ancient. I would suggest using 2.6. Probably a lot of
other people will view 2.4 as ancient and not worth spending time to
work on.
pgpEjbUbcoCRG.pgp
Description: PGP signature
We use postgresql for 2 internal tracs on 0.12, one is pretty large
(6,000 tickets; at least 50 ticket updates per workday and hundreds of
wiki pages). The only issues we've had have been occasional plugins
that have like one or two lines of SQL that's invalid for Postgresql.
We also had
"Chris Nelson" writes:
> MasterTickets plugin (http://trac-hacks.org/wiki/MasterTicketsPlugin)
> has been updated recently but still says "there are no explicit
> features that can assist you with sub-task management ... Although it
> would be cool." TracDependency plugin
I have on my todo lis
Olemis Lang writes:
>
> Mac OS X is (AFAIK) a full FreeBSD system with a proprietary kernel
> and Cocoa & other Mac specific libs working somewhere on top of it .
That's not true. Mac OS X is Darwin plus mac UI on top. Darwin is sort
of a cross between mach and some freebsd code and I think s
Josh Godsiff writes:
> The TracOnOSX page appears several major versions out of date.
>
> I suggest you follow the guides for one of the more modern flavours of
> Linux. (Or BSD, if there's one of those floating around). OSX and
> Linux are fairly similar under the hood, so most of it should
> t
I am planning on moving my Trac 0.12+svn to a newer version of openSUSE
(11.0 -> 11.3). That means that two significant components will change
version:
svn: 1.5.7 -> 1.6.9
python: 2.5 -> 2.6.5
I am guessing that I will need to reinstall all components for python.
Ye
Samuel Monsarrat writes:
> I have a number of trac envs that cannot be public at all, I cannot
> allow anonymous access to them. In trac 0.11 I used
> AuthRequiredPlugin (http://trac-hacks.org/wiki/AuthRequiredPlugin) to
> rederect all anonymous users to the form based login system. I have
> j
I found a lot of pgsql workers showing 'idle in transaction' and over
time this caused a lot of wedging.
I applied the following fix, and it solved the problem. If you think
this is sensible, I'd appreciate it being committed upstream.
(I am still on r5370 via pkgsrc.)
--- tande_filters.py.~1~
Joeri De Backer writes:
> I've set the authz_file parameter in my trac.ini, and everything works as
> expected.
>
> The only issue I have, is the following: some of my users are only allowed
> to see a part of my repository, so they only have read/write rights on a
> certain directory (let's say
I have gotten mastertickets to work with postgresql 8.3. The problem is SQL
like
"WHERE dest = %s", self.tkt.id()
which for example passes "WHERE dest = 34" which was fine in earlier
pgsql but causes 8.3 to throw a type mismatch error because there is no
= function that takes a strings and a
After looking into the most current version of mod_python, I found
that there is little to no support for it - development seems to have
stopped about 1 1/2 years ago.
The last active developer has suggested that users move to mod_wsgi.
Reference:
http://code.google.com/p/modwsgi/
I know this is bogus, but it's working for me for the moment.
--- trac/ticket/notification.py.orig2009-06-30 15:19:00.0 -0400
+++ trac/ticket/notification.py
@@ -148,7 +148,16 @@ class TicketNotifyEmail(NotifyEmail):
'changes_descr': changes_descr,
'change':
I have a fairly large trac install for a team of about 20. Our current
practice is for everyone to see every ticket change. This helps
communication and is also annoying. I realize that's a tough call, but
that's not the current issue. We implement this with
smtp_always_cc = group-mailing-l
I upgraded a trac server to new hardware and in the process took pgsql
From 8.1 to 8.3. Viewing of individual tickets failed:
Trac detected an internal error:
OperationalError: ERROR: operator does not exist: text = integer
LINE 1: SELECT dest FROM mastertickets WHERE source=1222 ORDER BY de.
Thanks. And that is persistent? I.e., once they've done that it
persists? Or does it disappear with the cookie?
Mine are keyed with authenticated user names from .htpassword - I don't
have any unauthenticated users.
I have no idea what happens when user cookies are lost, but I'd expect
they
When people put their emails in via the preferences, where are these
stored?
In the database:
#!/bin/sh
psql trac-foo -c "select * from session_attribute where name='email'"
psql trac-foo -c "select * from session_attribute where name='name'"
pgptbGJF3ZWW4.pgp
Description: PGP signature
Our customer uses the JIRA system for issues, and JIRA has the nice feature
of Links - it allows establishing a link in a given ticket (i.e. tic_1) to
another related ticket (i.e. tic_2) in a dedicated field on the ticket.
There is then a LINK section on the ticket that will show tic_2 (wh
The company I work for uses Trac quite heavily, and I was recently
tasked with getting Nagios up and running to replace our current
monitoring system, I was wondering if anyone had done any kind of
trac/nagios integration that would allow creation of a trac ticket
from a nagios alert? I
I am running a trac server that feels slower than it ought to be. Are
there benchmarks or load testers that can be quantitative about this,
and that can measure where time goes?
I am running
NetBSD 4 on xen (i386)
apache 2.2
mod_wsgi
pgsql 8.1
There are about 100 users with accounts
Ariel Balter writes:
> One possibility would be to have "tasks" or "projects" in addition to
> "tickets". Another might be if, as you have said, to define the right
> kind of edges--connections between tickets.
Tickets are already, by default, of type { defect, enhancement, task }.
> I chan
That is a good point. Just to make sure I better understand, you are
happy with the pointing-to structure of the tickets, but the question
was how to have effort and such also add up along a certain path. Is
that a better statement of your question?
I am sort of happy with it. The s
Ariel Balter writes:
> One would like to be able to do all of the following:
> Case 1:
> Ticket #A depends on tickets #B, #C, and #D all being done. In the
> lingo of the MasterTicketPlugin, tickets #B, #C, and #D block #A
> Case 2:
> Tickets #B, #C, and #D all depend on #A being done. Or, #A
Quick noob question:
How does one use the MasterTicketPlugin?
I will assume you have of course read
http://trac-hacks.org/wiki/MasterTicketsPlugin
In general, how does one build a ticket hierarchy?
The MasterTickets enables expressing directed edges between tickets, so
you can store "tick
I'm on an ubuntu server (9.04 jaunty). The trac server is virtualized,
so I was able to do a lot of experimenting without fear of messing
anything up. My ultimate solution was to simply remove the trac from
ubuntu and install it using easy_install. I had to point /usr/bin/
python back to
Jim Podroskey writes:
> Would you mind giving some more information about how you switched
> Trac to use python2.5?
>
> I've installed 2.5 and switched the /usr/bin/python link to point to
> 2.5 instead of 2.6, but I'm not sure what I need to do to make apache
> and mod_python or whatever acknow
I have edited the wiki:
http://trac-hacks.org/wiki/ProjectManagementIdeas
and added the notion that tasks are represented as tickets. If you
think otherwise, please explain - I'm not sure this is right, but it
seems obvious. I have also put a bit more of an earned value spin on
things.
I r
> I would say that A does not get allocated resources, just AA and AB, and
> A's planned start time is the earlier of AA and AB, and planned end the
> later, and that's that.
> In your example AA will be done in 4 days and
> AB 7.5 so that's A's finish time.
>
I m not sure about how
"Chris Nelson" writes:
> I admit to not having looked at how mastertickets is implemented. I
> *thought* it stored blocked/blockedby in additional fields of the
> ticket. Perhaps it does and you're talking about a new table for
> parent/child.
There is a new table in the database masterticket
Chris Nelson writes:
> Greg Troxel wrote:
>> I am currently using 0.11.4 with MasterTickets and
>> TimingAndEstimation.
>
> Me, too.
>
>
>> We use blocking/blocked-by for two separate meanings:
>>
>> Can't do X until Y is done.
>>
&g
I am currently using 0.11.4 with MasterTickets and TimingAndEstimation.
We use blocking/blocked-by for two separate meanings:
Can't do X until Y is done.
Ticket A comprises subtasks AA AB AC AD AE.
The second case is exactly what you need to represent a Work Breakdown
Structure in trac. I
"Chris Nelson" writes:
> Greg Troxel wrote:
>>2. Task A is composed of tasks B and C. A's estimated time is the
>>total of B's and C's.
>>
>> This makes sense, and I think it would be good to have support for
>> this indepen
2. Task A is composed of tasks B and C. A's estimated time is the
total of B's and C's.
This makes sense, and I think it would be good to have support for this
independent of a gantt plugin.
nit: Task A might have hours for A, in addition to subtasks B and C.
You might want to ban this by
If someone wants to adapt the old gantt plugin to the mastertickets
fields I would be happy to look at it, unlikely to have time to do it
myself though. Mastertickets does have a depgraph if it helps.
It seems the old gantt plugin requires you to assign start/stop dates.
What I think is nee
I installed MasterTicketPlugin and GraphvizPlugin. I can view
graphs by editing wiki page, but the dependancy graph is not
displaying when i click on 'degraph' link on ticket page. This is
problem when i use this plugins on linux. On windows it shows
dependancy graph.
The previous
I have installed the RoadmapHours plugin, and now the roadmap shows
hours instead of tickets. But, I'd like to see both lines. I could
merge the code from roadmap.py into roadmaphours.py, but it seems like
there should be a way to configure two providers and have them both run.
Is this possible?
From the wiki, I was unclear on whether the hook script replaced or
augmented the one I already used to record ticket changes. Diffing them
showed all lines changed, so I dug in. The script in
http://trac-hacks.org/svn/timingandestimationplugin/branches/trac0.11/scripts
is in DOS mode, and
I am creating a pkgsrc package for TimingAndEstimationPlugin and mostly
there. I found that the upgrade wanted to write trac.ini, which seems
unusual, but on reading the traceback it seems normal. Is my upgrade
ok, or should I be figuring out how to clean up?
www 12 /u0/TRAC/pirana > trac-admi
I have MasterTickets installed and working well. I wanted depgraphs, so
following the wiki installed GraphVizPlugin, which I got working. But
reading the source, I am thinking that MasterTickets uses graphviz
directly and doesn't use the GraphVizPlugin. If someone can confirm I will fix
the wik
"Noah Kantrowitz" writes:
> Different plugin authors do things differently. For my stuffs, I only keep
> one branch per Trac major version. I don't seem much value in ever
> installing anything other than the most recent version of a plugin. Version
> numbers are provided for human convenience m
I have several 0.11 trac instances, all on NetBSD with apache and
postgresql, and they are generally running well - thanks to all who have
worked on trac.
I am in the process of adding plugins for the first time and have a few
questions about plugin source control and releases. I use pkgsrc, a
m
Graham Dumpleton <[EMAIL PROTECTED]> writes:
> On Nov 21, 9:16 pm, "Emmanuel Blot" <[EMAIL PROTECTED]> wrote:
>> > Just be aware that Leopard ships with a more than usable Apache 2.2.X,
>> > Python 2.5.1 and subversion.
>>
>> AFAIR, it ships with a 1.4.x SVN version.
>> Hopefully, it's quite easy
I think of milestones as deliverable functionality and I use tickets
as items in my To Do list (typically a day's work or less) so I can
see progress as tickets are worked on and closed. But that leaves me
with a big gulf of resolution between a ticket and a milestone (which
might be we
Yes you're right. It's the INSERT statement and not the DELETE statement
that might fail if another transaction manages to execute and commit
between the DELETE and INSERT of the first transaction (if read
committed is being used).
I somehow managed to wrap the wrong cursor.execute st
Greg Troxel wrote:
> Occasionally ticket queries fail with a database error:
>
> Oops#
> Trac detected an internal error:
>
> OperationalError: ERROR: duplicate key violates unique constraint
"session_attribute_pk"
It appears to be a small w
"Martin S." <[EMAIL PROTECTED]> writes:
> On Nov 3, 2:04 pm, Greg Troxel <[EMAIL PROTECTED]> wrote:
>> Upgrading subversion was trivial. I just instructed the packaging
>> system (pkgsrc) to rebuild subversion and everything that depended on
>> it, a
[EMAIL PROTECTED] writes:
> I have a production server with svn 1.4 plus trac 0.10.4.
> I wolud like to migrate to svn 1.5 + Trac 0.11.1. I plan to setup another
> server (test) with 1.5 + 0.11.1, migrate all the data and then switch the
> two machine.
>
> Do you think it's a good idea or it is
Occasionally ticket queries fail with a database error:
Oops#
Trac detected an internal error:
OperationalError: ERROR: duplicate key violates unique constraint
"session_attribute_pk"
The query is this, with host and project name redacted:
https://redacted1.ir.bbn.com/projects/redacted2/quer
I am running 0.11.1 with postgresql back end via apache22 and mod_wsgi
and no plugins.
I would like a way to bulk move a bunch of tickets to a new milestone,
preferably with no email. I am thinking of writing a scrit
trac-move-tickets new-milestone # [# ...]
that just connects to the db and ba
I'm using an .htpasswd file for authentication for both Trac and
Subversion. Currently I use first names for usernames, which was a bad
idea. I want to change this to either use an email address as a
username or a surname instead. What needs to be changed for Trac &
Subversion to maintai
I've figured out that if I patch those plugins (e.g. mastertickets) to
call db.commit() (and some places calling rollback) after and
insert/updates (typically in the plugins api.py), then the plugin will
upgrade correctly.
I've searched the mailing list and bugs, and can not find any
Posting partly because it might help someone else, and partly because I
figure y'all might be amused.
In a 0.10 installation, I had a typo in the summary field of a ticket.
Not finding a way to edit that within trac, I fired up psql and typed
something wrong, setting summary on all tickets becaus
I am on a project that has 2 very distinct parts. An embedded device,
and a sister application that runs entirely on PC. From trac, I will
run them as separate milestones with separate components. The
question is really what is the best strategy for maintaining this in
the repo. I EV
I am running trac on NetBSD, with trac and all dependencies (apache 2.2,
python 2.4, postgresql 8.1, + more) installed from pkgsrc, all from
'make package' in /usr/pkgsrc/www/trac. It's been running fine since
October.
I suspect you'd have an equally easy time getting trac running on Linux,
Free
After much code tracing I think I have this figured out.
First, while I *knew* I had authz_module_name set, it was commented out,
so there was nothing mysterious there. This explained all my trouble.
The trac authorizer is only checking for read permission.
I traced through the logic, and I th
I'm running trac 0.10.4. I have an authz file, and my general
repository acl policy is that each module has a set of allowed users.
I'd like only certain people to be able to create top-level modules (to
avoid mistakes and the resulting mess, more than not trusting people's
intent).
So, I have
Following up to my own post, I've figured out a bit from others and
further reading.
0.11dev was hard to install on Mac OS X, and this makes me decide not to
run it. Given the absence of complaints about the the 0.10.4 release,
I'll go with that rather than 0.10.5dev.
sqlite: I found that pkgsr
I am about to set up a machine to serve two projects (or two machines
with one project each) with about 30-50 users per project. I will be using
some version of trac with the following (from pkgsrc):
i386 (XEN2 domU)
NetBSD 4
postfix 2.4.1
apache 2.2.6
python 2.4.4
subversion 1.4.4
76 matches
Mail list logo
