kdesrc-build update for Git migration

So this morning kde-core-devel was emailed to notify that a few projects that used to be hosted in kdesupport have moved to git.kde.org.

What this means for you if you use kdesrc-build is that you should probably update your ~/.kdesrc-buildrc to add the projects separately since they will no longer be built as part of kdesupport.

Affected are Akonadi (the underlying PIM layer, which might be required for kdelibs, I forget), Attica (“Implements the Open Collaboration Services API”, I assume this means it’s required as well) and Soprano (C++ RDF framework, used for Nepomuk. I believe Soprano is required even if Nepomuk is not being used, but that could also be wrong).

My recommendation is to add the following modules after your existing kdesupport module, before any other modules:

module soprano
    repository git://git.kde.org/soprano.git
end module

module attica
    repository git://git.kde.org/attica.git
end module

module akonadi
    repository git://git.kde.org/akonadi.git
end module

Naturally if you will be doing development on these repositories and not simply checking out a read-only copy for build purposes you should use the git@git.kde.org:foo.git form of the repository URL.

This migration to git has the potential to get annoying for end-users, especially as we modularize more and more. To that end, the KDE Sysadmin team is working on a specification for grouping related modules together, which kdesrc-build will support, that way you could just do something like:

kde-module-group kdeplatform
    # References known XML module grouping
end kde-module-group

and things would Automagically Work. Stay tuned…

3 thoughts on “kdesrc-build update for Git migration

  1. James C. Identicon James C.

    Michael –

    Thanks for the update. I use kdesrc-build to build the 4.5 branch of KDE, would the modules you listed above build the “trunk” version of the modules? If so, what would I use for a repository to build the 4.5 “branch” of the modules?

    Thanks,
    James

  2. mpyne Identicon mpyne Post author

    @James: The modules listed would be the “trunk” (now called “master” in git ;) edition. kdesupport never really had a 4.5 branch (instead there was a tag called kdesupport-for-4.5) so you may have been using trunk for those base modules the whole time unless you used that specific tag.

    The “branch” option still works for git modules, including these three. However they’ve always been developed independently and so they don’t share branch names.

    If you’re worried about the development versions going too far toward the bleeding edge you can install your distribution’s akonadi-dev, soprano-dev, etc. packages and build 4.5 normally from there.

    If you want to build them from git still you can check their project pages (https://projects.kde.org/projects/kdesupport/soprano/repository https://projects.kde.org/projects/kdesupport/akonadi/repository https://projects.kde.org/projects/kdesupport/attica/repository ) to find out what branches are available for each one, and then use the branch option to force that branch to be used, like

    module akonadi
    repository git://git.kde.org/akonadi.git
    branch 1.4
    end module

  3. James C. Identicon James C.

    Michael –

    Thanks for clearing that up for me. I was using the 4.5 tag for kdesupport, BTW.

    Also, thanks for kdesrc-build, I use it quite often as I prefer the KDE SC version from KDE over the customized versions provided by the distributions

Comments are closed.