Re: [gentoo-dev] Re: Fwd: [Bug 597822] www-apache/mod_perl-2.0.10 dev-perl/Chatbot-Eliza-1.60.0 keyword request

On Sat, 11 Mar 2017 22:25:45 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Alexis Ballier posted on Sat, 11 Mar 2017 20:59:56 +0100 as excerpted: > > > On Sat, 11 Mar 2017 20:45:07 +0100 "Andreas K. Huettel" > > wrote: > >> This keywording bug 597822 is now open

Re: [gentoo-dev] How to deal with package forks?

W dniu 11.03.2017, sob o godzinie 21∶49 -0500, użytkownik Rich Freeman napisał: > On Sat, Mar 11, 2017 at 8:48 PM, Kent Fredric wrote: > > On Thu, 09 Mar 2017 16:34:20 +0100 > > Michał Górny wrote: > > > > > 1. classic forks -- package B is forked out of A,

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

- Typo... Additional Security Project bugzilla notes * The Security Project is except (should that read "exempt"?) - An intermediate level before masking might be issuing a warning if some simple, specific remediation measure can protect against a vulnerability. E.g. forcing cups to only

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

On Sat, Mar 11, 2017 at 6:54 PM, Kristian Fiskerstrand wrote: > On 03/11/2017 11:23 PM, Andrew Savchenko wrote: >> >> My point is that users must be informed about security problem, but >> they still should have a choice. So it should be either a rule >> "mask without removal" or

Re: [gentoo-dev] How to deal with package forks?

On Sat, Mar 11, 2017 at 8:48 PM, Kent Fredric wrote: > On Thu, 09 Mar 2017 16:34:20 +0100 > Michał Górny wrote: > >> 1. classic forks -- package B is forked out of A, and the development of >> both continue independently (eudev/systemd, ffmpeg/libav); >> >>

Re: [gentoo-dev] [patch] golang-vcs-snapshot.eclass: add vendoring of external dependencies

On Thu, 09 Mar 2017 18:16:51 -0500 "William L. Thomson Jr." wrote: > That would likely be an incorrect ebuild and should not have been committed > to > tree. If people didn't accidentally overlook problems where variables contained the wrong contents and tried to access

Re: [gentoo-dev] How to deal with package forks?

On Thu, 09 Mar 2017 16:34:20 +0100 Michał Górny wrote: > 1. classic forks -- package B is forked out of A, and the development of > both continue independently (eudev/systemd, ffmpeg/libav); > > 2. large patch sets / continuously rebased forks -- where the particular > set of

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

On 03/11/2017 11:23 PM, Andrew Savchenko wrote: > Hi Kristian, > > On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote: >> A draft of a Pre-GLEP for the Security project is available for reading >> at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security >> >> The GLEP follows a line of

[gentoo-dev] Last rites: dev-scheme/schoca

# Michael Palimaka (11 Mar 2017) # Fails to build. Dead upstream. # Masked for removal in 30 days. Bug #592184. dev-scheme/schoca

[gentoo-dev] Re: Fwd: [Bug 597822] www-apache/mod_perl-2.0.10 dev-perl/Chatbot-Eliza-1.60.0 keyword request

Alexis Ballier posted on Sat, 11 Mar 2017 20:59:56 +0100 as excerpted: > On Sat, 11 Mar 2017 20:45:07 +0100 "Andreas K. Huettel" > wrote: >> This keywording bug 597822 is now open since 2016-10-22. > > > Man, it's been only 5 months :) ... which will make it six months

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

Hi Kristian, On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote: > A draft of a Pre-GLEP for the Security project is available for reading > at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security > > The GLEP follows a line of GLEPs for special projects that have > tree-wide access

[gentoo-dev] last rites: dev-perl/Net-Google-SafeBrowsing-UpdateRequest dev-perl/Mail-SpamAssassin-Plugin-GoogleSafeBrowsing

# Andreas K. Hüttel (11 Mar 2017) # Fails since upgrade to dev-lang/perl-5.12 (!). # Removal in 30 days. Bug 336898. dev-perl/Net-Google-SafeBrowsing-UpdateRequest dev-perl/Mail-SpamAssassin-Plugin-GoogleSafeBrowsing -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux

[gentoo-dev] last rites: dev-libs/btparse

(side notes, * the original dev-libs/btparse library has not seen any updates since 2007 * the Perl version removed the separate (autoconf) build system, so only Makefile.PL really works now...) # Andreas K. Hüttel (11 Mar 2017) # Dead upstream; the library has been

[gentoo-dev] Last rites: dev-java/jusb

# Patrice Clement (11 Mar 2017) # Upstream dead: no update since 2003. Ebuild is outdated and buggy. # Removal in 30 days. Bug #279088 dev-java/jusb -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature

[gentoo-dev] RFC: Pre-GLEP: Security Project

