2.4.4+dfsg1-1 is FTBFS on armhf in Noble

Moving the conditional _LARGEFILE64_SOURCE define ahead of the stdlib includes has fixed the issue.

Here's my PPA with the successful builds: https://launchpad.net/~cpete/+archive/ubuntu/389-ds-base-2/+packages

Hi Chris,

Thanks for providing a patch. I noticed that you're suggesting that we move that entire chunk of code from a header file to a specific source file. Without really testing it, I'm thinking whether such a change isn't too invasive. It will mean that other files including back-ldbm.h won't benefit from the code in question.

I also took some time to look if upstream has experienced this problem, but I couldn't find any reports there. But what happens if you reorder the header files on bdb_layer.c instead? I haven't had the time/chance to give it a try, but maybe we can find a simpler approach to this problem.

Thanks.

Hi Sergio,

Thanks for your feedback. I agree that simply reordering the header order in bdb_layer.c would be the best approach.

Originally, I had an issue where by simply moving the standard library header includes below the "bdb_layer.h" include (which should mean the define logic should be reached before any of the standard library headers are included) the project failed to compile with a cryptic error:

libtool: compile: gcc -DHAVE_CONFIG_H -I. -DRUST_ENABLE -DBUILD_NUM=\"2024.038.2016\" "-DVENDOR=\"389 Project\"" -DBRAND=\"389\" -DCAPBRAND=\"389\" -UPACKAGE_VERSION -UPACKAGE_TARNAME -UPACKAGE_STRING -UPACKAGE_BUGREPORT -I./ldap/include -I./ldap/servers/slapd -I./include -I. -DLOCALSTATEDIR=\"/var\" -DSYSCONFDIR=\"/etc\" -DLIBDIR=\"/usr/lib/x86_64-linux-gnu\" -DBINDIR=\"/usr/bin\" -DDATADIR=\"/usr/share\" -DDOCDIR=\"/usr/share/doc/389-ds-base\" -DSBINDIR=\"/usr/sbin\" -DPLUGINDIR=\"/usr/lib/x86_64-linux-gnu/dirsrv/plugins\" -DTEMPLATEDIR=\"/usr/share/dirsrv/data\" -DSYSTEMSCHEMADIR=\"/usr/share/dirsrv/schema\" -DLOCALRUNDIR=\"/run\" -DWITH_SYSTEMD -I/usr/include -I/usr/include/nss -I/usr/include/nspr -I/usr/include/nspr -I/usr/include -Wdate-time -D_FORTIFY_SOURCE=3 -g -O2 -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/<<PKGBUILDDIR>>=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/<<PKGBUILDDIR>>=/usr/src/389-ds-base-2.4.4+dfsg1-1ubuntu1 -c ldap/servers/slapd/back-ldbm/db-bdb/bdb_ldif2db.c -fPIC -DPIC -o ldap/servers/slapd/back-ldbm/db-bdb/.libs/libback_ldbm_la-bdb_ldif2db.o
In file included from ldap/servers/slapd/back-ldbm/db-bdb/../back-ldbm.h:78,
                 from ldap/servers/slapd/back-ldbm/db-bdb/bdb_layer.h:10,
                 from ldap/servers/slapd/back-ldbm/db-bdb/bdb_layer.c:13:
./ldap/servers/slapd/slap.h:544:20: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘.’ token
  544 | #define f_type f_un.f_un_type
      | ^
./ldap/servers/slapd/slap.h:544:20: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘.’ token
  544 | #define f_type f_un.f_un_type

but in the process of writing my response I've double checked my work and narrowed down the issue to requiring <sys/statvfs.h> be included in "ldap/servers/slapd/slap.h" for the code to compile correctly.

Looking through the upstream bug reports, all I found was: https://github.com/389ds/389-ds-base/issues/5962
which doesn't seem immediately related.

Adding the include to the relevant file (slap.h) seems to have addressed the compilation error and allows for simply rearranging the includes in the source file as you suggested.

Frankly, I'm still unsure why that specific include bypasses the compilation error at all, but I've attached a new diff.

Thanks, Chris.

I went ahead and uploaded it to noble-proposed. A few suggestions the next time:

- Providing a PPA and the dep8 test results is always welcome. It allows the sponsor to really check that the fix works and doesn't introduce any regressions.

- I adjusted the changelog entry to fully express the path of the new patch (i.e., "d/p/32bit...").

Also, it would be great if you could submit this patch upstream and/or to Debian. This way, we can make the package become a sync again in the near future. WDYT?

Thanks.

> Providing a PPA and the dep8 test results is always welcome. It allows the sponsor to really check that the fix works and doesn't introduce any regressions.

By dep8 test results you mean autopkgtest results right? But ACK, I will keep that in mind for the future. Thank you for the feedback.

> "d/p/32bit..."

I tried to match the style of the previous changelog entries, but I'll keep this in mind too, thanks.

> submit this patch upstream and/or to Debian.

I plan to do both, I just hadn't got to it yet. I will submit these today.

I was about to comment when I saw this was uploaded. FWIW, and something to keep in mind when submitting to Debian, is that I think this could be fixed by just:

diff --git a/debian/rules b/debian/rules
index 0c9d9e1b..f4943098 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,6 +7,9 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+pie
 ifneq (,$(filter $(DEB_HOST_ARCH), armel m68k mips mipsel powerpc powerpcspe sh4))
   export DEB_LDFLAGS_MAINT_APPEND=-latomic
 endif
+ifneq (,$(filter $(DEB_HOST_ARCH), armhf))
+ export DEB_CFLAGS_MAINT_APPEND=-D_LARGEFILE64_SOURCE
+endif

 REALFILE = \
        bin/ds-logpipe.py \

I.e., just avoid the ifdeffery (which is complicated by inclusion order), and define _LARGEFILE64_SOURCE on armhf (since we know it's needed).

On Friday, February 09 2024, Chris Peterson wrote:

>> Providing a PPA and the dep8 test results is always welcome. It allows
> the sponsor to really check that the fix works and doesn't introduce any
> regressions.
>
> By dep8 test results you mean autopkgtest results right? But ACK, I will
> keep that in mind for the future. Thank you for the feedback.

That's correct.

>> "d/p/32bit..."
>
> I tried to match the style of the previous changelog entries, but I'll
> keep this in mind too, thanks.

No problem, and it's not a big deal. This is more a matter of personal
taste.

>> submit this patch upstream and/or to Debian.
>
> I plan to do both, I just hadn't got to it yet. I will submit these
> today.

Awesome, thank you.

--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14

This bug was fixed in the package 389-ds-base - 2.4.4+dfsg1-1ubuntu1

---------------
389-ds-base (2.4.4+dfsg1-1ubuntu1) noble; urgency=medium

  * d/p/32bit-support.diff: Fixes support for 32-bit architectures
    (LP: #2052578)

 -- Chris Peterson <email address hidden> Thu, 08 Feb 2024 16:26:51 -0800

Upstream forward: https://github.com/389ds/389-ds-base/pull/6089

Thanks Nick, I tested your patch in a PPA and it worked. I forwarded it to Debian, but it looks like they may just remove the package anyways.

My response should appear here shortly: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063434