[gentoo-dev] Re: News item: upgrading to Plasma 5

2016-04-03 Thread Duncan
Michael Palimaka posted on Mon, 04 Apr 2016 05:23:03 +1000 as excerpted:

> The default in KDE 4 was KDM, with lightdm and sddm also supported.
> 
> We included information about migrating away from KDM because it's no
> longer developed or supported and in some cases fails to work with
> Plasma 5 at all.
> 
> lightdm continues to work fine with Plasma 5 so there's no special need
> to replace it.

For clarity, then, why not add a single sentence similar to this (reword 
if appropriate):

KDE 4 also supported lightdm and sddm, and users configured to use those 
display managers can continue to use them without reconfiguration.


Also, a word for users who can't use a desktop/* profile at all, because 
they are for instance using a no-multilib (or x32 or hardened or 
whatever) profile and the desktop profiles aren't available as options 
there, would be appropriate.  Because right now you (as the gentoo/kde 
project) are pretty much leaving these users who can't or simply don't 
want to use the plasma profile, for whatever reason, to their own devices 
out in the unguided cold.

Tho in the news item I'd suggest simply referring them to the upgrade 
guide, and ensure the subject is covered in more detail there.  
Unfortunately, it's not covered there at all, ATM.

That "more detail" in the upgrade guide could be to simply say to check 
the USE flags in (default path)
/usr/portage/profiles/targets/desktop/plasma/make.defaults, and consider 
setting similar USE flags manually.  And similarly the package.use file 
in the same location, for individual packages.

Whether and how you want to describe the effect of policykit in 
use.force, since these users will obviously not be getting that force as 
they can't use that profile, is up to you.  It's already in the 
make.defaults USE list as covered above.  Maybe that's enough.


Meanwhile, one final sentence referring back to the upgrade guide if 
there are problems may also be useful:

The upgrade guide contains further troubleshooting and solutions hints, 
should you run into problems.


(Much as I hate servantware such as skype, the hint on that may well be 
totally unintuitive for many of its gentoo/kde users, for instance.  BTW, 
is that still valid advice given the plasma-desktop sni embedding, now?)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




[gentoo-portage-dev] [PATCH] emerge: add --search-fuzzy and --search-fuzzy-cutoff options (bug 65566)

2016-04-03 Thread Zac Medico
Add --search-fuzzy option, with adjustable similarity ratio cutoff that
defaults to 0.8 (80% similarity).

X-Gentoo-bug: 65566
X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=65566
---
 man/emerge.1   | 13 -
 pym/_emerge/actions.py |  6 --
 pym/_emerge/main.py| 32 +++-
 pym/_emerge/search.py  | 25 +++--
 4 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/man/emerge.1 b/man/emerge.1
index bfa2f73..2727ccb 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -1,4 +1,4 @@
-.TH "EMERGE" "1" "Feb 2016" "Portage VERSION" "Portage"
+.TH "EMERGE" "1" "Apr 2016" "Portage VERSION" "Portage"
 .SH "NAME"
 emerge \- Command\-line interface to the Portage system
 .SH "SYNOPSIS"
@@ -854,6 +854,17 @@ If ebuilds using EAPIs which \fIdo not\fR support 
\fBHDEPEND\fR are built in
 the same \fBemerge\fR run as those using EAPIs which \fIdo\fR support
 \fBHDEPEND\fR, this option affects only the former.
 .TP
+.BR "\-\-search\-fuzzy [ y | n ]"
+Enable or disable fuzzy search for search actions.
+.TP
+.BR "\-\-search\-fuzzy\-cutoff CUTOFF"
+Set similarity ratio cutoff (a floating-point number between 0 and 1).
+Results with similarity ratios lower than the cutoff are discarded.
+This option has no effect unless the \fB\-\-search\-fuzzy\fR option
+is enabled.
+.br
+Defaults to 0.8 (80% similarity).
+.TP
 .BR "\-\-search\-index < y | n >"
 Enable or disable indexed search for search actions. This option is
 enabled by default. The search index needs to be regenerated by
diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py
index 59626ad..caae79a 100644
--- a/pym/_emerge/actions.py
+++ b/pym/_emerge/actions.py
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2016 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 from __future__ import division, print_function, unicode_literals
@@ -1955,7 +1955,9 @@ def action_search(root_config, myopts, myfiles, spinner):
spinner, "--searchdesc" in myopts,
"--quiet" not in myopts, "--usepkg" in myopts,
"--usepkgonly" in myopts,
-   search_index = myopts.get("--search-index", "y") != "n")
+   search_index=myopts.get("--search-index", "y") != "n",
+   fuzzy=myopts.get("--search-fuzzy", False),
+   fuzzy_cutoff=myopts.get("--search-fuzzy-cutoff"))
for mysearch in myfiles:
try:
searchinstance.execute(mysearch)
diff --git a/pym/_emerge/main.py b/pym/_emerge/main.py
index 5dbafee..06c385e 100644
--- a/pym/_emerge/main.py
+++ b/pym/_emerge/main.py
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2016 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 from __future__ import print_function
@@ -156,6 +156,7 @@ def insert_optional_args(args):
'--rebuild-if-unbuilt'   : y_or_n,
'--rebuilt-binaries' : y_or_n,
'--root-deps'  : ('rdeps',),
+   '--search-fuzzy' : y_or_n,
'--select'   : y_or_n,
'--selective': y_or_n,
"--use-ebuild-visibility": y_or_n,
@@ -647,6 +648,16 @@ def parse_opts(tmpcmdline, silent=False):
"choices" :("True", "rdeps")
},
 
