Another Makefile bug

[Michael]

My apologies for introducing another issue
Should i perhaps put these into RT somewhere?

RT_LOGFILE tells where to log stuff. If you want to use syslog, get

problems reported by mail or anything else, check etc/config.pm and

the Log::Dispatch POD.

RT_LOGFILE = ($RT_PATH)/rt.log

Should this not be $(RT_PATH) ?

Also, the Makefile doesnt do the inplace substitutions on
etc/config.pm, so it ends up looking like

[snip]

$Logger->add(Log::Dispatch::File->new
( name=>‘rtlog’,
min_level=>‘info’,
filename=>’!!RT_LOGFILE!!’,
mode=>‘append’,
callback => sub {%p=@_; return “$p{message}\n”}
));

And a file named !!RT_LOGFILE!! is placed in the current directory

When i look into this file i get:

[root@beer]15:55/www/rt2/bin/cgi%  cat \!\!RT_LOGFILE\!\! 
HTML::Mason::Interp::new: must specify value for data_dir
HTML::Mason::Interp::new: must specify value for data_dir
HTML::Mason::Interp::new: must specify value for data_dir

Being new to HTML::Mason, i’m not sure what this means, but
i’ll see if i can’t glean the problem from the perl source…

cheers,

_M.

Michael Jastremski … AIM:rstfinsyn
WORK:liquidation.com ME:westphila.net/mike
PHOTO:opl.megaglobal.net … BIZ:megaglobal.net

[Michael]

And so i says to him|her…

When i look into this file i get:

[root@beer]15:55/www/rt2/bin/cgi% cat !!RT_LOGFILE!!
HTML::Mason::Interp: must specify value for data_dir
HTML::Mason::Interp: must specify value for data_dir
HTML::Mason::Interp: must specify value for data_dir

Being new to HTML::Mason, i’m not sure what this means, but
i’ll see if i can’t glean the problem from the perl source…

I see. Looking at rtmux.pl.org, the problem is that after the install,
the following variables in rtmux.pl end up getting set to null.

#TODO: Make this draw from the config file
my $interp = new HTML::Mason::Interp (
parser=>$parser,
comp_root=>‘!!WEBRT_HTML_PATH!!’,
data_dir=>‘!!WEBRT_DATA_PATH!!’);

Probably due to the following typo in the mux-install rule:

s'!!WEBRT_HTML_PATH!!'$($WEBRT_HTML_PATH)'g;\
s'!!WEBRT_DATA_PATH!!'$($WEBRT_DATA_PATH)'g;\

It seems that the extra $ signs are spurious…
Another patch for the makefile…

regards,

_Michael.

Michael Jastremski … AIM:rstfinsyn
WORK:liquidation.com ME:westphila.net/mike
PHOTO:opl.megaglobal.net … BIZ:megaglobal.net

[Tobias_Brox]

My apologies for introducing another issue
Should i perhaps put these into RT somewhere?

Hm … what do you mean “Put it into RT”? If you mean “send patches”,
then that might be a good idea Also, minor bugfixes might be sent to
me instead of the list.

RT_LOGFILE = ($RT_PATH)/rt.log

Should this not be $(RT_PATH) ?

Of course. I didn’t test this, my fault. Thanx.

Also, the Makefile doesnt do the inplace substitutions on
etc/config.pm, so it ends up looking like

Oh? Weird. I’ll look at it.

And a file named !!RT_LOGFILE!! is placed in the current directory

When i look into this file i get:

[root@beer]15:55/www/rt2/bin/cgi% cat !!RT_LOGFILE!!
HTML::Mason::Interp: must specify value for data_dir
HTML::Mason::Interp: must specify value for data_dir
HTML::Mason::Interp: must specify value for data_dir

Being new to HTML::Mason, i’m not sure what this means, but
i’ll see if i can’t glean the problem from the perl source…

Hm. I just got a mail from another person that said he couldn’t get the
webmux.pl to work (httpd just died on him when the perlhandler was
installed). I’m running FCGI instead of perl_mod myself, so I don’t know
much.

“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”

• Bertrand Russell

[Jesse1]

My apologies for introducing another issue
Should i perhaps put these into RT somewhere?

Hm … what do you mean “Put it into RT”? If you mean “send patches”,
then that might be a good idea Also, minor bugfixes might be sent to
me instead of the list.

presumably the bugs queue.

RT_LOGFILE = ($RT_PATH)/rt.log

Should this not be $(RT_PATH) ?

Of course. I didn’t test this, my fault. Thanx.

Also, the Makefile doesnt do the inplace substitutions on
etc/config.pm, so it ends up looking like

Oh? Weird. I’ll look at it.

And a file named !!RT_LOGFILE!! is placed in the current directory

When i look into this file i get:

[root@beer]15:55/www/rt2/bin/cgi%  cat \!\!RT_LOGFILE\!\! 
HTML::Mason::Interp::new: must specify value for data_dir
HTML::Mason::Interp::new: must specify value for data_dir
HTML::Mason::Interp::new: must specify value for data_dir

Being new to HTML::Mason, i’m not sure what this means, but
i’ll see if i can’t glean the problem from the perl source…

