[gentoo-desktop] kde-sunset: Calling base_src_prepare from kde.eclass

[gentoo-desktop] kde-sunset: Calling base_src_prepare from kde.eclass

[Ladislav Laska]

Hello again,

I have decided to continue discussion in new thread. This discussion
was started in thread "kde-sunset: kdepim-kresources broken".

I have replaced my code with what I originally intended (the code in
git is wrong, since I made a mistake editing it - here is what I
intended):

        # Check for PATCHES in EAPI=0|1
        case ${EAPI:-0} in
            0|1)
                if [[ -n ${PATCHES} ]] && [[ -d "${KDE_S}" ]]; then
                    base_src_prepare
                fi
            ;;
        esac

Look, for example, at kde-base/ark ebuild. There is a patch, but it's
not applied correctly without my code.

What I'm worried about is the check  [[ -d "${KDE_S}" ]] makes sure,
that this code is called if

[[ -d "${KDE_S}" ]] || base_src_unpack unpack

did not called base-src_unpack and therefore did not applied patches.

There are two problems with EAPI=0|1

1) It depends on file naming and will not work if base_src_unpack
unpacks into $KDE_S
2) Even if base_src_unpack calls base_src_prepare, we're adding
patches automatically after this call, but they will not be applied.

Since I can't think of correct check, please let me know if you have
an idea. Also, let me know if I'm wrong about something and it's not
needed at all. (but I doubt that, because ark, as mentioned above, is
counterexample)

Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska@jabber.cz

Re: [gentoo-desktop] kde-sunset: Calling base_src_prepare from kde.eclass

[Martin von Gagern]

[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

Hi there!

On 19.02.2010 22:23, Ladislav Laska wrote:
> Hello again,
> 
> I have decided to continue discussion in new thread. This discussion
> was started in thread "kde-sunset: kdepim-kresources broken".
> 
> I have replaced my code with what I originally intended (the code in
> git is wrong, since I made a mistake editing it - here is what I
> intended):
> 
>         # Check for PATCHES in EAPI=0|1
>         case ${EAPI:-0} in
>             0|1)
>                 if [[ -n ${PATCHES} ]] && [[ -d "${KDE_S}" ]]; then
>                     base_src_prepare
>                 fi
>             ;;
>         esac
> 
> Look, for example, at kde-base/ark ebuild. There is a patch, but it's
> not applied correctly without my code.

media-gfx/gwenview-1.4.2-r3, on the other hand, would try applying
patches twice /with/ your code.

> What I'm worried about is the check  [[ -d "${KDE_S}" ]] makes sure,
> that this code is called if
> 
> [[ -d "${KDE_S}" ]] || base_src_unpack unpack
> 
> did not called base-src_unpack and therefore did not applied patches.
> 
> There are two problems with EAPI=0|1
> 
> 1) It depends on file naming and will not work if base_src_unpack
> unpacks into $KDE_S

You mean kde-meta_src_unpack does unpack into $KDE_S, right?

I just had a look. For kde-base/ark, kde-meta_src_unpack does unpack
part of the tarball, therefore kde_src_unpack won't call
base_src_unpack, therefore base_src_prepare won't get called either.

> 2) Even if base_src_unpack calls base_src_prepare, we're adding
> patches automatically after this call, but they will not be applied.

You're right, there is code collecting additional patches from $PATCHDIR
into the $PATCHES array. So we need to call base_src_prepare /after/
that, while the current base_src_unpack call comes before that, and
unpacking has to come before that as $PATCHDIR is unpacked as well.

As base_src_unpack calls base_src_prepare unconditionally for recent
incarnations of base.eclass, I feel we cannot call base_src_unpack at
all. Instead we should simply call "unpack ${A}" directly, and
base_src_prepare later on.

I feel that this code collecting and applying $PATCHES would be better
suited to a kde_src_prepare than kde_src_unpack, but I'm not sure it's
worth refactoring kde.eclass.

> Since I can't think of correct check, please let me know if you have
> an idea. Also, let me know if I'm wrong about something and it's not
> needed at all. (but I doubt that, because ark, as mentioned above, is
> counterexample)

No, you are correct in diagnosing the problem. I just had another stab
at a solution. Have a look at 5979aefafa6e200a09d5dd7b3a6e99b3e0a9d74e
and see if you find any package where that approach doesn't work.

Greetings,
 Martin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-desktop] kde-sunset: Calling base_src_prepare from kde.eclass

[Ladislav Laska]

Hello,

just what I had in mind. Works just fine with everything I tested - good job.

Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska@jabber.cz



On Sat, Feb 20, 2010 at 11:02 AM, Martin von Gagern
<Martin.vGagern@gmx.net> wrote:
> Hi there!
>
> On 19.02.2010 22:23, Ladislav Laska wrote:
>> Hello again,
>>
>> I have decided to continue discussion in new thread. This discussion
>> was started in thread "kde-sunset: kdepim-kresources broken".
>>
>> I have replaced my code with what I originally intended (the code in
>> git is wrong, since I made a mistake editing it - here is what I
>> intended):
>>
>>         # Check for PATCHES in EAPI=0|1
>>         case ${EAPI:-0} in
>>             0|1)
>>                 if [[ -n ${PATCHES} ]] && [[ -d "${KDE_S}" ]]; then
>>                     base_src_prepare
>>                 fi
>>             ;;
>>         esac
>>
>> Look, for example, at kde-base/ark ebuild. There is a patch, but it's
>> not applied correctly without my code.
>
> media-gfx/gwenview-1.4.2-r3, on the other hand, would try applying
> patches twice /with/ your code.
>
>> What I'm worried about is the check  [[ -d "${KDE_S}" ]] makes sure,
>> that this code is called if
>>
>> [[ -d "${KDE_S}" ]] || base_src_unpack unpack
>>
>> did not called base-src_unpack and therefore did not applied patches.
>>
>> There are two problems with EAPI=0|1
>>
>> 1) It depends on file naming and will not work if base_src_unpack
>> unpacks into $KDE_S
>
> You mean kde-meta_src_unpack does unpack into $KDE_S, right?
>
> I just had a look. For kde-base/ark, kde-meta_src_unpack does unpack
> part of the tarball, therefore kde_src_unpack won't call
> base_src_unpack, therefore base_src_prepare won't get called either.
>
>> 2) Even if base_src_unpack calls base_src_prepare, we're adding
>> patches automatically after this call, but they will not be applied.
>
> You're right, there is code collecting additional patches from $PATCHDIR
> into the $PATCHES array. So we need to call base_src_prepare /after/
> that, while the current base_src_unpack call comes before that, and
> unpacking has to come before that as $PATCHDIR is unpacked as well.
>
> As base_src_unpack calls base_src_prepare unconditionally for recent
> incarnations of base.eclass, I feel we cannot call base_src_unpack at
> all. Instead we should simply call "unpack ${A}" directly, and
> base_src_prepare later on.
>
> I feel that this code collecting and applying $PATCHES would be better
> suited to a kde_src_prepare than kde_src_unpack, but I'm not sure it's
> worth refactoring kde.eclass.
>
>> Since I can't think of correct check, please let me know if you have
>> an idea. Also, let me know if I'm wrong about something and it's not
>> needed at all. (but I doubt that, because ark, as mentioned above, is
>> counterexample)
>
> No, you are correct in diagnosing the problem. I just had another stab
> at a solution. Have a look at 5979aefafa6e200a09d5dd7b3a6e99b3e0a9d74e
> and see if you find any package where that approach doesn't work.
>
> Greetings,
>  Martin
>
>

