[gentoo-dev] [PATCH] kernel-2.eclass: Force deblob-check to use awk

[Alice Ferrazzi]

This patch remove python from the kernel-2.eclass
by forcing the deblob-check script to use awk instead
of python.

Closes: https://bugs.gentoo.org/610008

Signed-off-by: Alice Ferrazzi 
---
 eclass/kernel-2.eclass | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index b3fb5cef76c..50464470a9b 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -675,15 +675,7 @@ if [[ ${ETYPE} == sources ]]; then
 
# Bug #266157, deblob for libre support
if [[ -z ${K_PREDEBLOBBED} ]]; then
-   # deblob less than 5.10 require python 2.7
-   if kernel_is lt 5 10; then
-   K_DEBLOB_AVAILABLE=0
-   fi
if [[ ${K_DEBLOB_AVAILABLE} == 1 ]]; then
-   PYTHON_COMPAT=( python3_{8..10} )
-
-   inherit python-any-r1
-
IUSE="${IUSE} deblob"
 
# Reflect that kernels contain firmware blobs unless 
otherwise
@@ -691,8 +683,6 @@ if [[ ${ETYPE} == sources ]]; then
# tree has been dropped from the kernel.
kernel_is lt 4 14 && LICENSE+=" !deblob? ( 
linux-firmware )"
 
-   BDEPEND+=" deblob? ( ${PYTHON_DEPS} )"
-
if [[ -n KV_MINOR ]]; then
DEBLOB_PV="${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}"
else
@@ -1470,8 +1460,10 @@ kernel-2_src_compile() {
cd "${S}" || die
 
if [[ ${K_DEBLOB_AVAILABLE} == 1 ]] && use deblob; then
+   einfo ">>> Patching deblob script for forcing awk ..."
+   sed -i '/check="\/bin\/sh $check"/a \  check="$check 
--use-awk"' \
+   "${T}/${DEBLOB_A}" || die "Failed to patch ${DEBLOB_A}"
einfo ">>> Running deblob script ..."
-   python_setup
sh "${T}/${DEBLOB_A}" --force || die "Deblob script failed to 
run!!!"
fi
 }
-- 
2.35.1

[gentoo-dev] [PATCH] Clean deblob

[Alice Ferrazzi]

As we are moving out to deprecate EAPI=6 from kernel-2.eclass
start removing it from deblob function. Also clean code linked to old
kernel versions. kernel sources that use deblob are already updated to
EAPI=8

Signed-off-by: Alice Ferrazzi 
---
 eclass/kernel-2.eclass | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 58e0bae94e..36e081541e 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -220,11 +220,6 @@ fi
 HOMEPAGE="https://www.kernel.org/ https://wiki.gentoo.org/wiki/Kernel 
${HOMEPAGE}"
 : ${LICENSE:="GPL-2"}
 
-# This is the latest KV_PATCH of the deblob tool available from the
-# libre-sources upstream. If you bump this, you MUST regenerate the Manifests
-# for ALL kernel-2 consumer packages where deblob is available.
-: ${DEBLOB_MAX_VERSION:=38}
-
 # No need to run scanelf/strip on kernel sources/headers (bug #134453).
 RESTRICT="binchecks strip"
 
@@ -600,11 +595,6 @@ if [[ ${ETYPE} == sources ]]; then
 
# Bug #266157, deblob for libre support
if [[ -z ${K_PREDEBLOBBED} ]]; then
-   # Bug #359865, force a call to detect_version if needed
-   kernel_is ge 2 6 27 && \
-   [[ -z ${K_DEBLOB_AVAILABLE} ]] && \
-   kernel_is le 2 6 ${DEBLOB_MAX_VERSION} && \
-   K_DEBLOB_AVAILABLE=1
# deblob less than 5.10 require python 2.7
if kernel_is lt 5 10; then
K_DEBLOB_AVAILABLE=0
@@ -621,7 +611,6 @@ if [[ ${ETYPE} == sources ]]; then
# tree has been dropped from the kernel.
kernel_is lt 4 14 && LICENSE+=" !deblob? ( 
linux-firmware )"
 
-   [[ ${EAPI} == 6 ]] && DEPEND+=" deblob? ( 
${PYTHON_DEPS} )" ||
BDEPEND+=" deblob? ( ${PYTHON_DEPS} )"
 
if [[ -n KV_MINOR ]]; then
-- 
2.25.3

Re: [gentoo-dev] rfc: [QA] Ban policy introduction

[Alice Ferrazzi]

Sent from my phone. Please excuse my brevity.

On Sun, 29 Jul 2018, 16:39 Fabian Groffen,  wrote:

> Completely agreeing with Sergei, with some additional suggestions:
>
> On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote:
> > On Sun, 29 Jul 2018 00:40:18 +0300
> > Mikle Kolyada  wrote:
> >
> > > Hello,
> > >
> > > The Gentoo QA team would like to introduce the following policy that
> > > would be applied to individuals breaking the state and quality of the
> > > main gentoo.git tree
> > >
> > > ( as we do not have this strictly documented yet):
> > >
> > > 
> > >
> > > If recommended
> >
> > It's not called "recommended" but "enforced".
>
> I agree.  If you put penalties on these, they become hard rules.  I
> think that change should be discussed by the council perhaps?
>
> > > Gentoo workflow policies are not followed by an
> > > individual developer
> > > (e.g make major changes to the widely used eclasses without prior
> > > discussion on the mailing list or
> > > commit changes that lead to multiple CI checks failure)
> >
> > Here should go exhaustive list of links to the policies to be enforced.
>
> At least.  And they should be clear and concise.  No "common sense" or
> anything involved for exceptions and the like.  In addition, new checks
> should be introduced to the community and possibly approved by council
> as to whether being enforced or not.
>
> Fabian
>
> >
> > > the standard QA
> > > procedure is:
> > >
> > > 1.) Two warnings granted by QA team, after two independent breakages
> > > 2.) Revoking the commit access for 14 days
> > >
> > > These violations will be evaluated individually by all QA team members.
> > > Warnings can be revoked, if during 6 months period a developer makes at
> > > least 20 non trivial changes not producing more breakages.
> > >
> > > 
> >
> > --
> >
>
if you want to enforce rules, would be productive to also have extensive
documentation on how to avoid to make such problems.
Better would be to invest more time in something like the breckage checker
script, similar at what mgorny is doing, than adding more ways to block
developers contributions.

