On Thu, Oct 11, 2012 at 8:22 PM, Mike Frysinger vap...@gentoo.org wrote:
On Thursday 11 October 2012 14:56:11 Ben Kohler wrote:
I would like to suggest that the server profile variants
(ie default/linux/amd64/10.0/server) be unlisted from profiles.desc, so
that they do not show up in eselect
On Thu, Oct 11, 2012 at 9:04 PM, Walter Dnes waltd...@waltdnes.org wrote:
On Thu, Oct 11, 2012 at 03:22:17PM -0400, Mike Frysinger wrote
sounds like something to fix rather than punt. i don't know why
you think having server profiles is undesirable, but i certainly
desire it on many systems.
On Fri, Oct 12, 2012 at 4:08 AM, Markos Chandras hwoar...@gentoo.org wrote:
+1. I want these profiles to *staty*. I am using this profile on my
home boxes. It is the most minimal profile as the rest of the
profiles pull in too much useless stuff. What is wrong with these
profiles anyway?
On Fri, Oct 12, 2012 at 9:18 AM, Rich Freeman ri...@gentoo.org wrote:
On Fri, Oct 12, 2012 at 4:08 AM, Markos Chandras hwoar...@gentoo.org wrote:
+1. I want these profiles to *staty*. I am using this profile on my
home boxes. It is the most minimal profile as the rest of the
profiles pull in
On Mon, Oct 08, 2012 at 05:16:05PM +0200, Michał Górny wrote:
Hello,
This is the second and hopefully last version of python-r1 +
distutils-r1 eclasses before committing. I would also like to shortly
point out the goals and the differences between various python eclasses
in Gentoo.
Both
From time to time the topic of deprecating EAPIs comes up and usually
one suggestion is to keep 0 and start with converting EAPI 1 ebuilds.
Then someone comes along and asks what is the point? Indeed, a fair
question.
The following tries to take a different approach to the topic. It's not
all
On 10/11/2012 2:40 PM, Marien Zwart wrote:
I'm going to do something potentially rude and comment on this without
having read the entire thread.
On Thu, Oct 11, 2012 at 10:39 PM, Gregory M. Turner g...@malth.us wrote:
Anyhow one thing I have figured out is how things can work correctly on
On 10/11/2012 3:31 PM, Ben Kohler wrote:
There are other ways to achieve a lighter system, but that's not really
what this is about. The server profiles are not any lighter than the base
profiles.
To those in favor of keeping some kind of server profile around, how
would it differ from the
On Fri, 12 Oct 2012 13:35:44 +0300
Reinis Danne rei4...@gmail.com wrote:
On Mon, Oct 08, 2012 at 05:16:05PM +0200, Michał Górny wrote:
Hello,
This is the second and hopefully last version of python-r1 +
distutils-r1 eclasses before committing. I would also like to shortly
point out
11.10.2012 23:22, Mike Frysinger wrote:
On Thursday 11 October 2012 14:56:11 Ben Kohler wrote:
I would like to suggest that the server profile variants
(ie default/linux/amd64/10.0/server) be unlisted from profiles.desc, so
that they do not show up in eselect profile list for new users. As
On Fri, Oct 12, 2012 at 8:46 AM, Sergey Popov pinkb...@gentoo.org wrote:
Indeed. Hardened server profile does not fit in all cases, some
non-hardened server profile should exist, BUT without this warning(if
it's usable, of course), and probably with better support.
Well, support is mainly a
On Fri, Oct 12, 2012 at 4:18 AM, Rich Freeman ri...@gentoo.org wrote:
On Fri, Oct 12, 2012 at 4:08 AM, Markos Chandras hwoar...@gentoo.org wrote:
+1. I want these profiles to *staty*. I am using this profile on my
home boxes. It is the most minimal profile as the rest of the
profiles pull in
This is why I said that the server profile are no lighter than the base.
It's actually the base PLUS snmp truetype xml.
My original suggestion of hiding or removing the server profiles was based
on the assumption that no one wants to maintain it. The server profiles
*in their current state* are
Markos Chandras schrieb am 12.10.2012 10:08:
+1. I want these profiles to *staty*. I am using this profile on my
home boxes. It is the most minimal profile as the rest of the
profiles pull in too much useless stuff. What is wrong with these
profiles anyway?
If you want a minimal profile
On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote
From time to time the topic of deprecating EAPIs comes up and usually
one suggestion is to keep 0 and start with converting EAPI 1 ebuilds.
Then someone comes along and asks what is the point? Indeed, a fair
question.
It's my
On Fri, 12 Oct 2012 16:38:06 -0400
Walter Dnes waltd...@waltdnes.org wrote:
On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote
From time to time the topic of deprecating EAPIs comes up and
usually one suggestion is to keep 0 and start with converting EAPI
1 ebuilds. Then
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/10/12 04:38 PM, Walter Dnes wrote:
On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote
From time to time the topic of deprecating EAPIs comes up and
usually one suggestion is to keep 0 and start with converting
EAPI 1 ebuilds.
On Fri, 2012-10-12 at 16:38 -0400, Walter Dnes wrote:
It's my understanding that higher EAPI levels include more features.
How backwards compatable are the EAPI levels? I.e. assume that we take
an ebuild with EAPI 0, and slap in EAPI=1 (or 2 or 3, etc) at the top,
without any other changes.
On Fri, 12 Oct 2012 12:53:15 +0200
Ralph Sennhauser s...@gentoo.org wrote:
The EAPI=0 requirement comes from having to provide an update path for
systems with a package manager without EAPI support. By now we are
talking about really ancient systems and it's questionable if there is
any merit
19 matches
Mail list logo
