https://bugzilla.redhat.com/show_bug.cgi?id=2121585
--- Comment #56 from Benson Muite <benson_muite(a)emailplus.org> ---
a) devel packages should have header files and .so libraries, other library
files .so.1 and .so.1.1.2 should be in main packages. Should the plugins have
devel packages? If not, plugin libraries should not be on ld path. A method of
listing private libraries which may work is described at:
https://lists.fedoraproject.org/pipermail/devel/2012-June/169190.html
b) no-documentation warnings are fine
c) Ok on duplicates at this point. Can address this after other issues. It is
likely there are minor differences in the files.
d)
rpmlint -e file-contains-date-and-time
file-contains-date-and-time:
Your file uses __DATE__ and __TIME__ which causes the package to rebuild when
not needed.
rpmlint -e file-contains-current-date
file-contains-current-date:
Your file contains the current date, this may cause the package to rebuild in
excess.
Doxygen does not add a timestamp:
https://github.com/meetecho/janus-gateway/blob/master/docs/janus-doxygen....
https://github.com/meetecho/janus-gateway/blob/master/docs/janus-doxygen....
However, footer has a date:
https://github.com/meetecho/janus-gateway/blob/master/docs/footer.html#L16
For record_play not sure what is causing this error:
https://github.com/meetecho/janus-gateway/blob/master/src/plugins/janus_r...
For version, maybe it is better to get GitHub CI to generate this information
and have it distributed:
https://github.com/meetecho/janus-gateway/blob/master/src/version.h
https://stackoverflow.com/questions/1704907/how-can-i-get-my-c-code-to-au...
It seems one can set SOURCE_DATE_EPOCH as an optional parameter before using
autogen
https://github.com/meetecho/janus-gateway/blob/master/src/Makefile.am#L178
However, having this information in the release would likely enable more
efficient automated builds.
e) Raised an issue on gethostbyname
https://github.com/meetecho/janus-gateway/issues/3156
f) Further comments:
i) Consider adding make as a build dependency, cmake will bring it in, but one
might consider builds without cmake
ii) Would it be better to use BoringSSL
https://boringssl.googlesource.com/boringssl/ instead of OpenSSL
--
You are receiving this mail because:
You are always notified about changes to this product and component
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2121585