Re: MIOpen package LFS files
> On May 9, 2024, at 00:35, Cordell Bloor <cgmb@slerp.xyz> wrote:
>
> While d/not-installed filters things from the binary package, it does not affect the source package. If the *.kdb.bz2 files are not suitable for main due to DFSG violations, they need to be excluded from the source package. So, it sounds like the MIOpen LFS files should not be brought into the miopen repository on salsa.
I’ve uploaded the “pure” version of MIOpen without *.bz2 and *.kdb files to a new repo [20].
The source tarball is imported by gbp with —-filter=“*.bz2” —-filter=“*.kdb” options, and listing in Files-Excluded in d/copyright as well.
Currently I just copies the entire debian/ folder from the previous repository.
(I was trying to copy the commits via git cherry-pick, but sbuild reports error for incompatible source package content, I’ll try to fix this if possible.)
> Agreed. I think my only remaining question is whether those big assembly files are ok. They contain macros, so they're clearly not plain disassemblies, and I think their size might be exaggerated by loop unrolling. Still... I can't imagine that they were hand-written, so I think we need to know more about them.
One question for DFSG: can we regard the assembly code as a form of “source code”, even if they are generated from the unknown artifact (e.g., some compiled binary objects)?
Theoretically, the assembly is fully explainable as the AMD GPU ISA manual is public [21].
> We need to ask upstream. We should find out how they were created and how they are updated (e.g., if bugs are discovered). I would suggest opening an issue to ask the question on the upstream GitHub repository.
Issue submitted [22].
Best,
Xuanteng
[20]: https://salsa.debian.org/xuantengh/miopen
[21]: https://gpuopen.com/amd-gpu-architecture-programming-documentation/
[22]: https://github.com/ROCm/MIOpen/issues/2955
Reply to: