Re: [gentoo-dev] Herd likely up for grabs: kernel-misc

[Lars Wendler]

Hi guys,

On Wed, 20 Jan 2016 13:40:04 -0500 Mike Frysinger wrote:

>On 20 Jan 2016 12:39, Rich Freeman wrote:
>> On Wed, Jan 20, 2016 at 12:34 PM, Mike Frysinger 
>> wrote:  
>> > On 18 Jan 2016 00:57, Joshua Kinard wrote:  
>> >> On 01/17/2016 14:57, Michał Górny wrote:  
>> >> > sys-apps/kexec-tools :  
>> >>
>> >> Better suited for base-system, maybe?
>> >>  
>> >> > sys-fs/jfsutils  :  
>> >>
>> >> Definitely base-system, as xfsprogs is already maintained by
>> >> them.  
>> >
>> > sounds fine for both.  generally fs tools probably should live
>> > under base-system for consistency.  
>> 
>> Nothing wrong with consistency, but I'd prefer a package to be placed
>> under the base-system project because the base-system project members
>> intend to maintain it.  I don't want to see packages placed into
>> projects simply because they're similar to other packages in those
>> projects if it means they'll just be neglected.
>> 
>> I have no idea which is the case here.  If the base-system
>> maintainers want to maintain these two packages, have at it!  If
>> not, leave it as maintainer-needed.  
>
>if base-system@ isn't going to maintain it, we'll punt it from the herd
>-mike

well, I already added myself as maintainer of sys-fs/jfsutils and I
happen to be a base-system maintainer. So goal already reached :)

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpzZ8_9nS1tr.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Re: Herd likely up for grabs: kernel-misc

[Rich Freeman]

On Thu, Jan 21, 2016 at 1:06 AM, Mike Frysinger  wrote:
> On 20 Jan 2016 19:48, Duncan wrote:
>> Mike Frysinger posted on Wed, 20 Jan 2016 13:40:04 -0500 as excerpted:
>> > if base-system@ isn't going to maintain it, we'll punt it from the herd
>>
>> Umm, you mean project, right?  Because the whole discussion here is part
>> of getting rid of herds.  =:^)
>
> a distinction without a difference

And that would be why we're getting rid of them...

-- 
Rich

Re: [gentoo-dev] Herd up for grabs: net-dialup

[Lars Wendler]

Hi Mike,

On Wed, 20 Jan 2016 12:32:02 -0500 Mike Frysinger wrote:

>On 17 Jan 2016 21:57, Lars Wendler wrote:
>> I am going to take the following packages:
>> 
>> net-dialup/mingetty
>> net-dialup/ppp
>> net-dialup/rp-pppoe
>> 
>> I think that I might not be the perfect maintainer for these packages
>> (especially for ppp) so if anyone else wants to maintain these, feel
>> free to add yourself as well.  
>
>how about moving those to base-system@ ?

Sounds good. I already added myself to the packages, so please don't
just replace me yet.

>for the low level serial ones, we can move them to embedded since they
>get way more use there nowadays than w/dialup modems.
>app-misc/ckermit
>net-dialup/lrzsz
>net-dialup/minicom
>net-dialup/picocom
>net-dialup/xc
>-mike

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpvzBs59BVNV.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Lars Wendler]

Hi Dirkjan,

make it part of the news item please.

Kind regards
Lars

On Wed, 20 Jan 2016 13:16:19 +0100 Dirkjan Ochtman wrote:

>On Wed, Jan 13, 2016 at 6:13 PM, Dirkjan Ochtman 
>wrote:
>> After what feels like ages, we're just about ready to stabilize
>> apache-2.4. Since this is a major upgrade that in many cases require
>> configuration changes, we wanted to do a news item. After some
>> discussion with Lars (Poly-C), here's an initial attempt at a
>> draft.  
>
>I'm currently attempting this upgrade on a stable system I run. It
>mostly just works, although I run into trouble when trying to load
>modules that are not part of www-server/apache (e.g. mod_wsgi). I
>resolved this by reemerging all packages listed in `equery b
>/usr/lib/apache2/modules/*`, but maybe there's a different way? Should
>this be in an elog message, or part of the news item?
>
>Cheers,
>
>Dirkjan
>



-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpHvwXWc7nfa.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] [PATCH 13/15] cmake-utils.eclass: ban helper functions in EAPI 6 and later

[Michał Górny]

Dnia 20 stycznia 2016 11:43:11 CET, Michael Palimaka  
napisał(a):
>https://archives.gentoo.org/gentoo-dev/message/6ff6dedb44fff4289764dc5eb960e1c6
>
>Gentoo-bug: 514384
>---
> eclass/cmake-utils.eclass | 12 
> 1 file changed, 12 insertions(+)
>
>diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
>index 960b34b..507d27d 100644
>--- a/eclass/cmake-utils.eclass
>+++ b/eclass/cmake-utils.eclass
>@@ -161,6 +161,11 @@ unset CMAKEDEPEND
> _cmake_use_me_now() {
>   debug-print-function ${FUNCNAME} "$@"
> 
>+  local arg=$2
>+  [[ ! -z $3 ]] && arg=$3
>+
>+  has "${EAPI:-0}" 2 3 4 5 || die "${FUNCNAME[1]} is banned in EAPI 6
>and later: use -D$1${arg}=\"\$(usex $2)\" instead"
>+
>   local uper capitalised x
>   [[ -z $2 ]] && die "cmake-utils_use-$1  []"
>   if [[ ! -z $3 ]]; then
>@@ -178,6 +183,13 @@ _cmake_use_me_now() {
> _cmake_use_me_now_inverted() {
>   debug-print-function ${FUNCNAME} "$@"
> 
>+  local arg=$2
>+  [[ ! -z $3 ]] && arg=$3
>+
>+  if ! has "${EAPI:-0}" 2 3 4 5 && [[ "${FUNCNAME[1]}" !=
>cmake-utils_use_find_package ]] ; then
>+  die "${FUNCNAME[1]} is banned in EAPI 6 and later: use
>-D$1${arg}=\"\$(usex $2)\" insteadss"
>+  fi
>+
>   local uper capitalised x
>   [[ -z $2 ]] && die "cmake-utils_use-$1  []"
>   if [[ ! -z $3 ]]; then

I suggest making it more explicit what kind of helper functions are banned in 
the commit message.
-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Roy Bamford]

On 2016.01.21 16:53, William Hubbs wrote:
> On Tue, Jan 19, 2016 at 10:35:15AM -0800, Alec Warner wrote:
> > On Mon, Jan 18, 2016 at 9:44 PM, NP-Hardass 
> wrote:
> > 
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > With all of the unclaimed herds and unclaimed packages within
> them, I
> > > started to wonder what will happen after the GLEP 67 transition
> > > finally comes to fruition.  This left me with some concerns and I
> was
> > > wondering what the community thinks about them, and some possible
> > > solutions.
> > >
> > > There is a large number of packages from unclaimed herds that, at
> this
> > > time, look like they will not be claimed by developers.  This will
> > > likely result in a huge increase in maintainer-needed packages
> (and
> > > subsequent package rot).  This isn't to say that some of these
> > > packages weren't previously in a "maintainer-needed" like state,
> but
> > > now, they will explicitly be there.
> > >
> > 
> > Speaking as the dude who founded the treecleaners project...all
> things die.
> > Even software. While some may yearn for a software archive (nee,
> > graveyard!), I put forth that the gentoo-x86 tree is not such a
> thing. Do
> > not weep for the unmaintained packages that will be cleaned![1]
> 
> I couldn't have said this better myself. The gentoo-x86 tree is not a
> software archival service. If packages are unmaintained, that is what
> the treecleaners project is for is to boot those packages out of the
> tree.
> 
> I would like to see a possible timelimit set on how long packages can
> stay in maintainer-needed; once a package goes there, if we can't find
> someone to maintain it, we should consider booting it after that time
> limit passes.
> 
> If someone wants to run the graveyard overlay and keep those old
> packages around more power to them, but they definitely do not
> belong in the main tree if they are unmaintained for an extended
> period
> of time.
> 
> William
> 
> 

There is no point in removing unmaintained but perfectly functional software 
from the tree.
It needs to be both unmaintained and broken. Broken being evidenced by at least 
one open bug.

How would you define unmaintained?
Maybe its not changed for a year or two because there is no need for any 
maintenance?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpjSgX2JV8mk.pgp
Description: PGP signature

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Kristian Fiskerstrand]

On 01/21/2016 06:15 PM, Alexis Ballier wrote:
> On Thu, 21 Jan 2016 10:53:58 -0600
> William Hubbs  wrote:
> 
>> I would like to see a possible timelimit set on how long packages can
>> stay in maintainer-needed; once a package goes there, if we can't find
>> someone to maintain it, we should consider booting it after that time
>> limit passes.
> 
> Note that maintainer-needed doesn't necessarily mean package is crap.
> Some simply don't really need a maintainer because they just work.
> 
> 

However it can cause complications when issues are detected, in
particular security relevant ones. Attaching a CSV of bugs assigned to
security with maintainer-needed CCed.

e.g app-text/htmltidy has multiple reverse dependecies but is itself
maintainer needed with at least two vulnerabilities (bug 561452)

-- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
"Bug ID","Product","Component","Assignee","Status","Resolution","Summary","Changed"
571824,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","dev-db/firebird: authenticated remote crash by gbak invocation","2016-01-14 09:47:30"
537524,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","app-arch/ppmd: directory traversal","2016-01-10 17:07:17"
551144,"Gentoo Security","Vulnerabilities","security","IN_PROGRESS","---","

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 15/15] cmake-utils.eclass: update copyright year

