Development Snapshot 3.0.2++

RT Developers
1

This isn’t a formal pre-release of RT 3.0.3, but a snapshot that fixes
some of the utf8 issues in RT 3.0.2 that have been biting
western-european users. If you don’t have utf8-issues that you need to
deal with ASAP, hold off a bit.

http://fsck.com/aegis/aegis.cgi/rt.3.0.C91.tar.gz?file@aetar+project@rt.3.0+change@91

Jesse

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

2

Hello Jesse,

the problem reappeared now, where we became productive with rt-3.0.3pre4.
My threading patch is not active here but Autoreplies are.

It is now quite often, that the Subject, if it is displayed in the
MessageStanza (from the Head attribute of the datbase) is garbled (Umlauts
wrong) an sometimes cut off.
if it is displayed in the title (from the Subject attribute in the
database), is correctly written with Umlauts.

Can you send me (personally) an example message that fails? I’m betting
its that your message header isn’t properly encoded by the MUA.

Could it be right what someone wrote that RT is not thread-safe?

I very much doubt it.

Dirk.

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

3

Hello,

In the 3.0.3 rc1 I haven’t seen any commandline interface like rtadmin
from RT2. Is in RT3 no commandline interface anymore?

Harald Zielstorff

4

At 2003-06-18 12:54:05 +0200, harald.zielstorff@oekostadt.de wrote:

Is in RT3 no commandline interface anymore?

There isn’t one at the moment, but I’m working on a replacement, and I
will release a beta later today. I’d be grateful if all the people who
have expressed interest in a command-line interface could try it out
and send me feedback.

(I’m just working on a few problems I found recently and writing more
documentation. I’ll post a tarball when I’m done.)

– ams

5

±le 23/05/03 16:24 -0400, Jesse Vincent écrivait :
| This isn’t a formal pre-release of RT 3.0.3, but a snapshot that fixes
| some of the utf8 issues in RT 3.0.2 that have been biting
| western-european users. If you don’t have utf8-issues that you need to
| deal with ASAP, hold off a bit.
|
|
| http://fsck.com/aegis/aegis.cgi/rt.3.0.C91.tar.gz?file@aetar+project@rt.3.0
| +change@91

Are you sure of this link ?
It only contains a Makefile and a Makefile.in
with only a very small diff against 3.0.2 (about the doc-install target).

Mathieu Arnold

6

±le 23/05/03 16:24 -0400, Jesse Vincent �crivait :
| This isn’t a formal pre-release of RT 3.0.3, but a snapshot that fixes
| some of the utf8 issues in RT 3.0.2 that have been biting
| western-european users. If you don’t have utf8-issues that you need to
| deal with ASAP, hold off a bit.
|
|
| http://fsck.com/aegis/aegis.cgi/rt.3.0.C91.tar.gz?file@aetar+project@rt.3.0
| +change@91

Are you sure of this link ?
It only contains a Makefile and a Makefile.in
with only a very small diff against 3.0.2 (about the doc-install target).

We recently upgraded to aegis 4.11. There appears to be a bug in that
download target. Give

http://fsck.com/aegis/aegis.cgi/rt.3.C0.tar.gz?file@aetar+project@rt.3+change@0

a shot

–
Mathieu Arnold

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

7

Hello Jesse,

–Am Freitag, 23. Mai 2003 16:24 Uhr -0400 schrieb Jesse Vincent
jesse@bestpractical.com:

This isn’t a formal pre-release of RT 3.0.3, but a snapshot that fixes
some of the utf8 issues in RT 3.0.2 that have been biting
western-european users. If you don’t have utf8-issues that you need to
deal with ASAP, hold off a bit.

I have still the same issues as decribed earlier and I can now fuzzily
reproduce them (see below)

From an earlier posting of mine:

So I start with my config:

RT: Version 3.0.2++
OS: Debian Linux Woody
Apache: 1.3.26 with SSL
Modperl: 1
DBS. mysql 3.23
Perl: 5.8.0
sbin/rt-testdepedencies happy with all installed perl-libs

my issues (please add your’s and your comments):

  1. from time to time incoming (non-utf8) Email will not be converted any
    more to utf8. It will though be marked as being converted, but in real
    contain ISO-character-encodings. I have to be vague here, because I
    cannot reproduce any trigger of this behaviour. But if this happens, it
    seems to stick for one apache process.

httpd.conf:

…
SSLEnable
AddDefaultCharset UTF-8

<Location /rt>
    order allow,deny
    allow from all
    PerlRequire /export/rt3/bin/webmux.pl
    SetHandler perl-script
    PerlHandler RT::Mason

…

RT_Siteconfig:

…
@EmailInputEncodings = qw(utf-8 iso-8859-1 us-ascii) unless
(@EmailInputEncodings);
Set($EmailOutputEncoding , ‘iso-8859-15’);
…

REPRODUCTION OF PROBLEM:

I attach a digest with mails I send one after another to the rt-system and
they get queued into one queue, each as a new ticket.

The first two tickets are displayed correctly.

After the third or fourth ticket arrived, the subject field in the web
display (ticket history is garbled and shows "Subject: test
�ö������� " (The concrete garbage depend on the browser you use
to display.

BUT: If you go to the “The Basics” panel, the subject shows ok. So does the
subject of the Auto-Reply the user receives per Email.

If I do further send the same message (I sometimes varied the number of
line breaks at the end of the message), I arrive to different states, in
arbitrary order:

A) Some of the messages arrive intact
B) Some of the messages have garbled subjects
C) Some of the messages have garbled bodies (This then also applies to the
autoreplies which cite the body by including Transaction->Content into the
message.

I even observed the case that there was an alternation (Ticket 2n =>
garbled Subject, Ticket 2n+1 => garbled body)

So you might be able to reprduce the thing at your site.

If not I will be glad to provide you with further infos you need (queue
config, scrips a.s.o)

Regards,
Dirk.

8

Hello,

here is the digest I forgot to attach. And I also forgot to say, that these
were the only messages after a restart of apache.

The messages in the digest are the copies which I - for testing purpose -
allways queue into a mailbox just befor it is queued via rt-mailgate into
the rt-system.

–Am Montag, 26. Mai 2003 18:41 Uhr +0200 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:

test _________ (1.69 KB)

test _________ (1.69 KB)

test _________ (1.69 KB)

test _________ (1.69 KB)

test _________ (1.69 KB)

test _________ (1.69 KB)

test _________ (1.69 KB)

9

Hello Jesse,

–Am Montag, 26. Mai 2003 18:41 Uhr +0200 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:

I have still the same issues as decribed earlier and I can now fuzzily
reproduce them (see below)

I have thoroughly reviewed my configuration and wonder if my problem is
related to my apache virtual server configs:

I have set up two virtual servers for RT3, one is serving the web via https
and the other listens on localhost:80 and only serves the exim forwards to
rt-mailgate. I set this up long time ago to avoid SSL-encoding on the
localhost connection.

From other postings regarding running RT2 and RT3 on the same site I
remember now there were problems mentioned if using mod_perl and I wonder
if I ran into the same problem here.

I will now set up perl and exim to forward into the same virtual server,
shut down the localhost server and try to reproduce the problem.

If this is the cause, what would you suggest?

A) serving localhost:80 with another true apache instance
B) having rt-mailgate connect via https to the same VirtualServer serving
the web

Dirk.

Dirk.

10

–Am Montag, 26. Mai 2003 22:06 Uhr +0200 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:

I will now set up perl and exim to forward into the same virtual server,
shut down the localhost server and try to reproduce the problem.

the problem persisted after this change (using the same virtual server for
mail-gateway and web display).

Dirk.

11

Hello,

–Am Dienstag, 27. Mai 2003 9:17 Uhr +0200 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:

the problem persisted after this change (using the same virtual server
for mail-gateway and web display).

Is it possible that there is a kind of “racing condition” in general if web
interface and rt-mailgate are used in parallel, so that incoming mail
transliteration is disturbed when one refreshes a web page of rt?

Regards,
Dirk.

12

Hello,

–Am Dienstag, 27. Mai 2003 9:17 Uhr +0200 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:

