Hi! I’ve been looking into this again, due to M-A version skew.
According to the build log, clang is used for bpf_protocols only; this seems to be architecture-independent. Because clang isn’t available on every Debian architecture, especially new ones, but src:v4l-utils is deep inside dependency chains and thus needs to be available for things to even build, this is… unsatisfactory. Could you extract bpf_protocols from src:v4l-utils so that the bpf target code is generated as part of an arch:all build? I see three ways for this: Either it’s generated in build-indep of src:v4l-utils and shipped as arch:all data package which is used at runtime by the components that need it. Or it’s extracted from src:v4l-utils into another package, whose arch:all build result contains it and then becomes a Build-Depends of src:v4l-utils which copies it instead of rebuilding it. Or, perhaps, src:v4l-utils produces an arch:all package from its build-indep that contains the output, and Build-Depends-Arch on _that_ (so the arch:any build build-depens on the output of the arch:all build, requiring a split build, but that’s possible in Debian nowadays, AFAICT) and takes the build results from there. Update, just before actually sending the mail (BTS clone takes a few minutes): I see that the bpf files *are* already installed and dynamically loaded (/lib/udev/rc_keymaps/protocols), so just splitting an arch:all package ir-keytable-common from ir-keytable that contains them and making sure the arch:any build will still let the binary contain the bpf loader would do the trick. Thanks for your consideration, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” (#nosec) ‣‣‣ Please let MySQL and MariaDB finally die!
