Spec URL: http://hobbes1069.fedorapeople.org/spacenavd/spacenavd.spec SRPM URL: http://hobbes1069.fedorapeople.org/spacenavd/spacenavd-0.5-1.fc15.src.rpm Description: Spacenavd, is a free software replacement user-space driver (daemon), for 3Dconnexion's space-something 6dof input devices. It's compatible with the original 3dxsrv proprietary daemon provided by 3Dconnexion, and works perfectly with any program that was written for the 3Dconnexion driver.
rpmlint output: # ls *.rpm spacenavd-0.5-1.fc15.src.rpm spacenavd-debuginfo-0.5-1.fc15.x86_64.rpm spacenavd-0.5-1.fc15.x86_64.rpm # rpmlint *.rpm spacenavd.src:32: W: rpm-buildroot-usage %build %configure --prefix=%{buildroot}%{_prefix} Necessary because make file does not support DESTDIR spacenavd.x86_64: W: no-manual-page-for-binary spacenavd Is a daemon, not an end user binary. spacenavd.x86_64: W: no-manual-page-for-binary spnavd_ctl Not sure what to do here, upstream doesn't provide anything beyond a README. spacenavd.x86_64: W: service-default-enabled /etc/rc.d/init.d/spacenavd You'll only install this if you need to so should be on by default. spacenavd.x86_64: W: incoherent-subsys /etc/rc.d/init.d/spacenavd $prog Rpmlint has issues with $ variables in init scripts which is why this is a warning and not an error. Not really a problem. 3 packages and 0 specfiles checked; 0 errors, 5 warnings.
Initial review: naming: ok scriptlets: ok, though would be nice to investigate proper/native systemd init support licensing: ok sources: ok 0bb21da5315bd376aa508157a9455aaa spacenavd-0.5.tar.gz MUST: build doesn't use $RPM_OPT_FLAGS , please fix. Else, pretty small simple, fix the optflags thing, and looks like we have a winner.
(In reply to comment #2) > scriptlets: ok, though would be nice to investigate proper/native systemd init > support This was my first attempt at a daemon and didn't feel competent to do a systemd unit but if you want to help me I'm all for it. Here's my first attempt: [Unit] Description=Spacenav Daemon After=syslog.target [Service] Type=Simple ExecStart=/usr/bin/spacenavd [Install] WantedBy=graphical.target > MUST: build doesn't use $RPM_OPT_FLAGS , please fix. Fixed. Let me know if you want to move forward with a systemd unit or not then I'll post an updated spec and SRPM.
Hrm, systemd support can just as easily be developed outside of or after pkg review. (imo, better than way). I'll take your word that you've got the optflags thing nailed, (and will verify upon git import, and slap you with a wet noodle if they're still missing... :) ) APPROVED.
New Package SCM Request ======================= Package Name: spacenavd Short Description: A free, compatible alternative for 3Dconnexion's input drivers Owners: hobbes1069 Branches: f15 f16 InitialCC:
Git done (by process-git-requests).
Created attachment 519375 [details] Native systemd service file for spacenavd daemon As requested on -devel starts/restarts/stops cleanly https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd http://fedoraproject.org/wiki/Packaging:Tmpfiles.d Btw is it not mandatory now to provide native systemd units for new packages I certainly hope so... Oh and dont forget to submit the unit file upstream thanks
Thanks! It's funny. I just finished trying out a systemd based version of my package based on Lennart's input. I like the StandardError on yours so I'll definitely use that. As far as the target, mulit-user would work but I chose graphical since there is really no use for this outside of a graphical environment. Is there a reason to choose multi-user that I'm not aware of? Thanks, Richard
Nope not really (In reply to comment #8) > Thanks! It's funny. I just finished trying out a systemd based version of my > package based on Lennart's input. > > I like the StandardError on yours so I'll definitely use that. > > As far as the target, mulit-user would work but I chose graphical since there > is really no use for this outside of a graphical environment. Is there a reason > to choose multi-user that I'm not aware of? Not really the graphical target pulls in the multi user one but you are right we really should tie desktop only service to the graphical.target ( or create a specific desktop target for that). I also noticed spacenavd could be started in a non daemon mode if you need/want a unit file for that this should suffice.. [Unit] Description=3Dconnexion Input Devices Userspace Driver After=syslog.target [Service] ExecStart=/usr/bin/spacenavd -d StandardError=syslog [Install] WantedBy=graphical.target
spacenavd-0.5-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/spacenavd-0.5-2.fc16
spacenavd-0.5-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/spacenavd-0.5-2.fc15
spacenavd-0.5-2.fc16 has been pushed to the Fedora 16 testing repository.
spacenavd-0.5-2.fc15 has been pushed to the Fedora 15 stable repository.
spacenavd-0.5-2.fc16 has been pushed to the Fedora 16 stable repository.
Package Change Request ====================== Package Name: spacenavd New Branches: el6 Owners: zultron hobbes1069 InitialCC: The owner of this package (hobbes1069) and I (zultron) are building this package for EPEL6.
Package Change Request ====================== Package Name: spacenavd New Branches: epel7 Owners: zultron hobbes1069 InitialCC: