Re: [gentoo-dev] RFC: packages.g.o: new features available

2020-07-08 Thread Mike Pagano
On Tuesday, July 7, 2020 10:57:57 PM EDT Max Magorsch wrote:
> Hi all,
> 
> I am glad to announce further progress at packages.gentoo.org (pgo in
> the following). Compared to previous work during the last months,
> which mostly addressed the back end, the new changes are rather
> comprehensive. That's why I am looking forward to feedback here.
> 
> So the tl;dr is that the new pgo version now displays:
>   - dependencies
>   - reverse dependencies
>   - pkgcheck results
>   - repology.org data
>   - github pull requests
>   - stabilization bugs
>   - keywording bugs
>   - security bugs
>   - general bugs
> for each package.
> 
> Additionally, there are new sites for all package maintainers, that is:
>   - Gentoo Projects (e.g. pyt...@gentoo.org)
>   - Gentoo Developers  (e.g. la...@gentoo.org
>   - Proxied Maintainers (e.g. la...@the-cow.de)
> 
> The maintainer's sites contain:
>   - all packages of the maintainer
>   - all outdated packages (according to repology)
>   - all related pull requests
>   - all related bugs (general, keywording and stabilization)
>   - all security bugs
>   - the changelog of all maintained packages
> You will find the new sites under the 'Maintainers' tab.
> 
> The overall appearance of the site has also slightly changed to
> display all of the new information.
> 
> Currently, the new version is deployed to:
> 
>   https://packagestest.gentoo.org/
> 
> Everyone is welcome to take a look around and tell me whether you
> consider the new information as useful for your workflow and/or what
> you would still change.
> 
> I'm looking forward to your feedback.
> 
> -M

Very, very cool.

How is this sorted?

https://packagestest.gentoo.org/packages/search?q=ker...@gentoo.org








Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

2020-02-13 Thread Mike Pagano
On Thu, Feb 13, 2020 at 06:46:43PM +1100, Sam Jorna (wraeth) wrote:
> On Thursday, 13 February 2020 5:40:46 AM AEDT Matt Turner wrote:
> > On Wed, Feb 12, 2020 at 9:59 AM William Hubbs  wrote:
> > > On Wed, Feb 12, 2020 at 06:54:19PM +1100, Sam Jorna (wraeth) wrote:
> > > > On Monday, 10 February 2020 7:55:01 AM AEDT Michał Górny wrote:
> > > > > On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote:
> > > > > > Hrm, pardon my ignorance, but do 'we' really need to review 232
> > > > > > lines of
> > > > > > Manifest?!
> > > > > 
> > > > > Pardon mine but do 'we' really need to read your useless comments
> > > > > everywhere, all the time and just get irritated for no benefit to
> > > > > Gentoo?
> > > > 
> > > > Perhaps I'm the one being ignorant here, but why are we lambasting
> > > > someone for seeking clarification about an unusual inclusion on a
> > > > review thread?> 
> > > I wasn't going to say anything, but I can't let this go by without
> > > commenting.
> > > 
> > > Sam is correct. Maybe the tone is a bit off, (and that is debatable),
> > > but this definitely can be seen as a legit question, regardless of other
> > > things Michael has posted.
> > 
> > Unfortunately it's not about a single issue or email. It's a
> > consistent pattern that multiple people have asked him to rein in over
> > a long period. :(
> 
> Without going into specifics, veremit and I have certainly had our 
> 'differences 
> of opinion' in the past; but I don't believe this is one of those occasions.
> 
> Calling out bad actors (not saying veremit is one, I just mean in the general 
> sense) is an unfortunate but important task, but call them out on bad 
> behaviour, not for what appears to be an impassioned but otherwise 
> unremarkable query.
> 

I agree with this 100 percent.  Not judging solely on the content of the
specific email in the thread does not allow people to grow and improve. Are we 
all to be judged on our past behavior forever with no chance to overcome past
transgressions ?



> -- 
> Sam Jorna (wraeth)
> GnuPG ID: 0xD6180C26
> 



-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index



Re: [gentoo-dev] Last rites: sys-firmware/iwl6050-ucode

2020-02-07 Thread Mike Pagano
On Fri, Feb 07, 2020 at 12:10:38PM -0500, Mike Pagano wrote:
> # Mike Pagano  (2020-02-07)
> # The standalone ebuild for this driver is made
> # unnecessary as it is included in the package:
> # sys-kernel/linux-firmware
> sys-firmware/iwl6050-ucode

Bug #708622



> -- 
> Mike Pagano
> Gentoo Developer - Kernel Project
> Gentoo Sources - Member
> E-Mail : mpag...@gentoo.org
> GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
> Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index
> 

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index



[gentoo-dev] Last rites: sys-firmware/iwl6050-ucode

2020-02-07 Thread Mike Pagano
# Mike Pagano  (2020-02-07)
# The standalone ebuild for this driver is made
# unnecessary as it is included in the package:
# sys-kernel/linux-firmware
sys-firmware/iwl6050-ucode

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index



Re: [gentoo-dev] Keywordreqs and slacking arch teams

2020-01-02 Thread Mike Pagano
On Thursday, January 2, 2020 3:32:12 PM EST Rolf Eike Beer wrote:
> > - Allowed a simple "Add keyword(s)  for package " interface,
> > 
> >   that intelligently created an issue and a target list, and then once
> >   the list was built, constantly ensured the list to be valid, or
> >   determined automatically when sub-work was completed and reducing the
> >   published list automatically, and then responded to potential issues
> >   based on changes in git, ( as opposed to being only triggered when
> >   the bug was touched )
> 
> As someone who does both keywordings and stabilizations regularly on hppa
> and sparc I think I must share a bit of my experiences:



hppa is making us keep old kernels around [1].  Should the kernel team be 
doing more to get your attention then CC'ing hppa on all of the kernel 
STABLEREQ bugs [2]?

[1] https://packages.gentoo.org/packages/sys-kernel/gentoo-sources
[2] https://bugs.gentoo.org/700416

Mike


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Support move of genpatches tarballs from /space/distfiles-local to devspace

2019-10-11 Thread Mike Pagano
On Fri, Oct 11, 2019 at 11:28:48AM -0700, Alec Warner wrote:
>On Thu, Oct 10, 2019 at 3:04 AM Mike Pagano <[1]mpag...@gentoo.org>
>wrote:
> 
>  On Wed, Oct 09, 2019 at 06:23:06PM -0700, Alec Warner wrote:
>  >Â  Â  On Wed, Oct 9, 2019 at 10:01 AM Mike Pagano
>  <[1][2]mpag...@gentoo.org>
>  >Â  Â  wrote:
>  >
>  >Â  Â  Â  This change will support moving the genpatches tarballs
>  from
>  >Â  Â  Â  /space/distfiles-local to
>  >Â  Â  Â  the devspace ~developer/public_html/dist/genpatches
>  >
>  >Â  Â  I think it would help if you discussed why we were making
>  this change.
>  >Â  Â  (I mean I can guess why, but it's not obvious.)
>  >Â  Â  -A
>  >Â  Â  Ä
>  I was informed that use of /space/distfiles-local is deprecated in
>  favor
>  of devspace.
>  [3]https://devmanual.gentoo.org/general-concepts/mirrors/index.html
> 
>That policy was made in 2011; so clearly it's not super urgent nor
>stringently applied. Which is to say, I'm not sure it needs to be a
>policy.
>-A
>Â

Sounds like maybe a separate thread you can start to debate the policy.
I was called out by infra on IRC to do this, so I did it.

I have no horse in this race.




> 
>  >
>  >Â  Â  Â  Signed-off-by: Mike Pagano <[2][4]mpag...@gentoo.org>
>  >Â  Â  Â  ---
>  >Â  Â  Â  Ä eclass/kernel-2.eclass | 4 +++-
>  >Â  Â  Â  Ä 1 file changed, 3 insertions(+), 1 deletion(-)
>  >Â  Â  Â  diff --git a/eclass/kernel-2.eclass
>  b/eclass/kernel-2.eclass
>  >Â  Â  Â  index c5f35cd3e..0bc4f35de 100644
>  >Â  Â  Â  --- a/eclass/kernel-2.eclass
>  >Â  Â  Â  +++ b/eclass/kernel-2.eclass
>  >Â  Â  Â  @@ -295,7 +295,9 @@ handle_genpatches() {
>  >Â  Â  Â  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ
>  UNIPATCH_LIST_GENPATCHES+="
>  >Â  Â  Â  ${DISTDIR}/${tarball}"
>  >Â  Â  Â  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ
>  debug-print "genpatches tarball:
>  >Â  Â  Â  $tarball"
>  >Â  Â  Â  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  fi
>  >Â  Â  Â  -ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  Ä GENPATCHES_URI+="
>  >Â  Â  Â
>  ${use_cond_start}mirror://gentoo/${tarball}${use_cond_end}"
>  >Â  Â  Â  +ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  Ä GENPATCHES_URI+="
>  >Â  Â  Â
>  ${use_cond_start}[3][5]https://dev.gentoo.org/~mpagano/dist/genpatch
>  es/
>  >Â  Â  Â  ${tarball}${use_cond_end}
>  >Â  Â  Â  +ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  Ä
>  >Â  Â  Â  Ä
>  ${use_cond_start}[4][6]https://dev.gentoo.org/~whissi/dist/genpatche
>  s
>  >Â  Â  Â  /${tarball}${use_cond_end}
>  >Â  Â  Â  +ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  ÄÂ  Ä
>  >Â  Â  Â  Ä
>  ${use_cond_start}[5][7]https://dev.gentoo.org/~alicef/dist/genpatche
>  s
>  >Â  Â  Â  /${tarball}${use_cond_end}"
>  >Â  Â  Â  ÄÂ  ÄÂ  ÄÂ  ÄÂ  done
>  >Â  Â  Â  Ä }
>  >Â  Â  Â  --
>  >Â  Â  Â  2.21.0
>  >Â  Â  Â  --
>  >Â  Â  Â  Mike Pagano
>  >Â  Â  Â  Gentoo Developer - Kernel Project
>  >Â  Â  Â  Gentoo Sources - Member
>  >Â  Â  Â  E-MailÄÂ  ÄÂ  Ä : [6][8]mpag...@gentoo.org
>  >Â  Â  Â  GnuPG FPÄÂ  Ä : EEE2 601D 0763 B60F 848CÄÂ  9E14 3C33 C650
>  B576 E4E3
>  >Â  Â  Â  Public Key :
>  >Â  Â  Â
>  [7][9]http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index
>  >
>  > References
>  >
>  >Â  Â  1. mailto:[10]mpag...@gentoo.org
>  >Â  Â  2. mailto:[11]mpag...@gentoo.org
>  >Â  Â  3.
>  [12]https://dev.gentoo.org/~mpagano/dist/genpatches/${tarball}${use_
>  cond_end}
>  >Â  Â  4.
>  [13]https://dev.gentoo.org/~whissi/dist/genpatches/${tarball}${use_c
>  ond_end}
>  >Â  Â  5.
>  [14]https://dev.gentoo.org/~alicef/dist/genpatches/${tarball}${use_c
>  ond_end}
>  >Â  Â  6. mailto:[15]mpag...@gentoo.org
>  >Â  Â  7.
>  [16]http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index
>  --
>  Mike Pagano
>  Gentoo Developer - Kernel Project
>  Gentoo Sources - Member
>  E-Mail     : [17]mpag...@gentoo.org
>  GnuPG FPÂ  Â : EEE2 601D 0763 B60F 848CÂ  9E14 3C33 C650 B576 E4E3
>  Public Key :
>  [18]http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index
> 
> References
> 
>1. mailto:mpag...@gentoo.org
>2. mailto:mpag...@gentoo.org
>3. https://devmanual.gentoo.org/general-concepts/mirr

Re: [gentoo-dev] [PATCH v4 1/1] kernel-2.eclass: Support move of genpatches tarballs from /space/distfiles-local to devspace

2019-10-10 Thread Mike Pagano
This change will support moving the genpatches tarballs from 
/space/distfiles-local to
the devspace ~developer/public_html/dist/genpatches.

Additional modifications based on feedback.

Signed-off-by: Mike Pagano 
---
 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 c5f35cd3e..42307b963 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -295,7 +295,7 @@ handle_genpatches() {
  UNIPATCH_LIST_GENPATCHES+=" ${DISTDIR}/${tarball}"
  debug-print "genpatches tarball: $tarball"
fi
-   GENPATCHES_URI+=" 
${use_cond_start}mirror://gentoo/${tarball}${use_cond_end}"
+   GENPATCHES_URI+=" ${use_cond_start}$(echo 
https://dev.gentoo.org/\~{mpagano,whissi}/dist/genpatches/${tarball})${use_cond_end}"
  done
 }

-- 
2.21.0

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index



Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Support move of genpatches tarballs from /space/distfiles-local to devspace