Hm. I just got a mail from another person that said he couldn’t get the
webmux.pl to work (httpd just died on him when the perlhandler was
installed). I’m running FCGI instead of perl_mod myself, so I don’t know
much.

He should look in the !!RT_LOGFILE!! that was created. I’d put money on it
being the Mail::addrlist bug.

–
“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”

• Bertrand Russell

---

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

jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
As I sit here alone looking at green text on a laptop in a mostly bare room listening
to loud music wearing all black, I realize that that it is much less cool in real life
–Richard Tibbets

[Tobias_Brox]

I see. Looking at rtmux.pl.org, the problem is that after the install,
the following variables in rtmux.pl end up getting set to null.

You should use webmux.pl for operations with mod_perl. The
web-code in rtmux.pl contains a lot of errors, that’s for sure. I’ve
managed to get one rtmux.pl running locally, but I have been too lazy to
update the rtmux.pl yet.

Probably due to the following typo in the mux-install rule:

s’!!WEBRT_HTML_PATH!!‘$($WEBRT_HTML_PATH)‘g;
s’!!WEBRT_DATA_PATH!!’$($WEBRT_DATA_PATH)'g;\

Oh. I’ll fix that also.

“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”

• Bertrand Russell

[Kent_Longballa]

And a file named !!RT_LOGFILE!! is placed in the current directory

He should look in the !!RT_LOGFILE!! that was created. I’d put money on it
being the Mail::addrlist bug.

Actually the first bug is probably the same one that I got where RT tries to
write that log file to any directory it ends up in and rt dosn’t usually
have perms to write into say /usr/lib/perl5/site_perl/
I pointed the RT_LOGFILE to /tmp/rt.log and that fixes the first problem.
The second is most likely addrlist.pm and date.pm not being around, Find the
follow files and link them to thier lowercase names instead then it should
work. Here is the location on my system.

/usr/lib/perl5/site_perl/5.005/Mail/Field
do the next two commands in the Field dir to fix the problem.

ln -sf AddrList.pm addrlist.pm
ln -sf Date.pm date.pm

–
“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”

• Bertrand Russell

---

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

jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
As I sit here alone looking at green text on a laptop in a mostly bare room
listening
to loud music wearing all black, I realize that that it is much less cool in
real life
–Richard Tibbets

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

[Tobias_Brox]

Hm … what do you mean “Put it into RT”? If you mean “send patches”,
then that might be a good idea Also, minor bugfixes might be sent to
me instead of the list.

presumably the bugs queue.

Actually I will deal with small bugreports and attached patches if they
come directly to me. More complex bugs (without applied patches) should
be sent to the bug queue at rt20@fsck.com.

Hm. I just got a mail from another person that said he couldn’t get the
webmux.pl to work (httpd just died on him when the perlhandler was
installed). I’m running FCGI instead of perl_mod myself, so I don’t know
much.

He should look in the !!RT_LOGFILE!! that was created. I’d put money on it
being the Mail::addrlist bug.

No, he had already dealt with that…

That’s another really weird bug that I haven’t managed to reproduce. When
starting up RT2, it complains that it can’t find Mail::Field::addrlist and
Mail::Field::date - while Mail::Field::AddrList and Mail::Field::Date
exists. The problem vanishes when some symlinks are made at the right
place. I absolutely haven’t found out why this happens, and I haven’t
managed to get a stack trace which made any sense. I’ve even scanned the
whole RT + DBIx + site_perl after ‘addrlist’ without finding anything at
all!

The only thing that is certain is that this bug was introduced when I
started using Log::Dispatch. But Log::Dispatch passes it’s test suite …
so I really don’t know where and how to look…

“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”

• Bertrand Russell

[Jesse1]

/usr/lib/perl5/site_perl/5.005/Mail/Field
do the next two commands in the Field dir to fix the problem.

ln -sf AddrList.pm addrlist.pm
ln -sf Date.pm date.pm

while that will patch the problem for now, that’s not a solution we can
release with…

–
“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”

• Bertrand Russell

---

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

–
jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91

As I sit here alone looking at green text on a laptop in a mostly bare room
listening
to loud music wearing all black, I realize that that it is much less cool in
real life
–Richard Tibbets

---

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

---

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

jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
“It’s buried in the desert, got sand in it, melts Nazis. You know,
the Ark of the Covenant” – siva

[Michael]

And so i says to him|her…

Actually I will deal with small bugreports and attached patches if they
come directly to me. More complex bugs (without applied patches) should
be sent to the bug queue at rt20@fsck.com.

Gotcha. ‘Put it in RT’ is what folks are always saying around here .
Or perhaps thats what i tell them when they come to me with scraps
of paper with issues written on them;)

Hm. I just got a mail from another person that said he couldn’t get the
webmux.pl to work (httpd just died on him when the perlhandler was
installed). I’m running FCGI instead of perl_mod myself, so I don’t know
much.

I’m curious, is mod_perl the preferred platform, or can i get away
with running it in plain old CGI mode? I was using rtmux.pl to
begin with because ‘make install’ created a symlink from rtmux.pl
to webrt.cgi, so i assumed that was what i was to be using…

