Looking for Frans Pop, anyone know his new e-mail address?
Hey folks, I'm looking for Frans Pop elen...@planet.nl, I think he also used f...@debian.org but both e-mail addresses are bouncing... Anyone know his new e-mail address? Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAB=NE6Vd4KwNwa+FK5d2OdQq-whFELmdzDvHFD9gAa=ptpc...@mail.gmail.com
Re: Looking for Frans Pop, anyone know his new e-mail address?
On Fri, Dec 9, 2011 at 3:25 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Hey folks, I'm looking for Frans Pop elen...@planet.nl, I think he also used f...@debian.org but both e-mail addresses are bouncing... Anyone know his new e-mail address Thanks for the hint, unfortunately I was informed Frans Pop passed away: http://www.debian.org/News/2010/20100831 Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAB=NE6VLPUSBLdbDcbT02z4h8=gp6+plv8avduzayyx5w4x...@mail.gmail.com
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Wed, Mar 3, 2010 at 9:05 PM, Ben Hutchings b...@decadent.org.uk wrote: On Wed, 2010-03-03 at 17:51 -0800, Luis R. Rodriguez wrote: On Wed, Mar 3, 2010 at 3:50 PM, Peter Samuelson pe...@p12n.org wrote: [Luis R. Rodriguez] 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? It's available (version 0.9.14), but not shipped by default. Can it? Depends on what you mean by 'default'. Wherever iwconfig ships, so should iw, not sure where iwconfig ships by default on Debian. I think there's a good case for including it in the 'laptop' task, but not in the standard system (desktops and servers generally don't need it). It should also be upgraded to 'optional' priority. I see thanks, that makes sense, is that also the case for wireless-tools? Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/43e72e891003040001s1f0cb88m3fbd5243dbc4e...@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-devel-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 Wed, Mar 3, 2010 at 3:50 PM, Peter Samuelson pe...@p12n.org wrote: [Luis R. Rodriguez] 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? It's available (version 0.9.14), but not shipped by default. Can it? Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/43e72e891003031751uf0965a0o427708d86976a...@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-devel-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: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 9:59 PM, Paul Wise p...@debian.org wrote: On Thu, Mar 26, 2009 at 1:19 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Brainwave: no need to add a second public key to CRDA itself, the wireless-regdb could install the public key corresponding to the private key it was built with. Can you elaborate on what you mean? Do you mean for wireless-regdb to put the actual pubkey into the users' system somewhere? Otherwise not sure what you mean. The crda package would contain the default upstream public key. The wireless-regdb would ship the Debian maintainer's pubkey as debian/pubkeys/debian.pem in the source package and /lib/crda/pubkeys/debian.pub.pem (or similar) in the binary package. Ubuntu would add their pubkey in a similar way. When wireless-regdb is built, it would: check the sha1sum/sha256sum of db.txt (alternatively upstream could add a detached signature if possible to the tarball/git repo) if the db.txt is identical to the upstream one (or signed by upstream), ship the upstream regulatory.bin file if the db.txt has been modified: if no private key is available, generate one automatically rebuild the regulatory.bin file using the private key create the corresponding public key and install it in the package as /lib/crda/pubkeys/custom.pub.pem when it is not the same public key as one of the ones in debian/pubkeys/*.pem (avoids shipping two copies of the Debian pubkey) this scheme requires standard locations for the private key. I would suggest either ~/.debian-wireless-regdb.priv.pem or debian-wireless-regdb.priv.pem in the package build directory. It is possible for users to add more public keys to the CRDA pubkeys dir and build their own wireless-regdb using their own private key. The above simplification makes this much easier. Not sure what you mean, but the idea with the pubkeys directory The above scheme would allow users who apt-get source wireless-regdb, edit db.txt, debuild, debi to automatically trust their own key, as well as trusting Debian's key and the upstream key. I wonder if any of this would be even remotely acceptable to regulatory authorities. Thanks for the ideas, will post patches for this. Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Tue, Mar 24, 2009 at 11:44 PM, Kalle Valo kalle.v...@iki.fi wrote: Luis R. Rodriguez mcg...@gmail.com writes: As a lot of you know we have a new regulatory implementation for Linux wireless now [1]. We have kept the old regulatory implementation through a Kconfig option, CONFIG_WIRELESS_OLD_REGULATORY. Distributions are slowly converging to start setting this to N -- as of 2.6.28. Distributions are also now shipping wireless-regdb [2] and CRDA [3]. Just of curiosity, what's happening with crda in debian? I still don't see them in debian unstable. I just found iw version 0.9.9-nogit in unstable, though. So things are going forward. Last time I poked them it seemed it was not easy to figure out how to deal with, if at all, the optional but recommended RSA signature stuff [1] with the DFSG. [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 12:39 AM, Paul Wise p...@debian.org wrote: On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Last time I poked them it seemed it was not easy to figure out how to deal with, if at all, the optional but recommended RSA signature stuff [1] with the DFSG. [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature What is the percieved DFSG/RSA conflict? I can't detect any based on that section of the page. Thanks Paul, then its just a matter of packaging. There is an debian-example/ directory with a cdbs example of how to package for wireless-regdb and crda if anyone is up for it. Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 12:47 AM, Luis R. Rodriguez mcg...@gmail.com wrote: On Wed, Mar 25, 2009 at 12:39 AM, Paul Wise p...@debian.org wrote: On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Last time I poked them it seemed it was not easy to figure out how to deal with, if at all, the optional but recommended RSA signature stuff [1] with the DFSG. [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature What is the percieved DFSG/RSA conflict? I can't detect any based on that section of the page. Thanks Paul, then its just a matter of packaging. There is an debian-example/ directory with a cdbs example of how to package for wireless-regdb and crda if anyone is up for it. And as its probably best to coordinate with Ubuntu, they have a wireless-crda package which combines both into one package. Its shipping for Jaunty. Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 10:37 AM, Kel Modderman k...@otaku42.de wrote: On Wednesday 25 March 2009 17:51:41 Luis R. Rodriguez wrote: On Wed, Mar 25, 2009 at 12:47 AM, Luis R. Rodriguez mcg...@gmail.com wrote: On Wed, Mar 25, 2009 at 12:39 AM, Paul Wise p...@debian.org wrote: On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Last time I poked them it seemed it was not easy to figure out how to deal with, if at all, the optional but recommended RSA signature stuff [1] with the DFSG. [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature What is the percieved DFSG/RSA conflict? I can't detect any based on that section of the page. Thanks Paul, then its just a matter of packaging. There is an debian-example/ directory with a cdbs example of how to package for wireless-regdb and crda if anyone is up for it. The example packaging needs some love, I think. I don't see it as a great reference to the eventual packaging material that would enter Debian. And as its probably best to coordinate with Ubuntu, they have a wireless-crda package which combines both into one package. Its shipping for Jaunty. And that's the only way to sanely package it (by combining the two pieces upstream splits) as show by Fedora also choosing that route. Well I actually disagree. Luis why can't CRDA and regd simply be released in same tarball considering they have such a strong relationship with eachother due to the openssl stuff? Openssl stuff is optional and in fact not the lib chosen by default, libgcrypt is the default though. The point is that crda won't be updated regularly but the wireless-regdb will be. No point in updating a binary when only the file it reads is the one that changes. Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 12:03 PM, Paul Wise p...@debian.org wrote: On Thu, Mar 26, 2009 at 3:42 AM, Kel Modderman k...@otaku42.de wrote: The DFSG seems to suggest that the source code to the regulatory database should be modifiable and the derived work distributed under the same license. It is my understanding that: Debian probably won't need to build the regdb from source most of the time so we can just ship the upstream regulatory.bin file most of the time. Yes, that is the case. The user who would modify these rules for example would be people doing experiments, research, or maintaining their own db for some sort of custom hardware with specifically licensed regulatory information. When we do, just adding a second public key to the CRDA pubkeys dir and using the corresponding private key (from outside the package) during the build process of wireless-regdb would be just fine. Yes, this is the case. This would mean the maintainer of crda would also have to be the wireless-regdb maintainer. Actually technically it could be a different person. I maintain crda upstream and John maintains wireless-regdb upstream, for example. I just need John's pubkey file which is non-binary. CRDA just reads the regulatory.bin which wireless-regdb provides. I assume the wireless-regdb is architecture-independent so this would work because the buildds do not build such packages. This is correct. You do need a regulatory.bin installed first though so that if crda is built with the RSA digital signature check part of its build process is to ensure the signature checks out against the currently installed regulatory.bin file on your system. But that's just because a sanity check is part of the default target on the Makefile. It is possible for users to add more public keys to the CRDA pubkeys dir and build their own wireless-regdb using their own private key. Affirmative. Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 1:25 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Actually technically it could be a different person. I maintain crda upstream and John maintains wireless-regdb upstream, for example. I just need John's pubkey file which is non-binary. CRDA just reads the regulatory.bin which wireless-regdb provides. Let me be a little bit more clear on this last sentence. By provides I mean that John generated his pubkey using it and then e-mailed it to me. I then just merged it as part of CRDA so that by default CRDA trusts the regulatory.bin files he puts out. Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 8:08 PM, Paul Wise p...@debian.org wrote: On Thu, Mar 26, 2009 at 4:03 AM, Paul Wise p...@debian.org wrote: When we do, just adding a second public key to the CRDA pubkeys dir and using the corresponding private key (from outside the package) during the build process of wireless-regdb would be just fine. This would mean the maintainer of crda would also have to be the wireless-regdb maintainer. I assume the wireless-regdb is architecture-independent so this would work because the buildds do not build such packages. Brainwave: no need to add a second public key to CRDA itself, the wireless-regdb could install the public key corresponding to the private key it was built with. Can you elaborate on what you mean? Do you mean for wireless-regdb to put the actual pubkey into the users' system somewhere? Otherwise not sure what you mean. It is possible for users to add more public keys to the CRDA pubkeys dir and build their own wireless-regdb using their own private key. The above simplification makes this much easier. Not sure what you mean, but the idea with the pubkeys directory when building CRDA is it lets you add more keys to CRDA so it can use regulatory.bin from multiple trusted parties. A small example is a distribution can decide to use their own pubkey and also leave John's in the pubkeys/ directory. This allow the user to then install and actually use the distribution's release of wireless-regdb while also enabling the users to upgrade to John's latest regulatory.bin themselves whenever they feel like it either manually or using the upstream package. Of course if the distribution keeps up with these then there is no need for the user to be doing any of this. Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Packaging of a few new wireless packages
I'd like to help get a few new wireless userspace applications packaged into Debian unstable. Here are the new ones: * iw * crda * wireless-regdb iw is used to configure new cfg80211 based wireless drivers (all mac80211 drivers for example). wireless-regdb contains the wireless regulatory database we have moved out to userspace and crda is the udev helper which reads this database and sends regulatory domains to the kernel. Its best to separate crda and wireless-regdb as wireless-regdb can be updated while crda remains intact. I have an example debian/ dir using cdbs for each of these. Please let me know if someone is willing to review it so we can throw it into unstable soon. I *really* would prefer to *not* become the maintainer of these packages though so am hoping someone can take it up to keep them brushed up and updated. They all have respective man pages so it would require less effort :D http://wireless.kernel.org/en/users/Documentation/iw http://wireless.kernel.org/en/developers/Regulatory Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Problems packaging a kernel using cdbs
On 3/19/07, Goswin von Brederlow [EMAIL PROTECTED] wrote: Luis R. Rodriguez [EMAIL PROTECTED] writes: On 3/16/07, Roberto C. Sanchez [EMAIL PROTECTED] wrote: On Fri, Mar 16, 2007 at 01:50:14PM -0400, Luis R. Rodriguez wrote: I've seen some posts on debian-devel from a while back which indicates some of you (Robert Millan) you've build a kernel using cdbs. I'm Perhaps I misunderstand, but can't you use kernel-package? My goal is to actually generate a debian package which will have a very small x86 kernel and a very very custom initramfs (bundles of software) for a PXE boot environment. Kernel-package lets me build a debian package out of the kernel source tree, but I want to do something a bit different. I just looked into kernel-package's support for generating custom initramfs cpio archives but it really lacks documentation even on the source. I then checked out initramfs-tools but just installing this package makes it spin an generate an initramfs for me on /boot/ without even consulting...; then I read the man page for mkinitramfs and I see this: --- At boot time, the kernel unpacks that archive into RAM disk, mounts and uses it as initial root file system. All finding of the root device hap- pens in this early userspace. -- initramfs is not an archive that gets put into a RAM disk, the ramdisk is only used by initrd... the new design of initramfs replaces that whole mess and takes advantage of the new tmpfs filesystem. The fact that the man page has it wrong doesn't make me want to touch that in any way. Actualyl I think the manpage is right. The archive gets put into the ramdisk as that is how the bootloader passes the data along. The initramfs code then checks for the achive signature in the ramdisk, unpacks it to tmpfs and frees the ramdisk. That is similar to the initrd code looking at the ramdisk, finding the gzip signature and uncompressing it into the actual rmadisk. Nope, its very wrong. You do not need ramdisk support to support initramfs at all, we don't use ramdisk in any way. By default, meaning its supported without regard to your .config, the cpio archive gets packed into the kernel and later always extracted into rootfs. In fact the entire block layer can be removed, which is required by ramdisk support, and you will still get initramfs support, even if you want external initramfs support (ie, grub initrd line). I have a patch that'll allow you to get external initramfs support even if you do not want the block layer, currently it doesn't because of the layout of Kconfig, but its supposed to though, it works and I have tested it. Anyway -- I just tried to use make-kpkg build as the build commands for my kernel target and still run into the same problem. Running make-kpkg build manually works though. So there is something about using cdbs that is not letting me build the kernel right. The include path gets (./include) is getting ignored completely for some reason. Luis Please do use make-kpkg. If you need something in kernel-package to change for your use case (like building the initrd during compile) then please talk to the maintainer to support this. It is a bad Idea to duplicate the kernel building and packaging. It is bad enough linux-2.6 source has started to do that. It does not do what I want it to right now and I need to move on quick. I've adopted my own debian/rules instead of cdbs as well. Perhaps if I have time I'll hack on make-kpkg. Thanks, Luis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Problems packaging a kernel using cdbs
I've seen some posts on debian-devel from a while back which indicates some of you (Robert Millan) you've build a kernel using cdbs. I'm trying to do the same but ran into issues. My kernel is simple though, no modules, just the kernel. The problem I am running into is I have a target kernel in my Makefile which builds the kernel correctly when I run make kernel manually, however trying to build the debian package fails in the same target complaining it cannot find header files for when building the first target which relies on a file which includes headers from include/linux. The target it fails at is arch/i386/kernel/asm-offsets.s This relies on arch/i386/kernel/asm-offsets.c which includes files from include/linux. If you'd like to see what I'm talking about here is a sample minimal package which demos what I am talking about: http://ruslug.rutgers.edu/~mcgrof/cdbs/foo-0.1.tar.bz2 Running make kernel will work but debuild fails. My debian/rules looks like this: #!/usr/bin/make -f include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/makefile.mk Any advice on how to move forward is greatly appreciated. Luis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems packaging a kernel using cdbs
On 3/16/07, Roberto C. Sanchez [EMAIL PROTECTED] wrote: On Fri, Mar 16, 2007 at 01:50:14PM -0400, Luis R. Rodriguez wrote: I've seen some posts on debian-devel from a while back which indicates some of you (Robert Millan) you've build a kernel using cdbs. I'm Perhaps I misunderstand, but can't you use kernel-package? My goal is to actually generate a debian package which will have a very small x86 kernel and a very very custom initramfs (bundles of software) for a PXE boot environment. Kernel-package lets me build a debian package out of the kernel source tree, but I want to do something a bit different. I just looked into kernel-package's support for generating custom initramfs cpio archives but it really lacks documentation even on the source. I then checked out initramfs-tools but just installing this package makes it spin an generate an initramfs for me on /boot/ without even consulting...; then I read the man page for mkinitramfs and I see this: --- At boot time, the kernel unpacks that archive into RAM disk, mounts and uses it as initial root file system. All finding of the root device hap- pens in this early userspace. -- initramfs is not an archive that gets put into a RAM disk, the ramdisk is only used by initrd... the new design of initramfs replaces that whole mess and takes advantage of the new tmpfs filesystem. The fact that the man page has it wrong doesn't make me want to touch that in any way. Anyway -- I just tried to use make-kpkg build as the build commands for my kernel target and still run into the same problem. Running make-kpkg build manually works though. So there is something about using cdbs that is not letting me build the kernel right. The include path gets (./include) is getting ignored completely for some reason. Luis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Status of this ITP?
Its been more than a year now. What's the status of this ITP? This is ridiculous. If you can't package it, then say so so others can come in and do the job. We deserve a freedesktop.org package by now in debian. Get off your ass. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E pgp2sc12YUKkt.pgp Description: PGP signature
Re: Status of this ITP?
On Wed, Dec 08, 2004 at 05:21:56PM +, David Pashley wrote: On Dec 08, 2004 at 17:15, Luis R. Rodriguez praised the llamas by saying: Its been more than a year now. What's the status of this ITP? This is ridiculous. If you can't package it, then say so so others can come in and do the job. We deserve a freedesktop.org package by now in debian. Get off your ass. This is an ITP for KDrive, the experimental xserver. It is not the X.org xserver. I'm not sure this is what you think it is. I appriciate that english may not be your first language, but the tone of the email was not exactly friendly. People work on Debian because they want to. Having people shout at them isn't the best incentive to get them to do voluntary work. David, thanks for the prompt e-mail. The goal of my e-mail was to get us off our asses and get a debian xorg package out. Today I realized there wasn't one available and that just pissed me off. I won't appoologize for my tone as I feel we shouldn't settle. What's the right ITP then, 220347? Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E pgpxBTPVyClLD.pgp Description: PGP signature
Re: Status of this ITP?
On Wed, Dec 08, 2004 at 06:41:35PM +0100, Jose Carlos Garcia Sogo wrote: El mi??, 08-12-2004 a las 12:30 -0500, Luis R. Rodriguez escribi??: On Wed, Dec 08, 2004 at 05:21:56PM +, David Pashley wrote: On Dec 08, 2004 at 17:15, Luis R. Rodriguez praised the llamas by saying: Its been more than a year now. What's the status of this ITP? This is ridiculous. If you can't package it, then say so so others can come in and do the job. We deserve a freedesktop.org package by now in debian. Get off your ass. This is an ITP for KDrive, the experimental xserver. It is not the X.org xserver. I'm not sure this is what you think it is. I appriciate that english may not be your first language, but the tone of the email was not exactly friendly. People work on Debian because they want to. Having people shout at them isn't the best incentive to get them to do voluntary work. David, thanks for the prompt e-mail. The goal of my e-mail was to get us off our asses and get a debian xorg package out. Today I realized there wasn't one available and that just pissed me off. I won't appoologize for my tone as I feel we shouldn't settle. Please read X-Strike force FAQ[1] first. The relevant link is: http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xhtml#debianplans But to target a bit closer: As of this writing (October 2004), packaging of the X.Org distribution is underway in the X Strike Force's xorg Subversion repository (ViewCVS[2]) Please help packaging this, not whining about packages not being ready. [1]http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xhtml [2]http://necrotic.deadbeast.net/cgi-bin/viewcvs.cgi/?root=xorg Carlos, Damsel in distress voice My hero /Damsel in distress voice Thanks so much, Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E pgp7SVbNNLDVm.pgp Description: PGP signature
Accepted grub-splashimages 1.0 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 06 Jul 2004 23:50:48 -0400 Source: grub-splashimages Binary: grub-splashimages Architecture: source all Version: 1.0 Distribution: unstable Urgency: low Maintainer: Grub-Devel List [EMAIL PROTECTED] Changed-By: Luis R. Rodriguez [EMAIL PROTECTED] Description: grub-splashimages - a collection of great GRUB splashimages Closes: 266071 Changes: grub-splashimages (1.0) unstable; urgency=low . * Put a collection of splashimages into a debian package (closes: #266071) Files: 6c4c9739dc5663f99e33f969690e8090 605 admin optional grub-splashimages_1.0.dsc 8e90d08662373da9998114a78627a7d8 291396 admin optional grub-splashimages_1.0.tar.gz 2d6b6ed9045744c9a4910533b1d789ef 292350 admin optional grub-splashimages_1.0_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBIPw3C19io6rUCv8RAu+bAJ42RZgjmjhdbteX3gFGMPzniV3BjgCfX851 r/uVTid6C3qHXdvRu7o/mTQ= =Jjdx -END PGP SIGNATURE- Accepted: grub-splashimages_1.0.dsc to pool/main/g/grub-splashimages/grub-splashimages_1.0.dsc grub-splashimages_1.0.tar.gz to pool/main/g/grub-splashimages/grub-splashimages_1.0.tar.gz grub-splashimages_1.0_all.deb to pool/main/g/grub-splashimages/grub-splashimages_1.0_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted grubconf 0.5.1-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 16 Aug 2004 13:09:31 -0400 Source: grubconf Binary: grubconf Architecture: source i386 Version: 0.5.1-4 Distribution: unstable Urgency: low Maintainer: Grub-Devel List [EMAIL PROTECTED] Changed-By: Luis R. Rodriguez [EMAIL PROTECTED] Description: grubconf - a Gnome2 based GNU GRUB configuration editor Closes: 260276 263648 Changes: grubconf (0.5.1-4) unstable; urgency=low . * debian/control: get rid of gcrypt7 and gnutls10 dependency. Patch submitted by Matthias Urlichs [EMAIL PROTECTED] (closes: #263648) * fix get_index_dev() on grubconf_dev.c to check for root dev names which can be larger than 4 chars, ie hda10. The fix is to check the last char (which is '\0' on smaller dev node names, thus a valid check). (closes: #260276) Files: b184d876d5c92161a449d21d3c00a059 763 admin optional grubconf_0.5.1-4.dsc 5a2ac38e11bb07346cac49930a0d2d02 6775 admin optional grubconf_0.5.1-4.diff.gz 8110fc3ab4d820ea1993ed550b69311a 87268 admin optional grubconf_0.5.1-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBIPoEC19io6rUCv8RAjAlAJoDPytqY3i90oFoUl11uvggVK6zFQCeOS9l noHIAH5uQ3f4NM4/9RER5Eg= =Z4aA -END PGP SIGNATURE- Accepted: grubconf_0.5.1-4.diff.gz to pool/main/g/grubconf/grubconf_0.5.1-4.diff.gz grubconf_0.5.1-4.dsc to pool/main/g/grubconf/grubconf_0.5.1-4.dsc grubconf_0.5.1-4_i386.deb to pool/main/g/grubconf/grubconf_0.5.1-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted grubconf 0.5.1-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 23 May 2004 00:30:00 -0500 Source: grubconf Binary: grubconf Architecture: source i386 Version: 0.5.1-3 Distribution: unstable Urgency: low Maintainer: Grub-Devel List [EMAIL PROTECTED] Changed-By: Luis R. Rodriguez [EMAIL PROTECTED] Description: grubconf - a Gnome2 based GNU GRUB configuration editor Closes: 253463 Changes: grubconf (0.5.1-3) unstable; urgency=low . * Added amd64 to arch list. (Patch by Christopher L Cheney [EMAIL PROTECTED] * Removed gcc from Depends (part of build essential, not necessary) (same patch) (closes: #253463) Files: 7493c88ee72d271ed03f0c869082b8b1 763 admin optional grubconf_0.5.1-3.dsc 40f11abb50b9c3912c7df5b71861dbd2 6399 admin optional grubconf_0.5.1-3.diff.gz 97d58edd08298378599f0f21cc7b48cb 87420 admin optional grubconf_0.5.1-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAyDJKC19io6rUCv8RAkYEAJ4gUFKcC7uQpDfydLsI4J8jOxPN4ACfSvqN BLahAUefAWYlRhW2DhiCXdw= =Pi9t -END PGP SIGNATURE- Accepted: grubconf_0.5.1-3.diff.gz to pool/main/g/grubconf/grubconf_0.5.1-3.diff.gz grubconf_0.5.1-3.dsc to pool/main/g/grubconf/grubconf_0.5.1-3.dsc grubconf_0.5.1-3_i386.deb to pool/main/g/grubconf/grubconf_0.5.1-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted grubconf 0.5.1-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 10 May 2004 02:14:44 -0400 Source: grubconf Binary: grubconf Architecture: source i386 Version: 0.5.1-2 Distribution: unstable Urgency: low Maintainer: Grub-Devel List [EMAIL PROTECTED] Changed-By: Luis R. Rodriguez [EMAIL PROTECTED] Description: grubconf - a Gnome2 based GNU GRUB configuration editor Closes: 246865 Changes: grubconf (0.5.1-2) unstable; urgency=low . * debian/control: added DEB_CONFIGURE_EXTRA_FLAGS := --enable-splashimage which fixes package build for users who do not have grub installed onto their HD as a boot loader. (closes: #246865) Files: 5bac651704f132a1811f9c3d850b4a11 762 admin optional grubconf_0.5.1-2.dsc fa770bea96ae58342d78d2261a0182ba 6268 admin optional grubconf_0.5.1-2.diff.gz 4922b4a977cdbd6c56814e3c05146964 87326 admin optional grubconf_0.5.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAxsfuC19io6rUCv8RAjU5AJ9pi6Zt1gJy89EQTmwW+33sNJTGFQCfSyES 8Gjr8hPW06TqjJidiDMkAzQ= =ywPd -END PGP SIGNATURE- Accepted: grubconf_0.5.1-2.diff.gz to pool/main/g/grubconf/grubconf_0.5.1-2.diff.gz grubconf_0.5.1-2.dsc to pool/main/g/grubconf/grubconf_0.5.1-2.dsc grubconf_0.5.1-2_i386.deb to pool/main/g/grubconf/grubconf_0.5.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted grubconf 0.5.1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Mar 2004 04:19:35 -0500 Source: grubconf Binary: grubconf Architecture: source i386 Version: 0.5.1-1 Distribution: unstable Urgency: low Maintainer: Grub-Devel List [EMAIL PROTECTED] Changed-By: Luis R. Rodriguez [EMAIL PROTECTED] Description: grubconf - a Gnome2 based GNU GRUB configuration editor Closes: 235017 235345 Changes: grubconf (0.5.1-1) unstable; urgency=low . * new grubconf release: 0.5.1 * debian/control: added scrollkeeper to Build-Depends. Fixes (closes: #235017) * debian/control: added i386 hurd-i386 freebsd-i386 netbsd-i386 to Architecture field. These match the archs for which grub is available. * removed /usr/include/grubconf/* -- unwanted * debian/control: Added Grub-Devel List [EMAIL PROTECTED] as Maintainer, added myself as Uploader * debian/rules: moved to new cdbs format * debian/control: fixed format, removed double spaces and such (closes: #235345) * debian/patches/fix-dir_attempt.diff: Fixes upstream source for when filename specified is a directory * debian/patches/fix-makeinstall.diff: Fixes upstream source for make install on debian testing/unstable * debian/patches/fix-verbose.diff: Fixes upstream source with verbose message when non-supported grub command is encountered. Files: 46dc5d717121ec9e36fb5026140f6610 762 admin optional grubconf_0.5.1-1.dsc b696b0ed30394fd945adad1ce337ac7f 365602 admin optional grubconf_0.5.1.orig.tar.gz 1b0b040e4269626cc3688a9d49c4061c 6138 admin optional grubconf_0.5.1-1.diff.gz cbfdf5fdaf5f1002010552d4db6e82fb 87164 admin optional grubconf_0.5.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAkmEsC19io6rUCv8RAheEAJ9mz0DKuyQWS1Kpx8Fltc7BfdIAzgCePITt NiQb3UNU0pBtvIV2k9QiLvM= =3g07 -END PGP SIGNATURE- Accepted: grubconf_0.5.1-1.diff.gz to pool/main/g/grubconf/grubconf_0.5.1-1.diff.gz grubconf_0.5.1-1.dsc to pool/main/g/grubconf/grubconf_0.5.1-1.dsc grubconf_0.5.1-1_i386.deb to pool/main/g/grubconf/grubconf_0.5.1-1_i386.deb grubconf_0.5.1.orig.tar.gz to pool/main/g/grubconf/grubconf_0.5.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted grubconf 0.5-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 17 Apr 2003 13:05:39 -0400 Source: grubconf Binary: grubconf Architecture: source i386 Version: 0.5-1 Distribution: unstable Urgency: low Maintainer: Luis R. Rodriguez [EMAIL PROTECTED] Changed-By: Luis R. Rodriguez [EMAIL PROTECTED] Description: grubconf - a Gnome2 based GNU GRUB configuration editor Changes: grubconf (0.5-1) unstable; urgency=low . * Initial Debian package Release. * Patched src/callbacks.c:714 : I replaced, CAT (PACKAGE_PIXMAPS_DIR, /grubconf-app.png) with PACKAGE_PIXMAPS_DIR G_DIR_SEPARATOR_S /grubconf-app.png This allows the package to compile on debian unstable. Files: 3ffb08194884b4c3aea74e08199b9bb7 642 admin optional grubconf_0.5-1.dsc 7eb063e1403207d373bd2bcdc7b27638 355189 admin optional grubconf_0.5.orig.tar.gz 3d80f7107d176fc13ac0c1f26dba5081 93860 admin optional grubconf_0.5-1.diff.gz f4a50ff23f80d8d63ecc545b8ec04609 95620 admin optional grubconf_0.5-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAKk9mC19io6rUCv8RAmC7AJwPfUckheYozkhCKNa9x2iunZACTwCfTNV6 +WBra1VXIqk/Xbcbe0+bhCM= =FfGF -END PGP SIGNATURE- Accepted: grubconf_0.5-1.diff.gz to pool/main/g/grubconf/grubconf_0.5-1.diff.gz grubconf_0.5-1.dsc to pool/main/g/grubconf/grubconf_0.5-1.dsc grubconf_0.5-1_i386.deb to pool/main/g/grubconf/grubconf_0.5-1_i386.deb grubconf_0.5.orig.tar.gz to pool/main/g/grubconf/grubconf_0.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#181429: retitle 181429 ITP: grubconf -- Gnoretitle 181429 ITP: grubconf -- Gnome2 based GRUB configuration editor
retitle 181429 ITP: grubconf -- Gnome2 based GRUB configuration editor thanks * Package name : grubconf Version : 0.5 Upstream Author : Joseph Monti [EMAIL PROTECTED], Ryan Scotka [EMAIL PROTECTED] * URL : http://grubconf.sourceforge.net/ * License : GPL ABOUT Grubconf is a Gnome2 based GRUB configuration editor. It provides an easy to use interface allowing effortless modification of OS's and the flexibility to configure the most obscure options. Designed to require minimal user interaction while providing tools for the most adventurous user. Grubconf must be run as ROOT. This is to gain access to the grub configuration file. Notes: I need a sponsor. The package is ready.
