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, My hero Thanks so much, Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E pgp7SVbNNLDVm.pgp Description: PGP signature
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.
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]
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]
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
[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 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 ? 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
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 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 Date: Sat Jan 24 15:36:08 2009 +0100 bump version to 0.9.9 commit c1d44a6c68790adc45d4a047cdd3a93332210c17 Author: Johannes Berg Date: Sat Jan 24 15:35:30 2009 +0100 RTFM link for ap/master modes commit 0c099f3edd23586680e700dbe16a484b0d0568f9 Author: Johannes Berg Date: Sat Jan 24 15:15:46 2009 +0100 add commas to see also section commit 585e62cbc9fddaba274d948dd0e1ab78b18fc02f Author: Luis R. Rodriguez 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 commit 45d543f0a65cd4a5ad461b88acee1749a5c78431 Author: Johannes Berg 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 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 wrote: > On Tuesday 02 March 2010 04:13:25 Luis R. Rodriguez wrote: >> On Mon, Mar 1, 2010 at 8:09 AM, Paul Wise 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
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 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 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 Wed, Mar 3, 2010 at 9:05 PM, Ben Hutchings 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 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: [renamed] Debian crda?
On Tue, Mar 24, 2009 at 11:44 PM, Kalle Valo wrote: > "Luis R. Rodriguez" 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 wrote: > On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez 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 wrote: > On Wed, Mar 25, 2009 at 12:39 AM, Paul Wise wrote: >> On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez 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 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 wrote: >> > On Wed, Mar 25, 2009 at 12:39 AM, Paul Wise wrote: >> >> On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez >> >> 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 wrote: > On Thu, Mar 26, 2009 at 3:42 AM, Kel Modderman 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 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 wrote: > On Thu, Mar 26, 2009 at 4:03 AM, Paul Wise 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
Re: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 9:59 PM, Paul Wise wrote: > On Thu, Mar 26, 2009 at 1:19 PM, Luis R. Rodriguez 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
Looking for Frans Pop, anyone know his new e-mail address?
Hey folks, I'm looking for Frans Pop , 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 wrote: > Hey folks, I'm looking for Frans Pop , 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
