Re: svn binary packages for macOS
Den tors 11 nov. 2021 kl 16:21 skrev Nathan Hartman : > > On Mon, Nov 8, 2021 at 1:42 PM Daniel Sahlberg > wrote: > > There has been some discussion but I don't think there was an actual > > decision taken. So I'm throwing in a suggestion to add the following > > text to packages.html (just below the regarding "larger collections of > > software", and before the Centos Linux header): > > > > A condition to be listed is to provide "reasonably new" versions. > >This should be interpreted as the latest patch release of any of the > >supported versions (at the time of writing: either of 1.10.6 or 1.14.1). > >The rule will be implemented with a fair amount of flexibility to > >allow time to release new packages, as well as any considerations > >regarding the release process. Please discuss at the >href="mailto:users@subversion.apache.org";>Subversion users mailing > >list. > > > > I believe it is reasonable to accept someone distributing only 1.10.6 > > since there may be acceptable reasons not to distribute 1.14.1 (for > > example dependencies that are not possible to build on a certain > > platform). > > > > I added the "considerations regarding the release process" as a way to > > ignore Linux distributions since they might ship what was current at > > the time of their release and backport any important security fixes. > > It could be included directly in the text itself. For example: > > A condition to be listed is to keep current with security fixes by >offering the latest supported patch release or by backporting >security patches. The rule will be implemented with a fair amount >of flexibility... Thanks for the feedback. I copied verbatim and committed as r1894956 Kind regards, Daniel
Re: svn binary packages for macOS
On Mon, Nov 8, 2021 at 1:42 PM Daniel Sahlberg wrote: > There has been some discussion but I don't think there was an actual > decision taken. So I'm throwing in a suggestion to add the following > text to packages.html (just below the regarding "larger collections of > software", and before the Centos Linux header): > > A condition to be listed is to provide "reasonably new" versions. >This should be interpreted as the latest patch release of any of the >supported versions (at the time of writing: either of 1.10.6 or 1.14.1). >The rule will be implemented with a fair amount of flexibility to >allow time to release new packages, as well as any considerations >regarding the release process. Please discuss at the href="mailto:users@subversion.apache.org";>Subversion users mailing >list. > > I believe it is reasonable to accept someone distributing only 1.10.6 > since there may be acceptable reasons not to distribute 1.14.1 (for > example dependencies that are not possible to build on a certain > platform). > > I added the "considerations regarding the release process" as a way to > ignore Linux distributions since they might ship what was current at > the time of their release and backport any important security fixes. It could be included directly in the text itself. For example: A condition to be listed is to keep current with security fixes by offering the latest supported patch release or by backporting security patches. The rule will be implemented with a fair amount of flexibility... Cheers, Nathan
Re: svn binary packages for macOS
On Nov 8, 2021, at 12:21, Daniel Sahlberg wrote: > > Den mån 8 nov. 2021 kl 16:57 skrev Ryan Schmidt: >> >> On Oct 16, 2021, at 07:18, Daniel Sahlberg wrote: >>> > WANdisco is providing Subversion 1.10.6 for Mac OS 10.9. Is that version > of Mac OS supported by Fink/Homebrew/MacPorts? I am a manager of MacPorts. MacPorts supports Mac OS X 10.4 and later and provides binaries for Mac OS X 10.6 and later. See: https://ports.macports.org/port/subversion (The link at https://subversion.apache.org/packages.html#osx should be updated to this.) My understanding is that Homebrew requires OS X 10.9 or later and recommends macOS 10.14 or later. >>> >>> Thank you Ryan for your effort in providing Subversion on OS X as far back >>> as 10.6 (and 10.4)! >>> >>> Since we don't explicitly list the supported versions on other OSes, I >>> hesitate to add it to MacPorts. That kind of information will grow stale in >>> time and I don't think we will be able to maintain it as projects move on >>> in what versions they support. (I'm open to other opinions though!) >> >> I didn't mean to suggest that you should add version information to the >> MacPorts listing. I meant to request that someone please change the URL that >> is hyperlinked to the word "MacPorts" on that page from the one that's >> currently there, which is outdated, to the new one which I provided above. > > My bad, sorry about the misunderstanding. I've committed the change as > r1894844. Is it better now? Yes! Thanks.
Re: svn binary packages for macOS
Den tors 21 okt. 2021 kl 18:03 skrev Nathan Hartman : > > On Mon, Oct 18, 2021 at 2:55 AM Daniel Sahlberg > wrote: > >> Would it make sense to give them a heads up before removing the links in > >> case they would like to release newer packages and remain on the list? > > > > > > Yes, if we have any contact channels (I'm not sure about sending to an > > anonymous info address) and as long as it doesn't violate ASF vendor > > neutrality. It is about caring for the ecosystem. Nathan, can you do this > > with the PMC chair hat? > > > Apologies for the delayed reply... > > I'm also not too sure about sending to an anonymous info address. If > someone knows who is the proper contact, I'll be happy to send a > message. > > Cheers, > Nathan There has been some discussion but I don't think there was an actual decision taken. So I'm throwing in a suggestion to add the following text to packages.html (just below the regarding "larger collections of software", and before the Centos Linux header): A condition to be listed is to provide "reasonably new" versions. This should be interpreted as the latest patch release of any of the supported versions (at the time of writing: either of 1.10.6 or 1.14.1). The rule will be implemented with a fair amount of flexibility to allow time to release new packages, as well as any considerations regarding the release process. Please discuss at the mailto:users@subversion.apache.org";>Subversion users mailing list. I believe it is reasonable to accept someone distributing only 1.10.6 since there may be acceptable reasons not to distribute 1.14.1 (for example dependencies that are not possible to build on a certain platform). I added the "considerations regarding the release process" as a way to ignore Linux distributions since they might ship what was current at the time of their release and backport any important security fixes. If it is ok to make the change, I suggest that we let it soak for a while before reviewing and reviewing and removing those not conformant. Kind regards, Daniel
Re: svn binary packages for macOS
Den mån 8 nov. 2021 kl 16:57 skrev Ryan Schmidt : > > On Oct 16, 2021, at 07:18, Daniel Sahlberg wrote: > > Den ons 6 okt. 2021 kl 00:46 skrev Ryan Schmidt: > >> On Oct 4, 2021, at 10:23, Daniel Sahlberg wrote: > >> > >>> WANdisco is providing Subversion 1.10.6 for Mac OS 10.9. Is that version > >>> of Mac OS supported by Fink/Homebrew/MacPorts? > >> > >> I am a manager of MacPorts. MacPorts supports Mac OS X 10.4 and later and > >> provides binaries for Mac OS X 10.6 and later. See: > >> > >> https://ports.macports.org/port/subversion > >> > >> (The link at https://subversion.apache.org/packages.html#osx should be > >> updated to this.) > >> > >> My understanding is that Homebrew requires OS X 10.9 or later and > >> recommends macOS 10.14 or later. > > > > Thank you Ryan for your effort in providing Subversion on OS X as far back > > as 10.6 (and 10.4)! > > > > Since we don't explicitly list the supported versions on other OSes, I > > hesitate to add it to MacPorts. That kind of information will grow stale in > > time and I don't think we will be able to maintain it as projects move on > > in what versions they support. (I'm open to other opinions though!) > > I didn't mean to suggest that you should add version information to the > MacPorts listing. I meant to request that someone please change the URL that > is hyperlinked to the word "MacPorts" on that page from the one that's > currently there, which is outdated, to the new one which I provided above. My bad, sorry about the misunderstanding. I've committed the change as r1894844. Is it better now? Kind regards Daniel
Re: svn binary packages for macOS
On Oct 16, 2021, at 07:18, Daniel Sahlberg wrote: > Den ons 6 okt. 2021 kl 00:46 skrev Ryan Schmidt: >> On Oct 4, 2021, at 10:23, Daniel Sahlberg wrote: >> >>> WANdisco is providing Subversion 1.10.6 for Mac OS 10.9. Is that version of >>> Mac OS supported by Fink/Homebrew/MacPorts? >> >> I am a manager of MacPorts. MacPorts supports Mac OS X 10.4 and later and >> provides binaries for Mac OS X 10.6 and later. See: >> >> https://ports.macports.org/port/subversion >> >> (The link at https://subversion.apache.org/packages.html#osx should be >> updated to this.) >> >> My understanding is that Homebrew requires OS X 10.9 or later and recommends >> macOS 10.14 or later. > > Thank you Ryan for your effort in providing Subversion on OS X as far back as > 10.6 (and 10.4)! > > Since we don't explicitly list the supported versions on other OSes, I > hesitate to add it to MacPorts. That kind of information will grow stale in > time and I don't think we will be able to maintain it as projects move on in > what versions they support. (I'm open to other opinions though!) I didn't mean to suggest that you should add version information to the MacPorts listing. I meant to request that someone please change the URL that is hyperlinked to the word "MacPorts" on that page from the one that's currently there, which is outdated, to the new one which I provided above.
Re: svn binary packages for macOS
On Mon, Oct 18, 2021 at 2:55 AM Daniel Sahlberg wrote: >> Would it make sense to give them a heads up before removing the links in >> case they would like to release newer packages and remain on the list? > > > Yes, if we have any contact channels (I'm not sure about sending to an > anonymous info address) and as long as it doesn't violate ASF vendor > neutrality. It is about caring for the ecosystem. Nathan, can you do this > with the PMC chair hat? Apologies for the delayed reply... I'm also not too sure about sending to an anonymous info address. If someone knows who is the proper contact, I'll be happy to send a message. Cheers, Nathan
Re: svn binary packages for macOS
Den mån 18 okt. 2021 kl 03:57 skrev Nathan Hartman : > On Sun, Oct 17, 2021 at 12:38 PM Mark Phippard wrote: > >> On Sun, Oct 17, 2021 at 11:01 AM Nathan Hartman >> wrote: >> > >> > On Sat, Oct 16, 2021 at 9:25 AM Mark Phippard >> wrote: >> > > >> > > In terms of the policy, I think it should be that our latest LTS >> > > release must be available. If they have other packages available that >> > > is fine but the latest LTS must be one of them. In terms of the types >> > > of exceptions I could envision, perhaps we will discover it is really >> > > difficult to package the latest LTS for certain older distros and so >> > > they need to provide an older version. I would be OK with an exception >> > > like this but I would prefer to have the packagers raise it to us. >> > > >> > > Mark >> > >> > >> > I'm not opposed to this, but it might be a little tricky for OS >> > distros that freeze package versions. Debian for example. I haven't >> > checked what the current stable (bullseye) has, but I'm still on the >> > oldstable (buster) which supplies 1.10.x. I'm running a recent trunk >> > build though, heh heh :-) >> > >> > I'm not proposing an exception (and I'm not a packager); rather I'm >> > suggesting to consider a package compliant as long as it was a >> > supported LTS release at the time of the packager's version freeze >> > and security issues continue to be patched. >> >> My feeling is that our policy should focus on the situation where we >> are linking to an external website where the user downloads some >> package from them. For the Linux/BSD distros, and even Homebrew and >> MacPorts on MacOS, we are just telling the user that these package >> managers offer Subversion and maybe we list the commands to run in >> order to install the package. I do not think we need to police the >> version as heavily in this case. Especially with the Linux distros >> since they selectively backport patches so their version never >> perfectly matches ours and the distro provides support for their >> packages. > > > +1 > +1 > That said, the only problematic links on our current page are the ones >> from CollabNet and WanDisco. I have not verified WanDisco I am just >> taking the word of the people in this thread. Given that both of these >> were vendors trying to sell support and requiring registration to even >> get the download, I think we should just remove all of those links. If >> either of them ask to be put back we can tell them the requirement is >> that they offer the latest LTS version. > > > Would it make sense to give them a heads up before removing the links in > case they would like to release newer packages and remain on the list? > Yes, if we have any contact channels (I'm not sure about sending to an anonymous info address) and as long as it doesn't violate ASF vendor neutrality. It is about caring for the ecosystem. Nathan, can you do this with the PMC chair hat? Kind regards, Daniel
Re: svn binary packages for macOS
On Sun, Oct 17, 2021 at 12:38 PM Mark Phippard wrote: > On Sun, Oct 17, 2021 at 11:01 AM Nathan Hartman > wrote: > > > > On Sat, Oct 16, 2021 at 9:25 AM Mark Phippard > wrote: > > > > > > In terms of the policy, I think it should be that our latest LTS > > > release must be available. If they have other packages available that > > > is fine but the latest LTS must be one of them. In terms of the types > > > of exceptions I could envision, perhaps we will discover it is really > > > difficult to package the latest LTS for certain older distros and so > > > they need to provide an older version. I would be OK with an exception > > > like this but I would prefer to have the packagers raise it to us. > > > > > > Mark > > > > > > I'm not opposed to this, but it might be a little tricky for OS > > distros that freeze package versions. Debian for example. I haven't > > checked what the current stable (bullseye) has, but I'm still on the > > oldstable (buster) which supplies 1.10.x. I'm running a recent trunk > > build though, heh heh :-) > > > > I'm not proposing an exception (and I'm not a packager); rather I'm > > suggesting to consider a package compliant as long as it was a > > supported LTS release at the time of the packager's version freeze > > and security issues continue to be patched. > > My feeling is that our policy should focus on the situation where we > are linking to an external website where the user downloads some > package from them. For the Linux/BSD distros, and even Homebrew and > MacPorts on MacOS, we are just telling the user that these package > managers offer Subversion and maybe we list the commands to run in > order to install the package. I do not think we need to police the > version as heavily in this case. Especially with the Linux distros > since they selectively backport patches so their version never > perfectly matches ours and the distro provides support for their > packages. +1 That said, the only problematic links on our current page are the ones > from CollabNet and WanDisco. I have not verified WanDisco I am just > taking the word of the people in this thread. Given that both of these > were vendors trying to sell support and requiring registration to even > get the download, I think we should just remove all of those links. If > either of them ask to be put back we can tell them the requirement is > that they offer the latest LTS version. Would it make sense to give them a heads up before removing the links in case they would like to release newer packages and remain on the list? Cheers, Nathan
Re: svn binary packages for macOS
On Sun, Oct 17, 2021 at 11:01 AM Nathan Hartman wrote: > > On Sat, Oct 16, 2021 at 9:25 AM Mark Phippard wrote: > > > > In terms of the policy, I think it should be that our latest LTS > > release must be available. If they have other packages available that > > is fine but the latest LTS must be one of them. In terms of the types > > of exceptions I could envision, perhaps we will discover it is really > > difficult to package the latest LTS for certain older distros and so > > they need to provide an older version. I would be OK with an exception > > like this but I would prefer to have the packagers raise it to us. > > > > Mark > > > I'm not opposed to this, but it might be a little tricky for OS > distros that freeze package versions. Debian for example. I haven't > checked what the current stable (bullseye) has, but I'm still on the > oldstable (buster) which supplies 1.10.x. I'm running a recent trunk > build though, heh heh :-) > > I'm not proposing an exception (and I'm not a packager); rather I'm > suggesting to consider a package compliant as long as it was a > supported LTS release at the time of the packager's version freeze > and security issues continue to be patched. My feeling is that our policy should focus on the situation where we are linking to an external website where the user downloads some package from them. For the Linux/BSD distros, and even Homebrew and MacPorts on MacOS, we are just telling the user that these package managers offer Subversion and maybe we list the commands to run in order to install the package. I do not think we need to police the version as heavily in this case. Especially with the Linux distros since they selectively backport patches so their version never perfectly matches ours and the distro provides support for their packages. That said, the only problematic links on our current page are the ones from CollabNet and WanDisco. I have not verified WanDisco I am just taking the word of the people in this thread. Given that both of these were vendors trying to sell support and requiring registration to even get the download, I think we should just remove all of those links. If either of them ask to be put back we can tell them the requirement is that they offer the latest LTS version. The other links on the page all generally look good already. Mark
Re: svn binary packages for macOS
On Sun, Oct 17, 2021 at 11:01 AM Nathan Hartman wrote: > > On Sat, Oct 16, 2021 at 9:25 AM Mark Phippard wrote: > > > > In terms of the policy, I think it should be that our latest LTS > > release must be available. If they have other packages available that > > is fine but the latest LTS must be one of them. In terms of the types > > of exceptions I could envision, perhaps we will discover it is really > > difficult to package the latest LTS for certain older distros and so > > they need to provide an older version. I would be OK with an exception > > like this but I would prefer to have the packagers raise it to us. > > > > Mark > > > I'm not opposed to this, but it might be a little tricky for OS > distros that freeze package versions. Debian for example. I haven't > checked what the current stable (bullseye) has, but I'm still on the > oldstable (buster) which supplies 1.10.x. I'm running a recent trunk > build though, heh heh :-) I can vouch for this in the Red Hat world. I used to publish ports of Subversion over at repoforge, but the various dependency updates got a bit out of hand for me to continue after Repoforge ended. And EPEL refuses to replace any RHEL published tools. Red Hat sometimes publishes updates as part of their "SCL" or software collections library, but those can be really finicky to work with. > I'm not proposing an exception (and I'm not a packager); rather I'm > suggesting to consider a package compliant as long as it was a > supported LTS release at the time of the packager's version freeze > and security issues continue to be patched. > > Thoughts? > > Nathan
Re: svn binary packages for macOS
On Sat, Oct 16, 2021 at 9:25 AM Mark Phippard wrote: > > In terms of the policy, I think it should be that our latest LTS > release must be available. If they have other packages available that > is fine but the latest LTS must be one of them. In terms of the types > of exceptions I could envision, perhaps we will discover it is really > difficult to package the latest LTS for certain older distros and so > they need to provide an older version. I would be OK with an exception > like this but I would prefer to have the packagers raise it to us. > > Mark I'm not opposed to this, but it might be a little tricky for OS distros that freeze package versions. Debian for example. I haven't checked what the current stable (bullseye) has, but I'm still on the oldstable (buster) which supplies 1.10.x. I'm running a recent trunk build though, heh heh :-) I'm not proposing an exception (and I'm not a packager); rather I'm suggesting to consider a package compliant as long as it was a supported LTS release at the time of the packager's version freeze and security issues continue to be patched. Thoughts? Nathan
Re: svn binary packages for macOS
On Sat, Oct 16, 2021 at 8:57 AM Daniel Sahlberg wrote: > I second Mark's suggestion that we should only list those providing recent > versions. Would this be a reasonable definition: "Any software listed should > provide the latest bugfix of any supported version", where "version" is 1.10, > 1.14 etc. > > I realise this would rule out both WANdisco and CollabNet immediately since > they don't provide the latest bugfix release. We could delay implementing the > policy until april next year (when 1.10 is out of support). > As long as we are in agreement about what we think the policy ought to be we should just go ahead and do it. I feel like it leads to 3 possibilities for any packagers that we remove from our page: 1. This motivates them to update their packages and get listed again. 2. This reveals that they are no longer going to provide new packages 3. They come back to us with some kind of valid reasons that we were not aware of and we adjust the policy I personally feel like all 3 of these outcomes are better for the Subversion project than the current status quo. In terms of the policy, I think it should be that our latest LTS release must be available. If they have other packages available that is fine but the latest LTS must be one of them. In terms of the types of exceptions I could envision, perhaps we will discover it is really difficult to package the latest LTS for certain older distros and so they need to provide an older version. I would be OK with an exception like this but I would prefer to have the packagers raise it to us. Mark
Re: svn binary packages for macOS
Den mån 4 okt. 2021 kl 18:26 skrev Mark Phippard : > 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. > Thanks Mark for your excellent background information. I second Mark's suggestion that we should only list those providing recent versions. Would this be a reasonable definition: "Any software listed should provide the latest bugfix of any supported version", where "version" is 1.10, 1.14 etc. I realise this would rule out both WANdisco and CollabNet immediately since they don't provide the latest bugfix release. We could delay implementing the policy until april next year (when 1.10 is out of support). Kind regards, Daniel Sahlberg
Re: svn binary packages for macOS
Den mån 4 okt. 2021 kl 17:44 skrev Mark Phippard : > 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. > Thank you for pointing this out. Reading the website carefully it actually says "Note also that this list does not include distributions of larger collections of software of which Subversion is but one piece.". Until we change this policy, I believe Cornerstone and Versions should not be listed. On the other hand, I think we could change the policy. I think that the more help we can give to our users (both in the sense of "end users" and "consumers of our API") the better for everyone. Of course, we should then list Subclipse and AnkhSVN as well. I'll come back with another suggestion of change in policy as a reply to a separate e-mail. Kind regards, Daniel Sahlberg
Re: svn binary packages for macOS
Den ons 6 okt. 2021 kl 00:46 skrev Ryan Schmidt < subversion-2...@ryandesign.com>: > On Oct 4, 2021, at 10:23, Daniel Sahlberg wrote: > > > WANdisco is providing Subversion 1.10.6 for Mac OS 10.9. Is that version > of Mac OS supported by Fink/Homebrew/MacPorts? > > I am a manager of MacPorts. MacPorts supports Mac OS X 10.4 and later and > provides binaries for Mac OS X 10.6 and later. See: > > https://ports.macports.org/port/subversion > > (The link at https://subversion.apache.org/packages.html#osx should be > updated to this.) > > My understanding is that Homebrew requires OS X 10.9 or later and > recommends macOS 10.14 or later. > Thank you Ryan for your effort in providing Subversion on OS X as far back as 10.6 (and 10.4)! Since we don't explicitly list the supported versions on other OSes, I hesitate to add it to MacPorts. That kind of information will grow stale in time and I don't think we will be able to maintain it as projects move on in what versions they support. (I'm open to other opinions though!) Kind regards, Daniel
Re: svn binary packages for macOS
On Tue, 5 Oct 2021 17:45:39 -0500, Ryan Schmidt said: >I am a manager of MacPorts. MacPorts supports Mac OS X 10.4 and later >and provides binaries for Mac OS X 10.6 and later. See: > >https://ports.macports.org/port/subversion Ryan, Thanks! That worked for me. It was able to install svn 1.14.1 on macOS 10.13.6. Even better, it fixed my root issue, which is that since the Sept 30 Let's Encrypt certificate expiration, the WANDisco 1.11.1 binaries (for whatever reason) fail to `svn up` but it now works with the MacPorts 1.14.1 installation. Cheers, Sean
Re: svn binary packages for macOS
On Oct 4, 2021, at 10:23, Daniel Sahlberg wrote: > WANdisco is providing Subversion 1.10.6 for Mac OS 10.9. Is that version of > Mac OS supported by Fink/Homebrew/MacPorts? I am a manager of MacPorts. MacPorts supports Mac OS X 10.4 and later and provides binaries for Mac OS X 10.6 and later. See: https://ports.macports.org/port/subversion (The link at https://subversion.apache.org/packages.html#osx should be updated to this.) My understanding is that Homebrew requires OS X 10.9 or later and recommends macOS 10.14 or later. On Oct 3, 2021, at 18:17, 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... MacPorts installation instructions say to install Xcode and the command line tools in order to avoid the circumstance that you might encounter an error message when something has to be compiled that requires those. If what you are compiling does not require Xcode but can make do with the command line tools (as most things can), then you only need to install the command line tools, not Xcode. And in the most common case that what you want to install has already been compiled by our build servers and is available as a binary download, then you need neither Xcode nor the command line tools. You're welcome to install MacPorts without installing Xcode or the command line tools and try to install a port. If it works, great, if not, the error message should indicate if Xcode is required. If it indicates that, install Xcode; if not, install the command line tools.
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
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 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 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 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, 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
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 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
Re: svn binary packages for macOS
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 you are doing software development on OSX >it is pretty rare to not eventually need to use Homebrew or MacPorts. >Once you do, then installing SVN is trivial. Most svn users at my office are not doing software development. >I personally use Homebrew. The SVN package is all precompiled so it is >easy to install. Ah, so I guess Xcode is not required. Will try... >Myself and other SVN devs have even improved the >formula over the years. For example, I have provided improvements over >the years so that the JavaHL library is included by default and I >helped to get the package fully working on the new Apple Silicon. Thanks for your work! Sean
Re: svn binary packages for macOS
On Sun, Oct 3, 2021 at 8:54 AM Sean McBride wrote: > Alas, that seems to mean there are no other binary distributions for macOS, > unless anyone knows of any? Homebrew and MacPorts are both listed. 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. If you are doing software development on OSX it is pretty rare to not eventually need to use Homebrew or MacPorts. Once you do, then installing SVN is trivial. 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. For example, I have provided improvements over the years so that the JavaHL library is included by default and I helped to get the package fully working on the new Apple Silicon. Mark
