Re: [gentoo-dev] Re: bzr.eclass into Portage

2008-10-25 Thread Ulrich Mueller
 On Mon, 06 Oct 2008, Jorge Manuel B S Vicetto wrote:

 Ulrich Mueller wrote:
 As I just learned there are (at least) three overlays using
 bzr.eclass, namely desktop-effects, emacs, and ltsp.
 
 So I think it is justified to move bzr.eclass to the Portage tree.

 I'll be waiting for the commit to remove the eclass from the
 desktop-effects overlay.

Committed to Portage tree today.

Ulrich



[gentoo-dev] Re: bzr.eclass into Portage

2008-10-13 Thread Ulrich Mueller
 On Mon, 13 Oct 2008, Steve Long wrote:

 No objections, a minor point wrt bash:

 EBZR_OPTIONS=${EBZR_OPTIONS:-} (and similar variants)
 doesn't do anything (beyond waste lex and yacc time.)

It does something, namely assigns an empty string if the variable was
undefined before. ;-) git.eclass and mercurial.eclass do
: ${EGIT_OPTIONS:=}
which has the same effect.

I've left these statements in for now, since I don't see how they
could harm. Does anyone else have an opinion here? I'm not really
decided about this point.

 [[ -z ${EBZR_REPO_URI} ]]  die ..
 Here's how I'd write that:
 [[ $EBZR_REPO_URI ]] || die ..

Applied. (However, I didn't remove the curly braces which are Gentoo
house style.)

 I've heard the be explicit argument before (hey antarus;) and
 here's why I disagree:
 If you don't know test (''help test'') and what its default is, then
 you really don't know the basics of shellscript (you possibly only
 think you do.) If you don't know shell, and can't begin to
 understand what that might do, then you shouldn't consider coding as
 a career, and I'd expect you to take quite a while to go through the
 #bash crucible; if you ever make it I'd have a lot of time for you.

Don't use a sledgehammer to crack a nut. The above is purely a
question of coding style and personal preferences.

 Given that, is there any reason not to use 1.6 if installed, and
 fallback to an earlier version if not?

Of course not. The dependency is DEPEND==dev-util/bzr-1.5.

Ulrich



Re: [gentoo-dev] Re: bzr.eclass into Portage

2008-10-13 Thread Bo Ørsted Andresen
On Monday 13 October 2008 04:43:48 Steve Long wrote:
 EBZR_OPTIONS=${EBZR_OPTIONS:-} (and similar variants)
 doesn't do anything (beyond waste lex and yacc time.)

It gets listed in the generated man page.

[...]
 The same consideration applies to all those constant values 'and indeed'
 ${foo} as opposed to $foo, though first time I raised that I got sworn at,
 so not expecting miracles here.

Are you for real?

-- 
Bo Andresen


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Re: bzr.eclass into Portage

2008-10-06 Thread Ulrich Mueller
 On Mon, 06 Oct 2008, Jorge Manuel B S Vicetto wrote:

 No objections here, just a question. Do you know if the issue with the
 lp:// sources has been fixed in bzr?

Looks like this is working fine with bzr-1.5, so I'll change the
dependency.

Ulrich



[gentoo-dev] Re: bzr.eclass into Portage

2008-10-05 Thread Ulrich Mueller
 On Fri, 21 Mar 2008, Christian Faulhammer wrote:

 Jorge Manuel B. S. Vicetto [EMAIL PROTECTED]:
 With the help of Ingmar we did some cleanup and added support for 
 eclass-manpages at 
 http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=bzr.
  
 I'll be moving the updated eclass to the master branch, testing and 
 asking users to try it out during this weekend.
 This eclass is used in the overlay for the live
 avant-window-navigator ebuilds, so it's probably not as used/tested
 as the remaining packages. It has provided us the support we needed
 for awn, but you might need additional features or to review existing
 ones. Please test the updated eclass on your overlay, feel free to
 maintain it and, when you think its ready, add it to the tree. When
 you do so, I'll remove it from our overlay and we'll use the eclass
 on the tree.

  We have a prior version for some time now in the Emacs overlay for
 two live ebuilds...so we go and merge your changed (ulm already
 did), test it and report any problems.

As I just learned there are (at least) three overlays using
bzr.eclass, namely desktop-effects, emacs, and ltsp.

So I think it is justified to move bzr.eclass to the Portage tree.
Currect version of bzr.eclass is attached.

Please raise your objections *now*.

Ulrich

# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# @ECLASS: bzr.eclass
# @MAINTAINER:
# Jorge Manuel B. S. Vicetto jmbsvicetto@gentoo.org
# @BLURB: This eclass provides support to use the Bazaar DSCM
# @DESCRIPTION:
# The bzr.eclass provides support for apps using the bazaar DSCM (distributed 
source control management system).
# The eclass was originally derived from the git eclass.
#
# Note: Just set EBZR_REPO_URI to the url of the branch and the src_unpack
# this eclass provides will put an export of the branch in ${WORKDIR}/${PN}.

inherit eutils

EBZR=bzr.eclass

EXPORT_FUNCTIONS src_unpack

HOMEPAGE=http://bazaar-vcs.org/;
DESCRIPTION=Based on the ${EBZR} eclass

DEPEND==dev-util/bzr-0.92

# @ECLASS-VARIABLE: EBZR_STORE_DIR
# @DESCRIPTION:
# The dir to store the bzr sources.
EBZR_STORE_DIR=${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/bzr-src

# @ECLASS-VARIABLE: EBZR_FETCH_CMD
# @DESCRIPTION:
# The bzr command to fetch the sources.
EBZR_FETCH_CMD=bzr branch

# @ECLASS-VARIABLE: EBZR_UPDATE_CMD
# @DESCRIPTION:
# The bzr command to update the sources.
EBZR_UPDATE_CMD=bzr pull

# @ECLASS-VARIABLE: EBZR_DIFFSTAT_CMD
# @DESCRIPTION:
# The bzr command to get the diffstat output.
EBZR_DIFFSTAT_CMD=bzr diff

# @ECLASS-VARIABLE: EBZR_EXPORT_CMD
# @DESCRIPTION:
# The bzr command to export a branch.
EBZR_EXPORT_CMD=bzr export

# @ECLASS-VARIABLE: EBZR_REVNO_CMD
# @DESCRIPTION:
# The bzr command to list revision number of the branch.
EBZR_REVNO_CMD=bzr revno

# @ECLASS-VARIABLE: EBZR_OPTIONS
# @DESCRIPTION:
# The options passed to the fetch and update commands.
EBZR_OPTIONS=${EBZR_OPTIONS:-}

# @ECLASS-VARIABLE: EBZR_REPO_URI
# @DESCRIPTION:
# The repository uri for the source package.
#
# @CODE
# Supported protocols:
#   - http://
#   - https://
#   - sftp://
#   - rsync://
#   - lp://
# @CODE
#
# Note: lp = https://launchpad.net
EBZR_REPO_URI=${EBZR_REPO_URI:-}

# @ECLASS-VARIABLE: EBZR_BOOTSTRAP
# @DESCRIPTION:
# Bootstrap script or command like autogen.sh or etc.
EBZR_BOOTSTRAP=${EBZR_BOOTSTRAP:-}

# @ECLASS-VARIABLE: EBZR_PATCHES
# @DESCRIPTION:
# bzr eclass can apply patches in bzr_bootstrap().
# you can use regexp in this valiable like *.diff or *.patch or etc.
# NOTE: this patches will applied before EBZR_BOOTSTRAP is processed.
#
# Patches are searched both in ${PWD} and ${FILESDIR}, if not found in either
# location, the installation dies.
EBZR_PATCHES=${EBZR_PATCHES:-}

# @ECLASS-VARIABLE: EBZR_BRANCH
# @DESCRIPTION:
# The branch to fetch in bzr_fetch().
#
# default: trunk
EBZR_BRANCH=${EBZR_BRANCH:-trunk}

# @ECLASS-VARIABLE: EBZR_REVISION
# @DESCRIPTION:
# Revision to get, if not latest (see http://bazaar-vcs.org/BzrRevisionSpec)
EBZR_REVISION=${EBZR_REVISION:-}

# @ECLASS-VARIABLE: EBZR_CACHE_DIR
# @DESCRIPTION:
# The dir to store the source for the package, relative to EBZR_STORE_DIR.
#
# default: ${PN}
EBZR_CACHE_DIR=${EBZR_CACHE_DIR:-${PN}}

# @FUNCTION: bzr_fetch
# @DESCRIPTION:
# Wrapper function to fetch sources from bazaar via bzr fetch or bzr update,
# depending on whether there is an existing working copy in ${EBZR_BRANCH_DIR}.
bzr_fetch() {
local EBZR_BRANCH_DIR

# EBZR_REPO_URI is empty.
[[ -z ${EBZR_REPO_URI} ]]  die ${EBZR}: EBZR_REPO_URI is empty.

# check for the protocol or pull from a local repo.
if [[ -z ${EBZR_REPO_URI%%:*} ]] ; then
case ${EBZR_REPO_URI%%:*} in
# lp:// is https://launchpad.net
http|https|rsync|sftp|lp)

Re: [gentoo-dev] Re: bzr.eclass into Portage

2008-10-05 Thread Jonas Bernoulli
Here is a patch that adds support for shared repositories. Since bzr
is still a bit slow this is quite useful when using multiple branches.

For example I have modified the live emacs(-cvs) ebuild to use the bzr
mirror of emacs instead of cvs. I also have my own emacs branches, and
sometimes want to install from one of these and at other times from
trunk. Without support for shared repositories this would require the
standalone branches to be manually moved out of the way everytime I
want to switch branches. (Or worse the complete tree to be checked out
from scratch every time I switch branches.)

Please consider these changes

Jonas

--- /usr/local/portage/layman/emacs/eclass/bzr.eclass   2008-10-05
22:40:18.0 +0200
+++ /usr/portage/eclass/bzr.eclass  2008-10-05 10:22:12.0 +0200
@@ -9,6 +9,7 @@
 # @DESCRIPTION:
 # The bzr.eclass provides support for apps using the bazaar DSCM
(distributed source control management system).
 # The eclass was originally derived from the git eclass.
+# Shared repository support added by Jonas Bernoulli [EMAIL PROTECTED].
 #
 # Note: Just set EBZR_REPO_URI to the url of the branch and the src_unpack
 # this eclass provides will put an export of the branch in ${WORKDIR}/${PN}.
@@ -22,13 +23,23 @@
 HOMEPAGE=http://bazaar-vcs.org/;
 DESCRIPTION=Based on the ${EBZR} eclass

-DEPEND==dev-util/bzr-0.92
+DEPEND==dev-util/bzr-1.6

 # @ECLASS-VARIABLE: EBZR_STORE_DIR
 # @DESCRIPTION:
 # The dir to store the bzr sources.
 EBZR_STORE_DIR=${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/bzr-src

+# @ECLASS-VARIABLE: EBZR_SHARED_REPO
+# @DESCRIPTION:
+# Whether to use a shared repository (see bzr help repositories).
+EBZR_SHARED_REPO=${EBZR_SHARED_REPO:-}
+
+# @ECLASS-VARIABLE: EBZR_INIT_REPO_CMD
+# @DESCRIPTION:
+# The bzr command to initialize the shared repository.
+EBZR_INIT_REPO_CMD=bzr init-repo
+
 # @ECLASS-VARIABLE: EBZR_FETCH_CMD
 # @DESCRIPTION:
 # The bzr command to fetch the sources.
@@ -54,9 +65,24 @@
 # The bzr command to list revision number of the branch.
 EBZR_REVNO_CMD=bzr revno

+# @ECLASS-VARIABLE: EBZR_INIT_REPO_OPTS
+# @DESCRIPTION:
+# Options passed to the init-repo commands.
+EBZR_INIT_REPO_OPTS=${EBZR_INIT_REPO_OPTS:-}
+
+# @ECLASS-VARIABLE: EBZR_FETCH_OPTS
+# @DESCRIPTION:
+# Options passed to the fetch commands in additon to EBZR_OPTIONS.
+EBZR_FETCH_OPTS=${EBZR_FETCH_OPTS:-}
+
+# @ECLASS-VARIABLE: EBZR_UPDATE_OPTS
+# @DESCRIPTION:
+# Options passed to the update commands in additon to EBZR_OPTIONS.
+EBZR_UPDATE_OPTS=${EBZR_UPDATE_OPTS:-}
+
 # @ECLASS-VARIABLE: EBZR_OPTIONS
 # @DESCRIPTION:
-# The options passed to the fetch and update commands.
+# The common options passed to the fetch and update commands.
 EBZR_OPTIONS=${EBZR_OPTIONS:-}

 # @ECLASS-VARIABLE: EBZR_REPO_URI
@@ -72,7 +98,7 @@
 #  - lp://
 # @CODE
 #
-# Note: lp = https://launchpad.net
+# Note: lp = http://launchpad.net
 EBZR_REPO_URI=${EBZR_REPO_URI:-}

 # @ECLASS-VARIABLE: EBZR_BOOTSTRAP
@@ -93,21 +119,26 @@
 # @ECLASS-VARIABLE: EBZR_BRANCH
 # @DESCRIPTION:
 # The branch to fetch in bzr_fetch().
-#
-# default: trunk
-EBZR_BRANCH=${EBZR_BRANCH:-trunk}
+EBZR_BRANCH=${EBZR_BRANCH:-}

 # @ECLASS-VARIABLE: EBZR_REVISION
 # @DESCRIPTION:
 # Revision to get, if not latest (see http://bazaar-vcs.org/BzrRevisionSpec)
 EBZR_REVISION=${EBZR_REVISION:-}

-# @ECLASS-VARIABLE: EBZR_CACHE_DIR
+# @ECLASS-VARIABLE: EBZR_CACHE_REPO_DIR
 # @DESCRIPTION:
-# The dir to store the source for the package, relative to EBZR_STORE_DIR.
+# The dir name of the local shared repository (if any).
 #
 # default: ${PN}
-EBZR_CACHE_DIR=${EBZR_CACHE_DIR:-${PN}}
+EBZR_CACHE_REPO_DIR=${EBZR_CACHE_REPO_DIR:-}
+
+# @ECLASS-VARIABLE: EBZR_CACHE_BRANCH_DIR
+# @DESCRIPTION:
+# The dir name of the local branch.
+#
+# default: ${EBZR_BRANCH} when using a shared repository or ${PN} otherwise
+EBZR_CACHE_BRANCH_DIR=${EBZR_CACHE_BRANCH_DIR:-}

 # @FUNCTION: bzr_fetch
 # @DESCRIPTION:
@@ -143,37 +174,64 @@

cd -P ${EBZR_STORE_DIR} || die ${EBZR}: can't chdir to 
${EBZR_STORE_DIR}

-   EBZR_BRANCH_DIR=${EBZR_STORE_DIR}/${EBZR_CACHE_DIR}
-
addwrite ${EBZR_STORE_DIR}
-   addwrite ${EBZR_BRANCH_DIR}

-   debug-print ${FUNCNAME}: EBZR_OPTIONS = ${EBZR_OPTIONS}
+   if [[ -n ${EBZR_SHARED_REPO} ]]; then
+   # using shared repository
+   EBZR_REPO_DIR=${EBZR_STORE_DIR}/${EBZR_CACHE_REPO_DIR:-${PN}}
+   
EBZR_BRANCH_DIR=${EBZR_REPO_DIR}/${EBZR_CACHE_BRANCH_DIR:-${EBZR_BRANCH}}
+
+   addwrite ${EBZR_REPO_DIR}
+   else
+   # using stand-alone branch
+   
EBZR_BRANCH_DIR=${EBZR_STORE_DIR}/${EBZR_CACHE_BRANCH_DIR:-${PN}}
+   fi
+
+   addwrite ${EBZR_BRANCH_DIR}

-   local repository
+   local branch

-   if [[ ${EBZR_REPO_URI} == */* ]]; then
-   repository=${EBZR_REPO_URI}${EBZR_BRANCH}
+   if [[ -n ${EBZR_BRANCH} ]] ; then
+   branch=${EBZR_REPO_URI}/${EBZR_BRANCH}
else
-  

Re: [gentoo-dev] Re: bzr.eclass into Portage

2008-10-05 Thread Jorge Manuel B. S. Vicetto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ulrich.

Ulrich Mueller wrote:
 On Fri, 21 Mar 2008, Christian Faulhammer wrote:
 
 Jorge Manuel B. S. Vicetto [EMAIL PROTECTED]:
 With the help of Ingmar we did some cleanup and added support for 
 eclass-manpages at 
 http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=bzr.
  
 I'll be moving the updated eclass to the master branch, testing and 
 asking users to try it out during this weekend.
 This eclass is used in the overlay for the live
 avant-window-navigator ebuilds, so it's probably not as used/tested
 as the remaining packages. It has provided us the support we needed
 for awn, but you might need additional features or to review existing
 ones. Please test the updated eclass on your overlay, feel free to
 maintain it and, when you think its ready, add it to the tree. When
 you do so, I'll remove it from our overlay and we'll use the eclass
 on the tree.
 
  We have a prior version for some time now in the Emacs overlay for
 two live ebuilds...so we go and merge your changed (ulm already
 did), test it and report any problems.
 
 As I just learned there are (at least) three overlays using
 bzr.eclass, namely desktop-effects, emacs, and ltsp.
 
 So I think it is justified to move bzr.eclass to the Portage tree.
 Currect version of bzr.eclass is attached.
 
 Please raise your objections *now*.

No objections here, just a question. Do you know if the issue with the
lp:// sources has been fixed in bzr?
I'll be waiting for the commit to remove the eclass from the
desktop-effects overlay.

 Ulrich
 
 

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjpYrcACgkQcAWygvVEyAI3lwCZAfnVwW9RWALkXOINwaCbdxgg
QIsAn2noprlga9qzUtFtwIRZk8ew9ia+
=9xKc
-END PGP SIGNATURE-



Re: [gentoo-dev] Re: bzr.eclass into Portage

2008-03-25 Thread René 'Necoro' Neumann

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

René 'Necoro' Neumann schrieb:
| Hi,
|
| Christian Faulhammer schrieb:
| |  We have a prior version for some time now in the Emacs overlay for two
| | live ebuilds...so we go and merge your changed (ulm already did), test
| | it and report any problems.
|
| I just copied the bzr.eclass from the desctop-effects overlay over to my
| own one. And I had to find out, that bzr fails when updating an ebuild
| which uses the lp: address scheme[1]. So perhaps, the support for this
| scheme should be removed until it is fixed.
|
| Regards,
| Necoro
|
| [1] https://bugs.launchpad.net/bzr/+bug/181945

Ok - seems like it got fixed in the meantime ... (bug is open for
several months --- and then gets fixed minutes after I post here ... ;))

I guess this fix will make it into bzr-1.4. Should the eclass then
depend on this version or should it still not allow the lp:-scheme?

Regards,
Necoro
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH6Rfv4UOg/zhYFuARAsgFAJoDn9csUloGQxZ4tHhInKxQ2LvkTwCeJRg0
xNqxCP0FbbgG22At64IcovU=
=G5Er
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: bzr.eclass into Portage

2008-03-25 Thread Christian Faulhammer
Hi,

René 'Necoro' Neumann [EMAIL PROTECTED]:
 I guess this fix will make it into bzr-1.4. Should the eclass then
 depend on this version or should it still not allow the lp:-scheme?

 This eclass is still experimental...but I am all for raising the
version requirement and allow as much features as possible.  Let's wait
for 1.4 then.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode

URL:http://www.faulhammer.org/


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: bzr.eclass into Portage

2008-03-24 Thread René 'Necoro' Neumann

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Christian Faulhammer schrieb:
|  We have a prior version for some time now in the Emacs overlay for two
| live ebuilds...so we go and merge your changed (ulm already did), test
| it and report any problems.

I just copied the bzr.eclass from the desctop-effects overlay over to my
own one. And I had to find out, that bzr fails when updating an ebuild
which uses the lp: address scheme[1]. So perhaps, the support for this
scheme should be removed until it is fixed.

Regards,
Necoro

[1] https://bugs.launchpad.net/bzr/+bug/181945
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH6FVC4UOg/zhYFuARAkmbAJ0cFEFGeZubvjhocmgPcTFXL6hdzACfYpGE
WP5z9YJri1NZzdQkHQ/Nv7E=
=YWvP
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: bzr.eclass into Portage

2008-03-21 Thread Christian Faulhammer
Hi,

Jorge Manuel B. S. Vicetto [EMAIL PROTECTED]:
 you can check the current version used in desktop-effects at 
 http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=master

 Yes, I did not find xeffects, but desktop-effects I now know.

 With the help of Ingmar we did some cleanup and added support for 
 eclass-manpages at 
 http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=bzr.
  
 I'll be moving the updated eclass to the master branch, testing and 
 asking users to try it out during this weekend.
 This eclass is used in the overlay for the live
 avant-window-navigator ebuilds, so it's probably not as used/tested
 as the remaining packages. It has provided us the support we needed
 for awn, but you might need additional features or to review existing
 ones. Please test the updated eclass on your overlay, feel free to
 maintain it and, when you think its ready, add it to the tree. When
 you do so, I'll remove it from our overlay and we'll use the eclass
 on the tree.

 We have a prior version for some time now in the Emacs overlay for two
live ebuilds...so we go and merge your changed (ulm already did), test
it and report any problems.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode

URL:http://www.faulhammer.org/


signature.asc
Description: PGP signature


[gentoo-dev] Re: bzr.eclass into Portage

2008-03-20 Thread Christian Faulhammer
Jorge Manuel B. S. Vicetto [EMAIL PROTECTED]:

 Petteri Räty wrote:
  Christian Faulhammer kirjoitti:
  in the Emacs overlay we imported the bzr.eclass from the xeffects
  overlay.  In the near future Emacs development will switch from
  CVS to Bazaar and thus we need the new eclass in Portage to still
  provide our live ebuilds from app-editors/emacs-cvs.  Question is
  now, who wrote it?
 
  Look at the SCM history in xeffects?

 Better yet, look at the desktop-effects overlay[1] and check the
 history of the eclass[2].

 I could not find the xeffects overlay...ok, Jorge you seem to be the
author.  So is it ready to import to Portage?

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode

URL:http://www.faulhammer.org/


signature.asc
Description: PGP signature