Re: svn commit: r1215525 - in /httpd/httpd/trunk: ./ docs/manual/mod/ docs/manual/programs/ modules/debugging/ support/
On 12/18/2011 7:32 AM, Jim Jagielski wrote: > > On Dec 17, 2011, at 3:51 PM, William A. Rowe Jr. wrote: > >> NOBODY suggested that this proposed subproject go into trunk. > > I must have been reading a different thread that you when > the issue of having these as "subprojects" or "normal modules" > was discussed and Igor and Dan (at least) indicated the desire > for them being normal modules (since sub-modules have a tendency > to be ignored)... No wait, you had to have been reading that because > you rightly reminded people that large code donations normally > go thru the Incubator. Ahhh, no but wait, that chatter on a private list (your fault for disclosure, not mine) did not happen. Technical discussions that occur on the private list are void. Now I see why you and perhaps even Graham are confused, and to an outside observer, off-base. I see where there were private concerns expressed about acceptance of sub-project code. The fact that I disagreed with those comments, but published my concerns on the public list, mean that effectively this is a one sided discussion so far. Those concerns could be valid, but don't represent consensus, and until discussion on dev@ happens, they aren't even concerns. IMHO it is up to any subproject champion to promote their code for consideration in trunk if that's where they believe it should end up, once they demonstrate a community around the code. That means they have multiple committers. Do we really believe this code is more deserving of a fast track to trunk than mod_fcgid? At this time these are simply nothing more than a code dump, and that's not acceptable for mainline trunk. With five or fewer pmc supporters of this code out of some 70 PMC members, success doesn't seem to be written in stone just yet.
Re: can't compile module with apxs
Thanks for your advice :-) Rui Hu 2012/2/27 Nick Kew > On Mon, 27 Feb 2012 17:13:52 +0800 > Rui Hu wrote: > > > > Should I add some compile parameters in apxs? > > No, but you should probably have posted to the modules-dev > list rather than here. > > It's not a compile problem, it's a design problem. > You're trying to use data that's private to another module. > That means you lose all API support, and a change in the > core could break your 'module' at any time (and consequently > you can't in good faith supply it to any third-parties > as a module, because it'll prevent them upgrading). > > Your options are: > > 1. Redesign your module not to need core internals. > 2. Copy the relevant declarations, and live with the consequences. > 3. Propose a change to the core API to expose whatever you need. > > Your best option is probably the first. > > -- > Nick Kew > -- Best regards, Rui Hu State Key Laboratory of Networking & Switching Technology Beijing University of Posts and Telecommunications(BUPT) MSN: tchrb...@gmail.com -
Re: Proposal: adoption of mod_policy subproject
On 12/14/2011 2:29 PM, William A. Rowe Jr. wrote: > On 12/13/2011 12:39 PM, William A. Rowe Jr. wrote: >> On 12/13/2011 10:22 AM, Graham Leggett wrote: >>> - mod_policy: "HTTP protocol police" >>> >>> mod_policy is a set of httpd filters that detect and implement a set of >>> HTTP protocol checks, the idea being you declare a policy for your >>> development and testing environments, and requests/responses that violate >>> the policy will either log a warning to the error_log or explicitly fail >>> with a suitable error message, clearly telling the developer what they have >>> done wrong, with the expectation that the developer fixes this before the >>> code sees production. >> >> Very interesting, sounds generally useful to developers, and rounds out that >> large gap in modules/test/ that we essentially offer very little for >> 'testing' >> in terms of functional test modules. > > To clarify, I'm +1 for directly incorporating this into > httpd/trunk/modules/test/ I withdraw this vote, reverting my position to -1, until collaboration and respect for options and insights of fellow committers as well as project decisions and votes can be consistently demonstrated. This leaves +1; jim, minfrin. -1; wrowe. The vote fails for the time being.
Re: svn commit: r1215525 - in /httpd/httpd/trunk: ./ docs/manual/mod/ docs/manual/programs/ modules/debugging/ support/
On 12/18/2011 10:45 AM, Graham Leggett wrote: > On 17 Dec 2011, at 10:51 PM, William A. Rowe Jr. wrote: > >> I proposed instead that you directly propose mod_policy, one of the >> three modules, as a core httpd module, because it already has a clear >> fit and really needs little further review (improvements, sure). > > What you really said was: > > "To clarify, I'm +1 for directly incorporating this into > httpd/trunk/modules/test/ > > I don't think we need an independent subproject for this particular module, it > seems rather straightforward. Default to build-but-don't-load. Provide an > example > config under docs/conf/extra/httpd-policy.conf" The subject of what I really said was mod_policy. Only mod_policy. Nothing other than mod_policy. Do not twist my post. mod_policy is an expression of HTTP correctness which I suggested for test/, which httpd aught to have a vested interest in pursuing, as protocol correctness is one aspect that interests us technically. modules\test\ is a historic place for this. > Given that mod_firehose is significantly simpler than mod_policy, I am > struggling to understand given both your stated preference above, and the > preferences of others already stated, why suddenly this is a big issue. That's your evaluation, not mine. My evaluation is that you invented yet another wonky data representation and the whole idea of firehose merits further thought at its new home if httpd is to accept it. We don't even need mod_firehose. Maybe it will be nice to have. If we do want to adopt it, this implies killing mod_dump_io or refactoring one into the other since they are largely aspects of the same thing. Even back in the day I would have insisted this go to modules/experimental. As it stands, I insist it not go in until it has a community, something you have yet to demonstrate. You have only three votes for mod_policy... please fix this today, before I withdraw what starts to look like an ill-cast vote for introducing code with dubious support of the community.
Re: svn commit: r1294936 - in /httpd/httpd/trunk: CHANGES include/mpm_common.h include/scoreboard.h
On 2/28/2012 8:11 PM, Jeff Trawick wrote: > > AP_DECLARE_DATA just affects visibility, but the switch to __stdcall > for AP_DECLARE() is an API change. (important, since AIX needs this > in 2.4.x) If they weren't AP_DECLARE()ed before, they weren't exported. Ergo they are only used internally. Sure, if someone has a checkout and doesn't rebuild-all, that would be an issue, but let's just assume that recompiling only half the sources between 2.4.1 and 2.4.2 is a non-starter. Remember function signatures need to match between the .h and .c. This commit was only half a change.
Re: svn commit: r1294936 - in /httpd/httpd/trunk: CHANGES include/mpm_common.h include/scoreboard.h
On Tue, Feb 28, 2012 at 8:52 PM, wrote: > Author: trawick > Date: Wed Feb 29 01:52:17 2012 > New Revision: 1294936 > > URL: http://svn.apache.org/viewvc?rev=1294936&view=rev > Log: > Fix MPM DSO load failure on AIX. > > Without the proper AP_DECLARE*, these functions used by MPMs > were not exported from httpd on AIX, resulting in symbol > resolution errors. Windows: AP_DECLARE_DATA just affects visibility, but the switch to __stdcall for AP_DECLARE() is an API change. (important, since AIX needs this in 2.4.x) Bill, can you confirm that adding AP_DECLARE in 2.4.x is breakage on Windows? (Many of these don't apply to Windows for one reason or another; I haven't checked the exact list of APIs with a potential concern, pending an answer from Bill or other Windows-savants.) > > Modified: > httpd/httpd/trunk/CHANGES > httpd/httpd/trunk/include/mpm_common.h > httpd/httpd/trunk/include/scoreboard.h > > Modified: httpd/httpd/trunk/CHANGES > URL: > http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1294936&r1=1294935&r2=1294936&view=diff > == > --- httpd/httpd/trunk/CHANGES [utf-8] (original) > +++ httpd/httpd/trunk/CHANGES [utf-8] Wed Feb 29 01:52:17 2012 > @@ -1,6 +1,8 @@ > -*- coding: utf-8 -*- > Changes with Apache 2.5.0 > > + *) Fix MPM DSO load failure on AIX. [Jeff Trawick] > + > *) core: Add the port number to the vhost's name in the scoreboard. > [Stefan Fritsch] > > > Modified: httpd/httpd/trunk/include/mpm_common.h > URL: > http://svn.apache.org/viewvc/httpd/httpd/trunk/include/mpm_common.h?rev=1294936&r1=1294935&r2=1294936&view=diff > == > --- httpd/httpd/trunk/include/mpm_common.h (original) > +++ httpd/httpd/trunk/include/mpm_common.h Wed Feb 29 01:52:17 2012 > @@ -102,8 +102,8 @@ typedef void ap_reclaim_callback_fn_t(in > * in the scoreboard as well as those currently registered via > * ap_register_extra_mpm_process(). > */ > -void ap_reclaim_child_processes(int terminate, > - ap_reclaim_callback_fn_t *mpm_callback); > +AP_DECLARE(void) ap_reclaim_child_processes(int terminate, > + ap_reclaim_callback_fn_t > *mpm_callback); > > /** > * Catch any child processes that have been spawned by the parent process > @@ -115,7 +115,7 @@ void ap_reclaim_child_processes(int term > * in the scoreboard as well as those currently registered via > * ap_register_extra_mpm_process(). > */ > -void ap_relieve_child_processes(ap_reclaim_callback_fn_t *mpm_callback); > +AP_DECLARE(void) ap_relieve_child_processes(ap_reclaim_callback_fn_t > *mpm_callback); > > /** > * Tell ap_reclaim_child_processes() and ap_relieve_child_processes() about > @@ -128,7 +128,7 @@ void ap_relieve_child_processes(ap_recla > * ap_reclaim_child_processes(), remove it from the list of such processes > * by calling ap_unregister_extra_mpm_process(). > */ > -void ap_register_extra_mpm_process(pid_t pid, ap_generation_t gen); > +AP_DECLARE(void) ap_register_extra_mpm_process(pid_t pid, ap_generation_t > gen); > > /** > * Unregister an MPM child process which was previously registered by a > @@ -138,10 +138,11 @@ void ap_register_extra_mpm_process(pid_t > * @param old_gen Set to the server generation of the process, if found. > * @return 1 if the process was found and removed, 0 otherwise > */ > -int ap_unregister_extra_mpm_process(pid_t pid, ap_generation_t *old_gen); > +AP_DECLARE(int) ap_unregister_extra_mpm_process(pid_t pid, ap_generation_t > *old_gen); > > /** > * Pool cleanup for end-generation hook implementation > + * (core httpd function) > */ > apr_status_t ap_mpm_end_gen_helper(void *unused); > > @@ -154,7 +155,7 @@ apr_status_t ap_mpm_end_gen_helper(void > * APR_EINVAL is returned if passed either an invalid (< 1) pid, or if > * the pid is not in the current process group > */ > -apr_status_t ap_mpm_safe_kill(pid_t pid, int sig); > +AP_DECLARE(apr_status_t) ap_mpm_safe_kill(pid_t pid, int sig); > > /** > * Run the monitor hook (once every ten calls), determine if any child > @@ -166,8 +167,9 @@ apr_status_t ap_mpm_safe_kill(pid_t pid, > * @param p The pool to allocate out of > * @param s The server_rec to pass > */ > -void ap_wait_or_timeout(apr_exit_why_e *status, int *exitcode, apr_proc_t > *ret, > - apr_pool_t *p, server_rec *s); > +AP_DECLARE(void) ap_wait_or_timeout(apr_exit_why_e *status, int *exitcode, > + apr_proc_t *ret, apr_pool_t *p, > + server_rec *s); > > /** > * Log why a child died to the error log, if the child died without the > @@ -177,7 +179,7 @@ void ap_wait_or_timeout(apr_exit_why_e * > * @param status The status returned from ap_wait_or_timeout > * @return 0 on success, A
Re: svn commit: r1215525 - in /httpd/httpd/trunk: ./ docs/manual/mod/ docs/manual/programs/ modules/debugging/ support/
On 2/28/2012 5:47 PM, Graham Leggett wrote: > On 29 Feb 2012, at 12:21 AM, William A. Rowe Jr. wrote: > >> After two months, firehose still didn't obtain another +1, so the vote to >> incorporate firehose into trunk stands at 3 +1's, 1 -1, and therefore >> failed the vote for inclusion in trunk. > > I count 4 +1s on the dev@httpd list: > > minfrin, issac, sctemme, jim For firehose you called a vote for a *** subproject *** Subject: Proposal: adoption of mod_firehose subproject Date: Tue, 13 Dec 2011 17:19:16 +0200 Message-Id: These four people voted to adopt a subproject. Nobody within that thread suggested it become a module. I emailed some supportive questions seeking more detail, as I have been supportive of all subprojects to gain attention to code. Sometimes successful, sometimes not. You then ninja'ed the thread on the 17th after the voting that this had been a vote to add a module. Such behavior isn't becoming of a collaborator. I then voted -1 due to your bait and switch and asked for who voted to adopt firehose as a module? ... as I did not trust that the committers had really consented to maintaining this code in core, especially since it was only accepted on the slimmest of margin as a standalone subproject. Jim responded that his was a vote for a module or a subproject, no difference. Sander did not clarify after 12/13, and did not consent to a module. Issac did not clarify after 12/13, and did not consent to a module. "Based on the support expressed, and the expressed preference that the module be part of httpd, I have updated the documentation for both mod_firehose and firehose and will commit them to trunk shortly." There was no said support in that thread for mod_firehose in trunk. Don't piss on my head and tell me it's raining. Veto stands, calling your vote fundamentally invalid, and since you are failing to read my posts, is now unconditional. Revert this yourself to a subproject before I simply revert this into void.
Re: svn commit: r1215525 - in /httpd/httpd/trunk: ./ docs/manual/mod/ docs/manual/programs/ modules/debugging/ support/
On 29 Feb 2012, at 12:21 AM, William A. Rowe Jr. wrote: > After two months, firehose still didn't obtain another +1, so the vote to > incorporate firehose into trunk stands at 3 +1's, 1 -1, and therefore > failed the vote for inclusion in trunk. I count 4 +1s on the dev@httpd list: minfrin, issac, sctemme, jim and igalic on the pmc list. poirier and niq expressed support, but didn't vote. By my reckoning, it passes. > There are 4 +1's for a firehose subproject at httpd. If you wish to continue > this effort you can keep this simple by svn mv'ing those respective files > across > from httpd/httpd/trunk to httpd/mod_firehose/trunk, where it can build a > larger > community within httpd project, and things like the data representation format > can be evaluated and enhanced by the community. So far, you are the only one who has questioned the data representation format, claiming that wireshark/pcap could be used instead. When I invented the firehose I wanted an ASCII based protocol, so that I could look at a firehose being recorded and by inspection see the boundaries between the buckets. When you're debugging httpd or an application server behind httpd the bucket boundaries are important. The protocol used is simply chunked encoding, with additional fields behind the chunked value allowing you to tie the buckets back together, and it is very clear which bits are firehose and which part is the bucket by inspection, on purpose. In addition, there was a clear need to be able to capture both individual requests, and whole connection streams, and have the ability to choose which. With the individual requests we were able to isolate some tricky protocol edge cases in mod_cache, and with the connections we were able to identify issues with HTTP/1.0 clients and keepalive in a highly loaded service oriented environment. Further crucial information is dropped buckets, which is either a sign of congestion over the pipe to which these buckets are written, or a sign that the child process crashed unexpectedly. When you brought up pcap as a possibility, I went and did a whole bunch of research into it. What I discovered is that pcap itself gives you a binary encapsulation format, meaning that you lose the ability to see bucket boundaries, and the ability to debug by inspection. Then I looked for existing client support that might help, and discovered there is none - clients expect the pcap packets to contain clearly identified packets you would expect to find at layer 2, not free form binary that you can expect to find in an HTTP body. I considered hacking up fake TCP packets, but then ran into the problem that I now needed to care whether they were IPV4 or IPV6 packets, and trying to hack up fake packets when you captured individual requests on a long lived connection is a non trivial exercise. At the end of the day you want confidence in your debugging data, and a hacked together reconstruction of TCP is the exact opposite of that. The HTTP protocol dump is called a "firehose" for a reason - at one point we were recording and analysing hundreds of gigabytes of request data, and firehose had to decode and process that in situ on a production box that had been taken out of the pool without the installation of any scripting language stack (which would have been too slow anyway), or the moving around of the data. Both mod_firehose and firehose are battle tested in that real world scenario. I believe the pcap based solution you proposed is inferior to what we have now, and I believe there is no compelling reason at this point to attempt any alternative solution. Regards, Graham --
Re: svn commit: r1294380 - in /httpd/httpd/branches/2.2.x: build/aix/ build/aix/README build/aix/aixinfo build/aix/buildaix.ksh build/aix/mkinstallp.ksh config.layout
> > > > > License acceptance is one thing. I dunno what the copyright issue is. > > Again,m copyright is just something "nice", such as: Michael, would it be possible to clarify? There is nothing in the license > for httpd that obligates an end user to accept a license before installing, > so if they don't need to now, there is no need to change that. > If there is no requirement to accept, then it is easy - but the license will still be installed in the default location - should be IMHO. Install Software Type or select values in entry fields. Press Enter AFTER making all desired changes. [TOP] [Entry Fields] * LPP_SOURCE lpp_5307 * Software to Install[+ 4.5.0.5301 Open Se> + Customization SCRIPT to run after installation [] + (not applicable to SPOTs) installp Flags PREVIEW only? [no]+ Preview new LICENSE agreements? [no]+ ACCEPT new license agreements? [no]+ COMMIT software updates? [yes] + SAVE replaced files? [no]+ AUTOMATICALLY install requisite software? [yes] + With the above settings, you could get a FAILURE with acceptance required like this: LICENSE AGREEMENT FAILURES -- The software you have selected for installation contains license agreement(s) that must be accepted before proceeding. Failure to accept the license terms will prevent the installation of the software. Accept the license agreement(s) by selecting "yes" in the "Accept new license agreements" field or by specifying the -Y option to the installp command. Filesets Requiring Software License Acceptance -- openssh.base.client Without it, or with yes specified anyway, a copyright message similar this could appear: ... © Copyright Jakob Schlyter, 2003. © Copyright Dug Song. 1995 © Copyright Kevin Steves. 1995 © Copyright Peter Stuge , 2003 © Copyright Todd C. Miller, 1998. © Copyright Darren Tucker 2004. © Copyright Simon Wilkinson, 2001, 2003. © Copyright Tatu Ylonen , Espoo, Finland, 1995 All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. . . . . . << End of copyright notice for openssh.base >>. . . . In short - niceties. Regards, > Graham > -- > >
Re: svn commit: r1215525 - in /httpd/httpd/trunk: ./ docs/manual/mod/ docs/manual/programs/ modules/debugging/ support/
Graham, After two months, firehose still didn't obtain another +1, so the vote to incorporate firehose into trunk stands at 3 +1's, 1 -1, and therefore failed the vote for inclusion in trunk. There are 4 +1's for a firehose subproject at httpd. If you wish to continue this effort you can keep this simple by svn mv'ing those respective files across from httpd/httpd/trunk to httpd/mod_firehose/trunk, where it can build a larger community within httpd project, and things like the data representation format can be evaluated and enhanced by the community. I would be happy to entertain merging this to trunk once we have contribution from multiple individuals to the subproject and the consensus is that it will be supported by the entire community in 2.6. As an example, only Jeff and I have recently made any significant commits to the mod_fcgid, so by my own standards it is still missing at least one more active committer before mod_fcgid could be considered for inclusion trunk. FWIW my support to explore a mod_combine subproject is attached, and I'll clarify that I meant to +1 the subproject, -1 for commit to trunk as a module (Jim voted +1 to either case) so there are now three votes for a mod_combine subproject, if you want to proceed with that effort as well. Yours, Bill On 12/20/2011 12:53 PM, William A. Rowe Jr. wrote: >> On Dec 18, 2011, at 11:45 AM, Graham Leggett wrote: >>> >>> Given that mod_firehose is significantly simpler than mod_policy, I am >>> struggling to understand given both your stated preference above, and the >>> preferences of others already stated, why suddenly this is a big issue. > > Simpler? Far more files are touched. 10 commits to inject it. A new > support utility must be maintained by the project. It introduces a new > nonstandard data format. And the module name is not descriptive, which > is a no-no for httpd core, as far as I'm concerned. > > mod_policy was a single .c file, right? It doesn't require a support > binary to function, right? (Naming it mod_http_policy might be clearer). > Single commit, plus regen of the docs. I'm struggling to understand what > you mean by less simple. > > On 12/18/2011 11:31 AM, Jim Jagielski wrote: >> FWIW, my vote also applies to incorping direct into httpd repo... >> It was not "conditional" on it being a "subproject" > > Thanks Jim! > > mod_firehose had still needed one more vote if it was to become part > of trunk. It now needs two... > > -1 to this commit. I'm casting this as a vote, and expressly not vetoing > the change; *provided it obtains a majority +2 committers who will truly > review the design and the code*. (3 +1's are always needed; 4 +1/my -1 > passes for "accepted" as far as I'm concerned). > > My preference for it remains to be a subproject, and the name rethought > (we have all functional module names in httpd), so that people can start > adopting it and proving it *before* we inject it into 2.4 branch. > It would be a shame for it to grow stale for 2-5 years, but the 2.3-dev > process reflects that not enough committers are active right now to > ensure newly introduced code is sufficiently thought through. > > Also wondering about the choice of compiling the firehose support tool > instead of authoring something trivially maintainable in perl or python. > That's what we did for mod_log_forensic. Better yet, if it were using > a standard representation, there isn't much need for the 'firehose' > support utility to be maintained here. > > I won't trust your code to receive adequate review sitting out on trunk > for backport... we don't need to dwell on your previous poor designs > such as r59099... still not corrected by you after 7 years... and still > blocked by your veto for adequate resolution in httpd 2.4. Anything > you design that implies introduction of an API or a data representation > format is suspect until proven otherwise; particularly in light of your > failure to reasonably collaborate on implementation details. > > A subproject would give this new code the attention it deserves while > enabling users, and I'll even go so far as to +1 it's introduction as > a subproject, apart from httpd trunk, where it can float or sink on > its own merits. > > Igor and Jim both agreed with you to adopt mod_combine as a subproject, > so all three modules have green lights as such; only one was green lit > for trunk. Please don't repeat this mistake of jamming mod_combine > into trunk, just yet? Put it to a vote (or let voters refine their +1 > to indicate that it belongs in trunk). --- Begin Message --- I haven't had time to study this idea in detail, but it does sound much more like a subproject, as opposed to incorporating as a module. I'm not very clear how this differs in approach from mod_pagespeed, and how the two could be leveraged together. --- End Message ---
Re: svn commit: r1294380 - in /httpd/httpd/branches/2.2.x: build/aix/ build/aix/README build/aix/aixinfo build/aix/buildaix.ksh build/aix/mkinstallp.ksh config.layout
On Tue, Feb 28, 2012 at 10:26 PM, Jeff Trawick wrote:
> On Tue, Feb 28, 2012 at 3:06 PM, Graham Leggett wrote:
> > On 28 Feb 2012, at 3:48 PM, Jeff Trawick wrote:
> >
> >> Is this really ready? The trunk version (if even tested on trunk) at
> >> best barely works, and this hasn't seen many eyes.
> >
> > I don't have access to an AIX machine, so can only rely on Michael's
> judgement for this. Given that we aren't awash with AIX expertise, we need
> to put some trust in the person doing the packaging, the same as we do for
> Netware and other similar platforms.
>
> FWLIW, others on the list have access.
>
> >> Has the packaging of dependent libraries been figured out? Is there
> >> really a such thing as "ASF.apu.rte and ASF.apr.rte filesets"?
> >> Is it appropriate that a package built by a random user is labeled as
> >> an "ASF" package, as if the ASF created it?
> >
> > I don't see why labeling it "ASF" is a problem. Anyone building the
> package would be doing so by following a formal procedure codified in the
> build script, which is in turn published by the ASF, as opposed some
> vendor's build script.
>
> Maybe this info would help... I dunno. This really is project-only
> scope we're managing, not ASF-wide scope. Either there is
> coordination among different projects, or it shouldn't look like there
> is.
>
I cannot answer this. ASFhttpd may be the better (though ugly imho) PKG
name.
>
>
> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/pkging_sw4_install.htm
>
> >
> >> Is it appropriate to instruct users that in some cases they should
> >> "add symbolic links from /usr/include to /opt/include"?
> >
>
Note: I test for a script named build/aix/aixlinks that would be used to
create symbolic links where/if needed.
AIX has not used /opt as /usr/local - it has used /opt/freeware instead - I
debated between using /opt/include, /opt/lib, etc and /opt/aixtools/* - I
decided /opt/* was better for more generic things, and /opt/httpd/lib,
/opt/httpd/include for things needed and might collide with /usr/lib
symbolic links.
installp has a mechanism for when two filesets want to own the same file. I
wish I knew the intricacies, but there are ways to manage this - might even
be in just checking if the links are already there or not.
re: zlib - the library is installed on AIX by default. The zlib include
files are not, but httpd is not dependent on the include file to run (I
hope) - I don't have it on the system I am testing the installp with.
re: expat: using the embedded I think, I know I was - will have to verify
and/or I have an extra pre_i check I need to perform.
In any case, it is easy enough to test for presence of /usr/lib/libz.a in a
pre_i check.
My question is: what else?
> It looks like zlib isn't necessarily available as a proper package.
> Given we don't ship zlib, but depend on it, if the platform has certain
> limitations regarding the availability of certain dependencies, we would
> need to work around that.
>
> It doesn't sound like the right technical solution to me. CPPFLAGS?
>
CPPFLAGS? A typo of mine, or an AIX document referencing something not
valid for right now.
>
> >
> >> What about the todos regarding copyrights and licenses?
> >
> > What specifically about them?
>
> The todo file you committed says that verbatim ;) What are they, and
> why can't they be resolved before committing?
>
> > From what I can see, AIX packages offer the option to force the end user
> to accept a license before installing a package, and there is an open
> question as to whether we do this or not. We don't do it for RPM (nor does
> RPM let you do this), I see no reason to mandate doing it here.
>
> License acceptance is one thing. I dunno what the copyright issue is.
>
The copyright message is a banner that is shown during the install process.
It is something "nice". I sometimes go a bit too extreme in finishing
things. I guess the file I could use for that is NOTICE. That comes very
close
The license is installed in /usr/swlag/en_US/${PKG}.${NAME}.la - which
follows AIX nomenclature. The acceptance is implied because I have not
figured out how to enforce acceptance (either answering the question,
setting an environment variable ACCEPT_LICENSES=yes, or using a flag -Y to
installp.
> >
> >> What about the trivial issue of hard-coding the version? (search for
> >> "2.2.22") Presumably the real version is figured out later, but why
> >> is this in there?
> >
> > A mistake perhaps?
>
Say mistake, not supposed to be hard-coded anywhere anymore (ouch).
Laziness.
> >
> > Looks like VERSION is defined twice, once hard coded, and then a second
> time properly. Solution seems to be to remove the first attempt to set
> VERSION.
> >
> >> Committing to trunk is one thing, but IMO before moving to stable
> >> branches, especially 2.2.x, this needs careful review by at minimum
> >> someone who is very familiar with AIX and will test it perso
Re: svn commit: r1294380 - in /httpd/httpd/branches/2.2.x: build/aix/ build/aix/README build/aix/aixinfo build/aix/buildaix.ksh build/aix/mkinstallp.ksh config.layout
On Tue, Feb 28, 2012 at 5:04 PM, Graham Leggett wrote: > On 28 Feb 2012, at 11:26 PM, Jeff Trawick wrote: > >>> I don't have access to an AIX machine, so can only rely on Michael's >>> judgement for this. Given that we aren't awash with AIX expertise, we need >>> to put some trust in the person doing the packaging, the same as we do for >>> Netware and other similar platforms. >> >> FWLIW, others on the list have access. > > Noone has yet stepped forward if they have, it would be good to get more > experienced eyes on this. I've got regular access here, but no expertise or interest in the native packaging.
Re: svn commit: r1294380 - in /httpd/httpd/branches/2.2.x: build/aix/ build/aix/README build/aix/aixinfo build/aix/buildaix.ksh build/aix/mkinstallp.ksh config.layout
On 28 Feb 2012, at 11:26 PM, Jeff Trawick wrote: >> I don't have access to an AIX machine, so can only rely on Michael's >> judgement for this. Given that we aren't awash with AIX expertise, we need >> to put some trust in the person doing the packaging, the same as we do for >> Netware and other similar platforms. > > FWLIW, others on the list have access. Noone has yet stepped forward if they have, it would be good to get more experienced eyes on this. >> I don't see why labeling it "ASF" is a problem. Anyone building the package >> would be doing so by following a formal procedure codified in the build >> script, which is in turn published by the ASF, as opposed some vendor's >> build script. > Maybe this info would help... I dunno. This really is project-only > scope we're managing, not ASF-wide scope. Either there is > coordination among different projects, or it shouldn't look like there > is. Of course there is coordination among projects - Michael has packaged (or at least I understand he has, still waiting to be sent the scripts) the ASF versions of APR, and the ASF versions of APR-util, which are the logical dependencies of the ASF version of httpd. We have been using this naming convention in the Solaris build scripts for many many years, and I don't see why suddenly this should be a problem, or why we need to subvert that convention all of a sudden. >>> What about the todos regarding copyrights and licenses? >> >> What specifically about them? > > The todo file you committed says that verbatim ;) What are they, and > why can't they be resolved before committing? > >> From what I can see, AIX packages offer the option to force the end user to >> accept a license before installing a package, and there is an open question >> as to whether we do this or not. We don't do it for RPM (nor does RPM let >> you do this), I see no reason to mandate doing it here. > > License acceptance is one thing. I dunno what the copyright issue is. Michael, would it be possible to clarify? There is nothing in the license for httpd that obligates an end user to accept a license before installing, so if they don't need to now, there is no need to change that. Regards, Graham --
RE: Apache 2.4.1 Throughput compared with nginx
Some Nginx people just made a performance test with Apache 2.4.1 at http://blog.zhuzhaoyuan.com/category/c10k/ Were the Event_MPM configuration parameters somewhere close to optimal? Regards, Bing Jim Jagielski [mailto:j...@jagunet.com] wrote on 2012年2月24日 20:57 > > w00t!!! > > On Feb 23, 2012, at 5:26 PM, MATSUMOTO Ryosuke wrote: > >> Hi all, >> >> I evaluated the throughput of Apaceh 2.4.1. I compared apache(2.4.1, >> 2.2.3) with nginx. >> I used httperf benchmark 0.9.0 to measure thethroughput. >> >> http://blog.matsumoto-r.jp/?p=1812 >> >> I feel bad about writing this article in Japanese in my hurry ;) >> >> Regards, >> -- >> MATSUMOTO Ryosuke < matsu1229 at gmail.com > >> http://blog.matsumoto-r.jp/ >>
Re: svn commit: r1294380 - in /httpd/httpd/branches/2.2.x: build/aix/ build/aix/README build/aix/aixinfo build/aix/buildaix.ksh build/aix/mkinstallp.ksh config.layout
On Tue, Feb 28, 2012 at 3:06 PM, Graham Leggett wrote: > On 28 Feb 2012, at 3:48 PM, Jeff Trawick wrote: > >> Is this really ready? The trunk version (if even tested on trunk) at >> best barely works, and this hasn't seen many eyes. > > I don't have access to an AIX machine, so can only rely on Michael's > judgement for this. Given that we aren't awash with AIX expertise, we need to > put some trust in the person doing the packaging, the same as we do for > Netware and other similar platforms. FWLIW, others on the list have access. >> Has the packaging of dependent libraries been figured out? Is there >> really a such thing as "ASF.apu.rte and ASF.apr.rte filesets"? >> Is it appropriate that a package built by a random user is labeled as >> an "ASF" package, as if the ASF created it? > > I don't see why labeling it "ASF" is a problem. Anyone building the package > would be doing so by following a formal procedure codified in the build > script, which is in turn published by the ASF, as opposed some vendor's build > script. Maybe this info would help... I dunno. This really is project-only scope we're managing, not ASF-wide scope. Either there is coordination among different projects, or it shouldn't look like there is. http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/pkging_sw4_install.htm > >> Is it appropriate to instruct users that in some cases they should >> "add symbolic links from /usr/include to /opt/include"? > > It looks like zlib isn't necessarily available as a proper package. Given we > don't ship zlib, but depend on it, if the platform has certain limitations > regarding the availability of certain dependencies, we would need to work > around that. It doesn't sound like the right technical solution to me. CPPFLAGS? > >> What about the todos regarding copyrights and licenses? > > What specifically about them? The todo file you committed says that verbatim ;) What are they, and why can't they be resolved before committing? > From what I can see, AIX packages offer the option to force the end user to > accept a license before installing a package, and there is an open question > as to whether we do this or not. We don't do it for RPM (nor does RPM let you > do this), I see no reason to mandate doing it here. License acceptance is one thing. I dunno what the copyright issue is. > >> What about the trivial issue of hard-coding the version? (search for >> "2.2.22") Presumably the real version is figured out later, but why >> is this in there? > > A mistake perhaps? > > Looks like VERSION is defined twice, once hard coded, and then a second time > properly. Solution seems to be to remove the first attempt to set VERSION. > >> Committing to trunk is one thing, but IMO before moving to stable >> branches, especially 2.2.x, this needs careful review by at minimum >> someone who is very familiar with AIX and will test it personally, and >> hopefully by others who will ask the necessary questions to understand >> the ramifications, and not end up having to repair the thing in >> 2.2.(n+5)/2.4.(n+5) and break compatibility with previous versions. >> >> Hats off to Michael for working on this, but this contains a lot of >> gory details to consider, and AFAIK no one who has logged onto an AIX >> box since mid-2008 has stared at it enough to identify even the most >> trivial of issues. > > The build for v2.2.x will look nothing like the build for v2.4.x, and for > this reason there is no way to apply changes to trunk, and then backport it, > as each branch works completely differently, and therefore the build will > work completely differently. > > If this is too much of a pain, working from a branch might be a better idea > until these issues are solved. > > Regards, > Graham > -- > -- Born in Roswell... married an alien...
Re: svn commit: r1294380 - in /httpd/httpd/branches/2.2.x: build/aix/ build/aix/README build/aix/aixinfo build/aix/buildaix.ksh build/aix/mkinstallp.ksh config.layout
On Tue, Feb 28, 2012 at 3:44 PM, Michael Felt wrote: > Thanks for the "hats off", and I agree that claiming ownership is not simple > - did not feel right to PKG it as > AIXTOOLS, so I used what I thought was the convention in the build/pkg > > In pkginfo the PKG is ASFhttpd, and I thought ASFhttpd.httpd was a silly > name, so I shortened the PKG to ASF. > Assumptions are ever so dangerous! but naming it after anything other than > ASF seemed wrong too. Creating new prefixes for externally visible names is always interesting. > > regarding the testing: I have found a volunteer to test it all tomorrow - > especially useful for me and them as they use > self-built httpd on AIX. > > I do not claim perfection, but I did reinstall my development server to get > rid of as many hidden dependencies as possible. > There are actually no dependencies for the scripts themselves, only for a > successful configure, make and make install (to a DESTDIR) location. > > To this end I started a source forge project today to make these scripts as > generic as possible and shall work here and there to make them as fool proof > as possible. I like AIX a lot and hope this will lower thresholds to seeing > httpd running at the latest version on AIX. Improvements in httpd I'll leave > to all of you. > > So, not knowing the politics of ASF I would say delete any text that may be > misplaced, such as a reference to ASF.apr,rte and/or ASF.apu.rte (those are > the names given to the apr and apr-util via the 'aixinfo' script (again, > following the principle of the build/pkg/pkginfo script for getting names > and values from the release) I don't see the politics here... Where do I get ASF.apr.rte, whether it is "ASF" or something else? Does it exist anywhere? > Probably, wisdom is to remove them from 2.2.22 until they have been verified > independently. I am a bit prejudice after all :p so I wont "vote". > > p.s. thanks to all who have assisted me in gaining the knowledge needed to > get this done. If you're more comfortable with Sourceforge, then maybe that is the right place. My objection is to putting something unfinished and barely reviewed in a stable branch. That wasn't your job to understand. httpd trunk is the place to keep such things until they are working cleanly there, and then with review* move it back to the stable branches. That 2.2.x needs different configure invocations than 2.4.x/trunk doesn't change that fact that 2.2.x (and 2.4.x for that matter) is only for things that are finished and whose external interfaces are frozen. We should have pointed this out many days ago after some of the confusion about configure options. It was clear to some of us but not to you that we should be working only with trunk. Then when that is as good as it can get then it can go into 2.4.x. Then 2.2.x. *it isn't as if Michael has to be the Lone Ranger; some on this list have AIX access day to day; surely some of those can play with it > > > On Tue, Feb 28, 2012 at 2:48 PM, Jeff Trawick wrote: >> >> On Mon, Feb 27, 2012 at 5:57 PM, wrote: >> > Author: minfrin >> > Date: Mon Feb 27 22:57:18 2012 >> > New Revision: 1294380 >> > >> > URL: http://svn.apache.org/viewvc?rev=1294380&view=rev >> > Log: >> > AIX: Add build scripts for AIX. >> > Submitted by: Michael Felt >> >> Is this really ready? The trunk version (if even tested on trunk) at >> best barely works, and this hasn't seen many eyes. >> >> Has the packaging of dependent libraries been figured out? Is there >> really a such thing as "ASF.apu.rte and ASF.apr.rte filesets"? >> Is it appropriate that a package built by a random user is labeled as >> an "ASF" package, as if the ASF created it? >> Is it appropriate to instruct users that in some cases they should >> "add symbolic links from /usr/include to /opt/include"? >> What about the todos regarding copyrights and licenses? >> What about the trivial issue of hard-coding the version? (search for >> "2.2.22") Presumably the real version is figured out later, but why >> is this in there? >> >> Committing to trunk is one thing, but IMO before moving to stable >> branches, especially 2.2.x, this needs careful review by at minimum >> someone who is very familiar with AIX and will test it personally, and >> hopefully by others who will ask the necessary questions to understand >> the ramifications, and not end up having to repair the thing in >> 2.2.(n+5)/2.4.(n+5) and break compatibility with previous versions. >> >> Hats off to Michael for working on this, but this contains a lot of >> gory details to consider, and AFAIK no one who has logged onto an AIX >> box since mid-2008 has stared at it enough to identify even the most >> trivial of issues. >> >> > >> > Added: >> > httpd/httpd/branches/2.2.x/build/aix/ >> > httpd/httpd/branches/2.2.x/build/aix/README >> > httpd/httpd/branches/2.2.x/build/aix/aixinfo >> > httpd/httpd/branches/2.2.x/build/aix/buildaix.ksh (with props) >> > httpd/httpd/bran
Threads and signals in a module
Hello, I have a module which creates a thread using pthread_create and then registers for SIGRTMIN+4 signal from another process. Problem is I do not see a signal callback when the signal is sent to me. I only see it when I try to kill apache where just before dying it hits the signal callback. So something in Apache is blocking the signal. I am using worker MPM. What could be the issue. I do not have much leeway into changing the design of the module (the threading model comes from a separate lib which I link into the module)...but I can change to use a different signal than SIGRTMIN+4, etc. I can also change apache and recompile apache if needed. Please let me know if you have any suggestions. I have been stuck at this for a while now :-( Thanks
Re: Cannot start httpd v2.4.1 with mpm_build on AIX
it was easy to reset -- cp /etc/httpd/original/httpd.conf /etc/httpd But I shall remember that for the future! On Tue, Feb 28, 2012 at 7:37 AM, Rainer Jung wrote: > On 27.02.2012 23:14, Michael Felt wrote: > >> LoadModule unixd_module libexec/mod_unixd.so >> #LoadModule heartbeat_module libexec/mod_heartbeat.so >> #LoadModule heartmonitor_module libexec/mod_heartmonitor.so >> #LoadModule dav_module libexec/mod_dav.so >> LoadModule status_module libexec/mod_status.so >> LoadModule autoindex_module libexec/mod_autoindex.so >> >> from the looks of it, seemsI need to remove several # to test loading >> all modules :) >> > > For testing purposes like what you are doing right now, there is a > configure flag > > --enable-load-all-modules > > which will activate all LoadModule lines during installation. But as > already said by others: we think it is an improvement, that 2.4 does no > longer activate all modules by default, so don't package wth > "--enable-load-all-modules". > > Regards, > > Rainer >
Re: svn commit: r1294380 - in /httpd/httpd/branches/2.2.x: build/aix/ build/aix/README build/aix/aixinfo build/aix/buildaix.ksh build/aix/mkinstallp.ksh config.layout
Thanks for the "hats off", and I agree that claiming ownership is not simple - did not feel right to PKG it as AIXTOOLS, so I used what I thought was the convention in the build/pkg In pkginfo the PKG is ASFhttpd, and I thought ASFhttpd.httpd was a silly name, so I shortened the PKG to ASF. Assumptions are ever so dangerous! but naming it after anything other than ASF seemed wrong too. regarding the testing: I have found a volunteer to test it all tomorrow - especially useful for me and them as they use self-built httpd on AIX. I do not claim perfection, but I did reinstall my development server to get rid of as many hidden dependencies as possible. There are actually no dependencies for the scripts themselves, only for a successful configure, make and make install (to a DESTDIR) location. To this end I started a source forge project today to make these scripts as generic as possible and shall work here and there to make them as fool proof as possible. I like AIX a lot and hope this will lower thresholds to seeing httpd running at the latest version on AIX. Improvements in httpd I'll leave to all of you. So, not knowing the politics of ASF I would say delete any text that may be misplaced, such as a reference to ASF.apr,rte and/or ASF.apu.rte (those are the names given to the apr and apr-util via the 'aixinfo' script (again, following the principle of the build/pkg/pkginfo script for getting names and values from the release) Probably, wisdom is to remove them from 2.2.22 until they have been verified independently. I am a bit prejudice after all :p so I wont "vote". p.s. thanks to all who have assisted me in gaining the knowledge needed to get this done. On Tue, Feb 28, 2012 at 2:48 PM, Jeff Trawick wrote: > On Mon, Feb 27, 2012 at 5:57 PM, wrote: > > Author: minfrin > > Date: Mon Feb 27 22:57:18 2012 > > New Revision: 1294380 > > > > URL: http://svn.apache.org/viewvc?rev=1294380&view=rev > > Log: > > AIX: Add build scripts for AIX. > > Submitted by: Michael Felt > > Is this really ready? The trunk version (if even tested on trunk) at > best barely works, and this hasn't seen many eyes. > > Has the packaging of dependent libraries been figured out? Is there > really a such thing as "ASF.apu.rte and ASF.apr.rte filesets"? > Is it appropriate that a package built by a random user is labeled as > an "ASF" package, as if the ASF created it? > Is it appropriate to instruct users that in some cases they should > "add symbolic links from /usr/include to /opt/include"? > What about the todos regarding copyrights and licenses? > What about the trivial issue of hard-coding the version? (search for > "2.2.22") Presumably the real version is figured out later, but why > is this in there? > > Committing to trunk is one thing, but IMO before moving to stable > branches, especially 2.2.x, this needs careful review by at minimum > someone who is very familiar with AIX and will test it personally, and > hopefully by others who will ask the necessary questions to understand > the ramifications, and not end up having to repair the thing in > 2.2.(n+5)/2.4.(n+5) and break compatibility with previous versions. > > Hats off to Michael for working on this, but this contains a lot of > gory details to consider, and AFAIK no one who has logged onto an AIX > box since mid-2008 has stared at it enough to identify even the most > trivial of issues. > > > > > Added: > >httpd/httpd/branches/2.2.x/build/aix/ > >httpd/httpd/branches/2.2.x/build/aix/README > >httpd/httpd/branches/2.2.x/build/aix/aixinfo > >httpd/httpd/branches/2.2.x/build/aix/buildaix.ksh (with props) > >httpd/httpd/branches/2.2.x/build/aix/mkinstallp.ksh (with props) > > Modified: > >httpd/httpd/branches/2.2.x/config.layout > > > > Added: httpd/httpd/branches/2.2.x/build/aix/README > > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/build/aix/README?rev=1294380&view=auto > > > == > > --- httpd/httpd/branches/2.2.x/build/aix/README (added) > > +++ httpd/httpd/branches/2.2.x/build/aix/README Mon Feb 27 22:57:18 2012 > > @@ -0,0 +1,38 @@ > > +The script buildaix.ksh will attempt to build a AIX installp fileset > > +out of a source tree for ASF project > > + > > +REQUIREMENTS: > > + Fileset Level State Type Description > (Uninstaller) > > + > > > + bos.adt.insttools 5.3.7.2C FTool to Create > installp > > + Packages > > + Fileset Level State Type Description > (Uninstaller) > > + > > > + rpm.rte 3.0.5.41C FRPM Package Manager > > + > > +Additional: > > +Preferred: download zlib sources and copy zlib.h and zconf.h to > /opt/include > > +
Re: svn commit: r1294380 - in /httpd/httpd/branches/2.2.x: build/aix/ build/aix/README build/aix/aixinfo build/aix/buildaix.ksh build/aix/mkinstallp.ksh config.layout
On 28 Feb 2012, at 3:48 PM, Jeff Trawick wrote: > Is this really ready? The trunk version (if even tested on trunk) at > best barely works, and this hasn't seen many eyes. I don't have access to an AIX machine, so can only rely on Michael's judgement for this. Given that we aren't awash with AIX expertise, we need to put some trust in the person doing the packaging, the same as we do for Netware and other similar platforms. > Has the packaging of dependent libraries been figured out? Is there > really a such thing as "ASF.apu.rte and ASF.apr.rte filesets"? > Is it appropriate that a package built by a random user is labeled as > an "ASF" package, as if the ASF created it? I don't see why labeling it "ASF" is a problem. Anyone building the package would be doing so by following a formal procedure codified in the build script, which is in turn published by the ASF, as opposed some vendor's build script. > Is it appropriate to instruct users that in some cases they should > "add symbolic links from /usr/include to /opt/include"? It looks like zlib isn't necessarily available as a proper package. Given we don't ship zlib, but depend on it, if the platform has certain limitations regarding the availability of certain dependencies, we would need to work around that. > What about the todos regarding copyrights and licenses? What specifically about them? From what I can see, AIX packages offer the option to force the end user to accept a license before installing a package, and there is an open question as to whether we do this or not. We don't do it for RPM (nor does RPM let you do this), I see no reason to mandate doing it here. > What about the trivial issue of hard-coding the version? (search for > "2.2.22") Presumably the real version is figured out later, but why > is this in there? A mistake perhaps? Looks like VERSION is defined twice, once hard coded, and then a second time properly. Solution seems to be to remove the first attempt to set VERSION. > Committing to trunk is one thing, but IMO before moving to stable > branches, especially 2.2.x, this needs careful review by at minimum > someone who is very familiar with AIX and will test it personally, and > hopefully by others who will ask the necessary questions to understand > the ramifications, and not end up having to repair the thing in > 2.2.(n+5)/2.4.(n+5) and break compatibility with previous versions. > > Hats off to Michael for working on this, but this contains a lot of > gory details to consider, and AFAIK no one who has logged onto an AIX > box since mid-2008 has stared at it enough to identify even the most > trivial of issues. The build for v2.2.x will look nothing like the build for v2.4.x, and for this reason there is no way to apply changes to trunk, and then backport it, as each branch works completely differently, and therefore the build will work completely differently. If this is too much of a pain, working from a branch might be a better idea until these issues are solved. Regards, Graham --
Re: Was this thought through?
On Tue, Feb 28, 2012 at 12:16 PM, William A. Rowe Jr. wrote: > On 2/28/2012 10:46 AM, Jeff Trawick wrote: >> On Tue, Feb 28, 2012 at 11:40 AM, William A. Rowe Jr. >> wrote: >>> # /usr/local/bin/httpd -V >>> AH00534: httpd: Configuration error: No MPM loaded. >> >> if this post were from Joe User, I'd ask: >> >> what were your MPM-related configure arguments? >> are you using the httpd.conf created for that build or one from a >> different build? >> did you edit the MPM LoadModule directives in httpd.conf? >> >> IOW, how did you get here? maybe it makes sense, maybe it doesn't ;) > > I would have expected app -v or app -V to work whether it resolves > the externals or not. This is a typical result of install with static > mpm... toggle --enable-mpm-shared, re-make/make install. Of course > the stale conf file is left over, and is missing the mpm loadmodule. > > Without an MPM, the following do work (neither -M nor -V work), so > I guess we are fine about offering some minimal responses; I guess -V could be updated to display "(none loaded)" and skip the MPM query information. I don't see why that needs a working config. Big shrug on -M... If it is just a few lines of code, why not? (apachectl -M | grep mpm) > > # bin/httpd -v > Server version: Apache/2.4.1 (Unix) > Server built: Feb 28 2012 10:37:32 > > # bin/httpd -l > Compiled in modules: > core.c > mod_so.c > http_core.c > -- Born in Roswell... married an alien...
Re: Was this thought through?
On 2/28/2012 10:46 AM, Jeff Trawick wrote: > On Tue, Feb 28, 2012 at 11:40 AM, William A. Rowe Jr. > wrote: >> # /usr/local/bin/httpd -V >> AH00534: httpd: Configuration error: No MPM loaded. > > if this post were from Joe User, I'd ask: > > what were your MPM-related configure arguments? > are you using the httpd.conf created for that build or one from a > different build? > did you edit the MPM LoadModule directives in httpd.conf? > > IOW, how did you get here? maybe it makes sense, maybe it doesn't ;) I would have expected app -v or app -V to work whether it resolves the externals or not. This is a typical result of install with static mpm... toggle --enable-mpm-shared, re-make/make install. Of course the stale conf file is left over, and is missing the mpm loadmodule. Without an MPM, the following do work (neither -M nor -V work), so I guess we are fine about offering some minimal responses; # bin/httpd -v Server version: Apache/2.4.1 (Unix) Server built: Feb 28 2012 10:37:32 # bin/httpd -l Compiled in modules: core.c mod_so.c http_core.c
Re: Was this thought through?
On Tue, Feb 28, 2012 at 11:40 AM, William A. Rowe Jr. wrote: > # /usr/local/bin/httpd -V > AH00534: httpd: Configuration error: No MPM loaded. if this post were from Joe User, I'd ask: what were your MPM-related configure arguments? are you using the httpd.conf created for that build or one from a different build? did you edit the MPM LoadModule directives in httpd.conf? IOW, how did you get here? maybe it makes sense, maybe it doesn't ;)
Was this thought through?
# /usr/local/bin/httpd -V AH00534: httpd: Configuration error: No MPM loaded.
Re: [proposed] remove docs/1.3/
On Feb 26, 2012, at 12:52 PM, Nick Kew wrote: >> We're already using the >> >> http://httpd.apache.org/docs/current/"/> >> >> to tell Google not to index the pages, although that's not (yet) on all of >> the 1.3 doc pages - Unfortunately that's something of a manual process due >> to the fact that the 1.3 docs are in HTML, not generated, and that not every >> page in the 1.3 docs has an exact corollary in the /current/ docs. > > WTF? > > That's what robots.txt is for! Surely we can use that to stop indexing 2.0 > as well as 1.3? Maybe even 2.2 once 2.4 is windows-ready and in the distros? The rel canonical thing is a way to actively update the Google index for a particular page and search term, and has been very effective in updating certain searches. For example, searching Google for "rewriterule" has long given the 1.3 Rewrite Guide, but within 24 hours of adding a rel canonical tag, it started pointing to the 2.2 mod_rewrite docs as the top hit. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: svn commit: r1294600 - /httpd/httpd/branches/2.4.x/modules/loggers/mod_log_config.c
On Tue, Feb 28, 2012 at 8:42 AM, Jim Jagielski wrote: > > On Feb 28, 2012, at 7:14 AM, Jeff Trawick wrote: > >> On Tue, Feb 28, 2012 at 7:06 AM, wrote: >>> Author: jim >>> Date: Tue Feb 28 12:06:53 2012 >>> New Revision: 1294600 >>> >>> URL: http://svn.apache.org/viewvc?rev=1294600&view=rev >>> Log: >>> Merge r1243651 from trunk: >>> >>> Check during config test that directories for access logs exist >>> >>> PR 29941 >> >> CH CH CH CH CHANGES >> >> (some of the recent trunk fixes didn't have that, probably in >> anticipation of having to remove it from trunk CHANGES in the short >> term when merged to 2.4.x) >> > > Most likely... but since CHANGES, as with most docs, are CTR, > this shouldn't be a blocker or deep concern, imo. Fixing CHANGES is part of the merge-to-stable-branch workflow. Miss it then and it is too easy to forget about. (Presumably me complaining will result in the last couple of CHANGE-less backported fixes getting tweaked appropriately ;) )
Re: svn commit: r1294380 - in /httpd/httpd/branches/2.2.x: build/aix/ build/aix/README build/aix/aixinfo build/aix/buildaix.ksh build/aix/mkinstallp.ksh config.layout
On Mon, Feb 27, 2012 at 5:57 PM, wrote: > Author: minfrin > Date: Mon Feb 27 22:57:18 2012 > New Revision: 1294380 > > URL: http://svn.apache.org/viewvc?rev=1294380&view=rev > Log: > AIX: Add build scripts for AIX. > Submitted by: Michael Felt Is this really ready? The trunk version (if even tested on trunk) at best barely works, and this hasn't seen many eyes. Has the packaging of dependent libraries been figured out? Is there really a such thing as "ASF.apu.rte and ASF.apr.rte filesets"? Is it appropriate that a package built by a random user is labeled as an "ASF" package, as if the ASF created it? Is it appropriate to instruct users that in some cases they should "add symbolic links from /usr/include to /opt/include"? What about the todos regarding copyrights and licenses? What about the trivial issue of hard-coding the version? (search for "2.2.22") Presumably the real version is figured out later, but why is this in there? Committing to trunk is one thing, but IMO before moving to stable branches, especially 2.2.x, this needs careful review by at minimum someone who is very familiar with AIX and will test it personally, and hopefully by others who will ask the necessary questions to understand the ramifications, and not end up having to repair the thing in 2.2.(n+5)/2.4.(n+5) and break compatibility with previous versions. Hats off to Michael for working on this, but this contains a lot of gory details to consider, and AFAIK no one who has logged onto an AIX box since mid-2008 has stared at it enough to identify even the most trivial of issues. > > Added: > httpd/httpd/branches/2.2.x/build/aix/ > httpd/httpd/branches/2.2.x/build/aix/README > httpd/httpd/branches/2.2.x/build/aix/aixinfo > httpd/httpd/branches/2.2.x/build/aix/buildaix.ksh (with props) > httpd/httpd/branches/2.2.x/build/aix/mkinstallp.ksh (with props) > Modified: > httpd/httpd/branches/2.2.x/config.layout > > Added: httpd/httpd/branches/2.2.x/build/aix/README > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/build/aix/README?rev=1294380&view=auto > == > --- httpd/httpd/branches/2.2.x/build/aix/README (added) > +++ httpd/httpd/branches/2.2.x/build/aix/README Mon Feb 27 22:57:18 2012 > @@ -0,0 +1,38 @@ > +The script buildaix.ksh will attempt to build a AIX installp fileset > +out of a source tree for ASF project > + > +REQUIREMENTS: > + Fileset Level State Type Description (Uninstaller) > + > > + bos.adt.insttools 5.3.7.2 C F Tool to Create installp > + Packages > + Fileset Level State Type Description (Uninstaller) > + > > + rpm.rte 3.0.5.41 C F RPM Package Manager > + > +Additional: > +Preferred: download zlib sources and copy zlib.h and zconf.h to /opt/include > +and, if configure cannot find them directly, add symbolic links from > /usr/include to /opt/include > + > +To build a package, make sure you are in the root of the source tree, > +and run: > + > +build/aix/buildaix.ksh > + > +An AIX fileset named $PKG.$NAME.$ARCH.$VERSION.I will be > +created in the build/aix directory. the .template file created is also there. > + > +KNOWN issues: > +on AIX libtool is known to have issues with the install command. > +Some of these issues have been resolved by extracting the apr/apu utilities > +from the projects (i.e. NOT using the embedded version) > +In case of problems I recommend that you install the GNU 'install' program > (part of coreutils) > +If make DESTDIR=$TEMPDIR install command continues to fail, try 'make > install' and then run > +the buildaix.ksh command again > + > +TODO > +Add Copyright display/banner > +Add Apache LICENSE to fileset and require acceptance > +Add special instructions for TCB - to ignore /etc/* /var/httpd/htdocs/* > +Add _config_i scripts to setup autostart > +Add _pre_i scripts to verify pre-requisites, required users/groups, etc. > > Added: httpd/httpd/branches/2.2.x/build/aix/aixinfo > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/build/aix/aixinfo?rev=1294380&view=auto > == > --- httpd/httpd/branches/2.2.x/build/aix/aixinfo (added) > +++ httpd/httpd/branches/2.2.x/build/aix/aixinfo Mon Feb 27 22:57:18 2012 > @@ -0,0 +1,16 @@ > + > +PKG="ASF" > +NAME="httpd" > +ARCH="powerpc" > +VERSION="2.2.22" > +CATEGORY="application" > +VENDOR="Apache Software Foundation" > +EMAIL="dev@httpd.apache.org" > +VMMN=`build/get-version.sh mmn include/ap_mmn.h MODULE_MAGIC_NUMBER` > +REVISION=`build/get-version.sh all include/ap_release.h AP_SERVER` > +VERSION=`echo $REVISION | cut -d- -s -f1` > +RELEASE=
Re: svn commit: r1294600 - /httpd/httpd/branches/2.4.x/modules/loggers/mod_log_config.c
On Feb 28, 2012, at 7:14 AM, Jeff Trawick wrote: > On Tue, Feb 28, 2012 at 7:06 AM, wrote: >> Author: jim >> Date: Tue Feb 28 12:06:53 2012 >> New Revision: 1294600 >> >> URL: http://svn.apache.org/viewvc?rev=1294600&view=rev >> Log: >> Merge r1243651 from trunk: >> >> Check during config test that directories for access logs exist >> >> PR 29941 > > CH CH CH CH CHANGES > > (some of the recent trunk fixes didn't have that, probably in > anticipation of having to remove it from trunk CHANGES in the short > term when merged to 2.4.x) > Most likely... but since CHANGES, as with most docs, are CTR, this shouldn't be a blocker or deep concern, imo.
Re: can't compile module with apxs
On Mon, 27 Feb 2012 17:13:52 +0800 Rui Hu wrote: > Should I add some compile parameters in apxs? No, but you should probably have posted to the modules-dev list rather than here. It's not a compile problem, it's a design problem. You're trying to use data that's private to another module. That means you lose all API support, and a change in the core could break your 'module' at any time (and consequently you can't in good faith supply it to any third-parties as a module, because it'll prevent them upgrading). Your options are: 1. Redesign your module not to need core internals. 2. Copy the relevant declarations, and live with the consequences. 3. Propose a change to the core API to expose whatever you need. Your best option is probably the first. -- Nick Kew
Re: [proposed] remove docs/1.3/
On Sun, 26 Feb 2012 12:30:48 -0500 Rich Bowen wrote: > We're already using the > > http://httpd.apache.org/docs/current/"/> > > to tell Google not to index the pages, although that's not (yet) on all of > the 1.3 doc pages - Unfortunately that's something of a manual process due to > the fact that the 1.3 docs are in HTML, not generated, and that not every > page in the 1.3 docs has an exact corollary in the /current/ docs. WTF? That's what robots.txt is for! Surely we can use that to stop indexing 2.0 as well as 1.3? Maybe even 2.2 once 2.4 is windows-ready and in the distros? > Prior to doing that, there are some changes that we need to make the pointers > in them to the current docs actually go the right place. Some of the pages > reference 2.2 as the current version, and also /current/ still points to 2.2. > So, give us a moment to resolve those two issues … http://httpd.apache.org/docs/1.3/";> The current version of the server is 2.2. -- Nick Kew
Re: svn commit: r1294600 - /httpd/httpd/branches/2.4.x/modules/loggers/mod_log_config.c
On Tue, Feb 28, 2012 at 7:06 AM, wrote: > Author: jim > Date: Tue Feb 28 12:06:53 2012 > New Revision: 1294600 > > URL: http://svn.apache.org/viewvc?rev=1294600&view=rev > Log: > Merge r1243651 from trunk: > > Check during config test that directories for access logs exist > > PR 29941 CH CH CH CH CHANGES (some of the recent trunk fixes didn't have that, probably in anticipation of having to remove it from trunk CHANGES in the short term when merged to 2.4.x)
