Spec URL: https://fuller.fedorapeople.org/usbrelay.spec SRPM URL: https://fuller.fedorapeople.org/usbrelay-1.0.1-1.fc36.src.rpm Description: USB-connected electrical relay control, based on hidapi Fedora Account System Username: fuller
Updated: Spec URL: https://fuller.fedorapeople.org/usbrelay.spec SRPM URL: https://fuller.fedorapeople.org/usbrelay-1.1-1.fc37.src.rpm Description: USB-connected electrical relay control, based on hidapi Fedora Account System Username: fuller
I'll review this in exchange for #2135046 gprconfig-kb.
The bug number did not become a link. gprconfig-kb is here: https://bugzilla.redhat.com/show_bug.cgi?id=2135046
All %pre %preun %post %postun macros must have the appropriate package name, otherwise they will be omitted and will never be executed. You can view the scripts using the rpm -qp --scripts package_name.rpm command e.g. it should be something like this: %post -n %{name}-mqtt
Well, there are quite a few things to fix in this package. 1: The source URL is wrong. 404: Not Found. 2: The name "usbrelay-common" suggests a package that isn't useful by itself, but contains files that other packages need. The summary reinforces this impression. Users are likely to get the impression that there are interfaces for C, Python and MQTT but no command line interface. I think it would be better to call this subpackage just "usbrelay" (making it the main package), but it should at least be made clearer that it contains a command line tool. The summary could say something like "a library and command line tool for controlling USB-connected relays". 3: In the license field, SPDX syntax is now required for new packages. "GPLv2" is the old syntax. 4: GPL version 2 only is also wrong for the C parts. All the C files say "any later version", which is GPL-2.0-or-later in SPDX. 5: What license applies to the Python parts is unclear. The Python files themselves don't say. For the daemon it looks like GPL-2.0-only, because LICENSE.md presumably applies and nothing says "any later version" for usbrelayd. The file METADATA in python3-usbrelay seems to say GPL-2.0-only, but that's contradicted by libusbrelay_py.c which says "any later version". METADATA also disagrees with the file LICENSE in the same directory, which looks like MIT. I can't tell what code the MIT license applies to. And why is that file not in /usr/share/licenses? Please work with upstream to get this licensing mess sorted out. 6: The dependency on Git seems superfluous. I don't see Git invoked in the build log. 7: The explicit dependency on hidapi (not -devel) seems superfluous. The automatic soname dependency should suffice. If there is a reason for the explicit dependency, then it should be explained in a comment. 8: usbrelay-devel should require %{name}-common%{_isa} = %{version}-%{release}. 9: Is there a good reason why you don't use %{make_install}? The makefile looks like it supports DESTDIR correctly. 10: Several files are incorrectly marked as executable. From the build log: *** WARNING: ./usr/lib64/python3.11/site-packages/usbrelay/usbrelay_test.py is executable but has no shebang, removing executable bit *** WARNING: ./usr/lib/udev/rules.d/50-usbrelay.rules is executable but has no shebang, removing executable bit *** WARNING: ./usr/lib/systemd/system/usbrelayd.service is executable but has no shebang, removing executable bit *** WARNING: ./usr/include/libusbrelay.h is executable but has no shebang, removing executable bit *** WARNING: ./etc/usbrelayd.conf is executable but has no shebang, removing executable bit From RPMlint: usbrelay-mqtt.x86_64: W: spurious-executable-perm /usr/share/man/man8/usbrelayd.8.gz usbrelay-common.x86_64: W: spurious-executable-perm /usr/share/man/man1/usbrelay.1.gz Use cp instead of install, or pass --mode to install. 11: File timestamps should be preserved. Pass --preserve-timestamps to install, or use cp --preserve=timestamps. 12: The flags in py3_shebang_flags are missing from usbrelayd. It seems they're added automatically to programs in /usr/bin but not in /usr/sbin. Maybe work around it with py3_shebang_fix? 13: The comment "Create and empty key file and pid file to be marked as a ghost file below." confuses me. I see the pid file but what is the key file? If the sentence mentions two files, then it should be rephrased as plural. If it's about a single file, then the first "and" should be "an". 14: As Paweł noted, the scriptlets must be assigned to the correct subpackages. 15: No package owns the directory /usr/lib64/python3.11/site-packages/usbrelay. 16: usbrelay-common must require systemd-udev because it places a file in /usr/lib/udev/rules.d. (If it can function in a stripped-down system witout Udev installed, then it must instead own /usr/lib/udev and /usr/lib/udev/rules.d.) 17: /etc/usbrelayd.conf should be marked as %config(noreplace). 18: The manpages must be listed in the %files sections as patterns to allow other suffixes than ".gz". I'm not sure about these. They may be serious problems: 19: I get no hits searching for "usbrelay" on PyPI. There is a policy to prevent name collisions between Fedora and PyPI. I don't know whether a Python module that is only a part of the project can be published on PyPI. If not, the policy says that the name shall be blocked on PyPI. Has that been done? 20: usbrelay.sysusers creates only a group, but a username is specified for the pid file. I'm not sure how that's going to work. 21: The makefile contains code for signing a release. Can we get that signature and verify it? When upstream projects sign their releases, packages are supposed to verify the signature. 22: The comment in %check seems to say that the Python module can't even be imported unless one of the supported relays is connected. Do I understand that correctly? That seems like terrible design that should be rectified upstream. The policy requires at least a smoke test. These are just suggestions. They don't block the review: 23: Why not use %{make_build}? I acknowledge that there's nothing to parallelize in the makefile, but it's policy and it shouldn't hurt. 24: The gzip commands shouldn't be necessary. RPMbuild compresses manpages automatically.
Thank you for the detailed review. As you can probably tell, this was a difficult spec file for us (I and the upstream developer) and we will work to address all of these issues before posting an update.
Updated: Spec URL: https://fuller.fedorapeople.org/usbrelay.spec SRPM URL: https://fuller.fedorapeople.org/usbrelay-1.1-1.fc36.src.rpm Mock builds (and also alternative links for spec/srpm): https://copr.fedorainfracloud.org/coprs/fuller/usbrelay/build/4994082/ I believe all of the preceding issues have been addressed. Thank you again for the extremely thorough and informative review.
EDIT: SPEC URL: https://fuller.fedorapeople.org/usbrelay.spec SRPM URL: https://fuller.fedorapeople.org/usbrelay-1.1-1.fc37.src.rpm Sorry about the mixup
Points 1, 3, 4, 6, 8, 9, 10, 11, 13, 14, 15, 17, 18, 19, 20, 22, 23 and 24 are fixed. These are unresolved: 2: You turned the -common subpackage into the main package as I suggested, but you left two Requires and one Summary tag behind. Those are now just text that is part of the description. You can't have tags in a %description section. 5: Other than the License tag in the spec, the licensing situation has not improved. I see some changes have been committed upstream, but those aren't in the source package. Even in the Github repository it's still unclear which files the MIT license in usbrelay_py/LICENSE applies to. 7: The explicit dependency on hidapi is gone, but only by accident as "Requires: hidapi" is only text in the description. Delete that line, or explain why the automatic dependency is insufficient. 12: py3_shebang_flags is still not used. Try passing the pathname to py3_shebang_fix. 16: "Requires: systemd-udev" is nonfunctional because it's only text in the description. 21: I see no news about signature verification. So the signing code in the makefile is unused then? I noticed one thing that I missed previously: 25: The -mqtt subpackage should be tagged "BuildArch: noarch" as it contains only arch-independent files. Four new issues have appeared: 26: For Python libraries there is a policy that the Fedora package's name should contain the canonical project name. Now that the library is on PyPI as "usbrelay-py" (which correctly matches the module name), that defines the canonical project name as "usbrelay-py", so the subpackage should be called "python3-usbrelay-py" instead of "python3-usbrelay". (The policy says only "should" though, not "must".) 27: Since you removed the %generate_buildrequires section, pyproject_buildrequires is now executed in the %prep section. I don't think it does anything useful outside of a %generate_buildrequires section. 28: Installing the packages creates the group too late: Installing : hidapi-0.12.0-2.fc37.x86_64 Installing : usbrelay-1.1-1.fc37.x86_64 Installing : python3-usbrelay-1.1-1.fc37.x86_64 Installing : hidapi-devel-0.12.0-2.fc37.x86_64 Installing : python3-paho-mqtt-1.6.1-4.fc37.noarch Running scriptlet: usbrelay-mqtt-1.1-1.fc37.x86_64 Installing : usbrelay-mqtt-1.1-1.fc37.x86_64 warning: group usbrelay does not exist - using root warning: group usbrelay does not exist - using root Running scriptlet: usbrelay-mqtt-1.1-1.fc37.x86_64 Installing : usbrelay-devel-1.1-1.fc37.x86_64 Running scriptlet: usbrelay-devel-1.1-1.fc37.x86_64 Creating group 'usbrelay' with GID 982. That seems related to this RPMlint warning: usbrelay-mqtt.x86_64: W: empty-%pre The %pre scriptlet was supposed to create the group, but does nothing because sysusers_create_compat didn't output any commands. This goes a bit beyond my knowledge. I think sysusers_create_compat is executed during macro expansion, before the tarball is unpacked, so usbrelay.sysusers doesn't exist yet. It may also be that it has another working directory than you expected, so the relative pathname is wrong. It may be possible to avoid sysusers_create_compat and instead run systemd-sysusers in a suitable scriptlet after usbrelay is installed but before usbrelay-mqtt is installed. I'm asking for help on the devel list. 29: When I start the daemon without any relays connected, SystemD tries to restart it several times until it reaches a restart limit. That's not review-blocking but are you sure that's what you want?
Issue 28. I have been unable to find a solution, other than installing usbrelay first, then installing the rest. This is not good. Was there any response from the devel list?
I got no response at all on the mailing list. It seems to me that the whole sysusers thing fails to solve the problem it was meant to solve, and thus you're free to create the group any way that works reliably. The simplest solution seems to be to put a groupadd command directly in the scriptlet: %package mqtt Requires(pre): shadow-utils [...] %pre mqtt groupadd --force --system usbrelay # --force means it's not an error if the group already exists. The spec already must know the group name for the %files section (which is why the %pre scriptlet is needed) so hardcoding the name in %pre too doesn't introduce a new problem.
It looks like %sysusers_create_compat macro doesn't see rpm/usbrelay.sysusers file. But, if I include usbrelay.conf as a separate file e.g. Source1: usbrelay.conf .... install -p -D -m 0644 %{SOURCE1} %{buildroot}%{_sysusersdir}/usbrelay.conf .... %sysusers_create_compat %{SOURCE1} it starts to work properly. $ rpm -qp --scripts usbrelay-mqtt-1.1-1.fc36.x86_64.rpm preinstall scriptlet (using /bin/sh): # generated from usbrelay.conf getent group 'usbrelay' >/dev/null || groupadd -r 'usbrelay' || : postinstall scriptlet (using /bin/sh): PS. Currently, usbrelay owns an %{_sysusersdir}/usbrelay.conf file. Shouldn't it belong to usbrelay-mqtt?
(In reply to Paweł from comment #12) > Currently, usbrelay owns an %{_sysusersdir}/usbrelay.conf file. Shouldn't it > belong to usbrelay-mqtt? No, because 50-usbrelay.rules references the group.
The groupdel in the mqtt package %pre script works. One question though, the usbrelay group is created correctly by %sysusers_create_compat in the usbrelay package. rpm -qp --scripts RPMS/x86_64/usbrelay-1.1-1.fc37.x86_64.rpm shows no scripts. At what point is the group created? Would it be normal practice to put a groupdel in the %postun of usbrelay?
Sorry, that should be 'The groupaddin the mqtt package %pre script works.'
(In reply to Darryl Bond from comment #14) > At what point is the group created? Dropping a file in _sysusersdir triggers a file trigger that creates user accounts and groups as specified by the files in that directory. You can see it with "rpm --query --filetriggers systemd". It's a post-transaction trigger so it's executed after all the packages have been installed. That's too late for a package that needs the group during installation, so usbrelay-mqtt needs to create the group in %pre. > Would it be normal practice to put a groupdel in the %postun of usbrelay? As far as I know it's common practice to leave user accounts and groups behind when packages are removed. If the group has access to any files that aren't owned by the package, then the numeric group ID will still have that access after the group name is removed. Next time a group is created the group ID will be reused, and then the new group will inherit privileges from the deleted group. For security it's better to avoid deleting the group.
SPEC: https://fuller.fedorapeople.org/usbrelay.spec SRPM: https://fuller.fedorapeople.org/usbrelay-1.1.1-1.fc37.src.rpm Test builds: https://copr.fedorainfracloud.org/coprs/fuller/usbrelay/build/5073353/ Apologies again for the delays
I haven't forgotten this but several other things took priority. At last I've had some time for review work again. Points 2, 5, 7, 12, 16 and 26 are fixed. Points 21 and 29 are unanswered but not blocking. These aren't yet fully resolved: 25: The -mqtt subpackage is now arch-independent, as I requested. Thus it can of course not have arch-specific dependencies. Remove "%{_isa}" from its Requires tags. 27: No change since the previous version. Why do you run pyproject_buildrequires in %prep instead of in %generate_buildrequires? What do you expect it to accomplish when run in %prep? 28: The group is now created properly thanks to the groupadd command. sysusers_create_compat still does nothing, so RPMlint still warns "empty-%pre". This won't cause any technical problems, but it will cause confusion as people reading the spec will think sysusers_create_compat is supposed to do something. It should therefore be removed. As "force" is a rather unintuitive parameter name, I think it's wise to include an explanation under the groupadd command, as I wrote above: "# --force means it's not an error if the group already exists." That's just my opinion though, not review-blocking. Two new issues have appeared: 30: Why did you remove systemd_postun_with_restart? Should the running daemon not be replaced with the new version on upgrade? 31: RPMlint now thinks the summary is too long: usbrelay.x86_64: E: summary-too-long A library and command line tool for controlling USB-connected relays based on hidapi The policy says only that the summary shall be short and concise. According to "rpmlint --explain summary-too-long" the limit is 80 characters. Maybe the information that HIDAPI is used can be moved to the description where there is more room? Another way to shave off a few letters would be to write "to control" instead of "for controlling".
29 an 30 are related and some advice would be appreciated. The daemon needs the correct hardware to be plugged in to operate. The systemd service file is disabled and the daemon is started from udev when one of the relays is plugged in. If the daemon is manually started without a relay plugged in, the daemon exits but systemd restarts it the configured number of times. (30) I'm not sure of the correct incantation of systemd and the spec to only restart the daemon if it has been running after an upgrade. Does systemd_postun_with_restart only restart the daemon if it was running?
Issue 25: -mqtt is arch independent. But it does depend on both libusbrelay.so and the python package and library wich are obviously arch dependant. Requires: %{name}%{_isa} = %{version}-%{release} Requires: python3-%{name}-py%{_isa} = %{version}-%{release} What is the correct way to describe the Requires: ?
@bjorn Fixed: 25: After some reading, I realise what the issue was (%{_isa}, now fixed 30: systemd_postun_with_restart returned. Tested. 27: Added the %generate_buildrequires macro and moved pyproject_buildrequires there and tested. 28: Comment added 31: RPMLint no longer complains about the length of the summary and mixing of tabs and spaces Not fixed but not blocking: 21: Package signing is not yet used, once used I will release a future version with signed packages 29: Manual starting of the daemon still fails without the hardware. I can find nothing in systemd that will prevent the daemon attempting to run if the USB device isn't present. I did find the recommendation of using udev, which is being used as recommended. The correct fix is to fix the daemon so it keeps running without the hardware and probe for it periodically. Please find the latest version of the spec file here: https://github.com/darrylb123/usbrelay/blob/master/rpm/usbrelay.spec
(In reply to Darryl Bond from comment #19) > If the daemon is manually started without a relay plugged in, the daemon > exits but systemd restarts it the configured number of times. Because the service file specifies Restart=always. It would make more sense to have the daemon restarted if it crashes, but not when it will just terminate again. See "Restart=" in "man 5 systemd.service". You might want on-failure or on-abnormal, and maybe set RestartPreventExitStatus to an exit code that the daemon returns when there are no relays. > Does systemd_postun_with_restart only restart the daemon if it was running? It wouldn't hurt to have that documented, but anything else would be a bug in SystemD. At https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd you'll find this policy: | On upgrade, a package may only restart a service if it is running; it may not | start it if it is off. Also, the service may not enable itself if it is | currently disabled. It would then be stupid if the very next section would tell you to use something that violates that policy. (In reply to Darryl Bond from comment #21) > I can > find nothing in systemd that will prevent the daemon attempting to run if > the USB device isn't present. That should be possible but I think it's fine to have the daemon check that itself. I just think it should be enough to do it once, not repeatedly until the restart limit is reached. > The correct fix is to fix the daemon so it keeps running without the > hardware and probe for it periodically. Polling is rarely the best solution. It wastes resources and conflicts with things like low-power modes. If a daemon initializes itself quickly enough to avoid an annoying delay, then starting it on demand is fine. When a daemon is running, it's best to have it just wait until it's woken up by some kind of event, such as a network request or a USB device being inserted. But that's getting a bit too far beyond the scope of a package review. > Please find the latest version of the spec file here: > https://github.com/darrylb123/usbrelay/blob/master/rpm/usbrelay.spec For the record, I'm now looking at this version of the spec: https://raw.githubusercontent.com/darrylb123/usbrelay/2793c5e1d6fb9875e8718a8b529a29a14a8bffc9/rpm/usbrelay.spec There's still an empty %pre scriptlet, but now it's at least visible that it's empty. I expected you to understand by yourself that "%pre" could be removed when its content was gone. Other than that, it looks like all the blocking issues have been resolved. With the leftover "%pre" removed, I think this package can be approved. I hope to be back soon with the full checklist and a formal approval.
Bjorn, I have removed the %pre macro. The updated file is https://github.com/darrylb123/usbrelay/blob/6db874f9e10abafdd3e0b3c5153086dd1113de06/rpm/usbrelay.spec Your suggestions on handling no hardware are very good and I shall incorporate them and submit it to Mark once I'm happy with them. As it is not a blocking issue I shall let you formalise the package as it now stands. @bjorn
Bjorn, Mark will be unavailable until well into the new year. I have made the suggested changes to the daemon and service file, created a new release 1.1.2 and updated the SPEC file accordingly. The daemon now exits with EX_UNAVAILABLE when there are no attached relays and the service file now has: # Daemon exits with EX_UNAVAILABLE (69) when there is no compatible hardware plugged in Restart=on-failure RestartPreventExitStatus=69 Please find: SPEC file: https://github.com/darrylb123/usbrelay/blob/7fdaa58bce4ae73456471c2b0f2f156a6d3d4ece/rpm/usbrelay.spec SRPM file: https://github.com/darrylb123/usbrelay/blob/7fdaa58bce4ae73456471c2b0f2f156a6d3d4ece/rpm/usbrelay-1.1.2-1.fc37.src.rpm
This package is now ready to be imported when Mark returns. Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: Development (unversioned) .so files in -devel subpackage, if present. [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]: 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. [x]: License file installed when any subpackage combination is installed. [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. → I assume that autochangelog handles that. [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. → as far as I can tell [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. [x]: 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. [x]: 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]: 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]: systemd_post is invoked in %post, systemd_preun in %preun, and systemd_postun in %postun for Systemd service files. Note: Systemd service file(s) in usbrelay-mqtt [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local Python: [x]: Python eggs must not download any dependencies during the build process. [x]: A package which is used by another package via an egg interface should provide egg info. [x]: Package meets the Packaging Guidelines::Python [x]: Package contains BR: python2-devel or python3-devel [x]: Packages MUST NOT have dependencies (either build-time or runtime) on packages named with the unversioned python- prefix unless no properly versioned package exists. Dependencies on Python packages instead MUST use names beginning with python2- or python3- as appropriate. [x]: Python packages must not contain %{pythonX_site(lib|arch)}/* in %files [x]: Binary eggs must be removed in %prep ===== 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). [x]: Fully versioned dependency in subpackages if applicable. [?]: Package functions as described. → What little I can test without the hardware, seems to work. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: Scriptlets must be sane, if used. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. [x]: Package should compile and build into binary rpms on all supported architectures. [x]: %check is present and all tests pass. → There's no actual testsuite, but py3_check_import passes. [x]: Packages should try to preserve timestamps of original installed files. [-]: Files in /run, var/run and /var/lock uses tmpfiles.d when appropriate [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). Note: There are rpmlint messages (see attachment). [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. [x]: Spec file according to URL is the same as in SRPM. Rpmlint warnings: usbrelay-mqtt.noarch: W: only-non-binary-in-usr-lib → Yes, that's where SystemD wants its unit files. usbrelay-mqtt.noarch: W: non-standard-gid /run/usbrelay usbrelay usbrelay-mqtt.noarch: W: non-standard-gid /run/usbrelay/usbrelayd.pid usbrelay → This is fine now that the group is created reliably. python3-usbrelay-py.x86_64: W: no-documentation usbrelay-devel.x86_64: W: no-documentation → Users of these libraries would presumably want some API documentation, but undocumented libraries are not forbidden.
Thank you both very much for all of your hard work. I'm sorry about my recent unavailability, but I have just made the repo request *https://pagure.io/releng/fedora-scm-requests/issue/50125) and will make every effort to get this into Rawhide this week. I've learned quite a bit from this process, so thank you both for that as well.
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/usbrelay
Thank you Mark and Bjorn. I have been using RPMs since Redhat 4 and all through Fedora but this is the first time I have been involved with creating one. I am very pleased with the result.
FEDORA-2023-f4f20cdf04 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f4f20cdf04
FEDORA-2023-6d190e7fb2 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-6d190e7fb2
FEDORA-2023-6d190e7fb2 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-6d190e7fb2 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-6d190e7fb2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-f4f20cdf04 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-f4f20cdf04 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-f4f20cdf04 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-6d190e7fb2 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-f4f20cdf04 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.