[gentoo-dev] [PATCH] ebuild-writing/variables: add a section to explain the ROOT variable #144332

[Göktürk Yüksek]

The text is originally based on the patch provided by Thilo Bangert
 in the bug. It is revised and expanded to
mention the use of ROOT in cross-compiling environments as explained
in PMS Table 11.1.

Gentoo-Bug: https://bugs.gentoo.org/144332
Signed-off-by: Göktürk Yüksek 
---
 ebuild-writing/variables/text.xml | 55 +--
 1 file changed, 53 insertions(+), 2 deletions(-)

diff --git a/ebuild-writing/variables/text.xml 
b/ebuild-writing/variables/text.xml
index 9027cad..dc152e1 100644
--- a/ebuild-writing/variables/text.xml
+++ b/ebuild-writing/variables/text.xml
@@ -101,8 +101,8 @@ them.
 ROOT
 
   The absolute path to the root directory into which the package is to be
-  merged. Use this when referring to installed files in pkg_*
-  functions. Never use this in src_* functions.
+  merged. Only allowed in pkg_* phases. See
+  
 
   
   
@@ -393,6 +393,57 @@ GLEP 23 for details.
 
 
 
+ROOT
+
+
+
+The idea behind ROOT is that one can build a system with
+ROOT=/somewhere and then chroot into it or tar up
+/somewhere as a system image. It is not designed to allow the
+user to run /somewhere/usr/bin/foo.
+
+
+
+Ebuilds may reference ROOT only during pkg_* phases. It
+can't be used correctly in src_* phases, since ROOT may
+be different when merging a binary package. For example, a binary
+package may be built with ROOT=/ and then installed onto a
+system using ROOT=/somewhere.
+
+
+
+When building a package, ROOT should not be used to satisfy the
+required dependencies on libraries, headers files etc. Instead, the
+files on the build system should be specified using /.
+
+
+
+In a cross compiling environment, ebuilds must not call any of the
+binaries inside ROOT since they may not be executable on the
+build system.
+
+
+
+Below is an example of an ebuild that uses ROOT in
+pkg_postinst() to conditionally print an error message if an
+old and obsolete configuration file still exists:
+
+
+pkg_postinst() {
+   if [[ -e "${ROOT}/etc/oldconfig" ]]; then
+   ewarn "You still have the obsolete config file "
+   ewarn "${ROOT}/etc/oldconfig."
+   ewarn "Please migrate your settings to ${ROOT}/etc/newconfig"
+   ewarn "and remove ${ROOT}/etc/oldconfig."
+   fi
+}
+
+
+
+
+
+
+
 Version and Name Formatting Issues
 
 
-- 
2.7.3

Re: [gentoo-portage-dev] [PATCH] isolated-functions.sh: eliminate loop in has()

[Anthony G. Basile]

On 4/22/16 9:07 AM, rindeal wrote:
>>From edc6df44de4e0f22322062c7c7e1b973bd89f4cd Mon Sep 17 00:00:00 2001
> From: Jan Chren 
> Date: Fri, 22 Apr 2016 14:21:08 +0200
> Subject: [PATCH] isolated-functions.sh: eliminate loop in has()
> 
> Looping is slow and clutters debug log.
> Still this wouldn't matter that much if has() wasn't one of the most used
> functions.

do you have any benchmarks?  what you say makes sense but i'm not sure
of the implementation details of "$A" == "*${B}*" so its hard to say.

