Hi Vasyl, I'm removing #666772 as this issue has nothing to do with that wontfix bug. Quoting Vasyl Gello (2021-10-28 18:12:36) > Thanks for clarification! So I have to ask maintainers of groovy:all and > libcommons-lang-java:all whether they are OK marking it M-A: foreign? Lets take a step back. You observe that groovy and libcommons-lang-java cannot be installed when you try to cross-build kodi. You figure out that they cannot be installed because neither of the packages are marked as M-A:foreign so you conclude that the solution is to mark them as such. But you are jumping to conclusions too fast. I'm neither familiar with groovy nor with the kodi packaging, so I cannot tell you the final solution, but I can ask you questions that you might not've asked yourself yet: Firstly: groovy is a language that compiles to JVM bytecode. That bytecode is architecture-independent. If the code that is generated by groovy is distributed by one of the architecture independent kodi packages, then one solution would be to improve the kodi packaging and allow architecture dependent as well as architecture independent builds. At that point you can move the dependency on groovy from Build-Depends to Build-Depends-Indep. Since during a cross build you only want to generate architecture dependent binary packages, Build-Depends-Indep gets skipped and groovy is not a problem anymore. Secondly: a quick glance at the kodi build system suggests that maybe the code generated by groovy is not distributed by any of the packages built but instead the groovy code is only used as a helper script. If this is correct, then you don't need the host architecture version of groovy (which you cannot install) but the build architecture version of groovy, which is the native architecture that you can install. In that case, your solution is to change the build dependency on groovy into a build dependency on groovy:native. I suggest you explore those two options first before you start thinking about whether any package can be marked as M-A:foreign. > Also, why does apt-get install all arch:host build-deps but not libdevel:host > duplicated with libdevel:build ? I don't understand your question. Can you rephrase? Which package is libdevel:host and libdevel:build? By default, all build dependencies are satisfied by binary packages from the host architecture, that is the architecture you are building for. > Is it possible at all to have "pure" cross-compilation without need to > install qemu-binfmt-support on host? Yes. If you install qemu then you are doing something wrong and then you can do a "native" build inside qemu in the first place. Thousands of packages in the archive cross-build successfully without the need of qemu. For example try cross compiling the source package "hello". This will work out of the box without any qemu support: DEB_BUILD_OPTIONS=nocheck sbuild -d unstable \ --extra-repository="deb-src http://deb.debian.org/debian unstable main" \ --no-run-autopkgtest --no-run-lintian --no-arch-all --arch-any \ --build=amd64 --host=mipsel hello There is also the crossqa service that shows you the current status for all source packages in Debian. Here for src:hello: http://crossqa.debian.net/src/hello Thanks! cheers, josch
Attachment:
signature.asc
Description: signature