Re: [rt-users] fixdeps errors: DBD::SQLite and DBIx::SearchBuilder

2008-12-31 Thread Richard Foley
Hi Joseph,

It looks like DBD::SQLite is your problem - try installing that by hand first.  
It's not really RT's fault that a dependency module breaks on your particular 
system, and installing everything via CPAN is the most generic way to go.   
Once DBD::SQLite is succesfully installed then, and only then, try the 'make 
fixdeps' command again.

Failed Test Stat Wstat Total Fail  List of Failed
---
t/06error.t011 22  2
t/07busy.t 011 88  5-8
Failed 2/29 test scripts. 5/463 subtests failed.
Files=29, Tests=463,  7 wallclock secs ( 1.48 cusr +  1.45 csys =  2.93 CPU)
Failed 2/29 test programs. 5/463 subtests failed.
make[1]: *** [test_dynamic] Error 255
make[1]: Leaving directory `/root/.cpan/build/DBD-SQLite-1.14-6O4X44'
  MSERGEANT/DBD-SQLite-1.14.tar.gz
  /usr/bin/make test -- NOT OK

-- 
Richard Foley
Ciao - shorter than aufwiedersehen

http://www.rfi.net/

On Tuesday 30 December 2008 21:41:58 Joseph Spenner wrote:
 
 --- On Tue, 12/30/08, Jesse Vincent je...@bestpractical.com wrote:
 From: Jesse Vincent je...@bestpractical.com
 Subject: Re: [rt-users] fixdeps errors:  DBD::SQLite and DBIx::SearchBuilder
 To: Joseph Spenner joseph85...@yahoo.com
 Cc: rt-users@lists.bestpractical.com
 Date: Tuesday, December 30, 2008, 12:35 PM
 
  When trying to manually install DBD::SQLite, I see:
  
  MSERGEANT/DBD-SQLite-1.14.tar.gz
  /usr/bin/make test -- NOT OK
  
 
 Can you perhaps send the list the actual errors you got?
  
 
 Yes.  Here is the total output:
 
 r...@tuxtrack:/space/rt-packages/rt-3.8.1# 
 r...@tuxtrack:/space/rt-packages/rt-3.8.1# make fixdeps
 /usr/bin/perl ./sbin/rt-test-dependencies --verbose --install --with-mysql 
 --with-fastcgi
 perl:
 =5.8.3(5.10.0)...found
 users:
 rt group (apache)...found
 bin owner (root)...found
 libs owner (root)...found
 libs group (bin)...found
 web owner (apache)...found
 web group (apache)...found
 CLI dependencies:
 Term::ReadKey...found
 Getopt::Long = 2.24...found
 HTTP::Request::Common...found
 Term::ReadLine...found
 Text::ParseWords...found
 LWP...found
 CORE dependencies:
 Class::ReturnValue = 0.40...found
 Text::Quoted = 2.02...found
 CSS::Squish = 0.06...found
 Encode = 2.13...found
 Module::Versions::Report = 1.05...found
 MIME::Entity = 5.425...found
 DBI = 1.37...found
 Locale::Maketext::Lexicon = 0.32...found
 Devel::StackTrace = 1.19...found
 Digest::base...found
 Time::ParseDate...found
 File::Temp = 0.18...found
 Locale::Maketext = 1.06...found
 Tree::Simple = 1.04...found
 Text::Template...found
 Scalar::Util...found
 HTML::Scrubber = 0.08...found
 File::Spec = 0.8...found
 Calendar::Simple...found
 DBIx::SearchBuilder = 1.54...MISSING
 Mail::Mailer = 1.57...found
 File::ShareDir...found
 Regexp::Common...found
 Digest::MD5 = 2.27...found
 HTML::Entities...found
 Cache::Simple::TimedExpiry...found
 File::Glob...found
 Locale::Maketext::Fuzzy...found
 Time::HiRes...found
 Text::Wrapper...found
 Log::Dispatch = 2.0...found
 UNIVERSAL::require...found
 Email::Address...found
 
 Install module DBIx::SearchBuilder
 Going to read /root/.cpan/Metadata
   Database was generated on Tue, 30 Dec 2008 16:26:51 GMT
 Running install for module 'DBIx::SearchBuilder'
 'YAML' not installed, falling back to Data::Dumper and Storable to read 
prefs '/root/.cpan/prefs'
 Running make for J/JE/JESSE/DBIx-SearchBuilder-1.54.tar.gz
 CPAN: Digest::SHA loaded ok (v5.45)
 CPAN: Compress::Zlib loaded ok (v2.008)
 Checksum 
for /root/.cpan/sources/authors/id/J/JE/JESSE/DBIx-SearchBuilder-1.54.tar.gz 
ok
 DBIx-SearchBuilder-1.54/
 DBIx-SearchBuilder-1.54/Changes
 DBIx-SearchBuilder-1.54/ex/
 DBIx-SearchBuilder-1.54/ex/create_tables.pl
 DBIx-SearchBuilder-1.54/ex/Example/
 DBIx-SearchBuilder-1.54/ex/Example/Model/
 DBIx-SearchBuilder-1.54/ex/Example/Model/Address.pm
 DBIx-SearchBuilder-1.54/ex/Example/Model/Employee.pm
 DBIx-SearchBuilder-1.54/inc/
 DBIx-SearchBuilder-1.54/inc/Module/
 DBIx-SearchBuilder-1.54/inc/Module/AutoInstall.pm
 DBIx-SearchBuilder-1.54/inc/Module/Install/
 DBIx-SearchBuilder-1.54/inc/Module/Install/AutoInstall.pm
 DBIx-SearchBuilder-1.54/inc/Module/Install/Base.pm
 DBIx-SearchBuilder-1.54/inc/Module/Install/Include.pm
 DBIx-SearchBuilder-1.54/inc/Module/Install/Makefile.pm
 DBIx-SearchBuilder-1.54/inc/Module/Install/Metadata.pm
 DBIx-SearchBuilder-1.54/inc/Module/Install.pm
 DBIx-SearchBuilder-1.54/Makefile.PL
 DBIx-SearchBuilder-1.54/MANIFEST
 DBIx-SearchBuilder-1.54/META.yml
 DBIx-SearchBuilder-1.54/README
 DBIx-SearchBuilder-1.54/ROADMAP
 DBIx-SearchBuilder-1.54/SearchBuilder/
 

Re: [rt-users] fixdeps errors: DBD::SQLite and DBIx::SearchBuilder

2008-12-31 Thread Ruslan Zakirov
It's ok to force install DBD::SQLite, I saw this errors too. This
module is required to test DBIx::SearchBuilder functionality only.

On Wed, Dec 31, 2008 at 2:01 PM, Richard Foley richard.fo...@rfi.net wrote:
 Hi Joseph,

 It looks like DBD::SQLite is your problem - try installing that by hand first.
 It's not really RT's fault that a dependency module breaks on your particular
 system, and installing everything via CPAN is the most generic way to go.
 Once DBD::SQLite is succesfully installed then, and only then, try the 'make
 fixdeps' command again.

 Failed Test Stat Wstat Total Fail  List of Failed
 ---
 t/06error.t011 22  2
 t/07busy.t 011 88  5-8
 Failed 2/29 test scripts. 5/463 subtests failed.
 Files=29, Tests=463,  7 wallclock secs ( 1.48 cusr +  1.45 csys =  2.93 CPU)
 Failed 2/29 test programs. 5/463 subtests failed.
 make[1]: *** [test_dynamic] Error 255
 make[1]: Leaving directory `/root/.cpan/build/DBD-SQLite-1.14-6O4X44'
  MSERGEANT/DBD-SQLite-1.14.tar.gz
  /usr/bin/make test -- NOT OK

 --
 Richard Foley
 Ciao - shorter than aufwiedersehen

 http://www.rfi.net/

 On Tuesday 30 December 2008 21:41:58 Joseph Spenner wrote:

 --- On Tue, 12/30/08, Jesse Vincent je...@bestpractical.com wrote:
 From: Jesse Vincent je...@bestpractical.com
 Subject: Re: [rt-users] fixdeps errors:  DBD::SQLite and DBIx::SearchBuilder
 To: Joseph Spenner joseph85...@yahoo.com
 Cc: rt-users@lists.bestpractical.com
 Date: Tuesday, December 30, 2008, 12:35 PM

  When trying to manually install DBD::SQLite, I see:
 
  MSERGEANT/DBD-SQLite-1.14.tar.gz
  /usr/bin/make test -- NOT OK
 

 Can you perhaps send the list the actual errors you got?
 

 Yes.  Here is the total output:

 r...@tuxtrack:/space/rt-packages/rt-3.8.1#
 r...@tuxtrack:/space/rt-packages/rt-3.8.1# make fixdeps
 /usr/bin/perl ./sbin/rt-test-dependencies --verbose --install --with-mysql 
 --with-fastcgi
 perl:
 =5.8.3(5.10.0)...found
 users:
 rt group (apache)...found
 bin owner (root)...found
 libs owner (root)...found
 libs group (bin)...found
 web owner (apache)...found
 web group (apache)...found
 CLI dependencies:
 Term::ReadKey...found
 Getopt::Long = 2.24...found
 HTTP::Request::Common...found
 Term::ReadLine...found
 Text::ParseWords...found
 LWP...found
 CORE dependencies:
 Class::ReturnValue = 0.40...found
 Text::Quoted = 2.02...found
 CSS::Squish = 0.06...found
 Encode = 2.13...found
 Module::Versions::Report = 1.05...found
 MIME::Entity = 5.425...found
 DBI = 1.37...found
 Locale::Maketext::Lexicon = 0.32...found
 Devel::StackTrace = 1.19...found
 Digest::base...found
 Time::ParseDate...found
 File::Temp = 0.18...found
 Locale::Maketext = 1.06...found
 Tree::Simple = 1.04...found
 Text::Template...found
 Scalar::Util...found
 HTML::Scrubber = 0.08...found
 File::Spec = 0.8...found
 Calendar::Simple...found
 DBIx::SearchBuilder = 1.54...MISSING
 Mail::Mailer = 1.57...found
 File::ShareDir...found
 Regexp::Common...found
 Digest::MD5 = 2.27...found
 HTML::Entities...found
 Cache::Simple::TimedExpiry...found
 File::Glob...found
 Locale::Maketext::Fuzzy...found
 Time::HiRes...found
 Text::Wrapper...found
 Log::Dispatch = 2.0...found
 UNIVERSAL::require...found
 Email::Address...found

 Install module DBIx::SearchBuilder
 Going to read /root/.cpan/Metadata
   Database was generated on Tue, 30 Dec 2008 16:26:51 GMT
 Running install for module 'DBIx::SearchBuilder'
 'YAML' not installed, falling back to Data::Dumper and Storable to read
 prefs '/root/.cpan/prefs'
 Running make for J/JE/JESSE/DBIx-SearchBuilder-1.54.tar.gz
 CPAN: Digest::SHA loaded ok (v5.45)
 CPAN: Compress::Zlib loaded ok (v2.008)
 Checksum
 for /root/.cpan/sources/authors/id/J/JE/JESSE/DBIx-SearchBuilder-1.54.tar.gz
 ok
 DBIx-SearchBuilder-1.54/
 DBIx-SearchBuilder-1.54/Changes
 DBIx-SearchBuilder-1.54/ex/
 DBIx-SearchBuilder-1.54/ex/create_tables.pl
 DBIx-SearchBuilder-1.54/ex/Example/
 DBIx-SearchBuilder-1.54/ex/Example/Model/
 DBIx-SearchBuilder-1.54/ex/Example/Model/Address.pm
 DBIx-SearchBuilder-1.54/ex/Example/Model/Employee.pm
 DBIx-SearchBuilder-1.54/inc/
 DBIx-SearchBuilder-1.54/inc/Module/
 DBIx-SearchBuilder-1.54/inc/Module/AutoInstall.pm
 DBIx-SearchBuilder-1.54/inc/Module/Install/
 DBIx-SearchBuilder-1.54/inc/Module/Install/AutoInstall.pm
 DBIx-SearchBuilder-1.54/inc/Module/Install/Base.pm
 DBIx-SearchBuilder-1.54/inc/Module/Install/Include.pm
 DBIx-SearchBuilder-1.54/inc/Module/Install/Makefile.pm
 DBIx-SearchBuilder-1.54/inc/Module/Install/Metadata.pm
 DBIx-SearchBuilder-1.54/inc/Module/Install.pm
 

