Spec URL: http://linville.fedorapeople.org/crda.spec SRPM URL: http://linville.fedorapeople.org/crda-v0.9.5_2009_01_15-1.fc10.src.rpm Description: CRDA acts as the udev helper for communication between the kernel and userspace for regulatory compliance. It relies on nl80211 for communication. CRDA is intended to be run only through udev communication from the kernel.
Future versions of the kernel are likely to have limited wireless functionality without this package (or some future equivalent). I would like to have this in F11 if at all possible.
MUST items: - Package meets naming and packaging guidelines - OK - Spec file matches base package name. - OK - Spec has consistent macro usage. - *** The 'v' in the version seems extraneous. In fact, there seem to be identical tarballs on the upstream download site with and without the 'v'. - Meets Packaging Guidelines. - OK - License - BSD *** The code doesn't specify a license, so it's assumed from the included LICENSE file. Would be nice if the code made it explicit. Given the keys/signing involved in the build process, it would have been highly entertaining if this package was GPL3. Alas, it is not. - License field in spec matches - OK - License file included in package - OK - Spec in American English - OK - Spec is legible - OK *** 'An' in the summary is probably superfluous. - Sources match upstream md5sum: - OK - Package needs ExcludeArch - N/A - BuildRequires correct - OK - Package has %defattr and permissions on files is good. - OK - Package has a correct %clean section. - OK - Package has correct buildroot %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - OK - Package is code or permissible content. - OK - Doc subpackage needed/used. - *** There are READMEs for both the daemon and the wireless regdb that should probably be in %doc. - Packages %doc files don't affect runtime. - OK - Headers/static libs in -devel subpackage. - N/A - Package compiles and builds on at least one arch. - OK (tested rawhide x86_64, F10 x86) - Package has no duplicate files in %files. - OK - Package doesn't own any directories other packages own. - OK - Package owns all the directories it creates. - *** Should own /usr/lib/crda - No rpmlint output. - *** crda.i386: W: non-conffile-in-etc /etc/udev/rules.d/regulatory.rules See below about udev rules. crda.i386: E: only-non-binary-in-usr-lib Can be ignored. - final provides and requires are sane: - *** Arguably, should require udev. SHOULD Items: - Should build in mock. - OK (tested i386) - Should build on all supported archs - didn't test - Should function as described. - didn't test, don't have appropriate drivers - Should have sane scriptlets. - N/A - Should have dist tag - OK - Should package latest version - OK Random notes not covered above: - We end up building two different upstreams into one package here. It could be done with the wireless db built as a separate package, that includes its pubkey in /etc/pki for the daemon to build later. If the daemon and the regulatory information are going to be updated asynchronously, that might be worthwhile - system udev rules should go in /lib/udev/rules.d, and usually are named XX-regulatory.rules, where XX is some relative numeric priority - the regulatory db is on /usr ... will it be needed before /usr is mounted? - the usage flow seems to be 'user sets a domain -> netlink message to kernel -> uevent -> udev helper to daemon -> reads database -> new netlink message to kernel -> implements restrictions in driver. Seems overly convoluted, but.. meh. - we remove the upstream key, and sign the regulatory db with our own key, generated at build time (and then thrown away). As I understand it, this means users won't be able to drop in new upstream releases of the regulatory db. Is this intentional?
I chose the "v" version of the crda tarball because those had later dates than the equivalent non-"v" versions. I made the assumption that this was the new release policy for the project. I'm happy to change the spec summary -- how about "Regulatory compliance daemon for 802.11 wireless networking"? I will also include the README files, probably as README.crda and README.wireless-regdb. I will change the ownership of /usr/lib/crda. I will move and rename the udev rules. Any suggestions for choosing a numeric priority? Adding a udev requirement makes perfect sense. The point about /usr being mounted later is a good one. I don't know how realistic a NFS-mounted /usr over wireless is, but it probably makes sense to allow for wireless networking and all allowed channels even when /usr isn't mounted. Are there any other guidelines differentiating /lib versus /usr/lib? Regarding one package versus two, I'm open to suggestions. I combined them under the thought that relying on an externally signed binary would drive some people nuts. Building them together allows for an automatically generated key that can be discarded, similar to how kernel module signing has been handled in the past. If that isn't important, than your suggestion regarding /etc/pki is a good one. Realistically I don't know how much difference it makes -- I don't think either crda or wireless-regdb are likely to be spun very often, and crda is not such a big package as to discourage revving it when wireless-regdb changes -- thoughts? In the interim, I'll revise the spec assuming that it remains as a single package, and I'll probably continue to use /usr/lib/crda for now just because the crda upstream is preconditioned for that behavior. Thanks for the feedback!
(In reply to comment #3) > I chose the "v" version of the crda tarball because those had later dates than > the equivalent non-"v" versions. I made the assumption that this was the new > release policy for the project. Just using whichever they're using would work - I find it odd that they have both tarballs. > I'm happy to change the spec summary -- how about "Regulatory compliance daemon > for 802.11 wireless networking"? Sounds good. > I will move and rename the udev rules. Any suggestions for choosing a numeric > priority? It probably doesn't make a big difference. If nothing else is acting on regulatory events, pick an earlier number and you may want to add OPTIONS+="last_rule"; this (theoretically) would speed up processing some. > The point about /usr being mounted later is a good one. I don't know how > realistic a NFS-mounted /usr over wireless is, but it probably makes sense to > allow for wireless networking and all allowed channels even when /usr isn't > mounted. Are there any other guidelines differentiating /lib versus /usr/lib? With NetworkManager on /usr, we don't really support nfs-over-wireless - my main concern is whether these events are going to be generated on driver load or similar activities on startup, and will then get 'missed' if /usr isn't there yet. If that's not the case, it's probably fine. > Realistically I don't know how much difference it makes -- I don't > think either crda or wireless-regdb are likely to be spun very often, and crda > is not such a big package as to discourage revving it when wireless-regdb > changes -- thoughts? If updates aren't going to be that often, it's not a big deal. I was just worried about if there is going to be a 'monthly' spin of the regdb or something similar that the updates might start to add up.
Spec URL: http://linville.fedorapeople.org/crda.spec SRPM URL: http://linville.fedorapeople.org/crda-v0.9.5_2009_01_15-2.fc10.src.rpm Did I do the /usr/lib/crda directory ownership right? Or is there more magic? I'll propose the last_rule thing to the upstream project. Is it worth us carrying a patch for it?
(In reply to comment #5) > Spec URL: http://linville.fedorapeople.org/crda.spec > SRPM URL: > http://linville.fedorapeople.org/crda-v0.9.5_2009_01_15-2.fc10.src.rpm > > Did I do the /usr/lib/crda directory ownership right? Or is there more magic? Looks good. > I'll propose the last_rule thing to the upstream project. Is it worth us > carrying a patch for it? Not really, no. APPROVED.
New Package CVS Request ======================= Package Name: crda Short Description: Owners: linville Branches: F-10 InitialCC: linville
Ugh...forgot description... New Package CVS Request ======================= Package Name: crda Short Description: Regulatory compliance daemon for 802.11 wireless networking Owners: linville Branches: F-10 InitialCC: linville
New Package CVS Request ======================= Package Name: crda Short Description: Regulatory compliance daemon for 802.11 wireless networking Owners: linville Branches: F-10 InitialCC: linville
cvs done.
Packages built in koji.
crda-1.0.1_2009_01_15-3.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Package Change Request ====================== Package Name: crda New Branches: el6 epel7 Owners: moceap linville
crda already exists in rhel6 and rhel7.
https://admin.fedoraproject.org/pkgdb/package/crda/ !!!
I'm not sure what you are trying to show me -- I already know that I'm the maintainer.
There is no EPEL branches on package information.
The package is already in RHEL6 and RHEL7. Why problem do you think you would be solving by putting it in EPEL?
Just a misunderstanding, I thought it isn't there.