[Michał Górny]

Dnia 20 stycznia 2016 11:43:13 CET, Michael Palimaka  
napisał(a):
>---
> eclass/cmake-utils.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
>index 70b70e2..9e8e71e 100644
>--- a/eclass/cmake-utils.eclass
>+++ b/eclass/cmake-utils.eclass
>@@ -1,4 +1,4 @@
>-# Copyright 1999-2015 Gentoo Foundation
>+# Copyright 1999-2016 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Id$
>

Now I'm being picky but this should have happened in the first commit.


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Alexis Ballier]

On Thu, 21 Jan 2016 10:53:58 -0600
William Hubbs  wrote:

> I would like to see a possible timelimit set on how long packages can
> stay in maintainer-needed; once a package goes there, if we can't find
> someone to maintain it, we should consider booting it after that time
> limit passes.

Note that maintainer-needed doesn't necessarily mean package is crap.
Some simply don't really need a maintainer because they just work.

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Alexis Ballier]

On Thu, 21 Jan 2016 18:25:21 +0100
Kristian Fiskerstrand  wrote:

> On 01/21/2016 06:15 PM, Alexis Ballier wrote:
> > On Thu, 21 Jan 2016 10:53:58 -0600
> > William Hubbs  wrote:
> >   
> >> I would like to see a possible timelimit set on how long packages
> >> can stay in maintainer-needed; once a package goes there, if we
> >> can't find someone to maintain it, we should consider booting it
> >> after that time limit passes.  
> > 
> > Note that maintainer-needed doesn't necessarily mean package is
> > crap. Some simply don't really need a maintainer because they just
> > work.
> > 
> >   
> 
> However it can cause complications when issues are detected, in
> particular security relevant ones. Attaching a CSV of bugs assigned to
> security with maintainer-needed CCed.
> 
> e.g app-text/htmltidy has multiple reverse dependecies but is itself
> maintainer needed with at least two vulnerabilities (bug 561452)
> 

well, 'not ( forall x, x is m-n, x is crap )' and 'exists x, x is
m-n, x is crap' don't necessarily disagree either :)

Re: [gentoo-dev] [PATCH 07/15] cmake-utils.eclass: replace replace comment_add_subdirectory with a namespaced version

[Michał Górny]