Re: [gentoo-desktop] kde-sunset: Calling base_src_prepare from kde.eclass

[Chris Bandy]

[-- Attachment #1: Type: text/plain, Size: 4324 bytes --]

Ladislav Laska wrote:
> Hello,
>
> just what I had in mind. Works just fine with everything I tested - good job.
>
> Regards Ladislav Laska
> S pozdravem Ladislav Laska
> ---
> xmpp/jabber: ladislav.laska@jabber.cz
>
>
>
> On Sat, Feb 20, 2010 at 11:02 AM, Martin von Gagern
> <Martin.vGagern@gmx.net> wrote:
>   
>> Hi there!
>>
>> On 19.02.2010 22:23, Ladislav Laska wrote:
>>     
>>> Hello again,
>>>
>>> I have decided to continue discussion in new thread. This discussion
>>> was started in thread "kde-sunset: kdepim-kresources broken".
>>>
>>> I have replaced my code with what I originally intended (the code in
>>> git is wrong, since I made a mistake editing it - here is what I
>>> intended):
>>>
>>>         # Check for PATCHES in EAPI=0|1
>>>         case ${EAPI:-0} in
>>>             0|1)
>>>                 if [[ -n ${PATCHES} ]] && [[ -d "${KDE_S}" ]]; then
>>>                     base_src_prepare
>>>                 fi
>>>             ;;
>>>         esac
>>>
>>> Look, for example, at kde-base/ark ebuild. There is a patch, but it's
>>> not applied correctly without my code.
>>>       
>> media-gfx/gwenview-1.4.2-r3, on the other hand, would try applying
>> patches twice /with/ your code.
>>
>>     
>>> What I'm worried about is the check  [[ -d "${KDE_S}" ]] makes sure,
>>> that this code is called if
>>>
>>> [[ -d "${KDE_S}" ]] || base_src_unpack unpack
>>>
>>> did not called base-src_unpack and therefore did not applied patches.
>>>
>>> There are two problems with EAPI=0|1
>>>
>>> 1) It depends on file naming and will not work if base_src_unpack
>>> unpacks into $KDE_S
>>>       
>> You mean kde-meta_src_unpack does unpack into $KDE_S, right?
>>
>> I just had a look. For kde-base/ark, kde-meta_src_unpack does unpack
>> part of the tarball, therefore kde_src_unpack won't call
>> base_src_unpack, therefore base_src_prepare won't get called either.
>>
>>     
>>> 2) Even if base_src_unpack calls base_src_prepare, we're adding
>>> patches automatically after this call, but they will not be applied.
>>>       
>> You're right, there is code collecting additional patches from $PATCHDIR
>> into the $PATCHES array. So we need to call base_src_prepare /after/
>> that, while the current base_src_unpack call comes before that, and
>> unpacking has to come before that as $PATCHDIR is unpacked as well.
>>
>> As base_src_unpack calls base_src_prepare unconditionally for recent
>> incarnations of base.eclass, I feel we cannot call base_src_unpack at
>> all. Instead we should simply call "unpack ${A}" directly, and
>> base_src_prepare later on.
>>
>> I feel that this code collecting and applying $PATCHES would be better
>> suited to a kde_src_prepare than kde_src_unpack, but I'm not sure it's
>> worth refactoring kde.eclass.
>>
>>     
>>> Since I can't think of correct check, please let me know if you have
>>> an idea. Also, let me know if I'm wrong about something and it's not
>>> needed at all. (but I doubt that, because ark, as mentioned above, is
>>> counterexample)
>>>       
>> No, you are correct in diagnosing the problem. I just had another stab
>> at a solution. Have a look at 5979aefafa6e200a09d5dd7b3a6e99b3e0a9d74e
>> and see if you find any package where that approach doesn't work.
>>
>> Greetings,
>>  Martin
>>     

I also tested the specific packages in question, and here's what I found:

kde-base/ark-3.5.10
* inherit kde-meta
* EAPI=1 works

kde-base/kdepim-kresources-3.5.10
* inherit kde-meta eutils
* requires EAPI=1 (more details below)

kde-base/kicker-3.5.10-r2
* inherit kde-meta eutils
* EAPI=1 works
* EAPI=2 works

media-gfx/gwenview-1.4.2-r3
* inherit kde
* EAPI=1 works
* EAPI=2 works


As a more comprehensive test, I rebuilt everything I had in
kde-sunset[1].  Everything regarding PATCHES worked great!  However, I
had to make three changes to individual ebuilds:

1. Had to remove x11-libs/qt/qt-3.3.8-libpng14.patch because it was not
in the Manifest
2. Had to modify app-text/poppler/poppler-0.12.3-r3.ebuild as described
here: http://forums.gentoo.org/viewtopic-p-6170313.html#6170313
3. Had to revert kde-base/kdepim-kresources-3.5.10.ebuild back to EAPI=1

I've attached a log for the failed EAPI=2 build in #3.

[1] eix --installed-from-overlay kde-sunset --pure-packages --format
'<=emptyinstalled>' | xargs emerge -1


