Bug#703142: compatibility with alx ?
On Sun, Mar 17, 2013 at 2:43 PM, Ben Hutchings b...@decadent.org.uk wrote: [Re-sending to the correct list address.] On Sun, 2013-03-17 at 16:24 +0100, Camaleón wrote: El 2013-03-17 a las 14:58 +, Ben Hutchings escribió: On Sun, 2013-03-17 at 15:46 +0100, Camaleón wrote: (...) Using Debian's stock network driver is not an option for me (full report available here²) so I have to try with the latests drivers but now that compat-drivers are compiled the generated modules cannot be loaded. Is there any by-pass for this? ¹http://marc.info/?t=13635103432r=1w=2 ²http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664767 Talk to the compat-drivers developers. To be sincere, I don't think that's a user's role. I don't know what's going on with these drivers but if they are not supported by Debian at all it would be better for all of us (plain users and developers) to simply say it so to avoid wasting time and resources. I would like to support them, in fact more than that I would like to integrate them into official packages. But there is no way we can support an OOT module that defines symbols that we might need to add for our own backports. As it is 'compat' will ironically cause incompatibility with Debian's own kernel upgrades. Compat developers: please add a prefix (not 'compat', that one's already taken!) We have been using compat_ for a while now to prefix a lot of our symbols without clashes for the 32-64 compat stuff, but sure -- we can use something else to help with any theoretical issues. Surprised Debian of all distributions would frankly have been affected given RHEL / SUSE didn't, but its OK, lets deal with it. to all the symbols exported by the 'compat' module. Just #define'ing the function/variable name before declaring them should avoid the need for any changes to the drivers using it. How about backport_ ? Patches coming up. Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAB=ne6upgjoxi7wwbma5xvhy8mmcf6kwqswxwvim6kijypv...@mail.gmail.com
Bug#703142: compatibility with alx ?
On Wed, Mar 20, 2013 at 7:41 AM, Ben Hutchings b...@decadent.org.uk wrote: On Wed, 2013-03-20 at 02:07 -0700, Luis R. Rodriguez wrote: On Sun, Mar 17, 2013 at 2:43 PM, Ben Hutchings b...@decadent.org.uk wrote: [Re-sending to the correct list address.] On Sun, 2013-03-17 at 16:24 +0100, Camaleón wrote: El 2013-03-17 a las 14:58 +, Ben Hutchings escribió: On Sun, 2013-03-17 at 15:46 +0100, Camaleón wrote: (...) Using Debian's stock network driver is not an option for me (full report available here²) so I have to try with the latests drivers but now that compat-drivers are compiled the generated modules cannot be loaded. Is there any by-pass for this? ¹http://marc.info/?t=13635103432r=1w=2 ²http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664767 Talk to the compat-drivers developers. To be sincere, I don't think that's a user's role. I don't know what's going on with these drivers but if they are not supported by Debian at all it would be better for all of us (plain users and developers) to simply say it so to avoid wasting time and resources. I would like to support them, in fact more than that I would like to integrate them into official packages. But there is no way we can support an OOT module that defines symbols that we might need to add for our own backports. As it is 'compat' will ironically cause incompatibility with Debian's own kernel upgrades. Compat developers: please add a prefix (not 'compat', that one's already taken!) We have been using compat_ for a while now to prefix a lot of our symbols without clashes for the 32-64 compat stuff, but sure -- we can use something else to help with any theoretical issues. Surprised Debian of all distributions would frankly have been affected given RHEL / SUSE didn't, but its OK, lets deal with it. The conflict that just showed up in Debian involved the 'i2c_bit_algo' symbol which had no symbol prefix in 'compat'. We updated the in-tree DRM drivers from 3.4.32 and started exporting the symbol from i2c-algo-bit itself. I hadn't noticed that you already used the 'compat_' prefix for some exported symbols and I'm not aware of any current conflict with the 32-bit compatibility layer, but it seems plausible that it could happen in future. Sure, let me know what you think of the proposed posted changes. Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAB=ne6uz+rvfhyzuhswzatnkd9gaga0ekdqd+u9vxvm8fsv...@mail.gmail.com
Bug#664461: [squeeze] atl1c: AR8152: transmit queue 0 timed out and network is unusable until reset
On Wed, Jul 04, 2012 at 01:16:14PM -0500, Jonathan Nieder wrote: Jonathan Nieder wrote: Luis R. Rodriguez wrote: FWIW we already provide daily backports of code through compat-wireless. compat-wireless will eventually be changed to compat-drivers to reflect that it has drivers backported other than 802.11. We also have stable releases of the Linux kernel backported for use on older releases. I looked at the relevant repositories and am afraid I am too dim to see how to use them. Ok, it's becoming a little clearer now. Is the appropriate procedure something like this? git clone git://github.com/mcgrof/compat.git git clone git://github.com/mcgrof/compat-wireless.git git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git cd compat-wireless git checkout linux-3.0.y GIT_COMPAT_TREE=$(pwd)/compat/ this ones always assumes $HOME/compat so if you have it there already there is no need to specify this variable. NEXT_TREE=/path/to/src/linux GIT_TREE=/path/to/linux/repo export GIT_TREE GIT_COMPAT_TREE Nope, export GIT_TREE=/home/foo/linux-stable.git git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git I use Greg's linux-stable.git so I can use all the extra version stable kernels, but on top of that I have a remote set up to also pull in Linus' junk: [remote linus] fetch = +refs/heads/*:refs/remotes/origin/* url = git://github.com/torvalds/linux.git So I just do this on linux-stable: git fetch linus git reset --hard origin Then I get reset --hard v3.5-rc5 given that Linus will typically have a delta on top of the latest RC. scripts/gen-stable-release.sh some appropriate arguments The arguments allows you to specify which delta you want to suck in, if at all. http://wireless.kernel.org/en/users/Download/stable/#Legend http://wireless.kernel.org/en/users/Download/stable/#Additional_patches_to_stable_releases And then this will not generate a list of patches but just a patched source code tree with appropriate #ifdefs to make the code build against old kernels. #ifdef'ing around code to provide kernel backporting is a strategy of the stone age. We have taken a slightly different approach, we have stuffed as much into a module / headers: compat.git so that the code can remain as pristine as possible. This also means that you can backport *more* subsystems with less effort and I've proven this through a graph which shows the overhead cost of backporting a new subsystem once you have a lot of code within a shared compat module: https://docs.google.com/presentation/d/1axVNEGwKZjnzG1ocdd289WMqPxzJ3qfMv70ghGcnUKc/edit The only #ifdef crap needed really would then just be things that *cannot* be backported through a module / headers. In turn we've been discovering that some of this #ifdef'able stuff actually can be represented also using SmPL and that this SmPL actually represents collateral evolutions of the Linux kernel. So the patches/ directory represents just this: collateral evolutions of the Linux kernel. I've started to formally document this slowly. The first one is the patch with 4 digits: patches/0001-netdev_ops.patch Jesper Andersen however has written a tool called spdiff which I intend on using to extract SmPL *from* a patch file ! What this means is if one collateral evolution *which could not be backported through compat.git* is backported for *two drivers* it means that we can backport that collateral evolution for *all drivers*. Furthermore if we design collateral evolutions on the Linux kernel *with* SmPL it means we also can backport that respective collateral evolution with the *inverse* of SmPL ! That sounds useful. How about with all the other junk I just mentioned ? :) I should mention that stable releases are already made: http://wireless.kernel.org/en/users/Download/stable/ But surely you can also just make your own as well. The stable releases also are test compiled accross 21 kernels, and soon, thanks to Ozan's GSoC project I hope we'll have video backported as well. Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120705203235.GE11228@tux
Bug#664461: [squeeze] atl1c: AR8152: transmit queue 0 timed out and network is unusable until reset
On Thu, May 10, 2012 at 05:28:31AM +0100, Ben Hutchings wrote: On Thu, 2012-05-10 at 02:14 +, Huang, Xiong wrote: Hi Jonathan For driver atl1c, we add many patches recently. Please sync with the kernel, the last patch is 80bcb4238dd858d atl1c: remove PHY polling from atl1c_change_mtu I've attempted to backport these changes to Linux 2.6.32 as used in the current Debian stable release. The result can be found at: git://anonscm.debian.org/kernel/linux-2.6.git squeeze-driver-test Please can you review the changes and test whether this works properly (I have no hardware to test). The major difference I'm concerned about is in VLAN handling; I'm not sure that the backported version of the driver will configure the MAC properly for VLAN tag removal whenever it should. Ben, FWIW we already provide daily backports of code through compat-wireless. compat-wireless will eventually be changed to compat-drivers to reflect that it has drivers backported other than 802.11. We also have stable releases of the Linux kernel backported for use on older releases. http://wireless.kernel.org/en/users/Download/ http://wireless.kernel.org/en/users/Download/stable In the case of trying to merge patches that are critical but not yet even published, upstream or not yet merged somehow, I've also addressed this by categorizing the patches based on the life cycle the patch is in, but by still prioritizing upstream. http://wireless.kernel.org/en/users/Download/stable/#Additional_patches_to_stable_releases I think you had mentioned to me working together, perhaps its time we review how we can do that. Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120510204800.GB7185@tux
Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree
On Mon, Oct 24, 2011 at 6:12 AM, Ben Hutchings b...@decadent.org.uk wrote: Use of the GPL or a compatible licence doesn't necessarily make the code any good. We already consider staging modules to be suspect, and this should also be true for out-of-tree modules which may receive very little review. Signed-off-by: Ben Hutchings b...@decadent.org.uk --- Debian has been carrying this for the last few kernel versions. The recent thread '[RFC] virtualbox tainting.' and discussions at KS suggest that this might be more generally useful. This indeed seems like a good idea to advocate getting things upstream (not just staging) but what about the case where we have upstream drivers from future kernels backported to older kernels and the newer driver is simply provided as a feature for users who may need new features / chipset support on their old distribution kernel? It seems this taint flag will be used for driers backported through compat-wireless, the compat kernel module or any other backported driver, even if it is indeed upstream and whereby kernel developer *do* commit to actually fixing issues. In our experience compat-wireless bugs *are real bugs*, not backport bugs so we do look into them. In our latest linux-next.git based release for example backport code consists only of 1.3804% of the code. Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAB=ne6vt91thcbj7sjhjucadzzpqox+omcqjsej54vqatby...@mail.gmail.com
Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree
On Mon, Dec 12, 2011 at 1:58 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, Dec 12, 2011 at 01:40:44PM -0800, Luis R. Rodriguez wrote: On Mon, Oct 24, 2011 at 6:12 AM, Ben Hutchings b...@decadent.org.uk wrote: Use of the GPL or a compatible licence doesn't necessarily make the code any good. We already consider staging modules to be suspect, and this should also be true for out-of-tree modules which may receive very little review. Signed-off-by: Ben Hutchings b...@decadent.org.uk --- Debian has been carrying this for the last few kernel versions. The recent thread '[RFC] virtualbox tainting.' and discussions at KS suggest that this might be more generally useful. This indeed seems like a good idea to advocate getting things upstream (not just staging) but what about the case where we have upstream drivers from future kernels backported to older kernels and the newer driver is simply provided as a feature for users who may need new features / chipset support on their old distribution kernel? They continue to work without any loss of functionality. (After the follow-up patches to keep dynamic debugging and lock debugging working.) Great! It seems this taint flag will be used for driers backported through compat-wireless, the compat kernel module or any other backported driver, even if it is indeed upstream and whereby kernel developer *do* commit to actually fixing issues. In our experience compat-wireless bugs *are real bugs*, not backport bugs so we do look into them. In our latest linux-next.git based release for example backport code consists only of 1.3804% of the code. Now you can look for (O) after the module name in a BUG/Oops message and you can tell whether the user really had the original or compat-wireless version of the driver. It is really up to each distributor or developer how they treat bug reports with the O taint. When handling Debian bug reports I won't automatically reject such a tainted kernel but I will look carefully at the module list. I'm working on getting my companies to abandon 802.11 proprietary drivers for good. For Station mode of operation this is pretty much mission complete. For AP products.. this is work in progress. The out of tree flag is a good utility one can use to help justify working upstream but if we treat any future-kernel-backported-driver equally to any out of tree crap piece of shit driver, it seems to do unjustice to the value of a properly upstream backported driver. I will note that I put a lot of effort to ensure that the backport effort is upstream-centric in an *extremely* upstream-biased way, see how I label extra patches for tarballs [1]. If your patches are not upstream the only way you get into these tarballs are by providing patches into these directories: * pending-stable/ stable fixes from linux-next.git not yet on a stable release * linux-next-cherry-picks/ patches upstream but that won't go to the stable release that we want to cherry pick * linux-next-pending/ patches posted on the public development mailing list, patch not yet merged due to the maintainer being away on vacation or whatever * crap/ patches not even posted publicly yet Each tarball used also gets pegged with a letter if *any* patch from any of these directories gets applied. The compat module, upon being loaded, will also print the kernel ring buffer the exact release, whether extra patches were provided, the upstream git tree used as base and so on. So -- although from a technical perspective this may mean Debian / other kernel developers may ignore the taint flag for compat-wireless it'd sure be nice to avoid it for them all together. Just can't think of a way to do it yet... If you agree should we continue to think of a way if its possible? [1] http://wireless.kernel.org/en/users/Download/stable#Legend Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAB=NE6Wb9ySk6a1gB-edyF_uRe=-esehunbua+n0g2wygjx...@mail.gmail.com
Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree
On Mon, Dec 12, 2011 at 2:47 PM, Luis R. Rodriguez mcg...@frijolero.org wrote: On Mon, Dec 12, 2011 at 1:58 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, Dec 12, 2011 at 01:40:44PM -0800, Luis R. Rodriguez wrote: On Mon, Oct 24, 2011 at 6:12 AM, Ben Hutchings b...@decadent.org.uk wrote: Use of the GPL or a compatible licence doesn't necessarily make the code any good. We already consider staging modules to be suspect, and this should also be true for out-of-tree modules which may receive very little review. Signed-off-by: Ben Hutchings b...@decadent.org.uk --- Debian has been carrying this for the last few kernel versions. The recent thread '[RFC] virtualbox tainting.' and discussions at KS suggest that this might be more generally useful. This indeed seems like a good idea to advocate getting things upstream (not just staging) but what about the case where we have upstream drivers from future kernels backported to older kernels and the newer driver is simply provided as a feature for users who may need new features / chipset support on their old distribution kernel? They continue to work without any loss of functionality. (After the follow-up patches to keep dynamic debugging and lock debugging working.) Great! It seems this taint flag will be used for driers backported through compat-wireless, the compat kernel module or any other backported driver, even if it is indeed upstream and whereby kernel developer *do* commit to actually fixing issues. In our experience compat-wireless bugs *are real bugs*, not backport bugs so we do look into them. In our latest linux-next.git based release for example backport code consists only of 1.3804% of the code. Now you can look for (O) after the module name in a BUG/Oops message and you can tell whether the user really had the original or compat-wireless version of the driver. It is really up to each distributor or developer how they treat bug reports with the O taint. When handling Debian bug reports I won't automatically reject such a tainted kernel but I will look carefully at the module list. I'm working on getting my companies to abandon 802.11 proprietary drivers for good. For Station mode of operation this is pretty much mission complete. For AP products.. this is work in progress. The out of tree flag is a good utility one can use to help justify working upstream but if we treat any future-kernel-backported-driver equally to any out of tree crap piece of shit driver, it seems to do unjustice to the value of a properly upstream backported driver. I will note that I put a lot of effort to ensure that the backport effort is upstream-centric in an *extremely* upstream-biased way, see how I label extra patches for tarballs [1]. If your patches are not upstream the only way you get into these tarballs are by providing patches into these directories: * pending-stable/ stable fixes from linux-next.git not yet on a stable release * linux-next-cherry-picks/ patches upstream but that won't go to the stable release that we want to cherry pick * linux-next-pending/ patches posted on the public development mailing list, patch not yet merged due to the maintainer being away on vacation or whatever * crap/ patches not even posted publicly yet Each tarball used also gets pegged with a letter if *any* patch from any of these directories gets applied. The compat module, upon being loaded, will also print the kernel ring buffer the exact release, whether extra patches were provided, the upstream git tree used as base and so on. So -- although from a technical perspective this may mean Debian / other kernel developers may ignore the taint flag for compat-wireless it'd sure be nice to avoid it for them all together. Just can't think of a way to do it yet... If you agree should we continue to think of a way if its possible? [1] http://wireless.kernel.org/en/users/Download/stable#Legend How about a way to peg a driver as a backport from future kernels? Like maybe MODULE_COMPAT() ? Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAB=ne6w_ap2rylad4xylm8wmiuxrzbqzhczpeksvmsdq9...@mail.gmail.com
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Mon, Mar 1, 2010 at 8:39 PM, Paul Wise p...@debian.org wrote: On Tue, 2010-03-02 at 04:44 +0200, Faidon Liambotis wrote: Luis R. Rodriguez wrote: Can you guys upstream a package into Debian with a gitweb URL reference? If I'm understanding the question correctly, yes. We have Vcs-$VCS (i.e. Vcs-Git) and Vcs-Browser pseudo-headers. Both are optional. The Vcs-* fields are for the Debian package VCS. There is an emerging project to add upstream metadata to Debian source packages: http://wiki.debian.org/UpstreamMetadata I agree with Kel here, git2cl et al are unimportant details. Indeed, that is why the relevant lintian warning is marked pedantic. Personally I think this part of Debian policy needs a review, I don't have the time or energy to bring it up on debian-policy though. Kel, mail me in private when you have something ready for review upload, as usual. Check this thread: http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2010-March/thread.html#2541 He already created almost perfect packages that are pretty-much ready to be uploaded, just a couple of minor issues. BTW -- while we're on the topic of 2.6.32 and the next Debian release, and 802.11, do you guys ship iw by default yet? If not I highly encourage it. It should be shipped just as iwconfig is shipped. iw is the replacement for iwconfig, it uses the new nl80211 and nl80211 is used by all cfg80211 and mac80211 drivers. All new upstream drivers have to be cfg80211 based (or mac80211) so hence why I recommend to just ship iw by default today. Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/43e72e891003031416m5572e171j8c7978b77b278...@mail.gmail.com
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Mon, Mar 1, 2010 at 8:09 AM, Paul Wise p...@debian.org wrote: On Mon, 2010-03-01 at 10:47 -0500, John W. Linville wrote: FWIW, I don't create the tarballs. Perhaps we could ask Johannes to do something in his scripts that create them? Beyond that I don't see much point in checking-in a ChangeLog. I can add that too. It definitely shouldn't be checked into git, but rather generated from the git commit logs; with git2cl, git log or similar. With an autotools based build system you would add a command to the Makefile.am so that automake runs git2cl during 'make dist' / 'make distcheck'. For non-autotools based projects you usually won't have a standard 'make dist' so it would need to be added to whatever script is the equivalent. Do you like that git2cl output? It seems rather ugly to me... Its the standard ancient GNU form for a ChangeLog. I have no opinion on its aesthetics and I don't think it matters what format it has really. I think the format is indeed pretty ugly, can't we just do: git log v0.9.8..v0.9.9 ChangeLog I've attached an example output of this on the iw package for example. Paul, does Debian packaging not care the format the ChangeLog is on? Luis commit f8396b2454ece21a9db91ad592192b865522aa33 Author: Johannes Berg johan...@sipsolutions.net Date: Sat Jan 24 15:36:08 2009 +0100 bump version to 0.9.9 commit c1d44a6c68790adc45d4a047cdd3a93332210c17 Author: Johannes Berg johan...@sipsolutions.net Date: Sat Jan 24 15:35:30 2009 +0100 RTFM link for ap/master modes commit 0c099f3edd23586680e700dbe16a484b0d0568f9 Author: Johannes Berg johan...@sipsolutions.net Date: Sat Jan 24 15:15:46 2009 +0100 add commas to see also section commit 585e62cbc9fddaba274d948dd0e1ab78b18fc02f Author: Luis R. Rodriguez lrodrig...@atheros.com Date: Fri Jan 23 15:02:38 2009 -0800 iw: fix typo, add few references This fixes a small typo s/ip/iw, and adds references to the other new wireless subsystem userspace applications/files. Lets also point users to the iw wiki as it has lots of good stuff. Signed-off-by: Luis R. Rodriguez lrodrig...@atheros.com commit 45d543f0a65cd4a5ad461b88acee1749a5c78431 Author: Johannes Berg johan...@sipsolutions.net Date: Wed Jan 21 16:30:52 2009 +0100 include netlink/netlink.h also fixes the nl_handle vs. nl_sock issue that has been plaguing people trying to use libnl from git commit ee9cd9875412bbe0ab24c4f8acd25253ec1410c4 Author: Johannes Berg johan...@sipsolutions.net Date: Sun Jan 18 18:13:54 2009 +0100 suppress flags on disabled channels
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Mon, Mar 1, 2010 at 1:50 PM, Kel Modderman k...@otaku42.de wrote: On Tuesday 02 March 2010 04:13:25 Luis R. Rodriguez wrote: On Mon, Mar 1, 2010 at 8:09 AM, Paul Wise p...@debian.org wrote: On Mon, 2010-03-01 at 10:47 -0500, John W. Linville wrote: FWIW, I don't create the tarballs. Perhaps we could ask Johannes to do something in his scripts that create them? Beyond that I don't see much point in checking-in a ChangeLog. I can add that too. It definitely shouldn't be checked into git, but rather generated from the git commit logs; with git2cl, git log or similar. With an autotools based build system you would add a command to the Makefile.am so that automake runs git2cl during 'make dist' / 'make distcheck'. For non-autotools based projects you usually won't have a standard 'make dist' so it would need to be added to whatever script is the equivalent. Do you like that git2cl output? It seems rather ugly to me... Its the standard ancient GNU form for a ChangeLog. I have no opinion on its aesthetics and I don't think it matters what format it has really. I think the format is indeed pretty ugly, can't we just do: git log v0.9.8..v0.9.9 ChangeLog I've attached an example output of this on the iw package for example. Paul, does Debian packaging not care the format the ChangeLog is on? FWIW, I do not think all of this is necessary, the information stored in the git repository is rich and readily available. We're getting pedantic here. Can you guys upstream a package into Debian with a gitweb URL reference? Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/43e72e891003011356l7491007co1e6837e2a64d8...@mail.gmail.com
[RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
Adding debian-devel and debian-mentors. As per Paul Wise' advice I'd like to request for help with the crda/wireless-regdb package for Debian for the next release of Debian. I am the upstream crda maintainer and John Linville is the upstream wireless-regdb maintainer. Kel Modderman has already done most work required for the Debian package, if not all. What we now need is some Debian Developer to be willing to either upload the package as-is, or some help from some experienced package maintainers to address a few items. I should note Paul Wise has offered sponsorship for this package so I think we are on the last track to getting this package finalized and/or uploaded but he just noted a few changes required. Summary of review with Paul Wise: * Package could likely be uploaded into Debian as-is, just requires someone comfortable with it * We need more help with thepkg-wpa-devel group * Sponsorship available by Paul Wise given a few change below are made: o Modify the Makefile to add a 'make dist' to generate a ChangeLog using git2cl [1] and NEWS based on crda and wireless-regdb upstream git Paul I'm not familiar with the sponsorship process on Debian, does this mean if the above is address you would be wiling to upload the final package yourself? Or does this have other implications? I address some of Paul's own comments below. If you would like to read the original thread you can refer to the pkg-wpa-devel package list. [1] http://josefsson.org/git2cl/git2cl [2] http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2010-January/002415.html If anyone has any questions please let me know. On Fri, Feb 19, 2010 at 10:11 PM, Paul Wise p...@debian.org wrote: On Thu, 2010-02-18 at 09:19 -0800, Luis R. Rodriguez wrote: 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? Thanks John. So -- not sure if Kel will have time to split these, I gather he is still pretty busy with his move. Paul, is this a requirement for inclusion? If so we'll need to request for some help. I wouldn't upload it to Debian like that, you might find other people in Debian who would be willing to do so though. OK. 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. ... 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. Hmm, OK. I guess that makes sense. Yeah hope 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. Hmm, OK. So the Debian packaging should check that db.txt is unchanged, instead of the upstream Makefile doing that check? No, I meant that some distributions won't run make at all. Those who do will always have something done if you don't yet have a key built for you. By default the regulatory.bin is signed with this key. You will re-sign the file if db.txt changes. I guess that means Fedora, Gentoo, Ubuntu etc all need to do the same thing. Fedora does build stuff so they just go with the defaults. Ubuntu just ships the provided regulatory.bin, they do not build anything, the package is very simple for the binary regulatory database as you really only need to build if you have policies which require this (the content would be the same except the signature), or you want to change the database yourself. 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. It looked like a false positive to me, I
Re: linux-firmware-nonfree: Add prism54 softmac firmware
On Tue, Feb 23, 2010 at 12:17 PM, Chase Douglas chase.doug...@canonical.com wrote: On Tue, 2010-02-23 at 12:02 -0800, Luis R. Rodriguez wrote: On Tue, Feb 23, 2010 at 7:47 AM, Chase Douglas chase.doug...@canonical.com wrote: I have uploaded a new version of the linux-firmware-nonfree package to: http://kernel.ubuntu.com/~cndougla/linux-firmware-nonfree/ The new package includes the firmware for prism54 softmac cards. The firmware was removed from linux-firmware due to it missing a proper license statement. I did not copy over the old prism54 (non-softmac) firmware because it has been superseded by the softmac firmware and is no longer useful in the Lucid kernel version. Hey is PRISM54 no longer compiled in a module any more? I had set it for removal on the feature removal schedule but I wanted to give you the heads up we've received a few reports of users unable to use prism54 over p54pci. It was theorized this would happen but we didn't have any confirmation, which is why we just didn't remove it. How would you guys deal with having both enabled. Thanks for looking into this. I was going off of [1], which stated that the debian kernel does not include the prism54 module anymore. Fun, passing this as a memo to lkml/Debian -- p54pci doesn't seem to work well for *all* Prism54 FullMAC cards. They technically are the same and the SoftMAC functionality was possible through a smaller firmware. But it seems some cards have issues still with p54pci so I would still enable prism54 as a module but not sure what to recommend about dealing with two modules on the system for the same device. I checked the lucid kernel and we do have prism54 built as a module still. So, are we going to leave the prism54 module in, in which case we need to restore the prism54 firmware? Yes I'd restore the prism54 firmware until the coast is clear with p54pci for all. Its not the case so far as per reports. Or are we going to remove it, in which case the firmware package I uploaded was fine? I'm assuming at this point we'll be leaving it in though. I'd say keep it for now. Andy, do you have any thoughts here? [1] http://wiki.debian.org/prism54 Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/43e72e891002231646w269a1132i505ca5c21ab2...@mail.gmail.com
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Fri, Feb 5, 2010 at 11:10 PM, Paul Wise p...@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: p...@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
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Thu, Feb 18, 2010 at 10:14 AM, John W. Linville linvi...@tuxdriver.com wrote: On Thu, Feb 18, 2010 at 09:19:06AM -0800, Luis R. Rodriguez wrote: On Fri, Feb 5, 2010 at 11:10 PM, Paul Wise p...@debian.org wrote: 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? Fedora packages them together due to the dynamic keys. I have a (low priority) TODO to investigate separating them now that keys can be installed separately. Thanks John. So -- not sure if Kel will have time to split these, I gather he is still pretty busy with his move. Paul, is this a requirement for inclusion? If so we'll need to request for some help. Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/43e72e891002181036r23050801h8fc0ea3cc1d98...@mail.gmail.com
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Thu, Feb 4, 2010 at 4:25 PM, Luis R. Rodriguez mcg...@gmail.com wrote: On Thu, Feb 4, 2010 at 6:03 AM, Kel Modderman k...@otaku42.de wrote: On Thursday 04 February 2010 11:42:33 Luis R. Rodriguez wrote: On Mon, Feb 1, 2010 at 6:10 PM, Paul Wise p...@debian.org wrote: On Mon, 2010-02-01 at 09:58 -0800, Luis R. Rodriguez wrote: I can help with this only if no one else is up for it. I personally however find building a key on the fly for each build pretty pointless and would like to know if a package would be acceptable upstream on Debian if OpenSSL is used to allow administrators to add their own keys into the /etc/wireless-regdb/pubkeys/ dir for CRDA and from the start only trust John's key. As part of upstream, you're probably the best person to do the packaging stuff for Debian. OK, in that case here is my first shot at this. http://wireless.kernel.org/download/wireless-regdb/debs/ http://wireless.kernel.org/download/crda/debs/ Tim -- notice both packages have a Replaces: wireless-crda. If debian upstreams both packages then I think it would be good to separate the packages as I am recommending for integration on Debian and for Ubuntu to also use the same debian packages as debian. I think this would mean also having the new Ubuntu kernels depend on these new packages instead of the old wireless-crda. The package is very simple, I took what I could from Kel's work but did leave in the signature check stuff, used openssl and also just used cdbs. The wireless-regdb does not change *that* often so I do not expect debian itself to need a custom regulatory database to be automatically built and propagated so I left all the watch stuff out and can do manual updates for now, I can commit to that for now. If that is a requirement however, I am not that familiar with new package policies and am unclear how to do that. I would prefer if we can get something started and uploaded for now which at least meets the requirements for integration into an eventual stable release, but that's just me. Please review and let me know what you think. These demonstrate that most of what I've attempted to explain about the difficulties of getting this software into the Debian software pool in a maintainable form has been taken lightly. To reiterate what I think is most important: The software should be built from its preferable form of modification to produce the resulting binary. What's the point? This helps to make the source package available to other developers to modify and rebuild without invasive packaging changes. The source will always be available and users can themselves apt-get source wireless-regdb and compile their own regdb at any time, just as with CRDA. I've given this some more thought and while I think it is simply brain dead to require a build from source to produce a binary with exactly the same output except the signature I understand that asking for an exception to rule on Debian based on common sense is still likely more difficult to address than doing the temporary key thing and building CRDA and wireless-regdb together as Fedora does. I'll give that a shot next on my next break. Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Fri, Feb 5, 2010 at 12:09 PM, Luis R. Rodriguez mcg...@gmail.com wrote: On Thu, Feb 4, 2010 at 4:25 PM, Luis R. Rodriguez mcg...@gmail.com wrote: On Thu, Feb 4, 2010 at 6:03 AM, Kel Modderman k...@otaku42.de wrote: On Thursday 04 February 2010 11:42:33 Luis R. Rodriguez wrote: On Mon, Feb 1, 2010 at 6:10 PM, Paul Wise p...@debian.org wrote: On Mon, 2010-02-01 at 09:58 -0800, Luis R. Rodriguez wrote: I can help with this only if no one else is up for it. I personally however find building a key on the fly for each build pretty pointless and would like to know if a package would be acceptable upstream on Debian if OpenSSL is used to allow administrators to add their own keys into the /etc/wireless-regdb/pubkeys/ dir for CRDA and from the start only trust John's key. As part of upstream, you're probably the best person to do the packaging stuff for Debian. OK, in that case here is my first shot at this. http://wireless.kernel.org/download/wireless-regdb/debs/ http://wireless.kernel.org/download/crda/debs/ Tim -- notice both packages have a Replaces: wireless-crda. If debian upstreams both packages then I think it would be good to separate the packages as I am recommending for integration on Debian and for Ubuntu to also use the same debian packages as debian. I think this would mean also having the new Ubuntu kernels depend on these new packages instead of the old wireless-crda. The package is very simple, I took what I could from Kel's work but did leave in the signature check stuff, used openssl and also just used cdbs. The wireless-regdb does not change *that* often so I do not expect debian itself to need a custom regulatory database to be automatically built and propagated so I left all the watch stuff out and can do manual updates for now, I can commit to that for now. If that is a requirement however, I am not that familiar with new package policies and am unclear how to do that. I would prefer if we can get something started and uploaded for now which at least meets the requirements for integration into an eventual stable release, but that's just me. Please review and let me know what you think. These demonstrate that most of what I've attempted to explain about the difficulties of getting this software into the Debian software pool in a maintainable form has been taken lightly. To reiterate what I think is most important: The software should be built from its preferable form of modification to produce the resulting binary. What's the point? This helps to make the source package available to other developers to modify and rebuild without invasive packaging changes. The source will always be available and users can themselves apt-get source wireless-regdb and compile their own regdb at any time, just as with CRDA. I've given this some more thought and while I think it is simply brain dead to require a build from source to produce a binary with exactly the same output except the signature I understand that asking for an exception to rule on Debian based on common sense is still likely more difficult to address than doing the temporary key thing and building CRDA and wireless-regdb together as Fedora does. I'll give that a shot next on my next break. 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 Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Thu, Feb 4, 2010 at 6:03 AM, Kel Modderman k...@otaku42.de wrote: On Thursday 04 February 2010 11:42:33 Luis R. Rodriguez wrote: On Mon, Feb 1, 2010 at 6:10 PM, Paul Wise p...@debian.org wrote: On Mon, 2010-02-01 at 09:58 -0800, Luis R. Rodriguez wrote: I can help with this only if no one else is up for it. I personally however find building a key on the fly for each build pretty pointless and would like to know if a package would be acceptable upstream on Debian if OpenSSL is used to allow administrators to add their own keys into the /etc/wireless-regdb/pubkeys/ dir for CRDA and from the start only trust John's key. As part of upstream, you're probably the best person to do the packaging stuff for Debian. OK, in that case here is my first shot at this. http://wireless.kernel.org/download/wireless-regdb/debs/ http://wireless.kernel.org/download/crda/debs/ Tim -- notice both packages have a Replaces: wireless-crda. If debian upstreams both packages then I think it would be good to separate the packages as I am recommending for integration on Debian and for Ubuntu to also use the same debian packages as debian. I think this would mean also having the new Ubuntu kernels depend on these new packages instead of the old wireless-crda. The package is very simple, I took what I could from Kel's work but did leave in the signature check stuff, used openssl and also just used cdbs. The wireless-regdb does not change *that* often so I do not expect debian itself to need a custom regulatory database to be automatically built and propagated so I left all the watch stuff out and can do manual updates for now, I can commit to that for now. If that is a requirement however, I am not that familiar with new package policies and am unclear how to do that. I would prefer if we can get something started and uploaded for now which at least meets the requirements for integration into an eventual stable release, but that's just me. Please review and let me know what you think. These demonstrate that most of what I've attempted to explain about the difficulties of getting this software into the Debian software pool in a maintainable form has been taken lightly. To reiterate what I think is most important: The software should be built from its preferable form of modification to produce the resulting binary. What's the point? This helps to make the source package available to other developers to modify and rebuild without invasive packaging changes. The source will always be available and users can themselves apt-get source wireless-regdb and compile their own regdb at any time, just as with CRDA. An alternative approach: http://sidux.net/kelmo/sidux/crap/crda/crda_1.1.1-1.dsc I think I must just suck at packaging modern debian packages, can you elaborate a little on what this adds, I can't tell. Also, it seems that the REGDB_CHANGED stuff in wireless-regdb/Makefile does not work as expected - the sha1sum.txt file possibly contains the hash from an old db.txt Yeah, John -- can you please run: sha1sum db.txt sha1sum.txt and commit that? Maybe there is a way to add it as a hook to git commit? Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Thu, Feb 4, 2010 at 4:43 PM, John W. Linville linvi...@tuxdriver.com wrote: On Thu, Feb 04, 2010 at 04:25:53PM -0800, Luis R. Rodriguez wrote: Also, it seems that the REGDB_CHANGED stuff in wireless-regdb/Makefile does not work as expected - the sha1sum.txt file possibly contains the hash from an old db.txt Yeah, John -- can you please run: sha1sum db.txt sha1sum.txt and commit that? Maybe there is a way to add it as a hook to git commit? I can just put it into the Makefile. Anyway, what is REGDB_CHANGED supposed to be doing? It detects to see if you have edited db.txt and if so, it should build your own key and stuff. Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Mon, Feb 1, 2010 at 6:10 PM, Paul Wise p...@debian.org wrote: On Mon, 2010-02-01 at 09:58 -0800, Luis R. Rodriguez wrote: I can help with this only if no one else is up for it. I personally however find building a key on the fly for each build pretty pointless and would like to know if a package would be acceptable upstream on Debian if OpenSSL is used to allow administrators to add their own keys into the /etc/wireless-regdb/pubkeys/ dir for CRDA and from the start only trust John's key. As part of upstream, you're probably the best person to do the packaging stuff for Debian. OK, in that case here is my first shot at this. http://wireless.kernel.org/download/wireless-regdb/debs/ http://wireless.kernel.org/download/crda/debs/ Tim -- notice both packages have a Replaces: wireless-crda. If debian upstreams both packages then I think it would be good to separate the packages as I am recommending for integration on Debian and for Ubuntu to also use the same debian packages as debian. I think this would mean also having the new Ubuntu kernels depend on these new packages instead of the old wireless-crda. The package is very simple, I took what I could from Kel's work but did leave in the signature check stuff, used openssl and also just used cdbs. The wireless-regdb does not change *that* often so I do not expect debian itself to need a custom regulatory database to be automatically built and propagated so I left all the watch stuff out and can do manual updates for now, I can commit to that for now. If that is a requirement however, I am not that familiar with new package policies and am unclear how to do that. I would prefer if we can get something started and uploaded for now which at least meets the requirements for integration into an eventual stable release, but that's just me. Please review and let me know what you think. Also, a slightly related change is to change the kernel configuration to disable CONFIG_WIRELESS_OLD_REGULATORY. Can someone take care of that on the debian kernel side? We don't necessarily need to wait for crda/wireless-regdb to do that. The idea was that by default there would be no Debian key installed because the text and binary databases would be unmodified. The build system would detect if Debian had patched the databases and if so generate a new key, sign the binary database with it and install the public key to the /etc/wireless-regdb/pubkeys/ dir. Debian might need to patch the database for the stable release. Thanks for all the information about how wireless card firmware and drivers interact with regulatory information. No problem. Hmmm, OK. I guess that makes sense. I imagine it will definitely be the source of some annoyance for users in the future though. Tell me about it, but changing that would mean first getting regulatory agencies to allow regulatory compliance to fall down to the user when they customize a device's regulatory settings. As it stands that is not the case so all we can do upstream for now is allow users to enhance compliance, never allow more. There is also the complexity of calibration involved in allowing new channels but that is a separate topic as well. There is also the opportunity for user-based advocacy for change in the regulations. Whenever someone comes to the kernel wireless folks with a situation where they have been prevented from connecting to a wireless network because of restrictive wireless regulatory data, explain the issue and give them a form letter they can send to their local regulatory agency complaining about the situation and suggesting change. A list of relevant regulatory agency contact details would be useful here too I think. Sure, we'll have to write something up for that on the wiki. Ideally the manufacturer should be obligated to give users hardware that can be compliant for any level of radio license and defaults to being compliant for the default radio license for the whole population. It would then be up to individual users to comply with the relevant radio license(s). Such a situation would then turn into a much bigger enforcement problem, I guess that is the main reason it doesn't work this way. Right, I believe this ought to be the way things change for regulatory compliance in the future too. Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Fri, Jan 29, 2010 at 6:46 PM, Paul Wise p...@debian.org wrote: On Fri, 2010-01-29 at 10:54 -0800, Luis R. Rodriguez wrote: Given the OpenSSL stuff in crda 1.1.1, I don't think there are any technical roadblocks before crda/wireless-regdb can be uploaded to Debian (once the packaging implements what I suggested). Debian just needs someone to be the maintainer for it. IIRC Kel doesn't have the time. I don't really want to take on yet more packages, but I could probably offer sponsorship if Kel or others wanted to join pkg-wpa to do the work. Someone on the Debian kernel team might also be willing to do either sponsoring or maintainer-ship on this. Please note that the Debian freeze for the squeeze release is planned for March, so this stuff needs to be done soon. I can help with this only if no one else is up for it. I personally however find building a key on the fly for each build pretty pointless and would like to know if a package would be acceptable upstream on Debian if OpenSSL is used to allow administrators to add their own keys into the /etc/wireless-regdb/pubkeys/ dir for CRDA and from the start only trust John's key. Any idea what proportion of wireless card firmware will respect what Linux and crda tell it? All wireless drivers respect this, regardless of if you have firmware or not. Cool, but I would imagine ultimately it is up to the firmware to decide if it will use its own regulatory data or trust what Linux says? We have no way of overriding what firmware says, but in-kernel drivers do follow cfg80211 regulatory data so if cfg80211 says to disallow channel 13 because a user said so the driver will respect that. The regulatory API provided cfg80211 allows for drivers which have their own regulatory data to inform cfg80211 of this, whether that is that the device was designed for a specific country or it has a custom world regulatory domain. In terms of actual use cases currently all cfg80211 drivers (and therefore all mac80211 drivers) adhere to the regulatory domain that cfg80211 is using. Only a few drivers actually pass along regulatory information to cfg80211 for regulatory purposes. Those drivers are ath5k, ath9k, zd1211rw, ar9170. zd1211rw just passes a country for a few select possible countries it has allowed on the EEPROM. all other Atheros drivers (ath5k, ath9k, ar9170) all share the same EEPROM regulatory information and can either world roam, be part of a country region, or specifically be marked for one country. I have tried documenting this as best as possible here: http://wireless.kernel.org/en/users/Drivers/ath/ In short, most Atheros cards (95%) world roam, as such follow the its own custom world regulatory domain. The different custom world regulatory domains are documented on the wiki. All Intel cards world roam. Actually all wireless drivers do benefit from it. Note that all new wireless drivers upstream are expected to be either cfg80211 based or mac80211 based, that's it. The new regulatory infrastructure is part of cfg80211 and since all mac80211 drivers are cfg80211 drivers that means *every* wireless driver benefits from this and uses it. Excellent. I should note though that some firmware already have their regulatory stuff built-in to the firmware, just as some cards are configured on their EEPROM to use only one country. In those cases the regulatory infrastructure just helps regulatory compliance further, it would never allow more channels, for instance. Hmmm, OK. I guess that makes sense. I imagine it will definitely be the source of some annoyance for users in the future though. Tell me about it, but changing that would mean first getting regulatory agencies to allow regulatory compliance to fall down to the user when they customize a device's regulatory settings. As it stands that is not the case so all we can do upstream for now is allow users to enhance compliance, never allow more. There is also the complexity of calibration involved in allowing new channels but that is a separate topic as well. Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Thu, Jan 28, 2010 at 6:57 PM, Paul Wise p...@debian.org wrote: [Please keep me in CC for this thread] There is a technical change coming in Debian that may mean one key for the pkg-wpa folks will be more problematic; it is planned that maintainer-built .debs are to be thrown away on upload (but still required) and all packages rebuilt on the buildds. There will probably be the possibility to have exceptions though, so this may turn out to be a non-issue or less of an issue. Also, IIRC I wasn't fully happy with the way the signature stuff worked. My main issue was that the trusted RSA public keys are/were embedded into the crda binary at build time. I would have much preferred that they be split out into a set of directories. Something like /etc/crda/keys/ could be the default. This allows packages to drop new keys in and for sysadmins to also do that as needed, as well as for sysadmins to disable keys that have been compromised or similar. With the dir list and the upcoming buildd change, Debian could use something like Fedora's option; * wireless-regdb could check at build time if the source database has been modified and a new binary database been rebuilt * If so * generate a new temporary key at build time * sign the new binary database with the temporary key * install the temporary public key to /etc/crda/keys/ * throw away the temporary private key * If not * install the (unmodified) pre-built binary database I imagine the OpenSSL stuff in crda 1.1.1 would enable this kind of option. Exactly, this is already taken care of upstream with OpenSSL. The default directory is /etc/wireless-regdb/pubkeys/ In addition, crda should have a directory for the sysadmin to drop in a replacement binary database if for example they wanted to replace their distro's binary database with a newer version from John Linville. Patches for this are welcomed upstream on CRDA. Is this a requirement for Debian to package CRDA? Since the distros should install John's RSA key, new versions of the pre-built binary database would be trusted. If the sysadmin wanted to build their own binary database they would install the temporary key generated above as well as their new database. Sure. What is the point of having the CFG80211_INTERNAL_REGDB option? That sounds like a silly thing to do since there is crda and wireless-regdb. Some embedded solutions might make use of this but even today's embedded solutions like openwrt do use CRDA through userspace. The CFG80211_INTERNAL_REGDB motivational effort actually came out of the incentive to support new 2.6.32 drivers backported on older kernels which do not have generic netlink supported. If you want to backport proper CRDA support to older kernels and you will deal with proper kernel upgrades when regulatory updates are made this is a nice option. It also is a good way to finally remove the old crappy regulatory stuff we had which had only 3 static regulatory domains built in, instead now you can have properly updated static regulatory domains based on the same wireles-regdb db.txt. Since 2.6.33 isn't yet released, I assume there is time to change the behaviour of CFG80211_INTERNAL_REGDB (or remove it). Does CFG80211_INTERNAL_REGDB mean that crda will be consulted first and if it cannot be contacted, then the internal copy will be used? You mentioned the embedded world, I suppose that is the target for it? I know of no users yet of this, including on embedded systems. The way it works is it will first use the local database first and then call CRDA. If CRDA is present then it will update the regulatory information based on CRDA. Any idea what proportion of wireless card firmware will respect what Linux and crda tell it? All wireless drivers respect this, regardless of if you have firmware or not. I guess users of old wireless cards with abandoned or hard-coded firmware will not benefit from crda wireless-regdb. Actually all wireless drivers do benefit from it. Note that all new wireless drivers upstream are expected to be either cfg80211 based or mac80211 based, that's it. The new regulatory infrastructure is part of cfg80211 and since all mac80211 drivers are cfg80211 drivers that means *every* wireless driver benefits from this and uses it. The exemption then just becomes the old wireless-extensions only based drivers. Some effort by some developers has been made to start porting some of those drivers to cfg80211, the list of remaining drivers to port can be found here: http://wireless.kernel.org/en/developers/todo-list/cfg80211-conversion The other exemption is staging drivers but those are all TAINT_CRAP anyway so who the fuck cares about them. I speak here as a user of the ar6000 on the OpenMoko
Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
Hey folks, I wanted to try to help Debian in ways in which I can with the new regulatory infrastructure upstream on the Linux kernel. As of recent (= 2.6.34) the old regulatory stuff has been deprecated and replaced completely for CFG80211_INTERNAL_REGDB, the old regulatory framework was also disabled by default as of the 2.6.30 kernel release [1]. A user on linux-wireless recently reported that CONFIG_WIRELESS_OLD_REGULATORY was enabled on their debian squeeze 2.6.32 kernel [2]. I think its time for a change and wanted to help address questions and help ensure userspace is ready as well for now and in the future. I asked Kel Modderman [3] about the packages and it seems he is really busy with quite a few moves he has been doing and just lacks time to get wireless-regdb and crda packaged into Debian. I am the upstream CRDA maintainer and have already provided a sample debian/ directory for simple packaging for both wireless-regdb and CRDA. When reviewing debian packaging before though there were some technical details which needed to be ironed out over using an RSA private key to digitally sign the wireless-regdb database and then using the public key to read the and trust the key with CRDA [4]. Paul Wise also had some good feedback and I hope we have addressed it all now. Kel's last iteration consisted of creating a private/public RSA key for the pkg-wpa-devel team. Technical issue with this is the issues faced when doing automatic builds, unless you can get the automatic builds to incorporate your key somehow. Fedora seems to solves this by generating new keys on each build but always trusting John Linville's public key therefore allowing end users to download new upstream wireless-regdb binaries as well as using updates from their own repositories. Ubuntu simply packages both wireless-regdb and CRDA into one package, wireless-crda, and simply just trust John's key. That's all. As of the CRDA 1.1.1 release if you use OpenSSL you can now also dynamically read public keys at runtime, not sure if this is something that might help with packaging. As a last resort there is also the ability to just use the CFG80211_INTERNAL_REGDB that John Linville added recently but that won't be around until 2.6.34 and lacks the ability to update regulatory updates through userspace -- you'd have to provide a new kernel every time wireless regulatory updates are made, which is why we decided to move the regulatory database to userspace in the first place. I prefer to just recommend this kconfig option to embedded users. The other option is to just not use the RSA key stuff, but as noted on the documentation I advise against it as using it ensure we are doing best effort on our part in the FOSS community for the best regulatory compliance we can implement. With the RSA key stuff we get both authorship verification and file integrity checks without having to keep CRC checks around, it covers both with one solution. It is not designed to be bullet proof, anyone can hack their own regulatory database and we've even documented exactly how to do this [6] as there are real world examples for why a third party would do this, but by using the RSA key stuff we are doing best effort on ensuring authorship and file integrity prior to passing information to the kernel. We've tried to document as best as we can the new regulatory infrastructure [5], our motivation for it [6] and upstream commitment for it [7]. Please let me know if there are any questions, I'd be glad to help in any way I can. [1] http://wireless.kernel.org/en/developers/Regulatory#Old_regulatory_implementation [2] http://marc.info/?l=linux-wirelessm=126444734215577w=2 [3] http://marc.info/?l=linux-wirelessm=126468708719138w=2 [4] http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2009-May/002266.html [5] http://wireless.kernel.org/en/developers/Regulatory [6] http://wireless.kernel.org/en/developers/Regulatory#Custom_regulatory_information [7] http://wireless.kernel.org/en/vendors/VendorSupport [8] http://wireless.kernel.org/en/developers/Regulatory/statement Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558740: Push of AR9170 1-stage firmware to linux-firmware?
On Mon, Nov 30, 2009 at 06:40:38PM -0800, Geoff Simmons wrote: Hi Luis, Are you still considering a push of the AR9170 1-stage firmware to linux-firmware, as per your previous intention? [1] Well so I was hoping more people would test the GPL based firmware and instead support that [1]. But after Johannes' help with its release there hasn't been much activity on its development to try to stabilize a release. I think those of us interested just sort of have a lot of other priorities right now. [1] http://wireless.kernel.org/en/users/Drivers/ar9170.fw I don't use ar9170 on a daily basis either so I cannot say I notice any differences myself, but when I do ask Johannes who I know has tested both it seems the proprietary 1-stage firmware sometimes works and sometimes the 2-stage fw works better for him. I'm inclined to just say to prefer a build of the GPL firmware but I'm not looking at bug reports and not sure if anyone else is so I cannot commit to that. My interest is in having this packaged for the Debian distribution within its firmware-linux-nonfree package [2], which uses content in David Woodhouse's linux-firmware tree as its upstream. Lets see what Johannes and Christian think. I should note the 1-stage proprietary firmware should be technically the same as the open one but the open one had a lot of code removed we didn't need or shared. It also used gcc while the proprietary one was built with a proprietary sh2 compiler/linker. On a related note, I have not encountered issues with use of 1-stage firmware on my AR9170-based device (a Netgear WNDA3100), when compared with the 2-stage firmware. I'd encourage to test out the open firmware. Thank you for your time. Geoff [1] http://marc.info/?l=linux-wirelessm=125122858824049w=2 [2] http://bugs.debian.org/558740 Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481234: Where to get firmware for p54 driver?
On Sat, May 17, 2008 at 4:19 AM, Sam Morris s...@robots.org.uk wrote: Does anyone know where the firmware for the p54 driver comes from? It seems to live at http://prism54.org/firmware/, but there is no statement about the origin of those files, nor their copyright or licensing status. I've tried contacting the owners of that site, but only received bounces/silence. I can speak only for the firmware for the FullMAC chipsets. I had made a collection from the windows drivers. Intersil at that time was very aware of the website and never received any complaints so I took it hosting the firmware alone was OK. I take it the SoftMAC driver guys took the same approach. Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
