Re: [gentoo-dev] Baselayout-2 progress?
Ed W wrote: Hi baselayout-2 was renamed to openrc when Roy left Gentoo as an official dev. Answering my own question (for the record). I found some explanation here: http://lycos.dropcode.net/gregarius/author.php?author=Roy_Marples__uberlord_ Does Roy hang out here? Roy: Is this intended to be a baselayout replacement? How likely is this to be on-track to become a gentoo official baselayout? Do you (try to) support busybox and vserver environments? Don't know. Yes. Very. Yes Yes. Excellent - this is exciting to hear On the other hand since there still isn't a masked ebuild in portage (and I seem some notes on my on Roy's site) then I have to assume that in fact we are still a good way away from calling it a replacement and starting to push it out to users? Would it not make sense to start to snapshot some builds and push openrc out for testing? (Seems like a gentoo job rather than an upstream is the reason I ask here?) Cheers Ed W sudo emerge layman sudo layman -L sudo layman -a openrc sudo emerge openrc sudo etc-update -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Baselayout-2 progress?
Ed W wrote: Alon Bar-Lev wrote: Check out OpenRC it is baselayout successor and works great! Funnily enough I came across this earlier today for different reasons. However, I hadn't realised that it was a full baselayout competitor? baselayout-2 was renamed to openrc when Roy left Gentoo as an official dev. Does Roy hang out here? Roy: Is this intended to be a baselayout replacement? How likely is this to be on-track to become a gentoo official baselayout? Do you (try to) support busybox and vserver environments? Don't know. Yes. Very. Yes Yes. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Baselayout-2 progress?
Stefan Hellermann wrote: Roy Marples schrieb: Two small things happened here: After Login I the shell looks like: -bash-3.2# when I start then bash again manually it looks nice, the environment is not setup correctly the first time. Doesn't sound like an OpenRC issue as such as bash sets up it's own prompt. Also, OpenRC isn't responsible for setting up the environment. At most we suck in what's defined in /etc/profile.env when rebooting, INIT stops with no more processes left in this runlevel after remounting / Curious. A suggest you open a bug a http://bugs.marples.name against openrc so we can move the debugging off this list. Here is something other badly broken :) So I don't think it's a openrc issue. # echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # env | grep PATH *nothing* # sysctl # only a example for a app that works *works* # which sysctl# this should work if sysctl works without typing /sbin/sysctl which: no sysctl in ((null)) I think it could be a CFLAG, I compiled my whole System with -mfpmath=sse (not sse,387), but while emerging openrc there are compiler warnings saying it uses -mfpmath=387 because sse is not available. Does openrc block -msse? Cheers Stefan To hijack this thread, you know you're getting worse performance and more problematic results by using -mfpmath=sse. This is the very same reason that -march=pentium2 / -march=athlon-tbird and newer based CPUs don't enable this flag by default. It requires specific changes to system headers. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Baselayout-2 progress?
Duncan wrote: Roy Marples [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 29 Feb 2008 17:07:17 +: On Friday 29 February 2008 16:15:51 Ed W wrote: On the other hand since there still isn't a masked ebuild in portage (and I seem some notes on my on Roy's site) then I have to assume that in fact we are still a good way away from calling it a replacement and starting to push it out to users? It's actually been very stable and usable for a long time. It's not, and never will be a 100% drop in replacement for everything baselayout provides, but it's very very compatible. Is direct upgrade from previous baselayout-2.0.0-rcX going to be supported? I was running that for some time and just now added and upgraded to the via layman version. There's a blocker, of course, as openrc is now providing most of the files that baselayout did. You just answered your own question. If another package now provides files that an existing package provides, they must be blockers. Considering baselayout-2.0.0_rcX was a masked version and never recommended, it's also not in the direct upgrade path. The proper upgrade is what you've detailed out below. Such are the risks when you unmask a package and install it on your machine. The problem is that unmerging the old 2.0.0-rcX baselayout in ordered to resolve the blockage is SCARY, since it leaves the system basically unbootable until the new setup is merged and at least basically configured. There's also the issue of not knowing for sure just what's going to still be around in terms of config files and the like, since unmerging baselayout isn't exactly an everyday thing. FWIW, I took the jump anyway, and the etc-update seemed to go reasonably well, but I've not rebooted yet... -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] subversion.eclass
Doug Klima wrote:
Doug Klima wrote:
Doug Klima wrote:
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
ok. Well zlin and I have been talking lately and we've hammered out
his proposed changes and mine. I'm attaching a patch for the first
set of changes I have proposed.
Attached is a patch for the following:
- use $ECLASS
- adding rsync to deps
- fixing some quoting
- remove multiple subshell calls and problematic to upper usage (bug
#s escape me right now)
- provide some more information about the working copy that will be
used in the future.
- supporting svn switch
The most important being the svn switch functionality.
Please review for commit.
And the eclass-manpages documentation broken out into it's own patch.
Please review for commit.
Here's a patch that implements the ESVN_REVISION variable. It finally
removes all the problematic to_upper usage. It builds off the previous
patches that make the official way for an ebuild to pass the revision
it wants via the ESVN_REPO_URI. It ewarn's if an ebuild tries to stick
a revision into ESVN_OPTIONS. It prints out the revision that it's
going to be pulling. This was the issue I had with zlin's original
patch since it would break for the MythTV ebuilds since we request the
revision in the ebuild.
Here's another patch in the series.
This patch will skip running svn update when it's unnecessary. Basically
if your local working copy is the same URI and same revision, it won't
run svn update which should speed up emerge times for those svn KDE
users that specify a revision they're looking to use. Also MythTV users
that re-emerge with different use flags.
--- subversion-3.eclass 2008-02-20 11:07:57.0 -0500
+++ subversion-4.eclass 2008-02-20 11:14:23.0 -0500
@@ -222,14 +222,14 @@
if [ ${ESVN_WC_URL} != $(subversion__get_repository_uri ${repo_uri}) ]; then
einfo subversion switch start --
- einfo old repository: ${ESVN_WC_URL}
+ einfo old repository: [EMAIL PROTECTED]
einfo new repository: ${repo_uri}${revision:[EMAIL PROTECTED]
debug-print ${FUNCNAME}: ${ESVN_SWITCH_CMD} ${options}
cd ${wc_path} || die ${ESVN}: can't chdir to ${wc_path}
${ESVN_SWITCH_CMD} ${options} ${repo_uri} || die ${ESVN}: can't switch to ${repo_uri}.
- else
+ elif [ ${ESVN_WC_REVISION} -ne ${revision} ]; then
# update working copy
einfo subversion update start --
einfo repository: ${repo_uri}${revision:[EMAIL PROTECTED]
@@ -238,6 +238,8 @@
cd ${wc_path} || die ${ESVN}: can't chdir to ${wc_path}
${ESVN_UPDATE_CMD} ${options} || die ${ESVN}: can't update from ${repo_uri}.
+ else
+ einfo subversion update skipped. local copy is at requested revision
fi
fi
Re: [gentoo-dev] subversion.eclass
Doug Klima wrote:
Doug Klima wrote:
Doug Klima wrote:
Doug Klima wrote:
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
ok. Well zlin and I have been talking lately and we've hammered out
his proposed changes and mine. I'm attaching a patch for the first
set of changes I have proposed.
Attached is a patch for the following:
- use $ECLASS
- adding rsync to deps
- fixing some quoting
- remove multiple subshell calls and problematic to upper usage
(bug #s escape me right now)
- provide some more information about the working copy that will be
used in the future.
- supporting svn switch
The most important being the svn switch functionality.
Please review for commit.
And the eclass-manpages documentation broken out into it's own patch.
Please review for commit.
Here's a patch that implements the ESVN_REVISION variable. It finally
removes all the problematic to_upper usage. It builds off the
previous patches that make the official way for an ebuild to pass the
revision it wants via the ESVN_REPO_URI. It ewarn's if an ebuild
tries to stick a revision into ESVN_OPTIONS. It prints out the
revision that it's going to be pulling. This was the issue I had with
zlin's original patch since it would break for the MythTV ebuilds
since we request the revision in the ebuild.
Here's another patch in the series.
This patch will skip running svn update when it's unnecessary.
Basically if your local working copy is the same URI and same
revision, it won't run svn update which should speed up emerge times
for those svn KDE users that specify a revision they're looking to
use. Also MythTV users that re-emerge with different use flags.
The following patch makes changes to where the svn checkouts are stored.
This will fix the issue where for example:
mytharchive, mythdvd, mythvideo, mythweather are all stored in
http://svn.mythtv/svn/trunk/mythplugins
the KDE team has similar issues with their split out ebuilds and are
currently solving the issues by calling private subversion.eclass
Giving the ebuild and eclass programmer full control over the
ESVN_PROJECT path will allow for these hacks to disappear.
--- subversion-4.eclass 2008-02-20 11:14:23.0 -0500
+++ subversion-5.eclass 2008-02-20 11:35:10.0 -0500
@@ -104,9 +104,9 @@
# # jakarta commons-loggin
# ESVN_PROJECT=commons/logging
#
-# default: ${PN/-svn}.
+# default: ${CATEGORY/${PN/-svn}.
#
-: ${ESVN_PROJECT:=${PN/-svn}}
+: ${ESVN_PROJECT:=${CATEGORY}/${PN}}
# @ECLASS-VARIABLE: ESVN_BOOTSTRAP
@@ -410,7 +410,7 @@
debug-print ${FUNCNAME}: repo_uri = ${repo_uri}
- echo ${ESVN_STORE_DIR}/${ESVN_PROJECT}/${repo_uri##*/}
+ echo ${ESVN_STORE_DIR}/${ESVN_PROJECT}/
}
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
Ciaran McCreesh wrote: On Mon, 18 Feb 2008 18:15:18 -0500 Doug Klima [EMAIL PROTECTED] wrote: How many people are running a Portage version released after January 4? Eventually, all of them. And until then, how many users are going to get things going weirdly wrong if workarounds aren't added to everything using the code? 6 You think there are 6 people running stable Portage? Either you think all the users (including those installing off old stages) are running ~arch, or you think Gentoo has died, or you think everyone's moved to Paludis... Stupid questions deserve stupid answers. So I arbitrarily picked a number and gave it to you. A better statement on your part would have been We need to ensure compatibility for the greatest amount of users and requiring users to have a version of Portage released after January 4th when it's only the middle of February is not going to ensure the greatest compatibility. The previous policy was always 6 months between breaks like this. You're free to reword the above to however you see fit. -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
Ciaran McCreesh wrote: On Tue, 19 Feb 2008 08:44:43 -0500 Doug Klima [EMAIL PROTECTED] wrote: A better statement on your part would have been We need to ensure compatibility for the greatest amount of users and requiring users to have a version of Portage released after January 4th when it's only the middle of February is not going to ensure the greatest compatibility. The previous policy was always 6 months between breaks like this. You're free to reword the above to however you see fit. You mean the change should of course have been an EAPI bump. hth, As it's been explained to me by one of your fellow PMS developers, since EAPI=0 is not complete yet, there will be no work on further EAPIs until EAPI=0 is complete. Since this is the case and we still need to make changes, we must revert back to the previous policy with regard to changes. I personally would love to see EAPI=0 published as a draft for users and developers to see. I feel that it's going to be one of those things that's going to be difficult to nail down do the the nature of a whole package manager being developed without any specifications . Writing a concrete set of specifications after the fact, which encompass every little nook and cranny, is a difficult and tedious process that requires testing every single code path. -- 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).
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
ok. Well zlin and I have been talking lately and we've hammered out his
proposed changes and mine. I'm attaching a patch for the first set of
changes I have proposed.
Attached is a patch for the following:
- use $ECLASS
- adding rsync to deps
- fixing some quoting
- remove multiple subshell calls and problematic to upper usage (bug #s
escape me right now)
- provide some more information about the working copy that will be used
in the future.
- supporting svn switch
The most important being the svn switch functionality.
Please review for commit.
--- /usr/portage/eclass/subversion.eclass 2008-02-17 03:06:00.0 -0500
+++ subversion.eclass 2008-02-18 17:11:52.0 -0500
@@ -17,17 +17,16 @@
inherit eutils
-ESVN=subversion.eclass
+ESVN=$ECLASS
EXPORT_FUNCTIONS src_unpack
DESCRIPTION=Based on the ${ECLASS} eclass
-
## -- add subversion in DEPEND
#
-DEPEND=dev-util/subversion
-
+DEPEND=dev-util/subversion
+ net-misc/rsync
## -- ESVN_STORE_DIR: subversion sources store directory
#
@@ -42,6 +41,10 @@
#
ESVN_UPDATE_CMD=svn update
+## -- ESVN_SWITCH_CMD: subversion switch command
+#
+ESVN_SWITCH_CMD=svn switch
+
## -- ESVN_OPTIONS:
#
@@ -143,7 +146,7 @@
svn|svn+ssh)
;;
*)
- die ${ESVN}: fetch from ${protocol} is not yet implemented.
+ die ${ESVN}: fetch from \${protocol}\ is not yet implemented.
;;
esac
@@ -180,17 +183,24 @@
subversion_wc_info ${repo_uri} || die ${ESVN}: unknown problem occurred while accessing working copy.
if [ ${ESVN_WC_URL} != $(subversion__get_repository_uri ${repo_uri} 1) ]; then
- die ${ESVN}: ESVN_REPO_URI (or specified URI) and working copy's URL are not matched.
- fi
+ einfo subversion switch start --
+ einfo old repository: ${ESVN_WC_URL}
+ einfo new repository: ${repo_uri}
- # update working copy
- einfo subversion update start --
- einfo repository: ${repo_uri}
+ debug-print ${FUNCNAME}: ${ESVN_SWITCH_CMD} ${options}
- debug-print ${FUNCNAME}: ${ESVN_UPDATE_CMD} ${options}
+ cd ${wc_path} || die ${ESVN}: can't chdir to ${wc_path}
+ ${ESVN_SWITCH_CMD} ${options} ${repo_uri} || die ${ESVN}: can't switch to ${repo_uri}.
+ else
+ # update working copy
+ einfo subversion update start --
+ einfo repository: ${repo_uri}
- cd ${wc_path} || die ${ESVN}: can't chdir to ${wc_path}
- ${ESVN_UPDATE_CMD} ${options} || die ${ESVN}: can't update from ${repo_uri}.
+ debug-print ${FUNCNAME}: ${ESVN_UPDATE_CMD} ${options}
+
+ cd ${wc_path} || die ${ESVN}: can't chdir to ${wc_path}
+ ${ESVN_UPDATE_CMD} ${options} || die ${ESVN}: can't update from ${repo_uri}.
+ fi
fi
@@ -299,12 +309,10 @@
return 1
fi
- local k
-
- for k in url revision; do
- export ESVN_WC_$(subversion__to_upper_case ${k})=$(subversion__svn_info ${wc_path} ${k})
- done
-
+ export ESVN_WC_URL=$(subversion__svn_info ${wc_path} URL)
+ export ESVN_WC_ROOT=$(subversion__svn_info ${wc_path} Repository Root)
+ export ESVN_WC_UUID=$(subversion__svn_info ${wc_path} Repository UUID)
+ export ESVN_WC_REVISION=$(subversion__svn_info ${wc_path} Revision)
export ESVN_WC_PATH=${wc_path}
}
Re: [gentoo-dev] subversion.eclass
Doug Klima wrote:
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
ok. Well zlin and I have been talking lately and we've hammered out
his proposed changes and mine. I'm attaching a patch for the first set
of changes I have proposed.
Attached is a patch for the following:
- use $ECLASS
- adding rsync to deps
- fixing some quoting
- remove multiple subshell calls and problematic to upper usage (bug
#s escape me right now)
- provide some more information about the working copy that will be
used in the future.
- supporting svn switch
The most important being the svn switch functionality.
Please review for commit.
And the eclass-manpages documentation broken out into it's own patch.
Please review for commit.
--- subversion.eclass 2008-02-19 14:35:10.0 -0500
+++ subversion-2.eclass 2008-02-19 16:34:15.0 -0500
@@ -2,18 +2,18 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/subversion.eclass,v 1.45 2008/02/17 07:59:06 hattya Exp $
-## --- #
-# Author: Akinori Hattori [EMAIL PROTECTED]
+# @ECLASS: subversion.eclass
+# @MAINTAINER:
+# Akinori Hattori [EMAIL PROTECTED]
+# Doug Klima [EMAIL PROTECTED]
+#
+# Original Author: Akinori Hattori [EMAIL PROTECTED]
+# @BLURB: The subversion eclass is used to fetch sources from subversion repos
+# @DESCRIPTION:
+# The subversion eclass provides functions to fetch (checkout, update, and
+# switch), patch and bootstrap 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 ESVN_REPO_URI before inheriting this eclass.
inherit eutils
@@ -23,39 +23,47 @@
DESCRIPTION=Based on the ${ECLASS} eclass
-## -- add subversion in DEPEND
+## -- add subversion and rsync in DEPEND
#
DEPEND=dev-util/subversion
net-misc/rsync
-## -- ESVN_STORE_DIR: subversion sources store directory
-#
+# @ECLASS-VARIABLE: ESVN_STORE_DIR
+# @DESCRIPTION:
+# subversion sources store directory. Users may overright this by defining this
+# variable in /etc/make.conf
[ -z ${ESVN_STORE_DIR} ] ESVN_STORE_DIR=${PORTAGE_ACTUAL_DISTDIR:-${DISTDIR}}/svn-src
-## -- ESVN_FETCH_CMD: subversion fetch command
+# @ECLASS-VARIABLE: ESVN_FETCH_CMD
+# @DESCRIPTION:
+# subversion checkout 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_SWITCH_CMD: subversion switch command
-#
+# @ECLASS-VARIABLE: ESVN_SWITCH_CMD
+# @DESCRIPTION:
+# subversion switch command
ESVN_SWITCH_CMD=svn switch
-## -- ESVN_OPTIONS:
-#
-# the options passed to checkout or update.
-#
+# @ECLASS-VARIABLE: ESVN_OPTIONS
+# @DESCRIPTION:
+# the options passed to checkout, update or switch.
+# Not meant for -r REV, see ESVN_REPO_URI
: ${ESVN_OPTIONS:=}
-## -- ESVN_REPO_URI: repository uri
+# @ECLASS-VARIABLE: ESVN_REPO_URI
+# @DESCRIPTION:
+# repository uri
#
-# e.g. http://foo/trunk, svn://bar/trunk
+# e.g. http://foo/trunk, svn://bar/trunk, svn://bar/branch/[EMAIL PROTECTED]
#
# supported protocols:
# http://
@@ -63,10 +71,14 @@
# svn://
# svn+ssh://
#
+# to peg to a specific revision, append @REV to the repo's uri
+#
: ${ESVN_REPO_URI:=}
-## -- ESVN_PROJECT: project name of your ebuild (= name space)
+# @ECLASS-VARIABLE: ESVN_PROJECT
+# @DESCRIPTION:
+# project name of your ebuild (= name space)
#
# subversion eclass will check out the subversion repository like:
#
@@ -89,15 +101,15 @@
: ${ESVN_PROJECT:=${PN/-svn}}
-## -- ESVN_BOOTSTRAP:
-#
+# @ECLASS-VARIABLE: ESVN_BOOTSTRAP
+# @DESCRIPTION
Re: [gentoo-dev] [RFC] Deprecating an eclass
Doug Klima wrote: 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. Ok. I guess no one else has any feelings about this. Potentially doing something like: DEPRECIATED=$DEPRECATED $ECLASS at the top of each deprecated eclass. In the end $DEPRECATED would have a list of all the eclasses that are deprecated? Maybe even: DEPRECATED_MYECLASS=myreplacement would mean that myeclass.eclass is replaced by myreplacement.eclass ? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] Deprecating an eclass
Ciaran McCreesh wrote: On Mon, 18 Feb 2008 15:43:56 -0500 Doug Klima [EMAIL PROTECTED] wrote: Ok. I guess no one else has any feelings about this. Potentially doing something like: DEPRECIATED=$DEPRECATED $ECLASS Deprecated != depreciated. You caught my typo. You clearly still got the meaning of the e-mail... at the top of each deprecated eclass. In the end $DEPRECATED would have a list of all the eclasses that are deprecated? Maybe even: DEPRECATED_MYECLASS=myreplacement would mean that myeclass.eclass is replaced by myreplacement.eclass ? Well, that depends upon whether you want it to be part of the C/P-V metadata... If you do, it's a cache format change (and you can't easily do DEPRECATED_*). But then, deprecation is a property of the eclass, not an C/P-V. Deprecation is a property of the eclass. Not of an ebuild. The point is to allow utilities and users/developers to clearly see that an eclass is deprecated and what they should be using in place of it. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
Ciaran McCreesh wrote: On Mon, 18 Feb 2008 16:26:11 -0600 Ryan Hill [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Mon, 18 Feb 2008 13:54:34 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118r2=9140 Alright, so portage has put this stuff to stderr since January 4. Then why are we also adding workarounds to individual eclasses? How many people are running a Portage version released after January 4? Eventually, all of them. And until then, how many users are going to get things going weirdly wrong if workarounds aren't added to everything using the code? I'd mutter something about EAPIs here, but really if people are having difficulty understanding the necessity of the original commit, I suspect it's a lost cause... 6 -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- 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
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] missing quotes in eclasses
Markus Meier wrote: Hi There are several eclasses missing quotes: http://dev.gentoo.org/~maekke/eclass-quoting.txt This is the same check as repoman does, so there might be more quotes needed or false-positives. Markus Might want to cull that list of deprecated eclasses. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] missing quotes in eclasses
Markus Meier wrote: On Wed, 13 Feb 2008 14:42:32 -0500 Doug Klima [EMAIL PROTECTED] wrote: Markus Meier wrote: Hi There are several eclasses missing quotes: http://dev.gentoo.org/~maekke/eclass-quoting.txt Might want to cull that list of deprecated eclasses. That sounds like an idea. I blacklisted some obvious deprecated eclasses. You may refetch the list. Thanks deprecated eclasses:64-bit, darcs, db4-fix, debian, embassy-2.10, embassy-2.9, gcc, gnustep-old, gtk-engines, gtk-engines2, inherit, jakarta-commons, java-pkg, java-utils, kde-base, kde-i18n, kde-source, kmod, koffice-i18n, motif, mozilla, myth, pcmcia, perl-post, php, php-2, php-ext, php-ext-base, php-ext-pecl, php-ext-source, php-lib, php-pear, php-sapi, php5-sapi, php5-sapi-r1, php5-sapi-r2, php5-sapi-r3, tla, webapp-apache, xfree Missing from that list is kernel and gst-plugins. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/libselinux: ChangeLog libselinux-1.34.14.ebuild
Christian Faulhammer wrote:
Hi,
Chris PeBenito (pebenito) [EMAIL PROTECTED]:
pebenito08/01/29 15:12:57
Modified: ChangeLog
Added:libselinux-1.34.14.ebuild
Log:
sys-apps/libselinux: new upstream bugfix release.
(Portage version: 2.1.4)
pkg_postrm() {
python_version
python_mod_cleanup ${ROOT}usr/lib/python${PYVER}/site-packages
}
Per python.eclass, prefixing ${ROOT} to python_mod_cleanup is incorrect.
Donnie and I were going to look into making stuff like this a bit more
consistent but haven't had a chance.
--
Doug Klima [EMAIL PROTECTED]
http://dev.gentoo.org/~cardoe/
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] debianutils: system worthy ?
Mike Frysinger wrote: now that the mktemp binary has been moved out of debianutils and integrated straight into coreutils, perhaps it's time to ask how important this package is to everyone. current debianutils is part of system and provides: - installkernel - run-parts - tempfile - savelog - mkboot do people consider these things critical ? i dont know the last time i personally needed/wanted any of these ... -mike I feel the same as you Mike. Toss it. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] extend profiles.desc to include experimental profiles
Mike Frysinger wrote: after dealing with m68k, mips, and the *-fbsd ports, i think we could do with a new state for profiles.desc. the new field would simply be exp to indicate that the profile is experimental and that qa tools should generally not issue warnings about them. so in repoman's default mode, you wouldnt get any warnings, but if you were to run it in full mode, you'd see stuff like normal. this is useful for new projects which are still in the process of merging (like *-fbsd, m68k, and any new hardware i get my hands on) and are not really ready for dev marking. there are plenty of warnings in packages right now due to these profiles being labeled as dev that are the sole problem of the keyword maintainer in question and not the package maintainer. -mike I've very much been a proponent of properly listing out all of our profiles in profiles.desc. This sounds very reasonable and logical. And hopefully if the tools in question are coded properly, it should be compatible with older versions until users upgrade. Good stuff Mike. -- Doug Klima Gentoo Developer -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-core] Houston we have a problem
Alec Warner wrote: On 1/8/08, William L. Thomson Jr. [EMAIL PROTECTED] wrote: To keep it short and sweet. Our current structure is FUBARed. Foundation? Trustees? Election? Nominees? Ball dropped, shall we pick it up and resume a game? Gentoo does not exist legally. NPO filings in New Mexico expired. Effort was made to do something there. But hasn't yielded any results. We need to get legal some where ASAP. How, where, by whom? Seems policies dictated or held things back in the past. Do these policies matter now? There is no one really to enforce said policies. Council is fine, but per the structure has nothing to do with the foundation. Which I personally dislike, basically means the tail of the snake can live without the head. Which is where we are now. We have no head, no foundation, no one overseeing it. We just have a body and tail. I think we can grow a new head. Hopefully a better one, not just resurrecting the dead/broken/mia one. But at this point anything is better than nothing. Which is where things are at. What about the SFC you say? Good question. No foundation, no trustees, no one to oversee the transition to the SFC. If that's even the direction we want to go in. I personally have some hang-ups, reservations there. Take it to -nfp you say. I did, only a couple responded. No solution, no change. So that didn't work. Coming back to -core to hopefully catch alls attention. We all need to do something about this sooner rather than later. I have been kind silent about it waiting for things to happen. Things have not happened, so time to kick the pig. Hope the bitch doesn't kick back, or it will be all ham and bacon for us. To do nothing is each of us slowly letting Gentoo die. If it's going to die, let's not mess around. Let's shoot the thing in the head or euthanasia. Also I am not bringing this up to do nothing. But I will only act on consensus and if authorized. Otherwise it's up to others with the authority, etc. So that was very stream of consciousness ;) My question to you is: If Gentoo no longer exists, who owns the copyrights in that case? Who owns the money the foundation had in the bank? Is having the foundation even necessary? -Alec US Copyright law would say some stuff is Daniel Robbins' and some stuff is now Public Domain. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] USE flag documentation
Mark Loeser wrote: Alec Warner [EMAIL PROTECTED] said: One of the GLEP's primary goals is to provide a global use flag definition and over-ride it with a local definition. How does putting all flags in use.desc and over-riding local flags in use.local.desc not accomplish this? It does, and maybe that's what we should use instead? The reason for the email is to figure out if what we have now is good enough, or if we should switch to something else. You're the one forcing people to remove overriding USE flags from use.local.desc when that's something that people have been doing for ages. The current Portage tools support that method. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] USE flag documentation
Marius Mauch wrote: On Sun, 30 Dec 2007 19:54:04 -0500 Mark Loeser [EMAIL PROTECTED] wrote: Let me know if you like any of those ideas, or if they all suck (and if they do, you better tell me why). I'm not sure which is the best way forward, which is why I want everyone to contribute towards the best solution moving forward. I really don't want to be stuck with something that is going to end up being a pain a year down the road. What benefit does use.xml have over use.desc? My opinion is that we should use use.desc for a complete list of use flags, including a generic description, allow a more verbose description in metadata.xml and get rid of the stupid separation of local and global flags. No need to change the format of use.desc though. I completely agree with this. This allows each individual package to provide more insight to what a USE flag does. The only benefit use.local.desc gives us is a fast way to list packages using some flags, but that's unreliable at best. If needed such a list could be autogenerated. Marius -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Roy Marples wrote: On Tue, 2007-12-25 at 04:16 -0500, Ciaran McCreesh wrote: On 12/25/07, Roy Marples [EMAIL PROTECTED] wrote: Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI 1 environment, or what? If it's that such a big deal, then simply ensure that Thankyou for reading and understanding the GLEP before jumping in and commenting. I understand that metadata in a file name is pure and simple hackery that has no place here and the GLEP is a flimsy attempt to justify it. Thanks Roy Roy++ -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato wrote: Marius Mauch wrote: On Thu, 20 Dec 2007 08:10:13 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Ok, that seems a fine definition of what an eapi is. Everybody agrees on it? Nope. EAPI (from my POV) defines the API that a package manager has to export to an ebuild/eclass. That includes syntax and semantics of exported and expected functions and variables (IOW the content of ebuilds/eclasses), but does not contain naming and versioning rules (as those impact cross-package relationships). This restricted definition is ok for everybody? lu Logical and proper to me. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Asterisk 1.4 in Portage
Howdy all, As some people might have noticed, I've wanted to bring Asterisk 1.4 to the tree proper. The big holdup is the zaptel ebuild, which needs to be revamped and brought in as well for the 1.4.x series. I've already rewritten most of it, the only issue is I don't have hardware to test (nor do I want any). So I'd like if someone out there that used/had zaptel hardware would pick up the ebuild. If you're interested, drop me a line. I'll send you over a 1.4.x ebuild. -- Doug Klima Gentoo Developer -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato wrote: Rémi Cardona wrote: I'll speak up then :) What I _really_ would like to see ASAP : 1) Dropping digest-* files for real (ie, not even having them on the master rsync server and CVS) Slated for after 2007.1 is released. 2) Slotted deps (I had the feeling we were really close to having this a while back, and then radio silence, maybe I missed the final announcement?) You can already. Assuming you don't mind putting EAPI=1 inside of your ebuilds. 3) USE-deps Ok those interesting. As for the politics behind the naming of the EAPI, where it should be placed in the ebuild, whether it should be in metadata.xml or in the filename, I don't really care that much. I'm thinking about having them embedded in the comment as first line as something like #!/usr/bin/env emerge --eapi $foo I always wondered why we didn't put a shebang as such at the top of ebuilds. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
Petteri Räty wrote: Doug Klima kirjoitti: Since it doesn't appear the question was answered by the last thread. I'm starting a new thread. http://article.gmane.org/gmane.linux.gentoo.devel/52981/match=eapi I think it was answered. Regards, Petteri And I brough up valid reasons with zmedico why putting it before the inherit line was flawed currently since it could lead to some seriously unexpected behavior. If that's the case, it needs to be a very strict check in repoman and we need repoman on the eclasses to prevent people from putting EAPI into the eclasses. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
Ciaran McCreesh wrote: On Tue, 11 Dec 2007 16:59:28 -0500 Doug Klima [EMAIL PROTECTED] wrote: discuss. * EAPI may only be set before the 'inherit' in an ebuild. * Eclasses may not set EAPI. * Eclasses may not assume a particular EAPI. * If an eclass needs to work with multiple EAPIs, EAPI-specific code should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code and a conditional inherit should remain in foo.eclass. * Eclasses cannot be made not to work with any given EAPI. If such functionality is desirable, someone needs to file an EAPI request for permitting an alternative to 'die' that is legal in global scope. My point is it's fine to state this, however there needs to be enforcement of this in the associated utilities. repoman, etc. Unfortunately, eclasses are not checked at all at commit time, which would allow developers to make this potentially catastrophic change. So we're going to have eapi 1 inherit foo-eapi1.eclass allowable in foo.eclass? When will this eapi keyword be available for eclasses to use? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
Ciaran McCreesh wrote: On Wed, 12 Dec 2007 09:20:02 -0500 Doug Klima [EMAIL PROTECTED] wrote: And I brough up valid reasons with zmedico why putting it before the inherit line was flawed currently since it could lead to some seriously unexpected behavior. It's only unexpected if people screw up. If everyone understands the restrictions I posted and sticks to them then things work. If people start trying to be clever things go horribly wrong. If that's the case, it needs to be a very strict check in repoman and we need repoman on the eclasses to prevent people from putting EAPI into the eclasses. Or you need to get PMS and package managers retroactively updated to saying that 'inherit' does a 'declare -r EAPI'... Although that's only a good idea if you operate on the assumption that developers will screw up. That's the assumption I'm operating under because you and I both know if repoman and friends don't prevent it, it will happen. We can have all the docs in the world, but if we don't go about some steps to prevent bad things from happening. They can and will. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Use the Log
Christian Faulhammer wrote: Hi everyone, this is a reminder especially for architecture people: Please use the ChangeLog and really log everything you did. Don't do a change and forget to document it. Oh and please don't forget to remove your arches from the cc field if there is a bug. V-Li We've all made this request and made comments about this. The arches in question will not change. They've been doing it like that for years. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
William L. Thomson Jr. wrote: On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote: On 12/12/07, Jan Kundrát [EMAIL PROTECTED] wrote: Alon Bar-Lev wrote: As I told you before, I wont slot these two. Could you provide a link to reasons that lead you to this decision so that interested readers can make their own opinion? http://bugs.gentoo.org/show_bug.cgi?id=159623 Again while there might not be technical issues, what is not covered there in the bug is why rob users of a choice? Why make users mask a 2.0 version that's in the same slot as a 1.4.x version. Given that both will be actively maintained. If they are the same, why maintain 1.4.x at all? Kinda contradicts your justification and statements that gnupg-2 is a FULL replacement for gnupg-1. Plus your making Gentoo the ONLY distro where gnupg-1 and gnupg-2 can't be installed together. Just as upstream DESIGNED them. Nice one ;) And as I said then and now, good luck on stabilization ;) That's coming over a year after gnupg-2 was released. Can someone change the freaking broken record ;) Why don't you step up and offer to help maintain this? If I was Alon, I wouldn't want to do maintain both just cause you wanted me to. It increases maintenance load and work he has to do and since he's a volunteer it's all about scratching his personal itch, since this doesn't for him.. why should he do it. Clearly it gives you an itch, so setup up and offer to help maintain. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] EAPI placement
Since it doesn't appear the question was answered by the last thread. I'm starting a new thread. Cardoe did we decide where EAPI goes in an ebuild? zmedico yes, just above the inherit zmedico that's the safest and simplest thing to do, anyway Cardoe zmedico: what if I have EAPI=2 above the inherit but an eclass has EAPI=1 zmedico then the eclass would override the EAPI zmedico which probably isn't what you want zmedico are there any eclasses defining EAPI now? I hope not. :) * lavajoe has quit (Leaving) Cardoe I'm not sure zlin not in gentoo-x86 Cardoe but I think it would be something that would happen in the future Cardoe if an eclass uses features that require a specific EAPI Cardoe wouldn't it make sense to list that in there? zlin the kde4 eclasses in the kde4-experimental overlay set eapi=1. zmedico it's fine to do that, it's just too early to do that on lots of eclasses in the main tree, because EAPI=1 is too new zmedico we don't even have stages with EAPI=1 aware portage in them released yet zlin it probably shouldn't ever be done in an existing eclass. Cardoe I think putting EAPI above inherit is bad Cardoe because you're relying on the ebuild author to audit all the eclass code to know which EAPI version is required Cardoe for all the code zmedico same thing if you put it below, no? Cardoe no Cardoe because the eclass code should get executed at EAPI=1 Cardoe while the ebuild could get executed at EAPI=2 zmedico well, people can hash this stuff out over time zmedico there's no rush zmedico with =portage-2.1.4 we can make incompatible changes to eclasses :) Cardoe ok but you see what I'm saying? Cardoe it should go *AFTER* inherit zmedico to me, mixing code intended for multiple EAPIs is messy zmedico it's conceivable to have 2 different EAPIs where it's not even possible Cardoe While it might be messy, I can guarantee it will happen. Cardoe eutils might go to eapi=2 and some ebuild might need eapi=3, but eutils isn't ported to eapi=3 yet. Cardoe If you allow our developers to do it, it will happen. Cardoe Plain and simple. Unless repoman blocks this. zmedico we'll have some rules Cardoe Ok. Let's establish them. Cardoe releasing features and saying eh.. we'll figure it out as we go won't work Cardoe because you're gonna find people are going to stick stuff all over the place from the get go unless there are formal rules now zmedico 1) don't do anything stupid without discussing it with the community first ;) Cardoe well, we tried to talk about it on the mailing list but didn't get a solid answer. Cardoe I'm starting a new thread, and including this convo. Cardoe that's a too lose rule, people break that on a daily basis in the tree. Cardoe Let's address the issue now, rather then having a broken tree 3 months from now that will require 500 commits to fix. Cardoe I'll just send this to the ML now. discuss. -- Doug Klima Gentoo Developer -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: EAPI placement
Thomas Anderson wrote: On Tuesday 11 December 2007 18:21:31 Markus Ullmann wrote: Doug Klima schrieb: Cardoe zmedico: what if I have EAPI=2 above the inherit but an eclass has EAPI=1 if an eclass sets EAPI, then the ebuild shouldn't... make it two eclasses if needed or plain bump them if really really needed. Greetz Jokey That doesn't sound right. What happens if the eclass sets an EAPI(say 1), but you need to use say X feature(which is in EAPI 2). By what you said, this would prevent the ebuild from using the features in EAPI 2. It also isn't smart to bump eclasses' EAPI--EAPI should be set to the lowest common denominator that that feature being used is in. If that made sense ;) The issue additionally is that future EAPIs may remove deprecated features and may also have conflicting actions. So running an ebuild that's designed for say EAPI=2, which conflicts with EAPI=1, as EAPI=1 may be broken. -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
Marius Mauch wrote: On Tue, 11 Dec 2007 16:59:28 -0500 Doug Klima [EMAIL PROTECTED] wrote: Since it doesn't appear the question was answered by the last thread. I'm starting a new thread. The only sane solution I can think of is that eclasses shouldn't be allowed to change EAPI, but use conditionals to behave differently if needed. Mixing two (or more) different arbitrary EAPIs isn't going to work as after the inital parsing package managers will only see the last EAPI value anyway. Also there is no guarantee that future EAPI versions will be backwards compatible, so if eclasses could have an EAPI version it would eventually require that all packages using it need the same EAPI version (similar for nested inheritance). It's trivial to let inherit check that an eclass doesn't modify EAPI, and adding the conditional code to eclasses isn't difficult either: foo.eclass: if [ -z $EAPI ]; then inherit foo-eapi0 fi case $EAPI in 0) inherit foo-eapi0 ;; 1|2) inherit foo-eapi1_2 ;; *) eerror foo.eclass: unsupported EAPI value $EAPI ;; esac # EAPI independent code here Obviously instead of specific eclasses one could also inline the relevant code. The only two issues I see in this concept are the eventual multiplication of eclasses and the lack of proper error handling for unsupported EAPIs. Marius PS: Yes, this idea has been mentioned in the old thread as well This again leads to in a sense, code duplication due to the fact that you have to have several different versions of the code for each EAPI. When you could simply have $pkg_manager execute an eclass as 1 EAPI, another eclass as another and the ebuild as a third EAPI and simplify it for the eclass maintenance. -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] X drivers up for grabs
Piotr Jaroszyński wrote: (Nelson impression...) haha, peper! Start checkin out Ubuntu... compnerd says they apply 120 patches to this driver.. Also, start fixing the issues it has with HAL 0.5.10 since that's going to hit the tree for real shortly. If you need a version to test against, try Gentopia's overlay. mmm fun. I will look into all that during the weekend and at least I know who to harass :) Actually, I am no longer involved with HAL and am currently in the process of removing all traces of it off my system. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] X drivers up for grabs
Donnie Berkholz wrote: On 07:20 Tue 04 Dec , Piotr Jaroszyński wrote: On Tuesday 04 of December 2007 02:29:20 Donnie Berkholz wrote: evdev input driver I can take it unless someone else wants it more :) It's yours. I'll start reassigning bugs over the next couple of days. Thanks, Donnie (Nelson impression...) haha, peper! Start checkin out Ubuntu... compnerd says they apply 120 patches to this driver.. Also, start fixing the issues it has with HAL 0.5.10 since that's going to hit the tree for real shortly. If you need a version to test against, try Gentopia's overlay. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Features and documentation
Donnie Berkholz wrote: How the recent changes happened to allow USE flag descriptions in metadata.xml (which I'm not taking any position on now) gave me an idea. The Linux kernel requires that any needed documentation accompany all changes requiring said documentation -- part of the source-code patch must apply to the Documentation/ directory. Should we require that before you commit any changes, you (or someone) write the documentation for them and commit it or submit a patch at the same time? To sum up: No undocumented changes. Discuss. Thanks, Donnie I agree that documentation should be provided before anything is committed. I'd also like to note that documentation was provided with the USE flag descriptions as well as an example metadata.xml with all the new features being used was provided. -- Doug Klima Gentoo Developer -- [EMAIL PROTECTED] mailing list
Re: Reminder: Set your Reply-To (was Re: [gentoo-dev] packages.gentoo.org lives!)
Chris Gianelloni wrote: On Wed, 2007-11-14 at 13:22 -0700, Joe Peterson wrote: (Sorry for the previous reply to announce..) Let me take this opportunity to remind people to set a reply-to when sending anything to gentoo-dev-announce so people replying will reply to the proper place. Thanks, Robin's e-mail did set the Reply-To. Joe just broke the world.. bad Joe! -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] eselect_zenity: alpha eselect GUI
Donnie Berkholz wrote: Hey all, I've been wanting a GUI for eselect lately, so tonight I hacked up the start of one called eselect_zenity [1]. It only works for the most trivial modules so far -- it has to parse eselect output, so special parsers need to be written for each type. eselect_zenity uses (surprise!) Zenity, a shell-scripting interface to GTK+. I'd appreciate any patches you'd like to contribute to add functionality or fix bugs. Thanks, Donnie 1. http://dev.gentoo.org/~dberkholz/eselect_zenity/ This is something really good. I've been thinking that Gentoo could use a few small GUI utilities. Items such as a notification-applet for GLSA bits that affect your system. Similiar to Ubuntu's tool when there's updates that need to be applied. Additionally, I'd like to see all these utilities wrapped via PolicyKit rather then using gksu and kdesu applications. PolicyKit is definitely the way forward on designing custom, granular permissions and not relying on root in a GUI environment. While I haven't had much time to work on the bits, Gentopia does contain PolicyKit (though the 0.7 snapshots that appear do have some issues and you should stick to the 0.6 series). It's hopefully going to be the way forward for Gentoo to use PolicyKit. As many may know, Fedora has made this commitment and Ubuntu is starting to contribute more back and be involved a bit more. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: eselect_zenity: alpha eselect GUI
Markus Ullmann wrote: Doug Klima schrieb: While I haven't had much time to work on the bits, Gentopia does contain PolicyKit (though the 0.7 snapshots that appear do have some issues and you should stick to the 0.6 series). It's hopefully going to be the way forward for Gentoo to use PolicyKit. As many may know, Fedora has made this commitment and Ubuntu is starting to contribute more back and be involved a bit more. The gui project peoples along with two contributors and upstream already looked into that and at best we could use this notify feature for glsa. Gentoo is just too different to sanely work with it for full updates. Stuff like selecting useflags, outputting important changes, needed configuration updates afterwards and some more issues are plain not doable with packagekit. Though there is some work going on to get an abstraction layer for all three known package managers that work with the tree to make sure such a notify can be done. Greetz Jokey I only meant for notification purposes. Not for any updates or automatic merges. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-core] packages2 testing
Robin H. Johnson wrote: On Thu, Nov 08, 2007 at 07:52:49PM +0100, Marijn Schouten (hkBst) wrote: Isn't there supposed to be a search box too? Does anybody actually read the FAQ? - Short packages2 TODO list - Search: match a given string against: a substring in packages names, and description That's the same thing as expecting commenters on Slashdot to read the article before commenting, let alone the people that write the summary. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/updates: 4Q-2007
Mark Loeser wrote: Hanno Boeck (hanno) [EMAIL PROTECTED] said: hanno 07/11/06 01:01:35 Modified: 4Q-2007 Log: move beryl packages to their corresponding compiz fusion packages Revision ChangesPath 1.10 profiles/updates/4Q-2007 file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?rev=1.10view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?rev=1.10content-type=text/plain diff : http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?r1=1.9r2=1.10 Index: 4Q-2007 === RCS file: /var/cvsroot/gentoo-x86/profiles/updates/4Q-2007,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- 4Q-2007 3 Nov 2007 15:35:36 - 1.9 +++ 4Q-2007 6 Nov 2007 01:01:35 - 1.10 @@ -8,3 +8,10 @@ move x11-apps/compiz-settings x11-apps/ccsm move x11-plugins/compiz-extra x11-plugins/compiz-fusion-plugins-main slotmove =app-emulation/emul-linux-x86-java-1.4* 1.4.2 1.4 +move x11-wm/beryl x11-wm/compiz-fusion +move x11-wm/beryl-core x11-wm/compiz +move x11-plugins/beryl-plugins x11-plugins/compiz-fusion-plugins-main +move x11-plugins/beryl-dbus x11-plugins/compiz-fusion-plugins-extra +move x11-misc/beryl-settings-bindings x11-libs/compizconfig-python +move x11-misc/beryl-settings x11-libs/libcompizconfig +move x11-misc/beryl-manager x11-apps/ccsm Just to get a wider audience involved in this...this just seems wrong to do. There is a QA bug open about it as well: https://bugs.gentoo.org/show_bug.cgi?id=198248 What are other people's feelings on using package moves to forcibly migrate people like this? It also sounds like this wasn't announced at all and the packages just left the tree. Except the packages referenced are simply the same upstream project just renamed... so it is correct. -- [EMAIL PROTECTED] mailing list