2019-10-10 Thread Mike Pagano
On Wed, Oct 09, 2019 at 06:23:06PM -0700, Alec Warner wrote:
>On Wed, Oct 9, 2019 at 10:01 AM Mike Pagano <[1]mpag...@gentoo.org>
>wrote:
> 
>  This change will support moving the genpatches tarballs from
>  /space/distfiles-local to
>  the devspace ~developer/public_html/dist/genpatches
> 
>I think it would help if you discussed why we were making this change.
>(I mean I can guess why, but it's not obvious.)
>-A
>Â

I was informed that use of /space/distfiles-local is deprecated in favor
of devspace.


https://devmanual.gentoo.org/general-concepts/mirrors/index.html





> 
>  Signed-off-by: Mike Pagano <[2]mpag...@gentoo.org>
>  ---
>  Â eclass/kernel-2.eclass | 4 +++-
>  Â 1 file changed, 3 insertions(+), 1 deletion(-)
>  diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
>  index c5f35cd3e..0bc4f35de 100644
>  --- a/eclass/kernel-2.eclass
>  +++ b/eclass/kernel-2.eclass
>  @@ -295,7 +295,9 @@ handle_genpatches() {
>  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  UNIPATCH_LIST_GENPATCHES+="
>  ${DISTDIR}/${tarball}"
>  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  debug-print "genpatches tarball:
>  $tarball"
>  Â  Â  Â  Â  Â  Â  Â  Â  fi
>  -Â  Â  Â  Â  Â  Â  Â  Â GENPATCHES_URI+="
>  ${use_cond_start}mirror://gentoo/${tarball}${use_cond_end}"
>  +Â  Â  Â  Â  Â  Â  Â  Â GENPATCHES_URI+="
>  ${use_cond_start}[3]https://dev.gentoo.org/~mpagano/dist/genpatches/
>  ${tarball}${use_cond_end}
>  +Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â
>  Â ${use_cond_start}[4]https://dev.gentoo.org/~whissi/dist/genpatches
>  /${tarball}${use_cond_end}
>  +Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â
>  Â ${use_cond_start}[5]https://dev.gentoo.org/~alicef/dist/genpatches
>  /${tarball}${use_cond_end}"
>  Â  Â  Â  Â  done
>  Â }
>  --
>  2.21.0
>  --
>  Mike Pagano
>  Gentoo Developer - Kernel Project
>  Gentoo Sources - Member
>  E-Mail     : [6]mpag...@gentoo.org
>  GnuPG FPÂ  Â : EEE2 601D 0763 B60F 848CÂ  9E14 3C33 C650 B576 E4E3
>  Public Key :
>  [7]http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index
> 
> References
> 
>1. mailto:mpag...@gentoo.org
>2. mailto:mpag...@gentoo.org
>3. 
> https://dev.gentoo.org/~mpagano/dist/genpatches/${tarball}${use_cond_end}
>4. https://dev.gentoo.org/~whissi/dist/genpatches/${tarball}${use_cond_end}
>5. https://dev.gentoo.org/~alicef/dist/genpatches/${tarball}${use_cond_end}
>6. mailto:mpag...@gentoo.org
>7. http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index



Re: [gentoo-dev] [PATCH v3 1/1] kernel-2.eclass: Support move of genpatches tarballs from /space/distfiles-local to devspace

2019-10-09 Thread Mike Pagano
This change will support moving the genpatches tarballs from 
/space/distfiles-local to
the devspace ~developer/public_html/dist/genpatches.

Co-authored-by: Thomas Deutschmann 

Signed-off-by: Mike Pagano 
---
 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 c5f35cd3e..62e6c23e1 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -295,7 +295,7 @@ handle_genpatches() {
  UNIPATCH_LIST_GENPATCHES+=" ${DISTDIR}/${tarball}"
  debug-print "genpatches tarball: $tarball"
fi
-   GENPATCHES_URI+=" 
${use_cond_start}mirror://gentoo/${tarball}${use_cond_end}"
+   GENPATCHES_URI+=" ${use_cond_start}$(echo 
https://dev.gentoo.org/~{mpagano,whissi}/dist/genpatches/${tarball})${use_cond_end}"
  done
 }

-- 
2.21.0

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index



Re: [gentoo-dev] [PATCH v2 1/1] kernel-2.eclass: Support move of genpatches tarballs from /space/distfiles-local to devspace

2019-10-09 Thread Mike Pagano
Thanks for the suggestion. This is version 2

This change will support moving the genpatches tarballs from 
/space/distfiles-local to
the devspace ~developer/public_html/dist/genpatches.


Signed-off-by: Mike Pagano 
---
 eclass/kernel-2.eclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index c5f35cd3e..4b861beec 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -295,7 +295,9 @@ handle_genpatches() {
UNIPATCH_LIST_GENPATCHES+=" ${DISTDIR}/${tarball}"
debug-print "genpatches tarball: $tarball"
fi
-   GENPATCHES_URI+=" 
${use_cond_start}mirror://gentoo/${tarball}${use_cond_end}"
+   GENPATCHES_URI+=" 
${use_cond_start}https://dev.gentoo.org/~mpagano/dist/genpatches/${tarball}
+   
https://dev.gentoo.org/~whissi/dist/genpatches/${tarball}
+   
https://dev.gentoo.org/~alicef/dist/genpatches/${tarball}${use_cond_end};
    done
 }

--
2.21.0

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index



[gentoo-dev] [PATCH 1/1] kernel-2.eclass: Support move of genpatches tarballs from /space/distfiles-local to devspace

2019-10-09 Thread Mike Pagano
This change will support moving the genpatches tarballs from 
/space/distfiles-local to
the devspace ~developer/public_html/dist/genpatches

Signed-off-by: Mike Pagano 
---
 eclass/kernel-2.eclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index c5f35cd3e..0bc4f35de 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -295,7 +295,9 @@ handle_genpatches() {
UNIPATCH_LIST_GENPATCHES+=" ${DISTDIR}/${tarball}"
debug-print "genpatches tarball: $tarball"
fi
-   GENPATCHES_URI+=" 
${use_cond_start}mirror://gentoo/${tarball}${use_cond_end}"
+   GENPATCHES_URI+=" 
${use_cond_start}https://dev.gentoo.org/~mpagano/dist/genpatches/${tarball}${use_cond_end}
 
+   
${use_cond_start}https://dev.gentoo.org/~whissi/dist/genpatches/${tarball}${use_cond_end}
 
+   
${use_cond_start}https://dev.gentoo.org/~alicef/dist/genpatches/${tarball}${use_cond_end};
    done
 }
 
-- 
2.21.0

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index



Re: [gentoo-dev] GLEP 66 [git workflow] for another review round

2017-10-11 Thread Mike Pagano
On 10/11/2017 05:19 PM, Michał Górny wrote:
> Hi,

snip

>   - ``Reported-by: Full Name <em...@example.com>`` — usually indicates
> full review,

snip

Hi,

Is that was Reported-by usually indicates? I use it as upstream kernel and even 
github indicates, and thought this was the more common and documented use.

kernel[1] : 
"The Reported-by tag gives credit to people who find bugs and report them and 
it hopefully inspires them to help us again in the future. "

github[2]
"Reported-by:" is used to credit someone who found the bug that the patch 
attempts to fix.

[1] https://www.kernel.org/doc/html/v4.12/process/submitting-patches.html
[2] https://github.com/git/git/blob/master/Documentation/SubmittingPatches

Mike

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources
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




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH v3] eclass/kernel-2.eclass: Remove use of tr in global scope

2017-09-06 Thread Mike Pagano
This time, use bash 4.0, but limit the use of this function to ebuild that have 
EAPI >= 6.
Display a warning for maintainers to upgrade their ebuilds, or remove the call.
Thanks to mgorny for the suggestion.

