avahi fails to cross build from source. Since xmltoman became
M-A:foreign. avahi's Build-Depends are almost installable. Its python
dependencies still fail with postinst errors. For cross building, one
typically wants libpython from the host architecture and the rest from
the build architecture. After annotating all of those dependencies,
./configure fails figuring out the target distribution. After telling it
that we build for Debian, it cross builds successfully. Please consider
applying the attached patch.

Helmut

Hi Helmut

Given that python-all-dev already depends on libpython-all-dev,
shouldn't python-all-dev ensure to pull in the correct version?


After annotating all of those dependencies,

Hm, that would make the package not syncable to Ubuntu and other
derivatives.
I wonder if it would be better to conditionalize on dpkg-vendor
(DEB_VENDOR, /usr/share/dpkg/vendor.mk) instead.

Hi Michael,

Yes, python-all-dev depends on libpython-all-dev, but we want the build
architecture python-all-dev and the host architecture libpython-all-dev.
Thus the dependency doesn't get us the correct version. Note the ":any".

Yes, this is weired. No, I don't understand why we didn't make
dependencies on python-all-dev just work (by swapping python-all-dev and
libpython-all-dev and reversing the dependency).

Ubuntu is not a valid value for --with-distro. I guess it treats Ubuntu
as Debian. Furthermore, the flag is only passed for cross compilation
and thus doesn't affect native compilation. So I think we should first
make this work for Debian (while not breaking native Ubuntu builds) and
then Ubuntu can provide the dpkg-vendor code if necessary.

Helmut

Am 17.09.2017 um 20:12 schrieb Helmut Grohne:

I still don't understand why python-all-dev allows the combination with
libpython-all-dev which apparently results in a non-working python
installation and why working around that in individual packages by
specifying additional build depends is the correct way to go.

unconditional, since it's harmless to force --with-distro=debian when not
cross-compiling).

This part hasn't been applied.

    smcv

Control: severity -1 wishlist
Control: retitle -1 avahi FTCBFS: needs to run host python
Control: tags -1 - patch

On closer inspection, I don't think (the modernized version of) this
change is necessarily correct.

I have changed this part to use python2 instead of python-all-dev.
avahi doesn't actually compile an extension or use Python development
headers - it just wants the interpreter. Normally, the obvious response
to this would be "then you should use python2:any, python-dbus:native
and so on".

However, python2 is run during the build to convert a text file listing
mDNS service types into a gdbm database. gdbm databases appear to be
endianness- and word-size-specific, so we need to build a database that
matches the host architecture's endianness and word size, even if they
differ from the build architecture's endianness and word size; so using
python2:any (or more generally, python2:${build-arch} when cross-compiling
on ${build-arch} for ${host-arch}) would not be correct.

I realize this makes it impossible to cross-compile avahi, which is
unfortunate - but I don't think that's fixable with the package's current
content.

Making it cross-compilable would require either a database format that
does not vary between architectures (which the upstream C code would need
to be taught to load), or a conversion step: for example, the package
could install service-type-database/service-types directly, and maintainer
scripts could "compile" it into each appropriate architecture's gdbm format.

To be honest this all seems massively overengineered for a table of just
over 100 service types, but that's an upstream design decision rather
than a packaging choice.

    smcv

Despite the delay, I fully concur. It's Python 3.x now, but that doesn't
change much. The code consuming the file is in avahi-utils/stdb.c and
used e.g. by avahi-browse. The code creating the gdbm database is at
service-type-database/build-db and it is converting a 242 line text file
service-type-database/service-types that contains 107 non-empty
non-comment lines into a 16kb gbdm database.

To me, this does not make much sense. I'd rather convert the database to
some array in C and do a linear search compiling it into the binary
given the current database size. That's likely much faster than opening
an external file and removes the dependency on gdbm entirely. Only when
the database grows beyond around 1000 entries will a gdbm pose any
benefit in speed. We're more than a factor of 10 removed from that.

In any case, this very much is an upstream problem affecting all cross
building distributions. For the time being, I do not intend to work on
this problem. If anyone feels that this bug report is not actionable and
clutters avahi's bug listing, consider closing it. Cross build bugs
should be actionable in my opinion and Simon acted upon the actionable
parts (thanks).

Helmut