Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: https://copr-be.cloud.fedoraproject.org/results/jstanek/package-reviews/fedora-rawhide-x86_64/00868273-swaylock/swaylock.spec SRPM URL: https://copr-be.cloud.fedoraproject.org/results/jstanek/package-reviews/fedora-rawhide-x86_64/00868273-swaylock/swaylock-1.3-1.fc31.src.rpm Description: swaylock is a screen locking utility for Wayland compositors. Fedora Account System Username: jstanek
Package Review ============== Looks good to me! Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= Conflicts with the sway 0.x package, which will be updated soon. There is nothing to do about it. Note: I did not test the functionnality beyond printing the help message since I don't have a wayland environment available right now. ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [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. [-]: License file installed when any subpackage combination is installed. [-]: Package must own all directories that it creates. [x]: Package does not own files or directories owned by other packages. [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. [-]: 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. [!]: 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. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of 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. [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 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 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). [-]: Fully versioned dependency in subpackages if applicable. [?]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: 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]: 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: [x]: Rpmlint is run on debuginfo package(s). [x]: Rpmlint is run on all installed packages. [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 ------- Checking: swaylock-1.3-1.fc31.x86_64.rpm swaylock-debuginfo-1.3-1.fc31.x86_64.rpm swaylock-debugsource-1.3-1.fc31.x86_64.rpm swaylock-1.3-1.fc31.src.rpm swaylock.x86_64: W: non-conffile-in-etc /etc/pam.d/swaylock swaylock.x86_64: W: manual-page-warning /usr/share/man/man1/swaylock.1.gz 70: warning: macro `:'' not defined 4 packages and 0 specfiles checked; 0 errors, 2 warnings.
Thanks for the review! Based on the comment, I did some changes and tweaks, can I ask for re-review? Spec URL: https://copr-be.cloud.fedoraproject.org/results/jstanek/package-reviews/fedora-rawhide-x86_64/00868750-swaylock/swaylock.spec SRPM URL: https://copr-be.cloud.fedoraproject.org/results/jstanek/package-reviews/fedora-rawhide-x86_64/00868750-swaylock/swaylock-1.3-1.fc31.src.rpm > Conflicts with the sway 0.x package, which will be updated soon. There is nothing to do about it. Well, beside adding an explicit conflict with sway < 1.0 ;) Implicit conflicts should not be allowed – see [1]. On which fedoras is the sway update planned? I should probably only request stable branches for those where the swaylock and sway can be actually installed next to each other. Also, while running a scratch review for myself, I run into issue with ownership of the directories for the completion scripts -- they should also be owned by the package ([2]). Be aware that this will generate shared directory ownership warning in `fedora-review`, but that one always has false positives :) I suggest deleting the listing of packages that also share the directories and verifying that the list looks sane. [1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_splitting_packages [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_the_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function
Adding soft Blocks reference to sway-1.0 bug, in a sense it'd be good to have it as a required part of sway if we care about possible usability regression that would arise otherwise.
(In reply to Jan Staněk from comment #2) > Well, beside adding an explicit conflict with sway < 1.0 ;) Implicit > conflicts should not be allowed – see [1]. Oops, I feel a bit dumb missing this one. > On which fedoras is the sway update planned? I should probably only request > stable branches for those where the swaylock and sway can be actually > installed next to each other. I don't think it has been decided yet. Fedora 30 would be nice but the schedule might be a bit tight? Can we provide sway 1.0 as a module to provide some kind of "backports" if we miss F30? That's something to discuss with the other packagers in 1672268 [0]. > Also, while running a scratch review for myself, I run into issue with > ownership of the directories for the completion scripts -- they should also > be owned by the package ([2]). Be aware that this will generate shared > directory ownership warning in `fedora-review`, but that one always has > false positives :) I suggest deleting the listing of packages that also > share the directories and verifying that the list looks sane. I got some warnings for this (and checked a few other packages shipping completion files for shells) but missed the ownership rule for the parent directory. < %{_sysconfdir}/pam.d/%{name} --- > %config(noreplace) %{_sysconfdir}/pam.d/%{name} Fixes non-conffile-in-etc warning following the guidelines in [1]. Looks good to me. Thanks for the detailed comment, I learned a few things! I'm re-running fedora-review and will re-flag this bug once I've taken another look at the result. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1672268 [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_configuration_files
(In reply to Jan Staněk from comment #2) > [ ]: Package does not own files or directories owned by other packages. > Note: Dirs in package are owned also by: $LIST > I suggest deleting the listing of packages that also > share the directories and verifying that the list looks sane. Am I right with "ignore $LIST if it looks sane"? It looks weird since /usr/share/fish/completions and /usr/share/zsh/site-functions are owned by a few packages while half of the world own /usr/share/bash-completion/completions... My system contains many completion files for zsh and fish: ~ » ll /usr/share/bash-completion/completions | wc -l 932 ~ » ll /usr/share/fish/completions | wc -l 543 ~ » ll /usr/share/zsh/site-functions | wc -l 46 Any idea?
(In reply to Timothée Floure from comment #5) > Am I right with "ignore $LIST if it looks sane"? Yes. This automatic check always includes many false positives (looking at /.build-id). The relevant part in the guidelines (linked in my previous comment) states that if you do not hard-require the correct owner package in order to use the package being created (usually shell completions, optional plugins/integrations, etc.) AND there is no *-filesystem package to depend on, you should just own the directories in which you install the integrations. So just confirm that the $LIST does not contain anything unexpected.
One last thing: I'm not sure of the usefulness of the debugsources package. It only contains the source C and mostly overlap with the source archive. Does it have a particular role with debuggers?
I'm not really sure, but I found this: https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo TLDR version is that -debugsource used to be part of -debuginfo, but since not all debuggers need source of the code being debugged, it was split up to separate subpackages. So probably treat it as part of -debuginfo.
Oh yeah, it's fixed ever since (unless you intentionally block "recommends" dependenciews), but there were times you installed debuginfo package only to be able to make this tiny bit more reason out of a debugging session because of "dnf debuginfo-install" not installing these sources along (cf. [bug 1494628 comment 6]). Thanks for looking into packaging/reviewing this!
Makes sense, accepting this package. Thanks for the the details.
Repository requested: https://pagure.io/releng/fedora-scm-requests/issue/10483 Currently, only the rawhide/master branch is requested. I will keep an eye on sway, and request additional branches for stable Fedoras once it is clear where the sway gets updated to 1.0.
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/swaylock
Package successfully built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1234958