← Back to team overview

ubuntu-389-directory-server team mailing list archive

Re: [Bug 2052578] Re: 2.4.4+dfsg1-1 is FTBFS on armhf in Noble

 

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

-- 
You received this bug notification because you are a member of Ubuntu
389 Directory Server, which is subscribed to 389-ds-base in Ubuntu.
https://bugs.launchpad.net/bugs/2052578

Title:
   2.4.4+dfsg1-1 is FTBFS on armhf in Noble

Status in 389-ds-base package in Ubuntu:
  Triaged

Bug description:
  build fails with:
  ldap/servers/slapd/back-ldbm/db-bdb/bdb_layer.c: At top level:
  ldap/servers/slapd/back-ldbm/db-bdb/bdb_layer.c:429:26: error: unknown type name ‘off64_t’; did you mean ‘off_t’?
    429 | bdb_seek43_large(int fd, off64_t offset, int whence)
        |                          ^~~~~~~
        |                          off_t

  
  The source properly detects when to define _LARGEFILE64_SOURCE but I think this is an ordering issue of the define and a standard library header include.

  I can recreate this on an armhf machine by including <stdio.h> before
  the LFS define.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/389-ds-base/+bug/2052578/+subscriptions



References