Opened 7 years ago

Last modified 7 years ago

#55934 new enhancement

Mirror SourceForge svn repositories

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: admin@…
Priority: Normal Milestone:
Component: server/hosting Version:
Keywords: Cc:
Port:

Description (last modified by ryandesign (Ryan Carsten Schmidt))

SourceForge's uptime has been bad for the past two weeks. They moved to a new data center, and have experienced downtime and DDoS attacks since then. See https://twitter.com/sfnet_ops. For ports that fetch directly from a code repository hosted on SourceForge, such as netpbm, this means the port can't be installed, for users who for whatever reason don't receive a binary archive. See #55930, #55853, #54918.

There have also been many reports of fetch failures that were the result of restrictive user network configurations. We used to fetch from svn using the svn protocol, but some networks blocked that port number. See #41023. We tried using http, until we found that some proxies interfered with that, since svn uses WebDAV's additional HTTP verbs that some proxies are unfamiliar with. See #28590. We switched to https, but recently SourceForge disabled support for older SSL protocols, making fetches fail using the version of svn included on OS X El Capitan and earlier. See #55933.

When SourceForge comes back online, I propose that MacPorts provide mirrors of the SourceForge svn repositories we use. Currently that's the following 10 ports:

  • AtomicParsley-devel
  • PsyncX
  • cmuclmtk
  • codeblocks
  • cotvnc
  • despotify
  • flashdot
  • netpbm
  • pymol
  • spim

Such mirrors can be easily created using svnsync and kept up to date by rerunning svnsync periodically. Once a day is probably sufficient. They can be hosted on svn.macports.org, where we already host our own archived svn repo. Ports that fetch from svn can then either always use the MacPorts svn mirror, or it can just be available as something we can switch ports to if the original server goes offline.

I know other solutions to the vcs fetch problem have been proposed and are partially implemented, such as MacPorts automatically generating a tarball. See macports-base@vcs-fetch. But until such solutions are finished and available to users, mirroring the repos could be a quick simple solution.

There are also 4 ports fetching from git repositories hosted on SourceForge:

  • SSHKeychain
  • gcs-java
  • ttk
  • xchm

Offering mirrors of those is something we could discuss separately, though since git makes it easy to clone repos, there may already be mirrors of them on GitHub or elsewhere that we could use.

Change History (3)

comment:1 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)

comment:2 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Another option would be to use git-svn to mirror the svn repositories to git. If we mirrored them to GitHub, then we would get GitHub's ability to automatically generate tarballs. Someone may have already set up such a mirror for some of these projects. For example, I found this one for netpbm, which I will investigate using in the netpbm port:

https://github.com/chneukirchen/netpbm-mirror/tree/advanced

comment:3 Changed 7 years ago by raimue (Rainer Müller)

I prefer the generic solution for all VCS to generate tarballs that can be mirrored like any other distfile. As you noted, this is already implemented for git on the vcs-fetch branch, but there was no point to continue working on this without distfile mirroring. Before we invest time to set up mirrors of third-party Subversion repositories, we should rather fix our distfile mirroring and continue what we started.

Note: See TracTickets for help on using tickets.