thanks,
Alice

>

Re: [gentoo-dev] New "Portage Security" wiki page

[Alice Ferrazzi]

Hello

On Tue, Jul 3, 2018 at 9:33 AM, Virgil Dupras  wrote:
> Hi everyone,
>
> With the recent Github incident, users have (rightfully) voiced concerns 
> about the security of their Gentoo ebuild tree. Luckily, thanks to recent 
> efforts on the repository verification feature, we can answer "yes, it's 
> possible to update your ebuild tree in a convenient and secure manner", but 
> documentation about how to do it is not readily available. I've seen some of 
> these questions only partially answered due to our own lack of knowledge on 
> this subject as developers.
>
> To fix this, I've been working, in the last few days, on a new "Portage 
> Security" wiki page [1] that aims to guide the user to a secure setup and 
> dispel doubts about the security of their setup. I would invite you to start 
> pointing users to it when they ask questions on this matter.
>
> I'm not a very experienced developer and this has been written with the 
> little knowledge I have, so I invite you to review and correct it if needed.

I think is a nice idea :)
++


-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Gentoo Foundation Vice-Secretary
Gentoo Google Summer of Code Administrator
Mail: Alice Ferrazzi 
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

[gentoo-dev] Open Source Summit Japan 2018 MeetUp

[Alice Ferrazzi]

Gentoo,

I will be attending the Open Source Summit Japan in Tokyo. The
conference is Jun 20-22th.
I will give a talk about elivepatch (The current livepatch distributed
system for Gentoo)
https://events.linuxfoundation.org/events/open-source-summit-japan-2018/program/schedule/

Please reply if you are interested in meeting and which day(s)/time(s)
you are available. I'm looking forward to it!



Thanks,
Alice
-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Gentoo Foundation Vice-Secretary
Gentoo Google Summer of Code Administrator
Mail: Alice Ferrazzi 
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

[gentoo-dev] Gentoo has been accepted as a Google Summer of Code 2018 mentoring organization

[Alice Ferrazzi]

Hello everyone,

Gentoo has been accepted into the Google Summer of Code 2018!

Mentors:
If you want to mentor some projects on Gentoo GSoC 2018 please add
yourself here [1] as soon as possible, is important!.
Someone from the Gentoo GSoC team will contact you back, as soon as possible.

Students:
If you are a student and want to spend your summer on Gentoo projects
and having fun writing code, you can start discussing ideas in the
#gentoo-soc IRC Freenode channel [2].
You can find some ideas example here [3], but of course could be also
something different.
Just remember that we strongly recommend that you work with a
potential mentor to develop your idea before proposing it formally.
Don’t waste any time because there’s typically some polishing which
needs to occur before the deadline (March 28th)

I can assure you that Gentoo GSoC is really fun and a great experience
for improving yourself.
It is also useful for making yourself known in the Gentoo community.
Contributing to the Gentoo GSoC will be contributing to Gentoo, a
bleeding edge distribution, considered by many to be for experts and
with near-unlimited adaptability.

If you require any further information, please do not hesitate to
contact us [4] or check the Gentoo GSoC 2018 wiki page [5].

[1] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2018/Mentors
[2] http://webchat.freenode.net/?channels=gentoo-soc
[3] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2018/Ideas
[4] soc-ment...@gentoo.org
[5] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2018

-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Gentoo Foundation Vice-Secretary
Gentoo Google Summer of Code Administrator
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-dev] [PATCH] kernel.eclass: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y

[Alice Ferrazzi]

>From f9b2693b32b7c7c7c561ae417cbd757624184327 Mon Sep 17 00:00:00 2001
From: Alice Ferrazzi <ali...@gentoo.org>
Date: Thu, 18 Jan 2018 15:41:17 +
Subject: [PATCH] Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y

New 4.14 kernel is using CONFIG_UNWINDER_ORC=y by default
but having USE="minimal" is removing virtual/libelf,
this is breaking the Kernel compilation.
Closes: https://github.com/gentoo/gentoo/pull/6898

On Thu, Feb 1, 2018 at 4:09 AM, Robin H. Johnson <robb...@gentoo.org> wrote:
> On Thu, Feb 01, 2018 at 12:09:10AM +0900, Alice Ferrazzi wrote:
>> New 4.14 kernel is using CONFIG_UNWINDER_ORC=y by default
>> but having USE="minimal" is removing virtual/libelf,
>> this is breaking the Kernel compilation.
> +1, this explains a breakage I saw for catalyst/genkernel.
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
> E-Mail   : robb...@gentoo.org
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136



-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Gentoo Foundation Vice-Secretary
Gentoo Google Summer of Code Administrator
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

[gentoo-dev] [PATCH] kernel.eclass: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y

[Alice Ferrazzi]

New 4.14 kernel is using CONFIG_UNWINDER_ORC=y by default
but having USE="minimal" is removing virtual/libelf,
this is breaking the Kernel compilation.
---
 eclass/kernel-2.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index a42d5f5ec24b..6ffbd37f300e 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -606,6 +606,7 @@ if [[ ${ETYPE} == sources ]]; then
  sys-devel/make
  dev-lang/perl
  sys-devel/bc
+ virtual/libelf
  )"

  SLOT="${PVR}"



-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Gentoo Foundation Vice-Secretary
Gentoo Google Summer of Code Administrator
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-dev] vanilla-sources broken

[Alice Ferrazzi]

On Fri, Jan 5, 2018 at 11:08 PM, Nicolas Bock <nicolasb...@gentoo.org> wrote:
> Hi,
>
> currently vanilla-sources are broken, but there is an upstream patch that
> fixes it (appended at the end). I know that vanilla-sources are supposed to
> be vanilla, but it would help if we added this patch until upstream
> backports it. Any thoughts?
>

Hello Nicolas,

vanilla-sources, unfortunately, are given same as the kernel upstream,
Gentoo is not supporting or adding patches to vanilla-sources.
If you have any problem with vanilla-sources please report it to the Kernel
upstream not to Gentoo.
If you want kernel support from Gentoo kernel team, please switch to
gentoo-sources.

-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Gentoo Foundation Board Member
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

[gentoo-dev] Masking 4.12

[Alice Ferrazzi]

Hello,

We recently dropped the stable keywords for 4.14,
but 4.12 (the next stable in gentoo-sources) is no more
maintained from upstream.

The last update that 4.12 got from upstream was 2017-09-20,
and upstream is no more backporting security fixes since then.
Because of this, we will proceed to mask 4.12.

Keep in mind: If 4.14 works for you, you can keyword it and
continue to use it, if you need a more stable kernel, please
move to 4.9.

-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Gentoo Foundation Board Member
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

[gentoo-dev] Dropping stable USE flags for 4.14

[Alice Ferrazzi]

Hello,

We have recently started the stabilization of gentoo-sources-4.14.8.

Very soon we received reports regarding broken e1000e driver [1] and moved
to gentoo-sources-4.14.8-r1.

Since then we keep receiving new problems related to 4.14.x kernel:

- IPSec is broken [2]

- Change in 4.14.9 broke nVIDIA driver [3]

- Colors on console are broken with some Radeon HD cards [4]

- BUG report on boot [5]

- Unbootable system with CONFIG_MCORE2 [6]

- ...more bugs [7]

While not all issues are present in gentoo-sources-4.14.8-r1 we are
concerned about the current stability/quality of the 4.14.x branch in
general and don't feel comfortable recommending 4.14.x branch for general
use at the moment. But that's what a stable USE flag means for most
Gentoo users.

So, for now, we have decided to drop gentoo-sources-4.14.x stable keywords.
We will keep watching 4.14 branch and once the stability/quality matches
our requirements we will restart stabilization.

Keep in mind: We are only dropping stable USE flags. If
gentoo-sources-4.14.x works for you and you want to keep it, just keyword
the package on your own!

[1] https://bugs.gentoo.org/641818

[2] https://bugs.gentoo.org/642454

[3] http://lkml.iu.edu/hypermail/linux/kernel/1712.3/00099.html

[4] https://bugzilla.kernel.org/show_bug.cgi?id=198273

[5] https://lkml.org/lkml/2017/12/25/177

[6] https://bugs.gentoo.org/642268

[7] 
https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=REOPENED=cf_kernel_version=equals_format=advanced=4.14.8

-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Gentoo Foundation Board Member
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-dev] Maintainer-needed eclasses

[Alice Ferrazzi]

On Sun, Jul 2, 2017 at 7:39 AM, Michał Górny <mgo...@gentoo.org> wrote:
> Hi, everyone.
>
> I'm sending a complete list of eclasses that do not have an active
> maintainer (or lack a maintainer info). Please take a look at it and see
> if you can take up some of them.
>
> alternatives.eclass
> aspell-dict-r1.eclass
> bsdmk.eclass
> cannadic.eclass
> common-lisp-common.eclass
> common-lisp.eclass
> confutils.eclass [@DEAD]
> db-use.eclass
> font-ebdftopcf.eclass
> fox.eclass
> freebsd.eclass
> freedict.eclass
> games-mods.eclass
> git-2.eclass [deprecated]
> gkrellm-plugin.eclass
> gnatbuild.eclass
> gnatbuild-r1.eclass
> gnuconfig.eclass [supposedly DEAD but used]
> l10n.eclass
> makeedit.eclass [probably DEAD w/ false positive]
> myspell.eclass
> myspell-r2.eclass
> openib.eclass
> qmail.eclass [qmail team was disbanded]
> scsh.eclass
> ssl-cert.eclass
> stardict.eclass

Golden dict share same eclass of stardict ?

> vim-doc.eclass
> waf-utils.eclass
>
>
> --
> Best regards,
> Michał Górny



-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-dev] The status of grsecurity upstream and hardened-sources downstream

[Alice Ferrazzi]

Linus Torvald on grsecurity:
https://www.spinics.net/lists/kernel/msg2540934.html


-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-dev] Re: [gentoo-project] The status of grsecurity upstream and hardened-sources downstream

[Alice Ferrazzi]

On Sat, Jun 24, 2017 at 5:48 AM, Roy Bamford <neddyseag...@gentoo.org> wrote:
> On 2017.06.23 19:54, Alice Ferrazzi wrote:
> [snip]
>>
>> As we already contribute to grsec in the past,
>> would be sad to see hardened-sources go away.
>> What about the possibility of Gentoo forking PaX ?
>>
>> --
>> Thanks,
>> Alice Ferrazzi
>>
>> Gentoo Kernel Project Leader
>> Mail: Alice Ferrazzi <ali...@gentoo.org>
>> PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A
>>
>>
>
> Alice,
>
> Forking with what aim?
> Keeping the existing functionality alive in line with kernel
> developments or that and adding new features.
>

As now we have not enough resource for add new feature,
we can maybe consider to keep alive PaX.

I heard that also Alpine linux is thinking what to do.
Maybe we could ask to merge the efforts.

https://forum.alpinelinux.org/forum/pax-grsecurity/future-grsecurity-alpine


-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

[gentoo-dev] Re: [gentoo-project] The status of grsecurity upstream and hardened-sources downstream

[Alice Ferrazzi]

On Sat, Jun 24, 2017 at 1:28 AM, Anthony G. Basile <bluen...@gentoo.org> wrote:
>
> Hi everyone,
>
> Since late April, grsecurity upstream has stop making their patches
> available publicly.  Without going into details, the reason for their
> decision revolves around disputes about how their patches were being
> (ab)used.
>
> Since the grsecurity patch formed the main core of our hardened-sources
> kernel, their decision has serious repercussions for the Hardened Gentoo
> project.  I will no longer be able to support hardened-sources and will
> have to eventually mask and remove it from the tree.
>
> Hardened Gentoo has two sides to it, kernel hardening (done via
> hardened-sources) and toolchain/executable hardening.  The two are
> interrelated but independent enough that toolchain hardening can
> continue on its own.  The hardened kernel, however, provided PaX
> protection for executables and this will be lost.  We did a lot of work
> to properly maintain PaX markings in our package management system and
> there was no part of Gentoo that wasn't touched by issues stemming from
> PaX support.
>
> I waited two months before saying anything because the reasons were more
> of a political nature than some technical issue.  At this point, I think
> its time to let the community know about the state of affairs with
> hardened-sources.
>
> I can no longer get into the #grsecurity/OFTC channel (nothing personal,
> they kicked everyone), and so I have not spoken to spengler or pipacs.
> I don't know if they will ever release grsecurity patches again.
>
> My plan then is as follows.  I'll wait one more month and then send out
> a news item and later mask hardened-sources for removal.  I don't
> recommend we remove any of the machinery from Gentoo that deals with PaX
> markings.
>
> I welcome feedback.
>

