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 isn't any worse than the previous case of
> it instead being merged into some other v4 variant that you can access
> the source for but prefer to avoid because of something else in the
> license, except now you might not see the code at all.

Its like we need some sort of statement people can use that says
something to the effect of:

- GPL versions published after this release may be used, but contingent
  on the author of this release verifying that newer GPL versions continue the
  intended spirit of GPL2

The idea that my code might be later under some other terms of license
that I've never read is about as bad as somebody updating EULA/TOS
without informing anybody it changed.

Its *probably* fine, but I'd want to have opportunity to read those
before rubber stamping it.

As they say: Trust, but Verify.

GPL terms changing after an authors death should not really apply
retroactively to the dead authors code.


pgppHmDJ7BLMD.pgp
Description: OpenPGP digital signature


[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





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





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 dedicated
> > > maintainer with working bluez and possible a use case for one of its
> > > reverse dependencies:
> > I'm using lightblue for rapid development to reverse-engineer/test
> > behavior of some Bluetooth devices. Mostly as there was NOTHING else
> > that made it easy to get it done.
> > 
> > I don't care for the other reverse deps, but I'm willing to port
> > lightblue to py3 and bump pybluez.
> I reviewed most of the dev-python/lightblue codebase over my flights,
> and hereby recind my intent to port it to py3.
> 
> I converted my coding to Golang's bluetooth instead.
> 
> > > app-mobilephone/ganyremote
> > > app-mobilephone/wammu
> > > kde-misc/kanyremote
> > Is anybody willing to maintain these 3?
> > If not, lastrite them subject to upstream not doing the 2.7 ports.
> Please last-rite dev-python/lightblue with these.
> 
> I think dev-python/pybluez can stay for the moment, as it's maintained
> upstream. I'll keep pybluez if there are no other maintainers.

pybluez supports python3.  However, someone needs to test it with newer
Python 3 versions.

-- 
Best regards,
Michał Górny



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


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 one of its
> > reverse dependencies:
> I'm using lightblue for rapid development to reverse-engineer/test
> behavior of some Bluetooth devices. Mostly as there was NOTHING else
> that made it easy to get it done.
> 
> I don't care for the other reverse deps, but I'm willing to port
> lightblue to py3 and bump pybluez.
I reviewed most of the dev-python/lightblue codebase over my flights,
and hereby recind my intent to port it to py3.

I converted my coding to Golang's bluetooth instead.

> > app-mobilephone/ganyremote
> > app-mobilephone/wammu
> > kde-misc/kanyremote
> Is anybody willing to maintain these 3?
> If not, lastrite them subject to upstream not doing the 2.7 ports.
Please last-rite dev-python/lightblue with these.

I think dev-python/pybluez can stay for the moment, as it's maintained
upstream. I'll keep pybluez if there are no other maintainers.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: PGP signature


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 ebuild generation fails, we add
> > > > the ebuild manually, understand it and then update the generator to
> > > > cover it in the future.
> > > 
> > > Is this possible in all cases? I think of adding custom patches,
> > > appropriate mapping of dependencies, check for things like desktop
> > > icon cache...
> > 
> > That's too complex to handle automatically.  Luckily, in R overlay, such
> > packages are less than 5%.  An ebuild generator is based on the
> > observation that many language-specific packages are trivial to fetch,
> > compile and install.
> > 
> > > > > I'm only "maintaining" an overlay so maybe I'm  missing experience
> > > > > but I often have wished a tool that automatically parses the language 
> > > > > specific
> > > > > packaging files and is able to generate a primitive ebuild out of 
> > > > > that.
> > > > > Maybe it even can do this in an interactive way:
> > > > > "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I 
> > > > > have found
> > > > > 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
> > > > 
> > > > Yes, that's the way R overlay is working.  And I have a similar plan and
> > > > proof-of-concept solution for the Java Maven overlay.
> > > 
> > > Nice to hear. I think, it is meaningful to solve all generation with one
> > > tool. Maybe it can even "recognize" the used build system and package
> > > database. Is this your plan, too?
> > 
> > No, I don't think it possible as far as I can see...  That would be a
> > strong AI.
> I mean only on a primitive base:
> ```
> if link contains "pypi":
> # it's a Python package from pypi
> handle_pypi()
> elif work_tree contains "setup.py":
> # it's a Python package
> handle_generic_python()
> 

Please don't use generators for Python.  You'd have to put a lot of
effort to get things right.  Most of the time, you'll end up with broken
or no tests, useless deps and py2 where unnecessary.

Creating ebuilds is not a problem.  Maintaining is.  Python team ended
up with lots of packages dumped by former project members or other
developers.  Many of them are of very bad quality.  Even those that
aren't are a maintenance burden.  Removing broken and/or useless
packages is taking a lot of our time.

-- 
Best regards,
Michał Górny



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


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 and then update the generator to
> >> cover it in the future.
> >
> > Is this possible in all cases? I think of adding custom patches,
> > appropriate mapping of dependencies, check for things like desktop
> > icon cache...
> 
> That's too complex to handle automatically.  Luckily, in R overlay, such
> packages are less than 5%.  An ebuild generator is based on the
> observation that many language-specific packages are trivial to fetch,
> compile and install.
> 
> >> > I'm only "maintaining" an overlay so maybe I'm  missing experience
> >> > but I often have wished a tool that automatically parses the language 
> >> > specific
> >> > packaging files and is able to generate a primitive ebuild out of that.
> >> > Maybe it even can do this in an interactive way:
> >> > "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have 
> >> > found
> >> > 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
> >> 
> >> Yes, that's the way R overlay is working.  And I have a similar plan and
> >> proof-of-concept solution for the Java Maven overlay.
> >
> > Nice to hear. I think, it is meaningful to solve all generation with one
> > tool. Maybe it can even "recognize" the used build system and package
> > database. Is this your plan, too?
> 
> No, I don't think it possible as far as I can see...  That would be a
> strong AI.
I mean only on a primitive base:
```
if link contains "pypi":
# it's a Python package from pypi
handle_pypi()
elif work_tree contains "setup.py":
# it's a Python package
handle_generic_python()
elif work_tree contains "meson.build":
handle_meson_package()
...
```

Best,
Gerion


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


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 to
>>> cover it in the future.
>> Is this possible in all cases? I think of adding custom patches,
>> appropriate mapping of dependencies, check for things like desktop
>> icon cache...
> That's too complex to handle automatically.  Luckily, in R overlay, such
> packages are less than 5%.  An ebuild generator is based on the
> observation that many language-specific packages are trivial to fetch,
> compile and install.
>
 I'm only "maintaining" an overlay so maybe I'm  missing experience
 but I often have wished a tool that automatically parses the language 
 specific
 packaging files and is able to generate a primitive ebuild out of that.
 Maybe it even can do this in an interactive way:
 "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have 
 found
 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
>>> Yes, that's the way R overlay is working.  And I have a similar plan and
>>> proof-of-concept solution for the Java Maven overlay.
>> Nice to hear. I think, it is meaningful to solve all generation with one
>> tool. Maybe it can even "recognize" the used build system and package
>> database. Is this your plan, too?
> No, I don't think it possible as far as I can see...  That would be a
> strong AI.
>
> Yours,
> Benda
There was some interest in doing this for PyPI packages for Liguros linux.
See https://gitlab.com/liguros/bugs/issues/75 .



signature.asc
Description: OpenPGP digital signature


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 possible in all cases? I think of adding custom patches,
> appropriate mapping of dependencies, check for things like desktop
> icon cache...

That's too complex to handle automatically.  Luckily, in R overlay, such
packages are less than 5%.  An ebuild generator is based on the
observation that many language-specific packages are trivial to fetch,
compile and install.

>> > I'm only "maintaining" an overlay so maybe I'm  missing experience
>> > but I often have wished a tool that automatically parses the language 
>> > specific
>> > packaging files and is able to generate a primitive ebuild out of that.
>> > Maybe it even can do this in an interactive way:
>> > "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have 
>> > found
>> > 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
>> 
>> Yes, that's the way R overlay is working.  And I have a similar plan and
>> proof-of-concept solution for the Java Maven overlay.
>
> Nice to hear. I think, it is meaningful to solve all generation with one
> tool. Maybe it can even "recognize" the used build system and package
> database. Is this your plan, too?

No, I don't think it possible as far as I can see...  That would be a
strong AI.

Yours,
Benda


signature.asc
Description: PGP signature


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 little bit like g-sorcery
> > (gs-pypi, gs-elpa) or g-octave: a really cool project but not used at a
> > large scale.
> 
> Yes, that's true.  I share the same observation and concern with you.
> 
> This is one exception: the CRAN ebuild generator powered R overlay has
> been running well for 8 years.
> 
>   https://wiki.gentoo.org/wiki/Project:Science/Overlay/R
Hmm, interesting, thank you.


> > What do you think of the idea to not do this fully automated but supervised
> > by a maintainer? With that I mean an ebuild generator that generates only
> > the parts of the ebuild that it can easily parse and then present the ebuild
> > draft to a maintainer who completes it to an full ebuild. As far a I know no
> > tool like this exists. I think the focus shift helps a lot:
> > Developing a tool for the Gentoo maintainer not the Gentoo user.
> 
> 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 possible in all cases? I think of adding custom patches,
appropriate mapping of dependencies, check for things like desktop icon
cache...


> > I'm only "maintaining" an overlay so maybe I'm  missing experience
> > but I often have wished a tool that automatically parses the language 
> > specific
> > packaging files and is able to generate a primitive ebuild out of that.
> > Maybe it even can do this in an interactive way:
> > "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have 
> > found
> > 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
> 
> Yes, that's the way R overlay is working.  And I have a similar plan and
> proof-of-concept solution for the Java Maven overlay.
Nice to hear. I think, it is meaningful to solve all generation with one
tool. Maybe it can even "recognize" the used build system and package
database. Is this your plan, too?


Best,
Gerion


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