https://bugzilla.redhat.com/show_bug.cgi?id=1187713 --- Comment #17 from jiri vanek <jvanek@xxxxxxxxxx> --- (In reply to Zbigniew Jędrzejewski-Szmek from comment #16) > The patch to load libraries is wrong. It makes the jar file architecture > dependent, yes, intentionally > but it should not be. Just try loading from /usr/lib64, and then from > /usr/lib. > This will work on both 64 and 32 bit archs. Well - this patch is fedora only, and fedora do not support multilib jni packages (http://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI - uttermost end - ". Java packages using JNI do not support multiarch installation." Although I see your point, I would rather stay with my approach - to fail immediately if wrong arch is found. If you disagree, and insists, I will follow your opinion. > > ===== MUST items ===== > > [!]: License file installed when any subpackage combination is installed. > No license is installed with -javadocs. Eh... No license file does exists in whole project. > > [!]: Package requires other packages for directories it uses. > Note: No known owner of /usr/share/maven-poms/netty-tcnative, /usr/lib64 > /netty-tcnative, /usr/lib/java/netty-tcnative > [!]: Package must own all directories that it creates. > Note: Directories without known owners: /usr/share/maven-poms/netty- > tcnative, /usr/lib64/netty-tcnative, /usr/lib/java/netty-tcnative > Those should be added. fixed (sorry, I thought mvn_install is handling those three) > ...snip... > file > from upstream, the packager SHOULD query upstream to include it. > [!]: Final provides and requires are sane (see attachments). > See comments below > > [x]: Fully versioned dependency in subpackages if applicable. > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in netty- > tcnative-javadoc > Not needed. > > [?]: Package functions as described. The testclass runs fine on both x86_64 and i386 > [x]: Latest version is packaged. > [x]: Package does not include license text files separate from upstream. > [x]: Patches link to upstream bugs/comments/lists or are otherwise justified. > [-]: Description and summary sections in the package spec file contains > translations for supported Non-English languages, if available. > [?]: Package should compile and build into binary rpms on all supported > architectures. I have not tested arms... > I don't think it would actually build, because of the binary conflict. What do you mean?/Wy do you think so? > ... > > > Rpmlint > ------- > Checking: netty-tcnative-1.1.30-0.fc22.x86_64.rpm > netty-tcnative-javadoc-1.1.30-0.fc22.x86_64.rpm > netty-tcnative-1.1.30-0.fc22.src.rpm > netty-tcnative.x86_64: W: name-repeated-in-summary C Netty-tcnative > netty-tcnative.x86_64: W: spelling-error %description -l en_US mavenization > -> magnetization, humanization, maximization > netty-tcnative.x86_64: W: incoherent-version-in-changelog 1.1.30.Fork2.0 > ['1.1.30-0.fc22', '1.1.30-0'] > ??? > humph. No Named tags allowed? Oook. followed. > netty-tcnative.x86_64: W: no-documentation > netty-tcnative.src: W: name-repeated-in-summary C Netty-tcnative > rpmlint is right here. The summary is meaningless. > fixed > netty-tcnative.src: W: spelling-error %description -l en_US mavenization -> > magnetization, humanization, maximization > netty-tcnative.src: W: strange-permission netty-tcnative-1.1.30.Fork2.tar.gz > 0640L > netty-tcnative.src:68: W: macro-in-comment %{_jnidir} > netty-tcnative.src:68: W: macro-in-comment %{name} > netty-tcnative.src:68: W: macro-in-comment %{name} > Please fix those. done > > netty-tcnative.src:62: W: mixed-use-of-spaces-and-tabs (spaces: line 4, tab: > line 62) > And this. also fixed. > > netty-tcnative.src: W: patch-not-applied Patch1: fixLibNames.patch.in > 3 packages and 0 specfiles checked; 0 errors, 12 warnings. > OK. > > > Rpmlint (installed packages) > ---------------------------- > Cannot parse rpmlint output: > > > Requires > -------- > netty-tcnative (rpmlib, GLIBC filtered): > apr > java-headless > jpackage-utils > libapr-1.so.0()(64bit) > libc.so.6()(64bit) > libcrypto.so.10()(64bit) > libcrypto.so.10(OPENSSL_1.0.1)(64bit) > libcrypto.so.10(OPENSSL_1.0.1_EC)(64bit) > libcrypto.so.10(libcrypto.so.10)(64bit) > libdl.so.2()(64bit) > libpthread.so.0()(64bit) > libssl.so.10()(64bit) > libssl.so.10(libssl.so.10)(64bit) > openssl > This also seems unecessary. IIUC, only ssl libs are required, and that > dependency is provided automatically. Ok, I have removed (how had you found it?) Requires: apr Requires: openssl But added Requires: java-headless Requires: jpackage-utils (http://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires ?) > > rtld(GNU_HASH) > > netty-tcnative-javadoc (rpmlib, GLIBC filtered): > jpackage-utils > This seems unnecessary. This seems to be autoadded > > > Provides > -------- > netty-tcnative: > libnetty-tcnative-1.1.30.Fork2.so()(64bit) > mvn(io.netty:netty-tcnative) > mvn(io.netty:netty-tcnative:pom:) > netty-tcnative > netty-tcnative(x86-64) > osgi(io.netty.tcnative) > > netty-tcnative-javadoc: > netty-tcnative-javadoc > netty-tcnative-javadoc(x86-64) > One more patch added - build on i386 was failing... Directories updated (note, fixLibNames.patch.in kept as it was) Thank you! spec: https://jvanek.fedorapeople.org/elasticsearch/v4/netty-tcnative/netty-tcnative.spec srpm: https://jvanek.fedorapeople.org/elasticsearch/v4/netty-tcnative/netty-tcnative-1.1.30-0.fc21.src.rpm kept patch: https://jvanek.fedorapeople.org/elasticsearch/v4/netty-tcnative/fixLibNames.patch.in new patch: https://jvanek.fedorapeople.org/elasticsearch/v4/netty-tcnative/i388aprFix.patch (applied always, I'm not sure how arm32/64 will need it right now) -- 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 https://admin.fedoraproject.org/mailman/listinfo/package-review