Discussion:
Bug#948763: z3: cannot be built on buildds
Add Reply
Helmut Grohne
2020-01-13 05:30:01 UTC
Reply
Permalink
Source: z3
Version: 4.8.7-3
Severity: serious

z3 cannot be built on buildds, because its Build-Depends cannot be
satisfied on buildds. Failing to build on buildds is a serious problem.

| Build-Depends: debhelper-compat (= 12),
| dh-python:all, python3:native, cmake,

dh-python:all is broken. This is why dose-builddebcheck rejects your
package. dh-python is Multi-Arch: foreign and does not need any
annotation.

python3:native is correct in principle. The python ecosystem more
commonly uses python3:any though. dh-python parses the Build-Depends and
I'm not sure that the dh-python parser understands :native today. I
suggest that you prefer :any for python interpreter dependencies in
general.

| javahelper:all [!hppa !hurd-i386 !m68k !sh4],

Just like python:all this is broken. We don't support cross building
java stuff yet. If you want to get there, get in touch with
debian-***@lists.debian.org. This needs more work on the lower layers.

If you want to cross build z3 without the java bindings, please use the
<!nojava> build profile.

| default-jdk:native [!hppa !hurd-i386 !m68k !sh4]

This can work, but when you switch the development kit to native, you
need to explicitly depend on the runtime environment for the host
architecture. That'd be default-jre-headless without :native.
Unfortunately, doing so presently produces a conflict.

Helmut
Ximin Luo
2020-01-13 20:10:02 UTC
Reply
Permalink
Post by Helmut Grohne
Source: z3
Version: 4.8.7-3
Severity: serious
z3 cannot be built on buildds, because its Build-Depends cannot be
satisfied on buildds. Failing to build on buildds is a serious problem.
It builds now on all but three architectures, including, in particular, all
release architectures.
Post by Helmut Grohne
[...]
Thanks for your suggestions, but I'm not very familiar with how Multi-Arch
annotations should be used; I just accepted a patch to make the z3 package
more cross-build friendly (see #948109).
I tested this myself and also it's now working on buildds, so I don't see what the problem is here. Can we just close this bug report and mark it as `notfound -1 $version`?

FWIW, when I tried things locally with sbuild, changing dh-python:all to simply dh-python whilst retaining the other annotations *did not work*, regardless of how it's "supposed" to work. That is why I added the extra :all.
Can you give me a patch where you set the build dependency annotations in a
sound way that also works for cross-building? Otherwise, I would have to
simply remove all annotations again in order to fix this bug (but clearly,
that would not be the most desirable solution).
I would also be happy to use the nojava build profile that you suggested,
but again, I'm not familiar with this technique, and from what I've heard,
there are still some problems e. g. with using "dh-sequence-javahelper
<!nojava>". But if somebody gave me a patch, I'd be happy to apply it.
Thanks for your help!
Fabian
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
Helmut Grohne
2020-01-14 05:40:02 UTC
Reply
Permalink
Hi Ximin,
Post by Ximin Luo
FWIW, when I tried things locally with sbuild, changing dh-python:all to simply dh-python whilst retaining the other annotations *did not work*, regardless of how it's "supposed" to work. That is why I added the extra :all.
This might be a problem with your build environment. Can we move this
part of the z3 bug tracker onto debian-***@lists.debian.org? Can you
follow up there with an email describing your steps and including the
full build log that fails when you skip the :all on dh-python? We better
understand what's going on here before bothering the z3 maintainers
further.

I'm not opposed to fixing z3. Just slow down. Understand the issues
involved. Ximin usually is exceptionally fast at fixing cross build
issues in the rust ecosystem, but sometimes an extra round of discussion
helps.

Please keep in mind that these annotations can be harmful. For instance
if you annotate a package :native in 20 other packages and then notice
that you should have marked the annotated package "Multi-Arch: foreign",
you'll observe that you make those 20 other packages FTBFS natively by
adding "Multi-Arch: foreign". We should use these annotations sparingly
and always prefer using Multi-Arch: something if possible. And that's
not always possible.

Helmut

Ximin Luo
2020-01-13 22:10:01 UTC
Reply
Permalink
Control: retitle -1 cannot migrate to testing
Hi Fabian,
Post by Helmut Grohne
Source: z3
Version: 4.8.7-3
Severity: serious
z3 cannot be built on buildds, because its Build-Depends cannot be
satisfied on buildds. Failing to build on buildds is a serious problem.
It builds now on all but three architectures, including, in particular, all
release architectures.
Oh, I'm wrong here. It did build. But the dependency issue prevents it
from migrating to testing. So you want to fix that anyway.
Why is testing migration prevented, when the builds completed fine? Why is there a "dependency issue" when clearly the dependencies were satisfied?
Thanks for your suggestions, but I'm not very familiar with how Multi-Arch
annotations should be used; I just accepted a patch to make the z3 package
more cross-build friendly (see #948109).
That bug is not at all about cross building nor multi-arch. It seems you
(and your contributors) are conflating multiple issues. Things become
much easier once you start separating them.
Can you give me a patch where you set the build dependency annotations in a
sound way that also works for cross-building? Otherwise, I would have to
simply remove all annotations again in order to fix this bug (but clearly,
that would not be the most desirable solution).
No. The expectation that every package can be cross built is misguided.
z3 uses java stuff, which is an unsolved problem. Therefore you cannot
make z3's dependencies cross-satisfiable at this time. If you want to do
so anyway, be prepared to invest quite some work.
For this reason, reverting the annotations is not the worst of options.
The sbuild command-line I gave near the end of #948109 works perfectly fine to cross-compile java bindings and the files have the correct binary format (for the foreign architecture).

Granted, I didn't actually run the bindings, but I don't see why they wouldn't work.

I can understand that, based on what your expectations are of the current tool chain you believe it shouldn't work, but *I actually tried it empirically and it works*.

X
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
Loading...