Re: please set up a mod_python core group
Jorey Bump wrote: Mike Looijmans wrote: Seriously, I think Grisha's way is right - the three musketeers should decide based on the feedback they get. There's no substitute for running on other people's machines... 2006/1/19, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]: Thanks Roy. Very timely, since 3.2.6 is (so far) going to be a final/stable release. I propose that for starters those people are: me (I'm also in the Apache HTTP Server PMC) Jim Gallacher Nicolas Lehuen Graham Dumpleton +1 here, but since the build process and typical MPM differs among platforms, could we see a list that this group represents? I'm most interested in default nonvirtualized environments used in production or for principal development. This information will be useful when reviewing release candidates, to make sure we haven't overlooked any key platforms. IOW, could you guys list the OS on which you run, and not merely test, mod_python? By you guys I assume you mean the above 4 people? I'm not sure how relevant this is since looking at that information from just 4 people is too small a sample to determine if the code is ready for release. Hopefully Roy will clarify, but I see the role of the core group more as meta voters, where we vote on the voting. So in theory, the core group could vote for a release even if none of them has ever actually compiled or used mod_python. On the other hand, you may mean *all* the people on python-dev who test a release candidate should list their production platform. This would be useful to the core group as another data point in deciding on casting a binding vote to proceed to release. That being said, I do eat my own dogfood, so here is my setup: Development and testing (mod_python and my own stuff): Linux Debian unstable, Apache 2.0.55 mpm-prefork, python 2.3.5 Testing (mod_python only, using qemu) Linux Debian stable (sarge), Apache 2.0.54 mpm-prefork, python 2.3.4 Linux Debian stable (sarge), Apache 2.0.54 mpm-worker, python 2.3.4 Production Linux Debian stable (sarge), Apache 2.0.54 mpm-prefork, python 2.3.4 Similar to Nicolas, I need mpm-prefork as there are some php applications on the production server. Your point on making sure we don't overlook any key platforms in our testing is a good one. Should we (python-dev people) put together a list of key platforms as a future guide? It's likely a good idea, even at the risk of a flamewar. ;) I thought I'd put together a summary of 3.2.6 test results in the next few days anyway, which should be a good starting point for the key list. Jim
Re: please set up a mod_python core group
Jim Gallacher wrote: Jorey Bump wrote: IOW, could you guys list the OS on which you run, and not merely test, mod_python? By you guys I assume you mean the above 4 people? Yeah, youse 4 guys. :) On the other hand, you may mean *all* the people on python-dev who test a release candidate should list their production platform. This would be useful to the core group as another data point in deciding on casting a binding vote to proceed to release. No, I'm just interested in the core group. Everyone else gets an opportunity to list platforms when testing new releases, in pass/fail feedback responses. Your point on making sure we don't overlook any key platforms in our testing is a good one. Should we (python-dev people) put together a list of key platforms as a future guide? It's likely a good idea, even at the risk of a flamewar. ;) I thought I'd put together a summary of 3.2.6 test results in the next few days anyway, which should be a good starting point for the key list. A small checklist might be useful, such as Windows/Mac/Linux/UNIX/BSD. This has been handled fairly well in the past, but that might be due to luck. I'm concerned that some last minute fix will be checked into a stable release candidate without sufficient cross-platform testing. I mainly use Python in UNIX-like environments, and I forget how popular it is on Windows (the same goes for Apache). Ideally, it would be nice to solicit feedback from package maintainers. I use Slackware, which doesn't include Apache 2 or mod_python, so I can tell immediately how it's going to perform in my production systems. Users of stock Red Hat, Debian, SUSE, Mandriva, FreeBSD, Mac, etc. can't be so sure. The package maintainers are in the best position to flag potential problems. But this is an issue shared by many open source projects, and we'll need to be satisfied with the participation we get, and try our best to create a stable release.
Re: please set up a mod_python core group
Jim Gallacher wrote: Jorey Bump wrote: +1 here, but since the build process and typical MPM differs among platforms, could we see a list that this group represents? I'm most interested in default nonvirtualized environments used in production or for principal development. This information will be useful when reviewing release candidates, to make sure we haven't overlooked any key platforms. Your point on making sure we don't overlook any key platforms in our testing is a good one. Should we (python-dev people) put together a list of key platforms as a future guide? It's likely a good idea, even at the risk of a flamewar. ;) I thought I'd put together a summary of 3.2.6 test results in the next few days anyway, which should be a good starting point for the key list. As a non-x86 user (amd64 here), I second the notion that we need some non-Linux non-x86 platform testing out there, if people were willing to commit to be available to build and test when that time comes around (I think it's been pretty good, about every 2 months it's been on average?). I know there are people on PPC OSX, FreeBSD, AIX, Tru64, Solaris, and I just think it's a good idea to have a general concensus that a build will work on at least some of these platforms that both apache and Python are also supported and has worked for in the past. I'm not sure which of these you can identify as key, but I would say that *BSD, OSX and Solaris should top the list. I also suggest Linux x86_64 of some kind, since it's becoming more and more widely used; I know we've got 2 or 3 people that normally respond to release tests that do. Nick
Re: please set up a mod_python core group
On Thu, 19 Jan 2006, Jorey Bump wrote: +1 here, but since the build process and typical MPM differs among platforms, could we see a list that this group represents? This group would not represent any platforms when acting in _this_ capacity. One of the group's responsibility would be to decide whether sufficient number of platforms were represented by tests done by anyone on this mailing list (including anyone from this group, of course). Grisha
[patch] test fails when mod_alias not built
Hello, After reading mod_perl for speed freaks I trimmed down my httpd and had test failures building apreq trunk against Perl 5.8.6, mod_perl 2.0.2 and Apache 2.2.0. The following small changes resulting in make test completing when httpd was not built with mod_alias. - Fred Index: module/t/conf/extra.conf.in === --- module/t/conf/extra.conf.in (revision 370406) +++ module/t/conf/extra.conf.in (working copy) @@ -1,4 +1,7 @@ -ScriptAlias /cgi-bin/ @ServerRoot@/cgi-bin/ +IfModule mod_alias.c +ScriptAlias /cgi-bin/ @ServerRoot@/cgi-bin/ +/IfModule + IfModule !mpm_winnt.c LockFile @ServerRoot@/logs/accept.lock /IfModule Index: glue/perl/t/conf/extra.conf.in === --- glue/perl/t/conf/extra.conf.in (revision 370406) +++ glue/perl/t/conf/extra.conf.in (working copy) @@ -1,4 +1,7 @@ -ScriptAlias /cgi-bin/ @ServerRoot@/cgi-bin/ +IfModule mod_alias.c +ScriptAlias /cgi-bin/ @ServerRoot@/cgi-bin/ +/IfModule + IfModule !mpm_winnt.c LockFile @ServerRoot@/logs/accept.lock /IfModule
AW: PR#38123
-Ursprüngliche Nachricht-
Von: Nick Kew
[..cut..]
That's the same bug and fix as PR#37790!
Which leads me to wonder, is there some good reason not to
insert the input filter unconditionally somewhere earlier in
request_post_read? As it stands, it looks as if your fix has
the same problem as mine: namely, it fixes the immediate
problem but leaves the bug waiting to manifest itself anew in
other early error conditions.
What about the following patch instead (currently untested)?
Index: server/protocol.c
===
--- server/protocol.c (revision 370457)
+++ server/protocol.c (working copy)
@@ -902,6 +902,9 @@
(see RFC2616 section 14.23): %s, r-uri);
}
+ap_add_input_filter_handle(ap_http_input_filter_handle,
+ NULL, r, r-connection);
+
if (r-status != HTTP_OK) {
ap_send_error_response(r, 0);
ap_update_child_status(conn-sbh, SERVER_BUSY_LOG, r);
@@ -910,8 +913,6 @@
}
if ((access_status = ap_run_post_read_request(r))) {
-ap_add_input_filter_handle(ap_http_input_filter_handle,
- NULL, r, r-connection);
ap_die(access_status, r);
ap_update_child_status(conn-sbh, SERVER_BUSY_LOG, r);
ap_run_log_transaction(r);
@@ -934,8 +935,6 @@
ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
client sent an unrecognized expectation value of
Expect: %s, expect);
-ap_add_input_filter_handle(ap_http_input_filter_handle,
- NULL, r, r-connection);
ap_send_error_response(r, 0);
ap_update_child_status(conn-sbh, SERVER_BUSY_LOG, r);
ap_run_log_transaction(r);
@@ -943,8 +942,6 @@
}
}
-ap_add_input_filter_handle(ap_http_input_filter_handle,
- NULL, r, r-connection);
return r;
}
Regards
Rüdiger
add_input_filter.diff
Description: add_input_filter.diff
modules/aaa/mod_authz_owner.c
Hi,
On ReliantUnix the following code can't be compiled:
+++
typedef struct {
} authz_owner_config_rec;
+++
Because the structure is empty.
Any problem to apply the following patch:
+++
Index: aaa/mod_authz_owner.c
===
--- aaa/mod_authz_owner.c (revision 370359)
+++ aaa/mod_authz_owner.c (working copy)
@@ -29,14 +29,13 @@
#include mod_auth.h /* for AUTHZ_GROUP_NOTE */
-typedef struct {
-} authz_owner_config_rec;
+typedef struct authz_owner_config_rec_struct *authz_owner_config_rec_ptr;
APR_DECLARE_OPTIONAL_FN(char*, authz_owner_get_file_group, (request_rec
*r));
static void *create_authz_owner_dir_config(apr_pool_t *p, char *d)
{
-authz_owner_config_rec *conf = apr_palloc(p, sizeof(*conf));
+authz_owner_config_rec_ptr conf = apr_palloc(p, sizeof(conf));
return conf;
}
+++
Cheers
Jean-Frederic
Re: Header Handling in mod_smtpd
Hi, * Rian Hunter [EMAIL PROTECTED] [2006-01-17 16:43:07]: I just wanted to poll dev on how mod_smtpd should handle mail headers after receiving the data command. [snip] Does it seem like a good idea to save the extra line-break as the beginning of the body or remove it before letting the plugins deal with the body. Keep in mind that the reason it is like this now is to keep the loop simple so it can also handle header-less messages (the parser eats the bad data). Thanks! The empty line is part of the mail general structure, used to split the headers from the mail body. If you stick to this definition, the mail body does not include this line. IMHO, mod_smtpd should not save it and eventually put it back if it has to join the headers and the body together later. My 2 ¢, - Sam -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message. signature.asc Description: Digital signature
Re: Thread-only execution with Apache 2 : Newbie query
On 1/19/06, Praveen Bhaniramka [EMAIL PROTECTED] wrote: Hi all, We are developing a custom module for Apache using mod_gsoap over Linux. However, our software currently does not work very well in a multi-process environment as it was designed primarily for a multi-threaded environment. Is there a way to configure Apache such that it uses threads only instead of using processes for handling HTTP requests? I looked at the Apache documentation and it seems that the default MPM modules, prefork and worker, use processes by default. The worker module seems to allow both models of execution. Is it possible to configure it to use threads only? Thanks for any useful pointers. Yes, worker should be able to do this, although it will not adjust to load (you need to prespecify exactly how many threads will be available at all times). Something like: ServerLimit 1 StartServer 1 MaxClients 512 ThreadsPerChild 512 MaxSpareThreads 512 MinSpareThreads 0 Joshua.
Problem: compiling mod_tidy with Apache 2.2
Hi!
I am the project maintainer of the Apache2 module mod_tidy
(http://mod-tidy.sourceforge.net/), and there seems to be a problem
compiling mod_tidy with Apache 2.2, because API has changed from
Apache2.0 to Apache2.2:
Compiler error messages:
--
src/mod_tidy.c: In function 'mod_tidy_filter':
src/mod_tidy.c:189: warning: implicit declaration of function
'APR_BRIGADE_FOREACH'
src/mod_tidy.c:189: error: expected ';' before '{' token
src/mod_tidy.c:154: warning: unused variable 'r'
apxs:Error: Command failed with rc=65536
--
APR_BRIGADE_FOREACH does not longer exist, so there must be a short fix
reflecting this.
I have a short patch here, which compiles well under apache2.0.55 and
which lets to a functionable binary under Linux (OpenSuse), but I have
no possibility yet to check, if it also compiles and works with apache2.2.
For convenience, I have attached the little patch as a Unix diff to this email.
The source tarball of mod_tidy is available on:
http://mod-tidy.sourceforge.net/src/
Is here anybody, who can help and have a look into the source and the
patch or propose a better patch to solve the problem?
Thanks in advance,
Sierk Bornemann
Sierk Bornemann | Hannover | Germany
e-mail: [EMAIL PROTECTED]
URL: http://sierkbornemann.de/ 38,39c38,39
$Date: 2006-01-12 22:47:25 +0100 (Thu, 12 Jan 2006) $
$Revision: 96 $
---
$Date: 2006-01-17 20:51:26 +0100 (Tue, 17 Jan 2006) $
$Revision: 106 $
47a48
#include apr_version.h
189c190,197
APR_BRIGADE_FOREACH(e, bb) {
---
#if APR_MAJOR_VERSION
for (e = APR_BRIGADE_FIRST(bb);
e != APR_BRIGADE_SENTINEL(bb);
e = APR_BUCKET_NEXT(e))
#else
APR_BRIGADE_FOREACH(e, bb)
#endif
{
310c318
meta name=\revision\ content=\$Id:
mod_tidy.c 96 2006-01-12 21:47:25Z bornemann $\/\n
---
meta name=\revision\ content=\$Id:
mod_tidy.c 106 2006-01-17 19:51:26Z bornemann $\/\n
605c613
$Date: 2006-01-12 22:47:25 +0100 (Thu,
12 Jan 2006) $\n
---
$Date: 2006-01-17 20:51:26 +0100 (Tue,
17 Jan 2006) $\n
Re: please set up a mod_python core group
Mike Looijmans wrote: Seriously, I think Grisha's way is right - the three musketeers should decide based on the feedback they get. There's no substitute for running on other people's machines... 2006/1/19, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]: Thanks Roy. Very timely, since 3.2.6 is (so far) going to be a final/stable release. I propose that for starters those people are: me (I'm also in the Apache HTTP Server PMC) Jim Gallacher Nicolas Lehuen Graham Dumpleton +1 here, but since the build process and typical MPM differs among platforms, could we see a list that this group represents? I'm most interested in default nonvirtualized environments used in production or for principal development. This information will be useful when reviewing release candidates, to make sure we haven't overlooked any key platforms. IOW, could you guys list the OS on which you run, and not merely test, mod_python?
AW: Problem: compiling mod_tidy with Apache 2.2
-Ursprüngliche Nachricht- Von: Sierk Bornemann [..cut..] -- APR_BRIGADE_FOREACH does not longer exist, so there must be a short fix reflecting this. The macro APR_BRIGADE_FOREACH is marked deprecated in apr-util 0.9.x which is used by Apache 2.0.x for quite a long time (3.5 years, see http://svn.apache.org/viewcvs.cgi?rev=58680view=rev) Thus it is not contained in apr-util 1.2.2 which is used by Apache httpd 2.2.0. So please use different code to iterate over a brigade as shown in the comments above the definition of APR_BRIGADE_FOREACH in apr-util 0.9.x. Regards Rüdiger [..cut..]
Re: please set up a mod_python core group
Building + unit testing : * mod_python on Windows 2000 Server SP4 + ActivePython 2.3.5 + Apache 2.0.55 * mod_python on Windows XP SP2 + ActivePython 2.4.2 + Apache 2.0.55 Developing (mod_python itself + my own applications): * mod_python on Windows XP SP2 + ActivePython 2.4.2 + Apache 2.0.55 Production servers : * mod_python on Windows 2000 Server SP4 + ActivePython 2.4.1 + Apache 2.0.55 Yes that's a weird production setting but : 1) I need MS SQL Server 2000 and its nice cheap OLAP extensions. 2) I love Python 3) I still have to maintain some applications running under PHP 4) I need to have a single server which handles PHP, SVN and mod_python so Apache is a must, I cannot use IIS Regards, Nicolas I'm using mod_python for Python 2.4 on Windows XP for developement, and on Win 2006/1/19, Jorey Bump [EMAIL PROTECTED]: Mike Looijmans wrote: Seriously, I think Grisha's way is right - the three musketeers should decide based on the feedback they get. There's no substitute for running on other people's machines... 2006/1/19, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]: Thanks Roy. Very timely, since 3.2.6 is (so far) going to be a final/stable release. I propose that for starters those people are: me (I'm also in the Apache HTTP Server PMC) Jim Gallacher Nicolas Lehuen Graham Dumpleton +1 here, but since the build process and typical MPM differs among platforms, could we see a list that this group represents? I'm most interested in default nonvirtualized environments used in production or for principal development. This information will be useful when reviewing release candidates, to make sure we haven't overlooked any key platforms. IOW, could you guys list the OS on which you run, and not merely test, mod_python?
RE: Thread-only execution with Apache 2 : Newbie query
Hi Joshua, Thanks for your reply. I tried setting the parameters suggested by you. But when I re-run httpd2, I see that it is still creating 3 processes. Yes, worker should be able to do this, although it will not adjust to load (you need to prespecify exactly how many threads will be available at all times). Something like: ServerLimit 1 StartServer 1 MaxClients 512 ThreadsPerChild 512 MaxSpareThreads 512 MinSpareThreads 0 mangal ~ - ps -ef | grep httpd root 15588 1 1 21:04 ?00:00:00 httpd2 -k restart wwwrun 15589 15588 0 21:04 ?00:00:00 httpd2 -k restart wwwrun 15590 15588 0 21:04 ?00:00:00 httpd2 -k restart My server-tuning.conf file looks like the following - # worker MPM IfModule worker.c ServerLimit 1 # initial number of server processes to start StartServers 1 # minimum number of worker threads which are kept spare MinSpareThreads 25 # maximum number of worker threads which are kept spare MaxSpareThreads 75 # maximum number of simultaneous client connections MaxClients 25 # constant number of worker threads in each server process ThreadsPerChild 25 # maximum number of requests a server process serves MaxRequestsPerChild 0 /IfModule Any idea what might be going on? - Praveen
Re: httpd and locales
* Garrett Rooney [EMAIL PROTECTED] wrote: It doesn't belong here, but... I'm wondering why the path isn't passed as UTF-8. Why is it translated to the locale at all? It's all happening within the svn file system, so I'd really expect to get utf-8 and would consider locale translation as a bug. Well, I imagine that the assumption is that any hook script is going to be using the actual locale specified in LANG/LC_ALL/etc env variables, so if we don't translate to that locale it'll get rather confused by utf8 data in its command line. As a general rule svn translates from native - utf8 on input and from utf8 - native for output. Ironically, if the LANG/LC_ALL/etc env vars were being followed by httpd this translation would be a noop, since the system uses a utf8 locale... So whether the users of a repository (httpd or svnserve) may use the full unicode range for their files depends on the locale of the server? That feels just wrong ;-) I don't see how there are command line confusings... As long as one references files enclosed in the filesystem no translation should occur at all. It's just unicode (in utf-8 format). The only part of the subversion system which should deal with filename recodings of reposiory stored path should be a client. But as said, this doesn't belong here. nd
Re: Problem: compiling mod_tidy with Apache 2.2
Compiling on Windows and Apache 2.2.0 works with the patch.
Steffen
http://www.apachelounge.com
- Original Message -
From: Sierk Bornemann [EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Thursday, January 19, 2006 3:28 PM
Subject: Problem: compiling mod_tidy with Apache 2.2
Hi!
I am the project maintainer of the Apache2 module mod_tidy
(http://mod-tidy.sourceforge.net/), and there seems to be a problem
compiling mod_tidy with Apache 2.2, because API has changed from
Apache2.0 to Apache2.2:
Compiler error messages:
--
src/mod_tidy.c: In function 'mod_tidy_filter':
src/mod_tidy.c:189: warning: implicit declaration of function
'APR_BRIGADE_FOREACH'
src/mod_tidy.c:189: error: expected ';' before '{' token
src/mod_tidy.c:154: warning: unused variable 'r'
apxs:Error: Command failed with rc=65536
--
APR_BRIGADE_FOREACH does not longer exist, so there must be a short fix
reflecting this.
I have a short patch here, which compiles well under apache2.0.55 and
which lets to a functionable binary under Linux (OpenSuse), but I have
no possibility yet to check, if it also compiles and works with apache2.2.
For convenience, I have attached the little patch as a Unix diff to this
email.
The source tarball of mod_tidy is available on:
http://mod-tidy.sourceforge.net/src/
Is here anybody, who can help and have a look into the source and the
patch or propose a better patch to solve the problem?
Thanks in advance,
Sierk Bornemann
Sierk Bornemann | Hannover | Germany
e-mail: [EMAIL PROTECTED]
URL: http://sierkbornemann.de/
38,39c38,39
$Date: 2006-01-12 22:47:25 +0100 (Thu, 12 Jan 2006) $
$Revision: 96 $
---
$Date: 2006-01-17 20:51:26 +0100 (Tue, 17 Jan 2006) $
$Revision: 106 $
47a48
#include apr_version.h
189c190,197
APR_BRIGADE_FOREACH(e, bb) {
---
#if APR_MAJOR_VERSION
for (e = APR_BRIGADE_FIRST(bb);
e != APR_BRIGADE_SENTINEL(bb);
e = APR_BUCKET_NEXT(e))
#else
APR_BRIGADE_FOREACH(e, bb)
#endif
{
310c318
meta name=\revision\ content=\$Id: mod_tidy.c 96 2006-01-12
21:47:25Z bornemann $\/\n
---
meta name=\revision\ content=\$Id: mod_tidy.c 106 2006-01-17
19:51:26Z bornemann $\/\n
605c613
$Date: 2006-01-12 22:47:25 +0100 (Thu, 12 Jan 2006) $\n
---
$Date: 2006-01-17 20:51:26 +0100 (Tue, 17 Jan 2006) $\n
Re: Problem: compiling mod_tidy with Apache 2.2
torsdagen den 19 januari 2006 16.59 skrev Steffen:
Compiling on Windows and Apache 2.2.0 works with the patch.
Steffen
http://www.apachelounge.com
- Original Message -
From: Sierk Bornemann [EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Thursday, January 19, 2006 3:28 PM
Subject: Problem: compiling mod_tidy with Apache 2.2
Hi!
I am the project maintainer of the Apache2 module mod_tidy
(http://mod-tidy.sourceforge.net/), and there seems to be a problem
compiling mod_tidy with Apache 2.2, because API has changed from
Apache2.0 to Apache2.2:
Compiler error messages:
--
src/mod_tidy.c: In function 'mod_tidy_filter':
src/mod_tidy.c:189: warning: implicit declaration of function
'APR_BRIGADE_FOREACH'
src/mod_tidy.c:189: error: expected ';' before '{' token
src/mod_tidy.c:154: warning: unused variable 'r'
apxs:Error: Command failed with rc=65536
--
APR_BRIGADE_FOREACH does not longer exist, so there must be a short fix
reflecting this.
I have a short patch here, which compiles well under apache2.0.55 and
which lets to a functionable binary under Linux (OpenSuse), but I have
no possibility yet to check, if it also compiles and works with
apache2.2.
For convenience, I have attached the little patch as a Unix diff to this
email.
The source tarball of mod_tidy is available on:
http://mod-tidy.sourceforge.net/src/
Is here anybody, who can help and have a look into the source and the
patch or propose a better patch to solve the problem?
Looks similar to my hack in Mandriva.
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://li.nux.se
--- src/mod_tidy.c 2005-11-11 01:47:57.0 +0100
+++ src/mod_tidy.c.oden 2005-12-16 02:33:27.0 +0100
@@ -186,7 +186,9 @@
cfg-tidyoptions, NULL );
}
-APR_BRIGADE_FOREACH(e, bb) {
+for (e = APR_BRIGADE_FIRST(bb);
+ e != APR_BRIGADE_SENTINEL(bb);
+ e = APR_BUCKET_NEXT(e)) {
const char *str;
apr_size_t len;
Re: please set up a mod_python core group
Jorey Bump wrote: Jim Gallacher wrote: Jorey Bump wrote: IOW, could you guys list the OS on which you run, and not merely test, mod_python? By you guys I assume you mean the above 4 people? Yeah, youse 4 guys. :) On the other hand, you may mean *all* the people on python-dev who test a release candidate should list their production platform. This would be useful to the core group as another data point in deciding on casting a binding vote to proceed to release. No, I'm just interested in the core group. Everyone else gets an opportunity to list platforms when testing new releases, in pass/fail feedback responses. Your point on making sure we don't overlook any key platforms in our testing is a good one. Should we (python-dev people) put together a list of key platforms as a future guide? It's likely a good idea, even at the risk of a flamewar. ;) I thought I'd put together a summary of 3.2.6 test results in the next few days anyway, which should be a good starting point for the key list. A small checklist might be useful, such as Windows/Mac/Linux/UNIX/BSD. This has been handled fairly well in the past, but that might be due to luck. I'm concerned that some last minute fix will be checked into a stable release candidate without sufficient cross-platform testing. I mainly use Python in UNIX-like environments, and I forget how popular it is on Windows (the same goes for Apache). Between the 4 I think we good coverage of your checklist, except for the non-BSD Unix category. This is one where we really need to depend on those in our community to help out with the testing, which of course they do. Ideally, it would be nice to solicit feedback from package maintainers. I asked a few months ago if there were any package maintainers monitoring this list but there was no response. At the time I wondered if *we* should make contact with the downstream maintainers but others here felt that was not our job (IIRC). I use Slackware, which doesn't include Apache 2 or mod_python, so I can tell immediately how it's going to perform in my production systems. Users of stock Red Hat, Debian, SUSE, Mandriva, FreeBSD, Mac, etc. can't be so sure. The package maintainers are in the best position to flag potential problems. But this is an issue shared by many open source projects, and we'll need to be satisfied with the participation we get, and try our best to create a stable release. For whatever reason mod_python issues get logged in the various the distribution's bug tracking systems but never propagate upstream. Perhaps people here that have an interest in a particular platform could get in the habit of occasionally checking these other bug trackers for mod_python issues and alert the python-dev list? Or maybe we could have tracking the bug trackers day. Once every couple of months we'd declare a bug tracking day and everyone here could run around looking for trouble on the other bug trackers? Jim
Re: modules/aaa/mod_authz_owner.c
On 1/19/2006 at 6:46:25 am, in message
[EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Hi,
On ReliantUnix the following code can't be compiled:
+++
typedef struct {
} authz_owner_config_rec;
+++
Because the structure is empty.
Any problem to apply the following patch:
+++
Index: aaa/mod_authz_owner.c
===
--- aaa/mod_authz_owner.c (revision 370359)
+++ aaa/mod_authz_owner.c (working copy)
@@ -29,14 +29,13 @@
#include mod_auth.h /* for AUTHZ_GROUP_NOTE */
-typedef struct {
-} authz_owner_config_rec;
+typedef struct authz_owner_config_rec_struct
*authz_owner_config_rec_ptr;
APR_DECLARE_OPTIONAL_FN(char*, authz_owner_get_file_group,
(request_rec
*r));
static void *create_authz_owner_dir_config(apr_pool_t *p, char *d)
{
-authz_owner_config_rec *conf = apr_palloc(p, sizeof(*conf));
+authz_owner_config_rec_ptr conf = apr_palloc(p, sizeof(conf));
return conf;
}
+++
Cheers
Jean-Frederi
It should probably just be removed since it is no longer needed. After
the refactoring there was no need to store any per-dir-config
information so the structure was just left empty. I will be committing
a patch soon.
Brad
Re: Thread-only execution with Apache 2 : Newbie query
On 1/19/06, Praveen Bhaniramka [EMAIL PROTECTED] wrote: Hi Joshua, Thanks for your reply. I tried setting the parameters suggested by you. But when I re-run httpd2, I see that it is still creating 3 processes. Three processes is normal. One is the control process, one is the cgi daemon and one is the main server process. Only the latter should be serving requests. Joshua.
apache 2.0 module code clean-up
hey guys, I have this module which runs from within apache2.0 and at times it results in segmentation faults. how should I approach cleaning up this code (which spans multiple files) of all the null pointer issues. is there some tool that could show me where the problem is at ? I am aware of mod_log_forensic but i cant use it since on the production server i need to use the live logs and cant play around with them. Thanks in advance.
Re: apache 2.0 module code clean-up
Hi Kaushal, Stuff like this is probably better discussed on the apache-modules list. You can subscribe to that at: http://modules.apache.org/subscribe On Jan 19, 2006, at 9:08 AM, Kaushal Jha wrote: how should I approach cleaning up this code (which spans multiple files) of all the null pointer issues. is there some tool that could show me where the problem is at ? The best tool to use is probably gdb in combination with core dumps. How to make Apache dump core on segmentation faults is different for every opereating system. It looks like the information on http:// httpd.apache.org/dev/debugging.html is somewhat specific to Solaris, we should probably include some tips about Linux and other operating systems as well. On Linux: 1) Make sure to run ulimit -c unlimited from the shell that is going to start Apache. You can hack this into the apachectl script or the rc?.d startup script for your server. 2) Add the directive: CoredumpDirectory /somewhere to your httpd.conf. The location (/somewhere) needs to be a directory that the httpd child processes can write to, so it must be writable by the user name specified in the User directive (or by everyone, but that's up to you). The disk partition that holds this directory must also have enough space to store all the core images you expect to receive. You can analyze the core images by running $ gdb /path/to/httpd -core /somewhere/yourcore I can't go into details on how to use gdb (the bt command should cover most of your needs), but there is ample literature about that. To use gdb, it's probably a good idea to compile Apache with debugging symbols. You can do this by specifying $ CFLAGS=-DDEBUG -g -O0 ./configure ... when you start the build process. Good luck! S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: apache 2.0 module code clean-up
apologies. and thanks for the correct direction. :) -- -- Original Message --- From: Sander Temme [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thu, 19 Jan 2006 09:38:15 -0800 Subject: Re: apache 2.0 module code clean-up Hi Kaushal, Stuff like this is probably better discussed on the apache-modules list. You can subscribe to that at: http://modules.apache.org/subscribe On Jan 19, 2006, at 9:08 AM, Kaushal Jha wrote: how should I approach cleaning up this code (which spans multiple files) of all the null pointer issues. is there some tool that could show me where the problem is at ? The best tool to use is probably gdb in combination with core dumps. How to make Apache dump core on segmentation faults is different for every opereating system. It looks like the information on http:// httpd.apache.org/dev/debugging.html is somewhat specific to Solaris, we should probably include some tips about Linux and other operating systems as well. On Linux: 1) Make sure to run ulimit -c unlimited from the shell that is going to start Apache. You can hack this into the apachectl script or the rc?.d startup script for your server. 2) Add the directive: CoredumpDirectory /somewhere to your httpd.conf. The location (/somewhere) needs to be a directory that the httpd child processes can write to, so it must be writable by the user name specified in the User directive (or by everyone, but that's up to you). The disk partition that holds this directory must also have enough space to store all the core images you expect to receive. You can analyze the core images by running $ gdb /path/to/httpd -core /somewhere/yourcore I can't go into details on how to use gdb (the bt command should cover most of your needs), but there is ample literature about that. To use gdb, it's probably a good idea to compile Apache with debugging symbols. You can do this by specifying $ CFLAGS=-DDEBUG -g -O0 ./configure ... when you start the build process. Good luck! S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF --- End of Original Message ---
Re: apache 2.0 module code clean-up
apologies. and thanks for taking the time to direct me to the correct list. :) -- -- Original Message --- From: Sander Temme [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thu, 19 Jan 2006 09:38:15 -0800 Subject: Re: apache 2.0 module code clean-up Hi Kaushal, Stuff like this is probably better discussed on the apache-modules list. You can subscribe to that at: http://modules.apache.org/subscribe On Jan 19, 2006, at 9:08 AM, Kaushal Jha wrote: how should I approach cleaning up this code (which spans multiple files) of all the null pointer issues. is there some tool that could show me where the problem is at ? The best tool to use is probably gdb in combination with core dumps. How to make Apache dump core on segmentation faults is different for every opereating system. It looks like the information on http:// httpd.apache.org/dev/debugging.html is somewhat specific to Solaris, we should probably include some tips about Linux and other operating systems as well. On Linux: 1) Make sure to run ulimit -c unlimited from the shell that is going to start Apache. You can hack this into the apachectl script or the rc?.d startup script for your server. 2) Add the directive: CoredumpDirectory /somewhere to your httpd.conf. The location (/somewhere) needs to be a directory that the httpd child processes can write to, so it must be writable by the user name specified in the User directive (or by everyone, but that's up to you). The disk partition that holds this directory must also have enough space to store all the core images you expect to receive. You can analyze the core images by running $ gdb /path/to/httpd -core /somewhere/yourcore I can't go into details on how to use gdb (the bt command should cover most of your needs), but there is ample literature about that. To use gdb, it's probably a good idea to compile Apache with debugging symbols. You can do this by specifying $ CFLAGS=-DDEBUG -g -O0 ./configure ... when you start the build process. Good luck! S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF --- End of Original Message ---
Re: httpd and locales
André Malo wrote: * Garrett Rooney [EMAIL PROTECTED] wrote: It doesn't belong here, but... I'm wondering why the path isn't passed as UTF-8. Why is it translated to the locale at all? It's all happening within the svn file system, so I'd really expect to get utf-8 and would consider locale translation as a bug. Well, I imagine that the assumption is that any hook script is going to be using the actual locale specified in LANG/LC_ALL/etc env variables, so if we don't translate to that locale it'll get rather confused by utf8 data in its command line. As a general rule svn translates from native - utf8 on input and from utf8 - native for output. Ironically, if the LANG/LC_ALL/etc env vars were being followed by httpd this translation would be a noop, since the system uses a utf8 locale... So whether the users of a repository (httpd or svnserve) may use the full unicode range for their files depends on the locale of the server? That feels just wrong ;-) I don't see how there are command line confusings... You're confusing the content of the SVN repository and hook scripts stored on the local filesystem. Paths in the first are always encoded in UTF-8. The latter naturally have to obey the server's locale. -- Brane
Re: httpd and locales
* Branko Čibej wrote: You're confusing the content of the SVN repository and hook scripts stored on the local filesystem. Paths in the first are always encoded in UTF-8. The latter naturally have to obey the server's locale. I don't think so. The task was to pass the name of a file stored in the repository to a hook script via the command line. Otherwise I must have misunderstood something quite heavily. nd -- Das einzige, das einen Gebäudekollaps (oder auch einen thermonuklearen Krieg) unbeschadet übersteht, sind Kakerlaken und AOL-CDs. -- Bastian Lipp in dcsm
Re: httpd and locales
On 1/19/06, André Malo [EMAIL PROTECTED] wrote: * Branko Čibej wrote: You're confusing the content of the SVN repository and hook scripts stored on the local filesystem. Paths in the first are always encoded in UTF-8. The latter naturally have to obey the server's locale. I don't think so. The task was to pass the name of a file stored in the repository to a hook script via the command line. Otherwise I must have misunderstood something quite heavily. That is correct, it's an argument to the hook script that happens to contain the path of a file in the repository. Currently all arguments are transcoded from utf8 to native before we execute the hook script. -garrett
Re: httpd and locales
On Thu, Jan 19, 2006 at 11:09:13AM -0800, Garrett Rooney wrote: On 1/19/06, André Malo [EMAIL PROTECTED] wrote: * Branko Čibej wrote: You're confusing the content of the SVN repository and hook scripts stored on the local filesystem. Paths in the first are always encoded in UTF-8. The latter naturally have to obey the server's locale. I don't think so. The task was to pass the name of a file stored in the repository to a hook script via the command line. Otherwise I must have misunderstood something quite heavily. That is correct, it's an argument to the hook script that happens to contain the path of a file in the repository. Currently all arguments are transcoded from utf8 to native before we execute the hook script. I really don't think that relying on that working properly is a good idea. All it takes is for one rogue PHP script to set the locale to some odd locale to be able to print currency symbols properly or whatever, and the hook scripts would start behaving really strangely. As a module author, presuming the locale is undefined is the safest bet, and as an adminstrator, starting the server in the C locale is the safest bet. joe
Re: AW: PR#38123
On Thursday 19 January 2006 11:03, Plüm, Rüdiger, VIS wrote: -Ursprüngliche Nachricht- Von: Nick Kew [..cut..] That's the same bug and fix as PR#37790! Which leads me to wonder, is there some good reason not to insert the input filter unconditionally somewhere earlier in request_post_read? As it stands, it looks as if your fix has the same problem as mine: namely, it fixes the immediate problem but leaves the bug waiting to manifest itself anew in other early error conditions. What about the following patch instead (currently untested)? That's just about what I had in mind. But I'd hesitate to use it without knowing whether someone had a reason for putting it at the end of the function originally. It would affect the semantics of post_read_request, but is that fixing a bug or damaging a feature? Anyone recollect the origins of that code? -- Nick Kew