> 
> Thus this patch should bring a general improvement.
> ---
>  bin/isolated-functions.sh | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
> index e320f71..6900f99 100644
> --- a/bin/isolated-functions.sh
> +++ b/bin/isolated-functions.sh
> @@ -463,14 +463,12 @@ hasv() {
>  }
> 
>  has() {
> -   local needle=$1
> +   local needle=$'\a'"$1"$'\a'

why the ascii bell?  just because you'd never expect it in a parameter
to has?

> shift
> +   local IFS=$'\a'
> +   local haystack=$'\a'"$@"$'\a'

you want "$*" here not "$@"

> 
> -   local x
> -   for x in "$@"; do
> -   [ "${x}" = "${needle}" ] && return 0
> -   done
> -   return 1
> +   [[ "${haystack}" == *"${needle}"* ]]
>  }
> 
>  __repo_attr() {
> --
> 2.7.3
> 


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 15/05/16 02:04, Rich Freeman wrote:
> On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman  wrote:
>> On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
>>> On Sun, 15 May 2016 08:40:39 +0900
>>>
>>> Aaron Bauman  wrote:
 Please enlighten me as to what was impolite here?  The strong
 language of "seriously" or definitively stating that the individual
 did not perform the necessary QA actions before committing?  Both of
 which are completely called for and appropriate.  No vulgarity,
 insults, or demeaning words were used. How would you have responded
 professionally?
>>> It's important to remember that Gentoo is run by volunteers. Expecting
>>> a professional standard when it comes to the quality of commit
>>> criticism is unfair.
>> Applying that same rationale, it would be unfair to say that an undescribed
>> level of professionalism in communication is required as well.  Nothing here
>> violates the CoC.
>>
> If you're only able to behave in a professional manner if the
> standards of professionalism are explicitly spelled out, I think
> you're missing the point.
>
> Ultimately it is an attitude.  When you point out a mistake make it
> either about:
> 1.  Helping the person who made the mistake to improve because you
> want to see them make better contributions (which they aren't going to
> do if you drive them off).
> 2.  If you feel that somebody simply isn't going to cut it, then by
> all means report them so that their commit access can be revoked.
>
> Either of these has the potential to make Gentoo better.  Simply
> posting flames isn't likely to change the behavior of people who need
> #2, and it is likely to discourage people who need #1.  Either is
> against all of our interests in making the distro we benefit from
> better.
>
+1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 15/05/16 01:59, Rich Freeman wrote:
> On Sat, May 14, 2016 at 7:40 PM, Aaron Bauman  wrote:
>> Please enlighten me as to what was impolite here?  The strong language of
>> "seriously" or definitively stating that the individual did not perform the
>> necessary QA actions before committing?
> He actually didn't "state" anything at all - he posted a set of
> rhetorical questions.  And the use of "seriously" was inflammatory.
> In fact, if you're trying to avoid injecting passion into a discussion
> it is worth thinking carefully about just about any word ending in
> "ly" that you put into a sentence.  Nine times out of ten the word
> isn't necessary and can cause more harm than good.
>
>> Both of which are completely called
>> for and appropriate.  No vulgarity, insults, or demeaning words were used.
> I disagree.  The tone was uncivil and demeaning.
>
>> How would you have responded professionally?
>>
> How about this:
>
> You inserted this code snippet into the middle of a command line, so
> it is certain to break in either case.  This should have been detected
> during testing; please be sure to test changes to ebuilds/eclasses
> before committing them.  Additionally eclass changes should be
> submitted to the lists for review in any case prior to being
> committed.
>
> Or by all means refer the issue to QA/Comrel if you want to escalate it.
>
> I'm in no way suggesting that we should accept bad commits.  IMO when
> we see bad commits we should:
>
> 1.  Just point them out politely if it is a one-off.  ANYBODY can make
> a mistake.
> 2.  If they're a trend or show signs of bad practices like not testing
> changes then escalate to QA/Comrel.
> 3.  Let QA/Comrel do their job and block commit access or refer the
> dev for more mentoring/etc as appropriate.  Then we actually fix the
> problem instead of just yelling at each other.
>
+1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman  wrote:
> On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
>> On Sun, 15 May 2016 08:40:39 +0900
>>
>> Aaron Bauman  wrote:
>> > Please enlighten me as to what was impolite here?  The strong
>> > language of "seriously" or definitively stating that the individual
>> > did not perform the necessary QA actions before committing?  Both of
>> > which are completely called for and appropriate.  No vulgarity,
>> > insults, or demeaning words were used. How would you have responded
>> > professionally?
>>
>> It's important to remember that Gentoo is run by volunteers. Expecting
>> a professional standard when it comes to the quality of commit
>> criticism is unfair.
>
> Applying that same rationale, it would be unfair to say that an undescribed
> level of professionalism in communication is required as well.  Nothing here
> violates the CoC.
>

If you're only able to behave in a professional manner if the
standards of professionalism are explicitly spelled out, I think
you're missing the point.

Ultimately it is an attitude.  When you point out a mistake make it
either about:
1.  Helping the person who made the mistake to improve because you
want to see them make better contributions (which they aren't going to
do if you drive them off).
2.  If you feel that somebody simply isn't going to cut it, then by
all means report them so that their commit access can be revoked.

Either of these has the potential to make Gentoo better.  Simply
posting flames isn't likely to change the behavior of people who need
#2, and it is likely to discourage people who need #1.  Either is
against all of our interests in making the distro we benefit from
better.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 7:40 PM, Aaron Bauman  wrote:
>
> Please enlighten me as to what was impolite here?  The strong language of
> "seriously" or definitively stating that the individual did not perform the
> necessary QA actions before committing?

He actually didn't "state" anything at all - he posted a set of
rhetorical questions.  And the use of "seriously" was inflammatory.
In fact, if you're trying to avoid injecting passion into a discussion
it is worth thinking carefully about just about any word ending in
"ly" that you put into a sentence.  Nine times out of ten the word
isn't necessary and can cause more harm than good.

> Both of which are completely called
> for and appropriate.  No vulgarity, insults, or demeaning words were used.

I disagree.  The tone was uncivil and demeaning.

> How would you have responded professionally?
>

How about this:

You inserted this code snippet into the middle of a command line, so
it is certain to break in either case.  This should have been detected
during testing; please be sure to test changes to ebuilds/eclasses
before committing them.  Additionally eclass changes should be
submitted to the lists for review in any case prior to being
committed.

Or by all means refer the issue to QA/Comrel if you want to escalate it.

I'm in no way suggesting that we should accept bad commits.  IMO when
we see bad commits we should:

1.  Just point them out politely if it is a one-off.  ANYBODY can make
a mistake.
2.  If they're a trend or show signs of bad practices like not testing
changes then escalate to QA/Comrel.
3.  Let QA/Comrel do their job and block commit access or refer the
dev for more mentoring/etc as appropriate.  Then we actually fix the
problem instead of just yelling at each other.

-- 
Rich

[gentoo-dev] [PATCH v2 2/4] ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67 #572144

[Göktürk Yüksek]

A major rewrite of the section. Here is a brief summary of changes:
- Remove the information about the  tag per GLEP 67
- Restructure the section in the following order:
  - metadata.xml syntax
  - package metadata
- metadata examples
- maintainer-needed
  - category metadata
- Update the tables for metadata.xml syntax per GLEP 67
- Rewrite the package metadata examples to reflect better on GLEP 67
  and enhance with more explanations
- Assign meaningful titles to package metadata examples instead of
  using "First Example", "Second Example" etc.
- Add a subsection for handling maintainer-needed in metadata.xml
  per GLEP 67 and provide an example

This commit also makes #545272 obsolete.

Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=572144
Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=545272
Signed-off-by: Göktürk Yüksek 
---
 ebuild-writing/misc-files/metadata/text.xml | 418 
 1 file changed, 238 insertions(+), 180 deletions(-)

diff --git a/ebuild-writing/misc-files/metadata/text.xml 
b/ebuild-writing/misc-files/metadata/text.xml
index 2324f53..31ec926 100644
--- a/ebuild-writing/misc-files/metadata/text.xml
+++ b/ebuild-writing/misc-files/metadata/text.xml
@@ -10,16 +10,7 @@ package or category.
 
 
 
-Package Metadata
-
-
-For packages, metadata.xml can specify a long description and
-maintainer information. If a long description in any language is
-provided, an English long description must be present. A typical
-example might look like:
-
-
-
+Syntax
 
 
 
@@ -39,13 +30,10 @@ A metadata.xml file can contain a number of 
tags:
 This is the root element of the metadata.xml file for
 packages. It has no attributes. The following subtags are
 allowed:
-herd,
 maintainer,
 longdescription,
 use, and
 upstream.
-There should be at least one herd or
-maintainer subtag.
   
 
 
@@ -62,26 +50,16 @@ A metadata.xml file can contain a number of 
tags:
 
 
   
-herd
-  
-  
-If a package is maintained by one or more herds, names of these herds
-can be specified with the herd tag. The names
-used in this tag must be the same as specified in the https://sources.gentoo.org/viewcvs.py/*checkout*/gentoo/xml/htdocs/proj/en/metastructure/herds/herds.xml?content-type=text/plainrev=HEAD;>herds.xml
-file.
-  
-
-
-  
 maintainer
   
   
-Besides being part of a herd, a package can also be maintained directly. 
-The maintainers of a package can be specified with the 
-maintainer tag. This tag has one required subtag: 
+This tag specifies the persons and/or projects responsible for
+the maintenance of a package. The type attribute must
+be specified and can be either "person" or
+"project". There is one required subtag:
 email. It has two optional subtags:
-name, and description.
+name and
+description.
   
 
 
@@ -207,8 +185,7 @@ A metadata.xml file can contain a number of 
tags:
 
 
 
-There are also some attributes that can be used with these tags. They are all
-optional:
+There are also some attributes that can be used with these tags:
 
 
 
@@ -235,7 +212,7 @@ optional:
 
   restrict
   
-herd, maintainer, 
+maintainer,
 longdescription, flag
   
   
@@ -244,12 +221,7 @@ optional:
 without this attribute must also exist. That tag without the restrict 
 attribute will serve as the default. The format of the restrict attribute 
 is that of the DEPEND flag, except that "" and 
-"" need to be specified by lt; and gt;.
-
-For example, in the sys-libs/db package, 
-restrict="gt;=sys-libs/db-3.2.9-r5"  on the
-maintainer tag shows that I'm currently maintaining all
-versions greater then 3.2.9-r5.
+"" need to be specified by "lt;" and "gt;".
   
 
 
@@ -282,212 +254,298 @@ optional:
 remote-id
   
   
-A string identifying the type of upstream source. A list of valid strings 
are kept in metadata.dtd.
+A string identifying the type of upstream source. A list of valid strings 
are kept in
+https://www.gentoo.org/dtd/metadata.dtd;>metadata.dtd.
 Developers should email the gentoo-dev mailing list before using a new 
type value. 
   
 
+
+  type
+  
+maintainer
+  
+  
+Defines the type of the maintainer for a package. There are only
+two valid values: "person" and "project". The latter
+denotes an official
+
+Gentoo project.
+  
+
 
 
 
 
-
-
-
 
-
 
-Metadata Examples
-
-First Example
+Package Metadata
 
-
 
-In this first example we provide you with the metadata.xml for 
-OpenOffice of which the ebuilds are completely managed by a herd called
-openoffice:
+All packages must include a metadata.xml file which
+provides information about package description, maintainers, local USE
+flags, upstream etc.
 
 
-
-?xml version='1.0' encoding='UTF-8'?
-!DOCTYPE pkgmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd";
-pkgmetadata
-  herdopenoffice/herd
-  

[gentoo-dev] [PATCH v2 3/4] ebuild-writing/misc-files/metadata: update wrt slotting and per GLEP 68

[Göktürk Yüksek]

Add information about specifying slots and subslots in the
metadata.

Also, update the section according to the specifications in GLEP 68,
clarify some of the tags better, and reorder the tags to improve the
flow of the text.

Signed-off-by: Göktürk Yüksek 
---
 ebuild-writing/misc-files/metadata/text.xml | 140 ++--
 1 file changed, 93 insertions(+), 47 deletions(-)

diff --git a/ebuild-writing/misc-files/metadata/text.xml 
b/ebuild-writing/misc-files/metadata/text.xml
index 31ec926..3d135a6 100644
--- a/ebuild-writing/misc-files/metadata/text.xml
+++ b/ebuild-writing/misc-files/metadata/text.xml
@@ -14,7 +14,15 @@ package or category.
 
 
 
-A metadata.xml file can contain a number of tags:
+A metadata file follows the syntax defined in
+https://wiki.gentoo.org/wiki/GLEP:68;>GLEP 68.
+The character set must be UTF-8 as specified by
+https://wiki.gentoo.org/wiki/GLEP:31;>GLEP 31.
+
+
+
+The following table summarizes the tags that may appear in a
+metadata.xml:
 
 
 
@@ -24,28 +32,41 @@ A metadata.xml file can contain a number of 
tags:
 
 
   
+catmetadata
+  
+  
+This is the root element of the metadata.xml file for
+categories. It has no attributes. It contains a number of
+longdescription tags, each for a different
+language.
+  
+
+
+  
 pkgmetadata
   
   
 This is the root element of the metadata.xml file for
 packages. It has no attributes. The following subtags are
 allowed:
-maintainer,
 longdescription,
+maintainer,
+slots,
 use, and
 upstream.
+While all the subtags are optional, upstream may
+appear at most once.
   
 
 
+  longdescription
   
-catmetadata
-  
-  
-This is the root element of the metadata.xml file for
-categories as per https://wiki.gentoo.org/wiki/GLEP:34;>GLEP 
34.
-It has no attributes. It contains a number of 
-longdescription tags, each for a different 
-language.
+This tag contains a description for a category or a package. For
+packages, it is used to augment the
+
+DESCRIPTION field in the ebuilds themselves. This tag has
+two optional subtags: pkg and
+cat.
   
 
 
@@ -83,11 +104,25 @@ A metadata.xml file can contain a number of 
tags:
   
 
 
-  longdescription
+  slots
+  
+This tag describes the
+slots of a package.
+It has two optional subtags: slot and subslots.
+  
+
+
+  slot
+  
+This contains information for a particular slot. The name
+attribute is mandatory and specifies the name of the slot.
+  
+
+
+  subslots
   
-This tag contains a description of the package. This is to augment the 
-DESCRIPTION field in the ebuilds themselves. This tag has two optional
-subtags: pkg and cat.
+Describes the meaning of subslots for the whole package. This
+tag may appear at most once.
   
 
 
@@ -113,25 +148,30 @@ A metadata.xml file can contain a number of 
tags:
   upstream
   
 This tag contains information about the upstream developers/project.
+It supports multiple optional subtags: maintainer,
+changelog, doc, bugs-to,
+and remote-id.
   
 
 
   maintainer
   
-Name and e-mail of an upstream maintainer. May appear more than once.
+Provides information about the upstream maintainer. It requires a
+name subtag to be specified, supports an optional
+email subtag and an optional status attribute.
   
 
 
-  email
+  name
   
-The email address of an upstream may appear only once and must appear in 
first place.
+The name of an upstream maintainer should contain a block of text with 
upstream's name.
+This element is mandatory for an upstream maintainer and must appear 
exactly once.
   
 
 
-  name
+  email
   
-The name of an upstream maintainer should contain a block of text with 
upstream's name.
-This element is mandatory for an upstream maintainer and must appear only 
once.
+The email address of an upstream maintainer. May appear only once.
   
 
 
@@ -141,7 +181,7 @@ A metadata.xml file can contain a number of 
tags:
 The URL must be version independent and must point to a changelog which is 
only
 updated on new releases of the corresponding package. (This also implies 
that
 one can link to an automatically updated changelog in case of vcs snapshots
-only.)
+only). May appear at most once.
   
 
 
