Trying to upgrade from 2.4.39 to 2.4.40 fails with: checking if Berkeley DB version supported by BDB/HDB backends... yes checking for off_t... no configure: error: BerkeleyDB version incompatible with BDB/HDB backends The cause is: configure:22474: checking for Berkeley DB major version in db.h configure:22494: result: 6 configure:22500: checking for Berkeley DB minor version in db.h configure:22520: result: 0 configure:22526: checking if Berkeley DB version supported by BDB/HDB backends conftest.c:152:2: error: #error "BerkeleyDB 6.0.20+ license is incompatible with LDAP" #error "BerkeleyDB 6.0.20+ license is incompatible with LDAP" ^ configure:22568: result: no configure:22573: error: BerkeleyDB version incompatible with BDB/HDB backends As bug #523256 describes this breakage was intentionally introduced upstream, because of license changes in BerkeleyDB. But the ebuild of 2.4.40 does not reflect this restriction and so it fails to build. Or can configure made to automatically fall back to an older version, as I have both sys-libs/db-4.8.30-r2 and 6.0.30-r1 installed?
Is there any workaround? 'emerge @preserved-rebuild' due to this issue and 'emerge --exclude openldap @preserved-rebuild' fails also with: root@dog:/root(9)# emerge --exclude openldap @preserved-rebuild Calculating dependencies... done! !!! All ebuilds that could satisfy ">=net-nds/openldap-2:=" have been masked. !!! One of the following masked packages is required to complete your request: ... (dependency required by "mail-client/evolution-3.12.6[ldap]" [ebuild]) (dependency required by "@preserved-rebuild" [argument])
'perl-cleaner --all' and 'emerge -uvND --exclude "stunnel openldap" --keep-going world' fails as well.
Workaround found there : http://www.linuxfromscratch.org/blfs/view/svn/server/openldap.html
(In reply to Joachim IONOFF from comment #3) > Workaround found there : > http://www.linuxfromscratch.org/blfs/view/svn/server/openldap.html Confirm that the workaround works. Thanks
(In reply to timemars from comment #4) > (In reply to Joachim IONOFF from comment #3) > > Workaround found there : > > http://www.linuxfromscratch.org/blfs/view/svn/server/openldap.html > > Confirm that the workaround works. Thanks I a unsure of how to implement this as a workaround. The only reference I see to BerkeleyDB is that one should use 6.1.19, which is masked in the tree for failing the upstream testsuite. Is there a different workaround?
I successfully tested 2 workarounds: - mask sys-libs/db-6*, install sys-libs/db-5* and emerge openldap - USE=-berkdb emerge -1 openldap
The strange thing is, that I have three systems, where the upgrade from 2.4.39 to 2.4.40 fails and I have five systems, where it works like a charm and there are the same versions of Berkeley DB installed of both classes of systems: rose@caiman:/home/rose(4)$ qlist -Iv openldap net-nds/openldap-2.4.39 rose@caiman:/home/rose(5)$ qlist -Iv sys-libs/db sys-libs/db-4.8.30-r2 sys-libs/db-6.0.30-r1 'emerge openldap' fails for version 2.4.40 on caiman. root@lynx:/root(8)# genlop -t openldap | tail Sat Sep 20 11:35:35 2014 >>> net-nds/openldap-2.4.39 merge time: 2 minutes and 14 seconds. Mon Oct 13 10:13:46 2014 >>> net-nds/openldap-2.4.40 merge time: 1 minute and 58 seconds. Tue Oct 14 13:10:46 2014 >>> net-nds/openldap-2.4.40 merge time: 2 minutes and 1 second. root@lynx:/root(9)# qlist -Iv sys-libs/db sys-libs/db-4.8.30-r2 sys-libs/db-6.0.30-r1
(In reply to N. Andrew Walsh from comment #5) > (In reply to timemars from comment #4) > > (In reply to Joachim IONOFF from comment #3) > > > Workaround found there : > > > http://www.linuxfromscratch.org/blfs/view/svn/server/openldap.html > > > > Confirm that the workaround works. Thanks > > I a unsure of how to implement this as a workaround. The only reference I > see to BerkeleyDB is that one should use 6.1.19, which is masked in the tree > for failing the upstream testsuite. Is there a different workaround? Hi Andrew, the installation instruction states that the sed...configure command fixes configure script for building with Berkeley DB-6.0.20 or later. Thus I pressed Ctrl+z to pause the emerge process immediately after the autoconf phase, edited the file configure by running the sed...configure command, and typed 'fg' to resume the emerge process. I am too lazy to edit the ebuild. :P
Created attachment 386678 [details] an openldap-2.4.40.ebuild containing the sed command
(In reply to timemars from comment #8) > (In reply to N. Andrew Walsh from comment #5) > > (In reply to timemars from comment #4) > > > (In reply to Joachim IONOFF from comment #3) > > > > Workaround found there : > > > > http://www.linuxfromscratch.org/blfs/view/svn/server/openldap.html > > > > > > Confirm that the workaround works. Thanks > > > > I a unsure of how to implement this as a workaround. The only reference I > > see to BerkeleyDB is that one should use 6.1.19, which is masked in the tree > > for failing the upstream testsuite. Is there a different workaround? > > Hi Andrew, the installation instruction states that the sed...configure > command fixes configure script for building with Berkeley DB-6.0.20 or > later. Thus I pressed Ctrl+z to pause the emerge process immediately after > the autoconf phase, edited the file configure by running the sed...configure > command, and typed 'fg' to resume the emerge process. > > I am too lazy to edit the ebuild. :P Can confirm, that the sed command worked. Am to lazy to press Ctrl+z and enter it manually so I modified the ebuild in my local overlay. :P
Created attachment 386762 [details, diff] Remove BerkeleyDB < 6.0.20 restriction
(In reply to Juergen Rose from comment #9) > Created attachment 386678 [details] > an openldap-2.4.40.ebuild containing the sed command Confirmed working here; the package built AOK.
*** Bug 526218 has been marked as a duplicate of this bug. ***
InCVS. Please see the addition of USE=bindist, to fill the upstream license requirements.
Upstream OpenLDAP has requested that we not distribute an OpenLDAP with BDB-6 support at all (see below). As such, I'm rolling out a r2 ebuild, that restricts it to BDB-4.4 .. 5.x > Date: 27 Oct 2014 15:55:07 +0000 > From: Howard Chu <hyc@highlandsun.com> > Subject: [gentoo-commits] gentoo-x86 commit in net-nds/openldap/files: openldap-2.4.40-db-6.patch slapd-initd-2.4.40-r1 > To: robbat2@gentoo.org, gentoo-commits@lists.gentoo.org > Your mucking with the BDB 6 check is incorrect. It is not simply that > such binaries may not be distributed - they may not be used, period. > > The AGPL requires that any server using the software must inform every > client of the availability of the source code. There is no ability to > provide this notification to clients in the LDAP *Protocol*. To even > run an LDAP server with BDB 6.0.20+ is a violation of the AGPL. > > We don't make these upstream changes lightly. You should talk to us > before making build changes like this. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/
-r2 is now in the tree, with BDB6 disabled. For anybody that's BOUGHT a license from Oracle to use BDB6 outside of the AGPL3, please open a new bug, asking for the capability back...
BTW., why does any 'emerge -vuDN world' emerges openldap-2.4.40-r3 since Nov 10th? root@impala:/usr/src(28)# genlop -t openldap | tail -n 130 Wed Oct 29 13:59:21 2014 >>> net-nds/openldap-2.4.40-r2 merge time: 4 minutes and 56 seconds. Mon Nov 10 06:48:25 2014 >>> net-nds/openldap-2.4.40-r3 merge time: 4 minutes and 54 seconds. Tue Nov 11 12:38:33 2014 >>> net-nds/openldap-2.4.40-r3 merge time: 4 minutes and 55 seconds. Tue Nov 11 15:53:26 2014 >>> net-nds/openldap-2.4.40-r3 merge time: 5 minutes and 7 seconds. ... Thu Nov 27 15:00:09 2014 >>> net-nds/openldap-2.4.40-r3 merge time: 4 minutes and 51 seconds. Fri Nov 28 09:15:48 2014 >>> net-nds/openldap-2.4.40-r3 merge time: 4 minutes and 54 seconds. root@impala:/root(21)# emerge -pvuDNt world These are the packages that would be merged, in reverse order: Calculating dependencies... done! [nomerge ] media-gfx/freecad-0.14.3702-r1 PYTHON_TARGETS="python2_7" [ebuild R ] dev-python/pyside-1.2.2 USE="X declarative designer multimedia opengl sql svg webkit -help -phonon -script -scripttools {-test} -xmlpatterns" PYTHON_TARGETS="python2_7 python3_3 -python3_4 (-python3_2%)" 0 KiB [ebuild rR ] dev-lang/gdl-0.9.4 USE="eigen fftw hdf hdf5 imagemagick netcdf openmp postscript proj python wxwidgets -grib -gshhs -static-libs {-test} -udunits" PYTHON_TARGETS="python2_7" 0 KiB [ebuild rR ] net-nds/openldap-2.4.40-r3 USE="berkdb crypt cxx gnutls icu ipv6 kerberos odbc perl samba sasl slp ssl syslog tcpd -debug -experimental -iodbc -minimal -overlays (-selinux) -smbkrb5passwd -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB [ebuild R ] dev-python/matplotlib-1.3.1 USE="cairo examples fltk gtk gtk3 latex qt4 tk wxwidgets -doc -excel -pyside {-test}" PYTHON_TARGETS="python2_7 python3_3 -python3_4 (-python3_2%)" 0 KiB [nomerge ] sci-visualization/paraview-4.1.0-r1::x-portage USE="boost cg doc examples ffmpeg mpi mysql plugins python qt4 sqlite tcl tk -coprocessing -development -nvcontrol {-test}" PYTHON_TARGETS="python2_7" [ebuild U ] dev-libs/protobuf-2.5.0-r2:0/8 [2.5.0-r1:0/8] USE="emacs examples java python -source -static-libs -vim-syntax" ABI_X86="(64%*) -32% (-x32)" PYTHON_TARGETS="python2_7" 0 KiB Total: 5 packages (1 upgrade, 4 reinstalls), Size of downloads: 0 KiB
I am too seeing the same issue (openldap keeps rebuilding all the time).
I'm seeing the rebuild problem too. https://bugs.gentoo.org/show_bug.cgi?id=528610#c29 Its a bug in portage and already is fixed, but the fix is not yet released as a new version of portage.
