Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Fri, Feb 5, 2010 at 11:10 PM, Paul Wise <pabs@debian.org> wrote:
> On Fri, 2010-02-05 at 15:11 -0800, Luis R. Rodriguez wrote:
>
>> And after reviewing this again, I conclude Kel already did all the
>> work :) So any mentors / DDs willing to take his package up?
>>
>> I think its at:
>>
>> dget -ux http://sidux.net/kelmo/sidux/crap/crda/crda_1.1.1-1.dsc
>
> Ok, here are my comments:
>
> I very much like that it is based on the new shiny debhelper 7 stuff and
> dpkg-source v3.
>
> I don't really like that it merges the two packages. I don't think that
> is appropriate unless upstream is going to do the same.
Upstream does not do the same. Ubuntu packages these two together
right now but it was because it made life easier for packaging.
John, do you guys package wireless-regdb and crda together on Fedora
land? Was this because of the dynamic key building per package? If so
what is the restriction on using two packages?
> nl80211.h looks like it comes from Linux, can't you just build-depend on
> the linux-libc-dev package and do #include <linux/nl80211.h> ? Comparing
> the crda one and the one from Linux 2.6.32 reveals quite a few changes
> since you copied nl80211.h into crda.
nl80211 is designed to allow userspace applications to either ship
their own nl80211.h based on the most recent kernel or to ship it and
ifdef around a feature instead of the kernel version. Shipping your
own nl80211.h is a nice option for userspace to not have to build
depend on kernel headers. In CRDA's case it only needs one command and
a set of attributes now which have long existed on nl80211.h. It is
fine that it ships an older nl80211.h as it doesn't need any of the
new stuff. I can just synch it, but I there is just no need. The
benefit of shipping your own nl80211.h becomes more evident on iw, for
example, which does make use of most of the commands. The idea is
distributions can ship with an iw which supports commands which future
kernels will support, for older kernels it will just say the operation
is not supported. New iw also list of the list of available and
supported commands through 'iw list', for example:
Supported commands:
* new_interface
* set_interface
* new_key
* new_beacon
* new_station
* new_mpath
* set_mesh_params
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* Unknown command (55)
* Unknown command (57)
* Unknown command (59)
* set_wiphy_netns
* connect
* disconnect
Another example of a userpsace application shipping a copy of
nl80211.h is wpa_supplicant.
For CRDA then we ship our own nl80211.h and it doesn't matter much as
we only use only one command, and the API that can't change anyway.
When CRDA wants to make use of something new we can just re-synch,
just as we do with iw.
> Even after manually ensuring that sha1sum.txt reflects the sha1sum of
> db.txt with "sha1sum db.txt > sha1sum.txt", the wireless-regdb Makefile
> still seems to generate a new Debian RSA key pair. If the db.txt hasn't
> changed, there is no reason to auto-generate and install a key pair.
wireless-regdb is designed so that you do not have to run make at all
if you just intend on using John's key. So running make even if db.txt
has not changed will generate the keys for you and sign the
regulatory.bin with the new key.
> The package FTBFS when built twice in a row:
>
> dpkg-source: info: using source format `3.0 (quilt)'
> dpkg-source: info: building crda using existing ./crda_1.1.1.orig-wireless-regdb-20091125.tar.bz2 ./crda_1.1.1.orig.tar.bz2
> dpkg-source: error: cannot represent change to crda-1.1.1/wireless-regdb-20091125/regulatory.bin: binary file contents changed
> dpkg-source: error: add wireless-regdb-20091125/regulatory.bin in debian/source/include-binaries if you want to store the modified binary in the debian tarball
> dpkg-source: error: unrepresentable changes to source
>
> After working around this issue and building again, I get some files in
> debian/patches, you probably need to remove .custom on clean:
>
> pabs@chianamo:~/tmp/crda-1.1.1$ tail -n4 debian/patches/debian-changes-1.1.1-1
> --- /dev/null
> +++ crda-1.1.1/wireless-regdb-20091125/.custom
> @@ -0,0 +1 @@
> +Debian.key.pub.pem
>
> dpkg-shlibdeps complains that neither crda and regdbdump use symbols
> from libssl, it looks like this might be a false positive though:
>
> dpkg-shlibdeps: warning: dependency on libssl.so.0.9.8 could be avoided if "debian/crda/sbin/regdbdump debian/crda/sbin/crda" were not uselessly linked against it (they use none of its symbols).
They are not uselessly linking against libssl if indeed signature
checking is done.
> V=1 needs to be set on the make command-line so that the buildds
> verbosely print all the commands used to build everything.
>
> There are two lintian complaints:
>
> P: crda: no-upstream-changelog
> N:
> N: The package does not install an upstream changelog file. If upstream
> N: provides a changelog, it should be accessible as
> N: /usr/share/doc/<pkg>/changelog.gz.
> N:
> N: It's currently unclear how best to handle multiple binary packages from
> N: the same source. Some maintainers put a copy of the upstream changelog
> N: in each package, but it can be quite long. Some include it in one
> N: package and add symlinks to the other packages, but this requires there
> N: be dependencies between the packages. Some only include it in a
> N: "central" binary package and omit it from more ancillary packages.
> N:
> N: Refer to Debian Policy Manual section 12.7 (Changelog files) for
> N: details.
> N:
> N: Severity: pedantic, Certainty: wild-guess
> N:
>
> I'd suggest that 'make dist' should include a ChangeLog file in the
> tarball, generated with git2cl or git log or whatever. A NEWS file
> summarising the user-visible changes in each version would also be a
> good idea for both crda and wireless-regdb.
I see little point to maintaining a ChangeLog on these two upstream
git projects, is this something that has to be done on the package
debian/* stuff itself then? Is this required for inclusion into
Debian?
> W: crda: new-package-should-close-itp-bug
> N:
> N: This package appears to be the first packaging of a new upstream
> N: software package (there is only one changelog entry and the Debian
> N: revision is 1), but it does not close any bugs. The initial upload of a
> N: new package should close the corresponding ITP bug for that package.
> N:
> N: This warning can be ignored if the package is not intended for Debian or
> N: if it is a split of an existing Debian package.
> N:
> N: Refer to Debian Developer's Reference section 5.1 (New packages) for
> N: details.
> N:
> N: Severity: normal, Certainty: certain
> N:
>
> Someone needs to step up to be the maintainer of the package, retitle
> #536502 to an ITP (intent to package) and set themselves as the owner:
>
> http://bugs.debian.org/536502
>From what I gather Kel is busy, although he has done all the work for
this package. How can we request help for this package? I was offering
to do it but all the new debian/* magic makes me think its best for
someone else familiar with modern debian packages.
> I assume that the Debian installer should definitely install
> crda/wireless-regdb on systems that have a wireless card.
Yes, all new wireless devices would use this.
> Should it also
> be installed on other systems by default, in case a wireless card gets
> installed?
Yes, I would just always install it, sort of like firmware_request udev stuff.
> There is also existing systems to consider, how would you
> recommend crda/wireless-regdb be pulled in? Currently I'm thinking the
> Linux kernel images should Recommend crda; this would pull it in by
> default for those using Debian kernel images but allow those who do not
> need it to remove it. People compiling their own kernel will need to
> install it manually.
That seems fine logic.
Please let me know if there is anything I can do to help upstream wise
to help get this packaged up into Debian.
Luis
Reply to: