Mailing List Archive

I was able to get past this issue by using the attached patch that I
created (hopefully it stays attached during distribution to the list).
I'm running ~ Firefox 7 with this and the engine works.

For anyone else that might struggle with the issue (until such time that
this patch or similar get applied to the official kde-sunset repo), you
can do the following:

1. In your kde-sunset repo copy (by default these days it would be in
/var/lib/layman/kde-sunset), go to the x11-themes/gtk-engines-qt
directory.

2. Copy the current .ebuild file to a new .ebuild, changing the r<X> to
your own version number, higher than the official version, e.g. r99.
Complete example:
/var/lib/layman/kde-sunset/x11-themes/gtk-engines-qt $ cp
gtk-engines-qt-0.8-r4.ebuild gtk-engines-qt-0.8-r99.ebuild

3. Put the attached patch into the files subdirectory. You can rename
it if you like.

4. Edit the new .ebuild file created in step 2. In the PATCHES=
section, before the closing ")", add a new line following the format of
the previous line. The new line should read
"${FILESDIR}/undef_signals_cpp.patch" (or if you decided to rename the
patch, use your chosen filename). Save and exit.

5. Legitimize the ebuild in the eyes of Portage. At the command-line
and still in the gtk-engines-qt dir, run "ebuild
gtk-engines-qt-0.8-r99.ebuild digest" .

6. Now when you "emerge gtk-engines-qt", it should pick up your new
local version and proceed successfully through compilation. If not,
perhaps the original ebuild was marked as testing (0.8-r4 is stable as
of this writing, so this was not an issue for me), in which case you can
keyword the package.

7. Remember that a sync operation can blow away these files. Back up at
least your .ebuild and patch file. You may want to be more aggressive,
and backup the whole
/var/lib/layman/kde-sunset/x11-themes/gtk-engines-qt directory as well.

I disclaim copyright on the patch since it's so trivial.

V. Ram.

On Thursday, October 13, 2011 3:06 PM, "V. Ram" <vramml0@fastmail.fm>
wrote:
> I finally got KDE 3.5.10 built and installed, after keywording kdelibs,
> kcontrol, gdk-pixbuf, and libpng. Revdep-rebuild appears to have done
> the trick with the upgrade to libpng.
>
> Now I'm trying to install gtk-engines-qt, whose build fails with the
> indicated error:
>
> In file included from /usr/include/glib-2.0/gio/gio.h:54:0,
> from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
> from /usr/include/gtk-2.0/gdk/gdk.h:32,
> from /usr/include/gtk-2.0/gdk/gdkprivate.h:30,
> from /usr/include/gtk-2.0/gdk/gdkx.h:30,
> from
> /tmp/portage/x11-themes/gtk-engines-qt-0.8-r4/work/gtk-qt-engine/src/qt_qt_wrapper.cpp:18:
> /usr/include/glib-2.0/gio/gdbusintrospection.h: At global scope:
> /usr/include/glib-2.0/gio/gdbusintrospection.h:151:25: error: expected
> unqualified-id before ‘protected’
> /usr/include/glib-2.0/gio/gdbusintrospection.h:151:25: error: expected
> ‘;’ before ‘protected’
>
> The system glib is 2.28.8 and gtk+ is at 2.24.4 .
>
> I think this may be due to a conflicting use of the keyword "signals"
> between Qt and GLib (or gtk).
>
> Nokia (for now) has a guide on what to do about this:
>
> http://www.developer.nokia.com/Community/Wiki/How_to_prevent_symbol_collisions_between_GTK%2B_and_Qt
>
> There are a couple of bug reports along similar lines in the Debian bug
> tracker:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627016
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614436
>
> kde-sunset devs: could you please address this in a subsequent rev of
> the theming engine package?
>
> Thank you very much.

--
http://www.fastmail.fm - Choose from over 50 domains or use your own

V. Ram wrote:
> I was able to get past this issue by using the attached patch that I
> created (hopefully it stays attached during distribution to the list).
> I'm running ~ Firefox 7 with this and the engine works.
>
> For anyone else that might struggle with the issue (until such time that
> this patch or similar get applied to the official kde-sunset repo), you
> can do the following:
>
> 1. In your kde-sunset repo copy (by default these days it would be in
> /var/lib/layman/kde-sunset), go to the x11-themes/gtk-engines-qt
> directory.
>
> 2. Copy the current .ebuild file to a new .ebuild, changing the r<X> to
> your own version number, higher than the official version, e.g. r99.
> Complete example:
> /var/lib/layman/kde-sunset/x11-themes/gtk-engines-qt $ cp
> gtk-engines-qt-0.8-r4.ebuild gtk-engines-qt-0.8-r99.ebuild
>
> 3. Put the attached patch into the files subdirectory. You can rename
> it if you like.
>
> 4. Edit the new .ebuild file created in step 2. In the PATCHES=
> section, before the closing ")", add a new line following the format of
> the previous line. The new line should read
> "${FILESDIR}/undef_signals_cpp.patch" (or if you decided to rename the
> patch, use your chosen filename). Save and exit.
>
> 5. Legitimize the ebuild in the eyes of Portage. At the command-line
> and still in the gtk-engines-qt dir, run "ebuild
> gtk-engines-qt-0.8-r99.ebuild digest" .
>
> 6. Now when you "emerge gtk-engines-qt", it should pick up your new
> local version and proceed successfully through compilation. If not,
> perhaps the original ebuild was marked as testing (0.8-r4 is stable as
> of this writing, so this was not an issue for me), in which case you can
> keyword the package.
>
> 7. Remember that a sync operation can blow away these files. Back up at
> least your .ebuild and patch file. You may want to be more aggressive,
> and backup the whole
> /var/lib/layman/kde-sunset/x11-themes/gtk-engines-qt directory as well.
>
> I disclaim copyright on the patch since it's so trivial.
>
> V. Ram.
>

Maybe one of the kde sunset guys can apply the fix to the overlay too.
Then everyone can use it without any hacking.

I suspect this will be done too. They are good at this sort of thing.

Dale

:-) :-)