Signed-off-by: Mike Pagano <mpag...@gentoo.org>
---
 eclass/kernel-2.eclass | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 84909f30c..a80f3e91a 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1407,11 +1407,20 @@ getfilevar() {
 # This function sets ARCH_URI and ARCH_PATCH
 # with the neccessary info for the arch sepecific compatibility
 # patchsets.
+# To use, an ebuild could contain a line like:
+# AMD64_URI=http//linktothearchspecificpatch
+# This function requires EAPI >= 6.
 
 detect_arch() {
 
-   local ALL_ARCH LOOP_ARCH LOOP_ARCH_L COMPAT_URI i TC_ARCH_KERNEL
+   if [[ "${EAPI}" -lt 6 ]]; then 
+   eqawarn "ebuild is attempting to call detect_arch when EAPI < 
6." 
+   eqawarn "This function will not be executed." 
+   return
+   fi
 
+   local ALL_ARCH LOOP_ARCH LOOP_ARCH_L COMPAT_URI i TC_ARCH_KERNEL
+   
# COMPAT_URI is the contents of ${ARCH}_URI
# ARCH_URI is the URI for all the ${ARCH}_URI patches
# ARCH_PATCH is ARCH_URI broken into files for UNIPATCH
@@ -1425,18 +1434,15 @@ detect_arch() {
COMPAT_URI="${LOOP_ARCH}_URI"
COMPAT_URI="${!COMPAT_URI}"
 
-   declare -l LOOP_ARCH_L=${LOOP_ARCH}
-
[[ -n ${COMPAT_URI} ]] && \
-   ARCH_URI="${ARCH_URI} ${LOOP_ARCH_L}? ( ${COMPAT_URI} )"
+   ARCH_URI="${ARCH_URI} ${LOOP_ARCH,,}? ( ${COMPAT_URI} )"
 
-   declare -u TC_ARCH_KERNEL=$(tc-arch-kernel)
-   if [[ ${LOOP_ARCH} == ${TC_ARCH_KERNEL} ]]; then
+   TC_ARCH_KERNEL=$(tc-arch-kernel);
+   if [[ ${LOOP_ARCH} == ${TC_ARCH_KERNEL^^} ]]; then
for i in ${COMPAT_URI}; do
ARCH_PATCH="${ARCH_PATCH} ${DISTDIR}/${i/*\//}"
done
fi
-
done
 }
 
-- 
2.13.5




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH v2] eclass/kernel-2.eclass: Remove use of tr in global scope

2017-08-31 Thread Mike Pagano
On Thu, Aug 31, 2017 at 07:27:10PM +0200, Michał Górny wrote:
> W dniu czw, 31.08.2017 o godzinie 12∶33 -0400, użytkownik Mike Pagano
> napisał:
> > As per PMS remove calls to external command 'tr' in global scope See bug 
> > #629106.
> 
> Closes: https://bugs.gentoo.org/629106
> 
> (assuming you want the bug closed)
> 
> > 

Thanks for the review. Committed.  It seems we are limited by PMS one
way or the other.  If someone has a better idea of doing this simple
lowercase/uppercase change that satisifies PMS at all versions I am
happy to revisit.





[gentoo-dev] [PATCH v2] eclass/kernel-2.eclass: Remove use of tr in global scope

2017-08-31 Thread Mike Pagano
As per PMS remove calls to external command 'tr' in global scope See bug 
#629106.

Signed-off-by: Mike Pagano <mpag...@gentoo.org>
---
 eclass/kernel-2.eclass | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 09409ab1f..205ea93d5 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1410,7 +1410,7 @@ getfilevar() {
 
 detect_arch() {
 
-   local ALL_ARCH LOOP_ARCH COMPAT_URI i
+   local ALL_ARCH LOOP_ARCH LOOP_ARCH_L COMPAT_URI i TC_ARCH_KERNEL
 
# COMPAT_URI is the contents of ${ARCH}_URI
# ARCH_URI is the URI for all the ${ARCH}_URI patches
@@ -1418,20 +1418,25 @@ detect_arch() {
 
ARCH_URI=""
ARCH_PATCH=""
+   TC_ARCH_KERNEL=""
ALL_ARCH="ALPHA AMD64 ARM HPPA IA64 M68K MIPS PPC PPC64 S390 SH SPARC 
X86"
 
for LOOP_ARCH in ${ALL_ARCH}; do
COMPAT_URI="${LOOP_ARCH}_URI"
COMPAT_URI="${!COMPAT_URI}"
 
+   declare -l LOOP_ARCH_L=${LOOP_ARCH}
+
[[ -n ${COMPAT_URI} ]] && \
-   ARCH_URI="${ARCH_URI} $(echo ${LOOP_ARCH} | tr 
'[:upper:]' '[:lower:]')? ( ${COMPAT_URI} )"
+   ARCH_URI="${ARCH_URI} ${LOOP_ARCH_L}? ( ${COMPAT_URI} )"
 
-   if [[ ${LOOP_ARCH} == "$(echo $(tc-arch-kernel) | tr 
'[:lower:]' '[:upper:]')" ]];  then
+   declare -u TC_ARCH_KERNEL=$(tc-arch-kernel); 
+   if [[ ${LOOP_ARCH} == ${TC_ARCH_KERNEL} ]]; then
for i in ${COMPAT_URI}; do
ARCH_PATCH="${ARCH_PATCH} ${DISTDIR}/${i/*\//}"
done
fi
+
done
 }
 
-- 
2.13.5




[gentoo-dev] [PATCH] eclass/kernel-2.eclass: Remove use of tr in global scope

2017-08-30 Thread Mike Pagano
As per PMS remove calls to external command 'tr' in global scope
See bug #629106

Signed-off-by: Mike Pagano <mpag...@gentoo.org>
---
 eclass/kernel-2.eclass | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 09409ab1f..cdc8c4043 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1410,7 +1410,7 @@ getfilevar() {

 detect_arch() {

-   local ALL_ARCH LOOP_ARCH COMPAT_URI i
+   local ALL_ARCH LOOP_ARCH COMPAT_URI TC_ARCH_KERNEL

# COMPAT_URI is the contents of ${ARCH}_URI
# ARCH_URI is the URI for all the ${ARCH}_URI patches
@@ -1418,6 +1418,7 @@ detect_arch() {

ARCH_URI=""
ARCH_PATCH=""
+   TC_ARCH_KERNEL=""
ALL_ARCH="ALPHA AMD64 ARM HPPA IA64 M68K MIPS PPC PPC64 S390 SH SPARC X86"

for LOOP_ARCH in ${ALL_ARCH}; do
@@ -1425,9 +1426,10 @@ detect_arch() {
COMPAT_URI="${!COMPAT_URI}"

[[ -n ${COMPAT_URI} ]] && \
-   ARCH_URI="${ARCH_URI} $(echo ${LOOP_ARCH} | tr '[:upper:]' 
'[:lower:]')? ( ${COMPAT_URI} )"
+   ARCH_URI="${ARCH_URI} ${LOOP_ARCH,,}? ( ${COMPAT_URI} )"

-   if [[ ${LOOP_ARCH} == "$(echo $(tc-arch-kernel) | tr '[:lower:]' 
'[:upper:]')" ]];  then
+   TC_ARCH_KERNEL=$(tc-arch-kernel); 
+   if [[ ${LOOP_ARCH} == ${TC_ARCH_KERNEL^^} ]];   then




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] taking a break from arches stabilization

2017-07-10 Thread Mike Pagano
On Mon, Jul 10, 2017 at 07:22:20PM +0200, Agostino Sarubbo wrote:
> Hi all.
> 
> every time that I attach my tmux session to see what happens on irc, I always 
> see the same discussion about the 'minor' arches status.
> Since I joined gentoo(2011) I worked on all arches except hppa, I put more 
> effort in amd64 and less where I saw other people work on it (arm,alpha)
> But every time the magic phrase is that those arches are unmaintained.
> 
> Now, since I work on these arches just to help, i.e. I don't have any 
> business 
> and I do non have any installation of those arches and the work I'm doing is 
> not appreciated at all I decided to stop for now.
> If your dream is to put sparc and ia64 to ~arch, go ahead, I have no 
> objections.
> I will take a break also from amd64 and x86...let's see how things will 
> change.
> 
> -- 
> Agostino Sarubbo
> Gentoo Linux Developer
> 


Agostino as far as this maintainer is concerned you are totally wrong.
:) 

Its my bad that you have no idea how much I appreciate you stablizing kernels. 
I submit
stablereqs and almost say out loud "Ago, please do your thing".

It's my bad if I've never thanked you but I *do* depend on you.

Thanks for the time you spend on my "stuff".

Mike



-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index



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

2017-05-18 Thread Mike Pagano

On 05/17/2017 07:13 PM, Mike Pagano 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.
> 
> 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
> 

Pushed.

-- 
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




signature.asc
Description: OpenPGP digital signature


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

2017-05-17 Thread Mike Pagano
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.

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
-- 
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




signature.asc
Description: OpenPGP digital signature


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

2017-03-05 Thread Mike Pagano


On 03/02/2017 06:56 AM, Alice Ferrazzi wrote:
> 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
> 


Applied

-- 
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




signature.asc
Description: OpenPGP digital signature


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

2017-03-01 Thread Mike Pagano
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




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Remove DEBLOB support.

2017-02-20 Thread Mike Pagano
On 02/19/2017 12:32 PM, Mike Pagano wrote:
> Upstream does not version patches and every change breaks the manifest
> which
> breaks the tree. This results in a constant chasing of bugs since we can't
> predict the breakage.
> 
> Signed-off-by: Mike Pagano <mpag...@gentoo.org>
> ---
>  eclass/kernel-2.eclass | 102
> +
>  1 file changed, 2 insertions(+), 100 deletions(-)
> 
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> i

I will not be committing this. Maintainers of sys-kernels can decide for
themselves if they want to support deblob. Leaving it in gives them the
option.

-- 
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




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Remove DEBLOB support.

2017-02-19 Thread Mike Pagano


On 02/19/2017 06:03 PM, Mike Gilbert wrote:
> On Sun, Feb 19, 2017 at 12:32 PM, Mike Pagano <mpag...@gentoo.org> wrote:
>> Upstream does not version patches and every change breaks the manifest
>> which
>> breaks the tree. This results in a constant chasing of bugs since we can't
>> predict the breakage.
> 
> Sounds good to me.
> 
>> @@ -1517,17 +1425,11 @@ kernel-2_src_prepare() {
>>  # @FUNCTION: kernel-2_src_compile
>>  # @USAGE:
>>  # @DESCRIPTION:
>> -# conpile headers or run deblob script
>> +# conpile headers
>>
> 
> Is "conpile" an misspelled version of "compile"? Or does it actually
> mean something else?
> 

I can fix that typo before I commit.


-- 
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




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Remove DEBLOB support.

2017-02-19 Thread Mike Pagano


On 02/19/2017 05:55 PM, Andrew Savchenko wrote:
> On Sun, 19 Feb 2017 12:32:26 -0500 Mike Pagano wrote:
>> Upstream does not version patches and every change breaks the manifest
>> which
>> breaks the tree. This results in a constant chasing of bugs since we can't
>> predict the breakage.
> 
> Have you tried to contact upstream and fix this issue there?
> 
> Best regards,
> Andrew Savchenko
> 


Of course..


-- 
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




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 1/1] kernel-2.eclass: Remove DEBLOB support.

2017-02-19 Thread Mike Pagano
Upstream does not version patches and every change breaks the manifest
which
breaks the tree. This results in a constant chasing of bugs since we can't
predict the breakage.

Signed-off-by: Mike Pagano <mpag...@gentoo.org>
---
 eclass/kernel-2.eclass | 102
+
 1 file changed, 2 insertions(+), 100 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 0c9ce04..dcf94f4 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -129,26 +129,6 @@
 # If set, this kernel is unsupported by Gentoo Security
 # to the current eclass maintainer :)

-# @ECLASS-VARIABLE:  K_DEBLOB_AVAILABLE
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# A value of "0" will disable all of the optional deblob
-# code. If empty, will be set to "1" if deblobbing is
-# possible. Test ONLY for "1".
-
-# @ECLASS-VARIABLE:  K_DEBLOB_TAG  
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# This will be the version of deblob script. It's a upstream SVN tag
-# such asw -gnu or -gnu1.
-
-# @ECLASS-VARIABLE:  K_PREDEBLOBBED
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# This kernel was already deblobbed elsewhere.
-# If false, either optional deblobbing will be available
-# or the license will note the inclusion of freedist code.
-
 # @ECLASS-VARIABLE:  K_LONGTERM
 # @DEFAULT_UNSET
 # @DESCRIPTION:
@@ -219,11 +199,6 @@ HOMEPAGE="https://www.kernel.org/
https://www.gentoo.org/ ${HOMEPAGE}"

 has "${EAPI:-0}" 0 1 2 && ED=${D} EPREFIX= EROOT=${ROOT}

-# 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"

@@ -603,59 +578,6 @@ if [[ ${ETYPE} == sources ]]; then
DESCRIPTION="Sources based on the Linux Kernel."
IUSE="symlink build"

-   # 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
-   if [[ ${K_DEBLOB_AVAILABLE} == "1" ]] ; then
-   IUSE="${IUSE} deblob"
-
-   # Reflect that kernels contain firmware blobs unless 
otherwise
-   # stripped
-   LICENSE="${LICENSE} !deblob? ( freedist )"
-
-   DEPEND+=" deblob? ( ${PYTHON_DEPS} )"
-
-   if [[ -n KV_MINOR ]]; then
-   DEBLOB_PV="${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}"
-   else
-   DEBLOB_PV="${KV_MAJOR}.${KV_PATCH}"
-   fi
-
-   if [[ ${KV_MAJOR} -ge 3 ]]; then
-   DEBLOB_PV="${KV_MAJOR}.${KV_MINOR}"
-   fi
-
-   # deblob svn tag, default is -gnu, to change, use 
K_DEBLOB_TAG in ebuild
-   K_DEBLOB_TAG=${K_DEBLOB_TAG:--gnu}
-   DEBLOB_A="deblob-${DEBLOB_PV}"
-   DEBLOB_CHECK_A="deblob-check-${DEBLOB_PV}"
-   
DEBLOB_HOMEPAGE="http://www.fsfla.org/svn/fsfla/software/linux-libre/releases/tags;
-   DEBLOB_URI_PATH="${DEBLOB_PV}${K_DEBLOB_TAG}"
-   if ! has "${EAPI:-0}" 0 1 ; then
-   
DEBLOB_CHECK_URI="${DEBLOB_HOMEPAGE}/${DEBLOB_URI_PATH}/deblob-check ->
${DEBLOB_CHECK_A}"
-   else
-   
DEBLOB_CHECK_URI="mirror://gentoo/${DEBLOB_CHECK_A}"
-   fi
-
-   
DEBLOB_URI="${DEBLOB_HOMEPAGE}/${DEBLOB_URI_PATH}/${DEBLOB_A}"
-   HOMEPAGE="${HOMEPAGE} ${DEBLOB_HOMEPAGE}"
-
-   KERNEL_URI="${KERNEL_URI}
-   deblob? (
-   ${DEBLOB_URI}
-   ${DEBLOB_CHECK_URI}
-   )"
-   else
-   # We have no way to deblob older kernels, so just mark 
them as
-   # tainted with non-libre materials.
-   LICENSE="${LICENSE} freedist"
-   fi
-   fi
-
 elif [[ ${ETYPE} == headers ]]; then
DESCRIPTION=&q

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

2017-02-16 Thread Mike Pagano
On Thu, Feb 16, 2017 at 02:37:15AM +0900, Alice Ferrazzi wrote:
> 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
> 
> 

++

I think I've addressed all EAPI-6 bugs opened against the eclass. 

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index



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

2016-12-28 Thread Mike Pagano
Thank

On 12/27/2016 09:12 PM, Alice Ferrazzi wrote:
> 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.
>>
>> --

Thanks. 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




signature.asc
Description: OpenPGP digital signature


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

2016-12-27 Thread Mike Pagano
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





signature.asc
Description: OpenPGP digital signature


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

2016-12-26 Thread Mike Pagano


On 12/23/2016 11:31 PM, Alice Ferrazzi wrote:
> On Sat, Dec 24, 2016 at 7:43 AM, Mike Pagano <mpag...@gentoo.org> wrote:
>> ChangeLog
> 
> 
> looks good for me :)
> 
Thanks, Alice.

Committed.



signature.asc
Description: OpenPGP digital signature


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

2016-12-23 Thread Mike Pagano
Hi,  this code is no longer relevant and breaks PMS. See bug #566396

---
 eclass/kernel-2.eclass | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 424aa03..520a4c1 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -967,13 +967,6 @@ install_sources() {
done
fi

-   if [[ ! -f ${S}/patches.txt ]]; then
-   # patches.txt is empty so lets use our ChangeLog
-   [[ -f ${FILESDIR}/../ChangeLog ]] && \
-   echo "Please check the ebuild ChangeLog for more details." \
-   > "${S}"/patches.txt
-   fi
-
mv "${WORKDIR}"/linux* "${ED}"usr/src || die

if [[ -n "${UNIPATCH_DOCS}" ]] ; then
-- 
2.10.2



signature.asc
Description: OpenPGP digital signature


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

2016-12-15 Thread Mike Pagano
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




signature.asc
Description: OpenPGP digital signature


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

2016-12-14 Thread Mike Pagano
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.

---
 eclass/kernel-2.eclass | 18 --
 1 file changed, 18 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 2b4f21c..424aa03 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -156,13 +156,6 @@
 # in the long term directories on the upstream servers
 # as the location has been changed by upstream

-# @ECLASS-VARIABLE:  K_KDBUS_AVAILABLE 
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# If set, the ebuild contains the option of installing the
-# kdbus patch.  This patch is not installed without the 'kdbus'
-# and 'experimental' use flags.
-
 # @ECLASS-VARIABLE:  H_SUPPORTEDARCH   
 # @DEFAULT_UNSET
 # @DESCRIPTION:
@@ -610,10 +603,6 @@ if [[ ${ETYPE} == sources ]]; then
DESCRIPTION="Sources based on the Linux Kernel."
IUSE="symlink build"

-   if [[ -n ${K_KDBUS_AVAILABLE} ]]; then
-   IUSE="${IUSE} kdbus"
-   fi
-
# Bug #266157, deblob for libre support
if [[ -z ${K_PREDEBLOBBED} ]] ; then
# Bug #359865, force a call to detect_version if needed
@@ -1246,13 +1235,6 @@ unipatch() {
UNIPATCH_DROP+="
5000_enable-additional-cpu-optimizations-for-gcc.patch"
fi
fi
-
-   # if kdbus use flag is not set, drop the kdbus patch
-if [[ $UNIPATCH_DROP != *"5015_kdbus*.patch"* ]]; then
-   if ! has kdbus ${IUSE} ||  ! use kdbus; then
-   UNIPATCH_DROP="${UNIPATCH_DROP} 
5015_kdbus*.patch"
-   fi
-   fi
fi
done

-- 
2.10.2




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Add required @USAGE documentation to functions.

2016-12-14 Thread Mike Pagano
On 12/12/2016 07:34 PM, Mike Pagano wrote:
> According to (not pms) devmanual, @USAGE is required for functions.
> This patch only touches comments and no code has been modified.


Committed. If the devmanual changes, I can easily remove the empty USAGE
statements.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Add required @USAGE documentation to functions.

2016-12-13 Thread Mike Pagano


On 12/12/2016 09:49 PM, Mike Gilbert wrote:
> On Mon, Dec 12, 2016 at 9:44 PM, Mike Gilbert <flop...@gentoo.org> wrote:
>> On Mon, Dec 12, 2016 at 7:34 PM, Mike Pagano <mpag...@gentoo.org> wrote:
>>> According to PMS, @USAGE is required for functions.
>>> This patch only touches comments and no code has been modified.
>>
>> PMS says nothing on the topic of eclass documentation syntax.
>>
>> Any requirements are imposed by the eclass-manpages awk script.
> 
> Maybe you were referring to the devmanual (not PMS)?
> 
> https://devmanual.gentoo.org/eclass-writing/index.html
> 
> Personally, I don't think it makes sense to add an empty @USAGE entry
> for functions that take no arguments.
> 

You're absolutely right, Mike. It was the devmanual.

I'm not a fan of having an empty usage. As the devmanual is written
today, it is not optional.

I'll leave them in for now, and if the devmanual gets updated, I'll
remove them.

-- 
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




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 1/1] kernel-2.eclass: Add required @USAGE documentation to functions.

2016-12-12 Thread Mike Pagano
According to PMS, @USAGE is required for functions.
This patch only touches comments and no code has been modified.

---
 eclass/kernel-2.eclass | 38 ++
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index b19a396..99449a6 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -128,8 +128,6 @@
 # @DESCRIPTION:
 # If set, this kernel is unsupported by Gentoo Security
 # to the current eclass maintainer :)
-# added functionality:
-# unipatch  - a flexible, singular method to extract, add and
remove patches.

 # @ECLASS-VARIABLE:  K_DEBLOB_AVAILABLE
 # @DEFAULT_UNSET
@@ -241,6 +239,7 @@ RESTRICT="binchecks strip"


 # @FUNCTION: debug-print-kernel2-variables
+# @USAGE:
 # @DESCRIPTION:
 # this function exists only to help debug kernel-2.eclass
 # if you are adding new functionality in, put a call to it
@@ -255,6 +254,7 @@ debug-print-kernel2-variables() {
 }

 # @FUNCTION: handle_genpatches
+# @USAGE: [--set-unipatch-list]
 # @DESCRIPTION:
 # add genpatches to list of patches to apply uf wanted

@@ -312,6 +312,7 @@ handle_genpatches() {
 }

 # @FUNCTION: detect_version
+# @USAGE:
 # @DESCRIPTION:
 # this function will detect and set
 # - OKV: Original Kernel Version (2.6.0/2.6.0-test11)
@@ -543,6 +544,7 @@ detect_version() {
 }

 # @FUNCTION: kernel_is
+# @USAGE: 
 # @DESCRIPTION:
 # user for comparing kernel versions
 # or just identifying a version
@@ -576,6 +578,7 @@ kernel_is() {
 }

 # @FUNCTION: kernel_is_2_4
+# @USAGE:
 # @DESCRIPTION:
 # return true if kernel is version 2.4
 kernel_is_2_4() {
@@ -583,6 +586,7 @@ kernel_is_2_4() {
 }

 # @FUNCTION: kernel_is_2_6
+# @USAGE:
 # @DESCRIPTION:
 # return true if kernel is version 2.6
 kernel_is_2_6() {
@@ -677,6 +681,7 @@ fi
 # Cross-compile support functions

 # @FUNCTION: kernel_header_destdir
+# @USAGE:
 # @DESCRIPTION:
 # return header destination directory
 kernel_header_destdir() {
@@ -686,6 +691,7 @@ kernel_header_destdir() {
 }

 # @FUNCTION: cross_pre_c_headers
+# @USAGE:
 # @DESCRIPTION:
 # set use if neccesary for cross compile support
 cross_pre_c_headers() {
@@ -693,6 +699,7 @@ cross_pre_c_headers() {
 }

 # @FUNCTION: env_setup_xmakeopts
+# @USAGE:
 # @DESCRIPTION:
 # set the ARCH/CROSS_COMPILE when cross compiling

@@ -712,6 +719,7 @@ env_setup_xmakeopts() {
 }

 # @FUNCTION: unpack_2_4
+# @USAGE:
 # @DESCRIPTION:
 # unpack and generate .config for 2.4 kernels

@@ -725,6 +733,7 @@ unpack_2_4() {
 }

 # @FUNCTION: unpack_2_6
+# @USAGE:
 # @DESCRIPTION:
 # unpack and generate .config for 2.6 kernels

@@ -750,6 +759,7 @@ unpack_2_6() {
 }

 # @FUNCTION: universal_unpack
+# @USAGE:
 # @DESCRIPTION:
 # unpack kernel sources

@@ -793,6 +803,7 @@ universal_unpack() {
 }

 # @FUNCTION: unpack_set_extraversion
+# @USAGE:
 # @DESCRIPTION:
 # handle EXTRAVERSION

@@ -803,6 +814,7 @@ unpack_set_extraversion() {
 }

 # @FUNCTION: unpack_fix_install_path
+# @USAGE:
 # @DESCRIPTION:
 # Should be done after patches have been applied
 # Otherwise patches that modify the same area of Makefile will fail
@@ -815,6 +827,7 @@ unpack_fix_install_path() {
 # Compile Functions

 # @FUNCTION: compile_headers
+# @USAGE:
 # @DESCRIPTION:
 # header compilation

@@ -871,6 +884,7 @@ compile_headers() {
 }

 # @FUNCTION: compile_headers_tweak_config
+# @USAGE:
 # @DESCRIPTION:
 # some targets can be very very picky, so let's finesse the
 # .config based upon any info we may have
@@ -890,6 +904,7 @@ compile_headers_tweak_config() {
 # install functions

 # @FUNCTION: install_universal
+# @USAGE:
 # @DESCRIPTION:
 # Fix permissions in tarball

@@ -901,6 +916,7 @@ install_universal() {
 }

 # @FUNCTION: install_headers
+# @USAGE:
 # @DESCRIPTION:
 # Install headers

@@ -940,6 +956,7 @@ install_headers() {
 }

 # @FUNCTION: install_sources
+# @USAGE:
 # @DESCRIPTION:
 # Install sources

@@ -978,6 +995,7 @@ install_sources() {
 }

 # @FUNCTION: preinst_headers
+# @USAGE:
 # @DESCRIPTION:
 # Headers preinst steps

@@ -988,6 +1006,7 @@ preinst_headers() {
 }

 # @FUNCTION: postinst_sources
+# @USAGE:
 # @DESCRIPTION:
 # Sources post installation function.
 # see inline comments
@@ -1082,6 +1101,7 @@ postinst_sources() {
 # pkg_setup functions

 # @FUNCTION: setup_headers
+# @USAGE:
 # @DESCRIPTION:
 # Determine if ${PN} supports arch

@@ -1101,6 +1121,7 @@ setup_headers() {
 }

 # @FUNCTION: unipatch
+# @USAGE: 
 # @DESCRIPTION:
 # Universal function that will apply patches to source

@@ -1364,9 +1385,8 @@ unipatch() {
 }

 # @FUNCTION: getfilevar
+# @USAGE:  
 # @DESCRIPTION:
-# getfilevar accepts 2 vars as follows:
-# getfilevar  
 # pulled from linux-info

 getfilevar() {
@@ -1392,6 +1412,7 @@ getfilevar() {
 }

 # @FUNCTION: detect_arch
+# @USAGE:
 # @DESCRIPTION:
 # This function sets ARCH_URI and ARCH_PATCH
 # with the neccessary info for the arch sepecific compatibility
@@ -1425,6 +1446,7 @@ detect_arch() {
 }

 # @FUNCTION: headers___fix
+# @USAGE:

Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Convert eclass to use documentation standards.

2016-12-04 Thread Mike Pagano
On 12/03/2016 04:47 PM, Mike Pagano wrote:
> This patch modifies, removes and adds comments only. No code was harmed
> in the creation of this patch.
> This is to conform with ECLASS documentation standards.
> 
> ---
>  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




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 1/1] kernel-2.eclass: Convert eclass to use documentation standards.

2016-12-03 Thread Mike Pagano
This patch modifies, removes and adds comments only. No code was harmed
in the creation of this patch.
This is to conform with ECLASS documentation standards.

---
 eclass/kernel-2.eclass | 442
+
 1 file changed, 333 insertions(+), 109 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 91a24e9..b19a396 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -2,89 +2,199 @@
 # Distributed under the terms of the GNU General Public License v2
 # $Id$

-# Description: kernel.eclass rewrite for a clean base regarding the 2.6
-#  series of kernel with back-compatibility for 2.4
-#
-# Original author: John Mylchreest <jo...@gentoo.org>
-# Maintainer: ker...@gentoo.org
-#
+# @ECLASS: kernel-2.eclass
+# @MAINTAINER:
+# Gentoo Kernel project <ker...@gentoo.org>
+# @AUTHOR:
+# John Mylchreest <jo...@gentoo.org>
+# Mike Pagano <mpag...@gentoo.org>
+# 
+# @BLURB: Eclass for kernel packages
+# @DESCRIPTION:
+# This ia the kernel.eclass rewrite for a clean base regarding the 2.6
+# series of kernel with back-compatibility for 2.4
 # Please direct your bugs to the current eclass maintainer :)
-
 # added functionality:
 # unipatch - a flexible, singular method to extract, add and remove
patches.

-# A Couple of env vars are available to effect usage of this eclass
-# These are as follows:
-#
-# K_USEPV  - When setting the EXTRAVERSION 
variable, it should
-#add PV to the end.
-#this is useful for thigns 
like wolk. IE:
-#EXTRAVERSION would be 
something like : -wolk-4.19-r1
-# K_NOSETEXTRAVERSION  - if this is set then EXTRAVERSION will not be
-#automatically set within the 
kernel Makefile
-# K_NOUSENAME  - if this is set then EXTRAVERSION will not 
include the
-#first part of ${PN} in 
EXTRAVERSION
-# K_NOUSEPR- if this is set then EXTRAVERSION will 
not include the
-#anything based on ${PR}.
-# K_PREPATCHED - if the patchset is prepatched (ie: mm-sources,
-#ck-sources, ac-sources) it 
will use PR (ie: -r5) as
-#the patchset version for
-#and not use it as a true 
package revision
-# K_EXTRAEINFO - this is a new-line seperated list of einfo 
displays in
-#postinst and can be used to 
carry additional postinst
-#messages
-# K_EXTRAELOG  - same as K_EXTRAEINFO except using elog 
instead of einfo
-# K_EXTRAEWARN - same as K_EXTRAEINFO except using ewarn 
instead of einfo
-# K_SYMLINK- if this is set, then forcably create 
symlink anyway
-#
-# K_BASE_VER   - for git-sources, declare the base version 
this patch is
-#based off of.
-# K_DEFCONFIG  - Allow specifying a different defconfig target.
-#If length zero, defaults to 
"defconfig".
-# K_WANT_GENPATCHES- Apply genpatches to kernel source. Provide any
-#combination of "base", 
"extras" or "experimental".
-# K_EXP_GENPATCHES_PULL- If set, we pull "experimental" regardless of
the USE FLAG
-#but expect the ebuild 
maintainer to use K_EXP_GENPATCHES_LIST.
-# K_EXP_GENPATCHES_NOUSE   - If set, no USE flag will be provided for
"experimental";
-#as a result the user cannot 
choose to apply those patches.
-# K_EXP_GENPATCHES_LIST- A list of patches to pick from "experimental"
to apply when
-#the USE flag is unset and 
K_EXP_GENPATCHES_PULL is set.
-# K_FROM_GIT - If set, this variable signals that the kernel sources
derives from a git tree and special
-#  handling will be applied so that any patches that are applied
will actually apply.
-#
-# K_GENPATCHES_VER - The version of the genpatches tarball(s) to 
apply.
-#A value of "5" would apply 
genpatches-2.6.12-5 to
-#my-sources-2.6.12.ebuild
-# K_SECURITY_UNSUPPORTED- If set, this kernel is unsupported by Gentoo
Security
-# K_DEBLOB_AVAILABLE   - A value of "0" wil

Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Cleanup. Remove die from global, scope per EAPI 6 rules

2016-12-02 Thread Mike Pagano
On 12/01/2016 07:27 PM, Mike Pagano wrote:
> EAPI 6 prohibits dying in global scope.  Move that check to pkg_setup.
> 
> ---
>  eclass/kernel-2.eclass | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)

Committed




[gentoo-dev] [PATCH 1/1] kernel-2.eclass: Cleanup. Remove die from global, scope per EAPI 6 rules

2016-12-01 Thread Mike Pagano
EAPI 6 prohibits dying in global scope.  Move that check to pkg_setup.

---
 eclass/kernel-2.eclass | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 547153c..91a24e9 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -544,9 +544,6 @@ elif [[ ${ETYPE} == headers ]]; then
unset KBUILD_OUTPUT

SLOT="0"
-else
-   eerror "Unknown ETYPE=\"${ETYPE}\", must be \"sources\" or \"headers\""
-   die "Unknown ETYPE=\"${ETYPE}\", must be \"sources\" or \"headers\""
 fi

 # Cross-compile support functions
@@ -1371,6 +1368,11 @@ kernel-2_pkg_setup() {
fi

ABI="${KERNEL_ABI}"
+   if [[ ${ETYPE} != sources ]] && [[ ${ETYPE} != headers ]]; then
+   eerror "Unknown ETYPE=\"${ETYPE}\", must be \"sources\" or 
\"headers\""
+   die "Unknown ETYPE=\"${ETYPE}\", must be \"sources\" or 
\"headers\""
+   fi
+
[[ ${ETYPE} == headers ]] && setup_headers
[[ ${ETYPE} == sources ]] && echo ">>> Preparing to unpack ..."
 }
-- 
2.7.3




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RESEND PATCH 1/1] kernel-2.eclass: Fix eapply_user as per PMS spec and execute in, src_prepare. Support older EAPIs with epatch_user.

2016-12-01 Thread Mike Pagano
On 11/30/2016 07:32 PM, Mike Pagano wrote:
> Round 3. As per mgorny's additional advice, fix eapply_user as per PMS
> spec and execute in src_prepare. Support older EAPIs with epatch_user.
> export src_prepare only for supported EAPI versions.



mgorny, thanks for the feedback. Committed with peace and love. Peace.
And. Love.

-- 
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




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [RESEND PATCH 1/1] kernel-2.eclass: Fix eapply_user as per PMS spec and execute in, src_prepare. Support older EAPIs with epatch_user.

2016-11-30 Thread Mike Pagano
Round 3. As per mgorny's additional advice, fix eapply_user as per PMS
spec and execute in src_prepare. Support older EAPIs with epatch_user.
export src_prepare only for supported EAPI versions.

---
 eclass/kernel-2.eclass | 35 ++-
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 3f5fb3b..547153c 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -90,12 +90,18 @@
 # If you do change them, there is a chance that we will not fix
resulting bugs;
 # that of course does not mean we're not willing to help.

-has "${EAPI:-0}" 0 1 2 3 4 5 || die "kernel-2.eclass is unsupported for
EAPI ${EAPI}"
-
 PYTHON_COMPAT=( python{2_6,2_7} )

 inherit eutils toolchain-funcs versionator multilib python-any-r1
-EXPORT_FUNCTIONS pkg_setup src_unpack src_compile src_test src_install
pkg_preinst pkg_postinst pkg_postrm
+case ${EAPI:-0} in
+   0|1)
+   EXPORT_FUNCTIONS src_{unpack,compile,install,test} \
+   pkg_{setup,preinst,postinst,postrm} ;;
+   2|3|4|5)
+   EXPORT_FUNCTIONS src_{unpack,prepare,compile,install,test} \
+   pkg_{setup,preinst,postinst,postrm} ;;
+   *) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
+esac

 # Added by Daniel Ostrow 
 # This is an ugly hack to get around an issue with a 32-bit userland on
ppc64.
@@ -1260,12 +1266,9 @@ kernel-2_src_unpack() {
# we run misc `make` functions below
[[ $(type -t kernel-2_hook_premake) == "function" ]] &&
kernel-2_hook_premake

-   debug-print "Applying any user patches"
-   # apply any user patches
-case ${EAPI:-0} in
-0|1|2|3|4|5) epatch_user ;;
-6) eapply_user ;;
-esac
+   case ${EAPI:-0} in
+   0|1) kernel-2_src_prepare ;;
+   esac

debug-print "Doing unpack_set_extraversion"

@@ -1305,6 +1308,20 @@ kernel-2_src_unpack() {
fi
 }

+# @FUNCTION: kernel-2_src_prepare
+# @DESCRIPTION:
+# Apply any user patches
+kernel-2_src_prepare() {
+
+   debug-print "Applying any user patches"
+
+   # apply any user patches
+   case ${EAPI:-0} in
+   0|1|2|3|4|5) epatch_user ;;
+   6) eapply_user ;;
+   esac
+}
+
 kernel-2_src_compile() {
cd "${S}"
[[ ${ETYPE} == headers ]] && compile_headers
-- 
2.7.3




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/1] Fix eapply_user as per PMS spec and execute in, src_prepare. Support older EAPIs with epatch_user.

2016-11-29 Thread Mike Pagano


On 11/29/2016 07:05 PM, Mike Gilbert wrote:
> On Tue, Nov 29, 2016 at 6:24 PM, Mike Pagano <mpag...@gentoo.org> wrote:
>> 2nd round. As per mgorny's advice, fix eapply_user as per PMS spec and
>> execute in src_prepare. Support older EAPIs with epatch_user.
>>
>> ---
>>  eclass/kernel-2.eclass | 25 ++---
>>  1 file changed, 18 insertions(+), 7 deletions(-)
>>
>> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
>> index 3f5fb3b..e516aff 100644
>> --- a/eclass/kernel-2.eclass
>> +++ b/eclass/kernel-2.eclass
>> @@ -95,7 +95,7 @@ has "${EAPI:-0}" 0 1 2 3 4 5 || die "kernel-2.eclass
>> is unsupported for EAPI ${E
>>  PYTHON_COMPAT=( python{2_6,2_7} )
>>
>>  inherit eutils toolchain-funcs versionator multilib python-any-r1
>> -EXPORT_FUNCTIONS pkg_setup src_unpack src_compile src_test src_install
>> pkg_preinst pkg_postinst pkg_postrm
>> +EXPORT_FUNCTIONS pkg_setup src_prepare src_unpack src_compile src_test
>> src_install pkg_preinst pkg_postinst pkg_postrm
> 
> I don't think calling "EXPORT_FUNCTIONS src_prepare" is legal in EAPI
> 0 or 1. You should probably move this behind an EAPI check.
> 
> Also, for EAPI, 2, 3, 4, and 5, this change might break existing
> ebuilds; they may define src_prepare themselves, or inherit some other
> eclass that also exports src_prepare.
> 
> Otherwise, this seems like a good next step.
>

Thank-you, I did see that in another eclass.  (EXPORT)
I will revise and resend tomorrow.





signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 1/1] Fix eapply_user as per PMS spec and execute in, src_prepare. Support older EAPIs with epatch_user.

2016-11-29 Thread Mike Pagano
2nd round. As per mgorny's advice, fix eapply_user as per PMS spec and
execute in src_prepare. Support older EAPIs with epatch_user.

---
 eclass/kernel-2.eclass | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 3f5fb3b..e516aff 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -95,7 +95,7 @@ has "${EAPI:-0}" 0 1 2 3 4 5 || die "kernel-2.eclass
is unsupported for EAPI ${E
 PYTHON_COMPAT=( python{2_6,2_7} )

 inherit eutils toolchain-funcs versionator multilib python-any-r1
-EXPORT_FUNCTIONS pkg_setup src_unpack src_compile src_test src_install
pkg_preinst pkg_postinst pkg_postrm
+EXPORT_FUNCTIONS pkg_setup src_prepare src_unpack src_compile src_test
src_install pkg_preinst pkg_postinst pkg_postrm

 # Added by Daniel Ostrow 
 # This is an ugly hack to get around an issue with a 32-bit userland on
ppc64.
@@ -1260,12 +1260,9 @@ kernel-2_src_unpack() {
# we run misc `make` functions below
[[ $(type -t kernel-2_hook_premake) == "function" ]] &&
kernel-2_hook_premake

-   debug-print "Applying any user patches"
-   # apply any user patches
-case ${EAPI:-0} in
-0|1|2|3|4|5) epatch_user ;;
-6) eapply_user ;;
-esac
+   case ${EAPI:-0} in
+   0|1) kernel-2_src_prepare ;;
+   esac

debug-print "Doing unpack_set_extraversion"

@@ -1305,6 +1302,20 @@ kernel-2_src_unpack() {
fi
 }

+# @FUNCTION: kernel-2_src_prepare
+# @DESCRIPTION:
+# Apply any user patches
+kernel-2_src_prepare() {
+
+   debug-print "Applying any user patches"
+
+   # apply any user patches
+   case ${EAPI:-0} in
+   0|1|2|3|4|5) epatch_user ;;
+   6) eapply_user ;;
+   esac
+}
+
 kernel-2_src_compile() {
cd "${S}"
[[ ${ETYPE} == headers ]] && compile_headers
-- 
2.7.3






signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Support EAPI 6 when applying user patches.

2016-11-29 Thread Mike Pagano


On 11/29/2016 03:46 AM, Michał Górny wrote:
> On Mon, 28 Nov 2016 06:42:44 -0500
> Mike Pagano <mpag...@gentoo.org> wrote:
> 
>> On 11/27/2016 09:06 PM, Mike Gilbert wrote:
>>> On Sun, Nov 27, 2016 at 7:23 PM, Mike Pagano <mpag...@gentoo.org> wrote:  
>>>> If kernel-2_src_unpack() is called in EAPI6, epatch_user() function
>>>> inherited from eutils.eclass is undefined.
>>>> See bug #579188  
>>>
>>> kernel-2.eclass currently calls die in global scope for EAPI 6, so
>>> this change has no real effect.
>>>
>>> I would suggest modernizing the eclass before allowing it to be used
>>> with EAPI 6. For example, patches should be applied in src_prepare,
>>> not src_unpack.
>>>   
>>
>> Is this change not a step in the right direction? Or should it just be
>> one big bang?
>> All or nothing?
> 
> While I don't mean incremental changes, I'd really prefer if they made
> any sense. Calling eapply_user in src_unpack() is invalid, per PMS:
> 
> | In EAPIs where it is supported, eapply_user must be called once
> | in the src_prepare phase.
> 

Your last sentence is constructive criticism. I'll fix this.

-- 
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




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Support EAPI 6 when applying user patches.

2016-11-28 Thread Mike Pagano


On 11/27/2016 09:06 PM, Mike Gilbert wrote:
> On Sun, Nov 27, 2016 at 7:23 PM, Mike Pagano <mpag...@gentoo.org> wrote:
>> If kernel-2_src_unpack() is called in EAPI6, epatch_user() function
>> inherited from eutils.eclass is undefined.
>> See bug #579188
> 
> kernel-2.eclass currently calls die in global scope for EAPI 6, so
> this change has no real effect.
> 
> I would suggest modernizing the eclass before allowing it to be used
> with EAPI 6. For example, patches should be applied in src_prepare,
> not src_unpack.
> 


Is this change not a step in the right direction? Or should it just be
one big bang?
All or nothing?

-- 
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




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 1/1] kernel-2.eclass: Support EAPI 6 when applying user patches.

2016-11-27 Thread Mike Pagano
If kernel-2_src_unpack() is called in EAPI6, epatch_user() function
inherited from eutils.eclass is undefined.
See bug #579188

---
 eclass/kernel-2.eclass | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index c171940..3f5fb3b 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1260,8 +1260,12 @@ kernel-2_src_unpack() {
# we run misc `make` functions below
[[ $(type -t kernel-2_hook_premake) == "function" ]] &&
kernel-2_hook_premake

-   debug-print "Doing epatch_user"
-   epatch_user
+   debug-print "Applying user patches if they exist"
+   # apply any user patches
+case ${EAPI:-0} in
+0|1|2|3|4|5) epatch_user ;;
+6) eapply_user ;;
+esac

debug-print "Doing unpack_set_extraversion"

-- 
2.7.3



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 1/1] kernel-2.eclass: Remove call to KV_to_int. See bug #587318.

2016-11-27 Thread Mike Pagano
KV_to_int usage should be removed.
Tracker bug is at: 384041 and kernel-2.eclass bug is at 587318.

---
 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 1398c0c..c171940 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -681,7 +681,7 @@ compile_headers() {
# if K_DEFCONFIG isn't set, force to "defconfig"
# needed by mips
if [[ -z ${K_DEFCONFIG} ]]; then
-   if [[ $(KV_to_int ${KV}) -ge $(KV_to_int 2.6.16) ]]; then
+   if kernel_is ge 2 6 16 ; then
case ${CTARGET} in
powerpc64*) K_DEFCONFIG="ppc64_defconfig";;
powerpc*)   K_DEFCONFIG="pmac32_defconfig";;
-- 2.7.3




Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2015-11-17 Thread Mike Pagano
On Tuesday, November 17, 2015 08:19:29 AM Michał Górny wrote:
> On Mon, 16 Nov 2015 23:38:08 + (UTC)
> 
> "Mike Pagano" <mpag...@gentoo.org> wrote:
> > commit: aac24917ebe254a23990f0d7fff9f6f570b99d15
> > Author: Mike Pagano  gentoo  org>



