Yes, after much waiting, the Debian packages for the RT3.2 series are
now available to download. It has taken quite a while to transfer over
all the packaging from RT3.0 and ensure it all works plus add the new
bits. Apologies for the delay but we hope it has been worth the
wait.
The packages are not yet available for apt install, they will take a
couple of weeks or so to make it through all the usual checks the
ftpmasters make on upload of a new package. In the meantime you can
get .debs from http://users.ox.ac.uk/~stephen/, the current package
version is 3.2.1-1, so you want:
http://users.ox.ac.uk/~stephen/request-tracker3.2_3.2.1-1_all.deb
http://users.ox.ac.uk/~stephen/rt3.2-clients_3.2.1-1_all.deb
The packages are named request-tracker3.2 and rt3.2-clients which
means they can be installed at the same time as the request-tracker3
and rt3-clients packages. If you install both concurrently be careful
as the common commands (rt-crontool, rt-mailgate, etc…) are managed
via update-alternatives, with the 3.0 series tools currently having
the higher priority. Note that I don’t think it is possible to
actually run both systems concurrently with modperl1 or modperl2, it
might be possible with a simpler CGI environment.
Please read the README.Debian (and INSTALL.Debian if you haven’t
previously used the Debian rt packages) before proceeding.
I am sure there are going to be bugs in these first publically
available packages. We have tested them as much as possible but we
don’t have the opportunity to test even all the normal situations
never mind all the peculiar ones. Bug reports should be sent direct to
me for now until the request-tracker3.2 package appears in Debian
sid/unstable.
Have fun.
Stephen Quinney
signature.asc (189 Bytes)
I noticed today that an “RT32” port had shown up in FreeBSD Ports
(FreshPorts -- www/rt32: RT is an industrial-grade ticketing system written in Perl), and being an optimistic soul, I
decided to try installing it, via:
UPGRADE_RT30=1 make install
The install went mostly okay, but there appear to be some niggling UI
issues. Notably, the minimize buttons on the UI boxes don’t seem to
be there, and the new query builder…isn’t there.
By way of example, a screenshot or two:
http://blank.org/memory/work/rt.jpg
http://blank.org/memory/work/rt2.jpg
Should I just blow away /usr/local/rt3 and install the port from
scratch?
-n
------------------------------------------------------------memory@blank.org
Dear Future Employer: Who’s your daddy? Who’s your daddy? I think
we know. Thanks! $100,000 a year, I’ll be there on monday, please.
-chelleMarie
http://blank.org/memory/----------------------------------------------------
The install went mostly okay, but there appear to be some niggling UI
issues. Notably, the minimize buttons on the UI boxes don’t seem to
be there, and the new query builder…isn’t there.
Should I just blow away /usr/local/rt3 and install the port from
scratch?
Before you do that, find the var/mason_data directory and blow THAT away
and restart apache.
In the immortal words of Jesse Vincent (jesse@bestpractical.com):
Before you do that, find the var/mason_data directory and blow THAT away
and restart apache.
Woohoo; that did the trick.
Now, on to a more interesting problem. Whenver I try to save a search
in the new query builder, I get the following error:
Jul 26 15:15:54 zorak RT: DBD::mysql::st execute failed: Table
‘rt3.Attributes’ doesn’t exist at
/usr/local/lib/perl5/site_perl/5.8.4/DBIx/SearchBuilder.pm line 140.
(/usr/local/rt3/lib/RT.pm:250)
Jul 26 15:15:54 zorak RT: DBIx::SearchBuilder error:Table
‘rt3.Attributes’ doesn’t exist Query String is SELECT main.* FROM
Attributes main WHERE ((main.ObjectId = 23)) AND ((main.ObjectType =
‘RT::User’)) (/usr/local/rt3/lib/RT.pm:250)
Jul 26 15:15:54 zorak RT: DBD::mysql::st fetchrow_hashref failed:
fetch() without execute() at
/usr/local/lib/perl5/site_perl/5.8.4/DBIx/SearchBuilder.pm line 158.
(/usr/local/rt3/lib/RT.pm:250)
Jul 26 15:15:54 zorak RT: DBD::mysql::st execute failed: Table
‘rt3.Attributes’ doesn’t exist at
/usr/local/lib/perl5/site_perl/5.8.4/DBIx/SearchBuilder.pm line 140.
(/usr/local/rt3/lib/RT.pm:250)
Jul 26 15:15:54 zorak RT: DBIx::SearchBuilder error:Table
‘rt3.Attributes’ doesn’t exist Query String is SELECT main.* FROM
Attributes main WHERE ((main.ObjectId = 22)) AND ((main.ObjectType =
‘RT::Group’)) (/usr/local/rt3/lib/RT.pm:250)
Jul 26 15:15:54 zorak RT: DBD::mysql::st fetchrow_hashref failed:
fetch() without execute() at
/usr/local/lib/perl5/site_perl/5.8.4/DBIx/SearchBuilder.pm line 158.
(/usr/local/rt3/lib/RT.pm:250)
I gather that the port forgot to install some new tablespaces?
-n
------------------------------------------------------------memory@blank.org
“They’ve got an unmarked car with your name on it.” (–Golden Palominos)
http://blank.org/memory/----------------------------------------------------
In the immortal words of Jesse Vincent (jesse@bestpractical.com):
Before you do that, find the var/mason_data directory and blow THAT away
and restart apache.
Hm.
So last night, I did something unwise: I cvsup’ed /usr/ports and let
portupgrade do everything.
As it turns out, the perl port maintainers jumped the gun a bit:
the current port of perl is now 5.8.5, while the mod_perl port still
expects 5.8.4. Result: a very broken apache.
I used portdowngrade to roll perl back to 5.8.4, solving the proximate
problem, but now the searchbuilder functionality seems to have
vanished from RT again:
http://blank.org/memory/work/brokensearch.jpg
…and blowing away the mason_data cache doesn’t restore it.
All of the assorted perl modules (HTML-Tree; Searchbuilder, et al)
seem to be functional and up-to-date; any notion what I need to tweak
here?
-n
---------------------------------------------------memory@blank.org
$Id: .quotes,v 1.15 2003/09/18 18:33:32 memory Exp $
http://blank.org/memory/-------------------------------------------
In the immortal words of Jesse Vincent (jesse@bestpractical.com):
Before you do that, find the var/mason_data directory and blow THAT away
and restart apache.
Hm.
So last night, I did something unwise: I cvsup’ed /usr/ports and let
portupgrade do everything.
As it turns out, the perl port maintainers jumped the gun a bit:
the current port of perl is now 5.8.5, while the mod_perl port still
expects 5.8.4. Result: a very broken apache.
I used portdowngrade to roll perl back to 5.8.4, solving the proximate
problem, but now the searchbuilder functionality seems to have
vanished from RT again:
http://blank.org/memory/work/brokensearch.jpg
…and blowing away the mason_data cache doesn’t restore it.
After 'portdowngrade’ing perl to 5.8.4, did you ?
portupgrade -fr perl -x perl-5.8.4
That may or may not help.
Scott Lambert KC5MLE Unix SysAdmin
lambert@lambertfam.org
In the immortal words of Scott Lambert (lambert@lambertfam.org):
After 'portdowngrade’ing perl to 5.8.4, did you ?
portupgrade -fr perl -x perl-5.8.4
That may or may not help.
Wow, my CPUs hate you now. 
Anyway, for the record, after rebuilding pretty much everything on
this server twice, I finally got half a clue and realized…
…that the RT-Statistics-0.15 package has a slightly incompatibility
with RT 3.2.x: the “Tabs” page it puts in local/html/Elements contains
a link to the old, rt-3.0-style search function, i.e.:
B => { title => loc('Tickets'),
path => 'Search/Listing.html'
},
Replacing that with the link from the base Elements file, i.e.:
B => { title => loc('Tickets'),
path => 'Search/Build.html'
},
…solved the problem.
May I suggest that Listing.html become an alias to Build.html in
3.2.2?
-n
------------------------------------------------------------memory@blank.org
“[The] cover blurb calls Baudrillard `the most important French thinker of the
past twenty years’ – which sounds impressive, until you think of the
competition.” (–Scott McLemee)
http://blank.org/memory/----------------------------------------------------
