Sorry, I didn't realize I sent this e-mail directly to Kristis.
Maybe it's more useful if I send it to the mailing list, too.
Il 19/02/2011 20:49, Kristis Makris ha scritto:
>> Another problem: the daemon not starting because of error 79, "Package
>> 'Bugzilla' not found in installation directory"
>>
>> This was actually solved as suggested in this mailing list by Thorsten
>> Schöning, that is by adding the following at the beginning of the script
>> that starts the scmbug-server daemon:
>>
>> export PERL5LIB=<Bugzilla installation dir>/lib
>
> This makes sense. I wonder if it is possible for you to modify
> Bugzilla.pm to issue a 'use lib' instead, rather than having to edit
> scmbug-server. The goal is for users to only have to edit daemon.conf.
>
> e.g. as proposed by the following patch, or something to that effect.
>
> ===================================================================
> RCS
> file: /projects/scmbug/cvsroot/system/src/lib/product/Daemon/Bugzilla.pm.in,v
> retrieving revision 1.86
> diff -u -r1.86 Bugzilla.pm.in
> --- Bugzilla.pm.in 27 Sep 2010 18:59:23 -0000 1.86
> +++ Bugzilla.pm.in 15 Feb 2011 00:50:05 -0000
> @@ -139,7 +139,7 @@
> chdir $self->installation_directory();
>
> if ($self->is_version_up_to_3_4() || $self->is_version_latest()) {
> - unshift @INC, $self->installation_directory() . "/lib";
> + use lib $self->installation_directory();
> }
>
> #
Hi Kristis,
if I change the line "unshift..." with "use lib
$self->installation_directory();" as your patch suggests, I get the
following when I try to start the daemon:
Starting SCM to bug-tracking integration daemon: scmbug_daemon
Can't call method "installation_directory" on an undefined value at
/usr/share/scmbug/lib/Scmbug/Daemon/Bugzilla.pm line 145.
BEGIN failed--compilation aborted at
/usr/share/scmbug/lib/Scmbug/Daemon/Bugzilla.pm line 145.
I don't know Perl (I'm a Java programmer), however this sounds strange
to me, because $self->installation_directory() is also called elsewhere
in the same code with no compilation problem...
Any suggestion?
>> on another machine (Debian Lenny) hosting a CVS repository: I had to set
>> the PERL5LIB in the following way, otherwise the glue installer gave an
>> error:
>>
>> export PERL5LIB=/usr/share/scmbug/lib
>
> This is the first time I ever hear of this problem. Is it possible to
> reproduce the error message?
It's not easy, because I would have to uninstall and try to re-install
Scmbug in our CVS production server and see if it happens again. The
error was that the glue-installer couldn't find some of the Scmbug Perl
classes (I can't remember exactly which one... maybe CVS.pm)... sorry
for not being able to be more clear.
Anyway, yesterday I came accross another problem:
http://bugzilla.mkgnu.net/show_bug.cgi?id=580
Since encoding problems are not easy to track down, first I need to
explain our architecture.
We have some client systems used by developers to work with Java code
using th Eclipse IDE. These systems can be Windows systems (with the
default system encoding being cp1252) or Linux systems (with the default
system encoding being UTF-8).
Then our sources are placed in a CVS repository and they are plain text
encoded with ISO-8859-1 charset. That is, every developer must ensure
that his/her Eclipse workspace is configured so that sources are managed
as being ISO-8859-1 text files (this is particularly important for the
Linux users, since cp1252 used by Windows is actually a superset of
ISO-8859-1), otherwise he/she risks to corrupt code comments containing
accented letters.
Then, the server hosting the CVS is a Debian Lenny with the default
system encoding being UTF-8. Anyway, as I already said, sources stored
in the CVS are using ISO-8859-1 charset.
On the other hand, Bugzilla is hosted on a Debian Squeeze system with
the default system encoding being UTF-8. Bugzilla is also configured to
use UTF-8 and data in the MySql Bugzilla database is stored in UTF-8.
In this environment, if a Windows developer committed some changes to
the CVS and specified a comment log with non-ASCII characters, the
commit log was truncated by Scmbug immediately before the first
non-ASCII character. This was confirmed by the fact that looking at the
Bugzilla database (through a Mysql client) the comment added by Scmbug
was actually stored as truncated.
However, the notification e-mail sent by Scmbug worked perfectly: it was
sent with the following header:
Content-Type: text/plain; charset="iso-8859-1"
and the body contained the whole comment log (not truncated!), with
non-ASCII characters displayed properly.
So, to try to solve this problem, I firstly read all the comments in
Scmbug bug 580 and then I tried the suggestion given by Markus Kling and
reported in comment 34: that is, on the daemon side, I edited
Bugzilla.pm and added a "use Encoding" at the beginning, and the
following statement before the call to $bug->add_comment:
$comment = encode( "utf-8", $comment ) if Bugzilla->params->{ 'utf8' };
This actually works! The final result is the following:
- when a Windows user commits something to CVS and he inserts a comment
with non-ASCII characters, these characters are passed correctly to both
the CVS server (by the CVS client directly) and Bugzilla (by Scmbug),
and the comment is not truncated; the mails sent by Scmbug for
notification are also correct
- when a Linux user commits something to CVS and he inserts a comment
with non-ASCII characters, these characters are passed wrong to both the
CVS server (by the CVS client directly) and Bugzilla (by Scmbug), but
the comment is not truncated; also, the non-ASCII characters are
displayed wrong, but in the SAME way in all of the involved places (that
is: CVS log, Bugzilla comment and Scmbug notification e-mail); so, I
don't consider this to be a bug of Scmbug, but rather a problem with the
Eclipse CVS client, which does not convert the comment log to ISO-8859-1
(just like the sources) and doesn't let me set this kind of conversion.
In other words, if I completely remove Scmbug from the whole picture,
comments log with non-ASCII characters issued by Linux developers in our
environment are still stored in the wrong way in the CVS server and this
is confirmed when another developer tries to retrieve the CVS history of
one of the changed files.
To sum this up: the suggestion given by Markus Kling seems to work
perfectly in our environment. The only problem we still have with commit
comments issued by Linux clients is not due to Scmbug.
__UPDATE:__ I just discovered how to configure Eclipse to use the
ISO-8859-1 encoding when interacting with the CVS server: now our Linux
developers can commit changes with comments with non-corrupted non-ASCII
characters, too! :-) This confirms once more that Scmbug is working
perfectly in our environment now.
The only thing is not clear to me is the following: what if we were
using another charset as the one used for our sources? That is, what
would happen if we stored the sources in the CVS server in UTF-8 too?
All may work correctly anyway, or some corruptions may occur (for
instance: the notification e-mail is sent in ISO-8859-1 charset, so
would a conversion from UTF-8 occur?). To reply to this question I would
need a deep knowledge of Perl, Scmbug and all of the components involved
in the whole process, but unfortunately I don't. However, I hope this
helps you in some way.
--
Mauro Molinari
Software Designer & Developer
E-mail: [email protected]
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