That’s another really weird bug that I haven’t managed to reproduce. When
starting up RT2, it complains that it can’t find Mail::Field::addrlist and
Mail::Field::date - while Mail::Field::AddrList and Mail::Field::Date
exists. The problem vanishes when some symlinks are made at the right
place. I absolutely haven’t found out why this happens, and I haven’t
managed to get a stack trace which made any sense. I’ve even scanned the
whole RT + DBIx + site_perl after ‘addrlist’ without finding anything at
all!

I just did some quick searching of my own in my perl tree.
I haven’t come up with anything yet.

_Michael.

Michael Jastremski … AIM:rstfinsyn
WORK:liquidation.com ME:westphila.net/mike
PHOTO:opl.megaglobal.net … BIZ:megaglobal.net

[Tobias_Brox]

Actually I will deal with small bugreports and attached patches if they
come directly to me. More complex bugs (without applied patches) should
be sent to the bug queue at rt20@fsck.com.

Gotcha. ‘Put it in RT’ is what folks are always saying around here .
Or perhaps thats what i tell them when they come to me with scraps
of paper with issues written on them;)

Heh, while RT1 might be good enough for the support dept, it’s not good
enough for me One of the most essential things (which will be dealt
with in RT2) is that it doesn’t support attachments. Because of
linebreaks and so on, it’s usually a lot easier to get patches as
attachments.

Hm. I just got a mail from another person that said he couldn’t get the
webmux.pl to work (httpd just died on him when the perlhandler was
installed). I’m running FCGI instead of perl_mod myself, so I don’t know
much.

I’m curious, is mod_perl the preferred platform, or can i get away
with running it in plain old CGI mode?

You can get away with plain, old CGI, but it will go quite slowly.
Unfortunately, we have a lot of overhead in the object oriented approach
as for now - we hope we can optimize it a bit.

It’s really not that hard to install FCGI. I don’t like mod_perl much, it
seems to me that it has this tendency of letting the httpd die with a
segfault and no explanation whatsoever what’s wrong with itself nor the
perl code.

I was using rtmux.pl to
begin with because ‘make install’ created a symlink from rtmux.pl
to webrt.cgi, so i assumed that was what i was to be using…

Did you ever read the README?

That’s another really weird bug that I haven’t managed to reproduce.

…eh, I have managed to reproduce it, just not pinpoint it The perl
5.6.0 debugger seems instable, and it never managed to give me a stack
trace which made sense. It also seems to do a lot of weird things
(with a lot of weird warnings) during cleanup. So my advice to
everybody: Don’t install perl 5.6.0!

“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”

• Bertrand Russell

[Tobias_Brox]

Looking closer at the code, it seems pretty obvious that it must be
something wrong with Field.pm itself:

foreach $f (readdir(DIR))
next
unless $f =~ /^([\w-]+)/;

 my $p = lc $1;
 (...)
 eval "require ${pkg}::$p"

This is plain wrong, that’s one thing. But I’m still interessted to see
the stack trace to discover why this shi^H^H^Hinteressting piece of code
was called in the first place. It’s really a waste to require packages
that are never used.

“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”

• Bertrand Russell

[Brandon_S_Allbery_KF]

| > > Hm … what do you mean “Put it into RT”? If you mean “send patches”,
| > > then that might be a good idea Also, minor bugfixes might be sent
| to > > me instead of the list.
| > >
| > presumably the bugs queue.
|
| Actually I will deal with small bugreports and attached patches if they
| come directly to me. More complex bugs (without applied patches) should
| be sent to the bug queue at rt20@fsck.com.
|
| > > Hm. I just got a mail from another person that said he couldn’t get
| the > > webmux.pl to work (httpd just died on him when the perlhandler was
| > > installed). I’m running FCGI instead of perl_mod myself, so I don’t
| know > > much.
| > >
| >
| > He should look in the !!RT_LOGFILE!! that was created. I’d put money on
| it > being the Mail::addrlist bug.
|
| No, he had already dealt with that…
|
| That’s another really weird bug that I haven’t managed to reproduce. When
| starting up RT2, it complains that it can’t find Mail::Field::addrlist and
| Mail::Field::date - while Mail::Field::AddrList and Mail::Field::Date
| exists. The problem vanishes when some symlinks are made at the right
| place. I absolutely haven’t found out why this happens, and I haven’t
| managed to get a stack trace which made any sense. I’ve even scanned the
| whole RT + DBIx + site_perl after ‘addrlist’ without finding anything at
| all!
|
| The only thing that is certain is that this bug was introduced when I
| started using Log::Dispatch. But Log::Dispatch passes it’s test suite …
| so I really don’t know where and how to look…
±–>8

Mail::Field is broken. The stack trace is useless because it’s obscured by
an AUTOLOAD routine which automagically loads the appropriate
Mail::Field::* “subclass”; said AUTOLOAD does a ucfirst, but should be
doing an lc (or the files should be renamed…).

(The documentation matches Mail::Field::_header_pkg_name, so I conclude
that the *.pm files are misnamed.)

brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical & computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]