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
Re: 1.0.0 RC3
So, tagged rolled RC3 :-) Any feedback? Aim is to produce final 1.0 this week... david
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: 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
[BUG] apr-util-1.0.0.rc3: when src_dir != obj_dir make check won't work
Hi, 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. BR, Jani Here is a check report for apr-1.0.0.rc3 on amd64, with gcc 3.3.3: testatomic : SUCCESS testdir : FAILED 2 of 12 testdso : SUCCESS testdup : SUCCESS testenv : SUCCESS testfile: FAILED 3 of 22 testfilecopy: FAILED 2 of 4 testfileinfo: SUCCESS testflock : SUCCESS testfmt : SUCCESS testfnmatch : FAILED 2 of 2 testargs: SUCCESS testhash: SUCCESS testipsub : SUCCESS testlock: SUCCESS testlfs : SUCCESS testmmap: |make[1]: Leaving directory... Don't know what has happened to this last line.. -- Jani Averbach
Re: 1.0.0 RC3
I just tested this on FreeBSD 4.4 with no IPv6 (chipig persuaded me to test sendfile - which works just fine - on it). It failed 3/6 tests under testsocket. On investigatation, these proved to be the three tests using IPV6. So it appears to be the tests that are at fault, testing where they shouldn't. -- Nick Kew
