https://bugzilla.redhat.com/show_bug.cgi?id=1914292 code@xxxxxxxxxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(ti.eugene@gmail.c | |om) --- Comment #5 from code@xxxxxxxxxxxxxxxxxx --- Thanks. > - -lib is usual for those who requires libs without tkrzw CLI utils (e.g. future python-tkrzw) I agree with the existence of the -libs subpackage. Calling it -lib would have been fine, too, but -libs is a more popular choice. I am just not sure what the purpose of Provides: %{name}-lib = %{version}-%{release} Provides: %{name}-lib%{?_isa} = %{version}-%{release} is. Why offer “-lib” with a virtual Provides? Can’t you just expect packages like python-tkrzw to depend on tkrzw-libs? If you really like providing both -libs and -lib, I guess there is no prohibition against it, so you are welcome to do so. It just seems unnecessary. > --disable-static not helps with *.a (BTW it is disabled by default) You are right; I was mistaken on this point. > skip-test patch above not improved because all of file-based DB tests not pass on each of archs. So all those tests is disabled now. It doesn’t make sense to package a database library that is corrupting data in its test suite. Fortunately, I was able to make some progress on figuring out why this is happening. It looks like this must be an upstream bug (not necessarily a known one) that becomes apparent when LTO (link-time optimization) is enabled. Adding “%global _lto_cflags %{nil}” somewhere in the spec file to opt out of LTO seems to fix it. (From a packaging guidelines perspective, turning off LTO to fix a bug is perfectly fine.) That is probably worth reporting upstream, although it may be difficult for them to find the root cause. Often, this is happens when the program relies on undefined C or C++ behavior, but “gets away with it” until the compiler can consider multiple translation units. Here is a Koji build where I have taken your most recent spec file, rolled back to the original tests patch, and disabled LTO. I also did the following: - Changed “%doc doc/* api-doc/*” to “%doc doc api-doc”, to avoid intermixing two directories full of HTML, instead creating a subdirectory of the package documentation directory for each set of documentation - Changed “%license” to “%license COPYING” in the %files section for the -doc subpackage - Per https://docs.fedoraproject.org/en-US/packaging-guidelines/#_manpages, changed man page wildcards from %{_mandir}/man1/%{name}_*.1.* to %{_mandir}/man1/%{name}_*.1* (There could be a couple of other minor details remaining. I did not do a full re-review—but it looks good at a glance.) F34: https://koji.fedoraproject.org/koji/taskinfo?taskID=60045371 This is much closer! The tests pass on every architecture except i686. The nature if the i686 failure is concerning: “BROKEN_DATA_ERROR: invalid record magic number”. That implies data corruption, so I think it will be necessary to “ExcludeArch: %ix86” and file a bug blocking https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-x86, unless we can find a solution with a little more investigation. I would say that a database that corrupts data in its test suite on a platform “does not work” on that platform. See https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures for the policy on how to deal with this. The NEEDINFO is to solicit your comments on the above, and check if you have any ideas on the i686 failure. I will try to spend a little time looking at it as well. If we conclude there is no fix to be easily found, we can add the ExcludeArch and I will complete the re-review. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
