From Franz.Sirl-kernel at lauterbach.com Wed Sep 1 13:06:15 2021 From: Franz.Sirl-kernel at lauterbach.com (Franz Sirl) Date: Wed, 1 Sep 2021 13:06:15 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org> Message-ID: <4677fe55-8874-534c-6bc9-740d5b258226@lauterbach.com> Am 2021-08-31 um 14:14 schrieb Dagobert Michelsen via users: > Hi Daniel, > > Am 30.08.2021 um 16:01 schrieb Dagobert Michelsen via users : >> Am 28.08.2021 um 21:57 schrieb Daniel Sahlberg via users : >>> Is there any chance to rebuild Subversion using the 1.14.1 version? >> >> I?m giving it a try! The build looks promising, current blocker is >> missind py3c which is needed for the svn python module. I?ll keep you >> posted. > > The version bump was pretty much straight forward. Please have a look at the package > in experimental and let me know how it goes so I can push it to unstable/ next: > http://buildfarm.opencsw.org/experimental.html#subversion Hi Dagobert, that's great! I also tried to build subversion-1.14.1 myself, but couldn't pass the bindings hurdle yet :-(. But on the way there I noticed that 64-bit apr is broken and that's also the reason that 64-bit (when activated in the package Makefile with BUILD64=1) subversion didn't pass the tests. See the attached patch for the needed changes. I needed a 64-bit subversion so I can work against a Linux NFS server with 64-bit directory cookies. In principle a 32-bit subversion can also do this, but in that case apr has to be compiled with -D_FILE_OFFSET_BITS=64. Unfortunately this would change the apr ABI and all depending packages have to be recompiled. The attached patch also includes (not activated) preparations for -D_FILE_OFFSET_BITS=64. The other attached patches for libserf and scons were needed for me to build successfully on Solaris10 and 11, but maybe the reason is just that my build environment differs slightly from the official OpenCSW one. regards, Franz Sirl -------------- next part -------------- Index: apr/trunk/Makefile =================================================================== --- apr/trunk/Makefile (revision 26746) +++ apr/trunk/Makefile (working copy) @@ -11,10 +11,29 @@ MASTER_SITES = http://mirrors.ae-online.de/apache/apr/ DISTFILES = $(NAME)-$(VERSION).tar.gz +# apr.h needs PATH_MAX from limits.h defined, otherwise it will #error. +# So define __EXTENSIONS__ in build/apr_hints.m4 to make sure +# it is propagated to all users via 'apr-1-config --cppflags'. +# Acutually 'configure' checks for and enables __EXTENSIONS__, but it +# doesn't end up in 'apr-1-config --cppflags' without this patch. +PATCHFILES += 0001-Define-__EXTENSIONS__-so-that-also-all-apr.h-users-g.patch +# apr usually uses -D_LARGEFILE64_SOURCE to get support for large files +# on 32-bit OSes. +# Unfortunately this still doesn't support filesystems (eg. NFS) with +# 64-bit directory "cookies". For this to work we need +# to define _FILE_OFFSET_BITS=64 for apr and it's users via build/apr_hints.m4. +# (!!!) If you enable this patch, you need to also rebuild the whole +# dependency tree that depends on apr. +#PATCHFILES-32 += 0002-Define-_FILE_OFFSET_BITS-64-so-that-subversion-can-a.patch +PATCHFILES += $(PATCHFILES-$(MEMORYMODEL)) LICENSE = LICENSE VENDOR_URL = https://apr.apache.org/ +BUILD_DEP_PKGS += CSWautoconf +BUILD_DEP_PKGS += CSWautomake +BUILD_DEP_PKGS += CSWlibtool + PACKAGES += CSWlibapr1-0 SPKG_DESC_CSWlibapr1-0 = Apache portable runtime, libapr-1.so.0 PKGFILES_CSWlibapr1-0 += $(call pkgfiles_lib,libapr-1.so.0) @@ -48,8 +67,21 @@ EXTRA_MERGE_DIRS_isa-extra = $(libexecdir) +EXTRA_PAX_ARGS-32 = -s ",^\.$(includedir)/apr.h$$,.$(includedir)/apr-32.h,p" +EXTRA_PAX_ARGS-64 = -s ",^\.$(includedir)/apr.h$$,.$(includedir)/apr-64.h,p" +EXTRA_PAX_ARGS = $(EXTRA_PAX_ARGS-$(MEMORYMODEL)) + include gar/category.mk +# trigger re-configuration because of the build/apr_hints.m4 changes +pre-configure-modulated: + @(cd $(WORKSRC); ./buildconf ) + @$(MAKECOOKIE) + +post-merge: + ginstall $(FILEDIR)/apr.h $(PKGROOT)$(includedir)/apr.h + @$(MAKECOOKIE) + post-install-modulated: perl -pi -e 's,/usr/local/lib,$(libdir),g;' \ -e 's,#! /bin/bash,#!$(bindir_install)/bash,g;' \ Index: apr/trunk/files/0001-Define-__EXTENSIONS__-so-that-also-all-apr.h-users-g.patch =================================================================== --- apr/trunk/files/0001-Define-__EXTENSIONS__-so-that-also-all-apr.h-users-g.patch (nonexistent) +++ apr/trunk/files/0001-Define-__EXTENSIONS__-so-that-also-all-apr.h-users-g.patch (working copy) @@ -0,0 +1,26 @@ +From 5990f4150c662657a508ef3715378ab825707b3d Mon Sep 17 00:00:00 2001 +From: Franz Sirl +Date: Fri, 23 Apr 2021 12:42:57 +0200 +Subject: [PATCH 1/2] Define __EXTENSIONS__ so that also all apr.h users get + PATH_MAX from limits.h. + +--- + build/apr_hints.m4 | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/build/apr_hints.m4 b/build/apr_hints.m4 +index fd3d33d..ba53663 100644 +--- a/build/apr_hints.m4 ++++ b/build/apr_hints.m4 +@@ -236,7 +236,7 @@ dnl # Not a problem in 10.20. Otherwise, who knows? + ;; + *-solaris2*) + PLATOSVERS=`echo $host | sed 's/^.*solaris2.//'` +- APR_ADDTO(CPPFLAGS, [-DSOLARIS2=$PLATOSVERS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT]) ++ APR_ADDTO(CPPFLAGS, [-DSOLARIS2=$PLATOSVERS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D__EXTENSIONS__]) + if test $PLATOSVERS -eq 10; then + # pthread_mutex_timedlock is broken on Solaris 10. + # It can block without timeout in case of EDEADLK. +-- +2.3.1 + Index: apr/trunk/files/0002-Define-_FILE_OFFSET_BITS-64-so-that-subversion-can-a.patch =================================================================== --- apr/trunk/files/0002-Define-_FILE_OFFSET_BITS-64-so-that-subversion-can-a.patch (nonexistent) +++ apr/trunk/files/0002-Define-_FILE_OFFSET_BITS-64-so-that-subversion-can-a.patch (working copy) @@ -0,0 +1,26 @@ +From 840c0a96376c8028490e4cf04cc7046703b55a50 Mon Sep 17 00:00:00 2001 +From: Franz Sirl +Date: Fri, 23 Apr 2021 12:45:51 +0200 +Subject: [PATCH 2/2] Define _FILE_OFFSET_BITS=64 so that subversion can also + work against newer NFS servers. + +--- + build/apr_hints.m4 | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/build/apr_hints.m4 b/build/apr_hints.m4 +index ba53663..0c3437f 100644 +--- a/build/apr_hints.m4 ++++ b/build/apr_hints.m4 +@@ -236,7 +236,7 @@ dnl # Not a problem in 10.20. Otherwise, who knows? + ;; + *-solaris2*) + PLATOSVERS=`echo $host | sed 's/^.*solaris2.//'` +- APR_ADDTO(CPPFLAGS, [-DSOLARIS2=$PLATOSVERS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D__EXTENSIONS__]) ++ APR_ADDTO(CPPFLAGS, [-DSOLARIS2=$PLATOSVERS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64]) + if test $PLATOSVERS -eq 10; then + # pthread_mutex_timedlock is broken on Solaris 10. + # It can block without timeout in case of EDEADLK. +-- +2.3.1 + Index: apr/trunk/files/apr.h =================================================================== --- apr/trunk/files/apr.h (nonexistent) +++ apr/trunk/files/apr.h (working copy) @@ -0,0 +1,6 @@ +/* Allow 32 and 64 bit headers to coexist */ +#if defined __amd64 || defined __x86_64 || defined __sparcv9 +# include +#else +# include +#endif -------------- next part -------------- Index: libserf/trunk/Makefile =================================================================== --- libserf/trunk/Makefile (revision 26746) +++ libserf/trunk/Makefile (working copy) @@ -14,11 +14,14 @@ MASTER_SITES = http://mirror.serversupportforum.de/apache/serf/ DISTFILES += $(DISTNAME).tar.bz2 -#PATCHFILES += 0001-mark-solaris-as-posix-for-scons.patch +PATCHFILES += 0001-Remove-sunos5-exclusion.patch +PATCHFILES += 0002-Force-GCC-toolchain-instead-of-relying-on-the-defaul.patch LICENSE = LICENSE VENDOR_URL = https://serf.apache.org/ +GARCOMPILER = GNU + CONFIGURE_SCRIPTS = BUILD_SCRIPTS = serf INSTALL_SCRIPTS = serf @@ -33,6 +36,7 @@ PACKAGES += CSWlibserf1-1 SPKG_DESC_CSWlibserf1-1 += HTTP client library built on APR, multiplexes connections, libserf-1.so.1 +PKGFILES_CSWlibserf1-1 += $(call pkgfiles_lib,libserf-1.so.1) RUNTIME_DEP_PKGS_CSWlibserf1-1 += CSWlibapr1-0 RUNTIME_DEP_PKGS_CSWlibserf1-1 += CSWlibaprutil1-0 RUNTIME_DEP_PKGS_CSWlibserf1-1 += CSWlibssl1-0-0 @@ -48,7 +52,7 @@ PACKAGES += CSWlibserf-dev CATALOGNAME_CSWlibserf-dev = libserf_dev SPKG_DESC_CSWlibserf-dev = Development files for libserf-1.so.1 -PKGFILES_CSWlibserf-dev += $(PKGFILES_DEVEL) +# PKGFILES is catchall RUNTIME_DEP_PKGS_CSWlibserf-dev = CSWlibserf1-1 BUILD64 = 1 @@ -60,6 +64,7 @@ # scons doesn't honor CFLAGS, LDFLAGS... environment variables # so we must explicitely pass them as arguments +SCONS_FLAGS += CC="$(CC)" SCONS_FLAGS += CFLAGS="$(CFLAGS)" # scons expands the $ISADIR variable, so we must do some more Index: libserf/trunk/files/0001-Remove-sunos5-exclusion.patch =================================================================== --- libserf/trunk/files/0001-Remove-sunos5-exclusion.patch (nonexistent) +++ libserf/trunk/files/0001-Remove-sunos5-exclusion.patch (working copy) @@ -0,0 +1,26 @@ +From b9d271127d6bb06cdb9ed03de94073032995ffc8 Mon Sep 17 00:00:00 2001 +From: Franz Sirl +Date: Thu, 22 Apr 2021 18:11:53 +0200 +Subject: [PATCH 1/2] Remove sunos5 exclusion + +--- + SConstruct | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/SConstruct b/SConstruct +index 4358a23..9f32566 100644 +--- a/SConstruct ++++ b/SConstruct +@@ -215,8 +215,7 @@ incdir = '$PREFIX/include/serf-$MAJOR' + # Unfortunately we can't set the .dylib compatibility_version option separately + # from current_version, so don't use the PATCH level to avoid that build and + # runtime patch levels have to be identical. +-if sys.platform != 'sunos5': +- env['SHLIBVERSION'] = '%d.%d.%d' % (MAJOR, MINOR, 0) ++env['SHLIBVERSION'] = '%d.%d.%d' % (MAJOR, MINOR, 0) + + LIBNAME = 'libserf-%d' % (MAJOR,) + if sys.platform != 'win32': +-- +2.4.0 + Index: libserf/trunk/files/0002-Force-GCC-toolchain-instead-of-relying-on-the-defaul.patch =================================================================== --- libserf/trunk/files/0002-Force-GCC-toolchain-instead-of-relying-on-the-defaul.patch (nonexistent) +++ libserf/trunk/files/0002-Force-GCC-toolchain-instead-of-relying-on-the-defaul.patch (working copy) @@ -0,0 +1,25 @@ +From 89a049c01f4e6198e067d28ca6d2bf1c790c2e98 Mon Sep 17 00:00:00 2001 +From: Franz Sirl +Date: Fri, 23 Apr 2021 10:23:40 +0200 +Subject: [PATCH 2/2] Force GCC toolchain instead of relying on the default + +--- + SConstruct | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/SConstruct b/SConstruct +index 9f32566..2f261c2 100644 +--- a/SConstruct ++++ b/SConstruct +@@ -153,7 +153,7 @@ if sys.platform == 'win32': + ) + + env = Environment(variables=opts, +- tools=('default', 'textfile',), ++ tools=('gcc', 'gnulink', 'ar', 'textfile',), + CPPPATH=['.', ], + ) + +-- +2.4.0 + -------------- next part -------------- Index: scons/trunk/Makefile =================================================================== --- scons/trunk/Makefile (revision 26746) +++ scons/trunk/Makefile (working copy) @@ -1,7 +1,7 @@ # $Id$ NAME = scons -VERSION = 2.5.1 +VERSION = 3.1.2 CATEGORIES = python GARTYPE = v2 @@ -36,6 +36,7 @@ ARCHALL_CSWscons = 1 CHECKPKG_OVERRIDES_CSWscons += file-with-bad-content # We definitely need Python 2.7 +MODULATIONS_PYTHON_VERSION = 2_7 RUNTIME_DEP_PKGS_CSWscons += CSWpython27 CHECKPKG_OVERRIDES_CSWscons += surplus-dependency|CSWpython27 Index: scons/trunk/checksums =================================================================== --- scons/trunk/checksums (revision 26746) +++ scons/trunk/checksums (working copy) @@ -1 +1 @@ -aaaf09e1351a598f98d17b0cf1103e7a scons-2.5.1.tar.gz +77b2f8ac2661b7a4fad51c17cb7f1b25 scons-3.1.2.tar.gz From noloader at gmail.com Wed Sep 1 13:28:12 2021 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 1 Sep 2021 07:28:12 -0400 Subject: Subversion 1.14.1 In-Reply-To: <4677fe55-8874-534c-6bc9-740d5b258226@lauterbach.com> References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org> <4677fe55-8874-534c-6bc9-740d5b258226@lauterbach.com> Message-ID: On Wed, Sep 1, 2021 at 7:14 AM Franz Sirl via users wrote: > > Am 2021-08-31 um 14:14 schrieb Dagobert Michelsen via users: > > Am 30.08.2021 um 16:01 schrieb Dagobert Michelsen via users : > >> Am 28.08.2021 um 21:57 schrieb Daniel Sahlberg via users : > >>> Is there any chance to rebuild Subversion using the 1.14.1 version? > >> > >> I?m giving it a try! The build looks promising, current blocker is > >> missind py3c which is needed for the svn python module. I?ll keep you > >> posted. > > > > The version bump was pretty much straight forward. Please have a look at the package > > in experimental and let me know how it goes so I can push it to unstable/ next: > > http://buildfarm.opencsw.org/experimental.html#subversion > ... > > The other attached patches for libserf and scons were needed for me to > build successfully on Solaris10 and 11, but maybe the reason is just > that my build environment differs slightly from the official OpenCSW one. Hi Franz, I noticed this in apr-nfs.patch: +# apr.h needs PATH_MAX from limits.h defined, otherwise it will #error. +# So define __EXTENSIONS__ in build/apr_hints.m4 to make sure +# it is propagated to all users via 'apr-1-config --cppflags'. Hurd does not define PATH_MAX , so it will lead to a compile problem on the GNU's OS. I mention it in case you are interested in supporting Hurd. Hurd and PATH_MAX break a lot of packages. Jeff From dam at opencsw.org Wed Sep 1 14:28:40 2021 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 1 Sep 2021 14:28:40 +0200 Subject: Subversion 1.14.1 In-Reply-To: <4677fe55-8874-534c-6bc9-740d5b258226@lauterbach.com> References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org> <4677fe55-8874-534c-6bc9-740d5b258226@lauterbach.com> Message-ID: Hi Franz, Am 01.09.2021 um 13:06 schrieb Franz Sirl : > that's great! I also tried to build subversion-1.14.1 myself, but couldn't pass the bindings hurdle yet :-(. > But on the way there I noticed that 64-bit apr is broken and that's also the reason that 64-bit (when activated in the package Makefile with BUILD64=1) subversion didn't pass the tests. > See the attached patch for the needed changes. Excellent! I just bumped scons to 3.1.2 and pushed ot unstable/. > I needed a 64-bit subversion so I can work against a Linux NFS server with 64-bit directory cookies. In principle a 32-bit subversion can also do this, but in that case apr has to be compiled with -D_FILE_OFFSET_BITS=64. Unfortunately this would change the apr ABI and all depending packages have to be recompiled. The attached patch also includes (not activated) preparations for -D_FILE_OFFSET_BITS=64. I see. Recompiling APR would require recompiling some dependend packages, but not too many: https://www.opencsw.org/packages/CSWlibapr1-0/ > The other attached patches for libserf and scons were needed for me to build successfully on Solaris10 and 11, but maybe the reason is just that my build environment differs slightly from the official OpenCSW one. The move for catchall in libserf shouldn?t be necessary, apart from that the patches look good. Maybe I have not fully understood the issue, but wouldn?t a 64 bit subversion automatically include the 64 bit directory cookies as it automatically implies 64 bit data structures? And this should already be the case for 64 bit APR. The split header for 32 and 64 bit was not needed in the past IIRC. Besten Dank ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From Franz.Sirl-kernel at lauterbach.com Wed Sep 1 15:36:46 2021 From: Franz.Sirl-kernel at lauterbach.com (Franz Sirl) Date: Wed, 1 Sep 2021 15:36:46 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org> <4677fe55-8874-534c-6bc9-740d5b258226@lauterbach.com> Message-ID: <99c434c4-13a9-2967-c67d-04c868ef1979@lauterbach.com> Hi Dagobert, Am 2021-09-01 um 14:28 schrieb Dagobert Michelsen: > I see. Recompiling APR would require recompiling some dependend packages, > but not too many: > https://www.opencsw.org/packages/CSWlibapr1-0/ Well, that would be nice, too :-). I just wasn't sure if you can force an update of all dependent packages at the *user* sites within the OpenCSW framework. Meaning that it won't be good if for example a user mixes a new (_FILE_OFFSET_BITS=64) apr with an old subversion. So I thought enabling BUILD64=1 for subversion is the safer way to accomplish my goal. > Maybe I have not fully understood the issue, but wouldn?t a 64 bit subversion automatically > include the 64 bit directory cookies as it automatically implies 64 bit data structures? > And this should already be the case for 64 bit APR. The split header for 32 and 64 bit > was not needed in the past IIRC. The bug is exactly that the header is not split! I've attached a full diff between apr-32.h and apr-64.h as seen on Solaris11, but the most important difference is -#define APR_SIZEOF_VOIDP 4 +#define APR_SIZEOF_VOIDP 8 That's essentially why a 64-bit subversion compiled without a separate apr-64.h won't pass the tests and also doesn't work in practice as I've found out before I did the changes to apr. Gruesse, Franz -------------- next part -------------- --- /opt/csw/include/apr-32.h 2021-04-23 15:02:51.000000000 +0200 +++ /opt/csw/include/apr-64.h 2021-04-23 15:10:21.000000000 +0200 @@ -294,7 +294,7 @@ #define APR_HAS_UNICODE_FS 0 #define APR_HAS_PROC_INVOKED 0 #define APR_HAS_USER 1 -#define APR_HAS_LARGE_FILES 1 +#define APR_HAS_LARGE_FILES 0 #define APR_HAS_XTHREAD_FILES 0 #define APR_HAS_OS_UUID 1 #define APR_HAS_TIMEDLOCKS 1 @@ -333,7 +333,7 @@ typedef int apr_int32_t; typedef unsigned int apr_uint32_t; -#define APR_SIZEOF_VOIDP 4 +#define APR_SIZEOF_VOIDP 8 /* * Darwin 10's default compiler (gcc42) builds for both 64 and @@ -378,9 +378,9 @@ typedef size_t apr_size_t; typedef ssize_t apr_ssize_t; -typedef off64_t apr_off_t; +typedef off_t apr_off_t; typedef socklen_t apr_socklen_t; -typedef unsigned long apr_ino_t; +typedef ino_t apr_ino_t; #if APR_SIZEOF_VOIDP == 8 typedef apr_uint64_t apr_uintptr_t; @@ -555,10 +555,10 @@ #define APR_SIZE_T_FMT "lu" /* And APR_OFF_T_FMT */ -#define APR_OFF_T_FMT APR_INT64_T_FMT +#define APR_OFF_T_FMT "ld" /* And APR_PID_T_FMT */ -#define APR_PID_T_FMT "ld" +#define APR_PID_T_FMT "d" /* And APR_INT64_T_FMT */ #define APR_INT64_T_FMT PRId64 From Franz.Sirl-kernel at lauterbach.com Wed Sep 1 15:53:14 2021 From: Franz.Sirl-kernel at lauterbach.com (Franz Sirl) Date: Wed, 1 Sep 2021 15:53:14 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org> <4677fe55-8874-534c-6bc9-740d5b258226@lauterbach.com> Message-ID: <3ed5bfff-c736-215a-c4e4-b13be411c298@lauterbach.com> Am 2021-09-01 um 13:28 schrieb Jeffrey Walton via users: > On Wed, Sep 1, 2021 at 7:14 AM Franz Sirl via users > wrote: >> >> Am 2021-08-31 um 14:14 schrieb Dagobert Michelsen via users: >>> Am 30.08.2021 um 16:01 schrieb Dagobert Michelsen via users : >>>> Am 28.08.2021 um 21:57 schrieb Daniel Sahlberg via users : >>>>> Is there any chance to rebuild Subversion using the 1.14.1 version? >>>> >>>> I?m giving it a try! The build looks promising, current blocker is >>>> missind py3c which is needed for the svn python module. I?ll keep you >>>> posted. >>> >>> The version bump was pretty much straight forward. Please have a look at the package >>> in experimental and let me know how it goes so I can push it to unstable/ next: >>> http://buildfarm.opencsw.org/experimental.html#subversion >> ... >> >> The other attached patches for libserf and scons were needed for me to >> build successfully on Solaris10 and 11, but maybe the reason is just >> that my build environment differs slightly from the official OpenCSW one. > > Hi Franz, > > I noticed this in apr-nfs.patch: > > +# apr.h needs PATH_MAX from limits.h defined, otherwise it will #error. > +# So define __EXTENSIONS__ in build/apr_hints.m4 to make sure > +# it is propagated to all users via 'apr-1-config --cppflags'. > > Hurd does not define PATH_MAX , so it will lead to a compile problem > on the GNU's OS. I mention it in case you are interested in supporting > Hurd. > > Hurd and PATH_MAX break a lot of packages. Hi Jeffrey, I know next to nothing about Hurd, just a tiny bit via working with glibc sources. Is OpenCSW used with Hurd? In that case an alternative patch is needed for the Hurd case. But I guess apr doesn't work unchanged on Hurd anyway right now? regards, Franz Sirl From dsahlberg at apache.org Thu Sep 2 07:30:15 2021 From: dsahlberg at apache.org (Daniel Sahlberg) Date: Thu, 2 Sep 2021 07:30:15 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org> Message-ID: <6d12fab8-8be4-2d03-80ca-344cff4011ea@apache.org> On 2021-08-31 14:14, Dagobert Michelsen wrote: > Hi Daniel, > > Am 30.08.2021 um 16:01 schrieb Dagobert Michelsen via users : >> Am 28.08.2021 um 21:57 schrieb Daniel Sahlberg via users : >>> Is there any chance to rebuild Subversion using the 1.14.1 version? >> I?m giving it a try! The build looks promising, current blocker is >> missind py3c which is needed for the svn python module. I?ll keep you >> posted. > The version bump was pretty much straight forward. Please have a look at the package > in experimental and let me know how it goes so I can push it to unstable/ next: > http://buildfarm.opencsw.org/experimental.html#subversion Hi, Thank you so much for your effort! The build seems to work fine for the operations I checked manually. I have also executed the test suite in the subversion source archive. I have had some trouble building the tooling required (a few C programs in the test suite) but I can get most tests to complete and I deem that the failing tests are because of this missing tooling and not because of a problem in the package. There has been a discussion in the Subversion list regarding a decision to, by default, disable storing passwords in plaintext. OpenBSD decided to re-enable plaintext password storage (but having it disabled in the default config), primarily to better support servers with only commandline. Is there any chance you might consider to do the same? It is the following configure option: --enable-plaintext-password-storage And to add /opt/csw/etc/subversion/config: [[[ [auth] store-plaintext-passwords=no in /opt/csw/etc/subversion/config ]]] Kind regards Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Sep 2 10:19:31 2021 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 2 Sep 2021 10:19:31 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

