User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061119 Firefox/1.5.0.8 Build Identifier: configure: error: *** Can't find cairo-pdf.h. You must build Cairo with the pdf *** backend enabled Manually emerging cairo fixes this. Reproducible: Didn't try Portage 2.1.1-r2 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.4-r4, 2.6.17-gentoo-r8 i686) ================================================================= System uname: 2.6.17-gentoo-r8 i686 Intel(R) Pentium(R) D CPU 3.00GHz Gentoo Base System version 1.12.6 Last Sync: Sun, 10 Dec 2006 17:20:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://ftp.wwc.edu/pub/mirrors/ftp.gentoo.org http://mirror.clarkson.edu/pub/distributions/gentoo/ " LANG="en_US.UTF-8" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 X alsa apache2 apm arts berkdb bitmap-fonts cdr cli cracklib crypt cups dlloader doc dri dvd dvdr eds elibc_glibc emboss encode esd ffmpeg fglrx foomaticdb fortran gdbm gif gimp gimpprint gnome gphoto2 gpm gstreamer gtk gtk2 hal iconv imagemagick imap imlib input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog jpeg kde kernel_linux libg++ libwww mad maildir mbox mikmod mmx mmxext motif mp3 mpeg ncurses nls nptl nptlonly nsplugin ogg opengl oss pam pcre perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl session spell spl sse sse2 ssl svg tcpd truetype truetype-fonts type1-fonts udev usb userland_GNU video_cards_fglrx video_cards_video_cards_v4l video_cards_video_cards_vesa video_cards_video_cards_vga vorbis xdiv xml xorg xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
Cardoe, you've removed the pdf flag without revbumping cairo in any way (already caused Bug 157533) and now you've removed this check in gtk+ so this for dies with broken dependencies without any explanation. :/ Please, revbump cairo and force appropriate dependency in gtk+ ebuilds, so that people are actually forced to re-emerge cairo.
jakub: Cool it wrt bug #157533. I did the commits within minutes of each other... The fact that the rsync server/cvs trigger in between happens TO EVERYONE. If this was the case then tree wide changing commits could NEVER happen. And no, no rev bump is needed.
(In reply to comment #2) > jakub: Cool it wrt bug #157533. I did the commits within minutes of each > other... The fact that the rsync server/cvs trigger in between happens TO > EVERYONE. If this was the case then tree wide changing commits could NEVER > happen. > > And no, no rev bump is needed. This is completely irrelevant and unrelated to any rsync in-between whatever. Without revbumping this can only produce two-way borkage (either the failing built_with_use check, or failed compile as in this bug). You need to actually force people to re-emerge cairo if you nuke the flags that affect gtk+ compile, not just change flags on the fly and hope that noone will notice.
(In reply to comment #3) > You need to actually > force people to re-emerge cairo if you nuke the flags that affect gtk+ compile This can be done by "-N" / "--newuse" option of emerge.
(In reply to comment #4) > (In reply to comment #3) > > You need to actually > > force people to re-emerge cairo if you nuke the flags that affect gtk+ compile > This can be done by "-N" / "--newuse" option of emerge. I have the same problem on an update of gtk+. This workaround fixes it. Thanks! (And thanks gentoo-portage.com) My use flags have NOT changed, so this is a bug in this package, or maybe cairo?. I'm not too clear on how use flags propagate, but this looks like one of those flaws in the ebuild system, right? How can cairo know it needs to be recompiled if only the flags in gtk+ change, or was it the other way around? I don't really care, why not just bump the revision of cairo (and update gtk+ to require it) and call it fixed? There's hundreds, literally hundreds of revision numbers just waiting to be used. Use all you want!
*** Bug 158431 has been marked as a duplicate of this bug. ***
*** Bug 159000 has been marked as a duplicate of this bug. ***
*** Bug 159395 has been marked as a duplicate of this bug. ***
I believe most people with this problem are using x11-libs/cairo from some badly maintained overlay like gentoo-xeffects (and to be fair, there are others) which has broken ebuilds revision bumped. Fine example here, cairo-1.2.4-r1 ebuild provides USE="pdf" in-overlay, cairo-1.2.4 in-portage doesn't. This bug should be closed as invalid far as I can see..
No, I'm not using cairo from an overlay, I am using a rock solid myth box that I rarely update and don't have any overlays gone on there. It is indeed caused by the fact that I didn't do an -N option which causes cairo to be remerged. I think jakub's suggestion to rev bump and change dependency in gtk+ ebuild is the right one to take.
Came across this today. I havent updated my server in a while and got this error doing an emerge -uD world. Nothing told me that I 'needed' to do a -uDN. And no, my server doesnt use an overlay, and maybe a few ~amd's. I installed cairo 1.2.6 (from an older 1.2.4) just to see if it helped, and it did.
I'm not sure a revdep-rebuild is required for this. However, recompiling cairo then gtk+ resolves the issue for me. Wendall
What's the status on this bug? Anyone still experiencing anything?
Well when all arches stabilize cairo 1.2.6, it will be a completely none issue for everyone. Since all stale overlays will have to update.
