It seems subversion 1.2 doesn't support neon-0.25 yet: (confirmed with some op in #svn) aw php # svn up svn: Unrecognized URL scheme for 'http://svn.gnqs.org/svn/gentoo-php-overlay/for-portage' Downgrading neon to 0.24 and remerging subversion fixes it. Reproducible: Always Steps to Reproduce: 1. emerge =neon-0.25.3 2. 3. Portage 2.0.51.22-r2 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r1, 2.6.12-gentoo-r7 x86_64) ================================================================= System uname: 2.6.12-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.12.0_pre6 ccache version 2.4 [enabled] dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O3 -pipe -ffast-math" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/kde/devel/env /usr/kde/devel/share/config /usr/kde/devel/shutdown /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -O3 -pipe -ffast-math" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks multilib-strict prelink sfperms strict" GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo http://gentoo.ccccom.com http://gentoo.osuosl.org" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/overlays/php /usr/local/overlays/kde-live /usr/local/overlays/bmg-main /usr/local/portage" SYNC="rsync://rsync5.us.gentoo.org/gentoo-portage/" USE="amd64 X aalib alsa apache2 avi bash-completion bitmap-fonts bzip2 cairo cdb cdr crypt cups curl dvd dvdr dvdread eds encode ffmpeg firefox flac foomaticdb freetype gamin gdbm gif glitz gnome gpm gstreamer gtk gtk2 hal howl imagemagick imlib java jpeg jpg kde kdeenablefinal kernel_linux libwww lzw lzw-tiff mad matroska mikmod motif mozilla mp3 mpeg mpeg4 ncurses nls nptl nptlonly offensive ogg oggvorbis opengl oss pam pcre pdflib perl php png postgres python qt quicktime readline real ruby samba sdl spell sqlite ssl subversion svg tcpd theora tiff truetype truetype-fonts type1-fonts unicode usb userlocales vhosts vorbis xine xinerama xml xml2 xpm xv zlib" Unset: ASFLAGS, CTARGET, LDFLAGS, LINGUAS
ra_dav doesn't build with neon-0.25 Reproducible: Always Steps to Reproduce: 1. emerge =neon-0.25.3 2. emerge subversion 3. svn --version Output: svn, version 1.2.3 (r15833) compiled Sep 11 2005, 22:55:34 Copyright (C) 2000-2005 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme Expected output: svn, version 1.2.3 (r15833) compiled Sep 11 2005, 22:55:34 Copyright (C) 2000-2005 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme
Yep, subversion does not like the new neon here as well.
The problem is that ebuild checks ">=net-misc/neon-0.24.7", however the configure script for subversion has the version string hardcoded to "0.24.7" I suspect that the subversion configure script is probably too restrictive with the check. If the configure script can not be changed, then the ebuild will have to match the version requirement more strictly - i.e "=net-misc/neon-0.24.7"
I've changed the ebuild to specifically depend on 0.24.7
*** Bug 105727 has been marked as a duplicate of this bug. ***
*** Bug 105803 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > I've changed the ebuild to specifically depend on 0.24.7 I'm not sure if this will fix the problem. On ~ systems, neon will be updated to 0.25.3 anyway when doing emerge -uD world. Can it be package.mask'd?
(In reply to comment #7) > I'm not sure if this will fix the problem. On ~ systems, neon will be updated to > 0.25.3 anyway when doing emerge -uD world. Not for me, the newer neon dependency might come from another package or you included it in /var/lib/portage/world
(In reply to comment #8) > (In reply to comment #7) > > > I'm not sure if this will fix the problem. On ~ systems, neon will be updated to > > 0.25.3 anyway when doing emerge -uD world. > Not for me, the newer neon dependency might come from another package or you > included it in /var/lib/portage/world World file doesn't contain version info. Masking =net-misc/neon-0.25.3 myself causes no errors, so no other packages are depending on that version. emerge --update --deep will cause deps like neon to upgrade.
(In reply to comment #9) > World file doesn't contain version info. True, but if net-misc/neon is in your world file, portage will try to update it to the latest version.
Well, as long as subversion doesn't work with neon 0.25.3 , and it isn't package.mask'ed, this bug shouldn't be marked as fixed (we are getting several bug reports on this, since people have the upgrade/downgrade cycle problem). The way I see it, we have two options: 1: package.mask neon 0.25.3 2: fix subversion to work with it, or get a newer version of subversion. I personaly like option 1 best, but thats just my 0.2$
This issue is fixed in 1.3.0 RC, but mostly likely won't be backported to 1.2.x; also upstream does not seem particularly happy about shipping RC versions, so we should p.mask neon until 1.3.0 final is out.
The world file may actually contain version info. But I see no reason why it should be there in the first place. I'm adding Daniel Black to the bug as I don't know why he added 0.25.3 in the first place. I don't like to break things just to help people who put neon in their world files.
Isn't the real problem that portage wants to update (neon-0.25) and remove a the older version (neon-0.24.7) that is a dependency of a current package (subversion)? I'm thinking this should be blocked in the portage logic. Sure a package.mask will work in the interim but its not fixing the problem. When I added neon-0.25 I didn't anticipate this problem so my apologies to all concerned.
OK, subversion-1.3.0_rc4 confirmed working with neon-0.25.3, so I guess this bug can be closed again. Just please don't mark neon stable before the new subversion. ;)
Ok, I close the bug now. Please be aware though that I won't mark the rc stable at any point (it still is a rc).