Thanks for the review and feedback. Applied your suggestion.

Mike



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

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] qa last rites multiple packages

2015-01-07 Thread Mike Pagano
On Wed, Jan 07, 2015 at 01:08:21PM -0600, William Hubbs wrote:
 On Wed, Jan 07, 2015 at 01:29:15PM -0500, Mike Pagano wrote:
  On Wed, Jan 07, 2015 at 11:11:32AM -0600, William Hubbs wrote:
   On Wed, Jan 07, 2015 at 11:21:56AM -0500, Mike Pagano wrote:
On Tue, Jan 06, 2015 at 05:47:10PM -0600, William Hubbs wrote:
 All,
  William,
  
  At what point do we not care about users who have not upgraded and will
  miss this security message? 
  
  I would say that's more up to you as the maintainer, but put something
  to the affect in the mask comment.
 
  # This mask will be removed whenever
 
 William
 

Fair enough. This question is to anyone that supports users and works on
bugs.  Especially the portage devs. At what point do you say to a user
that their system is so old that they really need to upgrade?

2 years, 1 year,  1 year?  Maybe that's a good thing to state in documentation.

For a fully supported and reasonably secure as possible Gentoo system, the
distribution expects users to update at least X times a year. Notice of
insecure or potentially harmful packages is not guaranteed one year after
official notification.

Mike


-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] qa last rites multiple packages

2015-01-07 Thread Mike Pagano
On Tue, Jan 06, 2015 at 05:47:10PM -0600, William Hubbs wrote:
 All,
 
 these packages have been masked in the tree for months - years with no
 signs of fixes.
 
 I am particularly concerned about packages with known security
 vulnerabilities staying in the main tree masked. If people want to keep
 using those packages, I don't want to stop them, but packages like this
 should not be in the main tree.
 
 # Mask gentoo-sources ebuilds that are affected with security bug 
 CVE-2014-3153.
 #
 # Pinkie Pie discovered an issue in the futex subsystem that allows a
 # local user to gain ring 0 control via the futex syscall. An
 # unprivileged user could use this flaw to crash the kernel (resulting
 # in denial of service) or for privilege escalation.
 #
 # https://bugs.gentoo.org/show_bug.cgi?id=CVE-2014-3153
 =sys-kernel/gentoo-sources-3.2.58-r2
 ~sys-kernel/gentoo-sources-3.4.90
 =sys-kernel/gentoo-sources-3.4.91
 ~sys-kernel/gentoo-sources-3.10.40
 =sys-kernel/gentoo-sources-3.10.41
 ~sys-kernel/gentoo-sources-3.12.20
 =sys-kernel/gentoo-sources-3.12.21
 ~sys-kernel/gentoo-sources-3.14.4
 =sys-kernel/gentoo-sources-3.14.5

Hello,

What's the feeling for how long a package.mask entry should stay in the
file in the event that a package can cause physical damage to a user's 
system.

For certain types of hardware, kernel 3.17.0 could cause some
filesystem corruption. Of couse, 3.17.0 is out of the tree but when is
it appropiate to say that a user has had enough time to upgarde their
systems and we can remove this entry?

Mike


-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] qa last rites multiple packages

2015-01-07 Thread Mike Pagano
On Wed, Jan 07, 2015 at 11:11:32AM -0600, William Hubbs wrote:
 On Wed, Jan 07, 2015 at 11:21:56AM -0500, Mike Pagano wrote:
  On Tue, Jan 06, 2015 at 05:47:10PM -0600, William Hubbs wrote:
   All,
   #
   # Pinkie Pie discovered an issue in the futex subsystem that allows a
   # local user to gain ring 0 control via the futex syscall. An
   # unprivileged user could use this flaw to crash the kernel (resulting
   # in denial of service) or for privilege escalation.
   #
   # https://bugs.gentoo.org/show_bug.cgi?id=CVE-2014-3153
   =sys-kernel/gentoo-sources-3.2.58-r2
   ~sys-kernel/gentoo-sources-3.4.90
   =sys-kernel/gentoo-sources-3.4.91
   ~sys-kernel/gentoo-sources-3.10.40
   =sys-kernel/gentoo-sources-3.10.41
   ~sys-kernel/gentoo-sources-3.12.20
   =sys-kernel/gentoo-sources-3.12.21
   ~sys-kernel/gentoo-sources-3.14.4
   =sys-kernel/gentoo-sources-3.14.5
 
 Mike,
 
 since you responded here, what do you think about this p.mask entry?
 Should we keep these in the tree?
 
William,

At what point do we not care about users who have not upgraded and will
miss this security message? 

Mike


-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] qa last rites multiple packages

2015-01-07 Thread Mike Pagano
On Wed, Jan 07, 2015 at 12:14:23PM -0500, Mike Gilbert wrote:
 On Wed, Jan 7, 2015 at 12:11 PM, William Hubbs willi...@gentoo.org wrote:
  On Wed, Jan 07, 2015 at 11:21:56AM -0500, Mike Pagano wrote:
  On Tue, Jan 06, 2015 at 05:47:10PM -0600, William Hubbs wrote:
   All,
  
 
 If you remove the mask, users will no longer be warned that they are
 using a flawed copy of the kernel sources.
 
 Thus, Mike's question about timing.
 

Exactly.

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] Gentoo-sources - should we stable?

