[gentoo-dev] [PATCH] user-info.eclass: return immediately if db does not exist
Using portage to bootstrap gentoo install can lead to the following
warning when ROOT is empty:
>> Running pre-merge checks for acct-group/root-0
grep: /tmp/0xff.z2MjAjJXuo/root/etc/group: No such file or directory
grep: /tmp/0xff.z2MjAjJXuo/root/etc/group: No such file or directory
This change prevent egetent() from attempting to lookup key if database
does not exit, removing error from output.
Signed-off-by: Bertrand Jacquin
---
eclass/user-info.eclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/eclass/user-info.eclass b/eclass/user-info.eclass
index b18f280c1022..79d33d6881ae 100644
--- a/eclass/user-info.eclass
+++ b/eclass/user-info.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: user-info.eclass
@@ -34,6 +34,9 @@ egetent() {
*) die "sorry, database '${db}' not yet supported; file a bug" ;;
esac
+ # return immediately if db does not exist
+ [[ ! -e "${EROOT}/etc/${db}" ]] && return 1
+
case ${CHOST} in
*-freebsd*|*-dragonfly*)
case ${db} in
Re: [gentoo-dev] user.eclass ignores ROOT/SYSROOT
On 2020-05-05 21:22, Peter Stuge wrote: Hi, I'm trying something out over here and I'm surprised to find that acct-group/* do not work with ROOT+SYSROOT != "/". Should I file yet another bug about this Correct, https://bugs.gentoo.org/show_bug.cgi?id=541406 is tracking this and has some background into it. -- Bertrand
[gentoo-dev] [PATCH 3/3] eclass/enlightenment.eclass: Move HOMEPAGE to https://
Update DESCRIPTION while at there since DR17 is from the past.
---
eclass/enlightenment.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/enlightenment.eclass b/eclass/enlightenment.eclass
index c374af34cb1d..8e4cc5a7a241 100644
--- a/eclass/enlightenment.eclass
+++ b/eclass/enlightenment.eclass
@@ -88,8 +88,8 @@ case "${EAPI:-0}" in
esac
EXPORT_FUNCTIONS ${ENLIGHTENMENT_EXPF}
-DESCRIPTION="A DR17 production"
-HOMEPAGE="http://www.enlightenment.org/";
+DESCRIPTION="An Enlightenment Foundation production"
+HOMEPAGE="https://www.enlightenment.org";
if [[ -z ${SRC_URI} ]] ; then
case ${EURI_STATE:-${E_STATE}} in
release) SRC_URI="mirror://sourceforge/enlightenment/${P}.tar.gz";;
[gentoo-dev] [PATCH 2/3] eclass/enlightenment.eclass: Remove svn references
SVN for E is long gone.
---
eclass/enlightenment.eclass | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/eclass/enlightenment.eclass b/eclass/enlightenment.eclass
index 23b6ffcc9f54..c374af34cb1d 100644
--- a/eclass/enlightenment.eclass
+++ b/eclass/enlightenment.eclass
@@ -37,7 +37,7 @@ E_ECONF=()
#
# live $PV has a marker
# KEYWORDS ""
-# SRC_URI svn/etc... up
+# SRC_URI git/etc... up
# S$WORKDIR/$E_S_APPEND
#
# Overrides:
@@ -45,7 +45,6 @@ E_ECONF=()
# SRC_URI EURI_STATE
# S EURI_STATE
-E_LIVE_SERVER_DEFAULT_SVN="http://svn.enlightenment.org/svn/e/trunk";
E_LIVE_SERVER_DEFAULT_GIT="https://git.enlightenment.org";
E_STATE="release"
@@ -58,15 +57,6 @@ if [[ ${PV} == ** ]] ; then
E_S_APPEND=${EGIT_URI_APPEND}
E_LIVE_SOURCE="git"
inherit git-2
- else
- E_LIVE_SERVER=${E_LIVE_SERVER:-${E_LIVE_SERVER_DEFAULT_SVN}}
-
- ESVN_URI_APPEND=${ESVN_URI_APPEND:-${PN}}
- ESVN_PROJECT="enlightenment/${ESVN_SUB_PROJECT}"
-
ESVN_REPO_URI=${ESVN_SERVER:-${E_LIVE_SERVER_DEFAULT_SVN}}/${ESVN_SUB_PROJECT}/${ESVN_URI_APPEND}
- E_S_APPEND=${ESVN_URI_APPEND}
- E_LIVE_SOURCE="svn"
- inherit subversion
fi
E_STATE="live"
WANT_AUTOTOOLS="yes"
@@ -126,7 +116,6 @@ esac
enlightenment_src_unpack() {
if [[ ${E_STATE} == "live" ]] ; then
case ${E_LIVE_SOURCE} in
- svn) subversion_src_unpack;;
git) git-2_src_unpack;;
*) die "eek!";;
esac
@@ -147,7 +136,6 @@ enlightenment_src_prepare() {
# autotools require README, when README.in is around, but README
# is created later in configure step
[[ -f README.in ]] && touch README
- export SVN_REPO_PATH=${ESVN_WC_PATH}
eautoreconf
fi
epunt_cxx
@@ -178,7 +166,7 @@ enlightenment_src_compile() {
enlightenment_src_install() {
V=1 emake install DESTDIR="${D}" || die
- find "${D}" '(' -name CVS -o -name .svn -o -name .git ')' -type d -exec
rm -rf '{}' \; 2>/dev/null
+ find "${D}" '(' -name CVS -o -name -o -name .git ')' -type d -exec rm
-rf '{}' \; 2>/dev/null
for d in AUTHORS ChangeLog NEWS README TODO ${EDOCS}; do
[[ -f ${d} ]] && dodoc ${d}
done
[gentoo-dev] [PATCH 1/3] eclass/enlightenment.eclass: Use https:// git URI
git:// are now prohibited on git.enlightenment.org
---
eclass/enlightenment.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/enlightenment.eclass b/eclass/enlightenment.eclass
index ae7bb396590c..23b6ffcc9f54 100644
--- a/eclass/enlightenment.eclass
+++ b/eclass/enlightenment.eclass
@@ -46,7 +46,7 @@ E_ECONF=()
# S EURI_STATE
E_LIVE_SERVER_DEFAULT_SVN="http://svn.enlightenment.org/svn/e/trunk";
-E_LIVE_SERVER_DEFAULT_GIT="git://git.enlightenment.org"
+E_LIVE_SERVER_DEFAULT_GIT="https://git.enlightenment.org";
E_STATE="release"
if [[ ${PV} == ** ]] ; then
Re: [gentoo-dev] Gentoo-hosted code review
You might be interested in a few ebuild I made for it for Enlightenment: http://git.meleeweb.net/gentoo/portage.git/tree/dev-php/libphutil http://git.meleeweb.net/gentoo/portage.git/tree/www-client/arcanist http://git.meleeweb.net/gentoo/portage.git/tree/www-apps/phabricator Cheers On 01/11/2015 17:44, Michael Palimaka wrote: There's been a lot of discussion about relying on GitHub for pull requests and code review and such, so I have set up a Phabricator instance against gentoo.git to see how a free alternative might work. Here's a few examples of how things could work: General post-commit review: http://phabricator.astralcloak.net/rGENTOO27ba62d0c7fcabdc79ce82a064b43d67b3b11cca Tracking commits with issues that need attention: http://phabricator.astralcloak.net/audit/query/open/ Pre-commit review: http://phabricator.astralcloak.net/D1 Phabricator also has all sorts of fancy (optional) features that could be useful for collaborative development (see http://phabricator.org/ for more info). What do you think? -- Bertrand
Re: [gentoo-dev] [PATCH] bash-completion-r1: support for aliasing completions for commands
Hi Michał,
On 2014-08-27 17:06, Michał Górny wrote:
Please review.
+bashcomp_alias() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ [[ ${#} -lt 2 ]] && die "Usage: ${FUNCNAME} ..."
+ local base=${1} f
+ shift
+
+ for f; do
is there a missing 'in "$@" after 'for f' ? f is never initialized.
+ dosym "${base}" "$(_bash-completion-r1_get_bashcompdir)/${f}"
+ done
+}
--
Beber
Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings
Hi, On 2014-08-10 14:22, Sergei Trofimovich wrote: The script does not handle case of multiline description: DESCRIPTION="You have to clean that yourself." You could handle this by reading metadata/md5-cache/*/* instead of ebuild itself But is multiline DESCRIPTION something recommended as it should contain a short description ? -- Beber
Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value & deprecating multilib_for_best_abi()
On 2014-05-23 09:55, Michał Górny wrote:
Dnia 2014-05-05, o godz. 10:29:12
Michał Górny napisał(a):
2. adds ${MULTILIB_ABI} variable to foreach loops that contains the
flag
matching currently iterated ABI.
e.g.:
${ABI} == amd64
${MULTILIB_ABI} == abi_x86_64
Committed as MULTILIB_ABI_FLAG to avoid collision with ${MULTILIB_ABI}
used by multilib portage & confusion with ${MULTILIB_ABIS}.
Thank you Michał !
Re: [gentoo-dev] net-proxy herd is still looking for help (was: Re: [gentoo-dev] net-proxy herd is empty)
On 2013-09-01 16:01, Tom Wijsman wrote: On Sun, 3 Mar 2013 21:00:19 +0200 Pavlos Ratis wrote: On Sun, Mar 3, 2013 at 6:16 PM, Tom Wijsman wrote: > On Sun, 03 Mar 2013 17:00:57 +0100 > Pacho Ramos wrote: > >> As wschlich no longer has enough time for that packages, this herd >> is now empty. If you want to help, please join the herd. If nobody >> joins, I will proceed with dropping it and moving its packages >> maintainer-needed letting everybody want the packages they prefer. > > Not joining until others join because I don't want to be the sole > herd member, but I do want to help out with occasional bumps and > such if there clearly is a case of lack of manpower. > > I'm also interested in stepping up as a maintainer for > net-proxy/privoxy. I am interested in joining the herd. Now we can be 2 members. :) While I joined under the above premise to help out I have became the main maintainer but am unable to cover everything this herd does; Pavlos didn't have much time either to together cover everything. So, we currently have around 48 bugs open at the moment; there are also probably some versions bumps waiting as well, as well as some of the other maintaining tasks that possibly come along. If you want to help, please join the herd. If nobody joins, we will likely proceed with dropping it in a month and moving its packages to maintainer-needed letting everybody want the packages they prefer. Can be in as a proxied maintainer as net-proxy is something I'm interested in as other net- stuff. Another option is to combine the net herds together into a bigger net herd, as I have previously suggested; we might need to look into that.
Re: [gentoo-dev] Building custom package for multi-arch/system
D'ar gwener 29 a viz Genver 2010 e 00 eur 23, « Philipp Riegger » he deus skrivet : > On Thu, 28 Jan 2010 16:17:41 +0100 > Beber wrote: > > > So, I did a wrapper to emerge --buildpkg to create tbz2 with SHA1 in > > names function of USE, like : > > CHOST="x86_64-pc-linux-gnu" > > ACCEPT_KEYWORDS="amd64" > > tcpdump > > > > USE="+chroot +ipv6 -ssl -test -samba -smi" > > is placed > > under > > /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+2bf4bfffad82d4ae519f76770b4f7db7b4416738.tbz2 > > > > USE="+chroot +ipv6 +ssl -test +samba -smi" > > is placed > > under > > /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+5e099e8337e4cadfceda6ccf4c881fbb495980bd.tbz2 > > So these are the SHA1 sums of the packages? Nice. No, the SHA1 is USE var SHA1. sha1sum <<< "$USE" -- Beber pgpBKVzwhXru8.pgp Description: PGP signature
Re: [gentoo-dev] Building custom package for multi-arch/system
D'ar yaou 28 a viz Genver 2010 e 23 eur 31, « Robin H. Johnson » he deus skrivet : > On Thu, Jan 28, 2010 at 04:17:41PM +0100, Beber wrote: > > So, I did a wrapper to emerge --buildpkg to create tbz2 with SHA1 in > > names function of USE, like : > > CHOST="x86_64-pc-linux-gnu" > > ACCEPT_KEYWORDS="amd64" > > tcpdump > > > > USE="+chroot +ipv6 -ssl -test -samba -smi" > > is placed under > > /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+2bf4bfffad82d4ae519f76770b4f7db7b4416738.tbz2 > > > > USE="+chroot +ipv6 +ssl -test +samba -smi" > > is placed under > > /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+5e099e8337e4cadfceda6ccf4c881fbb495980bd.tbz2 > A word of warning on this. > > Simply capturing the USE flags is not enough, the libraries that a > binary is linked against can cause problems as well, as the dependency > imposed by linking is much stricter than the RDEPEND in the ebuild. > > tcpdump for example has: > RDEPEND="... ssl? ( >=dev-libs/openssl-0.9.6m )" Of course, but real *DEPEND could be added in the xpak part of tbz2 and resolv depedencies by the way. > But if you built and linked against openssl-0.9.7*, then upgraded to > openssl-0.9.8, you can expect breakage. > > Similar things happened with binaries linked against libmysqlclient in > the past. > > As to my own take on a solution to the problem for work stuff, we simply > maintain one chroot per unique environment (we only have 5 envs), and > build in the chroot, then use those binpkgs on the boxes. I did that already, but it's a bit heavy to maintain and do much repetitive (maybe it's not the good word) as many packages would be build with the same USE (in the case of same arch, chost etc). -- Beber pgppYr2q0aw1b.pgp Description: PGP signature
[gentoo-dev] New adresses
Hi, My new IM (Jabber) adress is : [EMAIL PROTECTED] My new email is : [EMAIL PROTECTED] Beber -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X: unmasking tonight, RFC
On 4/20/06, Stephen P. Becker <[EMAIL PROTECTED]> wrote: > Bertrand Jacquin wrote: > > On 4/19/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > >> Bertrand Jacquin wrote: > >>> Is it planned to release some xserver ebuilds ? > >> Could you rephrase the question? I don't understand it. > > > > I can't any ebuild for xserver > > (http://www.jabber.no/ejabberd-1.0.0.tar.bz2) (X over vesa fb). Is it > > planned to make an ebuild available ? > > > > Beber > > > > What does a jabber server have to do with X on vesafb? Are you not > satisfied with the vesa driver which is already part of modular Xorg, > provided by the x11-drivers/xf86-video-vesa ebuild? Could you possibly > rephrase your question so that it actually makes sense? Oh ok. Sorry for the bad URL but you answered to my request. Thanks. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X: unmasking tonight, RFC
On 4/19/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > Bertrand Jacquin wrote: > > Is it planned to release some xserver ebuilds ? > > Could you rephrase the question? I don't understand it. I can't any ebuild for xserver (http://www.jabber.no/ejabberd-1.0.0.tar.bz2) (X over vesa fb). Is it planned to make an ebuild available ? Beber -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X: unmasking tonight, RFC
On 3/23/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > Hi all, > > There aren't really any remaining blockers to keep modular X out of > ~arch, as far as I can see. > > If anyone's got one, please bring it up now. I'm planning to unmask > later tonight. > Is it planned to release some xserver ebuilds ? Beber -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Find apps not ported to modular X
On 3/13/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > Bertrand Jacquin wrote: > > On 2/24/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > > >> Latest list: > >> http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_maintainers.txt.20060224 > > > > scilab depend on virtual/x11 and is not in this list. Is your tool broken ? > > No, it just checks the latest ~arch version of each package. And > 3.1.1-r3 of scilab works fine. Ah ok, I test it on amd64, and latest ~arch is 2.7-r3. Thanks. > > Thanks, > Donnie > > > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Find apps not ported to modular X
On 2/24/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > Latest list: > http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_maintainers.txt.20060224 scilab depend on virtual/x11 and is not in this list. Is your tool broken ? Beber -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
that's great :) Thanks for doing that. That's exactly what I done with XCB ebuilds. Maybe some of you don't know xcb, it a remplacement for Xlib. Currently it only available on cvs. I think it couldn't have to be ignore it. Some ebuilds for : http://guybrush.ath.cx/svn/public/portage/x11-libs/ Website : http://freedesktop.org/Software/xcb Also It's on heavy devlopment, and I'not a dev. So take the choice you'll find the best :) ++ Beber On 8/1/05, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > (This is an expanded, updated version of a recent blog post, so some of > you may have already seen parts of it.) > > Background: Upstream is splitting up the monolithic X.Org X11 release > into a huge number of modular releases, the combination of which will be > released as X11R7. Simultaneously, a source-identical monolith will be > released as X11R6.9. > > Gentoo will only add X11R7, the modular release. Roughly 280 packages > will comprise this release, so this will entail adding a few new > categories to deal with them. > > Here's the categories I'm looking at using, which is mostly a mirror of > how upstream breaks it down: > > ~* x11-apps: The various applications that come along with all X11RX > releases. 86 ebuilds. > > ~* x11-proto: The protocol headers. 30 ebuilds. > > ~* x11-libs: 43 ebuilds. > > ~* media-fonts: 35 ebuilds. > > ~* x11-drivers: All the video and input drivers. 68 ebuilds. > > ~* x11-base: The actual X server, and meta-ebuilds. <10 ebuilds. > > ~* app-doc: Old-format docs that haven't been broken into individual > packages yet. Probably just a couple ebuilds. > > ~* x11-misc: The data module, which contains bitmaps and xkbdata. > Also the util module, with imake, etc. <10 ebuilds. > > The new categories are x11-apps, x11-proto and x11-drivers. Of these, > the name for x11-proto (the protocol headers) is debatable. The upstream > module they're all in is called "proto," and their pkg-config (*.pc) > files are called fooproto. But I'm also open to names such as > x11-protocol or x11-headers, so let me know what you think makes the > most sense, both in understanding the meaning and in combination with > upstream's naming. > > My plan is to have a series of "submetabuilds" that combine into a > "supermetabuild," which will be the actual xorg-x11 ebuild. There will > be one submetabuild for each major component: apps, drivers, libraries, > etc. This will allow me to split USE flags out a bit (so e.g., x11-fonts > would have 100dpi, 75dpi, truetype as flags) as well as allow people who > only want e.g. libraries for a headless server to get them cleanly. > > I intend to begin adding these packages to the tree shortly after the > first release candidate, which should be happening very soon. > > > Repercussions: > > All packages in the tree will need to clearly enunciate exactly which > parts of X they need as DEPENDs and RDEPENDs, down to the library or > application level. > > Until such time as that becomes possible for everyone to do, the > x11-libs metabuild will PROVIDE virtual/x11. But realize that not > everybody will have or want all the X libraries installed, when they > only need a few. > > If your package depends on virtual/x11 for any reason besides libraries, > it will require a dependency update to work with the new packages. > > > My preliminary work on the modular ebuilds is at > http://dev.gentoo.org/~spyderous/x-modular/ -- browse this at your > leisure. The metabuilds are all in x11-base/. There will be no tarball > of this overlay available because I'm not interested in dealing with > other testers before the first release candidate has even come out. > > I eagerly await your questions and concerns. > > Thanks, > Donnie > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFC7owDXVaO67S1rtsRAu68AJwISOSEwUChCvgQ96Y1KJGFmNYb/wCfaOEz > WURqd84yUyrb9cJqmiZE6sc= > =L4yH > -END PGP SIGNATURE- > -- > gentoo-dev@gentoo.org mailing list > > -- gentoo-dev@gentoo.org mailing list
