Re: [BUG] apr-util-1.0.0.rc3: when src_dir != obj_dir make check won't work
--On Saturday, July 10, 2004 7:12 PM -0600 Jani Averbach [EMAIL PROTECTED] wrote: The check target of apr-util(1.0.0.rc3) will fail when building directory is different than source directory. This happens because there isn't test directory in obj directory. The check target of apr works fine with separated build directory. Copy the data and internal directories from the $src/test. IIRC, it used to do that, but somehow when the test suite was migrated over, it stopped. -- justin
FreeBSD Atomics for 0.9
Can anyone commit the patch to fix FreeBSD's atomics in 0.9 Branch? http://issues.apache.org/bugzilla/show_bug.cgi?id=26818 FreeBSD's ports have been applying this patch for months, and the atomics in HEAD are already updated. Thanks, -Paul Querna
FreeBSD Atomics for 0.95
Can anyone commit the patch to fix FreeBSD's atomics in 0.9 Branch? http://issues.apache.org/bugzilla/show_bug.cgi?id=26818 FreeBSD's ports have been applying this patch for months, and the atomics in HEAD are already updated. Thanks, -Paul Querna
Re: 1.0.0 RC3
So, tagged rolled RC3 :-) Any feedback? Aim is to produce final 1.0 this week... david
Re: cvs commit: apr/threadproc/netware proc.c
On Fri, Jul 09, 2004 at 03:47:19PM -0600, Jean-Jacques Clar wrote: used as a bitfield like this in the 2.0 branch. For mod_cgi in HEAD it needn't be weird of course, the addrspace field could be left in there. I was trying to make head and 2.0 the same, my bet for not disconnecting the two branches... To do: 1- pull back today head httpd and apr changes, it is working and no need to touch it, 2- back port address_space api and apr_procattr_t field in apr 0.9 branch as it is in 1.0, Yes, and yes. 3- overload detach field from cgi_exec_info_t in 2.0 to make sure no bump are needed, no backport entry needed in that case. Not sure what you mean there, any proposed backport to the APACHE_2_0_BRANCH for httpd needs to be added to STATUS following the normal procedure. joe
Re: 1.0.0 RC3
David Reid wrote: So, tagged rolled RC3 :-) I didn't include jlibtool. Nor did I include the recent FreeBSD poll changes as I don't think we've quite gotten the changes far enough to amke them suitable for a 1.0.0 release. I removed the tag from the renames-pending file as I didn't think that should really be in our release :-) I did include the rpm file, the recent Netware changes and (hopefully) all the changes required to ensure we get versioned config files. The file apr.spec is missing from the tarball, which is created by buildconf. I see that the changes to buildconf that add the version to the specfile are missing - can you fix the tag on ./buildconf? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit: apr/threadproc/netware proc.c
3- overload detach field from cgi_exec_info_t in 2.0 to make sure no bump are needed, no backport entry needed in that case.Not sure what you mean there, any proposed backport to theAPACHE_2_0_BRANCH for httpd needs to be added to STATUS following thenormal procedure.The change done in 2.1 include an added field for address spacein the cgi_exec_info struct. The fieldcould not be backported because of a requested number bump. This is why I need to overload the detached field from the same structure in the 2.0 branch, not in the 2.1. How could I propose a backport on changes in mod_cgi.cthat will only be in the 2.0 and not in the 2.1 branch? This is not a backport, the2.0 changes are partiallya workaround in order to keep binary comp. Thank you, JJ
Re: 1.0.0 RC3
David Reid wrote: So, tagged rolled RC3 :-) I didn't include jlibtool. Nor did I include the recent FreeBSD poll changes as I don't think we've quite gotten the changes far enough to amke them suitable for a 1.0.0 release. I removed the tag from the renames-pending file as I didn't think that should really be in our release :-) I did include the rpm file, the recent Netware changes and (hopefully) all the changes required to ensure we get versioned config files. The file apr.spec is missing from the tarball, which is created by buildconf. I see that the changes to buildconf that add the version to the specfile are missing - can you fix the tag on ./buildconf? I can do. That'll need an RC4 though... Any other files that aren't tagged correctly? So far it looks like bumps should be made for these files... apr/buildconf apr-util/buildconf apr-util/misc/apr_rmm.c Any more prior to me rolling RC4... Very little feedback on RC3 so far... david
Re: 1.0.0 RC3
On Mon, Jul 12, 2004 at 12:09:20PM +0100, David Reid wrote: So, tagged rolled RC3 :-) Any feedback? Tested on a bunch of Linux boxes at the weekend and looks good, +1. joe
Re: 1.0.0 RC3
David Reid wrote: I can do. That'll need an RC4 though... Any other files that aren't tagged correctly? I only downloaded and tried apr, but not apr-util. In apr-util there should be buildconf, build/rpm, and build/rpm/apr-util.spec.in. I have created a spec file for apr-iconv - but so far it seems apr-iconv is only necessary on windows. Can anyone confirm whether apr-iconv is needed on any Unix like platforms at all? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: 1.0.0 RC3
On Mon, Jul 12, 2004 at 04:38:52PM +0100, David Reid wrote: David Reid wrote: I see that the changes to buildconf that add the version to the specfile are missing - can you fix the tag on ./buildconf? I can do. That'll need an RC4 though... Any other files that aren't tagged correctly? You can say no at some point David :) Otherwise this process will just Oh, trust me, I know! carry on every week for the rest of the year. 1.0.0 will have bugs and misfeatures and lack-of-features and some of these can wait to be fixed in 1.0.1, or 1.1 or later. Right. RC4 will be the FINAL RC unless there is some huge problem. And by huge I mean HUGE :-) The other thing that would be good to solve is the FreeBSD bug that Nick Kew found where configure seems to detect IPv6 when it shouldn't... However, it's not critical at all and won't delay RC4. The main reason for RC4 is the rpm stuff... Timetable is RC4 tomorrow, 1.0.0 on Thursday afternoon after my proficiency checks at work are over! Apart from those few files, are people happy that RC3 could be labelled as APR 1.0.0. and APR-Util 1.0.0 though? david
Re: 1.0.0 RC3
At 10:45 AM 7/12/2004, Graham Leggett wrote: I have created a spec file for apr-iconv - but so far it seems apr-iconv is only necessary on windows. Can anyone confirm whether apr-iconv is needed on any Unix like platforms at all? Anyone have other examples for Graham? Inquiring minds want to know! This has alot to do with creating the appropriate 'patch' to enable iconv-2.0 to run in Win32, thereby jettisoning apr-iconv in APR-util 1.0.1. Obviously the answer to this question will shape how we win32 porters move forward. Bill
Re: 1.0.0 RC3
At 10:52 AM 7/12/2004, David Reid wrote: Timetable is RC4 tomorrow, 1.0.0 on Thursday afternoon after my proficiency checks at work are over! David, please make sure we don't include STATUS in those final tarballs. I'd like to roll an RC4 win32 .zip as soon as your are done rolling RC4. If you use the roll-release script, apr-iconv should get an API_1_0_0_RC4 tag, but if not I will tag what I extract for win32. Bill
