Re: compiling on fedora core 14
On Tue, 2010-11-02 at 23:16 -0400, Paul Lockaby wrote: However, I do not know how to fix it. Has anyone else determined how to solve this problem? Are there plans to update libapreq2 to address this change in Fedora? You may to try look at these: http://pkgs.fedoraproject.org/gitweb/?p=libapreq2.git Obviously, Fedora packages build, so there must be a solution there. -- Bojan
Re: can't build mod_perl2, libapreq2 glue test failures in perl 5.8.8 after cpan upgrades
On Thu, 2009-07-23 at 18:40 -0700, Mark Hedges wrote: Argh why do they try to backport bugfixes to three-year old Apache 2.2.3 instead of using current stable minor revision 2.2.11? *tears out hair* Better question: why is RHEL6 not out yet ;-) -- Bojan
Re: libapreq2-2.12 +gmake on HP UX
On Tue, 2009-06-09 at 09:19 +0100, mmm zzz wrote: gcc: +b: No such file or directory From memory, +b may be an option used by HP-UX specific linker, so maybe GCC gets confused and sees it as a file. Don't have a box to try any more... Maybe you need to give it -Wl,+b instead? -- Bojan
Re: libapreq2-2.12 +gmake on HP UX
On Tue, 2009-06-09 at 10:44 +0100, mmm zzz wrote: I'm just a newbie in the compilation and don't know a lot in the compilers options and can't deside what to add or to remove to be able to finish the compilation in HP with GCC or CC. I'm guessing you'll need to have a good GCC installed (when I was working with the platform, one from HP gave me good results). Also, you'll need to have gmake. I also found that unless the machines were patched properly (i.e. brought up to date), many things would fail. Unfortunately, I don't have access to that platform any more, so I cannot really test. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.12 RC2
On Fri, 2009-03-06 at 11:35 -0800, Joe Schaefer wrote: Please test and vote on http://people.apache.org/~joes/libapreq2-2.12-RC2.tar.gz http://people.apache.org/~joes/libapreq2-2.12-RC2.tar.gz.asc Compiles and runs all tests successfully on F-10. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.12 RC2
On Sat, 2009-03-07 at 10:34 +1100, Bojan Smojver wrote: On Fri, 2009-03-06 at 15:25 -0800, Joe Schaefer wrote: Is that a +1 to release, or not yet? I'll try to build some RPMs from it first and report back. +1. Builds OK as RPM on F-10 and F-11. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.11
On Tue, 2009-02-17 at 08:47 +0200, Issac Goldstand wrote: I'm all for calling 2.11 a dud and restarting with 2.12 Version numbers are cheap - go for it. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.11
On Thu, 2009-01-29 at 14:53 -0500, Philip M. Gollucci wrote: I built from SVN or do you mean you'll add a patch to the rpm after release ? I thought you were referring to current RPM build/install there. If there is a problem with build/install on CentOS from source and we know how to fix it, we should do it before we push the release out the door. Version numbers are cheap. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.11
On Thu, 2009-01-29 at 13:53 -0800, Joe Schaefer wrote: That is bunk. We shoul NEVER try to support svn builds for releases, because that makes us dependent on whatever autocruft is on CentOS. It also doesn't help diddly squat when testing a potential candidate for release, since those are bundled by the RM's autotools. Please use the ACTUAL tarball when filing bug reports against a release. Thanks! Initially, I thought Philip was telling me that something is busted with RPM spec files (i.e. build/install on CentOS), so I wanted to fix that. What I was referring to in my second post when I said building from source was also the tarball, but your regular get source, configure, make, make install build, not an RPM build. Sorry, I wasn't making myself clear. -- Bojan
Re: next release lets go!
On Mon, 2009-01-19 at 23:06 -0500, Philip M. Gollucci wrote: If not, I'm tempted to roll it tomorrow day-time unless someone else beats me to it. Go ahead and roll. If you don't make it, I'll jump in later in the week. -- Bojan
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
On Mon, 2009-01-12 at 06:32 -0800, Joe Schaefer wrote: Are you planning to pursue 2.10 as RM or should we be moving on to 2.11? The only outstanding issue I am aware of is pgollucci's claim that the perl modules aren't linking correctly to libapreq2 on Solaris. While that would be nice to fix, I don't consider it a showstopper either. I'm kinda waiting for the outcome of that discussion on the list before we go ahead. From what I can see, current decision is to have 2.11 released, right? If so, let's roll that (I'm not attached to version numbers in any way). -- Bojan
Re: Should we release 2.10?
On Thu, 2008-11-27 at 01:40 -0500, Philip M. Gollucci wrote: Committed revision 721096. Backported to branches/2_10 721099. Let me know when you backport all the stuff you wanted to get from the trunk and I'll roll RC2. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.10 RC1
On Wed, 2008-11-19 at 04:34 -0500, Philip M. Gollucci wrote: its 4:30am and I've not look at this code in a while, the debugging will have to wait. Also, I I'm pretty sure I want to merge 1-2 things from trunk to 2.10 that are low risk but important. Cool. That's why we have RCs after all :-) -- Bojan
Re: Should we release 2.10?
On Fri, 2008-11-14 at 09:10 -0500, Adam Prime wrote: I was reminded of a documentation omission by an email on the mod_perl list this morning. Can something be added into the porting warnings here: http://httpd.apache.org/apreq/docs/libapreq2/group__apreq__xs__request.html mentioning that my @params = $r-param() no long returns a unique list of the params. IE that ?a=ba=c will return (a, a), not (a), which is how it worked in libapreq1. Sure. Do you have a patch? -- Bojan
Re: svn commit: r712936 - in /httpd/apreq/trunk: CHANGES STATUS
On Tue, 2008-11-11 at 17:00 +1100, Bojan Smojver wrote: OOPS, sorry. The trunk has been reverted to version 2.10 for now. -- Bojan
Re: Should we release 2.10?
On Mon, 2008-11-10 at 22:56 -0500, Philip M. Gollucci wrote:
Probably a good thing, I'm not sure what the differences are.
[are all my solaris fixes on the 2_10 branch ?]
Here you go...
--
Bojan
diff -rauN --exclude=.svn apreq-2.10/CHANGES apreq/CHANGES
--- apreq-2.10/CHANGES 2008-11-11 14:59:51.0 +1100
+++ apreq/CHANGES 2008-11-14 13:27:55.0 +1100
@@ -2,7 +2,7 @@
//! brief List of major changes.
[EMAIL PROTECTED] v2_10 Changes with libapreq2-2.10 (released Nov 11, 2008)
[EMAIL PROTECTED] v2_10 Changes with libapreq2-2.10 (under developement)
- Perl Glue Build [Philip M. Gollucci]
config.status format changed format yet again in autoconf 2.62+.
diff -rauN --exclude=.svn apreq-2.10/include/apreq_version.h apreq/include/apreq_version.h
--- apreq-2.10/include/apreq_version.h 2008-06-05 10:40:24.0 +1000
+++ apreq/include/apreq_version.h 2008-11-14 13:28:01.0 +1100
@@ -68,7 +68,8 @@
* This symbol is defined for internal, development copies of libapreq.
* This symbol will be \#undef'd for releases.
*/
-#undef APREQ_IS_DEV_VERSION
+#define APREQ_IS_DEV_VERSION
+
/** The formatted string of libapreq's version */
#define APREQ_VERSION_STRING \
diff -rauN --exclude=.svn apreq-2.10/module/t/TEST.PL apreq/module/t/TEST.PL
--- apreq-2.10/module/t/TEST.PL 2008-06-05 10:40:26.0 +1000
+++ apreq/module/t/TEST.PL 2008-11-14 13:28:05.0 +1100
@@ -71,7 +71,7 @@
if (WIN32) {
require File::Spec;
-my @goners = map {$name . '.' . $_} qw(exp ilk lib pdb so lo);
+my @goners = map {$name . '.' . $_} qw(exp ilk lib pdb so lo so.manifest);
my $libs = join ' ',
(map {'-l' . File::Spec-catfile($mod_apreq2_dir, $_)}
qw(libapreq2.lib mod_apreq2.lib));
diff -rauN --exclude=.svn apreq-2.10/STATUS apreq/STATUS
--- apreq-2.10/STATUS 2008-11-11 14:59:02.0 +1100
+++ apreq/STATUS 2008-11-14 13:27:55.0 +1100
@@ -1,6 +1,6 @@
/** @page apreq_status STATUS
-2.10 released 11-Nov-08
+2.10 under developement
Contributors looking for a mission:
diff -rauN --exclude=.svn apreq-2.10/win32/Configure.pl apreq/win32/Configure.pl
--- apreq-2.10/win32/Configure.pl 2008-06-05 10:40:29.0 +1000
+++ apreq/win32/Configure.pl 2008-11-14 13:29:53.0 +1100
@@ -37,12 +37,16 @@
generate_tests($apreq_home, [EMAIL PROTECTED]);
my %apr_libs;
-my %map = (apr = 'libapr.lib', apu = 'libaprutil.lib');
+my $prog = apache_prog_name($apache);
+my @httpd_ver = httpd_version($prog);
my $devnull = devnull();
+my %map = (
+apr = $httpd_ver[1] == 2 ? 'libapr-1.lib' : 'libapr.lib',
+apu = $httpd_ver[1] == 2 ? 'libaprutil-1.lib' : 'libaprutil.lib'
+);
-my $prog = apache_prog_name($apache);
foreach my $what (qw(apr apu)) {
-my $ap = ($prog eq 'httpd.exe') ?
+my $ap = ($httpd_ver[1] == 2) ?
$what-1-config.bat : $what-config.bat;
my $cfg = catfile $apache, 'bin', $ap;
my $lib;
@@ -110,6 +114,8 @@
$(RM_F) *.pch *.exe *.exp *.lib *.pdb *.ilk *.idb *.so *.dll *.obj *.manifest
cd $(TDIR)
$(RM_F) *.pch *.exe *.exp *.lib *.pdb *.ilk *.idb *.so *.dll *.obj *.manifest
+cd $(APREQ_HOME)\module\t\c-modules
+$(MAKE) clean
cd $(APREQ_HOME)
!IF EXIST($(PERLGLUE)\Makefile)
cd $(PERLGLUE)
@@ -308,6 +314,14 @@
return;
}
+sub httpd_version {
+my $prog = shift;
+my $vers = qx{$prog -v};
+die qq{Could not parse $apache version}
+unless $vers =~ m!Apache/2.(\d).(\d)!;
+return (2, $1, $2);
+}
+
sub generate_defs {
my $preamble ='END';
LIBRARY
@@ -411,8 +425,9 @@
my $apache = shift;
my $prog;
for my $trial(qw(Apache.exe httpd.exe)) {
-next unless -e catfile($apache, 'bin', $trial);
-$prog = $trial;
+my $path = catfile($apache, 'bin', $trial);
+next unless -e $path;
+$prog = $path;
last;
}
die Could not determine the Apache2 binary name unless $prog;
diff -rauN --exclude=.svn apreq-2.10/win32/libapreq2.mak apreq/win32/libapreq2.mak
--- apreq-2.10/win32/libapreq2.mak 2008-06-05 10:40:29.0 +1000
+++ apreq/win32/libapreq2.mak 2008-11-14 13:28:13.0 +1100
@@ -68,9 +68,7 @@
$(INTDIR)\module_custom.obj \
$(INTDIR)\module_cgi.obj \
$(INTDIR)\error.obj \
- $(INTDIR)\libapreq.res \
- $(APR_LIB) \
- $(APU_LIB)
+ $(INTDIR)\libapreq.res
!IF $(CFG) == libapreq2 - Win32 Release
@@ -87,7 +85,7 @@
BSC32_FLAGS=/nologo /o$(OUTDIR)\libapreq2.bsc
LINK32=link.exe
MANIFEST=$(OUTDIR)\libapreq2.dll.manifest
-LINK32_FLAGS=kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /incremental:no /machine:I386 /out:$(OUTDIR)\libapreq2.dll /implib:$(OUTDIR)\libapreq2.lib
+LINK32_FLAGS=$(APR_LIB) $(APU_LIB) kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
Re: Should we release 2.10?
On Wed, 2008-11-12 at 10:36 +1100, Bojan Smojver wrote: We should find out what's going on with this before the release. What I've discovered so far is that mod_apreq_output_filter_test.c gets the correctly parsed content from apreq machinery and puts all that in the brigade. But, upon ap_pass_brigade(f-next,bb) call, some of the content is mysteriously dropped when the connection over SSL. This will require further debugging... -- Bojan
Re: Should we release 2.10?
On Wed, 2008-11-12 at 20:31 +1100, Bojan Smojver wrote: This will require further debugging... After employing mod_dumpio, it seems that Apache actually outputs everything out, even over SSL. I have no idea how and why it doesn't show up in the client (i.e. as reported by request.t). Maybe something to do with the Perl test suite? Opinions? -- Bojan
Re: Should we release 2.10?
On Wed, 2008-11-12 at 23:08 -0500, Philip M. Gollucci wrote: Apache-Test definitely jumps through hoops for SSL. Are your perl SSL CPANs up-to-date ? Whatever Fedora 9 has, I have. Whether that's most up to date, I don't know. I think I should just put out an RC tarball and let people test. Then we'll know what's going on. -- Bojan
[RELEASE CANDIDATE] libapreq2 2.10 RC1
It has been over two years since the latest apreq2 release, so it is time to get some new code out the door. Numerous bugs were fixed (see the full list in the CHANGES file) since the last official release (2.08), so please give us feedback on this release candidate. You can get the tarball, its signature and MD5 checksum from here: http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz.asc http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz.md5 Please report any problems back to the list: apreq-dev@httpd.apache.org -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.10 RC1
On Thu, 2008-11-13 at 17:29 +1100, Bojan Smojver wrote: It has been over two years since the latest apreq2 release, so it is time to get some new code out the door. Numerous bugs were fixed (see the full list in the CHANGES file) since the last official release (2.08), so please give us feedback on this release candidate. You can get the tarball, its signature and MD5 checksum from here: http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz.asc http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz.md5 Please report any problems back to the list: apreq-dev@httpd.apache.org Could people subscribed to mod_perl and httpd lists please forward this e-mail there. Thanks! -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.10 RC1
On Thu, 2008-11-13 at 02:01 -0500, Philip M. Gollucci wrote: (ahh, you were in unix group httpd, I've just added you) I am not an httpd committer. I only have commit rights to apreq directory. -- Bojan
Re: Should we release 2.10?
On Tue, 2008-11-11 at 18:41 +1100, Bojan Smojver wrote: BTW, 2.08 and 2.09-rc2 fail exactly the same on my box. Something must be screwed in my setup... When I run the tests against vanilla httpd (instead of Fedora supplied one), the number of tests drops to 82 (as opposed to 121 with Fedora supplied httpd) and all those pass. So, there must be some functionality that I didn't compile into vanilla httpd that is screwing up the tests. -- Bojan
Re: Should we release 2.10?
On Wed, 2008-11-12 at 09:38 +1100, Bojan Smojver wrote: These two tests fail when SSL is enabled. Indeed, things get chopped off. I'm attaching an example from test 34. The files 1.e and 1.r are expected/received content, respectively, that the test sees over regular HTTP. The files 2.e and 2.r are the same over HTTPS. You'll notice immediately that 2.r is significantly smaller than 2.e. Similarly, in test 36 things get chopped off again. We should find out what's going on with this before the release. -- Bojan tests.tar.bz2 Description: application/bzip-compressed-tar
Re: Should we release 2.10?
On Mon, 2008-11-10 at 22:45 -0500, Philip M. Gollucci wrote: did you see the [EMAIL PROTECTED] post ? No, not really. I don't normally follow that list, as my Perl really, really sucks (did I mention my Perl really sucks? ;-)). If you want to volunteer RM for one of them, I'll take the other. I use 2.x, so I can volunteer for that. -- Bojan
Re: Should we release 2.10?
On Mon, 2008-11-10 at 23:46 -0500, Philip M. Gollucci wrote: Is that with $ make test TEST_VERBOSE=1 Fails in exactly the same way as make release_test. -- Bojan
Re: svn commit: r712936 - in /httpd/apreq/trunk: CHANGES STATUS
On Tue, 2008-11-11 at 07:51 +0200, Issac Goldstand wrote: Whoa -0.9 Update release info *after* the RCs pass muster. The release only happens after the votes - I'm pretty sure that that's in the RELEASE file (otherwise 1.34 would have a release date of 2006 ;-p) OOPS, sorry. -- Bojan
Re: Should we release 2.10?
On Tue, 2008-11-11 at 08:02 +0200, Issac Goldstand wrote: I'm gonna play with my version too. I'll shout if I get something working (and you do the same?) OK. -- Bojan
Re: Should we release 2.10?
On Tue, 2008-11-11 at 15:54 +1100, Bojan Smojver wrote: On Mon, 2008-11-10 at 23:46 -0500, Philip M. Gollucci wrote: Is that with $ make test TEST_VERBOSE=1 Fails in exactly the same way as make release_test. BTW, 2.08 and 2.09-rc2 fail exactly the same on my box. Something must be screwed in my setup... -- Bojan
Re: Should we release 2.10?
On Fri, 2008-07-11 at 18:46 +0300, Eli Marmor wrote: DON'T FORGET TO MERGE THE ENHANCED-CGI !!! Do you have a link? -- Bojan
Should we release 2.10?
Is there anything that needs to be addressed still before we roll this? It's been a long time since the last stable release, I think we should go ahead and get something out the door... -- Bojan
Re: Endless loop in split_on_bdry() of library/parser_multipart.c?
On Wed, 2008-06-04 at 21:35 -0700, Joe Schaefer wrote: Needs a comment in the source about why we're using volatile here, but otherwise +1. Done on both the trunk and v2_10 branch. Any comment regarding my other patch about strict aliasing warnings? -- Bojan
Re: Endless loop in split_on_bdry() of library/parser_multipart.c?
I propose we fix this as attached. I tested this on Fedora 9 and it
works OK. Opinions?
--
Bojan
Index: library/parser_multipart.c
===
--- library/parser_multipart.c (revision 663420)
+++ library/parser_multipart.c (working copy)
@@ -162,11 +162,13 @@
* so we can move previous buckets across
* and retest buf against the full bdry.
*/
+apr_bucket_brigade * volatile in_v = in;
+
do {
-apr_bucket *f = APR_BRIGADE_FIRST(in);
+apr_bucket *f = APR_BRIGADE_FIRST(in_v);
APR_BUCKET_REMOVE(f);
APR_BRIGADE_INSERT_TAIL(out, f);
-} while (e != APR_BRIGADE_FIRST(in));
+} while (e != APR_BRIGADE_FIRST(in_v));
off = 0;
goto look_for_boundary_up_front;
}
Index: acinclude.m4
===
--- acinclude.m4 (revision 663420)
+++ acinclude.m4 (working copy)
@@ -214,7 +214,6 @@
])
# -Wdeclaration-after-statement is only supported on gcc 3.4+
fi
-APR_ADDTO([CFLAGS], -fno-strict-aliasing)
APR_ADDTO([CPPFLAGS], `$APR_CONFIG --cppflags`)
Re: BUG: Problem with latest subversion libapreq2 on linux 64 bit amd (segfault accessing handle variable)
On Wed, 2008-05-07 at 11:20 -0400, Zero Altitude wrote: The segfault appears to be due to handle having an illegal-to-read memory address by the time its module member is referenced. I do not appear to be doing anything untoward with respect to initializing apreq, and so my current, defeasible, assumption is that the bug is somewhere in the apreq library. Try to set a watchpoint in GDB (while running the program) to see what actually stomps over it. -- Bojan
Re: BUG: Problem with latest subversion libapreq2 on linux 64 bit amd (segfault accessing handle variable)
On Thu, 2008-05-08 at 02:16 -0400, Zero Altitude wrote: I apologize: can you clarify the watchpoint suggestion? If you mean while running the program as in, while apache is still running and not crashed, this is virtually impossible -- as I said, the segfault occurs only once in a few thousand uploads. Yes. Obviously, don't use the production machine for this. Rather, set up a test instance somewhere and then hit it with a lot of uploads (you should be able to use ab for that). Watchpoint in GDB enable you to see when things change. Like this: - You can use a watchpoint to stop execution whenever the value of an expression changes, without having to predict a particular place where this may happen. (This is sometimes called a data breakpoint.) The expression may be as simple as the value of a single variable, or as complex as many variables combined by operators. Examples include: * A reference to the value of a single variable. * An address cast to an appropriate data type. For example, `*(int *)0x12345678' will watch a 4-byte region at the specified address (assuming an `int' occupies 4 bytes). * An arbitrarily complex expression, such as `a*b + c/d'. The expression can use any operators valid in the program's native language (*note Languages::). - So, in your case, see when handle becomes negative. When it does, GDB will stop execution and you'll see what code caused that memory location to change. My bet is that something completely unrelated is stomping over this, thus causing a segfault. -- Bojan
Re: Forcing -fno-strict-aliasing to all compiles breaks compiles with xlc/xlc_r
On Fri, 2008-03-07 at 12:22 -0700, Chris Dukes wrote: Your test is including the '-c', allowing it to pass. OK. After I sent the patch, I realised that you toolchain only had a problem with the whole thing during the link phase. Sorry :-( Can you try replacing AC_COMPILE_IFELSE in my patch with AC_LINK_IFELSE? I just want to see if the test will produce the correct result. If it does, I think the whole thing should be reworked to use both tests and only if both pass use -fno-strict-aliasing. -- Bojan
Re: Forcing -fno-strict-aliasing to all compiles breaks compiles with xlc/xlc_r
On Fri, 2008-02-29 at 12:54 -0500, Chris Dukes wrote: xlc_r -qcpluscmt Yeah, we should only use -fno-strict-aliasing with GCC. -- Bojan
Re: Forcing -fno-strict-aliasing to all compiles breaks compiles with xlc/xlc_r
On Mon, 2008-03-03 at 09:03 +1100, Bojan Smojver wrote: Yeah, we should only use -fno-strict-aliasing with GCC. Can you let me know if this helps? You'll need to run buildconf, of course... -- Bojan Index: acinclude.m4 === --- acinclude.m4 (revision 632858) +++ acinclude.m4 (working copy) @@ -214,8 +214,13 @@ ]) # -Wdeclaration-after-statement is only supported on gcc 3.4+ fi -APR_ADDTO([CFLAGS], -fno-strict-aliasing) +old_cflags=$CFLAGS +CFLAGS=$CFLAGS -fno-strict-aliasing +AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]])], + [CFLAGS=$old_cflags; APR_ADDTO([CFLAGS], -fno-strict-aliasing)], + [CFLAGS=$old_cflags]) + APR_ADDTO([CPPFLAGS], `$APR_CONFIG --cppflags`) get_version=$SHELL $abs_srcdir/build/get-version.sh
[RFC] Multilib issues of apreq2-config
As the maintainer of libapreq2 for Fedora, I had to do a bit of pkgconfig hacking recently on current libapreq2 (2.09-rc2) in order to get it to be multilib compliant. You can see that work here: http://cvs.fedoraproject.org/viewcvs/rpms/libapreq2/devel/ The files in question are libapreq2.pc.in, libapreq2-2.09-pkgconfig.patch and libapreq2.spec (you can see sed-ing done in there to facilitate the changes). Essentially, current configuration script apreq2-config, which gets installed in /usr/bin, turns out to be different for 32-bit and 64-bit versions of the library (both of which can be installed in parallel), something that is not desirable and prevents getting the correct information from the script for one of the architectures. So, instead of hardcoding variables into the script, they are taken from the pkgconfig file (located in /usr/lib/pkgconfig and /usr/lib64/pkgconfig respectively), keeping the script the same for both architectures. The new script then contains something like this: libdir=`pkg-config --variable=libdir libapreq2` LIBS=`pkg-config --libs libapreq2` LDFLAGS=`pkg-config --libs libapreq2` INCLUDES=`pkg-config --cflags-only-I libapreq2` LDFLAGS=`pkg-config --libs libapreq2` Would the patches along those lines be useful to the project or should I continue having this as Fedora specific patches? -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
Are we going to have 2.09 release? It's been quite some time since RC2 went out... -- Bojan
Re: version_check.pl bug?
On Wed, 2007-01-31 at 11:46 +1100, Bojan Smojver wrote: Just got a report from Fedora build system that libapreq2-2.09-rc1 failed to build. Sorry, I meant rc2 here. -- Bojan
Re: Location of APR/APU docs changed
On Thu, 2006-12-28 at 14:04 +1100, Bojan Smojver wrote: Changing APREQ build system to link to APR/APU docs with a specific version number would be the correct thing to do. Something like this, maybe. -- Bojan Index: build/doxygen.conf.in === --- build/doxygen.conf.in (revision 490861) +++ build/doxygen.conf.in (working copy) @@ -64,8 +64,8 @@ PREDEFINED = APREQ_DECLARE(x)=x \ APREQ_DECLARE_NONSTD(x)=x -TAGFILES = docs/apr.tag=http://apr.apache.org/docs/apr \ - docs/apu.tag=http://apr.apache.org/docs/apr-util +TAGFILES = docs/apr.tag=http://apr.apache.org/docs/apr/@APR_DOC_VERSION@ \ + docs/apu.tag=http://apr.apache.org/docs/apr-util/@APU_DOC_VERSION@ GENERATE_TAGFILE = docs/apreq2.tag ALLEXTERNALS = NO EXTERNAL_GROUPS= NO Index: acinclude.m4 === --- acinclude.m4 (revision 490861) +++ acinclude.m4 (working copy) @@ -92,8 +92,19 @@ if test -z `$prereq_check apache2 $APACHE2_HTTPD`; then AC_MSG_ERROR([Bad apache2 binary ($APACHE2_HTTPD)]) fi + +APR_DOC_VERSION=`$APACHE2_APXS -q APR_VERSION 2/dev/null | cut -d. -f -2` +APU_DOC_VERSION=`$APACHE2_APXS -q APU_VERSION 2/dev/null | cut -d. -f -2` fi +dnl Fallback to oldest version available +if test x$APR_DOC_VERSION = 'x'; then +APR_DOC_VERSION=0.9 +fi +if test x$APU_DOC_VERSION = 'x'; then +APU_DOC_VERSION=0.9 +fi + AC_CHECK_FILE([$APR_CONFIG],, AC_MSG_ERROR([invalid apr-config location ($APR_CONFIG)- did you forget to configure apr?])) @@ -266,6 +277,9 @@ AC_SUBST(MM_OPTS) AC_SUBST(TAR) +AC_SUBST(APR_DOC_VERSION) +AC_SUBST(APU_DOC_VERSION) + if test x$OS = xsolaris; then $PERL -pi -e 's,^shrext=,shrext_cmds=,' libtool fi Index: Makefile.am === --- Makefile.am (revision 490861) +++ Makefile.am (working copy) @@ -18,8 +18,8 @@ s(href=/APR/Request/Param/(?:Table|Cookie).html)(href=group__apreq__xs__apr__request.html)g, \ s(href=/APR/Request.html)(href=group__apreq__xs__apr__request.html)g, \ s(href=/APR/Request/([^/]+).html)(href=group__apreq__xs__apr__request__\L$$1.html)g, \ - s(href=/APR/Brigade.html)(href=http://apr.apache.org/docs/apr-util/apr__buckets_8h.html;)g, \ - s(href=/APR/([^/]+).html)(href=http://apr.apache.org/docs/apr/apr__\L$$1s_8h.html;)g + s(href=/APR/Brigade.html)(href=http://apr.apache.org/docs/apr-util/$(APU_DOC_VERSION)/apr__buckets_8h.html)g, \ + s(href=/APR/([^/]+).html)(href=http://apr.apache.org/docs/apr/$(APR_DOC_VERSION)/apr__\L$$1s_8h.html)g EUM=ExtUtils::Manifest PM_DIR=glue/perl/lib/Apache2
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
On Wed, 2006-11-08 at 23:43 -0800, Philip M. Gollucci wrote: Please download, test, and report back on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.09.tar.gz http://people.apache.org/~pgollucci/apreq2/libapreq2-2.09.tar.gz.asc http://people.apache.org/~pgollucci/apreq2/libapreq2-2.09.tar.gz.md5 Builds for Fedora Extras 6 and development should appear after the new packages have been signed. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC5
On Sun, 2006-08-06 at 21:40 -0700, Philip M. Gollucci wrote: Can you clue me in on this Fedora stuff and pardon my cluelessness. I'm not really an FE expert, but I'll give it a go :-) Do you test build it first, or just submit it to that service and it does everything ? Normally, I'll run build locally to make sure everything is OK (this is optional, of course). Then, I'll build using the FE build system (this happens on i386, PPC and x86_64). This enables everyone that is subscribed to FE Development to get the new package for testing in the next few days. Or do you test build it afterwards ? The idea is that if there are FC/FE users using libapreq2 out there, they will file bug reports and let me know if the package is broken. Sometimes I'm the guy that hits problems (e.g. -fno-strict-aliasing). And what does it mean exactly if the service says good When the service says good, it means I can build the thing on my build platforms. PS. If you question is does the build run 'make test', the answer is no. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC5
On Sun, 2006-08-06 at 19:46 -0700, Philip M. Gollucci wrote: Please download, test, and VOTE on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC5.tar.gz Should appear in Fedora Extras soon. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC3
On Sat, 2006-07-08 at 03:39 -0700, Philip M. Gollucci wrote: Please download, test, and VOTE on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC3.tar.gz Weird. I'm getting errors when unpacking the tarball: - -rw-r--r-- pgollucci/wheel 5921 2006-07-08 19:36 libapreq2-2.08/win32/libapreq2.mak -rw-r--r-- pgollucci/wheel 4321 2006-07-08 19:36 libapreq2-2.08/win32/mod_apreq2.mak -rw-r--r-- pgollucci/wheel 1516 2006-07-08 19:36 libapreq2-2.08/win32/README -rw-r--r-- pgollucci/wheel 4184 2006-07-08 19:36 libapreq2-2.08/win32/test_cgi.mak -rw-r--r-- pgollucci/wheel977 2006-07-08 19:36 libapreq2-2.08/win32/util.pl tar: Error exit delayed from previous errors - What's the MD5 supposed to be? -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC3
On Tue, 2006-07-11 at 05:47 +1000, Bojan Smojver wrote: What's the MD5 supposed to be? Sorry. I'm getting here: 3b8b52c261c72adc971b656ca77f6eab libapreq2-2.08-RC3.tar.gz -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC3
On Mon, 2006-07-10 at 13:41 -0700, Philip M. Gollucci wrote: Works fine, I just untarred it here: http://people.apache.org/~pgollucci/apreq/libapreq2-2.08 OK. I'm off to work now anyway - I'll try unpacking on machines there. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC3
Quoting Bojan Smojver [EMAIL PROTECTED]: OK. I'm off to work now anyway - I'll try unpacking on machines there. Works on Solaris Sparc and RHEL4 x86_64, doesn't on Fedora Core 5 x86_64/i386. Go figure... -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC3
Quoting Bojan Smojver [EMAIL PROTECTED]: Works on Solaris Sparc and RHEL4 x86_64, doesn't on Fedora Core 5 x86_64/i386. Go figure... New FC bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198305 -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC3
Quoting Philip M. Gollucci [EMAIL PROTECTED]: Should I roll another one or do you think its just that box ? You can if you want, but the file as it is may be just fine. RHEL4 and Solaris 9 don't have any problems with the file. I'm guessing Apache boxes are FreeBSD and that works too. It seems FC specific (I opened a bug for this). Two of my i386 FC5 systems at home have the same problem (didn't check on others), my FC5 workstation at work (running on x86_64), as well as Fedora Extras build system (both i386 and x86_64). Can anyone on FC confirm/deny any of this? -- Bojan
Re: Endless loop in split_on_bdry() of library/parser_multipart.c?
Quoting Bojan Smojver [EMAIL PROTECTED]: Looks like the offsetof() provided by the platform isn't being used. Which in turn causes a lot of casting all over the place, which creates the aliasing problem? Maybe? Nah, it isn't that... Fails just the same with native offsetof() :-( -- Bojan
Re: Endless loop in split_on_bdry() of library/parser_multipart.c?
On Sun, 2006-06-11 at 20:31 -0400, Joe Schaefer wrote: APR_RING_UNSPLICE(f, l, link); APR_RING_SPLICE_TAIL(out-list, f, l, apr_bucket, link); This is the right approach, I think. But the person who'd be in the best place to test/commit it is Bojan. Just be sure to bump the patch level in apreq_version.h, and add a comment to CHANGES. I can test the above in my setup and see what comes out, but I'm more worried about the incorrectly compiled code and why it happened. I'm not sure if it's due to bugs in gcc, or is it something that RING/BRIGADE macros are doing that really isn't quite right. RH gcc guys know about it and they already put a few comments into the bug report, but I'm guessing they are still working on a final verdict. In any event, we know how to work around the issue on the platform in question (Fedora Core), so the whole thing is under control. Well, sort of anyway... :-) -- Bojan
Re: Endless loop in split_on_bdry() of library/parser_multipart.c?
Quoting Philip M. Gollucci [EMAIL PROTECTED]: Seems to be Fedora Core X specific. Happens on x84_64 as well and with 2.07. Rebuilding the package in Fedora Extras 5 now. -- Bojan
Re: Endless loop in split_on_bdry() of library/parser_multipart.c?
Quoting Joe Schaefer [EMAIL PROTECTED]: At least now it's a bit clearer why the no-strict-aliasing optimization is getting confused ;-) Hey, speak for yourself ;-) -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC1
Quoting Philip M. Gollucci [EMAIL PROTECTED]:
Please download, test, and report back on the following
candidate tarball:
Builds as RPM on Fedora Core 5 on my x86_64 box. I'll try the same in
Fedora Extras development tree as well. The spec file required some
changes in order to build. I'm hoping Perl folks using Rawhide will be
able to verify if all is still cool, once the package becomes available.
Patch for spec file is attached for your reference.
--
Bojan
--- libapreq2.spec.orig 2006-05-19 15:29:17.0 +1000
+++ libapreq2.spec 2006-05-19 15:37:15.0 +1000
@@ -1,15 +1,15 @@
%{!?apxs: %{expand:%%define apxs %{_sbindir}/apxs}}
Name: libapreq2
-Version:2.07
-Release:1.1%{?dist}
+Version:2.08
+Release:0.rc1.1%{?dist}
Summary:Apache HTTP request library
Group: System Environment/Libraries
License:Apache Software License
URL:http://httpd.apache.org/apreq/
#Source0:http://www.cpan.org/authors/id/J/JO/JOESUF/%{name}-%{version}.tar.gz
-Source0:http://people.apache.org/~joes/libapreq2-2.07.tar.gz
+Source0:http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC1.tar.gz
Source1:%{name}-httpd.conf
Patch0: %{name}-build.patch
Patch1: %{name}-2.07-rc3-ldflags.patch
@@ -62,7 +62,6 @@
#!/bin/sh
%{__perl_provides} $* \
| grep -v 'perl(APR::\(Request\(::\(Apache2\|CGI\|Error\)\)\?\))$' \
-| grep -v 'perl(Apache2::\(Cookie\|Request\|Upload\))$'
EOF
%define __perl_provides %{_builddir}/%{name}-%{version}/%{name}-perl-prov
chmod +x %{__perl_provides}
@@ -147,7 +146,6 @@
%defattr(-,root,root,-)
%doc glue/perl/README
%{perl_vendorarch}/auto/APR/
-%{perl_vendorarch}/Apache2/
%{perl_vendorarch}/APR/
%{_mandir}/man3/A*::*.3*
2.06 v 2.07
If memory serves me right, 2.07 didn't have any major API or other incompatible changes when compared to 2.06, right? Before I push 2.07 package in Fedora Core 4 Extras, I'd like to make sure I didn't misunderstand that... -- Bojan
Static build of libapreq2-2.07-rc3
Just for kicks, I tried that today with Apache 2.1.8-beta. The instructions are a bit stale in the INSTALL script. Here are the questions to the points mentioned under static install: 1. What is the CPPFLAGS -I supposed to be? Top level libapreq2 source directory? Or some other directory under it (e.g. module/apache2)? 2. What is HTTPD_LDFLAGS supposed to be (i.e. we should tell people where to expect libapreq2.la)? An example would be great. 3. The env/mod_apreq2.c doesn't exist any more. Should we say module/apache2/filter.c or module/apache2/handler.c? Or something else? I tried a few combos, but the configure process of libapre2 tells me invalid apr-config location, where this is actually APR 1.x (as shipped with Apache 2.1.8), so it should be looking for apr-1-config anyway (which exists in srclib/apr directory of Apache 2.1.8)... I don't use this config (i.e. I use dynamic build, which work fine), but some people may. It would be good if we could document/test this before the release of 2.07. -- Bojan
Re: Summary: [apache-modules] Session/Cookie-Based Authentication Library
On Sun, 2005-09-25 at 18:45 +0300, Eli Marmor wrote: If anybody else has anything to add about the differences between these library, or even about another library which does the work, please speak now or forever hold your peace ;-) (just kidding...) Only because of the forever hold your peace bit... :-) Yours truly has written mod_spin (and this is therefore a shameless plug), which can also be used for such a purpose in conjunction with one of its applications, spin_auth. For now (as of version 1.0.10), only pages that are mod_spin templates can be authenticated using this code. New development code (unreleased mod_spin 1.1.0) can provide authentication for any URL. The whole thing is based on regular Apache basic authentication, so whatever Apache supports, this supports. One creates a URL that is going to be the authentication point and if the user gets in, this is recorded in the session file (this can be shared between servers if you have a clustered file system like GFS). This authentication can be over SSL/TLS (i.e. to prevent basic authentication being ripped to shreds), although the site can be a plain HTTP site. The cookie is base on mod_unique_id, but it is accompanied by an MD5 digest of itself and a salt (at least 30 characters) defined in the configuration file. The salts can be periodically rotated by an external script to further strengthen the digest. This requires a graceful restart of the server (which can be, of course, done under load - compliments of Apache developer :-). How good/bad and how (in)secure this whole thing is, you will have to judge for yourself, as this is not really a community project, but my own little concoction. The code is licensed under the GPL with exception to link with Apache and libapreq2. -- Bojan
Re: libapreq2 2.06 submitted to Freshmeat
Quoting VilleSkyttä [EMAIL PROTECTED]: Thanks, committed, will be in 2_06-2.*. Awesome! I see that the binaries hit the mirrors, so all of us Fedorans will be kept happy :-) Once again, thank you for putting the effort in to make libapreq2 part of Fedora Extras. -- Bojan
Re: libapreq2 2.06 submitted to Freshmeat
Quoting VilleSkyttä [EMAIL PROTECTED]: FYI, libapreq2 2.06 RPMS for Fedora Core 4 (and soon development) are available from Fedora Extras, http://fedoraproject.org/wiki/Extras Any chance you could include *.tag files in the docs directory of libapreq2-devel package? These are very useful when building local references to documentation, as opposed to Internet URLs. Helps people that aren't connected to the net getting to referenced docos from packages that use libapreq2... -- Bojan
