Installing gtkmm-2.10.2 with -accessibility breaks any program that uses pkg-config to work out gtkmm deps: ciaranm@snowdrop ~ 0 0.18 $ pkg-config --libs gtkmm-2.4 Package atkmm-1.6 was not found in the pkg-config search path. Perhaps you should add the directory containing `atkmm-1.6.pc' to the PKG_CONFIG_PATH environment variable Package 'atkmm-1.6', required by 'gtkmm', not found
*** Bug 153392 has been marked as a duplicate of this bug. ***
*** Bug 153467 has been marked as a duplicate of this bug. ***
Reported upstream: http://bugzilla.gnome.org/show_bug.cgi?id=366930
*** Bug 153831 has been marked as a duplicate of this bug. ***
*** Bug 153886 has been marked as a duplicate of this bug. ***
*** Bug 154251 has been marked as a duplicate of this bug. ***
*** Bug 154583 has been marked as a duplicate of this bug. ***
*** Bug 155283 has been marked as a duplicate of this bug. ***
*** Bug 155571 has been marked as a duplicate of this bug. ***
*** Bug 155574 has been marked as a duplicate of this bug. ***
The gnome team hasn't done much yet to solve this. Maybe we should use for now a conditional patch like the one on the upstream tracker.. I'll see what I can do. Also, please include the keyword "atkmm" in the summary. This way lots of dups would be avoided. Something like "(...) breaks pkg-config (missing atkmm-1.6)" would do fine. Cheers, Renato
media-video/bmpx is using this, and so should other ebuilds having this problem I think. pkg_setup() { if has_version '>dev-cpp/gtkmm-2.10' &&! built_with_use dev-cpp/gtkmm accessibility; then die "You need to build dev-cpp/gtkmm with USE accessibility." fi }
That's a horrible solution. It'd involve updating nearly every ebuild that uses gtkmm, and it'd involve going through and removing all those hacks as soon as it's fixed.
*** Bug 155585 has been marked as a duplicate of this bug. ***
No no no! that solution is indeed awful. The problem is with gtkmm, so the solution should solve the problem and not the symptoms. I've solved the problem in gtkmm by simply applying John Laliberte's patch conditionaly. It works perfectly, but as said in the upstream bugzila, it should be solved using a var. That's what I'm doing now.
Created attachment 102265 [details] The corrected ebuild This ebuild works perfectly, but I'm finishing solving this upstream. This will be obsoleted as soon as I finish this.
Created attachment 102266 [details, diff] A simplified version of John Laliberte's patch The conditionally applied patch
Created attachment 102267 [details, diff] The patch to be submitted upstream Ok I've corrected it for good. Unfortunately I guess it would be difficult to use this patch on the ebuild, as it involves changing configure.in, which would then require the recreation of the configure script, etc.. too much headache. But the corrected ebuild above already solves the problem gentoo-wise, so it can be used until the upstream publishes the corrected distfile. No more bmpx-like hacks :) Can someone please submit this patch upstream? I don't have a gnome account.. cheers renato
Created attachment 102272 [details] gtkmm-2.10.2-r1.ebuild I've done a gtkmm-2.10.2-r1.ebuild with the corrections. It should be used before a new version of gtkmm comes out from upstream. Can this be put in cvs along with the gentoo patch (102266)? By the way, I have a question regarding it. There is SLOT="2.4" on the ebuild, but I don't understand why this is set to 2.4 and not 2.10 or just 2.0.. Cheers Renato
*** Bug 155599 has been marked as a duplicate of this bug. ***
*** Bug 155625 has been marked as a duplicate of this bug. ***
*** Bug 155596 has been marked as a duplicate of this bug. ***
Created attachment 102314 [details, diff] gtkmm-2.10.2-no_atk.patch an upstream patch can't be conditional. needs dev-cpp/cairomm dependency maybe: checking for PANGOMM... configure: error: Package requirements (glibmm-2.4 >= 2.12.1 cairomm-1.0 >= 1.1.12 pangocairo >= 1.5.2) were not met: No package 'cairomm-1.0' found
Created attachment 102315 [details, diff] gtkmm-2.10.2.ebuild.patch if you change configure.in you need to eautoconf
Daniel, your configure.in patch looks very similar to what I posted upstream yesterday. However, your updated src_unpack() should probably model the one from gnome2.eclass which has an added gnome2_omf_fix call inside. Other than that, it works for me.
(In reply to comment #25) > Created an attachment (id=102315) [edit] > gtkmm-2.10.2.ebuild.patch > > if you change configure.in you need to eautoconf > Yes, that's why I said to use John's patch instead of the mine for now.
new release in portage, when?
I'm ready to commit the patch I sent upstream but repoman shows gtkmm is broken on alpha, ppc64 and x86-fbsd. Flameeyes gave me the go order for x86-fbsd to keep the arch for now. Alpha and PPC64, gtkmm won't compile on your arches with or without the patch. Should I keep KEYWORDS as is? Thanks
*** Bug 155716 has been marked as a duplicate of this bug. ***
*** Bug 155768 has been marked as a duplicate of this bug. ***
*** Bug 155795 has been marked as a duplicate of this bug. ***
*** Bug 155806 has been marked as a duplicate of this bug. ***
*** Bug 155809 has been marked as a duplicate of this bug. ***
Ok folks, I've finally committed the patch. This is my first commit to portage so please please tell me if something fscks up. Alpha and PPC64, i've committed the revbumped ebuild without your two arches. Closing bug, please reopen if things go wrong. Thanks
*** Bug 155843 has been marked as a duplicate of this bug. ***
marked ppc64 stable
disregard my previous comment, adding ppc64 back in
Hm, this is still not fixed for me, I just synced at 2006-11-21 19:40 CET, recompiled gtkmm and I'm still getting this error: [...] checking pkg-config is at least version 0.9.0... yes checking for LIBGNOMEMM... configure: error: Package requirements (gtkmm-2.4 >= 2.4.0 libgnome-2.0 >= 2.6.0) were not met. Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively you may set the LIBGNOMEMM_CFLAGS and LIBGNOMEMM_LIBS environment variables to avoid the need to call pkg-config. See the pkg-config man page for more details. !!! Please attach the following file when filing a report to bugs.gentoo.org: !!! /var/tmp/portage/dev-cpp/libgnomemm-2.12.2/work/libgnomemm-2.12.2/config.log !!! ERROR: dev-cpp/libgnomemm-2.12.2 failed. Call stack: ebuild.sh, line 1568: Called dyn_compile ebuild.sh, line 937: Called src_compile libgnomemm-2.12.2.ebuild, line 30: Called gnome2_src_compile gnome2.eclass, line 63: Called gnome2_src_configure gnome2.eclass, line 59: Called econf '--enable-gtk-doc' ebuild.sh, line 540: Called die !!! econf failed !!! If you need support, post the topmost build error, and the call stack if relevant. What am I doing wrong?
ppc64: looks good now, dropping you from CC arm, ia64, sh: like alpha, gtkmm-2.10.2{,-r1} will refuse to build on your arches because of unkeyworded deps. If you guys could please keyword the following packages or drop yourselves from gtkmm : ~alpha >=dev-cpp/cairomm-1.1.12 ~arm >=dev-cpp/cairomm-1.1.12 >=dev-cpp/glibmm-2.12.1 ~ia64 >=dev-cpp/cairomm-1.1.12 ~sh >=dev-cpp/cairomm-1.1.12 >=dev-cpp/glibmm-2.12.1 Thanks
@Martin : This is not what this bug is about, if you could file another bug for it, providing all info emerge gives you. Thanks
> @Martin : > > This is not what this bug is about, if you could file another bug for it, > providing all info emerge gives you. Hm, weird. There was a bug report, bug #155596 , that has been marked as a duplicate of this one. So, what shall I do?
(In reply to comment #42) > > @Martin : > > > > This is not what this bug is about, if you could file another bug for it, > > providing all info emerge gives you. > > Hm, weird. There was a bug report, bug #155596 , that has been marked as a > duplicate of this one. So, what shall I do? > That bug was correctly identified as a dup of this one. It's different from yours. The problem here is (was) with gtkmm and not gnomemm. Please compare the error outputs.
Ok, thanks. Please excuse me for my error.
*** Bug 179750 has been marked as a duplicate of this bug. ***
Will gtkmm become ever stable?
