Bug#1099415: samhain: FTBFS in Testing

[Santiago Vila]

Hello.

I tried building samhain on testing and it worked for me.

Can you try building it with sbuild on a chroot using only build-essential packages?

I would really worry if it also fails to build that way. For now it
seems there is something wrong in your system, or maybe you have
discovered an undeclared build-conflict, or your testing system
contains packages not in testing.

Thanks.

[Helge Kreutzmann]

severity 1099415 important
thanks

Hello Santiago,

Post by Santiago Vila
I tried building samhain on testing and it worked for me.

Ok, I was really suprised myself and tried it twice in my main system.

Post by Santiago Vila
Can you try building it with sbuild on a chroot using only build-essential packages?

In a sid chroot samhain builds for me.

Post by Santiago Vila
I would really worry if it also fails to build that way. For now it
seems there is something wrong in your system, or maybe you have
discovered an undeclared build-conflict, or your testing system
contains packages not in testing.

I pasted the build log on my system, if that gives you a hint?

I installed upstream Mediathekview but otherwise all packages on this
system come from Debian, however I did not check if some packages were
removed from Testing.

I'm happy to help investigating this, if you tell me what I should
look for.

Greetings

Helge

[Santiago Vila]

Post by Helge Kreutzmann

Post by Santiago Vila
I would really worry if it also fails to build that way. For now it
seems there is something wrong in your system, or maybe you have
discovered an undeclared build-conflict, or your testing system
contains packages not in testing.

I pasted the build log on my system, if that gives you a hint?

I see very funny differences:

(in what follows, "before" is mine and "after" is yours)

-checking for gcc version... 14
+./configure: line 4566: SH_GCC_VERSION: command not found

[...]

-checking for gethostbyname in -lnsl... no
+checking for gethostbyname in -lnsl... yes
checking for socket in -lsocket... no
-checking for gethostbyname in -lnsl... (cached) no
+checking for gethostbyname in -lnsl... (cached) yes

[...]

-checking for attr/xattr.h... no
-checking for sys/acl.h... no
+./configure: line 7337: sh_CHECK_XATTR: command not found
+./configure: line 7350: sh_CHECK_POSIX_ACL: command not found

Looks like your system is messed up in a very fundamental level.

I wonder if this is the only package which fails to build for you,
or maybe your gcc does not work at all.

If gcc is really ok, I would try this:

diff -ru good-tree bad-tree

where good-tree is a samhain-4.1.4 directory where you have
successfully built the package, and bad-tree is a directory
where the build failed.

To reduce the number of differences, compare the build in
your native trixie system with a build in a trixie chroot.

The config.log file created by configure is probably the
most interesting one:

diff -ru good-tree/config.log bad-tree/config.log

Because configure performs a series of individual checks,
you might want to find out which of those checks is failing,
or giving a different result, to see what's wrong in your
system.

Thanks.

[Helge Kreutzmann]

Hello Santiago,

Post by Santiago Vila

Post by Helge Kreutzmann

Post by Santiago Vila
I would really worry if it also fails to build that way. For now it
seems there is something wrong in your system, or maybe you have
discovered an undeclared build-conflict, or your testing system
contains packages not in testing.

I pasted the build log on my system, if that gives you a hint?

(in what follows, "before" is mine and "after" is yours)
-checking for gcc version... 14
+./configure: line 4566: SH_GCC_VERSION: command not found
[...]
-checking for gethostbyname in -lnsl... no
+checking for gethostbyname in -lnsl... yes
checking for socket in -lsocket... no
-checking for gethostbyname in -lnsl... (cached) no
+checking for gethostbyname in -lnsl... (cached) yes
[...]
-checking for attr/xattr.h... no
-checking for sys/acl.h... no
+./configure: line 7337: sh_CHECK_XATTR: command not found
+./configure: line 7350: sh_CHECK_POSIX_ACL: command not found
Looks like your system is messed up in a very fundamental level.

Ok. So far, this has not been visible.

$ gcc --version
gcc (Debian 14.2.0-16) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Post by Santiago Vila
I wonder if this is the only package which fails to build for you,
or maybe your gcc does not work at all.

It does work. A few hours ago I just complied a small programme, and
once in while I compile Debian packages (mainly to see if I can do an
L10n NMU).

Post by Santiago Vila
diff -ru good-tree bad-tree
where good-tree is a samhain-4.1.4 directory where you have
successfully built the package, and bad-tree is a directory
where the build failed.
To reduce the number of differences, compare the build in
your native trixie system with a build in a trixie chroot.

Please find the diff attached. One == good-tree and two = bad-tree

Post by Santiago Vila
The config.log file created by configure is probably the
diff -ru good-tree/config.log bad-tree/config.log

Also attached. It' pretty difficult to read, but e.g.
-gcc version 14.2.0 (Debian 14.2.0-17)
+gcc version 14.2.0 (Debian 14.2.0-16)

Post by Santiago Vila
Because configure performs a series of individual checks,
you might want to find out which of those checks is failing,
or giving a different result, to see what's wrong in your
system.

I see one difference: On the "failing" system, both mawk and gawk are
installed, in the chroot only mawk.

But this does not change the "good" build (succeeds with both). So
this is a false hint.

Next, on the good (chroot) only:
configure:4515: checking for ld used by x86_64-linux-gnu-gcc
configure:4581: result: /usr/bin/X11/ld
configure:4588: checking if the linker (/usr/bin/X11/ld) is GNU ld
configure:4605: result: yes

Howver, ld is installed in both environments, and /usr/bin/X11/ld is
present the same way in both.

On the good build (only) I have:
configure:4663: checking for gcc version
configure:4679: result: 14

(and in subsequent lines these appear only on the good chroot).

Later on, only on the good system:
configure:6302: checking whether _POSIX_SOURCE is necessary



And then later on it diverges more.

I guess my complier / building knowledge is more than exceeded here,
so sorry, that I cannot be of any help further (but of course, I can
run further commands if necessary).

Greetings

Helge

Dr. Helge Kreutzmann ***@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/

[Santiago Vila]

-gcc version 14.2.0 (Debian 14.2.0-17)
+gcc version 14.2.0 (Debian 14.2.0-16)

Note: gcc-14 in trixie is still at version 14.2.0-16, so you
are still comparing the good build you made in unstable
with the build made natively on your trixie system.

As a result, the diff has a lot of unwanted noise.

Either upgrade your system to unstable and compare
good and bad builds both made in unstable, or build it in a
trixie chroot to compare good and bad builds both made in trixie.

Also, use deborphan from bookworm to remove any package which
you don't really need, including binutils-gold (I don't think
it's related but who knows).

If it still fails, you could start adding packages to your chroot which
you know they are also installed in your native system until
the build also fails in the chroot. If there is an undeclared
build-conflict, that would be the way to tell.

I guess my complier / building knowledge is more than exceeded here,> so sorry, that I cannot be of any help further (but of course, I can
run further commands if necessary).

If everything else fails, consider reinstalling your testing system
from scratch. At some point, doing that will be less time-consuming
than debugging the problem. Your system seems to be messed up.

Thanks.

[Helge Kreutzmann]

Hello Santiago,
thanks for your review.

Post by Helge Kreutzmann
-gcc version 14.2.0 (Debian 14.2.0-17)
+gcc version 14.2.0 (Debian 14.2.0-16)
Note: gcc-14 in trixie is still at version 14.2.0-16, so you
are still comparing the good build you made in unstable
with the build made natively on your trixie system.

Yes, currently I only have an Unstable and Stable chroot, not Trixie,
but of course I can install it.

Post by Helge Kreutzmann
As a result, the diff has a lot of unwanted noise.

Yes, that's true. For my "analysis" I looked at the vimdiff, where I
had hoped to see the cause.

Post by Helge Kreutzmann
Either upgrade your system to unstable and compare
good and bad builds both made in unstable, or build it in a
trixie chroot to compare good and bad builds both made in trixie.

Well, the first is not an option (I run in Testing on purpose). If I
find time I can maybe try the latter.

Post by Helge Kreutzmann
Also, use deborphan from bookworm to remove any package which
you don't really need, including binutils-gold (I don't think
it's related but who knows).

No, unfortunately removing this and binutils-gold-x86-64-linux-gnu did
not change anything.

And I checked deborphan - it's removed from Debian for serious reasons
by it's maintainer, so I would not want to install an old version on
the system.

Post by Helge Kreutzmann
If it still fails, you could start adding packages to your chroot which
you know they are also installed in your native system until
the build also fails in the chroot. If there is an undeclared
build-conflict, that would be the way to tell.

Well, if I had an idea *which* package could cause this potential
hidden build-conflict I could try this, but for randomly adding
packages I'm afraid I'm lacking the time.

