Guys, gals,
Looking at tdebase build package for arch based on the original 3.5.13 tarball, I show the following patches:
patches/01-kicker-lockout-applet-button-order.patch patches/dbusfix.patch patches/07-bigger_title_icons_in_kcontrol.patch patches/06-nspluginscan-xdgcompliance.patch patches/08-kip_kdesktop_rounded_icon_text_corners.patch patches/03-kcontrol_advbg_step.patch patches/02-doc_location.patch
and
xsession.patch
Does anyone know which are still required for the tdebase build from the git tree? I looked at http://scm.trinitydesktop.org/scm/git/tdebase, but I can't figure out which patch may have been applied. Better tool for that?
On 22 February 2012 22:44, David C. Rankin drankinatty@suddenlinkmail.comwrote:
Guys, gals,
Looking at tdebase build package for arch based on the original 3.5.13 tarball, I show the following patches:
patches/01-kicker-lockout-applet-button-order.patch patches/dbusfix.patch patches/07-bigger_title_icons_in_kcontrol.patch patches/06-nspluginscan-xdgcompliance.patch patches/08-kip_kdesktop_rounded_icon_text_corners.patch patches/03-kcontrol_advbg_step.patch patches/02-doc_location.patch
and
xsession.patch
Does anyone know which are still required for the tdebase build from the git tree? I looked at http://scm.trinitydesktop.org/scm/git/tdebase, but I can't figure out which patch may have been applied. Better tool for that?
I don't think at any of them have anything to do with actual build issues. they are miscellaneous patches from kdemod3.
dbusfix might be the only one that is an actual build fix.
http://git.trinitydesktop.org is probaby easier to use
Calvin
On 02/22/2012 09:44 PM, David C. Rankin wrote:
Guys, gals,
Looking at tdebase build package for arch based on the original 3.5.13 tarball, I show the following patches:
patches/01-kicker-lockout-applet-button-order.patch patches/dbusfix.patch patches/07-bigger_title_icons_in_kcontrol.patch patches/06-nspluginscan-xdgcompliance.patch patches/08-kip_kdesktop_rounded_icon_text_corners.patch patches/03-kcontrol_advbg_step.patch patches/02-doc_location.patch
and
xsession.patch
Does anyone know which are still required for the tdebase build from the git tree? I looked at http://scm.trinitydesktop.org/scm/git/tdebase, but I can't figure out which patch may have been applied. Better tool for that?
From the initial look of it, they are still all valid. All patches applied and tdebase (git) is chugging through the cmake files and building. 3% and going strong :)
On 22 February 2012 23:28, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 02/22/2012 09:44 PM, David C. Rankin wrote:
Guys, gals,
Looking at tdebase build package for arch based on the original 3.5.13 tarball, I show the following patches:
patches/01-kicker-lockout-applet-button-order.patch patches/dbusfix.patch patches/07-bigger_title_icons_in_kcontrol.patch patches/06-nspluginscan-xdgcompliance.patch patches/08-kip_kdesktop_rounded_icon_text_corners.patch patches/03-kcontrol_advbg_step.patch patches/02-doc_location.patch
and
xsession.patch
Does anyone know which are still required for the tdebase build from the git tree? I looked at http://scm.trinitydesktop.org/scm/git/tdebase, but I can't figure out which patch may have been applied. Better tool for that?
From the initial look of it, they are still all valid. All patches applied and tdebase (git) is chugging through the cmake files and building. 3% and going strong :)
-- David C. Rankin, J.D.,P.E.
Yes they really should all be candidate for sending upstream ( I know pawel looked at them, but more eyes on it the better)
Calvin
On 02/22/2012 10:33 PM, Calvin Morrison wrote:
From the initial look of it, they are still all valid. All patches applied and tdebase (git) is chugging through the cmake files and building. 3% and going strong :)
-- David C. Rankin, J.D.,P.E.
Yes they really should all be candidate for sending upstream ( I know pawel looked at them, but more eyes on it the better)
Calvin
Yes, eyes.. From the look of it, within the hour I should have TDE 3.5.13 from git built though tdebase on both i686 and x86_64 and ready to test on a new Arch box via virtualbox. God I love that virtual machine :) I still have all my Trinity 3.5.13 installs in vbox environments from last May. The all still work. It will be great to setup another and run a side by side compare.
On Thu, Feb 23, 2012 at 5:33 AM, Calvin Morrison mutantturkey@gmail.com wrote:
On 22 February 2012 23:28, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 02/22/2012 09:44 PM, David C. Rankin wrote:
Guys, gals,
Looking at tdebase build package for arch based on the original 3.5.13 tarball, I show the following patches:
patches/01-kicker-lockout-applet-button-order.patch patches/dbusfix.patch patches/07-bigger_title_icons_in_kcontrol.patch patches/06-nspluginscan-xdgcompliance.patch patches/08-kip_kdesktop_rounded_icon_text_corners.patch patches/03-kcontrol_advbg_step.patch patches/02-doc_location.patch
and
xsession.patch
Does anyone know which are still required for the tdebase build from the git tree? I looked at http://scm.trinitydesktop.org/scm/git/tdebase, but I can't figure out which patch may have been applied. Better tool for that?
From the initial look of it, they are still all valid. All patches applied and tdebase (git) is chugging through the cmake files and building. 3% and going strong :)
-- David C. Rankin, J.D.,P.E.
Yes they really should all be candidate for sending upstream ( I know pawel looked at them, but more eyes on it the better)
Calvin
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
xsession.patch is arch specific doc_location.patch changes doc install location, enabling building i18n packages, without it i18n will complain about missing docs and fail. dbusfix.patch is needed for building as far as I can remember. Others are minor fixes pulled from kdemod3
On 02/23/2012 04:45 AM, Pawel Soltys wrote:
xsession.patch is arch specific doc_location.patch changes doc install location, enabling building i18n packages, without it i18n will complain about missing docs and fail. dbusfix.patch is needed for building as far as I can remember. Others are minor fixes pulled from kdemod3
AArgh!
xsession patch kills the build in the 'package' phase :(
-- Installing: /build/pkg/opt/trinity/lib/trinity/kded_kdeintegration.la patching file /build/pkg/opt/trinity/share/config/kdm/Xsession Hunk #1 FAILED at 43. 1 out of 1 hunk FAILED -- saving rejects to file /build/pkg/opt/trinity/share/config/kdm/Xsession.rej
On 02/23/2012 07:35 AM, David C. Rankin wrote:
On 02/23/2012 04:45 AM, Pawel Soltys wrote:
xsession.patch is arch specific doc_location.patch changes doc install location, enabling building i18n packages, without it i18n will complain about missing docs and fail. dbusfix.patch is needed for building as far as I can remember. Others are minor fixes pulled from kdemod3
AArgh!
xsession patch kills the build in the 'package' phase :(
-- Installing: /build/pkg/opt/trinity/lib/trinity/kded_kdeintegration.la patching file /build/pkg/opt/trinity/share/config/kdm/Xsession Hunk #1 FAILED at 43. 1 out of 1 hunk FAILED -- saving rejects to file /build/pkg/opt/trinity/share/config/kdm/Xsession.rej
I vunder why? (scowled with a German accent)
07:37 providence:~/tde/bld/trinity-tdebase> cat xsession.patch --- /mnt/archlinux/opt/trinity/share/config/kdm/Xsession 2011-12-08 13:08:43.000000000 +0100 +++ /opt/kde3/share/config/kdm/Xsession 2011-09-24 14:52:28.000000000 +0200 ^^^^^^^^^ @@ -43,4 +43,24 @@
On 23 February 2012 08:39, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 02/23/2012 07:35 AM, David C. Rankin wrote:
On 02/23/2012 04:45 AM, Pawel Soltys wrote:
xsession.patch is arch specific doc_location.patch changes doc install location, enabling building i18n packages, without it i18n will complain about missing docs and fail. dbusfix.patch is needed for building as far as I can remember. Others are minor fixes pulled from kdemod3
AArgh!
xsession patch kills the build in the 'package' phase :(
-- Installing: /build/pkg/opt/trinity/lib/trinity/kded_kdeintegration.la patching file /build/pkg/opt/trinity/share/config/kdm/Xsession Hunk #1 FAILED at 43. 1 out of 1 hunk FAILED -- saving rejects to file /build/pkg/opt/trinity/share/config/kdm/Xsession.rej
I vunder why? (scowled with a German accent)
07:37 providence:~/tde/bld/trinity-tdebase> cat xsession.patch --- /mnt/archlinux/opt/trinity/share/config/kdm/Xsession 2011-12-08 13:08:43.000000000 +0100 +++ /opt/kde3/share/config/kdm/Xsession 2011-09-24 14:52:28.000000000 +0200 ^^^^^^^^^ @@ -43,4 +43,24 @@
-- David C. Rankin, J.D.,P.E.
Tim,
what is the best way to submit patches for nonbugs/random stuff? bug report + patchavail?
Calvin
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
On 23 February 2012 09:04, Darrell Anderson humanreadable@yahoo.com 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
On 02/23/2012 09:08 AM, Calvin Morrison wrote:
On 23 February 2012 09:04, Darrell Andersonhumanreadable@yahoo.com 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"...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.
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 Andersonhumanreadable@yahoo.com 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"...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.
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:
http://www.3111skyline.com/dl/dt/trinity/tmp/patches.tar.bz2
contains:
patches/01-kicker-lockout-applet-button-order.patch patches/dbusfix.patch patches/07-bigger_title_icons_in_kcontrol.patch patches/06-nspluginscan-xdgcompliance.patch patches/08-kip_kdesktop_rounded_icon_text_corners.patch patches/03-kcontrol_advbg_step.patch patches/02-doc_location.patch
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 accommodate.
On 02/23/2012 10:05 AM, David C. Rankin wrote:
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 accommodate.
No they should be addressed at the dev point. Everthing that needs renamed should be accounted for by the devs.
Only packing issues should be dealt with from a packagers view. we all know that there are enought of those :(
This sounds related to bug report 660. Would you please
post the contents of the patch?
diff -u -r admin/debianrules kdebase/admin/debianrules --- src/kdebase/admin/debianrules 2012-01-05 17:41:56.000000000 +0100
Yup, same problem. :)
Darrell
On 23 February 2012 10:04, Darrell Anderson humanreadable@yahoo.com wrote:
This sounds related to bug report 660. Would you please
post the contents of the patch?
diff -u -r admin/debianrules kdebase/admin/debianrules --- src/kdebase/admin/debianrules 2012-01-05 17:41:56.000000000 +0100
Yup, same problem. :)
Darrell
take the patch, attach it to the bug report #660, mark patch available?
This sounds related to bug report 660. Would
you please
post the contents of the patch?
diff -u -r admin/debianrules
kdebase/admin/debianrules
--- src/kdebase/admin/debianrules 2012-01-05 17:41:56.000000000 +0100
Yup, same problem. :)
take the patch, attach it to the bug report #660, mark patch available?
I submitted a patch long ago. :) Once the patch is pushed to GIT the entire discussion ends. :)
Darrell
This sounds
related to bug report 660. Would
you please
post the contents of the patch?
diff -u -r admin/debianrules
kdebase/admin/debianrules
--- src/kdebase/admin/debianrules 2012-01-05 17:41:56.000000000 +0100
Yup, same problem. :)
take the patch, attach it to the bug report #660, mark
patch
available?
I submitted a patch long ago. :) Once the patch is pushed to GIT the entire discussion ends. :)
Well, I was being too cavalier with that statement.
The patch attached to the bug report is basically a one-liner. If nobody objects to the proposed patch then there is no reason not to push the patch to GIT. The patch fixes the expected default location in tdelibs. Possibly there are distros installing the help files in their own peculiar place, but those maintainers can deal with patching for their own peculiarities.
The patch fixes only the default path hard-coded into tdelibs. After applying the tdelibs patch the following needs to done for all packages converted to cmake:
find $APP_SOURCES_DIR -name TDESetupPaths.cmake -exec sed -i s'|${SHARE_INSTALL_PREFIX}/doc/kde/HTML|${SHARE_INSTALL_PREFIX}/doc/HTML|g' {} ; find $APP_SOURCES_DIR -name TDESetupPaths.cmake -exec sed -i s'|${SHARE_INSTALL_PREFIX}/doc/tde/HTML|${SHARE_INSTALL_PREFIX}/doc/HTML|g' {} ;
Fortunately, we're talking about a small number of packages that have been converted to cmake.
Leaving tdelibs and the few existing cmake packages as-is means we then have to modify all of the remaining automake packages to use those same paths. All of the automake packages point to ${SHARE_INSTALL_PREFIX}/doc/HTML and not to ${SHARE_INSTALL_PREFIX}/doc/tde/HTML. As the automake packages far outnumber the cmake packages, reverting the few cmake packages and tdelibs to that original path is less work.
A remaining question is where does KDE4 install the help files? As we still have app names that are the same in both desktops, we need to ensure our help files cannot conflict. Yet there is no conflict with KDE4 because when KDE4 is an option with any distro, then the distro maintainers and packagers will build Trinity to install to a place other than /usr. That is, the ${PREFIX} for both desktops will always be different and that eliminates any potential conflict.
Therefore all we need to do is apply the tdelibs patch and then fix a handful of TDESetupPaths.cmake files. Done.
Would be nice to eliminate this particular in-grown hair. :)
Tim, if you want, I can make the changes here. I'll need a full day to fully test, but then I could push the change set to GIT. Up to you. :)
Darrell
Looking at tdebase build package for arch based on the original 3.5.13 tarball, I show the following patches:
patches/01-kicker-lockout-applet-button-order.patch patches/dbusfix.patch patches/07-bigger_title_icons_in_kcontrol.patch patches/06-nspluginscan-xdgcompliance.patch patches/08-kip_kdesktop_rounded_icon_text_corners.patch patches/03-kcontrol_advbg_step.patch patches/02-doc_location.patch
and
xsession.patch
Does anyone know which are still required for the tdebase build from the git tree? I looked at http://scm.trinitydesktop.org/scm/git/tdebase, but I can't figure out which patch may have been applied. Better tool for that?
If they build against GIT then they haven't been merged.
Have these been submitted in any bug reports? If not then ask Tim to review and merge.
Darrell
-
Baho Utot -
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Pawel Soltys