Re: libapreq 2.12 failing with apache 2.2.14

2010-02-25 Thread David E. Wheeler 
Howdy,

Just built libapreq 2.12 on 64 bit CentOS 5.4 with Perl 5.10.1 and Apache 
2.2.14, and found two things I wanted to follow up on here:

1. The build initially failed with this error:

   /usr/lib/libexpat.so: could not read symbols: File in wrong format

   This appears to be because I have 64 bit Apache and apreq, but that library 
is 32 bit. To get apreq to use the 64 bit version, I had to configure like so:

   LDFLAGS=-L/usr/lib64 ./configure --with-apache2-apxs=/path/to/apxs

   So is there some way that apreq2's configure script could be updated to look 
for /usr/lib64 and perhaps /lib64 and /usr/local/lib64 on 64 bit platforms?

2. I got a bunch of Perl test failures, but it looks like they were known. It 
doesn't look like this patch has been applied yet:

   http://marc.info/?l=apreq-dev&m=125501679623914

Should it be?

Thanks,

David

Re: libapreq 2.12 failing with apache 2.2.14

2009-10-08 Thread Joe Schaefer 
- Original Message 

> From: Clinton Gormley 
> To: apreq-dev 
> Sent: Wednesday, October 7, 2009 6:19:44 AM
> Subject: Re: libapreq 2.12 failing with apache 2.2.14
> 
> > I'm installing apache 2.2.14 with libapreq 2.12, perl 5.8.9 and I'm
> > getting the failures listed below. 
> 
> OK - turns out all of the failures are about the file type:
>   expected: text/x-pod
>   received: text/x-plain
> 
> Although, I don't understand how the mime type could ever be text/x-pod.
> 
> The test uses UPLOAD_BODY to upload the file, which in turn relies (via
> HTTP::Request::Common) on LWP::MediaTypes, which has no definition for
> text/x-pod.

LWP recently changed the LWP/media.types file, pulling the cooked definition
for the .pod extension.  The reason it's now text/plain (not text/x-plain) is
because LWP::MediaTypes guesses the content type using the "-T" function in 
perl.

Can you write a patch for our tests that just checks for "text/*"?

> 
> Is this just a bad test?

Well they're dependent on LWP not being stupid with mime types and changing them
without any notice.  The fails aren't in any indicative of a problem with 
apreq's
codebase.

Re: libapreq 2.12 failing with apache 2.2.14

2009-10-07 Thread Mark Hedges 

> If you were referring to 5.10*, I can't use that version
> because of certain bugs that haven't been fixed - they
> keep throwing errors in my app.

Duh yeah that's what I meant.

I know with 5.8.8 there were a lot of problems because of a
bug in ExtUtils::ParseXS, there was a recent fix that was
supposed to fix this, does it help to upgrade that and/or
other core ExtUtils modules?

Mark