Message: previous - next
Month: February 2012

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

From: Baho Utot <baho-utot@...>
Date: Thu, 23 Feb 2012 09:45:24 -0500
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 PKGBUILDs.

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.