CentOS 7 will go EOL later this year, and infra wants to drop the nodes
soon-ish -- don't make them wait on our account.
Change-Id: Iaa31fc95ed2d100726adf60807c8bf95599afd3f
The autoconf manual warns against using the posix shell command `[ ... ]`:
> The `test` program is the way to perform many file and string tests. It
> is often invoked by the alternate name `[`, but using that name in
> Autoconf code is asking for trouble since it is an M4 quote character.
Using `[ foo = bar ]` is evaluated as `foo = bar` with m4-quoting
resolved. Here, we used `[[ foo = bar ]]` instead, which superficially
looks like a bashism, but is actually an m4 quote escape that resolves
to `[ foo = bar ]`.
Avoid the confusion by using the configure.ac standard for spelling
`test`.
Change-Id: I31dfa6ab4abb181159a4364900e6da24c929705f
Fixes regression in commit f3a99e81e9
which prevented successfully running on non-bash shells.
Bash provides the standard `test XXX = YYY` or `[ XXX = YYY ]`
utilities. It also provides the ability to spell the equals sign as a
double equals. This does nothing whatsoever -- it adds no new
functionality to bash, it forbids nothing, it is *literally* an exact
alias.
It should never be used under any circumstances. All developers must
immediately forget that it exists. Using it is non-portable and does not
work in /bin/sh scripts such as configure scripts, and it results in
dangerous muscle memory when used in bash scripts because it makes
people unthinkingly use the double equals even in /bin/sh scripts. To
add insult to injury, it makes scripts take up more disk space (by a
whole byte! and sometimes even a few bytes...)
Delete this accidental bashism, and restore the ability to get correct
./configure behavior on systems where /bin/sh is something other than a
symlink to GNU bash.
Change-Id: I38ee6d19d12cf8702ef394f3ee40f353f749b2c6
Some files use tabs instead of spaces for indent. Even some other
files use both of tabs and spaces which is quite confusing.
This updates all *.c files and *.h files to use spaces consistently.
Note that indent width is still inconsistent (2 vs 4), which may be
fixed later.
Change-Id: I7c0b2629785bfbaf3d0a06d8d81aa29c00168083
We probably want some format tools (like clang-format) in the future,
but for now all these spaces are deleted by sed.
Change-Id: Idcc1cbfa39aecf0d5109488defd89b8a60b786da
... and build it from source so we can build latest ISA-L
(otherwise, the version shipped by some distros would
complain about a %use directive).
Change-Id: Ic9284c0c24860e44f0c73281492ad4bf873b3d7c
Go ahead and move the FIPS job to CentOS 9; there doesn't seem to be
much value in having more than one FIPS job.
Change-Id: I8c2c95e490ec083116f2ed7b9fb0d66918424fb7
Note that the job still won't trigger a +1/-1 vote, but the comment will
accurately say whether the pipeline succeeded or failed.
Change-Id: I3fbc109526d194e1928fec5180e97071ad082b15
it actually doesn't assert the value
becase we now use same if statement
for the assertion but hope it to be
even a little better than no covarage.
Change-Id: I8860a2a8227e43e02afddcbad1e108157c0872f6
...if users *really* want to. They opt-in at run time by setting
LIBERASURECODE_WRITE_LEGACY_CRC=1
in the environment; leaving it unset, set to an empty string, or set to
the string "0" continues to write zlib crcs.
UpgradeImpact
=============
This option is intended to allow a smooth upgrade from liberasurecode
1.5.0 and earlier in a system with multiple readers and writers:
* Before upgrade, ensure the environment variable is set on all nodes.
This will be ignored by earlier versions.
* Upgrade liberasurecode on each node in the system, restarting any
services that use it. Every node continues writing CRCs that are
still usable by nodes that have not yet upgraded.
* Now that every node is capable of reading zlib CRCs, remove the
environment variable from each node to start writing new CRCs.
If you are already using 1.6.0 or later, just upgrade normally.
Closes-Bug: #1886088
Closes-Bug: #1867937
Related-Bug: #1666320
Needed-By: https://review.opendev.org/#/c/739164/
Change-Id: I9adfbe631a2dddc592fd08f8a325f3e8331b92f1
*Hopefully*, this will make it "standard" enough that GitHub will
call it out as the BSD-2-Clause that it is.
Change-Id: If097a3d86e1bd22cebbcbc160c6ae238663843c5
Compilers are getting smarter, and we started getting this:
libec_slap.c: In function 'test_hd_code':
libec_slap.c:285:14: error: 'frags.array' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
The fix is to consume the error code in such a way that the
test proceeds further only when frags are indeed initialized.
Change-Id: I54db0172a36419206d00b22608523a08818f41f6
Apparently the author of our old crc32 assumed that shifting an int
to the right sign-extends, which is not always the case. Result is,
building and running make test on s390x fails. The fix is to force
a sign-extension using the "xor 0x80; sub 0x80" trick.
N.B. This does not cause a compatibility problem, because by a
miracle the "broken" crc32_alt was actually computing a stock
crc32, same that zlib has. Therefore, if someone, somewhere,
ran a Swift cluster on s390x with erasure coding policy,
the data in it is already stored with zlib checksums, as we
do it now anyway. This fix only permits the tests pass, which
used the bad data sample from x86.
Change-Id: Ibd5e4e6c02be00540a9648cc7e0f8efda275bf3f
Related-Change: Ib5ea2a830c7c23d66bf2ca404a3eb84ad00c5bc5
Related-Bug: 1666320
This popped up because Fedora mandates warning-free builds,
and get_chksum triggers a warning because it returns an
unaligned pointer (it is so analigned, static analysis in
the compiler can detect it).
The easiest fix is to remove it altogether. We think it should
be safe, because:
- The function is not listed in any headers
- Its counterpart is called "set_checksum", not "set_chksum"
- PyECLib does not use it
We also hush some doxygen warnings about wrong comments.
Change-Id: Ie5bc736f912706e0ffd507765abd24e7f4761233