@@ -151,14 +191,14 @@ A metadata.xml file can contain a number of 
tags:
 found. The link must not point to any third party documentation and must be
 version independent. If the documentation is available in more than one 
language,
 a lang attribute can be used which follows the same rules as the one for
-longdescription.
+longdescription.
   
 
 
   bugs-to
   
 Should contain a place where bugs can be filed, a URL or an e-mail address 
prefixed
-with mailto:.
+with mailto:. May appear at most once.
   
 
 
@@ -167,12 +207,14 @@ A metadata.xml file can 

[gentoo-dev] [PATCH v2 4/4] ebuild-writing/misc-files/metadata: add an example for slots and subslots

[Göktürk Yüksek]

Signed-off-by: Göktürk Yüksek 
---
 ebuild-writing/misc-files/metadata/text.xml | 50 +
 1 file changed, 50 insertions(+)

diff --git a/ebuild-writing/misc-files/metadata/text.xml 
b/ebuild-writing/misc-files/metadata/text.xml
index 3d135a6..486af11 100644
--- a/ebuild-writing/misc-files/metadata/text.xml
+++ b/ebuild-writing/misc-files/metadata/text.xml
@@ -549,6 +549,56 @@ is demonstrated.
 
 
 
+
+Slots and Subslots
+
+
+
+The main focus of this example is to demonstrate how slots and
+subslots are specified, by examining the metadata of
+media-libs/libpng. There may be multiple reasons for
+slotting depending on the nature of the package. For this particular
+package, it can be seen that the slots are used to provide different
+versions of the library with varying binary compatibility and that
+developers are advised to build against the slot 0. Furthermore,
+different versions of this package with the same subslot provide the
+same Application Binary Interface (ABI), according to the description
+specified in the subslots tag.
+
+
+
+?xml version="1.0" encoding="UTF-8"?
+!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd";
+pkgmetadata
+  maintainer type="project"
+emailbase-sys...@gentoo.org/email
+nameGentoo Base System/name
+  /maintainer
+  use
+flag name="apng"support unofficial APNG (Animated PNG) 
spec/flag
+  /use
+  upstream
+remote-id type="cpe"cpe:/a:libpng:libpng/remote-id
+remote-id type="sourceforge"apng/remote-id
+  /upstream
+  slots
+slot name="0"
+  For building against. This is the only slot
+  that provides headers and command line tools.
+/slot
+slot name="1.2"
+  For binary compatibility, provides libpng12.so.0 only.
+/slot
+slot name="1.5"
+  For binary compatibility, provides libpng15.so.15 only.
+/slot
+subslotsReflect ABI compatibility for libpng.so./subslots
+  /slots
+/pkgmetadata
+
+
+
+
 
 
 
-- 
2.7.3

[gentoo-dev] [PATCH v2 1/4] general-concepts/herds-and-projects: update per GLEP 67 #572144 #549490

[Göktürk Yüksek]

The changes are:
- Rename the title to "Projects and Herds" to put the emphasis
  on projects
- Explain projects and subprojects in a new "Projects" section
- Add a subsection for starting new projects
- Add a subsection for joining/leaving a project
- Put a warning label at the beginning of the "Herds" section,
  declare it obsolete, and preserve it for historical reasons

Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=572144
Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=549490
Signed-off-by: Göktürk Yüksek 
---
 general-concepts/herds-and-projects/text.xml | 101 ++-
 1 file changed, 100 insertions(+), 1 deletion(-)

diff --git a/general-concepts/herds-and-projects/text.xml 
b/general-concepts/herds-and-projects/text.xml
index e030150..81b1885 100644
--- a/general-concepts/herds-and-projects/text.xml
+++ b/general-concepts/herds-and-projects/text.xml
@@ -1,10 +1,106 @@
 
 
 
-Herds and Projects
+Projects and Herds
 
 
 
+
+Projects
+
+
+
+The management structure of Gentoo, called the "metastructure", is
+defined in
+https://wiki.gentoo.org/wiki/GLEP:39#Specification;>
+GLEP 39. In Gentoo, a project is a group of developers working
+towards a common goal in various different areas. For example, the
+https://wiki.gentoo.org/wiki/Project:Devmanual;>
+Devmanual project focuses on maintaining this document. Many
+others are responsible for maintaining packages. Projects spanning a
+large area of topics can have multiple subprojects specializing in
+particular fields within the domain of the parent project and thus
+form a project hierarchy.
+
+
+
+A package maintained by a project needs to have the
+project explicitly listed as a maintainer in its
+metadata.xml.
+The full listing of all the projects can be found on
+https://api.gentoo.org/metastructure/projects.xml;>
+api.gentoo.org or on the
+https://wiki.gentoo.org/wiki/Project:Gentoo;>wiki.
+
+
+
+Starting New Projects
+
+
+
+According to the metastructure any developer may create a new
+project. There are two procedures involved in starting a new project:
+
+
+  
+Create a new project page https://wiki.gentoo.org/wiki/Gentoo_Wiki:Developer_Central/Project_pages;>
+through the wiki.
+  
+  
+Post a Request For Comments (RFC) email to the gentoo-dev
+mailing list.
+  
+
+
+There is no approval required for the RFC and negative comments do not
+block a developer from creating a project. Competing projects are
+allowed to co-exist in Gentoo; existence of another project with
+similar goals do not block another developer from starting a new
+project with the same goals.
+
+
+
+
+
+Joining and Leaving a Project
+
+
+
+Members of a project are managed through the project's page on the
+Gentoo Wiki. Each page has a "Project" template in its source which
+lists the members of the project. Simply modifying the list is
+sufficient for adding or removing a developer. Note that different
+projects have different requirements and procedures for recruiting
+developers, which may require prior arrangements to be made before
+modifying the member list.
+
+
+
+Developers should remember to add themselves to the alias by editing
+/var/mail/alias/misc/alias name on
+dev.gentoo.org. For example, the alias for the Devmanual project is
+located at /var/mail/alias/misc/devmanual, which corresponds to
+the project's email address devman...@gentoo.org.
+
+
+
+
+
+
+
+
+
+Herds
+
+
+
+Herds have been declared obsolete as per the Gentoo Council's https://projects.gentoo.org/council/meeting-logs/20160110-summary.txt;>
+decision on January 10, 2016. The following section is preserved
+for historical purposes.
+
+
 
 A herd is a collection of packages with an associated set of 
maintainers.
 It can happen for example because of retirement that a herd has no developers
@@ -27,6 +123,9 @@ as the silo bootloader). This is not always 
the case.
 
 
 
+
+
+
 
 
 
-- 
2.7.3

[gentoo-dev] [PATCH v2 0/4] devmanual: update the docs per GLEP 67 and 68

[Göktürk Yüksek]

This is the second iteration of the GLEP 67 and GLEP 68 combined
changeset. It also adds documentation about slotting in metadata.xml.

The changes compared to the previous iteration are:
- GLEP 34 reference removed as suggested by ulm
- The proper term "slot dependency specifier" is used
  instead of "slot operator" as suggested by ulm
- Clarified that  may appear at most once
- Clarified that  may appear at most once
- Clarified that  may appear at most once
- Minor cosmetic fixes

The previous iteration of the changeset can be found here:
https://archives.gentoo.org/gentoo-dev/message/54918d35b9ffe3751abd45e48dbb3da0

You can review the changes on Github for your own convenience:
https://github.com/gktrk/devmanual.gentoo.org/compare/master...gktrk:glep67_68-v2

The HTML version of the devmanual with the proposed changes can be found at:
http://devmanual.qui-gon.org/

Göktürk Yüksek (4):
  general-concepts/herds-and-projects: update per GLEP 67 #572144
#549490
  ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67
#572144
  ebuild-writing/misc-files/metadata: update wrt slotting and per GLEP
68
  ebuild-writing/misc-files/metadata: add an example for slots and
subslots

 ebuild-writing/misc-files/metadata/text.xml  | 588 +--
 general-concepts/herds-and-projects/text.xml | 101 -
 2 files changed, 471 insertions(+), 218 deletions(-)

-- 
2.7.3

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Aaron Bauman]

On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
> On Sun, 15 May 2016 08:40:39 +0900
> 
> Aaron Bauman  wrote:
> > Please enlighten me as to what was impolite here?  The strong
> > language of "seriously" or definitively stating that the individual
> > did not perform the necessary QA actions before committing?  Both of
> > which are completely called for and appropriate.  No vulgarity,
> > insults, or demeaning words were used. How would you have responded
> > professionally?
> 
> It's important to remember that Gentoo is run by volunteers. Expecting
> a professional standard when it comes to the quality of commit
> criticism is unfair.

Applying that same rationale, it would be unfair to say that an undescribed 
level of professionalism in communication is required as well.  Nothing here 
violates the CoC.

-- 
Cheers,
Aaron Bauman
Gentoo Linux Developer
GnuPG FP: 1536 F4B3 72EB 9C54 11F5  5C43 246D 23A2 10FB 0F3E

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ciaran McCreesh]

On Sun, 15 May 2016 08:40:39 +0900
Aaron Bauman  wrote:
> Please enlighten me as to what was impolite here?  The strong
> language of "seriously" or definitively stating that the individual
> did not perform the necessary QA actions before committing?  Both of
> which are completely called for and appropriate.  No vulgarity,
> insults, or demeaning words were used. How would you have responded
> professionally?

It's important to remember that Gentoo is run by volunteers. Expecting
a professional standard when it comes to the quality of commit
criticism is unfair.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Aaron Bauman]

On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
> On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman  wrote:
> > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:
> >> On Sat, 7 May 2016 23:25:58 +0200
> >> 
> >> Michał Górny  wrote:
> >> > Do you seriously expect this code to work? How about testing? Or
> >> > reading diffs before committing?
> > 
> > Absolutely nothing wrong was said here.  Obviously the code was not tested
> > and Michal pointed that out very plainly.
> 
> It is actually possible to communicate both plainly and politely at
> the same time.  This does not require sacrificing any commitment to
> quality at all.  Really the only downside is having more of an
> appearance of professionalism.

Please enlighten me as to what was impolite here?  The strong language of 
"seriously" or definitively stating that the individual did not perform the 
necessary QA actions before committing?  Both of which are completely called 
for and appropriate.  No vulgarity, insults, or demeaning words were used.  
How would you have responded professionally?

-- 
Cheers,
Aaron Bauman
Gentoo Linux Developer
GnuPG FP: 1536 F4B3 72EB 9C54 11F5  5C43 246D 23A2 10FB 0F3E

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT

