This is where all registered users can work on the documentation for the ebuilds.
This wiki has been provided as a central place for information regarding the kde-svn ebuilds.
The current maintainers/developers are:
Wulf C. Krueger - Philantrop (philantrop at gentoo.org)
Ingmar Vanhassel - Ingmar (ingmar.vanhassel at gmail.com)
Timo Gurr - Psy (tgurr at gentoo.org)
Tobias Heinlein - keytoaster ( keytoaster at gentoo.org )
Jorge Manuel B. S. Vicetto - jmbsvicetto (jmbsvicetto at gentoo.org)
Christian Heim - phreak (phreak at gentoo.org)
Keep in mind that the original KDE svn repository breaks from time to time, so if something fails to compile/install, try again the next day or so (do not overload the svn server, please!) but don't rush to complain about it to us or the Gentoo / KDE developers.
If the problems remains, you can report it on KDE bugs. If you think it's an ebuild bug, please report it on our bugtracker.
Again, if something breaks, please contact us first. Never post a bug about this project on the official Gentoo bugtracker.
Using Unsermake
The KDE-svn ebuilds have unsermake support now. If you don't know what unsermake is: unsermake is a replacement for automake.
unsermake is now used by default to build KDE. To disable it emerge with the environment UNSERMAKE=no
If you manually want to build KDE apps with unsermake, you must call unsermake directly instead of make:
make -f Makefile.cvs / Makefile.common ./configure unsermake unsermake install
If you set FEATURES="keepobj" in your /etc/make.conf or your environment, whenever a package is merged, its compiled files will be saved. When a new merge is attempted, only the files modified on the SVN repository will be compiled.
Additionally, you may add confcache to your features, which will speed up the configure script by saving a cache of results.
By default, the directory where the compiled objects are stored is /var/tmp/portage/objects, but you may modify it, by setting PORTAGE_OBJDIR in your make.conf or your environment.
NOTE: if you switch between automake to unsermake, dependencies may not be handled correctly and everything may be recompiled
KNOWN PROBLEMS: for unknown reasons, sometimes some compiles are performed in the install stage and they usually bomb out. The only remedy right now is deleting their corresponding folder in the objects directory. I hope I will sort this out sooner or later.
"autoskipcvs" is a feature we provide for the kde-svn ebuilds (and those only). If you enable it, those ebuilds will first check for newer revisions on the SVN server for the package and then only proceed if there is in fact a newer revision. This way, you can in fact queue all KDE apps for emerge, but only those with newer svn revisions will get updated, and you will save a lot of compile time this way.
Like all other FEATURES, you can specify them in make.conf:
FEATURES="autoskipcvs"
We don't advise enabling it this way. Best is to pass it along on the command line, to prevent weird behaviour ;)
FEATURES="autoskipcvs" emerge
Questions and answers
Q: Why name it autoskipcvs when it only applies to svn ebuilds ?
A: Well, because there already is a keyword related to cvs/svn ebuilds in portage, named autoaddcvs, so in the spirit of consistency we decided to call it autoskipcvs. By the way, it's not that cvs ebuilds will never be supported by this feature, We just haven't got around to it to implement it in the cvs.eclass. So be patient.
Q: When I emerge a list of packages, emerge stops at the first not-updated package ?
A: Yes. That's "normal" behaviour. I did not find a way to make the ebuild quit graciously so I made it quit with an error. If I don't do that, ebuilds that did not compile anything will get merged to the live filesystem, but nothing has been compiled so you will find no executables installed, and that's not a good thing.
A quick workaround is to use a BASH "for" loop to emerge a list of KDE apps:
list="app1 app2 app3"; for i in ${list}; do emerge "${i}"; done
Q: Some package haven't been updated for a long time
A: You have to be cautious about the order in which KDE apps are updated. All the source is kept and updated in the same place, which can lead to package A being updated from SVN for package B, but not being compiled and installed. Take a look at the script (scripts/updateKDEsvn), it uses autoskipcvs and you will notice it doesn't randomly merge packages after each other, there's an order, so that package A is indeed updated before package B.
To give you a more understandable example, kde-base/kcontrol also fetches the code for kde-base/kicker and kde-base/kdm (among others). So if you run
emerge kde-base/kcontrol kde-base/kicker kde-base/kdm
kicker and kdm do NOT get updated, because the local svn copy is the newest revision. Be aware of that.
Q: I have made some fixes and/or changes. How do I submit them?
A: Just email your modifications to genkdesvn-discussion@lists.sourceforge.net
Q: What about qt-copy (qt-3.99)?
A: If you emerge qt-3.99, it will be used for further compilation, otherwise qt-3* will be used. qt-3.99 installs into /usr/qt/devel, let me know if you experience problems with it. In short, unlike kdelibs-7, nothing enforces installation of qt-3.99, you need to install it yourself. Also, if you know that any of the ebuilds work with older versions of kdelibs, let me know so I can lower their requirements, so people don't have to install the svn kdelibs, but use their release version if they want the independent package. At present only koffice and non-distro ebuilds (amarok, konversation, etc.) have lower requirements.
Q: How do I know when to update, if there are no revision numbers to these ebuilds?
A: There is a script in the repositoy (scripts/updateKDEsvn) that checks for each installed KDE-svn app, if a newer revision exists on SVN, and then only compiles and installs if a newer revision exists.
Q: I am installing package A, but I see that package B is also being compiled! Why?
A: Many modules are interdependent. Part of the difficulty of maintaining subversion ebuilds is tracking all the changes and newly added dependencies. Feel free to play with the corresponding variables in the ebuild, until you reduce some of the (sometimes heavy) dependencies. Here are some variables that you might want to concentrate on:
Localization is supported differently from the release builds: the translations are installed per package. The kde-i18n ebuild will install just a few entry files, needed for successful switching of languages using the control center module; no translations come with it. To be able to switch via the control center, you would need to install kcontrol. These two ebuilds may eventually be merged into one for simplicity. Neither kde-i18n nor kcontrol are not needed if KDE is started with a LANG environment variable, nor if individual applications are launched with a KDE_LANG environment variable.
In order to have the translation for a certain language and a certain package installed, one needs to define the LINGUAS variable. It is typically done in /etc/make.conf. e.g. LINGUAS="de pt se ru en_GB". If you have used older versions of these ebuilds, it is likely that your kdelibs and other packages do not include support for translations. You would need to reinstall them.
But even if you do, at the current moment not all packages will be installed with all translations available for the requested languages, since this requires some manual work and your help is needed.
Here's how you can help: Translations to be installed are selected based on the KSCM_L10N_PO variable defined in the ebuild. If none is defined and the ebuild is not modular (i.e. arts, kdelibs, kdevelop) all translations belonging to it will be installed. If none is defined and the ebuild is modular, its name will be used for determination of translations to be installed, i.e. if the ebuild's name is kontact, kontact.po will be fetched and installed. If KSCM_L10N_PO is defined as a list of translation names to be installed, without the .po extension, the corresponding translations will be fetched and installed. Wildcards are supported. Here are examples of manually set KSCM_L10N_PO:
kcontrol: KSCM_L10N_PO="kcontrol kcm* filetypes kaccess"; this says that translation files named kcontrol.po, filetypes.po, kaccess.po, and all .po files starting with kcm will be installed
k3b: KSCM_L10N_PO="*k3b*"; this says that all translation files with k3b somewhere in their names will be installed. Now, this determination must be done manually (give suggestions if you know how to better automate it). There is a way to facilitate the process, however, but it requires that you have the packages in question installed already (untranslated versions will do). Here's how to do it:
Open http://websvn.kde.org/trunk/l10n/templates/ in a browser and decide on which directory to concentrate. For example, if you're concerned with kdebase ebuilds, choose kdebase, if you're concerned with extragear ebuilds, choose extragear-multimedia, or extragear-network, etc.
Say, you've chosen kdebase, you can now obtain the listing of all possible translations, and redirect it into a file as follows:
svn list svn://anonsvn.kde.org/home/kde/trunk/l10n/templates/kdebase > kdebaselist
You must have gentoolkit installed to perform this step. With the obtained file, perform the following:
for item in `cat kdebaselist`; do equery belongs `echo $item | sed -e "s/.pot//"`; done
Then review the output; if the matching file corresponds to a real executable or a shared library, then you should review whether the containing ebuild's definition of KSCM_L10N_PO handles it. Take in mind, however, that not all translations will be detected, as sometimes their names are not exactly corresponding to the name of the object they translate, but those are not that common (e.g. kcm*), which is one reason it is difficult to automate this process.
Please be aware that this is NOT an official Gentoo or KDE Project. So do not file bug reports concerning these ebuilds on bugs.gentoo.org, or bug gentoo developers with errors generated by these ebuilds.
You can report bugs by using our bugtracker, addressing one of the project admins, or by reporting them in the Gentoo Forum thread. We prefer the bugtracker, of course.
Before reporting a bug, please try setting UNSERMAKE=no and disable the kdeenablefinal USE flag. UNSERMAKE is deprecated and will not be used for KDE4 and kdeenablefinal can trigger several problems.
None known.
Mask everything; selectively unmask
One tip I have is to mask all of the kde svn ebuilds and then selectively unmask the ones I want to use. To accomplish this I did the following hacky command:
find /usr/local/overlays/kde-live/ -iname "*.ebuild" |sed "s/\/usr\/local\/overlays\/kde-live\///g" \ |cut -f1 -d'.'|cut -f1 -d'7'|cut -f1,3 -d'/'|sed "s/$/7/g"|sed "s/^/>=/g"|sort|uniq >> /etc/portage/package.mask
Basically it is a bunch of string manipulation to add entries to you /etc/portage/package.mask. To use a package simply go unmask it by deleting its line in /etc/portage/package.mask
I do this so I can use the amarok-svn ebuild but not tie in all of kde!
Uninstallation
I was using kde-live and was being very unproductive in my coding life, and uninstallation of the kde-meta ebuild is not very straight forward so I did:
emerge unmerge pretend `find /var/db/pkg/kde-base/ -name "*-7" -type d -exec basename {} \;`
This will prevent you from uninstalling your other kde build, if applicable.
Related links