[gentoo-dev] new eclass: xdg and xdg-utils as a replacement for fdo-mime
This is an attempt to fix bug #208047 [1] and bug #444568 [2]
Current fdo-mime eclass is often not used when it should be. I suppose
this is partly because one has to think too much about whether it is
needed or not and what to do with the functions.
The proposed solution is to not have to worry about it and just inherit
it when you have any kind of XDG specifications support and let the
exported phases do their job in a similar fashion to the gnome
eclasses.
For now, this covers .desktop and shared mime-info files and creating
base directory for packages that rely on it one way or another.
This helps solve problems like bug #545128 [3] and others that have
been covered by previous work resulting in gnome2_environment_reset
function and similar in other eclasses (cmake-utils, gstreamer, kde4
-base, mono, mono-env, qt4-*).
[1] [Bug 208047] fdo-mime.eclass should depend on desktop-file-utils
https://bugs.gentoo.org/show_bug.cgi?id=208047
[2] [Bug 444568] [Future EAPI] Export XDG_* variables in ebuild
environment
https://bugs.gentoo.org/show_bug.cgi?id=444568
[3] [Bug 545128] media-sound/pulseaudio-6.0 XDG_RUNTIME_DIR
(/run/user/1000) is not owned by us (uid 0)
https://bugs.gentoo.org/show_bug.cgi?id=545128
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: xdg.eclass
# @MAINTAINER:
# freedesktop-b...@gentoo.org
# @AUTHOR:
# Original author: Gilles Dartiguelongue e...@gentoo.org
# @BLURB: Provides phases for XDG compliant packages.
# @DESCRIPTION:
# Utility eclass to update the desktop and shared mime info as laid
# out in the freedesktop specs implementations
inherit xdg-utils
case ${EAPI:-0} in
4|5)
EXPORT_FUNCTIONS src_prepare pkg_preinst pkg_postinst pkg_postrm
;;
*) die EAPI=${EAPI} is not supported ;;
esac
DEPEND=
dev-util/desktop-file-utils
x11-misc/shared-mime-info
# @FUNCTION: xdg_src_prepare
# @DESCRIPTION:
# Prepare sources to work with XDG standards.
xdg_src_prepare() {
# Prepare XDG base directories
export XDG_DATA_HOME=${T}/.local/share
export XDG_CONFIG_HOME=${T}/.config
export XDG_CACHE_HOME=${T}/.cache
export XDG_RUNTIME_DIR=${T}/run
mkdir -p ${XDG_DATA_HOME} ${XDG_CONFIG_HOME} ${XDG_CACHE_HOME} \
${XDG_RUNTIME_DIR}
# This directory needs to be owned by the user, and chmod 0700
# http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
chmod 0700 ${XDG_RUNTIME_DIR}
}
# @FUNCTION: xdg_pkg_preinst
# @DESCRIPTION:
# Finds .desktop and mime info files for later handling in pkg_postinst
xdg_pkg_preinst() {
xdg_desktopfiles_savelist
xdg_mimeinfo_savelist
}
# @FUNCTION: xdg_pkg_postinst
# @DESCRIPTION:
# Handle desktop and mime info database updates.
xdg_pkg_postinst() {
xdg_desktop_database_update
xdg_mimeinfo_database_update
}
# @FUNCTION: xdg_pkg_postrm
# @DESCRIPTION:
# Handle desktop and mime info database updates.
xdg_pkg_postrm() {
xdg_desktop_database_update
xdg_mimeinfo_database_update
}
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: xdg-utils.eclass
# @MAINTAINER:
# gn...@gentoo.org
# @AUTHOR:
# Original author: Gilles Dartiguelongue e...@gentoo.org
# @BLURB: Auxiliary functions commonly used by XDG compliant packages.
# @DESCRIPTION:
# This eclass provides a set of auxiliary functions needed by most XDG
# compliant packages.
# It provides XDG stack related functions such as:
# * XDG .desktop files cache management
# * XDG mime information database management
case ${EAPI:-0} in
4|5) ;;
*) die EAPI=${EAPI} is not supported ;;
esac
# @ECLASS-VARIABLE: DESKTOP_DATABASE_UPDATE_BIN
# @INTERNAL
# @DESCRIPTION:
# Path to update-desktop-database
: ${DESKTOP_DATABASE_UPDATE_BIN:=/usr/bin/update-desktop-database}
# @ECLASS-VARIABLE: DESKTOP_DATABASE_DIR
# @INTERNAL
# @DESCRIPTION:
# Directory where .desktop files database is stored
: ${DESKTOP_DATABASE_DIR=/usr/share/applications}
# @ECLASS-VARIABLE: MIMEINFO_DATABASE_UPDATE_BIN
# @INTERNAL
# @DESCRIPTION:
# Path to update-desktop-database
: ${MIMEINFO_DATABASE_UPDATE_BIN:=/usr/bin/update-mime-database}
# @ECLASS-VARIABLE: MIMEINFO_DATABASE_DIR
# @INTERNAL
# @DESCRIPTION:
# Directory where .desktop files database is stored
: ${MIMEINFO_DATABASE_DIR:=/usr/share/mime}
# @FUNCTION: xdg_desktopfiles_savelist
# @DESCRIPTION:
# Find the .desktop files about to be installed and save their location
# in the XDG_ECLASS_DESKTOPFILES environment variable.
# This function should be called from pkg_preinst.
xdg_desktopfiles_savelist() {
pushd ${D} /dev/null
export XDG_ECLASS_DESKTOPFILES=$(find 'usr/share/applications' -type f
2 /dev/null)
popd
Re: [gentoo-dev] new eclass: xdg and xdg-utils as a replacement for fdo-mime
On Wed, Jun 10, 2015 at 10:12 AM, Gilles Dartiguelongue e...@gentoo.org wrote:
This is an attempt to fix bug #208047 [1] and bug #444568 [2]
Current fdo-mime eclass is often not used when it should be. I suppose
this is partly because one has to think too much about whether it is
needed or not and what to do with the functions.
The proposed solution is to not have to worry about it and just inherit
it when you have any kind of XDG specifications support and let the
exported phases do their job in a similar fashion to the gnome
eclasses.
For now, this covers .desktop and shared mime-info files and creating
base directory for packages that rely on it one way or another.
This helps solve problems like bug #545128 [3] and others that have
been covered by previous work resulting in gnome2_environment_reset
function and similar in other eclasses (cmake-utils, gstreamer, kde4
-base, mono, mono-env, qt4-*).
xdg_desktopfiles_savelist() {
pushd ${D} /dev/null
export XDG_ECLASS_DESKTOPFILES=$(find 'usr/share/applications' -type f 2
/dev/null)
popd /dev/null
}
Why are you sending stderr from pushd/popd to /dev/null? If they fail,
we want to see that in the log. As well, they should probably die, or
at least return from the function with a non-zero status.
This may also need some adjusting to work on prefix, but I will leave
that for someone else to figure out.
Re: [gentoo-dev] new eclass: go-live.eclass for handling go live ebuilds
On 08 Jun 2015 14:38, William Hubbs wrote: # Copyright 2015 Gentoo Foundation normally we use the header from skel.ebuild everywhere # We depend on dev-vcs/git since it is the most used vcs for Go # packages. However we will not depend on all vcs's Go supports at the # eclass level. If your package, or one of its dependencies, uses # another vcs, please depend on it directly. DEPEND==dev-lang/go-1.4.2 dev-vcs/git that really isn't what i was suggesting nor does it seem to be justified ? -mike signature.asc Description: Digital signature
Re: [gentoo-dev] new eclass: xdg and xdg-utils as a replacement for fdo-mime
Le mercredi 10 juin 2015 à 11:04 -0400, Mike Gilbert a écrit :
On Wed, Jun 10, 2015 at 10:12 AM, Gilles Dartiguelongue
e...@gentoo.org wrote:
This is an attempt to fix bug #208047 [1] and bug #444568 [2]
Current fdo-mime eclass is often not used when it should be. I
suppose
this is partly because one has to think too much about whether it
is
needed or not and what to do with the functions.
The proposed solution is to not have to worry about it and just
inherit
it when you have any kind of XDG specifications support and let the
exported phases do their job in a similar fashion to the gnome
eclasses.
For now, this covers .desktop and shared mime-info files and
creating
base directory for packages that rely on it one way or another.
This helps solve problems like bug #545128 [3] and others that have
been covered by previous work resulting in gnome2_environment_reset
function and similar in other eclasses (cmake-utils, gstreamer,
kde4
-base, mono, mono-env, qt4-*).
xdg_desktopfiles_savelist() {
pushd ${D} /dev/null
export XDG_ECLASS_DESKTOPFILES=$(find 'usr/share/applications'
-type f 2 /dev/null)
popd /dev/null
}
Why are you sending stderr from pushd/popd to /dev/null? If they
fail,
we want to see that in the log. As well, they should probably die, or
at least return from the function with a non-zero status.
This may also need some adjusting to work on prefix, but I will leave
that for someone else to figure out.
This is blind copy-paste from gnome2-utils functions, I will clean that
out.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Impl. egetent in user.eclass using script from sys-apps/getent?
I wonder if it would be possible to use the script from
sys-apps/getent(included below)
to impl. getent in user.eclass instead of using glibc's getent? I cannot see
any downside, is there one?
This would help a lot(just seed your groups/users is in ROOT/etc/{passwd,group
...} first)
when cross building or ROOT != / as it would be trivial for the script to
respect ROOT/EPREFIX
sys-apps/getent:
#!/bin/sh
#
# Closely (not perfectly) emulate the behavior of glibc's getent utility
#
#passwd|shadow|group|aliases|hosts|networks|ethers|netgroup|protocols|services|rpc
# only returns the first match (by design)
# dns based search is not supported (hosts,networks)
# case-insensitive matches not supported (ethers; others?)
# may return false-positives (hosts,protocols,rpc,services,ethers)
[ -z $PATH ] PATH=/bin:/usr/bin || PATH=${PATH}:/bin:/usr/bin export
PATH
file=/etc/$1
case $1 in
passwd|group)
match=^$2:\|^[^:]*:[^:]*:$2: ;;
shadow)
match=^$2: ;;
networks|netgroup)
match=^[[:space:]]*$2\ ;;
hosts|protocols|rpc|services|ethers)
match=\$2\ ;;
aliases)
match=^[[:space:]]*$2[[:space:]]*: ;;
|-h|--help)
echo USAGE: $0 database [key]
exit 0 ;;
*)
echo $0: Unknown database: $1 12
exit 1 ;;
esac
if [ ! -f $file ] ; then
echo $0: Could not find database file for $1 12
exit 1
fi
if [ $# -eq 1 ] ; then
exec cat $file
else
sed s/#.*//; /$match/q; d $file | grep . || exit 2
fi
[gentoo-portage-dev] [PATCH] require PORTAGE_{BIN,PYM}_PATH not be cleared
Rather than hardcode a full path everywhere as a fallback, assume the
value is always set to the right location. The current path isn't the
right place anymore already.
If it turns out we want to support this scenario, we can do it via a
bunch of bootstrapping (and symlinked) files.
---
bin/ebuild-helpers/die| 2 +-
bin/ebuild-helpers/dobin | 2 +-
bin/ebuild-helpers/doconfd| 2 +-
bin/ebuild-helpers/dodir | 2 +-
bin/ebuild-helpers/dodoc | 2 +-
bin/ebuild-helpers/doenvd | 2 +-
bin/ebuild-helpers/doexe | 2 +-
bin/ebuild-helpers/dohard | 2 +-
bin/ebuild-helpers/doheader | 2 +-
bin/ebuild-helpers/dohtml | 6 ++
bin/ebuild-helpers/doinfo | 2 +-
bin/ebuild-helpers/doinitd| 2 +-
bin/ebuild-helpers/doins | 2 +-
bin/ebuild-helpers/dolib | 2 +-
bin/ebuild-helpers/doman | 2 +-
bin/ebuild-helpers/domo | 2 +-
bin/ebuild-helpers/dosbin | 2 +-
bin/ebuild-helpers/dosed | 2 +-
bin/ebuild-helpers/dosym | 2 +-
bin/ebuild-helpers/ecompress | 2 +-
bin/ebuild-helpers/ecompressdir | 2 +-
bin/ebuild-helpers/elog | 2 +-
bin/ebuild-helpers/emake | 2 +-
bin/ebuild-helpers/fowners| 2 +-
bin/ebuild-helpers/fperms | 2 +-
bin/ebuild-helpers/keepdir| 2 +-
bin/ebuild-helpers/newins | 2 +-
bin/ebuild-helpers/portageq | 4 +---
bin/ebuild-helpers/prepall| 2 +-
bin/ebuild-helpers/prepalldocs| 2 +-
bin/ebuild-helpers/prepallinfo| 2 +-
bin/ebuild-helpers/prepallman | 2 +-
bin/ebuild-helpers/prepallstrip | 2 +-
bin/ebuild-helpers/prepinfo | 2 +-
bin/ebuild-helpers/prepman| 2 +-
bin/ebuild-helpers/prepstrip | 3 +--
bin/ebuild-helpers/unprivileged/chown | 4 ++--
bin/ebuild-helpers/xattr/install | 2 --
bin/ebuild-ipc| 4 +---
bin/ebuild.sh | 3 ---
bin/helper-functions.sh | 2 +-
bin/isolated-functions.sh | 2 +-
bin/misc-functions.sh | 2 +-
43 files changed, 43 insertions(+), 55 deletions(-)
diff --git a/bin/ebuild-helpers/die b/bin/ebuild-helpers/die
index 9869141..5c6b1d2 100755
--- a/bin/ebuild-helpers/die
+++ b/bin/ebuild-helpers/die
@@ -2,6 +2,6 @@
# Copyright 2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-source ${PORTAGE_BIN_PATH:-/usr/lib/portage/bin}/isolated-functions.sh
+source ${PORTAGE_BIN_PATH}/isolated-functions.sh || exit 1
die $@
exit 1
diff --git a/bin/ebuild-helpers/dobin b/bin/ebuild-helpers/dobin
index 0ba1eb0..9f4d73d 100755
--- a/bin/ebuild-helpers/dobin
+++ b/bin/ebuild-helpers/dobin
@@ -2,7 +2,7 @@
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-source ${PORTAGE_BIN_PATH:-/usr/lib/portage/bin}/isolated-functions.sh
+source ${PORTAGE_BIN_PATH}/isolated-functions.sh || exit 1
if [[ $# -lt 1 ]] ; then
__helpers_die ${0##*/}: at least one argument needed
diff --git a/bin/ebuild-helpers/doconfd b/bin/ebuild-helpers/doconfd
index 1baa3ed..926c318 100755
--- a/bin/ebuild-helpers/doconfd
+++ b/bin/ebuild-helpers/doconfd
@@ -3,7 +3,7 @@
# Distributed under the terms of the GNU General Public License v2
if [[ $# -lt 1 ]] ; then
- source ${PORTAGE_BIN_PATH:-/usr/lib/portage/bin}/isolated-functions.sh
+ source ${PORTAGE_BIN_PATH}/isolated-functions.sh || exit 1
__helpers_die ${0##*/}: at least one argument needed
exit 1
fi
diff --git a/bin/ebuild-helpers/dodir b/bin/ebuild-helpers/dodir
index e03ba9a..eed2c8b 100755
--- a/bin/ebuild-helpers/dodir
+++ b/bin/ebuild-helpers/dodir
@@ -2,7 +2,7 @@
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-source ${PORTAGE_BIN_PATH:-/usr/lib/portage/bin}/isolated-functions.sh
+source ${PORTAGE_BIN_PATH}/isolated-functions.sh || exit 1
if ! ___eapi_has_prefix_variables; then
ED=${D}
diff --git a/bin/ebuild-helpers/dodoc b/bin/ebuild-helpers/dodoc
index 6ccf0a4..75029eb 100755
--- a/bin/ebuild-helpers/dodoc
+++ b/bin/ebuild-helpers/dodoc
@@ -2,7 +2,7 @@
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-source ${PORTAGE_BIN_PATH:-/usr/lib/portage/bin}/isolated-functions.sh
+source ${PORTAGE_BIN_PATH}/isolated-functions.sh || exit 1
if ___eapi_dodoc_supports_-r; then
__PORTAGE_HELPER='dodoc' exec doins $@
diff --git a/bin/ebuild-helpers/doenvd b/bin/ebuild-helpers/doenvd
index 67bb934..eb31f37 100755
--- a/bin/ebuild-helpers/doenvd
+++ b/bin/ebuild-helpers/doenvd
@@ -3,7 +3,7 @@
# Distributed under the terms of the GNU General Public License v2
if [[ $# -lt
Re: [gentoo-portage-dev] [PATCH v4] xattr: centralize the various shims in one place
On 30 May 2015 16:59, Mike Frysinger wrote: Rather than each module implementing its own shim around the various methods for accessing extended attributes, start a dedicated module that exports a consistent API. ping ... are people ok with this change in API ? -mike signature.asc Description: Digital signature
[gentoo-dev] RFC: ban EAPI 1
Hi, The number of EAPI 1 ebuilds in the Portage tree has decreased to a total of 60, corresponding to 0.16 %. We briefly discussed in the QA team if we should demote EAPI 1 in layout.conf from eapis-deprecated to eapis-banned. This would have the consequence that repoman would refuse to commit packages containing such ebuilds. AFAICS there would be no impact on users. What do you think? Ulrich pgp85llJssNeT.pgp Description: PGP signature
Re: [gentoo-dev] Impl. egetent in user.eclass using script from sys-apps/getent?
On 6/10/15 1:52 PM, Mike Gilbert wrote: On Wed, Jun 10, 2015 at 12:44 PM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: I wonder if it would be possible to use the script from sys-apps/getent(included below) to impl. getent in user.eclass instead of using glibc's getent? I cannot see any downside, is there one? glibc's getent can get data from any NSS plugin (ie. LDAP, MySQL, etc). Switching to use sys-apps/getent would mean that lookups would only be performed against the local flat files. I added sys-apps/getent for musl and did not expect it to be used by anything else. When I moved that script into sys-libs/musl, I masked getent: # /usr/portage/profiles/package.mask: # Anthony G. Basile bluen...@gentoo.org (14 May 2015) # No longer required by any packages in the tree. # Masked for removal in 30 days. If you want to keep it, we can remove the mask, but it does block against glibc and uclibc. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Impl. egetent in user.eclass using script from sys-apps/getent?
On Wed, Jun 10, 2015 at 11:56 AM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
On Wed, 2015-06-10 at 18:48 +, Robin H. Johnson wrote:
On Wed, Jun 10, 2015 at 04:44:17PM +, Joakim Tjernlund wrote:
I wonder if it would be possible to use the script from
sys-apps/getent(included below)
to impl. getent in user.eclass instead of using glibc's getent? I
cannot see any downside, is there one?
This would help a lot(just seed your groups/users is in
ROOT/etc/{passwd,group ...} first)
when cross building or ROOT != / as it would be trivial for the script
to respect ROOT/EPREFIX
This would totally break when those services come from an NSS provider
other than files or compat.
But does user.eclass support anything but local system users ?
https://github.com/google/nsscache for example.
They are still 'local', but not via files or compat ;0)
-A
There was a non-upstream patch to support NSS on non-root filesystems,
which would probably help a lot more; I haven't seen that original patch
in a while, so here's a very quick and completely untested
re-implementation of it.
In your case, you probably should MAKE sure that regardless of the
system nsswitch settings, the NSS file provider gets used.
Usage: NSS_FILES_ROOT=$ROOT/etc getent -s files passwd ...
Re: [gentoo-dev] Impl. egetent in user.eclass using script from sys-apps/getent?
On Wed, 2015-06-10 at 14:06 -0400, Anthony G. Basile wrote: On 6/10/15 1:52 PM, Mike Gilbert wrote: On Wed, Jun 10, 2015 at 12:44 PM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: I wonder if it would be possible to use the script from sys-apps/getent(included below) to impl. getent in user.eclass instead of using glibc's getent? I cannot see any downside, is there one? glibc's getent can get data from any NSS plugin (ie. LDAP, MySQL, etc). Switching to use sys-apps/getent would mean that lookups would only be performed against the local flat files. I added sys-apps/getent for musl and did not expect it to be used by anything else. When I moved that script into sys-libs/musl, I masked getent: # /usr/portage/profiles/package.mask: # Anthony G. Basile bluen...@gentoo.org (14 May 2015) # No longer required by any packages in the tree. # Masked for removal in 30 days. If you want to keep it, we can remove the mask, but it does block against glibc and uclibc. I think one would have to take the guts of the script and transform it into an egetent eclass function. Your script has done the hard part already so it should be easy to mangle into an eclass fkn. Jocke
Re: [gentoo-dev] Impl. egetent in user.eclass using script from sys-apps/getent?
On Wed, 2015-06-10 at 18:48 +, Robin H. Johnson wrote:
On Wed, Jun 10, 2015 at 04:44:17PM +, Joakim Tjernlund wrote:
I wonder if it would be possible to use the script from
sys-apps/getent(included below)
to impl. getent in user.eclass instead of using glibc's getent? I
cannot see any downside, is there one?
This would help a lot(just seed your groups/users is in
ROOT/etc/{passwd,group ...} first)
when cross building or ROOT != / as it would be trivial for the script to
respect ROOT/EPREFIX
This would totally break when those services come from an NSS provider
other than files or compat.
But does user.eclass support anything but local system users ?
There was a non-upstream patch to support NSS on non-root filesystems,
which would probably help a lot more; I haven't seen that original patch
in a while, so here's a very quick and completely untested
re-implementation of it.
In your case, you probably should MAKE sure that regardless of the
system nsswitch settings, the NSS file provider gets used.
Usage: NSS_FILES_ROOT=$ROOT/etc getent -s files passwd ...
Re: [gentoo-dev] Impl. egetent in user.eclass using script from sys-apps/getent?
On Wed, Jun 10, 2015 at 12:44 PM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: I wonder if it would be possible to use the script from sys-apps/getent(included below) to impl. getent in user.eclass instead of using glibc's getent? I cannot see any downside, is there one? glibc's getent can get data from any NSS plugin (ie. LDAP, MySQL, etc). Switching to use sys-apps/getent would mean that lookups would only be performed against the local flat files.
Re: [gentoo-dev] Impl. egetent in user.eclass using script from sys-apps/getent?
On Wed, Jun 10, 2015 at 04:44:17PM +, Joakim Tjernlund wrote:
I wonder if it would be possible to use the script from
sys-apps/getent(included below)
to impl. getent in user.eclass instead of using glibc's getent? I
cannot see any downside, is there one?
This would help a lot(just seed your groups/users is in
ROOT/etc/{passwd,group ...} first)
when cross building or ROOT != / as it would be trivial for the script to
respect ROOT/EPREFIX
This would totally break when those services come from an NSS provider
other than files or compat.
There was a non-upstream patch to support NSS on non-root filesystems,
which would probably help a lot more; I haven't seen that original patch
in a while, so here's a very quick and completely untested
re-implementation of it.
In your case, you probably should MAKE sure that regardless of the
system nsswitch settings, the NSS file provider gets used.
Usage: NSS_FILES_ROOT=$ROOT/etc getent -s files passwd ...
--
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
nss_files: non-/ root support via env
In building systems eg cross-compile, it can be very useful to run getent on a
different root path.
This is a very rough, completely untested patch to implement it, based on a
patch I recall seeing many years ago, but can't find anywhere not.
Untested-By: Robin H. Johnson robb...@gentoo.org
Original-Author: Robin H. Johnson robb...@gentoo.org
Not-Signed-Off-By: Robin H. Johnson robb...@gentoo.org
diff -Nuar glibc-2.21.orig/nss/nss_files/files-XXX.c glibc-2.21/nss/nss_files/files-XXX.c
--- glibc-2.21.orig/nss/nss_files/files-XXX.c 2015-06-10 11:16:59.282269957 -0700
+++ glibc-2.21/nss/nss_files/files-XXX.c 2015-06-10 11:43:55.582631857 -0700
@@ -38,7 +38,8 @@
#define ENTNAME_r CONCAT(ENTNAME,_r)
-#define DATAFILE /etc/ DATABASE
+#define NSS_FILES_ROOT /etc/
+#define DATAFILE NSS_FILES_ROOT DATABASE
#ifdef NEED_H_ERRNO
# include netdb.h
@@ -75,7 +76,19 @@
if (stream == NULL)
{
- stream = fopen (DATAFILE, rce);
+ char* datafile = DATAFILE;
+ const char* datafile_root;
+ if(datafile_root = secure_getenv(NSS_FILES_ROOT)) {
+#define merged_datafile_len 1024
+ char merged_datafile[merged_datafile_len];
+ strncpy(merged_datafile, datafile_root, merged_datafile_len);
+ strncat(merged_datafile, DATABASE, merged_datafile_len - strlen(merged_datafile));
+ datafile = merged_datafile;
+ /* If we are using a different root to the files, do not cache */
+keep_stream = 0;
+ stayopen = 0;
+ }
+ stream = fopen (datafile, rce);
if (stream == NULL)
status = errno == EAGAIN ? NSS_STATUS_TRYAGAIN : NSS_STATUS_UNAVAIL;
Re: [gentoo-portage-dev] [PATCH v4] xattr: centralize the various shims in one place
On 05/30/2015 01:59 PM, Mike Frysinger wrote: Rather than each module implementing its own shim around the various methods for accessing extended attributes, start a dedicated module that exports a consistent API. --- v4 - merge in recent quickpkg changes - add a XATTRS_WORKS symbol for easy testing - use - with -m when matching all bin/quickpkg | 12 +- bin/xattr-helper.py | 11 +- pym/portage/dbapi/vartree.py | 10 +- pym/portage/tests/util/test_xattr.py | 178 +++ pym/portage/util/_xattr.py | 228 +++ pym/portage/util/movefile.py | 100 --- pym/portage/util/xattr.py| 20 --- 7 files changed, 441 insertions(+), 118 deletions(-) create mode 100644 pym/portage/tests/util/test_xattr.py create mode 100644 pym/portage/util/_xattr.py delete mode 100644 pym/portage/util/xattr.py LGTM, except this one line is indented with spaces instead of tabs in vartree.py: def tar_contents(contents, root, tar, protect=None, onProgress=None, - xattr=False): + xattrs=False): -- Thanks, Zac
Re: [gentoo-dev] new eclass: go-live.eclass for handling go live ebuilds
On Wed, Jun 10, 2015 at 11:53:28AM -0400, Mike Frysinger wrote: On 08 Jun 2015 14:38, William Hubbs wrote: # Copyright 2015 Gentoo Foundation normally we use the header from skel.ebuild everywhere Ok, I can fix that. # We depend on dev-vcs/git since it is the most used vcs for Go # packages. However we will not depend on all vcs's Go supports at the # eclass level. If your package, or one of its dependencies, uses # another vcs, please depend on it directly. DEPEND==dev-lang/go-1.4.2 dev-vcs/git that really isn't what i was suggesting nor does it seem to be justified ? Please clarify -- what are you suggesting then? The options as I see them are to either: 1. try to pick the most common vcs and depend on it. 2. depend on all vcs's go supports (git, mercurial, svn and bzr). 3. depend on no vcs's and leave it up to ebuild authors to pull them in if they choose, although they would have the same issue -- not knowing for sure which type of hosting their packages or any of their packages' dependencies use. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] Impl. egetent in user.eclass using script from sys-apps/getent?
On 6/10/15 2:49 PM, Joakim Tjernlund wrote: On Wed, 2015-06-10 at 14:06 -0400, Anthony G. Basile wrote: On 6/10/15 1:52 PM, Mike Gilbert wrote: On Wed, Jun 10, 2015 at 12:44 PM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: I wonder if it would be possible to use the script from sys-apps/getent(included below) to impl. getent in user.eclass instead of using glibc's getent? I cannot see any downside, is there one? glibc's getent can get data from any NSS plugin (ie. LDAP, MySQL, etc). Switching to use sys-apps/getent would mean that lookups would only be performed against the local flat files. I added sys-apps/getent for musl and did not expect it to be used by anything else. When I moved that script into sys-libs/musl, I masked getent: # /usr/portage/profiles/package.mask: # Anthony G. Basile bluen...@gentoo.org (14 May 2015) # No longer required by any packages in the tree. # Masked for removal in 30 days. If you want to keep it, we can remove the mask, but it does block against glibc and uclibc. I think one would have to take the guts of the script and transform it into an egetent eclass function. Your script has done the hard part already so it should be easy to mangle into an eclass fkn. Jocke To be clear, not mine, but from uclibc. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] RFC: ban EAPI 1
On Wed, 10 Jun 2015 22:43:10 +0200 Ulrich Mueller u...@gentoo.org wrote: We briefly discussed in the QA team if we should demote EAPI 1 in layout.conf from eapis-deprecated to eapis-banned. This would have the consequence that repoman would refuse to commit packages containing such ebuilds. AFAICS there would be no impact on users. What do you think? Java team is fully aware that we make up the bulk of the remainder and we are working to reduce it although other things have a habit of jumping in front. I am due to remove all ia64 keywords from Java packages and this change would mean that I have to address the EAPI of 5 ebuilds first but don't let that stop you. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpsbGyat_DRY.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: ban EAPI 1
On Wed, 10 Jun 2015 22:43:10 +0200 Ulrich Mueller u...@gentoo.org wrote: Hi, The number of EAPI 1 ebuilds in the Portage tree has decreased to a total of 60, corresponding to 0.16 %. We briefly discussed in the QA team if we should demote EAPI 1 in layout.conf from eapis-deprecated to eapis-banned. This would have the consequence that repoman would refuse to commit packages containing such ebuilds. AFAICS there would be no impact on users. What do you think? Ulrich DDOO IIIT ;) + -- Brian Dolbec dolsen
Re: [gentoo-dev] RFC: ban EAPI 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Mittwoch, 10. Juni 2015, 22:43:10 schrieb Ulrich Mueller: We briefly discussed in the QA team if we should demote EAPI 1 in layout.conf from eapis-deprecated to eapis-banned. This would have the consequence that repoman would refuse to commit packages containing such ebuilds. AFAICS there would be no impact on users. I was really looking forward to committing that :))) Do it!!! - -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVeLBZXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5nsMQALGeqB85oc+6zUoZ0/yalQAu 1liVvni0/qTbM5nsQXDE5bfHx8srhI5hzp9zo2veYTqc+MxdFYX2vuACyTaLZEjV v2YtNVlVrildtw7HvIRVUQAeIO5zNlPo/wvtzrKobOwD4iEnC6snTnJbCB0KNBJM kf7wlT57UM4sURt9vNtwkDz4BeAu/Z+hMAS3x2kDopoBfF1518xRLEJgEm3ODf9g eglifcFRJHCvf1lCvZphvqO/zA8VLpPGNeYRjdqvoMRxnIEuTM82r3SnV5KPqJal D9aiGwl+Sj2pK1ne2PLC25N9Q/hxB9V1KWHh2DAwOvRaVsEjOTwn1r2yxc4ngwXy k1xIlRoRgH8x9mMceo4IvklI3O3vS1BBc3Wa1n2RJUDoqfy5SBIwfWEsauXu9xZY mZUCTN5fWOSxDp+lOW7GcZzkzFgzCp7NxJfyLYxvBq2TX5R3LEnfniw3Wg/Boi9z syms29sUa3k2s7Grcy8Gi9JfEjZaod2sq6KPPjhrwaM/zMrmzMdikZ/DGhdXl3rD QHRpJfOGszEcK7TFf2Vkq7ofBeZqf63jtbt/+t935EspEpC/UjL/jgER5JML6GSl 2nJmnEQ8MQDUqNJbMoZyoBv516ftcsrcvQe3VfM0mHFJlClsHytSWHieptbutZZO M1JXLbCfdK6cuamEs4Fx =Vu8c -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: ban EAPI 1
On 6/10/2015 4:43 PM, Ulrich Mueller wrote: Hi, The number of EAPI 1 ebuilds in the Portage tree has decreased to a total of 60, corresponding to 0.16 %. We briefly discussed in the QA team if we should demote EAPI 1 in layout.conf from eapis-deprecated to eapis-banned. This would have the consequence that repoman would refuse to commit packages containing such ebuilds. AFAICS there would be no impact on users. What do you think? Ulrich Make it so.
Re: [gentoo-dev] RFC: ban EAPI 1
Dnia 2015-06-10, o godz. 22:43:10 Ulrich Mueller u...@gentoo.org napisał(a): Hi, The number of EAPI 1 ebuilds in the Portage tree has decreased to a total of 60, corresponding to 0.16 %. We briefly discussed in the QA team if we should demote EAPI 1 in layout.conf from eapis-deprecated to eapis-banned. This would have the consequence that repoman would refuse to commit packages containing such ebuilds. AFAICS there would be no impact on users. What do you think? So be it. -- Best regards, Michał Górny pgp1yG9KkDBcV.pgp Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH v4] xattr: centralize the various shims in one place
On 10 Jun 2015 11:54, Zac Medico wrote: On 05/30/2015 01:59 PM, Mike Frysinger wrote: LGTM, except this one line is indented with spaces instead of tabs in vartree.py: def tar_contents(contents, root, tar, protect=None, onProgress=None, - xattr=False): + xattrs=False): i don't know if we have a standard here. sometimes it's a single tab, sometimes it's spaces to line up. i prefer the latter as that's generally what PEP8 does. -mike signature.asc Description: Digital signature
Re: [gentoo-portage-dev] [PATCH v4] xattr: centralize the various shims in one place
On 06/10/2015 10:39 PM, Mike Frysinger wrote: On 10 Jun 2015 11:54, Zac Medico wrote: On 05/30/2015 01:59 PM, Mike Frysinger wrote: LGTM, except this one line is indented with spaces instead of tabs in vartree.py: def tar_contents(contents, root, tar, protect=None, onProgress=None, - xattr=False): + xattrs=False): i don't know if we have a standard here. sometimes it's a single tab, sometimes it's spaces to line up. i prefer the latter as that's generally what PEP8 does. -mike Ah, ok. The test pass, so guess it's fine that way. -- Thanks, Zac
Re: [gentoo-dev] new eclass: go-live.eclass for handling go live ebuilds
On 06/10/15 11:08, William Hubbs wrote: On Tue, Jun 09, 2015 at 11:34:34PM -0400, Dean Stephens wrote: On 06/08/15 15:38, William Hubbs wrote: All, here is the latest version of this eclass, which I will commit an hour from now if no one has any objections. Thanks, William Not an objection to the eclass as posted, but to the one hour timeout for feedback on a mailing list. While I realize that feedback had already been given and acted upon, bare minimum feedback windows for global mailing lists start at not less than 12 hours and are preferably at least twice that long. This hasn't been committed yet, because I'm considering adding a command to copy the code from EGO_STORE_DIR to WORKDIR after it is downloaded. Is a one line change enough to justify another poasting, or should I just commit once that works? William The answer to that would seem to be prescribed by policy[1]. [1] https://devmanual.gentoo.org/eclass-writing/index.html
Re: [gentoo-dev] new eclass: go-live.eclass for handling go live ebuilds
On Tue, Jun 09, 2015 at 11:34:34PM -0400, Dean Stephens wrote: On 06/08/15 15:38, William Hubbs wrote: All, here is the latest version of this eclass, which I will commit an hour from now if no one has any objections. Thanks, William Not an objection to the eclass as posted, but to the one hour timeout for feedback on a mailing list. While I realize that feedback had already been given and acted upon, bare minimum feedback windows for global mailing lists start at not less than 12 hours and are preferably at least twice that long. This hasn't been committed yet, because I'm considering adding a command to copy the code from EGO_STORE_DIR to WORKDIR after it is downloaded. Is a one line change enough to justify another poasting, or should I just commit once that works? William signature.asc Description: Digital signature
