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
(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)
They're all examples of kodi plugins that are compiled libraries and end up with a symlink of (for example):
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
(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
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 @@
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 @@
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
(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
And in add-ons,
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
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-platform can do something like,
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.
update to 18.8
use mariadb 10.5
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:
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
Created attachment 217345 [details]
testport log 1 (gzipped)