[Göktürk Yüksek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Mike Gilbert:
> The current description of ROOT makes no sense and just confuses
> people. The new description is paraphrased from PMS. --- 
> ebuild-writing/variables/text.xml | 5 +++-- 1 file changed, 3
> insertions(+), 2 deletions(-)
> 
> diff --git a/ebuild-writing/variables/text.xml
> b/ebuild-writing/variables/text.xml index ef15347..6ba6379 100644 
> --- a/ebuild-writing/variables/text.xml +++
> b/ebuild-writing/variables/text.xml @@ -100,8 +100,9 @@ them.  
> ROOT  -  Path to the root directory. When
> not using ${D}, -  always prepend ${ROOT} to the
> path. +  The absolute path to the root directory into which the
> package is to be merged. +  Use this when refering to installed
> files in pkg_* functions. +  Never use this in
> src_* functions.   
> 

Sorry for the late reply. There is actually a bug for this issue [0].
I'll rebase the patch attached to the bug on top of yours if you have
no technical objections to the content.

[0] https://bugs.gentoo.org/show_bug.cgi?id=144332

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJXN5oEAAoJEIT4AuXAiM4zCBoIAJb45hK2TtB4CpPMDC474XBc
sLk7H+2dDf4mFIkpqr6sTQlW4p/B+qNf/ov/RPC6/Rq3paDNsM9vZYa793pnVk0N
VjJo7iUA5Nmyv7mvgurMNFuiM5VjE3+64QGyTdw5Z9bBDYkWdK4bklZT1lCfIgcQ
OPpuLmuv80QpqUPyEqViqrmLaX9ajogGzeRlUxqUZJtNypNNJxSJ6xtUoLv/aEu5
htixSAMgUl25f+Xz6VY8GY/bhChx6gnEnzMolWQTJqiwfNgYCiRKLtZhAi0AkUwt
37xkVmjM48j9c0x5Dd5Wdk/nNKECatP0FthXcbzzHcNv46XXa9cNre6+8OcVzKc=
=fyKs
-END PGP SIGNATURE-

Re: [gentoo-dev] News Item: LastPass package migration

[Göktürk Yüksek]

Andrew Udvare:
> On 08/05/16 16:56, Andrew Udvare wrote:
>> On 07/05/16 22:25, Göktürk Yüksek wrote:
>>> Users of Chrome/Chromium and Opera browsers need to switch to
>>> app-admin/lastpass-binary-features and follow the instructions
>>> displayed on the screen after the installation to complete the process.
>>>
>> For Chromium, is there supposed to be a plugin listed in
>> chrome://plugins after installation? Supposedly I enabled native
>> messaging for the plugin but nothing for LastPass is listed at
>> chrome://plugins.
>>
>> Andrew
>>
> Actually I think I got it. Once you do everything correctly, and you go to
> 
> chrome://extensions/?options=hdokiejnpimakedhajhdlcegeplioahd (LastPass
> extension options)
> 
> under 'Advanced', you will not see a link to install the binary
> component anymore.
> 
Right. You can find the list by listing the contents of
'/etc/chromium/native-messaging-hosts/'. For LastPass, we install a file
named 'com.lastpass.nplastpass.json' that defines which extensions are
allowed to talk to the binary component.

> Andrew
> 

--
gokturk

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 3:21 PM, M. J. Everitt  wrote:
> On 14/05/16 18:52, Rich Freeman wrote:
>> On Sat, May 14, 2016 at 1:07 PM, landis blackwell
>>  wrote:
>>> No fun allowed
>>>
>> Are you saying that you don't want people to have fun developing
>> Gentoo?  Or are you trying to say that it is impossible to have fun
>> developing Gentoo without insulting strangers?  I don't think anybody
>> minds two friends teasing each other.
>>
> I think my gut feeling would go "there's a time and a place..." .. and
> err on the g-dev ML probably not being it .. unless everyone else is in
> on the 'joke' ..
>

Sure, and just to be clear I don't think we should be bothered by
informality and joking around.  If you have a good relationship with
somebody and poking at each other is just how you relate, you can get
away with it.  We shouldn't have to walk on eggshells, but it just
seems like we get a lot of flames in general going around and IMO at
least it seems like it makes the distro a bit less fun.

Of course we shouldn't lower our standards for quality, and I suspect
that most of the people who do commit mistakes to the tree would
probably agree, at least when they're sober.  :)

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Samstag, 14. Mai 2016, 18:59:02 schrieb M. J. Everitt:
> 
> I think the time is coming, given the diversity of members of this list,
> to add  tags when we are not describing something
> literally. 

wouldnt a  tag be sufficient?

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXN4VVXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkXskQAJJ6LWQ1b0Ap27SAFGnTIqJb
oYhGf8r3VoOxjVbqOKRVZnOZkudQ5KiURxUv+vAZbbomw4SMiV/gn1T/8V8xafbv
KCL7UJOaW4AXgCZ+dFaV2jjTbVrFSMtvkeKwl3klpqPgylk9Q0Vudm1a058iBPRQ
9VPNX14Ooj3cKyimCYesznwH8cGv7cCUZA/MmjnqCQyKy+N5kxDyKyVdEECQ2bEY
D/YDFoTtizixC8HS/OmOzRfCGRe3aPzHyzOMWL7FgCr9fnOE4METSa2kf9GQgViv
9g3RMfpQ4gudCQ/WcqEVDWUt8XlHxFvwdmleywP+Rh81MbUnkaLCA3dnk2Ev86su
s2g5ltS2ozOlCkeryzenbZ1Ezk66kE6o+lBtC1MGWL5MDZVRZvIM1zCaYEqAwabC
jDikqnGxWT3Lvyi7Jmus1p+vjty2LV00yA0JczED7tXSILUqW9ym2Trm/fAd1O+x
NBMMnrrzWW28lyLFUZ+akRFvR35shE1KiISW7GVoorVKtmL8er6LkxYVkvjYi2Vn
Ze+/mlxHNpJh1KjfQ3MC1MOqJQO3ZeOF0AFMPjxMvHFP+5J52PUdtTQeo68080kr
UpFzlwE4nJj5CxMMYgqn7XVjgoaI/jZKqWdUN2h6cj2OwZIe58rIvKroWnUYaVOD
4IsP85PN+scg0Evuj4wa
=jNhK
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 14/05/16 18:52, Rich Freeman wrote:
> On Sat, May 14, 2016 at 1:07 PM, landis blackwell
>  wrote:
>> No fun allowed
>>
> Are you saying that you don't want people to have fun developing
> Gentoo?  Or are you trying to say that it is impossible to have fun
> developing Gentoo without insulting strangers?  I don't think anybody
> minds two friends teasing each other.
>
I think my gut feeling would go "there's a time and a place..." .. and
err on the g-dev ML probably not being it .. unless everyone else is in
on the 'joke' ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 1:07 PM, landis blackwell
 wrote:
> No fun allowed
>

Are you saying that you don't want people to have fun developing
Gentoo?  Or are you trying to say that it is impossible to have fun
developing Gentoo without insulting strangers?  I don't think anybody
minds two friends teasing each other.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[landis blackwell]

No fun allowed
On May 14, 2016 12:06 PM, "Rich Freeman"  wrote:

> On Sat, May 14, 2016 at 12:59 PM, M. J. Everitt 
> wrote:
> > On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote:
> >> Gordon Pettey schrieb:
> >>
> >>> So, it's perfectly okay to make direct commits of obviously broken
> >>> code that
> >>> has no chance of working, because community something mumble...
> >>
> >> You may have missed some sarcasm in the post which you replied to.
> >> Plus, I don't think anybody said or implied that committing broken
> >> things is ok.
> >>
> >>
> >> Best regards,
> >> Chí-Thanh Christopher Nguyễn
> >>
> > I think the time is coming, given the diversity of members of this list,
> > to add  tags when we are not describing something
> > literally. It becomes very difficult to follow the thread of
> > conversation when people are (not) communicating their true thoughts!!
> >
>
> While this is certainly sensible, the irony here is that this whole
> discussion was started by somebody making a sarcastic remark when
> simply pointing out a mistake would have been just as functional.
>
> Nobody thinks it is ok to commit broken code.  What it seems like
> we'll be debating until there is only one of us left is how
> unprofessional we should be when pointing that out.
>
> --
> Rich
>
>

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 14/05/16 18:06, Rich Freeman wrote:
>
> While this is certainly sensible, the irony here is that this whole
> discussion was started by somebody making a sarcastic remark when
> simply pointing out a mistake would have been just as functional.
>
> Nobody thinks it is ok to commit broken code.  What it seems like
> we'll be debating until there is only one of us left is how
> unprofessional we should be when pointing that out.
>
+1 .. is it time to add  tags too?! :]

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 12:59 PM, M. J. Everitt  wrote:
> On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote:
>> Gordon Pettey schrieb:
>>
>>> So, it's perfectly okay to make direct commits of obviously broken
>>> code that
>>> has no chance of working, because community something mumble...
>>
>> You may have missed some sarcasm in the post which you replied to.
>> Plus, I don't think anybody said or implied that committing broken
>> things is ok.
>>
>>
>> Best regards,
>> Chí-Thanh Christopher Nguyễn
>>
> I think the time is coming, given the diversity of members of this list,
> to add  tags when we are not describing something
> literally. It becomes very difficult to follow the thread of
> conversation when people are (not) communicating their true thoughts!!
>

While this is certainly sensible, the irony here is that this whole
discussion was started by somebody making a sarcastic remark when
simply pointing out a mistake would have been just as functional.

Nobody thinks it is ok to commit broken code.  What it seems like
we'll be debating until there is only one of us left is how
unprofessional we should be when pointing that out.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote:
> Gordon Pettey schrieb:
>
>> So, it's perfectly okay to make direct commits of obviously broken
>> code that
>> has no chance of working, because community something mumble...
>
> You may have missed some sarcasm in the post which you replied to.
> Plus, I don't think anybody said or implied that committing broken
> things is ok.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
I think the time is coming, given the diversity of members of this list,
to add  tags when we are not describing something
literally. It becomes very difficult to follow the thread of
conversation when people are (not) communicating their true thoughts!!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Chí-Thanh Christopher Nguyễn]

Gordon Pettey schrieb:


So, it's perfectly okay to make direct commits of obviously broken code that
has no chance of working, because community something mumble...


You may have missed some sarcasm in the post which you replied to.
Plus, I don't think anybody said or implied that committing broken things is ok.


Best regards,
Chí-Thanh Christopher Nguyễn



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] USE flag proposal: memcached

[Matthew Thode]

On 05/14/2016 10:19 AM, Dirkjan Ochtman wrote:
> All,
> 
> I want to add a "memcached" USE flag to mail-filters/rmilter. Before
> doing so, I looked if there was a global USE flag. There is not, but I
> though see usage across 14 packages:
> 
> dev-db/pgpool2[memcached]: Use memcached for query caching
> dev-php/pecl-mysqlnd_qc[memcached]: Use
> dev-libs/libmemcached as a storage handler
> mail-filter/opendkim[memcached]: Add support for using
> dev-libs/libmemcached
> mail-mta/postfix[memcached]: Add support for using
> net-misc/memcached for lookup tables
> net-analyzer/graphite-web[memcached]: Enable memcached support
> net-analyzer/munin[memcached]: Install the packages required for
> memcached monitoring.
> net-mail/automx[memcached]: Enable memcached support
> sys-auth/keystone[memcached]: Installs dependencies needed for using
> memcached as a backend
> sys-cluster/cinder[memcached]: Installs the memcached server
> sys-cluster/gearmand[memcache]: Support memcache daemon (via
> dev-libs/libmemcached) for the queue storage.
> sys-cluster/nova[memcached]: Installs the memcached server
> sys-cluster/swift[memcached]: adds memcached support
> www-servers/lighttpd[memcache]: Enable memcache support for mod_cml
> and mod_trigger_b4_dl
> 
> Most of these seem to depend on dev-libs/libmemcached or
> net-misc/memcached, with a few packages depending on language-specific
> stuff (e.g. dev-perl/Cache-Memcached or dev-python/python-memcached).
> 
> I suppose the description can just be "Enable memcached support".
> 
> Any objections?
> 
> Cheers,
> 
> Dirkjan
> 
+1 from me :D

-- 
-- Matthew Thode (prometheanfire)

[gentoo-dev][PATCH v1] sys-devel/libtool: add m4/libtool.m4 patch for ppc64le #581314

[Leno Hou]

Reference Bug:
Gentoo Bug: https://bugs.gentoo.org/show_bug.cgi?id=581314
GNU Bug: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348

* m4/libtool (LD=elf64lppc): add recognise definition with
CHOST=powerpc64le-unknown-linux-gnu on ppc64le platform and
CHOST=powerpc64-unknown-linux-gnu on ppc64 platform. This
patch sets $LD=elf64lppc on ppc64le and $LD=elf64ppc on ppc64.

Package-Manager: portage-2.2.26
Signed-off-by: Leno Hou 
---
 .../libtool-2.4.6-libtool-m4-for-ppc64le.patch | 41 ++
 sys-devel/libtool/libtool-2.4.6-r1.ebuild  |  1 +
 sys-devel/libtool/libtool-2.4.6-r2.ebuild  |  1 +
 sys-devel/libtool/libtool-2.4.6.ebuild |  1 +
 4 files changed, 44 insertions(+)
 create mode 100644 
sys-devel/libtool/files/libtool-2.4.6-libtool-m4-for-ppc64le.patch

diff --git a/sys-devel/libtool/files/libtool-2.4.6-libtool-m4-for-ppc64le.patch 
b/sys-devel/libtool/files/libtool-2.4.6-libtool-m4-for-ppc64le.patch
new file mode 100644
index 000..946c8c7
--- /dev/null
+++ b/sys-devel/libtool/files/libtool-2.4.6-libtool-m4-for-ppc64le.patch
@@ -0,0 +1,41 @@
+From a08fc6407e6bead83024668227b91556de7292eb Mon Sep 17 00:00:00 2001
+From: Leno Hou 
+Date: Sat, 14 May 2016 14:56:57 +
+Subject: [PATCH] m4/libtool.m4: Fix LD parameters with ppc64 & ppc64le
+ platform
+
+For v2.4.6
+Reference Bug:
+Gentoo Bug: https://bugs.gentoo.org/show_bug.cgi?id=581314
+GNU Bug: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348
+
+* m4/libtool (LD=elf64lppc): add recognise definition with
+CHOST=powerpc64le-unknown-linux-gnu on ppc64le platform and
+CHOST=powerpc64-unknown-linux-gnu on ppc64 platform. This
+patch sets =elf64lppc on ppc64le and =elf64ppc on ppc64.
+
+Signed-off-by: Leno Hou 
+---
+ m4/libtool.m4 | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/m4/libtool.m4 b/m4/libtool.m4
+index a3bc337..91b2e01 100644
+--- a/m4/libtool.m4
 b/m4/libtool.m4
