-
-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test failures with zlib-ng #274
Comments
I really don't know how to best solve this.
I am leaning towards the last solution, because it is the simplest. But I am not really happy about it. |
Would unit tests also fail when using the zlib-ng-compat package instead? |
Yes because that is just zlib-ng's zlib compatibility mode that builds libz.so with the traditional API calls - that is in fact exactly what Fedora is using as the zlib replacement. There is also a libz-ng.so with a new native API which is in the main zlib-ng package. |
I just run into this exact same problem while building osmium-tool-1.16.0-4 (srpm from fedora 40) in mock on almalinux 9.3. However, almalinux AFAIK does not use zlib-ng. The mock build installed zlib-devel 1.2.11-40.el9 from the appstream repo. Update: I tried again with osmium-tool-1.16.0-1 (srpm from fedora 39) in the exact same mock environment. This time the tests succeeded and the binary rpm was built successfully. Both srpms use the exact same source code, so the difference must be in the .spec file. And quite right,
So there's nothing wrong with the source code or the tests. The problem is the .spec file, which should have conditioned patch1 according to the distro, |
So if the issue is really due to spec files (which are maintained elsewhere), we can probably close this one. |
@mmd-osm: Yes, it is an rpm packaging bug, not an osmium-tool bug. But both the problem and the solution have now been documented here and will be useful to the next person facing the same problem. |
It's not really a packaging bug, it's a "running the tests in any environment that doesn't match upstream" bug. Incidentally the suggested patch doesn't work (you can't make patch declarations conditional) and is also irrelevant to me as Fedora packager because I'm writing a spec to build for Fedora not a spec to build for arbitrary rpm based distros. Writing a spec for almalinux or RHEL or whatever is a matter for the packager of those distros, |
What version of osmium-tool are you using?
osmium version 1.16.0
libosmium version 2.20.0
What operating system version are you using?
Fedora Rawhide (the upcoming Fedora 40 release)
What did you do exactly?
Built osmium and ran the tests.
What did you expect to happen?
The tests should pass.
What did happen instead?
Tests which compare compressed PBF output failed, namely:
What did you do to try analyzing the problem?
The problem is that Fedora 40 is switching from zlib to zlib-ng for it's zlib implementation and the compressed output is different while producing the same result when decompressed.
This is in reality a broader problem in that the exact form of the compressed data could change at any time - in the past I have seen it change between zlib versions for example.
Options for fixing this would be to unpack the output before comparing it (but then you're not really testing quite the same thing) or to store multiple possible valid outputs for those tests which then requires extensions to the tooling for comparisons to support that.
The text was updated successfully, but these errors were encountered: