Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
K3B declares a dpendencies on an archaelogical revision of libglademm (2.2.0), which fails to emerge with a quickness. Error follows: make[2]: Entering directory `/var/tmp/portage/libglademm-2.2.0/work/libglademm-2.2.0/examples/basic' if x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../libglade -I../../libglade -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtkmm-2.0 -I/usr/lib/gtkmm-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/sigc++-1.2/include -I/usr/include/sigc++-1.2 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/atk-1.0 -I/usr/include/libglade-2.0 -I/usr/include/libxml2 -march=k8 -pipe -O2 -MT basic.o -MD -MP -MF ".deps/basic.Tpo" \ -c -o basic.o `test -f 'basic.cc' || echo './'`basic.cc; \ then mv -f ".deps/basic.Tpo" ".deps/basic.Po"; \ else rm -f ".deps/basic.Tpo"; exit 1; \ fi In file included from /usr/include/gtkmm-2.0/gtkmm/treeselection.h:31, from /usr/include/gtkmm-2.0/gtkmm/treeview.h:32, from /usr/include/gtkmm-2.0/gtkmm/fileselection.h:35, from /usr/include/gtkmm-2.0/gtkmm.h:60, from basic.cc:2: /usr/include/gtkmm-2.0/gtkmm/treepath.h: In member function `void Gtk::TreePath::append(In, In)': /usr/include/gtkmm-2.0/gtkmm/treepath.h:297: error: insufficient contextual information to determine type make[2]: *** [basic.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/libglademm-2.2.0/work/libglademm-2.2.0/examples/basic' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/libglademm-2.2.0/work/libglademm-2.2.0/examples' make: *** [all-recursive] Error 1 !!! ERROR: dev-cpp/libglademm-2.2.0 failed. the version of libglademm installed on this system is several revisions newer: * dev-cpp/libglademm Latest version available: 2.4.1 Latest version installed: 2.4.1 Size of downloaded files: 485 kB ... This emerge failure has been hanging around for a long time, and I guess nobody has reported it; my searching in the bugzilla db brought up seemingly related issues declared fixed months and months ago, but clearly this is ongoing. system is running kde 3.4.0, and gcc 3.4 Reproducible: Always Steps to Reproduce: 1. emerge k3b 2. build failure bringing in old libglademm 3. Actual Results: software fails to emerge, forcing us to use the deeply fusked up 'cdrecord-prodvd' tool, which claims it doesn't know how to burn a dvd when it isn't suggesting I use solaris instead. Expected Results: software should build and install on the system infiltrator ~ # emerge info Portage 2.0.51.22-r1 (default-linux/amd64/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-gentoo-r9 x86_64) ================================================================= System uname: 2.6.11-gentoo-r9 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.12 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.8 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.16 sys-devel/libtool: 1.5.18 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -pipe -O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/bind /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/init.d /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=k8 -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X aalib acpi adns alsa arts berkdb bitmap-fonts bonobo cdparanoia cdr crypt cups curl dvd eds fam flac font-server foomaticdb fortran gd gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile imagemagick imlib ipv6 jabber jack java jp2 jpeg junit kde ldap libwww lzw lzw-tiff mad maildir mikmod motif mozilla mp3 mpeg ncurses network nls odbc ogg opengl oss pam pda pdflib perl pic png postgres python qt readline ruby samba sdl slang speex ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts unicode usb userlocales vorbis xine xml xml2 xmms xpm xrandr xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS infiltrator ~ # gcc -v Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/specs Configured with: /var/tmp/portage/gcc-3.4.3.20050110-r2/work/gcc-3.4.3/configure --enable-version-specific-runtime-libs --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3-20050110 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.3-20050110 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.3-20050110/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.3-20050110/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/include/g++-v3 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --enable-multilib --disable-libgcj --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 3.4.3-20050110 (Gentoo 3.4.3.20050110-r2, ssp-3.4.3.20050110-0, pie-8.7.7)
You have a problem with libglademm, which is not a direct dependency of k3b.
what version(s) of gtkmm do you have installed ?
* dev-cpp/gtkmm Latest version available: 2.6.2 Latest version installed: 2.4.5
I've updated gtkmm, but trying to install k3b still seems to call in libglademm 2.2.0, which still fails to build.
well, i think i figured out your problem. because you are on ~amd64, you need cdrdao-1.1.9-r2 to compile k3b, cdrdao-1.1.9-r2 needs: =dev-cpp/libgnomeuimm-2.0.0 which needs: ( heres your error ) || ( =dev-cpp/libglademm-2.2* =dev-cpp/libglademm-2.0* ) which needs: =dev-cpp/gtkmm-2.2*, etc... and your back to k3b. thats why it wants that older version. therefore, i propose cdrdao should be updated so it can use the 2.6.0 version of libgnomeuimm. ( if that is possible )
well, I have a whole pile of stuff I'd like to burn off... think we could get those rdeps updated? thanks for looking into the bug. Brian
Quick workaround: Take out the gnome-USE-flag from cdrdao. I can't tell if cdrdao with the gnome-USE-flag enabled will build with newer vesions of the gtkmm libs. The README says this: The GnomeCDMaster GUI additionally requires the Gimp toolkit gtk+-1.2.8, recent Gnome libraries (e.g. gnome-libs-1.4.1.6) and the C++ bindings gtkmm-1.2.9 and gnomemm-1.2.2. The packages are available from www.gtk.org, www.gnome.org and www.sourceforge.net (project 'gtkmm'). You will need exactly the mentioned library version. With older or newer versions the GnomeCDMaster sources usually fail to compile. But we already build cdrdao with newer versions. So there may be a chance that it will build. I'm currently testing it on my machine.
Nope, gcdmaster, which is enabled with the gnome-use-flag, fails to build. It needs the 2.0-versions of gtkmm. So, if that problem with libglademm-2.2.0 is reproduceable on amd64, the team should mask that version. That means also that cdrdao will not be available on that architecture, unless a newer version will be released which can build with newer gtkmm-versions or the gnome-use-flag in cdrdao needs to be masked on amd64. I know there were some troubles with cdrdao and amd64 in the past, but I thought they are now resolved. amd64, please test and report.
well, for what it's worth, when I set: app-cdr/cdrdao -gnome in /etc/portage/package.use, I was able to emerge K3B, and I've just used it to burn a couple of iso images, which is a hell of a lot better'n what I was able to do /w cdrecord. ;) cdrdao appears to be functioning.. Brian
amd64 team: any update on this?
amd64: have a chance to test this?
cdrdao-1.2.0 is now stable on amd64 and compiles with newer versions of libglademm. I've masked libglademm-2.2.0 on amd64. Sorry for the delay, marking this fixed.