-- Chris

[-- Attachment #2: kdepim-kresources-ce3d54bb.tgz --]
[-- Type: application/x-gtar, Size: 58536 bytes --]

Re: [gentoo-desktop] kde-sunset: Calling base_src_prepare from kde.eclass

[Ladislav Laska]

Hello,

just looked at it.

1. The patch is currently not needed, since libpng>=1.4. But we can
apply it anyway, since it's checked inside code using macro.
2. No problem here (x86_64 issue?)
3. Seen this error, not sure why. But since patches work fine again
with eapi=1, there is probably no harm reverting.

Just pushed update, 1 and 3 should work fine now.

Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska@jabber.cz



On Sun, Feb 21, 2010 at 3:53 PM, Chris Bandy <cbandy@jbandy.com> wrote:
> Ladislav Laska wrote:
>> Hello,
>>
>> just what I had in mind. Works just fine with everything I tested - good job.
>>
>> Regards Ladislav Laska
>> S pozdravem Ladislav Laska
>> ---
>> xmpp/jabber: ladislav.laska@jabber.cz
>>
>>
>>
>> On Sat, Feb 20, 2010 at 11:02 AM, Martin von Gagern
>> <Martin.vGagern@gmx.net> wrote:
>>
>>> Hi there!
>>>
>>> On 19.02.2010 22:23, Ladislav Laska wrote:
>>>
>>>> Hello again,
>>>>
>>>> I have decided to continue discussion in new thread. This discussion
>>>> was started in thread "kde-sunset: kdepim-kresources broken".
>>>>
>>>> I have replaced my code with what I originally intended (the code in
>>>> git is wrong, since I made a mistake editing it - here is what I
>>>> intended):
>>>>
>>>>         # Check for PATCHES in EAPI=0|1
>>>>         case ${EAPI:-0} in
>>>>             0|1)
>>>>                 if [[ -n ${PATCHES} ]] && [[ -d "${KDE_S}" ]]; then
>>>>                     base_src_prepare
>>>>                 fi
>>>>             ;;
>>>>         esac
>>>>
>>>> Look, for example, at kde-base/ark ebuild. There is a patch, but it's
>>>> not applied correctly without my code.
>>>>
>>> media-gfx/gwenview-1.4.2-r3, on the other hand, would try applying
>>> patches twice /with/ your code.
>>>
>>>
>>>> What I'm worried about is the check  [[ -d "${KDE_S}" ]] makes sure,
>>>> that this code is called if
>>>>
>>>> [[ -d "${KDE_S}" ]] || base_src_unpack unpack
>>>>
>>>> did not called base-src_unpack and therefore did not applied patches.
>>>>
>>>> There are two problems with EAPI=0|1
>>>>
>>>> 1) It depends on file naming and will not work if base_src_unpack
>>>> unpacks into $KDE_S
>>>>
>>> You mean kde-meta_src_unpack does unpack into $KDE_S, right?
>>>
>>> I just had a look. For kde-base/ark, kde-meta_src_unpack does unpack
>>> part of the tarball, therefore kde_src_unpack won't call
>>> base_src_unpack, therefore base_src_prepare won't get called either.
>>>
>>>
>>>> 2) Even if base_src_unpack calls base_src_prepare, we're adding
>>>> patches automatically after this call, but they will not be applied.
>>>>
>>> You're right, there is code collecting additional patches from $PATCHDIR
>>> into the $PATCHES array. So we need to call base_src_prepare /after/
>>> that, while the current base_src_unpack call comes before that, and
>>> unpacking has to come before that as $PATCHDIR is unpacked as well.
>>>
>>> As base_src_unpack calls base_src_prepare unconditionally for recent
>>> incarnations of base.eclass, I feel we cannot call base_src_unpack at
>>> all. Instead we should simply call "unpack ${A}" directly, and
>>> base_src_prepare later on.
>>>
>>> I feel that this code collecting and applying $PATCHES would be better
>>> suited to a kde_src_prepare than kde_src_unpack, but I'm not sure it's
>>> worth refactoring kde.eclass.
>>>
>>>
>>>> Since I can't think of correct check, please let me know if you have
>>>> an idea. Also, let me know if I'm wrong about something and it's not
>>>> needed at all. (but I doubt that, because ark, as mentioned above, is
>>>> counterexample)
>>>>
>>> No, you are correct in diagnosing the problem. I just had another stab
>>> at a solution. Have a look at 5979aefafa6e200a09d5dd7b3a6e99b3e0a9d74e
>>> and see if you find any package where that approach doesn't work.
>>>
>>> Greetings,
>>>  Martin
>>>
>
> I also tested the specific packages in question, and here's what I found:
>
> kde-base/ark-3.5.10
> * inherit kde-meta
> * EAPI=1 works
>
> kde-base/kdepim-kresources-3.5.10
> * inherit kde-meta eutils
> * requires EAPI=1 (more details below)
>
> kde-base/kicker-3.5.10-r2
> * inherit kde-meta eutils
> * EAPI=1 works
> * EAPI=2 works
>
> media-gfx/gwenview-1.4.2-r3
> * inherit kde
> * EAPI=1 works
> * EAPI=2 works
>
>
> As a more comprehensive test, I rebuilt everything I had in
> kde-sunset[1].  Everything regarding PATCHES worked great!  However, I
> had to make three changes to individual ebuilds:
>
> 1. Had to remove x11-libs/qt/qt-3.3.8-libpng14.patch because it was not
> in the Manifest
> 2. Had to modify app-text/poppler/poppler-0.12.3-r3.ebuild as described
> here: http://forums.gentoo.org/viewtopic-p-6170313.html#6170313
> 3. Had to revert kde-base/kdepim-kresources-3.5.10.ebuild back to EAPI=1
>
> I've attached a log for the failed EAPI=2 build in #3.
>
> [1] eix --installed-from-overlay kde-sunset --pure-packages --format
> '<=emptyinstalled>' | xargs emerge -1
>
>
> -- Chris
>

Re: [gentoo-desktop] kde-sunset: Calling base_src_prepare from kde.eclass

[Martin von Gagern]

[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]

On 21.02.2010 15:53, Chris Bandy wrote:
> As a more comprehensive test, I rebuilt everything I had in
> kde-sunset[1].  Everything regarding PATCHES worked great!

Thanks a lot, I appreciate that testing!

