[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#666772: Bug 666772

Hi Johannes!

Thanks for detailed reply!

>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:

Let me describe what I tried and why.

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.

>> 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:

Previously I tried to cross-build without qemu + binfmt-misc installed on host but
building any package build-depending on, say, python3.9-minimal ended with
"Exec format error" in postinst script. Here comes my question about qemu.

>> 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? Why not pull only libdevel packages, like
architecture-dependent libraries, architecture independent headers etc
for the host archotecture and pull the rest of dependencies like python
or zip for build architecture? This way there will be no need running postinst
scripts from arch:armhf packages and thus no need for qemu on host.

>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.

>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.
Vasyl Gello
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.gello@gmail.com

Skype: vasek.gello
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Reply to: