Created attachment 217261 [details] Update to 18.8 Attached is a patch to bring Kodi up to the latest upstream stable release. I'm not sure what Tobias' plans are for multimedia/kodi-devel when v19 is released but as this port is currently without a maintainer, I'm happy to keep looking after it in the interim for the 18 branch. Poudriere build log to follow.
Created attachment 217262 [details] Poudriere Build Log (gzipped)
Note: multimedia/kodi-addon-pvr-hts (and possibly the other addon ports) need to have their pkg-plists bumped as they have the kodi version as part of a filename.
Build info is available at https://gitlab.com/swills/freebsd-ports/pipelines/178434460
Created attachment 217272 [details] Update to 18.8, expose API version for addon ports Same as previous patch, adds Makefile.addons which sets APIVERSION for addon ports to use in their plist files rather than need a bump for each minor Kodi patch.
Hi. I am also working on kodi 19. Is it not possible to get add-ons using kodi? They are mostly python and xml files?
(In reply to yzrh from comment #5) Kodi 19 (pre-release) is already in the tree as multimedia/kodi-devel maintained by tobik@FreeBSD.org. The last bump on that was about 2 weeks ago for 19.0A1 so it's up to date if you want Kodi 19. This port should probably get bumped to 19.0 only when it's actually released. You're right that most addons are just xml and python, but there are some that are compile C/C++ which need some attention. I'm referring to are the following ports: devel/kodi-platform (not an addon exactly, but needed to build them) multimedia/kodi-addon-pvr-hts multimedia/kodi-addon-pvr-iptvsimple multimedia/kodi-addon-peripheral-joystick They're all examples of kodi plugins that are compiled libraries and end up with a symlink of (for example): lib/kodi/addons/pvr.hts/pvr.hts.so.18.7 When Kodi goes up a major version, most of those ports need legitimate bumps to bring them up to a supported version. When Kodi gets a minor version bump, they all still work, but the ports currently break because their pkg-plist files reference a the old Kodi minor version. I've emailed those port maintainers with a suggestion of exposing the Kodi API version in Makefile.addons which can then be included in the other ports so they keep working (the second patch).
I am not entirely sure why tobik@FreeBSD.org does not maintain this as well. I was going to ask about maintainership, but I suppose you want to maintain kodi? I am working on kodi 19, so that when a stable release happen, this port can be updated right away. kodi-devel is not quite like kodi. I would suggest use only kodi's release as API version, like 18, 19, etc... Other ports can symlink (or even rename) the library. Then again, that number doesn't get changed often, maybe there is no need for an API version after all.
(In reply to yzrh from comment #7) I am only putting my hand up for maintainership so that it's looked after in the interim. No-one seemed that keen on the 18.6 (later 18.7.X) bug discussion to take it and it's been radio silence since 18.8 came out at the end of July. If you're keen, then by all means I'm happy if you take it instead. I'm mostly just keen to see the port with a maintainer, whomever that is. Slightly longer term, I was going to touch base with Tobias to see what the plan was with kodi-devel after 19 is released. If it's going to keep tracking the development branch then yeah, it makes sense to keep the two ports with two maintainers (assuming the kodi-devel maintainer isn't running kodi). If not, then I was going to propose replacing this port with kodi-devel. Unfortunately that API version filename is done by the upstream code itself. It's something we could patch for and I suspect in all likelihood that it's fine to omit that version specific symlink from our ports entirely. That said, that filename is what the upstream build scripts generate though so I'm reluctant to just tamper with it on the off chance it causes issues.
I was going to update it (kodi says a new version is available), did a search on bugzilla, I found this. I will gladly take it if you don't mind. My plan is to backport some improvements once kodi 19 (alpha1 as it is now) is in good shape. About API version, I think the correct way is to bump PORTREVISION when kodi's version get changed.
(In reply to yzrh from comment #9) No dramas on maintainer, I'll remove that line from my patch shortly, feel free to submit one to do take it. On the API, I'm not quite sure I've been understood. If you have a look at multimedia/kodi-addon-pvr-hts/pkg-plist you'll see the following lib/kodi/addons/pvr.hts/pvr.hts.so lib/kodi/addons/pvr.hts/pvr.hts.so.18.7 lib/kodi/addons/pvr.hts/pvr.hts.so.4.4.21 share/kodi/addons/pvr.hts/addon.xml share/kodi/addons/pvr.hts/changelog.txt ... When that port gets built, the upstream build scripts identify which version of Kodi is installed, and then generate that file. If we bump Kodi to 18.8 the four ports I listed above error at packaging because their build now generates *.so.18.8 (or in the case of kodi-platform case *.so.18.8.0). There's two ways to fix that, either we bump five ports between three maintainers every time we bump this one (and hope we forget none of them) or we can expose the API version to those ports and then bump just this port each time. Doing it the second way, the patch for one of them is just: diff -urN multimedia/kodi-addon-pvr-hts/Makefile multimedia/kodi-addon-pvr-hts/Makefile --- multimedia/kodi-addon-pvr-hts/Makefile 2020-07-19 13:40:42.366086000 +0800 +++ multimedia/kodi-addon-pvr-hts/Makefile 2020-08-17 17:19:48.848419000 +0800 @@ -22,4 +22,7 @@ GH_PROJECT= pvr.hts GH_TAGNAME= ${PORTVERSION}-Leia +.include "${CURDIR}../../multimedia/kodi/Makefile.addons" +PLIST_SUB= APIVERSION=${APIVERSION} + .include <bsd.port.mk> diff -urN multimedia/kodi-addon-pvr-hts/pkg-plist multimedia/kodi-addon-pvr-hts/pkg-plist --- multimedia/kodi-addon-pvr-hts/pkg-plist 2020-07-19 13:40:42.366547000 +0800 +++ multimedia/kodi-addon-pvr-hts/pkg-plist 2020-08-17 17:12:42.853153000 +0800 @@ -1,5 +1,5 @@ lib/kodi/addons/pvr.hts/pvr.hts.so -lib/kodi/addons/pvr.hts/pvr.hts.so.18.7 +lib/kodi/addons/pvr.hts/pvr.hts.so.%%APIVERSION%% lib/kodi/addons/pvr.hts/pvr.hts.so.4.4.21 share/kodi/addons/pvr.hts/addon.xml share/kodi/addons/pvr.hts/changelog.txt
Created attachment 217293 [details] Update to 18.8, expose API version - No maintainer update
Thanks for that! I got what you are saying. Kodi is a build dependency for kodi's add-ons. When kodi is updated, PORTREVISION of all add-ons should be incremented. This causes all add-ons to be built against the updated kodi, thus allowing pkg-plist of all add-ons to directly reference kodi's version.
(In reply to yzrh from comment #12) No dramas! It's also a pkg-plist bump needed for each of those ports in addition to PORTREVISION. I think we're both essentially saying the same thing in slightly different ways so all good.
Wouldn't it be better to put KODI_VERSION= 18.8 in multimedia/kodi/version.mk. And in add-ons, .include "${PORTSDIR}/multimedia/kodi/version.mk" and PLIST_SUB= KODI_VERSION=${KODI_VERSION}. It's more readable, what do you think?
(In reply to yzrh from comment #14) Yeah, that works too!
I should open a new issue. Since I have removed bundled library and enabled aarch64 as well. I think I will include KODI_CODENAME= Leia in version.mk. Maybe someone will use it.
(In reply to yzrh from comment #16) A couple of other items that might be good to add would be KODI_MAJOR_VERSION etc. For the patch release of 18.7.1 the libraries still only used 18.7 (and in the case of kodi-platform 18.7.0). kodi-platform also as an .so.18.0 symlink there. You're right though that this should probably be two separate issues. If you submit a updated 18 patch with your other fixes here, I'll obsolete my patch to remove any confusion.
Suppose the current version is 18.8.1, what about KODI_VERSION= 18.8.1 KODI_VER= 18.8 kodi-platform can do something like, KODI_RELEASE= ${KODI_VER:C/\.[0-9]+$//}
My patch is ready. Should I open a new issue?
(In reply to yzrh from comment #19) Feel free to post it here, I'll obsolete my patch.
Created attachment 217297 [details] Patch against r543873
Created attachment 217298 [details] testport log (gzipped)
As we discussed, KODI_VERSION, KODI_CODENAME, KODI_VER are available in version.mk for add-ons. Other changes: update to 18.8 use mariadb 10.5 aarch64 support remove bundled libdvd* bluetooth support (but broken due to bluez stuff) fix -nogit in kodi information page make USES accurate
Created attachment 217300 [details] Patch against r543873 (fix KODI_VER) Kodi doesn't always use x.y.z versioning, it could be x.y.
^Triage: Please confirm this change passes QA (portlint, poudriere at least) For details and instructions, see: https://www.freebsd.org/doc/en/books/porters-handbook/testing.html
portlint -C WARN: Makefile: Consider adding support for a NLS knob to conditionally disable gettext support. WARN: Consider to set DEVELOPER=yes in /etc/make.conf 0 fatal errors and 2 warnings found.
Created attachment 217339 [details] Poudriere build log for latest patch
Comment #22 is the output of poudriere testport. It was built with all options enabled. I will do it again with all options disabled.
Created attachment 217345 [details] testport log 1 (gzipped)
Moin moin What's the benefit of having the version.mk? mfg Toibas
(In reply to Tobias C. Berner from comment #30) It's discussed above in Comments 10 through 14. In a short sumamry, there are a number of child ports (addons) that include library files that have the kodi version as part of their shipped filenames. Every time kodi sees a version update those ports break because they fail to package. The thinking is to provide an easy way to expose the current kodi version and allow those child port maintainers to set those paths dynamically if they wish.
(In reply to James French from comment #31) Ok, fair enough :) Could you include a fix for =========================================================================== ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist Error: Orphaned: lib/libkodiplatform.so.18.8.0 ===> Checking for items in pkg-plist which are not in STAGEDIR Error: Missing: lib/libkodiplatform.so.18.7.0 ===> Error: Plist issues found. *** Error code 1 Stop. make: stopped in /usr/ports/devel/kodi-platform in your patch, I guess that is related ot the update. mfg Tobias
Created attachment 218506 [details] Version.mk patch for devel/kodiplatform
Created attachment 218507 [details] Version.mk patch for multimedia/kodi-addon-pvr-hts
Created attachment 218508 [details] Version.mk patch for multimedia/kodi-addon-pvr-iptvsimple
Created attachment 218509 [details] Version.mk patch for multimedia/kodi-addon-peripheral-joystick This should be all of the child ports for the stable version of kodi at present. There are a few other addons ports but they are related to the kodi-devel port.
RPI platform is gone... https://github.com/xbmc/xbmc/commit/605b3b05dc8aee32a1238653a5f02ce5be25719a
(In reply to James French from comment #34) I don't see a reason why you touch DISTVERSIONSUFFIX for multimedia/kodi-addon-pvr-hts
Sorry to jump into this so late but this looks a bit clumsy to me. The update for kodi 18.8 is what this bug is about and the addons topic should be a new bug really because otherwise the discussions and brainstorming are blocking everything. The implementation for the addons should be a "USES=kodiaddon" (better names are always welcome) and should set everything that is necessary for the plugins to REDUCE duplicate code (like PLIST_SUB+=KODI_VERSION=${KODI_VERSION}). Have a look at Mk/Uses/ for existing implementations - they are quite simple. After all I am not convinced yet that it is really necessary to have all of this at all because the number of addon ports is 3 so really low and whenever the major version changes you need to update the addon ports anyway.
(In reply to Bernhard Froehlich from comment #38) Apologies for quoting you hear, I broadly agree with you but wanted to touch on the items you raised. > I don't see a reason why you touch DISTVERSIONSUFFIX My apologies - neither do I, this patch was written weeks ago, and that was the port I was doing most of the experimenting with, I suspect it's not required. > The update for kodi 18.8 is what this bug is about Agreed - the addition of that file was intended to be just an easy thing we could do to make life easier not to be the star of the show. Patches were requested for the other ports, I'm just as happy to submit pkg-plist patches for them and drop that file if it makes everyone's life easier. > The implementation for the addons should be a "USES=kodiaddon" Agreed, that's a cleaner way to do it. When I was looking at how this was done, the proposed method was used by at least one other multimedia port. What was intended as a small improvement we could include has sufficiently muddied the waters to end up being the main point of discussion for this bug. I didn't originally submit patches for the child ports because I had intended to leave it to you and the other maintainer to decide what you wanted to do with your own ports. I'm very happy at this point to park that file & the discussion for now and just commit 18.8. Kodi 19 is about to drop, and that's going to start this whole thing over again.
> After all I am not convinced yet that it is really necessary to have all of > this at all because the number of addon ports is 3 so really low and whenever > the major version changes you need to update the addon ports anyway. No, it is more than 3. I have 10+ that wait for approve here.
I suggest we commit 18.8 first (with or without version.mk). Since I am closely tracking kodi 19, I expect it will be updated as soon as a release is made. We have all the time before that to think about Mk/Uses.
Created attachment 218715 [details] Mk/Uses/kodi.mk What about something like this?
(In reply to yzrh from comment #43) Looks good I'd say. Should we also get rid of version.mk altogether and define the version numbers in Uses/kodi.mk to make it self consistent?
(In reply to Bernhard Froehlich from comment #44) And shouldn't we also add some mandatory dependencies? Judging from the 3 addon ports in the tree it would be: BUILD_DEPENDS= ${LOCALBASE}/include/kodi/libXBMC_addon.h:multimedia/kodi LIB_DEPENDS= libp8-platform.so:devel/p8-platform \ libkodiplatform.so:devel/kodi-platform RUN_DEPENDS= kodi:multimedia/kodi but it would be good to compare this with the 10 addons that are not committed yet.
Created attachment 218716 [details] diff against r552067 Remove version.mk
Created attachment 218718 [details] Mk/Uses/kodi.mk (add DEPENDS) Without version.mk, it must be updated separately.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250546 update to 19.0a2-Matrix / 19.0.a20201006
Created attachment 219074 [details] diff against r552067 Update to 18.9
Created attachment 219075 [details] testport log
Created attachment 219076 [details] portlint log
Created attachment 219077 [details] Mk/Uses/kodi.mk (18.9)
Due to the upcoming python2 removal we were forced to update kodi to 19.0b2 which is the first release that supports python3. I think we should close this bug and discuss a future kodi.mk for addons in a new bug ticket. Thanks a lot for all the work guys!