I tried to do my daily update today and discovered two problems: portage insists on downgrading octave-2.1.57-r1 to octave-2.1.50, despite that 2.1.57-r1 is stable on amd64 and I'm using the -U flag. octave-2.1.50 doesn't compile Reproducible: Always Steps to Reproduce: 1. emerge -auUD world 2. 3. Actual Results: emerge -auUD world *** Warning: --upgradeonly is a deprecated option in portage-2.0.51-r3 *** and will likely be removed in a future version. These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild UD] sci-mathematics/octave-2.1.50 [2.1.57-r1] [ebuild U ] x11-libs/openmotif-2.1.30-r6 [2.1.30-r5] When saying Y compilation of octave fails: x86_64-pc-linux-gnu-g++ -c -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc -I../glob -I../glob -DHAVE_CONFIG_H -O2 CollocWt.cc -o pic/CollocWt.o In file included from MArray2.h:31, from dMatrix.h:30, from CollocWt.h:32, from CollocWt.cc:33: Array2.h: In constructor `Array2<T>::Array2(T*, int, int)': Array2.h:55: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available Array2.h:55: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) Array2.h: In constructor `Array2<T>::Array2()': Array2.h:71: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available Array2.h: In constructor `Array2<T>::Array2(int, int)': Array2.h:78: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available Array2.h: In constructor `Array2<T>::Array2(int, int, const T&)': Array2.h:85: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available Array2.h: In copy constructor `Array2<T>::Array2(const Array2<T>&)': Array2.h:92: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available Array2.h: In constructor `Array2<T>::Array2(const Array<LT>&, int, int)': Array2.h:99: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available In file included from MDiagArray2.h:31, from dMatrix.h:31, from CollocWt.h:32, from CollocWt.cc:33: DiagArray2.h: In constructor `DiagArray2<T>::DiagArray2(T*, int, int)': DiagArray2.h:120: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available DiagArray2.h: In constructor `DiagArray2<T>::DiagArray2()': DiagArray2.h:129: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available DiagArray2.h: In constructor `DiagArray2<T>::DiagArray2(int, int)': DiagArray2.h:136: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available DiagArray2.h: In constructor `DiagArray2<T>::DiagArray2(int, int, const T&)': DiagArray2.h:143: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available DiagArray2.h: In constructor `DiagArray2<T>::DiagArray2(const Array<LT>&)': DiagArray2.h:149: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available DiagArray2.h: In copy constructor `DiagArray2<T>::DiagArray2(const DiagArray2<T>&)': DiagArray2.h:156: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available In file included from dMatrix.h:31, from CollocWt.h:32, from CollocWt.cc:33: MDiagArray2.h: In member function `MDiagArray2<T>::operator MArray2<T>() const':MDiagArray2.h:79: error: there are no arguments to `xelem' that depend on a template parameter, so a declaration of `xelem' must be available x86_64-pc-linux-gnu-g++ -c -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc -I../glob -I../glob -DHAVE_CONFIG_H -O2 DASPK.cc -o pic/DASPK.o make[2]: *** [pic/CollocWt.o] Error 1 make[2]: *** Waiting for unfinished jobs.... In file included from ./MArray2.h:31, from ./dMatrix.h:30, from ./base-de.h:29, from ./base-dae.h:26, from ./DAE.h:27, from DASPK-opts.h:10, from DASPK.h:33, from DASPK.cc:34: ./Array2.h: In constructor `Array2<T>::Array2(T*, int, int)': ./Array2.h:55: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available ./Array2.h:55: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) ./Array2.h: In constructor `Array2<T>::Array2()': ./Array2.h:71: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available ./Array2.h: In constructor `Array2<T>::Array2(int, int)': ./Array2.h:78: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available ./Array2.h: In constructor `Array2<T>::Array2(int, int, const T&)': ./Array2.h:85: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available ./Array2.h: In copy constructor `Array2<T>::Array2(const Array2<T>&)': ./Array2.h:92: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available ./Array2.h: In constructor `Array2<T>::Array2(const Array<LT>&, int, int)': ./Array2.h:99: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available In file included from ./MDiagArray2.h:31, from ./dMatrix.h:31, from ./base-de.h:29, from ./base-dae.h:26, from ./DAE.h:27, from DASPK-opts.h:10, from DASPK.h:33, from DASPK.cc:34: ./DiagArray2.h: In constructor `DiagArray2<T>::DiagArray2(T*, int, int)': ./DiagArray2.h:120: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available ./DiagArray2.h: In constructor `DiagArray2<T>::DiagArray2()': ./DiagArray2.h:129: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available ./DiagArray2.h: In constructor `DiagArray2<T>::DiagArray2(int, int)': ./DiagArray2.h:136: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available ./DiagArray2.h: In constructor `DiagArray2<T>::DiagArray2(int, int, const T&)': ./DiagArray2.h:143: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available ./DiagArray2.h: In constructor `DiagArray2<T>::DiagArray2(const Array<LT>&)': ./DiagArray2.h:149: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available ./DiagArray2.h: In copy constructor `DiagArray2<T>::DiagArray2(const DiagArray2<T>&)': ./DiagArray2.h:156: error: there are no arguments to `set_max_indices' that depend on a template parameter, so a declaration of `set_max_indices' must be available In file included from ./dMatrix.h:31, from ./base-de.h:29, from ./base-dae.h:26, from ./DAE.h:27, from DASPK-opts.h:10, from DASPK.h:33, from DASPK.cc:34: ./MDiagArray2.h: In member function `MDiagArray2<T>::operator MArray2<T>() const': ./MDiagArray2.h:79: error: there are no arguments to `xelem' that depend on a template parameter, so a declaration of `xelem' must be available make[2]: *** [pic/DASPK.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/octave-2.1.50/work/octave-2.1.50/liboctave' make[1]: *** [liboctave] Error 2 make[1]: Leaving directory `/var/tmp/portage/octave-2.1.50/work/octave-2.1.50' make: *** [all] Error 2 Expected Results: It should leave octave alone. emerge info Portage 2.0.51-r3 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r12 x86_64) ================================================================= System uname: 2.6.9-gentoo-r12 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.8.1-r2 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O2" CHOST="x86_64-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /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/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox" GENTOO_MIRRORS="http://gentoo.nedlinux.nl http://ftp.easynet.nl/mirror/gentoo/ http://gentoo.mirror.sdv.fr http://gentoo.math.bme.hu" 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 acpi alsa arts berkdb bitmap-fonts bonobo cdr crypt doc dvd dvdr emul-linux-x86 esd f77 fam flac font-server fortran gdbm gif gnome gpm gstreamer gtk gtkhtml guile imagemagick imlib ipv6 java jp2 jpeg junit kde ldap libwww lm-sensors lzw lzw-tiff mad mikmod motif mozilla multilib mysql ncurses nls oggvorbis opengl oss pam pda pdflib perl png postgres python qt readline samba sdl slang ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts usb userlocales xml xml2 xmms xpm xrandr xv zlib"
Peter: _Don't_use_-U_! It breaks your system and is deprected.
The same thing happened to my PC. Octave 2.1.57-r1 gets downgraded to 50 and then upgraded back to 57 again! In fact it all started yesterday (17th Jan). This may have something to do with a stable x86 octave-forge which was also installed on my machine. I discovered that uninstalling octave-forge, for which the unstable version had a keyword ~amd64 added on the 17th Jan!) fixes the problem. After uninstalling octave-forge I did emerge -puDv world and portage said it needed to install both octave 2.1.50 and 2.1.57-r1 (both at the same time!) I then installed octave (emerge unmerge octave) and then installed octave from fresh. Portage installed octave 2.1.57-r1 and did not attempt to downgrade it later when I checked it with "emerge -puDv world". So in my case the quick fix was to unmerge octave-forge and octave, check that there were no missing dependencies by running " revdep-rebuild -pv " and then emerge octave again.
The problem is that current stable octave-forge does not work with octave > .50 - use unstable octave-forge, unmerge octave-forge or live with ancient octave, these are the only alternatives I see.
I too noticed that portage wants to downgrade octave, also I haven't let do it this. I first digged somewhat into the possible reasons of this, as 2.0.57-r1 has been stable for about 6 weeks at least (I installed this release on December, 2nd) May the problem be this line? DEPEND=">=sci-mathematics/octave-2.1.40 <=sci-mathematics/octave-2.1.57 from the (stable) octave-forge-2004.02.12.ebuild? Shouldn't read this <=sci-mathematics/octave-2.1.57-r1, or even better <sci-mathematics/octave-2.1.58? The ChangeLog of octave-forge says that the DEPEND has been updated as of 17th of January. So I suppose this is not a problem with octave/octave-forge and/or stable/unstable but this is a bug of the ebuild introduced yesterday. Were there any problems with 2004.02.12 release? I discovered none so far and updated octave-forge on December 15th for the last time. I ran on x86 platform, and here my emerge info: Gentoo Base System version 1.4.16 Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.10-ck4-udev-ipv6m i686) ================================================================= System uname: 2.6.10-ck4-udev-ipv6m i686 Intel(R) Pentium(R) 4 CPU 2.40GHz ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r6,sys-devel/autoconf-2.13 Automake: sys-devel/automake-1.8.5-r2,sys-devel/automake-1.5,sys-devel/automake-1.4_p6,sys-devel/automake-1.6.3,sys-devel/automake-1.7.9,sys-devel/automake-1.9.4 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r2 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -fforce-addr -mfpmath=sse -mmmx -msse -msse2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -fforce-addr -mfpmath=sse -mmmx -msse -msse2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg candy ccache collision-protect distlocks fixpackages nostrip sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp.gentoo.mesh-solutions.com/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/mnt/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/portage-de" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib accessibility acl acpi aim alsa apache2 arts avi berkdb bitmap-fonts crypt cscope cups dedicated doc dvd encode esd exif fam flac font-server foomaticdb fortran gdbm ggi gif gnome gpm gstreamer gtk2 hal icq jabber jack java joystick jpeg junit libwww linguas_de mad maildir mikmod mmx mmx2 motif mpeg mpi msn ncurses nls nptl odbc offensive oggvorbis openal opengl oscar oss pam pic pie png ppds pwdb python qt quicktime readline samba sdl shared slang spell sqlite sse ssl svg svga sysvipc tcpd tetex tiff truetype truetype-fonts type1-fonts unicode usb videos x86 xml xml2 xmms xprint yahoo zlib"
Unmerging octave-forge stops portage from downgrading octave. We still have a compilation problem for octave-2.1.50 on my (amd64) machine.
Well why dont mark the ebuild as ~amd64 instead. Like I said, I'm using x86 and run octave-2.1.57-r1 since December, 2nd and octave-forge-2004.02.12 since December, 15th without any problems. So it is really strange to me. If there are problems with the amd64 platform, then changes to the ebuilds should IMHO only affect this platform and not all platforms in general. I will not uninstall octave-forge. Like I said before, IMHO this is a bug in the ebuild that was introduced yesterday. Before doing this I will mask octave version less than 2.1.57-r1 to ensure it goes not downgraded.
Sorry, Bernd, that was clearly my fault. I accidently did only include .57, but not .57-r1 in the range of allowed octave versions for this octave-forge version. Using <.64 instead now. My comment #3 is nonsense. Will have to address the amd64 problem, though. So, Peter, .50 is broken for amd64?
As far as I can see octave-2.1.50 is broken on amd64 with gcc-3.4.3. Still fails with the same compilation errors.
Could the amd64 team please adjust the KEYWORDS accordingly?
2.1.57-r1 is stable for a while
