[gentoo-dev] Re: News item: upgrading to Plasma 5
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)
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
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
-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
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
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
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
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
On 4 April 2016 at 14:43, Robin H. Johnsonwrote: > 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
On Mon, Apr 04, 2016 at 09:03:59AM +1200, Kent Fredric wrote: > On 4 April 2016 at 08:57, Ulrich Muellerwrote: > > 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
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
On Sun, Apr 3, 2016 at 4:57 PM, Ulrich Muellerwrote: > 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
On Sun, Apr 3, 2016 at 5:57 PM, William Hubbswrote: > 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
# 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
-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 Muellerwrote: >>> 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
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
On Mon, Apr 04, 2016 at 09:03:59AM +1200, Kent Fredric wrote: > On 4 April 2016 at 08:57, Ulrich Muellerwrote: > > 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
On 4 April 2016 at 08:57, Ulrich Muellerwrote: > 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
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
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
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
On Sun, Apr 3, 2016 at 1:34 PM, Michael Palimakawrote: > > 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
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
On Sun, Apr 3, 2016 at 1:34 PM, Michael Palimakawrote: > 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
> 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
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 PalimakaContent-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