2015-01-03 Thread Mike Pagano
On Saturday, January 03, 2015 11:18:26 AM Pacho Ramos wrote:
 El vie, 02-01-2015 a las 12:25 -0500, Mike Pagano escribió:
  Hello, Everyone,
  

  [2] http://packages.gentoo.org/package/sys-kernel/gentoo-sources
 
 In my case I still run only stable gentoo-sources in many machines to
 prevent regressions introduced by new major kernel releases. For
 example, few weeks ago kernel 3.17.x were breaking X in some of them due
 to a regression with AGP handling that was fixed in 3.17.4.
 
 Even if arch team members cannot test the versions really deep, for now
 it has been enough for me to rely on kernel maintainers thinking a
 concrete major version is ready to be stabilized after some weeks :)

Hi, Pacho,

I think if you read further in the thread and find Ian's suggestion, it should 
cover your needs nicely.

Mike

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Team Lead - Gentoo Sources
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index




Re: [gentoo-dev] Gentoo-sources - should we stable?

2015-01-02 Thread Mike Pagano
On Friday, January 02, 2015 01:10:21 PM Ian Stakenvicius wrote:

Resending as I replied to Ian instead of the list by accident. (sorry, Ian)

 On 02/01/15 12:25 PM, Mike Pagano wrote:
  Hello, Everyone,
  
  Are there solid arguments for stabilizing any version of
  gentoo-sources?  I think the valid arguments for not stabilizing
  gentoo-sources can be garnered from the thread about not
  stabilizing vanilla-sources[1].
  
  This is in no way complaining about how long it takes to stabilize
  a kernel. It's just a fact that by the time we do stabilizing one,
  there might be many, many kernel versions released for that 3.X
  branch that contains security fixes for which the stable version
  will not have.  Kernel versions are coming out 1-2 a week at this
  point.
  
  I feel we are giving users a false sense of security, and maybe it
  would be better for them to upgrade faster than they are doing now
  if they are only using stable kernels.
  
  Having stable kernels around keeps me from deleting these old,
  potentially vulnerable releases.[2]
  
  Mike
  
  [1] http://marc.info/?l=gentoo-kernelm=137182668616082w=2 [2]
  http://packages.gentoo.org/package/sys-kernel/gentoo-sources
 
 The thing about stable gentoo-sources is that it shows that it's been
 tested, and ideally that testing's been done against the rdeps of the
 kernel package too (ie, external modules).  For instance, I like that
 I can generally expect vbox-modules and tp_smapi and bbswitch to
 emerge against whatever the current-stable gentoo-sources kernel is,
 whereas with the ~arch one(s) I don't hold any such expectation
 (although it's nice when it does).

You should *definitely* not assume out of kernel modules are stable (or even 
compile, install or run) on any stable version.

Kernel stabilization has never been held up by out of kernel modules. They are 
not part of the decision on whether or not a kernel should be stabilized.

 Similarly, when there are known functionality issues that do not have
 an upstream fix (nor one scheduled for some time), like say, intel drm
 being broken except for ~arch or - xorg/libdrm/xf86-video-intel ,
 I think it's pertinent that the newer versions stay ~arch until a fix
 is developed and available -- the stable kernel being pegged at 3.4.9
 for a long time is a good example of this.

Some Arch members have told me that stabilizing kernel does not include much 
more than a compile and boot test.  Some run it for a few days, but the 
mixture of hardware and versions out there really precludes an all 
encompassing blessing.

 That said, given the frequency of security updates, I do think it
 makes sense to try and keep the stabilization of LTS kernel versions
 in sync with upstream as much as possible, including
 quick-stabilization whenever we can.  Hopefully those security
 backports don't usually change functionality and features much,
 although if they do then perhaps we need to hold off on their
 stabilization for a little while too..

And that is the problem.  We can't keep up and still with a straight face tell 
user's *this* is the kernel you should run.

 Makes sense or am I way off base?


Thanks for responding,
MIke



-- 
Mike Pagano
Gentoo Developer - Kernel Project
Team Lead - Gentoo Sources
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index




Re: [gentoo-dev] Gentoo-sources - should we stable?

2015-01-02 Thread Mike Pagano
On Friday, January 02, 2015 04:05:42 PM Rich Freeman wrote:
 On Fri, Jan 2, 2015 at 3:44 PM, Mike Pagano mpag...@gentoo.org wrote:
  To summarize.
  
  In this instance, as this moment:
  
  1. Only enter stable req bugs for 3.18 and 3.17.
 
 I assume this bit is just a transition since we don't want to
 downgrade from 3.17/18 to 3.14, and that once we get the next longterm
 we'll just follow that?  If we kept doing delayed stablereqs on the
 latest stable then users are going to tend to be behind on the fixes
 just as they are today since they won't run longterm by default.

I would not destabilize 3.17 (or anything for that matter). So those people 
would not be affected.

  2. Once they enter LTS, then auto stable going forward.
  3. At this moment, auto stable 3.14, 3.12, 3.10 and 3.4.
 
 ++
 
  If this is what you're saying, this would make things much better for me
  and better for our users.
  
  Who needs to bless this? Council, Arch Teams, Rich0, God, my dog?
 
 Not that it means anything, but you have a +4 from me and my cats
 (just be happy I don't let them post here - FYI they're easily bribed
 with food).

Good news, I wasn't sure if I should CC them or not.

 I'd suggest that the kernel maintainers can just do it if there is
 no objection after a few days.  Escalation is for when there is
 disagreement.

That sounds like good advice.

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Team Lead - Gentoo Sources
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index




[gentoo-dev] Gentoo-sources - should we stable?

2015-01-02 Thread Mike Pagano
Hello, Everyone,

Are there solid arguments for stabilizing any version of gentoo-sources?  I 
think the valid arguments for not stabilizing gentoo-sources can be garnered 
from the thread about not stabilizing vanilla-sources[1].  

This is in no way complaining about how long it takes to stabilize a kernel. 
It's just a fact that by the time we do stabilizing one, there might be many, 
many kernel versions released for that 3.X branch that contains security fixes 
for which the stable version will not have.  Kernel versions are coming out 
1-2 a week at this point.

I feel we are giving users a false sense of security, and maybe it would be 
better for them to upgrade faster than they are doing now if they are only 
using stable kernels.

Having stable kernels around keeps me from deleting these old, potentially 
vulnerable releases.[2]

Mike

[1] http://marc.info/?l=gentoo-kernelm=137182668616082w=2
[2] http://packages.gentoo.org/package/sys-kernel/gentoo-sources


-- 
Mike Pagano
Gentoo Developer - Kernel Project
Team Lead - Gentoo Sources
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index




Re: [gentoo-dev] Gentoo-sources - should we stable?

2015-01-02 Thread Mike Pagano
On Friday, January 02, 2015 03:11:22 PM Ian Stakenvicius wrote:
 On 02/01/15 02:57 PM, Mike Pagano wrote:
  I understand your point. Maybe waiting a few days to auto stable
  makes sense, because less than 7 days later, a new version with
  bug/security fixes is released.
  
  Isn't our current rate of stabilization selling a promise of
  stability we can't stand behind?
  
  Mike
 
 Well to be perfectly honest, the current-stable 3.16 and 3.17 kernels
 for me at least have some rather unfortunate regressions over 3.15 and
 previous, so even with the stabilization we're achieving now I don't
 think we're living up to our promise of stability :)

Exactly.  It may give people a warm fuzzy feeling, but it's not like other 
packages.


-- 
Mike Pagano
Gentoo Developer - Kernel Project
Team Lead - Gentoo Sources
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index




Re: [gentoo-dev] Gentoo-sources - should we stable?

2015-01-02 Thread Mike Pagano
On Friday, January 02, 2015 02:18:24 PM Rich Freeman wrote:
 On Fri, Jan 2, 2015 at 1:10 PM, Ian Stakenvicius a...@gentoo.org wrote:
  The thing about stable gentoo-sources is that it shows that it's been
  tested, and ideally that testing's been done against the rdeps of the
  kernel package too (ie, external modules).  ...
  That said, given the frequency of security updates, I do think it
  makes sense to try and keep the stabilization of LTS kernel versions
  in sync with upstream as much as possible, including
  quick-stabilization whenever we can.
 
 ++ and ++
 
 Would an approach like this make sense:
 1.  For ~arch keep doing what we're doing (which seems to be generally
 following the upstream stable branches).
 2a.  For stable always target the latest longterm, and commit straight
 to stable.
 or
 2b.  For stable just follow ~arch a few days behind.
 3.  Either way immediately remove packages that aren't
 upstream-supported (by all means keep all the longterm/stable
 branches, but don't leave cruft hanging around or abandoned stable
 branches - if somebody ~arch tagged a particular branch and didn't get
 the news that it won't go longterm then they'll either downgrade to a
 supported stable or notice and adjust their keywords to go to the next
 stable).
 
 2a is extremely unlikely to break anything, but probably won't get any
 testing so you might as well commit straight to stable (nobody running
 ~arch is going to be running longterm as well).  2b is more likely to
 break stuff, but on the other hand will be more likely to have actual
 bugs reported so it will be more tested.
 
 The biggest issue I see is with packages that actually use recent
 kernel features (systemd comes to mind, maybe udev to a lesser degree,
 and I'm sure there are others).  These kinds of packages should have
 clear kernel dependencies though.  In some sense EVERYTHING is an rdep
 of the kernel so breakage could conceivably happen anywhere - but the
 risk is higher in some places.
 
 I think the classical stable user is probably best off following
 upstream longterm anyway, unless they just bought a new laptop or
 something like that.
 
 In general though I think that it is perfectly acceptable to have a QA
 policy specific to the kernel since upstream has very robust stable
 branch support, and the level of QA and release maturity is extremely
 high.
 
 I do think that it makes sense to not throw stable Gentoo users at
 kernels that were mainline release candidates only a day before.

I understand your point. Maybe waiting a few days to auto stable makes sense, 
because less than 7 days later, a new version with bug/security fixes is 
released.

Isn't our current rate of stabilization selling a promise of stability we 
can't stand behind?

Mike

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Team Lead - Gentoo Sources
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index




Re: [gentoo-dev] Gentoo-sources - should we stable?

2015-01-02 Thread Mike Pagano
On Saturday, January 03, 2015 12:39:39 AM Mikle Kolyada wrote:
 02.01.2015 20:25, Mike Pagano пишет:
  This is in no way complaining about how long it takes to stabilize a
  kernel.
 As for this fact.
 
 hat type=arch teams developer
 
 The main problem is that: we only can test sources on machine we can
 reboot. For example me and Agostino
 have access to the rest hardware like alpha, ia64 and so on. But we
 can't reboot it for clear reason i think.
 Another side is that: not all hardware i have around can use
 gentoo-sources, so it works with custom kernels.
 
 /hat

Mikle,

Let me reiterate. This should be in no way interpreted as an attack on the 
arch teams.  I'm getting more and more constrained by life and slacking like 
crazy, so I would never complain about the amount of time other volunteers put 
into this distribution.

AFAIC, you definitely don't need to defend the arch teams whom I respect and 
whose efforts I greatly appreciate.

Mike

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Team Lead - Gentoo Sources
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index




Re: [gentoo-dev] Gentoo-sources - should we stable?

2015-01-02 Thread Mike Pagano
On Friday, January 02, 2015 03:22:31 PM Ian Stakenvicius wrote:
 On 02/01/15 03:17 PM, Mike Pagano wrote:
  On Friday, January 02, 2015 03:11:22 PM Ian Stakenvicius wrote:
  On 02/01/15 02:57 PM, Mike Pagano wrote:
  I understand your point. Maybe waiting a few days to auto
  stable makes sense, because less than 7 days later, a new
  version with bug/security fixes is released.
  
  Isn't our current rate of stabilization selling a promise of
  stability we can't stand behind?
  
  Mike
  
  Well to be perfectly honest, the current-stable 3.16 and 3.17
  kernels for me at least have some rather unfortunate regressions
  over 3.15 and previous, so even with the stabilization we're
  achieving now I don't think we're living up to our promise of
  stability :)
  
  Exactly.  It may give people a warm fuzzy feeling, but it's not
  like other packages.
 
 I agree; and also with Rich.
 
 It might be a good idea to avoid stabilization of versions other than
 the LTS ones, ie let users that want anything newer than a (at this
 time of writing) 3.14 kernel use keywords to get them, and
 direct-to-stable gentoo-sources packages for 3.14, 3.12, 3.10
 (probably with a 'genkernel kernel' test run on at least one arch
 first to make sure this doesn't break for the really lazy user).  Then
 major dev work related to gentoo-sources stabilization is just in
 preparation for the next longterm release.

 Would that workflow still be too much for the current gentoo-sources
 maintainers?
Hi, that's only me.  :)


FYI, I do a compile/boot test on amd64 for every kernel I put out there.

OK, I don't hate this idea.

To summarize.

In this instance, as this moment:

1. Only enter stable req bugs for 3.18 and 3.17.
2. Once they enter LTS, then auto stable going forward.
3. At this moment, auto stable 3.14, 3.12, 3.10 and 3.4.

If this is what you're saying, this would make things much better for me and 
better for our users.

Who needs to bless this? Council, Arch Teams, Rich0, God, my dog?  


Mike








-- 
Mike Pagano
Gentoo Developer - Kernel Project
Team Lead - Gentoo Sources
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index




Re: [gentoo-dev] Gentoo-sources - should we stable?

2015-01-02 Thread Mike Pagano
On Friday, January 02, 2015 03:30:40 PM Rich Freeman wrote:
 On Fri, Jan 2, 2015 at 3:11 PM, Ian Stakenvicius a...@gentoo.org wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
  
  On 02/01/15 02:57 PM, Mike Pagano wrote:
  I understand your point. Maybe waiting a few days to auto stable
  makes sense, because less than 7 days later, a new version with
  bug/security fixes is released.
  
  Isn't our current rate of stabilization selling a promise of
  stability we can't stand behind?
  
  Mike
  
  Well to be perfectly honest, the current-stable 3.16 and 3.17 kernels
  for me at least have some rather unfortunate regressions over 3.15 and
  previous, so even with the stabilization we're achieving now I don't
  think we're living up to our promise of stability :)
 
 As a btrfs user I went through quite a bit of pain in the whole
 3.15-17 series, but I that probably isn't a typical mainstream user
 experience.  This sort of thing was why I did suggest targeting
 longterm.  When the next longterm is announced then we could
 transition to it at our leisure (ie with plenty of testing while
 following point releases quickly on the previous longterm).
 
 So, moving between longterm branches would have a more typical Gentoo
 QA process.  However, between point releases within a branch we would
 auto-stable releases, since it is unlikely that our own QA process is
 going to add any real value beyond what upstream already does.
 
 We also need to keep in mind just what our promise of stability even
 means.  We're not a release-based distro, and we're NEVER going to
 offer an experience like RHEL or Debian Stable where the entirety of
 the package base is pinned and tested and we only do security
 backports.  The kernel stable branches probably represent a lot more
 stability than we have almost anywhere else in the distro anyway.

We have had a lot of stable kernels with a not-so-stable btrfs.  That's a 
whole conversation in itself.  There are pieces of the kernel that are in a, 
shall we say, less stable state than others.

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Team Lead - Gentoo Sources
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index




Re: [gentoo-dev] local repo kernel ebuild search for tar.bz2 instead of tar.xz

2014-06-26 Thread Mike Pagano
On Thu, Jun 26, 2014 at 07:37:40PM +0300, Kfir Lavi wrote:
Hi,
I have copied ebuild from sys-kernel/hardened-sources to my local
repository, in order to patch the sources.
I didn't change the ebuild for now, but repoman manifest does not work.
It tries to download files with extension tar.bz2 and not tar.xz.
If I delete my local copy of the ebuild, emerge will work ok from the
global portage tree.
I think bug [1]https://bugs.gentoo.org/show_bug.cgi?id=421721
is related to my problem, as it changed the extension of tar archives
from bz2 to xz.
Maybe there is a global flag I need to specify in order to inherit
gentoo main tree behaviour?
Regards,
Kfir
 
 References
 
1. https://bugs.gentoo.org/show_bug.cgi?id=421721


Check that you are using the latest kernel-2.eclass in your local repo.

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kernel-2.eclass?view=log
Diff to previous 1.278

Revision 1.279 - (view) (download) (annotate) - [select for diffs] 
Sat Mar 9 21:05:50 2013 UTC (15 months, 2 weeks ago) by tomwij 
Kernel sources and (gen)patches now use xz instead of bz2. Bug #421721


-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy

2013-08-04 Thread Mike Pagano
On Sunday, August 04, 2013 07:45:47 AM Rich Freeman wrote:
 On Sun, Aug 4, 2013 at 7:16 AM, Ben de Groot yng...@gentoo.org wrote:
  On 4 August 2013 09:56, Alex Xu alex_y...@yahoo.ca wrote:
  Minor grammar/typographical errata:
  snip


Thanks, everyone for helping out.  Here is the latest with some of the 
requested changes:


Title: vanilla-sources stabilization policy
Author: Mike Pagano mpag...@gentoo.org
Content-Type: text/plain
Posted: 2013-08-07
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-kernel/vanilla-sources

The Gentoo Kernel Team will no longer be providing stable
vanilla-sources kernels. All currently stabilized vanilla-sources
versions will be dropped to ~arch. The Arch teams, via normal requests
of the Kernel Team, will continue to stabilize gentoo-sources kernels
upon request. This decision is based on the facts that upstream is now
releasing approximately 1-2 vanilla-sources kernels a week. Arch teams,
understandably, are unable to keep up with this rate of release.  As
most vanilla releases contain security fixes, the user who only runs
stable vanilla-sources will consistently be behind and potentially at
risk.  For the latest upstream kernel unpatched by Gentoo kernel, we
recommend users add 'sys-kernel/vanilla-sources' to their
package.accept_keywords file. gentoo-sources will continue to be a
tested and supported version for Gentoo users.


Note: This news item only applies to gentoo-sources and vanilla-sources.
Other kernels currently maintained in portage have their own policies
and procedures in place toda


-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy

2013-08-04 Thread Mike Pagano
On Sunday, August 04, 2013 07:24:23 PM Alex Xu wrote:

 wat. Possibly intended:
  For the latest upstream kernel unpatched by Gentoo

Not intended
---


Title: vanilla-sources stabilization policy
Author: Mike Pagano mpag...@gentoo.org
Content-Type: text/plain
Posted: 2013-08-07
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-kernel/vanilla-sources

The Gentoo Kernel Team will no longer be providing stable
vanilla-sources kernels. All currently stabilized vanilla-sources
versions will be dropped to ~arch. The Arch teams, via normal requests
of the Kernel Team, will continue to stabilize gentoo-sources kernels
upon request. This decision is based on the facts that upstream is now
releasing approximately 1-2 vanilla-sources kernels a week. Arch teams,
understandably, are unable to keep up with this rate of release.  As
most vanilla releases contain security fixes, the user who only runs
stable vanilla-sources will consistently be behind and potentially at
risk.  For the latest upstream kernel unpatched by Gentoo, we
recommend users add 'sys-kernel/vanilla-sources' to their
package.accept_keywords file. gentoo-sources will continue to be a
tested and supported version for Gentoo users.


Note: This news item only applies to gentoo-sources and vanilla-sources.
Other kernels currently maintained in portage have their own policies
and procedures in place today.



-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



[gentoo-dev] newsitem: Kernel Team vanilla-sources policy

2013-08-03 Thread Mike Pagano

All,
Here is the vanilla-sources non stablizing policy news item.
If all goes well, this will be committed to the tree  on 08/07 UTC.
Mike



Title: vanilla-sources stabilization policy
Author: Mike Pagano mpag...@gentoo.org
Content-Type: text/plain
Posted: 2013-08-07
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-kernel/vanilla-sources

The Gentoo Kernel Team will no longer be providing stable vanilla-sources
kernels. All currently stabilized vanilla-sources versions will be dropped
to ~arch. The Arch teams, via normal requests of the Kernel Team, will
continue to stabilize gentoo-sources kernels upon request. This decision is
based on the facts that upstream is now releasing approximately 1-2 vanilla-
sources kernels a week. Arch teams, understandable, are unable to keep up with
this rate of release.  As most vanilla releases contain security fixes, the
user who only runs stable vanilla-sources will consistently be behind and
potentially at risk.  For the latest upstream non Gentoo patched vanilla
kernel, we recommend user add 'sys-kernel/vanilla-sources' to their
package.accept_keywords file.  Gentoo-sources will continue to be a tested and
supported version for Gentoo users.


Note: This news item only applies to gentoo-sources and vanilla-sources. Other
kernels currently maintained in portage have their own policies and procedures
in place today.



-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-27 Thread Mike Pagano
On Saturday, July 27, 2013 09:58:08 AM Rich Freeman wrote:

 
 Unless it were stable-masked it would create the exact same problem.
 


^^ This

-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



[gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Mike Pagano

tl;dr

Summary

Team members working alongside upstream (and downstream) developer Greg k-h 
have decided to no longer request stabilization of the vanilla sources kernel.  
Team members and arch teams (understandably) are unable to keep up with the 
1-2 weekly kernel releases, and therefore will now direct users to always run 
the latest vanilla sources, or to run gentoo-sources for a fully Gentoo 
supported kernel. We will continue to do our best effort to request and get 
stabililzed g-s versions.


Details

Some facts:

1. Upstream release rate is now a much higher 1-2 kernels a week.
2. Very frequently, these releases contain security fixes.
3. This rate of release puts arch teams in a difficult position, since
it is unsustainable to try to keep up to date with stabilization
4. By continuing the policy of providing a stable vanilla kernel version, 
Gentoo is giving a false sense of security to its users, since by the time the 
kernel does get stabilized, a newer version with more security fixes is almost 
always already released

Eventually, we will be updating our project pages to reflect these changes. As 
always with me, constructive dialog concerning this policy is welcome.

Original thread of discussion:
http://thread.gmane.org/gmane.linux.gentoo.kernel/697

-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] Proper distribution integration of kernel *-sources, patches and configuration.

2013-07-04 Thread Mike Pagano
On Monday, July 01, 2013 01:52:10 PM Rick Zero_Chaos Farina wrote:
 On 07/01/2013 01:35 PM, Tom Wijsman wrote:
  On Mon, 01 Jul 2013 12:20:09 -0400
  
  Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:
  Some patches are reasonably easy to combine, such as genpatches and
  aufs.  Some patches are difficult to combine, such as hardened and *.
  When you combine hardened patches and aufs (for example) you need
  extra patches.  I would be THRILLED to see the number of sources cut
  down, but hardened-sources must be it's own thing (that said, I'll
  personally maintain the aufs patches for hardened if they wanted to
  add a USE=aufs flag).
  
  Yes, gave it as an quick example but I indeed remember from going
  through the sources ebuilds that hardened ebuilds do quite some things.
  I think the downside from extending genpatches is that hardened-sources
  can no longer rely on it, but we'll have to see that as we go forward.
  
  I don't think that apart from hardened the optional patches on their own
  are hard to combine; they each have their own separate goal, I don't
  see them conflict on anything. If it happens once in a while, we can
  still maintain them to work together.
 
 Hardened has K_WANT_GENPATCHES=base which means it already doesn't
 take the extra patches.  We could either introduce a new flag for your
 patches like K_WANT_GENPATCHES=base extra geek or more likely make
 each one with their own name so that hardened et al can take what they
 like and leave the rest.