the problem persisted after this change (using the same virtual server
for mail-gateway and web display).

Is it possible that there is a kind of “racing condition” in general if web
interface and rt-mailgate are used in parallel, so that incoming mail
transliteration is disturbed when one refreshes a web page of rt?

It really shouldn’t be. We’ve made additional changes to the RT core
for UTF8. I’m not sure that any of them will fix it, but if you grab the
same URL from aegis for the rt 3.0 branch, it should be the current
code. I’d love to know how that works for you.

-j

Regards,
Dirk.

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

13

Hello Jesse,

–Am Donnerstag, 29. Mai 2003 2:13 Uhr -0400 schrieb Jesse Vincent
jesse@bestpractical.com:

It really shouldn’t be. We’ve made additional changes to the RT core
for UTF8. I’m not sure that any of them will fix it, but if you grab the
same URL from aegis for the rt 3.0 branch, it should be the current
code. I’d love to know how that works for you.

the newest version did not solve the problem neither. I have now taken care
of eliminating most custom configs here. rt-mailgate is invoked from the
same Virtual Server as the webserver.

I cannot see any differences in the record for the displayed transaction
attachments when I browse through the rt3 database with phpmyadmin. Even
though the display of one ticket in the webbrowser ist garbled and the
other one not. This does not depend on the browser I choose to display and
also the source of the webpage is different with the characters displayed
in the header fields of the transaction.

Can you reproduce the error at your test set with the decriptions I sent to
you?

This specific error which I could reproduce was only a minor annoyance
compared to the former problems I decribed before in the thread, but which
I could not reproduce.

I will continue testing and save the two tickets here. If you tell me how
to get them from our database, I can send you a dump of them.

Dirk.

14

Hello,

I have to apologize. I cannot reproduce the described problem, if I remove
one patch I have done, which enables RT to write almost correct threading
headers into notification mails.
I did not try to remove this patch before testing, because I did not see
how it can be related to the problem.
And for now after looking several hours into the code and testing it, I
still cannot see it.

I tracked my (header encoding) problem down to the following situation:

  1. Have my threading patch installed (I attached a light version, which
    consists of only one file to be put in lib/RT/Action).

  2. Send several emails with German Umlauts in subject and body to a queue,
    which has an Autoreply set up.

  3. refresh the Ticket Listing of the Queue in the web while Tickets arrives

  4. After some (5-10) Tickets arrived try the Ticket Display of the Tickets.
    The Subject header shown in the Ticket-Message-Display (not the Subject
    shown in other fields) of some Tickets (it is fuzzy!) is mangled and so is
    the Head-Field of those tickets in the mysql-database.

  5. This then seems to be a “global apache switch” which can toggle after
    some other messages arrive but will definitely be set to normal behaviour
    if apache is restarted.

So I have a workaround now but I would greatly appreciate, if someone takes
a look into my code, which is fairly short and the problem is within 3
lines of code:

It happens, when I leave the patch installed and comment out all calls of
“$self->SetHeader” in my SetReferences subroutine, I cannot reproduce the
problem any more.

But why??? SetHeader is called multiple time everywhere in SendEmail.pm.

Dirk.

–Am Montag, 26. Mai 2003 18:41 Uhr +0200 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:

SendEmail_Local.pm (2.29 KB)

15

Hello Jesse,

the problem reappeared now, where we became productive with rt-3.0.3pre4.
My threading patch is not active here but Autoreplies are.

It is now quite often, that the Subject, if it is displayed in the
MessageStanza (from the Head attribute of the datbase) is garbled (Umlauts
wrong) an sometimes cut off.
if it is displayed in the title (from the Subject attribute in the
database), is correctly written with Umlauts.

Could it be right what someone wrote that RT is not thread-safe?

Dirk.

–Am Dienstag, 10. Juni 2003 10:02 Uhr +0200 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:

16

Hello,

–Am Dienstag, 17. Juni 2003 14:59 Uhr +0200 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:

Could it be right what someone wrote that RT is not thread-safe?

an if this is so or if I want to test it, how can I disable threading in
Perl, modperl1 or RT?

Dirk.