... ====> Compressing man pages (compress-man) =========================================================================== ====> Running Q/A tests (stage-qa) Warning: 'lib/python2.7/site-packages/tdb.so' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'lib/python2.7/site-packages/_tevent.so' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Error: /usr/local/lib/libpyldb-util.so.1 is linked to /usr/local/lib/libintl.so.8 from devel/gettext-runtime but it is not declared as a dependency Warning: you need USES+=gettext-runtime ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist Error: Orphaned: %%PYTHON_SITELIBDIR%%/_tdb_text.py Error: Orphaned: %%PYTHON_SITELIBDIR%%/_tevent.so Error: Orphaned: %%PYTHON_SITELIBDIR%%/tdb.so Error: Orphaned: %%PYTHON_SITELIBDIR%%/tevent.py ===> Checking for items in pkg-plist which are not in STAGEDIR ===> Error: Plist issues found. *** Error code 1 Stop. make: stopped in /usr/ports/databases/ldb14 Full log: https://people.freebsd.org/~amdmi3/ldb14.log
Created attachment 210661 [details] database_ldb14_Makefile.patch This is going on 3 months with no fix, and blocking 241347. Attached patch resolves fully, if not elegantly. Please commit ASAP on maintainer timeout.
(In reply to Phillip R. Jaenke from comment #1) The patch does not apply due to CRLF line terminators.
(In reply to Phillip R. Jaenke from comment #1) If you need ldb 1.4 then you are doing something wrong. The only valid Samba ATM is the Samba 4.10, which is dependent on ldb 1.5. If you want to bring Samba independent dependency, then, please, use databses/ldb instead. This has to be cleaned up from the Samba 4.8 compatibility staff, but that's a different story. By using ldb 1.4 you just again introducing conflict with Samba, just on another iteration. Please, don't do this.
(In reply to Phillip R. Jaenke from comment #1) Moreover your patch is completely wrong, just brute forcing configuration that you happen to have, omitting all the system variables and breaking compatibility with Python 2.7+(which is questionably necessary now by itself) and Python3. Your particular problem is easily resolvable by setting: WITH_SAMBA4_PYTHON3=3.7 In the /etc/make.conf. But again, I'm strongly dis-advise to use any ldb1[2-9] ports for SSD.
(In reply to Dmitry Marakasov from comment #2) Somebody needs to check Bugzilla there. I literally copy-pasted `cat the-working-patch` into the box.
Created attachment 210717 [details] Same patch, not copy-pasted (In reply to Timur I. Bakeyev from comment #4) You keep sending snippy 'send patches' responses to everyone - well here's a patch. This is tested and working in my environment with no issues; bugzilla mangled the patch - it happens. The patch is still valid. That certainly does not justify or warranty closing a valid bug, especially with incorrect information. net/openldap24-[client,server] depends on ldb14 and will continue to depend on ldb14 for the foreseeable future, which impacts a further 124 ports. It should not require dragging portmgr@ in to deal with what is unquestionably a valid bug for what amounts to a 4 line fix that took me 5 minutes.
(In reply to Phillip R. Jaenke from comment #6) > You keep sending snippy 'send patches' responses to everyone - well here's a > patch. This is tested and working in my environment with no issues; bugzilla > mangled the patch - it happens. The patch is still valid. That certainly does > not justify or warranty closing a valid bug, especially with incorrect > information. Patches are welcome, but correct patches, which do take ports infrastructure into account and variety of the system configuration options. The provided patch just brute forced the state of your environment, without taking into account the presence or absence of Python 2 and Python 3 in the system. > net/openldap24-[client,server] depends on ldb14 and will continue to depend on > ldb14 for the foreseeable future, which impacts a further 124 ports. It could be that I'm missing something, but I'd be VERY surprised if OpenLDAP depends on any version of LDB. The opposite is true, but who doesn't? Can you, please, provide any confirmation of that statement? So far I see only: # pkg rquery %ro ldb14 security/sssd security/sssd Which is also a bug on my opinion, introduced by: r505782 | antoine | 2019-07-03 21:30:03 +0200 (Wed, 03 Jul 2019) | 2 lines > It should not require dragging portmgr@ in to deal with what is unquestionably > a valid bug for what amounts to a 4 line fix that took me 5 minutes. The bug is valid, but should be obsoleted, as NOTHING should depend on any of ldb1[2-9] ports. Alas, the mentioned above commit introduced that invalid dependency and now I have to deal with the consequences of this. Rolling back to databases/ldb may not work properly, as database format has changed between the versions and downgrade is... Not supported. Well, databases/ldb may become that moving target...
I guess the easiest solution for ldb14 would be to disable Python bindings completely, as they are not used(?) by SSSD and the given combination of Python3 enabled talloc/tevent/tdb and Python 2 bind ldb doesn't play well anyhow. You can try to build port with NO_PYTHON=yes configuration option to see if that helps.
Expired port removed.