You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Reser <be...@reser.org> on 2005/04/05 00:03:55 UTC
1.2.0-rc1 tarballs up for testing/signing
http://fornix.brain.org/subversion/
-rw-rw-r-- 1 svnrm svnrm 6973827 Apr 4 19:46 subversion-1.2.0-rc1.tar.bz2
-rw-rw-r-- 1 svnrm svnrm 8520113 Apr 4 19:46 subversion-1.2.0-rc1.tar.gz
-rw-rw-r-- 1 svnrm svnrm 11364041 Apr 4 19:50 subversion-1.2.0-rc1.zip
md5sums:
c96be2d7591b7ee260ac372fe1248dff subversion-1.2.0-rc1.tar.gz
b99e49eea110ebfca338b62db5f5a2be subversion-1.2.0-rc1.tar.bz2
d28d5f6fd84b9f4651e879af0b9500c6 subversion-1.2.0-rc1.zip
sha1sums:
75138673c63b8e5015ff2f9ffdc6f27e49f4d65d subversion-1.2.0-rc1.tar.gz
a64ae487bbb3e752e074c59e1f9665fc5e53bd7b subversion-1.2.0-rc1.tar.bz2
e65c81a507a95ad5ad7645c776ab48b841602011 subversion-1.2.0-rc1.zip
Please test and send me your signatures. Thank you.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Cory Omand <co...@blastwave.org>.
On Mon, 2005-04-04 at 20:15, Ben Collins-Sussman wrote:
> On Apr 4, 2005, at 9:30 PM, Justin Erenkrantz wrote:
> > --On Monday, April 4, 2005 5:03 PM -0700 Ben Reser <be...@reser.org>
> >
> > Passes 'make check' on Darwin with the following output:
> >
> > SKIP: revert_tests.py 2: reverting to corrupt text base should fail
> > SKIP: utf8_tests.py 1: conversion of paths and logs to/from utf8
> >
>
> Passes 'make check' on WinXP sp1 compiled with VC6, with a bunch of
> expected 'skipped' tests. Here's my signature of the .zip:
Passes 'make check' on Solaris 8 compiled Sun One CC with the
following output:
At least one test was SKIPPED, checking /usr/share/src/csw/utils/subversion-1.2/work/sparc.d/subversion-1.2.0-rc1/tests.log
SKIP: revert_tests.py 2: reverting to corrupt text base should fail
SKIP: utf8_tests.py 1: conversion of paths and logs to/from utf8
--
Cory Omand <co...@blastwave.org>
Blastwave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 4, 2005, at 9:30 PM, Justin Erenkrantz wrote:
> --On Monday, April 4, 2005 5:03 PM -0700 Ben Reser <be...@reser.org>
> wrote:
>
>> http://fornix.brain.org/subversion/
>
> Passes 'make check' on Darwin with the following output:
>
> SKIP: revert_tests.py 2: reverting to corrupt text base should fail
> SKIP: utf8_tests.py 1: conversion of paths and logs to/from utf8
>
Passes 'make check' on WinXP sp1 compiled with VC6, with a bunch of
expected 'skipped' tests. Here's my signature of the .zip:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQBCUgI4U0gaaOxrUVYRAkzYAKCDhyx7babI7pUVP8mObBNpfihmmQCfUwmW
CMqeKPlvlBNnXY1btamD3P0=
=l7O2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, April 4, 2005 5:03 PM -0700 Ben Reser <be...@reser.org> wrote:
> http://fornix.brain.org/subversion/
Passes 'make check' on Darwin with the following output:
SKIP: revert_tests.py 2: reverting to corrupt text base should fail
SKIP: utf8_tests.py 1: conversion of paths and logs to/from utf8
I believe both of these are expected. I think the revert_tests.py skip is the
one Max did this AM that was discussed here on dev@svn. And, the
utf8_tests.py is the borked one on Darwin.
So, +1.
> -rw-rw-r-- 1 svnrm svnrm 6973827 Apr 4 19:46 subversion-1.2.0-rc1.tar.bz2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
iD8DBQBCUe1KFqlkleIiZ5URAgpOAKDLt8xl3RNZRA60SSsQln+fGBWOrgCeJ6Ko
WEcS+dcC83p83PFf7XkmDlM=
=wpEe
-----END PGP SIGNATURE-----
> -rw-rw-r-- 1 svnrm svnrm 8520113 Apr 4 19:46 subversion-1.2.0-rc1.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
iD8DBQBCUe56FqlkleIiZ5URAsWXAJ9B/2IsgJF5fI66hVBOPI6o/V0+FgCgu61r
QqoTC/Be0y8Jdsn20hj8Z5E=
=zVSa
-----END PGP SIGNATURE-----
Thanks! -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Max Bowsher <ma...@ukf.net>.
John Lenz wrote:
> On 04/06/05 17:28:20, Max Bowsher wrote:
>> John Lenz wrote:
>>> I noticed that SWIG is still required to build the tarball. In my
>>> opinion, removing the requirement that SWIG be installed to build the
>>> subversion tarball should be something that makes it into 1.2. No code
>>> changes need to take place to support this, it is only Makefile changes
>>> and build script changes so it shouldn't be a problem of testing. I
>>> attempted to hack the build system to support this, but the way
>>> build-outputs.mk is built with those python scripts is so complicated I
>>> couldn't figure out how to do it.
>
>> As you have observed, this requires an extremely nontrivial bit of
>> buildsystem work.
>>
>> 1.2 is feature frozen, so it will not be happening in 1.2.
>>
>
> One solution would be to just copy the files into the tarball inside
> dist.sh. Then there aren't any build changes that need to take place:
> just do something like
>
> cp subversion/bindings/swig/python/core.c
> $DISTPATH/subversion/bindings/swig/python
> cp ...
>
> Perhaps list the files to be copied inside a file, and inside dist.sh read
> that list and copy those files into the DISTPATH.
>
> As long as the .c files get included in the tarball, the current makefiles
> should work fine.
No. configure will still look for a swig installed on the system, and
decline to set things up for the bindings if not found.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by John Lenz <le...@cs.wisc.edu>.
On 04/06/05 17:28:20, Max Bowsher wrote:
> John Lenz wrote:
>> I noticed that SWIG is still required to build the tarball. In my
>> opinion, removing the requirement that SWIG be installed to build the
>> subversion tarball should be something that makes it into 1.2. No code
>> changes need to take place to support this, it is only Makefile changes
>> and build script changes so it shouldn't be a problem of testing. I
>> attempted to hack the build system to support this, but the way
>> build-outputs.mk is built with those python scripts is so complicated I
>> couldn't figure out how to do it.
> As you have observed, this requires an extremely nontrivial bit of
> buildsystem work.
>
> 1.2 is feature frozen, so it will not be happening in 1.2.
>
One solution would be to just copy the files into the tarball inside
dist.sh. Then there aren't any build changes that need to take place: just
do something like
cp subversion/bindings/swig/python/core.c
$DISTPATH/subversion/bindings/swig/python
cp ...
Perhaps list the files to be copied inside a file, and inside dist.sh read
that list and copy those files into the DISTPATH.
As long as the .c files get included in the tarball, the current makefiles
should work fine.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Max Bowsher <ma...@ukf.net>.
John Lenz wrote:
> On 04/04/05 19:03:55, Ben Reser wrote:
>> http://fornix.brain.org/subversion/
>>
>> -rw-rw-r-- 1 svnrm svnrm 6973827 Apr 4 19:46
>> subversion-1.2.0-rc1.tar.bz2
>> -rw-rw-r-- 1 svnrm svnrm 8520113 Apr 4 19:46
>> subversion-1.2.0-rc1.tar.gz -rw-rw-r-- 1 svnrm svnrm 11364041 Apr 4
>> 19:50 subversion-1.2.0-rc1.zip
>>
>> md5sums:
>> c96be2d7591b7ee260ac372fe1248dff subversion-1.2.0-rc1.tar.gz
>> b99e49eea110ebfca338b62db5f5a2be subversion-1.2.0-rc1.tar.bz2
>> d28d5f6fd84b9f4651e879af0b9500c6 subversion-1.2.0-rc1.zip
>>
>> sha1sums:
>> 75138673c63b8e5015ff2f9ffdc6f27e49f4d65d subversion-1.2.0-rc1.tar.gz
>> a64ae487bbb3e752e074c59e1f9665fc5e53bd7b subversion-1.2.0-rc1.tar.bz2
>> e65c81a507a95ad5ad7645c776ab48b841602011 subversion-1.2.0-rc1.zip
>>
>> Please test and send me your signatures. Thank you.
>>
>
> I noticed that SWIG is still required to build the tarball. In my
> opinion, removing the requirement that SWIG be installed to build the
> subversion tarball should be something that makes it into 1.2. No code
> changes need to take place to support this, it is only Makefile changes
> and build script changes so it shouldn't be a problem of testing. I
> attempted to hack the build system to support this, but the way
> build-outputs.mk is built with those python scripts is so complicated I
> couldn't figure out how to do it.
> In case the previous mail got lost (there were no replies), something like
> the following needs to be added to the makefile:
>
> SWIGLIBDIR=`$(SWIG) -swiglib`
>
> subversion/bindings/swig/python/libsvn_swig_py/swigpyrun.h:
> $(SWIG) -python -external-runtime path/swigpyrun.h || \
> ( cat $(SWIGLIBDIR)/swigrun.swg > path/swigpyrun.h && \
> cat $(SWIGLIBDIR)/python/pyrun.swg >> path/swigpyrun.h && \
> cat $(SWIGLIBDIR)/runtime.swg >> path/swigpyrun.h; )
>
> and then have the swigutil_py.c file include swigpyrun.h instead of
> including the swigrun.swg, pyrun.swg, and runtime.swg directly.
>
> The main problem is dist.sh does not actually run configure or make, so I
> don't know where to add this into the build system. You would like it to
> be added so the rule gets added to build-outputs.mk so that during normal
> development if an .i file changes you have the rules to rebuild the SWIG
> files. But you also need to build these rules from dist.sh, so having a
> separate Makefile with the SWIG rules would work better. What I'm
> thinking here is gen_make.py dumps all the SWIG rules (that is, only the
> rules to build .c files from .i files) into a build-swig-outputs.mk which
> build-outputs.mk includes. Then dist.sh could run
> make -f build-swig-outputs.mk SWIG=/path/to/swig
> The only variable build-swig-outputs.mk should have is the SWIG variable,
> and when building normally the toplevel Makefile.in would set it, and
> otherwise dist.sh would look it up and set it.
As you have observed, this requires an extremely nontrivial bit of
buildsystem work.
1.2 is feature frozen, so it will not be happening in 1.2.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by John Lenz <le...@cs.wisc.edu>.
On 04/04/05 19:03:55, Ben Reser wrote:
> http://fornix.brain.org/subversion/
>
> -rw-rw-r-- 1 svnrm svnrm 6973827 Apr 4 19:46
> subversion-1.2.0-rc1.tar.bz2
> -rw-rw-r-- 1 svnrm svnrm 8520113 Apr 4 19:46 subversion-1.2.0-rc1.tar.gz
> -rw-rw-r-- 1 svnrm svnrm 11364041 Apr 4 19:50 subversion-1.2.0-rc1.zip
>
> md5sums:
> c96be2d7591b7ee260ac372fe1248dff subversion-1.2.0-rc1.tar.gz
> b99e49eea110ebfca338b62db5f5a2be subversion-1.2.0-rc1.tar.bz2
> d28d5f6fd84b9f4651e879af0b9500c6 subversion-1.2.0-rc1.zip
>
> sha1sums:
> 75138673c63b8e5015ff2f9ffdc6f27e49f4d65d subversion-1.2.0-rc1.tar.gz
> a64ae487bbb3e752e074c59e1f9665fc5e53bd7b subversion-1.2.0-rc1.tar.bz2
> e65c81a507a95ad5ad7645c776ab48b841602011 subversion-1.2.0-rc1.zip
>
> Please test and send me your signatures. Thank you.
>
I noticed that SWIG is still required to build the tarball. In my opinion,
removing the requirement that SWIG be installed to build the subversion
tarball should be something that makes it into 1.2. No code changes need
to take place to support this, it is only Makefile changes and build script
changes so it shouldn't be a problem of testing. I attempted to hack the
build system to support this, but the way build-outputs.mk is built with
those python scripts is so complicated I couldn't figure out how to do it.
In case the previous mail got lost (there were no replies), something like
the following needs to be added to the makefile:
SWIGLIBDIR=`$(SWIG) -swiglib`
subversion/bindings/swig/python/libsvn_swig_py/swigpyrun.h:
$(SWIG) -python -external-runtime path/swigpyrun.h || \
( cat $(SWIGLIBDIR)/swigrun.swg > path/swigpyrun.h && \
cat $(SWIGLIBDIR)/python/pyrun.swg >> path/swigpyrun.h && \
cat $(SWIGLIBDIR)/runtime.swg >> path/swigpyrun.h; )
and then have the swigutil_py.c file include swigpyrun.h instead of
including the swigrun.swg, pyrun.swg, and runtime.swg directly.
The main problem is dist.sh does not actually run configure or make, so I
don't know where to add this into the build system. You would like it to
be added so the rule gets added to build-outputs.mk so that during normal
development if an .i file changes you have the rules to rebuild the SWIG
files. But you also need to build these rules from dist.sh, so having a
separate Makefile with the SWIG rules would work better. What I'm thinking
here is gen_make.py dumps all the SWIG rules (that is, only the rules to
build .c files from .i files) into a build-swig-outputs.mk which
build-outputs.mk includes. Then dist.sh could run
make -f build-swig-outputs.mk SWIG=/path/to/swig
The only variable build-swig-outputs.mk should have is the SWIG variable,
and when building normally the toplevel Makefile.in would set it, and
otherwise dist.sh would look it up and set it.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Ben Reser <be...@reser.org>.
On Mon, Apr 04, 2005 at 05:03:55PM -0700, Ben Reser wrote:
> http://fornix.brain.org/subversion/
>
> -rw-rw-r-- 1 svnrm svnrm 6973827 Apr 4 19:46 subversion-1.2.0-rc1.tar.bz2
> -rw-rw-r-- 1 svnrm svnrm 8520113 Apr 4 19:46 subversion-1.2.0-rc1.tar.gz
> -rw-rw-r-- 1 svnrm svnrm 11364041 Apr 4 19:50 subversion-1.2.0-rc1.zip
>
> md5sums:
> c96be2d7591b7ee260ac372fe1248dff subversion-1.2.0-rc1.tar.gz
> b99e49eea110ebfca338b62db5f5a2be subversion-1.2.0-rc1.tar.bz2
> d28d5f6fd84b9f4651e879af0b9500c6 subversion-1.2.0-rc1.zip
>
> sha1sums:
> 75138673c63b8e5015ff2f9ffdc6f27e49f4d65d subversion-1.2.0-rc1.tar.gz
> a64ae487bbb3e752e074c59e1f9665fc5e53bd7b subversion-1.2.0-rc1.tar.bz2
> e65c81a507a95ad5ad7645c776ab48b841602011 subversion-1.2.0-rc1.zip
>
> Please test and send me your signatures. Thank you.
And since I forgot this is from r13929 on /branches/1.2.x
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Daniel Berlin <db...@dberlin.org>.
On Mon, 2005-04-04 at 17:03 -0700, Ben Reser wrote:
> http://fornix.brain.org/subversion/
>
> -rw-rw-r-- 1 svnrm svnrm 6973827 Apr 4 19:46 subversion-1.2.0-rc1.tar.bz2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBCUqmg7FmgR1HlB6wRAtI5AJsHcD+fdmE/EvyqAZ2Mv02yHqEQFACfYqvr
SecJ2B29lR0IyFs6CCV862M=
=fbMH
-----END PGP SIGNATURE-----
> -rw-rw-r-- 1 svnrm svnrm 8520113 Apr 4 19:46 subversion-1.2.0-rc1.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBCUqmo7FmgR1HlB6wRAlZaAJ9XZhT8hVgHO4GzQiZcY0dUKA3ejgCfXlZP
w7BjcN8JQqdKoNbJIF/ZBPE=
=p/JC
-----END PGP SIGNATURE-----
> -rw-rw-r-- 1 svnrm svnrm 11364041 Apr 4 19:50 subversion-1.2.0-rc1.zip
>
> md5sums:
> c96be2d7591b7ee260ac372fe1248dff subversion-1.2.0-rc1.tar.gz
> b99e49eea110ebfca338b62db5f5a2be subversion-1.2.0-rc1.tar.bz2
> d28d5f6fd84b9f4651e879af0b9500c6 subversion-1.2.0-rc1.zip
>
> sha1sums:
> 75138673c63b8e5015ff2f9ffdc6f27e49f4d65d subversion-1.2.0-rc1.tar.gz
> a64ae487bbb3e752e074c59e1f9665fc5e53bd7b subversion-1.2.0-rc1.tar.bz2
> e65c81a507a95ad5ad7645c776ab48b841602011 subversion-1.2.0-rc1.zip
>
> Please test and send me your signatures. Thank you.
>
Works on my linux machines.
Haven't tried the zip yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, April 6, 2005 11:59 AM -0500 "Brian W. Fitzpatrick"
<fi...@collab.net> wrote:
> I'm really torn here, but I think I have to agree with you--let's push
> rc1 out there, with the caveat that copy_tests.py #25 is an invalid
> test, and we'll put that fix, along with other fixes, into rc2. It's
> not like we're not going to have an rc2. :)
+1. It doesn't have to be perfect. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Tue, 2005-04-05 at 13:11 -0700, Ben Reser wrote:
> On Tue, Apr 05, 2005 at 02:21:31PM -0500, kfogel@collab.net wrote:
> > As has been discussed on IRC, copy_tests 25 is failing over DAV, not
> > because there's anything wrong in Subversion, but because the test is
> > expecting the wrong error message (the DAV error message differs from
> > the error message printed by other RA layers, apparently).
> >
> > Since Subversion itself is correct, here are my sigs for the .tar.gz
> > and .tar.bz2. However, I think it's a Bad Idea to release an RC that
> > has a test failing, for any reason. It makes us look sloppy and
> > causes doubts among the faithful. I'm not vetoing the release, but my
> > strong preference would be to not release rc1, fix the problem, and
> > reroll, making rc2 our first blessed release candidate I guess.
>
> How does everyone else feel about this? I'm inclined to just ship rc1
> since it's such a small issue with a note saying that we're aware that
> copy_tests.py test #25 fails. Fix it in rc2. Is it worth another day
> worth of delay to retest, reaquire signatures, etc... to fix a test that
> isn't really failing but is incomplete?
>
> I'm not sure it is. But if you guys think so I will gladly cut an rc2
> with a fix.
I'm really torn here, but I think I have to agree with you--let's push
rc1 out there, with the caveat that copy_tests.py #25 is an invalid
test, and we'll put that fix, along with other fixes, into rc2. It's
not like we're not going to have an rc2. :)
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Ben Reser <be...@reser.org>.
On Tue, Apr 05, 2005 at 02:21:31PM -0500, kfogel@collab.net wrote:
> As has been discussed on IRC, copy_tests 25 is failing over DAV, not
> because there's anything wrong in Subversion, but because the test is
> expecting the wrong error message (the DAV error message differs from
> the error message printed by other RA layers, apparently).
>
> Since Subversion itself is correct, here are my sigs for the .tar.gz
> and .tar.bz2. However, I think it's a Bad Idea to release an RC that
> has a test failing, for any reason. It makes us look sloppy and
> causes doubts among the faithful. I'm not vetoing the release, but my
> strong preference would be to not release rc1, fix the problem, and
> reroll, making rc2 our first blessed release candidate I guess.
How does everyone else feel about this? I'm inclined to just ship rc1
since it's such a small issue with a note saying that we're aware that
copy_tests.py test #25 fails. Fix it in rc2. Is it worth another day
worth of delay to retest, reaquire signatures, etc... to fix a test that
isn't really failing but is incomplete?
I'm not sure it is. But if you guys think so I will gladly cut an rc2
with a fix.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by kf...@collab.net.
I tested subversion-1.2.0-rc1.tar.gz over all six combinations of RA
layer and back end. I also did a cmp to make sure that the .tar
extracted from the .bz2 was the same as that from the .gz.
As has been discussed on IRC, copy_tests 25 is failing over DAV, not
because there's anything wrong in Subversion, but because the test is
expecting the wrong error message (the DAV error message differs from
the error message printed by other RA layers, apparently).
Since Subversion itself is correct, here are my sigs for the .tar.gz
and .tar.bz2. However, I think it's a Bad Idea to release an RC that
has a test failing, for any reason. It makes us look sloppy and
causes doubts among the faithful. I'm not vetoing the release, but my
strong preference would be to not release rc1, fix the problem, and
reroll, making rc2 our first blessed release candidate I guess.
Here are my signatures:
subversion-1.2.0-rc1.tar.gz:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.92 (GNU/Linux)
iD8DBQBCUugQvJ27E9sAokgRAjUoAKDE0W2nMGHiPgcFvlhGuXWF8kJSpwCfQyH3
oYuDUIpDIOw3DhHxoeQE4y8=
=rXn/
-----END PGP SIGNATURE-----
subversion-1.2.0-rc1.tar.bz2:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.92 (GNU/Linux)
iD8DBQBCUugdvJ27E9sAokgRAp/ZAJ0V+uL2IGlDvRFN7/dpEZeE0sBFkwCfVvmQ
cjVMHd8/QcFw4hreivU3Ikc=
=YWDH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 5, 2005, at 12:35 PM, Jim Correia wrote:
> On Apr 5, 2005, at 1:04 PM, Dominic Anello wrote:
>
>> Mac OS X doesn't like static binaries and doesn't include a staticly
>> linked crt (part of the C runtime AFAIK).
>>
>> Perhaps before you had Darwin ports or the like installed and svn was
>> picking up crt0.o from that?
>
> No. In fact, if I go back to my 1.1.2 tarball that I had archived
> (last release I built from source) and do
>
> ./configure --without-berkeley-db --enable-all-static
> make
>
> Subversion builds just find. Something must have changed in the build
> system?
>
The build system has changed, yes. But the new tarball also uses
libtool 1.5 instead of 1.4. I wonder if that's relevant.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Jim Correia <ji...@pobox.com>.
On Apr 7, 2005, at 7:44 AM, Jim Correia wrote:
> On Apr 6, 2005, at 11:06 PM, Ben Reser wrote:
>
>> On Wed, Apr 06, 2005 at 12:16:47PM -0400, Jim Correia wrote:
>>> Is there a solution for building static binaries on Mac OS X with the
>>> new libtool in use?
>>
>> Let's find out really if libtool is an issue here. Can you start
>> with a
>> freshly extracted copy of the tarball and run:
>> ./autogen.sh
>
> Just to be clear, you wanted me to (on a fresh copy) do
>
> ./autogen.sh
> ./configure --enable-all-static --without-berkeley-db
> make
>
> ?
>
> I did that and got the same build/link error as before.
>
>> See if you still have the problem. Then post the output of:
>> libtool --version
>
> ltmain.sh (GNU libtool) 1.5 (1.1220 2003/04/05 19:32:58)
Following up to my own message...
Building using --disable-shared as in
<http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=29160>
works fine for me (since I am using the fsfs backend and don't need to
worry about the dynamic BerkeleyDB issue he points out.) so this is an
acceptable workaround.
If --enable-all-static is not to work on Darwin, ideally an error would
be reported during configure (or something) to that effect rather than
just having the link mysteriously fail. I'm afraid I don't know enough
about autoconf and friends to submit a patch to make it so though.
Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Jim Correia <ji...@pobox.com>.
On Apr 6, 2005, at 11:06 PM, Ben Reser wrote:
> On Wed, Apr 06, 2005 at 12:16:47PM -0400, Jim Correia wrote:
>> Is there a solution for building static binaries on Mac OS X with the
>> new libtool in use?
>
> Let's find out really if libtool is an issue here. Can you start with
> a
> freshly extracted copy of the tarball and run:
> ./autogen.sh
Just to be clear, you wanted me to (on a fresh copy) do
./autogen.sh
./configure --enable-all-static --without-berkeley-db
make
?
I did that and got the same build/link error as before.
> See if you still have the problem. Then post the output of:
> libtool --version
ltmain.sh (GNU libtool) 1.5 (1.1220 2003/04/05 19:32:58)
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Ben Reser <be...@reser.org>.
On Wed, Apr 06, 2005 at 12:16:47PM -0400, Jim Correia wrote:
> Is there a solution for building static binaries on Mac OS X with the
> new libtool in use?
Let's find out really if libtool is an issue here. Can you start with a
freshly extracted copy of the tarball and run:
./autogen.sh
See if you still have the problem. Then post the output of:
libtool --version
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Jim Correia <ji...@pobox.com>.
On Apr 6, 2005, at 12:07 PM, Max Bowsher wrote:
> Jim Correia wrote:
>> On Apr 5, 2005, at 1:04 PM, Dominic Anello wrote:
>>> Mac OS X doesn't like static binaries and doesn't include a staticly
>>> linked crt (part of the C runtime AFAIK).
>>> Perhaps before you had Darwin ports or the like installed and svn was
>>> picking up crt0.o from that?
>> No. In fact, if I go back to my 1.1.2 tarball that I had archived
>> (last
>> release I built from source) and do
>> ./configure --without-berkeley-db --enable-all-static
>> make
>> Subversion builds just find. Something must have changed in the build
>> system?
>
> Yes, the version of libtool has changed.
Is there a solution for building static binaries on Mac OS X with the
new libtool in use?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Max Bowsher <ma...@ukf.net>.
Jim Correia wrote:
> On Apr 5, 2005, at 1:04 PM, Dominic Anello wrote:
>
>> Mac OS X doesn't like static binaries and doesn't include a staticly
>> linked crt (part of the C runtime AFAIK).
>>
>> Perhaps before you had Darwin ports or the like installed and svn was
>> picking up crt0.o from that?
>
> No. In fact, if I go back to my 1.1.2 tarball that I had archived (last
> release I built from source) and do
>
> ./configure --without-berkeley-db --enable-all-static
> make
>
> Subversion builds just find. Something must have changed in the build
> system?
Yes, the version of libtool has changed.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Dominic Anello <da...@danky.com>.
On 2005-04-05 13:35:58 -0400, Jim Correia wrote:
> On Apr 5, 2005, at 1:04 PM, Dominic Anello wrote:
>
> >Mac OS X doesn't like static binaries and doesn't include a staticly
> >linked crt (part of the C runtime AFAIK).
> >
> >Perhaps before you had Darwin ports or the like installed and svn was
> >picking up crt0.o from that?
>
> No. In fact, if I go back to my 1.1.2 tarball that I had archived (last
> release I built from source) and do
>
> ./configure --without-berkeley-db --enable-all-static
> make
>
> Subversion builds just find. Something must have changed in the build
> system?
Yeah, I don't know. I just know that I've had problems with other
programs that want to staticly link on OS X that returned the exact same
error and when I googled around, I saw links to that article.
I don't really know a whole lot about build systems, just something that
I've noticed in the past that might be relevant.
Good luck!
-Dominic
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Jim Correia <ji...@pobox.com>.
On Apr 5, 2005, at 1:04 PM, Dominic Anello wrote:
> Mac OS X doesn't like static binaries and doesn't include a staticly
> linked crt (part of the C runtime AFAIK).
>
> Perhaps before you had Darwin ports or the like installed and svn was
> picking up crt0.o from that?
No. In fact, if I go back to my 1.1.2 tarball that I had archived (last
release I built from source) and do
./configure --without-berkeley-db --enable-all-static
make
Subversion builds just find. Something must have changed in the build
system?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Dominic Anello <da...@danky.com>.
On 2005-04-05 12:04:03 -0400, Jim Correia wrote:
> On Apr 4, 2005, at 8:03 PM, Ben Reser wrote:
>
> >Please test
>
> When building on Mac OS X 10.3.8 I get the following error:
>
> ld: can't locate file for: -lcrt0.o
> make: *** [subversion/clients/cmdline/svn] Error 1
>
> I configured with
>
> ./configure --without-berkeley-db --with-zlib --with-ssl
> --enable-all-static
>
> as I have in the past. The non-static build appears to complete (but I
> didn't do make check on it.)
>
> Jim
Mac OS X doesn't like static binaries and doesn't include a staticly
linked crt (part of the C runtime AFAIK).
Perhaps before you had Darwin ports or the like installed and svn was
picking up crt0.o from that?
See: http://developer.apple.com/qa/qa2001/qa1118.html
-Dominic
Re: 1.2.0-rc1 tarballs up for testing/signing
Posted by Jim Correia <ji...@pobox.com>.
On Apr 4, 2005, at 8:03 PM, Ben Reser wrote:
> Please test
When building on Mac OS X 10.3.8 I get the following error:
ld: can't locate file for: -lcrt0.o
make: *** [subversion/clients/cmdline/svn] Error 1
I configured with
./configure --without-berkeley-db --with-zlib --with-ssl
--enable-all-static
as I have in the past. The non-static build appears to complete (but I
didn't do make check on it.)
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org