Zlib.crc32 calculates CRC checksum for string and initial CRC value FAILED about spec

[ljavorsk]

I apologize for this problem. I made a pretty big zlib rebase yesterday and I should've provided it in the private copr repository for deeper testing.

I've asked the Fedora Releng team to untag this build, so it should be fine again.

I'll fix the new release and provide the repository for testing purposes when it's ready

[voxik]

@pvalena, @junaruga, @jackorp could you please help me and try the updated zlib and see if it resolves the issue above?

[mscastanho]

This could be related the issue fixed by this zlib commit.

[eregon]

Let's close, it seems an incompatibility/bug from zlib, which sounds like it will get fixed to be the same as before.

FWIW I know of 1 ABI issue with zlib in

spec/library/zlib/crc_table_spec.rb

Lines 4 to 11 in ab32a1a

	describe "Zlib.crc_table" do
	# This spec fails when zlib.h and libz.so are not from the same version.
	# In older zlib (< 1.2.7 it seems), get_crc_table() is stored as u64[],
	# but in newer zlib, get_crc_table() is stored as u32[].
	# Technically, there is ABI breakage between those zlib versions,
	# but get_crc_table() is an "undocumented function" according to zlib.h.
	guard -> { ENV["RUBY_SPEC_TEST_ZLIB_CRC_TABLE"] != "false" } do
	it "returns the same value as zlib's get_crc_table()" do

But that sounds fair enough given get_crc_table() is an "undocumented function".

[ljavorsk]

The Fedora zlib RPMs with the commit above applied are available for testing, could you please test them and let me know if the issue is fixed?

You can download them here: https://ljavorsk.fedorapeople.org/zlib/

[jackorp]

could you please help me and try the updated zlib and see if it resolves the issue above?

I am taking a look using the RPMs from @ljavorsk's link.

[jackorp]

Builds do not fail on the ZLib related portion anymore: see Copr build (i.e. the i386 arch): https://copr.fedorainfracloud.org/coprs/jackorp/ruby_zlib/build/4608429/ .

The failure now lies with some (probably) temp test files, see the end of i386 logs for detail. However, this should not be the result of the ZLib library (I'll take a closer look tomorrow to verify).

[ljavorsk]

Okay, please let me know as soon as you can if I can push this release to Fedora Rawhide.

The releng team is pinging me for having this fixed ASAP.

Thank you for the help :)

[jackorp]

The failure is not zlib related, as it is related to directory permission manipulation.

This seems like the commit that fixes that: rubygems/rubygems@623162a