Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
On 01/23/2014 04:48 PM, Michał Górny wrote: Dnia 2014-01-23, o godz. 11:36:06 Chris Reffett creff...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 11:28 AM, Michał Górny wrote: Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett creff...@gentoo.org napisał(a): After some discussion on good ways to communicate optional dependencies to users, I was shown the optfeature() function in net-misc/netctl. Gentoo contributor Andrew Hamilton and I came up with a cleaned up and expanded version of it, and I would like to add it to eutils.eclass to provide a standard way of notifying users of optional dependencies. The patch to eutils.eclass is attached. This was discussed already: http://thread.gmane.org/gmane.linux.gentoo.devel/72162 First of all, this is a short patch for a function, not a full eclass. Ah, sorry, this changes *a lot*. Let's start the bikeshed again then, whatever. I haven't looked at the implementation, but I wonder if we need a function for such trivial stuff. Most maintainers deal with this problem using pkg_postinst() einfo/elog messages. Why do we need a dedicated function for that? Just for consistency reasons...? -- Regards, Markos Chandras
Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
Dnia 2014-01-25, o godz. 10:12:26 Markos Chandras hwoar...@gentoo.org napisał(a): On 01/23/2014 04:48 PM, Michał Górny wrote: Dnia 2014-01-23, o godz. 11:36:06 Chris Reffett creff...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 11:28 AM, Michał Górny wrote: Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett creff...@gentoo.org napisał(a): After some discussion on good ways to communicate optional dependencies to users, I was shown the optfeature() function in net-misc/netctl. Gentoo contributor Andrew Hamilton and I came up with a cleaned up and expanded version of it, and I would like to add it to eutils.eclass to provide a standard way of notifying users of optional dependencies. The patch to eutils.eclass is attached. This was discussed already: http://thread.gmane.org/gmane.linux.gentoo.devel/72162 First of all, this is a short patch for a function, not a full eclass. Ah, sorry, this changes *a lot*. Let's start the bikeshed again then, whatever. I haven't looked at the implementation, but I wonder if we need a function for such trivial stuff. Most maintainers deal with this problem using pkg_postinst() einfo/elog messages. Why do we need a dedicated function for that? Just for consistency reasons...? The intent of the original optfeature implementation was to provide users with nice, colorful '[installed]' messages whenever the optional dependency was installed. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/25/2014 05:12 AM, Markos Chandras wrote: On 01/23/2014 04:48 PM, Michał Górny wrote: Dnia 2014-01-23, o godz. 11:36:06 Chris Reffett creff...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 11:28 AM, Michał Górny wrote: Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett creff...@gentoo.org napisał(a): After some discussion on good ways to communicate optional dependencies to users, I was shown the optfeature() function in net-misc/netctl. Gentoo contributor Andrew Hamilton and I came up with a cleaned up and expanded version of it, and I would like to add it to eutils.eclass to provide a standard way of notifying users of optional dependencies. The patch to eutils.eclass is attached. This was discussed already: http://thread.gmane.org/gmane.linux.gentoo.devel/72162 First of all, this is a short patch for a function, not a full eclass. Ah, sorry, this changes *a lot*. Let's start the bikeshed again then, whatever. I haven't looked at the implementation, but I wonder if we need a function for such trivial stuff. Most maintainers deal with this problem using pkg_postinst() einfo/elog messages. Why do we need a dedicated function for that? Just for consistency reasons...? Consistency, and because it removes the need for a bunch of if has_version lines, instead only displaying if you don't satisfy the deps (and supports both and and or groupings for packages satisfying the dep). This also stems from a complaint I've seen a lot about how optional dep messages should only display if the requisite package isn't installed, this makes that job a little simpler. But mostly consistency, this gives us one nice function that we can standardize on. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLjt6NfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1SAZACgqLjfMMmvPNa/6Nwxzlpm5sde kwQAniZMjvFkQ7H/1+wpYnDjyezplMud =6E+E -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
On 01/25/2014 01:09 PM, Chris Reffett wrote: On 01/25/2014 05:12 AM, Markos Chandras wrote: On 01/23/2014 04:48 PM, Michał Górny wrote: Dnia 2014-01-23, o godz. 11:36:06 Chris Reffett creff...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 11:28 AM, Michał Górny wrote: Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett creff...@gentoo.org napisał(a): After some discussion on good ways to communicate optional dependencies to users, I was shown the optfeature() function in net-misc/netctl. Gentoo contributor Andrew Hamilton and I came up with a cleaned up and expanded version of it, and I would like to add it to eutils.eclass to provide a standard way of notifying users of optional dependencies. The patch to eutils.eclass is attached. This was discussed already: http://thread.gmane.org/gmane.linux.gentoo.devel/72162 First of all, this is a short patch for a function, not a full eclass. Ah, sorry, this changes *a lot*. Let's start the bikeshed again then, whatever. I haven't looked at the implementation, but I wonder if we need a function for such trivial stuff. Most maintainers deal with this problem using pkg_postinst() einfo/elog messages. Why do we need a dedicated function for that? Just for consistency reasons...? Consistency, and because it removes the need for a bunch of if has_version lines, instead only displaying if you don't satisfy the deps (and supports both and and or groupings for packages satisfying the dep). This also stems from a complaint I've seen a lot about how optional dep messages should only display if the requisite package isn't installed, this makes that job a little simpler. But mostly consistency, this gives us one nice function that we can standardize on. Chris Reffett I am fine with that especially given it's an opt-in feature. -- Regards, Markos Chandras
Re: [gentoo-dev] new profiles.desc header documenting profile/keyword policy
On 01/22/2014 06:58 AM, Mike Frysinger wrote: On Monday 20 January 2014 12:26:13 William Hubbs wrote: On Mon, Jan 20, 2014 at 02:23:24AM -0500, Mike Frysinger wrote: this has all been fairly ad-hoc in the past, so formalize it in the one place that impacts everyone -- profiles.desc. If it is policy, shouldn't it go in the dev manual rather than in this file? maybe. devmanual doesn't talk about this file at all atm. or maybe i still have it in my head that devmanual.g.o is the ad-hoc documentation and not a policy manual -- policy lives in the Gentoo Developer Handbook. The handbook has not been updated for a good number of years therefore I am moving bits from it to devmanual whenever I have the time. -- Regards, Markos Chandras
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 11/10/2013 06:12 AM, Johann Schmitz wrote: - gpg control packet I already have too many packages to take care of but my company is using nagion on Gentoo so I take care of it. Although I wouldn't mind if somebody else helps with the packages as well. We use Nagios on many servers at work, so i can help out with these packages too. ... git overlay for easier nondev contributions? :) A git repo would be useful if there are many changes to the code (e.g. plugins). From what i see in the buglist, most of the bugs are ebuild related (bumps, compile and installation issues). (picking a random email from the thread) ping again. 3 months later, the list of bugs remain the same. Shall we consider dropping it to maintainer-needed? -- Regards, Markos Chandras
[gentoo-dev] Dealing with XDG directories in ebuild environment
It seems having XDG variables like XDG_CONFIG_HOME set in the
environment when calling emerge has a tendency to cause sandbox
violations. For example, see the bugs blocking bug 499202.
https://bugs.gentoo.org/show_bug.cgi?id=499202
If you grep for XDG_CONFIG_HOME in the eclass directory, you can see
that several eclasses work around this by setting
XDG_CONFIG_HOME=${T} or ${T}/.config.
gnome2-utils.eclass takes it a step further and creates empty
directories for several other XDG variables.
Is this something we can/should consolidate into some central place?
Or should I just copy/paste something into distutils-r1.eclass?
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 1/25/2014 9:24 AM, Markos Chandras wrote: On 11/10/2013 06:12 AM, Johann Schmitz wrote: - gpg control packet I already have too many packages to take care of but my company is using nagion on Gentoo so I take care of it. Although I wouldn't mind if somebody else helps with the packages as well. We use Nagios on many servers at work, so i can help out with these packages too. ... git overlay for easier nondev contributions? :) A git repo would be useful if there are many changes to the code (e.g. plugins). From what i see in the buglist, most of the bugs are ebuild related (bumps, compile and installation issues). (picking a random email from the thread) ping again. 3 months later, the list of bugs remain the same. Shall we consider dropping it to maintainer-needed? I would be happy to proxy-maintain these packages. Andrew Hamilton
[gentoo-dev] [PATCH] games.eclass: rm unnecessary exports
I don't know of any reason they are exported, but I could be wrong.
I'm going to run the modified eclass for some time.
rm unnecessary export wrt #467374
--- eclass/games.eclass
+++ eclass/games.eclass
@@ -19,20 +19,20 @@
*) die no support for EAPI=${EAPI} yet ;;
esac
-export GAMES_PREFIX=${GAMES_PREFIX:-/usr/games}
-export GAMES_PREFIX_OPT=${GAMES_PREFIX_OPT:-/opt}
-export GAMES_DATADIR=${GAMES_DATADIR:-/usr/share/games}
-export GAMES_DATADIR_BASE=${GAMES_DATADIR_BASE:-/usr/share} # some packages auto append 'games'
-export GAMES_SYSCONFDIR=${GAMES_SYSCONFDIR:-/etc/games}
-export GAMES_STATEDIR=${GAMES_STATEDIR:-/var/games}
-export GAMES_LOGDIR=${GAMES_LOGDIR:-/var/log/games}
-export GAMES_BINDIR=${GAMES_BINDIR:-${GAMES_PREFIX}/bin}
-export GAMES_ENVD=90games
+GAMES_PREFIX=${GAMES_PREFIX:-/usr/games}
+GAMES_PREFIX_OPT=${GAMES_PREFIX_OPT:-/opt}
+GAMES_DATADIR=${GAMES_DATADIR:-/usr/share/games}
+GAMES_DATADIR_BASE=${GAMES_DATADIR_BASE:-/usr/share} # some packages auto append 'games'
+GAMES_SYSCONFDIR=${GAMES_SYSCONFDIR:-/etc/games}
+GAMES_STATEDIR=${GAMES_STATEDIR:-/var/games}
+GAMES_LOGDIR=${GAMES_LOGDIR:-/var/log/games}
+GAMES_BINDIR=${GAMES_BINDIR:-${GAMES_PREFIX}/bin}
+GAMES_ENVD=90games
# if you want to use a different user/group than games.games,
# just add these two variables to your environment (aka /etc/profile)
-export GAMES_USER=${GAMES_USER:-root}
-export GAMES_USER_DED=${GAMES_USER_DED:-games}
-export GAMES_GROUP=${GAMES_GROUP:-games}
+GAMES_USER=${GAMES_USER:-root}
+GAMES_USER_DED=${GAMES_USER_DED:-games}
+GAMES_GROUP=${GAMES_GROUP:-games}
games_get_libdir() {
echo ${GAMES_PREFIX}/$(get_libdir)
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 01/25/2014 09:24 AM, Markos Chandras wrote: (picking a random email from the thread) ping again. 3 months later, the list of bugs remain the same. Shall we consider dropping it to maintainer-needed? These are easy fixes, some for nagios-plugins: * https://bugs.gentoo.org/show_bug.cgi?id=434192 * https://bugs.gentoo.org/show_bug.cgi?id=388323 * https://bugs.gentoo.org/show_bug.cgi?id=457042 * https://bugs.gentoo.org/show_bug.cgi?id=483530 (QA can fix this) * https://bugs.gentoo.org/show_bug.cgi?id=481926
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
El sáb, 25-01-2014 a las 11:13 -0500, Mike Gilbert escribió:
It seems having XDG variables like XDG_CONFIG_HOME set in the
environment when calling emerge has a tendency to cause sandbox
violations. For example, see the bugs blocking bug 499202.
https://bugs.gentoo.org/show_bug.cgi?id=499202
If you grep for XDG_CONFIG_HOME in the eclass directory, you can see
that several eclasses work around this by setting
XDG_CONFIG_HOME=${T} or ${T}/.config.
gnome2-utils.eclass takes it a step further and creates empty
directories for several other XDG variables.
Is this something we can/should consolidate into some central place?
Or should I just copy/paste something into distutils-r1.eclass?
Maybe the function cleaning stuff could be added to eutils.eclass and we
would call it from other eclasses/ebuilds. I also wonder if this cleanup
could be done always in a newer eapi since we usually need to add that
fix whenever we suffer the sandbox violation :S (not before)
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
Dnia 2014-01-25, o godz. 11:13:38
Mike Gilbert flop...@gentoo.org napisał(a):
It seems having XDG variables like XDG_CONFIG_HOME set in the
environment when calling emerge has a tendency to cause sandbox
violations. For example, see the bugs blocking bug 499202.
https://bugs.gentoo.org/show_bug.cgi?id=499202
If you grep for XDG_CONFIG_HOME in the eclass directory, you can see
that several eclasses work around this by setting
XDG_CONFIG_HOME=${T} or ${T}/.config.
gnome2-utils.eclass takes it a step further and creates empty
directories for several other XDG variables.
Is this something we can/should consolidate into some central place?
Or should I just copy/paste something into distutils-r1.eclass?
I'd say portage should kill that as part of sanitizing the environment.
There's no point in reproducing it in random eclasses.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
On Sat, Jan 25, 2014 at 4:16 PM, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-01-25, o godz. 11:13:38
Mike Gilbert flop...@gentoo.org napisał(a):
It seems having XDG variables like XDG_CONFIG_HOME set in the
environment when calling emerge has a tendency to cause sandbox
violations. For example, see the bugs blocking bug 499202.
https://bugs.gentoo.org/show_bug.cgi?id=499202
If you grep for XDG_CONFIG_HOME in the eclass directory, you can see
that several eclasses work around this by setting
XDG_CONFIG_HOME=${T} or ${T}/.config.
gnome2-utils.eclass takes it a step further and creates empty
directories for several other XDG variables.
Is this something we can/should consolidate into some central place?
Or should I just copy/paste something into distutils-r1.eclass?
I'd say portage should kill that as part of sanitizing the environment.
There's no point in reproducing it in random eclasses.
I have filed an enhancement request for Portage.
https://bugs.gentoo.org/show_bug.cgi?id=499288
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
On Sat, Jan 25, 2014 at 7:10 PM, Mike Gilbert flop...@gentoo.org wrote:
On Sat, Jan 25, 2014 at 4:16 PM, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-01-25, o godz. 11:13:38
Mike Gilbert flop...@gentoo.org napisał(a):
It seems having XDG variables like XDG_CONFIG_HOME set in the
environment when calling emerge has a tendency to cause sandbox
violations. For example, see the bugs blocking bug 499202.
https://bugs.gentoo.org/show_bug.cgi?id=499202
If you grep for XDG_CONFIG_HOME in the eclass directory, you can see
that several eclasses work around this by setting
XDG_CONFIG_HOME=${T} or ${T}/.config.
gnome2-utils.eclass takes it a step further and creates empty
directories for several other XDG variables.
Is this something we can/should consolidate into some central place?
Or should I just copy/paste something into distutils-r1.eclass?
I'd say portage should kill that as part of sanitizing the environment.
There's no point in reproducing it in random eclasses.
I have filed an enhancement request for Portage.
https://bugs.gentoo.org/show_bug.cgi?id=499288
It seems Arfrever beat me to it. However, it looks like it would need
to be an EAPI change, which means quite a long wait.
https://bugs.gentoo.org/show_bug.cgi?id=444568
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
Duncan wrote: My point being... yes indeed, there's a LOT of folks for whom gentoo without a stable tree would be a gentoo freed of a to-them useless weight, allowing gentoo to move even faster, and be even better in areas that are already its strength, heavily automated leading edge releases and live-development level packages. And I'm one of those folks! +1 //Peter
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Fri, Jan 24, 2014 at 11:02 PM, Duncan 1i5t5.dun...@cox.net wrote: I've often wondered just how much faster gentoo could move, and how much better we could keep up with upstream, if we weren't so focused on 30+day outdated stab?l3 bumping all the time. All that effort... from my viewpoint going to waste on something that gentoo really isn't going to be that great at anyway, certainly in comparison to other distros which REALLY provide a stab?le service, up to a /decade/ outdated, supporting often trailing edge software, in an effort to slow down progress for people that don't want to move so fast. I get what you're saying, and I'm going to use a bit of hyperbole so don't take this too seriously, but couldn't you just as easily argue that Gentoo could go much faster if we actually took advantage of the fact that we DO have a stable tree, and stop being so careful about not breaking the testing tree? Honestly, I think both trees represent a pretty decent balance. It is pretty safe to run ~arch for the packages you really are interested in, and run stable for the stuff that you don't care so much about, thus limiting your exposure to problems while getting cutting-edge where you care for it. Most of the concern in this thread has been about some minor archs that struggle to keep up. It seems like the simplest solution in these cases is to just have them focus on @system packages for the stable tree, and let users deal with more breakage outside of that set (where it isn't super-disruptive). If you're running a minor arch chances are that you're happy to have any support at all, since you sure aren't going to be running Ubuntu... Rich
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 01/25/2014 12:22 PM, Andrew Hamilton wrote: On 1/25/2014 9:24 AM, Markos Chandras wrote: On 11/10/2013 06:12 AM, Johann Schmitz wrote: - gpg control packet I already have too many packages to take care of but my company is using nagion on Gentoo so I take care of it. Although I wouldn't mind if somebody else helps with the packages as well. We use Nagios on many servers at work, so i can help out with these packages too. ... git overlay for easier nondev contributions? :) A git repo would be useful if there are many changes to the code (e.g. plugins). From what i see in the buglist, most of the bugs are ebuild related (bumps, compile and installation issues). (picking a random email from the thread) ping again. 3 months later, the list of bugs remain the same. Shall we consider dropping it to maintainer-needed? I would be happy to proxy-maintain these packages. Andrew Hamilton I will proxy for him, will update metadata shortly. Chris Reffett
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
Rich Freeman wrote: It seems like the simplest solution in these cases is to just have them focus on @system packages for the stable tree, and let users deal with more breakage outside of that set Why not make stable completely optional for arch teams? //Peter
Re: [gentoo-portage-dev] [PATCH 1/3] emerge: Deprecate --autounmask
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19/01/14 17:49, Mike Gilbert wrote:
Please give me a way to shut off autounmask entirely no mater what
other options I pass to emerge.
Here you go.
I don't have time to figure out how send-email's --in-reply-to option
works right now. If someone wants to tell me how to find the
Message-ID (using Thunderbird), I would be grateful for the effort.
- --
Alexander
alexan...@plaimi.net
http://plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlLkC3UACgkQRtClrXBQc7Un7gD8DFjXDZzWypJiCD7GFdXIiGEg
Gbzl2rZb3b9JOssNC8sA/3JdcsQI315GJ8szKYBsadmcZVC/k2/gZE8ZnW2qXtK+
=SJ9h
-END PGP SIGNATURE-
From 3a4cd65e97d7323562fba9669a14f5caa5523eeb Mon Sep 17 00:00:00 2001
From: Alexander Berntsen alexan...@plaimi.net
Date: Sat, 25 Jan 2014 20:03:00 +0100
Subject: [PATCH] emerge: Let --autounmask=n override other options
---
pym/_emerge/depgraph.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index e8b680d..2d32190 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -427,7 +427,8 @@ class _dynamic_depgraph_config(object):
self._backtrack_infos = {}
self._buildpkgonly_deps_unsatisfied = False
- self._autounmask = True
+ self._autounmask = \
+depgraph._frozen_config.myopts.get(--autounmask) != 'n'
self._success_without_autounmask = False
self._traverse_ignored_deps = False
self._complete_mode = False
@@ -6808,7 +6809,7 @@ class depgraph(object):
ask = --ask in self._frozen_config.myopts
autounmask_write = ask or \
-self._frozen_config.myopts.get(--autounmask, n) == True
+self._frozen_config.myopts.get(--autounmask, y)
autounmask_unrestricted_atoms = \
self._frozen_config.myopts.get(--autounmask-unrestricted-atoms, n) == True
quiet = --quiet in self._frozen_config.myopts
--
1.8.3.2
