Re: [Pkg-alsa-devel] RFS: alsa-tools
--- Mikael Magnusson <[EMAIL PROTECTED]> wrote: > I have debianized alsa-tools and am looking for a > sponsor. What is the status of alsa-tools being in Debian legally? Rather, what is debian-legal's stance on these packages? Since the firmware has been separated out into upstream's alsa-firmware, there shouldn't be any problems, but it's never too late to double-check. Thanks, Daniel Chen __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-alsa-devel] RFS: alsa-tools
On Wed, 26 Jan 2005 19:40:05 +0100, Dan Chen wrote: > What is the status of alsa-tools being in Debian > legally? Rather, what is debian-legal's stance on > these packages? Since the firmware has been separated > out into upstream's alsa-firmware, there shouldn't be > any problems, but it's never too late to double-check. 1. Should this package be in contrib because of this dependency? 2. Can we please have some manpages? Now running lintian... W: alsa-tools-gui: binary-without-manpage echomixer W: alsa-tools-gui: binary-without-manpage hdspconf W: alsa-tools-gui: binary-without-manpage hdspmixer W: alsa-tools-gui: binary-without-manpage rmedigicontrol W: alsa-tools: binary-without-manpage ac3dec W: alsa-tools: binary-without-manpage as10k1 W: alsa-tools: binary-without-manpage extract_ac3 W: alsa-tools: binary-without-manpage hdsploader W: alsa-tools: binary-without-manpage mixartloader W: alsa-tools: binary-without-manpage pcxhrloader W: alsa-tools: binary-without-manpage sbiload W: alsa-tools: binary-without-manpage sscape_ctl W: alsa-tools: binary-without-manpage us428control W: alsa-tools: binary-without-manpage usx2yloader W: alsa-tools: binary-without-manpage vxloader Finished running lintian. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-alsa-devel] RFS: alsa-tools
Dan Chen wrote: --- Mikael Magnusson <[EMAIL PROTECTED]> wrote: I have debianized alsa-tools and am looking for a sponsor. What is the status of alsa-tools being in Debian legally? Rather, what is debian-legal's stance on these packages? Since the firmware has been separated out into upstream's alsa-firmware, there shouldn't be any problems, but it's never too late to double-check. Thanks, Daniel Chen I think most of the binaries are used to control some aspects of the hardware, not to load non-free firmwares. And a couple aren't depending of specific hardware to work. Do we have to split the alsa-tools source into two packages, one free and one non-free/contrib? It will make it a bit harder. Regards, Mikael Hardware independent binaries: ac3dec - A free AC-3 stream decoder as10k1 - An assembler for the EMU10K1 (EMU10K2) DSP chip Soundcard control tools: cspctl - Sound Blaster 16 ASP/CSP control program sbiload - OPL2/3 FM instrument loader for the ALSA sequencer us428control - Controller utility for Tascam US-X2Y echomixer - Control tool for Echoaudio soundcards envy24control - Control tool for Envy24 (ice1712) based soundcards hdspconf - A GUI to control the Hammerfall HDSP Alsa Settings. hdspmixer - A tool to control the advanced routing features of the RME Hammerfall DSP. rmedigicontrol - Control tool for RME Digi32 and RME Digi96 soundcards Soundcard firmware loaders: hdsploader - Firmware loader for the RME Hammerfall DSP cards mixartloader - Firmware loader for Digigram's miXart board sound drivers pcxhrloader - Firmware loader for Digigram pcxhr compatible soundcards sscape_ctl - SoundScape control utility usx2yloader - Firmware loader for Tascam USX2Y USB soundcards vxloader - Firmware loader for Digigram VX soundcards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-alsa-devel] RFS: alsa-tools
Walter Landry <[EMAIL PROTECTED]> schrieb: > "Marco d'Itri" <[EMAIL PROTECTED]> wrote: >> [EMAIL PROTECTED] wrote: >> >> >Do we have to split the alsa-tools source into two packages, one free >> >and one non-free/contrib? It will make it a bit harder. >> No. > > Unfortunately, that is not the case. All of the source for packages > in main must satisfy the DFSG. For example, if there are some > non-free, but distributable, files in the original tar ball, those > have to be taken out and a new "original" tar ball made. I don't have the original mails at hand, but IIRC the problem was that some parts of the package _depend_ on something in non-free. In this case, the split-off binary package would go to contrib, and the sources can stay in main. If an upstream tarball contains code that is only needed for compiling on M$ Windows, but is itself free, it can stay in main as well. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: [Pkg-alsa-devel] RFS: alsa-tools
"Marco d'Itri" <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > >Do we have to split the alsa-tools source into two packages, one free > >and one non-free/contrib? It will make it a bit harder. > No. Unfortunately, that is not the case. All of the source for packages in main must satisfy the DFSG. For example, if there are some non-free, but distributable, files in the original tar ball, those have to be taken out and a new "original" tar ball made. Regards, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
