A packaged libsmf: a C library to manage MIDI files. It's required for some packages not yet in the fedora repository like: Mamba, drumgizmo. The original github repository: https://github.com/stump/libsmf The SPEC file of the libsmf package: https://raw.githubusercontent.com/ycollet/fedora-spec/master/libsmf/libsmf.spec The src RPM file: https://download.copr.fedorainfracloud.org/results/ycollet/linuxmao/fedora-33-x86_64/01746641-libsmf/libsmf-1.3-4.fc33.src.rpm
This package is used in this package review: https://bugzilla.redhat.com/show_bug.cgi?id=1887709
>Summary: MIDI library Too generic, in my opinion. Could be mistaken for "a library of MIDI files" instead of "library for working with MIDI files". >%package static >Summary: Static library for %{name} >Requires: %{name}%{?_isa} = %{version}-%{release} The -static package should require the -devel package, since -devel contains the library's header files (.h). Also, in the repo, there is a Doxygen configuration file. Could that be used to generate documentation (which would then go in a -doc subpackage)?
Nice shot for the doxygen file. I tested, it generates an api directory with html pages. I will add these files in /usr/share/doc/libsmf/api For the Summary, I will check what have been added in the debian package. For the static part, I will add the require part. You're right, this part was missing.
The fixed spec file: https://github.com/ycollet/fedora-spec/blob/master/libsmf/libsmf.spec And the src rpm file: https://download.copr.fedorainfracloud.org/results/ycollet/linuxmao/fedora-33-x86_64/01749988-libsmf/libsmf-1.3-5.fc33.src.rpm
> The fixed spec file: > https://github.com/ycollet/fedora-spec/blob/master/libsmf/libsmf.spec When pointing to the SPEC file, try to point directly to the raw file itself like so: https://raw.githubusercontent.com/ycollet/fedora-spec/master/libsmf/libsmf.spec Artur, I hope it's okay to take it over. I saw the review request wasn't assigned to anyone. Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=55409673 > URL: https://github.com/stump/libsmf > > Source0: https://github.com/stump/%{name}/archive/%{name}-%{version}.tar.gz You can re-use URL in the Source0 field like so: Source0: %{url}/archive/%{name}-%{version}.tar.gz Also, any reason URL doesn't use %{name}? > BuildRequires: gcc gcc-c++ Split these into separate lines like the other BuildRequires. > %build > > autoreconf --force --install > %configure > %make_build > > doxygen doxygen.cfg > > %install > > %make_install > > install -m 755 -d %{buildroot}/%{_datadir}/doc/%{name}/ > cp -ra api %{buildroot}/%{_datadir}/doc/%{name}/ Please, remove the new lines after section headers. What about something like this? %build autoreconf --force --install %configure %make_build doxygen doxygen.cfg %install %make_install install -m 755 -d %{buildroot}/%{_datadir}/doc/%{name}/ cp -ra api %{buildroot}/%{_datadir}/doc/%{name}/ > %{_datadir}/man/man1/smfsh.* > %{_datadir}/doc/%{name}/api/* - Documentation should go into a -doc subpackage. - Also, make sure something owns the %{_datadir}/doc/%{name}/api/ subdir. > %files devel > %{_includedir}/* > %{_libdir}/libsmf.so > %{_libdir}/libsmf.la - This is not mandatory, but could you be slightly more specific about the packaged content inside %{_includedir}? - Also, libtool archives should not be packaged. Please, remove them at the end of the %build step. > %changelog > * Sat Nov 08 2020 Yann Collette <ycollette dot nospam at free.fr> 1.3-5 > - fix spec file Nov 8th was a Sunday. Full review below: Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - Package does not contain any libtool archives (.la) Note: libsmf-devel : /usr/lib64/libsmf.la See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#packaging-static-libraries - Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 1832960 bytes in 79 files. See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#_documentation ===== 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]: Rpath absent or only used for internal libs. [x]: Development (unversioned) .so files in -devel subpackage, if present. Generic: [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. Note: Using prebuilt packages [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". 19 files have unknown license. Detailed output of licensecheck in /home/amender/rpmbuild/SPECS/libsmf/libsmf/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [!]: Package requires other packages for directories it uses. Note: No known owner of /usr/share/doc/libsmf/api Review: Make sure this packageo owns the directory or make the -doc subpackage do it. [!]: Package must own all directories that it creates. Note: Directories without known owners: /usr/share/doc/libsmf/api [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. [x]: 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. [!]: Package complies to the Packaging Guidelines Review: Some outstanding issues mentioned earlier. [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 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]: Static libraries in -static or -devel subpackage, providing -devel if present. Note: Package has .a files: libsmf-static. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [x]: Reviewer should test that the package builds in mock. [-]: 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). [!]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in libsmf- static Review: Probably needed. [?]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [-]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [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]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: The placement of pkgconfig(.pc) files are correct. [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: [!]: Package should not use obsolete m4 macros Note: Some obsoleted macros found, see the attachment. See: https://fedorahosted.org/FedoraReview/wiki/AutoTools [!]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Arch-ed rpms have a total of 1832960 bytes in /usr/share Review: Looks like the documentation files. Should be moved to a -doc subpackage. [x]: Rpmlint is run on debuginfo package(s). Note: No rpmlint messages. [x]: Rpmlint is run on all installed packages. Note: No rpmlint messages. Rpmlint ------- Checking: libsmf-1.3-5.fc34.x86_64.rpm libsmf-devel-1.3-5.fc34.x86_64.rpm libsmf-static-1.3-5.fc34.x86_64.rpm libsmf-debuginfo-1.3-5.fc34.x86_64.rpm libsmf-debugsource-1.3-5.fc34.x86_64.rpm libsmf-1.3-5.fc33.src.rpm libsmf.x86_64: W: name-repeated-in-summary C LibSMF libsmf-devel.x86_64: W: no-documentation libsmf-static.x86_64: W: no-documentation libsmf.src: W: name-repeated-in-summary C LibSMF libsmf.src: E: specfile-error warning: bogus date in %changelog: Sat Nov 08 2020 Yann Collette <ycollette dot nospam at free.fr> 1.3-5 6 packages and 0 specfiles checked; 1 errors, 4 warnings. Rpmlint (debuginfo) ------------------- Checking: libsmf-debuginfo-1.3-5.fc34.x86_64.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. Rpmlint (installed packages) ---------------------------- (none): E: no installed packages by name libsmf-debuginfo (none): E: no installed packages by name libsmf-devel (none): E: no installed packages by name libsmf (none): E: no installed packages by name libsmf-debugsource (none): E: no installed packages by name libsmf-static 0 packages and 0 specfiles checked; 0 errors, 0 warnings. Source checksums ---------------- https://github.com/stump/libsmf/archive/libsmf-1.3.tar.gz : CHECKSUM(SHA256) this package : f6f899897f1cf07f392d869456058c36b3ea17a8887ba1672c14b41d18bb4794 CHECKSUM(SHA256) upstream package : f6f899897f1cf07f392d869456058c36b3ea17a8887ba1672c14b41d18bb4794 Requires -------- libsmf (rpmlib, GLIBC filtered): libc.so.6()(64bit) libglib-2.0.so.0()(64bit) libm.so.6()(64bit) libsmf.so.0()(64bit) rtld(GNU_HASH) libsmf-devel (rpmlib, GLIBC filtered): /usr/bin/pkg-config libsmf(x86-64) libsmf.so.0()(64bit) pkgconfig(glib-2.0) libsmf-static (rpmlib, GLIBC filtered): libsmf-devel(x86-64) libsmf-debuginfo (rpmlib, GLIBC filtered): libsmf-debugsource (rpmlib, GLIBC filtered): Provides -------- libsmf: libsmf libsmf(x86-64) libsmf.so.0()(64bit) libsmf-devel: libsmf-devel libsmf-devel(x86-64) libtool(/usr/lib64/libsmf.la) pkgconfig(smf) libsmf-static: libsmf-static libsmf-static(x86-64) libsmf-debuginfo: debuginfo(build-id) libsmf-debuginfo libsmf-debuginfo(x86-64) libsmf-debugsource: libsmf-debugsource libsmf-debugsource(x86-64)
obody seems to be interested ... So, I close the package review. Somebody else will had back this if somebody at fedora is interested.
Fair enough. Thanks for the update!
I have agreed to sponsor Yann. Andy, would you like to continue this review? If so, then I can take the sponsoring step once everybody is satisfied.
Of course! I am ready when you are :)
I'm holding off for a bit because Vasiliy may be the sponsor instead. We'll wait to see what he says. In the meantime, Yann, Andy pointed out a few more things that need to be fixed in comment 5. If you need more detail, please ask.
Oh, I forgot to mention that upstream may have some memory/resource leaks, judging by this commit: https://github.com/stump/libsmf/commit/e3d49e375310ffc71b64e242eae9095c36c97139 and this pull request: https://github.com/stump/libsmf/pull/7 It may be necessary at some point to patch those issues, since upstream appears to be inactive.
> When pointing to the SPEC file, try to point directly to the raw file itself > like so: > https://raw.githubusercontent.com/ycollet/fedora-spec/master/libsmf/libsmf. > spec Ah, yes, I forgot to click on the raw button on github ... > > Source0: https://github.com/stump/%{name}/archive/%{name}-%{version}.tar.gz > > You can re-use URL in the Source0 field like so: > Source0: %{url}/archive/%{name}-%{version}.tar.gz > Also, any reason URL doesn't use %{name}? Added %{url} > > BuildRequires: gcc gcc-c++ Splitted ... > Split these into separate lines like the other BuildRequires. Done. > - Documentation should go into a -doc subpackage. > - Also, make sure something owns the %{_datadir}/doc/%{name}/api/ subdir. Can you be a little bit more specific about "make sure somethin ..." ? I added the doc subpackage > - This is not mandatory, but could you be slightly more specific about the > packaged content inside %{_includedir}? > - Also, libtool archives should not be packaged. Please, remove them at the > end of the %build step. I fixed the %{includedir} part + I remove the la file > > %changelog > > * Sat Nov 08 2020 Yann Collette <ycollette dot nospam at free.fr> 1.3-5 > > - fix spec file > > Nov 8th was a Sunday. Date fixed
The last spec file: https://raw.githubusercontent.com/ycollet/fedora-spec/master/libsmf/libsmf.spec The corresponding src rpm file: https://download.copr.fedorainfracloud.org/results/ycollet/linuxmao/fedora-33-x86_64/01805172-libsmf/libsmf-1.3-7.fc33.src.rpm
> Source0: %{url}/archive/%{name}-%{version}.tar.gz > Patch0: libsmf-0001-fixe-various-problems.patch Add a comment above the Patch0 line explaining why the patch is needed. You mentioned a memory leak earlier. I think that should also feature in the SPEC file. Also, if the patch fixes several unrelated issues, it's perhaps better to split it into multiple patch records so that they can be addressed individually later (for instance, by upstream). > BuildRequires: gcc > BuildRequires: gcc-c++ > BuildRequires: autoconf > BuildRequires: automake > BuildRequires: libtool > BuildRequires: pkgconfig > BuildRequires: glib2-devel > BuildRequires: doxygen Since you're using make, add it as a BuildRequires as well. > Can you be a little bit more specific about "make sure somethin ..." ? > I added the doc subpackage Yes, apologies. What I meant is that currently, the api subdir is not owned properly: > %files doc > %{_datadir}/doc/%{name}/api/* The last line means that all content in the directory is owned, but not the directory itself. You have the following options: > %{_datadir}/doc/%{name}/api/ or > %dir %{_datadir}/doc/%{name}/api or (not ideal, since it's unclear whether "api" is a directory) > %{_datadir}/doc/%{name}/api The rest looks really good so I'll go ahead and approve it :).
(In reply to Andy Mender from comment #14) > > Source0: %{url}/archive/%{name}-%{version}.tar.gz > > Patch0: libsmf-0001-fixe-various-problems.patch > > Add a comment above the Patch0 line explaining why the patch is needed. You > mentioned a memory leak earlier. I think that should also feature in the > SPEC file. > Also, if the patch fixes several unrelated issues, it's perhaps better to > split it into multiple patch records so that they can be addressed > individually later (for instance, by upstream). I added all the patches from the PR (8 patches). The title of the patches are informative enough I think. > > BuildRequires: gcc > > BuildRequires: gcc-c++ > > BuildRequires: autoconf > > BuildRequires: automake > > BuildRequires: libtool > > BuildRequires: pkgconfig > > BuildRequires: glib2-devel > > BuildRequires: doxygen > > Since you're using make, add it as a BuildRequires as well. Added > > > Can you be a little bit more specific about "make sure somethin ..." ? > > I added the doc subpackage > > Yes, apologies. What I meant is that currently, the api subdir is not owned > properly: > > %files doc > > %{_datadir}/doc/%{name}/api/* > > The last line means that all content in the directory is owned, but not the > directory itself. You have the following options: > > %{_datadir}/doc/%{name}/api/ Added The spec file: https://raw.githubusercontent.com/ycollet/fedora-spec/master/libsmf/libsmf.spec The src rpm file: https://download.copr.fedorainfracloud.org/results/ycollet/linuxmao/fedora-33-x86_64/01805954-libsmf/libsmf-1.3-8.fc33.src.rpm
> I added all the patches from the PR (8 patches). The title of the patches are informative enough I think. Yup, that will do. Thanks!
What are the next steps now ?
You need to request a repo for your new package according to this section: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join#Add_Package_to_Source_Code_Management_.28SCM.29_system_and_Set_Owner But also have a look at the entire doc to make sure you've completed all the previous steps: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
Thanks for the links, I read that.
I am not a member of the packager group. I certainly need to perform some other steps before that to happen.
Why was the request closed as NOTABUG? The request should remain ASSIGNED (if the submitter is not a member of the packaging group yet) or POST to indicate that the review has been completed.