Dnia 20 stycznia 2016 11:43:05 CET, Michael Palimaka  
napisał(a):
>---
> eclass/cmake-utils.eclass | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
>diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
>index 1de863f..e8b24bd 100644
>--- a/eclass/cmake-utils.eclass
>+++ b/eclass/cmake-utils.eclass
>@@ -250,11 +250,11 @@ _generator_to_use() {
>   echo ${generator_name}
> }
> 
>-# @FUNCTION: comment_add_subdirectory
>+# @FUNCTION: cmake_comment_add_subdirectory
> # @USAGE: 
> # @DESCRIPTION:
># Comment out an add_subdirectory call in CMakeLists.txt in the current
>directory
>-comment_add_subdirectory() {
>+cmake_comment_add_subdirectory() {
> if [[ -z ${1} ]]; then
>die "comment_add_subdirectory must be passed the directory name to
>comment"
> fi
>@@ -265,6 +265,17 @@ comment_add_subdirectory() {
> fi
> }
> 
>+# @FUNCTION: comment_add_subdirectory
>+# @USAGE: 
>+# @DESCRIPTION:
>+# Comment out an add_subdirectory call in CMakeLists.txt in the
>current directory
>+# Banned in EAPI 6 and later - use cmake_comment_add_subdirectory
>instead.
>+comment_add_subdirectory() {
>+  has "${EAPI:-0}" 2 3 4 5 || die "comment_add_subdirectory is banned
>in EAPI 6 and later - use cmake_comment_add_subdirectory instead"
>+
>+  cmake_comment_add_subdirectory "$@"
>+}
>+
> # @FUNCTION: cmake-utils_use_with
> # @USAGE:  [flag name]
> # @DESCRIPTION:

Enough to 'replace' once :-P (commit message).
-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[William Hubbs]

On Tue, Jan 19, 2016 at 10:35:15AM -0800, Alec Warner wrote:
> On Mon, Jan 18, 2016 at 9:44 PM, NP-Hardass  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > With all of the unclaimed herds and unclaimed packages within them, I
> > started to wonder what will happen after the GLEP 67 transition
> > finally comes to fruition.  This left me with some concerns and I was
> > wondering what the community thinks about them, and some possible
> > solutions.
> >
> > There is a large number of packages from unclaimed herds that, at this
> > time, look like they will not be claimed by developers.  This will
> > likely result in a huge increase in maintainer-needed packages (and
> > subsequent package rot).  This isn't to say that some of these
> > packages weren't previously in a "maintainer-needed" like state, but
> > now, they will explicitly be there.
> >
> 
> Speaking as the dude who founded the treecleaners project...all things die.
> Even software. While some may yearn for a software archive (nee,
> graveyard!), I put forth that the gentoo-x86 tree is not such a thing. Do
> not weep for the unmaintained packages that will be cleaned![1]

I couldn't have said this better myself. The gentoo-x86 tree is not a
software archival service. If packages are unmaintained, that is what
the treecleaners project is for is to boot those packages out of the
tree.

I would like to see a possible timelimit set on how long packages can
stay in maintainer-needed; once a package goes there, if we can't find
someone to maintain it, we should consider booting it after that time
limit passes.

If someone wants to run the graveyard overlay and keep those old
packages around more power to them, but they definitely do not
belong in the main tree if they are unmaintained for an extended period
of time.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/21/2016 06:30 PM, Alexis Ballier wrote:
> On Thu, 21 Jan 2016 18:25:21 +0100 Kristian Fiskerstrand
>  wrote:
> 


>> However it can cause complications when issues are detected, in 
>> particular security relevant ones. Attaching a CSV of bugs
>> assigned to security with maintainer-needed CCed.
>> 
>> e.g app-text/htmltidy has multiple reverse dependecies but is
>> itself maintainer needed with at least two vulnerabilities (bug
>> 561452)
>> 
> 
> well, 'not ( forall x, x is m-n, x is crap )' and 'exists x, x is 
> m-n, x is crap' don't necessarily disagree either :)
> 

Indeed, however it does cause issues with assignment when security
vulnerabilities are reported, as nobody is CCed to handle it if m-n.
So this list needs to be actively maintained and treecleaning is
difficult with reverse deps involved.

... we might get around this by amending procedures to CC every
maintainer of reverse deps in these cases though (and if no rdep
simply treeclean it).

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWoRb4AAoJECULev7WN52F4ZMH/i4c5tSxJqgPmJY07c4qFkfL
N2cNWz+lRe9xr/VQxS9kLwG9IlqEJMMe4A6f2MvIeKwgN3A+HpLHQrEfK7we6Ctl
+wy25IxEWbfk8ajuXU89qYN29CIeZcunhcNkA/5WvZSI4fiakxMkP2aDq9nSl+t3
VJ5V54jVEQGvS4vBcR8hKSU7uW5fnwWFIRxV4TFeD+wQNEIDdF8dMEvvqdJUpKuj
5LzlLnXXjBW9vB53wM8n0BsufLVOK/xU1Cx8AJabqmoUX5O+NdlDTXks2r/yuVUk
YAze94Pb4oFKUSsQ0eHObr7vXXkpFQgwA4c4H0u75y5zAtaSDQFJ+8Fg7qIvb1k=
=NQwO
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Michał Górny]