Message-ID: <79CFDA98-815F-4CD9-B60A-8F83143718ED@opencsw.org> Hi Daniel, Am 02.09.2021 um 07:22 schrieb Daniel Sahlberg : > The build seems to work fine for the operations I checked manually. > > I have also executed the test suite in the subversion source archive. I have had some trouble building the tooling required (a few C programs in the test suite) but I can get most tests to complete and I deem that the failing tests are because of this missing tooling and not because of a problem in the package. > > There has been a discussion in the Subversion list regarding a decision to, by default, disable storing passwords in plaintext. OpenBSD decided to re-enable plaintext password storage (but having it disabled in the default config), primarily to better support servers with only commandline. Is there any chance you might consider to do the same? > > It is the following configure option: --enable-plaintext-password-storage > > And to add /opt/csw/etc/subversion/config: > [[[ > [auth] > store-plaintext-passwords=no > in /opt/csw/etc/subversion/config > ]]] Sure, I?ll add the configure option. IMHO this is fine because it sticks to previous behaviour. Currently /opt/csw/etc/subversion/config is not part of the package. Usually OpenCSW ships default configuration files but this is for historical reasons not the case for subversion so I would skip the example. My plan is to rebuild subversion now with the extra build option and release the version after some testing. After that I?ll give the updated APR and 64 bit subversion a try. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dsahlberg at apache.org Thu Sep 2 13:26:30 2021 From: dsahlberg at apache.org (Daniel Sahlberg) Date: Thu, 2 Sep 2021 13:26:30 +0200 Subject: Subversion 1.14.1 In-Reply-To: <79CFDA98-815F-4CD9-B60A-8F83143718ED@opencsw.org> References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

