https://bugzilla.redhat.com/show_bug.cgi?id=1013095 --- Comment #7 from Orion Poplawski <orion@xxxxxxxxxxxxx> --- (In reply to Mukundan Ragavan from comment #6) > Issues: > ======= > - Packages have proper BuildRequires/Requires on jpackage-utils > > ---> BuildRequires and cube-java has Requires: jpackage-utils - looks fine. > Does cube also require this? Requires does not show that below. No. > - gtk-update-icon-cache is invoked in %postun and %posttrans if package > contains icons. > Note: icons in cube > See: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache Fixed. > - Javadocs are placed in %{_javadocdir}/%{name} (no -%{version} symlink) > Note: No javadoc subpackage present > See: https://fedoraproject.org/wiki/Packaging:Java#Javadoc_installation > - Javadoc documentation files are generated and included in -javadoc > subpackage > Note: No javadoc subpackage present > See: https://fedoraproject.org/wiki/Packaging:Java#Javadoc_installation Yeah, this package doesn't provide a way to build it, and I'm not able to do it by hand. The Java folks are talking about making this optional as well. > - This seems like a Java package, please install fedora-review-plugin-java to > get additional checks > > ---> I don't why fedora-review is saying this when it **is** using the java > plugin! Hmm, file a bug :) > - Large documentation must go in a -doc subpackage. Large could be size > (~1MB) > or number of files. > Note: Documentation size is 2068480 bytes in 29 files. > See: > http://fedoraproject.org/wiki/Packaging/Guidelines#PackageDocumentation I was ending up with duplicated docs. Fixed. > - update-desktop-database is invoked in %post and %postun if package contains > desktop file(s) with a MimeType: entry. > Note: desktop file(s) with MimeType entry in cube > See: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#desktop- > database Fixed. > [?]: Fully versioned dependency in subpackages if applicable. > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in cube-doc , > cube-java > > ---> cube-doc is fine, but is this important for cube-java? No, java is noarch. > [x]: Package functions as described. > [!]: Latest version is packaged. > > ---> Latest version is 4.2.2 released on Feb 26. Please update. Done. > [?]: Package should compile and build into binary rpms on all supported > architectures. > > ---> Please do a koji scratch build. http://koji.fedoraproject.org/koji/taskinfo?taskID=6592007 > Generic: > [!]: Large data in /usr/share should live in a noarch subpackage if package > is > arched. > Note: Arch-ed rpms have a total of 2078720 bytes in /usr/share > > ---> Is this because there is no javadoc subpackage? No, the duplicated docs above. > Rpmlint > ------- > Checking: cube-4.2.1-2.fc21.x86_64.rpm > cube-devel-4.2.1-2.fc21.x86_64.rpm > cube-doc-4.2.1-2.fc21.noarch.rpm > cube-java-4.2.1-2.fc21.noarch.rpm > cube-4.2.1-2.fc21.src.rpm > cube.x86_64: W: shared-lib-calls-exit /usr/lib64/libcube4.so.4.2.0 > exit@GLIBC_2.2.5 > > $ rpmlint -I shared-lib-calls-exit > shared-lib-calls-exit: > This library package calls exit() or _exit(), probably in a non-fork() > context. Doing so from a library is strongly discouraged - when a library > function calls exit(), it prevents the calling program from handling the > error, reporting it to the user, closing files properly, and cleaning up any > state that the program has. It is preferred for the library to return an > actual error code and let the calling program decide how to handle the > situation. > > ---> Please investigate. Upstream response: note that the scorep libraries call exit()/_exit() as well. Here it is not always possible for the user to evaluate return codes. E.g., when using compiler instrumentation, function calls that possibly fail are inserted by the compiler. There is no way the user can handle this. > cube.src:63: E: hardcoded-library-path in /usr/lib > > $ rpmlint -I hardcoded-library-path > hardcoded-library-path: > A library path is hardcoded to one of the following paths: /lib, /usr/lib. It > should be replaced by something like /%{_lib} or %{_libdir}. > > ---> This is a problem. But, I think this is because of the sed call in the > spec file, in which case, it **might** be fine? Must be looked at. With 4.2.2 as I ended up moving to using chrpath to strip the rpaths. This seems to be gone with that. > Rpmlint (installed packages) > ---------------------------- > cube.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcubewriter4.so.4.2.0 > cube_write_sev_row > cube.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcubewriter4.so.4.2.0 > cube_write_sev_row_of_doubles > cube.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcubewriter4.so.4.2.0 > cube_create > cube.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcubewriter4.so.4.2.0 > cube_set_known_cnodes_for_metric > cube.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcubewriter4.so.4.2.0 > cube_write_sev_row_of_uint64 > cube.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcubewriter4.so.4.2.0 > cube_free > > $ rpmlint -I undefined-non-weak-symbol > undefined-non-weak-symbol: > The binary contains undefined non-weak symbols. This may indicate improper > linkage; check that the binary has been linked as expected. > > > ---> Please take a look at this. I've reported this upstream. As it stands I don't believe it is an issue because cube users use cube-config to get the libraries to link to. * Mon Mar 3 2014 Orion Poplawski <orion@xxxxxxxxxxxxx> - 4.2.2-1 - Update to 4.2.2 - Fix doc duplication - Add icon and destop-database scriptlets - Use chrpath to strip rpaths http://www.cora.nwra.com/~orion/fedora/cube.spec http://www.cora.nwra.com/~orion/fedora/cube-4.2.2-1.fc20.src.rpm -- You are receiving this mail because: 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