[Bug 1476458] Review Request: paho-c - MQTT client library in C

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1476458



--- Comment #16 from Miroslav Suchý <msuchy@xxxxxxxxxx> ---
Can you please provide updated SRC.RPM? The latest I was able to find
 
https://copr-be.cloud.fedoraproject.org/results/orpiske/paho-testing/fedora-26-x86_64/00589833-paho-c/
contains different tar.gz file from the one located on the Source0 URL.
paho-c.src: W: file-size-mismatch v1.2.0.tar.gz = 441242,
https://github.com/eclipse/paho.mqtt.c/archive/v1.2.0.tar.gz = 431819


The description should be wrapped to 80 characters (you have 81).

paho-c.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaho-mqtt3a.so.1.2.0
exit@GLIBC_2.2.5
paho-c.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaho-mqtt3as.so.1.2.0
exit@GLIBC_2.2.5
paho-c.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaho-mqtt3c.so.1.2.0
exit@GLIBC_2.2.5
paho-c.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaho-mqtt3cs.so.1.2.0
exit@GLIBC_2.2.5
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.

You cannot do anything about it as just maintainer. But you should at least
file issue for upstream.

paho-c.x86_64: W: crypto-policy-non-compliance-openssl
/usr/lib64/libpaho-mqtt3as.so.1.2.0 SSL_CTX_set_cipher_list
paho-c.x86_64: W: crypto-policy-non-compliance-openssl
/usr/lib64/libpaho-mqtt3cs.so.1.2.0 SSL_CTX_set_cipher_list
Again. File issue to upstream:
https://fedoraproject.org/wiki/Packaging:CryptoPolicies

paho-c-devel.x86_64: W: no-manual-page-for-binary MQTTAsync_publish
paho-c-devel.x86_64: W: no-manual-page-for-binary MQTTAsync_subscribe 
paho-c-devel.x86_64: W: no-manual-page-for-binary MQTTClient_publish
paho-c-devel.x86_64: W: no-manual-page-for-binary MQTTClient_publish_async
paho-c-devel.x86_64: W: no-manual-page-for-binary MQTTClient_subscribe
paho-c-devel.x86_64: W: no-manual-page-for-binary MQTTVersion
paho-c-devel.x86_64: W: no-manual-page-for-binary paho_c_pub
paho-c-devel.x86_64: W: no-manual-page-for-binary paho_c_sub
paho-c-devel.x86_64: W: no-manual-page-for-binary paho_cs_pub
paho-c-devel.x86_64: W: no-manual-page-for-binary paho_cs_sub
This is not blocker for the review, but you should write man pages for those
binaries.

paho-c-devel-doc.noarch: E: standard-dir-owned-by-package /usr/share/doc
You should not own that directory. Instead of
  %{_datadir}/*
use
  %{_defaultdocdir}/*

Are you sure that main package should not contain any /usr/bin/SOMETHING? It
now contains only library. Then such package should be named libpaho-c.

I would highly recommend renaming `%package devel-doc` to just `%package doc`.
The doc subpackage for such packages is nearly always meant for developers.

-- 
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




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite Conditions]     [KDE Users]

  Powered by Linux