+   "--search-fuzzy": {
+   "help": "Enable or disable fuzzy search",
+   "choices": true_y_or_n
+   },
+
+   "--search-fuzzy-cutoff": {
+   "help": "Set similarity ratio cutoff (a floating-point 
number between 0 and 1)",
+   "action": "store"
+   },
+
"--search-index": {
"help": "Enable or disable indexed search (enabled by 
default)",
"choices": y_or_n
@@ -908,6 +919,11 @@ def parse_opts(tmpcmdline, silent=False):
if myoptions.root_deps in true_y:
myoptions.root_deps = True
 
+   if myoptions.search_fuzzy in true_y:
+   myoptions.search_fuzzy = True
+   else:
+   myoptions.search_fuzzy = None
+
if myoptions.select in true_y:
myoptions.select = True
myoptions.oneshot = False
@@ -1000,6 +1016,20 @@ def parse_opts(tmpcmdline, silent=False):
 
myoptions.rebuilt_binaries_timestamp = 
rebuilt_binaries_timestamp
 
+   if myoptions.search_fuzzy_cutoff:
+   try:
+   fuzzy_cutoff = float(myoptions.search_fuzzy_cutoff)
+   except ValueError:
+   fuzzy_cutoff = 0.0
+
+   if fuzzy_cutoff <= 0.0:
+   fuzzy_cutoff = None
+   if not silent:
+  

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

2016-04-03 Thread M. J. Everitt
On 04/04/16 05:57, NP-Hardass wrote:
> On 04/04/2016 12:34 AM, Göktürk Yüksek wrote:
>> +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.
> I'm not particularly fond of this statement.  The implication is that
> most projects require permission, whereas I believe that the opposite
> is true.  To the best of my knowledge, most projects are open, and
> ones that have special requirements almost always list them explicitly
> on their project pages.  As far as I know, the only exception to this
> is new developers, as they are noobs and thus project lead approval is
> a slight quality control. I'd rather see it worded more like:
> 
> Seasoned developers, generally speaking, can join any project at their
> leisure, however, some projects explicitly list restrictions or
> requirements to join such as training, apprenticing, or approval of
> the project lead.  When in doubt, consulting the project/lead prior to
> joining a project.
> 
> 
Still needs some work, I think ... :)



signature.asc
Description: OpenPGP digital signature


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

2016-04-03 Thread NP-Hardass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/04/2016 12:34 AM, Göktürk Yüksek wrote:
> +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.
I'm not particularly fond of this statement.  The implication is that
most projects require permission, whereas I believe that the opposite
is true.  To the best of my knowledge, most projects are open, and
ones that have special requirements almost always list them explicitly
on their project pages.  As far as I know, the only exception to this
is new developers, as they are noobs and thus project lead approval is
a slight quality control. I'd rather see it worded more like:

Seasoned developers, generally speaking, can join any project at their
leisure, however, some projects explicitly list restrictions or
requirements to join such as training, apprenticing, or approval of
the project lead.  When in doubt, consulting the project/lead prior to
joining a project.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXAfRPAAoJEBzZQR2yrxj7ER0P/1CGUdUBNaGNV6BmawohnbIs
U6OsqSGOM1VJk6KjG+wZkhi+BdbNfTrv/3ynrE39fJO1XqmOrBRSJ5PBIpQZHoHP
N6IfiZgUHvGpdFr8nmLrEBNSP9VUZ56UJYS468hWObUOehp1V4TZDfKWAoi1SA5k
RwAZUu0L69I6I06wodnP1yBuIk56sPmCUdwGC0oOmQnEyPdIsQ934VYnRg2yfXqg
8fFaoXdPYOX/Au+dEDGyEWVRd73XRyMEFkt3IVvewph1X/nQ63ArbYsiNvTh/tnO
XLz0M5Tk726ONRRflvb2A5K6fC+/s3wQBGWThLJcuA45MOr470EBsnAy0Ii1ZuD3
WtRT1h57pBO4HEZ1WQfgfAfNRXgp4E8hiCY5Rgd0CcI/Z/QzLrZG49oFaWiTfd7I
wfIWZ0oyrYtL9UiXBU8ArDjQmQRqbS4iATMeXvfHLFUAYjXrySwdlTEa/lK7OVWE
8WAL2SR/UUrzn097NuT2Sj270a9ShmW9rdM6hl9gnRlwbO4+K2KwXHh1FK3sx60g
MOAgy0jxVaNWqjwrXEocXbziQIqofmRa47mcjJ1/ipH+gWZfoYt6gICIziIkCJxH
GaCURYGwFdGvfVLdDsKaopVcJ31XbQZHckYSrJcRqtLd2QCTRV19R/FYORDiTJU2
LTyD0d43Kh5E6Ob7PA6b
=50RB
-END PGP SIGNATURE-



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

2016-04-03 Thread 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 | 128 ++-
 1 file changed, 127 insertions(+), 1 deletion(-)

diff --git a/general-concepts/herds-and-projects/text.xml 
b/general-concepts/herds-and-projects/text.xml
index e030150..39813c8 100644
--- a/general-concepts/herds-and-projects/text.xml
+++ b/general-concepts/herds-and-projects/text.xml
@@ -1,10 +1,133 @@
 
 
 
-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:Metastructure;>
+Gentoo Metastructure Project oversees the developments
+regarding the metastructure. There are other projects such as the
+https://wiki.gentoo.org/wiki/Project:Bug-wranglers;>
+Bug Wranglers which works on assigning bugs reported on Gentoo
+Bugzilla to the responsible developers/projects, or, the
+https://wiki.gentoo.org/wiki/Project:Devmanual;>
+Devmanual which focuses on maintaining this document. Many
+others are responsible for maintaining packages in the tree: the
+https://wiki.gentoo.org/wiki/Project:Base;>
+Base-System focuses on compilers, toolchains and various other
+system software; the
+https://wiki.gentoo.org/wiki/Project:Portage;>
+Portage Development Project specializes in the development of
+sys-apps/portage; the
+https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers;>
+Proxy Maintainers allows keen users to assume responsibility for
+various packages in the official tree under the guidance of Gentoo
+developers. 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.
+
+
+
+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. For example,
+https://wiki.gentoo.org/wiki/Project:ComRel;>
+Community Relations project mainly concerns itself with
+inter-developer and user-developer relationships as well as upholding
+the Gentoo Code of Conduct.
+https://wiki.gentoo.org/wiki/Project:Recruiters;>
+Recruiters project, on the other hand, is tasked with
+orchestrating the process of recruiting developers for Gentoo. Both
+projects tackle different problems, yet, at the same time work towards
+the common goal of improving and maintaining good relations in the
+community. As such, both of these are subprojects of
+https://wiki.gentoo.org/wiki/Project:ComRes;>
+Community Resources project.
+
+
+
+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 email address devman...@gentoo.org.
+
+
+
+
+
+
+
+
+
+Herds
+
+
+
+Herds have been declared obsolete as per the Gentoo 

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

2016-04-03 Thread 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 #549490 obsolete.

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 
---
 ebuild-writing/misc-files/metadata/text.xml | 408 
 1 file changed, 227 insertions(+), 181 deletions(-)

diff --git a/ebuild-writing/misc-files/metadata/text.xml 
b/ebuild-writing/misc-files/metadata/text.xml
index 2324f53..9d0dc19 100644
--- a/ebuild-writing/misc-files/metadata/text.xml
+++ b/ebuild-writing/misc-files/metadata/text.xml
@@ -10,20 +10,13 @@ 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
 
 
 
-A metadata.xml file can contain a number of tags:
+A metadata file follows the syntax defined in
+https://www.gentoo.org/dtd/metadata.dtd;>
+metadata.dtd and can contain a number of tags:
 
 
 
@@ -39,13 +32,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 +52,21 @@ 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. A package may contain zero or more
+maintainer tags. 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. Unless specified otherwise, the
+maintainer who is listed in the metadata first shall be the
+assignee for the bugs for that package as per
+https://wiki.gentoo.org/wiki/GLEP:67#Bug_assignment;>
+GLEP 67.
   
 
 
@@ -108,7 +93,9 @@ A metadata.xml file can contain a number of 
tags:
   longdescription
   
 This tag contains a description of the package. This is to augment the 
-DESCRIPTION field in the ebuilds themselves. This tag has two optional
+DESCRIPTION field in the ebuilds themselves. If a long description
+in any language is provided, an English long description must be
+present. This tag has two optional
 subtags: pkg and cat.
   
 
@@ -207,8 +194,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 +221,7 @@ optional:
 
   restrict
   
-herd, maintainer, 
+maintainer,
 longdescription, flag
   
   
@@ -244,12 +230,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;".
   
 
 
@@ -286,208 +267,273 @@ optional:
 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 

[gentoo-dev] [PATCH v1 2/3] ebuild-maintenance: s/herd/project/ per GLEP 67 #572144

2016-04-03 Thread Göktürk Yüksek
Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=572144
Signed-off-by: Göktürk Yüksek 
---
 ebuild-maintenance/text.xml | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml
index 5b2abee..a299bf2 100644
--- a/ebuild-maintenance/text.xml
+++ b/ebuild-maintenance/text.xml
@@ -281,7 +281,18 @@ which is often more convenient.
 
 Touching other developers ebuilds
 
-Usually you don't just change other developers ebuilds without permission 
unless you know that developer does not mind or if you are part of the herd 
involved in maintenance (this information can typically be found in 
metadata.xml). Start with filing a bug or trying to catch them on IRC or via 
email. Sometimes you cannot reach them, or there is no response to your bug. 
It's a good idea to consult other developers on how to handle the situation, 
especially if it's a critical issue that needs to be handled ASAP. Otherwise a 
soft limit of 2 to 4 weeks depending on the severity of the bug is an 
acceptable time frame before you go ahead and fix it yourself. 
+
+Usually you don't just change other developers ebuilds without
+permission unless you know that developer does not mind or if you are
+part of the project involved in maintenance (this information can
+typically be found in metadata.xml). Start with filing a bug or trying
+to catch them on IRC or via email. Sometimes you cannot reach them, or
+there is no response to your bug. It's a good idea to consult other
+developers on how to handle the situation, especially if it's a
+critical issue that needs to be handled ASAP. Otherwise a soft limit
+of 2 to 4 weeks depending on the severity of the bug is an acceptable
+time frame before you go ahead and fix it yourself.
+
  Common sense dictates to us that toolchain/base-system/core 
packages and eclasses or anything else which is delicate (e.g. glibc) or widely 
used (e.g. gtk+) should usually be left to those maintainers. If in doubt, 
don't touch it.
 
 
-- 
2.7.3




[gentoo-dev] [PATCH v1 0/3] devmanual: update the docs per GLEP 67

2016-04-03 Thread Göktürk Yüksek
Hi,

This is the first iteration of the patch series for updating devmanual
per GLEP 67. It replaces any reference to herds, includes a major
rewrite of the section that explains the metadata.xml file, and talks
about how projects are created and managed through the wiki.

The section about herds is currently preserved but deprecated. It may
be useful to keep it around for a while before removing it.

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

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

Göktürk Yüksek (3):
  general-concepts/herds-and-projects: update per GLEP 67 #572144
#549490
  ebuild-maintenance: s/herd/project/ per GLEP 67 #572144
  ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67
#572144

 ebuild-maintenance/text.xml  |  13 +-
 ebuild-writing/misc-files/metadata/text.xml  | 408 +++
 general-concepts/herds-and-projects/text.xml | 129 -
 3 files changed, 367 insertions(+), 183 deletions(-)

-- 
2.7.3




Re: [gentoo-dev] CVS headers in ebuilds

2016-04-03 Thread Kent Fredric
On 4 April 2016 at 14:43, Robin H. Johnson  wrote:
> We'd have to find all of those files and explicitly create .gitattribute
> files, per directory, for them.


I was under the impression that a .gitattribute file in the root
directory sufficed?

( I maybe have misinterpreted what you said, but the writing implied
">1 .gitattribute files proliferated into the tree" )

I'd personally think */*/*.ebuild would be a satisfactory start, and
the rest could be turned on in an as-deemed-necessary basis.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL



Re: [gentoo-dev] CVS headers in ebuilds

2016-04-03 Thread Robin H. Johnson
On Mon, Apr 04, 2016 at 09:03:59AM +1200, Kent Fredric wrote:
> On 4 April 2016 at 08:57, Ulrich Mueller  wrote:
> > Does anyone still use the CVS $Id$ keywords that are in all ebuilds'
> > headers, or are they being expanded anywhere? Or is there any other
> > reason why they should be kept?
> Last time this came up, a sole example case was mentioned, but it
> might have been buried.
> https://bugs.gentoo.org/show_bug.cgi?id=557386
Infra left the $Id$ stubs in place for this use case, but did not turn
on global expansion due to the related issue mentioned in the bug:
CVS allows easy individual file control of disabling keyword expansion
(and setting a file as binary which also implicitly disables keyword
expansion).
We'd have to find all of those files and explicitly create .gitattribute
files, per directory, for them.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85



