Created attachment 190644 [details] Update dns/mDNSResponder_nss to 878.30.4 (diff in /usr/ports/dns/mDNSResponder_nss) Hello, following the net/mDNSResponder update to 878.30.4, here's the update for the companion port dns/mDNSResponder_nss. Here's the QA: /usr/ports/dns/mDNSResponder_nss# portlint . looks fine. /usr/ports/dns/mDNSResponder_nss# make check-plist ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist ===> Checking for items in pkg-plist which are not in STAGEDIR ===> No pkg-plist issues found (check-plist) Thanks and have a nice day,
Could you please fix these problems: Warning: Bad symlink '/usr/local/lib/nss_mdns.so' pointing to an absolute pathname '/usr/local/lib/nss_mdns.so.1' Warning: /usr/ports/dns/mDNSResponder_nss/work/stage/usr/local/lib/nss_mdns.so.1 doesn't have a SONAME. Warning: pkg(8) will not register it as being provided by the port. Warning: If another port depend on it, pkg will not be able to know where it comes from. Warning: It is directly in /usr/local/lib, it is probably used by other ports.
Created attachment 190885 [details] Update w/o absolute link path. Those are strange complains... Regarding absolute path, they are a safe way of ensuring the right path, but the "fix" is easy and in the updated diff. Regarding the missing SONAME issue, I'm not sure what the issue is really: is it because poudriere (I guess this is poudriere output?) blindly think a .so should be follow a libname.so[.x.y] template?
(In reply to Matthieu Volat from comment #2) > Regarding the missing SONAME issue, I'm not sure what the issue is really: is it because poudriere (I guess this is poudriere output?) blindly think a .so should be follow a libname.so[.x.y] template? Missing SONAME means that it was linked without setting SONAME. This is an upstream problem, but without SONAME such library can't be indexed and found in a standard way. You should report it upstream as a bug.
Created attachment 191026 [details] Updates w/ fixes Ok, I understand now. Since this manually build some part of the upstream project, this is actually my responsibility to do this. I've added the soname in the link command, this made the commande incompatible between the i386/amd64 version and the arm one, but this is easily fixed by linking the library with CC on every platform.
Created attachment 196087 [details] Updates w/ fixes + getaddrinfo fix Hello, sorry I failed to ping this issue sooner, Would it be OK to add another fix in this new version that fix getaddrinfo's behavior to report both ipv4 and ipv6 addresses when specifying AF_UNSPEC family. This should be OK right now, as other issues were addressed? Thanks,
Sore.
(In reply to Yuri Victorovich from comment #6) *Sure!
Created attachment 199659 [details] New update, rebase against 878.70.2, getaddrinfo fix. Hi, there was a new mDNSResponder update, I'm rebasing the patch against it (really, only PORTVERSION and distinfo update). QA is as fine as before: dns/mDNSResponder_nss# portlint looks fine. dns/mDNSResponder_nss# make check-plist ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist ===> Checking for items in pkg-plist which are not in STAGEDIR ===> No pkg-plist issues found (check-plist) Could this be commited so next update are easier? Thank you very much
Committed, thanks!
A commit references this bug: Author: yuri Date: Thu Nov 29 09:03:02 UTC 2018 New revision: 486156 URL: https://svnweb.freebsd.org/changeset/ports/486156 Log: dns/mDNSResponder_nss: Update 878.1.1 -> 878.70.2 PR: 225912 Submitted by: Matthieu Volat <mazhe@alkumuna.eu> Changes: head/dns/mDNSResponder_nss/Makefile head/dns/mDNSResponder_nss/distinfo head/dns/mDNSResponder_nss/files/nss_mdns_freebsd.c