Here is the patch - as text, and a file (not sure what normal is, but since
it is small doing both).
I moved $DLNAME != $TARGET_NAME test up because it seems more logical to
try and let this bit resolve
any issue before testing for the existance of $TARGET_NAME
Then, if $TARGET_NAME is still miss
On Jun 20, 2014, at 12:35 PM, Michael Felt wrote:
> At least, I am assuming this to be the problem - because I am assuming the
> expectation is that $TARGET_NAME has been installed - unless DLNAME !=
> TARGET_NAME - because in that case DLNAME gets moved.
>
> Unfortunately, what has been instal
Revisiting.
First I looked at apxs using perl debug mode:
Getting to the core: it looks like apxs is working fine:
It gets to where it calls instdso.sh and the second command (chmod) fails.
DB<1>
apxs::(/opt/httpd/sbin/apxs:525): &execute_cmds(@cmds);
DB<1> x @cmds
0 '/var/httpd/bu
However, in general, I agree w/ the basic idea of having
bitfields defined as unsigned ints, not because I like
the idea of somehow using these bitfields as "tiny"
signed ints but because it's better for packing and
alignment purposes.
So I'm not against the commit at all.
We are using, afaik, al
What I meant was "true or false"... Sorry for the confusion.
On Jun 20, 2014, at 9:06 AM, Yann Ylavic wrote:
> I can't agree with you on this.
>
> You first say a bit is either 0 or 1, which is not true for a signed
> bit (0 or -1), and confirms somehow we should use unsigned here.
> A good com
I can't agree with you on this.
You first say a bit is either 0 or 1, which is not true for a signed
bit (0 or -1), and confirms somehow we should use unsigned here.
A good compiler should also complain about setting 1 to something that
can only take 0 or -1, and we did that before this commit.
Th
Besides that, any compiler worth its salt should complain.
On Jun 20, 2014, at 7:50 AM, Jim Jagielski wrote:
> Who does that w/ bit fields? You either check if it's
> true/false or you use the expected bit operations.
>
> On Jun 19, 2014, at 9:29 AM, Yann Ylavic wrote:
>
>> On Thu, Jun 19, 20
Who does that w/ bit fields? You either check if it's
true/false or you use the expected bit operations.
On Jun 19, 2014, at 9:29 AM, Yann Ylavic wrote:
> On Thu, Jun 19, 2014 at 2:59 PM, Jim Jagielski wrote:
>>
>> On Jun 19, 2014, at 8:43 AM, yla...@apache.org wrote:
>>
>>> Author: ylavic
>>
On Fri, Jun 20, 2014 at 1:21 AM, Christophe JAILLET
wrote:
> Hi,
>
> while looking at backport candidate to synch 2.4 and trunk, I found this
> commit.
>
> It seems harmless to me, so could be a good candidate.
> Actually, it should be no use in module provided with apache, because none
> seems to
Thanks for your patch (and patience).
Commited in http://svn.apache.org/r1604123.
On Fri, Jun 20, 2014 at 11:40 AM, Mario Brandt wrote:
> Hi,
>
> I had filed a bug[1] about mod fcgid polluting my apache error log.
> So far no commiter had reviewed my patch.
>
> Can someone please take a look that
Hi,
I had filed a bug[1] about mod fcgid polluting my apache error log.
So far no commiter had reviewed my patch.
Can someone please take a look that patch?
My logs have tons of lines like
[Fri Jun 20 11:16:32.321859 2014] [fcgid:warn] [pid 2828:tid 504]
mod_fcgid: process 7404 graceful kill fai
11 matches
Mail list logo