As we already contribute to grsec in the past,
would be sad to see hardened-sources go away.
What about the possibility of Gentoo forking PaX ?

-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Handle upstream rc kernel file type and, file location change for versions >= 4.12

[Alice Ferrazzi]

Hello Mike,



On Thu, May 18, 2017 at 8:13 AM, Mike Pagano <mpag...@gentoo.org> wrote:
> For the latest rc kernel release, (4.12-rc1), upstream has decided to
> change the way the patch is distributed.
> The patch now resides in a git repository and is no longer compressed.
>
> Some discussion can be found here[1] if one is interested. They could
> reverse this decision.

>>One thing worth noting - I haven't uploaded diffs or tar-balls for
>>this rc. Those should now be automagically generated by kernel.org for
>>the rc's, but that also means that they won't be signed by my key. If
>>you really care about signing, get the git repo and check the tag.

so maybe they will start to auto-generate the tar-balls and diff ?
looks like a bit step for kernel.org


>
> This patch handles the change for rc kernels >= 4.12.
>
>
> [1] https://lkml.org/lkml/2017/5/13/182
>
> Signed-off-by: Mike Pagano <mpag...@gentoo.org>
> ---
>  eclass/kernel-2.eclass | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index db4a3bf72..52749cda9 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -506,10 +506,20 @@ detect_version() {
> OKV_DICT=(["2"]="${KV_MAJOR}.$((${KV_PATCH_ARR} - 1))" 
> ["3"]="2.6.39"
> ["4"]="3.19")
>
> if [[ ${RELEASETYPE} == -rc ]] || [[ ${RELEASETYPE} == -pre 
> ]]; then
> +
> OKV=${K_BASE_VER:-$OKV_DICT["${KV_MAJOR}"]}
> -   
> KERNEL_URI="${KERNEL_BASE_URI}/testing/patch-${CKV//_/-}.xz
> -   
> ${KERNEL_BASE_URI}/linux-${OKV}.tar.xz"
> -   
> UNIPATCH_LIST_DEFAULT="${DISTDIR}/patch-${CKV//_/-}.xz"
> +
> +   # as of 12/5/2017, the rc patch is no longer offered 
> as a compressed
> +   # file, and no longer is it mirrored on kernel.org
> +   if [[ ${KV_MAJOR} -ge 4 ]] && [[ ${KV_PATCH} -ge 12 
> ]]; then
> +   
> KERNEL_URI="https://git.kernel.org/torvalds/p/v${KV}/v${OKV} ->
> patch-${KV}
> +   
> ${KERNEL_BASE_URI}/linux-${OKV}.tar.xz"
> +   
> UNIPATCH_LIST_DEFAULT="${DISTDIR}/patch-${CKV//_/-}"
> +   else
> +   
> KERNEL_URI="${KERNEL_BASE_URI}/testing/patch-${CKV//_/-}.xz
> +   
> ${KERNEL_BASE_URI}/linux-${OKV}.tar.xz"
> +   
> UNIPATCH_LIST_DEFAULT="${DISTDIR}/patch-${CKV//_/-}.xz"
> +   fi
> fi
>
>     if [[ ${RELEASETYPE} == -git ]]; then


looks ok for me.

> --
> 2.13.0
> Mike Pagano
> Gentoo Developer - Kernel Project
> Gentoo Sources - Lead
> E-Mail : mpag...@gentoo.org
> GnuPG FP   : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137
> Public Key :
> http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
>
>



-- 
アリス フェッラッツィ
Alice Ferrazzi

Gentoo Kernel Project Leader
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-dev] [PATCH 1/1] eclass/kernel-2: Add additional help text when K_SECURITY_UNSUPPORTED is set

[Alice Ferrazzi]

On Thu, Mar 2, 2017 at 9:09 AM, Mike Pagano <mpag...@gentoo.org> wrote:
> This patch will add some additional text to bring some additional notice
> to users
> about the security considerations of a specific kernel and direct them
> to the
> upstream website for further information.  See bug #599454
>
> Signed-off-by: Mike Pagano <mpag...@gentoo.org>
> ---
>  eclass/kernel-2.eclass | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index e95ec07..2aaab58 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -1054,6 +1054,12 @@ postinst_sources() {
> #  And now the general message.
> if [[ -n ${K_SECURITY_UNSUPPORTED} ]]; then
> ewarn "This means that it is likely to be vulnerable to recent
> security issues."
> +   echo
> +   ewarn "Upstream kernel developers recommend always running 
> the latest "
> +   ewarn "release of any current long term supported Linux 
> kernel version."
> +   ewarn "To see a list of these versions, their most current 
> release and "
> +   ewarn "long term support status, please go to 
> https://www.kernel.org ."
> +   echo
> ewarn "For specific information on why this kernel is 
> unsupported,
> please read:"
> ewarn "https://wiki.gentoo.org/wiki/Project:Kernel_Security;
> fi
> --
> 2.10.2
>
>

looks like a nice idea.
+1

-- 
アリス フェッラッツィ
Alice Ferrazzi

Gentoo Kernel Project Leader
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

[gentoo-dev] [PATCH] kernel-2.eclass: enable eapi6

[Alice Ferrazzi]

After mpagano works on the kernel-2.eclass update,
I think we can move kernel-2.eclass to EAPI6.

---
 eclass/kernel-2.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 0c9ce04..351e32c 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -198,7 +198,7 @@ case ${EAPI:-0} in
0|1)
EXPORT_FUNCTIONS src_{unpack,compile,install,test} \
pkg_{setup,preinst,postinst,postrm} ;;
-   2|3|4|5)
+   2|3|4|5|6)
EXPORT_FUNCTIONS src_{unpack,prepare,compile,install,test} \
pkg_{setup,preinst,postinst,postrm} ;;
*) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
-- 
2.7.3

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Alice Ferrazzi]