[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-04-03 23:59 UTC

2016-04-03 Thread Robin H. Johnson
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2016-04-03 23:59 UTC.

Removals:
app-admin/usermin20160402-12:30 pacho  22d71b0
app-benchmarks/expedite  20160402-04:16 vapier 7cd2b6c
dev-games/etrophy20160402-04:24 vapier 16add2f
dev-libs/clearsilver 20160401-03:18 bman   904ee29
dev-libs/ecore   20160402-04:16 vapier 7cd2b6c
dev-libs/e_dbus  20160402-04:24 vapier 16add2f
dev-libs/eet 20160402-04:16 vapier 7cd2b6c
dev-libs/eeze20160402-04:16 vapier 7cd2b6c
dev-libs/efreet  20160402-04:16 vapier 7cd2b6c
dev-libs/eina20160402-04:16 vapier 7cd2b6c
dev-libs/eio 20160402-04:16 vapier 7cd2b6c
dev-libs/embryo  20160402-04:16 vapier 7cd2b6c
dev-ruby/bouncy-castle-java  20160401-03:21 bman   6522f1d
dev-ruby/jruby-openssl   20160401-03:21 bman   a229e2b
media-libs/edje  20160402-04:16 vapier 7cd2b6c
media-libs/emotion   20160402-04:16 vapier 7cd2b6c
media-libs/ethumb20160402-04:16 vapier 7cd2b6c
media-libs/evas  20160402-04:16 vapier 7cd2b6c
media-sound/xmp  20160401-03:02 bman   0fcb1a6
net-mail/perdition   20160401-03:04 bman   f4eb7ab
sci-biology/readseq  20160403-21:40 chewi  c07656a
www-apps/dragonflycms20160401-02:59 bman   126a7d8
www-apps/horde   20160401-03:14 bman   0360b9c
www-apps/horde-chora 20160401-03:14 bman   9f35161
www-apps/horde-dimp  20160401-03:14 bman   a1efee3
www-apps/horde-gollem20160401-03:13 bman   303f4e9
www-apps/horde-hermes20160401-03:13 bman   7aa58d8
www-apps/horde-imp   20160401-03:13 bman   e34712c
www-apps/horde-ingo  20160401-03:13 bman   dee3c6a
www-apps/horde-jeta  20160401-03:13 bman   fbbb59f
www-apps/horde-kronolith 20160401-03:12 bman   89006a2
www-apps/horde-mimp  20160401-03:12 bman   5cf7bc2
www-apps/horde-mnemo 20160401-03:11 bman   f6e2fe3
www-apps/horde-nag   20160401-03:11 bman   046b940
www-apps/horde-passwd20160401-03:11 bman   3600bf1
www-apps/horde-pear  20160401-03:10 bman   b4e275b
www-apps/horde-turba 20160401-03:10 bman   9c9d1dd
www-apps/mantisbt20160401-03:35 bman   dd6d753
x11-misc/qt5ct   20160401-16:09 kensington 4a0dda3
x11-plugins/echievements 20160402-04:24 vapier 16add2f

Additions:
app-vim/merginal 20160402-04:18 radhermit  fbde40c
dev-haskell/disk-free-space  20160403-21:15 slyfox 6aa7116
dev-haskell/magic20160403-21:16 slyfox 7a0697d
dev-haskell/mountpoints  20160403-21:15 slyfox 87f4325
dev-perl/constant-defer  20160330-22:36 dilfridge  548fa5d
dev-perl/Data-Float  20160401-01:34 dilfridge  dc8af75
dev-perl/ExtUtils-CppGuess   20160331-00:15 dilfridge  5398c10
dev-perl/ExtUtils-Typemaps-Default   20160331-01:10 dilfridge  54494aa
dev-perl/Growl-GNTP  20160331-13:07 dilfridge  0ed19fa
dev-perl/IO-Socket-PortState 20160402-03:59 dilfridge  f24de7f
dev-perl/Math-BigInt-Lite20160401-13:11 dilfridge  c2a5f67
dev-perl/Math-Factor-XS  20160401-00:32 dilfridge  df50325
dev-perl/Math-Libm   20160330-23:04 dilfridge  b5f7948
dev-perl/Math-NumSeq 20160401-01:37 dilfridge  0fa1b46
dev-perl/Math-PlanePath  20160330-23:05 dilfridge  bbd68fa
dev-perl/Math-Prime-XS   20160401-13:12 dilfridge  288851f
dev-perl/Module-Build-WithXSpp   20160330-23:00 dilfridge  b7aa60e
dev-perl/Net-Bonjour 20160330-22:39 dilfridge  8aa4082
dev-perl/Number-Fraction 20160401-00:50 dilfridge  65c4381
dev-perl/Pod-Markdown20160402-01:08 dilfridge  48efe09
dev-perl/Pod-Simple-LaTeX20160402-01:18 dilfridge  68c672d
dev-perl/Wx-GLCanvas 20160330-22:34 dilfridge  e490069
dev-perl/XML-SAX-ExpatXS 20160331-13:11 dilfridge  60a1238
media-gfx/slic3r 20160401-18:39 dilfridge  345fdc3
sci-geosciences/opencpn-plugin-iacfleet

Re: [gentoo-dev] CVS headers in ebuilds

2016-04-03 Thread Mike Gilbert
On Sun, Apr 3, 2016 at 4:57 PM, Ulrich Mueller  wrote:
> Does anyone still use the CVS $Id$ keywords that are in all ebuilds'
> headers, or are they being expanded anywhere? Or is there any other
> reason why they should be kept?
>
> In fact, the council had already voted to drop them in its 20141014
> meeting:
>
>Can we drop CVS headers post-migration?
>Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge,
>radhermit, rich0, williamh

Please get a fix for repoman lined up before dropping the line from ebuilds.

floppym@naomi systemd % head -n 4 systemd-.ebuild
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

EAPI=6
floppym@naomi systemd % repoman full

RepoMan scours the neighborhood...
 ebuild.badheader  1
  sys-apps/systemd/systemd-.ebuild: Malformed Id header on line: 3



Re: [gentoo-dev] CVS headers in ebuilds

2016-04-03 Thread Rich Freeman
On Sun, Apr 3, 2016 at 5:57 PM, William Hubbs  wrote:
> On Mon, Apr 04, 2016 at 09:03:59AM +1200, Kent Fredric wrote:
>> On 4 April 2016 at 08:57, Ulrich Mueller  wrote:
>> > Does anyone still use the CVS $Id$ keywords that are in all ebuilds'
>> > headers, or are they being expanded anywhere? Or is there any other
>> > reason why they should be kept?
>>
>>
>> Last time this came up, a sole example case was mentioned, but it
>> might have been buried.
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=557386
>
> Tracking this type of value to "track upstream" doesn't seem to make
> much sense, and I think if infra was going to be able to fix it, it
> would have happened by now.
>
> My vote is to nuke it and be done with it.
>

++ - though as was pointed out this is a vote I've already cast before.

-- 
Rich



[gentoo-dev] Last-rites: dev-java/java-config-wrapper

2016-04-03 Thread James Le Cuirot
# James Le Cuirot  (03 Apr 2016)
# Legacy migration package that is no longer needed. See
# bug #549508. Removal in 30 days.
dev-java/java-config-wrapper

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpcejKQSNaW0.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] CVS headers in ebuilds

