[PATCH] mod_status: s/%c/'%c'/ in table
Rationale: allow me to search in my browser for 'W' (with quotes) to
find entries in the W state.
Patch (against trunk):
[[[
Index: modules/generators/mod_status.c
===
--- modules/generators/mod_status.c (revision 1161295)
+++ modules/generators/mod_status.c (working copy)
@@ -765,40 +765,40 @@
switch (ws_record->status) {
case SERVER_READY:
-ap_rputs("_", r);
+ap_rputs("'_'", r);
break;
case SERVER_STARTING:
-ap_rputs("S", r);
+ap_rputs("'S'", r);
break;
case SERVER_BUSY_READ:
-ap_rputs("R", r);
+ap_rputs("'R'", r);
break;
case SERVER_BUSY_WRITE:
-ap_rputs("W", r);
+ap_rputs("'W'", r);
break;
case SERVER_BUSY_KEEPALIVE:
-ap_rputs("K", r);
+ap_rputs("'K'", r);
break;
case SERVER_BUSY_LOG:
-ap_rputs("L", r);
+ap_rputs("'L'", r);
break;
case SERVER_BUSY_DNS:
-ap_rputs("D", r);
+ap_rputs("'D'", r);
break;
case SERVER_CLOSING:
-ap_rputs("C", r);
+ap_rputs("'C'", r);
break;
case SERVER_DEAD:
-ap_rputs(".", r);
+ap_rputs("'.'", r);
break;
case SERVER_GRACEFUL:
-ap_rputs("G", r);
+ap_rputs("'G'", r);
break;
case SERVER_IDLE_KILL:
-ap_rputs("I", r);
+ap_rputs("'I'", r);
break;
default:
-ap_rputs("?", r);
+ap_rputs("'?'", r);
break;
}
]]]
I'll send in a formal bug report if it helps, but hoped that for a trivial
patch the registration/filing overhead could be spared.
Re: www.apache.org upgraded to 2.3.15-dev-r116760
Paul Querna wrote on Sun, Sep 11, 2011 at 12:10:53 -0700: > Infra has upgraded eos, aka the main webserver for *.apache.org to > 2.3.15-dev-r1167603 We observe processes whose memory, in trend, grows over time up to 2.8GB and more, for example: http://www.apache.org/eos/mem.txt
Re: www.apache.org upgraded to 2.3.15-dev-r116760
Stefan Fritsch wrote on Sat, Oct 15, 2011 at 23:58:18 +0200: > On Tuesday 11 October 2011, Stefan Fritsch wrote: > > Can you try setting MaxMemFree, maybe to 4000? > > Actually, since you use FreeBSD and FreeBSD has an efficient malloc, > you can try something a lot lower, like 400 or even 1. Thanks for following up. Sorry for going silent after my last mail; I'm not particularly familiar with httpd configuration, and found the discussion inconclusive when I considered the IRC input as well as the list's. I'll ping people again and see if I can reach an actionable conclusion. Thanks, Daniel
Re: www.apache.org upgraded to 2.3.15-dev-r116760
[ Sorry again for the delayed reply. ] Stefan Fritsch wrote on Tue, Oct 11, 2011 at 21:35:08 +0200: > On Tuesday 11 October 2011, Jim Jagielski wrote: > > On Oct 11, 2011, at 3:01 PM, Jim Jagielski wrote: > > > On Oct 11, 2011, at 2:09 PM, Daniel Shahaf wrote: > > >> Paul Querna wrote on Sun, Sep 11, 2011 at 12:10:53 -0700: > > >>> Infra has upgraded eos, aka the main webserver for *.apache.org > > >>> to 2.3.15-dev-r1167603 > > >> > > >> We observe processes whose memory, in trend, grows over time up > > >> to 2.8GB and more, for example: > > >> > > >> http://www.apache.org/eos/mem.txt > > > > > > which mom? > > > > mpm even :) > > mpm event: http://www.apache.org/server-status > At least I assume that's eos. > Yes. eos.apache.org == 140.211.11.131 > Is this a new problem since you upgraded? > I'm told that it's not a new problem. > > I think the problem may be the combination of > - by default, httpd never gives memory back to the OS > - mpm event creates transaction pool with a separate allocator for > every connection > - by default, it never destroys transaction pools ... > Can you try setting MaxMemFree, maybe to 4000? This will limit the > maximum free memory kept in each allocator to 4000K. It will also > cause mpm event to destroy transaction pools if more than 128 * 0.75 > == 96 are unused, but I am not sure that will make a difference if the > load is more or less constant. > Thanks for your reply. Besides the theory you suggest above, #asfinfra residents suggested to isolate mod_mbox. I started by testing that theory (sorry, it does exist even though it wasn't on-list). I changed mail-archives.apache.org DNS entry to point at aurora (in Amsterdam) rather than eos (in OSUOSL). Halfway through the one hour DNS propagation period a graceful restart was done. Looking at top now (after DNS finished propagating), the memory use is at around 650MB and at no point exceeded 750MB (in manual spot checks, not yet in a scripted every-5-seconds check; I'll do that later). By comparison, before the DNS change and the graceful, I saw two processes at 2GB+, and in an unscientific glimpse it did seem to be growing. So, this is preliminary data that appears to corroborate the mod_mbox theory. It does not rule out the allocators theory, and I plan to collect more data in the current configuration to see if the processes continue to behave. > > Cheers, > Stefan Thanks, Daniel
Re: www.apache.org upgraded to 2.3.15-dev-r116760
sebb wrote on Sun, Oct 16, 2011 at 02:39:42 +0100: > https://issues.apache.org/bugzilla/show_bug.cgi?id=51951 > > Certain mails cause mod_mbox to hang; maybe it is chewing on memory. Does that issue still reproduce now that I've cut mail-archives.a.o over to aurora (which runs a different httpd)?
mod_mbox issue 51951 Re: www.apache.org upgraded to 2.3.15-dev-r116760
sebb wrote on Sun, Oct 16, 2011 at 12:45:26 +0100: > On 16 October 2011 12:24, sebb wrote: > > On 16 October 2011 06:44, Daniel Shahaf wrote: > >> sebb wrote on Sun, Oct 16, 2011 at 02:39:42 +0100: > >>> https://issues.apache.org/bugzilla/show_bug.cgi?id=51951 > >>> > >>> Certain mails cause mod_mbox to hang; maybe it is chewing on memory. > >> > >> Does that issue still reproduce now that I've cut mail-archives.a.o over > >> to aurora (which runs a different httpd)? > > > > Yes, the Sep 29th mails from press@ don't display in Firefox. > > > > However, I just tried one of the same mails in Chrome, and it reports > > an encoding error. > > Sorry, that was a different mail from ooo-private. > > I need to go back and retrace my steps to be absolutely clear. > > Unfortunately, the only mails where I have noticed this are on > member-private mailing lists (press and ooo-private), which may be a > problem when posting screen-shots and contents. > > I don't know how to create a private Buzilla issue, so should I post > the evidence to a private JIRA issue? > How about uploading the evidence to a member-only https location? You could put them on http://people.apache.org/~sebb/ with a .htaccess password, and put the password in a sebb:member 0640 file.
Re: www.apache.org upgraded to 2.3.15-dev-r116760
Stefan Fritsch wrote on Sun, Oct 16, 2011 at 16:25:28 +0200: > On Sun, 16 Oct 2011, Daniel Shahaf wrote: > > >sebb wrote on Sun, Oct 16, 2011 at 02:39:42 +0100: > >>https://issues.apache.org/bugzilla/show_bug.cgi?id=51951 > >> > >>Certain mails cause mod_mbox to hang; maybe it is chewing on memory. > > There was one obvious memory leak in mod_mbox. It's only a few bytes > per message displayed, but maybe it adds up. The fix is here > (compiles, but otherwise untested): > > http://svn.apache.org/viewvc/httpd/mod_mbox/trunk/module-2.0/mod_mbox_mime.c?r1=1184831&r2=1184830&pathrev=1184831 I gathered some stats on Mon/Tue when mail-archives.a.o traffic was routed entirely to aurora.a.o (our EU mirror). This morning I installed current HEAD mod_mbox on eos, after flipping the DNS back yesterday, and graceful'd the server. Right now I see httpd processes with around 3GB memory in top, whereas in three different 'while sleep 5 && $i++ < 5000' samples taken prior to flipping the DNS I see exactly one process having exceeded 1600MB memory (to 1613MB). I'm not aware of differences other than flipping the DNS and upgrading the mod_mbox version to include the last week's fixes.
[PATCH] mod_mbox: show list name in the
Henri Yandell (Created) (JIRA) wrote on Wed, Dec 21, 2011 at 06:03:30 +:
> Note list name on mail detail page
> --
>
> Key: INFRA-4238
> URL: https://issues.apache.org/jira/browse/INFRA-4238
> Project: Infrastructure
> Issue Type: Improvement
> Security Level: public (Regular issues)
> Reporter: Henri Yandell
> Priority: Minor
>
>
> Looking at
> http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/201112.mbox/%3ca603ffce-623b-43e9-87f8-39baa51c7...@gbiv.com%3E
> - it would be nice to know what mailing list the email is to in the
> UI. Currently you have to infer it from links or the url.
>
> Having it as some kind of title would be good. Possibly it could
> replace the 'list index' text for the link to the emails for that
> mailing list.
>
[[[
Tweak title in the message display screen, for INFRA-4238.
Patch by: danielsh
* module-2.0/mod_mbox_out.c
(mbox_ajax_browser, mbox_static_browser):
Include the directory's basename in the title.
]]]
[[[
Index: module-2.0/mod_mbox_out.c
===
--- module-2.0/mod_mbox_out.c (revision 1188408)
+++ module-2.0/mod_mbox_out.c (working copy)
@@ -17,6 +17,8 @@
/* This file contains all output functions.
*/
+#include /* basename() */
+
#include "mod_mbox.h"
#ifdef APLOG_USE_MODULE
@@ -886,9 +888,11 @@ apr_status_t mbox_ajax_browser(request_rec *r)
{
mbox_dir_cfg_t *conf;
char *baseURI;
+const char *base_path;
conf = ap_get_module_config(r->per_dir_config, &mbox_module);
baseURI = get_base_uri(r);
+base_path = get_base_path(r);
ap_set_content_type(r, "text/html; charset=utf-8");
@@ -920,7 +924,8 @@ apr_status_t mbox_ajax_browser(request_rec *r)
ap_rprintf(r,
" \n",
baseURI);
-ap_rputs(" Mailing list archives\n\n", r);
+ap_rprintf(r, " %s mailing list archives\n\n",
+ basename(base_path));
ap_rputs(" \n", r);
@@ -930,7 +935,7 @@ apr_status_t mbox_ajax_browser(request_rec *r)
}
ap_rprintf(r, ""
- "List index", get_base_path(r));
+ "List index", base_path);
/* Output a small notice if no MboxScriptPath configuration
directive was specified. */
@@ -1122,6 +1127,7 @@ int mbox_static_message(request_rec *r, apr_file_t
Message *m;
char *baseURI, *from, **context, *msgID, *escaped_msgID;
+const char *base_path = get_base_path(r);
conf = ap_get_module_config(r->per_dir_config, &mbox_module);
baseURI = get_base_uri(r);
@@ -1166,7 +1172,8 @@ int mbox_static_message(request_rec *r, apr_file_t
ap_rputs(" \n\n", r);
ap_rputs(" \n", r);
-ap_rputs(" Mailing list archives\n\n", r);
+ap_rprintf(r, " %s mailing list archives\n\n",
+ basename(base_path));
ap_rputs(" \n", r);
@@ -1176,7 +1183,7 @@ int mbox_static_message(request_rec *r, apr_file_t
}
ap_rprintf(r, ""
- "List index", get_base_path(r));
+ "List index", base_path);
/* Display context message list */
from = ESCAPE_OR_BLANK(r->pool, m->from);
]]]
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators:
> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
Re: [PATCH] mod_mbox: show list name in the
Stefan Fritsch wrote on Mon, Jan 02, 2012 at 20:07:30 +0100: > On Monday 02 January 2012, Daniel Shahaf wrote: > > Henri Yandell (Created) (JIRA) wrote on Wed, Dec 21, 2011 at > 06:03:30 +: > > > Note list name on mail detail page > > > -- > > > > > > Key: INFRA-4238 > > > URL: > > > https://issues.apache.org/jira/browse/INFRA-423 > > > 8 > > > > > > Project: Infrastructure > > > > > > Issue Type: Improvement > > > > > > Security Level: public (Regular issues) > > > > > > Reporter: Henri Yandell > > > Priority: Minor > > > > > > Looking at > > > http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/2 > > > 01112.mbox/%3ca603ffce-623b-43e9-87f8-39baa51c7...@gbiv.com%3E - > > > it would be nice to know what mailing list the email is to in > > > the UI. Currently you have to infer it from links or the url. > > > > > > Having it as some kind of title would be good. Possibly it could > > > replace the 'list index' text for the link to the emails for that > > > mailing list. > > > > [[[ > > Tweak title in the message display screen, for INFRA-4238. > > > > Patch by: danielsh > > > > * module-2.0/mod_mbox_out.c > > (mbox_ajax_browser, mbox_static_browser): > > Include the directory's basename in the title. > > ]]] > > Hi Daniel, > > I have done some work on mod_mbox last week which I have committed > now. It includes displaying the list name in and tags, > though implemented slightly differently than your patch. This and some > more code cleanup is now in trunk. This code should still work with > 2.2 > Saw the commits --- thanks. I'll deploy the code on eos and let this list know when that's done. > In the new convert-charsets branch, I have committed some work to > actually convert mail bodies, subject and from lines to UTF-8. This > should take care of a load of displaying problems with various mails. Sounds good. > I have tested it with Firefox 9, Chrome, and KDE Konqueror 4.6. > There are two caveats, though: It adds a field to the cache files. > This means that all mbox cache files need to be re-created. And it > depends on HTTPD 2.3.x functionality. > Meaning that we can't deploy it for the private mail archives yet. > It would of course be very nice if you could test the code from the > branch, but doing the re-indexing is of course more work. Maybe you > could pull some tricks with ZFS snapshots to allow for a fall-back > path. > Okay. I'll first see about installing trunk@HEAD, and later separately about giving the branch a spin too. Filed this as https://issues.apache.org/jira/browse/INFRA-4273. > Cheers, > Stefan Thanks, Daniel
Re: [jira] [Created] (INFRA-4437) Cannot create new account on modules.a.o
modules-dev@, please fix. Code is at https://svn.apache.org/repos/infra/infrastructure/trunk/projects/modules.a.o It runs on bil.zones.apache.org. There are httpd-error.log entries that seem relevant: mysql_query(): A link to the server could not be established in /usr/local/www/apache22/data/signup.php on line 62, referer: https://modules.apache.org/signup.php Thanks -- Apache Infrastructure Daniel Gruno (Created) (JIRA) wrote on Tue, Feb 14, 2012 at 19:32:00 +: > Cannot create new account on modules.a.o > > > Key: INFRA-4437 > URL: https://issues.apache.org/jira/browse/INFRA-4437 > Project: Infrastructure > Issue Type: Bug > Security Level: public (Regular issues) > Components: Website > Reporter: Daniel Gruno > Priority: Minor > > > I have tried four times now to create an account for dan...@gruno.dk, > and each time I get an email saying "Welcome to modules.apache.org. > etc etc", but the account never seems to be created. One would think > that if it _had_ been created, I could not create new accounts using > the same email address, so my guess is that the creation process fails > at some point, without letting me know. > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators: > https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa > For more information on JIRA, see: http://www.atlassian.com/software/jira > >
[PATCH] s/#if/#ifdef/ for AP_ENABLE_DTRACE
This patch should suppress the ~only warning I get when building svn against httpd-2.4.1: [[[ Index: include/ap_config.h === --- include/ap_config.h (revision 1291669) +++ include/ap_config.h (working copy) @@ -194,7 +194,7 @@ #define AP_NONBLOCK_WHEN_MULTI_LISTEN 1 #endif -#if AP_ENABLE_DTRACE && HAVE_SYS_SDT_H +#if defined(AP_ENABLE_DTRACE) && HAVE_SYS_SDT_H #include #else #undef _DTRACE_VERSION ]]] For refernce: [[[ % grep -R AP_ENABLE_DTRACE include/ include/ap_config.h:#if AP_ENABLE_DTRACE && HAVE_SYS_SDT_H include/ap_config_auto.h.in:#undef AP_ENABLE_DTRACE include/ap_config_auto.h:/* #undef AP_ENABLE_DTRACE */ ]]] OK to commit?
[PATCH] Eliminate warnings with C89 compilers
Subversion uses C89 by default, which doesn't defined __STDC_VERSION__. (ap_config.h accomodates that explicitly.) This causes a fair amount of warnings, which the following patch should suppress. (I'm working on the assumption that API consumers are allowed to write their code in C89.) [[[ Check that __STDC_VERSION__ is defined before using it, to accomodate pre-C99 compilers. ]]] [[[ Index: include/http_log.h === --- include/http_log.h (revision 1291669) +++ include/http_log.h (working copy) @@ -358,7 +358,7 @@ int level, apr_status_t status, const server_rec *s, const char *fmt, ...); #else -#if __STDC_VERSION__ >= 199901L +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* need additional step to expand APLOG_MARK first */ #define ap_log_error(...) ap_log_error__(__VA_ARGS__) /* need server_rec *sr = ... for the case if s is verbatim NULL */ @@ -401,7 +401,8 @@ int level, apr_status_t status, apr_pool_t *p, const char *fmt, ...); #else -#if __STDC_VERSION__ >= 199901L && defined(APLOG_MAX_LOGLEVEL) +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L \ +&& defined(APLOG_MAX_LOGLEVEL) /* need additional step to expand APLOG_MARK first */ #define ap_log_perror(...) ap_log_perror__(__VA_ARGS__) #define ap_log_perror__(file, line, mi, level, status, p, ...)\ @@ -443,7 +444,7 @@ int level, apr_status_t status, const request_rec *r, const char *fmt, ...); #else -#if __STDC_VERSION__ >= 199901L +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* need additional step to expand APLOG_MARK first */ #define ap_log_rerror(...) ap_log_rerror__(__VA_ARGS__) #define ap_log_rerror__(file, line, mi, level, status, r, ...) \ @@ -487,7 +488,7 @@ int level, apr_status_t status, const conn_rec *c, const char *fmt, ...); #else -#if __STDC_VERSION__ >= 199901L +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* need additional step to expand APLOG_MARK first */ #define ap_log_cerror(...) ap_log_cerror__(__VA_ARGS__) #define ap_log_cerror__(file, line, mi, level, status, c, ...) \ @@ -534,7 +535,7 @@ const conn_rec *c, const server_rec *s, const char *fmt, ...); #else -#if __STDC_VERSION__ >= 199901L +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* need additional step to expand APLOG_MARK first */ #define ap_log_cserror(...) ap_log_cserror__(__VA_ARGS__) #define ap_log_cserror__(file, line, mi, level, status, c, s, ...) \ ]]]
Re: [PATCH] Eliminate warnings with C89 compilers
With gcc on Debian I see this error ---
/home/daniel/prefix/apache2/include/http_log.h:361:5: warning:
"__STDC_VERSION__" is not defined
unless I force it to C99 mode.
Michael Felt wrote on Tue, Feb 21, 2012 at 18:43:34 +:
> FYI - I see no notable difference in the W messages with the IBM vacpp
> (xlc) v7 compiler using no CFLAGS and CFLAGS='-O2 -qlanglvl=extc99'
>
> "util_expr_eval.c", line 1553.7: 1506-196 (W) Initialization between types
> "const void*" and "const char*(*)(struct {...}*,const void*)" is not
> allowed.
>
> "util_expr_eval.c", line 1601.7: 1506-196 (W) Initialization between types
> "const void*" and "int(*)(struct {...}*,const void*,const char*,const
> char*)" is not allowed.
> "mod_include.c", line 721.26: 1506-068 (W) Operation between types "const
> void*" and "const char*(*)(struct {...}*,const void*,const char*)" is not
> allowed.
> "mod_headers.c", line 898.43: 1506-280 (W) Function argument assignment
> between types "const void*" and "const char*(*)(struct request_rec*,char*)"
> is not allowed.
> "util_expr_eval.c", line 1601.7: 1506-196 (W) Initialization between types
> "const void*" and "int(*)(struct {...}*,const void*,const char*,const
> char*)" is not allowed.
> "mod_include.c", line 721.26: 1506-068 (W) Operation between types "const
> void*" and "const char*(*)(struct {...}*,const void*,const char*)" is not
> allowed.
> "mod_headers.c", line 898.43: 1506-280 (W) Function argument assignment
> between types "const void*" and "const char*(*)(struct request_rec*,char*)"
> is not allowed.
>
> On Tue, Feb 21, 2012 at 10:44 AM, William A. Rowe Jr.
> wrote:
>
> > On 2/21/2012 4:00 AM, Daniel Shahaf wrote:
> > >
> > > (I'm working on the assumption that API consumers are allowed to write
> > > their code in C89.)
> >
> > I believe that in 2012 that is a more than fair assumption, go with it.
> >
> > I'm not sure we have a C99 consensus, although I believe it's past time
> > that we should :)
> >
Re: [PATCH] Eliminate warnings with C89 compilers
Stefan Fritsch wrote on Tue, Feb 21, 2012 at 22:53:44 +0100:
> On Tuesday 21 February 2012, Michael Felt wrote:
> > FYI - I see no notable difference in the W messages with the IBM
> > vacpp (xlc) v7 compiler using no CFLAGS and CFLAGS='-O2
> > -qlanglvl=extc99'
>
> Hrm. Assigning function pointers to void * is not really portable. Not
> sure about the best way to fix this, yet, while keeping the code
> readable.
>
I think the issue is a constness mismatch?
> > "util_expr_eval.c", line 1601.7: 1506-196 (W) Initialization between types
> > "const void*" and "int(*)(struct {...}*,const void*,const char*,const
> > char*)" is not allowed.
There is a "pointer to constant" on the left and a "pointer to func with
such and such arguments and return value" on the right. Formally the
function object itself isn't marked as const...
> Cheers,
> Stefan
Re: AsyncRequestWorkerFactor / Event Sizing / Closing Connections
Rainer Jung wrote on Wed, Feb 22, 2012 at 04:53:34 +0100: > "C" only occasionally, not with such a big percentage. E.g. on the > EU mirror running 2.2 and having less traffic there is hardly ever a > "C" to notice. Is that an expected 2.4/event difference, or is there > something strange with the us network infrastructure? The EU mirror is not in the geo DNS rotation at this time. The only traffic it sees it are people who type foo.eu.apache.org directly into their browser. (which probably happens occasionally for www.eu and never for the other vhosts)
Re: [PATCH] s/#if/#ifdef/ for AP_ENABLE_DTRACE
Daniel Shahaf wrote on Tue, Feb 21, 2012 at 11:21:34 +0200:
> This patch should suppress the ~only warning I get when building svn
> against httpd-2.4.1:
>
> [[[
> Index: include/ap_config.h
> ===
> --- include/ap_config.h (revision 1291669)
> +++ include/ap_config.h (working copy)
> @@ -194,7 +194,7 @@
> #define AP_NONBLOCK_WHEN_MULTI_LISTEN 1
> #endif
>
> -#if AP_ENABLE_DTRACE && HAVE_SYS_SDT_H
> +#if defined(AP_ENABLE_DTRACE) && HAVE_SYS_SDT_H
Ping?
Attached an updated version that fixes another instance of the same
issue.
Thanks,
Daniel
> #include
> #else
> #undef _DTRACE_VERSION
> ]]]
>
> For refernce:
> [[[
> % grep -R AP_ENABLE_DTRACE include/
> include/ap_config.h:#if AP_ENABLE_DTRACE && HAVE_SYS_SDT_H
> include/ap_config_auto.h.in:#undef AP_ENABLE_DTRACE
> include/ap_config_auto.h:/* #undef AP_ENABLE_DTRACE */
> ]]]
>
> OK to commit?
Index: ap_mpm.h
===
--- ap_mpm.h (revision 1293533)
+++ ap_mpm.h (working copy)
@@ -218,7 +218,7 @@
#define AP_MONCONTROL(x)
#endif
-#if AP_ENABLE_EXCEPTION_HOOK
+#ifdef AP_ENABLE_EXCEPTION_HOOK
typedef struct ap_exception_info_t {
int sig;
pid_t pid;
Index: ap_config.h
===
--- ap_config.h (revision 1293533)
+++ ap_config.h (working copy)
@@ -194,7 +194,7 @@
#define AP_NONBLOCK_WHEN_MULTI_LISTEN 1
#endif
-#if AP_ENABLE_DTRACE && HAVE_SYS_SDT_H
+#if defined(AP_ENABLE_DTRACE) && HAVE_SYS_SDT_H
#include
#else
#undef _DTRACE_VERSION
Re: [RE-VOTE #3] adoption of mod_combine subproject
Guys. You were asked a boolean question. I'm pretty sure it was intended to be taken literally. Have you considered just answering it?
Re: [RE-VOTE #3] adoption of mod_combine subproject
William A. Rowe Jr. wrote on Tue, Apr 03, 2012 at 13:16:22 -0500: > On 3/28/2012 6:04 PM, Daniel Shahaf wrote: > > Guys. You were asked a boolean question. I'm pretty sure it was > > intended to be taken literally. Have you considered just answering it? > > I believe that you meant to direct this to Graham and cc me, and not visa > versa, since I don't have such an answer. Don't pay too much attention to the To/Cc. Sometimes I just press "Reply all" and go with the default partitioning. > I also believe he did so (you > might also refer to the bugzilla ticket Sam hasn't replied to yet). > https://issues.apache.org/bugzilla/show_bug.cgi?id=52322 Thanks for the pointer -- I only read the legal-discuss@ thread, not the ticket.
Re: svnmerge.py (Was: Re: mergeinfo ignorance)
Jim Jagielski wrote on Mon, Jul 23, 2012 at 11:55:32 -0400: > Is this still useful: svnmerge.py ? > > http://www.orcaware.com/svn/wiki/Svnmerge.py > For 1.4 repositories (regardless of server software version) yes. I'd not use both svnmerge.py and 'svn merge' on the same branch, that's just asking for trouble/headaches. http://subversion.apache.org/docs/release-notes/1.5#compatibility
Re: Using APR pools "better"
Jim Jagielski wrote on Wed, 26 Sep 2018 11:09 -0400: > At ApacheCon's welcoming event last night, Greg, Sander and I were > chatting and Greg reminded us that the Subversion project "learned a lot > about using APR pools" and it seems to me that a lot of that knowledge > is likely missing in httpd-land. I also know that some of that has been > backported back to APR itself, but I am wondering (as I am wont to do), > if we couldn't do a better job here. I am sure that there are things in > svn that could be easily and readily folded back into APR w/o breaking > anything. > > I know that some of that influenced Greg's PoCore work, but it would be > really cool if someone in Subversion could maybe point out some of those > improvements and "lessons learned" so that both APR and httpd could > benefit. For starters, here's what we've already written down: https://subversion.apache.org/docs/community-guide/conventions.html#apr-pools I would especially point out the result_pool/scratch_pool distinction: each function gets *two* pools, one in which to allocate the return value, and one whose lifetime is defined as "the pool may be deleted at any time after the function returns". For example, when one calls a function declared as: . apr_status_t find_foo(foo_t *outparam, ..., apr_pool_t *result_pool, apr_pool_t *scratch_pool) . then on return *outparam will be allocated in result_pool, and apr_pool_clear(scratch_pool) may be called as soon as find_foo() returned. Thus, scratch_pool is passed into the result_pool formal parameter of functions find_foo() calls, is the pool iterpools are created as subpools of, etc. . I'm sure Greg is subscribed to at least one of these lists and will add anything I forgot :) Daniel
Re: svn commit: r1760148 - in /httpd/httpd/branches/2.4.x: ./ STATUS
Luca Toscano wrote on Sat, Sep 10, 2016 at 12:45:35 +0200: > 2016-09-10 12:22 GMT+02:00 : > > +++ svn:mergeinfo Sat Sep 10 10:22:56 2016 > > @@ -2,4 +2,4 @@ > > -/httpd/httpd/trunk:1200475,1200478,1200482,1200491, > > 1200496,1200513,1200550,1200556,1200580,1200605,[...] > > 1757540,1757662-1757663,1757985,1758003,1758083,1758307-1758311,1758446, > > 1758558,1759984,1760018 > > > > The diff are my two commits proposed to backport, The emailed mergeinfo diffs used to be easier to read; see INFRA-9186. > that have been probably tracked in my local repo, For future reference: this would have shown up as " M ." in 'svn status'. When you see that, you can just revert it with 'svn revert ./'; without -R it won't revert anything else. I assume what happened was that you merged the commits to test the backport and then reverted them with 'svn revert -R *'. That reverts everything *except* the working copy root. To revert everything, 'svn revert -R ./' is required. Cheers, Daniel
Re: svn commit: r1765368 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/mod/mod_proxy_html.html.en docs/manual/mod/mod_proxy_html.xml
Eric Covener wrote on Mon, Oct 17, 2016 at 16:33:36 -0400: > On Mon, Oct 17, 2016 at 4:22 PM, Jacob Champion wrote: > > On 10/17/2016 01:15 PM, jchamp...@apache.org wrote: > >> > >> Log: > >> Merge r1765361 from trunk: > > > > > > Copy-pasted the wrong rev; this should have been r1765357. Sorry, first time > > merging... > > For straightforward backports some of us use: > http://people.apache.org/~jorton/svn.merge Subversion uses a cron job that automatically merges STATUS entries that have received sufficient votes. It creates commits such as this: https://svn.apache.org/r1765006
Re: Automated tests
Luca Toscano wrote on Mon, Jan 02, 2017 at 15:51:43 +0100: > I don't have a wide experience on build httpd on systems different than > Debian/Ubuntu, so any help/suggestion/pointer would help a lot (for > example, building on Windows). I wouldn't worry about that just yet. Start by having only an Ubuntu bot; that'd already be a step forward. Let someone who builds on Windows be the liaison with infra about a Windows buildslave. Setting this up isn't a lot more complicated than filing an INFRA ticket with a build script, a list of build dependencies, and a list of branches to build, and deciding how build failures would be notified. Cheers, Daniel
Re: Autobuild Progress (was Re: Automated tests)
Jacob Champion wrote on Mon, Jan 30, 2017 at 12:02:35 -0800: > On 01/02/2017 07:53 AM, Daniel Shahaf wrote: > >Setting this up isn't a lot more complicated than filing an INFRA ticket > >with a build script, a list of build dependencies, and a list of > >branches to build, and deciding how build failures would be notified. > > To follow up on this, we now have an operational (if not yet fully > functional) buildbot for trunk: > > https://ci.apache.org/builders/httpd-trunk > Nice! > There's a lot of work yet to do, but for now we have an Ubuntu machine that > can be manually triggered to run an incremental build on trunk. > > Here's my list of TODOs: > - run per-commit incremental builds > - run nightly clean builds > - run a nightly test suite > - set up 2.4.x in addition to trunk > - set up Windows in addition to Ubuntu You could also configure buildbot to detect any new compiler warnings. That'll cause buildbot to report a FAILURE (red) or a WARNING (yellow), instead of a SUCCESS (green), if the build succeeded but a compiler warning has been issued. (Currently, the build passes the -Wall flag and has no warnings.) You can crib the setup from the 'svn-warnings' builder in subversion.conf in the same directory. Cheers, Daniel
