Hello, Before I file a formal ITP, I'd like to inform you of my plans with respect to carl9170, and how we will need to work together. carl9170 is already packaged in firmware-linux-free, so why do I plan on making it its own source package? Right now, carl9170 is not built from source, and we are generally going to need to keep up with Git snapshots in order to keep it building with newer versions of Binutils and GCC. Currently I'm packaging and seeking sponsors for binutils-sh-elf and gcc-sh-elf; those are the only blockers to being able to build from source. One problem that needs to be handled delicately is that, since firmware-linux-free already ships /lib/firmware/carl9170-1.fw, and there is no alternative file path that the kernel can look (unlike the case with ath9k_htc), we need to coordinate the handover of the filename. I can upload carl9170fw to experimental, and after it clears NEW, we can determine what version of firmware-linux-free will be the last to ship carl9170-1.fw. I can then add Breaks+Replaces to my carl9170fw package, we can add a Recommends: firmware-carl9170 to firmware-linux- free, and then upload them simultaneously to unstable. Does this sound reasonable to the Kernel Team? I think carl9170fw rightfully belongs in the Kernel Team namespace, so could you please create an empty Git repository at https://salsa.debian.org/kernel-team/carl9170fw and grant me Salsa access for when I have the package ready (username jscott)? And when I do have it ready after Binutils+GCC have cleared NEW, is anyone here particularly interested in reviewing and sponsoring? Thanks, John
Attachment:
signature.asc
Description: This is a digitally signed message part