On Wed, Jan 4, 2017 at 12:23 AM, Rich Freeman <ri...@gentoo.org> wrote:
> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol <mike...@gmail.com> wrote:
>>
>> For security's sake, even mature software needs, at minimum, routine 
>> auditing.
>> Unless someone's doing that work, the package should be considered for
>> removal. (Call that reason #π, in honor of TeX.)
>>
>
> Are you suggesting that we should ban any package from the tree if we
> don't have evidence of it having recently being subjected to a
> security audit?  We might literally have 3 packages left in the tree
> in that case, probably not including the kernel (forget the GNU/Linux
> debate, we might be neither).
>
> The fact that a project gets 47 commits and 100 list posts a week
> doesn't mean that it is being security audited, or that security is
> any kind of serious consideration in how their workflow operates.
>
> I tend to be firmly in the camp that a package shouldn't be removed
> unless there is evidence of a serious bug (and that includes things
> blocking other Gentoo packages).  If somebody wants to come up with a
> "curated" overlay or some way of tagging packages that are considered
> extra-secure that would be a nice value-add, but routine auditing is
> not a guarantee we provide to our users.  The lack of such an audit
> should not be a reason to treeclean.

+1

>
> --
> Rich
>



-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Gentoo Euscan: http://goo.gl/YNbU3h
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Point user to additional kernel removal, instructions. See bug #581522.

[Alice Ferrazzi]

looks like nice information to give :)

ok, for me.

On Wed, Dec 28, 2016 at 9:52 AM, Mike Pagano <mpag...@gentoo.org> wrote:
> This addresses concerns that users might not realize that after an
> unmerge of kernel sources some files will need to be removed manually.
> The particular concern was specific to the files in /lib/modules/. I
> liked this solution, since it does not require a wordy explanation to be
> written in the eclass.
>
> ---
>  eclass/kernel-2.eclass | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index 520a4c1..29b2987 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -1619,4 +1619,7 @@ kernel-2_pkg_postrm() {
> ewarn "with modified files will remain behind. By design, package
> managers"
> ewarn "will not remove these modified files and the directories they
> reside in."
> echo
> +   ewarn "For more detailed kernel removal instructions, please see: "
> +   ewarn "https://wiki.gentoo.org/wiki/Kernel/Removal;
> +   echo
>  }
> --
> 2.10.2
>
>
>



-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Gentoo Euscan: http://goo.gl/YNbU3h
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Remove code that looks for Changelog which is also breaks PMS rules going above FILESDIR.

[Alice Ferrazzi]

On Sat, Dec 24, 2016 at 7:43 AM, Mike Pagano <mpag...@gentoo.org> wrote:
> ChangeLog


looks good for me :)

-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Gentoo Euscan: http://goo.gl/YNbU3h
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Remove kdbus support as it is, discontinued. First reported in bug #576614 by jon R-B

[Alice Ferrazzi]

looks nice

On 16 Dec 2016 08:38, "Mike Pagano"  wrote:

On 12/14/2016 07:23 PM, Mike Pagano wrote:
> kdbus is discontinued and is being reworked upstream as a different
> effort with a different name.
> That said, remove unused kdbus support from the kernel eclass.
>

Committed.


--
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead
E-Mail : mpag...@gentoo.org
GnuPG FP   : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137
Public Key :
http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index

Re: [gentoo-dev] Gentoo Staffing Needs page is out of date

[Alice Ferrazzi]

On Tue, Nov 29, 2016 at 7:45 AM, Gokturk Yuksek <gokt...@gentoo.org> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 11/23/2016 12:31 AM, Gokturk Yuksek wrote:
>> Hi all,
>>
>> The Staffing Needs page on the wiki [0] seems a little out of
>> date, there are still mentions of "herds". I invite project leads
>> and members to update it. We added a reference to it in the Mentors
>> wiki page [1] and hoping to get more attention to it.
>>
>> Thanks,
>>
>> [0] https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs [1]
>> https://wiki.gentoo.org/wiki/Project:Mentors
>>
>
> Given the inactivity on the page since the submission of this post,
> I'll clear the page entirely in two days. It's better to have no
> information than a misleading one. Please remember to update the page
> with your staffing needs after the cleanup.
>
> Thanks,
>

Thanks!

> - --
> gokturk
> -BEGIN PGP SIGNATURE-
>
> iQEcBAEBCgAGBQJYPLNjAAoJEIT4AuXAiM4zpDAH+wdvnDtsApe0eJ2rZ+um5Hhy
> +YdkxVmd4c2jmvSqBKQL4zC3EHX5vWU5agQ+cTPi4vzb2OvVvodiRYgczwC+8s6W
> neXJ1T2VQ82woZ2pi97Vcu8DNdxJJcXAtCufpAEIj94OH10yPPnLazZS5I0SJXh+
> LVVgcfbLPIKJxuJoqJlyLqzc1PD7A6ZQ4Z6Hlvdj9xZs0DL4MeK7p+YrqBEG9DBX
> ciKkPzu2i8Kv+dzOfJOW6KlGmlfShtH61Z4ApKJSDB4K2wGifoQ5bfUzm109t9UR
> lfN14BOS0uA0eVIf5EmqY+b4rganZUkyYfyvRIjXmclaV5NkN++YkwW+fixe9K0=
> =2/+R
> -END PGP SIGNATURE-
>



-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Gentoo Euscan: http://goo.gl/YNbU3h
Mail: Alice Ferrazzi <ali...@gentoo.org>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-dev] Re: Stabilisation procedure

[Alice Ferrazzi]

