[gentoo-dev] Re: [RFC] global useflags
Steve Long [EMAIL PROTECTED] writes: Well if you're going for a widely-known acronym outside Gentoo-land it'd be decss: http://en.wikipedia.org/wiki/DeCSS I've always wondered why that wasn't used in the first place (not that it helps now; just found css odd for the same reason as others.) Because DeCSS and libdvdcss are not the same thing. It's like calling acrobat the pdf USE flag: yeah Acrobat produces and read PDF, but it's not Acrobat you're enabling. libdvdcss uses part of the code of DeCSS to do its work, but it is not DeCSS proper. -- Diego Flameeyes Pettenò http://farragut.flameeyes.is-a-geek.org/ pgp85UDAW9VS6.pgp Description: PGP signature
[gentoo-dev] Last rites: www-apps/bugs-bug-genie and www-apps/disc-cover
# Gunnar Wrobel [EMAIL PROTECTED] (14 Feb 2008) # Outdated package. See # https://bugs.gentoo.org/show_bug.cgi?id=209030 www-apps/disc-cover # Gunnar Wrobel [EMAIL PROTECTED] (14 Feb 2008) # Broken and outdated package. See # https://bugs.gentoo.org/show_bug.cgi?id=209029 www-apps/bugs-bug-genie Both ebuilds will be removed in 30 days if nobody objects. Cheers, Gunnar -- Gunnar WrobelGentoo Developer __C_o_n_t_a_c_t__ Mail: [EMAIL PROTECTED] WWW: http://www.gunnarwrobel.de IRC: #gentoo-web at freenode.org _ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [RFC] global useflags
Paul de Vrieze [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 15 Feb 2008 16:26:57 +1100: djvu: support DjVu, a PDF-like document format esp. suited for scanned documents Looks just about perfect, here. =8^) In contrast, the previous proposal may be more technically correct, but also has that unfortunate eyes-glaze- over effect. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] subversion.eclass
For quite a while the KDE herd has had a modified version of subversion.eclass
in the kde overlay. During that time we have added the following features to
the eclass which we would like to put back in gentoo-x86 soon. Since the
changes are fairly extensive we decided to send it to this list for review
first.
1) ESVN_REVISION (before this people had to use ESVN_OPTIONS for this
purpose).
2) ESVN_OFFLINE which disables svn up.
3) ESVN_UP_FREQ which uses GNU find to determine if the specified number of
hours has passed and only do svn up if it has. This is currently used in the
kde4svn-meta eclass for split kde ebuilds that use the same checkout of each
module.
4) ESCM_LOGDIR for logging which revisions packages get installed with. See
[1]. Users need to explicitly enable this feature to use it.
Other than this the eclass has been documented for use with eclass-manpages.
[1] http://thread.gmane.org/gmane.linux.gentoo.devel/54233
--
Bo Andresen
Gentoo KDE dev
--- /var/repositories/gentoo/eclass/subversion.eclass 2007-07-03 10:36:11.0 +0200
+++ /home/bo/git/genkde4svn-dev/eclass/subversion.eclass 2008-02-15 23:27:36.0 +0100
@@ -1,56 +1,52 @@
-# Copyright 1999-2007 Gentoo Foundation
+# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/subversion.eclass,v 1.44 2007/07/03 08:27:40 peper Exp $
+# $Header: $
-## --- #
-# Author: Akinori Hattori [EMAIL PROTECTED]
+# @ECLASS: subversion.eclass
+# @MAINTAINER:
+# ???
+#
+# Original author: Akinori Hattori [EMAIL PROTECTED]
+# @BLURB: The subversion eclass is written to fetch software sources from subversion repositories
+# @DESCRIPTION:
+# The subversion eclass provides functions to fetch, patch and bootstrap
+# software sources from subversion repositories.
#
-# The subversion eclass is written to fetch the software sources from
-# subversion repositories like the cvs eclass.
-#
-#
-# Description:
-# If you use this eclass, the ${S} is ${WORKDIR}/${P}.
-# It is necessary to define the ESVN_REPO_URI variable at least.
-#
-## --- #
+# You must define the ESVN_REPO_URI variable before inheriting this eclass.
inherit eutils
ESVN=subversion.eclass
-EXPORT_FUNCTIONS src_unpack
+EXPORT_FUNCTIONS src_unpack pkg_preinst
DESCRIPTION=Based on the ${ECLASS} eclass
-
-## -- add subversion in DEPEND
-#
DEPEND=dev-util/subversion
-
-## -- ESVN_STORE_DIR: subversion sources store directory
-#
-ESVN_STORE_DIR=${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/svn-src
-
-
-## -- ESVN_FETCH_CMD: subversion fetch command
-#
+# @ECLASS-VARIABLE: ESVN_STORE_DIR
+# @DESCRIPTION:
+# subversion sources store directory
+ESVN_STORE_DIR=${PORTAGE_ACTUAL_DISTDIR:-${DISTDIR}}/svn-src
+
+# @ECLASS-VARIABLE: ESVN_FETCH_CMD
+# @DESCRIPTION:
+# subversion fetch command
ESVN_FETCH_CMD=svn checkout
-## -- ESVN_UPDATE_CMD: subversion update command
-#
+# @ECLASS-VARIABLE: ESVN_UPDATE_CMD
+# @DESCRIPTION:
+# subversion update command
ESVN_UPDATE_CMD=svn update
-
-## -- ESVN_OPTIONS:
-#
+# @ECLASS-VARIABLE: ESVN_OPTIONS:
+# @DESCRIPTION:
# the options passed to checkout or update.
-#
-: ${ESVN_OPTIONS=}
-
+ESVN_OPTIONS=${ESVN_OPTIONS:=}
-## -- ESVN_REPO_URI: repository uri
+# @ECLASS-VARIABLE: ESVN_REPO_URI
+# @DESCRIPTION:
+# repository uri
#
# e.g. http://foo/trunk, svn://bar/trunk
#
@@ -59,11 +55,19 @@
# https://
# svn://
# svn+ssh://
-#
-: ${ESVN_REPO_URI=}
-
+ESVN_REPO_URI=${ESVN_REPO_URI:=}
-## -- ESVN_PROJECT: project name of your ebuild (= name space)
+# @ECLASS-VARIABLE: ESVN_REVISION
+# @DESCRIPTION:
+# svn revision to fetch
+#
+# Note that if you're specifying a revision to fetch in ESVN_OPTIONS while
+# setting ESVN_REVISION, you will get an error message.
+ESVN_REVISION=${ESVN_REVISION:=}
+
+# @ECLASS-VARIABLE: ESVN_PROJECT
+# @DESCRIPTION:
+# project name of your ebuild (= name space)
#
# subversion eclass will check out the subversion repository like:
#
@@ -82,45 +86,62 @@
# ESVN_PROJECT=commons/logging
#
# default: ${PN/-svn}.
-#
-: ${ESVN_PROJECT:=${PN/-svn}}
-
+ESVN_PROJECT=${ESVN_PROJECT:=${PN/-svn}}
-## -- ESVN_BOOTSTRAP:
-#
+# @ECLASS-VARIABLE: ESVN_BOOTSTRAP
+# @DESCRIPTION:
# bootstrap script or command like autogen.sh or etc..
-#
-: ${ESVN_BOOTSTRAP=}
-
+ESVN_BOOTSTRAP=${ESVN_BOOTSTRAP:=}
-## -- ESVN_PATCHES:
-#
-# subversion eclass can apply pathces in subversion_bootstrap().
+# @ECLASS-VARIABLE: ESVN_PATCHES
+# @DESCRIPTION:
+# subversion eclass can apply patches in subversion_bootstrap().
# you can use regexp in this variable like *.diff or *.patch or etc.
# NOTE: patches will be applied before ESVN_BOOTSTRAP is processed.
#
# Patches are searched both in / and ${FILESDIR}, if not found in both locations,
# the installation dies.
-#
-: ${ESVN_PATCHES=}
-
Re: [gentoo-dev] subversion.eclass
On 23:39 Fri 15 Feb , Bo Ørsted Andresen wrote: For quite a while the KDE herd has had a modified version of subversion.eclass in the kde overlay. During that time we have added the following features to the eclass which we would like to put back in gentoo-x86 soon. Since the changes are fairly extensive we decided to send it to this list for review first. 1) ESVN_REVISION (before this people had to use ESVN_OPTIONS for this purpose). 2) ESVN_OFFLINE which disables svn up. 3) ESVN_UP_FREQ which uses GNU find to determine if the specified number of hours has passed and only do svn up if it has. This is currently used in the kde4svn-meta eclass for split kde ebuilds that use the same checkout of each module. 4) ESCM_LOGDIR for logging which revisions packages get installed with. See [1]. Users need to explicitly enable this feature to use it. Other than this the eclass has been documented for use with eclass-manpages. [1] http://thread.gmane.org/gmane.linux.gentoo.devel/54233 Some of these features seem like they should get pushed up into a generic framework for all SCMs like scm.eclass. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] [RFC] Deprecating an eclass
Howdy all, We need to agree upon some syntax which we can mark an eclass as deprecated and potentially point to a replacement or multiple replacements. Discuss. -- Doug -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] subversion.eclass
Bo Ørsted Andresen wrote:
For quite a while the KDE herd has had a modified version of subversion.eclass
in the kde overlay. During that time we have added the following features to
the eclass which we would like to put back in gentoo-x86 soon. Since the
changes are fairly extensive we decided to send it to this list for review
first.
1) ESVN_REVISION (before this people had to use ESVN_OPTIONS for this
purpose).
ESVN_REPO_URI is a standard subversion URI and as such supports @HEAD,
@BASE, @COMMITTED, @PREV and @REV. So this is unnecessary.
2) ESVN_OFFLINE which disables svn up.
Isn't this a bit of a hack? The point is for it to run svn up. Now I've
added support in a local refactor that I had started today that if the
working copy's revision matches the requested revision, that no svn up
is performed. Obviously the situation when you have a live SVN ebuild
would still result in an svn up, but then again live SVN ebuilds are
frowned upon and if the person is trying to emerge a live SVN ebuild I
would expect them to always get the latest version.
3) ESVN_UP_FREQ which uses GNU find to determine if the specified number of
hours has passed and only do svn up if it has. This is currently used in the
kde4svn-meta eclass for split kde ebuilds that use the same checkout of each
module.
This would be handled by the feature above.
4) ESCM_LOGDIR for logging which revisions packages get installed with. See
[1]. Users need to explicitly enable this feature to use it.
This seems like it belongs in a generic SCM framework/eclass that all
SCM eclasses can support.
However, I personally like to handle this with two different situations.
emerge --info pkg, where the pkg installs a file to
/usr/share/${PN}/revision that stores the revision used and emerge
--info reads out that info. This is only for live SVN ebuilds. I don't
have any as an example currently.
The other solution is the way I do this with mythtv. For example,
mythtv-0.21_pre15768 checks out trunk revision 15768. This way the
revision is part of the version of the package and it's always known.
Additionally the changes I've been working on address the 5 outstanding
bugs found in Bugzilla and also remove some unnecessary and unused
functionality found in the eclass.
I had actually planned on providing the eclass on the ML later tonight
when I had it complete.
Since I have a feeling my changes or suggestions won't jive with the kde
herd, I'll offer mine up as svn.eclass
--
Doug Klima [EMAIL PROTECTED]
http://dev.gentoo.org/~cardoe/
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] subversion.eclass
Donnie Berkholz schrieb: On 23:39 Fri 15 Feb , Bo Ørsted Andresen wrote: For quite a while the KDE herd has had a modified version of subversion.eclass in the kde overlay. During that time we have added the following features to the eclass which we would like to put back in gentoo-x86 soon. Since the changes are fairly extensive we decided to send it to this list for review first. 1) ESVN_REVISION (before this people had to use ESVN_OPTIONS for this purpose). 2) ESVN_OFFLINE which disables svn up. 3) ESVN_UP_FREQ which uses GNU find to determine if the specified number of hours has passed and only do svn up if it has. This is currently used in the kde4svn-meta eclass for split kde ebuilds that use the same checkout of each module. 4) ESCM_LOGDIR for logging which revisions packages get installed with. See [1]. Users need to explicitly enable this feature to use it. Other than this the eclass has been documented for use with eclass-manpages. [1] http://thread.gmane.org/gmane.linux.gentoo.devel/54233 Some of these features seem like they should get pushed up into a generic framework for all SCMs like scm.eclass. Thanks, Donnie I'm already working on git.eclass. I've got some nice ideas for that one (or should I say, ideas, that I would want in it? ;-)). But I don't think, that they would benifit from a generic framework, since it's just a few lines anyway and since every scm is somewhat different, maybe it would blow up the generic thing. Regards, Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] subversion.eclass
Bernd Steinhauser wrote: Doug Klima schrieb: 2) ESVN_OFFLINE which disables svn up. Isn't this a bit of a hack? The point is for it to run svn up. Now I've added support in a local refactor that I had started today that if the working copy's revision matches the requested revision, that no svn up is performed. Obviously the situation when you have a live SVN ebuild would still result in an svn up, but then again live SVN ebuilds are frowned upon and if the person is trying to emerge a live SVN ebuild I would expect them to always get the latest version. What, if - the server containing the repository doesn't respond? - there is currently no connection to update but you need to remerge because of new useflags added (or similar)? In both cases with a normal merge it will die when trying to do svn up. Of course with 1) you could hack around that and specify the last revision in the repository, which btw. did a svn up, too, but this was changed today. Regards, Bernd I actually re-evaluated this after I sent that e-mail and changed it to behave like cvs.eclass. Basically if you set ESVN_REPO_URI=offline, then it'll assume you've got the revision you already want. -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] subversion.eclass
Doug Klima schrieb: 2) ESVN_OFFLINE which disables svn up. Isn't this a bit of a hack? The point is for it to run svn up. Now I've added support in a local refactor that I had started today that if the working copy's revision matches the requested revision, that no svn up is performed. Obviously the situation when you have a live SVN ebuild would still result in an svn up, but then again live SVN ebuilds are frowned upon and if the person is trying to emerge a live SVN ebuild I would expect them to always get the latest version. What, if - the server containing the repository doesn't respond? - there is currently no connection to update but you need to remerge because of new useflags added (or similar)? In both cases with a normal merge it will die when trying to do svn up. Of course with 1) you could hack around that and specify the last revision in the repository, which btw. did a svn up, too, but this was changed today. Regards, Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] subversion.eclass
On Saturday 16 February 2008 00:40:31 Doug Klima wrote: For quite a while the KDE herd has had a modified version of subversion.eclass in the kde overlay. During that time we have added the following features to the eclass which we would like to put back in gentoo-x86 soon. Since the changes are fairly extensive we decided to send it to this list for review first. 1) ESVN_REVISION (before this people had to use ESVN_OPTIONS for this purpose). ESVN_REPO_URI is a standard subversion URI and as such supports @HEAD, @BASE, @COMMITTED, @PREV and @REV. So this is unnecessary. The idea is that users can set ESVN_REVISION in the environment without having to modify the ebuilds. This isn't really possible with appending it to ESVN_REPO_URI. 2) ESVN_OFFLINE which disables svn up. Isn't this a bit of a hack? The point is for it to run svn up. Now I've added support in a local refactor that I had started today that if the working copy's revision matches the requested revision, that no svn up is performed. Obviously the situation when you have a live SVN ebuild would still result in an svn up, but then again live SVN ebuilds are frowned upon and if the person is trying to emerge a live SVN ebuild I would expect them to always get the latest version. Same as above. It's a convenience for users of live ebuilds which enables them to rebuild a package even when they don't have network without having to look up the revision of every packages that is currently available. 3) ESVN_UP_FREQ which uses GNU find to determine if the specified number of hours has passed and only do svn up if it has. This is currently used in the kde4svn-meta eclass for split kde ebuilds that use the same checkout of each module. This would be handled by the feature above. How? 4) ESCM_LOGDIR for logging which revisions packages get installed with. See [1]. Users need to explicitly enable this feature to use it. This seems like it belongs in a generic SCM framework/eclass that all SCM eclasses can support. Not opposed to that. But what would that scm eclass do exactly? [...] -- Bo Andresen Gentoo KDE dev signature.asc Description: This is a digitally signed message part.