2016-04-03 Thread Daniel Campbell
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/03/2016 02:57 PM, William Hubbs wrote:
> On Mon, Apr 04, 2016 at 09:03:59AM +1200, Kent Fredric wrote:
>> On 4 April 2016 at 08:57, Ulrich Mueller  wrote:
>>> Does anyone still use the CVS $Id$ keywords that are in all
>>> ebuilds' headers, or are they being expanded anywhere? Or is
>>> there any other reason why they should be kept?
>> 
>> 
>> Last time this came up, a sole example case was mentioned, but
>> it might have been buried.
>> 
>> https://bugs.gentoo.org/show_bug.cgi?id=557386
> 
> Tracking this type of value to "track upstream" doesn't seem to
> make much sense, and I think if infra was going to be able to fix
> it, it would have happened by now.
> 
> My vote is to nuke it and be done with it.
> 
> William
> 
+1

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXAZaPAAoJEAEkDpRQOeFwnP0P/Al+A36ls1DMQjEPu5U11vYn
L9aQPtckfeztfBYq4EB94Xazrno+yZI9kPg+vhUXA577H7h+OxM06wGd+DH4Q8ZJ
tChD+HrJleKZVV4lcT0e11FRKjzMm4ImKXXcEXFoy8asV76nT+U/Qd2cc+I10EnF
rgapKsIPpzUjOmmESmEX2ZxMcT5sDbUY2/4qE6veaS9HJbkjyoUChfv13SwiFydf
5jB2LQmru+A8Eq9u1ju21dQGTmkhLQCGcSBTmPvscpzrDmmqofpCeWo2rrn8Jz+l
4uWOcsBmnWOnJ6GzlZ+oY7iQ/2p+5Suzom61egKe2moNQyP2Fxgj58KhRZPRYvZ3
GJrkN/CGJOpc+usQVNk0ggSaewR8PRVBITT7LeRxyz/PukNaH6leP75+TtiBSnIJ
6UDKsRh/aMaZixKq8hcLUlhITaVQOI/zbYZmXGWcbxFQ8348kFGCdXXDFJf8g3CA
Bq1Z50fBaCDDEQ/3dVV479nuT3su/XCoI2VL3E5BwWVhra5nFh56jf3uSZ9ihGgd
IQFNWRIZ7ZEep2rciSl8ohFvEFgyP9lc6uod6Iukef3QPDPWK0YIVSyBgQGKzju/
qZqnHXUYv6vBvJxKtIVWNFWUzEnPLH6WrW+ec4m+bhCekHnJOpLxMLhCn0TySVtD
OQNW+DngQ8gI3q8pYngk
=GkAE
-END PGP SIGNATURE-



Re: [gentoo-dev] News item: upgrading to Plasma 5

2016-04-03 Thread Richard Yao
On Mon, Apr 04, 2016 at 03:34:07AM +1000, Michael Palimaka wrote:
> Hi,
> 
> KDE team intends to stabilise Plasma 5 shortly, so please review the
> accompanying news items.
> 
> Regards,
> 
> Michael
> 
> Title: KDE Plasma 5 Upgrade
> Author: Michael Palimaka 
> Content-Type: text/plain
> Posted: 2016-04-02
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: kde-base/plasma-workspace:4
> 
> KDE Workspaces 4.11 has reached end of life and is no longer supported
> by upstream. It is therefore recommended for all users to upgrade to
> KDE Plasma 5.