+@@ -1417,10 +1417,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
+ x86_64-*linux*)
+   LD="${LD-ld} -m elf_x86_64"
+   ;;
+-powerpcle-*linux*)
++powerpcle-*linux*|powerpc64le-*linux*)
+   LD="${LD-ld} -m elf64lppc"
+   ;;
+-powerpc-*linux*)
++powerpc-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf64ppc"
+   ;;
+ s390*-*linux*|s390*-*tpf*)
+-- 
+2.7.3
+
diff --git a/sys-devel/libtool/libtool-2.4.6-r1.ebuild 
b/sys-devel/libtool/libtool-2.4.6-r1.ebuild
index 677db33..2038ff0 100644
--- a/sys-devel/libtool/libtool-2.4.6-r1.ebuild
+++ b/sys-devel/libtool/libtool-2.4.6-r1.ebuild
@@ -48,6 +48,7 @@ src_prepare() {
 
epatch "${FILESDIR}"/${PN}-2.4.3-use-linux-version-in-fbsd.patch #109105
epatch "${FILESDIR}"/${P}-fuse-ld.patch
+   epatch "${FILESDIR}"/${PN}-2.4.6-libtool-m4-for-ppc64le.patch #581314
pushd libltdl >/dev/null
AT_NOELIBTOOLIZE=yes eautoreconf
popd >/dev/null
diff --git a/sys-devel/libtool/libtool-2.4.6-r2.ebuild 
b/sys-devel/libtool/libtool-2.4.6-r2.ebuild
index 7e8b7ef..528ce85 100644
--- a/sys-devel/libtool/libtool-2.4.6-r2.ebuild
+++ b/sys-devel/libtool/libtool-2.4.6-r2.ebuild
@@ -53,6 +53,7 @@ src_prepare() {
epatch "${FILESDIR}"/${P}-libtoolize-slow.patch
epatch "${FILESDIR}"/${P}-libtoolize-delay-help.patch
epatch "${FILESDIR}"/${P}-sed-quote-speedup.patch #542252
+   epatch "${FILESDIR}"/${PN}-2.4.6-libtool-m4-for-ppc64le.patch #581314
pushd libltdl >/dev/null
AT_NOELIBTOOLIZE=yes eautoreconf
popd >/dev/null
diff --git a/sys-devel/libtool/libtool-2.4.6.ebuild 
b/sys-devel/libtool/libtool-2.4.6.ebuild
index 71a9b47..e7eeaed 100644
--- a/sys-devel/libtool/libtool-2.4.6.ebuild
+++ b/sys-devel/libtool/libtool-2.4.6.ebuild
@@ -47,6 +47,7 @@ src_prepare() {
use vanilla && return 0
 
epatch "${FILESDIR}"/${PN}-2.4.3-use-linux-version-in-fbsd.patch #109105
+   epatch "${FILESDIR}"/${PN}-2.4.6-libtool-m4-for-ppc64le.patch #581314
pushd libltdl >/dev/null
AT_NOELIBTOOLIZE=yes eautoreconf
popd >/dev/null
-- 
2.7.3

Re: [gentoo-dev] USE flag proposal: memcached

[Brian Dolbec]

On Sat, 14 May 2016 11:32:02 -0400
"Anthony G. Basile"  wrote:

> On 5/14/16 11:19 AM, Dirkjan Ochtman wrote:
> > All,
> > 
> > I want to add a "memcached" USE flag to mail-filters/rmilter. Before
> > doing so, I looked if there was a global USE flag. There is not,
> > but I though see usage across 14 packages:
> > 
> > dev-db/pgpool2[memcached]: Use memcached for query caching
> > dev-php/pecl-mysqlnd_qc[memcached]: Use
> > dev-libs/libmemcached as a storage handler
> > mail-filter/opendkim[memcached]: Add support for using
> > dev-libs/libmemcached
> > mail-mta/postfix[memcached]: Add support for using
> > net-misc/memcached for lookup tables
> > net-analyzer/graphite-web[memcached]: Enable memcached support
> > net-analyzer/munin[memcached]: Install the packages required for
> > memcached monitoring.
> > net-mail/automx[memcached]: Enable memcached support
> > sys-auth/keystone[memcached]: Installs dependencies needed for using
> > memcached as a backend
> > sys-cluster/cinder[memcached]: Installs the memcached server
> > sys-cluster/gearmand[memcache]: Support memcache daemon (via
> > dev-libs/libmemcached) for the queue storage.
> > sys-cluster/nova[memcached]: Installs the memcached server
> > sys-cluster/swift[memcached]: adds memcached support
> > www-servers/lighttpd[memcache]: Enable memcache support for mod_cml
> > and mod_trigger_b4_dl
> > 
> > Most of these seem to depend on dev-libs/libmemcached or
> > net-misc/memcached, with a few packages depending on
> > language-specific stuff (e.g. dev-perl/Cache-Memcached or
> > dev-python/python-memcached).
> > 
> > I suppose the description can just be "Enable memcached support".
> > 
> > Any objections?
> > 
> > Cheers,
> > 
> > Dirkjan
> >   
> 
> its a good idea given its popularity and the unequivocal meaning of
> "memcached".  so i say do it.
> 

+1

-- 
Brian Dolbec 

Re: [gentoo-dev] USE flag proposal: memcached

[Anthony G. Basile]

On 5/14/16 11:19 AM, Dirkjan Ochtman wrote:
> All,
> 
> I want to add a "memcached" USE flag to mail-filters/rmilter. Before
> doing so, I looked if there was a global USE flag. There is not, but I
> though see usage across 14 packages:
> 
> dev-db/pgpool2[memcached]: Use memcached for query caching
> dev-php/pecl-mysqlnd_qc[memcached]: Use
> dev-libs/libmemcached as a storage handler
> mail-filter/opendkim[memcached]: Add support for using
> dev-libs/libmemcached
> mail-mta/postfix[memcached]: Add support for using
> net-misc/memcached for lookup tables
> net-analyzer/graphite-web[memcached]: Enable memcached support
> net-analyzer/munin[memcached]: Install the packages required for
> memcached monitoring.
> net-mail/automx[memcached]: Enable memcached support
> sys-auth/keystone[memcached]: Installs dependencies needed for using
> memcached as a backend
> sys-cluster/cinder[memcached]: Installs the memcached server
> sys-cluster/gearmand[memcache]: Support memcache daemon (via
> dev-libs/libmemcached) for the queue storage.
> sys-cluster/nova[memcached]: Installs the memcached server
> sys-cluster/swift[memcached]: adds memcached support
> www-servers/lighttpd[memcache]: Enable memcache support for mod_cml
> and mod_trigger_b4_dl
> 
> Most of these seem to depend on dev-libs/libmemcached or
> net-misc/memcached, with a few packages depending on language-specific
> stuff (e.g. dev-perl/Cache-Memcached or dev-python/python-memcached).
> 
> I suppose the description can just be "Enable memcached support".
> 
> Any objections?
> 
> Cheers,
> 
> Dirkjan
> 

its a good idea given its popularity and the unequivocal meaning of
"memcached".  so i say do it.

-- 
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

[gentoo-dev] USE flag proposal: memcached

[Dirkjan Ochtman]

All,

I want to add a "memcached" USE flag to mail-filters/rmilter. Before
doing so, I looked if there was a global USE flag. There is not, but I
though see usage across 14 packages:

dev-db/pgpool2[memcached]: Use memcached for query caching
dev-php/pecl-mysqlnd_qc[memcached]: Use
dev-libs/libmemcached as a storage handler
mail-filter/opendkim[memcached]: Add support for using
dev-libs/libmemcached
mail-mta/postfix[memcached]: Add support for using
net-misc/memcached for lookup tables
net-analyzer/graphite-web[memcached]: Enable memcached support
net-analyzer/munin[memcached]: Install the packages required for
memcached monitoring.
net-mail/automx[memcached]: Enable memcached support
sys-auth/keystone[memcached]: Installs dependencies needed for using
memcached as a backend
sys-cluster/cinder[memcached]: Installs the memcached server
sys-cluster/gearmand[memcache]: Support memcache daemon (via
dev-libs/libmemcached) for the queue storage.
sys-cluster/nova[memcached]: Installs the memcached server
sys-cluster/swift[memcached]: adds memcached support
www-servers/lighttpd[memcache]: Enable memcache support for mod_cml
and mod_trigger_b4_dl

Most of these seem to depend on dev-libs/libmemcached or
net-misc/memcached, with a few packages depending on language-specific
stuff (e.g. dev-perl/Cache-Memcached or dev-python/python-memcached).

I suppose the description can just be "Enable memcached support".

Any objections?

Cheers,

Dirkjan

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Gordon Pettey]

On Sat, May 14, 2016 at 6:35 AM, Ciaran McCreesh <
ciaran.mccre...@googlemail.com> wrote:

> Why? Gentoo is about the community. Requiring a basic standard of commit
> quality a) reduces the number of community members who are able to
> contribute, 2) leads to fewer forums posts discussing how to fix
> problems, iii) hurts Gentoo's DistroWatch statistics by reducing the
> volume of commits, and fourthly, discriminates unfairly against
> competency-challenged developers by imposing subjective interpretations
> of the value of source code from a position of unearned authority. This
> is against the code of conduct, and is bad for the community!
>
> So, it's perfectly okay to make direct commits of obviously broken code
that has no chance of working, because community something mumble...

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman  wrote:
> On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:
>> On Sat, 7 May 2016 23:25:58 +0200
>> Michał Górny  wrote:
>> >
>> > Do you seriously expect this code to work? How about testing? Or
>> > reading diffs before committing?
>> >
>
> Absolutely nothing wrong was said here.  Obviously the code was not tested and
> Michal pointed that out very plainly.
>