Re: [rt-users] RTFM make test fails: requires 3.8 to run tests

2008-12-31 Thread Kevin Falcone

On Dec 10, 2008, at 6:20 PM, Paul Hirose wrote:

 Installed RT381, appears to work fine.

 Now installing RTFM240.  I did perl Makefile.PL and it was ok.  I  
 then wanted to do the test (before the install) and did:
   RT_DBA_USER=user RT_DBA_PASSWORD=password PERL5LIB=/opt/rt3/lib  
 make test
 with my username/password for the MySQL database system.

 Upon doing so, I get
 PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e  
 test_harness(0, 'inc', 'blib/lib', 'blib/arch') t/00smoke.t t/ 
 04interface.t t/05cfsearch.t t/2basic_api.t t/3upload-customfields.t  
 t/Article_Overlay.pm.t t/ArticleCollection_Overlay.pm.t t/ 
 Class_Overlay.pm.t t/URI_a.t t/URI_fsck_com_rtfm.t
 t/00smoke.skipped: requires 3.8 to run  
 tests.  You may need to set PERL5LIB=/path/to/rt/lib
   ...
 t/URI_fsck_com_rtfm...skipped: requires 3.8 to run  
 tests.  You may need to set PERL5LIB=/path/to/rt/lib
 Files=10, Tests=0, 22 wallclock secs ( 0.14 usr  0.15 sys + 18.32  
 cusr  2.83 csys = 21.44 CPU)
 Result: NOTESTS

