Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
On 03/22/2018 05:52 PM, Joakim Tjernlund wrote: > On Mon, 2018-03-19 at 15:59 -0700, Zac Medico wrote: >> On 03/15/2018 12:22 PM, Michał Górny wrote: >>> Hi, >>> >>> Here are three of four INSTALL_MASK updates I've sent long time ago >>> which were not really reviewed. The fourth patch added support >>> for repo-defined install-mask.conf and I'll do that separately. >>> >>> Those patches focus on smaller changes. What they change, in order: >>> >>> 1. Removes explicit file removal code for FEATURES=no*. Instead, those >>>values are converted into additional INSTALL_MASK entries >>>and handled directly via INSTALL_MASK processing. >>> >>> 2. Rework INSTALL_MASK to filter files while installing instead of >>>pre-stripping them. In other words, before: INSTALL_MASK removes >>>files from ${D} before merge. After: ${D} contains all the files, >>>Portage just skip INSTALL_MASK-ed stuff, verbosely indicating that. >>> >>> 3. Adds support for exclusions in INSTALL_MASK. In other words, you >>>can do stuff like: >>> >>> INSTALL_MASK="/usr/share/locale -/usr/share/locale/en_US" >>> >>> I have been using this via user patches since the last submission. >>> Guessing by 'git log', this means almost 2 years now. >>> >>> -- >>> Best regards, >>> Michał Górny >>> >>> Michał Górny (3): >>> portage.package.ebuild.config: Move FEATURES=no* handling there >>> portage.dbapi.vartree: Move INSTALL_MASK handling into merging >>> portage.dbapi.vartree: Support exclusions in INSTALL_MASK >>> >>> bin/misc-functions.sh| 30 -- >>> pym/portage/dbapi/vartree.py | 104 >>> ++- >>> pym/portage/package/ebuild/config.py | 11 >>> 3 files changed, 77 insertions(+), 68 deletions(-) >>> >> >> As mentioned in #gentoo-portage today, the rationale for including the >> INSTALL_MASKed files in CONTENTS is to that we can detect collisions >> that would have occurred had people not been using INSTALL_MASK. >> >> Since people can use INSTALL_MASK to intentionally prevent collisions, >> in cases where COLLISION_IGNORE is not appropriate (this is common >> practice at my workplace), we'll need a new FEATURES setting to trigger >> the new behavior where INSTALL_MASKed files still trigger file collisions. > > Are we going to see this in Portage soon? And PKG_INSTALL_MASK too ? Yes, I'll clean up the patches an resubmit them. Bug filed: https://bugs.gentoo.org/651214 -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 03/22/2018 04:17 PM, James Le Cuirot wrote: > On Thu, 22 Mar 2018 20:03:46 +0100 > Michał Górnywrote: > >> After 2+ years of repeating disagreements with Portage maintainer(s) >> I have finally decided to fork Portage. My little fork uses technical >> name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), >> and aims to focus on cleaning up code and adding useful features with >> less concern for infinite bug-by-bug compatibility. > I hope you will continue with our efforts to drive regular Portage > forwards too. It's been a long road but also very productive. > > I notice that your fork cannot be installed at the same time as regular > Portage. I think this will really hinder any interest in it. As > Gentoo developers, we obviously have to make sure things work with the > official package manager and that goes for you too. Would it be > possible for them to coexist? I'm not saying I'll try it though, just > making a suggestion. :) > Seems to also be blocked by other management tools such as perl-cleaner and haskell-updater. I'd love to take it for a spin if you have any suggestions on how to navigate the blocks. https://paste.pound-python.org/show/VxWWAGW9PpPCS3L4Q6Z3/ Herb Miller Jr.
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
On Mon, 2018-03-19 at 15:59 -0700, Zac Medico wrote: > On 03/15/2018 12:22 PM, Michał Górny wrote: > > Hi, > > > > Here are three of four INSTALL_MASK updates I've sent long time ago > > which were not really reviewed. The fourth patch added support > > for repo-defined install-mask.conf and I'll do that separately. > > > > Those patches focus on smaller changes. What they change, in order: > > > > 1. Removes explicit file removal code for FEATURES=no*. Instead, those > >values are converted into additional INSTALL_MASK entries > >and handled directly via INSTALL_MASK processing. > > > > 2. Rework INSTALL_MASK to filter files while installing instead of > >pre-stripping them. In other words, before: INSTALL_MASK removes > >files from ${D} before merge. After: ${D} contains all the files, > >Portage just skip INSTALL_MASK-ed stuff, verbosely indicating that. > > > > 3. Adds support for exclusions in INSTALL_MASK. In other words, you > >can do stuff like: > > > > INSTALL_MASK="/usr/share/locale -/usr/share/locale/en_US" > > > > I have been using this via user patches since the last submission. > > Guessing by 'git log', this means almost 2 years now. > > > > -- > > Best regards, > > Michał Górny > > > > Michał Górny (3): > > portage.package.ebuild.config: Move FEATURES=no* handling there > > portage.dbapi.vartree: Move INSTALL_MASK handling into merging > > portage.dbapi.vartree: Support exclusions in INSTALL_MASK > > > > bin/misc-functions.sh| 30 -- > > pym/portage/dbapi/vartree.py | 104 > > ++- > > pym/portage/package/ebuild/config.py | 11 > > 3 files changed, 77 insertions(+), 68 deletions(-) > > > > As mentioned in #gentoo-portage today, the rationale for including the > INSTALL_MASKed files in CONTENTS is to that we can detect collisions > that would have occurred had people not been using INSTALL_MASK. > > Since people can use INSTALL_MASK to intentionally prevent collisions, > in cases where COLLISION_IGNORE is not appropriate (this is common > practice at my workplace), we'll need a new FEATURES setting to trigger > the new behavior where INSTALL_MASKed files still trigger file collisions. Are we going to see this in Portage soon? And PKG_INSTALL_MASK too ?
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 03/22/2018 03:52 PM, Geaaru wrote: > Hi, > > a bit out of topic (sorry in advance) but connect to eventually new > portage feature... > > for both portage and your fork I think that could be interesting add an > extension to PMS for define inside profiles or targets masking of > packages of a particular repslository. Currently PMS doesn't permit this > but have this feature could be help users to define our profiles under > overlays. > > Something like this: > > sys-devel/gcc::gentoo > > Currently this is permitted only under /etc/portage but for distro based > of gentoo or others use cases share our profiles directly under overlay > could permit an easy and elegant way to share our customizations. > > Unlucky this break specifications but I think that could be a fine new > feature. > > wdyt? > > My cent. > > G. Bug filed: https://bugs.gentoo.org/651208 -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
Hi, a bit out of topic (sorry in advance) but connect to eventually new portage feature... for both portage and your fork I think that could be interesting add an extension to PMS for define inside profiles or targets masking of packages of a particular repslository. Currently PMS doesn't permit this but have this feature could be help users to define our profiles under overlays. Something like this: sys-devel/gcc::gentoo Currently this is permitted only under /etc/portage but for distro based of gentoo or others use cases share our profiles directly under overlay could permit an easy and elegant way to share our customizations. Unlucky this break specifications but I think that could be a fine new feature. wdyt? My cent. G. On Thu, Mar 22, 2018, 23:06 Michał Górnywrote: > W dniu pią, 23.03.2018 o godzinie 00∶47 +0300, użytkownik Consus > napisał: > > On 20:03 Thu 22 Mar, Michał Górny wrote: > > > Hello, everyone. > > > > > > After 2+ years of repeating disagreements with Portage maintainer(s) > > > I have finally decided to fork Portage. My little fork uses technical > > > name of 'portage[mgorny]' [1] (to distinguish it from mainline > Portage), > > > and aims to focus on cleaning up code and adding useful features with > > > less concern for infinite bug-by-bug compatibility. > > > > > > Detailed rationale in README [2]. > > > > Do you have any roadmap? > > > > No. Just a few general ideas. It's Portage, so I don't expect anything > major to be able to happen. > > -- > Best regards, > Michał Górny > > >
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
W dniu pią, 23.03.2018 o godzinie 00∶47 +0300, użytkownik Consus napisał: > On 20:03 Thu 22 Mar, Michał Górny wrote: > > Hello, everyone. > > > > After 2+ years of repeating disagreements with Portage maintainer(s) > > I have finally decided to fork Portage. My little fork uses technical > > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > > and aims to focus on cleaning up code and adding useful features with > > less concern for infinite bug-by-bug compatibility. > > > > Detailed rationale in README [2]. > > Do you have any roadmap? > No. Just a few general ideas. It's Portage, so I don't expect anything major to be able to happen. -- Best regards, Michał Górny
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 20:03 Thu 22 Mar, Michał Górny wrote: > Hello, everyone. > > After 2+ years of repeating disagreements with Portage maintainer(s) > I have finally decided to fork Portage. My little fork uses technical > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > and aims to focus on cleaning up code and adding useful features with > less concern for infinite bug-by-bug compatibility. > > Detailed rationale in README [2]. Do you have any roadmap?
Re: [gentoo-dev] [PATCH 2/2] java-utils-2.eclass: Drop sys-apps/portage build dependency
On 03/22/2018 02:22 PM, James Le Cuirot wrote: > It originates from 2006 and should arguably have never been added. > --- > eclass/java-utils-2.eclass | 12 ++-- > 1 file changed, 2 insertions(+), 10 deletions(-) These dependencies seem were only to pull in a version of portage supporting phase hooks, since the java eclasses used those as a workaround for lack of environment loading support in portage back then. None of the eclasses are using pre_/post_ phase hooks these days. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH 1/2] java-ant-2.eclass: Drop sys-apps/portage build dependency
This comes via java-utils-2.eclass. It originates from 2006 and should arguably have never been added. --- eclass/java-ant-2.eclass | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/eclass/java-ant-2.eclass b/eclass/java-ant-2.eclass index 8da5971844a0..1fd4feb39134 100644 --- a/eclass/java-ant-2.eclass +++ b/eclass/java-ant-2.eclass @@ -56,12 +56,10 @@ if [[ $? != 0 ]]; then die "java-pkg_ant-tasks-depend() failed" fi -# We need some tools from javatoolkit. We also need portage 2.1 for phase hooks -# and ant dependencies constructed above. Python is there for -# java-ant_remove-taskdefs +# We need some tools from javatoolkit. We also need ant dependencies +# constructed above. JAVA_ANT_E_DEPEND="${JAVA_ANT_E_DEPEND} ${ANT_TASKS_DEPEND} - ${JAVA_PKG_PORTAGE_DEP} >=dev-java/javatoolkit-0.3.0-r2" # this eclass must be inherited after java-pkg-2 or java-pkg-opt-2 -- 2.16.1
[gentoo-dev] [PATCH 2/2] java-utils-2.eclass: Drop sys-apps/portage build dependency
It originates from 2006 and should arguably have never been added. --- eclass/java-utils-2.eclass | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass index 25e35c33dd21..967050925245 100644 --- a/eclass/java-utils-2.eclass +++ b/eclass/java-utils-2.eclass @@ -1,4 +1,4 @@ -# Copyright 2004-2017 Gentoo Foundation +# Copyright 2004-2018 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # @ECLASS: java-utils-2.eclass @@ -25,21 +25,13 @@ export WANT_JAVA_CONFIG="2" # Prefix variables are only available for EAPI>=3 has "${EAPI:-0}" 0 1 2 && ED="${D}" EPREFIX= EROOT="${ROOT}" -# @VARIABLE: JAVA_PKG_PORTAGE_DEP -# @INTERNAL -# @DESCRIPTION: -# The version of portage we need to function properly. Previously it was -# portage with phase hooks support but now we use a version with proper env -# saving. For EAPI 2 we have new enough stuff so let's have cleaner deps. -has "${EAPI}" 0 1 && JAVA_PKG_PORTAGE_DEP=">=sys-apps/portage-2.1.2.7" - # @VARIABLE: JAVA_PKG_E_DEPEND # @INTERNAL # @DESCRIPTION: # This is a convience variable to be used from the other java eclasses. This is # the version of java-config we want to use. Usually the latest stable version # so that ebuilds can use new features without depending on specific versions. -JAVA_PKG_E_DEPEND=">=dev-java/java-config-2.2.0-r3 ${JAVA_PKG_PORTAGE_DEP}" +JAVA_PKG_E_DEPEND=">=dev-java/java-config-2.2.0-r3" has source ${JAVA_PKG_IUSE} && JAVA_PKG_E_DEPEND="${JAVA_PKG_E_DEPEND} source? ( app-arch/zip )" # @ECLASS-VARIABLE: JAVA_PKG_WANT_BOOTCLASSPATH -- 2.16.1
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 03/22/2018 01:17 PM, James Le Cuirot wrote: > On Thu, 22 Mar 2018 20:03:46 +0100 > Michał Górnywrote: > >> After 2+ years of repeating disagreements with Portage maintainer(s) >> I have finally decided to fork Portage. My little fork uses technical >> name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), >> and aims to focus on cleaning up code and adding useful features with >> less concern for infinite bug-by-bug compatibility. > > I hope you will continue with our efforts to drive regular Portage > forwards too. It's been a long road but also very productive. > > I notice that your fork cannot be installed at the same time as regular > Portage. I think this will really hinder any interest in it. As > Gentoo developers, we obviously have to make sure things work with the > official package manager and that goes for you too. Would it be > possible for them to coexist? I'm not saying I'll try it though, just > making a suggestion. :) > You can probably use the PATH/PYTHONPATH approach described here as long as support for that has not been eliminated: https://wiki.gentoo.org/wiki/Project:Portage#Testing_Portage -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
W dniu czw, 22.03.2018 o godzinie 20∶17 +, użytkownik James Le Cuirot napisał: > On Thu, 22 Mar 2018 20:03:46 +0100 > Michał Górnywrote: > > > After 2+ years of repeating disagreements with Portage maintainer(s) > > I have finally decided to fork Portage. My little fork uses technical > > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > > and aims to focus on cleaning up code and adding useful features with > > less concern for infinite bug-by-bug compatibility. > > I hope you will continue with our efforts to drive regular Portage > forwards too. It's been a long road but also very productive. > > I notice that your fork cannot be installed at the same time as regular > Portage. I think this will really hinder any interest in it. Making them co-installable would require creating divergent packages and eventually making a huge mess of almost-identical-but-different Python modules. It's not worth the effort, especially that the two projects are not that divergent. > As > Gentoo developers, we obviously have to make sure things work with the > official package manager and that goes for you too. Would it be > possible for them to coexist? I'm not saying I'll try it though, just > making a suggestion. :) As Gentoo developers, we have have to make sure things work with *all* package managers. That's why we have standards and policies. Unlike mainline Portage, portage[mgorny] follows those policies strictly and therefore any ebuild that works with it should also work with mainline Portage. -- Best regards, Michał Górny
Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)
On 03/21/2018 04:30 PM, M. J. Everitt wrote: > On 21/03/18 23:26, M. J. Everitt wrote: >> n 20/03/18 04:49, Manuel Rüger wrote: >>> Hi Zac, >>> >>> alternatively could --exclude be extended to support sets? >>> So users could --exclude @world or @profile. >>> >>> Cheers, >>> Manuel >>> >> The idea is sound enough, but I fear the syntax would be too confusing. >> >> Reading a potential command-line as "emerge > world-file unless --no-replace specified> puts my head into >> a spin! I can see it might be clearer for an unmerge perhaps .. >> >> Unless I'm missing something fundamental ... >> > On a related note, it would be quite handy to enumerate an > "exclude-from" option like rsync/tar(?) to specify a file with the > --exclude options in. There could be some way to append @world to this > option, perhaps? All that --ignore-world does it remove the implicit @world root the dependency graph, so --complete-graph options no longer pull @world and its deep dependencies into the dependency graph. It's still possible to use @world together with --ignore-world, but in this case --ignore-world has no effect because @world has been pulled in explicitly (and pulling @world in implicitly would be redundant in this case). -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On Thu, 22 Mar 2018 20:03:46 +0100 Michał Górnywrote: > After 2+ years of repeating disagreements with Portage maintainer(s) > I have finally decided to fork Portage. My little fork uses technical > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > and aims to focus on cleaning up code and adding useful features with > less concern for infinite bug-by-bug compatibility. I hope you will continue with our efforts to drive regular Portage forwards too. It's been a long road but also very productive. I notice that your fork cannot be installed at the same time as regular Portage. I think this will really hinder any interest in it. As Gentoo developers, we obviously have to make sure things work with the official package manager and that goes for you too. Would it be possible for them to coexist? I'm not saying I'll try it though, just making a suggestion. :) -- James Le Cuirot (chewi) Gentoo Linux Developer pgps9_fhr_B36.pgp Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)
On 03/21/2018 05:59 PM, Manuel Rüger wrote: > On 22.03.2018 01:25, Zac Medico wrote: >> On 03/19/2018 09:49 PM, Manuel Rüger wrote: >>> Hi Zac, >>> >>> alternatively could --exclude be extended to support sets? >>> So users could --exclude @world or @profile. >> >> Your idea doesn't really fit the current meaning of --exclude, since >> --exclude excludes packages from being merged, but still adds installed >> instances to the dependency graph in order to ensure that their >> dependencies remain satisfied. >> > Thanks for providing the clarification, now I have a better > understanding what both approaches do and withdraw my suggestion for > this patch. :-) Ok, glad to clarify. Thinking some more on the implications of your question, it seems like you were thinking that packages matched by the excluded set would somehow be magically eliminated from the dependency graph? That's not how --ignore-world works at all. Things matched by @world, @selected, @system, and their deep dependencies can still be pulled into the dependency graph despite --ignore-world. The only difference with --ignore-world is that @world is no longer an implicit member of the dependency graph, so --complete-graph options will not force @world into the dependency graph, and the packages given as arguments will be the only root(s) of the dependency graph. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
[gentoo-dev] New Portage fork: sys-apps/portage-mgorny
Hello, everyone. After 2+ years of repeating disagreements with Portage maintainer(s) I have finally decided to fork Portage. My little fork uses technical name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), and aims to focus on cleaning up code and adding useful features with less concern for infinite bug-by-bug compatibility. Detailed rationale in README [2]. Before installing - This is a bleeding-edge, strictness-first fork of Portage. It is intended for developers and power users mostly. Things will break. You will eventually be asked to remove files deprecated 5+ years ago. Developer mistakes will harm you (but someone needs to find them and report them!) Dynamic dependencies are off by default (following Council decision from 3.5yr ago). If you haven't rebuilt your system recently, you may need to use '--changed-deps' once. Afterwards, things should work fine unless developers screw up, and then you should report bugs. Only ~arch version at the moment. Installing -- To switch to my fork of Portage, just: emerge -vn sys-apps/portage-mgorny Note that you may need to: emerge --deselect sys-apps/portage app-portage/repoman (repoman is integrated back into Portage) You may also need to upgrade all revdeps of Portage since the newest versions were bumped with updated dependencies. Please note that due to misdesign, Portage will abort upon having to unmerge itself on first install. However, it is a harmless failure and portage[mgorny] will be installed already at the point, so upon restarting it will just finish cleaning up. Merge plan -- I do intend to regularly merge from mainline Portage, and preserve reasonable compatibility (especially in terms of API). I also plan to keep reasonably good commit quality as to make it easier for Portage developers to merge back. However, this is not my primary concern. Releases I plan to make frequent releases. I'm planning to version the releases by sequential values of fourth version component from the last Portage release. For example, since the last Portage release is 2.3.24, I have just released portage-mgorny-2.3.24.1, the next release will be 2.3.24.2, etc. until Portage 2.3.25 is released. The releases are made against *git HEAD* and not respective Portage versions, i.e. 2.3.24.1 is [2.3.24 + changes in mainline + my changes]. The matching versions are mostly meant to make >= deps easier, i.e. you can reasonably assume portage-mgorny-2.3.24* will have all the new APIs of portage-2.3.24. The release notes [3] list any major changes I make. They do not list the respective changes in mainline Portage, sorry. Bugs, features and requests --- I'm open to your feedback, including things that were rejected by mainline Portage team. For best efficiency, please report bugs on GitHub [4] and/or open pull requests [5]. Enjoy! [1]:https://github.com/mgorny/portage [2]:https://github.com/mgorny/portage/blob/master/README [3]:https://github.com/mgorny/portage/releases [4]:https://github.com/mgorny/portage/issues [5]:https://github.com/mgorny/portage/pulls -- Best regards, Michał Górny
Re: [gentoo-dev] Mailing list moderation and community openness
On 03/22/2018 12:38 PM, Rich Freeman wrote: > On Thu, Mar 22, 2018 at 4:30 AM, Alexander Berntsen> wrote: >> On 22/03/18 07:31, Benda Xu wrote: >>> We might be able to require GPG signed email to make a post. >> Almost definitely. >> >> But before bikeshedding that, it would be advisable to find out whether >> it would be a good idea in the first place. Unless you want only >> prospective developers to be able to contribute to the ML (maybe you do >> want that?), it seems like a poor idea to unnecessarily exclude anyone >> who doesn't care (nor want to care) about OpenPGP. > > That, and getting yourself whitelisted by a dev is gong to be a lower > barrier than having to meet one in-person to have a key signed. That > is unless devs just start signing keys for people they've never met > (which honestly doesn't really bother me much as I don't put much > faith in the WoT anyway), in which case it turns into a whitelist that > only comrel can un-whitelist since I don't think you can revoke a > signature. The one issuing the signature can also revoke it (see revsig in --edit-key). That said, I'd rather focus on our own devs having WoT and requiring it to become a developer long before we require it to be part of a mailing list. If anything the technical complexity of verifying it doesn't make much sense to me vs a simple whitelist. > > Plus signing emails is a pain if you don't use an MUA that has this > feature, and the web-based ones which do aren't very good. > -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Mailing list moderation and community openness
On Thu, Mar 22, 2018 at 4:30 AM, Alexander Berntsenwrote: > On 22/03/18 07:31, Benda Xu wrote: >> We might be able to require GPG signed email to make a post. > Almost definitely. > > But before bikeshedding that, it would be advisable to find out whether > it would be a good idea in the first place. Unless you want only > prospective developers to be able to contribute to the ML (maybe you do > want that?), it seems like a poor idea to unnecessarily exclude anyone > who doesn't care (nor want to care) about OpenPGP. That, and getting yourself whitelisted by a dev is gong to be a lower barrier than having to meet one in-person to have a key signed. That is unless devs just start signing keys for people they've never met (which honestly doesn't really bother me much as I don't put much faith in the WoT anyway), in which case it turns into a whitelist that only comrel can un-whitelist since I don't think you can revoke a signature. Plus signing emails is a pain if you don't use an MUA that has this feature, and the web-based ones which do aren't very good. -- Rich
Re: [gentoo-dev] New category: app-metrics
On Tue, Mar 20, 2018 at 6:21 AM, Manuel Rügerwrote: > In addition, the following packages will drop their prometheus- prefix > during the package move: > > * net-analyzer/prometheus-blackbox_exporter > * net-analyzer/prometheus-node_exporter > * net-analyzer/prometheus-redis_exporter > * net-analyzer/prometheus-snmp_exporter > * net-analyzer/prometheus-uwsgi_exporter > * net-analyzer/prometheus-pushgateway > * net-analyzer/prometheus-alertmanager > > With the growing adoption of prometheus I expect more exporters to be > added (I have five more that I want to add in the near future). > > On the face of it, I wouldn't drop the "prometheus-" prefix if app-metrics is to be the home to other tools. Otherwise, other tools like graphite or collectd might want very similar names for the same tools out there. Regards, Dirkjan
Re: [gentoo-dev] Mailing list moderation and community openness
On 22/03/18 07:31, Benda Xu wrote: > We might be able to require GPG signed email to make a post. Almost definitely. But before bikeshedding that, it would be advisable to find out whether it would be a good idea in the first place. Unless you want only prospective developers to be able to contribute to the ML (maybe you do want that?), it seems like a poor idea to unnecessarily exclude anyone who doesn't care (nor want to care) about OpenPGP. -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New category: app-metrics
Hi! On 20-03-2018 06:21:00 +0100, Manuel Rüger wrote: > Hi everyone, > > I'm planning to add a new category app-metrics, which is mainly (at > least for my own use case) going to be used for prometheus[0] and its > exporters providing endpoints for prometheus. It can be used for other > packages whose _main_ purpose is to provide metrics, transform or > consume them. > > * net-analyzer/prometheus > * app-admin/bind_exporter > * app-admin/elasticsearch_exporter > * app-admin/mongodb_exporter > * app-admin/nginx-vts-exporter > * app-admin/prom2json > * dev-util/buildbot-prometheus Does the graphite stack fit in this too, you think? app-admin/diamond app-admin/collectd app-misc/carbon-c-relay dev-python/carbon net-analyzer/graphite-web www-apps/grafana-bin We might have more packages, but this is from the top off my head. Thanks, Fabian > > In addition, the following packages will drop their prometheus- prefix > during the package move: > > * net-analyzer/prometheus-blackbox_exporter > * net-analyzer/prometheus-node_exporter > * net-analyzer/prometheus-redis_exporter > * net-analyzer/prometheus-snmp_exporter > * net-analyzer/prometheus-uwsgi_exporter > * net-analyzer/prometheus-pushgateway > * net-analyzer/prometheus-alertmanager > > With the growing adoption of prometheus I expect more exporters to be > added (I have five more that I want to add in the near future). > > > Thanks, > > Manuel > > [0] https://prometheus.io > > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Mailing list moderation and community openness
Hi Rich, Rich Freemanwrites: > Actually, I think it is more of a technical constraint. It is > basically impossible to blacklist somebody on a mailing list, since > all they need to do is roll up a new email address. > I can think of various arguments for whitelisting or not whitelisting, > but it seems silly to blacklist. Okay, I see your argument. Just a random bikeshedding. We might be able to require GPG signed email to make a post. Then we can blacklist the GPG identity? To think of it further, the web of trust is basically a whitelist. But it has the flexibility to chain the trust from a Gentoo dev by several 'hops'. Benda