Spec URL: https://download.copr.fedorainfracloud.org/results/msuchy/package-review/fedora-rawhide-x86_64/07030840-blesh/blesh.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/msuchy/package-review/fedora-rawhide-x86_64/07030840-blesh/blesh-0.4.0~devel3-1.fc41.src.rpm Description: Enhanced Bash Line Editor with features like: * Syntax highlighting: Highlight command lines input by users as in fish and zsh-syntax-highlighting. Unlike the simple highlighting in zsh-syntax-highlighting, ble.sh performs syntactic analysis to enable the correct highlighting of complex structures such as nested command substitutions, multiple here documents, etc. Highlighting colors and styles are fully configurable. * Enhanced completion: Extend completion by syntax-aware completion, completion with quotes and parameter expansions in prefix texts, ambiguous candidate generation, etc. Also, menu-complete supports the selection of candidates in the menu (candidate list) by cursor keys, TAB, and S-TAB. The feature auto-complete supports the automatic suggestion of completed texts as in fish and zsh-autosuggestions (with Bash 4.0+). The feature menu-filter integrates automatic filtering of candidates into menu completion (with Bash 4.0+). There are other functionalities such as dabbrev and sabbrev like zsh abbreviations or zsh-abbr. * Vim editing mode: Enhance readline's vi editing mode available with set -o vi. Vim editing mode supports various vim modes such as char/line/block visual/select mode, replace mode, command mode, operator pending mode as well as insert mode and normal mode. Vim editing mode supports various operators, text objects, registers, keyboard macros, marks, etc. It also provides vim-surround as an option. * Other interesting features include status line, history share, right prompt, transient prompt, xterm title, etc. Fedora Account System Username: msuchy
Copr build: https://copr.fedorainfracloud.org/coprs/build/7030851 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2264719-blesh/fedora-rawhide-x86_64/07030851-blesh/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 If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Updated Spec URL: https://download.copr.fedorainfracloud.org/results/msuchy/package-review/fedora-rawhide-x86_64/07030870-blesh/blesh.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/msuchy/package-review/fedora-rawhide-x86_64/07030870-blesh/blesh-0.4.0~devel3-2.fc41.src.rpm
Created attachment 2017446 [details] The .spec file difference from Copr build 7030851 to 7030872
Copr build: https://copr.fedorainfracloud.org/coprs/build/7030872 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2264719-blesh/fedora-rawhide-x86_64/07030872-blesh/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 If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Thank you for preparing the package. I have found these 6 areas, which would deserve some discussion/improvement. === 1 Sources The package release ble-0.4.0-devel3.tar.xz is already pre-compiled scripts and not the source code. I believe for building the fedora package the original source code should be used. I understand that the ble-0.4.0-devel3.tar.xz is still readable set of scripts, but I believe long-term it would be difficult to make any patches to the package (if needed) and report them in the same shape to upstream. I mean we should be using the source code from https://github.com/akinomyoga/ble.sh/archive/refs/tags/v0.4.0-devel3.tar.gz#/blesh-%{version}.tar.gz and run the pre-processing during the build phase instead of just copying the the pre-compiled files from https://github.com/akinomyoga/ble.sh/releases/download/v0.4.0-devel3/ble-0.4.0-devel3.tar.xz. === 2 License This is bit related to the previous one - there is separate license file LICENSE.md in the source tar.gz release (or github), which could have been used in %license, but such file is not published in the pre-compiled tar.xz tarball ble-0.4.0-devel3.tar.xz. I have reported upstream that the pre-compiled tar.xz ball doesn't include the standalone license file - https://github.com/akinomyoga/ble.sh/issues/475, but still I would recommend building from source and taking the file there. === 3 Documentation RPM Package provides only brief usage guide relevant for Fedora (good). But it doesn't provide any documentation provided by upstream - README.md README-ja_JP.md doc/* . === 4 Check The check in the spec file is missing. I would recommend to add at least dummy sanity check %check bash -c "source %{buildroot}%{_libexecdir}/blesh/ble.sh" === 5 Reporting issues to upstream In the spec file I can see that you fix some file duplicities in the release by linking the files, but I have not found that issue reported to the upstream. Please have you reported that somehow? If not can you report the issue to upstream and note it in the spec file? == 6 Requirements There is one script with ksh in its shabang ... is ble.sh library meant to run also in ksh or not? BUILD/blesh-0.4.0_devel3-build/ble-0.4.0-devel3/lib/benchmark.ksh Should the ksh package one of the strong requirements (currently the build makes requirement to /usr/bin/ksh) or rather some weak dependency of Recommends perhaps ? Talking about that ... dependency to bash is not explicitly stated and is surprisingly not created same way as the /usr/bin/ksh dependency. I know bash is in most/all RedHat/Fedora Linux systems, but maybe the explicit requirement would not hurt, when we talk about functionality, which extends the working of bash. Some kind of dependency (Recommends?) should be also added to the tools used in the blesh scripts. Util - package gzip - gzip awk,gawk - awk sed - sed tput - ncurses gzip - gzip bzcat - bzip2 lzcat - xz-lzma-compat nroff,groff - groff-base date,stty,sort,readlink... - coreutils - probably not needed to be explicit about coreutils Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed ===== MUST items ===== Generic: [X]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. Note: Using prebuilt source from github [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: BSD-3-Clause AND MIT [X]: License file installed when any subpackage combination is installed. [X]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [!]: Package requires other packages for directories it uses. [X]: Package must own all directories that it creates. [X]: Package contains no bundled libraries without FPC exception. [X]: Changelog in prescribed format. [?]: Sources contain only permissible code or content. I believe the situation is on the edge. Package contains pre-processed bash scripts, which are technically still readable, but it is not the original source snapshot. [-]: Package contains desktop file if it is a GUI application. [-]: Development files must be in a -devel package [-]: Package uses nothing in %doc for runtime. [X]: Package consistently uses macros (instead of hard-coded directory names). [?]: Package is named according to the Package Naming Guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_addon_packages Package is providing another functionality to bash, so should be possibly named bash-blesh as addon package. But it sounds kinda silly and there are no other bash module packages besides the bash-argsparse, where already the upstream package is named bash-argsparse and not just argsparse. Checked also for the prior art in other distributions - this package is so far only in Arch, where the name "ble.sh" is also renamed to "blesh" for the package name. I leave this on the consideration of submitter and I tend to agree that blesh is better alternative to bash-blesh. [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. [-]: Package is not known to require an ExcludeArch tag. [X]: Package complies to the Packaging Guidelines [X]: Package installs properly. [X]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [X]: The License field must be a valid SPDX expression. [X]: Package does not own files or directories owned by other packages. [X]: Package uses either %{buildroot} or $RPM_BUILD_ROOT Note: uses %{buildroot} consistently [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. [-]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [X]: Package is named using only allowed ASCII characters. Note: upstream "ble.sh" renamed to "blesh" [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]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 2280 bytes in 1 files. [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 python3-xlrd2 [X]: Package functions as described. [X]: Latest version is packaged. Note: lates tagged release is packed, however there is 1 year of fixes on git head [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. [!]: %check is present and all tests pass. I would recommend adding at least a sanity %check of bash running " [X]: Packages should try to preserve timestamps of original installed files. [-]: 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: [X]: Rpmlint is run on all installed packages. Note: No rpmlint messages. Source checksums ---------------- srpm c8612ee612bc6b10dbfd6e85c6cbdfd7caf152a12d1f9de22ea0a9d735b3080c ble-0.4.0-devel3.tar.xz upstream https://github.com/akinomyoga/ble.sh/releases/download/v0.4.0-devel3/ble-0.4.0-devel3.tar.xz c8612ee612bc6b10dbfd6e85c6cbdfd7caf152a12d1f9de22ea0a9d735b3080c ble-0.4.0-devel3.tar.xz Requires -------- Provides -------- Rpmlint ------- $ rpmlint blesh-0.4.0~devel3-2.fc41.src.rpm blesh-0.4.0~devel3-2.fc40.noarch.rpm blesh.spec ============================================================================================== rpmlint session starts ============================================================================================= rpmlint: 2.5.0 configuration: /usr/lib/python3.12/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: 32, packages: 3 blesh.src: E: unknown-key 4e2a1f01 blesh.noarch: E: spelling-error ('zsh', '%description -l en_US zsh -> sh, ssh, ash') blesh.noarch: E: spelling-error ('autosuggestions', '%description -l en_US autosuggestions -> autosuggestion, auto suggestions, auto-suggestions') blesh.noarch: E: spelling-error ('dabbrev', '%description -l en_US dabbrev -> abbrev, d abbrev') blesh.noarch: E: spelling-error ('sabbrev', '%description -l en_US sabbrev -> abbrev, s abbrev') blesh.noarch: E: spelling-error ("readline's", "%description -l en_US readline's -> breadline's, deadline's, headline's") blesh.src: E: spelling-error ('zsh', '%description -l en_US zsh -> sh, ssh, ash') blesh.src: E: spelling-error ('autosuggestions', '%description -l en_US autosuggestions -> autosuggestion, auto suggestions, auto-suggestions') blesh.src: E: spelling-error ('dabbrev', '%description -l en_US dabbrev -> abbrev, d abbrev') blesh.src: E: spelling-error ('sabbrev', '%description -l en_US sabbrev -> abbrev, s abbrev') blesh.src: E: spelling-error ("readline's", "%description -l en_US readline's -> breadline's, deadline's, headline's") ===> spelling errors not relevant, otherwise package is clean $ scancode --license --copyright --license-references -n6 --html /tmp/scan.html ./ ===> license of BSD-3-Clause AND MIT seems to be correct
hello, please are you working on the package?
I just returned from PTO. I will address the issues in a few days.
Thank you for a thorough review. I hope I addressed all issues now. > 1) Sources I tried to use your suggestion, but the make file hard-except git checkout with submodules. So the tarball from tag does not work. Not even git-archive or git-archive-all because the Makefile does git operation in the checkout so you need .git directory too. At the end I created the tarball manually. > 2) License It is now correctly listed as %license > 3) Documentation Done. Although 'make install' leaves various files on various places, so I had to correct it at the end of %install section to comply with Fedora standards. > 4) Check I discovered that it has option --test. Added. > 5) Reporting issues to upstream The makefile is a mess. I plan to report it later to upstream case by case and provide PRs. But I did not have done it yet. > 6) Requirements ksh is only in bechmark.ksh. As a counterpart to benchmark.sh. I never run it. The /usr/bin/ksh is added by some automation. Even when I add ksh as weak deps. Should I filter it out? I added deps on bash and few other packages. Some of them as weak deps. But most of them are not needed. The code check for availability and should not fail when not available. Spec URL: https://download.copr.fedorainfracloud.org/results/msuchy/package-review/fedora-rawhide-x86_64/07921582-blesh/blesh.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/msuchy/package-review/fedora-rawhide-x86_64/07921582-blesh/blesh-0.4.0~devel3-3.fc42.src.rpm
Is there some guidelines for when we can add something to `/etc/profile.d` or not? I have a similar situation with `bash-preexec` and `atuin` and I would want the user to have a seamless experience, but at the same time there are potential security concerns.
I am not aware of any such guidelines. In the case of blesh, I would hesitate to add it to system's profile.d and affecting all users (think about e.g. university environment).
> In the case of blesh, I would hesitate to add it to system's profile.d and affecting all users (think about e.g. university environment). I had the same thought when I initially considered blesh. It seemed to have too many side-effects. `bash-preexec` seems safer in that regards since it doesn't do anything if you don't export to its interface, but these still seem that they should be hardened by a check against root user or non-interactive environment, which could be done as a wrapper, but I don't have a reference to go for. Than there's `atuin` for which I am just :shrug:, but I would probably want to export the file somewhere, at the very least so that if anything is able to scan it for vulnerabilities, it should do so. Another option could be to have the `profile.d` be installed as an optional package, but how would that be named?
I would say adding to profile.d and working out of the box is OK. It is not opening any new network service (in potentially unsafe configuration). File belongs to package, it is easily trackable who/when/how put it there. If it is marked as configuration, then somebody could choose to change it and it wont be overwritten with new package update.
Miroslave sorry I am struggling to reproduce the re-creation of the Source0 tarball. https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#:~:text=MUST:%20The%20sources "MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use sha256sum for this task as it is used by the sources file once imported into git. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this." The upstream release is 400kb, Git snapshot is cca 20MB, git-archive-all is cca 25MB, what is in your src.rpm is 125MB. That seems to be huge difference. Following the guide from the spec file I am not able to verify it is the same source. https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ If it is not possible to include the full download URL in the Source0, then it is preffered to have a prepared download script, which takes version as argument. Example in https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#when-upstream-uses-prohibited-code As bare minimum there should be repeatable instructions how to obtain the source code. https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/
ping
> The upstream release is 400kb, Git snapshot is cca 20MB, git-archive-all is cca 25MB, what is in your src.rpm is 125MB. > That seems to be huge difference. I cannot use neither git snapshot and nor git-archive-all because the upstream build scripts use git operations. And if `.git` directory is missing then the build fails. So I have to include `.git` directory of main repository and submodules. The other option is to completely rework rel-engs scripts of upstream. > As bare minimum there should be repeatable instructions how to obtain the source code. I did. These comments starting on line 11 in https://download.copr.fedorainfracloud.org/results/msuchy/package-review/fedora-rawhide-x86_64/07921582-blesh/blesh.spec > If it is not possible to include the full download URL in the Source0, then it is preferred to have a prepared download script Fair enough. I added the script as Source2. > I would say adding to profile.d and working out of the box is OK. I feel very uncomfortable about it.
Spec URL: https://download.copr.fedorainfracloud.org/results/msuchy/package-review/fedora-rawhide-x86_64/08052970-blesh/blesh.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/msuchy/package-review/fedora-rawhide-x86_64/08052970-blesh/blesh-0.4.0~devel3-4.fc42.src.rpm
Created attachment 2048126 [details] The .spec file difference from Copr build 7030872 to 8053123
Copr build: https://copr.fedorainfracloud.org/coprs/build/8053123 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2264719-blesh/fedora-rawhide-x86_64/08053123-blesh/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 If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
I looked a bit on where the git commands are used. Wouldn't it work if you had `Source2` pointing to the git submodule and mv it to the blesh source. Worst case you would have to patch out the git references also. What errors did you encountered when trying to remove thr `.git` folder?
I have tried to do this locally, and indeed it can work, I'll update a compatible version and propose changes upstream. But there is a more fundamental question, `ble.sh` supports internal updates[1]. Do we keep that functionality as-is, or do we patch it out? I haven't used `ble.sh` so I don't know how well it works, would it work even without the original git source being packaged? [1]: https://github.com/akinomyoga/ble.sh/blob/32f290df78554e22d7ff779d34f1dfec271c16df/ble.pp#L2100
Here is the promised version without the .git folder, feel free to make it more proper, I didn't handle the contrib folder that nicely. https://lecris.fedorapeople.org/reviews/blesh/blesh.spec https://lecris.fedorapeople.org/reviews/blesh/blesh-0.4.0~devel3-1.fc40.src.rpm
> But there is a more fundamental question, `ble.sh` supports internal updates[1]. Do we keep that functionality as-is, or do we patch it out? My view is that it is "not supported". I.e. if user try to active, it will fail for him with permissions error. I do not think we need to patch it out. At least for now.
Never underestimate the propensity of users to use `sudo` :D. But yeah, should be ok in this form. I'll contact upstream to see if they have some plans around it. Btw I'm also :+1: to not including it by default in `/etc/profile.d`, but I think it would be useful to have a way to make it available out-of-the-box for all users as well maybe as an optional package. We were discussing that some approach should be considered for multi-user environments, and that is probably something that will be configurable upstream in both `ble.sh` and `bash-preexec`, we just need to find a good design for those. If anyone has some experience or suggestions, probably it's worth mentioning upstream [1] [1]: https://github.com/rcaloras/bash-preexec/issues/159
Actually upstream mentioned that you can override the update mechanism [1]. I think it would be a good enhancement, but not a blocker for the review. [1]: https://github.com/akinomyoga/ble.sh/issues/511
Miroslave (as reporter) please could you decide whether I should now re-check your last SPEC or the one from Christian? Thank you
Just a small update, upstream has made quite some nice changes to simplify the packaging for the next release [1]. Not sure when they will cut a new release or what issues should be tracked for it though. [1]: https://github.com/akinomyoga/ble.sh/issues/509#issuecomment-2410238603
This is an automatic action taken by review-stats script. The ticket submitter failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we consider this ticket as DEADREVIEW and proceed to close it.