Can the user who is running 'make test' read the files in /opt/rt3/lib  
and /opt/rt3/etc (specifically the
RT_Config.pm and RT_SiteConfig.pm files).  It won't run if it can't  
load RT::Test

-kevin




 I tried looking in t/lib/RT/FM/Test.pm which led me to  /opt/rt3/lib/ 
 RT/Test.pm but I confess, I'm not sure what I'm looking at.  At  
 least nothing obvious jumped out at me :)

 I just like to always make sure a typical make test works. :)

 PH

 --
 Paul Hirose  : pthir...@ucdavis.edu : Sysadm Motto: rm -fr / 
 MyLife
 1034 Academic Surge  : Programmer/Analyst   : Backup Motto : rm -fr /
 One Shields Avenue   : Voice (530) 752-7181 : Robot, n.: Univ. Admin
 Davis, CA 95616-8770 : Fax   (530) 752-4465 : rec.pets.cat.anecdotes
 ___
 http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

 Community help: http://wiki.bestpractical.com
 Commercial support: sa...@bestpractical.com


 Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
 Buy a copy at http://rtbook.bestpractical.com


___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] fixdeps errors: DBD::SQLite and DBIx::SearchBuilder

2008-12-31 Thread Joseph Spenner
Ruslan:
  Thanks for the tip.  Forcing SQLite succeeded, and 'make fixdeps' took care 
