Quoting Vasyl Gello (2021-10-28 21:38:18) > Working on #996627 I had to build Kodi for armhf to let the bug reporter test > the fix proposed by Helmut. I started with plain simple "pbuilder build > --host-arch armhf kodi_*.dsc". My PBUILDERSATISFYDEPENDSCMD is set to > /usr/lib/pbuilder-satisfydepends-apt as error message told me to do. As a > result, pbuilder tried to download all build-deps for a host architecture > (even those like zip:armhf, groovy:armhf, python3.9-minimal:armhf etc) and > failed to resolve groovy:armhf and libcommons-lang-java:armhf. So I spawned > a container with armhf emulated by qemu and found out that I need to > "emulate" m-a: foreign and wrote the MR I later put on Salsa. you'll probably get results quicker if you do a native build in a qemu virtual machine emulating your host architecture. > >> 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. > > The short question is: why apt resolver tries satisfying all build-deps from > the host architecture? Because that's the rule. In Debian, all build dependencies default to being resolved as the host architecture package. If it was the other way round and the default was the build architecture, then you would now ask the opposite question and ask why all build-deps come from the build architecture. It's just the default and in reality you need both build and host architecture packages to do the build. Multi-Arch allows you to mark the packages that deviate from the default as such. > Why not pull only libdevel packages, like architecture-dependent libraries, > architecture independent headers etc for the host archotecture This is already done. > and pull the rest of dependencies like python or zip for build architecture? If the package is Multi-Arch:foreign, then that is already done. If the package is not M-A:foreign, then the dependency resolver has no way to know whether you need the build architecture or host architecture of a package. We mark packages with the right metadata to install build dependencies of the correct architecture. But without that metadata, the resolver cannot know what the build actually needs. > This way there will be no need running postinst scripts from arch:armhf > packages and thus no need for qemu on host. Maybe I'm missing context but I think we are missing topics here. Whether or not installing packages from a foreign architecture which might thus execute foreign architecture code in their maintainer scripts is independent of build dependency resolution. > >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. > > Groovy is used with Swig to generate C++ sources later built into final architecture- > dependent binary, kodi.bin. This means moving to Build-Depends-Indep will > not help me at all. I will try groovy:native approach. If the generated C++ code is the same independent of the host architecture, then that approach might work. > >There is also the crossqa service that shows you the current status for all > >source packages in Debian. > > Do you need by chance the list of packages whose postinst scripts invoke > armhf binaries? I can extract that info from build log on my local desktop. > Most of these are python packages and Perl SAX parsers. I still think you are looking at the problem from the wrong perspective. You install a foreign architecture package and its maintainer script fails because you cannot execute the foreign architecture so you look for a solution that allows you to execute the foreign architecture and you use qemu binfmt for that. But it's likely that you should instead take a step back and ask yourself whether you really need that package installed in the foreign architecture. Does the build really need the package in host architecture to succeed? Thanks! cheers, josch
Attachment:
signature.asc
Description: signature