I’m pleased to announce the first release candidate of RT 3.4.0. This
release contains all functionality we expect to be present in RT 3.4.0
and has been tested by a number of beta testers and is now ready for
wider exposure in advance of its official release (which could be as
early as next week if feedback is positive.)
Please download RT 3.4.0rc1 from:
http://download.bestpractical.com/pub/rt/devel/
SHA1 sums:
0d71fe1d1441cb319bc5989b525e454a8018876a rt-3.4.0rc1.tar.gz
37500c9ca39d2c7493c592ae258d5751adc94c6d rt-3.4.0rc1.tar.gz.sig
We appreciate any and all feedback. Please report bugs to
rt-devel@lists.bestpractical.com if you’re already subscribed there or
to rt-bugs@fsck.com if not.
RT 3.4 represents significant improvement and stabilization of RT
relative to 3.2.0 and boasts a host of new features. The largest
user-visible change is a completely rewritten custom fields system.
Custom fields can now be created for users, groups and ticket
transactions. Additionally, we’ve now got “full text”, “file upload”
and “image upload” custom fields. On top of that, you can now apply
custom fields to a set of queues (rather than just one-or-all, like RT
3.2). On the inside, we’ve done a significant amount of work cleaning
up and restructuring RT’s codebase. We’ve added a whole slew of new
tests and overhauled the test infrastructure. We’ve added a new
“developer mode” to RT, which allows you to modify RT’s libraries on the
fly and have the webserver pick them up instantly.
Oh. And we made it faster.
Jesse
RT-Announce mailing list
RT-Announce@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-announce
With DevelMode on the first web request works fine, then all
other requests generate undefined subroutine errors in the
web interface and this in the log:
Huh. Do you have local customizations? And is this behaviour a change
from 3.3.x?
This happens even if I move local out of the way. Before
running “make upgrade” in cd’d into /opt/rt3 and ran:
rm -rf bin/ lib/ sbin/ share/ var/On Mon, Dec 20, 2004 at 03:12:57PM -0500, Jesse Vincent wrote:
On Mon, Dec 20, 2004 at 02:27:57PM -0500, Todd Chapman wrote:
With DevelMode on the first web request works fine, then all
other requests generate undefined subroutine errors in the
web interface and this in the log:
Huh. Do you have local customizations? And is this behaviour a change
from 3.3.x?
This happens even if I move local out of the way. Before
running “make upgrade” in cd’d into /opt/rt3 and ran:
rm -rf bin/ lib/ sbin/ share/ var/
Can you try it on a vanilla RT 3.4.0RC instance? Also, were you coming
from RT 3.2 or 3.3? And did the functionality work on 3.3? I don’t
actually expect the magic reloading to be bulletproof, but I wouldn’d
expect it to fail that easily
I did: “make dropdb: rm -rf /opt/rt3; make install; make initialize-database”
and I still get the same problem after turning on DevelMode.
On a probably unrelated note, “make test” fails with:
ok 96 - Requiring ‘fsck_com_rt.pm’
ok 97 - Requiring ‘base.pm’
[Mon Dec 20 20:27:53 2004] [crit]: Can’t locate RT/Action/Generic.pm in @INC (@INC contains: lib /usr/local/lib/perl5/5.8.3/i686-linux /usr/local/lib/perl5/5.8.3 /usr/local/lib/perl5/site_perl/5.8.3/i686-linux /usr/local/lib/perl5/site_perl/5.8.3 /usr/local/lib/perl5/site_perl .) at CreateTickets.pm line 47.
(lib/RT.pm:285)
1…97On Mon, Dec 20, 2004 at 03:23:13PM -0500, Jesse Vincent wrote:
On Mon, Dec 20, 2004 at 02:32:17PM -0500, Todd Chapman wrote:
This happens even if I move local out of the way. Before
running “make upgrade” in cd’d into /opt/rt3 and ran:
rm -rf bin/ lib/ sbin/ share/ var/
Can you try it on a vanilla RT 3.4.0RC instance? Also, were you coming
from RT 3.2 or 3.3? And did the functionality work on 3.3? I don’t
actually expect the magic reloading to be bulletproof, but I wouldn’d
expect it to fail that easily
I did: “make dropdb: rm -rf /opt/rt3; make install; make initialize-database”
and I still get the same problem after turning on DevelMode.
Ok. I’d love it if you could dig into it a bit more.
On a probably unrelated note, “make test” fails with:
Run ‘make regression’ not ‘make test’
I’m having a hard time figuring out how to do that…
For starters, how are you running the webserver? standalone_httpd or
something else? If not, try standalone_httpd
Do you want the output of “make regression”?
That depends. Are there failing tests?
There is no problem when running with standalone_httpd.
Some test fail. See attached outout file.
-ToddOn Mon, Dec 20, 2004 at 05:21:45PM -0500, Jesse Vincent wrote:
On Mon, Dec 20, 2004 at 04:04:51PM -0500, Todd Chapman wrote:
I’m having a hard time figuring out how to do that…
For starters, how are you running the webserver? standalone_httpd or
something else? If not, try standalone_httpd
Do you want the output of “make regression”?
That depends. Are there failing tests?
reg.out (13.9 KB)
There is no problem when running with standalone_httpd.
Ok. so it looks like something in how the other handlers deal with
devel mode. Which other handler is it failing on?
Some test fail. See attached outout file.
That sure looks like “you have another webserver running”
There is no problem when running with standalone_httpd.
Ok. so it looks like something in how the other handlers deal with
devel mode. Which other handler is it failing on?
Not sure what you are asking. Running under mod_per 1.27
Some test fail. See attached outout file.
That sure looks like “you have another webserver running”
I’m pretty sure I wasn’t but I ran it again to be safe.
Results attached.
reg2.out (13.9 KB)
There is no problem when running with standalone_httpd.
Ok. so it looks like something in how the other handlers deal with
devel mode. Which other handler is it failing on?
Not sure what you are asking. Running under mod_per 1.27
That was what I was asking. “mod_perl or fastcgi?”
That sure looks like “you have another webserver running”
I’m pretty sure I wasn’t but I ran it again to be safe.
Results attached.
What happens if you visit http://localhost? It sure looks like it’s not
giving you RT. Perhaps you’ve misconfigured your webserver?
Jesse
There is no problem when running with standalone_httpd.
Ok. so it looks like something in how the other handlers deal with
devel mode. Which other handler is it failing on?
Not sure what you are asking. Running under mod_per 1.27
That was what I was asking. “mod_perl or fastcgi?”
My previous version of RT was 3.3.11, so I did an rm -rf /opt/rt3
and did a make install of 3.3.11. The problem went away. Then
I tried each version of RT and it turns out that the problem
started happening in 3.3.14.
All my undefined subroutine errors seem to be on RT::Tickets objects.
I see that Tickets_Overlay.pm change quite a bit between those
versions.
That sure looks like “you have another webserver running”
I’m pretty sure I wasn’t but I ran it again to be safe.
Results attached.
What happens if you visit http://localhost? It sure looks like it’s not
giving you RT. Perhaps you’ve misconfigured your webserver?
Correct. But how can I have misconfigred my web server? Is there
some setup that you have to perform before “make regression”?
Tickets_Overlay.pm seems to be missing a package statement
starting at 3.3.14. Why this only causes a problem in DevelMode
I don’t know, but 3.4 rc1 is working for me after adding that
statement.
-Todd
Results attached.
What happens if you visit http://localhost? It sure looks like it’s not
giving you RT. Perhaps you’ve misconfigured your webserver?
Correct. But how can I have misconfigred my web server? Is there
some setup that you have to perform before “make regression”?
It looks like the issue is something about DirectoryIndexes, which
need special treatment with some modperl_2 variants.
Tickets_Overlay.pm seems to be missing a package statement
starting at 3.3.14. Why this only causes a problem in DevelMode
I don’t know, but 3.4 rc1 is working for me after adding that
statement.
Indeed. That could do it. Good sleuthing. I’ll fix that right up.
Tickets_Overlay.pm seems to be missing a package statement
starting at 3.3.14. Why this only causes a problem in DevelMode
I don’t know, but 3.4 rc1 is working for me after adding that
statement.
So. it only applies in Devel mode because of the magic in
Module::Refresh. But your patch has been applied.
What is strange is that I was the only one to hit it…
I would think that RT developers especially would have
seen it right away. I guess it doesn’t apply to
FastCGI, which is something I need to consider setting
up to make my development environment more flexible.
How do you develop? Do you checkout RT right into
the web tree, run configure and go? Or, do you make
upgrade each time you want to test your changes?On Mon, Dec 20, 2004 at 09:47:05PM -0500, Jesse Vincent wrote:
On Mon, Dec 20, 2004 at 07:02:35PM -0500, Todd Chapman wrote:
Tickets_Overlay.pm seems to be missing a package statement
starting at 3.3.14. Why this only causes a problem in DevelMode
I don’t know, but 3.4 rc1 is working for me after adding that
statement.
So. it only applies in Devel mode because of the magic in
Module::Refresh. But your patch has been applied.
-Todd
–
How do you develop? Do you checkout RT right into
the web tree, run configure and go? Or, do you make
upgrade each time you want to test your changes?
For day to day development, I generally:
./configure --with-my-user-group --enable-layout=inplace
make initialize-database
./bin/standalone_httpd
But this is mod_perl 1.27.On Mon, Dec 20, 2004 at 09:09:44PM -0500, Jesse Vincent wrote:
Results attached.
What happens if you visit http://localhost? It sure looks like it’s not
giving you RT. Perhaps you’ve misconfigured your webserver?
Correct. But how can I have misconfigred my web server? Is there
some setup that you have to perform before “make regression”?
It looks like the issue is something about DirectoryIndexes, which
need special treatment with some modperl_2 variants.
Jesse
–
But this is mod_perl 1.27.
And if you go to / on the webserver, does it give you a directory
listing or an RT page? Do note that the regression suite is somewhat
tuned for development environments like ours and may make assumptions
about RT listening, even without a vhost specified. Patches would be
appreciated.
Jesse