Hi Orion, We followed your steps and below are our comment. Based on our comments, please let us know if we can go ahead with submitting a review for DMTCP or correct some things below first: A) The following is the original header from fedora-review command for DMTCP: Generated by fedora-review 0.7.4 (54fa030) last change: 2019-12-07 Command line :/usr/bin/fedora-review --rpm-spec -n rpmbuild/SRPMS/dmtcp-2.6.1~rc1-0.1.fc31.src.rpm Buildroot used: fedora-rawhide-x86_64 Active plugins: C/C++, Generic, Shell-api Disabled plugins: SugarActivity, Perl, fonts, Ocaml, Haskell, R, Python, Java, PHP Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH B) As you might already know DMTCP is unusual in that it sits both high and low on the software stack, which could be causing some of the reported aspects in the fedora-review. The DMTCP executables are fairly standard, but it operates on arbitrary target applications. It acts on those applications by preloading libraries specific to the DMTCP package, and also interposing on many of the calls from the target application to LibC and POSIX. We feel some of the results back from fedora-review might not be applicable to DMTCP, and we expanded on each as follows: ======================================== 1. Unversioned so-files -------------------- dmtcp: /usr/lib64/dmtcp/libdmtcp.so [ and many more] ==== This package uses these bundled libraries. It will requier an FPC exception. a. Rationale: These libraries are linked only into the DMTCP executables, and are never shared with other pacakges. b. When transparently launching a user's executable for checkpoitning, the syntax will be something like: dmtcp_launch a.out ... 'dmtcp_launch' will set LD_PRELOAD to be a library search path including all of the above bundled DMTCP libraries. 'dmtcp_launch' will then exec into the 'a.out' user application, which will inherit the LC_PRELOAD. 2. Rpmlint ------- Checking: dmtcp-2.6.1~rc1-0.1.fc32.x86_64.rpm dmtcp-devel-2.6.1~rc1-0.1.fc32.x86_64.rpm dmtcp-debuginfo-2.6.1~rc1-0.1.fc32.x86_64.rpm dmtcp-debugsource-2.6.1~rc1-0.1.fc32.x86_64.rpm dmtcp-2.6.1~rc1-0.1.fc32.src.rpm dmtcp.x86_64: W: spelling-error %description -l en_US checkpointing -> check pointing, check-pointing, checkpoint dmtcp.x86_64: E: statically-linked-binary /usr/bin/mtcp_restart dmtcp.x86_64: E: shared-lib-without-dependency-information /usr/lib64/dmtcp/libdmtcp_alloc.so dmtcp.x86_64: E: missing-call-to-setgroups-before-setuid /usr/lib64/dmtcp/libdmtcp_pid.so dmtcp-devel.x86_64: W: no-documentation dmtcp.src: W: spelling-error %description -l en_US checkpointing -> check pointing, check-pointing, checkpoint 5 packages and 0 specfiles checked; 3 errors, 3 warnings. ==== a. spelling-error %description ... : 'checkpoint' is also a verb. The English is correct. b. statically-linked-binary /usr/bin/mtcp_restart This is requeited, and will need an FPC exception. 'mtcp_restart' is a position-independent statically linked executable. This is needed at the time of restart. Internally, something like: mtcp_restart --hole-in-memory [ADDRESS] ckpt_a.out_*.dmtcp is being executed. The 'mtcp_restart' code must relocate itself to start at ADDRESS, and it must then jump to the entry point of the new location. In the second phase, it then restores all memory regions in 'ckpt_a.out_*.dmtcp', with the guarantee that the memory regions will not have an address conflict with ADDRESs. In order for 'mtcp_restart' to relocate itself, this is much simpler and easier with a traditional statically linked executable (just text/data/stack). c. dmtcp.x86_64: E: shared-lib-without-dependency-information /usr/lib64/dmtcp/libdmtcp_alloc.so I Probably this occurs ecause 'libdmtcp_alloc.so' is included in the LAD_PRELOAD described above. However, libdmtcp_alloc.so is never linked with the DTMTCP executables, since it is not needed in that context. ] d dmtcp.x86_64: E: missing-call-to-setgroups-before-setuid /usr/lib64/dmtcp/libdmtcp_pid.so DMTCP provides _real_pid() in src/plugin/pid/syscalls_real.c . This calls setuid() in libc.so It doesn't seem to be called at all by the rest of DMTCP. It's there in case an end-user application adds a wrapper function around 'setuid()'. We don't do that for 'getgroups()' or 'setgroups()' right now. We could add the '_real_' version of those functions, if you like. e. dmtcp-devel.x86_64: W: no-documentation [ The DMTCP web site is the best documentation for those who wish to develop new code or new plugins for DMTCP. ] f. dmtcp.src: W: spelling-error %description -l en_US checkpointing -> ... [ As stated above, 'checkpoint' is also a verb. The English is correct. 3. Rpmlint (installed packages) perl ... ============================= We never use 'perl' ourselves. Rpmlint caught this only because one of our tests under '%check' involves checkpointing a 'perl' process. Hopefully, this is fine. But if desired, we could remove our test of 'perl' for the Fedora package. 4. Rpmlint (installed packages) dmtcp-debugsource.x86_64: W: invalid-url URL: http://dmtcp.sourceforge.net dmtcp-devel.x86_64: W: invalid-url URL: http://dmtcp.sourceforge.net dmtcp-devel.x86_64: W: no-documentation dmtcp-debuginfo.x86_64: W: invalid-url URL: http://dmtcp.sourceforge.net [ I don't understand the warning about invalid-url. The URL is a valid URL on the public Web. ] [ no-documentation for dmtcp-devel: The best documentation for developers is the DMTCP web site. ] 5. Unversioned so-files -------------------- dmtcp: /usr/lib64/dmtcp/libdmtcp.so [ and many more libraries ] As explained above, this needs an FPC Exception, Rationale: a. These libraries are linked only into the DMTCP executables, and are never shared with other pacakges. b. When transparently launching a user's executable for checkpoitning, these libraries appears in LD_PRELOAD path before exec'ing into user executable. In both these cases, these are bundled libraries that are private to the DMTCP library. There is no nee3d for versioning, since there is no sharing of these libraries with executables outside of the dmtcp package. The version of the library changes implicitly every time we move to a new dmtcp release, since the bundled libraries are recompiled from the newer DMTCP source. We also attached the review.txt that was the output of the fedora-review. Please let us know if the next step is the submission for review or otherwise based on your suggestion. Thank you, Paul