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 since 2016-10-22.
> >
>
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, and the development of
> > > both cont
- 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 li
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 clear guidelines
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);
>>
>> 2. large patch sets / continuously reba
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 files they shouldn't,
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 changes is usually
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 G
# Michael Palimaka (11 Mar 2017)
# Fails to build. Dead upstream.
# Masked for removal in 30 days. Bug #592184.
dev-scheme/schoca
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 after the announced 30-d
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 in
# 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 developer (council, perl
(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 picked up by
# dev-perl/Text
# 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
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 f
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 co-ma
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 :)
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 restored the KEYWORD yet in th
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 properly
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 inserti
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 implic
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 to
> 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 maintain
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 toolchain-fun
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, in
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 implic
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 to
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 b/eclas
28 matches
Mail list logo