Post by Helge Kreutzmann

I guess my complier / building knowledge is more than exceeded here,> so sorry, that I cannot be of any help further (but of course, I can
run further commands if necessary).

If everything else fails, consider reinstalling your testing system
from scratch. At some point, doing that will be less time-consuming
than debugging the problem. Your system seems to be messed up.

Well, for debugging a potential problem in samhain (a programm I've
never used) this is a bit big "workload". And I'm really not conviced
that my system "is messed up". All other workloads, including
occassionally building programms, work fine (except the bugs
you can find under my name in the BTS, of course).

So if I find time today, I'll check the Trixie chroot output, but
otherwise I guess there's no further debugging possibly right now.

Greetings

Helge

[Santiago Vila]

Post by Helge Kreutzmann
And I checked deborphan - it's removed from Debian for serious reasons
by it's maintainer, so I would not want to install an old version on
the system.

Well, I still use deborphan to remove cruft from my chroots
(the ones I use for archive rebuilds), and I can tell you
that it's still useful, at least for me. The reason it was
removed from trixie is that in trixie it may have false positives,
but the tool by itself does nothing when invoked from the command
line, it just tell what would be a candidate to be removed.
(i.e. it's not "dangerous").

You can also try debfoster to remove cruft, which still exists
in trixie.

And finally, you can try this script I use from time to time,
called "installed-packages-which-do-not-exist-in-trixie" which
has a self-explanatory name (needs wget to work).

Thanks.

[Helge Kreutzmann]

retitle 1099415 samhain is missing build conflict on autoconf-archive
# Severity is fine
thanks

After more diagnosis (thanks Santiago) it turned out thet install
autoconf-archive make samhain FTBFS.

Please install the appropriate build conflicts.

Greetings

Helge

[Helge Kreutzmann]

Hello Santiago,
thanks for your e-mails, I saw your most recent e-mail.

I installed a trixie chroot now, but there is nothing new in diffs.

I now compared configure in both my main system (not working,-) and the
Trixie chroot (working,+):
--- ../tbuild/samhain-4.1.4/configure 2025-03-03 17:06:35.389011407 +0100
+++ samhain-4.1.4/configure 2025-03-03 16:03:50.371638797 +0100
@@ -677,18 +677,18 @@
myport
mydebugdef
HAVE_MYSQL_CONFIG
-PTHREAD_LDFLAGS
PTHREAD_CFLAGS
PTHREAD_LIBS
+PTHREAD_CXX
PTHREAD_CC
-acx_pthread_config
+ax_pthread_config
+SED
clmytclient
mytclient
sh_main_prg
samhainadmin_prg
yulectl_prg
setpwd_prg
-tiger_src
sh_libsocket
selectconfig
cmd_hostname
@@ -772,6 +772,7 @@
with_libwrap
enable_network
enable_static
+with_zlib
with_database
with_console
with_altconsole
@@ -1492,6 +1493,9 @@
--with-cflags additional flags to pass to compiler
--with-libs additional libraries to link with
--with-libwrap=PATH Compile in libwrap (TCP Wrappers) support
+ --with-zlib=DIR root directory path of zlib installation [defaults to
+ /usr/local or /usr if not found in /usr/local]
+ --without-zlib to disable zlib usage completely
--with-database=[mysql|postgresql|oracle|odbc] database support [no]
--with-console=PATH set path to console device [/dev/console]
--with-altconsole=PATH set path to second console device [none]

And the config.log still shows the same diff, still noisy because of the
changing line numbers, but in the first part the build from the chroot
shows the following addtional:
-configure:4515: checking for ld used by x86_64-linux-gnu-gcc
-configure:4581: result: /bin/ld
-configure:4588: checking if the linker (/bin/ld) is GNU ld
-configure:4605: result: yes
-configure:4663: checking for gcc version
-configure:4679: result: 14

I already tried installing some PTHREAD packages[1] in the chroot (which
I have on my main system), but the build in the chroot continues to
succeed with them).

I'm quite a bit beyond my knowledge now, and I have no idea why
PTHREAD_LDFLAGS is not, but PTHREAD_CXX is used on my main system and
the acx_pthread_config → ax_pthread_config seems also to indicate some
package changing things.

(And now idea what "tiger_src" is).

Zlib is identically inside and outside the chroot.

That's it for now.

Greetings

Helge

[1] libpthread-stubs0-dev libpthreadpool0 libopenblas0-pthread