Re: [gentoo-dev] git-r3: initial draft for review
Dnia 2013-08-31, o godz. 01:17:26
Markos Chandras hwoar...@gentoo.org napisał(a):
On 31 August 2013 00:37, Michał Górny mgo...@gentoo.org wrote:
Hello, all.
After a few days of thinking, discovering and working, here it is.
The first working draft of new git eclass codenamed 'git-r3'.
First of all, the name is not final. I'm open to ideas. I'm open to
naming it 'git-r1' to put it in line with my other -r1 eclasses :).
I'd definitely like to avoid 'git-3' though, since that version-like
naming was a mistake as almost-'python-2' eclass shown.
Secondly, it's not even final that there will be a new eclass. Most
likely I will commit it as a new eclass since that way is easier for us
but if you prefer I may try to get it and git-2 more API-friendly
and work on making it a almost-drop-in replacement. Since, after all,
internals have actually changed much more than the API.
Hi,
I have no capacity to review the eclass right now (although I promise
I will soon)
but I was wondering why the whole eclass is inside the if [[ !
${_GIT_R3} ]] block.
Is it so you can avoid inheriting the same eclass twice? I haven't
seen that before
so I was wondering if that's the only reason. If yes, then maybe this
needs to be solved in PM scope instead?
As in, prevent portage from inheriting the same eclass twice instead
of handling this case in the eclass itself.
Yep, it's exactly that. All my new eclasses use that, and vapier's use
rather some 'spank' serpentines. Plus mine have 'EXPORT_FUNCTIONS' out
of it, so wrapping them does not change export order.
I suggested that into EAPI [1] but it didn't get in so far. The issue
is that some eclasses may actually need to be sourced twice, e.g. due
to environment changing. Though they are nowhere near 'sane' then.
[1]:https://bugs.gentoo.org/show_bug.cgi?id=422533
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] git-r3: initial draft for review
Dnia 2013-08-31, o godz. 06:55:01 C. Bergström cbergst...@pathscale.com napisał(a): Do you have any plans to add support for sparse checkout? Something like this |cd parentdir git clone -n url cd repo_dir git remote add –f name url git config core.sparsecheckout true echo /foldername/ .git/info/sparse-checkout git checkout tagname Considering our specific work flow, I think it would be enough to do: git checkout branch [dir1 dir2 ...] Depending on the need for it, I can either add it as optional arguments to git_checkout or an envvar for it. What about subtrees? Looking at their specific design, don't they work out-of-the-box? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] git-r3: initial draft for review
Dnia 2013-08-31, o godz. 01:46:40 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org napisał(a): 5. Safer default EGIT_DIR choice. EGIT_PROJECT removed. Since submodules are cloned as separate repositories as well, we can't afford having EGIT_PROJECT to change the clone dir. Instead, the eclass uses full path from first repo URI (with some preprocessing) to determine the clone location. This should ensure non-colliding clones with most likeliness that two ebuilds using the same repo will use the same clone without any special effort from the maintainer. [snip] 5. EGIT_PROJECT - should be no longer necessary. How so? Point 5. over there :). It is supposed to choose perfect clone location itself now. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] git-r3: initial draft for review [v2]
And time for a small update.
Dnia 2013-08-31, o godz. 01:37:44
Michał Górny mgo...@gentoo.org napisał(a):
3. sys-fs/bedup's btrfs-progs submodule says the given commit id is
'not a valid branch point'. Need to investigate what this means.
4. 'git fetch --depth 1' seems to be refetching stuff even when nothing
changed. Need to investigate it. It may be enough to do an additional
'did anything change?' check.
Those are fixed now. The eclass has been adjusted to work properly with
branches, tags and commit ids. It also avoids shallowing repo that was
unshallowed already (since we expect that one of the packages needs it
non-shallow), and properly unshallows shallow repos ;).
Attaching the new version and a diff.
--
Best regards,
Michał Górny
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: git-r3.eclass
# @MAINTAINER:
# MichaŠGórny mgo...@gentoo.org
# @BLURB: Eclass for fetching and unpacking git repositories.
# @DESCRIPTION:
# Third generation eclass for easing maitenance of live ebuilds using
# git as remote repository. Eclass supports lightweight (shallow)
# clones, local object deduplication and submodules.
case ${EAPI:-0} in
0|1|2|3|4|5)
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
if [[ ! ${_GIT_R3} ]]; then
inherit eutils
fi
EXPORT_FUNCTIONS src_unpack
if [[ ! ${_GIT_R3} ]]; then
# @ECLASS-VARIABLE: EGIT_STORE_DIR
# @DESCRIPTION:
# Storage directory for git sources.
#
# EGIT_STORE_DIR=${DISTDIR}/git3-src
# @ECLASS-VARIABLE: EGIT_REPO_URI
# @REQUIRED
# @DESCRIPTION:
# URIs to the repository, e.g. git://foo, https://foo. If multiple URIs
# are provided, the eclass will consider them as fallback URIs to try
# if the first URI does not work.
#
# It can be overriden via env using ${PN}_LIVE_REPO variable.
#
# Example:
# @CODE
# EGIT_REPO_URI=git://a/b.git https://c/d.git;
# @CODE
# @ECLASS-VARIABLE: EVCS_OFFLINE
# @DEFAULT_UNSET
# @DESCRIPTION:
# If non-empty, this variable prevents any online operations.
# @ECLASS-VARIABLE: EGIT_BRANCH
# @DEFAULT_UNSET
# @DESCRIPTION:
# The branch name to check out. If unset, the upstream default (HEAD)
# will be used.
#
# It can be overriden via env using ${PN}_LIVE_BRANCH variable.
# @ECLASS-VARIABLE: EGIT_COMMIT
# @DEFAULT_UNSET
# @DESCRIPTION:
# The tag name or commit identifier to check out. If unset, newest
# commit from the branch will be used. If set, EGIT_BRANCH will
# be ignored.
#
# It can be overriden via env using ${PN}_LIVE_COMMIT variable.
# @ECLASS-VARIABLE: EGIT_NONSHALLOW
# @DEFAULT_UNSET
# @DESCRIPTION:
# Disable performing shallow fetches/clones. Shallow clones have
# a fair number of limitations. Therefore, if you'd like the eclass to
# perform complete clones instead, set this to a non-null value.
#
# This variable is to be set in make.conf. Ebuilds are not allowed
# to set it.
# @FUNCTION: _git-r3_env_setup
# @INTERNAL
# @DESCRIPTION:
# Set the eclass variables as necessary for operation. This can involve
# setting EGIT_* to defaults or ${PN}_LIVE_* variables.
_git-r3_env_setup() {
debug-print-function ${FUNCNAME} $@
local esc_pn livevar
esc_pn=${PN//[-+]/_}
livevar=${esc_pn}_LIVE_REPO
EGIT_REPO_URI=${!livevar:-${EGIT_REPO_URI}}
[[ ${EGIT_REPO_URI} ]] \
|| die EGIT_REPO_URI must be set to a non-empty value
[[ ${!livevar} ]] \
ewarn Using ${livevar}, no support will be provided
livevar=${esc_pn}_LIVE_BRANCH
EGIT_BRANCH=${!livevar:-${EGIT_BRANCH}}
[[ ${!livevar} ]] \
ewarn Using ${livevar}, no support will be provided
livevar=${esc_pn}_LIVE_COMMIT
EGIT_COMMIT=${!livevar:-${EGIT_COMMIT}}
[[ ${!livevar} ]] \
ewarn Using ${livevar}, no support will be provided
# git-2 unsupported cruft
local v
for v in EGIT_{SOURCEDIR,MASTER,HAS_SUBMODULES,PROJECT} \
EGIT_{NOUNPACK,BOOTSTRAP}
do
[[ ${!v} ]] die ${v} is not supported.
done
}
# @FUNCTION: _git-r3_set_gitdir
# @USAGE: repo-uri
# @INTERNAL
# @DESCRIPTION:
# Obtain the local repository path and set it as GIT_DIR. Creates
# a new repository if necessary.
#
# repo-uri may be used to compose the path. It should therefore be
# a canonical URI to the repository.
_git-r3_set_gitdir() {
debug-print-function ${FUNCNAME} $@
local repo_name=${1#*://*/}
# strip common prefixes to make paths more likely to match
# e.g. git://X/Y.git vs https://X/git/Y.git
# (but just one of the prefixes)
case ${repo_name} in
# cgit can proxy requests to git
cgit/*) repo_name=${repo_name#cgit/};;
# pretty common
git/*) repo_name=${repo_name#git/};;
# gentoo.org
Re: [gentoo-dev] git-r3: initial draft for review [v2]
On Sat, 31 Aug 2013, Michał Górny wrote:
And time for a small update.
In git-r3_checkout:
git --no-pager diff --color --stat \
${old_commit_id}..${new_commit_id}
I'd rather omit the --color option, otherwise log files will contain
escape sequences.
Also it won't harm to make the unpack location configurable, so can we
please have a variable like EGIT_SOURCEDIR or EGIT_UNPACK_DIR (as it
was called in git.eclass)?
Ulrich
[gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
As described here:
https://bugs.gentoo.org/show_bug.cgi?id=483128
This is a very lightweight patch to support the few packages that
provide gdk pixbuf loaders. The ones I know of are: gdk-pixbuf itself,
librsvg and libopenraw and emul-gtklibs but more could be missing simply
because they do not run the command.
Since this patch is quite trivial, I'd like to have it commited by
Sunday. Thanks.
I am attaching the patch here as well for convience.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Index: gnome2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2.eclass,v
retrieving revision 1.122
diff -u -B -r1.122 gnome2.eclass
--- gnome2.eclass 26 May 2013 14:08:21 - 1.122
+++ gnome2.eclass 31 Aug 2013 10:56:58 -
@@ -258,6 +258,7 @@
gnome2_icon_savelist
gnome2_schemas_savelist
gnome2_scrollkeeper_savelist
+ gnome2_gdk_pixbuf_savelist
}
# @FUNCTION: gnome2_pkg_postinst
@@ -271,6 +272,7 @@
gnome2_icon_cache_update
gnome2_schemas_update
gnome2_scrollkeeper_update
+ gnome2_gdk_pixbuf_update
}
# # FIXME Handle GConf schemas removal
Index: gnome2-utils.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2-utils.eclass,v
retrieving revision 1.31
diff -u -B -r1.31 gnome2-utils.eclass
--- gnome2-utils.eclass 27 Oct 2012 22:24:10 - 1.31
+++ gnome2-utils.eclass 31 Aug 2013 10:56:58 -
@@ -50,6 +50,12 @@
# Path to glib-compile-schemas
: ${GLIB_COMPILE_SCHEMAS:=/usr/bin/glib-compile-schemas}
+# @ECLASS-VARIABLE: GDK_PIXBUF_UPDATE_BIN
+# @INTERNAL
+# @DESCRIPTION:
+# Path to gdk-pixbuf-query-loaders
+: ${GDK_PIXBUF_UPDATE_BIN:=/usr/bin/gdk-pixbuf-query-loaders}
+
# @ECLASS-VARIABLE: GNOME2_ECLASS_SCHEMAS
# @INTERNAL
# @DEFAULT_UNSET
@@ -74,6 +80,12 @@
# @DESCRIPTION:
# List of GSettings schemas provided by the package
+# @ECLASS-VARIABLE: GNOME2_ECLASS_GDK_PIXBUF_LOADERS
+# @INTERNAL
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# List of gdk-pixbuf loaders provided by the package
+
DEPEND==sys-apps/sed-4
@@ -387,6 +399,45 @@
eend $?
}
+# @FUNCTION: gnome2_gdk_pixbuf_savelist
+# @DESCRIPTION:
+# Find if there is any gdk-pixbuf loader to install and save the list in
+# GNOME2_ECLASS_GDK_PIXBUF_LOADERS variable.
+# This function should be called from pkg_preinst.
+gnome2_gdk_pixbuf_savelist() {
+ has ${EAPI:-0} 0 1 2 ! use prefix ED=${D}
+ pushd ${ED} /dev/null
+ export GNOME2_ECLASS_GDK_PIXBUF_LOADERS=$(find usr/$(get_libdir)/gdk-pixbuf-2.0 -type f 2/dev/null)
+ popd /dev/null
+}
+
+# @FUNCTION: gnome2_gdk_pixbuf_update
+# @USAGE: gnome2_gdk_pixbuf_update
+# @DESCRIPTION:
+# Updates gdk-pixbuf loader cache if GNOME2_ECLASS_GDK_PIXBUF_LOADERS has some.
+# This function should be called from pkg_postinst and pkg_postrm.
+gnome2_gdk_pixbuf_update() {
+ has ${EAPI:-0} 0 1 2 ! use prefix EROOT=${ROOT}
+ local updater=${EROOT}${GDK_PIXBUF_UPDATE_BIN}
+
+ if [[ ! -x ${updater} ]]; then
+ debug-print ${updater} is not executable
+ return
+ fi
+
+ if [[ -z ${GNOME2_ECLASS_GDK_PIXBUF_LOADERS} ]]; then
+ debug-print gdk-pixbuf loader cache does not need an update
+ return
+ fi
+
+ ebegin Updating gdk-pixbuf loader cache
+ local tmp_file=$(mktemp -t tmp.XX_gdkpixbuf)
+ ${updater} 1 ${tmp_file} 2/dev/null
+ cat ${tmp_file} ${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache
+ eend $?
+}
+
+
# @FUNCTION: gnome2_query_immodules_gtk2
# @USAGE: gnome2_query_immodules_gtk2
# @DESCRIPTION:
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Dnia 2013-08-31, o godz. 13:07:41
Gilles Dartiguelongue e...@gentoo.org napisał(a):
+# @FUNCTION: gnome2_gdk_pixbuf_savelist
+# @DESCRIPTION:
+# Find if there is any gdk-pixbuf loader to install and save the list in
+# GNOME2_ECLASS_GDK_PIXBUF_LOADERS variable.
+# This function should be called from pkg_preinst.
+gnome2_gdk_pixbuf_savelist() {
+ has ${EAPI:-0} 0 1 2 ! use prefix ED=${D}
+ pushd ${ED} /dev/null
pushd ${ED} /dev/null || die
(don't hide errors)
+ export GNOME2_ECLASS_GDK_PIXBUF_LOADERS=$(find
usr/$(get_libdir)/gdk-pixbuf-2.0 -type f 2/dev/null)
+ popd /dev/null
+}
+
+# @FUNCTION: gnome2_gdk_pixbuf_update
+# @USAGE: gnome2_gdk_pixbuf_update
+# @DESCRIPTION:
+# Updates gdk-pixbuf loader cache if GNOME2_ECLASS_GDK_PIXBUF_LOADERS has
some.
+# This function should be called from pkg_postinst and pkg_postrm.
+gnome2_gdk_pixbuf_update() {
+ has ${EAPI:-0} 0 1 2 ! use prefix EROOT=${ROOT}
+ local updater=${EROOT}${GDK_PIXBUF_UPDATE_BIN}
+
+ if [[ ! -x ${updater} ]]; then
+ debug-print ${updater} is not executable
+ return
+ fi
+
+ if [[ -z ${GNOME2_ECLASS_GDK_PIXBUF_LOADERS} ]]; then
+ debug-print gdk-pixbuf loader cache does not need an update
+ return
+ fi
+
+ ebegin Updating gdk-pixbuf loader cache
+ local tmp_file=$(mktemp -t tmp.XX_gdkpixbuf)
+ ${updater} 1 ${tmp_file} 2/dev/null
Why do you hide errors from user? '[FAIL]' with no explanation doesn't
seem really helpeful.
+ cat ${tmp_file}
${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache
Why not mv or cp? Also you need '|| die' here since 'cat' can fail
writing.
Is it safe to assume constant '2.10.0'?
+ eend $?
+}
+
+
# @FUNCTION: gnome2_query_immodules_gtk2
# @USAGE: gnome2_query_immodules_gtk2
# @DESCRIPTION:
Also, please make 'loaders.cache' owned by x11-libs/gdk-pixbuf.
And please ensure to remove it in pkg_postrm() when last version
of gdk-pixbuf is unmerged.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Le samedi 31 août 2013 à 13:40 +0200, Michał Górny a écrit :
Dnia 2013-08-31, o godz. 13:07:41
Gilles Dartiguelongue e...@gentoo.org napisał(a):
+# @FUNCTION: gnome2_gdk_pixbuf_savelist
+# @DESCRIPTION:
+# Find if there is any gdk-pixbuf loader to install and save the list in
+# GNOME2_ECLASS_GDK_PIXBUF_LOADERS variable.
+# This function should be called from pkg_preinst.
+gnome2_gdk_pixbuf_savelist() {
+ has ${EAPI:-0} 0 1 2 ! use prefix ED=${D}
+ pushd ${ED} /dev/null
pushd ${ED} /dev/null || die
(don't hide errors)
ok, I'll check all other usage in gnome eclasses.
+ export GNOME2_ECLASS_GDK_PIXBUF_LOADERS=$(find
usr/$(get_libdir)/gdk-pixbuf-2.0 -type f 2/dev/null)
+ popd /dev/null
+}
+
+# @FUNCTION: gnome2_gdk_pixbuf_update
+# @USAGE: gnome2_gdk_pixbuf_update
+# @DESCRIPTION:
+# Updates gdk-pixbuf loader cache if GNOME2_ECLASS_GDK_PIXBUF_LOADERS has
some.
+# This function should be called from pkg_postinst and pkg_postrm.
+gnome2_gdk_pixbuf_update() {
+ has ${EAPI:-0} 0 1 2 ! use prefix EROOT=${ROOT}
+ local updater=${EROOT}${GDK_PIXBUF_UPDATE_BIN}
+
+ if [[ ! -x ${updater} ]]; then
+ debug-print ${updater} is not executable
+ return
+ fi
+
+ if [[ -z ${GNOME2_ECLASS_GDK_PIXBUF_LOADERS} ]]; then
+ debug-print gdk-pixbuf loader cache does not need an update
+ return
+ fi
+
+ ebegin Updating gdk-pixbuf loader cache
+ local tmp_file=$(mktemp -t tmp.XX_gdkpixbuf)
+ ${updater} 1 ${tmp_file} 2/dev/null
Why do you hide errors from user? '[FAIL]' with no explanation doesn't
seem really helpeful.
True.
+ cat ${tmp_file}
${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache
Why not mv or cp? Also you need '|| die' here since 'cat' can fail
writing.
I'd have to look back at the original bug report to get the exact reason
but it seems mv/cp was not atomic enough.
Is it safe to assume constant '2.10.0'?
afaik yes, it's not changed in ages.
+ eend $?
+}
+
+
# @FUNCTION: gnome2_query_immodules_gtk2
# @USAGE: gnome2_query_immodules_gtk2
# @DESCRIPTION:
Also, please make 'loaders.cache' owned by x11-libs/gdk-pixbuf.
Yes, we need to work on that for all other caches as well.
And please ensure to remove it in pkg_postrm() when last version
of gdk-pixbuf is unmerged.
I am not clear on this last sentence. Could you reformulate it please ?
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
On 31/08/13 09:00 AM, Gilles Dartiguelongue wrote: And please ensure to remove it in pkg_postrm() when last version of gdk-pixbuf is unmerged. I am not clear on this last sentence. Could you reformulate it please ? Ensure that the loaders.cache file is removed correctly when all versions of gdk-pixbuf have been removed from the system. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Dnia 2013-08-31, o godz. 15:00:43
Gilles Dartiguelongue e...@gentoo.org napisał(a):
Le samedi 31 août 2013 à 13:40 +0200, Michał Górny a écrit :
+ cat ${tmp_file}
${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache
Why not mv or cp? Also you need '|| die' here since 'cat' can fail
writing.
I'd have to look back at the original bug report to get the exact reason
but it seems mv/cp was not atomic enough.
Well, 'cat' is not atomic at all, so definitely not that :). 'mv' is
the only command that you can expect to at least try to be atomic.
It may had something to do with file metadata or symlinks.
And please ensure to remove it in pkg_postrm() when last version
of gdk-pixbuf is unmerged.
I am not clear on this last sentence. Could you reformulate it please ?
In gdk-pixbuf, something like:
pkg_postrm() {
# TODO: check if i used the correct variable :)
[[ ${REPLACING_VERSIONS} ]] || rm -f ${EROOT}usr/.../loaders.cache
}
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] rfc: stabilization policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/21/2013 05:13 AM, Tom Wijsman wrote: On Wed, 21 Aug 2013 12:32:35 +0400 Sergey Popov pinkb...@gentoo.org wrote: 21.08.2013 12:13, Tom Wijsman пишет: Recruiting shows to be a hard task; so, the suggestions I am doing are assuming that that doesn't work out. In which case, I wonder what by some other ways you would think of... Dropping some keywords to unstable on minor arches. If we grow (like you said below), then doing less seems like a decision that we shouldn't take; it is rather about doing it different to use our resources in a better way. Crowd sourcing users is an option here... And about recruiting, it is the only way we can keep moving with getting distro, which makes bigger and bigger all the time. Yes, but apart from recruiting you can make the resources used better; if the current way of using our resources isn't sufficient, we can improve that as well. Improving both is going to make the difference. I would have joined recruiters unless i knew how difficult job they are doing. Yes, I am interested in both mentoring and recruiting and I need to contact them again; but I do not really intend to point at recruiters here or how hard that is, what I intend to point at with recruiting is finding those users that are willing to learn to write better ebuilds and are willing to become a Gentoo Developer. They are hard to find; and in order for them to be found, a mentor has to find them somewhere. Came across three types of people already trying to find a mentee: 1. The first one doesn't want to go through the amount of time it takes; this depends a bit on the queue, but it can take months. 2. The second one's interest to become a Gentoo Developer depends from time to time; so, tries to start over and over to become one. 3. The third one writes a lot of ebuilds (and has an overlay that looks like a gold mine), but there is a language barrier that keeps the user from contributing; so, we take things slowly instead... 4. The fourth one leaves a message on IRC and quits before you return. 5. ... I know we are a little OT here but the fifth type of recruit is someone who is very excited, very dedicated, and completely unable to find a mentor. That is where I was for a long time, no one seemed to have the time to mentor me. Personally I think that is a big issue in the growth of gentoo, if we all take a little time out to be mentors there will be more gentoo devs and we will get more done. - -ZC So, recruiting in the terms of finding recruits appears to be hard. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSIhvmAAoJEKXdFCfdEflKwykP/32wuUhRfcwYZsq5pZDMhj3e KVDrODlnNt9gsLU3nWj4CuOil5IecWzaODmrejN9bWjW9xEPHGYhs6WfUkGL+8Bm wVg7yun1v/ACNynraLi9F3YimDeFruFSLMeYttaxb04KJVGdCETXQN4/qiKGqRl5 p4o1kEQUAWie0DURKm1rO1z7zdBOJczdk70QAcwO/5t80gCyrIlWFor/jZ1Nvk05 TASTs25Jxd5hQ+FZsqeIem458eQj3j+OvuJBgcBT34+7ka1nsP7ZWmLBVBEvejGC If3D0xaDQD0Rjxf6jtnt8vILSzQTq7UUkGLIvRGlxiA7fFSLxMrQHz2UDo1pxKfg BbQZ4ftm7icjum/DE5XyGWRHlbVE5Zvi/joV+pKoLw2BaDZrxTqGgDjqLGPpP5W4 P7/+3+PH8x9GZKgco1d34eFA9oXdGVorRDybuOb33Hy/CgUvAr+n9tLfPOjHW1Ye U09BTRzlceJQmp3KLHvdmYLIm9THsdI7YfjlSxPyaDKykiFNwRCfRPMvp2FTqBNr doVm8dyX8+4FqtW+BkwdUZjTVEv5AQv9jdqx/rfNy9UJ8qWfLTPXWcHrJWu8gOsv 3G+mAGvqKMXkJWarguydGf3q8QJzmPXscps4vPq9AcTpWldPLQW8lxPzic4IpYjN O3TUqhO0KX9NejKTO6Ef =yG20 -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Le samedi 31 août 2013 à 16:49 +0200, Michał Górny a écrit :
Dnia 2013-08-31, o godz. 15:00:43
Gilles Dartiguelongue e...@gentoo.org napisał(a):
Le samedi 31 août 2013 à 13:40 +0200, Michał Górny a écrit :
+ cat ${tmp_file}
${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache
Why not mv or cp? Also you need '|| die' here since 'cat' can fail
writing.
I'd have to look back at the original bug report to get the exact reason
but it seems mv/cp was not atomic enough.
Well, 'cat' is not atomic at all, so definitely not that :). 'mv' is
the only command that you can expect to at least try to be atomic.
It may had something to do with file metadata or symlinks.
I sort of remember there was a bug report but I can find no trace of it.
All I could find was the commit that introduced this logic, by lxnay:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.24.0.ebuild?hideattic=0revision=1.2view=markup
@lxnay, could you please comment on previous question ?
And please ensure to remove it in pkg_postrm() when last version
of gdk-pixbuf is unmerged.
I am not clear on this last sentence. Could you reformulate it please ?
In gdk-pixbuf, something like:
pkg_postrm() {
# TODO: check if i used the correct variable :)
[[ ${REPLACING_VERSIONS} ]] || rm -f ${EROOT}usr/.../loaders.cache
}
ok, will do.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
signature.asc
Description: This is a digitally signed message part
How to find a mentor, WAS: [gentoo-dev] rfc: stabilization policies
On Sat, 31 Aug 2013 12:37:58 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: I know we are a little OT here but the fifth type of recruit is Yes. someone who is very excited, very dedicated, and completely unable to find a mentor. That is where I was for a long time, no one seemed to have the time to mentor me. Your recruitment bug disagrees with you here in that you had a mentor right from the start. The netmon@g.o alias never saw mail from you before your recruitment bug was openend, so how could anyone have known you were trying to attract a mentor and do netmon stuff? I don't see any mail on gentoo-dev or gentoo-project either. There are exactly *nill* bugs that you reported and were (subsequently) CC'd or Assigned to netmon@g.o. You have only yourself to blame. jer
Re: [gentoo-dev] rfc: stabilization policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 31 Aug 2013 12:37:58 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: I know we are a little OT here but the fifth type of recruit is someone who is very excited, very dedicated, and completely unable to find a mentor. That is where I was for a long time, no one seemed to have the time to mentor me. It can indeed be though to find someone with time. But there are certainly people that do have time and are willing to mentor; it's just that, you've got to find each other at the right time and place. Which makes me think we should have some way to list people that are willing to become Gentoo Developers as well as Gentoo Developers that are willing to mentor people. Perhaps on the Gentoo Wiki? That would turn the easy to miss anyone want to mentor me? or random probing do _you_ want to be my mentor? into an approach where it's a matter of looking at a list, contacting someone and you are set. Personally I think that is a big issue in the growth of gentoo, if we all take a little time out to be mentors there will be more gentoo devs and we will get more done. +1 - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iQEcBAEBAgAGBQJSIjWiAAoJEJWyH81tNOV99Z4H/RqrSRQFZ2GtXhp/3cDJkulP +gxYk2kdWxfoPRCzn4Yv9rLELEkvrrcSEN2u0HM6kP+Br9rOVwY0n5MjFlQbu6+t I0xN372l9I489tjj9THMB3NjgTnyFqFRzTv07xu9oeiw1OtbmII4JDMyEmsyUMmC MgfgSEMyd1CgsYF9lTp9nJLIMoRym+o9d6PrjoFgGKIhBKL//JGxMIdAdixQotCo r7aOXpO0mf0sOLI3m5JdIp4wm12uTjBtkSpuOkCUeKz16F23M4fwd8l+v+lLQ1G+ cqjnPs1QHUos8W/wzSw5gohCnc0anF9D1mkiwmnd4qhblg1jRzwNm271zD7hv+k= =HByi -END PGP SIGNATURE-
Re: How to find a mentor, WAS: [gentoo-dev] rfc: stabilization policies
On Sat, 31 Aug 2013 19:29:30 +0200 Jeroen Roovers j...@gentoo.org wrote: someone who is very excited, very dedicated, and completely unable to find a mentor. That is where I was for a long time, no one seemed to have the time to mentor me. Your recruitment bug disagrees with you here in that you had a mentor right from the start. The recruitment bug is filed by the mentor; the bug on it own marks the time at which a mentor is willing to mentor the mentee, but it does not reflect the time at which he started to look for a mentor. I don't see any mail on gentoo-dev or gentoo-project either. This makes me wonder if that is a good or bad idea; on the one hand, it would be nice to see a mentee step up and look for a mentor on the MLs but on the other hand that might result in some noise. After all, the relation between a mentor and a mentee is from person to person; and not from person to list. It's not really a discussion; so, I don't feel like it necessarily belongs on the MLs, unless as announcement. Even if this were considered a good idea, then how would we get people to advertise themselves on the mailing lists? There seem to be two things we need to think about: 1. Where do people find the information on how to find a mentor? 2. Where do we want people to look for a mentor? But that's one side of the story; the other side has the same questions, but at least has an answer. Mentors find the a mentee (eg. nice bug reporter) between a lot of people (eg. all bug reporters); so, it's like finding signal in a lot of noise. What we need on this other side, might be better tools to find outstanding users; but that on their own take some time to implement and might not gain much. So, I'm rooting for having a central list where mentors and mentees can find each other; I think that that would give the best of both worlds. The netmon@g.o alias never saw mail from you before your recruitment bug was openend, so how could anyone have known you were trying to attract a mentor and do netmon stuff? ... There are exactly *nill* bugs that you reported and were (subsequently) CC'd or Assigned to netmon@g.o. Not everyone wants to immediately start out on a herd. You have only yourself to blame. Since when did this become a game of blame with him? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: stabilization policies
El sáb, 31-08-2013 a las 12:37 -0400, Rick Zero_Chaos Farina escribió: [...] I know we are a little OT here but the fifth type of recruit is someone who is very excited, very dedicated, and completely unable to find a mentor. That is where I was for a long time, no one seemed to have the time to mentor me. Personally I think that is a big issue in the growth of gentoo, if we all take a little time out to be mentors there will be more gentoo devs and we will get more done. -ZC I guess we should have a official contact or mail alias to let them contact. If they don't even contact me, I cannot know about them and then mentor them :/
Re: [gentoo-dev] rfc: stabilization policies
On Sat, 31 Aug 2013 20:45:00 +0200 Pacho Ramos pa...@gentoo.org wrote: El sáb, 31-08-2013 a las 12:37 -0400, Rick Zero_Chaos Farina escribió: [...] I know we are a little OT here but the fifth type of recruit is someone who is very excited, very dedicated, and completely unable to find a mentor. That is where I was for a long time, no one seemed to have the time to mentor me. Personally I think that is a big issue in the growth of gentoo, if we all take a little time out to be mentors there will be more gentoo devs and we will get more done. -ZC I guess we should have a official contact or mail alias to let them contact. If they don't even contact me, I cannot know about them and then mentor them :/ Ah, I like this idea better than the list on Gentoo Wiki I was trying to approach; the only downside I can imagine if it were a single person that might not respond in time (busy / devaway / MIA), so I think we should at least aim to make it a mail alias with multiple persons. We could then list people on some project page; but, only their forenames or nicknames and not their actual full name and e-mail such that their private details can stay private if they wish to. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] git-r3: initial draft for review [v2]
Dnia 2013-08-31, o godz. 11:26:30
Ulrich Mueller u...@gentoo.org napisał(a):
On Sat, 31 Aug 2013, Michał Górny wrote:
And time for a small update.
In git-r3_checkout:
git --no-pager diff --color --stat \
${old_commit_id}..${new_commit_id}
I'd rather omit the --color option, otherwise log files will contain
escape sequences.
I'd rather leave it. The diff is more for pretty-printing anyway, it
shouldn't really matter in the logs.
Also it won't harm to make the unpack location configurable, so can we
please have a variable like EGIT_SOURCEDIR or EGIT_UNPACK_DIR (as it
was called in git.eclass)?
I've added EGIT_CHECKOUT_DIR :).
Will submit the new version and a diff against v2 in a minute.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] git-r3: initial draft for review [v3]
A few more changes.
1. Added EGIT_CHECKOUT_DIR to control the place where stuff is checked
out.
2. Moved the defaults from src_fetch() and src_unpack()
into git-r3_fetch() and git-r3_checkout(). This makes using them
easier, like:
git-r3_fetch http://repo1
git-r3_fetch http://repo2
git-r3_checkout http://repo1
git-r3_checkout http://repo2 ${S}/foo
3. Added prototype pkg_isuptodate() function [bug 482666 [1]].
(I will update it when we decide on how the func should be named :))
As an additional testing tool, I attached the version of git-r3
converted to git-2 compatible API. IOW, a drop-in replacement that you
could use to test the new eclass internals with API almost fully
compatible with the old one.
[1]:https://bugs.gentoo.org/show_bug.cgi?id=482666
--
Best regards,
Michał Górny
diff --git a/gx86/eclass/git-r3.eclass b/gx86/eclass/git-r3.eclass
index d56c818..84c04c7 100644
--- a/gx86/eclass/git-r3.eclass
+++ b/gx86/eclass/git-r3.eclass
@@ -71,6 +71,12 @@ if [[ ! ${_GIT_R3} ]]; then
#
# It can be overriden via env using ${PN}_LIVE_COMMIT variable.
+# @ECLASS-VARIABLE: EGIT_CHECKOUT_DIR
+# @DESCRIPTION:
+# The directory to check the git sources out to.
+#
+# EGIT_CHECKOUT_DIR=${WORKDIR}/${P}
+
# @ECLASS-VARIABLE: EGIT_NONSHALLOW
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -94,8 +100,6 @@ _git-r3_env_setup() {
livevar=${esc_pn}_LIVE_REPO
EGIT_REPO_URI=${!livevar:-${EGIT_REPO_URI}}
- [[ ${EGIT_REPO_URI} ]] \
- || die EGIT_REPO_URI must be set to a non-empty value
[[ ${!livevar} ]] \
ewarn Using ${livevar}, no support will be provided
@@ -209,26 +213,44 @@ _git-r3_set_submodules() {
}
# @FUNCTION: git-r3_fetch
-# @USAGE: repo-uri remote-ref local-id
+# @USAGE: [repo-uri [remote-ref [local-id]]]
# @DESCRIPTION:
-# Fetch new commits to the local clone of repository. repo-uri follows
-# the syntax of EGIT_REPO_URI and may list multiple (fallback) URIs.
-# remote-ref specifies the remote ref to fetch (branch, tag
-# or commit). local-id specifies an identifier that needs to uniquely
-# identify the fetch operation in case multiple parallel merges used
-# the git repo. local-id usually involves using CATEGORY, PN and SLOT.
+# Fetch new commits to the local clone of repository.
+#
+# repo-uri specifies the repository URIs to fetch from, as a space-
+# -separated list. The first URI will be used as repository group
+# identifier and therefore must be used consistently. When not
+# specified, defaults to ${EGIT_REPO_URI}.
#
-# The fetch operation will only affect the local storage. It will not
-# touch the working copy. If the repository contains submodules, they
-# will be fetched recursively as well.
+# remote-ref specifies the remote ref or commit id to fetch.
+# It is preferred to use 'refs/heads/branch-name' for branches
+# and 'refs/tags/tag-name' for tags. Other options are 'HEAD'
+# for upstream default branch and hexadecimal commit SHA1. Defaults
+# to the first of EGIT_COMMIT, EGIT_BRANCH or literal 'HEAD' that
+# is set to a non-null value.
+#
+# local-id specifies the local branch identifier that will be used to
+# locally store the fetch result. It should be unique to multiple
+# fetches within the repository that can be performed at the same time
+# (including parallel merges). It defaults to ${CATEGORY}/${PN}/${SLOT}.
+# This default should be fine unless you are fetching multiple trees
+# from the same repository in the same ebuild.
+#
+# The fetch operation will affect the EGIT_STORE only. It will not touch
+# the working copy, nor export any environment variables.
+# If the repository contains submodules, they will be fetched
+# recursively.
git-r3_fetch() {
debug-print-function ${FUNCNAME} $@
- local repos=( ${1} )
- local remote_ref=${2}
- local local_id=${3}
+ local repos=( ${1:-${EGIT_REPO_URI}} )
+ local branch=${EGIT_BRANCH:+refs/heads/${EGIT_BRANCH}}
+ local remote_ref=${2:-${EGIT_COMMIT:-${branch:-HEAD}}}
+ local local_id=${3:-${CATEGORY}/${PN}/${SLOT}}
local local_ref=refs/heads/${local_id}/__main__
+ [[ ${repos[@]} ]] || die No URI provided and EGIT_REPO_URI unset
+
local -x GIT_DIR
_git-r3_set_gitdir ${repos[0]}
@@ -282,7 +304,7 @@ git-r3_fetch() {
if [[ ${is_branch} ]]; then
ref_param+=( -f ${remote_ref}:${local_id}/__main__ )
else
-ref_param+=( ${remote_ref} )
+ref_param+=( refs/tags/${remote_ref} )
fi
fi
@@ -331,22 +353,31 @@ git-r3_fetch() {
}
# @FUNCTION: git-r3_checkout
-# @USAGE: repo-uri local-id path
+# @USAGE: [repo-uri [checkout-path [local-id]]]
# @DESCRIPTION:
-# Check the previously fetched commit out to path (usually
-# ${WORKDIR}/${P}). repo-uri follows the syntax of EGIT_REPO_URI
-# and will be used to re-construct the local storage path. local-id
-# is the unique identifier used for the fetch operation and will
-# be used to obtain the proper commit.
+# Check the previously fetched tree to the working copy.
+#
+# repo-uri specifies the repository URIs, as a
Re: How to find a mentor, WAS: [gentoo-dev] rfc: stabilization policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/31/2013 01:29 PM, Jeroen Roovers wrote: On Sat, 31 Aug 2013 12:37:58 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: I know we are a little OT here but the fifth type of recruit is Yes. someone who is very excited, very dedicated, and completely unable to find a mentor. That is where I was for a long time, no one seemed to have the time to mentor me. Your recruitment bug disagrees with you here in that you had a mentor right from the start. The netmon@g.o alias never saw mail from you before your recruitment bug was openend, so how could anyone have known you were trying to attract a mentor and do netmon stuff? I don't see any mail on gentoo-dev or gentoo-project either. There are exactly *nill* bugs that you reported and were (subsequently) CC'd or Assigned to netmon@g.o. You have only yourself to blame. Always a pleasure my friend. - -ZC jer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSImbCAAoJEKXdFCfdEflKi1sP/1lXGfpuM6u55OcAtvhiQFE4 CL5Zff1vHdLXv1/3JOz9WyVn6D5cmo2zF0Da3IIVYfbnEIU7TDTkdGUrGz/xnTJi wjbmbLQqxIrB5HYMMHVoa7JFsotkV8c4Tnwg2J81HcuQOQpJMb19xlkLHI0fNbrh 8r8Ac2MPGDdx3kwlq7K5zi85scYXGBJN7rR4Ok4y01AGZlrKLan2GH473/eoE8DD 8iLcm9tc2fvN/PWtAO2J0UvpqPbQOx9DF0ttWzVCA/RV/KAtf90p3Exf+uWCy8ru HHCxlo4hG9q3q5ehuJMYXw6cqql5RIB7s6HeJKM9lFXukaOxmW7+xiqo0ne22ePD Novpuip4rd5Brir2QKDLMPu8feQ+PJwkQU+U/q/K6KsSrTT2AYVnZR3SuiykjxG6 4AjBMF4KLVWLhOcYlmtCTg0XWBwqyN7+KBfiAVOKBwX0NZcUp8ILnd0C34I/Cqp+ YGPlY2JCpeWCU4XVJo++RhOtNZP9pnPFATcW+a2bdjMfTOQ9Z7Sjy3bn8r9d1TMe PMLEwVWKQkoreK8w1MNKoxU1x2UGkj82Fal/WEf8OLXev6hdzZOZ1tb/S91KRZT6 OoN7zQy8TpkFqqbNWRsIao4J6V9kW+4RKMCTAJKSqH/Ere1AoJje/WSkly+vuL++ SIVKdElbXczHu482qm6W =aN4N -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: stabilization policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/31/2013 03:57 PM, Tom Wijsman wrote: On Sat, 31 Aug 2013 20:45:00 +0200 Pacho Ramos pa...@gentoo.org wrote: El sáb, 31-08-2013 a las 12:37 -0400, Rick Zero_Chaos Farina escribió: [...] I know we are a little OT here but the fifth type of recruit is someone who is very excited, very dedicated, and completely unable to find a mentor. That is where I was for a long time, no one seemed to have the time to mentor me. Personally I think that is a big issue in the growth of gentoo, if we all take a little time out to be mentors there will be more gentoo devs and we will get more done. -ZC I guess we should have a official contact or mail alias to let them contact. If they don't even contact me, I cannot know about them and then mentor them :/ Ah, I like this idea better than the list on Gentoo Wiki I was trying to approach; the only downside I can imagine if it were a single person that might not respond in time (busy / devaway / MIA), so I think we should at least aim to make it a mail alias with multiple persons. We could then list people on some project page; but, only their forenames or nicknames and not their actual full name and e-mail such that their private details can stay private if they wish to. I remember actively seeking out mentors and recruiters on irc for a while and not getting very far. I think that exposing recruitment to a wider audience than just the recruiters is a good idea, why limit ourselves to their bandwidth? This isn't a remark on the performance of the recruiters, just a note that more people means more bandwidth. I like the idea of having a wiki page of people willing to be mentors for each area (or in general). - -ZC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSImdFAAoJEKXdFCfdEflKq+cP+gIhD2zAR6CnVFVx7hmYvPKa n8Jkg5oCPgchqVPN3AtDqPXwTELSPXTasRJCToaembKYuhPiyO6py/dpo6nIeg/P 4WiLZb+ehCSWAUBMmAemsDoL3WftwrV9w6h1bWBytpbrJ6YZEyumVvHNqMi3r7vI +k54LZc+uurUEHFtPP6SC6kCHj9n0lD/4Biq1lsY/vwZFViHzuBhnTHBYBohy4lo rkB2/k/KvrJ6F9MXfc87A/PUxkU29+WKiul9A9te/X97QheeXXWptI4gEYFevVgT aUP8AfaY0YAD1+RpjyxDPxJ4cTqcL38Wic8ql6pzlV9nwAnN3/fHFQEKJ477UWO4 YLGkdQ0BX4y0WkJH0H5fi3zuU80iHvLw0I0U1rVOP861IrlYxKMPuXUn6F1vGCpq Huzx7pbLcLE0GTYU6Sq5Li4zdMxW7Lre2oqIAD9smj1Fx2VpQp35lFI01TKfAbdb dP08EBfI/c15C6O8v1UooDYjwM7JV1EjoZW+OcPO8rLdahakzS6VhTs6JRMKH+UM X1xqX1Grj5dRUIt2KHGPtCxHAI9VuMQqWDNEv8qmDCzenL4WOcd2TCYL5HNofAbH lWJdKYL3m6OhEVH8e7qaOIbm0hShJBqY90kJWbyowJgbPSllaPepbBNuys3iq4dM eToDKW2TXa4ELG6Xc5vl =eFsz -END PGP SIGNATURE-
Re: [gentoo-dev] Moving more arches to dev profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/22/2013 07:24 AM, Rich Freeman wrote: On Thu, Aug 22, 2013 at 6:19 AM, Markos Chandras hwoar...@gentoo.org wrote: On 22 August 2013 11:01, Rich Freeman ri...@gentoo.org wrote: I think the result of a policy like this would be that stable keywords would get dropped on most peripheral packages, but system packages might still keep them. What's the point of that? Most users need more than what @system provides so after they deploy the 'stable' stage3 they will start pulling ~arch packages that were never tested against the stable tree. It so much better if stage3 was also ~arch. Do we actually have examples of this happening? I've never had problems with a mix of stable and ~arch keywords. Granted, I'm not running ~arch on most libs. I've seen lots of talk about stable being less reliable than ~arch, and ~arch applications on a stable core being unreliable, but I've never actually seen any real evidence that either is true. Granted, I'm not necessarily expecting a scientific study, but I haven't even heard anecdotes. I can't offer much personally - I only really use stable to any extent and I find it works just fine other than the occasional need to unmask something. I unmask/keyword things as needed for Pentoo and I can't say I've ever noticed a lack of stability due to it. I have a (mostly) stable base of @system packages and key things like DE's most of the time, but I also randomly mix in an ~arch package or two when I need to. Almost all of the security tools I put on Pentoo are ~arch, and many of them pull in some random ~arch libs, etc. I can't say I've never had an issue but as long as we all keep the deps are correct as possible it really isn't an issue. Just my $0.02 - -ZC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSIpI3AAoJEKXdFCfdEflKbHUP/RIPo/Z28yv627LU52VlQ9aP +GkEcCEi8Ae55GHaTvLWQqc1Qn03jqffKKp383XN3CyOp1dpQAFsgygcP29FJWTk KwXQtoSrOPrdt2lXsm3CEqE+NFD1SpuycZ/7nu/W1bhEgML7XdmAKKOwdfX/5FpK WVU4pXoU7it2/hCkScOBTGyjb8ULOKUmX6JH9JG1D2vGk2PAulHpAyD1ovlQYZTL lBWkYh6q8Bwf4aTPksmBc6ADfp4EmNJdh018l4OEyrj9uCyaXFB6BmHlMZJMCvk9 jBJngTj5driIhlPjVmyHbZvRcjbfyJskpUAbeDhQ1R+XSyx2hGLRPCEl66XvYpcQ aCFfYCncyvqPRR7Hcfh+xlOsXZMQZFTJSsFriudByC9Q/5V0mpL7F4OWUDsmDqRD l4k1MERDlbXTBfBVEaPTYsS5KtHZD+mYlERO+hmmJCjCB2WDMfE6Y1ItnQjN4Khh qZzeTm9UyHg0iViGQ6Fezt+ahMhYVVLZKm8a9n3J10AOiDjtsCPhDR/itH/ndNL3 tFir2pG/7cWisLHAISPhKO/e34liU/+QC1RHLxxGpaHciBYJISATMnQzqfv59eHL 3WUEMSOo6kTTEdIdTerMo3k0mZiILALACrwKcoK7lBhNrmyoPQynjKUqsw+Ry4S+ oPPZD+G+GEjW2XKZTZFk =5WWm -END PGP SIGNATURE-
Re: [gentoo-dev] Moving more arches to dev profiles
Am Sonntag, 1. September 2013, 03:02:47 schrieb Rick Zero_Chaos Farina: On 08/22/2013 07:24 AM, Rich Freeman wrote: On Thu, Aug 22, 2013 at 6:19 AM, Markos Chandras hwoar...@gentoo.org wrote: On 22 August 2013 11:01, Rich Freeman ri...@gentoo.org wrote: I think the result of a policy like this would be that stable keywords would get dropped on most peripheral packages, but system packages might still keep them. What's the point of that? Most users need more than what @system provides so after they deploy the 'stable' stage3 they will start pulling ~arch packages that were never tested against the stable tree. It so much better if stage3 was also ~arch. Do we actually have examples of this happening? I've never had problems with a mix of stable and ~arch keywords. Granted, I'm not running ~arch on most libs. I've seen lots of talk about stable being less reliable than ~arch, and ~arch applications on a stable core being unreliable, but I've never actually seen any real evidence that either is true. Granted, I'm not necessarily expecting a scientific study, but I haven't even heard anecdotes. I can't offer much personally - I only really use stable to any extent and I find it works just fine other than the occasional need to unmask something. I unmask/keyword things as needed for Pentoo and I can't say I've ever noticed a lack of stability due to it. I have a (mostly) stable base of @system packages and key things like DE's most of the time, but I also randomly mix in an ~arch package or two when I need to. Almost all of the security tools I put on Pentoo are ~arch, and many of them pull in some random ~arch libs, etc. I can't say I've never had an issue but as long as we all keep the deps are correct as possible it really isn't an issue. As a sidenote, that is exactly what --autounmask-write does as well. Meaning whoever uses this very nifty portage feature will end up with such a mix of stable and testing as well. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
