FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Desktop

 
 
LinkBack Thread Tools
 
Old 02-20-2010, 10:08 PM
Ladislav Laska
 
Default kde-sunset: Calling base_src_prepare from kde.eclass

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
>
>
 
Old 02-21-2010, 01:53 PM
Chris Bandy
 
Default kde-sunset: Calling base_src_prepare from kde.eclass

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
 
Old 02-21-2010, 04:09 PM
Ladislav Laska
 
Default kde-sunset: Calling base_src_prepare from kde.eclass

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
>
 
Old 02-22-2010, 10:58 AM
Andrew John Hughes
 
Default kde-sunset: Calling base_src_prepare from kde.eclass

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
 
Old 02-23-2010, 04:27 PM
Duncan
 
Default kde-sunset: Calling base_src_prepare from kde.eclass

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
 
Old 02-23-2010, 08:33 PM
Andrew John Hughes
 
Default kde-sunset: Calling base_src_prepare from kde.eclass

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
 
Old 02-25-2010, 12:14 AM
Duncan
 
Default kde-sunset: Calling base_src_prepare from kde.eclass

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
 

Thread Tools




All times are GMT. The time now is 08:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org