https://bugzilla.redhat.com/show_bug.cgi?id=2121585 --- Comment #57 from Renich Bon Ciric <renich@xxxxxxxxxxxxxxxx> --- (In reply to Benson Muite from comment #56) > 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 Hey Benson, nice to read you. :D Well, I failed to see which the listing method was. I've added the __provides_exclude_from and __requires_exclude_from macros to all .so files to avoid looking for dependencies there since they, indeed, are private libraries. (event handlers, loggers, plugins and transports). If you think I need to create devel packages for every plugin and include the .so files there, I will. No problem. I might've understood wrongly what you said. > b) no-documentation warnings are fine OK. Phew! > c) Ok on duplicates at this point. Can address this after other issues. It > is likely there are minor differences in the files. OK. > 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. > cfg#L1219 > https://github.com/meetecho/janus-gateway/blob/master/docs/janus-doxygen. > cfg#L1846 > > However, footer has a date: > https://github.com/meetecho/janus-gateway/blob/master/docs/footer.html#L16 I've created a patch to remove the date from the footer. I'll include it in the next build. Hopefully, that takes care of most of the messages. > For record_play not sure what is causing this error: > https://github.com/meetecho/janus-gateway/blob/master/src/plugins/ > janus_recordplay.c I see there is an example date written in an example, right after the note: https://janus.conf.meetecho.com/docs/recordplay.html That might be triggering the warning, right? > 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- > automatically-print-out-its-git-version-hash/1843783#1843783 version.c gets auto-generated after `make`. it's even ignored in .gitignore to this end. I have no idea of how it gets generated but, when it does, it has the current date. [root@bc8d0dcfefb2 janus]# cat src/version.c #include "version.h" const char *janus_build_git_sha = "e8d1395d3de9caa5e244605ec1a7281cd7d3ecf1"; const char *janus_build_git_time = "Wed Feb 1 05:08:47 UTC 2023"; int janus_version = 1102; const char *janus_version_string = "1.1.2"; const char *libnice_version_string = "0.1.19"; > 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. I didn't really understand what you meant here. We should pass this SOURCE_DATE_EPOCH env var to autgen? Which date should we provide? The commit's date? OK, I know where version.c gets generated. Right bellow the link you gave me: https://github.com/meetecho/janus-gateway/blob/master/src/Makefile.am#L183. With gawk. :D What do we do with this? > e) Raised an issue on gethostbyname > https://github.com/meetecho/janus-gateway/issues/3156 Thank you very much for the help. :D > f) Further comments: > i) Consider adding make as a build dependency, cmake will bring it in, but > one might consider builds without cmake Done. It's been added to BuildRequires. > ii) Would it be better to use BoringSSL > https://boringssl.googlesource.com/boringssl/ instead of OpenSSL Well, the message in their own website is discouraging. "Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is.". I'd rather stick to openssl unless you think boring is better. The updated SPEC and SRPM: SPEC: https://renich.fedorapeople.org/janus/janus.spec SRPM: https://renich.fedorapeople.org/janus/janus-1.1.2-3.fc37.src.rpm -- 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 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
