RT 3.0.1 is primarily a bug-fix release. A number of issues have been
corrected, primarily several UTF-8 related issues, as well as an issue
that could cause corruption of binary attachments.
This release is now available at:
http://fsck.com/pub/rt/release/rt-3-0-1.tar.gz
Changelog annotations are below. For more detail, consult aegis at
http://fsck.com/aegis/aegis.cgi?file@proj_menu+project@rt.3.0
33 20 A tiny bit of extra data passing for some callbacks
35 21 New czech translation
37 22 Updated dependencies
36 23 Updated Spanish translation
38 24 Updates for RT RPC interface from AMS
39 25 Many users should be able to have a blank address; new test suite to ensure this
50 26 Integrating rafael's failing UTF-8 test suite and proposed fix from autrijus
51 27 Changing address used in examples to not send mail to author
53 29 Added preliminary left to right hebrew translation
55 30 #2365 Removing outdated Mason setup parameter
56 31 Testing fixes for mail authentication/authorization
58 33 Better binary attachment handling fix from autrijus
59 34 Bumping to RT 3.0.1pre2
60 35 SMTP and I18N fixes from autrijus tang. Updated chinese translations
61 36 New speedycgi support from vivek khera
62 37 Bumping to version 3.0.1
Request Tracker — Best Practical Solutions – Trouble Ticketing. Free.
rt-announce mailing list
rt-announce@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-announce
Ok. It looks lik a couple issues crept into the 3.0.1 release.
My flight to the UK is about to board, but I’ll see about getting a
point release out once I find network in the UK on wednesday.
Jesse VincentOn Wed, Apr 16, 2003 at 12:00:10AM +0200, Jeroen Ruigrok/asmodai wrote:
-On [20030415 18:34], Jesse Vincent (jesse@bestpractical.com) wrote:
RT 3.0.1 is primarily a bug-fix release. A number of issues have been
corrected, primarily several UTF-8 related issues, as well as an issue
that could cause corruption of binary attachments.
Using up to date perl modules, except SearchBuilder, since I need to
benchmark the old one first (0.80 though), and a compliant Storable
(current one won’t build), I get this under perl 5.8.0:
[Tue Apr 15 23:57:05 2003] [warn] FastCGI: server
“/usr/local/rt/bin/mason_handler.fcgi” restarted (pid 57896)
Insecure dependency in require while running setgid at
/usr/local/rt3/lib/RT/I18N.pm line 82.
Compilation failed in require at /usr/local/rt/bin/mason_handler.fcgi
line 28.
[Tue Apr 15 23:57:08 2003] [warn] FastCGI: server
“/usr/local/rt/bin/mason_handler.fcgi” (pid 57896) terminated by calling
exit with status ‘255’
78 sub Init {
79 # Load language-specific functions
80 foreach my $language ( glob(substr(__FILE__, 0, -3) . "/*.pm")) {
81 if ($language =~ /\b([-\w.\/\\]+)$/) {
82 require $language;
83 }
Hope this helps,
–
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / a capoeirista
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B
http://www.tendra.org/ | http://www.in-nomine.org/~asmodai/diary/
Only the wisest and the stupidest of men never change…
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
rt-announce mailing list
rt-announce@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-announce
Hi Jesse,— Jesse Vincent jesse@bestpractical.com wrote:
RT 3.0.1 is primarily a bug-fix release. A number of issues have been
corrected, primarily several UTF-8 related issues, as well as an issue
that could cause corruption of binary attachments.
After upgrading from 3.0.1pre2:
the incoming e-mail with
charset=“iso-8859-1” and a single non-ASCII character in it:
regardless of the ticket number present or not in the subject line,
the new ticket is created with empty Requestor, body and subject.
I’ll try and dig into the problem while you’re on the road.
Cheers,
Stan
the incoming e-mail with
charset=“iso-8859-1” and a single non-ASCII character in it:
regardless of the ticket number present or not in the subject line,
the new ticket is created with empty Requestor, body and subject.
The whole mess is around the line 26 in html/autohandler.
Before Change 60 it was:
Encode::utf8_on($ARGS{$}) foreach (keys %ARGS);
After that it is:
$ARGS{$} = Encode::decode_utf8($ARGS{$}) foreach (keys %ARGS);
After the change, the iso-8859-1 e-mail messages are screwed as described above.
UTF-8 e-mail messages are handled fine.
With this line reverted to the old value, not everything is fine:
When the iso-8859-1 e-mail comes,
each accent or umlaut character is stored in the database as 4 bytes,
and is diasplayed in the web interface as two meaningless Unicode symbols.
But the notification e-mail sent to AdminCC contains correctly written UTF-8 text.
With this line commented out, not everything’s fine either:
The database contains correctly encoded UTF-8 text,
but the e-mail to AdminCC has utf-8 in the header, but the body in fact
is encoded as Latin1.
I hope this helps to track the problem down.
Regards,
Stan
On a related note, I see this happening to templates I try to save
under 3.0.1pre2 and 3.0.1 as well - the web interface reports ‘the new
value has been set’, but the template is not saved if umlauts are
entered. I checked the database, and the template is not stored. If I
change an existing template (without umlauts) to contain umlauts, the
old template is deleted (in the database).
This is with MySQL 3.23.54a and 4.0.10
Regards,
Harald Wagener
Harald Wagener * FCB/Wilkens * An der Alster 42 * 20099 Hamburg
the incoming e-mail with
charset=“iso-8859-1” and a single non-ASCII character in it:
regardless of the ticket number present or not in the subject line,
the new ticket is created with empty Requestor, body and subject.
The whole mess is around the line 26 in html/autohandler.
Hi all,
perhaps it would be easier to handle the international charsets, if
the charset conversion to UTF8 would happen within rt-mailgate, before
POSTing to the web interface.
Stan