> However, I had to make three changes to individual ebuilds:
> 
> 1. Had to remove x11-libs/qt/qt-3.3.8-libpng14.patch because it was not
> in the Manifest

Committed by Ladislav in f7ba03a46f179acb658a9775a75972fa3d2b68c5

> 2. Had to modify app-text/poppler/poppler-0.12.3-r3.ebuild as described
> here: http://forums.gentoo.org/viewtopic-p-6170313.html#6170313

Committed by me in 5ba737169016a164646bbfe1da53cbf7f34d137f

> 3. Had to revert kde-base/kdepim-kresources-3.5.10.ebuild back to EAPI=1

Committed by Ladislav in 5be5829c56380ca6ff08775d814558d936f816cc

> I've attached a log for the failed EAPI=2 build in #3.

I've had a look. Could reproduce the issue here, and could diff both
runs. One of the first differences I noted was this:

EAPI=1: checking if libkcal should be compiled... no
EAPI=2: checking if libkcal should be compiled... yes

This output is, of course, from configure. If you look at the ebuild,
you notice that it disables libkcal via an environment variable:

src_compile() {
	export DO_NOT_COMPILE="knotes libkcal"

This is only done in src_compile, i.e. after src_configure has already
completed. Only in EAPI=1, where there is no src_configure phase, but
instead a configure stage of the kde-meta_src_compile function, setting
the variable in this fashion gives the desired result.

I've written a EAPI=2 version of the ebuild that avoids these issues. It
works for me, so I decided to commit it, just in case we'll want to use
EAPI=2 in the future.

Committed by me in 1a496ce8440c3b8781be988df65ecc77ea267e6b

Greetings,
 Martin von Gagern


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-desktop] kde-sunset: Calling base_src_prepare from kde.eclass

[Chris Bandy]

