In qemu package there's a source file, pc-bios/spapr-rtas/spapr-rtas.S, which is an PPC assembly file with exactly 5 instructions:
#define KVMPPC_HCALL_BASE 0xf000 #define KVMPPC_H_RTAS (KVMPPC_HCALL_BASE + 0x0) .globl _start _start: mr 4,3 lis 3,KVMPPC_H_RTAS@h ori 3,3,KVMPPC_H_RTAS@l sc 1 blr (it is "Trivial in-partition RTAS implementation, based on a hypercall"). This file is also included in the upstream source in compiled form, as pc-bios/spapr-rtas.bin. This is because it needs ppc assembler to compile, and not every system out there has this tool ready available. The resulting .bin file is 20 bytes long, here's the disassembly output of it: objdump -b binary -m powerpc:common -EB -D pc-bios/spapr-rtas.bin 0: 7c 64 1b 78 mr r4,r3 4: 3c 60 00 00 lis r3,0 8: 60 63 f0 00 ori r3,r3,61440 c: 44 00 00 22 sc 1 10: 4e 80 00 20 blr But qemu builds basically on all platforms, and on each platform it runs, it needs this .bin file to run (emulated) PPC platform. So we have the following options: 1) package just this single file, of 20 bytes long, in a separate Arch:all package, in it's own separate source. 2) drop ppc support where this file is required. Neither of which appears to be good solution. I think there's on other possibility. But I'm not sure whenever it can be considered DFSG-clean. I can ship something like the above disassembly code, and build the .bin file during package build time using just hex tools, on all patforms. The source and hex-binary will both be platform-independent. But on PPC platform, at build time, I can actually build the .bin file using the upstream method by calling real compiler/linker/objcopy, and can compare the result with the result of processing the hex-binary, and fail if they don't match -- this is to catch changes in toolchain or the upstream source. This way, due to trivial nature of the file, we can, with grain of salt, say that the source is actually modifiable using just the tools listed in Build-depends, in a form of hand-crafted binary assembly. If you know the assembler (description of which is not listed as Build-depends!), you can hand-translate a several-instructions-long program from source into binary form by looking up assembly instruction codes in the manual. This is a bit of cheating, but I still think it is better than to create a separate source package just with that file. Comments? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50539077.1080...@msgid.tls.msk.ru