Did you mean 4.14? 4.11 should have been EOL a long time ago.

> A detailed upgrade guide is available[1], but in most cases it enough to
> switch to the new desktop/plasma profile, update @world, and
> emerge kde-plasma/plasma-meta:
> 
> # eselect profile list
> # eselect profile set 
> # emerge --ask --changed-use --newrepo --deep world
> # emerge --ask --verbose kde-plasma/plasma-meta
> 
> If you normally use KDM to launch Plasma, note that it is no longer
> supported.
> Upstream recommends x11-misc/sddm instead which is pulled in by
> plasma-meta by
> default. To switch, edit /etc/conf.d/xdm and update DISPLAYMANAGER.
> 
> Due to an an evolution of KDE upstream's release process[2], the traditional
> monolithic KDE 4 release is now split into three distinct components. This
> means that KDE Applications are now separate from the Plasma desktop and
> older KDE 4-based applications will continue to function as normal
> inside Plasma 5.
> 
> KDE Workspaces 4.11 will remain in the tree for a reasonable time, but
> be warned that it is unmaintained and may cause conflicts with
> newer versions of KDE Applications.
> 
> [1] https://wiki.gentoo.org/wiki/KDE/Plasma_5_upgrade
> [2] https://dot.kde.org/2013/09/04/kde-release-structure-evolves
> 
> 



Re: [gentoo-dev] CVS headers in ebuilds

2016-04-03 Thread William Hubbs
On Mon, Apr 04, 2016 at 09:03:59AM +1200, Kent Fredric wrote:
> On 4 April 2016 at 08:57, Ulrich Mueller  wrote:
> > Does anyone still use the CVS $Id$ keywords that are in all ebuilds'
> > headers, or are they being expanded anywhere? Or is there any other
> > reason why they should be kept?
> 
> 
> Last time this came up, a sole example case was mentioned, but it
> might have been buried.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=557386

Tracking this type of value to "track upstream" doesn't seem to make
much sense, and I think if infra was going to be able to fix it, it
would have happened by now.

My vote is to nuke it and be done with it.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] CVS headers in ebuilds

2016-04-03 Thread Kent Fredric
On 4 April 2016 at 08:57, Ulrich Mueller  wrote:
> Does anyone still use the CVS $Id$ keywords that are in all ebuilds'
> headers, or are they being expanded anywhere? Or is there any other
> reason why they should be kept?


Last time this came up, a sole example case was mentioned, but it
might have been buried.

https://bugs.gentoo.org/show_bug.cgi?id=557386

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL



[gentoo-dev] CVS headers in ebuilds

2016-04-03 Thread Ulrich Mueller
Does anyone still use the CVS $Id$ keywords that are in all ebuilds'
headers, or are they being expanded anywhere? Or is there any other
reason why they should be kept?

In fact, the council had already voted to drop them in its 20141014
meeting:

   Can we drop CVS headers post-migration?
   Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge,
   radhermit, rich0, williamh 

Ulrich


pgpgE2OMmRbpc.pgp
Description: PGP signature


[gentoo-dev] Re: News item: upgrading to Plasma 5

2016-04-03 Thread Michael Palimaka
On 04/04/16 05:06, Rich Freeman wrote:
> On Sun, Apr 3, 2016 at 1:34 PM, Michael Palimaka  
> wrote:
>>
>> If you normally use KDM to launch Plasma, note that it is no longer
>> supported.
>> Upstream recommends x11-misc/sddm instead which is pulled in by
>> plasma-meta by
>> default. To switch, edit /etc/conf.d/xdm and update DISPLAYMANAGER.
>>
> 
> Didn't we previously recommend using lightdm?  I'm sure migrating is
> trivial but perhaps some kind of note about this might be useful?  I
> suspect that the instructions for migrating from lightdm->sddm are the
> same as kdm->sddm.
> 

The default in KDE 4 was KDM, with lightdm and sddm also supported.

We included information about migrating away from KDM because it's no
longer developed or supported and in some cases fails to work with
Plasma 5 at all.

lightdm continues to work fine with Plasma 5 so there's no special need
to replace it.



[gentoo-dev] Re: News item: upgrading to Plasma 5

2016-04-03 Thread Michael Palimaka
On 04/04/16 04:48, Mike Gilbert wrote:
> On Sun, Apr 3, 2016 at 1:34 PM, Michael Palimaka  
> wrote:
>> Hi,
>>
>> KDE team intends to stabilise Plasma 5 shortly, so please review the
>> accompanying news items.
> 
> Very exciting, nice work!
> 
>> If you normally use KDM to launch Plasma, note that it is no longer
>> supported.
>> Upstream recommends x11-misc/sddm instead which is pulled in by
>> plasma-meta by
>> default. To switch, edit /etc/conf.d/xdm and update DISPLAYMANAGER.
> 
> That only works for OpenRC users. systemd users should run the
> following after installing sddm to adjust the display-manager.service
> symlink:
> 
> systemctl reenable sddm.service
> 
> 

