Bug 480870 - Review Request: crda - An 802.11 wireless regulatory compliance daemon
Review Request: crda - An 802.11 wireless regulatory compliance daemon
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-20 19:30 EST by John W. Linville
Modified: 2014-12-15 16:50 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-27 15:32:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
notting: fedora‑review+


Attachments (Terms of Use)

  None (edit)
Description John W. Linville 2009-01-20 19:30:15 EST
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.
Comment 1 John W. Linville 2009-01-20 19:31:53 EST
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.
Comment 2 Bill Nottingham 2009-01-21 15:49:29 EST
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?
Comment 3 John W. Linville 2009-01-22 15:47:40 EST
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!
Comment 4 Bill Nottingham 2009-01-22 15:57:39 EST
(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.
Comment 5 John W. Linville 2009-01-22 20:43:24 EST
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?
Comment 6 Bill Nottingham 2009-01-23 13:44:00 EST
(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.
Comment 7 John W. Linville 2009-01-26 14:56:33 EST
New Package CVS Request
=======================
Package Name: crda
Short Description: 
Owners: linville
Branches: F-10
InitialCC: linville
Comment 8 John W. Linville 2009-01-26 15:01:56 EST
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
Comment 9 John W. Linville 2009-01-26 15:02:28 EST
New Package CVS Request
=======================
Package Name: crda
Short Description: Regulatory compliance daemon for 802.11 wireless networking
Owners: linville
Branches: F-10
InitialCC: linville
Comment 10 Kevin Fenzi 2009-01-26 17:10:00 EST
cvs done.
Comment 11 John W. Linville 2009-01-27 15:32:27 EST
Packages built in koji.
Comment 12 Fedora Update System 2009-01-29 18:12:15 EST
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.
Comment 13 Mosaab Alzoubi 2014-12-15 16:10:10 EST
Package Change Request
======================
Package Name: crda
New Branches: el6 epel7
Owners: moceap linville
Comment 14 John W. Linville 2014-12-15 16:19:12 EST
crda already exists in rhel6 and rhel7.
Comment 15 Mosaab Alzoubi 2014-12-15 16:25:21 EST
https://admin.fedoraproject.org/pkgdb/package/crda/ !!!
Comment 16 John W. Linville 2014-12-15 16:27:26 EST
I'm not sure what you are trying to show me -- I already know that I'm the maintainer.
Comment 17 Mosaab Alzoubi 2014-12-15 16:37:45 EST
There is no EPEL branches on package information.
Comment 18 John W. Linville 2014-12-15 16:40:11 EST
The package is already in RHEL6 and RHEL7.  Why problem do you think you would be solving by putting it in EPEL?
Comment 19 Mosaab Alzoubi 2014-12-15 16:50:33 EST
Just a misunderstanding, I thought it isn't there.

Note You need to log in before you can comment on or make changes to this bug.