Hi,
+1 for dev-python/ipcalc
I will update my issue as proxy maintainer for this if is ok.
Bye
On Mar 3, 2018 08:38, "Johann Schmitz (ercpe)" wrote:
> Hi,
>
> due to my retirement, the following packages need a new maintainer:
>
> dev-java/boilerpipe
> dev-libs/grok
> dev-python/cfgio
> dev-p
Hi,
due to my retirement, the following packages need a new maintainer:
dev-java/boilerpipe
dev-libs/grok
dev-python/cfgio
dev-python/disqus-python
dev-python/django-openid-auth
dev-python/django-opensearch
dev-python/django-otp
dev-python/django-otp-yubikey
dev-python/django-phonenumber-field
de
On Tue, Jan 17, 2017 at 04:45:39AM -0800, Daniel Campbell wrote:
> On 01/06/2017 12:46 PM, William L. Thomson Jr. wrote:
> > On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote:
> >>
> >> The nice thing about ::graveyard or similar is that its a clear demarcation
> >> between maintained (in
On 01/06/2017 12:46 PM, William L. Thomson Jr. wrote:
> On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote:
>>
>> The nice thing about ::graveyard or similar is that its a clear demarcation
>> between maintained (in tree) and unmaintained (graveyard.) It also means
>> that people doing act
On 06/01/17 17:14, Alec Warner wrote:
>
> Treecleaning to me is really two things:
>
> 1) developer maintenance time.
> a) It costs nothing to add packages to the tree, and the tree grows
> in size every year.
> b) Removals occur due to obsolescence (X replaces Y, etc) but these
> are strictly le
On 06/01/17 15:01, Rich Freeman wrote:
> On Thu, Jan 5, 2017 at 11:27 PM, Kent Fredric wrote:
>> If packages had a field called "BUGS=" it could contain an array of
>> bugs a package is known to contain, but can be conditionally avoided if
>> you're careful.
>>
>> Packages with non-empty BUGS= fie
On 06/01/17 04:27, Kent Fredric wrote:
> On Tue, 3 Jan 2017 10:23:02 -0500
> Rich Freeman wrote:
>
>> I tend to be firmly in the camp that a package shouldn't be removed
>> unless there is evidence of a serious bug (and that includes things
>> blocking other Gentoo packages).
> I would probably go
On Friday, January 6, 2017 9:13:20 AM EST Michael Mol wrote:
>
> The bigger resource drain, I suspect, will come from maintaining new ebuilds
> of old packages; as eclass development and maintenance seeks to eliminate
> old and buggy code, old ebuilds will need to be dragged along for the ride.
Th
On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote:
>
> The nice thing about ::graveyard or similar is that its a clear demarcation
> between maintained (in tree) and unmaintained (graveyard.) It also means
> that people doing actual maintenance work can basically ignore the
> graveyard as
On Fri, Jan 6, 2017 at 12:14 PM, Alec Warner wrote:
>
> So my understanding of the status quo is that maintainers get to make the
> call with regard to what is reasonable to keep or drop. I'm loathe to add
> additional policy here; mostly because the expectation is that the
> maintainer has the mo
On Thu, Jan 5, 2017 at 8:27 PM, Kent Fredric wrote:
> On Tue, 3 Jan 2017 10:23:02 -0500
> Rich Freeman wrote:
>
> > I tend to be firmly in the camp that a package shouldn't be removed
> > unless there is evidence of a serious bug (and that includes things
> > blocking other Gentoo packages).
>
>
On Thu, Jan 5, 2017 at 11:27 PM, Kent Fredric wrote:
>
> If packages had a field called "BUGS=" it could contain an array of
> bugs a package is known to contain, but can be conditionally avoided if
> you're careful.
>
> Packages with non-empty BUGS= fields would be treated as hard-masked
> for th
On Friday, January 6, 2017 5:27:24 PM EST Kent Fredric wrote:
> On Tue, 3 Jan 2017 10:23:02 -0500
>
> Rich Freeman wrote:
> > I tend to be firmly in the camp that a package shouldn't be removed
> > unless there is evidence of a serious bug (and that includes things
> > blocking other Gentoo packa
Ühel kenal päeval, N, 05.01.2017 kell 22:00, kirjutas Daniel Campbell:
> I'm in favor of keeping software around until it breaks. When there's
> a
> non-existent upstream and nobody's willing to take up the helm
> themselves, it's a clear indication that it's in danger of being
> treecleaned. In so
On 01/03/2017 06:31 AM, M. J. Everitt wrote:
> On 03/01/17 11:05, Michał Górny wrote:
>> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
>> gro...@gentoo.org wrote:
>>
>>> On Mon, 2 Jan 2017, Brian Evans wrote:
IMO, this one should be given last-rites as upstream is dead and it
heavily depends on
On Wed, 04 Jan 2017 05:11:18 +0200
Mart Raudsepp wrote:
> I believe with this mgorny has given ample proof that he is just a
> ciaranm sock puppet account.
One neat trick is to have *two* sock puppet accounts, and then have one
accuse the other of being a sock puppet, which typically leads peop
On Tue, 3 Jan 2017 10:23:02 -0500
Rich Freeman wrote:
> I tend to be firmly in the camp that a package shouldn't be removed
> unless there is evidence of a serious bug (and that includes things
> blocking other Gentoo packages).
I would probably go further and extend that argument to older versi
On 03/01/2017 15:24, Damien LEVAC wrote:
>
>
> On 01/03/2017 09:14 AM, Michael Mol wrote:
>> On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
>>> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
>>>
>>> gro...@gentoo.org wrote:
On Mon, 2 Jan 2017, Brian Evans wrote:
> IMO, this o
Ühel kenal päeval, T, 03.01.2017 kell 09:34, kirjutas Damien LEVAC:
>
> On 01/03/2017 09:31 AM, M. J. Everitt wrote:
> >
> > On 03/01/17 11:05, Michał Górny wrote:
> > >
> > > On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> > > gro...@gentoo.org wrote:
> > >
> > > >
> > > > On Mon, 2 Jan 2017, Brian
On 01/03/2017 09:10 AM, Kristian Fiskerstrand wrote:
> On 01/03/2017 03:57 PM, Michael Mol wrote:
>> For security's sake, even mature software needs, at minimum, routine
>> auditing.
>> Unless someone's doing that work, the package should be considered for
>> removal. (Call that reason # π, in h
On 01/03/2017 09:11 AM, Damien LEVAC wrote:
> But routine auditing, while being wishful thinking in the open-source
> world (even when the projects are alive), are not meant to find those
> kind of bugs anyway (and wouldn't be effective at doing so either).
>
I think it's wishful thinking in ever
On 01/03/2017 10:41 AM, Alice Ferrazzi wrote:
On Wed, Jan 4, 2017 at 12:23 AM, Rich Freeman wrote:
On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol wrote:
For security's sake, even mature software needs, at minimum, routine auditing.
Unless someone's doing that work, the package should be conside
On Tue, Jan 3, 2017 at 11:09 AM, Michael Mol wrote:
>
> Ideas like this is one reason I'm looking for a corpus of pros and cons for
> treecleaning. I don't see it as black and white. But having ideas like these
> brought up is at least useful.
>
Sure, and almost any rule has its exceptions. My t
On Tuesday, January 3, 2017 10:23:02 AM EST Rich Freeman wrote:
> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol wrote:
> > For security's sake, even mature software needs, at minimum, routine
> > auditing. Unless someone's doing that work, the package should be
> > considered for removal. (Call that
On Wed, Jan 4, 2017 at 12:23 AM, Rich Freeman wrote:
> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol wrote:
>>
>> For security's sake, even mature software needs, at minimum, routine
>> auditing.
>> Unless someone's doing that work, the package should be considered for
>> removal. (Call that reaso
On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol wrote:
>
> For security's sake, even mature software needs, at minimum, routine auditing.
> Unless someone's doing that work, the package should be considered for
> removal. (Call that reason #π, in honor of TeX.)
>
Are you suggesting that we should
On 03/01/17 14:57, Michael Mol wrote:
> On Tuesday, January 3, 2017 9:24:19 AM EST Damien LEVAC wrote:
>> On 01/03/2017 09:14 AM, Michael Mol wrote:
>>> On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
gro...@gentoo.org wrote:
>>
On 01/03/2017 09:57 AM, Michael Mol wrote:
On Tuesday, January 3, 2017 9:24:19 AM EST Damien LEVAC wrote:
On 01/03/2017 09:14 AM, Michael Mol wrote:
On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
gro...@gentoo.org wrote:
On Mon, 2 Ja
On 01/03/2017 03:57 PM, Michael Mol wrote:
> For security's sake, even mature software needs, at minimum, routine
> auditing.
> Unless someone's doing that work, the package should be considered for
> removal. (Call that reason # π, in honor of TeX.)
A distinction here likely needs to be made
On Tuesday, January 3, 2017 9:24:19 AM EST Damien LEVAC wrote:
> On 01/03/2017 09:14 AM, Michael Mol wrote:
> > On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
> >> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> >>
> >> gro...@gentoo.org wrote:
> >>> On Mon, 2 Jan 2017, Brian Evans wrot
On 01/03/2017 09:31 AM, M. J. Everitt wrote:
On 03/01/17 11:05, Michał Górny wrote:
On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
gro...@gentoo.org wrote:
On Mon, 2 Jan 2017, Brian Evans wrote:
IMO, this one should be given last-rites as upstream is dead and it
heavily depends on wireless-tools a
On 03/01/17 11:05, Michał Górny wrote:
> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> gro...@gentoo.org wrote:
>
>> On Mon, 2 Jan 2017, Brian Evans wrote:
>>> IMO, this one should be given last-rites as upstream is dead and it
>>> heavily depends on wireless-tools and WEXT.
>> I use it on 2 notebook
On 01/03/2017 09:14 AM, Michael Mol wrote:
On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
gro...@gentoo.org wrote:
On Mon, 2 Jan 2017, Brian Evans wrote:
IMO, this one should be given last-rites as upstream is dead and it
heavily depe
On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
>
> gro...@gentoo.org wrote:
> > On Mon, 2 Jan 2017, Brian Evans wrote:
> > > IMO, this one should be given last-rites as upstream is dead and it
> > > heavily depends on wireless-tools and WE
Hi,
On Tue, 3 Jan 2017 16:00:52 +0700 (+07) gro...@gentoo.org wrote:
>On Mon, 2 Jan 2017, Brian Evans wrote:
>> IMO, this one should be given last-rites as upstream is dead and it
>> heavily depends on wireless-tools and WEXT.
this is plain wrong. Upstream is not dead, just not very active any
On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
gro...@gentoo.org wrote:
> On Mon, 2 Jan 2017, Brian Evans wrote:
> > IMO, this one should be given last-rites as upstream is dead and it
> > heavily depends on wireless-tools and WEXT.
> I use it on 2 notebooks. It works fine, and is (from my point of vie
On Mon, 2 Jan 2017, Brian Evans wrote:
IMO, this one should be given last-rites as upstream is dead and it
heavily depends on wireless-tools and WEXT.
I use it on 2 notebooks. It works fine, and is (from my point of view) the
most convenient tool to control ethernet and wifi connections on a
no
On 01/01/2017 12:16 PM, Lars Wendler wrote:
> Hi Thomas,
>
> On Sat, 31 Dec 2016 22:54:28 +0100 Thomas Kahle wrote:
>
>> Hi,
>>
>> I will retire, so here are my remaining packages.
>
> Sad day seeing another dev leaving :-(
>
>> net-misc/wicd
>
> I can take this one if nobody else is interest
Hi Thomas,
On Sat, 31 Dec 2016 22:54:28 +0100 Thomas Kahle wrote:
>Hi,
>
>I will retire, so here are my remaining packages.
Sad day seeing another dev leaving :-(
>net-misc/wicd
I can take this one if nobody else is interested in it.
>Cheers,
>Thomas
>
>
I wish you all the best and if you
On Sun, 1 Jan 2017 10:42:51 +0100
Thomas Kahle wrote:
> On 01/01/2017 00:00, James Le Cuirot wrote:
> > On Sat, 31 Dec 2016 22:54:28 +0100
> > Thomas Kahle wrote:
> >
> >> I will retire
> >
> > Sorry to hear that. :(
> >
> >> app-text/tesseract
> >
> > I maintain media-libs/leptonica
On 01/01/2017 00:00, James Le Cuirot wrote:
> On Sat, 31 Dec 2016 22:54:28 +0100
> Thomas Kahle wrote:
>
>> I will retire
>
> Sorry to hear that. :(
>
>> app-text/tesseract
>
> I maintain media-libs/leptonica, which is primarily in the tree because
> of Tesseract. I don't use Tesseract myself
On Sat, 31 Dec 2016 22:54:28 +0100
Thomas Kahle wrote:
> I will retire
Sorry to hear that. :(
> app-text/tesseract
I maintain media-libs/leptonica, which is primarily in the tree because
of Tesseract. I don't use Tesseract myself though and it's not a
trivial package to maintain so I'd rather
Hi,
I will retire, so here are my remaining packages. Feel free to
e-mail me any questions re this. sci-math is in CC because there
are quite a few math packages.
app-emacs/undo-tree
app-misc/anki
app-portage/tatt
app-text/tesseract
app-text/pdfsandwich
dev-cpp/gtest
dev-python/python-wpactrl
d
43 matches
Mail list logo
