Re: [gentoo-dev] Ebuild Generators (Was: GSoC 2020: Call for mentors and project ideas)

2020-02-03 Thread Gerion Entrup
Am Montag, 3. Februar 2020, 05:20:42 CET schrieb Benda Xu: > Gerion Entrup writes: > > > I saw the idea „Big Data Infrastructure by Gentoo“ and found it kind of > > interesting. However, I have a little bit the fear that a full automation > > won't be possible and the whole project becomes a litt

Re: [gentoo-dev] Ebuild Generators

2020-02-03 Thread Benda Xu
Hi Gerion, Gerion Entrup writes: >> Yes, that makes a lot of sense. The R overlay follows this model. Most >> of the ebuilds are automated. When an ebuild generation fails, we add >> the ebuild manually, understand it and then update the generator to >> cover it in the future. > > Is this pos

Re: [gentoo-dev] Ebuild Generators

2020-02-03 Thread Michael 'veremitz' Everitt
On 03/02/20 12:19, Benda Xu wrote: > Hi Gerion, > > Gerion Entrup writes: > >>> Yes, that makes a lot of sense. The R overlay follows this model. Most >>> of the ebuilds are automated. When an ebuild generation fails, we add >>> the ebuild manually, understand it and then update the generator t

Re: [gentoo-dev] Ebuild Generators

2020-02-03 Thread Gerion Entrup
Am Montag, 3. Februar 2020, 13:19:52 CET schrieb Benda Xu: > Hi Gerion, > > Gerion Entrup writes: > > >> Yes, that makes a lot of sense. The R overlay follows this model. Most > >> of the ebuilds are automated. When an ebuild generation fails, we add > >> the ebuild manually, understand it an

Re: [gentoo-dev] Ebuild Generators

2020-02-03 Thread Michał Górny
On Mon, 2020-02-03 at 14:20 +0100, Gerion Entrup wrote: > Am Montag, 3. Februar 2020, 13:19:52 CET schrieb Benda Xu: > > Hi Gerion, > > > > Gerion Entrup writes: > > > > > > Yes, that makes a lot of sense. The R overlay follows this model. Most > > > > of the ebuilds are automated. When an eb

Re: [gentoo-dev] Last rites: app-mobilephone/lightblue

2020-02-03 Thread Robin H. Johnson
On Fri, Jan 31, 2020 at 04:24:31PM +, Robin H. Johnson wrote: > > The Python team no longer wishes to maintain the following package: > > > > dev-python/pybluez > > > > It has no tests, and it'd be better for it to have a dedicated > > maintainer with working bluez and possible a use case for

Re: [gentoo-dev] Last rites: app-mobilephone/lightblue

2020-02-03 Thread Michał Górny
On Mon, 2020-02-03 at 17:31 +, Robin H. Johnson wrote: > On Fri, Jan 31, 2020 at 04:24:31PM +, Robin H. Johnson wrote: > > > The Python team no longer wishes to maintain the following package: > > > > > > dev-python/pybluez > > > > > > It has no tests, and it'd be better for it to have a

[gentoo-dev] Last-rites: dev-util/gquilt and dev-util/xesam-tools

2020-02-03 Thread Andreas Sturmlechner
# Andreas Sturmlechner (2020-02-03) # Ancient, no maintainer, py27-only, bug 708104. Masked for removal in 30 days. dev-util/gquilt # Andreas Sturmlechner (2020-02-03) # Ancient, no maintainer, py27-only. Masked for removal in 30 days. dev-util/xesam-tools

[gentoo-dev] Last-rites: x11-misc/googsystray

2020-02-03 Thread Andreas Sturmlechner
# Andreas Sturmlechner (2020-02-03) # No maintainer, py27-only, broken at runtime, last release in 2010. # Masked for removal in 30 days. x11-misc/googsystray

[gentoo-dev] Last-rites: app-misc/pystopwatch

2020-02-03 Thread Andreas Sturmlechner
# Andreas Sturmlechner (2020-02-03) # No maintainer, py27-only, blocks pygtk-removal, last release in 2012. app-misc/pystopwatch

Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?

2020-02-03 Thread Kent Fredric
On Thu, 30 Jan 2020 08:19:08 -0500 Rich Freeman wrote: > Really the main threat (IMO) is that the code could be de-copylefted. > They could make GPL v4 a copy of the BSD license, and now anything > that was v2+ is effectively BSD and can be used in non-FOSS software > without issue. I guess that