Gentoo Archives: gentoo-desktop

From: Ladislav Laska <ladislav.laska@×××××.com>
To: gentoo-desktop@l.g.o
Subject: Re: [gentoo-desktop] kde-sunset: Calling base_src_prepare from kde.eclass
Date: Sun, 21 Feb 2010 17:09:36
Message-Id: 255f067f1002210909o67109af2td6470beca9a42ff6@mail.gmail.com
In Reply to: Re: [gentoo-desktop] kde-sunset: Calling base_src_prepare from kde.eclass by Chris Bandy
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@××××××.cz



On Sun, Feb 21, 2010 at 3:53 PM, Chris Bandy <cbandy@××××××.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@××××××.cz >> >> >> >> On Sat, Feb 20, 2010 at 11:02 AM, Martin von Gagern >> <Martin.vGagern@×××.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 >