Message: previous - next
Month: February 2012

Re: [trinity-devel] tdebase - which patches still required for git?

From: "David C. Rankin" <drankinatty@...>
Date: Thu, 23 Feb 2012 09:05:52 -0600
On 02/23/2012 08:45 AM, Baho Utot wrote:
> On 02/23/2012 09:08 AM, Calvin Morrison wrote:
>> On 23 February 2012 09:04, Darrell Anderson<humanreadable@...>  wrote:
>>>> doc_location.patch changes doc install location, enabling
>>>> building i18n packages, without it i18n will complain about missing
>>>> docs and fail.
>>> This sounds related to bug report 660. Would you please post the contents of
>>> the patch?
>>> Darrell
>> diff -u -r admin/debianrules kdebase/admin/debianrules
>> --- src/kdebase/admin/debianrules    2012-01-05 17:41:56.000000000 +0100
>> +++ admin/debianrules    2011-08-21 09:08:23.000000000 +0200
>> @@ -16,7 +16,7 @@
>>   $kde_cgidir    =    "$kde_prefix/lib/cgi-bin";
>>   $kde_confdir    =    "$sysconfdir/trinity";
>> -$kde_htmldir    =    "$kde_prefix/share/doc/kde/HTML";
>> +$kde_htmldir    =    "$kde_prefix/share/doc/HTML";
>>   if (defined $ENV{DEB_BUILD_OPTIONS}&&
>>       $ENV{DEB_BUILD_OPTIONS} =~ /\bnostrip\b/) {
>> diff -u -r src/kdebase/cmake/modules/TDESetupPaths.cmake
>> kdebase/cmake/modules/TDESetupPaths.cmake
>> --- src/kdebase/cmake/modules/TDESetupPaths.cmake    2012-01-05
>> 17:42:06.000000000 +0100
>> +++ cmake/modules/TDESetupPaths.cmake    2011-08-21 09:08:24.000000000 +0200
>> @@ -41,7 +41,7 @@
>>     _tde_internal_setup_path( PLUGIN_INSTALL_DIR
>> "${LIB_INSTALL_DIR}/trinity"                     "The subdirectory
>> relative to the install prefix where plugins will be installed
>> (default is ${LIB_INSTALL_DIR}/trinity)" )
>>     _tde_internal_setup_path( CONFIG_INSTALL_DIR
>> "${SHARE_INSTALL_PREFIX}/config"              "The config file install
>> dir" )
>>     _tde_internal_setup_path( DATA_INSTALL_DIR
>> "${SHARE_INSTALL_PREFIX}/apps"                "The parent directory
>> where applications can install their data" )
>> -  _tde_internal_setup_path( HTML_INSTALL_DIR
>> "${SHARE_INSTALL_PREFIX}/doc/kde/HTML"        "The HTML install dir
>> for documentation" )
>> +  _tde_internal_setup_path( HTML_INSTALL_DIR
>> "${SHARE_INSTALL_PREFIX}/doc/HTML"        "The HTML install dir for
>> documentation" )
>>     _tde_internal_setup_path( ICON_INSTALL_DIR
>> "${SHARE_INSTALL_PREFIX}/icons"               "The icon install dir
>> (default ${SHARE_INSTALL_PREFIX}/share/icons/)" )
>>     _tde_internal_setup_path( KCFG_INSTALL_DIR
>> "${SHARE_INSTALL_PREFIX}/config.kcfg"         "The install dir for
>> kconfig files" )
>>     _tde_internal_setup_path( LOCALE_INSTALL_DIR
>> "${SHARE_INSTALL_PREFIX}/locale"              "The install dir for
>> translations" )
>> Currently I am rather annoyed at the tarball of patches>_>
>> Pawel, David, Baho - can we just avoid tarballs for patches? I'd
>> rather have them extracted. it makes it impossible to track patch
>> changes with them inside binary blobs like a tarball.
>> Calvin
> I don't do the "tarball of patches"...That is not mine.
> I use seds as I am only working at the packing level.  I put the seds into the
> The devs (which I am not,  maybe a packager)  for trinity need to address the
> "patches" any way the feel they need to.
> I look at it this way, trinity and or trinity devs need to get me something I
> can use/package.  I can/should/help with  fixing some things but I should not
> need to be a developer just to package this thing.
> What I am looking for completed tarball from the devs that build,  not really
> into fixing problems with the source code etc...only from the point to get it to
> package.
> If trinity gets to the point where I have lots of problems to package it I will
> need to move on.
> Notice I have not built from git only built from the 3.5.13 tarballs.
> I will try building the next release when it is released.  If that doesn't work
> or I have a lot of "issues" packaging it, I will need move to another desktop as
> I have other things that require my time.  I have a scratch built GNU/Linux
> system that I maintain every single package using pacman 3.5.
> I can use any desktop from xcfe to KDE4, doesn't really matter to me only that
> it works and I don't have to mess with it all day long to get something done.
> To recap I am looking for releases that can be made to build with little or no
> trouble to get it packaged.

  The primary problem with building tdebase from git on arch is an arch
packaging problem. I have it solved. There were patches that references 'kdm'
instead of 'tdm' and 'kde' instead of 'tde' in multiple places.

  The tdebase patchfiles need to either be included in the git tree or evaluated
for whether they are even needed. The primary patch file:



  I don't know enough about the code to tell whether they are needed or not. The
all still apply cleanly, so I can only presume they are needed. If so, then they
should be added to the git tree if they are needed by tdebase. Tim, Serghei,
Darrell, who is smart enough to do that? I'll look, but I'm not familiar at all
with the source for kicker, dbus, kcontrol or nspluginscan.

  I'll put up the updated pkgbuilds once I get them cleaned. All the build
scripts need work. There is a mismatch of naming between $pkgname $provides and
$depends that I'm just going to make a table of the values and start from the
beginning and update all the pkgbuilds so the dependency tree is clean. I.e.:
Qt3 -> tde-tqtinterface -> tde-arts -> tde-dbus-tqt -> .... tde-tdelibs ->
tde-tdebase, and so on. Right now the scripts still have 'kde' in the pkgname
and provides.

  There have been significant changes from a distro build standpoint between the
3.5.13 tarballs and the current git tree. Primarily, just the 'kd_whatever' to
'td_whatever'. All necessary, but it will just take reworking the PKGBUILDs to

David C. Rankin, J.D.,P.E.