You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Anderson <da...@calixo.net> on 2005/11/21 22:35:45 UTC
1.3.0-rc3 tarballs up for testing/signing
After a long lapse in RCs, here is the latest from the factory floor:
Subversion 1.3.0-rc3. The magic revision is r17470.
http://lolut.utbm.info/pub/subversion-1.3.0/rc3/
Noticing that no single tarball reached the required 3 commiter
signatures during the first two RCs because of the effort dilution
induced by the double-tarball regime, we have reverted to the 1.2.x
status quo: a single tarball, containing bundled dependencies.
Also, the Book now officially no longer ships in the tarball.
Please test this and send signatures, critical bug reports, small furry
creatures and free lunches. Don't forget to Cc: me for binding
signatures, so that I can keep track and (perhaps, this time) release to
the general public.
Finally, a small note to package maintainers for various distributions
and operating systems out there: Subversion 1.3.0-rc3 is currently NOT
released to the public. It is released for the benefit of developers
(commiters and otherwise), for testing and validation.
It is most certainly NOT, at this stage, for inclusion in any
distribution, or exposure to non-developer users without due prior
warning. Even the most bleeding edge package trees will probably
want to wait until the release of rc3 to the users@ mailing list (ie.
once it has passed basic independant validation by several commiters).
Just a reminder of what "being released to dev@" actually means, in
terms of readiness-for-public-consumption terms.
Have fun.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by Michael Sweet <mi...@easysw.com>.
Michael Sinz wrote:
> ...
> Anyway, the error is at link time - undefined reference
> svn_diff_file_output_unified2
I have the same problem on a standard FC4 install with GCC 4.0.1...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by Michael Sinz <Mi...@sinz.org>.
David Anderson wrote:
> After a long lapse in RCs, here is the latest from the factory floor:
> Subversion 1.3.0-rc3. The magic revision is r17470.
>
> http://lolut.utbm.info/pub/subversion-1.3.0/rc3/
>
> Noticing that no single tarball reached the required 3 commiter
> signatures during the first two RCs because of the effort dilution
> induced by the double-tarball regime, we have reverted to the 1.2.x
> status quo: a single tarball, containing bundled dependencies.
>
> Also, the Book now officially no longer ships in the tarball.
>
> Please test this and send signatures, critical bug reports, small furry
> creatures and free lunches. Don't forget to Cc: me for binding
> signatures, so that I can keep track and (perhaps, this time) release to
> the general public.
Well, I would send you a free lunch if I can ever find one :-)
Thanks for all of the work, but the build failed on the first
test system I just tried it on. This system had built every prior
version of Subversion (including rc1) and actively runs 1.2.3...
Anyway, the error is at link time - undefined reference svn_diff_file_output_unified2
cd subversion/clients/cmdline && /bin/sh /usr/subversion/build/build-2005-11-22_05-41-40/subversion-1.3.0-rc3/libtool --tag=CC --silent --mode=link gcc -g -O2 -g -O2 -pthread -D_LARGEFILE64_SOURCE -DNE_LFS -rpath /home/subversion/svn/lib -o svn add-cmd.o blame-cmd.o cat-cmd.o checkout-cmd.o cleanup-cmd.o commit-cmd.o copy-cmd.o delete-cmd.o diff-cmd.o export-cmd.o help-cmd.o import-cmd.o info-cmd.o lock-cmd.o log-cmd.o ls-cmd.o main.o merge-cmd.o mkdir-cmd.o move-cmd.o notify.o prompt.o propdel-cmd.o propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o unlock-cmd.o update-cmd.o util.o ../../../subversion/libsvn_client/libsvn_client-1.la ../../../subversion/libsvn_wc/libsvn_wc-1.la ../../../subversion/libsvn_ra/libsvn_ra-1.la ../../../subversion/libsvn_delta/libsvn_delta-1.la ../../../subversion/libsvn_subr/libsvn_subr-1.la
/usr/subversion/build/build-2005-11-22_05-41-40/subversion-1.3.0-rc3/apr-util/libaprutil-0.la -lgdbm -lexpat /usr/subversion/build/build-2005-11-22_05-41-40/subversion-1.3.0-rc3/apr/libapr-0.la -lrt -lm -lcrypt -lnsl -lpthread -ldl /usr/subversion/build/build-2005-11-22_05-41-40/subversion-1.3.0-rc3/neon/src/libneon.la
../../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined reference to `svn_diff_file_output_unified2'
collect2: ld returned 1 exit status
make: *** [subversion/clients/cmdline/svn] Error 1
Configure was run as follows:
./configure \
--prefix=${D_INSTALL}/svn \
--with-ssl \
--without-swig \
--without-berkeley-db \
--with-apxs=${D_INSTALL}/apache/bin/apxs
($D_INSTALL is part of my server build script that defines the
install location for the Subversion server and related Apache)
When I get a chance (I am getting ready to wake up the kids right now) I will
try the build on a different (newer) system. It will just take some time.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: swig: srcdir vs. blddir
Posted by David James <ja...@cs.toronto.edu>.
On 11/23/05, Julian Foad <ju...@btopenworld.com> wrote:
> David James wrote:
> >
> > [[[
> > Always generate SWIG/C files in the source directory.
>
> In the log message, can you try to include a few words to indicate why the
> change is being made, so that somebody who might contest it later on can judge
> whether it was done for a good reason and/or is still appropriate at that
> future time. If it can't be summarised well in a sentence or two, include a
> link to the email thread or issue. This applies to any commit the reason for
> which is not totally self-evident. Thanks.
Good idea! I've added a summary to my log message, and also a link to
the thread. Here's my new log message:
[[[
Always generate SWIG/C files and SWIG headers in the source directory.
(Now that the SWIG generated files are bundled in source tarballs, it makes
sense to treat them as "source directory" files. This change greatly
simplifies our SWIG build system, because we don't have to worry about
copying generated SWIG files from the source directory to the build directory
any more.)
* Makefile.in
(SWIG_PL_SRC_DIR): Add variable.
(EXTRACLEAN_SWIG_HEADERS, EXTRACLEAN_SWIG_PL, EXTRACLEAN_SWIG_PY,
EXTRACLEAN_SWIG_RB): Clean SWIG files from the source directory.
(copy-swig-py): Copy Python files directly from the source directory to
the libsvn directory.
* build/generator/gen_base.py
(TargetSWIG.add_dependencies): Read and write generated SWIG/C files in
the source directory.
* build/generator/gen_make.py
(write): Generate SWIG headers and SWIG/C files in source directory. Don't
copy SWIG/C files from the source directory to the build directory.
Suggested by: epg
Thread: http://svn.haxx.se/dev/archive-2005-11/1207.shtml
]]]
I've committed this patch with several improvements in r17497.
Hope this helps!
David
--
David James -- http://www.cs.toronto.edu/~james
Re: swig: srcdir vs. blddir
Posted by Julian Foad <ju...@btopenworld.com>.
David James wrote:
>
> [[[
> Always generate SWIG/C files in the source directory.
In the log message, can you try to include a few words to indicate why the
change is being made, so that somebody who might contest it later on can judge
whether it was done for a good reason and/or is still appropriate at that
future time. If it can't be summarised well in a sentence or two, include a
link to the email thread or issue. This applies to any commit the reason for
which is not totally self-evident. Thanks.
> * build/generator/gen_make.py
> (write): Generate SWIG/C files in source directory. Don't copy SWIG/C
> files from the source directory to the build directory.
[...]
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: swig: srcdir vs. blddir (was Re: 1.3.0-rc3 tarballs up for testing/signing)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
David James <ja...@cs.toronto.edu> writes:
> I couldn't wait, so I attached a patch which demonstrates your idea.
> Let me know if you have any suggestions or feedback.
I haven't actually tested it, but this looks good.
> We still have some logic in Makefile.in for copying Python files from
> the source directory to the build directory under the copy-swig-py. I
> haven't removed this code yet, but it might be a good idea for us to
> do so
Yeah.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: swig: srcdir vs. blddir (was Re: 1.3.0-rc3 tarballs up for testing/signing)
Posted by David James <ja...@cs.toronto.edu>.
On 11/22/05, Eric Gillespie <ep...@pretzelnet.org> wrote:
> Max Bowsher <ma...@ukf.net> writes:
>
> > The interesting wrinkle here is that, SWIG files which can be shipped in
> > a tarball, or generated during the build, can be in the srcdir OR the
> > blddir, not always one or the other.
>
> That's not very wrinkly, but actually quite common. Files that
> ship in the distfile have to work from srcdir, so why have them
> also work from blddir? Just build them into srcdir instead of
> blddir.
>
> [snip convincing argument for generating SWIG code in the src dir]
Great idea, Eric! I'm convinced. It's not only better to generate our
SWIG code in the source directory, but also much easier.
I couldn't wait, so I attached a patch which demonstrates your idea.
Let me know if you have any suggestions or feedback.
We still have some logic in Makefile.in for copying Python files from
the source directory to the build directory under the copy-swig-py. I
haven't removed this code yet, but it might be a good idea for us to
do so, as soon as we update our install and test suite targets to use
the Python files from the source directory.
[[[
Always generate SWIG/C files in the source directory.
* build/generator/gen_make.py
(write): Generate SWIG/C files in source directory. Don't copy SWIG/C
files from the source directory to the build directory.
* build/generator/gen_base.py
(TargetSWIG.add_dependencies): Read generate SWIG/C dependencies from
the source directory.
Suggested by: epg
]]]
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
Re: swig: srcdir vs. blddir
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-12-16 20:40+0000, Philip Martin wrote:
> > Please see: http://svn.haxx.se/dev/archive-2005-11/1324.shtml
>
> So it fails shortly after r17497 "Always generate SWIG/C files and
> SWIG headers in the source directory", are you using a VPATH build?
>
Yes, the test system is using vpath setup.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: swig: srcdir vs. blddir
Posted by Philip Martin <ph...@codematters.co.uk>.
Jani Averbach <ja...@jaa.iki.fi> writes:
> On 2005-12-16 19:57+0000, Philip Martin wrote:
>
>> Even more annoying is that the perl bindings don't build at all. I've
>> build the perl bindings in the past, so this is a recent breakage.
>
> Last time when swig-pl has worked on my test machine is:
>
> Date: Wed, 23 Nov 2005 05:46:39 -0700
> Subject: swig-pl trunk r17488: PASS (x86_64-unknown-linux-gnushared)
>
> Please see: http://svn.haxx.se/dev/archive-2005-11/1324.shtml
So it fails shortly after r17497 "Always generate SWIG/C files and
SWIG headers in the source directory", are you using a VPATH build?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: swig: srcdir vs. blddir
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-12-16 19:57+0000, Philip Martin wrote:
> Even more annoying is that the perl bindings don't build at all. I've
> build the perl bindings in the past, so this is a recent breakage.
Last time when swig-pl has worked on my test machine is:
Date: Wed, 23 Nov 2005 05:46:39 -0700
Subject: swig-pl trunk r17488: PASS (x86_64-unknown-linux-gnushared)
Please see: http://svn.haxx.se/dev/archive-2005-11/1324.shtml
> rm -f blib/arch/auto/SVN/_Core/_Core.so
> LD_RUN_PATH="/home/pm/sw/subversion/obj/subversion/libsvn_client/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_delta/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_fs/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_ra/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_repos/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_wc/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_diff/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_subr/.libs:/home/pm/sw/subversion/obj/subversion/bindings/swig/perl/libsvn_swig_perl/.libs" cc -shared -L/usr/local/lib core.o -o blib/arch/auto/SVN/_Core/_Core.so -L/home/pm/sw/subversion/obj/subversion/bindings/swig/perl/libsvn_swig_perl/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_client/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_delta/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_fs/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_ra/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_repos/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_wc/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_diff/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_subr/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_ra_local/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_ra_svn/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_ra_dav/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_fs_base/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_fs_fs/.libs -lsvn_client-1 -lsvn_delta-1 -lsvn_fs-1 -lsvn_ra-1 -lsvn_repos-1 -lsvn_wc-1 -lsvn_diff-1 -lsvn_subr-1 -lsvn_swig_perl-1
> cc: core.o: No such file or directory
The problem is same.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: swig: srcdir vs. blddir
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> A more annoying problem is that the 'make -j4 swig-py' parallel build
> is broken, it sometimes fails with
>
> /usr/local/swig-1.3.24/bin/swig -I/home/pm/sw/subversion/obj/../svn/subversion/include -I/home/pm/sw/subversion/obj/../svn/subversion/bindings/swig -I/home/pm/sw/subversion/obj/../svn/subversion/bindings/swig/include -I/home/pm/sw/subversion/obj/../svn/subversion/bindings/swig/proxy -I/home/pm/sw/subversion/obj/subversion/bindings/swig/proxy -I/usr/local/apache2/include -I/usr/local/apache2/include -python -classic -w451 -w305 -o ../svn/subversion/bindings/swig/python/svn_client.c ../svn/subversion/bindings/swig/svn_client.i
> Traceback (most recent call last):
> File "build/generator/swig/external_runtime.py", line 107, in ?
> gen.write()
> File "build/generator/swig/external_runtime.py", line 99, in write
> self.write_long_long_fix()
> File "build/generator/swig/external_runtime.py", line 82, in write_long_long_fix
> self.checkout("python","python.swg")
> File "/home/pm/sw/subversion/svn/build/generator/swig/__init__.py", line 56, in checkout
> shutil.copy("%s/%s/%s" % (self.swig_libdir, dir, file), out)
> File "/usr/lib/python2.3/shutil.py", line 73, in copy
> copymode(src, dst)
> File "/usr/lib/python2.3/shutil.py", line 52, in copymode
> os.chmod(dst, mode)
> OSError: [Errno 2] No such file or directory: 'subversion/bindings/swig/proxy/python.swg'
Even more annoying is that the perl bindings don't build at all. I've
build the perl bindings in the past, so this is a recent breakage.
'make swig-pl' creates the generated C files in the source dir, but no
attempt is made to compile them, and then a link command fails because
the object is not found:
Writing Makefile.wc for SVN::_Wc
cd /home/pm/sw/subversion/obj/subversion/bindings/swig/perl/native; make
make[1]: Entering directory `/home/pm/sw/subversion/obj/subversion/bindings/swig/perl/native'
cp ../../../../../../svn/subversion/bindings/swig/perl/native/Core.pm blib/lib/SVN/Core.pm
cp ../../../../../../svn/subversion/bindings/swig/perl/native/Repos.pm blib/lib/SVN/Repos.pm
cp ../../../../../../svn/subversion/bindings/swig/perl/native/Base.pm blib/lib/SVN/Base.pm
cp ../../../../../../svn/subversion/bindings/swig/perl/native/Client.pm blib/lib/SVN/Client.pm
cp ../../../../../../svn/subversion/bindings/swig/perl/native/Fs.pm blib/lib/SVN/Fs.pm
cp ../../../../../../svn/subversion/bindings/swig/perl/native/Ra.pm blib/lib/SVN/Ra.pm
cp ../../../../../../svn/subversion/bindings/swig/perl/native/Wc.pm blib/lib/SVN/Wc.pm
cp ../../../../../../svn/subversion/bindings/swig/perl/native/Delta.pm blib/lib/SVN/Delta.pm
Running Mkbootstrap for SVN::_Core ()
chmod 644 _Core.bs
rm -f blib/arch/auto/SVN/_Core/_Core.so
LD_RUN_PATH="/home/pm/sw/subversion/obj/subversion/libsvn_client/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_delta/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_fs/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_ra/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_repos/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_wc/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_diff/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_subr/.libs:/home/pm/sw/subversion/obj/subversion/bindings/swig/perl/libsvn_swig_perl/.libs" cc -shared -L/usr/local/lib core.o -o blib/arch/auto/SVN/_Core/_Core.so -L/home/pm/sw/subversion/obj/subversion/bindings/swig/perl/libsvn_swig_perl/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_client/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_delta/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_fs/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_ra/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_repos/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_wc/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_diff/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_subr/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_ra_local/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_ra_svn/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_ra_dav/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_fs_base/.libs -L/home/pm/sw/subversion/obj/subversion/libsvn_fs_fs/.libs -lsvn_client-1 -lsvn_delta-1 -lsvn_fs-1 -lsvn_ra-1 -lsvn_repos-1 -lsvn_wc-1 -lsvn_diff-1 -lsvn_subr-1 -lsvn_swig_perl-1
cc: core.o: No such file or directory
make[1]: *** [blib/arch/auto/SVN/_Core/_Core.so] Error 1
make[1]: Leaving directory `/home/pm/sw/subversion/obj/subversion/bindings/swig/perl/native'
make: *** [swig-pl] Error 2
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: swig: srcdir vs. blddir
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Hudson <gh...@MIT.EDU> writes:
> I don't think "make clean" should be deleting files generated in the
> source tree. That would mean a tarball build would break after a "make
> clean" for users who don't have the tools used to create those files.
My build from a working copy deletes generated files. Looking at the
Makefile it appears to depend on RELEASE_MODE, I'm not sure what sets
that.
> "make distclean" shouldn't remove them either, for that matter, since
> they're part of the distributed files. I guess that's what "make
> extraclean" is for.
>
> Regardless, two parallel builds in separate directories won't be
> independent if you start from the checked-out sources. But they will be
> if you start from the distributed tarball sources; that's good enough
> for me.
I don't build the bindings very often so I'm not really bothered--but
the old system was better :)
A more annoying problem is that the 'make -j4 swig-py' parallel build
is broken, it sometimes fails with
/usr/local/swig-1.3.24/bin/swig -I/home/pm/sw/subversion/obj/../svn/subversion/include -I/home/pm/sw/subversion/obj/../svn/subversion/bindings/swig -I/home/pm/sw/subversion/obj/../svn/subversion/bindings/swig/include -I/home/pm/sw/subversion/obj/../svn/subversion/bindings/swig/proxy -I/home/pm/sw/subversion/obj/subversion/bindings/swig/proxy -I/usr/local/apache2/include -I/usr/local/apache2/include -python -classic -w451 -w305 -o ../svn/subversion/bindings/swig/python/svn_client.c ../svn/subversion/bindings/swig/svn_client.i
Traceback (most recent call last):
File "build/generator/swig/external_runtime.py", line 107, in ?
gen.write()
File "build/generator/swig/external_runtime.py", line 99, in write
self.write_long_long_fix()
File "build/generator/swig/external_runtime.py", line 82, in write_long_long_fix
self.checkout("python","python.swg")
File "/home/pm/sw/subversion/svn/build/generator/swig/__init__.py", line 56, in checkout
shutil.copy("%s/%s/%s" % (self.swig_libdir, dir, file), out)
File "/usr/lib/python2.3/shutil.py", line 73, in copy
copymode(src, dst)
File "/usr/lib/python2.3/shutil.py", line 52, in copymode
os.chmod(dst, mode)
OSError: [Errno 2] No such file or directory: 'subversion/bindings/swig/proxy/python.swg'
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: swig: srcdir vs. blddir
Posted by Philip Martin <ph...@codematters.co.uk>.
David James <ja...@gmail.com> writes:
> If you run ./autogen.sh --release in your source directory, then all
> of your parallel builds should be completely independent.
The only time I used parallel directories to build the bindings was
when I was testing one of the swig transitions--I configured the
builds to use different versions of swig. That doesn't work so well
now, even in release mode, since I only have one set of swig generated
files. I don't do that much testing of the bindings, and since it's
got harder I'll do even less, but so as long as the new system means
that others do *more* testing it's a net win!
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: swig: srcdir vs. blddir
Posted by David James <ja...@gmail.com>.
On 12/15/05, Greg Hudson <gh...@mit.edu> wrote:
> On Thu, 2005-12-15 at 23:57 +0000, Philip Martin wrote:
> > Finally spotted this. One disadvantage of the new system is that
> > multiple parallel builds are no longer independent. Previously it was
> > possible to have two or more build dirs, maybe with different
> > configurations, and each would be independent. With the new system
> > it's no longer possible to configure the builds to use different
> > versions of swig, and running 'make clean' in one dir could break the
> > build in another if the generated files disappear during the build.
> > Now I don't do things like that very often, so it's not a big problem,
> > but I have done both of them in the past.
Phillip, have you tried configuring your source dir in release mode?
If you run ./autogen.sh --release in your source directory, then all
of your parallel builds should be completely independent.
> I don't think "make clean" should be deleting files generated in the
> source tree. That would mean a tarball build would break after a "make
> clean" for users who don't have the tools used to create those files.
>
> "make distclean" shouldn't remove them either, for that matter, since
> they're part of the distributed files. I guess that's what "make
> extraclean" is for.
When we're in release mode, the generated SWIG files will only be
destroyed when you "make extraclean".
On the other hand, if you're starting from checked out sources, the
generated SWIG files will be built at runtime, so it makes sense to
destroy them when you type "make clean".
> Regardless, two parallel builds in separate directories won't be
> independent if you start from the checked-out sources. But they will be
> if you start from the distributed tarball sources; that's good enough
> for me.
If you configure your source directory in release mode, your multiple
parallel builds should be completely independent. That's good enough
for me, too.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
Re: swig: srcdir vs. blddir
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2005-12-15 at 23:57 +0000, Philip Martin wrote:
> Finally spotted this. One disadvantage of the new system is that
> multiple parallel builds are no longer independent. Previously it was
> possible to have two or more build dirs, maybe with different
> configurations, and each would be independent. With the new system
> it's no longer possible to configure the builds to use different
> versions of swig, and running 'make clean' in one dir could break the
> build in another if the generated files disappear during the build.
> Now I don't do things like that very often, so it's not a big problem,
> but I have done both of them in the past.
I don't think "make clean" should be deleting files generated in the
source tree. That would mean a tarball build would break after a "make
clean" for users who don't have the tools used to create those files.
"make distclean" shouldn't remove them either, for that matter, since
they're part of the distributed files. I guess that's what "make
extraclean" is for.
Regardless, two parallel builds in separate directories won't be
independent if you start from the checked-out sources. But they will be
if you start from the distributed tarball sources; that's good enough
for me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: swig: srcdir vs. blddir
Posted by Philip Martin <ph...@codematters.co.uk>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> Max Bowsher <ma...@ukf.net> writes:
>
>> The interesting wrinkle here is that, SWIG files which can be shipped in
>> a tarball, or generated during the build, can be in the srcdir OR the
>> blddir, not always one or the other.
>
> That's not very wrinkly, but actually quite common. Files that
> ship in the distfile have to work from srcdir, so why have them
> also work from blddir? Just build them into srcdir instead of
> blddir.
>
> Before you contest in revulsion that anything you "build" must go
> in the "build dir", realize that's not true. configure,
> documentation, headers, *.in files, and various other bits are
> shipped in srcdir, yet are "built". I think we only have
> configure falling into that category in Subversion today, but
> these swig files should be treated the same way.
>
> The distinction here is not "built files go in blddir", but
> "files added to an unpacked distfile go in blddir". Users are
> not expected to build configure, documentation, or swig files.
>
> I'll post a patch in a couple days to demonstrate, and hopefully
> no one will object to my committing it :).
Finally spotted this. One disadvantage of the new system is that
multiple parallel builds are no longer independent. Previously it was
possible to have two or more build dirs, maybe with different
configurations, and each would be independent. With the new system
it's no longer possible to configure the builds to use different
versions of swig, and running 'make clean' in one dir could break the
build in another if the generated files disappear during the build.
Now I don't do things like that very often, so it's not a big problem,
but I have done both of them in the past.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
swig: srcdir vs. blddir (was Re: 1.3.0-rc3 tarballs up for testing/signing)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Max Bowsher <ma...@ukf.net> writes:
> The interesting wrinkle here is that, SWIG files which can be shipped in
> a tarball, or generated during the build, can be in the srcdir OR the
> blddir, not always one or the other.
That's not very wrinkly, but actually quite common. Files that
ship in the distfile have to work from srcdir, so why have them
also work from blddir? Just build them into srcdir instead of
blddir.
Before you contest in revulsion that anything you "build" must go
in the "build dir", realize that's not true. configure,
documentation, headers, *.in files, and various other bits are
shipped in srcdir, yet are "built". I think we only have
configure falling into that category in Subversion today, but
these swig files should be treated the same way.
The distinction here is not "built files go in blddir", but
"files added to an unpacked distfile go in blddir". Users are
not expected to build configure, documentation, or swig files.
I'll post a patch in a couple days to demonstrate, and hopefully
no one will object to my committing it :).
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by Max Bowsher <ma...@ukf.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric Gillespie wrote:
> Max Bowsher <ma...@ukf.net> writes:
>
>
>>This could have been very usefully used in the Subversion build system.
>>Instead, we have to put up with copying files from srcdir to objdir, in
>>a VPATH setup.
>
>
> As someone who has built fairly complex build systems that
> support srcdir != blddir using standard make, i'm skeptical.
> I've never had to do that.
>
> Though there is usually a better way to construct your rules, at
> the bare minimum this transform always works:
>
> foo: ${srcdir}/bar ${srcdir}/baz ${srcdir}/quux
> foocmd $@ $<
>
> to
>
> FOOSRC=${srcdir}/bar ${srcdir}/baz ${srcdir}/quux
> foo: ${FOOSRC}
> foocmd $@ ${FOOSRC}
>
> Maybe you could point me to the relevant parts of our Makefile?
The interesting wrinkle here is that, SWIG files which can be shipped in
a tarball, or generated during the build, can be in the srcdir OR the
blddir, not always one or the other.
If we could use $<, we wouldn't have to care about generating different
build-outputs.mk files in different situations, and we could just let
make choose the appropriate path automatically.
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDg3r7fFNSmcDyxYARAjgCAJ9/3+5ICDLr+/1AZsAoPwDqjXOZNwCfX5an
Rnz6uVZdX8+B6pCrHH5HCK8=
=ioHt
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Max Bowsher <ma...@ukf.net> writes:
> This could have been very usefully used in the Subversion build system.
> Instead, we have to put up with copying files from srcdir to objdir, in
> a VPATH setup.
As someone who has built fairly complex build systems that
support srcdir != blddir using standard make, i'm skeptical.
I've never had to do that.
Though there is usually a better way to construct your rules, at
the bare minimum this transform always works:
foo: ${srcdir}/bar ${srcdir}/baz ${srcdir}/quux
foocmd $@ $<
to
FOOSRC=${srcdir}/bar ${srcdir}/baz ${srcdir}/quux
foo: ${FOOSRC}
foocmd $@ ${FOOSRC}
Maybe you could point me to the relevant parts of our Makefile?
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by Max Bowsher <ma...@ukf.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric Gillespie wrote:
> it's using $<, which is only defined for implicit rules (yes, i'm
> aware that GNU stupidly breaks this, but we haven't required GNU
> make before and i hope we're not going to start).
WHOA! STOP!
I can accept the argument that GNU make has features which are
non-portable, and we should be portable to generic Unix make.
But do *NOT* call an extremely useful feature stupid!!!
This could have been very usefully used in the Subversion build system.
Instead, we have to put up with copying files from srcdir to objdir, in
a VPATH setup.
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDgtrvfFNSmcDyxYARAtNxAJ9h6af75d/2gOq57iJrntApGuon2QCfZmXr
8lzhulmqFHdOG+oadrg0j/E=
=d2IH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Max Bowsher <ma...@ukf.net> writes:
> Uhh...
>
> $ fgrep '$<' subversion-1.3.0-rc3/build-outputs.mk
> $
> $ wcgrep -F '$<' subversion-1.3.0-rc3/build/generator/
> $
>
>
> Whatever it is you built, it wasn't RC3.
Worse. I built rc3 with a rc2 build-outputs.mk. It works now,
imagine that :).
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by Max Bowsher <ma...@ukf.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric Gillespie wrote:
> This has serious swig-related regressions from rc2. Is anyone
> else testing without swig? This is currently broken. Even with
> swig, it's broken unless you're using GNU make.
>
> 1. build-outputs.mk has
> subversion/bindings/swig/perl/native/core.c depending on
> subversion/bindings/swig/proxy/*.swg
>
> 2. These files are newer than core.c in this tar file (i assume
> the other files for the Python build, and maybe Perl and Ruby,
> have the same problem), so make tries to run swig ('none', in
> my case) to regenerate core.c
>
> 3. To see if there were other problems, i work around this:
> touch -t 11211533 subversion/bindings/swig/proxy/*
>
> 4. I'm not sure why, but after that, (some of?) the rules to
> build proxy/* are triggered. This, too, is broken:
>
> subversion/bindings/swig/proxy/svn_error_codes_h.swg: subversion/include/svn_error_codes.h
> $(abs_srcdir)/build/generator/swig/header_wrappers.py $(PYTHON) $(abs_srcdir)/build/generator/swig/header_wrappers.py $(abs_srcdir)/build.conf $(SWIG) $<
>
> Again, SWIG = 'none', so it's broken anyway. On top of that,
> it's using $<
Uhh...
$ fgrep '$<' subversion-1.3.0-rc3/build-outputs.mk
$
$ wcgrep -F '$<' subversion-1.3.0-rc3/build/generator/
$
Whatever it is you built, it wasn't RC3.
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDgt//fFNSmcDyxYARAva7AJwMZr41O5REhdh0ILQzE0vm6voQOQCcCrOE
+91ktln2v93I1wvL1GLklCE=
=9mZL
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by David James <ja...@cs.toronto.edu>.
On 11/22/05, Eric Gillespie <ep...@pretzelnet.org> wrote:
> This has serious swig-related regressions from rc2. Is anyone
> else testing without swig? This is currently broken.
[...]
> Again, SWIG = 'none', so it's broken anyway. On top of that,
> it's using $<, which is only defined for implicit rules
Looks like you're still building RC2. I've verified that
build-outputs.mk contains no references to SWIG or to '$<' in RC3. Can
you give it another try?
Thanks!
David
--
David James -- http://www.cs.toronto.edu/~james
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by Eric Gillespie <ep...@pretzelnet.org>.
This has serious swig-related regressions from rc2. Is anyone
else testing without swig? This is currently broken. Even with
swig, it's broken unless you're using GNU make.
1. build-outputs.mk has
subversion/bindings/swig/perl/native/core.c depending on
subversion/bindings/swig/proxy/*.swg
2. These files are newer than core.c in this tar file (i assume
the other files for the Python build, and maybe Perl and Ruby,
have the same problem), so make tries to run swig ('none', in
my case) to regenerate core.c
3. To see if there were other problems, i work around this:
touch -t 11211533 subversion/bindings/swig/proxy/*
4. I'm not sure why, but after that, (some of?) the rules to
build proxy/* are triggered. This, too, is broken:
subversion/bindings/swig/proxy/svn_error_codes_h.swg: subversion/include/svn_error_codes.h
$(abs_srcdir)/build/generator/swig/header_wrappers.py $(PYTHON) $(abs_srcdir)/build/generator/swig/header_wrappers.py $(abs_srcdir)/build.conf $(SWIG) $<
Again, SWIG = 'none', so it's broken anyway. On top of that,
it's using $<, which is only defined for implicit rules (yes, i'm
aware that GNU stupidly breaks this, but we haven't required GNU
make before and i hope we're not going to start). Thus, i can't
even tell which file is triggering the rebuild. I couldn't even
build if i did have swig installed.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by Daniel Berlin <db...@dberlin.org>.
On Mon, 2005-11-21 at 23:35 +0100, David Anderson wrote:
> After a long lapse in RCs, here is the latest from the factory floor:
> Subversion 1.3.0-rc3. The magic revision is r17470.
>
> http://lolut.utbm.info/pub/subversion-1.3.0/rc3/
>
> Noticing that no single tarball reached the required 3 commiter
> signatures during the first two RCs because of the effort dilution
> induced by the double-tarball regime, we have reverted to the 1.2.x
> status quo: a single tarball, containing bundled dependencies.
>
> Also, the Book now officially no longer ships in the tarball.
>
> Please test this and send signatures, critical bug reports, small furry
> creatures and free lunches. Don't forget to Cc: me for binding
> signatures, so that I can keep track and (perhaps, this time) release to
> the general public.
>
> Finally, a small note to package maintainers for various distributions
> and operating systems out there: Subversion 1.3.0-rc3 is currently NOT
> released to the public. It is released for the benefit of developers
> (commiters and otherwise), for testing and validation.
>
> It is most certainly NOT, at this stage, for inclusion in any
> distribution, or exposure to non-developer users without due prior
> warning. Even the most bleeding edge package trees will probably
> want to wait until the release of rc3 to the users@ mailing list (ie.
> once it has passed basic independant validation by several commiters).
Tested completed on ppc-linx and x86-linux with fsfs and bdb and
svncheck :)
.gz sig:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQBDg+Ae7FmgR1HlB6wRArBcAKCg3kNhDag37P3XZ96o/bk3TYwG1gCfbAk5
daFCqzjWJzf43iXLCsw9PaA=
=+jYb
-----END PGP SIGNATURE-----
.bz2 sig:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQBDg+AW7FmgR1HlB6wRAnR7AJ4x9KQ83ynABsUrOapqmcgQK3X3MACdH7Ac
ktj2XfrSUFAuQRhlhmc3JHI=
=SRO4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by David James <ja...@cs.toronto.edu>.
On 11/21/05, David Anderson <da...@calixo.net> wrote:
> After a long lapse in RCs, here is the latest from the factory floor:
> Subversion 1.3.0-rc3. The magic revision is r17470.
>
> http://lolut.utbm.info/pub/subversion-1.3.0/rc3/
Passes make check and make svncheck with FSFS and BDB.
Passes make check-swig-pl, make check-swig-py, make check-swig-rb, and
make check-javahl.
(Tested on Linux 2.4)
subversion-1.3.0-rc3.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQBDgnEfLRA4bItz/Q4RAgi2AKDBk2dXPysMF4hwTiXaaSnQdPT8rACgwwPw
ADJsy/zwRsQ9ZoVZIbN8nKE=
=5QH/
-----END PGP SIGNATURE-----
subversion-1.3.0-rc3.tar.bz2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQBDgnGvLRA4bItz/Q4RAtH4AKC1xYH2DJi8v5LB04cW2gZODJHCLgCgie8q
WmkF2DAHZMLY91E6pRQr4RY=
=QZuu
-----END PGP SIGNATURE-----
Signed as: David James <ja...@cs.toronto.edu>
Fingerprint: 31CE 283E A5AD A57C 476F 1FA7 2D10 386C 8B73 FD0E
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by Barry Scott <ba...@barrys-emacs.org>.
On Nov 22, 2005, at 23:35, David Anderson wrote:
> Barry Scott wrote:
>> It does not build against neon 0.25.3 as recommended to make svn
>> lock work
>> against old svn servers.
>> It does not build with .net 2003, the .ezt files I fixed are not
>> in the kit.
>> Having provided the fixed .ezt files I'm disappointed they are not in
>> rc3.
>
> I'm sorry to hear all this. I did not follow the discussions and
> changeset integrations leading up to the rolling of -rc3, and so
> can't really comment on what happened to the fixes you proposed.
>
> Can someone who followed this summarize what happened, and perhaps
> clarify why -rc3 (and therefore -rc4) doesn't seem to include
> Barry's fixes? If this is a genuine case of missing fixes (and not
> another problem with otherwise sane code), we'll need an -rc5, and
> I'd like it to happen fast.
See the thread "1.3.0-rc2 build fails on windows with .net 2003
compiler" on Nov 6.
My last reply contains the ezt files as an attachment. And the thread
has the discussion
of the issues.
I see that INSTALL says that neon 0.24.7 or 0.25.3 can be used. I
think you need
to let packages know that if they use 0.24.7 that svn lock will not
fail gracefully when
run against old svn servers.
Barry
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by David Anderson <da...@calixo.net>.
Barry Scott wrote:
> It does not build against neon 0.25.3 as recommended to make svn lock work
> against old svn servers.
> It does not build with .net 2003, the .ezt files I fixed are not in the
> kit.
> Having provided the fixed .ezt files I'm disappointed they are not in
> rc3.
I'm sorry to hear all this. I did not follow the discussions and
changeset integrations leading up to the rolling of -rc3, and so can't
really comment on what happened to the fixes you proposed.
Can someone who followed this summarize what happened, and perhaps
clarify why -rc3 (and therefore -rc4) doesn't seem to include Barry's
fixes? If this is a genuine case of missing fixes (and not another
problem with otherwise sane code), we'll need an -rc5, and I'd like it
to happen fast.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by Barry Scott <ba...@barrys-emacs.org>.
On Nov 22, 2005, at 05:06, Ben Collins-Sussman wrote:
> On 11/21/05, David Anderson <da...@calixo.net> wrote:
>> After a long lapse in RCs, here is the latest from the factory floor:
>> Subversion 1.3.0-rc3. The magic revision is r17470.
>
> It builds and passes all 6 combinations of tests on Windows. (Note,
> however, that I did not try to build anything swig-related.)
>
It does not build against neon 0.25.3 as recommended to make svn lock
work
against old svn servers.
It does not build with .net 2003, the .ezt files I fixed are not in
the kit.
Having provided the fixed .ezt files I'm disappointed they are not in
rc3.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 11/21/05, David Anderson <da...@calixo.net> wrote:
> After a long lapse in RCs, here is the latest from the factory floor:
> Subversion 1.3.0-rc3. The magic revision is r17470.
It builds and passes all 6 combinations of tests on Windows. (Note,
however, that I did not try to build anything swig-related.)
subversion-1.3.0-rc3.zip:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQBDgp8hU0gaaOxrUVYRArj1AJ9ikFS57nSo26llD6qEtyF85S0tIQCfY5hA
j9fm9KkgIQCiDUStHezMHo8=
=XgJa
-----END PGP SIGNATURE-----
Signed as:
sec 1024D/EC6B5156 1998-11-09
uid Ben Collins-Sussman <su...@red-bean.com>
uid Ben Collins-Sussman <su...@google.com>
Fingerprint: 9FBF BEB7 409D D55F 6946 5CC6 5348 1A68 EC6B 5156
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 22 Nov 2005 10:01:09 -0600, kfogel@collab.net <kf...@collab.net> wrote:
> I was just about to post sigs for rc3, which passed 6-way tests, heh.
> But at least I'm already set up to test rc4 now... Will watch for it.
My poor windows box... churning for hours last night... all for naught. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by kf...@collab.net.
David Anderson <da...@calixo.net> writes:
> Okay, everyone forget about testing rc3. I'm off to an exam now, I'll
> get a quick rc4 out when I get back.
>
> As I said on IRC yesterday, for something totally unrelated - "Stupid
> stupid stupid".
No problem, David, and thanks for your persistence.
I was just about to post sigs for rc3, which passed 6-way tests, heh.
But at least I'm already set up to test rc4 now... Will watch for it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by David Anderson <da...@calixo.net>.
Peter N. Lundblad wrote:
> OK. Seems like the libtool provided by Debian got used while rolling the
> tarball.
Wha?...
Oh, shit.
Right, my stupid fault. Forgot to set the paths right before rolling.
I *knew* I was forgetting something.
Okay, everyone forget about testing rc3. I'm off to an exam now, I'll
get a quick rc4 out when I get back.
As I said on IRC yesterday, for something totally unrelated - "Stupid
stupid stupid".
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Tue, 22 Nov 2005, John Szakmeister wrote:
> On Monday 21 November 2005 17:35, David Anderson wrote:
> > After a long lapse in RCs, here is the latest from the factory floor:
> > Subversion 1.3.0-rc3. The magic revision is r17470.
> >
> Sorry for the pasted output, but I'm getting the following on my machine,
> which has never failed before:
[Snipped link errors due to libtool The Fool picking up the wrong libs.]
pl@fnapp:~/src/svn/1.3/subversion-1.3.0-rc3$ pwd
/home/pl/src/svn/1.3/subversion-1.3.0-rc3
pl@fnapp:~/src/svn/1.3/subversion-1.3.0-rc3$ ./libtool --version
ltmain.sh (GNU libtool) 1.5.20 Debian 1.5.20-2 (1.1220.2.287 2005/08/31 18:54:15)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
pl@fnapp:~/src/svn/1.3/subversion-1.3.0-rc3$
Skriptet fÃĪrdigt tis 22 nov 2005 12.46.33
OK. Seems like the libtool provided by Debian got used while rolling the
tarball. Seems like we're up for an RC4. Good we have those sig
requirement nowadays...
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.3.0-rc3 tarballs up for testing/signing
Posted by John Szakmeister <jo...@szakmeister.net>.
On Monday 21 November 2005 17:35, David Anderson wrote:
> After a long lapse in RCs, here is the latest from the factory floor:
> Subversion 1.3.0-rc3. The magic revision is r17470.
>
> http://lolut.utbm.info/pub/subversion-1.3.0/rc3/
>
> Noticing that no single tarball reached the required 3 commiter
> signatures during the first two RCs because of the effort dilution
> induced by the double-tarball regime, we have reverted to the 1.2.x
> status quo: a single tarball, containing bundled dependencies.
>
> Also, the Book now officially no longer ships in the tarball.
>
> Please test this and send signatures, critical bug reports, small furry
> creatures and free lunches. Don't forget to Cc: me for binding
> signatures, so that I can keep track and (perhaps, this time) release to
> the general public.
>
> Finally, a small note to package maintainers for various distributions
> and operating systems out there: Subversion 1.3.0-rc3 is currently NOT
> released to the public. It is released for the benefit of developers
> (commiters and otherwise), for testing and validation.
>
> It is most certainly NOT, at this stage, for inclusion in any
> distribution, or exposure to non-developer users without due prior
> warning. Even the most bleeding edge package trees will probably
> want to wait until the release of rc3 to the users@ mailing list (ie.
> once it has passed basic independant validation by several commiters).
>
> Just a reminder of what "being released to dev@" actually means, in
> terms of readiness-for-public-consumption terms.
Sorry for the pasted output, but I'm getting the following on my machine,
which has never failed before:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
cd subversion/tests/libsvn_ra_local
&& /bin/sh /tmp/sub/subversion-1.3.0-rc3/libtool --tag=CC --silent
--mode=link gc c -g -O2 -g -O2 -pthread -D_LARGEFILE64_SOURCE -DNE_LFS
-rpath /usr/local/lib -o ra-local-test
ra-local-test.o ../../../subversion/tests/libsvn_test-1.la ../../../subversion/libsvn_ra_local/libsvn_ra_local-1.la ../../../subversi
on/libsvn_ra/libsvn_ra-1.la ../../../subversion/libsvn_fs/libsvn_fs-1.la ../../../subversion/libsvn_delta/libsvn_delt
a-1.la ../../../subversion/libsvn_subr/libsvn_subr-1.la /tmp/sub/subversion-1.3.0-rc3/apr-util/libaprutil-0.la
-lgdbm -ldb-4.3 -lexpat /tmp/sub/subversion-1.3.0-rc3/apr/libapr-0.la -lrt
-lm -lcrypt -lnsl -lpthread -ldl -lz
cd subversion/tests/libsvn_delta
&& /bin/sh /tmp/sub/subversion-1.3.0-rc3/libtool --tag=CC --silent
--mode=link gcc -g -O2 -g -O2 -pthread -D_LARGEFILE64_SOURCE -DNE_LFS
-rpath /usr/local/lib -o random-test
random-test.o ../../. ./subversion/tests/libsvn_test-1.la ../../../subversion/libsvn_delta/libsvn_delta-1.la ../../../subversion/libsvn_sub
r/libsvn_subr-1.la /tmp/sub/subversion-1.3.0-rc3/apr-util/libaprutil-0.la
-lgdbm -ldb-4.3 -lexpat /tmp/sub/subversion -1.3.0-rc3/apr/libapr-0.la -lrt
-lm -lcrypt -lnsl -lpthread -ldl -lz
../../../subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.so: undefined
reference to `svn_repos_get_commit_editor3'
collect2: ld returned 1 exit status
make: *** [subversion/tests/libsvn_ra_local/ra-local-test] Error 1
make: *** Waiting for unfinished jobs....
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
It looks like libsvn_repos is missing from the link step.
:: uname -a
Linux peanut 2.6.13-15-smp #1 SMP Tue Sep 13 14:56:15 UTC 2005 i686 athlon
i386 GNU/Linux
:: cat /etc/SuSE-release
SUSE LINUX 10.0 (i586)
VERSION = 10.0
:: make -v
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
:: gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,f95,java,ada --disable-checking
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk
--disable-libjava-multilib --with-slibdir=/lib --with-system-zlib
--enable-shared --enable-__cxa_atexit --without-system-libunwind
--host=i586-suse-linux
Thread model: posix
gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org