https://bugzilla.redhat.com/show_bug.cgi?id=843695
Mario Blättermann <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |m --- Comment #1 from Mario Blättermann <[email protected]> --- Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4401812 $ rpmlint -i -v * gecode.i686: I: checking gecode.i686: I: checking-url http://www.gecode.org/ (timeout 10 seconds) gecode.i686: W: shared-lib-calls-exit /usr/lib/libgecodegist.so.32.0 exit@GLIBC_2.0 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. gecode.i686: W: shared-lib-calls-exit /usr/lib/libgecodeflatzinc.so.32.0 exit@GLIBC_2.0 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. gecode.i686: W: shared-lib-calls-exit /usr/lib/libgecodedriver.so.32.0 exit@GLIBC_2.0 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. gecode.src: I: checking gecode.src: I: checking-url http://www.gecode.org/ (timeout 10 seconds) gecode.src: I: checking-url http://www.gecode.org/download/gecode-3.7.3.tar.gz (timeout 10 seconds) gecode.x86_64: I: checking gecode.x86_64: I: checking-url http://www.gecode.org/ (timeout 10 seconds) gecode.x86_64: W: shared-lib-calls-exit /usr/lib64/libgecodeflatzinc.so.32.0 exit@GLIBC_2.2.5 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. gecode.x86_64: W: shared-lib-calls-exit /usr/lib64/libgecodedriver.so.32.0 exit@GLIBC_2.2.5 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. gecode.x86_64: W: shared-lib-calls-exit /usr/lib64/libgecodegist.so.32.0 exit@GLIBC_2.2.5 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. gecode-debuginfo.i686: I: checking gecode-debuginfo.i686: I: checking-url http://www.gecode.org/ (timeout 10 seconds) gecode-debuginfo.x86_64: I: checking gecode-debuginfo.x86_64: I: checking-url http://www.gecode.org/ (timeout 10 seconds) gecode-devel.i686: I: checking gecode-devel.i686: I: checking-url http://www.gecode.org/ (timeout 10 seconds) gecode-devel.i686: W: no-documentation The package contains no documentation (README, doc, etc). You have to include documentation files. gecode-devel.i686: W: no-manual-page-for-binary fz Each executable in standard binary directories should have a man page. gecode-devel.i686: W: no-manual-page-for-binary mzn-gecode Each executable in standard binary directories should have a man page. gecode-devel.x86_64: I: checking gecode-devel.x86_64: I: checking-url http://www.gecode.org/ (timeout 10 seconds) gecode-devel.x86_64: W: no-documentation The package contains no documentation (README, doc, etc). You have to include documentation files. gecode-devel.x86_64: W: no-manual-page-for-binary fz Each executable in standard binary directories should have a man page. gecode-devel.x86_64: W: no-manual-page-for-binary mzn-gecode Each executable in standard binary directories should have a man page. gecode-doc.noarch: I: checking gecode-doc.noarch: I: checking-url http://www.gecode.org/ (timeout 10 seconds) gecode-examples.noarch: I: checking gecode-examples.noarch: I: checking-url http://www.gecode.org/ (timeout 10 seconds) gecode.spec: I: checking-url http://www.gecode.org/download/gecode-3.7.3.tar.gz (timeout 10 seconds) 9 packages and 1 specfiles checked; 0 errors, 12 warnings. Some of the issues can be ignored, such as the missing docs and manpages. Your package looks almost fine, but there is a recognizable issue: gecode.x86_64: W: shared-lib-calls-exit /usr/lib64/libgecodegist.so.32.0 exit@GLIBC_2.2.5 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. Well, this is no review blocker, because you are the packager and cannot fix such bugs. But it is worth to inform the upstream people about that. Just a few objections from me: %{name} = %{version}-%{release} has to be for the -devel package %{name}%{?_isa} = %{version}-%{release} because it is no "noarch" package. The -doc package owns the folder %{_defaultdocdir}/%{name}-doc-%{version}/html, but not the parent folder %{_defaultdocdir}/%{name}-doc-%{version}. Please add this as %dir or just use %{_defaultdocdir}/%{name}-doc-%{version}. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ package-review mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/package-review