I was hoping someone would chime in with the systemd command. :)

I have updated that paragraph to read:

If you normally use KDM to launch Plasma, note that it is no longer
supported.
Upstream recommends x11-misc/sddm instead which is pulled in by
plasma-meta by
default. OpenRC users should edit /etc/conf.d/xdm and update DISPLAYMANAGER.
Systemd users should run: systemctl reenable sddm.service



Re: [gentoo-dev] News item: upgrading to Plasma 5

2016-04-03 Thread Rich Freeman
On Sun, Apr 3, 2016 at 1:34 PM, Michael Palimaka  wrote:
>
> If you normally use KDM to launch Plasma, note that it is no longer
> supported.
> Upstream recommends x11-misc/sddm instead which is pulled in by
> plasma-meta by
> default. To switch, edit /etc/conf.d/xdm and update DISPLAYMANAGER.
>

Didn't we previously recommend using lightdm?  I'm sure migrating is
trivial but perhaps some kind of note about this might be useful?  I
suspect that the instructions for migrating from lightdm->sddm are the
same as kdm->sddm.

-- 
Rich



[gentoo-dev] Re: News item: upgrading to Plasma 5

2016-04-03 Thread Michael Palimaka
On 04/04/16 04:34, Ulrich Mueller wrote:
>> On Mon, 4 Apr 2016, Michael Palimaka wrote:
> 
>> News-Item-Format: 1.0
>> Display-If-Installed: kde-base/plasma-workspace:4
> 
> Slot dependencies in Display-If-Installed are not allowed in news item
> format 1.0. You should use format 2.0 (which allows EAPI 5 dependency
> specifications) if you need them.
> 
> Ulrich
> 

Thanks, we don't actually need the slot dependency so I just dropped it.



Re: [gentoo-dev] News item: upgrading to Plasma 5

2016-04-03 Thread Mike Gilbert
On Sun, Apr 3, 2016 at 1:34 PM, Michael Palimaka  wrote:
> Hi,
>
> KDE team intends to stabilise Plasma 5 shortly, so please review the
> accompanying news items.

Very exciting, nice work!

> If you normally use KDM to launch Plasma, note that it is no longer
> supported.
> Upstream recommends x11-misc/sddm instead which is pulled in by
> plasma-meta by
> default. To switch, edit /etc/conf.d/xdm and update DISPLAYMANAGER.

That only works for OpenRC users. systemd users should run the
following after installing sddm to adjust the display-manager.service
symlink:

systemctl reenable sddm.service



Re: [gentoo-dev] News item: upgrading to Plasma 5

2016-04-03 Thread Ulrich Mueller
> On Mon, 4 Apr 2016, Michael Palimaka wrote:

> News-Item-Format: 1.0
> Display-If-Installed: kde-base/plasma-workspace:4

Slot dependencies in Display-If-Installed are not allowed in news item
format 1.0. You should use format 2.0 (which allows EAPI 5 dependency
specifications) if you need them.

Ulrich


pgpOnKj2xJqtM.pgp
Description: PGP signature


[gentoo-dev] News item: upgrading to Plasma 5

2016-04-03 Thread Michael Palimaka
Hi,

KDE team intends to stabilise Plasma 5 shortly, so please review the
accompanying news items.

Regards,

Michael

Title: KDE Plasma 5 Upgrade
Author: Michael Palimaka 
Content-Type: text/plain
Posted: 2016-04-02
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: kde-base/plasma-workspace:4

KDE Workspaces 4.11 has reached end of life and is no longer supported
by upstream. It is therefore recommended for all users to upgrade to
KDE Plasma 5.

A detailed upgrade guide is available[1], but in most cases it enough to
switch to the new desktop/plasma profile, update @world, and
emerge kde-plasma/plasma-meta:

# eselect profile list
# eselect profile set 
# emerge --ask --changed-use --newrepo --deep world
# emerge --ask --verbose kde-plasma/plasma-meta

If you normally use KDM to launch Plasma, note that it is no longer
supported.
Upstream recommends x11-misc/sddm instead which is pulled in by
plasma-meta by
default. To switch, edit /etc/conf.d/xdm and update DISPLAYMANAGER.

Due to an an evolution of KDE upstream's release process[2], the traditional
monolithic KDE 4 release is now split into three distinct components. This
means that KDE Applications are now separate from the Plasma desktop and
older KDE 4-based applications will continue to function as normal
inside Plasma 5.

KDE Workspaces 4.11 will remain in the tree for a reasonable time, but
be warned that it is unmaintained and may cause conflicts with
newer versions of KDE Applications.

[1] https://wiki.gentoo.org/wiki/KDE/Plasma_5_upgrade
[2] https://dot.kde.org/2013/09/04/kde-release-structure-evolves