An emerge of dev-libs/gobject-introspection-0.10.8 (a new install, not an update to an existing gobject-introspection) failed with the error: ... Making all in scanner make[4]: Entering directory `/home/usr/portage/tmp/portage/dev-libs/gobject-introspection-0.10.8/work/gobject-introspection-0.10.8/tests/scanner' CC libregress_la-regress.lo In file included from ./regress.c:6: ./regress.h:4:19: error: cairo.h: No such file or directory In file included from ./regress.c:6: ... [followed by a number of parse errors due to unrecognized data types that would have been defined in cairo.h] There was a /usr/include/cairo/cairo.h on the system, owned by x11-libs/cairo. x11-libs/cairo was already at the latest level, 1.10.2-r1. I attempted the ugly hack of adding "-I/usr/include/cairo" to CFLAGS in /etc/make.conf. This allowed the emerge to move beyond that step, but only slightly: ... Making all in scanner make[4]: Entering directory `/home/usr/portage/tmp/portage/dev-libs/gobject-introspection-0.10.8/work/gobject-introspection-0.10.8/tests/scanner' CC libregress_la-regress.lo CCLD libregress.la GISCAN Regress-1.0.gir Package gl was not found in the pkg-config search path. Perhaps you should add the directory containing `gl.pc' to the PKG_CONFIG_PATH environment variable Package 'gl', required by 'cairo', not found ... There was no gl.pc on the system, in /usr/lib/pkgconfig or anywhere else. Further research revealed that media-libs/mesa is supposed to supply /usr/lib/pkgconfig/gl.pc. The version on this system, media-libs/mesa-6.5.2-r1, did not include it. Updating to media-libs/mesa-7.9.2 put /usr/lib/pkgconfig/gl.pc in place and allowed dev-libs/gobject-introspection-0.10.8 to build, even with the ugly hack removed from CFLAGS in /etc/make.conf. So dev-libs/gobject-introspection-0.10.8 needs to have a more recent media-libs/mesa as a dependency. I do not know what the minimum version number requirement is. (Note: while media-libs/mesa-7.9.2 supplies /usr/lib/pkgconfig/gl.pc, even with this newer media-libs/mesa in place -- along with the numerous dependencies it pulled in -- the only cairo.h on the system remains /usr/include/cairo/cairo.h. But the dev-libs/gobject-introspection-0.10.8 build did not trip up on cairo.h this time. I am not sure whether the media-libs/mesa upgrade itself, or one of its dependencies, solved the initial problem of not finding cairo.h. However, as far as fixing this bug, it's immaterial: making dev-libs/gobject-introspection-0.10.8 require the correct media-libs/mesa is sufficient.)
Are you using FEATURES=test ?
Created attachment 284047 [details] emerge --info
(In reply to comment #1) > Are you using FEATURES=test ? No. emerge --info attached
Confirming. What you experienced is a combination of two issues. The first issue is that gobject-introspection always builds tests, even when the user didn't ask for them and doesn't need them, and those tests require cairo. The second issue is that cairo[opengl] requires gl.pc, but depends on virtual/opengl, and virtual/opengl can be satisfied by any version of mesa, potentially including ancient ones that don't have gl.pc. To be honest, I don't think that the second issue deserves to be addressed. All users should have upgraded to mesa-7.x *years* ago. Gentoo dropped support for mesa-6.5.2-r1 in 2009, and I have no idea how you got that package on a new Gentoo install. The first issue, however, is a real bug, and should be patched.
(In reply to comment #4) > All users should have upgraded to mesa-7.x *years* ago. I disagree -- different users have different needs, and for some of those needs, running with current software is not a priority. Choosing when to update software surely falls within the Gentoo philosophy of giving the user control over his/her system. > Gentoo dropped support for mesa-6.5.2-r1 in 2009, Does dropping support for a package imply dropping support for the upgrade path from that package to a supported version? > and I have no idea how you got that package on a new Gentoo install. Sorry for the confusion: I meant that this was a new install of dev-libs/gobject-introspection-0.10.8 on an existing (and, obviously, old) system.
(In reply to comment #5) > (In reply to comment #4) > > All users should have upgraded to mesa-7.x *years* ago. > > I disagree -- different users have different needs, and for some of those > needs, running with current software is not a priority. I am sorry, but in that case, I can only suggest you look at a distro that offers long-term support, such as RHEL, CentOS, or Ubuntu LTS. Gentoo's flexibility comes at a price: Gentoo devs need to test all those options, flags, knobs, and toggles in current versions of packages. and that leaves fewer resources for supporting old versions, or even upgrades from old versions. As a result, users must update frequently, or risk being left behind, unsupported. If you don't update world for several months, you are guaranteed to run into problems. If you don't update in over a year, often the easiest solution is to just reinstall.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > All users should have upgraded to mesa-7.x *years* ago. > > > > I disagree -- different users have different needs, and for some of those > > needs, running with current software is not a priority. > > I am sorry, but in that case, I can only suggest you look at a distro that > offers long-term support, such as RHEL, CentOS, or Ubuntu LTS. > What Alexander means to say is that you are free to run whatever you want, but you shouldn't expect us to give you support for that. Our priorities do not include making sure that systems that haven't been upgraded in 2 years are able to selectively upgrade packages. If you're using such an outdated system, we recommend that you get everything up-to-date to latest stable.
Created attachment 284211 [details, diff] gobject-introspection-0.10.8-make-check.patch Patch for gobject-introspection to not build tests unless FEATURES=test. Reported upstream at https://bugzilla.gnome.org/show_bug.cgi?id=657066 (note that the patch is the same as the one submitted upstream; it appears to work equally well both for gobject-introspection-0.10.8 and 1.29.16).
Upstream looks happy about this, good news. Feel free to apply.
+ 12 Sep 2011; Pacho Ramos <pacho@gentoo.org> + gobject-introspection-0.10.8.ebuild, + +files/gobject-introspection-0.10.8-build-tests.patch: + Build tests only on make check, bug #379929 by Dave Kemper and patch by + Alexandre Rostovtsev. +
Alexandre, thank you for fixing the bug requiring the test suite to be built. Concerning the other bug identified in comment #4: (In reply to comment #6) > Gentoo's flexibility comes at a price: Gentoo devs need to test all those > options, flags, knobs, and toggles in current versions of packages. and that > leaves fewer resources for supporting old versions, or even upgrades from old > versions. As a result, users must update frequently, or risk being left behind, > unsupported. Is that your opinion, or is that official, documented Gentoo policy? The Gentoo Philosophy (http://www.gentoo.org/main/en/philosophy.xml) states, "If the tool forces the user to do things a particular way, then the tool is working against, rather than for, the user. ... This is backwards, and contrary to the Gentoo philosophy." The position you've stated contravenes this: requiring upgrades on a particular schedule is a case of the tool controlling the user. Just to be clear, I am not looking for, nor asking for, support for outdated packages. I am not even asking that anyone do extra testing, just that they not be dismissive of bugs reported for upgrade paths from old packages.
(In reply to comment #11) > Is that your opinion, or is that official, documented Gentoo policy? It is my empirical observation both as a longtime Gentoo user and now as a developer. I have seen on multiple occasions that if I don't update a particular Gentoo box for over 3-4 months, the upgrade is likely to be problematic and will require careful hand-holding, manual ordering of emerges, and setting temporary USE flags (that will later need to be removed) on particular packages. I have also seen the same observation echoed by several other Gentoo developers.
In summary, we don't break updates from old systems intentionally, but sometimes it can occur as it's impossible to test all setups
(In reply to comment #12) > It is my empirical observation both as a longtime Gentoo user and now as a > developer. ... > I have also seen the same observation echoed by several other Gentoo > developers. I won't dispute that it's a pervasive problem. In an effort to help reduce the scope of this problem, I open bugs when I run across instances of it. Your viewpoint seems to be that because this has been a pervasive problem for some time, nothing should be done to change it: individual instances of the problem should be disregarded. I don't want to put words into your mouth, so please correct me if I'm misinterpreting your comment. (In reply to comment #13) > In summary, we don't break updates from old systems intentionally, but > sometimes it can occur as it's impossible to test all setups No breakages are intentional. What is intentional is the response upon having one reported. In any case, I would think the benefits of making it as smooth and hassle-free as possible to upgrade to the latest versions would be obvious.
