Re: svn binary packages for macOS
On Sun, Oct 3, 2021 at 7:17 PM Sean McBride wrote: > On Sun, 3 Oct 2021 09:07:04 -0400, Mark Phippard said: > > >Homebrew and MacPorts are both listed. > > I saw that, but I thought they required Xcode... > > >Honestly once those projects > >supported SVN it kind of removed all of the incentive to publish a > >package. That is why we stopped providing one from CollabNet and > >removed our listing from that page. I would guess it had to do with > >why WanDisco stopped too. > > I see. Do you agree Wandisco's should be removed from the website listing at > this point? If they no longer intend to provide newer versions then yes I think it should be removed. I would prefer someone else do it though simply because I used to work for a competitor of WanDisco and would not want anyone there to think that was a motive. I tried to remove any CollabNet package from this page that we were no longer maintaining, such as when we stopped providing new binaries for OSX and Solaris. Mark
svn: E000040: Can't read directory "###" Too many levels of symbolic links
I have an automated SVN job which fails when it's run via CA Workload, but when I run it myself it always goes through. Can anyone tell me why this might be? The job does the following things: 1) svn update 2) Do some "git" commands to download a repository from another location (downloading from Bitbucket). 3) svn add --force . 4) svn status, which looks for something that was deleted from git and deletes it for svn 5) svn commit. The svn add command seems to fail whenever it runs via CA Workload by running into "too many levels of symbolic links" error: DOING: svn add A (bin) force-app/main/default/customMetadata/DL_IntegrationMapping.ethnicity.md-meta.xml svn: E40: Can't read directory '/#/svn/#//##/main/default/objects/#/validationRules': Too many levels of symbolic links Whenever I run this manually, whether I call the shell script or run the commands one at a time, I don't get this error.
Re: svn: E000040: Can't read directory "###" Too many levels of symbolic links
On Mon, Oct 4, 2021 at 10:04 AM Morin, Michael wrote: > svn: E40: Can't read directory > '/#/svn/#//##/main/default/objects/#/validationRules': > Too many levels of symbolic links > > Whenever I run this manually, whether I call the shell script or run the > commands one at a time, I don't get this error. Just a thought but given that this is being run via some background automation maybe you need to explicitly set the current working directory in your scripts before running any svn commands? The error itself is coming back to SVN from the OS. So Google "Too many levels of symbolic links" if you have not already and you may find some ideas. Mark
Re: svn: E000040: Can't read directory "###" Too many levels of symbolic links
Too many levels of symbolic links This error is generated by the Operating system. Inspect '/#/svn/#//##/main/default/objects/#/validationRules' This file/link is either directly or inderictly pointing to it self, so subversion can not use it. When you add the file manually, you probably use a different svn config that ignores "validationRules". Best regards,
Re: svn binary packages for macOS
Den mån 4 okt. 2021 kl 15:57 skrev Mark Phippard : > On Sun, Oct 3, 2021 at 7:17 PM Sean McBride > wrote: > > > On Sun, 3 Oct 2021 09:07:04 -0400, Mark Phippard said: > > > > >Homebrew and MacPorts are both listed. > > > > I saw that, but I thought they required Xcode... > > > > >Honestly once those projects > > >supported SVN it kind of removed all of the incentive to publish a > > >package. That is why we stopped providing one from CollabNet and > > >removed our listing from that page. I would guess it had to do with > > >why WanDisco stopped too. > > > > I see. Do you agree Wandisco's should be removed from the website > listing at this point? > > If they no longer intend to provide newer versions then yes I think it > should be removed. I would prefer someone else do it though simply > because I used to work for a competitor of WanDisco and would not want > anyone there to think that was a motive. I tried to remove any > CollabNet package from this page that we were no longer maintaining, > such as when we stopped providing new binaries for OSX and Solaris. I don't pretend to know anything about Macos, but WANdisco is providing Subversion 1.10.6 for Mac OS 10.9. Is that version of Mac OS supported by Fink/Homebrew/MacPorts? If not, then I think it is reasonable to keep the link - at least until 1.10 is EOL (or we find a client side security issue in 1.10, there was a CVE fix in 1.10.7 but only server side). By the way, the situation for Linux and Windows is just the same so we should make the same decision for all platforms. Checking further, CollabNet is providing packages for 1.12.2. That one is for sure EOL. I downloaded and installed Subversion Edge 5.2.4, which seems to contain Apache HTTP Server 2.4.39 and Subversion 1.8.19. It is not evident to me if CollabNet is providing any Subversion services in any other product. Cornerstone was last updated 2019-12-31 so it is based on either 1.13.0 or 1.10.6 if they used the lastest version on the time of release. As for VersionsApp it seems current and active and I can't see any reason not including it. If "only providing outdated versions" is a reason for de-listing then sadly both CollabNet and WANdisco should go (at least when 1.10 is EOL). I can edit the website but I'd appreciate if anyone else in PMC would give their opinion on policy. Kind regards Daniel Sahlberg
Re: svn binary packages for macOS
On Mon, 4 Oct 2021 17:23:56 +0200, Daniel Sahlberg said: >I don't pretend to know anything about Macos, but WANdisco is providing >Subversion 1.10.6 for Mac OS 10.9. Is that version of Mac OS supported by >Fink/Homebrew/MacPorts? If not, then I think it is reasonable to keep the >link - at least until 1.10 is EOL (or we find a client side security issue >in 1.10, there was a CVE fix in 1.10.7 but only server side). By the way, >the situation for Linux and Windows is just the same so we should make the >same decision for all platforms. That's a good point. The WANDisco builds are still useful for old macOS. I retract my suggestion to remove it. Perhaps just put a note that they are not current? >Cornerstone was last updated 2019-12-31 so it is based on either 1.13.0 or >1.10.6 if they used the lastest version on the time of release. I would still include it, unlike Versions.app it supports things like shelving. Sean
Re: svn binary packages for macOS
On Mon, Oct 4, 2021 at 11:24 AM Daniel Sahlberg wrote: > If "only providing outdated versions" is a reason for de-listing then sadly > both CollabNet and WANdisco should go (at least when 1.10 is EOL). I can edit > the website but I'd appreciate if anyone else in PMC would give their opinion > on policy. My recommendation is we discuss and create a policy, add it to the page and then we can enforce it. I would expect the policy would be related to providing our LTS version and the only question is whether we want to require the latest LTS version be made available or just that one of our still supported LTS versions is available. Perhaps the latter could be an exception if there is some OS that cannot support a newer LTS for some reason. Historically, we only allowed distributions of our command line binaries to be listed. TortoiseSVN was the first exception we made and that was after they added the command line binaries as part of their installer. But AFAIK, clients like Cornerstone and Versions are GUI clients. Other clients with a long and close relationship with SVN such as Subclipse and AnkhSVN have never been listed on this page for that reason. Thanks Mark
Re: svn binary packages for macOS
On Mon, Oct 4, 2021 at 11:44 AM Mark Phippard wrote: > > On Mon, Oct 4, 2021 at 11:24 AM Daniel Sahlberg > wrote: > > > If "only providing outdated versions" is a reason for de-listing then sadly > > both CollabNet and WANdisco should go (at least when 1.10 is EOL). I can > > edit the website but I'd appreciate if anyone else in PMC would give their > > opinion on policy. > > My recommendation is we discuss and create a policy, add it to the > page and then we can enforce it. I would expect the policy would be > related to providing our LTS version and the only question is whether > we want to require the latest LTS version be made available or just > that one of our still supported LTS versions is available. Perhaps the > latter could be an exception if there is some OS that cannot support a > newer LTS for some reason. Some websites have a link to "older releases" which are listed on a separate page. Instead of removing mention of binaries, we could move them to a separate page (called "older 3rd party binaries" rather than "older releases" since they're not our binaries). That page could have a prominent note about the disadvantages of running older unsupported releases, but leave the choice in the user's hands. Thoughts? Cheers, Nathan
Re: svn binary packages for macOS
On Oct 4, 2021, at 12:00 PM, Nathan Hartman wrote: > > On Mon, Oct 4, 2021 at 11:44 AM Mark Phippard wrote: >> >>> On Mon, Oct 4, 2021 at 11:24 AM Daniel Sahlberg >>> wrote: >>> >>> If "only providing outdated versions" is a reason for de-listing then sadly >>> both CollabNet and WANdisco should go (at least when 1.10 is EOL). I can >>> edit the website but I'd appreciate if anyone else in PMC would give their >>> opinion on policy. >> >> My recommendation is we discuss and create a policy, add it to the >> page and then we can enforce it. I would expect the policy would be >> related to providing our LTS version and the only question is whether >> we want to require the latest LTS version be made available or just >> that one of our still supported LTS versions is available. Perhaps the >> latter could be an exception if there is some OS that cannot support a >> newer LTS for some reason. > > Some websites have a link to "older releases" which are listed on a > separate page. Instead of removing mention of binaries, we could move > them to a separate page (called "older 3rd party binaries" rather than > "older releases" since they're not our binaries). That page could have > a prominent note about the disadvantages of running older unsupported > releases, but leave the choice in the user's hands. Thoughts? My suggestion would be that we start simple (for us) and say that we want anyone listed to provide the latest available LTS version in order to be listed. Then as we get requests to add packages back in we can discuss the exceptions and why we should allow them. One exception I think we should make would be Linux/BSD distros. Where we just are showing the commands to install the package for a distro I do not think we should bother getting involved with what version that distro is providing. That said ... if someone thinks we should just not list them if they only provide an old version then I am OK with that too. I think the policies should mainly apply to when we are linking to some external download page. Mark
Re: svn binary packages for macOS
On Sun, 3 Oct 2021 09:07:04 -0400, Mark Phippard said: >I personally use Homebrew. The SVN package is all precompiled so it is >easy to install. Myself and other SVN devs have even improved the >formula over the years. Mark, Not sure if this is veering off-topic for this list, but I've tried using brew to install svn and it gives me: -- $ brew install --build-bottle subversion Error: The following formulae cannot be installed from bottles and must be built from source. openjdk, gdbm, mpdecimal, ca-certificates, openssl@1.1, readline, sqlite, python@3.9, scons, pcre, autoconf@2.69, apr and utf8proc -- if I try just: $ brew install subversion it ends with: -- ==> Installing subversion dependency: openjdk ==> ./configure --disable-warnings-as-errors --with-boot-jdk-jvmargs=-Duser.home=/Users/builder/Library/Caches/Homebrew/java_cache --with-boot-jdk=/private/tmp/openjdk-20211004-15 ==> make images Last 15 lines from /Users/builder/Library/Logs/Homebrew/openjdk/02.make: watchos(1.0, API_TO_BE_DEPRECATED), ^ /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Security.framework/Headers/SecTrust.h:357:47: error: expected a version of the form 'major[.minor[.subminor]]' tvos(2.0, API_TO_BE_DEPRECATED)); ... (rest of output omitted) * All command lines available in /private/tmp/openjdk-20211004-15582-jeery1/jdk17u-jdk-17-ga/build/macosx-x86_64-server-release/make-support/failure-logs. === End of repeated output === No indication of failed target found. Hint: Try searching the build log for '] Error'. Hint: See doc/building.html#troubleshooting for assistance. make[1]: *** [main] Error 2 make: *** [images] Error 2 Do not report this issue to Homebrew/brew or Homebrew/core! These open issues may also help: openjdk: try to reproduce java.lang.UnsatisfiedLinkError https://github.com/Homebrew/homebrew-core/pull/84886 OpenJDK is somewhat broken on newer MacOS instances, console is flooded with errors when using JMeter, AdoptOpenJDK has no issues https://github.com/Homebrew/homebrew-core/issues/66953 -- this is on macOS 10.13.6. I guess I should add backstory: I'm currently using WANDisco's binaries, but the reason I'm looking to update is because of the Let's Encrypt certificate expiring the other day. I'm not totally sure, but I think the cURL and/or OpenSSL/LibreSSL that that svn is using is not dealing well with the expired cert. So I'm looking to try a newer build. Sean
Re: svn binary packages for macOS
On Mon, Oct 4, 2021 at 1:00 PM Sean McBride wrote: > > On Sun, 3 Oct 2021 09:07:04 -0400, Mark Phippard said: > > >I personally use Homebrew. The SVN package is all precompiled so it is > >easy to install. Myself and other SVN devs have even improved the > >formula over the years. > > Mark, > > Not sure if this is veering off-topic for this list, but I've tried using > brew to install svn and it gives me: > > -- > $ brew install --build-bottle subversion > > Error: The following formulae cannot be installed from bottles and must be > built from source. > openjdk, gdbm, mpdecimal, ca-certificates, openssl@1.1, readline, sqlite, > python@3.9, scons, pcre, autoconf@2.69, apr and utf8proc > -- > > if I try just: > > $ brew install subversion ^ that is the command to use. I am not sure why you are having that problem installing OpenJDK. Maybe you could try this first? $ brew install openjdk I will see if I have a Mac on an older version where I can try this. I am on Apple Silicon now so I am on version 11.6. One thing that is weird is that openjdk is a build dependency. It should not be required for installing the bottle. So it is like it is trying to build from source or something. When I examine the formula I see: ==> Dependencies Build: openjdk ✔, pkg-config ✔, python@3.9 ✔, scons ✔, swig ✔ Required: apr ✔, apr-util ✔, gettext ✔, lz4 ✔, openssl@1.1 ✔, utf8proc ✔ So if it is installing the bottle it should not even be trying to install openjdk. Mark
