Re: [gentoo-dev] mercurial.eclass: change clone destination
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/11/10 02:40, Donnie Berkholz wrote:
I read it more closely and realized I was a little confused by the way
you listed all the bullet points mixing together benefits and problems.
So I'll try again: if you really want to do this change, you might want
to consider adding a mercurial-2.eclass instead. Eclasses of this nature
(svn, git, hg, etc) tend to be broadly used outside the tree as well as
within, so breaking backwards compatibility can be a real problem. A new
versioned eclass allows for a much more gradual transition.
I've only just jumped into the conversation, but the obvious question
is, why not just use ${S} as the location of the working directory
(rather than ${WORKDIR}/${workdir})? That way, if it's set old
ebuilds still work, and if it's not set, new ebuilds get the benefit of
using ${S}? I can only see a problem with this if there's somewhere
that the value of the working directory needs to be known before any of
the phases...
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAkzWloYACgkQu7rWomwgFXosEACgiFBLbFABweQR0JrZqprBxdkT
10UAoJVESt/2T3Y1AXkBXu7qYPY4NBf2
=ULZu
-END PGP SIGNATURE-
[gentoo-dev] [RFC] virtual/openvg virtual/gles virtual/egl
I'd like to introduce those virtual so far mesa[gallium] provides openvg-1.0, gles-2.0, gles-1.0 and egl-1.4 and binaries from companies are going to provide more or less the same features. Caveat: openvg and gles are bound to the egl implementation so you cannot mix and match them. Caveat2: I'm checking what happens with the xcb move since it should be compatible but it could not. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] mercurial.eclass: change clone destination
On 11/06/2010 11:22 AM, Krzysztof Pawlik wrote:
Hello,
I'm sending this patch for discussion, what it changes? The change is to where
the final clone of repository will be placed, it used to be
${WORKDIR}/${module}
(where module usually is the last component of source URI) to ${WORKDIR}/${P}
(essentially ${S}). This has few effects:
- ebuilds using mercurial.eclass don't need to set S any longer
- mercurial.eclass behaves more like git.eclass
- it breaks all existing ebuilds using this eclass
Which means that the doing the chance is not allowed as eclasses must
remain backwards compatible.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Please move your packages to virtual/jpeg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As some of you are aware libjpeg-turbo is in the tree, with v8 support. We will not keyword for any archs until we officially add the 1.1 release that is not avaliable as of yet. If we all use virtual/jpeg we can ensure that the user has the right to determine what version of jpeg they wish to use. I have already began the process with packages that have been tested a few packages that have already been converted include but are not limited to, openoffice, gegl, mplayer. qt-gui, vigra, chromium, ghostscript-gpl, mjpegtools, gdk-pixbug, gimp transcode and imaging. - -- == Jory A. Pratt anarchy -at- gentoo.org Gentoo Mozilla Lead GPG: 2C1D 6AF9 F35D 5122 0E8F 9123 C270 3B43 5674 6127 == -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzXAzQACgkQwnA7Q1Z0YSeOXgCgn98WQgs0rUxlTHqP7bqayBHo hrAAoKjAEl5Wkb7we+371Uq7ZwJEka4s =+4xs -END PGP SIGNATURE-
Re: [gentoo-dev] Please move your packages to virtual/jpeg
On 11/7/10 8:51 PM, Jory A. Pratt wrote: As some of you are aware libjpeg-turbo is in the tree, with v8 support. We will not keyword for any archs until we officially add the 1.1 release that is not avaliable as of yet. If we all use virtual/jpeg we can ensure that the user has the right to determine what version of jpeg they wish to use. Is media-libs/jpeg binary compatible with media-libs/libjpeg-turbo? I'm not sure what to do with chromium-bin, which is compiled on a Gentoo system. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please move your packages to virtual/jpeg
On 11/07/2010 10:40 PM, Paweł Hajdan, Jr. wrote: On 11/7/10 8:51 PM, Jory A. Pratt wrote: As some of you are aware libjpeg-turbo is in the tree, with v8 support. We will not keyword for any archs until we officially add the 1.1 release that is not avaliable as of yet. If we all use virtual/jpeg we can ensure that the user has the right to determine what version of jpeg they wish to use. Is media-libs/jpeg binary compatible with media-libs/libjpeg-turbo? I'm not sure what to do with chromium-bin, which is compiled on a Gentoo system. libjpeg.so.62 - media-libs/jpeg:62 libjpeg.so.8 - virtual/jpeg yes, it's binary compatible.
Re: [gentoo-dev] mercurial.eclass: change clone destination
On 11/07/10 13:07, Mike Auty wrote:
On 07/11/10 02:40, Donnie Berkholz wrote:
I read it more closely and realized I was a little confused by the way
you listed all the bullet points mixing together benefits and problems.
So I'll try again: if you really want to do this change, you might want
to consider adding a mercurial-2.eclass instead. Eclasses of this nature
(svn, git, hg, etc) tend to be broadly used outside the tree as well as
within, so breaking backwards compatibility can be a real problem. A new
versioned eclass allows for a much more gradual transition.
I've only just jumped into the conversation, but the obvious question
is, why not just use ${S} as the location of the working directory
(rather than ${WORKDIR}/${workdir})? That way, if it's set old
ebuilds still work, and if it's not set, new ebuilds get the benefit of
using ${S}? I can only see a problem with this if there's somewhere
that the value of the working directory needs to be known before any of
the phases...
Hm.. good idea :) I'm attaching modified patch that uses ${S} by default, so it
will improve the situation and at the same time it won't break existing ebuilds.
Thanks Mike for this suggestion.
--
Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
Index: mercurial.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/mercurial.eclass,v
retrieving revision 1.14
diff -u -r1.14 mercurial.eclass
--- mercurial.eclass26 Oct 2010 19:04:44 - 1.14
+++ mercurial.eclass7 Nov 2010 23:05:22 -
@@ -68,12 +68,12 @@
EHG_OFFLINE=${EHG_OFFLINE:-${ESCM_OFFLINE}}
# @FUNCTION: mercurial_fetch
-# @USAGE: [repository_uri] [module]
+# @USAGE: [repository_uri] [module] [sourcedir]
# @DESCRIPTION:
# Clone or update repository.
#
-# If not repository URI is passed it defaults to EHG_REPO_URI, if module is
-# empty it defaults to basename of EHG_REPO_URI.
+# If repository URI is not passed it defaults to EHG_REPO_URI, if module is
+# empty it defaults to basename of EHG_REPO_URI, sourcedir defaults to S.
function mercurial_fetch {
debug-print-function ${FUNCNAME} ${*}
@@ -81,6 +81,7 @@
[[ -z ${EHG_REPO_URI} ]] die EHG_REPO_URI is empty
local module=${2-$(basename ${EHG_REPO_URI})}
+ local sourcedir=${3-${S}}
# Should be set but blank to prevent using $HOME/.hgrc
export HGRCPATH=
@@ -116,19 +117,19 @@
fi
# Checkout working copy:
- einfo Creating working directory in ${WORKDIR}/${module} (target
revision: ${EHG_REVISION})
+ einfo Creating working directory in ${sourcedir} (target revision:
${EHG_REVISION})
hg clone \
${EHG_QUIET_CMD_OPT} \
--rev=${EHG_REVISION} \
${EHG_STORE_DIR}/${EHG_PROJECT}/${module} \
- ${WORKDIR}/${module} || die hg clone failed
+ ${sourcedir} || die hg clone failed
# An exact revision helps a lot for testing purposes, so have some
output...
# id num branch
# fd6e32d61721 6276 default
- local HG_REVDATA=($(hg identify -b -i ${WORKDIR}/${module}))
+ local HG_REVDATA=($(hg identify -b -i ${sourcedir}))
export HG_REV_ID=${HG_REVDATA[0]}
local HG_REV_BRANCH=${HG_REVDATA[1]}
- einfo Work directory: ${WORKDIR}/${module} global id: ${HG_REV_ID}
branch: ${HG_REV_BRANCH}
+ einfo Work directory: ${sourcedir} global id: ${HG_REV_ID} branch:
${HG_REV_BRANCH}
}
# @FUNCTION: mercurial_src_unpack
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-11-07 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2010-11-07 23h59 UTC. Removals: sys-auth/pam_pwdfile2010-11-01 16:14:41 flameeyes net-misc/omnievents 2010-11-01 16:14:41 flameeyes net-mail/ixbiff 2010-11-01 16:14:41 flameeyes sys-apps/stat 2010-11-01 16:14:42 flameeyes sys-devel/omni 2010-11-01 16:14:42 flameeyes dev-libs/pcl2010-11-01 16:14:42 flameeyes app-i18n/imhangul-status-applet 2010-11-01 16:14:42 flameeyes dev-lang/hugs98 2010-11-02 19:33:29 slyfox net-wireless/libbtctl 2010-11-02 21:41:22 eva net-wireless/bluez-gnome2010-11-02 21:49:12 eva xfce-base/tumbler 2010-11-03 19:50:41 ssuominen xfce-extra/xfce4-vala 2010-11-05 14:49:00 ssuominen net-misc/metacafe-dl2010-11-05 17:13:35 ricmm dev-libs/luaevent-prosody 2010-11-05 20:09:14 rafaelmartins dev-libs/luaexpat 2010-11-05 20:48:22 rafaelmartins dev-libs/luasec 2010-11-05 21:17:51 rafaelmartins dev-libs/luasocket 2010-11-05 21:40:56 rafaelmartins media-tv/v4l2-ctl 2010-11-05 22:23:33 ssuominen dev-lang/luarocks 2010-11-05 22:23:42 rafaelmartins dev-libs/luafilesystem 2010-11-05 23:23:03 rafaelmartins dev-util/luadoc 2010-11-05 23:47:19 rafaelmartins dev-lang/toluapp2010-11-06 01:49:30 rafaelmartins dev-lisp/cl-acclaim 2010-11-07 16:53:33 pchrist dev-lisp/cl-acl-compat 2010-11-07 17:05:33 pchrist dev-lisp/cl-aim 2010-11-07 17:06:04 pchrist dev-lisp/cl-aima2010-11-07 17:06:35 pchrist dev-lisp/cl-anaphora2010-11-07 17:07:05 pchrist dev-lisp/cl-ansi-tests-cvs 2010-11-07 17:07:35 pchrist dev-lisp/cl-araneida2010-11-07 17:08:07 pchrist dev-lisp/cl-archive 2010-11-07 17:08:37 pchrist dev-lisp/cl-arnesi-darcs2010-11-07 17:09:08 pchrist dev-lisp/cl-asdf-system-connections 2010-11-07 17:09:39 pchrist dev-lisp/cl-aserve 2010-11-07 17:10:10 pchrist dev-lisp/cl-aspectl 2010-11-07 17:10:42 pchrist dev-lisp/cl-awk 2010-11-07 17:11:13 pchrist dev-lisp/cl-base64 2010-11-07 17:11:45 pchrist dev-lisp/cl-bayescl 2010-11-07 17:12:15 pchrist dev-lisp/cl-binary-types2010-11-07 17:12:46 pchrist dev-lisp/cl-bind2010-11-07 17:13:16 pchrist dev-lisp/cl-blowfish2010-11-07 17:13:47 pchrist dev-lisp/cl-bouquet 2010-11-07 17:14:20 pchrist dev-lisp/cl-cclan 2010-11-07 17:14:51 pchrist dev-lisp/cl-cells 2010-11-07 17:15:22 pchrist dev-lisp/cl-cffi2010-11-07 17:15:53 pchrist dev-lisp/cl-cgi-utils 2010-11-07 17:16:23 pchrist dev-lisp/cl-ch-util 2010-11-07 17:16:54 pchrist dev-lisp/cl-chemical-compounds 2010-11-07 17:17:25 pchrist dev-lisp/cl-chunga 2010-11-07 17:17:56 pchrist dev-lisp/cl-clem2010-11-07 17:18:26 pchrist dev-lisp/cl-closer-mop 2010-11-07 17:18:57 pchrist dev-lisp/cl-colorize2010-11-07 17:19:28 pchrist dev-lisp/cl-common-idioms 2010-11-07 17:19:59 pchrist dev-lisp/cl-contextl2010-11-07 17:20:29 pchrist dev-lisp/cl-csv 2010-11-07 17:20:59 pchrist dev-lisp/cl-curl2010-11-07 17:21:29 pchrist dev-lisp/cl-cxml2010-11-07 17:21:59 pchrist dev-lisp/cl-defpatt 2010-11-07 17:22:29 pchrist dev-lisp/cl-defsystem3 2010-11-07 17:23:00 pchrist dev-lisp/cl-diff2010-11-07 17:23:31 pchrist dev-lisp/cl-difflib 2010-11-07
[gentoo-dev] last rites: games-mud/panache
+# Michael Sterrett mr_bon...@gentoo.org (07 Oct 2010) +# No release since 2002; uses gnome-vfs +# Mask for removal on 20101207 +games-mud/panache
Re: [gentoo-dev] mercurial.eclass: change clone destination
On 16:42 Sun 07 Nov , Petteri Räty wrote:
On 11/06/2010 11:22 AM, Krzysztof Pawlik wrote:
Hello,
I'm sending this patch for discussion, what it changes? The change is to
where
the final clone of repository will be placed, it used to be
${WORKDIR}/${module}
(where module usually is the last component of source URI) to
${WORKDIR}/${P}
(essentially ${S}). This has few effects:
- ebuilds using mercurial.eclass don't need to set S any longer
- mercurial.eclass behaves more like git.eclass
- it breaks all existing ebuilds using this eclass
Which means that the doing the chance is not allowed as eclasses must
remain backwards compatible.
Is that really still the case now that full environments have been saved
for a number of years? Clearly breaking things is unacceptable, but I
could envision someone simultaneously updating the eclass and all
consumers.
Perhaps you could point me to the appropriate documentation, if any
exists.
--
Thanks,
Donnie
Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgppENlLMLoiu.pgp
Description: PGP signature
