Bug#424407: sympa: New build-depends
Stefan Hornburg (Racke) a écrit : Micah Anderson wrote: Package: sympa Severity: minor You may have noticed that when building the new sympa, there are some new perl modules that it depends on. These perl modules were not in Debian, so I packaged them and they recently passed NEW. You may wish to adjust your build dependencies on sympa to include the following: libcrypt-openssl-x509-perl Where is this module used in sympa ? We've just realized, thanks to you, that is was not used. It has been introduced with an X509 related patch but the patch code still uses mod_ssl. See http://sourcesup.cru.fr/cgi/viewvc.cgi/trunk/check_perl_modules.pl?root=sympar1=3531r2=3754 We'll remove that dependency from both SVN branches of Sympa. Thanks for reporting this.
Bug#416508: sympa: Sympa should suggest libsoap-lite-perl which is needed for its SOAP server
Olivier Berger wrote: Package: sympa Version: 5.2.3-1.2 Severity: normal In order to use the sympa soap server, the SOAP-lite perl module must be installed. Hence, Sympa should suggest installation of libsoap-lite-perl package. [...] Sympa DOES ; it suggests installing SOAP::Lite during sympa's make (via check_perl_modules.pl). I don't know how the Debian package should cope with this... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411987: Activation FastCGI support won't configure use_fast_cgi in wwsympa.conf
Olivier Berger wrote: Package: sympa Version: 5.2.3-1.2 Severity: normal I'm not sure if this is important... I've run into the situation where I had 'use_fast_cgi' set to 0 in /etc/sympa/wwsympa.conf and wwsympa.fcgi wouldn't work (running as a simple CGI instead of using all FastCGI API's resources, which is no good). For the records, I though that mod_fastcgi wasn't working since I had wwsympa.fcgi's output in error.log... see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411928 for some details... and my misunderstanding of what FastCGI was about ;) But it was just that use_fast_cgi should have been set to 1 when fastcgi tried to execute wwsympa.fcgi... I'm not sure how the variable was set to 0, though. I'm not completely sure that this situation is linked to this... but still I think that debconf's FastCGI activation should result in setting use_fast_cgi accordingly in /etc/sympa/wwsympa.conf ... There are known problems with mod_fastcgi with Apache 2.2 because the Apache API has changed. A patch has been provided by a user but it was not applied back in mod_fastcgi itself. The patch : http://hack.emilykwan.com/node/95 Since mod_fastcgi seems to be a dead product, it is worth looking at alternatives : * mod_fcgid ; see http://www.sympa.org/wiki/faq/fastcgi?s=fastcgi#installing_mod_fcgid_for_apache2_on_debian * mod_proxy_fcgi (http://mproxyfcgi.sourceforge.net/) might be integrated in Apache itself
Bug#408211: sympa: wws doesn't display french character correctly with apache2.2
Olivier Berger wrote: Package: sympa Version: 5.2.3-1 Severity: minor With apache2.2 (which sets a adddefaultcharset utf-8), and french language set for the interface, wws will produce weird characters. AFAICT wws will produce iso8859-1 characters which are then rendered weird since apache 2.2 pretends its utf-8. I think the config file should then contain something like Location /wws AddDefaultCharset Off /Location I confirm that the AddDefaultCharset feature of Apache should be disabled for Sympa web interface, since web pages use the charset associated to the current language. Things change in the release to come, because utf-8 will be used for all HTML pages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408097: sympa logs error on /style.css file not found
Olivier Berger wrote:
Package: sympa
Version: 5.2.3-1
Severity: minor
Tags: patch
Sympa logs (/var/log/sympa.log) contain error messages complaining for file
/style.css not found :
could not find CSS file /style.css, using default CSS
Such error occurs all the time (each action in wws, acutally), and thus
annoying. I noticed it by using logcheck.
But I think this is actually no error when no css_path was defined (by
default), according to the docs, because in such case, sympa will construct a
dynamic CSS instead of using a predefined static CSS file (css_path + css_url).
So this should only be an info message I think, when no css_path is defined (or
nothing).
You're right it may be a common behavior and users should not get these
logs.
We've make things better in current development version where :
* a new static_content/ directory has been added to store all these
contents (like CSS, SOAP WSDP, user pictures, ...) that don't
change and therefore don't require any wwsympa processing.
* CSS is automatically updated (in static_content/ directory) after
an upgrade process
* As a consequence, Sympa no more fills out his logs with the
message you report
But we don't have plans to report all these changes to 5.2.x branch.
Here's a proposed workaround.
/usr/lib/cgi-bin/sympa# diff -uibw wwsympa.fcgi.orig wwsympa.fcgi
--- wwsympa.fcgi.orig 2007-01-23 14:52:04.0 +0100
+++ wwsympa.fcgi2007-01-23 14:49:20.0 +0100
@@ -723,7 +723,7 @@
$param-{'css_url'} = Conf::get_robot_conf($robot, 'css_url');
## If CSS file not found, let Sympa do the job...
unless (-f $param-{'css_path'}.'/style.css') {
-wwslog('err','Could not find CSS file %s, using default CSS',
$param-{'css_path'}.'/style.css');
+wwslog('info','Could not find CSS file %s, using default CSS',
$param-{'css_path'}.'/style.css');
$param-{'css_url'} = $param-{'base_url'}.$param-{'path_cgi'}.'/css';
}
In fact, I think a better algorithm should be needed : if no css_path is
defined, nothing to log, and otherwise, if the file is not found in css_path,
then THERE is an error to log, then.
Hope this helps.
Should probably be forwarded upstream ?
Bug#408097: sympa logs error on /style.css file not found
Hi Sylvain,
I've applied the patch to the 5_2 branch ; it is legitimate :
http://sourcesup.cru.fr/cgi/viewcvs.cgi/sympa/wwsympa/wwsympa.fcgi?only_with_tag=sympa-5_2-branchr2=1.652.2.13r1=1.652.2.12
We might release another 5.2 release if we have major fixes applied to
this branch.
Sylvain Amrani wrote:
css_path is $Conf{'static_content_path'}.'/css' if not defined
It's been fixed this way in the development branch :
@@ -723,7 +771,8 @@
$param-{'css_url'} = Conf::get_robot_conf($robot, 'css_url');
## If CSS file not found, let Sympa do the job...
unless (-f $param-{'css_path'}.'/style.css') {
-wwslog('err','Could not find CSS file %s, using default CSS',
$param-{'css_path'}.'/style.css');
+ wwslog('err','Could not find CSS file %s, using default CSS', $param-{'css_path'}.'/style.css')
+ if ($param-{'css_path'}); ## Notice only if path was defined
$param-{'css_url'} = $param-{'base_url'}.$param-{'path_cgi'}.'/css';
}
If css_url dir does not exist, the Upgrade process will create it and create
.css files in it.
So, please :
Stefan Hornburg : could you please double-check that the default
static_content_pass/css directory is writable for user sympa ?
Sympa-author : will you release a new 5.2 release ? If so, would you apply this
patch in the 5_2 branch ?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403909: bad /usr/share/sympa/web_tt2/authorization_reject.tt2 symlink
Stefan Hornburg (Racke) wrote:
Jean Charles Delepine wrote:
Package: sympa
Version: 5.2.3-0.5
Severity: important
Tags: patch
sympa native instalattion links
/usr/share/sympa/mail_tt2/authorization_reject.tt2 to
${PREFIX}/usr/share/sympa/web_tt2/authorization_reject.tt2
Is this a bug in Sympa or somehow related to the Debian
packaging ?
sympa-5.2.3/mail_tt2/Makefile : rm -f
$(DESTDIR)$(ETCBINDIR)/web_tt2/authorization_reject.tt2 ;
ln -s $(DESTDIR)$(ETCBINDIR)/mail_tt2/authorization_reject.tt2
$(DESTDIR)$(ETCBINDIR)/web_tt2
DESTDIR when native insallation will be somewhat like /usr/local/sympa
ETCBINDIR will be somewhat like share. Relative symlinks might be
better but I don't think we can say it a bug.
The installation in $(DESTDIR) should be self-contained, therefore I
consider
that a bug of Sympa.
I've fixed the link problem in both CVS trees.
Here is the patch for 5.2.x :
http://sourcesup.cru.fr/cgi/viewcvs.cgi/sympa/mail_tt2/Makefile?only_with_tag=sympa-5_2-branchr2=1.4.4.1r1=1.4
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349883: sympa: WWSympa fails to bring email when using CAS
The problem you reported has already been fixed in recent versions of Sympa : http://sourcesup.cru.fr/cgi/viewcvs.cgi/sympa/wwsympa/Auth.pm?only_with_tag=sympa-5_1-branchr2=1.14r1=1.13 Pierre Pattard wrote: Package: sympa Version: 4.1.5-7 Severity: important When using the cas policy in /etc/sympa/auth.conf with a ldap_bind_dn and a ldap_bind_password (which means a NOT anonymous bind), WWsympa though try to bind anonymously, ignoring configuration variables. This is due to an error in the Auth.pm class. The bind_dn and bind_password stand for the ldap policy whereas you need to use ldap_bind_dn and ldap_bind_password for the cas policy. See my patch enclosed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299701: sympa logs way too much
Could you please precise what kind of log entries you consider useless. These log entries could either be removed or filtered depending on the log_level parameter... Geoff Crompton wrote: I agree. Sympa does log way to much. Does anyone know if upstream is aware of this, or cares about this? Thanks Enrico for your work on the logcheck rules. I suspect I will soon just logcheck ignore everything coming out of sympa though. Or is there a mod to /etc/syslog.conf that makes it all go away? smime.p7s Description: S/MIME Cryptographic Signature
Bug#330853: sympa: documentation for setting up robots misses a step
We've completed the documentation according to your suggestions, in both 5.1 stable branch and development branch : http://sourcesup.cru.fr/cgi/viewcvs.cgi/sympa/doc/sympa.tex.tpl?only_with_tag=sympa-5_1-branchr2=1.228.2.2r1=1.228.2.1 Geoff Crompton wrote: Package: sympa Version: 4.1.5-2 Severity: normal I recently setup sympa with a robot config. As per http://localhost/doc/sympa/html/node12.html I created the directory and file /etc/sympa/lists.mydomain.com/robot.conf. However after some debugging, I know I also needed to create /var/lib/sympa/expl/lists.mydomain.com/, and set the owner to sympa:sympa and the permissions to 0750. Can the documentation be updated to reflect this? smime.p7s Description: S/MIME Cryptographic Signature
Bug#330854: sympa: robot config doesn't work if wws is behind apache proxy
We took your proposal into account in the current development version of Sympa as described below : Fix problems when using Sympa in a proxy context (virtual robot selection, navigation in web archives). WWSympa now uses the HTTP_X_FORWARDED_SERVER and HTTP_X_FORWARDED_HOST header fields if set Here is a patch : http://sourcesup.cru.fr/cgi/viewcvs.cgi/sympa/wwsympa/wwsympa.fcgi?r1=1.574r2=1.575 Geoff Crompton wrote: Package: sympa Version: 4.1.5-2 Severity: normal The robot works by looking for the environment variable SERVER_NAME. However if the web server is sitting behind an apache1.3 proxy, SERVER_NAME is not set. Instead the HTTP_X_FORWARDED_SERVER variable has the frontend name, and SERVER_NAME has the name of the backend host. Can the package be made to check either variable? Or Can the documentation be updated to mention this limitation? Cheers Geoff Cromptno smime.p7s Description: S/MIME Cryptographic Signature
