There is a team intended to ship MIOpen to Debian's official repository and has made some progress. We notice that there exist some binary files like src/kernels/*.kdb.bz2 used as the kernel cache to avoid runtime JIT when the kernel is first invoked, tracked as either normal Git files or LFS refs based on their sizes. However, it seems that these files are maintained in an opaque way, where the engineers upload without extra explanation #2859, which is not compatible with DFSG requiring source code when distributing the package.
So our question is: can we rebuild/reproduce these binary files locally when compiling MIOpen? This allows us to bring MIOpen in the main archive is the package repository. Otherwise, we may choose to exclude all the binary files at the expense of user performance.
Same problem comes for the src/kernels/*.inc assembly codes, which are uploaded likewisely #2778, #1968. As they're thousands of lines, are they disassembled from some other artifacts?
Hi MIOpen developers,
There is a team intended to ship MIOpen to Debian's official repository and has made some progress. We notice that there exist some binary files like
src/kernels/*.kdb.bz2
used as the kernel cache to avoid runtime JIT when the kernel is first invoked, tracked as either normal Git files or LFS refs based on their sizes. However, it seems that these files are maintained in an opaque way, where the engineers upload without extra explanation #2859, which is not compatible with DFSG requiring source code when distributing the package.So our question is: can we rebuild/reproduce these binary files locally when compiling MIOpen? This allows us to bring MIOpen in the
main
archive is the package repository. Otherwise, we may choose to exclude all the binary files at the expense of user performance.Same problem comes for the
src/kernels/*.inc
assembly codes, which are uploaded likewisely #2778, #1968. As they're thousands of lines, are they disassembled from some other artifacts?Looking forward to your replay. Thanks!