Bugzilla Bug 153294

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. ***

*** 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 an attachment (id=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 an attachment (id=102266) [details]
A simplified version of John Laliberte's patch

The conditionally applied patch

Created an attachment (id=102267) [details]
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 an attachment (id=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 an attachment (id=102314) [details]
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 an attachment (id=102315) [details]
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] [details]
> 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?