<79CFDA98-815F-4CD9-B60A-8F83143718ED@opencsw.org> Message-ID: <4eecb3e6-a6fa-01e9-eca2-a979f86bc8c3@apache.org> On 2021-09-02 10:19, Dagobert Michelsen wrote: > Hi Daniel, > > Am 02.09.2021 um 07:22 schrieb Daniel Sahlberg : >> The build seems to work fine for the operations I checked manually. >> >> I have also executed the test suite in the subversion source archive. I have had some trouble building the tooling required (a few C programs in the test suite) but I can get most tests to complete and I deem that the failing tests are because of this missing tooling and not because of a problem in the package. >> >> There has been a discussion in the Subversion list regarding a decision to, by default, disable storing passwords in plaintext. OpenBSD decided to re-enable plaintext password storage (but having it disabled in the default config), primarily to better support servers with only commandline. Is there any chance you might consider to do the same? >> >> It is the following configure option: --enable-plaintext-password-storage >> >> And to add /opt/csw/etc/subversion/config: >> [[[ >> [auth] >> store-plaintext-passwords=no >> in /opt/csw/etc/subversion/config >> ]]] > Sure, I?ll add the configure option. IMHO this is fine because it sticks to > previous behaviour. Currently /opt/csw/etc/subversion/config is not part > of the package. Usually OpenCSW ships default configuration files but this is for historical > reasons not the case for subversion so I would skip the example. > > My plan is to rebuild subversion now with the extra build option and release > the version after some testing. After that I?ll give the updated APR and > 64 bit subversion a try. Excellent! When you do, let me know what I can do to test. (I'm not so experienced on Solaris but I will do my best). Kind regards Daniel From dam at opencsw.org Thu Sep 2 22:00:45 2021 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 2 Sep 2021 22:00:45 +0200 Subject: Subversion 1.14.1 In-Reply-To: <4eecb3e6-a6fa-01e9-eca2-a979f86bc8c3@apache.org> References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

<79CFDA98-815F-4CD9-B60A-8F83143718ED@opencsw.org> <4eecb3e6-a6fa-01e9-eca2-a979f86bc8c3@apache.org> Message-ID: <41CC9167-86E8-4F10-8968-B415D7038227@opencsw.org> Hi Daniel, Am 02.09.2021 um 13:26 schrieb Daniel Sahlberg : > Excellent! When you do, let me know what I can do to test. (I'm not so experienced on Solaris but I will do my best). Updated packages with plaintext passwords enable should appear here soon with the date of today: http://buildfarm.opencsw.org/experimental.html#subversion Please let me know how it goes so I can push the packages to unstable/ if they are in good shape. I?ll try a 64 bit rebuild after that. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From Franz.Sirl-kernel at lauterbach.com Tue Sep 7 10:54:32 2021 From: Franz.Sirl-kernel at lauterbach.com (Franz Sirl) Date: Tue, 7 Sep 2021 10:54:32 +0200 Subject: Subversion 1.14.1 In-Reply-To: <41CC9167-86E8-4F10-8968-B415D7038227@opencsw.org> References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

<79CFDA98-815F-4CD9-B60A-8F83143718ED@opencsw.org> <4eecb3e6-a6fa-01e9-eca2-a979f86bc8c3@apache.org> <41CC9167-86E8-4F10-8968-B415D7038227@opencsw.org> Message-ID: <70e89899-3813-65d3-a673-52ea926ead12@lauterbach.com> Am 2021-09-02 um 22:00 schrieb Dagobert Michelsen via users: > Hi Daniel, > > Am 02.09.2021 um 13:26 schrieb Daniel Sahlberg : >> Excellent! When you do, let me know what I can do to test. (I'm not so experienced on Solaris but I will do my best). > > Updated packages with plaintext passwords enable should appear here soon > with the date of today: > http://buildfarm.opencsw.org/experimental.html#subversion > Please let me know how it goes so I can push the packages to unstable/ if > they are in good shape. > > I?ll try a 64 bit rebuild after that. Hi Dagobert, FWIW, here my current patch for subversion that builds/tests/packages fine on Solaris11. On Solaris10 it builds and tests fine, but fails during packaging: cd subversion/bindings/swig/perl/libsvn_swig_perl && /opt/csw/bin/bash "/home/fsirl/opencsw/subversion/trunk/work/build-isa-sparcv9-python_version-2.7/subversion-1.14.1/libtool" --tag=CC --silent --mode=link /opt/developerstudio12.6/bin/cc -xO3 -m64 -xarch=sparc -xO3 -m64 -xarch=sparc -m64 -xarch=sparc -L/opt/csw/bdb48/lib/64 -L/opt/csw/lib/64/64 -L/opt/csw/lib/64 -lintl -liconv -L/opt/csw/bdb48/lib/64 -L/opt/csw/lib -L/opt/csw/lib -L/opt/csw/lib -rpath /opt/csw/lib/64 -version-info 0 -o libsvn_swig_perl-1.la swigutil_pl.lo ../../../../../subversion/libsvn_delta/libsvn_delta-1.la ../../../../../subversion/libsvn_subr/libsvn_subr-1.la -L/opt/csw/lib/64 -laprutil-1 -L/opt/csw/lib/64 -lapr-1 -lsocket ld: fatal: file .libs/swigutil_pl.o: wrong ELF class: ELFCLASS32 ld: fatal: file processing errors. No output written to .libs/libsvn_swig_perl-1.so.0.0.0 gmake: *** [build-outputs.mk:536: subversion/bindings/swig/perl/libsvn_swig_perl/libsvn_swig_perl-1.la] Error 2 gmake: Leaving directory '/home/fsirl/opencsw/subversion/trunk/work/build-isa-sparcv9-python_version-2.7/subversion-1.14.1' gmake[1]: *** [Makefile:720: svn-perl] Error 2 gmake[1]: Leaving directory '/home/fsirl/opencsw/subversion/trunk' gmake: *** [gar/gar.mk:202: merge-isa-sparcv9-python_version-2.7] Error 2 No idea yet on how to fix that and what is the deciding difference to Solaris 11 here. Anyway, never came this far before, your py3c addition helped a lot. Thanks for that! Franz. -------------- next part -------------- Index: subversion/trunk/Makefile =================================================================== --- subversion/trunk/Makefile (revision 26780) +++ subversion/trunk/Makefile (working copy) @@ -23,6 +23,8 @@ VERSION = 1.14.1 GARTYPE = v2 +BUILD64 = 1 + DESCRIPTION = Version control rethought define BLURB The goal of the Subversion project is to build a version control system @@ -63,7 +65,17 @@ BUILD_DEP_PKGS += CSWlibexpat-dev BUILD_DEP_PKGS += CSWlibsqlite3-dev +BUILD_DEP_PKGS += CSWliblz4-dev +BUILD_DEP_PKGS += CSWlibutf8proc-dev +BUILD_DEP_PKGS += CSWlibiconv-dev +BUILD_DEP_PKGS += CSWsasl-dev +BUILD_DEP_PKGS += CSWlibapr-dev +BUILD_DEP_PKGS += CSWlibaprutil-dev +BUILD_DEP_PKGS += CSWapache24-dev +BUILD_DEP_PKGS += CSWlibsecret-dev BUILD_DEP_PKGS-5.10 += CSWlibserf-dev +BUILD_DEP_PKGS-5.11 += CSWlibserf-dev +BUILD_DEP_PKGS-5.10 += CSWjdk8 BUILD_DEP_PKGS += $(BUILD_DEP_PKGS-$(GAROSREL)) PACKAGES += CSWsubversion @@ -545,6 +557,7 @@ GARCOMPILER-5.9 = SOS12 # We need __restrict for javahl GARCOMPILER-5.10 = SOS12U6 +GARCOMPILER-5.11 = SOS12U6 GARCOMPILER += $(GARCOMPILER-$(GAROSREL)) # There are lots of failing tests, needs more work @@ -583,6 +596,12 @@ CONFIGURE_ARGS += $(CONFIGURE_ARGS-$(GAROSREL)-$(MEMORYMODEL)) +EXTRA_CONFIGURE_ENV-32 = +EXTRA_CONFIGURE_ENV-64 = PKG_CONFIG_PATH=/usr/lib/64/pkgconfig + +EXTRA_CONFIGURE_ENV = $(EXTRA_CONFIGURE_ENV-$(MEMORYMODEL)) +EXTRA_CONFIGURE_ENV += CONFIG_SHELL=/opt/csw/bin/bash /opt/csw/bin/bash + # Version from PYTHON modulation # This is honoured in build/find_python.sh EXTRA_CONFIGURE_EXPORTS += PYTHON From dam at opencsw.org Wed Sep 8 12:50:31 2021 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 8 Sep 2021 12:50:31 +0200 Subject: Subversion 1.14.1 In-Reply-To: <70e89899-3813-65d3-a673-52ea926ead12@lauterbach.com> References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

<79CFDA98-815F-4CD9-B60A-8F83143718ED@opencsw.org> <4eecb3e6-a6fa-01e9-eca2-a979f86bc8c3@apache.org> <41CC9167-86E8-4F10-8968-B415D7038227@opencsw.org> <70e89899-3813-65d3-a673-52ea926ead12@lauterbach.com> Message-ID: <968CD3F5-768E-4CE9-A00C-547861ACC7DD@opencsw.org> Hi Franz, Am 07.09.2021 um 10:54 schrieb Franz Sirl : > FWIW, here my current patch for subversion that builds/tests/packages fine on Solaris11. On Solaris10 it builds and tests fine, but fails during packaging: > > cd subversion/bindings/swig/perl/libsvn_swig_perl && /opt/csw/bin/bash "/home/fsirl/opencsw/subversion/trunk/work/build-isa-sparcv9-python_version-2.7/subversion-1.14.1/libtool" --tag=CC --silent --mode=link /opt/developerstudio12.6/bin/cc -xO3 -m64 -xarch=sparc -xO3 -m64 -xarch=sparc -m64 -xarch=sparc -L/opt/csw/bdb48/lib/64 -L/opt/csw/lib/64/64 -L/opt/csw/lib/64 -lintl -liconv -L/opt/csw/bdb48/lib/64 -L/opt/csw/lib -L/opt/csw/lib -L/opt/csw/lib -rpath /opt/csw/lib/64 -version-info 0 -o libsvn_swig_perl-1.la swigutil_pl.lo ../../../../../subversion/libsvn_delta/libsvn_delta-1.la ../../../../../subversion/libsvn_subr/libsvn_subr-1.la -L/opt/csw/lib/64 -laprutil-1 -L/opt/csw/lib/64 -lapr-1 -lsocket > ld: fatal: file .libs/swigutil_pl.o: wrong ELF class: ELFCLASS32 > ld: fatal: file processing errors. No output written to .libs/libsvn_swig_perl-1.so.0.0.0 This happens when something is available in 32 bit only: in this case the ffi-bindings. The 64 bit tests for x86 works fine, but in sparcv9 I get one failed test: START: ra-test TEST ASSERTION FAILED: child_exit_code == 0 PASS: ra-test 1: test svn_ra_get_location_segments PASS: ra-test 2: test ra_svn tunnel callback check svn_tests: E200006: Test crashed (run in debugger with '--allow-segfaults') FAIL: ra-test 3: test ra_svn tunnel creation callbacks FAIL: ra-test: Unknown test failure; see tests.log. END: ra-test ELAPSED: ra-test 0:00:09.533302 Is this an artefact of the non-split apr headers between 32 and 64 bit? I have committed my 64 bit changes in r26782. This looks like the last failing part before we can push out 64 bit. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From Franz.Sirl-kernel at lauterbach.com Wed Sep 8 18:35:57 2021 From: Franz.Sirl-kernel at lauterbach.com (Franz Sirl) Date: Wed, 8 Sep 2021 18:35:57 +0200 Subject: Subversion 1.14.1 In-Reply-To: <968CD3F5-768E-4CE9-A00C-547861ACC7DD@opencsw.org> References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

<79CFDA98-815F-4CD9-B60A-8F83143718ED@opencsw.org> <4eecb3e6-a6fa-01e9-eca2-a979f86bc8c3@apache.org> <41CC9167-86E8-4F10-8968-B415D7038227@opencsw.org> <70e89899-3813-65d3-a673-52ea926ead12@lauterbach.com> <968CD3F5-768E-4CE9-A00C-547861ACC7DD@opencsw.org> Message-ID: Hi Dagobert, Am 2021-09-08 um 12:50 schrieb Dagobert Michelsen via users: > Hi Franz, > > Am 07.09.2021 um 10:54 schrieb Franz Sirl : >> FWIW, here my current patch for subversion that builds/tests/packages fine on Solaris11. On Solaris10 it builds and tests fine, but fails during packaging: >> >> cd subversion/bindings/swig/perl/libsvn_swig_perl && /opt/csw/bin/bash "/home/fsirl/opencsw/subversion/trunk/work/build-isa-sparcv9-python_version-2.7/subversion-1.14.1/libtool" --tag=CC --silent --mode=link /opt/developerstudio12.6/bin/cc -xO3 -m64 -xarch=sparc -xO3 -m64 -xarch=sparc -m64 -xarch=sparc -L/opt/csw/bdb48/lib/64 -L/opt/csw/lib/64/64 -L/opt/csw/lib/64 -lintl -liconv -L/opt/csw/bdb48/lib/64 -L/opt/csw/lib -L/opt/csw/lib -L/opt/csw/lib -rpath /opt/csw/lib/64 -version-info 0 -o libsvn_swig_perl-1.la swigutil_pl.lo ../../../../../subversion/libsvn_delta/libsvn_delta-1.la ../../../../../subversion/libsvn_subr/libsvn_subr-1.la -L/opt/csw/lib/64 -laprutil-1 -L/opt/csw/lib/64 -lapr-1 -lsocket >> ld: fatal: file .libs/swigutil_pl.o: wrong ELF class: ELFCLASS32 >> ld: fatal: file processing errors. No output written to .libs/libsvn_swig_perl-1.so.0.0.0 > > This happens when something is available in 32 bit only: in this case the ffi-bindings. > > The 64 bit tests for x86 works fine, but in sparcv9 I get one failed test: > > START: ra-test > TEST ASSERTION FAILED: child_exit_code == 0 > PASS: ra-test 1: test svn_ra_get_location_segments > PASS: ra-test 2: test ra_svn tunnel callback check > svn_tests: E200006: Test crashed (run in debugger with '--allow-segfaults') > FAIL: ra-test 3: test ra_svn tunnel creation callbacks > FAIL: ra-test: Unknown test failure; see tests.log. > END: ra-test > ELAPSED: ra-test 0:00:09.533302 > > Is this an artefact of the non-split apr headers between 32 and 64 bit? After you installed the new apr, did you already rebuild and install aprutil and then libserf? If not, the apr fix did not take full effect yet. regards, Franz From dam at opencsw.org Thu Sep 9 10:53:39 2021 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 9 Sep 2021 10:53:39 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

Message-ID: Hi Dagobert, Am 2021-09-09 um 10:53 schrieb Dagobert Michelsen via users: > Hi Franz, > > Am 08.09.2021 um 18:35 schrieb Franz Sirl : >> After you installed the new apr, did you already rebuild and install aprutil and then libserf? If not, the apr fix did not take full effect yet. > > In fact I did not rebuild apr yet, I wanted to see subversion build and package in 64 bit first. > Now that this is done one more question: would adding the conditional include for apr-32/-64 > without the _FILE_OFFSET_BITS patch also require rebuildung? My impression is that this is > needed for all packages that do have 64 bit components as the header file for 64 bit changed > but not the header for the 32 bit build. without the _FILE_OFFSET_BITS patch only the 64-bit stuff depending on the fixed apr.h/apr-64.h needs rebuilding, the 32bit stuff is unaffected. But can the OpenCSW framework rebuild only the 64-bit dependencies? That's why I didn't include the _FILE_OFFSET_BITS patch by default. Without it all the working 32-bit applications and libraries remain backward and forward ABI compatible. The 64-bit applications and libraries depending on the old apr.h were potentially (certainly for subversion) broken anyway. Or, in other words, the _FILE_OFFSET_BITS patch is irrelevant for 64-bit, because there _FILE_OFFSET_BITS is already set to 64. Setting _FILE_OFFSET_BITS=64 on 32-bit would be nice for the functionality of 32-bit applications, but has the big drawback of changing the ABI (if you try the patch you will see a changed apr-32.h) of apr. And changing the ABI means you need a way to force users to update all their installed applications/libraries depending on apr if they try to update apr alone. regards, Franz From dam at opencsw.org Tue Sep 14 11:42:10 2021 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 14 Sep 2021 11:42:10 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

Message-ID: <88F21360-F90E-4BF6-838A-A8939D46C7CC@opencsw.org> Hi Franz, Am 09.09.2021 um 11:32 schrieb Franz Sirl : > without the _FILE_OFFSET_BITS patch only the 64-bit stuff depending on the fixed apr.h/apr-64.h needs rebuilding, the 32bit stuff is unaffected. But can the OpenCSW framework rebuild only the 64-bit dependencies? > > That's why I didn't include the _FILE_OFFSET_BITS patch by default. Without it all the working 32-bit applications and libraries remain backward and forward ABI compatible. > The 64-bit applications and libraries depending on the old apr.h were potentially (certainly for subversion) broken anyway. > > Or, in other words, the _FILE_OFFSET_BITS patch is irrelevant for 64-bit, because there _FILE_OFFSET_BITS is already set to 64. > Setting _FILE_OFFSET_BITS=64 on 32-bit would be nice for the functionality of 32-bit applications, but has the big drawback of changing the ABI (if you try the patch you will see a changed apr-32.h) of apr. And changing the ABI means you need a way to force users to update all their installed applications/libraries depending on apr if they try to update apr alone. I see. I rebuilt APR and all dependent packages with 64 bit components or who would require a version bump anyway at http://buildfarm.opencsw.org/experimental.html#subversion64 Subversion will show up soon. Please give it a try and let me know if everything works. It may be useful to make the binaries isaexec automatically to 64 bit. What do you think? Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From noloader at gmail.com Tue Sep 14 12:03:00 2021 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 14 Sep 2021 06:03:00 -0400 Subject: Subversion 1.14.1 In-Reply-To: <88F21360-F90E-4BF6-838A-A8939D46C7CC@opencsw.org> References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

<88F21360-F90E-4BF6-838A-A8939D46C7CC@opencsw.org> Message-ID: On Tue, Sep 14, 2021 at 5:44 AM Dagobert Michelsen via users wrote: > > ... > Subversion will show up soon. Please give it a try and let me know if > everything works. It may be useful to make the binaries isaexec automatically > to 64 bit. What do you think? Oracle recommends 64-bit when available. Also see https://docs.oracle.com/cd/E37838_01/html/E66175/features-1.html. For some reason, GNU software is still stuck in a 32-bit default. I think it is due to some Autotools decisions, but I have never dived into it. GNU is not exactly known for doing what the platform provider recommends. At times GNU will disregard what Apple, Microsoft or Oracle says to do. Jeff From dam at opencsw.org Wed Sep 15 12:05:35 2021 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 15 Sep 2021 12:05:35 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

<88F21360-F90E-4BF6-838A-A8939D46C7CC@opencsw.org> Message-ID: Hi Jeff, Am 14.09.2021 um 12:03 schrieb Jeffrey Walton via users : > On Tue, Sep 14, 2021 at 5:44 AM Dagobert Michelsen via users > wrote: >> >> ... >> Subversion will show up soon. Please give it a try and let me know if >> everything works. It may be useful to make the binaries isaexec automatically >> to 64 bit. What do you think? > > Oracle recommends 64-bit when available. Also see > https://docs.oracle.com/cd/E37838_01/html/E66175/features-1.html. > > For some reason, GNU software is still stuck in a 32-bit default. I > think it is due to some Autotools decisions, but I have never dived > into it. GNU is not exactly known for doing what the platform provider > recommends. At times GNU will disregard what Apple, Microsoft or > Oracle says to do. I repackages Subversion 1.14.1 with isaexec for all 64 bit binaries and again put them in experimental where they will show up soon: http://buildfarm.opencsw.org/experimental.html#subversion64 Please give them a try and let me know how it goes. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From Franz.Sirl-kernel at lauterbach.com Wed Sep 15 15:07:41 2021 From: Franz.Sirl-kernel at lauterbach.com (Franz Sirl) Date: Wed, 15 Sep 2021 15:07:41 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

<88F21360-F90E-4BF6-838A-A8939D46C7CC@opencsw.org>

Message-ID: Hi Dagobert, Am 2021-09-15 um 12:05 schrieb Dagobert Michelsen via users: > Hi Jeff, > > Am 14.09.2021 um 12:03 schrieb Jeffrey Walton via users : >> On Tue, Sep 14, 2021 at 5:44 AM Dagobert Michelsen via users >> wrote: >>> >>> ... >>> Subversion will show up soon. Please give it a try and let me know if >>> everything works. It may be useful to make the binaries isaexec automatically >>> to 64 bit. What do you think? >> >> Oracle recommends 64-bit when available. Also see >> https://docs.oracle.com/cd/E37838_01/html/E66175/features-1.html. >> >> For some reason, GNU software is still stuck in a 32-bit default. I >> think it is due to some Autotools decisions, but I have never dived >> into it. GNU is not exactly known for doing what the platform provider >> recommends. At times GNU will disregard what Apple, Microsoft or >> Oracle says to do. > > I repackages Subversion 1.14.1 with isaexec for all 64 bit binaries and > again put them in experimental where they will show up soon: > http://buildfarm.opencsw.org/experimental.html#subversion64 > Please give them a try and let me know how it goes. subversion seems to work nicely, thanks! I got only one problem during install of py_subversion: --->>> => Installing CSWpy-subversion-1.14.1,REV=2021.09.15 (1/1) ... Processing package instance from py_subversion - Subversion Python Language Binding(sparc) 1.14.1,REV=2021.09.15 Please see /opt/csw/share/doc/py_subversion/license for license information. ## Processing package information. ## Processing system information. 2 package pathnames are already properly installed. ## Verifying package dependencies. ## Verifying disk space requirements. ## Checking for conflicts with packages already installed. ## Checking for setuid/setgid programs. Installing py_subversion - Subversion Python Language Binding as ## Installing part 1 of 1. /opt/csw/lib/libsvn_swig_py-1.so.0 /opt/csw/lib/libsvn_swig_py-1.so.0.0.0 /opt/csw/lib/python2.7/site-packages/libsvn/_client.so /opt/csw/lib/python2.7/site-packages/libsvn/_core.so /opt/csw/lib/python2.7/site-packages/libsvn/_delta.so /opt/csw/lib/python2.7/site-packages/libsvn/_diff.so /opt/csw/lib/python2.7/site-packages/libsvn/_fs.so /opt/csw/lib/python2.7/site-packages/libsvn/_ra.so /opt/csw/lib/python2.7/site-packages/libsvn/_repos.so /opt/csw/lib/python2.7/site-packages/libsvn/_wc.so /opt/csw/share/doc/py_subversion/license [ verifying class ] Installing class ... /opt/csw/lib/python2.7/site-packages/libsvn/__init__.py /opt/csw/lib/python2.7/site-packages/libsvn/client.py /opt/csw/lib/python2.7/site-packages/libsvn/core.py /opt/csw/lib/python2.7/site-packages/libsvn/delta.py /opt/csw/lib/python2.7/site-packages/libsvn/diff.py /opt/csw/lib/python2.7/site-packages/libsvn/fs.py /opt/csw/lib/python2.7/site-packages/libsvn/ra.py /opt/csw/lib/python2.7/site-packages/libsvn/repos.py /opt/csw/lib/python2.7/site-packages/libsvn/wc.py /opt/csw/lib/python2.7/site-packages/svn/__init__.py /opt/csw/lib/python2.7/site-packages/svn/client.py /opt/csw/lib/python2.7/site-packages/svn/core.py /opt/csw/lib/python2.7/site-packages/svn/delta.py /opt/csw/lib/python2.7/site-packages/svn/diff.py /opt/csw/lib/python2.7/site-packages/svn/fs.py /opt/csw/lib/python2.7/site-packages/svn/ra.py /opt/csw/lib/python2.7/site-packages/svn/repos.py /opt/csw/lib/python2.7/site-packages/svn/wc.py Compiling .py files to bytecode (2.6, if any). Compiling .py files to bytecode (2.7, if any). File "/opt/csw/lib/python2.7/site-packages/libsvn/client.py", line 146 def svn_client_version() -> "svn_version_t const *": ^ SyntaxError: invalid syntax File "/opt/csw/lib/python2.7/site-packages/libsvn/core.py", line 144 def apr_initialize() -> "apr_status_t": ^ SyntaxError: invalid syntax File "/opt/csw/lib/python2.7/site-packages/libsvn/delta.py", line 143 def svn_swig_py_make_editor(*args) -> "svn_delta_editor_t const **, void **": ^ SyntaxError: invalid syntax File "/opt/csw/lib/python2.7/site-packages/libsvn/diff.py", line 143 def svn_diff_version() -> "svn_version_t const *": ^ SyntaxError: invalid syntax File "/opt/csw/lib/python2.7/site-packages/libsvn/fs.py", line 144 def svn_fs_version() -> "svn_version_t const *": ^ SyntaxError: invalid syntax File "/opt/csw/lib/python2.7/site-packages/libsvn/ra.py", line 144 def svn_ra_version() -> "svn_version_t const *": ^ SyntaxError: invalid syntax File "/opt/csw/lib/python2.7/site-packages/libsvn/repos.py", line 145 def svn_swig_py_make_parse_fns3(*args) -> "svn_repos_parse_fns3_t const **, void **": ^ SyntaxError: invalid syntax File "/opt/csw/lib/python2.7/site-packages/libsvn/wc.py", line 145 def svn_wc_version() -> "svn_version_t const *": ^ SyntaxError: invalid syntax pkgadd: ERROR: class action script did not complete successfully Installation of failed. pkgadd failed with exit code: 1 ---<<< This happened on Solaris 10 and 11 for me. regards, Franz Sirl From Franz.Sirl-kernel at lauterbach.com Thu Sep 16 10:29:00 2021 From: Franz.Sirl-kernel at lauterbach.com (Franz Sirl) Date: Thu, 16 Sep 2021 10:29:00 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

<88F21360-F90E-4BF6-838A-A8939D46C7CC@opencsw.org>

Message-ID: Hi Dagobert, Am 2021-09-15 um 15:07 schrieb Franz Sirl via users: > Hi Dagobert, > > Am 2021-09-15 um 12:05 schrieb Dagobert Michelsen via users: >> Hi Jeff, >> >> Am 14.09.2021 um 12:03 schrieb Jeffrey Walton via users >> : >>> On Tue, Sep 14, 2021 at 5:44 AM Dagobert Michelsen via users >>> wrote: >>>> >>>> ... >>>> Subversion will show up soon. Please give it a try and let me know if >>>> everything works. It may be useful to make the binaries isaexec >>>> automatically >>>> to 64 bit. What do you think? >>> >>> Oracle recommends 64-bit when available. Also see >>> https://docs.oracle.com/cd/E37838_01/html/E66175/features-1.html. >>> >>> For some reason, GNU software is still stuck in a 32-bit default. I >>> think it is due to some Autotools decisions, but I have never dived >>> into it. GNU is not exactly known for doing what the platform provider >>> recommends. At times GNU will disregard what Apple, Microsoft or >>> Oracle says to do. >> >> I repackages Subversion 1.14.1 with isaexec for all 64 bit binaries and >> again put them in experimental where they will show up soon: >> ?? http://buildfarm.opencsw.org/experimental.html#subversion64 >> Please give them a try and let me know how it goes. > > subversion seems to work nicely, thanks! I have to take this partly back, first I updated only the subversion packages and everything was working with my older self-compiled libapr/libaprutil/libserf. Then I issued a pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/subversion64 -u to pull all your other changes and then a simple "svn ls https://svn..." wouldn't work anymore. I tracked it down to the libserf package, the one in experimental doesn't work for me, a freshly self-compiled one (mgar clean && mgar build && mgar package-svr4) works nicely though. Can you try to rebuild libaprutil (libserf depends on it) and libserf again? I'll happily re-check it here then. regards, Franz Sirl From dam at opencsw.org Fri Sep 17 10:32:12 2021 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 17 Sep 2021 10:32:12 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

<88F21360-F90E-4BF6-838A-A8939D46C7CC@opencsw.org>

Message-ID: Hi Franz, Am 16.09.2021 um 10:29 schrieb Franz Sirl : > I have to take this partly back, first I updated only the subversion packages and everything was working with my older self-compiled libapr/libaprutil/libserf. Then I issued a > > pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/subversion64 -u > > to pull all your other changes and then a simple "svn ls https://svn..." wouldn't work anymore. I tracked it down to the libserf package, the one in experimental doesn't work for me, a freshly self-compiled one (mgar clean && mgar build && mgar package-svr4) works nicely though. > Can you try to rebuild libaprutil (libserf depends on it) and libserf again? I'll happily re-check it here then. Good catch! I could reproduce the issue and repackaged aprutil and libserf and sparcv9 now and the listing now works: root at experimental10s [experimental10s]:/root > /opt/csw/bin/sparcv9/svn list https://svn.code.sf.net/p/gar/code/csw/mgar/pkg/libserf/trunk Makefile checksums files/ Would you mind giving the package set another try? Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From Franz.Sirl-kernel at lauterbach.com Fri Sep 17 12:02:54 2021 From: Franz.Sirl-kernel at lauterbach.com (Franz Sirl) Date: Fri, 17 Sep 2021 12:02:54 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

<88F21360-F90E-4BF6-838A-A8939D46C7CC@opencsw.org>

Message-ID: <1632232c-7698-4786-b492-e008d14c345c@lauterbach.com> Hi Dagobert, Am 2021-09-17 um 10:32 schrieb Dagobert Michelsen via users: > Hi Franz, > > Am 16.09.2021 um 10:29 schrieb Franz Sirl : >> I have to take this partly back, first I updated only the subversion packages and everything was working with my older self-compiled libapr/libaprutil/libserf. Then I issued a >> >> pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/subversion64 -u >> >> to pull all your other changes and then a simple "svn ls https://svn..." wouldn't work anymore. I tracked it down to the libserf package, the one in experimental doesn't work for me, a freshly self-compiled one (mgar clean && mgar build && mgar package-svr4) works nicely though. >> Can you try to rebuild libaprutil (libserf depends on it) and libserf again? I'll happily re-check it here then. > > Good catch! I could reproduce the issue and repackaged aprutil and libserf and > sparcv9 now and the listing now works: > > root at experimental10s [experimental10s]:/root > /opt/csw/bin/sparcv9/svn list https://svn.code.sf.net/p/gar/code/csw/mgar/pkg/libserf/trunk > Makefile > checksums > files/ > > Would you mind giving the package set another try? Yes, this set works fine here too! Thanks for your work on updating subversion in OpenCSW! Franz Sirl From dam at opencsw.org Sat Sep 18 15:15:59 2021 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 18 Sep 2021 15:15:59 +0200 Subject: Subversion 1.14.1 In-Reply-To: <1632232c-7698-4786-b492-e008d14c345c@lauterbach.com> References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <90BE61FF-0400-407E-A6D0-4E0BF92F9391@opencsw.org>

<88F21360-F90E-4BF6-838A-A8939D46C7CC@opencsw.org>

<1632232c-7698-4786-b492-e008d14c345c@lauterbach.com> Message-ID: Hi Franz, Am 17.09.2021 um 12:02 schrieb Franz Sirl : > Am 2021-09-17 um 10:32 schrieb Dagobert Michelsen via users: >> Hi Franz, >> Am 16.09.2021 um 10:29 schrieb Franz Sirl : >>> I have to take this partly back, first I updated only the subversion packages and everything was working with my older self-compiled libapr/libaprutil/libserf. Then I issued a >>> >>> pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/subversion64 -u >>> >>> to pull all your other changes and then a simple "svn ls https://svn..." wouldn't work anymore. I tracked it down to the libserf package, the one in experimental doesn't work for me, a freshly self-compiled one (mgar clean && mgar build && mgar package-svr4) works nicely though. >>> Can you try to rebuild libaprutil (libserf depends on it) and libserf again? I'll happily re-check it here then. >> Good catch! I could reproduce the issue and repackaged aprutil and libserf and >> sparcv9 now and the listing now works: >> root at experimental10s [experimental10s]:/root > /opt/csw/bin/sparcv9/svn list https://svn.code.sf.net/p/gar/code/csw/mgar/pkg/libserf/trunk >> Makefile >> checksums >> files/ >> Would you mind giving the package set another try? > > Yes, this set works fine here too! I have now fixed the issue with compilation of py_subversion with Python 2.7. Support 2.7 has officially been discontinued and only 1.10 will stay clean, but for the time being undoing annotations seems to be enough to get it to compile. Updating swig with Python 3.3 seems to be more work than I am capable of spending at the moment. Would you mind giving it one last try of everything that you can test before I push it to unstable? Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From Franz.Sirl-kernel at lauterbach.com Mon Sep 20 18:10:27 2021 From: Franz.Sirl-kernel at lauterbach.com (Franz Sirl) Date: Mon, 20 Sep 2021 18:10:27 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <79CFDA98-815F-4CD9-B60A-8F83143718ED@opencsw.org> <4eecb3e6-a6fa-01e9-eca2-a979f86bc8c3@apache.org> <41CC9167-86E8-4F10-8968-B415D7038227@opencsw.org> <70e89899-3813-65d3-a673-52ea926ead12@lauterbach.com> <968CD3F5-768E-4CE9-A00C-547861ACC7DD@opencsw.org>

<88F21360-F90E-4BF6-838A-A8939D46C7CC@opencsw.org>

<1632232c-7698-4786-b492-e008d14c345c@lauterbach.com> Message-ID: Hi Dagobert, Am 2021-09-18 um 15:15 schrieb Dagobert Michelsen: > Hi Franz, > > Am 17.09.2021 um 12:02 schrieb Franz Sirl : >> Am 2021-09-17 um 10:32 schrieb Dagobert Michelsen via users: >>> Hi Franz, >>> Am 16.09.2021 um 10:29 schrieb Franz Sirl : >>>> I have to take this partly back, first I updated only the subversion packages and everything was working with my older self-compiled libapr/libaprutil/libserf. Then I issued a >>>> >>>> pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/subversion64 -u >>>> >>>> to pull all your other changes and then a simple "svn ls https://svn..." wouldn't work anymore. I tracked it down to the libserf package, the one in experimental doesn't work for me, a freshly self-compiled one (mgar clean && mgar build && mgar package-svr4) works nicely though. >>>> Can you try to rebuild libaprutil (libserf depends on it) and libserf again? I'll happily re-check it here then. >>> Good catch! I could reproduce the issue and repackaged aprutil and libserf and >>> sparcv9 now and the listing now works: >>> root at experimental10s [experimental10s]:/root > /opt/csw/bin/sparcv9/svn list https://svn.code.sf.net/p/gar/code/csw/mgar/pkg/libserf/trunk >>> Makefile >>> checksums >>> files/ >>> Would you mind giving the package set another try? >> >> Yes, this set works fine here too! > > I have now fixed the issue with compilation of py_subversion with Python 2.7. > Support 2.7 has officially been discontinued and only 1.10 will stay clean, > but for the time being undoing annotations seems to be enough to get it to > compile. Updating swig with Python 3.3 seems to be more work than I am > capable of spending at the moment. > > Would you mind giving it one last try of everything that you can test before > I push it to unstable? no problems during install or use with these packages, working like a charm here. regards, Franz Sirl From dam at opencsw.org Mon Sep 20 21:12:02 2021 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 20 Sep 2021 21:12:02 +0200 Subject: Subversion 1.14.1 In-Reply-To: References: <53f8ab58-0024-ecb1-325c-a38d5f0ed3b6@apache.org> <79CFDA98-815F-4CD9-B60A-8F83143718ED@opencsw.org> <4eecb3e6-a6fa-01e9-eca2-a979f86bc8c3@apache.org> <41CC9167-86E8-4F10-8968-B415D7038227@opencsw.org> <70e89899-3813-65d3-a673-52ea926ead12@lauterbach.com> <968CD3F5-768E-4CE9-A00C-547861ACC7DD@opencsw.org>

<88F21360-F90E-4BF6-838A-A8939D46C7CC@opencsw.org>

<1632232c-7698-4786-b492-e008d14c345c@lauterbach.com>

Message-ID: <3A1504C5-EAC5-4930-89C0-2F3AA36B52F8@opencsw.org> Hi Franz, Am 20.09.2021 um 18:10 schrieb Franz Sirl : >> I have now fixed the issue with compilation of py_subversion with Python 2.7. >> Support 2.7 has officially been discontinued and only 1.10 will stay clean, >> but for the time being undoing annotations seems to be enough to get it to >> compile. Updating swig with Python 3.3 seems to be more work than I am >> capable of spending at the moment. >> Would you mind giving it one last try of everything that you can test before >> I push it to unstable? > > no problems during install or use with these packages, working like a charm here. Excellent, I have now pushed all the packages from experimental/subversion64 to unstable/. Thanks a lot for the detailed prework! ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896