On Fri, Nov 25, 2016 at 11:47:35PM -0800, Daniel Campbell wrote:
> On 11/22/2016 12:06 AM, Alice Ferrazzi wrote:
> > On Sat, Nov 19, 2016 at 12:55:09AM -0800, Daniel Campbell wrote:
> >> On 11/17/2016 01:07 PM, Robin H. Johnson wrote:
> >>> On Thu, Nov 17, 2016 at 03:05:41PM +0100, Kristian Fiskerstrand wrote:
> >>>>> Isn't it implied that any stabilisation is approved by the maintainer?
> >>>>> Has it ever been acceptable to go around stabilising random packages?
> >>>>>
> >>>>
> >>>> Explicit > Implicit when we're updating things anyways.
> >>>>
> >>>> There are scenarios where e.g Security is calling for stabilization ,
> >>>> I'll add some info to the draft security GLEP with some requirements for
> >>>> when this can happen without maintainer involvement as well..
> >>>>
> >>>> Ultimately maintainer is responsible for the state of the stable tree
> >>>> for the packages they maintain and should be taking proactive steps for
> >>>> this also for security bugs, it doesn't "always" happen like that.
> >>>
> >>> The interaction of this proposal and the prior discussion of allow
> >>> maintainers to document the maintenance policy of given packages is
> >>> where it would really come into play.
> >>>
> >>> Using two packages for examples:
> >>> app-admin/diradm: I am the upstream author as well as the package
> >>> maintainer. I care about it being marked stable. I'd prefer the normal
> >>> policy of other people asking me (with timeout) before touching it.
> >>>
> >>> app-admin/cancd: It's a very obscure package that I put in the tree
> >>> because I needed it, but I haven't personally used it in many years. 
> >>> I fix the packaging if it's broken only.
> >>> I'm inclined to mark it with 'anybody-may-bump/fix/stabilize'.
> >>>
> >> Agreed. For most of my packages, I really don't mind since we're all
> >> working on Gentoo together, but it'd be super helpful if I was simply
> >> notified in the event that a package I maintain has gotten a security
> >> bump, patch, or stabilization. Sure, 'git log' and 'git blame' can
> >> explain a few things, but if I was going to edit a package, I have the
> >> maintainer's e-mail available right there in metadata.xml. To me it's a
> >> courtesy that should be a requirement by default, while devs that don't
> >> care can use whatever means we agree upon to indicate that they don't care.
> >>
> >> This creates a "contact first" practice, which it seems we want to
> >> encourage. If someone isn't responsive and/or away, that complicates
> >> things, but if it's a security concern or the last blocker in a big
> >> stabilization effort (looking at you, tcl 8.6...), then it makes sense
> >> to just go ahead and make the bumps necessary.
> > 
> > What about maintainers that are away without writing it in their
> > maintainer bug ?
> > After how many days of no replay can be fair to touch their package ?
> > 
> >>
> >> -- 
> >> Daniel Campbell - Gentoo Developer
> >> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
> >> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
> >>
> > 
> > 
> > 
> We have a formal dev-away practice, requiring little more than literally:
> 
> ssh m...@dev.gentoo.org; echo "Away for vacation. Back in a week" >
> ~/.away; exit
> 
> A dev can add more details to the file if they want to. If they're gone
> and can't be reached at all, then I think a week is enough time for a
> developer to check their mail and get (or make) enough time to either
> update their dev-away status or otherwise indicate how they feel about a
> change that needs their feedback.
> 
> Maybe the maintainer-bug case is different if we're talking
> proxy-maintainers, but that's a good question; one that maybe p-m should
> make on its own before we aim for a global, concrete policy.

yes, i was talking about maintainer-bug and not about dev-away practice.
The Maintainer Bug is referred here:
https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Bugs_and_Maintainership_Requests#Maintainer_Bug

> 
> I think the requirement for contact is all we should really settle on
> formally; the rest being handled in wetware where it belongs. :)

sure keeping in contact can be good but not in all case always plausible.

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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Stabilisation procedure

[Alice Ferrazzi]

On Sat, Nov 19, 2016 at 12:55:09AM -0800, Daniel Campbell wrote:
> On 11/17/2016 01:07 PM, Robin H. Johnson wrote:
> > On Thu, Nov 17, 2016 at 03:05:41PM +0100, Kristian Fiskerstrand wrote:
> >>> Isn't it implied that any stabilisation is approved by the maintainer?
> >>> Has it ever been acceptable to go around stabilising random packages?
> >>>
> >>
> >> Explicit > Implicit when we're updating things anyways.
> >>
> >> There are scenarios where e.g Security is calling for stabilization ,
> >> I'll add some info to the draft security GLEP with some requirements for
> >> when this can happen without maintainer involvement as well..
> >>
> >> Ultimately maintainer is responsible for the state of the stable tree
> >> for the packages they maintain and should be taking proactive steps for
> >> this also for security bugs, it doesn't "always" happen like that.
> > 
> > The interaction of this proposal and the prior discussion of allow
> > maintainers to document the maintenance policy of given packages is
> > where it would really come into play.
> > 
> > Using two packages for examples:
> > app-admin/diradm: I am the upstream author as well as the package
> > maintainer. I care about it being marked stable. I'd prefer the normal
> > policy of other people asking me (with timeout) before touching it.
> > 
> > app-admin/cancd: It's a very obscure package that I put in the tree
> > because I needed it, but I haven't personally used it in many years. 
> > I fix the packaging if it's broken only.
> > I'm inclined to mark it with 'anybody-may-bump/fix/stabilize'.
> > 
> Agreed. For most of my packages, I really don't mind since we're all
> working on Gentoo together, but it'd be super helpful if I was simply
> notified in the event that a package I maintain has gotten a security
> bump, patch, or stabilization. Sure, 'git log' and 'git blame' can
> explain a few things, but if I was going to edit a package, I have the
> maintainer's e-mail available right there in metadata.xml. To me it's a
> courtesy that should be a requirement by default, while devs that don't
> care can use whatever means we agree upon to indicate that they don't care.
> 
> This creates a "contact first" practice, which it seems we want to
> encourage. If someone isn't responsive and/or away, that complicates
> things, but if it's a security concern or the last blocker in a big
> stabilization effort (looking at you, tcl 8.6...), then it makes sense
> to just go ahead and make the bumps necessary.

What about maintainers that are away without writing it in their
maintainer bug ?
After how many days of no replay can be fair to touch their package ?

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





signature.asc
Description: PGP signature

Re: [gentoo-dev] Packages up for grabs

[Alice Ferrazzi]

interested in euscan
I'm using it in one of my server.
but I'm away untill 14 of this month.

2016/08/07 18:27 "Patrick Lauer" :

> On 08/07/2016 10:12 AM, Dirkjan Ochtman wrote:
> > On Sun, Aug 7, 2016 at 9:51 AM, Pacho Ramos  wrote:
> >> This packages are now up for grabs:
> >> app-portage/euscan
> >
> > Patrick,
> >
> > Are you still keeping euscan running?
> >
>
> Yes. It's not in the best shape, but for now it works well enough to
> keep it around.
>
>
>

Re: [gentoo-dev] git.gentoo.org/git.overlays.gentoo.org upgrades, 2014/12/24 2014/12/26: gitolite upgrade done

[Alice Ferrazzi]

