[gentoo-dev] New cvs.eclass

[gentoo-dev] New cvs.eclass

[Dan Armak]

[-- Attachment #1.1: body text --]
[-- Type: text/plain, Size: 2956 bytes --]

Hello everyone,

I've rewritten cvs.eclass. I'll test all cvs euilds once again now and then 
commit the new eclass and ebuilds if noone objects. Extra testing from anyone 
else welcome.

Attached are the new eclass, and kde-source.eclass which had to be slightly 
modified to match. A new kde-cvs tarball that works with the new 
cvs.eclass is at http://cvs.gentoo.org/~danarmak/kde-cvs-20030418.tar.gz.

Changes to the eclass:
- General fixes for many cases, even if noone seemed to be having problems 
except for me. This didn't start out as a cleanup...

- It is now much smaller and cleaner and easy to read and understand.

- No longer uses the pexpect package with inline python to log in.

- Explicitly deprecates ext auth support. This was claimed to be supported 
before, but never actually worked. There is no ebuild in portage that uses 
ext instead of pserver; if you have one and want ext auh to work, lpease send 
me your ebuild to test against.

- Transfers some logic from the eclass code to cvs itself. Therefore virtual 
cvs modules are now transparently supported (in at least some cases), this 
enables the php-cvs ebuild to work (soon to be submitted on bugzilla by 
coredumb).

Changes people writing cvs ebuilds want to know about:

- ECVS_RUNAS, running everything under su to a specified user, does not work. 
I am not sure how well it worked before. In any case it is impossible to do 
in portage's userpriv mode AFAIK, unless the administrator gave the portage 
user the right to su or sudo to that user without benig prompted for a 
password. I may implement this again before committing, mostly for 
non-userpriv mode (especially if people ask me to ;-).

- ECVS_ANON is deprecated. From the cvs POV there is always a password, even 
if it's empty. So if you want the previous "anonymous login" behaviour, just 
leave things alone and the default values of ECVS_USER="anonymous", 
ECVS_PASS="" should work.

- ECVS_SUBDIR is deprecated. Instead you can now specify subdirectories like 
this: ECVS_MODULE="dir/dir/dir..."

- ECVS_AUTH=ext is deprecated and will make the eclass die.

- ECVS_CVS_OPTIONS doesn't exist anymore since update and checkout give 
different meaning to the same parameters, such as -P. So now there are 
separate ECVS_UP_OPTS, ECVS_CO_OPTS vars for update and checkout parameters 
respectively. (Because I moved some logic to cvs as said above, I now do real 
cvs checkout when needed, not just a fake cvs update.)

These ebuilds set the deprecated variables ECVS_ANON and/or ECVS_CVS_OPTIONS, 
these settings can be safely removed (I went over the ebuilds and it should 
be OK): app-editors/emacs-cvs, dev-perl/Common, dev-python/twisted-cvs, 
net-www/galeon-cvs, sys-libs/ldetect-lst, sys-libs/ldetect.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key



[-- Attachment #1.2: cvs.eclass --]
[-- Type: text/plain, Size: 10230 bytes --]

# Copyright 1999-2003 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# $Header: /home/cvsroot/gentoo-x86/eclass/cvs.eclass,v 1.35 2003/04/17 09:05:03 cretin Exp $
#
# Author Dan Armak <danarmak@gentoo.org>
#
# This eclass provides the generic cvs fetching functions.
# to use from an ebuild, set the 'ebuild-configurable settings' below in your ebuild before inheriting.
# then either leave the default src_unpack or extend over cvs_src_unpack.
# if you find that you need to call the cvs_* functions directly, i'd be interested to hear about it.

ECLASS=cvs
INHERITED="$INHERITED $ECLASS"

# You shouldn't change these settings yourself! The ebuild/eclass inheriting this eclass
# will take care of that. If you want to set the global KDE cvs ebuilds' settings,
# see the comments in kde-source.eclass.

# --- begin ebuild-configurable settings

# cvs command to run. you can set fex. "cvs -t" for extensive debug information
# on the cvs onnection. the default of "cvs -q -f -z4" means to be quiet, to disregard
# the ~/.cvsrc config file and to use maximum compression.
[ -z "$ECVS_CVS_COMMAND" ] && ECVS_CVS_COMMAND="cvs -q -f -z4"

# cvs options given after the cvs command (update or checkout)
# don't remove -dP from update or things won't work
[ -z "$ECVS_UP_OPTS" ] && ECVS_UP_OPTS="-dP"
[ -z "$ECVS_CO_OPTS" ] && ECVS_CO_OPTS=""

# set this to some value for the module/subdir to be fetched non-recursively: ECVS_LOCAL

# Where the cvs modules are stored/accessed
[ -z "$ECVS_TOP_DIR" ] && ECVS_TOP_DIR="${DISTDIR}/cvs-src"

# Name of cvs server, set to "offline" to disable fetching
# (i.e. to assume module is checked out already and don't update it).
# Format is server:/dir e.g. "anoncvs.kde.org:/home/kde". remove the other
# parts of the full CVSROOT (which looks like
# ":pserver:anonymous@anoncvs.kde.org:/home/kde"); these are added from
# other settings
# the special value 'offline' disables fetching, assumes sources are alread in ECVS_TOP_DIR
[ -z "$ECVS_SERVER" ] && ECVS_SERVER="offline"

# Authentication method to use - possible values are "pserver" and "ext"
# WARNING ext is NOT supported! (never was, despite what earlier version of this file said)
[ -z "$ECVS_AUTH" ] && ECVS_AUTH="pserver"
[ "$ECVS_AUTH" == ext ] && die "ERROR: ext auth not supported. If you want it, please contact danarmak@gentoo.org."

# Use su to run cvs as user
# Currently b0rked and wouldn't work with portage userpriv anyway without special magic
# [ -z "$ECVS_RUNAS" ] && ECVS_RUNAS="`whoami`"

# Username to give to the server
[ -z "$ECVS_USER" ] && ECVS_USER="anonymous"

# Password to use
[ -z "$ECVS_PASS" ] && ECVS_PASS=""

# Module to be fetched, must be set when kde_src_unpack is called
# can include several directory levels, ie foo/bar/baz
#[ -z "$ECVS_MODULE" ] && die "$ECLASS: error: ECVS_MODULE not set, cannot continue"

# Branch/tag to use, default is HEAD
# the following default _will_ reset your branch checkout to head if used
#[ -z "$ECVS_BRANCH" ] && ECVS_BRANCH="HEAD"

# deprecated - do not use
[ -n "$ECVS_SUBDIR" ] && die "ERROR: deprecated ECVS_SUBDIR defined. Please fix this ebuild."

# --- end ebuild-configurable settings ---

# add cvs to deps
# ssh is used for ext auth
# sudo is used to run as a specified user
DEPEND="$DEPEND dev-util/cvs app-admin/sudo"
#[ "$ECVS_AUTH" == "ext" ] && DEPEND="$DEPEND net-misc/openssh"

# calls cvs_contorl, is called from cvs_src_unpack
cvs_fetch() {

	debug-print-function $FUNCNAME $*

	# parameters modifying other parameters that should be effective every time cvs_prep is called, and not
	# just every time cvs.eclas is inherited
	# 1. parameter for local (non-recursive) fetching
	if [ -n "$ECVS_LOCAL" ]; then
		ECVS_UP_OPTS="$ECVS_UP_OPTS -l"
		ECVS_CO_OPTS="$ECVS_CO_OPTS -l"
	fi
	# 2. cvs auto-switches branches, we just have to pass the correct -rBRANCH option to it when updating.
	# doing it this way we get multiple -rX options - harmless afaik
	if [ -n "$ECVS_BRANCH" ]; then
		ECVS_UP_OPTS="$ECVS_UP_OPTS -r$ECVS_BRANCH"
		ECVS_CO_OPTS="$ECVS_CO_OPTS -r$ECVS_BRANCH"
	fi

	# it's easiest to always be in "run-as mode", logic-wise
	# or would be if sudo didn't ask for a password even when sudo'ing to `whoami`
	if [ -z "$ECVS_RUNAS" ]; then
		run=""
	else
		run="sudo -u $ECVS_RUNAS"
	fi

	# create the top dir if needed
	if [ ! -d "$ECVS_TOP_DIR" ]; then
		# note that the addwrite statements in this block are only there to allow creating ECVS_TOP_DIR;
		# we've already allowed writing inside it
		# this is because it's simpler than trying to find out the parent path of the directory, which
		# would need to be the real path and not a symlink for things to work (so we can't just remove
		# the last path element in the string)
		debug-print "$FUNCNAME: checkout mode. creating cvs directory"
		addwrite /foobar
		addwrite /
		$run mkdir -p "/$ECVS_TOP_DIR"
		export SANDBOX_WRITE="${SANDBOX_WRITE//:\/foobar:\/}"
	fi

	# in case ECVS_TOP_DIR is a symlink to a dir, get the real dir's path,
	# otherwise addwrite() doesn't work.
	cd -P "$ECVS_TOP_DIR" > /dev/null
	ECVS_TOP_DIR="`/bin/pwd`"

	# determine checkout or update mode
	if [ ! -d "$ECVS_TOP_DIR/$ECVS_MODULE/CVS" ]; then
		mode=checkout
	else
		mode=update
	fi

	# disable the sandbox for this dir
	addwrite "$ECVS_TOP_DIR"

	# chowning the directory and all contents
	if [ -n "$ECVS_RUNAS" ]; then
		$run chown -R "$ECVS_RUNAS" "/$ECVS_TOP_DIR"
	fi

	# our server string (aka CVSHOST), without the password so it can be put in Root
	server=":${ECVS_AUTH}:${ECVS_USER}@${ECVS_SERVER}"

	# switch servers automagically if needed
	if [ "$mode" == "update" ]; then
		cd /$ECVS_TOP_DIR/$ECVS_MODULE
		oldserver="`$run cat CVS/Root`"
		if [ "$server" != "$oldserver" ]; then

			einfo "Changing CVS server from $oldserver to $server:"
			debug-print "$FUNCNAME: Changing CVS server from $oldserver to $server:"

			einfo "Searching for CVS dirs..."
			cvsdirs="`$run find . -iname CVS -print`"
			debug-print "$FUNCNAME: CVS dirs found:"
			debug-print "$cvsdirs"

			einfo "Modifying CVS dirs..."
			for x in $cvsdirs; do
				debug-print "In $x"
				$run echo "$server" > "$x/Root"
			done

		fi
	fi

	# the server string with the password in it
	# needed for mode=update too as we may not be inside ECVS_MODULE but only inside ECVS_TOP_DIR
	# however putting the password in in update mode can break (?)
	if [ "$mode" == "checkout" ]; then
		export CVSROOT=":${ECVS_AUTH}:${ECVS_USER}:${ECVS_PASS}@${ECVS_SERVER}"
	else
		export CVSROOT=":${ECVS_AUTH}:${ECVS_USER}@${ECVS_SERVER}"
	fi

	# prepare a cvspass file just for this session, we don't want to mess with ~/.cvspass
	touch "${T}/cvspass"
	export CVS_PASSFILE="${T}/cvspass"
	if [ -n "$ECVS_RUNAS" ]; then
		chown "$ECVS_RUNAS" "${T}/cvspass"
	fi

	# commands to run
	cmdupdate="${run} ${ECVS_CVS_COMMAND} update ${ECVS_UP_OPTS} ${ECVS_MODULE}"
	cmdcheckout="${run} ${ECVS_CVS_COMMAND} checkout ${ECVS_CO_OPTS} ${ECVS_MODULE}"

	cd "${ECVS_TOP_DIR}"
	if [ "${ECVS_AUTH}" == "pserver" ]; then
		if [ "${mode}" == "update" ]; then
			$cmdupdate
		elif [ "${mode}" == "checkout" ]; then
			$cmdcheckout
		fi
#	elif [ "${ECVS_AUTH}" == "ext" ]; then
#		# for ext there's also a possible ssh prompt, code not yet written
#		echo "${ECVS_DELAY} continue connecting&yes" >> "$instruct"
#		echo "${ECVS_DELAY} CVS password:&${ECVS_PASS}" >> "$instruct"
#		if [ "$mode" == "update" ]; then
#			expect "$cvsout" "$instruct" | $cmdupdate > "$cvsout"
#		elif [ "$mode" == "checkout" ]; then
#			expect "$cvsout" "$instruct" | $cmdcheckout > "$cvsout"
#		fi
	fi

	# restore ownership. not sure why this is needed, but someone added it in the orig ECVS_RUNAS stuff.
	if [ -n "$ECVS_RUNAS" ]; then
		chown `whoami` "${T}/cvspass"
	fi

}


cvs_src_unpack() {

	debug-print-function $FUNCNAME $*

	debug-print "$FUNCNAME: init:
ECVS_CVS_COMMAND=$ECVS_CVS_COMMAND
ECVS_UP_OPTS=$ECVS_UP_OPTS
ECVS_CO_OPTS=$ECVS_CO_OPTS
ECVS_TOP_DIR=$ECVS_TOP_DIR
ECVS_SERVER=$ECVS_SERVER
ECVS_USER=$ECVS_USER
ECVS_PASS=$ECVS_PASS
ECS_MODULE=$ECVS_MODULE
ECVS_LOCAL=$ECVS_LOCAL
ECVS_RUNAS=$ECVS_RUNAS"

	[ -z "$ECVS_MODULE" ] && die "ERROR: CVS module not set, cannot continue."

	if [ "$ECVS_SERVER" == "offline" ]; then
		# we're not required to fetch anything, the module already exists and shouldn't be updated
	 		if [ -d "${ECVS_TOP_DIR}/${ECVS_MODULE}" ]; then
			debug-print "$FUNCNAME: offline mode, exiting"
			return 0
		else
			debug-print "$FUNCNAME: offline mode specified but module/subdir not found, exiting with error"
			die "ERROR: Offline mode specified, but module/subdir checkout not found. Aborting."
		fi
	elif [ -n "$ECVS_SERVER" ]; then # ECVS_SERVER!=offline --> real fetching mode
		einfo "Fetching cvs module $ECVS_MODULE into $ECVS_TOP_DIR..."
		cvs_fetch
	else	# ECVS_SERVER not set
		die "ERROR: CVS server not set, cannot continue."
	fi

	einfo "Copying $ECVS_MODULE from $ECVS_TOP_DIR..."
	debug-print "Copying module $ECVS_MODULElocal_mode=$ECVS_LOCAL from $ECVS_TOP_DIR..."

	# probably redundant, but best to make sure
	mkdir -p "$WORKDIR/$ECVS_MODULE"

	if [ -n "$ECVS_LOCAL" ]; then
		mkdir -p "$WORKDIR/$ECVS_MODULE"
		cp -f "$ECVS_TOP_DIR/$ECVS_MODULE"/* "$WORKDIR/$ECVS_MODULE"
	else
		cp -Rf "$ECVS_TOP_DIR/$ECVS_MODULE" "$WORKDIR/$ECVS_MODULE/.."
	fi

	# if the directory is empty, remove it; empty directories cannot exist in cvs.
	# this happens when fex. kde-source requests module/doc/subdir which doesn't exist.
	# still create the empty directory in workdir though.
	if [ "`ls -A \"${ECVS_TOP_DIR}/${ECVS_MODULE}\"`" == "CVS" ]; then
		debug-print "$FUNCNAME: removing cvs-empty directory $ECVS_MODULE"
		rm -rf "${ECVS_TOP_DIR}/${ECVS_MODULE}"
	fi

	# implement some of base_src_unpack's functionality;
	# note however that base.eclass may not have been inherited!
	if [ -n "$PATCHES" ]; then
		debug-print "$FUNCNAME: PATCHES=$PATCHES, S=$S, autopatching"
		cd "$S"
		for x in $PATCHES; do
			debug-print "patching from $x"
			patch -p0 < "$x"
		done
		# make sure we don't try to apply patches more than once, since
		# cvs_src_unpack is usually called several times from e.g. kde-source_src_unpack
		export PATCHES=""
	fi

}

EXPORT_FUNCTIONS src_unpack

[-- Attachment #1.3: kde-source.eclass --]
[-- Type: text/x-diff, Size: 4338 bytes --]

# Copyright 1999-2003 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# $Header: /home/cvsroot/gentoo-x86/eclass/kde-source.eclass,v 1.14 2003/04/08 17:48:12 danarmak Exp $
#
# Author Dan Armak <danarmak@gentoo.org>
#
# This is for kde-base cvs ebuilds. Read comments about settings.
# It uses $S and sets $SRC_URI, so inherit it as late as possible (certainly after any other eclasses).
# See http://www.gentoo.org/~danarmak/kde-cvs.html !
# All of the real functionality is in cvs.eclass; this just adds some trivial kde-specific items

ECLASS=kde-source
INHERITED="$INHERITED $ECLASS"

# --- begin user-configurable settings ---

# Set yours in profile (e.g. make.conf), or export from the command line to override.
# Most have acceptable default values or are set by the ebuilds, but be sure to read the comments
# in cvs.eclass for detailed descriptions of them all.
# You should probably set at least ECVS_SERVER.

# TODO: add options to store the modules as tarballs in $DISTDIR or elsewhere

# Under this directory the cvs modules are stored/accessed
# Storing in tarballs in $DISTDIR to be implemented soon
[ -z "$ECVS_TOP_DIR" ] && ECVS_TOP_DIR="$DISTDIR/cvs-src/kde"

# Set to name of cvs server. Set to "" to disable fetching (offline mode).
# In offline mode, we presume that modules are already checked out at the specified
# location and that they shouldn't be updated.
# Format example: "anoncvs.kde.org:/home/kde" (without :pserver:anonymous@ part)
# Mirror list is available at http://developer.kde.org/source/anoncvs.html
[ -z "$ECVS_SERVER" ] && ECVS_SERVER="anoncvs.kde.org:/home/kde"
[ -z "$ECVS_AUTH" ] && ECVS_AUTH="pserver"

# ECVS_SUBDIR reimplementation
if [ -n "$KCVS_SUBDIR" ]; then
    ECVS_MODULE="$KCVS_MODULE/$KCVS_SUBDIR"
	S="$WORKDIR/$KCVS_MODULE"
elif [ -n "$KCVS_MODULE" ]; then
    ECVS_MODULE="$KCVS_MODULE"
	S="$WORKDIR/$KCVS_MODULE"
else
    # default for kde-base ebuilds
    ECVS_MODULE="$PN"
	S="$WORKDIR/$ECVS_MODULE"
fi

# Other variables: see cvs.eclass

# we do this here and not in the very beginning because we need to keep
# the configuration order intact: env. and profile settings override
# kde-source.eclass defaults, which in turn override cvs.eclass defaults
inherit cvs
#... and reset $ECLASS. Ugly I know, hopefully I can prettify it someday
ECLASS=kde-source

# --- end user-configurable settings ---

DESCRIPTION="$DESCRIPTION (cvs) "

# set this to more easily maintain cvs and std ebuilds side-by-side
# (we don't need to remove SRC_URI, kde-dist.eclass, kde.org.eclass etc
# from the cvs ones). To download patches or something, set SRC_URI again after
# inheriting kde_source.
SRC_URI=""

kde-source_src_unpack() {

	debug-print-function $FUNCNAME $*

	cvs_src_unpack

	# subdirs of kde modules get special treatment that is designed for
	# subdirs which are separate selfcontained apps and only need
	# automake/autoconf stuff etc. added to them.
	# this fits for apps from kdenonbeta, kdeextragear modules etc.
	# So, if we just fetched a module's subdir, fetch the top directory
	# of the module (non-recursively) and make it build only the subdirectory
	# we need
	if [ -n "$KCVS_SUBDIR" ]; then

		ECVS_MODULE="$KCVS_MODULE" ECVS_LOCAL=yes cvs_src_unpack

		# we need the <module>/doc/<name> directory too,
		# and we need the top-level doc/ directory fetched locally
		ECVS_MODULE="${KCVS_MODULE}/doc" ECVS_LOCAL=yes cvs_src_unpack
		# but, if such a directory doesn't exist on the cvs server and we're
		# in offline mode cvs.eclass will abort, so only call this if we're
		# in online mode or the dir is already fetched
		if [ -d "$ECVS_TOP_DIR/$KCVS_MODULE/doc/$KCVS_SUBDIR" -o "$ECVS_SERVER" != "offline" ]; then
			ECVS_MODULE="${KCVS_MODULE}/doc/${KCVS_SUBDIR}" cvs_src_unpack
		fi

	fi

	# typically for kde cvs, the admin subdir lives in the kde-common module
	# which is also needed
	if [ ! -d "$S/admin" ]; then
		ECVS_MODULE="kde-common/admin" cvs_src_unpack
		IFS2="$IFS"
		IFS="/"
		path=""
		for x in $ECVS_MODULE; do
			[ -z "$path" ] && path="$x"
		done
		IFS="$IFS2"
		mv ${WORKDIR}/kde-common/admin $WORKDIR/$path
	fi

	# make sure we give them a clean cvs checkout
	cd ${S}
	[ -f "Makefile" ] && make -f Makefile.cvs cvs-clean
	[ -f "config.cache" ] && rm config.cache

}


EXPORT_FUNCTIONS src_unpack


[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [gentoo-core] New cvs.eclass

[Dan Armak]

[-- Attachment #1.1: body text --]
[-- Type: text/plain, Size: 346 bytes --]

The gpg sig on my orig message turned out bad for some reason. I want to 
reassure everyone, the message is genuine. Hope the sig on this one is OK :-)

Attaching the files again to have them signed again.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key

[-- Attachment #1.2: cvs.eclass --]
[-- Type: text/plain, Size: 10230 bytes --]

# Copyright 1999-2003 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# $Header: /home/cvsroot/gentoo-x86/eclass/cvs.eclass,v 1.35 2003/04/17 09:05:03 cretin Exp $
#
# Author Dan Armak <danarmak@gentoo.org>
#
# This eclass provides the generic cvs fetching functions.
# to use from an ebuild, set the 'ebuild-configurable settings' below in your ebuild before inheriting.
# then either leave the default src_unpack or extend over cvs_src_unpack.
# if you find that you need to call the cvs_* functions directly, i'd be interested to hear about it.

ECLASS=cvs
INHERITED="$INHERITED $ECLASS"

# You shouldn't change these settings yourself! The ebuild/eclass inheriting this eclass
# will take care of that. If you want to set the global KDE cvs ebuilds' settings,
# see the comments in kde-source.eclass.

# --- begin ebuild-configurable settings

# cvs command to run. you can set fex. "cvs -t" for extensive debug information
# on the cvs onnection. the default of "cvs -q -f -z4" means to be quiet, to disregard
# the ~/.cvsrc config file and to use maximum compression.
[ -z "$ECVS_CVS_COMMAND" ] && ECVS_CVS_COMMAND="cvs -q -f -z4"

# cvs options given after the cvs command (update or checkout)
# don't remove -dP from update or things won't work
[ -z "$ECVS_UP_OPTS" ] && ECVS_UP_OPTS="-dP"
[ -z "$ECVS_CO_OPTS" ] && ECVS_CO_OPTS=""

# set this to some value for the module/subdir to be fetched non-recursively: ECVS_LOCAL

# Where the cvs modules are stored/accessed
[ -z "$ECVS_TOP_DIR" ] && ECVS_TOP_DIR="${DISTDIR}/cvs-src"

# Name of cvs server, set to "offline" to disable fetching
# (i.e. to assume module is checked out already and don't update it).
# Format is server:/dir e.g. "anoncvs.kde.org:/home/kde". remove the other
# parts of the full CVSROOT (which looks like
# ":pserver:anonymous@anoncvs.kde.org:/home/kde"); these are added from
# other settings
# the special value 'offline' disables fetching, assumes sources are alread in ECVS_TOP_DIR
[ -z "$ECVS_SERVER" ] && ECVS_SERVER="offline"

# Authentication method to use - possible values are "pserver" and "ext"
# WARNING ext is NOT supported! (never was, despite what earlier version of this file said)
[ -z "$ECVS_AUTH" ] && ECVS_AUTH="pserver"
[ "$ECVS_AUTH" == ext ] && die "ERROR: ext auth not supported. If you want it, please contact danarmak@gentoo.org."

# Use su to run cvs as user
# Currently b0rked and wouldn't work with portage userpriv anyway without special magic
# [ -z "$ECVS_RUNAS" ] && ECVS_RUNAS="`whoami`"

# Username to give to the server
[ -z "$ECVS_USER" ] && ECVS_USER="anonymous"

# Password to use
[ -z "$ECVS_PASS" ] && ECVS_PASS=""

# Module to be fetched, must be set when kde_src_unpack is called
# can include several directory levels, ie foo/bar/baz
#[ -z "$ECVS_MODULE" ] && die "$ECLASS: error: ECVS_MODULE not set, cannot continue"

# Branch/tag to use, default is HEAD
# the following default _will_ reset your branch checkout to head if used
#[ -z "$ECVS_BRANCH" ] && ECVS_BRANCH="HEAD"

# deprecated - do not use
[ -n "$ECVS_SUBDIR" ] && die "ERROR: deprecated ECVS_SUBDIR defined. Please fix this ebuild."

# --- end ebuild-configurable settings ---

# add cvs to deps
# ssh is used for ext auth
# sudo is used to run as a specified user
DEPEND="$DEPEND dev-util/cvs app-admin/sudo"
#[ "$ECVS_AUTH" == "ext" ] && DEPEND="$DEPEND net-misc/openssh"

# calls cvs_contorl, is called from cvs_src_unpack
cvs_fetch() {

	debug-print-function $FUNCNAME $*

	# parameters modifying other parameters that should be effective every time cvs_prep is called, and not
	# just every time cvs.eclas is inherited
	# 1. parameter for local (non-recursive) fetching
	if [ -n "$ECVS_LOCAL" ]; then
		ECVS_UP_OPTS="$ECVS_UP_OPTS -l"
		ECVS_CO_OPTS="$ECVS_CO_OPTS -l"
	fi
	# 2. cvs auto-switches branches, we just have to pass the correct -rBRANCH option to it when updating.
	# doing it this way we get multiple -rX options - harmless afaik
	if [ -n "$ECVS_BRANCH" ]; then
		ECVS_UP_OPTS="$ECVS_UP_OPTS -r$ECVS_BRANCH"
		ECVS_CO_OPTS="$ECVS_CO_OPTS -r$ECVS_BRANCH"
	fi

	# it's easiest to always be in "run-as mode", logic-wise
	# or would be if sudo didn't ask for a password even when sudo'ing to `whoami`
	if [ -z "$ECVS_RUNAS" ]; then
		run=""
	else
		run="sudo -u $ECVS_RUNAS"
	fi

	# create the top dir if needed
	if [ ! -d "$ECVS_TOP_DIR" ]; then
		# note that the addwrite statements in this block are only there to allow creating ECVS_TOP_DIR;
		# we've already allowed writing inside it
		# this is because it's simpler than trying to find out the parent path of the directory, which
		# would need to be the real path and not a symlink for things to work (so we can't just remove
		# the last path element in the string)
		debug-print "$FUNCNAME: checkout mode. creating cvs directory"
		addwrite /foobar
		addwrite /
		$run mkdir -p "/$ECVS_TOP_DIR"
		export SANDBOX_WRITE="${SANDBOX_WRITE//:\/foobar:\/}"
	fi

	# in case ECVS_TOP_DIR is a symlink to a dir, get the real dir's path,
	# otherwise addwrite() doesn't work.
	cd -P "$ECVS_TOP_DIR" > /dev/null
	ECVS_TOP_DIR="`/bin/pwd`"

	# determine checkout or update mode
	if [ ! -d "$ECVS_TOP_DIR/$ECVS_MODULE/CVS" ]; then
		mode=checkout
	else
		mode=update
	fi

	# disable the sandbox for this dir
	addwrite "$ECVS_TOP_DIR"

	# chowning the directory and all contents
	if [ -n "$ECVS_RUNAS" ]; then
		$run chown -R "$ECVS_RUNAS" "/$ECVS_TOP_DIR"
	fi

	# our server string (aka CVSHOST), without the password so it can be put in Root
	server=":${ECVS_AUTH}:${ECVS_USER}@${ECVS_SERVER}"

	# switch servers automagically if needed
	if [ "$mode" == "update" ]; then
		cd /$ECVS_TOP_DIR/$ECVS_MODULE
		oldserver="`$run cat CVS/Root`"
		if [ "$server" != "$oldserver" ]; then

			einfo "Changing CVS server from $oldserver to $server:"
			debug-print "$FUNCNAME: Changing CVS server from $oldserver to $server:"

			einfo "Searching for CVS dirs..."
			cvsdirs="`$run find . -iname CVS -print`"
			debug-print "$FUNCNAME: CVS dirs found:"
			debug-print "$cvsdirs"

			einfo "Modifying CVS dirs..."
			for x in $cvsdirs; do
				debug-print "In $x"
				$run echo "$server" > "$x/Root"
			done

		fi
	fi

	# the server string with the password in it
	# needed for mode=update too as we may not be inside ECVS_MODULE but only inside ECVS_TOP_DIR
	# however putting the password in in update mode can break (?)
	if [ "$mode" == "checkout" ]; then
		export CVSROOT=":${ECVS_AUTH}:${ECVS_USER}:${ECVS_PASS}@${ECVS_SERVER}"
	else
		export CVSROOT=":${ECVS_AUTH}:${ECVS_USER}@${ECVS_SERVER}"
	fi

	# prepare a cvspass file just for this session, we don't want to mess with ~/.cvspass
	touch "${T}/cvspass"
	export CVS_PASSFILE="${T}/cvspass"
	if [ -n "$ECVS_RUNAS" ]; then
		chown "$ECVS_RUNAS" "${T}/cvspass"
	fi

	# commands to run
	cmdupdate="${run} ${ECVS_CVS_COMMAND} update ${ECVS_UP_OPTS} ${ECVS_MODULE}"
	cmdcheckout="${run} ${ECVS_CVS_COMMAND} checkout ${ECVS_CO_OPTS} ${ECVS_MODULE}"

	cd "${ECVS_TOP_DIR}"
	if [ "${ECVS_AUTH}" == "pserver" ]; then
		if [ "${mode}" == "update" ]; then
			$cmdupdate
		elif [ "${mode}" == "checkout" ]; then
			$cmdcheckout
		fi
#	elif [ "${ECVS_AUTH}" == "ext" ]; then
#		# for ext there's also a possible ssh prompt, code not yet written
#		echo "${ECVS_DELAY} continue connecting&yes" >> "$instruct"
#		echo "${ECVS_DELAY} CVS password:&${ECVS_PASS}" >> "$instruct"
#		if [ "$mode" == "update" ]; then
#			expect "$cvsout" "$instruct" | $cmdupdate > "$cvsout"
#		elif [ "$mode" == "checkout" ]; then
#			expect "$cvsout" "$instruct" | $cmdcheckout > "$cvsout"
#		fi
	fi

	# restore ownership. not sure why this is needed, but someone added it in the orig ECVS_RUNAS stuff.
	if [ -n "$ECVS_RUNAS" ]; then
		chown `whoami` "${T}/cvspass"
	fi

}


cvs_src_unpack() {

	debug-print-function $FUNCNAME $*

	debug-print "$FUNCNAME: init:
ECVS_CVS_COMMAND=$ECVS_CVS_COMMAND
ECVS_UP_OPTS=$ECVS_UP_OPTS
ECVS_CO_OPTS=$ECVS_CO_OPTS
ECVS_TOP_DIR=$ECVS_TOP_DIR
ECVS_SERVER=$ECVS_SERVER
ECVS_USER=$ECVS_USER
ECVS_PASS=$ECVS_PASS
ECS_MODULE=$ECVS_MODULE
ECVS_LOCAL=$ECVS_LOCAL
ECVS_RUNAS=$ECVS_RUNAS"

	[ -z "$ECVS_MODULE" ] && die "ERROR: CVS module not set, cannot continue."

	if [ "$ECVS_SERVER" == "offline" ]; then
		# we're not required to fetch anything, the module already exists and shouldn't be updated
	 		if [ -d "${ECVS_TOP_DIR}/${ECVS_MODULE}" ]; then
			debug-print "$FUNCNAME: offline mode, exiting"
			return 0
		else
			debug-print "$FUNCNAME: offline mode specified but module/subdir not found, exiting with error"
			die "ERROR: Offline mode specified, but module/subdir checkout not found. Aborting."
		fi
	elif [ -n "$ECVS_SERVER" ]; then # ECVS_SERVER!=offline --> real fetching mode
		einfo "Fetching cvs module $ECVS_MODULE into $ECVS_TOP_DIR..."
		cvs_fetch
	else	# ECVS_SERVER not set
		die "ERROR: CVS server not set, cannot continue."
	fi

	einfo "Copying $ECVS_MODULE from $ECVS_TOP_DIR..."
	debug-print "Copying module $ECVS_MODULElocal_mode=$ECVS_LOCAL from $ECVS_TOP_DIR..."

	# probably redundant, but best to make sure
	mkdir -p "$WORKDIR/$ECVS_MODULE"

	if [ -n "$ECVS_LOCAL" ]; then
		mkdir -p "$WORKDIR/$ECVS_MODULE"
		cp -f "$ECVS_TOP_DIR/$ECVS_MODULE"/* "$WORKDIR/$ECVS_MODULE"
	else
		cp -Rf "$ECVS_TOP_DIR/$ECVS_MODULE" "$WORKDIR/$ECVS_MODULE/.."
	fi

	# if the directory is empty, remove it; empty directories cannot exist in cvs.
	# this happens when fex. kde-source requests module/doc/subdir which doesn't exist.
	# still create the empty directory in workdir though.
	if [ "`ls -A \"${ECVS_TOP_DIR}/${ECVS_MODULE}\"`" == "CVS" ]; then
		debug-print "$FUNCNAME: removing cvs-empty directory $ECVS_MODULE"
		rm -rf "${ECVS_TOP_DIR}/${ECVS_MODULE}"
	fi

	# implement some of base_src_unpack's functionality;
	# note however that base.eclass may not have been inherited!
	if [ -n "$PATCHES" ]; then
		debug-print "$FUNCNAME: PATCHES=$PATCHES, S=$S, autopatching"
		cd "$S"
		for x in $PATCHES; do
			debug-print "patching from $x"
			patch -p0 < "$x"
		done
		# make sure we don't try to apply patches more than once, since
		# cvs_src_unpack is usually called several times from e.g. kde-source_src_unpack
		export PATCHES=""
	fi

}

EXPORT_FUNCTIONS src_unpack

[-- Attachment #1.3: kde-source.eclass --]
[-- Type: text/x-diff, Size: 4338 bytes --]

# Copyright 1999-2003 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# $Header: /home/cvsroot/gentoo-x86/eclass/kde-source.eclass,v 1.14 2003/04/08 17:48:12 danarmak Exp $
#
# Author Dan Armak <danarmak@gentoo.org>
#
# This is for kde-base cvs ebuilds. Read comments about settings.
# It uses $S and sets $SRC_URI, so inherit it as late as possible (certainly after any other eclasses).
# See http://www.gentoo.org/~danarmak/kde-cvs.html !
# All of the real functionality is in cvs.eclass; this just adds some trivial kde-specific items

ECLASS=kde-source
INHERITED="$INHERITED $ECLASS"

# --- begin user-configurable settings ---

# Set yours in profile (e.g. make.conf), or export from the command line to override.
# Most have acceptable default values or are set by the ebuilds, but be sure to read the comments
# in cvs.eclass for detailed descriptions of them all.
# You should probably set at least ECVS_SERVER.

# TODO: add options to store the modules as tarballs in $DISTDIR or elsewhere

# Under this directory the cvs modules are stored/accessed
# Storing in tarballs in $DISTDIR to be implemented soon
[ -z "$ECVS_TOP_DIR" ] && ECVS_TOP_DIR="$DISTDIR/cvs-src/kde"

# Set to name of cvs server. Set to "" to disable fetching (offline mode).
# In offline mode, we presume that modules are already checked out at the specified
# location and that they shouldn't be updated.
# Format example: "anoncvs.kde.org:/home/kde" (without :pserver:anonymous@ part)
# Mirror list is available at http://developer.kde.org/source/anoncvs.html
[ -z "$ECVS_SERVER" ] && ECVS_SERVER="anoncvs.kde.org:/home/kde"
[ -z "$ECVS_AUTH" ] && ECVS_AUTH="pserver"

# ECVS_SUBDIR reimplementation
if [ -n "$KCVS_SUBDIR" ]; then
    ECVS_MODULE="$KCVS_MODULE/$KCVS_SUBDIR"
	S="$WORKDIR/$KCVS_MODULE"
elif [ -n "$KCVS_MODULE" ]; then
    ECVS_MODULE="$KCVS_MODULE"
	S="$WORKDIR/$KCVS_MODULE"
else
    # default for kde-base ebuilds
    ECVS_MODULE="$PN"
	S="$WORKDIR/$ECVS_MODULE"
fi

# Other variables: see cvs.eclass

# we do this here and not in the very beginning because we need to keep
# the configuration order intact: env. and profile settings override
# kde-source.eclass defaults, which in turn override cvs.eclass defaults
inherit cvs
#... and reset $ECLASS. Ugly I know, hopefully I can prettify it someday
ECLASS=kde-source

# --- end user-configurable settings ---

DESCRIPTION="$DESCRIPTION (cvs) "

# set this to more easily maintain cvs and std ebuilds side-by-side
# (we don't need to remove SRC_URI, kde-dist.eclass, kde.org.eclass etc
# from the cvs ones). To download patches or something, set SRC_URI again after
# inheriting kde_source.
SRC_URI=""

kde-source_src_unpack() {

	debug-print-function $FUNCNAME $*

	cvs_src_unpack

	# subdirs of kde modules get special treatment that is designed for
	# subdirs which are separate selfcontained apps and only need
	# automake/autoconf stuff etc. added to them.
	# this fits for apps from kdenonbeta, kdeextragear modules etc.
	# So, if we just fetched a module's subdir, fetch the top directory
	# of the module (non-recursively) and make it build only the subdirectory
	# we need
	if [ -n "$KCVS_SUBDIR" ]; then

		ECVS_MODULE="$KCVS_MODULE" ECVS_LOCAL=yes cvs_src_unpack

		# we need the <module>/doc/<name> directory too,
		# and we need the top-level doc/ directory fetched locally
		ECVS_MODULE="${KCVS_MODULE}/doc" ECVS_LOCAL=yes cvs_src_unpack
		# but, if such a directory doesn't exist on the cvs server and we're
		# in offline mode cvs.eclass will abort, so only call this if we're
		# in online mode or the dir is already fetched
		if [ -d "$ECVS_TOP_DIR/$KCVS_MODULE/doc/$KCVS_SUBDIR" -o "$ECVS_SERVER" != "offline" ]; then
			ECVS_MODULE="${KCVS_MODULE}/doc/${KCVS_SUBDIR}" cvs_src_unpack
		fi

	fi

	# typically for kde cvs, the admin subdir lives in the kde-common module
	# which is also needed
	if [ ! -d "$S/admin" ]; then
		ECVS_MODULE="kde-common/admin" cvs_src_unpack
		IFS2="$IFS"
		IFS="/"
		path=""
		for x in $ECVS_MODULE; do
			[ -z "$path" ] && path="$x"
		done
		IFS="$IFS2"
		mv ${WORKDIR}/kde-common/admin $WORKDIR/$path
	fi

	# make sure we give them a clean cvs checkout
	cd ${S}
	[ -f "Makefile" ] && make -f Makefile.cvs cvs-clean
	[ -f "config.cache" ] && rm config.cache

}


EXPORT_FUNCTIONS src_unpack


[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [gentoo-core] New cvs.eclass

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 448 bytes --]

Sorry... for some reason when I sign messages with files attached the sig 
becomes bad. Maybe something's wrong with kmail.

Anyway, this one has nothing attached and so should be signed OK. I'll put the 
files up at htttp://cvs.gentoo.org/~danarmak/{cvs,kde-source}.eclass.

Sorry for all the posting...

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [gentoo-core] New cvs.eclass

[Peter Ruskin]

On Friday 18 Apr 2003 15:21, Dan Armak wrote:
> Sorry... for some reason when I sign messages with files attached the
> sig becomes bad. Maybe something's wrong with kmail.

Dan, your signature was fine here for all 3 emails.

Peter
-- 
Gentoo-1.4.2.8 Stable. KDE: 3.1.1a Qt: 3.1.2
AMD Athlon(tm) XP 2200+ 768MB.	Kernel: 2.4.20-xfs-r2.	GCC 3.2.2


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] New cvs.eclass

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 602 bytes --]

On Friday 18 April 2003 14:27, Peter Ruskin wrote:
> On Friday 18 Apr 2003 15:21, Dan Armak wrote:
> > Sorry... for some reason when I sign messages with files attached the
> > sig becomes bad. Maybe something's wrong with kmail.
> 
> Dan, your signature was fine here for all 3 emails.

Then it was probably kmail thinking it was bad for some reason... Maybe the 
infamous whitespace/underscore bug again, though I haven't seen it for a long 
time now.


-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [gentoo-core] New cvs.eclass

[Norberto BENSA]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 496 bytes --]

nbensa@venkman ~ $ date ; echo ${Dan Armak}
Friday 18 April 2003 11:21 am

> Sorry... for some reason when I sign messages with files attached the sig
> becomes bad. Maybe something's wrong with kmail.
>

Because you are using kmail 1.5.1!!! Downgrade to 1.5 and you'll be fine...

That's the reason I haven't upgrade to kde 3.1.1 yet. There's another bug with 
signatures affecting all kmail versions when using pgp pluging AND imap, but 
I can live with it.

Regards.
Norberto


[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [gentoo-core] New cvs.eclass

[Norberto BENSA]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 424 bytes --]

nbensa@venkman ~ $ date ; echo ${John Ziniti}
Friday 18 April 2003 04:40 pm

> Possibly -- I don't know what the kmail bug is, but with Mozilla 1.3, your
> first two emails were "gpg: BAD SIGNATURE" and the third one was
> fine.

The third is fine 'cos it doesn't have attachments... It's a bug in kmail 
1.5.1. Follow the discussion at:

http://lists.kde.org/?l=kmail&m=104794107903309&w=2

Regards,
Norberto

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [gentoo-core] New cvs.eclass

[John Ziniti]

Dan Armak wrote:

>On Friday 18 April 2003 14:27, Peter Ruskin wrote:
>  
>
>>On Friday 18 Apr 2003 15:21, Dan Armak wrote:
>>    
>>
>>>Sorry... for some reason when I sign messages with files attached the
>>>sig becomes bad. Maybe something's wrong with kmail.
>>>      
>>>
>>Dan, your signature was fine here for all 3 emails.
>>    
>>
>
>Then it was probably kmail thinking it was bad for some reason... Maybe the 
>infamous whitespace/underscore bug again, though I haven't seen it for a long 
>time now.
>
>  
>
Possibly -- I don't know what the kmail bug is, but with Mozilla 1.3, your
first two emails were "gpg: BAD SIGNATURE" and the third one was
fine.

Just my $0.02,

JZ


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New cvs.eclass

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 522 bytes --]

On Friday 18 April 2003 14:11, Dan Armak wrote:
> Hello everyone,
> 
> I've rewritten cvs.eclass. I'll test all cvs euilds once again now and then 
> commit the new eclass and ebuilds if noone objects. Extra testing from 
anyone 
> else welcome.

No objections recieved and everything tests out ok. I'll commit it in a few 
minutes, and update the kde-cvs page accordingly.


-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New cvs.eclass

[Alexander Futasz]

On Fri, 18 Apr 2003 14:11:48 +0000, Dan Armak wrote:
> I've rewritten cvs.eclass. I'll test all cvs euilds once again now and
> then commit the new eclass and ebuilds if noone objects. Extra testing
> from anyone else welcome.

> - ECVS_RUNAS, running everything under su to a specified user, does
> not work. I am not sure how well it worked before. In any case it is
> impossible to do in portage's userpriv mode AFAIK, unless the
> administrator gave the portage user the right to su or sudo to that
> user without benig prompted for a password. I may implement this again
> before committing, mostly for non-userpriv mode (especially if people
> ask me to ;-).

Does that mean ebuilds using the cvs.eclass wont work with userpriv and
usersandbox?

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] New cvs.eclass

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 775 bytes --]

On Friday 18 April 2003 17:30, Norberto BENSA wrote:
> nbensa@venkman ~ $ date ; echo ${Dan Armak}
> Friday 18 April 2003 11:21 am
> 
> > Sorry... for some reason when I sign messages with files attached the sig
> > becomes bad. Maybe something's wrong with kmail.
> >
> 
> Because you are using kmail 1.5.1!!! Downgrade to 1.5 and you'll be fine...
> 
> That's the reason I haven't upgrade to kde 3.1.1 yet. There's another bug 
with 
> signatures affecting all kmail versions when using pgp pluging AND imap, but 
> I can live with it.

I've looked up the diff in kde cvs and am making a kdenetwork-3.1.1-r1 with 
it.


-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New cvs.eclass

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1370 bytes --]

On Saturday 19 April 2003 17:50, Alexander Futasz wrote:
> On Fri, 18 Apr 2003 14:11:48 +0000, Dan Armak wrote:
> > I've rewritten cvs.eclass. I'll test all cvs euilds once again now and
> > then commit the new eclass and ebuilds if noone objects. Extra testing
> > from anyone else welcome.
> 
> > - ECVS_RUNAS, running everything under su to a specified user, does
> > not work. I am not sure how well it worked before. In any case it is
> > impossible to do in portage's userpriv mode AFAIK, unless the
> > administrator gave the portage user the right to su or sudo to that
> > user without benig prompted for a password. I may implement this again
> > before committing, mostly for non-userpriv mode (especially if people
> > ask me to ;-).
> 
> Does that mean ebuilds using the cvs.eclass wont work with userpriv and
> usersandbox?

No, it only means the special ECVS_RUNAS feature doesn't work with userpriv. 

This isn't a feature ebuilds use, it's something you can use to make 
cvs.eclass chown its checked-out files to the user specified via $ECVS_RUNAS. 
If you don't use it, you don't need to worry.

Again, this didn't really work before either, it's just the the eclass claimed 
it to work :-)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New cvs.eclass

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 519 bytes --]

On Saturday 19 April 2003 21:40, Dan Armak wrote:
> Again, this didn't really work before either, it's just the the eclass 
claimed 
> it to work :-)

Um, correction - it didn't work before in userpriv mode. Right now it doesn't 
work at all, I disabled its code. The best way to get me to spend the needed 
testing time to re-enable it is to tell me you actually use it :-)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New cvs.eclass

[Chris Smith]

On Sunday 20 April 2003 02:04, Dan Armak wrote:
> On Friday 18 April 2003 14:11, Dan Armak wrote:
> > Hello everyone,
> >
> > I've rewritten cvs.eclass. I'll test all cvs euilds once again now and
> > then commit the new eclass and ebuilds if noone objects. Extra testing
> > from
>
> anyone
>
> > else welcome.
>
> No objections recieved and everything tests out ok. I'll commit it in a few
> minutes, and update the kde-cvs page accordingly.

Hi Dan,

When I try and emerge the CVS Kopete (using your latest ebuilds) I get this 
output here:

--snip--
chris local # PORTDIR_OVERLAY=/usr/local/portage emerge kopete
Calculating dependencies ...done!
>>> emerge (1 of 1) net-im/kopete-5 to /
>>> Unpacking source...
 * Running cvs -q -f -z4 update -dP with anoncvs.kde.org:/home/kde for 
kopete/...
cvsro server: cannot open directory /home/kde/kopete: No such file or 
directory
cvsro server: skipping directory
 * Copying kopete/ from /usr/portage/distfiles/cvs-src/kde...
/usr/sbin/ebuild.sh: line 126: cd: //usr/portage/distfiles/cvs-src/kde/kopete: 
No such file or directory
 * Running cvs -q -f -z4 update -dP with anoncvs.kde.org:/home/kde for 
kde-common/admin...
U ChangeLog
U Doxyfile.am
U Doxyfile.global
U Makefile.common
U acinclude.m4.in
U am_edit
U compile
U conf.change.pl
U config.guess
U config.pl
U config.sub
U configure.in.bot.end
U configure.in.min
U cvs-clean.pl
U cvs.sh
U debianrules
U depcomp
U detect-autoconf.sh
U install-sh
U libtool.m4.in
U ltmain.sh
U missing
U mkinstalldirs
U nmcheck
U ylwrap
 * Copying kde-common/admin from /usr/portage/distfiles/cvs-src/kde...
>>> Source unpacked.
grep: Makefile.am: No such file or directory
*** Creating aclocal.m4
aclocal: `configure.ac' or `configure.in' is required
make: *** [cvs] Error 1

!!! ERROR: net-im/kopete-5 failed.
!!! Function kde_src_compile, Line 107, Exitcode 1
!!! no configure script found, generation unsuccessful
--snip--

Any Ideas? To state the obvious, it's looking in /home/kde on the CVS server 
for some reason, which is why it would fail. But why is it doing that?

-- 
Removing the straw that broke the camel's back does not necessarily
allow the camel to walk again.



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New cvs.eclass

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 920 bytes --]

On Saturday 19 April 2003 22:42, Chris Smith wrote:
> Hi Dan,
> 
> When I try and emerge the CVS Kopete (using your latest ebuilds) I get this 
> output here:
> 
> --snip--
> chris local # PORTDIR_OVERLAY=/usr/local/portage emerge kopete
> Calculating dependencies ...done!
> >>> emerge (1 of 1) net-im/kopete-5 to /
> >>> Unpacking source...
>  * Running cvs -q -f -z4 update -dP with anoncvs.kde.org:/home/kde for 
> kopete/...

Are you sure you have the latest cvs.eclass, kde-source.eclass? Try emerge 
sync again. As afr as I can tell from that output, you're using the new 
ebuilds with the old eclasses.

I say this first of all because only the old cvs.eclass had output saying "* 
Running cvs with...", the new one rephrases it as "* Fetching module...".

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]