Opened 7 years ago

Closed 6 years ago

#6277 closed Bug/Something is broken (fixed)

consider upgrading to trac 1.0

Reported by: Daniel Kahn Gillmor Owned by: Daniel Kahn Gillmor
Priority: High Component: Tech
Keywords: trac wheezy git subversion Cc:
Sensitive: no


Trac's upstream released version 1.0 back in september. Among other features, this new release includes builtin support for presenting public git repositories and the ability for RSS feeds to use authenticated logins.

This new version of trac is not in debian at the moment due to the freeze for the impending release of wheezy.

However, if these features are appealing enough, we may want to consider packaging the new version of trac and providing experimental debian packages of it. I've opened DebianBug:690018 to cover that project. Doing that properly would probably involve first upgrading to wheezy, and then dealing with the trac package.

Change History (10)

comment:1 Changed 6 years ago by Daniel Kahn Gillmor

Status: newassigned

I've just upgraded trac from 0.12.2 to 0.12.4.

I'm also working on debian packaging for trac in git now:


comment:2 Changed 6 years ago by Daniel Kahn Gillmor

It would be good to resolve #4959 before doing this upgrade.

comment:3 Changed 6 years ago by Daniel Kahn Gillmor

Once we're on trac 1.0, the guidelines to migrate from svn to a multi-repo setup should be useful.

Last edited 6 years ago by Daniel Kahn Gillmor (previous) (diff)

comment:4 Changed 6 years ago by Daniel Kahn Gillmor

I've just prepared packages for trac 1.0.1 for debian experimental. I will be preparing a backport to squeeze for installation on moses as a next step.

comment:5 Changed 6 years ago by Daniel Kahn Gillmor

Priority: LowHigh

I'm actively working on this now. I just tested the sensitivetickets plugin against this new version, and it seems to work fine. So i'm going to try to address #4959 first, and if that's doable, i'll move ahead with the upgrade.

comment:6 Changed 6 years ago by Daniel Kahn Gillmor

#4959 is now complete, so this upgrade is mostly ready to go.

I've installed the needed dependencies on moses (backporting where needed).

I've tested the installation on a local instance.

I'm in the process of reviewing all the plugins we're using. It looks to me like i ought to update DebianPackage:trac-tags since there has been upstream work done on that related to the new release as well.

The rest of the plugins all seem good to go for 1.0.

comment:7 Changed 6 years ago by Daniel Kahn Gillmor

I've just upgraded trac-tags to 0.7 after packaging and uploading it to debian.

comment:8 Changed 6 years ago by Daniel Kahn Gillmor

OK, the upgrade appears to be complete. i still need to write up my notes.

comment:9 Changed 6 years ago by Daniel Kahn Gillmor

The upgrade got stuck because of the privilege separation we're doing. there were three places where it got stuck:


everything in /srv/trac/support/attachments got moved to /srv/trac/support/files, and used different names.

Since the upgrade was done by the supportdb user, and those attachments were created by the web service user, the file move couldn't be done cleanly. I did this by changing ownership of the files and directories to supportdb before the upgrade, and then changing the ownership back to www-data back after the upgrade.

What i probably should have done was to use setfacl as the www-data user to grant permissions on the relevant source directories and files to supportdb, and setfacl as the supportdb user to grant permissions on the recreated directories back to www-data. This would have avoided extra activity as the superuser.

A handful of files didn't get transferred, i think because they were no longer referred to by the database. I've backed those up as root@moses:tickets/6277/old-attachments.tgz in case they're needed.


the upgrade wanted to rewrite /srv/trac/support/conf/trac.ini (in reality, it looks like it just sorted the file and discarded comments :/). I needed to grant supportdb write access to /srv/trac/support/conf to be able to make this change. after the transition, i locked supportdb out of writing those files again.


the upgrade changed the database in some way, and didn't address permissions. I fixed this (as the supportdb system user in psql support) with:

support=> grant all on cache to "www-data";

comment:10 Changed 6 years ago by Daniel Kahn Gillmor

Resolution: fixed
Status: assignedclosed

OK, i think this is all taken care of.

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.