Martin von Gagern wrote:
> On 21.02.2010 15:53, Chris Bandy wrote:
>   
>> As a more comprehensive test, I rebuilt everything I had in
>> kde-sunset[1].  Everything regarding PATCHES worked great!
>>     
>
> Thanks a lot, I appreciate that testing!
>
>   
>> However, I had to make three changes to individual ebuilds:
>>
>> 1. Had to remove x11-libs/qt/qt-3.3.8-libpng14.patch because it was not
>> in the Manifest
>>     
>
> Committed by Ladislav in f7ba03a46f179acb658a9775a75972fa3d2b68c5
>
>   
>> 2. Had to modify app-text/poppler/poppler-0.12.3-r3.ebuild as described
>> here: http://forums.gentoo.org/viewtopic-p-6170313.html#6170313
>>     
>
> Committed by me in 5ba737169016a164646bbfe1da53cbf7f34d137f
>
>   
>> 3. Had to revert kde-base/kdepim-kresources-3.5.10.ebuild back to EAPI=1
>>     
>
> Committed by Ladislav in 5be5829c56380ca6ff08775d814558d936f816cc
>
>   
>> I've attached a log for the failed EAPI=2 build in #3.
>>     
>
> I've had a look. Could reproduce the issue here, and could diff both
> runs. One of the first differences I noted was this:
>
> EAPI=1: checking if libkcal should be compiled... no
> EAPI=2: checking if libkcal should be compiled... yes
>
> This output is, of course, from configure. If you look at the ebuild,
> you notice that it disables libkcal via an environment variable:
>
> src_compile() {
> 	export DO_NOT_COMPILE="knotes libkcal"
>
> This is only done in src_compile, i.e. after src_configure has already
> completed. Only in EAPI=1, where there is no src_configure phase, but
> instead a configure stage of the kde-meta_src_compile function, setting
> the variable in this fashion gives the desired result.
>
> I've written a EAPI=2 version of the ebuild that avoids these issues. It
> works for me, so I decided to commit it, just in case we'll want to use
> EAPI=2 in the future.
>
> Committed by me in 1a496ce8440c3b8781be988df65ecc77ea267e6b
>
> Greetings,
>  Martin von Gagern
>   

I re-emerged everything I had in kde-sunset[1] again.  No build errors;
everything works!  Thanks!

[1] 1a496ce8440c3b8781be988df65ecc77ea267e6b

-- Chris

Re: [gentoo-desktop] kde-sunset: Calling base_src_prepare from kde.eclass

[Andrew John Hughes]

On 22 February 2010 03:23, Chris Bandy <cbandy@jbandy.com> wrote:
> Martin von Gagern wrote:
>> On 21.02.2010 15:53, Chris Bandy wrote:
>>
>>> As a more comprehensive test, I rebuilt everything I had in
>>> kde-sunset[1].  Everything regarding PATCHES worked great!
>>>
>>
>> Thanks a lot, I appreciate that testing!
>>
>>
>>> However, I had to make three changes to individual ebuilds:
>>>
>>> 1. Had to remove x11-libs/qt/qt-3.3.8-libpng14.patch because it was not
>>> in the Manifest
>>>
>>
>> Committed by Ladislav in f7ba03a46f179acb658a9775a75972fa3d2b68c5
>>
>>
>>> 2. Had to modify app-text/poppler/poppler-0.12.3-r3.ebuild as described
>>> here: http://forums.gentoo.org/viewtopic-p-6170313.html#6170313
>>>
>>
>> Committed by me in 5ba737169016a164646bbfe1da53cbf7f34d137f
>>
>>
>>> 3. Had to revert kde-base/kdepim-kresources-3.5.10.ebuild back to EAPI=1
>>>
>>
>> Committed by Ladislav in 5be5829c56380ca6ff08775d814558d936f816cc
>>
>>
>>> I've attached a log for the failed EAPI=2 build in #3.
>>>
>>
>> I've had a look. Could reproduce the issue here, and could diff both
>> runs. One of the first differences I noted was this:
>>
>> EAPI=1: checking if libkcal should be compiled... no
>> EAPI=2: checking if libkcal should be compiled... yes
>>
>> This output is, of course, from configure. If you look at the ebuild,
>> you notice that it disables libkcal via an environment variable:
>>
>> src_compile() {
>>       export DO_NOT_COMPILE="knotes libkcal"
>>
>> This is only done in src_compile, i.e. after src_configure has already
>> completed. Only in EAPI=1, where there is no src_configure phase, but
>> instead a configure stage of the kde-meta_src_compile function, setting
>> the variable in this fashion gives the desired result.
>>
>> I've written a EAPI=2 version of the ebuild that avoids these issues. It
>> works for me, so I decided to commit it, just in case we'll want to use
>> EAPI=2 in the future.
>>
>> Committed by me in 1a496ce8440c3b8781be988df65ecc77ea267e6b
>>
>> Greetings,
>>  Martin von Gagern
>>
>
> I re-emerged everything I had in kde-sunset[1] again.  No build errors;
> everything works!  Thanks!
>
> [1] 1a496ce8440c3b8781be988df65ecc77ea267e6b
>
> -- Chris
>
>

I've managed to rebuild most of KDE 3.5 against the new jpeg-8 library
using the overlay.  Many thanks for maintaining it!

I think the removal from the main tree is premature.  Not only is KDE
4 still an unstable resource hog, but the KOffice developers
explicitly state that 2.1:

'is not aimed at end users, and we do not recommend Linux
distributions to package it as the default office suite yet.'

http://www.koffice.org/news/koffice-2-1-released/

Whoever removed it from the main tree has completely ignored this and
decided to ship an incomplete office suite to users for the own
convenience.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[gentoo-desktop] Re: kde-sunset: Calling base_src_prepare from kde.eclass

[Duncan]

Andrew John Hughes posted on Mon, 22 Feb 2010 11:58:46 +0000 as excerpted:

> I've managed to rebuild most of KDE 3.5 against the new jpeg-8 library
> using the overlay.  Many thanks for maintaining it!
> 
> I think the removal from the main tree is premature.  Not only is KDE 4
> still an unstable resource hog, but the KOffice developers explicitly
> state that 2.1:
> 
> 'is not aimed at end users, and we do not recommend Linux distributions
> to package it as the default office suite yet.'
> 
> http://www.koffice.org/news/koffice-2-1-released/
> 
> Whoever removed it from the main tree has completely ignored this and
> decided to ship an incomplete office suite to users for the own
> convenience.

FWIW, I agree that it's premature, but it's not Gentoo's problem so much 
as KDE's and Qt Software's, as both kde3 and qt3 are unsupported upstream, 
thus, subject to security vulns, getting increasingly difficult to 
maintain in the face of continuing system updates, etc.  Why KDE refuses 
to support the previous stable version until the new version is generally 
stable as well, I don't know, but they don't.  (Qt I can see a bit more, 
as they're a commercial company, now part of Nokia, and supporting older 
versions costs real money.  It wasn't their fault that kde decided to go 
for a full rewrite instead of a straight upgrade port, /then/ do the 
rewrite when they have an existing stable kde based on a qt that's going 
to be supported for awhile.)

FWIW, I've been quite pleased with kde 4.4.  The upgrade from 3.x is still 
likely to be a big nightmare for many, as so many things have changed and 
there's some areas that other non-kde-core solutions will have to be used 
instead, but that's to be expected with an upgrade of that size. I had 
predicted with early 4.3 that based on evident rate of progress, 4.3 was 
the first one I could in good conscience call late beta quality, and 4.4 
should be rc quality with 4.5 hopefully finally reaching release quality.  
4.4 has certainly met at least that prediction, here, and to my very 
pleasant surprise, exceeded it to the point where I'm very nearly ready to 
call it full release quality, the only things keeping me from doing so is 
that I don't have all of kde installed, and haven't tested in 4.4 all of 
what I do have installed, and the caution from having been burned so many 
times previously by kde4.  But kde's official position was that 4.2 was 
ready for normal users, and that was terribly sad, because all it did was 
demonstrate how terribly out of touch with reality they were.

Well, there's still one bug that could be a show-stopper.  konqueror (and 
all of KDE) SSL and certificate support and management isn't yet up to 
what I'd call normal usable standards (it works in general, but the cert 
management familiar to kde3 users is missing, with the result being that 
it's broken on some sites with more exotic certificates -- good SSL and 
certificate management is absolutely critical in this day and age when 
many banking transactions and purchases are via web browser!).  But 
realistically, konqueror as a web browser is falling behind and looking to 
be replaced by the webkit based rekonq browser after it matures a bit 
more, enough so that few people use konqueror as their main browser any 
more anyway, with chrome/chromium and firefox/iceweasel/icecat being the 
major browsers picking up from konqueror, so this isn't the blocker it 
could have been as there's honestly not that many people, even among kde 
devs I gather, using konqueror as their primary browser anyway.  But that 
same support is used in a few other areas in kde as well, and it continues 
to be problematic there.

Then of course as you mentioned, there's koffice.  Just as it's really not 
qt's fault that kde took so long to stabilize on a reasonably current 
version, it's not so much kde-core's fault that koffice isn't yet properly 
stable on kde4.

The same applies to other apps built on kde, such as k3b, possibly amarok 
(which was bad enough, especially for amd64 users, that I got fed up and 
switched to something else, thus the "possibly" as I don't know current 
status), kaffeine, etc.  But the k3b live version (ebuild available in the 
kde overlay) is actually quite good, as I mentioned I gave up on amarok as 
it never was a real good fit for me, and I found the very good qt4 based 
smplayer to replace kaffeine, so the status on those isn't too bad.  But 
koffice... that remains a legitimate blocker, for those dependent on it 
for their workflow.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-desktop] Re: kde-sunset: Calling base_src_prepare from kde.eclass

[Andrew John Hughes]

On 23 February 2010 17:27, Duncan <1i5t5.duncan@cox.net> wrote:
> Andrew John Hughes posted on Mon, 22 Feb 2010 11:58:46 +0000 as excerpted:
>
>> I've managed to rebuild most of KDE 3.5 against the new jpeg-8 library
>> using the overlay.  Many thanks for maintaining it!
>>
>> I think the removal from the main tree is premature.  Not only is KDE 4
>> still an unstable resource hog, but the KOffice developers explicitly
>> state that 2.1:
>>
>> 'is not aimed at end users, and we do not recommend Linux distributions
>> to package it as the default office suite yet.'
>>
>> http://www.koffice.org/news/koffice-2-1-released/
>>
>> Whoever removed it from the main tree has completely ignored this and
>> decided to ship an incomplete office suite to users for the own
>> convenience.
>
> FWIW, I agree that it's premature, but it's not Gentoo's problem so much
> as KDE's and Qt Software's, as both kde3 and qt3 are unsupported upstream,
> thus, subject to security vulns, getting increasingly difficult to
> maintain in the face of continuing system updates, etc.  Why KDE refuses
> to support the previous stable version until the new version is generally
> stable as well, I don't know, but they don't.  (Qt I can see a bit more,
> as they're a commercial company, now part of Nokia, and supporting older
> versions costs real money.  It wasn't their fault that kde decided to go
> for a full rewrite instead of a straight upgrade port, /then/ do the
> rewrite when they have an existing stable kde based on a qt that's going
> to be supported for awhile.)
>

