The following code in the _global_ scope of cvs.eclass, is freaking evil. if [ "$ECVS_AUTH" == "ext" ]; then #default to ssh [ -z "$CVS_RSH" ] && export SSH_RSH="ssh" if [ "$CVS_RSH" != "ssh" ]; then die "Support for ext auth with clients other than ssh has not been implemented yet" fi DEPEND="$DEPEND net-misc/openssh" fi Why is it evil? Portage _cannot_ use any ebuilds affected by this, period. It bails during the depend phase, making the ebuild functionally invisible to portage (roughly). In other words, it's dead ebuilds in the tree. If this is an attempt to get people to upgrade, grepping the tree and picking off ebuilds in the list is the way to go, not this. Reproducible: Always Steps to Reproduce: rm -rf /var/cache/edb/dep/$(/usr/lib/portage/bin/portageq portdir)/gnustep-base emerge -s @gnustep-base Actual Results: !!! ERROR: gnustep-base/gnustep-back-xlib-0.9.5_pre20040928 failed. !!! Function source, Line 168, Exitcode 0 !!! Support for ext auth with clients other than ssh has not been implemented yet !!! If you need support, post the topmost build error, NOT this status message Fex. As I stated... a global die of this sort shouldn't be in the eclass. If you're attempting to change the eclass and phase out support (or phase it in), grepping the tree is proper, not this method.
Not that this is a gnustep related bug directly (though I 'package' date spec'd cvs pull style ebuilds for GNUstep packages from time-to-time) ... regardless, I cannot recreate the problem with the steps given in the bug report. Is there any other info you can supply to recreate this bug?
I run a modified portage, can't duplicate this with vanilla. Offhand, [ -z "$CVS_RSH" ] && export SSH_RSH="ssh" if [ "$CVS_RSH" != "ssh" ]; then die "Support for ext auth with clients other than ssh has not been implemented yet, CVS_RSH=$CVS_RSH" fi looks wrong. Why check cvs_rsh being empty, export SSH_RSH, and then bail upon CVS_RSH != ssh?
Haven't tracked down when it was added, but /etc/profile.env is src'd, which sets CVS_RSH="ssh" (kind of a weird thing, but neh). That was the critical difference. Still, the -z $CVS_RSH && export SSH_RSH=ssh; [ $CVS_RSH != ssh ] && die "blah" is a bit pointless, assuming that was a typo.
Ahhhh ... the /etc/profile.env src'ng may explain the access violations on /root/.cvspass I was getting on a fresh install, where I don't think it fails if it can't write to .cvspass, but the file must exist. I use userpriv/usersandbox a lot, and the symptoms went away. Now that root has a .cvpass after using cvs regularly, these symptoms also went away for -userpriv/-usersandbox. ...just more info.
So yeah... that check is horked, as I pointed out. Unless you were attempting something else I'm intendant on correcting that check in the near future...
blah