On Thu, 21 Jan 2016 17:25:02 +
Roy Bamford  wrote:

> On 2016.01.21 16:53, William Hubbs wrote:
> > On Tue, Jan 19, 2016 at 10:35:15AM -0800, Alec Warner wrote:  
> > > On Mon, Jan 18, 2016 at 9:44 PM, NP-Hardass   
> > wrote:  
> > >   
> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA256
> > > >
> > > > With all of the unclaimed herds and unclaimed packages within  
> > them, I  
> > > > started to wonder what will happen after the GLEP 67 transition
> > > > finally comes to fruition.  This left me with some concerns and I  
> > was  
> > > > wondering what the community thinks about them, and some possible
> > > > solutions.
> > > >
> > > > There is a large number of packages from unclaimed herds that, at  
> > this  
> > > > time, look like they will not be claimed by developers.  This will
> > > > likely result in a huge increase in maintainer-needed packages  
> > (and  
> > > > subsequent package rot).  This isn't to say that some of these
> > > > packages weren't previously in a "maintainer-needed" like state,  
> > but  
> > > > now, they will explicitly be there.
> > > >  
> > > 
> > > Speaking as the dude who founded the treecleaners project...all  
> > things die.  
> > > Even software. While some may yearn for a software archive (nee,
> > > graveyard!), I put forth that the gentoo-x86 tree is not such a  
> > thing. Do  
> > > not weep for the unmaintained packages that will be cleaned![1]  
> > 
> > I couldn't have said this better myself. The gentoo-x86 tree is not a
> > software archival service. If packages are unmaintained, that is what
> > the treecleaners project is for is to boot those packages out of the
> > tree.
> > 
> > I would like to see a possible timelimit set on how long packages can
> > stay in maintainer-needed; once a package goes there, if we can't find
> > someone to maintain it, we should consider booting it after that time
> > limit passes.
> > 
> > If someone wants to run the graveyard overlay and keep those old
> > packages around more power to them, but they definitely do not
> > belong in the main tree if they are unmaintained for an extended
> > period
> > of time.
> > 
> > William
> > 
> >   
> 
> There is no point in removing unmaintained but perfectly functional software 
> from the tree.
> It needs to be both unmaintained and broken. Broken being evidenced by at 
> least one open bug.

That's nonsense. In fact, that's exactly the opposite of what should be
removed.

If I see a package that clearly doesn't build or otherwise simply
doesn't work, could not have worked for past 3 years, are you forcing
me to waste a time reporting a bug to no maintainer who could fix it?

Because to me, the lack of any open bugs is a clear evidence that
the package is not only unmaintained, but also unused.


-- 
Best regards,
Michał Górny



pgpvMDRjkN96q.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Paul Varner]

On 01/21/2016 06:52 AM, Lars Wendler wrote:
> Hi Dirkjan,
>
> make it part of the news item please.
>
> Kind regards
> Lars
>
> On Wed, 20 Jan 2016 13:16:19 +0100 Dirkjan Ochtman wrote:
>
>> On Wed, Jan 13, 2016 at 6:13 PM, Dirkjan Ochtman 
>> wrote:
>>> After what feels like ages, we're just about ready to stabilize
>>> apache-2.4. Since this is a major upgrade that in many cases require
>>> configuration changes, we wanted to do a news item. After some
>>> discussion with Lars (Poly-C), here's an initial attempt at a
>>> draft.  
>> I'm currently attempting this upgrade on a stable system I run. It
>> mostly just works, although I run into trouble when trying to load
>> modules that are not part of www-server/apache (e.g. mod_wsgi). I
>> resolved this by reemerging all packages listed in `equery b
>> /usr/lib/apache2/modules/*`, but maybe there's a different way? Should
>> this be in an elog message, or part of the news item?
>>
The simple command to do this is: emerge -av1 /usr/lib/apache2/modules
--exclude=www-servers/apache

Regards,
Paul

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[waltdnes]