A draft of a Pre-GLEP for the Security project is available for reading at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security The GLEP follows a line of GLEPs for special projects that have tree-wide access in order to ensure proper accountability (c.f GLEP 48 for QA and still non-produced GLEP

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

On 3/11/17 3:13 PM, Peter Stuge wrote: > > All lines containing +knots should say knots instead. > Done. I'm getting increasingly unsatisfied with where bitcoins* is going. I think I'd like to take full ownership of it and remove all unnecessary patches. If there's anyone that wants to

Re: [gentoo-dev] Fwd: [Bug 597822] www-apache/mod_perl-2.0.10 dev-perl/Chatbot-Eliza-1.60.0 keyword request

On Sat, 11 Mar 2017 20:45:07 +0100 "Andreas K. Huettel" wrote: > This keywording bug 597822 is now open since > 2016-10-22. Man, it's been only 5 months :)

[gentoo-dev] Fwd: [Bug 597822] www-apache/mod_perl-2.0.10 dev-perl/Chatbot-Eliza-1.60.0 keyword request

Forwarded message: https://bugs.gentoo.org/show_bug.cgi?id=597822 --- Comment #5 from Andreas K. Hüttel --- @@@ IMPORTANT MESSAGE TO ARCH TEAMS @@ I'll drop keywords for mod_perl and all of its reverse dependencies for any arch that has not even

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

Anthony G. Basile wrote: > >> I proxy maintain bitcoins for luke-jr. He wants to propose a patch > >> against the bitcoin eclass. The following is his proposed change. > >> I'll commit it after review. > > > > Please do not do that, Anthony. > > I don't have time nor the familiarity to

[gentoo-dev] [PATCH] eutils.eclass: Kill multilib inherit for EAPI 7

The multilib.eclass seems not to be used by any eutils function. Therefore, disable the inherit for EAPI 7. It is being preserved for older EAPIs not to break ebuilds inheriting this eclass and using multilib.eclass functions implicitly. --- eclass/eutils.eclass | 4 ++-- 1 file changed, 2

[gentoo-dev] [PATCH v2] epatch.eclass: Split epatch* logic from eutils

Move epatch and epatch_user (along with the descriptions for all their variables) into a dedicated epatch.eclass. This function is very complex, therefore it benefits from separate eclass and a dedicated maintainer. Furthermore, it is mostly obsoleted by eapply* in EAPI 6. The new eclass is

[gentoo-dev] [PATCH v2] estack.eclass: Split estack* logic from eutils

Split the estack_* and related functions from eutils into a dedicated estack.eclass. Those functions have significant complexity and are not used frequently, therefore they benefit from having a separate file and an explicit dedicated maintainer. The new eclass is implicitly inherited by eutils

Re: [gentoo-dev] [PATCH] estack.eclass: Split estack* logic from eutils

> On Sat, 11 Mar 2017, Michał Górny wrote: > Split the estack_* and related functions from eutils into a > dedicated estack.eclass. Those functions have significant complexity > and are not used frequently, therefore they benefit from having a > separate file and an explicit dedicated

Re: [gentoo-dev] [PATCH] epatch.eclass: Split epatch* logic from eutils

W dniu 11.03.2017, sob o godzinie 09∶04 -0500, użytkownik Michael Orlitzky napisał: > On 03/11/2017 08:51 AM, Michał Górny wrote: > > > > However, the inherit will be removed in EAPI 7 > > > > ... > > > > -inherit estack multilib toolchain-funcs > > +inherit epatch estack multilib

Re: [gentoo-dev] [PATCH] epatch.eclass: Split epatch* logic from eutils

On 03/11/2017 08:51 AM, Michał Górny wrote: > > However, the inherit will be removed in EAPI 7 > > ... > > -inherit estack multilib toolchain-funcs > +inherit epatch estack multilib toolchain-funcs > Would it hurt to do that now, so that we don't forget when EAPI 7 comes? For EAPI=0 to 6,

[gentoo-dev] [PATCH] epatch.eclass: Split epatch* logic from eutils

Move epatch and epatch_user (along with the descriptions for all their variables) into a dedicated epatch.eclass. This function is very complex, therefore it benefits from separate eclass and a dedicated maintainer. Furthermore, it is mostly obsoleted by eapply* in EAPI 6. The new eclass is

[gentoo-dev] [PATCH] estack.eclass: Split estack* logic from eutils

Split the estack_* and related functions from eutils into a dedicated estack.eclass. Those functions have significant complexity and are not used frequently, therefore they benefit from having a separate file and an explicit dedicated maintainer. The new eclass is implicitly inherited by eutils

[gentoo-dev] [PATCH] eutils.eclass: Deprecate validate_desktop_entries

The validate_desktop_entries function is redundant to the built-in .desktop file checks done by Portage directly. It is used in total by two packages for both of which bugs have been filed. --- eclass/eutils.eclass | 3 +++ 1 file changed, 3 insertions(+) diff --git a/eclass/eutils.eclass