hopefully the subject says it all the unbound that was bundled with FreeBSD 13
Hi Andrew, Do you mean this file? /usr/src/contrib/unbound/libunbound/unbound-event.h It can be obtained when installing the source code of the distribution (or via git clone). Can you elaborate? Thanks in advance.
(that's weird, the comments box appears at the top) Yes. If I remember right configuring with --libevent will add it to the install.
Make that --with-libevent
Nope, remind me to check the documentation: --enable-event-api Enable (experimental) pluggable event base libunbound API installed to unbound-event.h
Any progress? It is used when building libreswan's event-loop code.
(In reply to Andrew Cagney from comment #5) Since that is marked as experimental ("Enable (experimental) pluggable event base libunbound API installed to unbound-event.h") I can see why it is not included by default. I'm afraid that if you want ubound-event.h in 13.1 you will need to checkout the sources for the release and configure with --enable-event-api.
Interesting. NetBSD, OpenBSD, and the Linux distros all bundle this.
(In reply to Andrew Cagney from comment #7) I really don't know what version they use. At least in 1.17.0 (the one in current) it seems to be still experimental.
That's the version that is installed.
(In reply to Andrew Cagney from comment #9) I doubt we will bundle that file being marked as unstable. Would the provided workaround be useful for you?
> I'm afraid that if you want ubound-event.h in 13.1 you will need to checkout the sources for the release and configure with --enable-event-api. So libreswan should build and link against a private version of unbound? I'm guessing but wouldn't bundling a private copy of a security sensitive library such as unbound be a big no-no when it comes to "ports" (FreeBSD's packaging guidelines).
(In reply to Andrew Cagney from comment #11) Including maintainer in the discussion. I don't see security/libreswan failing in the cluster and the port depends on dns/unbound. Does it fail for you?
Libreswan currently manages to build on FreeBSD because it is dragging around an old copy of unbound-event.h. Little different to unpacking the sources.
(In reply to Andrew Cagney from comment #13) Again maintainer might have better information :-) Here are my thoughts: In the install instructions[1] for Fedora and NetBSD they install unbound. That is from the packages repositories. So it would be equivalent to use unbound from ports in FreeBSD right? Unless something is incompatible. If libreswan has its own copy of unbound-event.h, I wonder if they really _want_ to use that instead of whatever is installed in the host machine. https://libreswan.org/wiki/Building_and_installing_from_source
(In reply to Fernando Apesteguía from comment #14) https://lists.libreswan.org/pipermail/swan-dev/2022-January/004481.html https://github.com/libreswan/libreswan/issues/826
Created attachment 237922 [details] patch Does the attached patch look reasonable?
I'm not clear on how this can help anyone building libreswan outside of FreeBSD's packaging system. BTW, this should no longer be needed: ${RLN} netbsd.mk freebsd.mk
(In reply to Andrew Cagney from comment #17) Port patches are only for in-tree builds. If you need the upstream package changed - you should contact the project maintainer.
What exactly needs to change upstream? I don't see anything wrong with either libreswan or unbound here.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=22784d03f650254ab0516030594719946b475db1 commit 22784d03f650254ab0516030594719946b475db1 Author: Yuri Victorovich <yuri@FreeBSD.org> AuthorDate: 2022-11-08 01:37:04 +0000 Commit: Yuri Victorovich <yuri@FreeBSD.org> CommitDate: 2022-11-08 01:44:19 +0000 security/libreswan: Unbundle unbound-event.h Use the header from dns/unbound. PR: 263838 Reported by: Andrew Cagney <andrew.cagney@gmail.com> security/libreswan/Makefile | 7 +++++++ 1 file changed, 7 insertions(+)
Patch committed. Thanks for reporting the issue!
Er, this bug isn't fixed. unbound-event.h isn't being packaged.
(In reply to Andrew Cagney from comment #22) What do you mean by "not being packaged"? This port doesn't install any headers.
The request is to build and package unbound with --enable-event-api.
There is the port option EVAPI. Is it the same thing?
^Triage: canonicalize assignment.
I can't reproduce the problem when both py39-duckdb and py39-pyarrow are installed, or when only py39-duckdb is installed.
Sorry, wrong PR.
Comment on attachment 237922 [details] patch ^Triage: this patch does not belong to this PR.
^Triage: notify current maintainer after removing irrelevant information.
(In reply to Mark Linimon from comment #30) This option is relatively harmless it seems. I'll enable it starting te next release