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@××××××.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
>