Hide Forgot
Spec URL: https://troycurtisjr.fedorapeople.org/rapidfuzz-cpp/rapidfuzz-cpp.spec SRPM URL: https://troycurtisjr.fedorapeople.org/rapidfuzz-cpp/rapidfuzz-cpp-1.10.4-1.fc38.src.rpm Description: RapidFuzz is a fast string matching library for Python and C++, which is using the string similarity calculations from FuzzyWuzzy. However there are two aspects that set RapidFuzz apart from FuzzyWuzzy: 1. It is MIT licensed so it can be used whichever License you might want to choose for your project, while you're forced to adopt the GPL license when using FuzzyWuzzy 2. It is mostly written in C++ and on top of this comes with a lot of Algorithmic improvements to make string matching even faster, while still providing the same results. The Python library is available in the python-rapidfuzz package. Fedora Account System Username: troycurtisjr
This package built on koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=95644537
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - Dist tag is present. ===== 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]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. 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", "MIT License", "*No copyright* MIT License". 39 files have unknown license. Detailed output of licensecheck in /home/fedora-packaging/2156237-rapidfuzz-cpp/licensecheck.txt [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. [-]: 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 20480 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]: 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 ===== 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). [?]: 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. [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]: 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]: 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: [!]: Spec file according to URL is the same as in SRPM. Note: Spec file as given by url is not the same as in SRPM (see attached diff). See: (this test has no URL) [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. Rpmlint ------- Checking: rapidfuzz-cpp-devel-1.10.4-1.fc38.aarch64.rpm rapidfuzz-cpp-1.10.4-1.fc38.src.rpm ============================ 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 rpmlintrc: [PosixPath('/tmp/tmpmcvyel5y')] checks: 31, packages: 2 rapidfuzz-cpp.src: W: strange-permission rapidfuzz-cpp.spec 600 rapidfuzz-cpp-devel.aarch64: W: only-non-binary-in-usr-lib 2 packages and 0 specfiles checked; 0 errors, 2 warnings, 0 badness; has taken 0.3 s 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: 1 rapidfuzz-cpp-devel.aarch64: W: only-non-binary-in-usr-lib 1 packages and 0 specfiles checked; 0 errors, 1 warnings, 0 badness; has taken 0.1 s Source checksums ---------------- https://github.com/maxbachmann/rapidfuzz-cpp/archive/v1.10.4/rapidfuzz-cpp-1.10.4.tar.gz : CHECKSUM(SHA256) this package : 84a1ea8759aaa5bc8587c26504421d6fd34ad2a8dc74bf469b0cc3cc6758e17a CHECKSUM(SHA256) upstream package : 84a1ea8759aaa5bc8587c26504421d6fd34ad2a8dc74bf469b0cc3cc6758e17a Requires -------- rapidfuzz-cpp-devel (rpmlib, GLIBC filtered): cmake-filesystem(aarch-64) Provides -------- rapidfuzz-cpp-devel: cmake(rapidfuzz) rapidfuzz-cpp-devel rapidfuzz-cpp-devel(aarch-64) rapidfuzz-cpp-static Diff spec file in url and in SRPM --------------------------------- --- /home/fedora/2156237-rapidfuzz-cpp/srpm/rapidfuzz-cpp.spec 2022-12-27 07:14:07.903233261 +0000 +++ /home/fedora/2156237-rapidfuzz-cpp/srpm-unpacked/rapidfuzz-cpp.spec 2022-12-25 16:59:48.000000000 +0000 @@ -1,2 +1,12 @@ +## START: Set by rpmautospec +## (rpmautospec version 0.3.1) +## RPMAUTOSPEC: autorelease, autochangelog +%define autorelease(e:s:pb:n) %{?-p:0.}%{lua: + release_number = 1; + base_release_number = tonumber(rpm.expand("%{?-b*}%{!?-b:1}")); + print(release_number + base_release_number - 1); +}%{?-e:.%{-e*}}%{?-s:.%{-s*}}%{!?-n:%{?dist}} +## END: Set by rpmautospec + # Header only library %global debug_package %{nil} @@ -66,3 +76,4 @@ %changelog -%autochangelog +* Sun Dec 25 2022 Troy Curtis Jr <troy> - 1.10.4-1 +- Initial spec file. Generated by fedora-review 0.9.0 (6761b6c) last change: 2022-08-23 Command line :/usr/bin/fedora-review -b 2156237 Buildroot used: fedora-rawhide-aarch64 Active plugins: C/C++, Shell-api, Generic Disabled plugins: PHP, fonts, Perl, Java, R, Python, SugarActivity, Haskell, Ocaml Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH Comments: a) Might it be possible to do a smoke test? Perhaps compile and run the provided example? b) Perhaps the provided example could also be packaged in the documentation? c) May also package changelog in the documentation d) It would be helpful to indicate filetypes that are installed, so perhaps use %{_includedir}/rapidfuzz/*.hpp %{_includedir}/rapidfuzz/*.impl %{_includedir}/rapidfuzz/distance/*.hpp %{_includedir}/rapidfuzz/details/*.hpp %{_libdir}/cmake/rapidfuzz/*.cmake e) need dist in the spec file Release: 1%{?dist}
(In reply to Benson Muite from comment #2) > > Comments: > a) Might it be possible to do a smoke test? Perhaps compile and run the > provided example? The example is pretty useless, even as a smoketest IMO, however I figured out that the fuzzers test multiple APIs using clang's fuzzer capabilities. So I've enabled the fuzzers and run a simple loop on the resulting executables. Since this is a header only library anyway, there is no impact/change to the runtime package. > b) Perhaps the provided example could also be packaged in the documentation? I ended up building the doxygen html docs and including those. The example isn't particularly meaningful. > c) May also package changelog in the documentation Good idea! Included. > d) It would be helpful to indicate filetypes that are installed, so perhaps > use > %{_includedir}/rapidfuzz/*.hpp > %{_includedir}/rapidfuzz/*.impl > %{_includedir}/rapidfuzz/distance/*.hpp > %{_includedir}/rapidfuzz/details/*.hpp > %{_libdir}/cmake/rapidfuzz/*.cmake This seems unusual and a bit redundant. This package owns the directories (and must own them), and including the directory automatically pulls in the contained files. Some workarounds would have to be employed to own the dir, but not include the files, and then manually include the files contained by the directory (using the %dir macro presumably, though I haven't actually tested it). All to basically communicate that "header files are included from the include path and cmake files are included from the cmake path". Since these aren't shared directories, and there isn't a SOVERSION unexpected bump type of situation, I don't think using the multiple globs improves the specfile in this case. > e) need dist in the spec file > Release: 1%{?dist} This spec file is using the rpmautospec tooling, %autorelease takes care of this automatically (even though fedora-review hasn't been "taught" about it yet). This can be confirmed from the srpm itself: ❯ rpm -q --info --changelog ./rapidfuzz-cpp-1.10.4-3.fc38.src.rpm Name : rapidfuzz-cpp Version : 1.10.4 Release : 3.fc38 Architecture: x86_64 Install Date: (not installed) Group : Unspecified Size : 287061 License : MIT Signature : (none) Source RPM : (none) Build Date : Sat 31 Dec 2022 10:47:49 AM EST Build Host : arafel URL : https://github.com/maxbachmann/rapidfuzz-cpp Summary : A fast string matching header-only library for C++ Description : RapidFuzz is a fast string matching library for Python and C++, which is using the string similarity calculations from FuzzyWuzzy. However there are two aspects that set RapidFuzz apart from FuzzyWuzzy: 1. It is MIT licensed so it can be used whichever License you might want to choose for your project, while you're forced to adopt the GPL license when using FuzzyWuzzy 2. It is mostly written in C++ and on top of this comes with a lot of Algorithmic improvements to make string matching even faster, while still providing the same results. This is the C++ component of RapidFuzz, the Python library is available in the python-rapidfuzz package. * Sat Dec 31 2022 Troy Curtis Jr <troy> - 1.10.4-3 - Add doxygen API docs and CHANGELOG as documentation. * Sat Dec 31 2022 Troy Curtis Jr <troy> - 1.10.4-2 - Use clang to build the fuzzers to use as a package test. * Sun Dec 25 2022 Troy Curtis Jr <troy> - 1.10.4-1 - Initial spec file. Updated spec and srpm available at: https://troycurtisjr.fedorapeople.org/rapidfuzz-cpp/rapidfuzz-cpp.spec https://troycurtisjr.fedorapeople.org/rapidfuzz-cpp/rapidfuzz-cpp-1.10.4-3.fc38.src.rpm
Build fails on PowerPC: https://copr.fedorainfracloud.org/coprs/fed500/rapidfuzz-cpp/build/5193301/
A new year and a new build! It turns out the ppc64le clang doesn't have the required fuzzer library, so I had to disable that test on the ppc64le arch. Additionally, I had to trace down a semi-random failure on i686, which actually turned into an upstream PR: https://github.com/maxbachmann/rapidfuzz-cpp/pull/99 This time I actually tested the build on all the archs: https://copr.fedorainfracloud.org/coprs/troycurtisjr/python-Levenshtein-update/build/5203538/ New spec and srpm available: https://troycurtisjr.fedorapeople.org/rapidfuzz-cpp/rapidfuzz-cpp.spec https://troycurtisjr.fedorapeople.org/rapidfuzz-cpp/rapidfuzz-cpp-1.10.4-7.fc38.src.rpm
Copr build: https://copr.fedorainfracloud.org/coprs/build/5203558 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/frostyx/fedora-review-2156237-rapidfuzz-cpp/fedora-rawhide-x86_64/05203558-rapidfuzz-cpp/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service
Review template indicates javascript file duplicates.
These are small auto-generated files from doxygen, and apparently they are only "almost duplicate": troycurtisjr@arafel:.../share/doc/rapidfuzz-cpp-devel/html/search🔒 ❌1 ❯ diff all_0.js pages_0.js 3c3 < ['bibliography_0',['Bibliography',['../citelist.html',1,'']]] --- > ['bibliography_23',['Bibliography',['../citelist.html',1,'']]] troycurtisjr@arafel:.../share/doc/rapidfuzz-cpp-devel/html/search🔒 ❌1 ❯ diff groups_0.js all_1.js 3c3 < ['fuzz_22',['Fuzz',['../group__Fuzz.html',1,'']]] --- > ['fuzz_1',['Fuzz',['../group__Fuzz.html',1,'']]] troycurtisjr@arafel:.../share/doc/rapidfuzz-cpp-devel/html/search🔒 ❌1 ❯ diff all_3.js functions_1.js 3c3 < ['qratio_6',['QRatio',['../group__Fuzz.html#gacdca33b08c5937824b385db55fd54a2e',1,'rapidfuzz::fuzz']]] --- > ['qratio_16',['QRatio',['../group__Fuzz.html#gacdca33b08c5937824b385db55fd54a2e',1,'rapidfuzz::fuzz']]] troycurtisjr@arafel:.../share/doc/rapidfuzz-cpp-devel/html/search🔒 ❌1 ❯ diff functions_0.js all_2.js 3,6c3,6 < ['partial_5fratio_12',['partial_ratio',['../group__Fuzz.html#ga3edd989a6f37b2b642c7574285f4af4c',1,'rapidfuzz::fuzz']]], < ['partial_5ftoken_5fratio_13',['partial_token_ratio',['../group__Fuzz.html#gaef2447fac84ea8f23ce4803bf9284a62',1,'rapidfuzz::fuzz']]], < ['partial_5ftoken_5fset_5fratio_14',['partial_token_set_ratio',['../group__Fuzz.html#ga949f8ab6b568d0ec5ea5d245fb62a1cf',1,'rapidfuzz::fuzz']]], < ['partial_5ftoken_5fsort_5fratio_15',['partial_token_sort_ratio',['../group__Fuzz.html#ga871db1dc809604cb302cfde6b2d55f10',1,'rapidfuzz::fuzz']]] --- > ['partial_5fratio_2',['partial_ratio',['../group__Fuzz.html#ga3edd989a6f37b2b642c7574285f4af4c',1,'rapidfuzz::fuzz']]], > ['partial_5ftoken_5fratio_3',['partial_token_ratio',['../group__Fuzz.html#gaef2447fac84ea8f23ce4803bf9284a62',1,'rapidfuzz::fuzz']]], > ['partial_5ftoken_5fset_5fratio_4',['partial_token_set_ratio',['../group__Fuzz.html#ga949f8ab6b568d0ec5ea5d245fb62a1cf',1,'rapidfuzz::fuzz']]], > ['partial_5ftoken_5fsort_5fratio_5',['partial_token_sort_ratio',['../group__Fuzz.html#ga871db1dc809604cb302cfde6b2d55f10',1,'rapidfuzz::fuzz']]] They are all tiny though: ❯ ll *.js .rw-r--r--. root root 85 B Sun Jan 8 16:18:13 2023 all_0.js .rw-r--r--. root root 72 B Sun Jan 8 16:18:13 2023 all_1.js .rw-r--r--. root root 572 B Sun Jan 8 16:18:13 2023 all_2.js .rw-r--r--. root root 126 B Sun Jan 8 16:18:13 2023 all_3.js .rw-r--r--. root root 124 B Sun Jan 8 16:18:13 2023 all_4.js .rw-r--r--. root root 397 B Sun Jan 8 16:18:13 2023 all_5.js .rw-r--r--. root root 127 B Sun Jan 8 16:18:13 2023 all_6.js .rw-r--r--. root root 576 B Sun Jan 8 16:18:13 2023 functions_0.js .rw-r--r--. root root 127 B Sun Jan 8 16:18:13 2023 functions_1.js .rw-r--r--. root root 125 B Sun Jan 8 16:18:13 2023 functions_2.js .rw-r--r--. root root 399 B Sun Jan 8 16:18:13 2023 functions_3.js .rw-r--r--. root root 127 B Sun Jan 8 16:18:13 2023 functions_4.js .rw-r--r--. root root 73 B Sun Jan 8 16:18:13 2023 groups_0.js .rw-r--r--. root root 86 B Sun Jan 8 16:18:13 2023 pages_0.js So I don't think there is (or really can be since they aren't actually duplicate) any action to take for them.
Thanks. Package bundles jquery in the documentation. This is already packaged: https://packages.fedoraproject.org/pkgs/js-jquery/js-jquery/ Can the Fedora package be used instead? Can you also generate man page output? Content below can be appended to the Doxyfile: #--------------------------------------------------------------------------- # Configuration options related to the MAN output #--------------------------------------------------------------------------- GENERATE_MAN = YES MAN_LINKS = YES
(In reply to Benson Muite from comment #9) > Thanks. Package bundles jquery in the documentation. This is already > packaged: > https://packages.fedoraproject.org/pkgs/js-jquery/js-jquery/ > Can the Fedora package be used instead? Not really. Also, this jquery is not provided by rapidfuzz-cpp in any case. It is actually generated by Fedora's doxygen: troycurtisjr@arafel:.../rapidfuzz-cpp-1.10.4 ❯ find -name jquery.js troycurtisjr@arafel:.../rapidfuzz-cpp-1.10.4 ❯ doxygen &> /dev/null troycurtisjr@arafel:.../rapidfuzz-cpp-1.10.4 ❯ find -name jquery.js ./doxygen/html/jquery.js > > Can you also generate man page output? Content below can be appended to the > Doxyfile: > > #--------------------------------------------------------------------------- > # Configuration options related to the MAN output > #--------------------------------------------------------------------------- > > GENERATE_MAN = YES > > MAN_LINKS = YES I'm not sure how useful the man pages will be for this project, but it was pretty easy to include, so I did. I didn't use MAN_LINKS however, as it produces link manpages which aren't named specifically for this package, including things like "ratio.3". I also had to tweak the configured group so that the manpage had a name that might actually be looked for. The formatting/content of the page is much better than I would have thought, so maybe it will be useful to someone. Updated spec/srpm: https://troycurtisjr.fedorapeople.org/rapidfuzz-cpp/rapidfuzz-cpp.spec https://troycurtisjr.fedorapeople.org/rapidfuzz-cpp/rapidfuzz-cpp-1.10.4-8.fc38.src.rpm
For bundled libraries and javascript see: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling https://docs.fedoraproject.org/en-US/packaging-guidelines/JavaScript/
(In reply to Benson Muite from comment #11) > For bundled libraries and javascript see: > https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling I think this statement really helps to hint why I don't think it applies in this situation: All packages whose upstreams allow them to be built against system libraries MUST be built against system libraries. In this case, bundled libraries (and/or their source code) MUST be explicitly deleted during %prep. Build scripts may need to be patched to deal with this situation. Whenever possible, the patch should conditionalize the use of the bundled libraries, so that the patch can be sent upstream for consideration. There is no jquery to delete in the source, no builds to patch to use system libraries, or upstream change to use system libraries. Instead, the package already *is* using system libraries. It provides no jquery, it uses the jquery provided by the Fedora packaged doxygen. Calling this bundled seems more akin to saying libc++ template code is bundled into a compiled C++ application. Also, looking across at other examples as expected the jquery files for doxygen are present in other package already present in my system. Some examples after a quick look, flac-devel, opus-devel, alsa-lib-devel, mpg-123-devel, and more. > https://docs.fedoraproject.org/en-US/packaging-guidelines/JavaScript/ I don't believe this applies in this case, those guidelines even say "Please note that this section really only applies to JavaScript libraries intended for use on the web." This is not targeted at the web. It seems pretty clear to me that this does not constitute a bundled library, and I'm not even sure how or what I would change to make it not bundled as it already pulls the jquery present in the doxygen system package. However, if you still think there is uncertainty, we can definitely bring it up on the devel list to seek clarity and guidance. Let me know what you think needs to happen in order to make you comfortable with the package.
Prompted by my own mention of the devel list, I searched the archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MFGITTEK2RHDQGUSKPXER5PLQ2MCTJ2K/#T5M5P2ZDSOVLZPWZFX7G44YRAYH26KTF https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/thread/LLUAURXZVADATHK65HBPPBHKF4EM4UC3/ And in fact the package [1] that prompted one of the postings, the requestor determined the requirement were a bit unclear and that the burden would be too onerous for a nice to have. I think from the discussion on the mailing list it is apparent that it is not in fact as clear cut as I was thinking. Consider no clear guidance, which is reasonable to follow, I will just drop the html docs all together. The man page is reasonably useful for this small package, and doesn't run afoul of any of the issues, so I will continue to package it.
I forgot to include the link to my [1] footnote in the last message, here it is: https://bugzilla.redhat.com/show_bug.cgi?id=2006555 I've updated the spec & srpm to drop the doxygen generated html docs: https://troycurtisjr.fedorapeople.org/rapidfuzz-cpp/rapidfuzz-cpp.spec https://troycurtisjr.fedorapeople.org/rapidfuzz-cpp/rapidfuzz-cpp-1.10.4-9.fc38.src.rpm Copr build: https://copr.fedorainfracloud.org/coprs/troycurtisjr/python-Levenshtein-update/build/5219189/
Copr build: https://copr.fedorainfracloud.org/coprs/build/5219297 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2156237-rapidfuzz-cpp/fedora-rawhide-x86_64/05219297-rapidfuzz-cpp/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service
Thanks. Javascript in HTML documentation is contentious and different approaches are in packages available in Fedora. It seems ok for me, at present with man pages, though it maybe good to make some progress resolving this issue. Is it reasonable to remove jquery after the install step and place a symlink to /usr/share/web-assets/jquery/latest/jquery.js ? There seems to be one other bundled library in doxygen https://github.com/doxygen/doxygen/blob/master/templates/html/svgpan.js though this is not used in the generated documentation for rapidfuzz-cpp There are similar issues for other html documentation generation systems. Maybe one could come up with reasonable guidelines to add to Fedora packaging documentation for doxygen? It seems fine for me at this point, but if you want to add html documentation with symlinked jquery.js this would be fine as well. Personally, would advocate for html docs to be in separate docs packages since this allows easy opt out of other software that is often bundled, but upto you on this if you want to ship html documentation.
(In reply to Benson Muite from comment #16) > There are similar issues for other html documentation generation systems. > Maybe one could come up with reasonable guidelines to add to Fedora > packaging documentation for doxygen? Yeah this would be nice. > It seems fine for me at this point, but if you want to add html > documentation with symlinked jquery.js this would be fine as well. > Personally, would advocate for html docs to be in separate docs packages > since this allows easy opt out of other software that is often bundled, but > upto you on this if you want to ship html documentation. Unfortunately, this isn't possible. Despite the name jquery.js, there are multiple different packages included in the same file: /*! jQuery v3.4.1 | (c) JS Foundation and other contributors | jquery.org/license */ ... /*! jQuery UI - v1.12.1 - 2019-01-27 ... * http://jqueryui.com * Includes: widget.js, position.js, data.js, disable-selection.js,... * Copyright jQuery Foundation and other contributors; Licensed MIT */ ... /*! PowerTip v1.3.1 (2018-04-15) https://stevenbenner.github.io/jquery-powertip/ Copyright (c) 2018 Steven Benner (http://stevenbenner.com/). Released under MIT license. https://raw.github.com/stevenbenner/jquery-powertip/master/LICENSE.txt */ * jQuery UI Touch Punch 0.2.3 * /*! SmartMenus jQuery Plugin - v1.1.0 - September 17, 2017 * http://www.smartmenus.org/
Thanks. Approved. Started writeup for packaging guidelines on documentation: https://pagure.io/packaging-committee/pull-request/1244 Suggestions and improvements would be appreciated.
The Pagure repository was created at https://src.fedoraproject.org/rpms/rapidfuzz-cpp
FEDORA-2023-891714b2f8 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-891714b2f8
FEDORA-2023-b76d241a3c has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-b76d241a3c
FEDORA-2023-891714b2f8 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-891714b2f8 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-891714b2f8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-b76d241a3c has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-b76d241a3c \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-b76d241a3c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-891714b2f8 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-b76d241a3c has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.