Julian Simioni

I Forgot How Frustrating SVN Can Be

Yesterday, I was installing the latest KDE 4.10 beta, which is built from source. The Gentoo KDE overlay already has ebuilds, which use KDE’s SVN as the source, rather than a tarball. While installing all the packages, there was a failure to install kdeartwork-wallpapers:

 * Package:    kde-base/kdeartwork-wallpapers-9999
 * Repository: kde
 * Maintainer: kde@gentoo.org
 * USE:        amd64 elibc_glibc kernel_linux userland_GNU
 * FEATURES:   sandbox splitdebug userpriv usersandbox
>>> Unpacking source...
 * Fetching disabled since 1 hours has not passed since last update.
 * Using existing repository copy at revision 1326016.
 *    working copy: /usr/portage/distfiles/svn-src/kdeartwork/kdeartwork

 * Exporting parts of working copy to /var/tmp/portage/kde-base/kdeartwork-wallpapers-9999/work/kdeartwork-wallpapers-9999
rsync: link_stat "/usr/portage/distfiles/svn-src/kdeartwork/kdeartwork/wallpapers" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1052) [sender=3.0.9]
 * ERROR: kde-base/kdeartwork-wallpapers-9999 failed (unpack phase):
 *   {ESVN}: can't export subdirectory 'wallpapers' to '/var/tmp/portage/kde-base/kdeartwork-wallpapers-9999/work/kdeartwork-wallpapers-9999/'.
 * Call stack:
 *     ebuild.sh, line   93:  Called src_unpack
 *   environment, line 4224:  Called kde4-meta_src_unpack
 *   environment, line 3403:  Called kde4-meta_src_extract
 *   environment, line 3309:  Called die
 * The specific snippet of code:
 *                       rsync --recursive ${rsync_options} "${wc_path}/${subdir%/}" "${S}/${targetdir}" || die "${escm}: can't export subdirectory '${subdir}' to '${S}/${targetdir}'.";
 * If you need support, post the output of `emerge --info '=kde-base/kdeartwork-wallpapers-9999'`,
 * the complete build log and the output of `emerge -pqv '=kde-base/kdeartwork-wallpapers-9999'`.
 * This ebuild used the following eclasses from overlays:
 *   /var/lib/layman/kde/eclass/kde4-meta.eclass
 *   /var/lib/layman/kde/eclass/kde4-base.eclass
 *   /var/lib/layman/kde/eclass/kde4-functions.eclass
 *   /var/lib/layman/kde/eclass/cmake-utils.eclass
 * This ebuild is from an overlay named 'kde': '/var/lib/layman/kde/'
 * The complete build log is located at '/var/tmp/portage/kde-base/kdeartwork-wallpapers-9999/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/kde-base/kdeartwork-wallpapers-9999/temp/environment'.
 * Working directory: '/var/tmp/portage/kde-base/kdeartwork-wallpapers-9999/work/kdeartwork-wallpapers-9999'
 * S: '/var/tmp/portage/kde-base/kdeartwork-wallpapers-9999/work/kdeartwork-wallpapers-9999'

This is a simple package, and since it is a live ebuild, I assumed a directory had been moved and set about debugging the problem. I spent a good amount of time looking into the KDE eclasses, trying to figure out how to figure out what was being built. Only after a while of this, during another attempt at compiling the package, did I realize that SVN could be the culprit.

A little digging revealed that indeed SVN, for reasons unknown, had done only a partial checkout of the repository. Indeed trying manually to checkout the entire part of the repository required was never successful in one go: it took multiple manual resumes to checkout the complete repository. Somehow, this error was never detected by Portage.

Having not even touched SVN for 8 months, after several years of begrudingly using it, I had totally forgotten the sort of pains it allowed.