Bugzilla Automation <[email protected]> has asked freebsd-kde (group) <[email protected]> for maintainer-feedback: Bug 288902: devel/kdesdk, editors/kate: dependency on katebacktracebrowserplugin.so not registered (?!) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288902
--- Description --- i tried building devel/kdesdk yesterday (tree at @923d2f4) with all options ON. i'm on 13.5-RELEASE-p3/amd64 isn't this a metaport? how then does it even have any shared libraries showing up in actual-package-depends? (possibly the USES=kde:6 & KDE=kate:run somehow lead to this): ===> Building packages for kdesdk-25.08.0 actual-package-depends: dependency on /usr/local/lib/qt6/plugins/ktexteditor/katebacktracebrowserplugin.so not registered (normal if it belongs to base) obviously it does not belong to base. and yet, there is no file even there: root@Rick:/usr/local/lib # ll qt6/plugins/ktexteditor/katebacktracebrowserplugin.so* ls: No match. it is here (note the /kf6): root@Rick:/usr/local/lib # ll qt6/plugins/kf6/ktexteditor/katebacktracebrowserplugin.so* -rwxr-xr-x 1 root wheel 124872 Aug 15 18:00 qt6/plugins/kf6/ktexteditor/katebacktracebrowserplugin.so* furthermore `pkg which` says its from kate-25.08.0 BUT `pkg info kate` does NOT list it in shared libs provided. `pkg info kdesdk` shows none/none libs required/provided, as expected. what am i failing to understand? to be clear, the outcome _seemed_ fine [to me]; i'm just inquiring about the peculiar actual-package-depends notice. feel free to close this as "not a bug" with no action, and i'll feel sufficiently reassured. my concern is there's something to fix re: the /kf6/ path discrepancy; my astonishment is from the .so missing from kate's registered shared libs provided. i cant say ive ever used katebacktracebrowserplugin (though Kate yes, day in+out) so i dont know if it should/has/does work as intended, but it sounds cool! note i'm not using poudriere, rather building from ports on a system with 7000+ pkgs installed, all locally built similarly and in sync to the same commit (at least according to each $PKGNAME). (tbh i also have hundreds of modified/added files in my local repo painstakingly maintained and merged.) i'm not opposed to rebuilding this or everything with poudriere if suggested or requested nor would i hesitate to stand up public access to my local repo. however, a potential reason completely eludes me that any of my mod9s might have any bearing on this issue; the subject ports and Mk/* are unmodified (save for blaslapack.mk).