Ok, so I have talked to Tom about this on IRC and it's probably prudent to 
chime in.  I have gotten many complaints in the past that there is not enough 
in g-s, and, of course, I've gotten complaints about there being too much.

I have 'relaxed' a tad about what I think should be in g-s, but maybe it has 
gone a bit farther than I wanted it too.

I would like to see a -experimental use flag and base,extras,geek (whatever) 
so that g-s goes back to what it's original goal was with nothing non-upstream 
unless the user does a configuration change themselves.

This will actually help us solve both issues.

1) it will allow us to pull g-s back to it's original goal as  a minimal 
kernel sources with upstream only patches.
2) we can carry some patches from upstreams trees that possibly aren't yet in 
-next, or not yet accepted to mainline but do provide some benefit to a smaller 
group of our users. (Thinking about our thinkpad patches)


-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] Re: Gentoo Hangouts

2013-06-24 Thread Mike Pagano
On Mon, Jun 24, 2013 at 12:04:04PM +0100, Markos Chandras wrote:
 On 24 June 2013 11:54, Michael Palimaka kensing...@gentoo.org wrote:
  On 24/06/2013 07:30, Pavlos Ratis wrote:
 
  That's why I'd like to propose Gentoo Hangouts. Gentoo Hangouts will
  be Google+  video Hangouts(video calls) held by teams or developers
  independent of a team. The main goal is to have the teams introduce
  themselves and discuss about different issues in their Gentoo-related
  projects.
 
 
  Thanks for taking the time and initiative to work on something new, I am
  sure it will prove interesting.
 
  It is the response that confuses me - I don't understand why everyone is
  rushing to shut it down before it even begins. For those that are not
  interested in the idea of a video hangout, just don't use it and move on -
  simple.
 
 
 
 I like the idea. It might help bring developers and users closer.
 
 --

I can't see the harm, and people who don't have the time, interest or
social skills can certainly not join.  

I worked from a home office for 7 years and used this all the time.
Sometimes it helps to realize that the people on the other end of the
wire are just that: people.

I've seen behaviors change among team members for the better. Plus,
maybe I can learn how to pronouce more than half of your names. :)





Re: [gentoo-dev] January stabilization candidates

2013-01-22 Thread Mike Pagano
On Wednesday, January 16, 2013 07:14:12 PM Tomáš Chvátal wrote:
 Dne So 12. ledna 2013 14:49:52, Paweł Hajdan, Jr. napsal(a):
  Please review attached automatically generated stabilization candidates
  for January.
  
  I don't want to annoy people with automatically filed bugs, and at the
  same time I also received lots of positive feedback about the effort to
  keep the stable tree more up-to-date.
  
  I think the best way to proceed is to listen to that feedback and
  continue the effort, while also keeping an updated list of exclusions
  for packagers/herds that are actively stabilized by maintainers.
  
  Paweł
 
 Hmm, nice idea but how about expanding metadata.xml with something like info 
 for stabilisations so they can be automatically grabbed for it. Quite few 
 software is just nice enough that it can go automatically for stable in 30 
 days, and someone could just go then and open new bugs (with assigned 
arches) 
 based on it (of course it expects brain from the guy reporting it that he 
 checks if there are no open bugs).
 
 Because mails to -dev are frankly annoying. :-)
 
 Tom

Tom,

This is a better idea.  I also believe this one can be auto stablized after 30 
days. It's just kernel documentation.



-- 
Mike Pagano
Gentoo Developer - Kernel Project
Team Lead - Gentoo Sources
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] January stabilization candidates

2013-01-15 Thread Mike Pagano
13.01.2013 02:49, Paweł Hajdan, Jr. wrote:
Please review attached automatically generated stabilizatiocandidates
for January.

 

# mpagano kernel-misc
sys-kernel/linux-docs-3.6.

I'll do this for the just committed version linux-docs-3.6.11. What I will do 
for now on is change our stabilization procedure for kernels to include 
opening up a bug to stabilize the corresponding linux-docs version.

So going forward, you can exclude this and hopefully we'll do a better job of 
keeping this package stable.

-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] default mta

2012-12-26 Thread Mike Pagano
On Wednesday, December 26, 2012 09:46:17 AM Eray Aslan wrote:
 The current default mta in gentoo - ssmtp - has a more or less dead
 upstream and has some outstanding bugs.  It is prudent to change our
 default mta.
 
 Both mail-mta/nullmailer and mail-mta/msmtp are lightweight good mtas.
 Both packages have active development and provide AUTH and SSL/TLS
 support.
 
 Our current mta list is:
 mail-mta/ssmtp
 mail-mta/courier
 rest of the list
 ...
 
 As net-mail herd, we would like to have the following mta list:
 mail-mta/nullmailer
 mail-mta/msmtp
 mail-mta/ssmtp
 rest of the list
 ...
 
 If there are no objections, the above change will be committed in ~10
 days.
 
 

Would it be prudent to coordinate Gentoo documentation changes with the above?

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Team Lead - Gentoo Sources
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] systemd project created.

