iw package (Was: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda)
Hello, 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. $ apt-cache show iw Package: iw Priority: extra Section: net Installed-Size: 120 Maintainer: Debian/Ubuntu wpasupplicant Maintainers pkg-wpa-de...@lists.alioth.debian.org Architecture: amd64 Version: 0.9.14-1 Depends: libc6 (= 2.3), libnl1 (= 1.1) Conflicts: aircrack-ng ( 1:1.0~rc2-1) Filename: pool/main/i/iw/iw_0.9.14-1_amd64.deb Size: 30602 MD5sum: 8c04be8f94b178d0c3f6a2c8b95ed994 SHA1: 7cdf4372b119a89f27132b9453d7d93e4715ce77 SHA256: fa1ad798b631b3f3b7f0ad02a1d99db678746706117e794c540af4b63f4b7910 Description: tool for configuring Linux wireless devices This package contains the `iw' tool which allows you to configure and show information about wireless networking. . In the future iw will become the canonical command line tool for wireless configuration and iwconfig/wireless-tools will no longer be required. See /usr/share/doc/iw/README.Debian for a more detailed overview of iw. Homepage: http://wireless.kernel.org/en/users/Documentation/iw Tag: implemented-in::c, network::configuration, role::program, use::configuring so it exists, but for now this isn't installed by default. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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/20100304105523.ge5...@pengutronix.de
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, 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. 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. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Sat, Feb 27, 2010 at 01:43:46PM -0800, Luis R. Rodriguez wrote: 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? The point is that upstream are already maintaining a ChangeLog with git and it'd be nice if they included that in the release tarballs (which don't include the git history) by doing git2cl or git log or whatever in 'make dist' when they create the tarball. The NEWS file is a separate, hand-maintained file summarising user-visible changes between different releases. Thanks, I understand now. I just downloaded git2cl: http://josefsson.org/git2cl/git2cl I'll include some ChangeLog for the next release. Its up to John if he wants to use that as well, he maintains wireless-regdb while I maintain crda. The current Debian package puts these two together though so something custom is required anyway for now. 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. Do you like that git2cl output? It seems rather ugly to me... John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- 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/20100301154701.gc2...@tuxdriver.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
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
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. Thanks, Kel. -- 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/201003020750.58757@otaku42.de
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
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. I agree with Kel here, git2cl et al are unimportant details. Kel, mail me in private when you have something ready for review upload, as usual. Regards, Faidon -- 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/4b8c7b7c.5010...@debian.org
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
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. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
[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: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
Luis R. Rodriguez wrote: 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 I'm a member of pkg-wpa-devel and I've been sponsoring Kel for almost 4 years. I have absolute trust in him and I've even offered to advocate him to the NM process multiple times. I'd be happy to review and sponsor the uploads of crda/wireless-regdb, if Paul doesn't have a problem with this. I usually prefer team maintenance, so I think it'd be best if this happened in pkg-wpa; my offer to sponsor is independent of that, though. Regards, Faidon -- 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/4b8995b6.5000...@debian.org
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Sat, 2010-02-27 at 23:59 +0200, Faidon Liambotis wrote: I'm a member of pkg-wpa-devel and I've been sponsoring Kel for almost 4 years. I have absolute trust in him and I've even offered to advocate him to the NM process multiple times. I'd definitely agree with your assessment here and would also encourage Kel to apply for NM. I'd be happy to review and sponsor the uploads of crda/wireless-regdb, if Paul doesn't have a problem with this. Definitely no problem there. I usually prefer team maintenance, so I think it'd be best if this happened in pkg-wpa; my offer to sponsor is independent of that, though. Agreed, whoever wants to help maintain this should join pkg-wpa. So, summary of the main issues with Kel's current package: He doesn't have time to maintain it and needs folks to join pkg-wpa, take ownership of the crda RFP (#536502) and work to get both crda and wireless-regdb uploaded. It combines crda wireless-regdb into one source package. While upstream keeps them separate, we should do the same. A few other issues that are easy to fix: http://lists.debian.org/debian-kernel/2010/02/msg00336.html -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
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. 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. 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? I guess that means Fedora, Gentoo, Ubuntu etc all need to do the same thing. 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 didn't investigate too closely though. 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? The point is that upstream are already maintaining a ChangeLog with git and it'd be nice if they included that in the release tarballs (which don't include the git history) by doing git2cl or git log or whatever in 'make dist' when they create the tarball. The NEWS file is a separate, hand-maintained file summarising user-visible changes between different releases. 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. Once it is uploaded, I'll be sure to file a bug asking for it to be added as a recommends of the Linux image packages, thanks for the advice. 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. Please let me know if there is anything I can do to help upstream wise to help get this packaged up into Debian. Hmm, not really sure. We have processes to request help for stuff already in Debian, but not really anything for new packages that no-one . You could try emailing the debian-devel list asking for
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 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. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- 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/20100218181435.ga3...@tuxdriver.com
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 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. 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. 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. 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). 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. 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 I assume that the Debian installer should definitely install crda/wireless-regdb on systems that have a wireless card. Should it also be installed on other systems by default, in case a wireless card gets installed? 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. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
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. This helps to make the source package available to other developers to modify and rebuild without invasive packaging changes. An alternative approach: http://sidux.net/kelmo/sidux/crap/crda/crda_1.1.1-1.dsc 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 Thanks, Kel. -- 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 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? -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- 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 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. 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. 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. 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. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
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
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Fri, 2010-01-29 at 10:54 -0800, Luis R. Rodriguez wrote: Exactly, this is already taken care of upstream with OpenSSL. The default directory is /etc/wireless-regdb/pubkeys/ Excellent. Patches for this are welcomed upstream on CRDA. Is this a requirement for Debian to package CRDA? No, that was just my personal opinion. 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. 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. OK, I guess that sounds reasonable. 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. Great. 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? 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. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
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
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Friday 29 January 2010 04:10:04 Luis R. Rodriguez wrote: 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. I mistakingly overlooked, when writing [3], that wireless-regdb is arch independent and thus does not get rebuilt upon upload (at least for now, but this may possibly change in the future). The issue is more that : There are potentially lots of people who could be building/uploading these packages and having the same private key for all people to sign regulatory.bin may not be feasible. Generating a one time private key requires that wireless-regdb and crda are built in the same sourceful upload afaik. Just installing the prebuilt regulatory.bin doesn't feel very Debian, I am pretty sure Debian would like to build that binary from its source and reserve the right to patch that source and rebuild the binary for a variety of reasons. Thanks, Kel. -- 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 06:11:50AM +1000, Kel Modderman wrote: There are potentially lots of people who could be building/uploading these packages and having the same private key for all people to sign regulatory.bin may not be feasible. Generating a one time private key requires that wireless-regdb and crda are built in the same sourceful upload afaik. I think you've identified the nut of the problem. AFAICT, you need to pick either one of the above options or you need to accept using an unsigned regulatory.bin. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- 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
[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. 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. 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. 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. 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? Any idea what proportion of wireless card firmware will respect what Linux and crda tell it? I guess users of old wireless cards with abandoned or hard-coded firmware will not benefit from crda wireless-regdb. I speak here as a user of the ar6000 on the OpenMoko FreeRunner and a friend of people with ipw2x00-based cards on laptops. I'm using an iwl3945-based card, do you know if Intel plan to implement support for this stuff in their firmware? I thank you very much for working on this stuff. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Fri, 2010-01-29 at 10:57 +0800, Paul Wise wrote: * 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 Woops, should have read your references, it seems that something like this is already enabled by the patch from[1] that is merged upstream? 1. http://bugs.debian.org/536502 -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part