of the rest.  I think I'm almost there.
  My next/current problem is with FastCGI.  My rt-test-dependencies indicate it 
should work.  However, when I add these lines to my httpd.conf as described in 
the doc at http://wiki.bestpractical.com/view/FastCGIConfiguration:

# Tell FastCGI to put its temporary files somewhere sane.
FastCgiIpcDir /tmp

# Number of processes is tunable, but you need at least 3 or 4
FastCgiServer /opt/rt3/bin/mason_handler.fcgi -idle-timeout 120 -processes 4

I get errors when trying to start apache:

Invalid command 'FastCgiIpcDir', perhaps misspelled or defined by a module not 
included in the server configuration

I'm using the apache which came standard on my slackware 12.2 distribution.

r...@tuxtrack:/space/rt-packages# httpd -V
Server version: Apache/2.2.10 (Unix)
Server built:   Oct 22 2008 17:54:27
Server's Module Magic Number: 20051115:18
Server loaded:  APR 1.3.3, APR-Util 1.3.4
Compiled using: APR 1.3.3, APR-Util 1.3.4
Architecture:   32-bit
Server MPM: Prefork
  threaded: no
    forked: yes (variable process count)
Server compiled with
 -D APACHE_MPM_DIR=server/mpm/prefork
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=128
 -D HTTPD_ROOT=/usr
 -D SUEXEC_BIN=/usr/bin/suexec
 -D DEFAULT_PIDLOG=/var/run/httpd/httpd.pid
 -D DEFAULT_SCOREBOARD=logs/apache_runtime_status
 -D DEFAULT_LOCKFILE=/var/run/httpd/accept.lock
 -D DEFAULT_ERRORLOG=logs/error_log
 -D AP_TYPES_CONFIG_FILE=/etc/httpd/mime.types
 -D SERVER_CONFIG_FILE=/etc/httpd/httpd.conf
r...@tuxtrack:/space/rt-packages#  



From what I can tell, the available modules in /usr/lib/httpd/modules/ do not 
include a mod_fastcgi.so (name?).  I only see mod_cgi.so.  I tried downloading 
and compiling the module from http://www.fastcgi.com/drupal/ which created a 
libfcgi.so.  I copied that into /usr/lib/httpd/modules/ and made an entry in 
httpd.conf:

LoadModule libfcgi lib/httpd/modules/libfcgi.so

But it didn't like that at all:

httpd: Syntax error on line 54 of /etc/httpd/httpd.conf: Can't locate API 
module structure `libfcgi' in file /usr/lib/httpd/modules/libfcgi.so: 
/usr/lib/httpd/modules/libfcgi.so: undefined symbol: libfcgi

Perhaps I'm heading down the wrong path.
Any help would be great.

Thanks!


--- On Wed, 12/31/08, Ruslan Zakirov ruslan.zaki...@gmail.com wrote:

It's ok to force install DBD::SQLite, I saw this errors too. This
module is required to test DBIx::SearchBuilder functionality only.





  ___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com

Re: [rt-users] fixdeps errors: DBD::SQLite and DBIx::SearchBuilder

2008-12-31 Thread Joseph Spenner

--- On Wed, 12/31/08, Joseph Spenner joseph85...@yahoo.com wrote:
From: Joseph Spenner joseph85...@yahoo.com
Subject: Re: [rt-users] fixdeps errors: DBD::SQLite and DBIx::SearchBuilder
To: rt-users@lists.bestpractical.com
Date: Wednesday, December 31, 2008, 9:55 AM

Ruslan:
  Thanks for the tip.  Forcing SQLite succeeded, and 'make fixdeps' took care 
of the rest.  I think I'm almost there.
  My next/current problem is with FastCGI.  My rt-test-dependencies indicate it 
should work.  However, when I add these lines to my httpd.conf as described in 
the doc at http://wiki.bestpractical.com/view/FastCGIConfiguration:

# Tell FastCGI to put its temporary files somewhere sane.
FastCgiIpcDir /tmp

# Number of processes is tunable, but you need at least 3 or 4
FastCgiServer /opt/rt3/bin/mason_handler.fcgi -idle-timeout 120 -processes 4

I get errors when trying to start apache:

Invalid command 'FastCgiIpcDir', perhaps misspelled or defined by a module not 
included in the server configuration

I'm using the
 apache which came standard on my slackware 12.2 distribution.

I believe I have figured it out.  I did the following:

downloaded http://www.fastcgi.com/dist/mod_fastcgi-2.4.6.tar.gz

compiled it:

r...@tuxtrack:/space/rt-packages/mod_fastcgi-2.4.6# apxs -o mod_fastcgi.so -c 
*.c

copied it to a place where apache will find it:

r...@tuxtrack:/space/rt-packages/mod_fastcgi-2.4.6# cp .libs/mod_fastcgi.so 
/usr/lib/httpd/modules/mod_fastcgi.so

Updated httpd.conf with the VirtualHost entry and FastCGI entries as described 
in the documentation, as well as added:

LoadModule fastcgi_module lib/httpd/modules/mod_fastcgi.so

Also had to add (to get rid of Permission Denied error):

Directory /opt/rt3
    Order allow,deny
    Allow from all
/Directory

Looks good so far.

Thanks for listening!





  ___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com

Re: [rt-users] RT2-to-RT3 migration lost ticket data and status change issues

2008-12-31 Thread Kevin Falcone

On Dec 18, 2008, at 9:01 PM, Brian Friday wrote:

 Thanks Drew,

 Your tips led me to the library issues. RT2 can not be exported
 without the same perl modules used for RT2. Once I installed the
 correct libraries everything exported correctly.

 My import however still has one snag, or rather 51,000 or so snags. I
 have 51,000 tickets with the status of new 99% of which did not
 originally have that status when they were exported and did not have
 that status in the dump file.

You didn't say what version of RT-Extension-RT2toRT3 you're
using, but I've done numerous rt2 to rt3 conversions using
the cpan versions without seeing this

If Status isn't making it into the dumpfiles generated by rt-2.0-to- 
dumpfile
then they will default to 'new' when being created by in rt3

-kevin

 Anyone have any ideas on this issue that still remains?

 - Brian

 On Dec 15, 2008, at 7:19 AM, Drew Barnes wrote:

 When I upgraded several years ago, I had to run rt2-to-dumpfile
 BEFORE I installed RT3 at all.  Something about the version of
 SearchBuilder (I think) that RT# used broke the data export of RT2.
 At one point I was very good with the procedure for that upgrade,
 but my memory seems to have been lost to time and projects past.

 I hope this may help you out some.  Searching for part of my email
 on http://www.gossamer-threads.com/lists/rt/ may bring some of those
 posts back up for you.



 Brian Friday wrote:
 Hello all,

 I am using the RT2-to-RT3 migration tool (latest) to migrate a RT2
 instance (Mysql 3.23, DB is 1+ GB in size) from 2.0.14 to RT 3.6.7
 (Mysql 5). I have copied the original RT2 install, and the new RT3
 from their respective machines to a go between system. I've fixed
 the  paths and configurations so that both installs still can
 connect to  their respective databases.

 This go between machine is running perl 5.8.8 with all the modules
 and  dependancies for a mysql based RT 3.6.7 instance. RT2 is
 running on a  Mac OS X panther server with Perl 5 (I think 004) and
 RT3 is running  on a Leopard Server also running Perl 5.8.8.

 I had to update the RT2-to-dumpfile script in the migration package
 to  change the status as well as the priority of the tickets it
 exports.  In addition I had to add to RT3 the additional status
 files used by  the client.  After that I was able to successfully
 run both the rt-2.0- to-dumpfile script and the dumpfile to rt-3.0
 script.  All the basic  data appears to have come across intact
 including queues, acl's, users  and ticket metadata.

 First Problem:
 ---
 While the ticket metadata has been exported, the actual
 transactions,  as well as ticket contents, emails, attachments etc
 have not been  exported. I have verified that they exist in the
 original database.

 Second Problem:
 
 Within RT3 I have edited the etc/RT_SiteConfig.pm to include the
 additional status lines here:
 @ActiveStatus = qw(new open waiting monitoring ongoing stalled
 verify  EC) unless @ActiveStatus;
 @InactiveStatus = qw(resolved rejected dead deferred deleted)
 unless  @InactiveStatus;

 From the default below:
 @ActiveStatus = qw(new open stalled) unless @ActiveStatus;
 @InactiveStatus = qw(resolved rejected deleted) unless
 @InactiveStatus;

 The catch I have discovered is that when the old tickets were
 imported  about 90% of the tickets which were resolved now have the
 status of  new (specifically new (unchanged) ). These tickets
 instead should be  listed
 as resolved.

 

 Has anyone seen or experienced either of these behaviors before
 and  could provide any advice?

 Any help would be appreciated,

 - Brian
 ___
 http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

 Community help: http://wiki.bestpractical.com
 Commercial support: sa...@bestpractical.com


 Discover RT's hidden secrets with RT Essentials from O'Reilly
 Media. Buy a copy at http://rtbook.bestpractical.com


 -- 
 Drew Barnes
 Applications Analyst
 Network Resources Department
 Raymond Walters College
 University of Cincinnati


 ___
 http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

 Community help: http://wiki.bestpractical.com
 Commercial support: sa...@bestpractical.com


 Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
 Buy a copy at http://rtbook.bestpractical.com


___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] RT2-to-RT3 migration lost ticket data and status change issues

2008-12-31 Thread Brian Friday

On Dec 31, 2008, at 10:45 AM, Kevin Falcone wrote:


 On Dec 18, 2008, at 9:01 PM, Brian Friday wrote:

 Thanks Drew,

 Your tips led me to the library issues. RT2 can not be exported
 without the same perl modules used for RT2. Once I installed the
 correct libraries everything exported correctly.

 My import however still has one snag, or rather 51,000 or so snags. I
 have 51,000 tickets with the status of new 99% of which did not
 originally have that status when they were exported and did not have
 that status in the dump file.

 You didn't say what version of RT-Extension-RT2toRT3 you're
 using, but I've done numerous rt2 to rt3 conversions using
 the cpan versions without seeing this

 If Status isn't making it into the dumpfiles generated by rt-2.0-to-
 dumpfile
 then they will default to 'new' when being created by in rt3

 -kevin

Actually I did, latest, though I guess I could be more clear and said  
SVN version as well.
The status exists in the dumped tickets but that status is not  
maintained in the dumpfile to rt3
push rather all resolved tickets are pushed back to new a status we  
did not have in RT2.

- Brian



___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] RT2-to-RT3 migration lost ticket data and status change issues

2008-12-31 Thread Kevin Falcone

On Dec 31, 2008, at 4:11 PM, Brian Friday wrote:


 On Dec 31, 2008, at 10:45 AM, Kevin Falcone wrote:


 On Dec 18, 2008, at 9:01 PM, Brian Friday wrote:

 Thanks Drew,

 Your tips led me to the library issues. RT2 can not be exported
 without the same perl modules used for RT2. Once I installed the
 correct libraries everything exported correctly.

 My import however still has one snag, or rather 51,000 or so  
 snags. I
 have 51,000 tickets with the status of new 99% of which did not
 originally have that status when they were exported and did not have
 that status in the dump file.

 You didn't say what version of RT-Extension-RT2toRT3 you're
 using, but I've done numerous rt2 to rt3 conversions using
 the cpan versions without seeing this

 If Status isn't making it into the dumpfiles generated by rt-2.0-to-
 dumpfile
 then they will default to 'new' when being created by in rt3

 -kevin

 Actually I did, latest, though I guess I could be more clear and  
 said SVN version as well.

I don't trust 'latest' as a version number since people occasionally  
download the
incredibly old version on downloads.bestpractical.com rather than the  
CPAN
version, and I fixed quite a bit for the CPAN version.

 The status exists in the dumped tickets but that status is not  
 maintained in the dumpfile to rt3
 push rather all resolved tickets are pushed back to new a status we  
 did not have in RT2.

The only change made to Status during the dumpfile - rt3 script is  
that if the status
is dead it is changed to deleted.

Have you verified the output by using Storable to reinflate one of the  
stored ticket
files?  If so, please send along the content (feel free to strip the  
subject and anonymise
the other data) seeing the hash that ends up in the file would help me  
make
suggestions, since the Status field is a rather straightforward copy  
across the
versions.

-kevin


___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] RT2-to-RT3 migration lost ticket data and status change issues

2008-12-31 Thread Brian Friday

On Dec 31, 2008, at 1:31 PM, Kevin Falcone wrote:


 Actually I did, latest, though I guess I could be more clear and
 said SVN version as well.

 I don't trust 'latest' as a version number since people occasionally
 download the
 incredibly old version on downloads.bestpractical.com rather than the
 CPAN
 version, and I fixed quite a bit for the CPAN version.

As I found when I went searching for this originally.

 The status exists in the dumped tickets but that status is not
 maintained in the dumpfile to rt3
 push rather all resolved tickets are pushed back to new a status we
 did not have in RT2.

 The only change made to Status during the dumpfile - rt3 script is
 that if the status
 is dead it is changed to deleted.

Status is definitely not dead

 Have you verified the output by using Storable to reinflate one of the
 stored ticket files?

Without sample code I'd hazard a guess you've lost me regarding what  
or how you wish me to use storable.

 If so, please send along the content (feel free to strip the
 subject and anonymise
 the other data) seeing the hash that ends up in the file would help me
 make
 suggestions, since the Status field is a rather straightforward copy
 across the
 versions.

I had thought so as well but in RT2 we are using status variables  
which do not exist in RT3 and had to be
added. The comment section of that portion of the SiteConfig indicates  
the existing status's can not be removed.

I've sent a off list message containing a sample ticket santized but  
which shows up as resolved in our current database, resolved in the  
ticket dumpfile but new in the RT3 instance. I have also attached  
screenshots of the ticket in the new RT instance showing that the last  
transaction was to resolve the ticket but yet it was imported as new.

- Brian

___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] RT2-to-RT3 migration lost ticket data and status change issues

2008-12-31 Thread Kevin Falcone

On Dec 31, 2008, at 5:14 PM, Brian Friday wrote:

 The status exists in the dumped tickets but that status is not
 maintained in the dumpfile to rt3
 push rather all resolved tickets are pushed back to new a status we
 did not have in RT2.

 The only change made to Status during the dumpfile - rt3 script is
 that if the status
 is dead it is changed to deleted.

 Status is definitely not dead

I assume select Status from Tickets where id = t-58818; returns
resolved?

 Have you verified the output by using Storable to reinflate one of  
 the
 stored ticket files?

 Without sample code I'd hazard a guess you've lost me regarding what
 or how you wish me to use storable.

Something like
perl -MStorable -MData::Dumper -le 'print Dumper retrieve(t-11)'
should retrieve the contents.

 If so, please send along the content (feel free to strip the
 subject and anonymise
 the other data) seeing the hash that ends up in the file would help  
 me
 make
 suggestions, since the Status field is a rather straightforward copy
 across the
 versions.

 I had thought so as well but in RT2 we are using status variables
 which do not exist in RT3 and had to be
 added. The comment section of that portion of the SiteConfig indicates
 the existing status's can not be removed.

You can't remove them, there are hooks if you want to rename the rt2
statuses to different ones in rt3 during the import.

 I've sent a off list message containing a sample ticket santized but
 which shows up as resolved in our current database, resolved in the
 ticket dumpfile but new in the RT3 instance. I have also attached
 screenshots of the ticket in the new RT instance showing that the last
 transaction was to resolve the ticket but yet it was imported as new.

I teased apart the ticket file and it doesn't actually have a Status  
field,
which explains why it is showing up as new in rt3.

You should verify that FIELD_MAPPINGS in rt-2.0-to-dumpfile
for RT::Ticket contains Status and that your rt2 DB has a
Status column that matches up.  The newer versions of
rt-2.0-to-dumpfile use a hardcoded rt2 schema to avoid
needing a really old version of SearchBuilder to function.

-kevin
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] RT2-to-RT3 migration lost ticket data and status change issues

2008-12-31 Thread Kevin Falcone

On Dec 31, 2008, at 6:28 PM, Brian Friday wrote:


 On Dec 31, 2008, at 2:58 PM, Kevin Falcone wrote:

 I assume select Status from Tickets where id = t-58818; returns
 resolved?

 Correct

Ok, so it isn't a mapping issue from old custom status to new custom
status which is what I was worried about as first.


 I teased apart the ticket file and it doesn't actually have a Status
 field,
 which explains why it is showing up as new in rt3.

 Hmm.. weird I am showing resolved as the status as I look at the  
 ticket contents but then I am not familiar enough with how the  
 ticket is constructed in the dumpfile. Status is in the  
 FIELD_MAPPINGS of the rt-2.0-to-dumpfile and everything seems fine.

You're probably seeing the transaction setting it from new to resolved

You should search for nstore in rt-2.0-to-dumpfile, you'll find a call  
to it around line 447
You want to add something like
use Data::Dumper; print STDERR Dumper($tick_ds);
above that so you can get a log of what is actually
going to disk.

After that you'll need to work backwords through the code
to see where the Status isn't being found/set and try
to trace the code that builds up $tick_ds

-kevin


 If you have indeed fixed the old version of search builder issue I  
 can tell you that the fix does not work. I was only able to export  
 the ticket metadata with the current search builder and was unable  
 to export any of the transactions or attachment data. To get what I  
 thought was the full data I had to use DBIx::SearchBuilder 0.99 only  
 then did the data extract out (minus the status it seems).

I used a 1.3x or a 1.4x version of SearchBuilder, haven't tried with  
one of the 1.5xs
I usually end up having the rt2 install and db copied to the new host  
and working from
that for the export, although it varies from situation to situation.   
I don't have access to
the hosts where the last export was done to check DBIx::SearchBuilder  
versions.

-kevin
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com