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

Sergey sergey@mende.spb.ru changed:

What |Removed |Added ---------------------------------------------------------------------------- Blocks| |2126323, 177841 | |(FE-NEEDSPONSOR)

Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=177841 [Bug 177841] Tracker: Review requests from new Fedora packagers who need a sponsor https://bugzilla.redhat.com/show_bug.cgi?id=2126323 [Bug 2126323] Review Request: camotics - CAMotics is an Open-Source software which can simulate 3-axis NC machining.

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

Sergey sergey@mende.spb.ru changed:

What |Removed |Added ---------------------------------------------------------------------------- Comment|0 |updated

--- Comment #0 has been edited ---

Spec: https://download.copr.fedorainfracloud.org/results/snmende/cbang/fedora-rawh... SRPM: https://download.copr.fedorainfracloud.org/results/snmende/cbang/fedora-rawh... 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/4881562/

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

Benson Muite benson_muite@emailplus.org changed:

What |Removed |Added ---------------------------------------------------------------------------- Blocks| |505154 (FE-SCITECH) Assignee|nobody@fedoraproject.org |benson_muite@emailplus.org Doc Type|--- |If docs needed, set a value Flags| |fedora-review?

--- Comment #2 from Benson Muite benson_muite@emailplus.org --- 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.ta... : 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.

Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=505154 [Bug 505154] Tracker: Review Requests for Science and Technology related packages

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

--- Comment #4 from Sergey sergey@mende.spb.ru --- (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

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

--- Comment #6 from Benson Muite benson_muite@emailplus.org --- 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

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

--- Comment #8 from Sergey sergey@mende.spb.ru --- (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

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

--- Comment #10 from Benson Muite benson_muite@emailplus.org --- ELN is not critical. Good to know the reason for failure though. Thanks.

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

--- Comment #12 from Sergey sergey@mende.spb.ru --- (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

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

--- Comment #14 from Sergey sergey@mende.spb.ru --- (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

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

--- Comment #16 from Sergey sergey@mende.spb.ru --- (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.

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

Sergey sergey@mende.spb.ru changed:

What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(sergey@mende.spb. | |ru) |

--- Comment #18 from Sergey sergey@mende.spb.ru --- 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.

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

Benson Muite benson_muite@emailplus.org changed:

What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(benson_muite@emai | |lplus.org) |