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
signature.asc
Description: OpenPGP digital signature