On Thu, Jan 21, 2016 at 06:45:20PM +0100, Micha?? Górny wrote
> On Thu, 21 Jan 2016 17:25:02 +
> Roy Bamford  wrote:
> 
> > There is no point in removing unmaintained but perfectly functional
> > software from the tree.  It needs to be both unmaintained and broken.
> > Broken being evidenced by at least one open bug.
> 
> That's nonsense. In fact, that's exactly the opposite of what should
> be removed.
> 
> If I see a package that clearly doesn't build or otherwise simply
> doesn't work, could not have worked for past 3 years, are you forcing
> me to waste a time reporting a bug to no maintainer who could fix it?

  I think you misunderstood Roy.  He was speaking about "unmaintained
but perfectly functional software".  You're talking about "a package
that clearly doesn't build or otherwise simply doesn't work, could not
have worked for past 3 years".  Between those 2 extremes will be many
cases of doesn't-work-for-me/works-for-me.  Who'll be the final arbiter?

  Maybe we should start a "gentoo-ebuilds" mailing list to help regular
users learn the ins and outs of making ebuilds.  Once regular users run
a lot of their own ebuilds from their local overlays, then it would be
possible to do draconian pruning of the "official portage tree", without
so adversely affecting regular users.  This would fit in with the mantra
of Gentoo being about freedom of choice.

  E.g. I use Pale Moon, a fork of Firefox.  Currently, I have to build
as regular user, su, and copy the binary to /usr/local.  You can see
"Walter's excellent adventure"  as I learn the build process at...
https://forum.palemoon.org/viewtopic.php?f=37=10002

  I'd like to have Portage manage the process.  The ebuild from Firefox
should serve as a template, because they both use the same weird Mozilla
build setup.  The main change should be where the source is pulled from.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Rich Freeman]

On Thu, Jan 21, 2016 at 5:41 PM,   wrote:
>   I think you misunderstood Roy.  He was speaking about "unmaintained
> but perfectly functional software".  You're talking about "a package
> that clearly doesn't build or otherwise simply doesn't work, could not
> have worked for past 3 years".  Between those 2 extremes will be many
> cases of doesn't-work-for-me/works-for-me.  Who'll be the final arbiter?
>

I don't think we need any kind of formalized policy.  The treecleaners
can make a decision and there doesn't need to be any appeals.

The treecleaners should remove packages that are both unmaintained and
broken.  They don't have to have bugs open, and simply having a bug
open for a long time shouldn't be a reason to treeclean on its own.
If a package has a security issue or is just generally crippled then
it should be removed.  That might sound a bit subjective, but I don't
think that is a problem - if the treecleaners want to make a statement
of policy they can do so.

And if somebody disagrees with the treecleaners then they can go ahead
and volunteer to maintain the package.  Maintainers aren't actually
obligated to fix non-security bugs at all, by the way (though doing so
would certainly be nice).  But, they'll get to listen to all the grief
about problems they cause instead of the treecleaners.  Obviously if
things get out of hand there are ways to escalate.

In any case, I consider the labeling of these unmaintained packages as
maintainer-needed as a good thing, even if some get treecleaned as a
result.  Part of our social contract is not hiding problems.
Unmaintained packages should be clearly labeled as such.  And I'm all
for some suggestions that have been offered to hghlight packages they
use which are unmaintained (I'd suggest that instead of messing with
eclasses we simply put that feature in portage though).

-- 
Rich

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/21/2016 02:41 PM, waltd...@waltdnes.org wrote:
> On Thu, Jan 21, 2016 at 06:45:20PM +0100, Micha?? Górny wrote
>> On Thu, 21 Jan 2016 17:25:02 + Roy Bamford
>>  wrote:
>> 
>>> There is no point in removing unmaintained but perfectly
>>> functional software from the tree.  It needs to be both
>>> unmaintained and broken. Broken being evidenced by at least one
>>> open bug.
>> 
>> That's nonsense. In fact, that's exactly the opposite of what
>> should be removed.
>> 
>> If I see a package that clearly doesn't build or otherwise
>> simply doesn't work, could not have worked for past 3 years, are
>> you forcing me to waste a time reporting a bug to no maintainer
>> who could fix it?
> 
> I think you misunderstood Roy.  He was speaking about
> "unmaintained but perfectly functional software".  You're talking
> about "a package that clearly doesn't build or otherwise simply
> doesn't work, could not have worked for past 3 years".  Between
> those 2 extremes will be many cases of
> doesn't-work-for-me/works-for-me.  Who'll be the final arbiter?
> 
> Maybe we should start a "gentoo-ebuilds" mailing list to help
> regular users learn the ins and outs of making ebuilds.  Once
> regular users run a lot of their own ebuilds from their local
> overlays, then it would be possible to do draconian pruning of the
> "official portage tree", without so adversely affecting regular
> users.  This would fit in with the mantra of Gentoo being about
> freedom of choice.
> 
> E.g. I use Pale Moon, a fork of Firefox.  Currently, I have to
> build as regular user, su, and copy the binary to /usr/local.  You
> can see "Walter's excellent adventure"  as I learn the build
> process at... 
> https://forum.palemoon.org/viewtopic.php?f=37=10002
> 
> I'd like to have Portage manage the process.  The ebuild from
> Firefox should serve as a template, because they both use the same
> weird Mozilla build setup.  The main change should be where the
> source is pulled from.
> 

