KDE TechBase - User contributions [en]

Projects/Utils/ksecretsservice

2013-05-05T01:19:51Z

Mechanical snail: /* Structure */ Fix URL

== Structure ==

ksecretsservice is a secrets management infrastructure aiming to replace [[Projects/Utils/kwallet]].

All the sources of this infrastructure are located on projects.kde.org [[https://projects.kde.org/projects/playground/utils/ksecrets]]

{| class="wikitable"
|-
! part
! description
|-
| ksecretsserviced
| store the secrets in a secure manner
|-
| ksecretsservice
| Public API to be used by KDE applications
|-
| secretsync
| Tool used to synchronize secrets between several devices
|-
| kio
| Let users browse secrets using the ksecrets:// protocol
|-
| kwl2kss
| KWallet to KSecretsService conversion tool
|}

=== Roadmap ===

* Daemon (ksecretsserviced)
** ksecrets specific file format storage [DONE]
** testing and bugfixing [IN PROGRESS]
* KDE API (ksecretsservice)
** support secret creation and retrieving [DONE]
** implement signals [TO BE DONE]
* Secrets Sync Tool (ksecretssync)
** Implement syncing protocol [TO BE DONE]
** Add IMAP support [TO BE DONE]
** Add SFTP support [TO BE DONE]
* ksecrets tool
** Specify commands to be added [TO BE DONE]
** Implement these commands [TO BE DONE]
* kio (used to display secrets in e.g. Dolphin)
** Finish it [TO BE DONE]
* KWallet conversion tool (kwl2kss)
** More testing [TO BE DONE]

=== Notes ===

Originally, this project was started as a freedesktop.org specification, that one could find here [[http://specs.freedesktop.org/secret-service/]]. This specification is for a DBus daemon providing a means for applications to securely store and retrieve secrets information. Under KDE, this is considered an implementation detail and KDE applications are supposed to use the client API described above. However, this implementation detail is important to be known for those users mixing KDE and GNOME, as the freedesktop.org specification is also implemented by gnome-keyring. These user should make a choice about the actual daemon they want to activate and then stick with it, as no migration tool exists (yet) from ksecretsserviced to gnome-keyring or viceversa.

Getting Started/Using Project Neon to contribute to KDE

2012-09-11T05:35:05Z

Mechanical snail: Formatting; specify it's for ubuntu in the lead.

[https://launchpad.net/project-neon Project Neon] is a nightly build of the latest KDE trunk for Ubuntu. It is an easy way for new contributors to KDE to get started without having to download and build the entire KDE source code tree. Additionally, dependencies are automatically handled and updated. This is suitable for new developers, translators, usability designers, documenters, promoters, bug triagers, etc. This process makes the steps detailed on [[Getting_Started/Build|this page]].

However, for developers, it may at some point become necessary to build more components from source code as you become more involved in the project. The [[Getting_Started/Build/kdesrc-build|kdesrc-build]] script is an easy way to build all or parts of KDE from its source code repositories.

== Requirements ==

Project Neon always requires either the latest stable Kubuntu release or the development release. Previous versions of Kubuntu are not supported.

== Installing Project Neon ==

To use Project Neon, add the following PPA (Personal Package Archive) to your <tt>sources.list</tt> using your preferred method:

<syntaxhighlight lang="bash">
sudo add-apt-repository ppa:neon/ppa
</syntaxhighlight>
or
<pre>
# Project neon nightly KDE4 build
deb http://ppa.launchpad.net/neon/ppa/ubuntu maverick main

#above repository is PGP signed, refer to below link for getting PGP key
https://launchpad.net/~neon/+archive/ppa
</pre>

After that, you can simply install the nightly package of whichever modules you want to work on. The Packages are named project-neon-<git/svn module name>. The packages are installed in /opt/project-neon/ and won't affect your stable KDE install.

You can install all of the packages or just the ones you are interested in, depending on what you want to use them for. For example if you want to install the KDE Workspace with the extra plasmoids, you would install the <tt>project-neon-kdeplasma-addons</tt> and <tt>project-neon-session</tt> so you get KDM support for Project Neon.

<syntaxhighlight lang="bash">
sudo apt-get install project-neon-kdeplasma-addons project-neon-session
</syntaxhighlight>

If you are only interested in application development in another module, you can install just the module package.

<syntaxhighlight lang="bash">
sudo apt-get install project-neon-kdepim project-neon-common
</syntaxhighlight>

That command will also install the <tt>kdelibs</tt>, <tt>kdepimlibs</tt> and other dependencies too. In your regular (stable) KDE session you can then run the nightly version of your chosen application after setting up the environment.

<syntaxhighlight lang="bash">
neon-env
kmail
</syntaxhighlight>

<tt>neon-env</tt> will setup the environment and start a subshell from which you can work with your project neon installation.
This will correctly use the nightly version of libraries instead of using the stable versions, so no other changes are necessary to your library path etc.
You'll need to close the terminal session for the settings to be undone.

Note that settings for applications that you run from project neon do not conflict with your regular application settings and data. <tt>.project-neon-kde/</tt> is used instead of <tt>.kde/</tt>

== Using Project Neon for development ==

If you are joining one of the development teams in KDE, you will need a real SVN/GIT checkout in order to contribute your code back to the project and create patches easily. If you only code for KDE every now and then, Project Neon provides some extra tools for this purpose in the package <tt>project-neon-utils</tt>:

NOTE: both neon-cmake and neonmake require neon-env to be run first!

* <tt>neon-env</tt> - sets up the necessary environment settings for project neon builds and opens a subshell.
* <tt>neon-cmake</tt> - cmake wrapper with neon environment settings for cmake, same synopsis as cmake and passes arguments to cmake
* <tt>neonmake</tt> - convenience script which will create a build folder, configure the source, build it and install it in /opt/project-neon/ so you can test your changes.
* <tt>neon-clean</tt> - script that resets any changes you made to /opt/project-neon after installing the packages. Since this script reinstalls the packages it might require a working internet connection.
* <tt>neonbuild</tt> - pbuilder/pdebuild wrapper to rebuild a neon package in a chroot. Takes the same options as pbuilder. If no pbuidler action is given pdebuild is run instead.

=== Options for cmake/make ===
You can change the cmake and make options used by setting these variables in ~/.neonrc:

* <tt>NEON_CMAKE_OPTS=""</tt> - Here you can add additional cmake options that should be used together with the default neon options.
* <tt>NEON_CMAKE_OVERRIDE=""</tt> - If you set this variable cmake will ignore the default neon options and only use the ones in NEON_CMAKE_OVERRIDE.
* <tt>NEON_MAKE_OVERRIDE=""</tt> - If you set this variable make in neonmake will only use your options. By default make uses '-j CPUs+1'

=== Debugging symbols ===
The debugging symbols for every package are in it's corresponding <code>-dbg</code> package, so to install the debugging symbols for kdelibs you can use
<syntaxhighlight lang="bash">
sudo apt-get install project-neon-kdelibs-dbg
</syntaxhighlight>

If you are already using a nightly package of the module you want to develop for, you should remove that, and checkout the development version. For example:

<pre>
# Remove the packaged nightly version
sudo apt-get purge project-neon-kdepim

# Add below Project Neon source code repository to sources.list if you didn't use add-apt-repository
deb-src http://ppa.launchpad.net/neon/ppa/ubuntu maverick main

# Get the dependencies for building kdepim
sudo apt-get build-dep project-neon-kdepim
cd ~
# You may choose to do your development in a different folder.
cd Development
# Gets the latest version of the kdepim module.
git clone git://anongit.kde.org/kdepim
cd kdepim
# Set up neon environment
neon-env
# Shortcut provided by Project Neon to make the module
# and install it to the prefix /opt/project-neon/
neonmake
</pre>

Note that you should usually checkout a module from KDE, not an application. Most modules contain libraries shared within the module and which are necessary to build the applications in the module.

Also note that when using apt-get build-dep it will always get all build-depends, so watch out that it doesn't install a component you want to build yourself as that would overwrite your changes should you install the packages after installing your build.

== Using Project Neon for translation ==

The Project Neon nightly packages include English language strings only. Translated packages are not available. However, if you are translating KDE applications, you can install the translations from KDE SVN in your normal workflow.

<syntaxhighlight lang="bash">
cd ~
cd Translations
# The -N switch checks out only the top level directory from svn.
svn co -N svn://anonsvn.kde.org/home/kde/trunk/l10n-kde4
cd l10n-kde4
# scripts necessary to build translations.
svn up scripts
# Get the German translations
svn up de
# Generate the build files for the German language pack - if you get a message
# that revpath couldn't be found you need to install the xutils-dev package
./scripts/autogen.sh de
cd de
neon-env
neonmake
</syntaxhighlight>

After building the translations it is possible to either change the language in system settings, or run applications in another language using the environment variable <tt>KDE_LANG</tt>.

<syntaxhighlight lang="bash">
switchtonightly # or neon-env
KDE_LANG=de kmail
</syntaxhighlight>

exit the shell to reset the settings.

== Using Project Neon for documentation ==

The Project Neon nightly source packages include the official KDE User Documentation in English.

TODO: How to build user docs from SVN.

== Using Project Neon for promotion ==

If you are creating screenshots or screencasts of the latest version of KDE, project Neon is a simple and fast way of getting a default KDE4 session.

The KDE Promotion team recommends using the default background, theme, icons etc when preparing official promotional materials (unless the feature you are showing is related to configuring KDE artwork). Project Neon uses the default artwork that comes with KDE4, so it is useful for creating promo materials.

Here is a shortcut to get all available modules from the PPA:

<syntaxhighlight lang="bash">
sudo apt-get install project-neon-all
</syntaxhighlight>

The application [http://ariya.blogspot.com/2008/06/creating-fancy-screenshots-with.html screenie] is provided since Kubuntu 8.10 as <tt>screenie-qt</tt>.

<syntaxhighlight lang="bash">
sudo apt-get install screenie-qt
</syntaxhighlight>

== Contact the Team ==

You can reach the Project Neon team on IRC in
<syntaxhighlight lang="text">#project-neon on irc.freenode.net</syntaxhighlight>
by mail at <syntaxhighlight lang="text">neon@lists.launchpad.net</syntaxhighlight>
or you can ask a question on [https://answers.launchpad.net/project-neon launchpad]

If you think there is a bug in our packaging of the provided software you can file a bug on [https://bugs.launchpad.net/project-neon launchpad]

[https://wiki.kubuntu.org/Kubuntu/ProjectNeon Team page in the Kubuntu Wiki]

Thread:Talk:Policies/Git commit policy

2012-09-11T05:15:22Z

Mechanical snail: New thread: Git commit policy

With the recent move to Git, I assume there should be a policy for Git contributions. Currently there's only the SVN commit policy.

Development/Languages/Java

2012-09-11T05:01:59Z

Mechanical snail: punctuation

Java support for KDE is now fairly significant. You can add applet support to your KDE applications, and with the Qt/KDE Java bindings you can develop KDE apps in Java. Issues relating to Java support for KDE should be discussed on the kde-java mailing list (though applet issues are usually discussed on kfm-devel).

* [http://developer.kde.org/language-bindings/java/qtjava.html QtJava and KDEJava (Koala)]<br /> The QtJava and KDEJava (Koala) bindings developed by Richard Dale allow you to create Qt and KDE applications using Java. The code uses JNI to allow Java code to access KDEs native widgets. These bindings can be found in the [http://websvn.kde.org/trunk/KDE/kdebindings/ kdebindings module] of the KDE Subversion repository ([http://developer.kde.org/source/anonsvn.html Instructions]).

* [http://developer.kde.org/language-bindings/java/kjas/index.html KDE Java Applet Server (KJAS)]<br />KJAS allows KDE applications to embedd Java applets. It uses a pure Java server to run the applets, which it communicates with using standard UNIX pipes. KDE programmers can use a special KJavaAppletWidget to display the applets in their application. KJAS is already in a usable state.

* [http://developer.kde.org/language-bindings/java/qtawt/index.html QtAWT]<br />The QtAWT is a port of the peer classes underlying the Java AWT to the Qt toolkit, in future it will also use the KDE widgets. QtAWT is currently very incomplete, but you should feel free to give it a try, or even better to help finish it.

* [https://mail.kde.org/mailman/listinfo/kde-java Mailing List] ([http://mail.kde.org/pipermail/kde-java/ Archives]) <br />There is a dedicated mailing list for Java-specific issues in KDE. It is a fairly low-traffic list aimed at developers with an interest in writing Java applications for KDE and/or writing and maintaining the Java bindings.

* [http://doc.trolltech.com/qtjambi-1.0.0beta/com/trolltech/qt/qtjambi-index.html Qt Jambi Reference Documentation]
* [http://www.trolltech.com/pdf/qtjambi-whitepaper-tp3.pdf Qt Jambi Whitepaper]
* [http://lists.trolltech.com/qt-jambi-interest/ Qt-jambi-interest Mailing List]

[[Category:Java]]

Development/Review Board

2012-09-11T04:59:11Z

Mechanical snail: /* Using post-review to post changes for review */ add corresponding package name for debian/ubuntu

= KDE Review Board =

KDE currently uses the [http://www.reviewboard.org/ Review Board] software for performing reviews on code changes.

There are separate versions of Review Board for use with Git and Subversion:
* [http://git.reviewboard.kde.org KDE Git Review Board]
* [http://svn.reviewboard.kde.org KDE Subversion Review Board]

Note that http://reviewboard.kde.org/ redirects to the Git version.

== Using Review Board and post-review with Git ==

Every Git Project repository has its own entry on the KDE Git Review Board.

=== Creating your changeset ===

To create your changeset, you probably want to work in a separate branch - or even in your clone. This is actually suggested and the proper way to do changesets in Git. You can create any number of commits, amend them, and do whatever you want to do - it won't affect the next steps, as you will submit the whole branch for review.

Before proceeding it is good practice to rebase your branch onto the branch you want to target for the merge. So, supposing you want to target <tt>master</tt>, make sure it is up-to-date with the remote and then run, and want to publish a review for a local branch:

git pull --rebase

If you want to post a review for merging a non local branch, you might want to run the following:

git merge master

=== Using post-review to post changes for review ===

Once you are done with the above, it is time to post the changes to ReviewBoard. The easiest and most comfortable way to do that is <tt>[http://www.reviewboard.org/docs/manual/dev/users/tools/post-review/ post-review]</tt>, a handy command line tool which takes care of creating review requests for you. This is normally in a package called RBTools, available as [http://software.opensuse.org/search?q=rbtools <code>rbtools</code> in OpenSuse's devel:tools repository] and [apt://python-rbtools <code>python-rbtools</code> in Debian/Ubuntu].

==== Prerequisites ====

The following has to be done only once to make your local clone fit for use with <tt>post-review</tt>.

First of all, you have to tell it about the ReviewBoard server. If your project does not ship with a <tt>.reviewboardrc</tt> file (encourage the project manager to add one!), the first thing you have to run is:

git config reviewboard.url https://git.reviewboard.kde.org

ReviewBoard currently only knows the project repositories by their git:// URLs, making it necessary to have a remote using the git:// URL in your clone. If your <tt>origin</tt> remote is already using the git:// URL, you are all set. If not you need to add another remote now.

Let's suppose you are looking to have some changes to [https://projects.kde.org/projects/extragear/multimedia/amarok Amarok] reviewed, and the URL of your <tt>origin</tt> remote is <tt>git@git.kde.org:amarok</tt>. To add another remote using the git:// URL you might run:

git remote add anonupstream git://anongit.kde.org/amarok
git fetch anonupstream

If your <tt>origin</tt> remote was already using the git:// url, substitute <tt>anonupstream</tt> with <tt>origin</tt> throughout the rest of this tutorial.

If you used a <tt>kde:</tt> prefix for your git remotes, post-review won't expand it (it uses <tt>git config --get remote.origin.url</tt>).
This can be fixed by editing
<tt>/usr/local/lib/python2.7/site-packages/RBTools-0.4.1-py2.7.egg/rbtools/clients/git.py</tt>
and at the end of the function "def get_origin", adding the following line before the return line:

<tt>origin_url = origin_url.replace("kde:", "git://anongit.kde.org/")</tt>

==== Creating the review request ====

You are now ready to create the review request. The <tt>post-review</tt> command should look something like this:

post-review --parent=master --tracking-branch=anonupstream/master

This command tells <tt>post-review</tt> that your branch is based upon <tt>master</tt>, and it is set to track the remote branch <tt>anonupstream/master</tt>. You can also give <tt>post-review</tt> some more arguments to avoid using the web interface later - have a look at the [http://www.reviewboard.org/docs/manual/dev/users/tools/post-review/ user manual] for more on that.

After the command has been run a web address will be shown in the terminal, pointing at your review request.

==== Updating a review request ====

If you need to update an existing review request you can invoke <tt>post-review</tt> with an additional <tt>-r</tt> argument, which should be the numeric id of the review request you want to update. Supposing you want to update review request 54, you would run:

post-review --parent=master --tracking-branch=anonupstream/master -r 54

==== Create a convenient git alias ====

To reduce the typing needed you can create a git alias with the options you use for post-review. Add the line
below to the <tt>[alias]</tt> section of your ~/.gitconfig file.

post-review = !post-review --guess-summary --guess-description --username=<YOUR USERNAME> --parent=master --tracking-branch=anonupstream/master

Now you can submit a committed patch for review by just typing

git post-review

If you want to amend an already existing review request just add <tt>-r NUM</tt> to the end of the command.

==== Creating a ReviewBoard-compatible diff ====

In some rare cases you simply want to generate a diff and submit it to ReviewBoard later. You can do that by running:

post-review --parent=master -n > your-patch.patch

=== Closing a review request ===

A review request can be closed in two ways. Either the user who opened the review request can use the ReviewBoard web interface. Or you close the review right in a GIT commit. This is done by using the REVIEW keyword followed by the review ID you want to close. For example, to close review 54, you would put

REVIEW: 54

in your commit. A message will also be posted to ReviewBoard indicating the commit SHA1 that closed the request. Please note that this only works for GIT commits, and not for Subversion commits.

== Using Review Board With Subversion ==

Not all KDE Subversion projects use Review Board so first you need to check if the project you've created the patch for is actually using reviewboard. For this, go to the [http://svn.reviewboard.kde.org/groups/ groups section] and see if the project's group is listed there. If it is listed there, you should use the reviewboard, otherwise send the patch by other means.

For sending a patch, you first need to register. Then simply click ''[http://svn.reviewboard.kde.org/r/new/ New Review Request]'' and fill out the form. The most important parts of the form are:

* '''The actual patch'''. You need to upload the patch you've created earlier here
* '''The SVN base path'''. This is needed for the inline patch display to work. This can be a bit tricky, if you are unfamiliar with KDE's SVN layout, check [http://websvn.kde.org WebSVN]. For example, if you're ''svn diff'ing'' from <tt>/path/to/your/copy/of/kdelibs/cmake/modules</tt>, the base path should be <tt>/trunk/KDE/kdelibs/cmake/modules</tt>. If you still don't know the correct base path, ask a developer on IRC. You can also edit the review request later.
* '''A summary of the patch'''. This should be short, it will show up as subject of the notification emails.
* '''A description of the patch'''. This can be longer.
* '''The group(s)'''. Make sure you enter the correct group '''ID''' here, as seen earlier on the [http://reviewboard.kde.org/groups/ groups page].

After you completed the form, a notification mail will be sent to the developers and they will answer you.

/!\ You need to use svn diff in english, if your system is not english, please do LC_ALL=C svn diff