The page at https://git-annex.branchable.com/install/Linux_standalone/ has a link to the tarball for the standalone git-annex for the most recent version. Is it possible to make a page with link to stand-alone builds for specific git-annex versions? This is for creating a conda-forge recipe, which requires a pointer to a stable URL for a given version.
The git-annex repository https://downloads.kitenet.net/.git/ keeps track of all the old versions, which get moved to archive.org eventually to free up space on my server. So it would be possible to build such a page from the information in that repository. Or just look up the archive.org url for the version of the file that you want using git annex whereis.
git-annex-whereisdoes not seem to report a URL... how do I find it?Reason for needing a stable per-version URL is that conda recipes require one.
That file had not been uploaded to archive.org, so there was no archive.org url available for it.
What I'll do is automate the upload to archive.org after each release, so the tarballs should usually be available from there, barring some breakage.
Ok -- until this gets automated, could you manually push the 8.20200309 standalone tarball to archive.org? (My setup now relies on the standalone conda build, and this would let me get the recent bug fixes.) Thanks a lot!
@joey, when you get a chance, could you add the standalone distribution for the current released version (8.20200720.1, not the bleeding-edge git) to the archive at downloads.kitenet.net?
Would it be practical to document the process for creating a standalone distro, so that it can be built on conda-forge simultaneously with the corresponding non-standalone version?
Thanks!
The build process is "make linuxstandalone" or "make osxapp"
The builds will be updated with today's release.
Building the standalone distribution on conda-forge doesn't seem possible, unfortunately, since the build environment there is CentOS not Debian.
@joey, when you get a chance, could you update the https://downloads.kitenet.net/git-annex/linux/current/ and http://archive.org/download/git-annex-builds version to 8.20200908 ? Current version there is 8.20200815 , which is not an official release. Thanks!
It's copied there as part of the release process, and git-annex says it's there already.
Hmm, I'm not seeing an archive.org URL:
Hmm, I'm not seeing an archive.org URL:
Two other current standalone builds do exist in archive.org, but not
git-annex-standalone-amd64.tar.gz:That's strange, the repo's git-annex branch was somehow behind, but its info/refs had the branch up-to-date with the information. I don't know how that can happen as git update-server-info updates the latter based on the former, but git-annex sync in the repo does look to have fixed the problem.
git-annex-standalone-amd64.tar.gzis 8.20210224-gf951847c6 . Would it be difficult to adjust the release process so that the standalone version corresponding to the current hackage version gets uploaded to archive.org?git-annex-standalone-arm64.tar.gzandgit-annex-standalone-armel.tar.gzgot (auto-)uploaded to the web, butgit-annex-standalone-amd64.tar.gzdid not.I checked in a fresh clone of the repository, and it shows it was uploaded to archive.org. It reached it soon after it was added to the repository:
git-annex-standalone-amd64.tar.gz -> ../../../.git/annex/objects/KM/Ff/SHA256E-s51276461--a1cef631ef2cc0c977580eacaa1294d7617727df99214920ca6e8f3172bae03e.tar.gz/SHA256E-s51276461--a1cef631ef2cc0c977580eacaa1294d7617727df99214920ca6e8f3172bae03e.tar.gz) prints8.20210622-g0e7906e80, while the current standard version is8.20210630. If the versions could be synced up, it would simplify things for the conda package. Thanks!It would take a significant amount of extra work, on an ongoing basis, for the version output by the standalone build to match the version used for the release. I would need to, after making a release, go build git-annex against that tag, on multiple OS's. It is much easier to simply have an autobuilder that builds current master, and when I make a release, ship the most recent build.
It's also some ongoing amount of work to respond to repeated questions about it, when people notice that the version strings don't perfectly match up, but I guess I've answered your questions about it now and you won't be contributing to that workload further. Right?
(The third way I could reduce the workload, which does seem more appealing for some reason right now, would be to stop offering release builds.)