2011-06-21 Thread Mike Pagano
On Tuesday, June 21, 2011 05:43:10 AM Michał Górny wrote:
 Hello,
 
 I'd like to announce that I've created an initial project page for
 Gentoo systemd project [1].
 
 The main purpose of that project page would be keeping docs for systemd
 users in Gentoo. Hopefully, we will include some soon. If anyone is
 interested in helping out, we'd be grateful.
 
 We won't be probably maintaining many packages, thus I'm not adding
 a herd. We can be reached through systemd@g.o alias though.
 
 [1] http://www.gentoo.org/proj/en/systemd/
 
 

Thank-you for you and the team's hard work on this. Installed and running great 
over here.



Re: [gentoo-dev] rfc: use of the /run directory

2011-05-20 Thread Mike Pagano
On Friday 20 May 2011 04:58:12 Luca Barbato wrote:
 On 5/17/11 6:57 PM, William Hubbs wrote:
 That shouldn't be read as endorsing the peculiar and conceptually broken 
 init replacement called systemd.
 
 lu

Just curious, would you mind elaborating on it's peculiarities and conceptual 
brokenness?



Re: [gentoo-dev] gentoo-src cvs repo and svn repos migration to git

2011-01-31 Thread Mike Pagano
On Mon, Jan 31, 2011 at 04:54:47AM +0200, Theo Chatzimichos wrote:
 Hello,
 
 I'd like to point me out the ones that are still active, and you (the 
 maintainer(s)) want to be migrated to git. In that case, I'll contact you for 
 any additional info I will need, such as the structure of the git repo or any 
 hooks I should be aware of.
 Thanks
 -- 
 Theo Chatzimichos (tampakrap)
 Gentoo KDE/Qt, Planet, Overlays


linux-patches is still active and I would like it to remain in svn. 

Thanks.


-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



[gentoo-dev] Kernel maintainers that use genpatches

2010-11-22 Thread Mike Pagano
For all the kernel maintainers that use genpatches in their kernel
package, please make sure you are subscribed to gentoo-kernel so that I
know I can reach all of you easily.

Thanks,
-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] Going inactive

2010-09-27 Thread Mike Pagano
 Hi,
 
 I've been too busy with other things to work on Gentoo for quite some 
 time and this isn't going to change now that I've just picked up new 
 study and work commitments.

As I said in private, I will repeat here. Thanks for mentoring me into Gentoo 
and answering all of my questions along the way.  You set an example with your 
intelligence in technical matters and patience with users that goes years 
beyond your age.  

You will be missed and I hope you find your way back here someday. 

Best regards,
Mike

--
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] Gentoo Council 2010/2011 - Nominations are now open

2010-06-15 Thread Mike Pagano
 I nominate the following developers
 
 *mpagano

Thank-you, Markos, for your vote of confidence. I am honored and flattered but 
even though I thoroughly enjoy my work on Gentoo, my current full time job 
leaves little free time and I feel a council member really needs to dedicate 
time to enable positive change.

Thanks, again.
MIke


Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: Notify people about empty herds (Was: Re: [gentoo-dev] FTR: media-opti...@g.o has no developers)

2010-06-03 Thread Mike Pagano
On Thursday, June 03, 2010 10:44:10 am Markos Chandras wrote:
  kernel can merge with kernel-misc. 

Please don't do this.



Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project

2010-04-09 Thread Mike Pagano
Here's one possible use-case.

For me, I would consider moving 
http://dev.gentoo.org/~mpagano/genpatches/index.htm to the official wiki so 
that other people in the kernel herd can update it.

If the updating could be scripted, of course.

I would not have considered it for an unofficial wiki running on nonGentoo 
infrastructure. We've been looking for a new 'home' for awhile. [1]

[1]http://bugs.gentoo.org/show_bug.cgi?id=176186

---
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



[gentoo-dev] gentoo-sources 2.6.32 stable plans

2010-02-24 Thread Mike Pagano
I'm planning to request the stabling of gentoo-sources-2.6.32 on March 5th,
a little more than 1 week from now. We have a few regressions we are 
tracking but they are not far reaching and most are close to resolution. We 
will follow up on all unresolved regressions.

Regressions in external packages in the stable tree are tracked in bug 
#300324. If any arise, please make every effort to fix these.

Thanks,
Mike Pagano

Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] 2.6.31 stable plans

2009-11-04 Thread Mike Pagano
I'm planning to request the stabling of gentoo-sources-2.6.31 on November 
13th, a little more than 1 week from now. We have a few regressions we are 
tracking but they are not far reaching and most are close to resolution. We 
will follow up on all unresolved regressions.

Regressions in external packages in the stable tree are tracked in bug 
#291927. If any arise, please make every effort to fix these.

Thanks,
Mike Pagano

-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] 2.6.30 stable plans

2009-07-22 Thread Mike Pagano
On Wed, Jul 15, 2009 at 10:28:18AM -0400, Mike Pagano wrote:
 I'm planning to request the stabling of gentoo-sources-2.6.30 on July
 22nd, 1 week from now. We have no known regressions in the kernel.
 
 
 Thanks,
 Mike Pagano
 


Due to serious patches released, the new plan is too release a 
gentoo-sources-2.6.30-r4 which contains the
latest 2.6.30.x from upstream and then ask for stable about a week after that.

Thanks,
Mike





[gentoo-dev] 2.6.30 stable plans

2009-07-15 Thread Mike Pagano
I'm planning to request the stabling of gentoo-sources-2.6.30 on July
22nd, 1 week from now. We have no known regressions in the kernel.

Regressions in external packages in the stable tree are tracked in bug 
#277944. If any arise, please make every effort to fix these.

Thanks,
Mike Pagano



[gentoo-dev] Linux 2.6.28 stabilization plans

2009-04-11 Thread Mike Pagano
Hello,

The kernel team is tentatively planning to request that gentoo-sources-2.6.28 
gets marked stable on x86+amd64 on May 3rd, assuming we have fixed all 
regressions (we have some open, which will hopefully be fixed soon).

We currently only have one open out-of-kernel package bug.  This bug, and 
additional closed ones that were broken by this upgrade, are tracked at 
https://bugs.gentoo.org/show_bug.cgi?id=252467

Please help us fix this in the stable tree in advance of the stabling date.

Thanks,
Mike

-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [RFC] Change to kernel-2.eclass for bug #233266

2008-08-25 Thread Mike Pagano
On Monday 25 August 2008 15:00:24 Mike Frysinger wrote:
 On Saturday 23 August 2008, Mike Pagano wrote:
  After querying some folks in #gentoo-portage concerning bug #233266[1],
  it was suggested to me to add the entire /usr/src to PRELINK_PATH_MASK.
 

 why dont we merge it into the prelink package
 -mike

Mike,

This would be great. I believe you're suggesting to include /usr/src within 
the 60prelink file.   If my comprehension is correct, please let me know if 
you want me to submit a bug or anything else I can do to make this happen..

-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins

2008-08-06 Thread Mike Pagano
On Wednesday 06 August 2008 17:18:05 Robin H. Johnson wrote:
 Hi folks,

 Sorry that it's taken this long to get completed, but the Jeeves
 replacement, Willikins, is finally 99% done, and ready to join lots of
 channels.


#gentoo-kernel

Thanks to everyone involved.

-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



[gentoo-dev] Last rites: dev-util/lincvs

2008-05-19 Thread Mike Pagano
Mike Pagano [EMAIL PROTECTED] (19 May 2008)
Masked for removal in 30 days.  Upstream has changed
name to crossvc, which is available in the tree.
(bug #213496)

---

Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Monthly Gentoo Council Reminder for April

2008-04-07 Thread Mike Pagano
On Monday 07 April 2008 04:37:18 pm Petteri Räty wrote:
 Petteri Räty kirjoitti:
  
 So I wrote a new slacker script that gets the active developers from 
 LDAP and checks the activity for the last 60 days. One repoman commit 
 should equal a couple entries on history but not sure on that. robbat2 
 succested that we add the info to LDAP on who is expected to have 
 commits so purely infra people would not show up. Current slacker script 
 has the info hard coded. Posting to public as the info is available via 
 anoncvs for example any way.
 
 
 [EMAIL PROTECTED] ~ $ python slacker.py /var/cvsroot/CVSROOT/history
 snip

I may be incorrect but I do believe I see some 'staff' level people without 
commit access on the list. We may want to exclude them along with the infra 
folks, also.
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Downtime: lists.gentoo.org migration

2008-01-03 Thread Mike Pagano
On Thursday 03 January 2008 07:51:35 pm Robin H. Johnson wrote:
 snip  
 I'm aiming to do the bulk of the changeover around 05h00 UTC Sunday (Jan
 6th) morning, and all that should be visible is some delays in mail
 processing.
 

Thanks to you and everyone in your team for their time and efforts.  It is 
appreciated.

-- 
Mike Pagano 
[EMAIL PROTECTED]
GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] New ALSA maintainers

2007-03-28 Thread Mike Pagano

On 3/28/07, Daniel Drake [EMAIL PROTECTED] wrote:

 snip 

...here are the diffs of the
latest alsa development release vs the latest kernel development release:


 snip

Just a user opinion here, but I find the need to use unstable
alsa-driver to solve a bug every now and then.  This procedure would
be more complicated if I had to run a development kernel to solve a
sound problem.
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: 2.6.18 going stable in 1 week

2006-10-20 Thread Mike Pagano

On 10/20/06, Daniel Drake [EMAIL PROTECTED] wrote:

Christian Faulhammer wrote:
  Announce it here (or -core) which needs a fix and then just commit the
 fix if it is trivial and there has been no reaction.

I think you didn't grasp the problem exactly.

There are a large number of packages which build against the kernel and
do not get much attention from their maintainers. To avoid too many
sharp objects coming in my direction when a new kernel goes stable, I
spend a lot of time providing fixes for these packages.

The problem is that this (i.e. producing the fixes) is a big waste of
time on my part, I'd rather work on real kernel stuff which is lagging
behind.

Daniel
--
gentoo-dev@gentoo.org mailing list




This seems to me like a good opportunity to engage the arch teams for
some assistance.
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

2006-10-04 Thread Mike Pagano

On 10/4/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

On Wed, 2006-10-04 at 12:21 -0700, Donnie Berkholz wrote:
 Donnie Berkholz wrote:
  Chris Gianelloni wrote:
  Now, perhaps what everyone would like, instead, would be status reports
  *where necessary* from certain projects?
 
  In fact, the council has been discussing asking a few projects about the
  status on some of their tasks.  The main reason for this is for
  communications purposes.  Basically, we'd just get a Hey, where are you
  at on $x? response from the teams.
 
  I don't *want* to drown projects in bureaucracy and paperwork.  I want
  them to *accomplish* things, instead.
 
  I really like the concept of answering questions rather than giving
  arbitrary reports. The problem is, sometimes nobody outside your project
  knows the right questions to ask.

 I was thinking more about this. What if, instead of these periodic
 status reports, you just send out a note when something interesting
 happens? There's no point in holding it back till your monthly required
 report, and it saves the trouble of the report when nothing's happening.

That's really a good idea.  When I was writing, I was thinking more
along the lines of things like:

What's the status of bugs getting updated?
What's the status of anonsvn/anoncvs?
What's the status of QA's policy document?

These are things that either are interesting to a large number of
developers, and easier to answer once rather than 300 times, or things
the council itself has asked a group to do based on one of our
decisions.  Of course, we could/would take ideas for things to ask, and
again, all we need really is something like this (mock) answer:

Well, we have all the hardware in place and have gotten access to the
systems.  We've installed the OS and setup the main databases, but we're
still having some issues with the virtual IP scheme, and that's slowing
us down on getting this implemented.

That's it.  No long report or anything is necessary.  Just a simple,
short few sentences on the current status is all that's really needed
for the long ongoing projects.  For other things, like, xorg 7.1 going
stable or KDE 3.5.5 being unmasked, a simple announcement from the team
when it happens should really cover it.  That isn't even necessary from
most projects, as they simply do maintenance tasks which don't really
need an announcement.

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation





How about something in the planet format that where each group
reporting status could do so at their schedule when they feel an
update is necessary or warrented.

Then users could just read the website for the latest status updates.

There are a few hot items many people are interested in such as kde
or gnome stablization, for example.  A simple line like Don't expect
KDE 5.0 to go stable before the end of the year provides transparency
and a bit of communication to the user community.
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] treecleaner removals

2006-09-28 Thread Mike Pagano

On 9/28/06, Mark Stier [EMAIL PROTECTED] wrote:

How about entering the removed ebuilds into bugzilla under an adequate section?
--
gentoo-dev@gentoo.org mailing list




In the event of tree booting, you have the option to maintain the
ebuild in an overlay such as sunrise[1]. Or seeking out some
interested party to do so for you.


[1]http://www.gentoo.org/proj/en/sunrise/
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] seeds, GLEPs, and projects

2006-09-21 Thread Mike Pagano

On 9/21/06, Simon Stelling [EMAIL PROTECTED] wrote:

Ciaran McCreesh wrote:
 Huge amounts of time, effort and users. How much arch team time was
 spent fixing genkernel? How much time was spent fixing the OS X mess?
 How many users did we lose as a result of all the QA screwups?

Eh, I wanted answers, not more questions :P

 As much as I hate relying upon slashdot for anything reasonable at all,
 an awful lot of people in that thread were suggesting that more time be
 spent on QA and fixing existing bugs and much less on fancy new
 things...

These users are ignoring the fact that time is not the only and most
important factor. Motivation is far more important IMO, and it's pretty
hard to get the motivation together to test 60 packages instead of
tinkering around with a new idea. At least for me it often is.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list




Maybe a recruiting drive to help with the maintenance.  A typical
business brings on new blood and assigns them just that role to free
up more senior developers for more complicated projects.

New developers should definitely meet a standard, but the possibility
of bringing developers with energy and potential to assist in
maintenance might be worth a consideration.
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] question about non-dev submitting snapshot ebuild to bugzilla

2005-05-23 Thread Mike Pagano
I am working on a new ebuild for a currently open bug in bugzilla.

This ebuild happens to be a snapshot as upstream provides anonymous
web cvs but does not provide a nice tar.

When a non-dev submits a snapshot ebuild to bugzilla  what is the
proper method of providing access to the snapshot I created myself
that it installs.

Even though this tar is fairly small (128k), I imagine that if I
attached the snapshot, the big giant hand of common sense would
descend and slap me silly.

Please advise.

Mike

-- 
gentoo-dev@gentoo.org mailing list