The idea sounds nice, but there's already the devmanual to cover
ebuild development, and now that the gentoo repo is in git, any
ebuilds that get treecleaned can be fetched again through history, and
users can then add those to their personal overlay(s) and keep the
piece if they break.

I like the idea of encouraging people to learn good ebuild writing,
but who really has the time and skill to teach it?

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

iQIcBAEBCAAGBQJWoXgPAAoJEAEkDpRQOeFwPvUP/1cOdVx0Mnm2yF6DU9BCXCzn
6LdE4/g05CnkggQkQEPsL6U+oiU/C2wu9nsSSRwrHNKEoIvly/pZEz75+FFoEnF5
RQTltJQi4lyG63bzaHYCx1nzmqAHBVbCBGDPqEC8whV8C8YAufk3SxqocBaIsD5Z
IbujCelJNGvRGBPmsIOD38aaVbcyJZFGG+m9nTTJyRQtdFGxfccE/K+xuZMLKFS/
BQkyJdAyvGscRBLAx80o5TgZ+h7BTNW78b8aIubWaeMyqYrvQhdwaDTK7xj0cb5M
uxC7fg493PphNLLYY5sL9yHPKtyJzuWhE6r9IXtMSH3b8sTEUU4cXxF4Ep1af+k0
9BafYy+vAxv6fM/3VS8KGcGCwElNrCiNLJYjEdW7mCDRFNQR8cja5IVRF8KGlXD3
33eKUviyPtx9LB5GNS2bZNSayeJbIENr1LsY2gZ4C6nfXUOzsUp7KhM4P4WmFKWV
TOn/DbigDQjMa07L0+G+cwvrc2X2QJWG8kstD16iARvaRAnlvlO+HQeSAtO1LWwU
7O44z0eQDxpGO6RZrBDVKNGe8dAaObQT+ueCL/sOHV2Co71Iz8zCu8z75OIhSWWM
8Tu4pa+doFetFLmOkfkcFTxuAjcxJAJomxnLD9rNcdjDtuWF2wxATdWFruFmYPm+
u0/PNb0YQg4Xx5M2qV63
=FxNx
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Michael Orlitzky]

On 01/21/2016 05:41 PM, waltd...@waltdnes.org wrote:
> 
>   Maybe we should start a "gentoo-ebuilds" mailing list to help regular
> users learn the ins and outs of making ebuilds.

Try gentoo-devhelp@lists.g.o, or the associated #gentoo-dev-help on IRC.

We should be trying to get these things proxy maintained at least since
they don't do anyone else any good in a personal overlay.

Re: [gentoo-dev] Herd likely up for grabs: kernel-misc

[Michał Górny]

On Sun, 17 Jan 2016 20:57:50 +0100
Michał Górny  wrote:

> Hello, everyone.
> 
> The current maintainers of kernel-misc herd so far haven't replied to
> our queries. If we don't get any reply in a week, we will be disbanding
> it and looking for new maintainers for its packages.
> 
> Is anyone interested in keeping the herd as a whole and maintaining all
> of its packages? If nobody replies till 2016-01-24, the herd will be
> automatically disbanded and I will be sending a complete list of
> packages needing maintainers.
> 
> Packages currently in herd along with their other maintainers:

Oh, there's also the three kernel-related eclasses. I think they should
to go kernel@ where most of the actual maintainers are.

-- 
Best regards,
Michał Górny



pgps61amsMqVD.pgp
Description: OpenPGP digital signature