New major version of BIND 9.16 is available, but not yet packaged. Current snapshots are at COPR [1] repository. Some changes noted: - requires libuv library - not yet support for native PKCS11. We would like OpenSSL PKCS#11 support possible. - isc-config.sh was removed by upstream. Libraries are no longer considered for public consumtion. That affects bind-dyndb-ldap plugin and dnsperf. Linking against libraries is still possible, but bind-devel no longer provides it. 1. https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.16/
Changes required to configuration file: dnssec-enable no longer has any effect and should be removed. - managed-keys and trusted-keys are replaced by trust-anchors [1]. /etc/named.root.key should be updated or different file should be used. 1. https://ftp.isc.org/isc/bind9/cur/9.16/doc/arm/Bv9ARM.ch05.html#trust_anchors
For some reason, SDB and DLZ modules are linked to /usr/sbin/named. They should be only to DLZ modules.
rndc.key generation does not work anymore. -r /dev/urandom is not accepted by rndc-confgen anymore. The server starts, but rndc does not work.
Updated to 9.16.4, which introduced changes to documentation and manual pages generation. It contains few fixes required.
petr, fyi, SoftwareCollection for ISC BIND v9.16.5 installed of F32 from COPR, as linked above, installs 'scl' which OOPS on exec on one subcommand, 'scl list-enabled'. I filed it upstream already, OOPS on exec of `scl list-enabled`, from BIND9 SoftwareCollection install https://gitlab.isc.org/isc-projects/bind9/-/issues/2051 in #fedeora-devel others suggested I cc: you as well. I haven't figured out yet how to add an external cc: @ ISC bugs, so commenting here ...
No need to add external bugs, I have account also on ISC gitlab [1]. @pemensik should work on comments there. Anyway, it is not issue in bind itself or it seems to. It should be filled to scl tool, which crashes reliably with your reproduction. Until scm_source is used, it does nothing wrong. I will open a new bug and add you to copy, once I finish gathering all report information. abrt tool is your friend, it should be able to report it from captured core dump. But note, it suggests it should not be used this way: $ scl_source --help Usage: source scl_source <action> [<collection> ...] Don't use this script outside of SCL scriptlets! Anyway, it is already handled by bug #1728450 and does not belong to this component. I cannot push fixed version to f32 for you I am afraid. SCL maintainers would have to do that. 1. https://gitlab.isc.org/pemensik
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
Prepared bind-dyndb-ldap backward compatibility macros. Made a test [1] release tag, prepared COPR [2] build. Now it has to be tested both with BIND 9.16 and BIND 9.11. I validated it only compiles so far. 1. https://github.com/pemensik/bind-dyndb-ldap/tree/bind-9.16-sg 2. https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.16/build/1607887/
For some strange reason, I am unable to prepare COPR builds fro Rawhide and f33 successfully. It always fails on COPR because latex config file: /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf is for some strange reason always generated on my mock builds, rawhide local builds. But it is not present on COPR builds. When it is missing, documentation build of Bv9ARM.pdf fails. It is owned by package texlive-kpathsea, but I could not find how is that file generated. Or how it should be on COPR and is not. Example of failed builds are on [1]. Check build log [2] for fmtutil-user --listcfg. It should start with fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order): fmtutil: /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf But because that file is not generated, build always fails on rawhide. The same commit works fine on f32 an f31 chroot. 1. https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.16/build/1637746/ 2. https://download.copr.fedorainfracloud.org/results/pemensik/bind-9.16/fedora-rawhide-x86_64/01637746-bind/builder-live.log.gz
Hi Tom, I have found you as texlive-base maintainer. My builds fail on Rawhide for some reason, check above comment #9 for details. Could you find reason, why my build does not have /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf generated on rawhide chroot? It is possible to generate configuration as unprivileged user? Ie. during the build as workaround I have found /usr/sbin/generate-fmtutilcnf, but it seems suited only for running as root. Build have no root privilege. Can you help me?
I'm trying to figure this out. 1. You never want to be running the -user version of texlive tools. See: http://tug.org/texlive/scripts-sys-user.html 2. /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf should be generated during the %transfiletriggerin for texlive-kpathsea, by this command: %{_bindir}/fmtutil-sys --all &> /dev/null ||: That should fire off once per transaction with any files installed into %{_texdir}. 3. I don't know why that's not happening in copr. I've seen some weird things when mock is not run in --isolation=simple. 4. One thing that is concerning in your logs is the large number of segfaults happening around systemd. I'm wondering if the fmtutil-sys invocation is crashing as well.
(In reply to Tom "spot" Callaway from comment #11) > I'm trying to figure this out. > > 1. You never want to be running the -user version of texlive tools. See: > http://tug.org/texlive/scripts-sys-user.html > > 2. /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf should be generated > during the %transfiletriggerin for texlive-kpathsea, by this command: > > %{_bindir}/fmtutil-sys --all &> /dev/null ||: I have noticed installation order on failing COPR machines. There texlive-xetex is installed before texlive-kpat > > That should fire off once per transaction with any files installed into > %{_texdir}. > > 3. I don't know why that's not happening in copr. I've seen some weird > things when mock is not run in --isolation=simple. > > 4. One thing that is concerning in your logs is the large number of > segfaults happening around systemd. I'm wondering if the fmtutil-sys > invocation is crashing as well. If it would help, I have created smaller package [1] able to reproduce this issue. It is rpkg repository configured as: Source Type: Build from an SCM repository SCM type: git Clone URL: https://src.fedoraproject.org/forks/pemensik/rpms/bind.git Committish: texlive-test Subdirectory: texlive Build SRPM with: rpkg It passes correctly on f31 and f32, but fails on f33 and rawhide. It manifest the same issues my build did. I am confused, there are proper requirements in texlive-xetex to depend on texlive-kpathsea, but it is installed before kpathsea. That way, it does not trigger config generation and later latexmk invocation fails. I am not sure why that happens, it might be specific to COPR installation. I were not able to reproduce that on any f31-f33 virtual machines. It seems the order of installed packages is reason to succeed. # Works on f32, fails on f33 $ curl https://download.copr.fedorainfracloud.org/results/pemensik/bind-9.16/fedora-{32,33}-x86_64/01637867-texlive-test/root.log.gz | gunzip -c | grep -E 'Installing.*(texlive-kpathsea|texlive-xetex)' % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 31214 100 31214 0 0 98466 0 --:--:-- --:--:-- --:--:-- 98466 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 DEBUG util.py:623: Installing : texlive-kpathsea-7:20190410-12.fc32.x86_64 115/395 # << OK, kpathsea first DEBUG util.py:623: Installing : texlive-xetexconfig-9:svn45845-19.fc32.noarch 256/395 DEBUG util.py:623: Installing : texlive-xetex-7:20190410-12.fc32.x86_64 321/395 100 51215 100 51215 0 0 162k 0 --:--:-- --:--:-- --:--:-- 162k DEBUG util.py:623: Installing : texlive-xetexconfig-9:svn45845-27.fc33.noarch 524/632 DEBUG util.py:623: Installing : texlive-xetex-7:20200327-15.fc33.x86_64 551/632 DEBUG util.py:623: Installing : texlive-kpathsea-7:20200327-15.fc33.x86_64 556/632 # << FAIL, kpatsea last 1. https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.16/package/texlive-test/
To move forward, I have disabled PDF generation on package build. It is unsolved, but main package can move forward. It seems to be related only to COPR anyway, it should work in dist-git.
It seems like texlive-kpathsea is installed after texlive-xetex, which is the problem here. I think either the transaction needs to be fixed by better specifying the dependencies (ie. scriptlets need to depend on kpathsea). Or even better, the script responsible for doing the changes should not only be run in %filetriggerin, but _also in %post_ of kpathsea. That way is guaranteed, no matter the order of installation, that the script will be run. From what I've seen elsewhere, we usually want to run the %filetriggerin scriptlet only if the main package _is installed_. But we don't want to strictly depend on the main package. E.g. see "info pages"; I want to install the info page in my "foo.rpm", but I don't require info.rpm to be installed for "foo" to be working. Anytime (later) user decides to install "info" package, %post scriptlet is run and all the info tree documentation is generated.
texlive-base has a %transfiletriggerin, which I will copy below: %transfiletriggerin -n texlive-kpathsea -- %{_texdir} /usr/share/texlive/texmf-dist/scripts/texlive/mktexlsr 2> /dev/null || : export TEXMF=/usr/share/texlive/texmf-dist export TEXMFCNF=/usr/share/texlive/texmf-dist/web2c export TEXMFCACHE=/var/lib/texmf %{_bindir}/mtxrun --generate &> /dev/null || : %{_bindir}/fmtutil-sys --all &> /dev/null || : ***** A %transfiletriggerin should fire off once per transaction when the "rule" is true, this rule is "any files added/changed in %{_texdir}". This should not depend on package ordering, it should get run at the end of the transaction. As far as the scriptlets depending on kpathsea... that doesn't make any sense, because the %transfiletriggerin is in the texlive-kpathsea package. Now, we _can_ also run this in %post of texlive-kpathsea, but... we're trying not to run these commands multiple times. The question here is: why does this work in a local install and in koji but not in copr? What is done differently? Are you invoking mock with --isolation=nspawn?
> This should not depend on package ordering, it should get run at the end of the transaction. That's right, per [1]: %transfiletriggerin: Executed once after transaction for all installed packages that contained file(s) that matches prefix of this trigger. Also executed after transaction if there was a package containing this file trigger in that transaction and there is/are some files(s) matching prefix of this trigger in rpmdb. https://rpm.org/user_doc/file_triggers.html > The question here is: why does this work in a local install and in koji but > not in copr? What is done differently? Are you invoking mock with > --isolation=nspawn? In Copr, yes. Locally, by default yes. In Koji, no. I'd be curious if nspawn environment can cause the transaction behaves differently than in normal chroot, though.
FWIW, this issue is pretty hard to play with without bug 1876430 and bug 1876441 resolved :-(
Rebuilt with new released version. Changes solib versions again. Disabled DLZ statically linked into named. Removed also DLZ modules from main named package, where it does not belong. Moved DLZ modules to %{_libdir}/named from %{_libdir}/bind. Created compatibility links in any case. Also merged two dlz-mysql and dlz-mysqldyn into single package. Just configuration and documentation is required for both of them, solved in sec.
what, if any, plans are there for addition of config/support to 9.6.17 pkgs for --with-lmdb=PATH build with LMDB library [yes|no|path] --with-maxminddb=PATH Build with MaxMind GeoIP2 support (auto|yes|no|path) [default=auto] --with-libidn2=PATH enable IDN support using GNU libidn2 [yes|no(default)|path] and standalone dlz bdbhpt (http://bind-dlz.sourceforge.net/bdbhpt_driver.html) module support ?
Latest 9.16.9 release changed database interface. bind-dyndb-ldap modification is required.
Merge prepared on master branch in commit [1], but waiting for protobuf-c [2] build to be merged. 1. https://src.fedoraproject.org/rpms/bind/c/ce6a7853ac6e54fdbc260eec8546dfe3e9cc343c 2. https://koji.fedoraproject.org/koji/buildinfo?buildID=1668205
(In reply to pgnet.dev from comment #19) > what, if any, plans are there for addition of config/support to 9.6.17 pkgs > for > > --with-lmdb=PATH build with LMDB library [yes|no|path] > --with-maxminddb=PATH Build with MaxMind GeoIP2 support > (auto|yes|no|path) > [default=auto] > --with-libidn2=PATH enable IDN support using GNU libidn2 > [yes|no(default)|path] > > and > > standalone dlz bdbhpt (http://bind-dlz.sourceforge.net/bdbhpt_driver.html) > module support > > ? No plans for Berkeley DB support, it is deprecated and being removed from Fedora. For that reason, it was removed from regular builds a while ago. I think there is licensing issues with that database, other backends are suggested instead. Is there any reason for this specific driver? GeoIP2 and IDN 2008 (libidn2) are already enabled in current 9.11.26 builds and would be enabled in 9.16.x builds as well. LMDB should be also enabled for some time and no plan to change it exists.
*** Bug 1916503 has been marked as a duplicate of this bug. ***
Production builds often fail, because unit tests do not handle higher count of CPU cores well. Filled merge request [1], not yet accepted. But fixes quite often failing builds on Fedora, would be replaced later by any final fix found. Again changed libdns and libns so version with a new update. 1. https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4582
Built by chainbuild https://koji.fedoraproject.org/koji/taskinfo?taskID=60243117