thanks for updating gitolite :)

On Sun, Dec 28, 2014 at 12:36 PM, Robin H. Johnson robb...@gentoo.org wrote:
 On Wed, Dec 24, 2014 at 01:48:03AM +, Robin H. Johnson wrote:
 I'm going to be doing some upgrades of Gitolite on our Git services,
 it'll be split between Dec 24th and Dec 26th.

 Watch #gentoo-dev IRC topic for a more live report of times, but I
 expect the outage portions to be under 45 minutes collectively.
 This is completed now, however please keep an eye out for breakages and
 unexpected output when the hooks run after commits...

 We are now running gitolite-gentoo-3.6.2.1, a huge jump from our prior
 2.3.3.

 File a bug if you see anything weird, and ping me in IRC (#gentoo-dev)
 if you think it's urgent.

 I'd like to thank the following, and I suspect I've forgotten at least
 one person who's name isn't coming to mind:
 idl0r
 perfinion
 mgorny

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



-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Gentoo Euscan: http://goo.gl/YNbU3h
Mail: Alice Ferrazzi alice.ferra...@gmail.com
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-dev] Packages up for grabs

[Alice Ferrazzi]

i'm interested on sys-apps/epoch, if no one takes it

On Fri, Nov 14, 2014 at 12:16 PM, Tom Wijsman tom...@gentoo.org wrote:
 Hello all

 Due to lack of time I'm giving up some packages. Feel free to take them:

 app-admin/ec2-ami-tools
 app-admin/ec2-api-tools
 These command-line tools serve as the client interface
 to the Amazon EC2 web service

 app-admin/logmon
 Split-screen terminal/ncurses based log viewer

 app-admin/usermin
 A web-based user administration interface

 app-admin/yaala
 Yet Another Log Analyzer

 app-editors/retext
 A Qt-based text editor for Markdown and reStructuredText

 app-misc/fslint
 A utility to find various forms of lint on a filesystem

 app-text/logmerge
 Merge multiple logs such that multilined entries appear
 in chronological order without breaks

 dev-games/aseprite
 Animated sprite editor and pixel art tool

 dev-python/markups
 A wrapper around various text markups

 dev-util/cdiff
 Colored, side-by-side diff terminal viewer

 dev-util/oprofile
 A transparent low-overhead system-wide profiler

 media-libs/libmkv
 Lightweight Matroska muxer written for
 HandBrake

 media-sound/teamspeak-client-bin
 media-sound/teamspeak-server-bin
 TeamSpeak Client / Server (Voice Communication Software)

 media-video/openshot
 Free, open-source, non-linear video editor to create
 and edit videos and movies

 sys-apps/epoch
 An init system (analogous to systemd or upstart) for
 Linux by Subsentient; it is intended as a lightweight
 solution for lightweight distributions that don't want
 a huge mess just to boot up; it has one unified
 configuration file, is very small in size, and it has
 no external dependencies besides glibc or similar;
 installing a shell for /bin/sh is strongly recommended

 sys-process/ftop
 Monitor open files and filesystems

 www-misc/monitorix
 A lightweight system monitoring tool

 x11-misc/growl-for-linux
 A Linux-compatible version of Growl, a notification
 system for Mac OS X


 Thanks,

 Tom Wijsman




-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Gentoo Euscan: http://goo.gl/JUVyTN
Mail: Alice Ferrazzi alice.ferra...@gmail.com
PGP: 0EE4 555E 3AAC B4A4 798D 9AC5 8E31 1808 C553 2D33

Re: [gentoo-dev] help needed: net-irc/weechat

[Alice Ferrazzi]

i use weechat everyday :)
glad to help

On Wed, Nov 12, 2014 at 8:31 PM, Andreas K. Huettel
dilfri...@gentoo.org wrote:
 [Sending this out for scarabeus since the gmail conspiracy is keeping him from
 posting to the -dev mailing list...]


 Hello people,

 I stopped using weechat and it is slowly piling bugs, so if someone wants to
 take over, it would be lovely.

 net-irc/weechat

 Thanks

 Tom

 --
 Andreas K. Huettel
 Gentoo Linux developer
 kde, council





-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Gentoo Euscan: http://goo.gl/JUVyTN
Mail: Alice Ferrazzi alice.ferra...@gmail.com
PGP: 0EE4 555E 3AAC B4A4 798D 9AC5 8E31 1808 C553 2D33

Re: [gentoo-dev] stepping out

[Alice Ferrazzi]

* games-simulation/corsix-th
development is active in upstream, has quite a few Gentoo users.

oh corsix-th. i played at theme hospital and i would like to try
corsix-th with time permitting :O
i liked bullfrog games.


* dev-embedded/arduino
does not need introduction

i'm bit interested in this.

-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Gentoo Euscan: http://goo.gl/JUVyTN
Mail: Alice Ferrazzi alice.ferra...@gmail.com
PGP: 0EE4 555E 3AAC B4A4 798D 9AC5 8E31 1808 C553 2D33

Re: [gentoo-dev] Packages up for grabs

[Alice Ferrazzi]

 There are a list of packages up for grabs. I cannnot test anymore some of
 them, or i stopped use them.

 app-text/fbreader
 dev-libs/liblinebreak
 net-wireless/madwimax
 net-wireless/wimax-tools
 net-wireless/wimax
 net-wireless/wpa_supplicant
 sys-fs/ocfs2-tools
 www-apps/owncloud
 www-apps/rutorrent

i will like to take
net-wireless/wpa_supplicant
-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Mail: Alice Ferrazzi alice.ferra...@gmail.com
PGP: 0EE4 555E 3AAC B4A4 798D 9AC5 8E31 1808 C553 2D33

Re: [gentoo-dev] Packages up for grabs

[Alice Ferrazzi]

There are still other Gentoo Developers listed in some of them, for
example owncloud and wpa_supplicant; are they really up for grabs?

About the package, i use manly only wpa_supplicant for connecting so i
would like to help give support if there is the necessity but as Tom
Wijsman said there is already 2 maintainer.

 You're listed in metadata.xml of 8 packages already, as proxy. Have you 
 considered trying
 to find a mentor and becoming a full developer?

I'm interested in becoming full developer.