You're right that KDE's attitude is even worse - the choice of version
numbering being only the start.  I just don't think the Gentoo
position helps things, especially when the opposite tact could be
taken; provide KDE4 in an overlay for those who want to try it and
maintain KDE 3 in the main tree.  After all, they wouldn't be alone as
Debian is also maintaining it in stable.  Instead, we are faced with a
blanket mask out of the blue and the 'upgrade -- it's so much better'
fallacy.

I also approach this not so much for myself (I only use the odd KDE
app and not the desktop environment itself; I find even 3.5 too
bloated) but for other less tech-savvy users who just want to go about
their day-to-day tasks on the computer.  For them, everything works
fine wtih 3.5.  Why do they need to change?  It gets worse when you
then install a few KDE 4 apps and see sporadic crashes and heavy CPU
utilisation.  I used to find khexedit a useful tool for debugging data
files when coding.  In 4, there is a complete rewrite called okteta
with no apparent additional functionality but which uses 100% CPU as
soon as it loads up and is basically unusable.  And that's with 4.4 on
x86_64!

I don't really put Qt in the same boat.  Qt4 has been around for quite
a while longer than the equivalent KDE release (because of this huge
rewrite they decided to do) and I'd be happy to ditch it for the
superior 4 release if it wasn't for the loss of all those usable KDE
applications.  If you compare the switch from Gtk+1 to Gtk+2, it was
also painful but developers tended to do the minimum required to get
their code building (making use of the deprecated symbols still
available) rather than throw it all away and do a complete rewrite.  I
don't remember anything like this KDE upgrade with GNOME.

> FWIW, I've been quite pleased with kde 4.4.  The upgrade from 3.x is still
> likely to be a big nightmare for many, as so many things have changed and
> there's some areas that other non-kde-core solutions will have to be used
> instead, but that's to be expected with an upgrade of that size. I had
> predicted with early 4.3 that based on evident rate of progress, 4.3 was
> the first one I could in good conscience call late beta quality, and 4.4
> should be rc quality with 4.5 hopefully finally reaching release quality.
> 4.4 has certainly met at least that prediction, here, and to my very
> pleasant surprise, exceeded it to the point where I'm very nearly ready to
> call it full release quality, the only things keeping me from doing so is
> that I don't have all of kde installed, and haven't tested in 4.4 all of
> what I do have installed, and the caution from having been burned so many
> times previously by kde4.  But kde's official position was that 4.2 was
> ready for normal users, and that was terribly sad, because all it did was
> demonstrate how terribly out of touch with reality they were.

I haven't used it as an environment much.  I've seen it running on a
Debian testing box and to me, it just seems much the same with lots
more flashy gimmicks that slow the machine down.  Of most
disappointment is the decision to copy Windows with the K button, a
change I immediately reverted.

The applications are a mixed bunch.  Some are close to being Qt4 ports
of the originals with some improvements.  Others are just a joke.

>
> Well, there's still one bug that could be a show-stopper.  konqueror (and
> all of KDE) SSL and certificate support and management isn't yet up to
> what I'd call normal usable standards (it works in general, but the cert
> management familiar to kde3 users is missing, with the result being that
> it's broken on some sites with more exotic certificates -- good SSL and
> certificate management is absolutely critical in this day and age when
> many banking transactions and purchases are via web browser!).  But
> realistically, konqueror as a web browser is falling behind and looking to
> be replaced by the webkit based rekonq browser after it matures a bit
> more, enough so that few people use konqueror as their main browser any
> more anyway, with chrome/chromium and firefox/iceweasel/icecat being the
> major browsers picking up from konqueror, so this isn't the blocker it
> could have been as there's honestly not that many people, even among kde
> devs I gather, using konqueror as their primary browser anyway.  But that
> same support is used in a few other areas in kde as well, and it continues
> to be problematic there.
>

Yeah I wouldn't recommend Konqueror to anyone.  It had little use with
3.5 because it was unusable with so many sites, so I haven't even
really tried the KDE 4 version.  khtml has succeeded in being the
basis for WebKit, so they may as well just use that directly rather
than trying to continue developing a separate browser.  Qt even
includes a webkit binding and I assume they are using that to some
extent.  At least, building 4.4 required it.

> Then of course as you mentioned, there's koffice.  Just as it's really not
> qt's fault that kde took so long to stabilize on a reasonably current
> version, it's not so much kde-core's fault that koffice isn't yet properly
> stable on kde4.
>

koffice is the main issue with the one of the other users I mentioned
earlier.  She uses kword just fine with 1.6.3.  There's no particular
reason to try and use 2.2, and the website explicitly puts you off the
idea.  If only they'd made that more clear by calling it 2.0 beta or
something.  Gentoo seem to have taken the availability of some version
of KOffice that builds against Qt4 as a reason to dump the old
versions.  It seems to me that they don't actually use said
applications and just want a reason to get rid of the old
dependencies.

> The same applies to other apps built on kde, such as k3b, possibly amarok
> (which was bad enough, especially for amd64 users, that I got fed up and
> switched to something else, thus the "possibly" as I don't know current
> status), kaffeine, etc.  But the k3b live version (ebuild available in the
> kde overlay) is actually quite good, as I mentioned I gave up on amarok as
> it never was a real good fit for me, and I found the very good qt4 based
> smplayer to replace kaffeine, so the status on those isn't too bad.  But
> koffice... that remains a legitimate blocker, for those dependent on it
> for their workflow.
>

The new amarok was the first part of KDE 4 I tried, and probably still
takes the crown as the worst.  They seem to have dumped everything
good about it, including MusicBrainz support.  Strangely enough, users
aren't that excited by knowing an application builds against Qt4 --
that's pretty meaningless.  What they generally want is something that
works and a few new features are a bonus.

> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>
>

Thanks again for maintaining the overlay,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[gentoo-desktop] Re: kde-sunset: Calling base_src_prepare from kde.eclass

[Duncan]

Andrew John Hughes posted on Tue, 23 Feb 2010 21:33:55 +0000 as excerpted:

> On 23 February 2010 17:27, Duncan <1i5t5.duncan@cox.net> wrote:
>> Andrew John Hughes posted on Mon, 22 Feb 2010 11:58:46 +0000 as
>> excerpted:
>>
>>> KDE 3.5
>>>
>>> [R]emoval from the main tree is premature.  Not only
>>> is KDE 4 still an unstable resource hog, but [the koffice devs
>>> say koffice for kde4 isn't stable yet.]
>>> 
>>> Whoever removed it from the main tree has completely ignored this

>> FWIW, I agree that it's premature, but it's not Gentoo's problem so
>> much as KDE's and Qt Software's, as both kde3 and qt3 are unsupported
>> upstream, thus, subject to security vulns[.] Why KDE refuses to support
>> the previous stable version until the new version is generally stable
> as well, I don't know, but they don't.  (Qt I can see a bit more, as
>> they're a commercial company, [and] supporting older versions costs
>> real money.  It wasn't their fault that kde decided to go for a full
>> rewrite instead of a straight upgrade port[.)]
>>
> You're right that KDE's attitude is even worse - the choice of version
> numbering being only the start.  I just don't think the Gentoo position
> helps things, especially when the opposite tact could be taken; provide
> KDE4 in an overlay for those who want to try it and maintain KDE 3 in
> the main tree.  After all, they wouldn't be alone as Debian is also
> maintaining it in stable.  Instead, we are faced with a blanket mask out
> of the blue and the 'upgrade -- it's so much better' fallacy.

But there's a difference between gentoo and debian.  Gentoo is a rolling 
distribution that very much depends on upstream to continue to maintain 
package viability in the face of continuing system upgrades and security 
vulns.  Debian, OTOH, has a quite old stable version that basically 
doesn't get ordinary updates, with security fixes backported as 
necessary.  Gentoo basically doesn't do backports, they kick out the 
packages when they're no longer supported upstream and they get broken 
(security or cruft-wise).

So that's why the Gentoo choice was as it was.  No backporting, no 
supporting what upstream has abandoned.  We even have a dedicated tree 
cleaner project that removes stale and abandoned packages if they get 
forgotten.  Thus, the kde3/qt3 removal is in accordance with general 
gentoo policy.

But still, if there had been Gentoo devs that had wanted to maintain it, 
it may well have remained.  But all the gentoo/kde devs are kde4 users, 
and actually, took quite some trouble going out of their way to maintain 
an ever more broken kde3/qt3 in the tree as long as they did.

> I also approach this not so much for myself (I only use the odd KDE app
> and not the desktop environment itself; I find even 3.5 too bloated) but
> for other less tech-savvy users who just want to go about their
> day-to-day tasks on the computer.  For them, everything works fine wtih
> 3.5.  Why do they need to change?  It gets worse when you then install a
> few KDE 4 apps and see sporadic crashes and heavy CPU utilisation.  I
> used to find khexedit a useful tool for debugging data files when
> coding.  In 4, there is a complete rewrite called okteta with no
> apparent additional functionality but which uses 100% CPU as soon as it
> loads up and is basically unusable.  And that's with 4.4 on x86_64!

I'd file a bug about that, as it shouldn't be using 100% CPU...  Do you 
have multi-core (or hyperthreading if on Intel)?  Does it use 100% of just 
one core or of all of them?

> I don't really put Qt in the same boat.  Qt4 has been around for quite a
> while longer than the equivalent KDE release (because of this huge
> rewrite they decided to do) and I'd be happy to ditch it for the
> superior 4 release if it wasn't for the loss of all those usable KDE
> applications.  If you compare the switch from Gtk+1 to Gtk+2, it was
> also painful but developers tended to do the minimum required to get
> their code building (making use of the deprecated symbols still
> available) rather than throw it all away and do a complete rewrite.  I
> don't remember anything like this KDE upgrade with GNOME.

You know what I think the problem is?  I think too many of the KDE devs 
must be young and still think they can code the world in a day...  They 
didn't realized how big a job they were setting out for themselves when 
they decided to go the full rewrite route, and obviously, many of them 
aren't trying to run a kde system in a production environment, on ordinary 
hardware, or they'd not have been even /thinking/ about calling 4.2 ready 
for such users.

>> FWIW, I've been quite pleased with kde 4.4.[snip]
> 
> I haven't used it as an environment much.  I've seen it running on a
> Debian testing box and to me, it just seems much the same with lots more
> flashy gimmicks that slow the machine down.  Of most disappointment is
> the decision to copy Windows with the K button, a change I immediately
> reverted.

I can't say I know to what you're referring with that "copy Windows" bit, 
as I made the jump to freedomware the week eXPrivacy came out, as there 
was simply no way I was going to consent to having to go to MS for 
authorization if I upgraded too much of my machine.  After having been a 
faithful MS user for a decade, one who liked the idea of Linux but 
honestly, might not have jumped without that extra push from MS because I 
/was/ leaving a decade of knowledge behind, the only other alternative 
would have been to start pirating the software, as doing the authorization 
thing was just somewhere I wasn't going to go, period.  But luckily, 
Linux /was/ available, and now, I have MS to thank for giving me that 
push.  I've never looked back except in increasing revulsion as I've 
realized what true software freedom is.

Um... excuse me... where was I... Oh, yes... Anyway, I suppose that's why 
I haven't any idea what you're talking about with copy windows thing on 
the kmenu.

FWIW, the kickoff menu remains, here, but I didn't use the kmenu much on 
kde3, and I don't use the kickoff menu much on kde4.  I have hotkey 
assignments for the apps I use regularly, and often type commands into 
krunner, for stuff I know by name that's not hotkeyed.  Thus, the only 
time I use the kmenu/kickoff, both back on kde3 and now on kde4, is for 
those apps I use seldom enough that I actually need to browse the menu for 
them.  For that, the kickoff menu /is/ somewhat of an improvement from 
kde3's kmenu, or at least I find it so.  But that's maybe a couple times a 
month to a couple times a week I do that at all.  The rest of the time, I 
don't need and don't use that menu, at all.

>> But realistically, konqueror as a web browser is falling
>> behind and looking to be replaced by the webkit based rekonq browser
>> after it matures a bit more

> Yeah I wouldn't recommend Konqueror to anyone.  It had little use with
> 3.5 because it was unusable with so many sites, so I haven't even really
> tried the KDE 4 version.

I actually /do/ still use konqueror as my main browser.  But I have 
firefox available for those sites that need it.   Most of the sites I 
frequent with any regularity, tho, work fine in konqueror, even with 
scripting disabled most of the time as that's my default, as they're tech 
news sites and the like, generally targeted at Linux users.  Slashdot, 
LWN, LXer, ArsTechnica, the KDE and Gentoo planet blogs, etc.  Even my 
bank (Bank of America) works reasonably well with konqueror (tho I have 
scripting enabled there, of course). =:^)  But both konqueror and firefox 
get filtered thru privoxy, here, which deals with the ads, etc, plus a 
bunch of my own custom filters (I prefer a "reverse" color scheme, for 
instance, light text on a dark background, and have a whole set of privoxy 
filters I've developed over the years, that do custom page rewriting to 
give me that, without killing the colors entirely.)

