* Generating an empty sasldb2 ... illegal flag specified to DB_ENV->set_encrypt DB->fd: method not permitted before handle's open method illegal flag specified to DB_ENV->set_encrypt DB->fd: method not permitted before handle's open method saslpasswd2: generic failure * ERROR: dev-libs/cyrus-sasl-2.1.28-r5::gentoo failed (install phase): * Failed to generate sasldb2 * ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_musl-20240824-035506 UNMASKED: Please re-assign to toolchain@ if you get a test failure in C, C++, or Fortran code which makes no sense. /etc/portage/package.unmask/60gcc:<sys-devel/gcc-15.0.9999:15 The attached etc.portage.tar.xz has all details. ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-musl-15 * clang/llvm (if any): clang version 18.1.8 Target: x86_64-pc-linux-musl Thread model: posix InstalledDir: /usr/lib/llvm/18/bin Configuration file: /etc/clang/x86_64-pc-linux-musl-clang.cfg /usr/lib/llvm/18 18.1.8 Python 3.12.5 Available Ruby profiles: [1] ruby31 (with Rubygems) [2] ruby32 (with Rubygems) [3] ruby33 (with Rubygems) * Available Rust versions: [1] rust-bin-1.80.1 * The following VMs are available for generation-2: 1) Eclipse Temurin JDK 17.0.12_p7 [openjdk-bin-17] *) Eclipse Temurin JDK 21.0.4_p7 [openjdk-bin-21] Available Java Virtual Machines: [1] openjdk-bin-17 [2] openjdk-bin-21 system-vm php cli (if any): go version go1.23.0 linux/amd64 HEAD of ::gentoo commit a0cfd054b5657989a40da3fc7788193213f1bc89 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Sun Aug 25 02:49:01 2024 +0000 2024-08-25 02:49:01 UTC emerge -qpvO =dev-libs/cyrus-sasl-2.1.28-r5 [ebuild N ] dev-libs/cyrus-sasl-2.1.28-r5 USE="berkdb mysql openldap pam sample ssl urandom -authdaemond -gdbm -kerberos -ldapdb -postgres (-selinux) -sqlite -srp -static-libs"
Created attachment 901209 [details] emerge-info.txt
Created attachment 901210 [details] dev-libs:cyrus-sasl-2.1.28-r5:20240825-035639.log
Created attachment 901211 [details] emerge-history.txt
Created attachment 901212 [details] environment
Created attachment 901213 [details] etc.clang.tar.xz
Created attachment 901214 [details] etc.portage.tar.xz
Created attachment 901215 [details] logs.tar.xz
Created attachment 901216 [details] qlist-info.txt
Created attachment 901217 [details] temp.tar.xz
Same error on 3 machines.
I'm also seeing this on my machine. ================================ * Generating an empty sasldb2 ... call implies an access method which is inconsistent with previous calls DB->cursor: method not permitted before handle's open method call implies an access method which is inconsistent with previous calls DB->cursor: method not permitted before handle's open method saslpasswd2: generic failure * ERROR: dev-libs/cyrus-sasl-2.1.28-r5::gentoo failed (install phase): * Failed to generate sasldb2 * * Call stack: * ebuild.sh, line 136: Called src_install * environment, line 2850: Called multilib-minimal_src_install * environment, line 2062: Called multilib_foreach_abi 'multilib-minimal_abi_src_install' * environment, line 2292: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' * environment, line 1974: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' * environment, line 1972: Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_install' * environment, line 580: Called multilib-minimal_abi_src_install * environment, line 2052: Called multilib_src_install * environment, line 2554: Called die * The specific snippet of code: * ./utils/saslpasswd2 -f "${ED}"/etc/sasl2/sasldb2-empty -p login <<< p || die "Failed to generate sasldb2"; * * If you need support, post the output of `emerge --info '=dev-libs/cyrus-sasl-2.1.28-r5::gentoo'`, * the complete build log and the output of `emerge -pqv '=dev-libs/cyrus-sasl-2.1.28-r5::gentoo'`. * The complete build log is located at '/var/log/portage/build/dev-libs/cyrus-sasl-2.1.28-r5:20241127-161427.log'. * For convenience, a symlink to the build log is located at '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.28-r5/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.28-r5/temp/environment'. * Working directory: '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.28-r5/work/cyrus-sasl-2.1.28-abi_x86_64.amd64' * S: '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.28-r5/work/cyrus-sasl-2.1.28' ================================ $ gcc-config -l [1] x86_64-pc-linux-gnu-13 * [2] x86_64-pc-linux-gnu-14 ================================ I can share more info if need be.
Sorry I didn't see this bug in the first place when searching and then added here: https://bugs.gentoo.org/944628 So I do have the same problem.
I know I made the last major change to this package, but I don't think this is a new problem. It's a slightly different error message to the one reported by Toralf in bug #664842, but the last commenter there reported the same error message as this one back in 2019. I did try looking into that issue when I made my changes, but I don't think I was able to reproduce it, and I still can't reproduce it now.
(In reply to James Le Cuirot from comment #13) > I know I made the last major change to this package, but I don't think this > is a new problem. It's a slightly different error message to the one > reported by Toralf in bug #664842, but the last commenter there reported the > same error message as this one back in 2019. I did try looking into that > issue when I made my changes, but I don't think I was able to reproduce it, > and I still can't reproduce it now. Wait, Toralf's error message here *is* the same as #664842, but comment #11 shows the other message. So there's two messages that keep appearing.
Created attachment 914797 [details] build.log
I added my build log above. looks same error on my end.
In case it's helpful, and to make it explicit: I have no issue with -r4.
(In reply to Philippe Chaintreuil from comment #17) > In case it's helpful, and to make it explicit: I have no issue with -r4. same here, I can easily rebuild -r4
You might see it if you delete /etc/sasl2/sasldb2 first.
(In reply to James Le Cuirot from comment #19) > You might see it if you delete /etc/sasl2/sasldb2 first. I have one, and it's pretty old: ============================================================== $ ls -la /etc/sasl2/sasldb2 -rw-r----- 1 root mail 12288 Aug 6 2015 /etc/sasl2/sasldb2 ============================================================== But renaming it to sasldb2.bak did not change the error.
Just running the command on -r4, I get the "DB->cursor" error from the logs, so the issue is present in -r4, I presume -r4 doesn't try to run the command. ================================================== $ sudo /usr/sbin/saslpasswd2 -f /etc/sasl2/sasldb2 -d login DB->cursor: method not permitted before handle's open method DB->cursor: method not permitted before handle's open method DB->cursor: method not permitted before handle's open method DB->cursor: method not permitted before handle's open method DB->cursor: method not permitted before handle's open method ================================================== strace shows it pretty early -- right after .so's are being loaded. Aside from .so files, it only seems to open /etc/sasl2/saslpasswd.conf, /dev/urandom, and /sys/devices/system/cpu/online before the error gets output. ================================================== [...] openat(AT_FDCWD, "/usr/lib64/sasl2/liblogin.la", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib64/sasl2/liblogin.so", O_RDONLY|O_CLOEXEC) = 4 read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832 fstat(4, {st_mode=S_IFREG|0755, st_size=26704, ...}) = 0 mmap(NULL, 24816, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7f33133d5000 mmap(0x7f33133d6000, 12288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1000) = 0x7f33133d6000 mmap(0x7f33133d9000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x4000) = 0x7f33133d9000 mmap(0x7f33133da000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x5000) = 0x7f33133da000 close(4) = 0 mprotect(0x7f33133da000, 4096, PROT_READ) = 0 getdents64(3, 0x55f4b21388f0 /* 0 entries */, 32768) = 0 close(3) = 0 ioctl(0, TCGETS, {c_iflag=ICRNL|IXON|IXANY|IMAXBEL|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B9600|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0 getpid() = 7715 openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 3 read(3, "0-1\n", 1024) = 4 close(3) = 0 write(2, "\n", 1 ) = 1 write(2, "DB->cursor: method not permitted"..., 60DB->cursor: method not permitted before handle's open method) = 60 write(2, "\n", 1 ) = 1 openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=3552, ...}) = 0 [...] ================================================== Upstream bug?
Looking at the patches Fedora applies [0], I wonder if https://src.fedoraproject.org/rpms/cyrus-sasl/blob/rawhide/f/cyrus-sasl-2.1.23-db5.patch could help? (completely blind guess) [0] https://src.fedoraproject.org/rpms/cyrus-sasl/tree/rawhide
(In reply to Sam James from comment #22) > Looking at the patches Fedora applies [0], I wonder if > https://src.fedoraproject.org/rpms/cyrus-sasl/blob/rawhide/f/cyrus-sasl-2.1. > 23-db5.patch could help? (completely blind guess) > > [0] https://src.fedoraproject.org/rpms/cyrus-sasl/tree/rawhide ... in that vein, it might be useful if folks for whom it works and doesn't could state clearly which sys-libs/db version they have (and if it works or not).
Aha. I get it with sys-libs/db 6.0.35-r5 here if I build cyrus-sasl with berkdb. I was building with gdbm before.
That Fedora patch doesn't apply at all, those lines have changed to using this condition since: > #if DB_VERSION_FULL >= 0x04010000
(In reply to James Le Cuirot from comment #24) > Aha. I get it with sys-libs/db 6.0.35-r5 here if I build cyrus-sasl with > berkdb. I was building with gdbm before. What do you mean with "I get it"? you get it running or you get the error?
(In reply to Sam James from comment #23) > (In reply to Sam James from comment #22) > > Looking at the patches Fedora applies [0], I wonder if > > https://src.fedoraproject.org/rpms/cyrus-sasl/blob/rawhide/f/cyrus-sasl-2.1. > > 23-db5.patch could help? (completely blind guess) > > > > [0] https://src.fedoraproject.org/rpms/cyrus-sasl/tree/rawhide > > ... in that vein, it might be useful if folks for whom it works and doesn't > could state clearly which sys-libs/db version they have (and if it works or > not). up to now I have sys-libs/db-5.3.28-r10 installed and get the error. I tried sys-libs/db-6.0.35-r5 as well (not sure I somehow would need to force actually using that slot 6) and still get the error
(In reply to Sam James from comment #23) > ... in that vein, it might be useful if folks for whom it works and doesn't > could state clearly which sys-libs/db version they have (and if it works or > not). I have sys-libs/db-4.8.30-r9 & sys-libs/db-5.3.28-r10 installed and get the error.
The sys-libs/db-4.8.30-r9 is installed here in addition, too. Sorry for my impreciseness
I really wonder, so less people need cyrus-sasl for authenticated login while sending mail via external mail-server and hence so little progress on such a blocking issue? What do I understand wrong or oversee alternatives?
It's specific to certain USE (berkdb).
*** Bug 951574 has been marked as a duplicate of this bug. ***
During tatt package testing for bug #944628 I found out this only occurs with USE='berkdb -gdbm'. The other USE-flag combinations work fine: # cat cyrus-sasl-944628.report USE tests started on Tue Mar 18 21:54:26 CET 2025 FEATURES=' test' USE='' succeeded for =dev-libs/cyrus-sasl-2.1.28-r5 USE='-authdaemond berkdb -gdbm -kerberos ldapdb openldap pam postgres -sample -sqlite srp -ssl -static-libs -urandom' failed for =dev-libs/cyrus-sasl-2.1.28-r5 USE='-authdaemond -berkdb -gdbm -kerberos ldapdb openldap pam -postgres sample sqlite srp ssl -static-libs -urandom' succeeded for =dev-libs/cyrus-sasl-2.1.28-r5 USE='-authdaemond -berkdb gdbm kerberos -ldapdb -openldap -pam -postgres -sample sqlite -srp -ssl static-libs -urandom' succeeded for =dev-libs/cyrus-sasl-2.1.28-r5 USE='authdaemond -berkdb -gdbm -kerberos ldapdb openldap -pam postgres sample sqlite -srp -ssl static-libs -urandom' succeeded for =dev-libs/cyrus-sasl-2.1.28-r5 USE='authdaemond berkdb -gdbm kerberos -ldapdb -openldap -pam postgres sample -sqlite srp ssl static-libs -urandom' failed for =dev-libs/cyrus-sasl-2.1.28-r5 USE='authdaemond -berkdb -gdbm kerberos -ldapdb openldap pam -postgres -sample sqlite srp ssl static-libs -urandom' succeeded for =dev-libs/cyrus-sasl-2.1.28-r5 USE='authdaemond berkdb -gdbm -kerberos -ldapdb openldap -pam postgres sample sqlite srp -ssl -static-libs urandom' failed for =dev-libs/cyrus-sasl-2.1.28-r5 USE='authdaemond -berkdb -gdbm -kerberos -ldapdb -openldap pam postgres sample -sqlite -srp ssl -static-libs urandom' succeeded for =dev-libs/cyrus-sasl-2.1.28-r5 USE='-authdaemond berkdb gdbm kerberos -ldapdb -openldap pam -postgres sample -sqlite srp ssl -static-libs urandom' succeeded for =dev-libs/cyrus-sasl-2.1.28-r5 USE='authdaemond -berkdb -gdbm -kerberos ldapdb openldap -pam -postgres -sample sqlite srp ssl -static-libs urandom' succeeded for =dev-libs/cyrus-sasl-2.1.28-r5 USE='-authdaemond -berkdb gdbm -kerberos ldapdb openldap pam -postgres -sample sqlite srp ssl -static-libs urandom' succeeded for =dev-libs/cyrus-sasl-2.1.28-r5 USE='authdaemond berkdb -gdbm -kerberos -ldapdb -openldap pam postgres -sample -sqlite -srp -ssl static-libs urandom' failed for =dev-libs/cyrus-sasl-2.1.28-r5
