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

Re: Bug#666772: Bug 666772



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


Reply to: