checking for history max command lenght... yes checking for pkg-config... no checking for fontconfig... no configure: WARNING: ----------------------------------------------------- `fontconfig' was not found on your system. Although `adesklets' will work anyway system-wide automatic font detection will not occur: it is therefore quite possible that only the default font provided with the package will display. ----------------------------------------------------- checking for fork... yes checking for X... no checking for imlib2-config... /usr/bin/imlib2-config checking for imlib2 - version >= 1.1.2... ./configure: line 7383: test: 1.009: integer expression expected yes checking for imlib2... checking for imlib2 - version >= 1.2.0... ./configure: line 7457: test: 1.009: integer expression expected yes checking for imlib2 program linking with ad-hoc flags... no checking for imlib2 program linking... no configure: error: Cannot link Imlib2 program. If you specified you did not want X support this can be caused by your Imlib2 installment being configured so it needs it or conversely. In that case reinstall Imlib2 with proper --enable-x11-support parameter (as from enlightement CVS) before retrying to configure this package. !!! Please attach the following file when filing a report to bugs.gentoo.org: !!! /var/tmp/portage/adesklets-0.6.1/work/adesklets-0.6.1/config.log !!! ERROR: x11-misc/adesklets-0.6.1 failed. configure:7534: x86_64-pc-linux-gnu-gcc -o conftest -O2 -pipe -std=c99 -pedantic -Wall conftest.c -lImlib2 >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libfreetype.so.6, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libImlib2.so, not found (try using -rpath or -rpath-link) /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libX11.so.6, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libImlib2.so, not found (try using -rpath or -rpath-link) that leads to this DEP in imlib2: DEPEND="=media-libs/freetype-2* bzip2? ( app-arch/bzip2 ) zlib? ( sys-libs/zlib ) gif? ( >=media-libs/giflib-4.1.0 ) png? ( >=media-libs/libpng-1.2.1 ) jpeg? ( media-libs/jpeg ) tiff? ( >=media-libs/tiff-3.5.5 ) X? ( || ( ( x11-libs/libXext x11-proto/xextproto ) virtual/x11 ) ) mp3? ( media-libs/libid3tag )" obviously freetype is RDEPEND, please fix
looks fine to me
Eh, this whole thing is definitely not fine, because the only RDEPEND actually is sys-devel/gettext that comes from enlightenment.eclass. Please, finally stop relying on a non-existant implicit RDEPEND, because as you can see it plain doesn't work.
toss off, i already said in other bugs what needs to be with the RDEPEND situation
Dude ... this package is seriously missing an RDEPEND. Breaking binpkgs on purpose is really uncool, so please just add freetype to RDEPEND.
do some reading first
(In reply to comment #5) > do some reading first kindly reference a bug number first ;)
(In reply to comment #3) > toss off, i already said in other bugs what needs to be with the RDEPEND > situation Getting tired of this. The ebuild is broken, nothing's gonna be done about the RDEPEND situation (whatever you mean by that, portage folks already explained to you multiple times) - so how about fixing the bad dependencies instead of marking bugs that are apparently valid as invalid?
(In reply to comment #6) > (In reply to comment #5) > > do some reading first > kindly reference a bug number first ;) See Bug 149434 (we document non-existant behaviour in an official howto, oh the fun), Bug 142755 and bunch of others. Apparently fighting windmills is more important than having ebuilds that are not broken.
yawn
(In reply to comment #9) > yawn OMG fix the darned ebuild that has completely broken RDEPEND which is missing all the needed libraries. Not even funny any more.
i wasnt laughing when the bug was originally posted
May I ask what are you after here? Having fun causing intentional borkage or what exactly? The RDEPEND is completely broken, missing all the libs like freetype, jpeg, png, libpng, tiff, libid3tag etc. etc.) there - so perhaps you could explain how is this bug INVALID?
According to the conventional rules for implicit RDEPEND handling the ebuild is correct. Now stop being a dick please.
(In reply to comment #13) > According to the conventional rules for implicit RDEPEND handling the ebuild is > correct. Now stop being a dick please. Your conventional rules (whatever you mean) are broken, as everyone can check. Now re-read Bug 149434 Comment #5, or go ask portage folks if you need more explanation how the dependencies work. I can see we have a wonderful QA, really folks maybe just go dissolve your team as it's apparently not useful. Valid bugs getting closed as INVALID w/ QA consent, calling someone a dick instead of providing some argument, oh this really rocks.
here's a great idea ... let the developers do the developing and the bug wranglers to the bug wrangling
The current portage behaviour is broken however you look at it. Once that's fixed one way or the other, then we can start changing ebuilds to comply with it.
OK, if portage is broken, then assign this to portage folks.
Portage folks, you should fix portage. Enjoy. ;)
if you bothered to actually follow portage development you'd know that WE ARE ALREADY WORKING ON IT
Jakub, there is a patch to fix this and it awaits development approval. Chill. As much as broken stuff sucks this bug is rather minor and it can wait. So please be patient. Thanks.
Created attachment 101092 [details, diff] revert implicit RDEPEND behavior to how it was in portage-2.0.51 If we do this then we have to make sure everybody is prepared for the consequences. Basically, it restricts implicit RDEPEND to the ebuild level, making it independent of whatever RDEPEND may or may not be defined in the inherited eclasses. That means that some ebuilds will get implicit RDEPEND that they don't get currently. Also, some ebuilds will loose some implicit RDEPEND that they current get from eclasses. In order to make the transition as smooth and consistent as possible, we should do a portage-2.1.1-r2 revbump with the patch and have it stabilized. At the same time, I'll apply the patch on the master rsync mirror and force regeneration of the entire cache.
(In reply to comment #21) > Created an attachment (id=101092) [edit] > revert implicit RDEPEND behavior to how it was in portage-2.0.51 RDEPEND in 2.0.51 was RDEPEND="${RDEPEND} ${E_RDEPEND}"... so, no it's not like how it was in .51 > If we do this then we have to make sure everybody is prepared for the > consequences. Basically, it restricts implicit RDEPEND to the ebuild level, > making it independent of whatever RDEPEND may or may not be defined in the > inherited eclasses. That means that some ebuilds will get implicit RDEPEND > that they don't get currently. Also, some ebuilds will loose some implicit > RDEPEND that they current get from eclasses. Take this to the dev ml. I know spankys views on implicit RDEPEND/DEPEND, but fair number of folks were pushing for it to be flat out killed. If y'all are going to screw with it again (unversioned I might add), please make sure *everyone* will agree to it and it will *not* be screwed with again.
(In reply to comment #22) > (In reply to comment #21) > > Created an attachment (id=101092) [edit] > > revert implicit RDEPEND behavior to how it was in portage-2.0.51 > > RDEPEND in 2.0.51 was > RDEPEND="${RDEPEND} ${E_RDEPEND}"... so, no it's not like how it was in .51 AFAIK the patch reverts the behavior to the 2.0.51 level. The implicit part of RDEPEND comes from ${DEPEND}, and then ${E_RDEPEND} is added to the ebuild's RDEPEND (as with all versions of portage). Anyway, if that's not correct, we can straighten it all out in the mailing list discussion I guess...
(In reply to comment #23) > Anyway, if that's not correct, we > can straighten it all out in the mailing list discussion I guess... Quick check of hte src shows it to be; either way, ml it since it's going to cause issues with folks caches among other things...
i wrote the patch from scratch so i wasnt trying to revert it to a specific version, only to the proper behavior
http://article.gmane.org/gmane.linux.gentoo.devel/43937 holds the main details, but the short version is that if going to revert to the old behaviour, all portage versions need to be revbump'd (holding same keywords), old versions yoinked, and touching all eclasses to force transfer of the updated cache entries to the localized cache...
This has been released in 2.1.1-r2 and 2.1.2_rc2. Both have a note in the ChangeLog and an ewarn message with a reference to this bug. I timed the release with regeneration of the metadata on the rsync mirrors for all affected packages. In all, 2786 cache entries were updated. For reference, here is the postinst ewarn message: * In portage-2.1.1-r2, the implicit RDEPEND behavior has been reverted back to * the way it was in <portage-2.0.52. This change restricts implicit RDEPEND to * the ebuild level, making it independent of whatever RDEPEND may or may not be * defined in the inherited eclasses. As a result, some ebuilds will get * implicit RDEPEND that they did not get previously. Also, some ebuilds will * loose some implicit RDEPEND that they previously got from eclasses. Users * that sync with the rsync mirrors will have their metadata cache automatically * updated on the next sync (or the next time that they run * `emerge --metadata`). Users of the gentoo-x86 CVS repository, in order to * make the change immediately effective, will have to manually remove the * entire contents of /var/cache/edb/dep/ and then run `emerge --regen`. * If necessary, please refer to bug #153591 for more information.
*** Bug 142755 has been marked as a duplicate of this bug. ***
*** Bug 151911 has been marked as a duplicate of this bug. ***
*** Bug 152208 has been marked as a duplicate of this bug. ***
*** Bug 159210 has been marked as a duplicate of this bug. ***