On Mon, Apr 14, 2014 at 6:12 PM, Panagiotis Christopoulos
pchr...@gentoo.org wrote:
 On 17:35 Mon 14 Apr , Alice Ferrazzi wrote:
 ...
 i will like to take
 net-wireless/wpa_supplicant

 You're listed in metadata.xml of 8 packages already, as proxy. Have you 
 considered trying
 to find a mentor and becoming a full developer?

 --
 Panagiotis Christopoulos ( pchrist )
 ( Gentoo Lisp Project )



-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Mail: Alice Ferrazzi alice.ferra...@gmail.com
PGP: 0EE4 555E 3AAC B4A4 798D 9AC5 8E31 1808 C553 2D33

Re: [gentoo-dev] Packages up for grabs

[Alice Ferrazzi]

I can help in:
net-analyzer/sbd (the upstream website looks down)
dev-db/opendbx
app-crypt/sign
net-misc/shmux
app-benchmarks/tiobench


On Wed, Mar 12, 2014 at 5:20 AM, Tim Harder radher...@gentoo.org wrote:
 On 2014-03-11 13:10, Pacho Ramos wrote:
 app-arch/snappy

 I can help with this.

 dev-python/snappy

 This can go to me/python.

 - Tim



-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Mail: Alice Ferrazzi alice.ferra...@gmail.com
PGP: 0EE4 555E 3AAC B4A4 798D 9AC5 8E31 1808 C553 2D33

Re: [gentoo-dev] Python project is looking for a new PyPy maintainer/hacker

[Alice Ferrazzi]

I'm interested in helping out,
I usually use PyPy and im good at python coding.
I'm not sure about PyPy code but i will check as fast as i can.

On Tue, Jan 7, 2014 at 3:36 AM, Michał Górny mgo...@gentoo.org wrote:
 Hello, all.

 We've been slacking for some time and we're two versions of PyPy behind
 already. Therefore, I've opened a staffing need [1] for a new PyPy
 package maintainer and hacker.

 We specifically need someone who knows the basics of Python ecosystem
 and is able to hack on PyPy's code. The work involves:

 - checking our existing patchset and updating it for future versions
   of PyPy,

 - hacking PyPy to be compatible with common Python install layout
   as outlined in bug #465546 [2],

 - updating PyPy ebuilds and building binary packages [3].

 We will offer all help we can. We can help with ebuild-related issues
 and understanding of Python ecosystem in Gentoo. We can provide
 some infrastructure to build PyPy if that is necessary.

 However, we don't know the PyPy internals, so that's what the candidate
 will need to face alone. Hopefully, it will be just a one-time effort.

 If you are interested in helping out, please contact us at
 #gentoo-python (freenode) or pyt...@gentoo.org. We appreciate all
 the help you can give us.

 [1]:https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs/PyPy_hacker
 [2]:https://bugs.gentoo.org/show_bug.cgi?id=465546
 [3]:https://bugs.gentoo.org/show_bug.cgi?id=479832

 --
 Best regards,
 Michał Górny



-- 

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Mail: Alice Ferrazzi alice.ferra...@gmail.com
PGP: 0EE4 555E 3AAC B4A4 798D 9AC5 8E31 1808 C553 2D33

Re: [gentoo-dev] Packages up for grabs

[Alice Ferrazzi]

i want to grab the following:

www-apps/ikiwiki


On Tue, Dec 24, 2013 at 3:11 AM, Pavlos Ratis daster...@gentoo.org wrote:

 I want to grab the following:

 dev-vcs/vcsh
 dev-vcs/mr
 app-admin/cronolog
 app-emulation/ganeti-instance-image

 If there isn't any objection, I'll add myself as maintainer.




-- 


--
Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Mail: Alice Ferrazzi alice.ferra...@gmail.com
PGP: 0EE4 555E 3AAC B4A4 798D 9AC5 8E31 1808 C553 2D33

Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?

[Alice Ferrazzi]

On Sun, Dec 15, 2013 at 2:19 AM, Michael Orlitzky m...@gentoo.org wrote:
   rc-update del vixie-cron default
   /etc/init.d/vixie-cron stop
   emerge -C vixie-cron
   emerge cronie
   rc-update add cronie default
   /etc/init.d/cronie start

I Just did the same, is simple and drop-in

-- 

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Mail: Alice Ferrazzi alice.ferra...@gmail.com
PGP: 0EE4 555E 3AAC B4A4 798D 9AC5 8E31 1808 C553 2D33

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Alice Ferrazzi]

I can help on dev-vcs/git ?
On Oct 31, 2013 8:31 AM, Robin H. Johnson robb...@gentoo.org wrote:

 On Wed, Oct 30, 2013 at 06:27:17PM -0500, Matthew Thode wrote:
  dev-libs/libmemcache  #ok
  dev-libs/libmemcached #so
  dev-vcs/git   #I will need help with this 600+ line ebuild...
 On that middle list, I suggest adding yourself, not replacing me.

  net-misc/ifenslave#I'll take it
 Long-term should probably be removed, replaced by sysfs+iproute2; still
 useful on embedded for now.

  net-misc/memcached#And this
  sys-auth/nss_ldap #and this
 You get pam_ldap as well, partial common codebase upstream.

  sys-block/fio #...
  sys-power/nut #wellnow
 Don't break em ;-).

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

Re: [gentoo-dev] Gentoo Scire project - plans?

[Alice Ferrazzi]

This project seems so interesting, if is possible i also would like to join.
On Tue, 2013-10-29 at 17:15 +0400, Sergey Popov wrote:
 Hello, i just want to raise question: should we add deprecation on
 project page of Scire[1] or even remove this project entirely? Cause
 project seems slightly abandonded, leader(agaffney) is in progress of
 retiring[2], other project member(blackace) has no commit access to
tree[3].

 CCing all interested parties

 [1] - http://www.gentoo.org/proj/en/scire/
 [2] - https://bugs.gentoo.org/show_bug.cgi?id=68900
 [3] - https://bugs.gentoo.org/show_bug.cgi?id=45816


I'll join.  Although I do have too many projects on my plate in some
ways.  I've always thought it would fairly easy to add another backend
interface to porthole capable of interfacing with remote machines or
groups of machines.  It is something I'd like to add.

It also goes with a plan to add an extension to eclean to get remote pkg
lists from machines for consideration doing distfiles and binpkg
cleaning.

C'mon, there has to be more people interested in this...
--
Brian Dolbec dol...@gentoo.org