Kodi Community Forum

Full Version: PVR addons move to new repository!
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5
To all addon authors:

In the context of moving to a new build system with cmake we also moved and split the repository of the addons. opdenkamp master branch is frozen. The addons have an intermediate home at:

Those repositories were used to setup cmake builds. Note that history from opdemkamp repository is lost. I have split out vnsi from opdenkamp repo and synchronized with https://github.com/Montellese/pvr.vdr.vnsi. This way I was able to keep history for vnsi. For help on this process see: https://help.github.com/articles/splitti...epository/
Please change pvr.vuplus to the addon you're working with.

Fork https://github.com/opdenkamp/xbmc-pvr-addons

Clone the fork to your disk
git clone [email protected]:<your username>/xbmc-pvr-addons.git

Create a copy of the freshly cloned repo. In case things go south you can start over.
cp -r xbmc-pvr-addons/ pvr.vuplus/

Go to the root folder of new repo
cd pvr.vuplus/

Filter what we what to keep
git filter-branch --prune-empty --subdirectory-filter addons/pvr.vuplus/ master

Remove unneeded files and folders
git rm Makefile.am
git rm -r project/

Rename old stuff
git mv addon/ pvr.vuplus/
cd pvr.vuplus/
git rm addon.xml.in

We're missing some files but fortunately notspiff and Montellese already took care of that.

Go to https://github.com/notspiff?tab=repositories or https://github.com/Montellese?tab=repositories, click the repository you're interested in and download the zip file.

Open the file and copy debian folder and every file in root folder (CMakeLists.txt, FindTinyXML.cmake, etc) to the new root folder of your repository. Only one more file missing. Find addon.xml inside pvr.vuplus folder and copy it to pvr.vuplus folder of your repository.

At this stage, everything we need is in place. Let's update the repo.

Add new/changed files to git. You must be on repository root folder, I think... can't remember
git add *

Commit the changes
git commit -m "Sync with cmake"

Go to your GitHub account and create a new pvr.vuplus repository

Change origin to new repository
git remote set-url origin [email protected]:hudokkow/pvr.vuplus.git

Verify new remote origin
git remote -v

Push to new origin
git push origin master
or simply
git push

Done! You should end with something like https://github.com/hudokkow/pvr.vuplus. More importantly, git history is preserved.

I'm sure there's probably more simple ways to achieve the same and, as usual, improvements and suggestions are very welcome.
Thanks FernetMenta for the tips!

It may be a good idea to double check the "sync with cmake" change with the original code. Just to make sure nothing has been lost/added unintentionally.
Ah! You're right!

I forgot to update the #includes. Probably missed some more things. Crap!

Awesome work guys Wink

Does it means that each addon repo will be owned by its author and he only needs to submit a PR to bump his addon (change the addon cmake txt in the xbmc repo)?
(2015-02-23, 21:30)xhaggi Wrote: [ -> ]Awesome work guys Wink

Does it means that each addon repo will be owned by its author and he only needs to submit a PR to bump his addon (change the addon cmake txt in the xbmc repo)?

That is my idea of how it should work but discussion goes on. Others think that it may be good to fork the original repos and point cmake to those.
Thanks guys for the tuto. I recovered full history and authors would be happy.
Probably a good idea to update the first post.
(2015-02-25, 17:49)ironic_monkey Wrote: [ -> ]Probably a good idea to update the first post.

I'm packaging the alpha releases for testing (and translating) on my Arch Linux laptop.

I think it might be a good idea to be able to transfer the git git-revision as parameter without making changes in the [addon].txt, I'm sure addons developers won't bother with bumping the git hash/tag for every alpha so this will be quite useful.
I suggested using a branch, not a particular revision: https://github.com/xbmc/xbmc/pull/6227#i...t-75913272
Not sure about the down sides.

Lets say I'm building from the alpha2 tag when the merge window of alpha3 is open, a pvr api change has been merge to the I*** branch at an addon's repo (following changes in alpha3 merged to kodi), this might cause an addon runtime or build time breakage, so I'm not sure only having branch as parameter to the cmake system is a good idea.
p.s. I'm assuming you don't expect addons developers to create a branch for each alpha release.
For packaging i reckon it is best to use standalone builds rather than the in-tree buildsystem which really only is necessary for cross builds and windows. The install target of kodi installs everything needed from kodi to build the addon. Since you be using native packaging tools you are free to specify what you build however you want.
Pages: 1 2 3 4 5