Bug 215741 - security/heimdal: 7.1.0 breaks OTP with sqlite backend
Summary: security/heimdal: 7.1.0 breaks OTP with sqlite backend
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Hiroki Sato
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-03 17:43 UTC by Phil Pennock
Modified: 2017-01-10 07:06 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (hrs)


Attachments
poudriere log of heimdal-7.1.0 build (32.75 KB, text/plain)
2017-01-03 17:43 UTC, Phil Pennock
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Phil Pennock 2017-01-03 17:43:20 UTC
Created attachment 178485 [details]
poudriere log of heimdal-7.1.0 build

As of today with ports git commit fe9cd7e2 updating security/heimdal to 7.1.0 this port no longer builds in my local poudriere environment.

Per the attached, I build with BDB=off SQLITE=on

The Port builds with `--enable-otp` unilaterally on.  This does not appear to be a change in the Port, so the error is probably a new upstream configure check.

```
configure: error: OTP requires a NDBM/DB compatible library
```

It looks like `--enable-otp` now needs to be dependent upon `BDB=on` ?

(For my use-case, losing OTP is acceptable, I'd rather have sqlite and no OTP than deal with BDB storage format compatibility headaches every couple of years)
Comment 1 commit-hook freebsd_committer freebsd_triage 2017-01-03 20:01:03 UTC
A commit references this bug:

Author: hrs
Date: Tue Jan  3 20:00:31 UTC 2017
New revision: 430517
URL: https://svnweb.freebsd.org/changeset/ports/430517

Log:
  - Enable dbopen() in DB 1.85 even if !BDB because libhdb with
    no backend is very confusing.

  - Fix build when !BDB[*]

  PR:	215741 [*]

Changes:
  head/security/heimdal/Makefile
  head/security/heimdal/files/patch-admin-Makefile.in
  head/security/heimdal/files/patch-appl-afsutil-Makefile.in
  head/security/heimdal/files/patch-appl-gssmask-Makefile.in
  head/security/heimdal/files/patch-appl-kf-Makefile.in
  head/security/heimdal/files/patch-appl-su-Makefile.in
  head/security/heimdal/files/patch-appl-test-Makefile.in
  head/security/heimdal/files/patch-configure
  head/security/heimdal/files/patch-doc__Makefile.in
  head/security/heimdal/files/patch-kadmin-Makefile.in
  head/security/heimdal/files/patch-kcm-Makefile.in
  head/security/heimdal/files/patch-kdc-Makefile.in
  head/security/heimdal/files/patch-kpasswd-Makefile.in
  head/security/heimdal/files/patch-kuser-Makefile.in
  head/security/heimdal/files/patch-lib-base-Makefile.in
  head/security/heimdal/files/patch-lib-gssapi-Makefile.in
  head/security/heimdal/files/patch-lib-hdb-Makefile.in
  head/security/heimdal/files/patch-lib-hx509-Makefile.in
  head/security/heimdal/files/patch-lib-kadm5-Makefile.in
  head/security/heimdal/files/patch-lib-krb5-Makefile.in
  head/security/heimdal/files/patch-lib-roken-Makefile.in
  head/security/heimdal/pkg-message
Comment 2 Phil Pennock 2017-01-03 22:18:11 UTC
With a fresh run, the Heimdal port itself built, but so far one dependent port has failed, when it didn't fail before.

dns/bind-tools building with `GSSAPI_HEIMDAL=on` fails `./configure`

--CONFIGURE_ARGS--
--localstatedir=/var --disable-linux-caps  --disable-symtable  --with-randomdev=/dev/random  --with-libxml2=/usr/local  --with-readline="-L/usr/local/lib -ledit"  --with-dlopen=yes  --sysconfdir=/usr/local/etc/namedb --disable-shared --disable-filter-aaaa --disable-fixed-rrset --with-idn=/usr/local  --enable-ipv6 --with-libjson --disable-largefile --without-python --with-gssapi=/usr/local KRB5CONFIG="/usr/local/bin/krb5-config" --with-openssl=/usr/local --disable-native-pkcs11 --with-gost --enable-threads --prefix=/usr/local ${_LATE_CONFIGURE_ARGS}
--End CONFIGURE_ARGS--


[...]
checking for GSSAPI library... looking in /usr/local/lib
checking gssapi.h usability... yes
checking gssapi.h presence... yes
checking for gssapi.h... yes
checking gssapi/gssapi.h usability... yes
checking gssapi/gssapi.h presence... yes
checking for gssapi/gssapi.h... yes
checking gssapi_krb5.h usability... no
checking gssapi_krb5.h presence... no
checking for gssapi_krb5.h... no
checking gssapi/gssapi_krb5.h usability... yes
checking gssapi/gssapi_krb5.h presence... yes
checking for gssapi/gssapi_krb5.h... yes
checking krb5.h usability... yes
checking krb5.h presence... yes
checking for krb5.h... yes
checking krb5/krb5.h usability... no
checking krb5/krb5.h presence... no
checking for krb5/krb5.h... no
checking kerberosv5/krb5.h usability... no
checking kerberosv5/krb5.h presence... no
checking for kerberosv5/krb5.h... no
checking linking as -Wl,--enable-new-dtags -Wl,-rpath -Wl,/usr/local/lib/heimdal -L/usr/local/lib/heimdal -lgssapi... no
configure: error: could not determine proper GSSAPI linkage
===>  Script "configure" failed unexpectedly.
Please report the problem to mat@FreeBSD.org [maintainer] and attach the
"/wrkdirs/usr/ports/dns/bind-tools/work/bind-9.11.0-P1/config.log" including
the output of the failure of your make command. Also, it might be a good idea
to provide an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
Comment 3 Phil Pennock 2017-01-03 22:55:19 UTC
nb: I have disabled the GSSAPI dependency in bind-tools locally, via `GSSAPI_NONE` options choice, so won't be able to test any fixes for that dependency.  I'm assuming though that where one port breaks, others will too, so this is still of interest.
Comment 4 Hiroki Sato freebsd_committer freebsd_triage 2017-01-10 07:06:55 UTC
r430529 should fix this.  Please re-open this PR if the problem persists.