> khtml has succeeded in being the basis for
> WebKit, so they may as well just use that directly rather than trying to
> continue developing a separate browser.  Qt even includes a webkit
> binding and I assume they are using that to some extent.  At least,
> building 4.4 required it.

The plasma desktop uses qt4's webkit for various plasmoids, among other 
things.  However, the qt4 webkit implementation was quite buggy and 
limited to begin with, and wasn't particularly suited to implementation of 
a full browser based on it.  It's maturing and will be at some point, but 
kde was one of the first big users and uncovered many bugs as a result, 
which had to be fixed before it could be used for a decent browser 
implementation.  As I mentioned, tho, rekonq is webkit based (I'm not sure 
if it's qt-webkit or something-else webkit, but webkit, anyway), and the 
general plan is that it will eventually officially supplant konqueror, 
when it's ready.  But I don't expect that until at least qt 4.7 and kde 
4.6, basically a year from now.

> koffice is the main issue with the one of the other users I mentioned
> earlier.  She uses kword just fine with 1.6.3.  There's no particular
> reason to try and use 2.2, and the website explicitly puts you off the
> idea.  If only they'd made that more clear by calling it 2.0 beta or
> something.  Gentoo seem to have taken the availability of some version
> of KOffice that builds against Qt4 as a reason to dump the old versions.
>  It seems to me that they don't actually use said applications and just
> want a reason to get rid of the old dependencies.

Well, as explained above, that's not quite it.  There really is no 
developer interested in continuing what they all see as the dead-end of 
qt3/kde3.  And as it's a community distro, with all the devs being 
volunteers, it's not as if any of them are being paid to do it.  If any of 
the folks now maintaining the kde-sunset overlay had put enough into it to 
be full Gentoo devs before this all happened... but of course they're 
volunteers too, and they may simply not have the time or energy to put 
into being a full Gentoo dev, or be uninterested in it for other reasons.


> The new amarok was the first part of KDE 4 I tried, and probably still
> takes the crown as the worst.  They seem to have dumped everything good
> about it, including MusicBrainz support.

Seems we agree on that.  FWIW, amarok's supposed to be gradually regaining 
many of those features, but it's too late for that here.  Amarok always 
was a pretty heavy dependency app for my needs, as you said, they dumped 
many of the useful features while adding crap for the new version, and 
when they basically ignored the problems that had mysql-embedded broken on 
amd64 and switched to it anyway, therefore breaking things for that whole 
swath of their users, that was the last straw, here.  Yes, they said that 
was while they weren't yet claiming the kde4 version was ready for 
primetime, but too bad, kde-core-3 support was already being dropped by 
the kde-core folks and by distributions, so ready or not, the kde4 version 
was what was available for many.  And then to go breaking it for that 
large a segment of their users...

Let's just say, same kde4 mess song, yet another verse. <shaking head>  
But unlike kde4 itself, I didn't rely on amarok enough to be worth the 
hassle of trying to stick with it, so it got dumped.

> Strangely enough, users aren't that excited by knowing an application
> builds against Qt4 -- that's pretty meaningless.  What they generally
> want is something that works and a few new features are a bonus.

Well, being a Gentoo user/sysadmin, I'm perhaps beyond the level of user 
you're referring to.  But when I saw that kde3 and qt3 were in the 
pipeline to be dumped, qt4 support DID mean a lot to me.  As soon as I got 
a reasonably working kde4 system (thus after the 100+ hours I put into 
working around breakage, etc, see below), I dumped kde3 and qt3 as fast as 
possible.  For one thing, keeping up with updates on both of them was a 
big chore, one I was eager to get rid of by eliminating all remaining kde3 
and qt3 dependencies so I could eliminate them.  For another, the kde3 
build system especially, was irreparably broken in terms of parallel 
building.  The cmake build system kde4 uses is MUCH more parallelizable, 
with the result being that kde4 upgrades are FAR more manageable on this 
dual dual-core (so 4 cores) system, taking only a third to a half the time 
they did with kde3.  Spending all day upgrading KDE when an upgrade came 
out, is something I definitely do NOT miss now, and something I was 
certainly eager to do what I could to hasten its departure from my system, 
once I finally did get kde4 up and running in a halfway decently usable 
way, even if did take over a hundred hours of workarounds to get it there, 
time very few users have to spend at all, and even fewer are going to be 
willing to spend.  No /wonder/ so many folks ended up dumping kde 
entirely.  I would have too had I felt there was a reasonable alternative 
to kde for my usage.

> Thanks again for maintaining the overlay,

Just to avoid any confusion, I have nothing to do with the overlay.  I'm 
simply a user who saw what was coming, and spent WAY more time than most 
would tolerate, 100 hours plus of researching and installing, or in some 
cases, scripting my own workaround solutions for stuff broken in kde4, 
that should have "just worked", as it did in kde3.  That's on top of the 
time I'd have expected to put into upgrading, and this was the same kde4 
they were claiming was working just fine, despite the open bugs saying it 
wasn't, while they were dumping the kde3 that /was/ stable and where 
stuff /did/ "just work".

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman