The project home page for Git LFS was moved to https://git-lfs.com/
from https://git-lfs.github.com/ last year, so we now update our
Debian and RPM package metadata to refer to the new home page URL.
Since commit git-lfs/build-dockers@d4c2fe6f79
the centos_script.bsh script in that repository has not built the
"repository configuration" or "repo" RPM packages, which were intended,
it seems, to contain extra packages and GPG signatures for Git LFS.
We can therefore remove the stale RPM spec and source files which
pertained only to this extra RPM build, and also some lines in the
rpm/build_rpms.bsh which created an empty stub GPG key file for this
build.
In commit c2d25ee6b6d89425cf39dbc3be7a215d3d0fc050 of PR #511 we added
support for building RPM packages for 32-bit platforms by updating the
docker/centos_script.bsh script which was present at that time to
call rpmbuild with a --target=i686 argument.
Since commit 56ffe420b787ba2f738287e07d6af9f177e51b4f of PR #555 both
that script and the rpm/build_rpms.bsh script contained the same logic
to parse the OS name and version in order to set a short suffix for
the RPM filenames.
However, the docker/centos_script.bsh script was subsequently moved into
the git-lfs/build-dockers repository, where it has not been updated to
match the rpm/build_rpms.bsh script, such as when parsing of the OS major
version was added in commit e93940960ee0e1749a2de6616150cd10061b18e2 of
PR #5054, which allows us to properly parse the version number on
CentOS/Rocky Linux 8 and above, or when parsing of the Rocky Linux OS
name was added in commit 723be34bd0e9802c0dc5fa728edf86cc16bc62b0 of
PR #5144.
The result is that at present we build 32-bit RPMs for CentOS 8 and
Rocky Linux 9 (el8 and el9, respectively) without the platform short
name suffix in their filenames, e.g., git-lfs-3.3.0-1.i686.rpm and
git-lfs-3.3.0-1.i686.rpm, and then upload them to Packagecloud with
those names.
To resolve this problem and avoid later regressions between the two
sets of parsing logic, we move the rpmbuild command for 32-bit packages
into our rpm/build_rpms.bsh script, which ensures they will be built
with the same context as our 64-bit packages.
To do this we introduce an rpmbuild command with the --target=i686
argument into rpm/build_rpms.bsh, which allows us to also remove
the rpmbuild command from the centos_script.bsh script in the
git-lfs/build-dockers repository in PR git-lfs/build-dockers#54.
Since the original introduction of support for building CentOS RPMs
in commit 4a7162777913489e7c70a3da3235dcd3eeec553b of PR #332, an
rpm/clean.bsh script has been provided to perform the equivalent of
a "git clean -xdf" command on the Git repository from which we build
Git LFS.
However, this script is no longer needed as all of the CentOS and
Rocky Linux container image builds have a native Git package installed,
and so we remove the only use of it, in the centos_script.bsh script
of the git-lfs/build-dockers project, in commit
git-lfs/build-dockers@7be51a4ddd of
PR git-lfs/build-dockers#54, and can therefore also drop the
script from this repository as well.
In commit e2f770c8f5f2251976a83a5983c9ce170a764884 of PR #428
the rpm/build_rpms.bsh script was updated to run the rpmbuild command
with the --nodeps option when the NODEPS environment variable was defined
and set non-zero.
However, in commit 88430de792d96ec74846779aeb0530a4fb1ff49a of PR #654
the script was revised to always pass the --nodeps option to the
rpmbuild command, so the NODEPS environment variable no longer had
any effect, and so We can therefore remove our handling of this variable.
The SPEC variable is currently set with the relative path to our
git-lfs.spec file, but is then not used in places where it could be,
so we replace those with references to the variable.
We no longer support either CentOS 5 or 6, per commit
b560b853a6e557195c0c68875218f45c89dce56b of PR #1298 and commit
git-lfs/build-dockers@64a3a9fc4d
of PR git-lfs/build-dockers#3, and commit
git-lfs/build-dockers@898d9b045e
of PR git-lfs/build-dockers#33.
We also now build the Asciidoctor Ruby gem in order to generate
our man pages, rather than using ronn and several other gems,
per commit db9a82132a2bb066876d8ddf06c5255da2f199a4 of PR #5054.
We therefore update the documentation for our RPM package build
utilities and for our Docker container image build utilities to
reflect these changes.
In commit db9a82132a2bb066876d8ddf06c5255da2f199a4 of PR #5054 we
replaced our use of ronn with Asciidoctor, and as part of that change
we updated our rpm/build_rpms.bsh script to only install the
Asciidoctor Ruby gem instead of a set of four gems including one
for ronn.
As a consequence we no longer have any x86_64 Ruby gem RPMs but only
"noarch" ones, so we can simplify our installation slightly, and
also update our status messages to reflect that we are installing
just one gem.
Since the original introduction of the rpm/build_rpms.bsh script in
commit 4a7162777913489e7c70a3da3235dcd3eeec553b of PR #332 it has
installed a number of packages, including make, curl, tar, and bison.
Then in commit a4c9db890e19a6b70451db99b8db622e5af8997a of PR #480 the
perl-Digest-SHA package was added as an install target as well.
However, we no longer need to install any of these, either because the
are already installed by our CentOS and Rocky Linux Dockerfiles in
our git-lfs/build-dockers project, or because they are simply unused
at present, so we remove these packages now.
In commit git-lfs/build-dockers@544e07ee1a
of PR git-lfs/build-dockers#47 we updated our CentOS 7 Dockerfile to
install Ruby 3.0 using the rh-ruby30-{ruby,build} packages and then run
our CentOS build script with that version of Ruby as the default. We made
this change to support our use of Asciidoctor in preference to ronn,
which was completed in PR #5054, and as part of that PR, in commit
db9a82132a2bb066876d8ddf06c5255da2f199a4 we replaced our installation of
ronn with one of asciidoctor in our rpm/build_rpms.bsh script.
As a result, none of our CentOS or Rocky Linux container image builds
now rely on Ruby 2.x, so we can remove the code which installed that
version.
We can also remove the related code which used to install Ruby 2.x when
an even older version was the default, along with our local ruby.spec
file for Ruby 2.2.2.
Finally, we can remove the code which installed the rubygems-devel
package on CentOS 8 because that is taken care of by the corresponding
Dockerfile in our git-lfs/build-dockers project, which, like the
one for Rocky Linux 9, installs ruby, ruby-devel, and rubygems-devel.
Since the original introduction of the rpm/build_rpms.bsh script in
commit 4a7162777913489e7c70a3da3235dcd3eeec553b of PR #332 it has
checked for the absence of the "go" binary and, if it is not found,
installs the golang package, except on CentOS 5 where fetches and
patches a golang.spec file and then builds a local RPM using that
in order to install Go.
However, in commit b560b853a6e557195c0c68875218f45c89dce56b of PR #1298 and
in commit git-lfs/build-dockers@64a3a9fc4d of
PR git-lfs/build-dockers#3 we dropped support for CentOS 5.
And in commit 88430de792d96ec74846779aeb0530a4fb1ff49a of PR #654 we
updated our CentOS Dockerfiles (before they were moved to the
git-lfs/build-dockers repository) to download and install Go from the
googleapis.com service, and we still continue to do this but as of
commit git-lfs/build-dockers@c63850354e
in PR git-lfs/build-dockers#35 we now use the golang.org service.
This direct download obviates the logic in our rpm/build_rpms.bsh
script to install the golang package, and the special handling for
CentOS 5 is also obsolete, so we remove this logic from our script.
In commit cd3e92e947fcc9c43ddc932226c155731cd00978 of PR #480 we
introduced support for CentOS 6 into our rpm/build_rpms.bsh script by
building an early version of Git from a local git.spec file. Then in
commit d2d90a801a98cc9789e691e8c43251c51ce0b333 of PR #891 this was
replaced with installation from the setup.ius.io service.
In commit git-lfs/build-dockers@7af55520c6
of PR git-lfs/build-dockers#19, however, the download and installation
of Git 2.16 from github.com was added to the CentOS 6 Dockerfile; later
this was adjusted to download from kernel.org.
In commit git-lfs/build-dockers@f1f573fd5b
of PR git-lfs/build-dockers#29 we added support for CentOS 8, which
supports a direct installation of Git using yum.
And in commit git-lfs/build-dockers@898d9b045e
of PR git-lfs/build-dockers#33 we dropped support for CentOS 6 entirely.
Therefore we no longer have any need for our rpm/build_rpms.bsh script
to install Git at all, especially not very old versions, so we simply
remove that logic from our script.
In commit b560b853a6e557195c0c68875218f45c89dce56b of PR #1298 and in
commit git-lfs/build-dockers@64a3a9fc4d of
PR git-lfs/build-dockers#3 we dropped support for CentOS 5, so we can
remove the logic in our rpm/build_rpms.bsh which installed a RedHat
EPEL package only on this platform.
Our rpm/build_rpms.bsh script currently attempts to parse the
/etc/os-release file to retrieve the major OS version number, and
if that file does not exist, reads /etc/redhat-release instead;
the latter logic has been in place since the introduction of the
script in commit 4a7162777913489e7c70a3da3235dcd3eeec553b of
PR #332, and has been the fallback logic since commit
56ffe420b787ba2f738287e07d6af9f177e51b4f of PR #555.
However, /etc/os-release should exist on all the current versions
of CentOS and Rocky Linux we support, so we do not need to retain
the fallback parsing of /etc/redhat-release at this point.
We generally get a lot of requests for problems that are already
answered in the FAQ. Right now, this lives in the wiki, but this is
hard to find, so let's include it in the documentation with Git LFS
itself.
Add the relevant portions to the binary and Makefile so that it can be
accessed using `git lfs help faq`, and add it as well to the Linux
packages.
The version of RPM in Rocky Linux 9 no longer allows string comparisons
with barewords. Quote the arguments properly to make sure that the
comparison works on Rocky Linux 9.
For CentOS, we've traditionally included the el7 component, so let's
include the same component for Rocky 8. While we're at it, let's be
honest about what we're shipping and say Rocky Linux and not CentOS,
since CentOS 8 is dead.
The version ID set right now is a value like "8.5" on Rocky Linux 8. In
such a situation, it's hard to compare, and this prevents rubygems-devel
from being installed properly in such a situation. To make things work
properly, strip off the decimal point and decimal value from the end of
the string.
We currently build our manual pages and the HTML versions of
them into a single "man" directory, which results in release
package archives on GitHub that contain all of these files
interleaved with each other in that one directory.
When we build Linux RPM and Debian packages, though, the man
pages are installed into their conventional locations under
/usr/share/man/man{1,5}. (The HTML versions are not included
at all.)
For those downloading the release package archives and not using
the RPM or Debian packages, we can improve their experience by
placing the roff man pages into "man1" and "man5" subdirectories
corresponding to their respective sections of the manual, and the
HTML versions of the pages into an "html" subdirectory.
When we build packages, we always want them to include localization.
Let's make sure the gettext-devel package is installed and set the
FORCE_LOCALIZE variable to ensure that localization happens and that we
fail if it does not.
Debian has recently deprecated the which utility and will remove it in a
future version, since POSIX specifies "command -v" for finding the
location of a path and has for some time. In addition, which has
started complaining loudly to standard error, so it causes test and
makefile output to be hard to read.
Let's switch to the preferred invocation, command -v, in the Makefile,
build tooling, and test suite.
When building on any CentOS version, we end up building a lot of
additional items, and this is especially true of CentOS 6, where we must
build Ruby. These intermediate build products run us out of disk space
in CI, so let's remove the RPMs that we installed to build Ruby once
we're done with them.
When building on any CentOS version, we end up building a lot of
additional items, and this is especially true of CentOS 6, where we must
build Ruby. These intermediate build products run us out of disk space
in CI, so let's clean up the RPM build areas and recreate them before
building Git LFS itself.
We need to have different %setup invocations on CentOS 8 and older
CentOS versions. Originally, CentOS 7 was thought to behave like CentOS
8, but the fact that it behaves like CentOS 6 was hidden by the
container images building the RPMs against Git LFS 2.4.0 as part of the
setup process. As a consequence, we never built the RPMs using the new
versions of the spec files in master, and we never noticed that they
failed in this case.
Since we're no longer building RPMs against an ancient version of Git
LFS as part of the setup process, adjust the Ruby RPMs to call the
correct %setup invocation on CentOS 7. Note that like the code with
%{?el6}, %{?el7} will expand to either 1 or nothing, so the condition
will be true (nonzero) for CentOS 6 or 7 and false (zero) for 8.
CentOS 8 has recently gained a new version of tar. This version of tar
is sensitive about the order of its operands and only applies the
--exclude arguments to file arguments following them. As a result, this
version of tar ignores the exclude arguments altogether, which results
in us trying to recursively copy the contents of the tmptar directory
into itself until the operation fails because the file name is too long.
Predictably, this results in a failed build for CentOS 8. To avoid
that, place the --exclude options before the file arguments so that
they apply correctly and the build succeeds.
Build packages for CentOS 8. Add it to the list of containers we build
for and the list of packages we have downloads available for.
In the gem spec files, use a different tooling on CentOS 8, since the
old method no longer works there. Build using a more standard gem build
process so that RPM does the abstraction for us now that it's capable of
it. Stop deleting the root in the install step since we may have
installed things there by that point, and RPM has handled this properly
for many versions.
Since the syntax "%{?el8}" expands to "1" on CentOS 8 and nothing on
earlier versions, add a 0 in front of it any time we use the macro so
that we don't end up with an empty conditional on earlier versions.
"01" is still true and "0" is false, so the logic works out.
It's been verified that the packages still build on CentOS 7 as well as
CentOS 8.
The upstream of go-ntlm has archived its repository and is no longer
doing releases. Because this dependency is required for Git LFS, we've
created our own fork to ensure that the upstream repo doesn't disappear
on us. Use our own copy of go-ntlm within Git LFS.
