23 Feb
2012
23 Feb
'12
9:45 p.m.
On 02/23/2012 09:08 AM, Calvin Morrison wrote:
On 23 February 2012 09:04, Darrell
Anderson<humanreadable(a)yahoo.com> wrote:
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"...in 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.
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