[Pkg-samba-maint] Bug#1030593: tdb FTCBFS: performs run checks
Helmut Grohne
helmut at subdivi.de
Mon Feb 6 08:39:41 GMT 2023
Control: forwarded -1 https://gitlab.com/samba-team/samba/-/merge_requests/2922
Hi Michael,
On Mon, Feb 06, 2023 at 10:01:52AM +0300, Michael Tokarev wrote:
> Why did you include the sysname change? — this one:
>
> +--- tdb-1.4.8.orig/buildtools/wafsamba/samba_conftests.py
> ++++ tdb-1.4.8/buildtools/wafsamba/samba_conftests.py
> +@@ -440,7 +440,7 @@
> + def CHECK_UNAME(conf):
> + '''setup SYSTEM_UNAME_* defines'''
> + ret = True
> +- for v in "sysname machine release version".split():
> ++ for v in "sysname".split():
> + if not conf.CHECK_CODE('''
> + int printf(const char *format, ...);
> + struct utsname n;
These aspects are non-discoverable during cross builds, so I'd have to
add them to the cross-answers file. I looked at what values they'd get
and quickly noticed that any kind of depending on them would cause
reproducibility issues. I then looked how they're being used: Not at
all. So the simplest way to solve this problem was skipping the
unnecessary checks. And really, nothing should ever match these unless
you want to make the reproducibility folks angry.
> For tdb, there's one more change needed. Its test target
> requires host python for python tests. This is unfortunate,
> the build procedure itself uses python (which best to be the
> native python), and determines python characteristics from
> there instead of from host python, this is where that
> _PYTHON_SYSCONFIGDATA_NAME hack is handy; but it doesn't
> help with the tests.
Correct. This is why cross builds are performed with the nocheck profile
and option. Thus tests are disabled and the problem does not apply. The
right way for tdb to express this limitation would be adding "python3
<!nocheck>" to Build-Depends. This time, python3 is not annotated with
:any or :native and thus it really asks for the host instance. Such a
dependency would cause a conflict with the build architecture python and
any cross build not specifying nocheck would become bd-uninstallable,
but this really is as good as we can get on this. The way to test cross
built packages is autopkgtest on native hardware I fear.
> Besides, the same set of changes is needed for other samba-related
> packages, namely tevent and talloc, and for samba itself.
> In tevent we already have cross.patch from you (I fixed that one
> a week or so ago) which should be applied to tdb as well, I guess.
Yeah, the tevent one overlaps, but I think the conflicting tdb hunk is
better than the one in tevent. Also tevent should probably be using
CHECK_SIZEOF rather than inlining that check, but then this is the
annoyance that comes with doing your own buildsystem instead of using
existing ones.
> It would be great to push the changes upstream. But since cross-
> compilation is not a very hot topic upstream, I guess debian can
> be sort of a playground for that, to test things before submitting.
Thank you.
> Overall, the samba build system is in a quite bad state, from my
> PoV anyway, - it is based on many hacks (like including files
> from "random" dirs, see for example "helper" attributes in librpc/
> idl/*.idl files and try to guess how this "include" supposed to
> work; the PYTHONHASHSEED fiasco on sparc64 and shipping multiple
> include files of the same name in same-named dirs, - which is still
> unfixed upstream with random -I order, so it's impossible to guess
> which one will be included, and so on.) So maybe cross-compile
> changes aren't of the first priority here.
Who am I to disagree? For me, this works differently: I fix cross
building all over the place. When one package gets stuck, I work on
others. You improved cross building of tdb and that made me further
improve it. If it gets stuck again, so be it. You can summon me working
on this by closing this bug (preferably with including at least some of
the contained changes). Some FTCBFS bugs are over 3 years old now and
I've had at least 20 closed by ftp-master RM. Not every change reaches
upstream.
Helmut
More information about the Pkg-samba-maint
mailing list