It is actually possible to communicate both plainly and politely at
the same time.  This does not require sacrificing any commitment to
quality at all.  Really the only downside is having more of an
appearance of professionalism.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Aaron Bauman]

On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:
> On Sat, 7 May 2016 23:25:58 +0200
> Michał Górny  wrote:
> >
> > Do you seriously expect this code to work? How about testing? Or
> > reading diffs before committing?
> >

Absolutely nothing wrong was said here.  Obviously the code was not tested and 
Michal pointed that out very plainly.

> >
> 
> 
> Do you seriously expect us to sit and absorb this form of pious
> put down? From one who knows far better who is entitled to speak down
> to colleagues as is completely lacking a cerebral cortex? Those times

In one sentence you question him about putting someone down then in the next 
sentence you say he is lacking a cerebral cortex... hypocritical.

> are drawing to an end. Did anyone ever teach you to treat folk in such
> manner and expect them to respect it? I don't think so
> Not over my dead cvs perhaps

Not even really sure what that means?  dead cvs?

> 

> --
> kind regards
> 
> Ian Delaney


-- 
Cheers,
Aaron Bauman
Gentoo Linux Developer
GnuPG FP: 1536 F4B3 72EB 9C54 11F5  5C43 246D 23A2 10FB 0F3E

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 14/05/16 12:35, Ciaran McCreesh wrote:
> On Sat, 14 May 2016 11:55:42 +0200
>> Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney:
>>> On Sat, 7 May 2016 23:25:58 +0200  
 Do you seriously expect this code to work? How about testing? Or
 reading diffs before committing?  
>>> Do you seriously expect us to sit and absorb this form of pious
>>> put down? From one who knows far better who is entitled to speak
>>> down to colleagues as is completely lacking a cerebral cortex?
>>> Those times are drawing to an end. Did anyone ever teach you to
>>> treat folk in such manner and expect them to respect it? I don't
>>> think so Not over my dead cvs perhaps  
>> Well, we still do need some commit quality, you know...
> Why? Gentoo is about the community. Requiring a basic standard of commit
> quality a) reduces the number of community members who are able to
> contribute, 2) leads to fewer forums posts discussing how to fix
> problems, iii) hurts Gentoo's DistroWatch statistics by reducing the
> volume of commits, and fourthly, discriminates unfairly against
> competency-challenged developers by imposing subjective interpretations
> of the value of source code from a position of unearned authority. This
> is against the code of conduct, and is bad for the community!
>
In defense of Gentoo at large .. the entry-level to contribute is really
quite low .. and all the documentation for gentoo 'standards' is widely
documented in both the Devmanual (under revision currently) and the
Package Manager Spec. Not only this, but there are active projects
within gentoo to welcome, nurture and develop devs and contributors
alike so that there is a sustainable level of man-power available to
keep up with the demands of users and pace of code development. Ok, it
can be off-putting to those looking in from the outside, but really I
think it benefits more than it costs.

I agree broadly with the ethos of the QA team, gentoo tends to focus on
quality over quantity where commits are concerned. It's better to retain
a stable, reliable set of packages, with additional untested/unstable
packages available via overlays, rather than a massive, unwieldy number
of packages in a broadly unknown state. As it is, there is a deficit of
active people maintaining the less-widely used packages, and also people
able to add new packages to the tree, and this means that resources are
inevitably spread more thinly.

As always there will be a balance, but this thread did start out with
some tit-for-tat between devs, totally unnecessary either in private or
public. So, ditch that bike-shed, and get on with fixing bugs, closing
issues, adding, updating and deprecating packages, folks :]. Thank you.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ciaran McCreesh]

On Sat, 14 May 2016 11:55:42 +0200
> Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney:
> > On Sat, 7 May 2016 23:25:58 +0200  
> > > Do you seriously expect this code to work? How about testing? Or
> > > reading diffs before committing?  
> > 
> > Do you seriously expect us to sit and absorb this form of pious
> > put down? From one who knows far better who is entitled to speak
> > down to colleagues as is completely lacking a cerebral cortex?
> > Those times are drawing to an end. Did anyone ever teach you to
> > treat folk in such manner and expect them to respect it? I don't
> > think so Not over my dead cvs perhaps  
> 
> Well, we still do need some commit quality, you know...

Why? Gentoo is about the community. Requiring a basic standard of commit
quality a) reduces the number of community members who are able to
contribute, 2) leads to fewer forums posts discussing how to fix
problems, iii) hurts Gentoo's DistroWatch statistics by reducing the
volume of commits, and fourthly, discriminates unfairly against
competency-challenged developers by imposing subjective interpretations
of the value of source code from a position of unearned authority. This
is against the code of conduct, and is bad for the community!

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney:
> On Sat, 7 May 2016 23:25:58 +0200

> > 
> > Do you seriously expect this code to work? How about testing? Or
> > reading diffs before committing?
> 
> Do you seriously expect us to sit and absorb this form of pious
> put down? From one who knows far better who is entitled to speak down
> to colleagues as is completely lacking a cerebral cortex? Those times
> are drawing to an end. Did anyone ever teach you to treat folk in such
> manner and expect them to respect it? I don't think so
> Not over my dead cvs perhaps

Well, we still do need some commit quality, you know...

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXNvYeXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkXA4P/jDuTHnBkZfkzwjIbk6ZTi8J
/sb/ypGT3h+tXUoYei2978drsF091WnDU6H+RCj3Lk4LKtPR6pMzL9OEXdihQqJh
+OSZgh1T3pZJAjRWAVeXjgGmSlW9Pmxfnb1G9D9Zv+58cRohQhbZZG3baXih3QBY
2umIqYKgfbq+whtr49YYPVU6mVovQ8esWCAZWw5+vYqw2/9MDIUl4wWJVlDXgo7l
Bmb2t5XudJ5lApfDGhOSaxi2lacPK2WggAlN2XmG5MkjPuQAauEQly8MhxlSUQxX
Q8ZAyqzokPENXq0C+PwrF9TGBaFAQjMAnCLP7F4eo8jDqfsPhTxcthNQRhYXFpx6
/5aXEBb4DZwTOust9hdBUvUM5pUo7P9IyoBVGQdejo87YrLxy1MI0/J2E+GrRQfM
HNRdAwRrhUpQrF6sCyD5mH7uVWdVwdhIY70Lau4d8HIP/J5TRN2FwP7F2zqjjQmz
lUj20/meBvgHlGUgjsi2sb15HLwx2E2OkMrxhYcuE9JuBiaomBnz+OpSlzp2wGwR
X1rXBVz/nvn2nVTH75QybLcjvTO9FfdfGFEGOrjQ/f68sTHpcat+Co9wJjYgD/LA
EtUomNUkIFGcMJAyOBgdgZDiYREFXnlW1FlB94VS4SgcPpkcvxKBruM+DcJDgZ+h
/F5kkAuRtmOsXBN2e1MT
=5e68
-END PGP SIGNATURE-