Spec: https://download.copr.fedorainfracloud.org/results/snmende/cbang/fedora-rawhide-x86_64/04948741-cbang/cbang.spec SRPM: https://download.copr.fedorainfracloud.org/results/snmende/cbang/fedora-rawhide-x86_64/04948741-cbang/cbang-1.7.2-1.fc38.src.rpm Description: The C! or cbang library is a collection of C++ utility libraries developed over the course of +15 years and several major C++ application development projects. It should compile and run on Windows, Linux and OSX using a modern C++ compiler. Many of the facilities of C! are geared towards cross-platform application development and providing basic services that most applications need such as a configuration system, run-time build information, logging facilities, threads, smart pointers, simple embedded scripting, etc. C!'s philosophy is to create clean, simple, readable, modular and reusable code. C! also encourages exception based error handling, and light use of C++ templates and C preprocesor macros. C! "leans" on the venerable boost library but also reimplements several boost APIs which are considered by the author to be too template heavy, less readable or overly complicated in boost. The code was developed on an as needed basis and was never intended to be any sort of grand unifying system for C++ application development. However, I hope you find many parts of the library useful in your C++ development projects. Fedora Account System Username: snmende Build: https://copr.fedorainfracloud.org/coprs/snmende/cbang/build/4948741/
Benson, the dependency on moodycamel-readerwriterqueue is dropped. The links in the OP are updated Thank you, Sergey
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: If your application is a C or C++ application you must list a BuildRequires against gcc, gcc-c++ or clang. [x]: Header files in -devel subpackage, if present. [x]: ldconfig not called in %post and %postun for Fedora 28 and later. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. [x]: Development (unversioned) .so files in -devel subpackage, if present. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "GNU Lesser General Public License v2.1 or later", "GNU Lesser General Public License, Version 2.1", "BSD 3-Clause License". 379 files have unknown license. Detailed output of licensecheck in /home/FedoraPackaging/reviews/cbang/2129303-cbang/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [x]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [?]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 10240 bytes in 1 files. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: Package requires other packages for directories it uses. [x]: Package must own all directories that it creates. [x]: Package does not own files or directories owned by other packages. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package must not depend on deprecated() packages. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local Python: [-]: Python eggs must not download any dependencies during the build process. [-]: A package which is used by another package via an egg interface should provide egg info. [-]: Package meets the Packaging Guidelines::Python [x]: Package contains BR: python2-devel or python3-devel [x]: Packages MUST NOT have dependencies (either build-time or runtime) on packages named with the unversioned python- prefix unless no properly versioned package exists. Dependencies on Python packages instead MUST use names beginning with python2- or python3- as appropriate. [x]: Python packages must not contain %{pythonX_site(lib|arch)}/* in %files [x]: Binary eggs must be removed in %prep ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Patches link to upstream bugs/comments/lists or are otherwise justified. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [x]: Package should compile and build into binary rpms on all supported architectures. [x]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Fully versioned dependency in subpackages if applicable. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on debuginfo package(s). Note: There are rpmlint messages (see attachment). [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Cannot parse rpmlint output: Rpmlint (debuginfo) ------------------- Cannot parse rpmlint output: Rpmlint (installed packages) ---------------------------- ============================ rpmlint session starts ============================ rpmlint: 2.4.0 configuration: /usr/lib/python3.11/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-legacy-licenses.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml checks: 31, packages: 4 cbang.x86_64: W: no-documentation 4 packages and 0 specfiles checked; 0 errors, 1 warnings, 0 badness; has taken 6.6 s Source checksums ---------------- https://github.com/CauldronDevelopmentLLC/cbang/archive/1.7.2/cbang-1.7.2.tar.gz : CHECKSUM(SHA256) this package : c0c86df602f65f733d275da782bbec3eda66ee355bc1aeb6f736175ba7532ac1 CHECKSUM(SHA256) upstream package : c0c86df602f65f733d275da782bbec3eda66ee355bc1aeb6f736175ba7532ac1 Requires -------- cbang (rpmlib, GLIBC filtered): libboost_filesystem.so.1.78.0()(64bit) libboost_iostreams.so.1.78.0()(64bit) libbz2.so.1()(64bit) libc.so.6()(64bit) libexpat.so.1()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) liblz4.so.1()(64bit) libm.so.6()(64bit) libnode.so.108()(64bit) libsqlite3.so.0()(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.8)(64bit) libstdc++.so.6(CXXABI_1.3.9)(64bit) libyaml-0.so.2()(64bit) rtld(GNU_HASH) cbang-devel (rpmlib, GLIBC filtered): cbang(x86-64) libcbang0.so.1.7()(64bit) cbang-debuginfo (rpmlib, GLIBC filtered): cbang-debugsource (rpmlib, GLIBC filtered): Provides -------- cbang: cbang cbang(x86-64) libcbang0.so.1.7()(64bit) cbang-devel: cbang-devel cbang-devel(x86-64) cbang-debuginfo: cbang-debuginfo cbang-debuginfo(x86-64) debuginfo(build-id) libcbang0.so.1.7.2-1.7.2-1.fc38.x86_64.debug()(64bit) cbang-debugsource: cbang-debugsource cbang-debugsource(x86-64) Generated by fedora-review 0.9.0 (6761b6c) last change: 2022-08-23 Command line :/usr/bin/fedora-review -b 2129303 Buildroot used: fedora-rawhide-x86_64 Active plugins: Shell-api, C/C++, Python, Generic Disabled plugins: PHP, R, Haskell, fonts, Java, Ruby, SugarActivity, Ocaml, Perl Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH Comments: a) Maybe worth explicitly listing Openssl as a dependency b) BSD License is for test-harness which seems to not be installed, but is used in build c) Should MariaDB/LevelDB be added as dependencies for the extra features? d) Should libbfd, libiberty be added as dependencies for debug builds? e) Maybe worth asking upstream to soname the library? f) Build on ELN fails https://copr.fedorainfracloud.org/coprs/fed500/cbang/build/4945964/ though this is not essential g) For documentation, maybe upstream would consider doxygen, https://www.doxygen.nl/manual/starting.html#man_out which can generate man pages? This might avoid some of the duplication in the README and in the documentation in docs/www? h) Maybe also remove the scripts folder? i) The utilities in general are useful. Can many of them be made available as subpackages? For example, renewing ACME certificates maybe helpful as a standalone feature. Subpackages would give greater visibility and encourage greater use. This is not essential though.
(In reply to Benson Muite from comment #2) > Comments: > a) Maybe worth explicitly listing Openssl as a dependency > c) Should MariaDB/LevelDB be added as dependencies for the extra features? As I mentioned earlier, I did not find another OSS project that uses cbang, thoug I was not digging too deep. The sqlite dependency is not needed for camotics, but without it cbang's build fails and there is no option to completely disable it. The openssl is not used by camotics as well. My intent was to make it have as many dependencies as necessary to build camotics. > b) BSD License is for test-harness which seems to not be installed, but is > used in build Does this mean that BSD license must be also listed in `License:`? > d) Should libbfd, libiberty be added as dependencies for debug builds? Yes, this could be useful in problems troubleshooting as the camotics is in pre-release stage and I used to report a bug causing core dump upstream. I'll add these > e) Maybe worth asking upstream to soname the library? I have asked Joseph on his versioning policy in general and he replied that he has no one [0]. As 1) Joseph adds the functionality on as needed basis, 2) there are obvious bugfixes, 3) camotics builds properly with up-to-date version of cbang and 4) cbang exports c++ classes, I decided to use `version.subversion` as an so version, leaving `.revision` for bug fixes in cbang. The leading zero in `libcbang0` is from upstream, I suspect that it is somehow related to debian packaging/naming, so I leaved this as is. However, I will ask Joseph again about soname specifically. > f) Build on ELN fails > https://copr.fedorainfracloud.org/coprs/fed500/cbang/build/4945964/ though > this is not essential Yes, there is no python3-scons at least. > g) For documentation, maybe upstream would consider doxygen, > https://www.doxygen.nl/manual/starting.html#man_out which can generate man > pages? This might avoid some of the duplication in the README and in the > documentation in docs/www? I will see if I can manage with that as Joseph hardly would make docs suite which is not a blocking factor for his development goals. > h) Maybe also remove the scripts folder? done > i) The utilities in general are useful. Can many of them be made available > as subpackages? For example, renewing ACME certificates maybe helpful as a > standalone feature. Subpackages would give greater visibility and encourage > greater use. This is not essential though. Yes, I agree on adoption possibility, but these are mostly use examples. The acmev2 utility would impose OpenSSL dependency. I will update and upload new versions of spec e.t.c. as you respond in regard of BSD License [0] https://github.com/CauldronDevelopmentLLC/cbang/issues/98
(In reply to Sergey from comment #2) > > e) Maybe worth asking upstream to soname the library? > > I have asked Joseph on his versioning policy in general and he replied that > he has no one [0]. As 1) Joseph adds the functionality on as needed basis, > 2) there > are obvious bugfixes, 3) camotics builds properly with up-to-date version of > cbang > and 4) cbang exports c++ classes, I decided to use `version.subversion` as > an so version, > leaving `.revision` for bug fixes in cbang. The leading zero in `libcbang0` > is from > upstream, I suspect that it is somehow related to debian packaging/naming, > so I > leaved this as is. However, I will ask Joseph again about soname > specifically. Done, confirmed upstream https://github.com/CauldronDevelopmentLLC/cbang/issues/103
Benson, one more question. Is this acceptable to reduce BR `python3-devel` to `python3-rpm-macros` in this particular case (the only required feature is `%py_byte_compile` macro to create a compiled cache for .py files) Thank you, Sergey
Thanks for contributing to Fedora. Utilities in C! may be helpful for other packages, so it is good to make it easy to use, maintain and extend. Having subpackages would help minimize dependencies that are not required in other projects. For example sqlite3 could be used in only one/a few subpackages. Maybe this is worth suggesting upstream? It would require more changes than providing one library with all features, so is a worthwhle future development but does not prevent inclusion in Fedora. Checking the Python guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ I think python3-devel is required. A subpackage with Python files seems useful. Will you want this in EPEL as well? Listing BSD license is not required: https://docs.fedoraproject.org/en-US/legal/license-field/#_basic_policy
(In reply to Benson Muite from comment #6) > Thanks for contributing to Fedora. > > Utilities in C! may be helpful for other packages, so it is good to make it > easy to use, maintain and extend. > > Having subpackages would help minimize dependencies that are not required in > other projects. For example sqlite3 could be used in only one/a few > subpackages. Maybe this is worth suggesting upstream? It would require more > changes than providing one library with all features, so is a worthwhle > future development but does not prevent inclusion in Fedora. Yes, I understand this. The problem is that upstream developer uses cbang as a static library in his projects. The shared library build appeared due to the demand from other people and it was done with minimal effort to achieve. So basically, if someone split it into sub-libraries, it would not be an upstream developer. I could do this but I would like first to get through the whole package maintenance procedures, so I will get an experience that could give me a better view. > Will you want this in EPEL as well? It would be nice of course as it extends the target audience. However, if that would require any customisation (e.g. build fails on ELN, so RHEL has no python3-scons as well, obviously) then I prefer to postpone this a bit due to the reason I wrote above. Links in the OP are updated with a fresh spec & build Thank you Sergey
(In reply to Benson Muite from comment #2) > f) Build on ELN fails > https://copr.fedorainfracloud.org/coprs/fed500/cbang/build/4945964/ though I rebuilt locally all missing deps for ELN from rawhide source packages, namely scons, node (for v8 library), nodejs-packaging as a dependency of node and re2 and then the cbang build completed without problems. So basically it is possible to build for EPEL as well as soon as these deps are included into EPEL
(In reply to Sergey from comment #8) > (In reply to Benson Muite from comment #2) > > > f) Build on ELN fails > > https://copr.fedorainfracloud.org/coprs/fed500/cbang/build/4945964/ though > > I rebuilt locally all missing deps for ELN from rawhide source packages, > namely scons, node (for v8 library), nodejs-packaging as a dependency of > node and re2 and then the cbang build completed without problems. > > So basically it is possible to build for EPEL as well as soon as these deps > are included into EPEL Benson, I found that nodejs-*.eln121.x86_64.rpm exists in ELN AppStream collection, but no v8-devel, a subpackage of nodejs, the re2-20211101-4.eln121.x86_64.rpm also exists, but no re2-devel-20211101-4.eln121.x86_64.rpm. How this comes out? Thank you, Sergey
ELN is not critical. Good to know the reason for failure though. Thanks.
Further comments: a) The license file is included in both cbang and cbang-devel packages, putting it in the cbang package alone is likely sufficient as cbang-devel will require cbang. b) What libraries are needed when using cbang? The spec file should likely have a "Requires" section. c) Is the folder cbang-devel-1.7.2-1.fc38.x86_64.rpm/usr/lib/cbang/config has a number of config files. Are all of these needed? If so, should they be in %libexecdir ? See https://docs.fedoraproject.org/en-US/packaging-guidelines/#_libexecdir Perhaps they should be marked as configuration files, see https://docs.fedoraproject.org/en-US/packaging-guidelines/#_configuration_files
(In reply to Benson Muite from comment #11) Benson, > Further comments: > a) The license file is included in both cbang and cbang-devel packages, > putting it in the cbang package alone is likely sufficient as cbang-devel > will require cbang. I'll take this to account. > b) What libraries are needed when using cbang? The spec file should likely > have a "Requires" section. The [0] in the Q&A Section under "Do I need a Requires: glibc..." states, that all binaries in a package are scanned for actual dependencies and the RPM automatically includes all necessary `Requires:`. Indeed, if you inspect the resulting arch-ed rpm you'll see that it requires for example, libboost_filesystem.so.1.76.0 and libboost_iostreams.so.1.76.0, the only parts from the `boost` library the cbang depends. > c) Is the folder cbang-devel-1.7.2-1.fc38.x86_64.rpm/usr/lib/cbang/config > has a number of config files. Are all of these needed? If so, should they be > in %libexecdir ? See > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_libexecdir > Perhaps they should be marked as configuration files, see > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > #_configuration_files These files are not configuration files, the name of a directory a bit misleading. Apart from C++ functions the cbang library contains a collection of a `scons` extensions scripts that could be used by a user to extend the build system of his project. Particularly, the camotics' (a project from which I unbundled cbang library per your request) build scripts uses part of these extensions directly form the cbang source tree. The directory structure created by the upstream developer has a subdir `config` with these scripts and the `camotic's` build script relies on the name `config` of this directory. These files are only needed during build of a dependant project so they are part of cbang-devel package. [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/ Thank you, Sergey
Thanks. Scons packaging guidelines are still to be done: https://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo so your efforts have really helped with this. Godot and gpsd have Scons in BuildRequires: https://src.fedoraproject.org/rpms/gpsd/blob/rawhide/f/gpsd.spec https://src.fedoraproject.org/rpms/godot/blob/rawhide/f/godot.spec but they do not have further use for the Scons build and configuration files which seems to be an approach specific to this package used because Scons is very configurable. Arch also has Cbang: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cbang and packages entire config directory. It is unclear how to manage the .pyc files. You have used the %py_byte_compile macro as described in the documentation: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/#_byte_compiling Should a different path than you have chosen be used? For example /usr/libexec/cbang/config or /usr/share/cbang/config https://docs.fedoraproject.org/en-US/packaging-guidelines/#_libexecdir https://lists.fedoraproject.org/pipermail/packaging/2015-April/010611.html https://github.com/CauldronDevelopmentLLC/jmpapi also uses Cbang, though author indicates it is not used in many projects developed by other people: https://github.com/CauldronDevelopmentLLC/cbang/issues/16
(In reply to Benson Muite from comment #13) > Thanks. Scons packaging guidelines are still to be done: > https://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo > so your efforts have really helped with this. Godot and gpsd have Scons in > BuildRequires: > https://src.fedoraproject.org/rpms/gpsd/blob/rawhide/f/gpsd.spec > https://src.fedoraproject.org/rpms/godot/blob/rawhide/f/godot.spec Actually there are 24 packages that BR Scons (less than 0.1%) in Fedora ATM. > but they do not have further use for the Scons build and configuration files > which seems to > be an approach specific to this package used because Scons is very > configurable. Yes, the upstream developer controls both the `cbang` and most (if not all) dependant projects, so he reuses as much of his work as suitable. > > Arch also has Cbang: > https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cbang > > and packages entire config directory. > > It is unclear how to manage the .pyc files. You have used the > %py_byte_compile macro as described in the documentation: > https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/ > #_byte_compiling > Should a different path than you have chosen be used? For example > /usr/libexec/cbang/config or /usr/share/cbang/config > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_libexecdir > https://lists.fedoraproject.org/pipermail/packaging/2015-April/010611.html I have no objections to move these files. Though, the `%{_libexecdir}` is more suitable than `%{_datadir}` as `config` contains `executable programs that are designed primarily to be run by other programs rather than by users`. I'll do this. Thank you, Sergey
What query did you run to find the packages that BR Scons?
(In reply to Benson Muite from comment #15) > What query did you run to find the packages that BR Scons? When I started to work on `camotics` (and `cbang`) spec, I found that it uses completely unknown for myself build system. I wanted to see how it is worked out in another packages specs so I build a list of all source packages in Fedora and then crawled all spec files from src.fedora. Then I used `grep` :) The complete list is: boswars.spec cantera.spec compat-tolua++.spec endless-sky.spec glob2.spec godot.spec gpsd.spec lcdtest.spec libffado.spec libserf.spec mapnik.spec mingw-nsis.spec minicomputer.spec mypaint.spec netpanzer.spec pingus.spec rmlint.spec sagemath.spec sar2.spec sunpinyin.spec tolua++.spec vdrift.spec wesnoth.spec zfs-fuse.spec if it makes sense.
Do you want to finish this, cannot find https://copr.fedorainfracloud.org/coprs/snmende/cbang/
Hi, Benson. Yes, I do. I have been busy last month and missed the copr build auto-deletion. I will incorporate some changes you have proposed and recreate a build in a couple of days. Thank you, Sergey.
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time, but it seems that the review is still being working out by you. If this is right, please respond to this comment clearing the NEEDINFO flag and try to reach out the submitter to proceed with the review. If you're not interested in reviewing this ticket anymore, please clear the fedora-review flag and reset the assignee, so that a new reviewer can take this ticket. Without any reply, this request will shortly be resetted.