[gentoo-dev] Review request for dev-lang/clojure

2020-02-11 Thread Tom Gillespie
Hi all,
 I have submitted a pull request
(https://github.com/gentoo/gentoo/pull/14224) that allows
dev-lang/clojure-1.9.0 and 1.10.0 to build. Two related bugs are
https://bugs.gentoo.org/670680 and https://bugs.gentoo.org/684536. I
have also attached the changes as patches below. Given that there is
no maintainer for dev-lang/clojure I wondered if someone on this could
take a look. Many thanks!
Tom
From 4d25fead235199b59f42c23ce91b723112e2472d Mon Sep 17 00:00:00 2001
From: Tom Gillespie 
Date: Fri, 3 Jan 2020 15:47:57 -0500
Subject: [PATCH 5/5] dev-java/spec-alpha: add metadata.xml

Signed-off-by: Tom Gillespie 
---
 dev-java/spec-alpha/Manifest | 3 ---
 dev-java/spec-alpha/metadata.xml | 8 
 2 files changed, 8 insertions(+), 3 deletions(-)
 create mode 100644 dev-java/spec-alpha/metadata.xml

diff --git a/dev-java/spec-alpha/Manifest b/dev-java/spec-alpha/Manifest
index db86db8f403..52d59ab3ee0 100644
--- a/dev-java/spec-alpha/Manifest
+++ b/dev-java/spec-alpha/Manifest
@@ -1,5 +1,2 @@
-AUX build.xml 1401 BLAKE2B 500b8a1de2b452a1198d66a222e82a8bc78fdc2827d457a50b70d5ffa59866a1f37295a4b275b7ded9bab2a544ee5458b98fba308fb6833816c7567cfc33 SHA512 6d2297aaa240e05688a8062ea02bbb6e488567c00df83d8325c75862240ab109d8c0d9f3779c702161a98ac2f0f684ab87d81c3c0637d73ec382e4e9ca2cf36b
 DIST spec.alpha-0.1.143.tar.gz 35568 BLAKE2B f63fdd2b3c83dbd3936e36ff57b6ea399b7173fe805c60a6ecbd8e4aef5942f051a8551c259d89885a202c20045f67921b66c4dc9e361aacc8903c6542d7c7b5 SHA512 87887d72bc7343f96fad937b90feb4cc1be1eeaad8b7c01ae090ebe5cb17c30612e63797ea9eb39e6fe4c07870dcba9e153a98777d372923e95163f3219a976c
 DIST spec.alpha-0.2.176.tar.gz 37055 BLAKE2B 0588772e4a47a5b122984abefaf5ef2d0fffbacaf277b22737c94889e646c16a029017d405b72b829e88bcf03b12f689cb2053884b24b47193a26978ab54a318 SHA512 decf0dbff09bf8ee12503e6117ab635b98cd8dd2c389acf7aeebf00f32b5fd8250d66c2ec54cfe5da45e727e39480ae738a3ee7fcad71684d8c3acf464fe21e7
-EBUILD spec-alpha-0.1.143.ebuild 960 BLAKE2B a3534caaf1e4f28a8b892b086c4427f0e6da7dae63232ba7aff769df6737f4fd927b64fd065c92f891267dea0b6eefc46f8ec0c437a0ddd174fd077ecd9bb37f SHA512 b60a477da8e233b8af0b98c83aaa40b8de298e1a4c47385bbab1ea5db1dfb65d6638635deb8a90acd93c41cbf02e0d7954685d0b134114911e8fad3eebe69708
-EBUILD spec-alpha-0.2.176.ebuild 960 BLAKE2B ad2e6b2c8beaed8c22d59ef9665dc78421928447f54118fc97815b0d46cd84756267a2b5c58c04ab707715e380f4d1d66c70a3140a1ae602a0248302b920 SHA512 50b2434013d5626b16eb3b8e36e9cac6098373948af406f89ef9143db72689e7d21e482fe1713f5a09fcd084aa9fd65c3c2979772e9f0042afb78dc827b54ba8
diff --git a/dev-java/spec-alpha/metadata.xml b/dev-java/spec-alpha/metadata.xml
new file mode 100644
index 000..aeb8a865b1f
--- /dev/null
+++ b/dev-java/spec-alpha/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+	
+	
+		clojure/spec.alpha
+	
+
-- 
2.24.1

From 7fae2d16c41e4d62dd76f958fcd30c78b2ea7fcd Mon Sep 17 00:00:00 2001
From: Tom Gillespie 
Date: Fri, 3 Jan 2020 02:39:38 -0500
Subject: [PATCH 1/5] dev-java/spec-alpha: added for clojure build

>=clojure-1.9.0 depends on spec-alpha
includes an ant build.xml file to avoid maven

Signed-off-by: Tom Gillespie 
---
 dev-java/spec-alpha/Manifest  |  5 ++
 dev-java/spec-alpha/files/build.xml   | 37 +++
 dev-java/spec-alpha/spec-alpha-0.1.143.ebuild | 47 +++
 dev-java/spec-alpha/spec-alpha-0.2.176.ebuild | 47 +++
 4 files changed, 136 insertions(+)
 create mode 100644 dev-java/spec-alpha/Manifest
 create mode 100644 dev-java/spec-alpha/files/build.xml
 create mode 100644 dev-java/spec-alpha/spec-alpha-0.1.143.ebuild
 create mode 100644 dev-java/spec-alpha/spec-alpha-0.2.176.ebuild

diff --git a/dev-java/spec-alpha/Manifest b/dev-java/spec-alpha/Manifest
new file mode 100644
index 000..db86db8f403
--- /dev/null
+++ b/dev-java/spec-alpha/Manifest
@@ -0,0 +1,5 @@
+AUX build.xml 1401 BLAKE2B 500b8a1de2b452a1198d66a222e82a8bc78fdc2827d457a50b70d5ffa59866a1f37295a4b275b7ded9bab2a544ee5458b98fba308fb6833816c7567cfc33 SHA512 6d2297aaa240e05688a8062ea02bbb6e488567c00df83d8325c75862240ab109d8c0d9f3779c702161a98ac2f0f684ab87d81c3c0637d73ec382e4e9ca2cf36b
+DIST spec.alpha-0.1.143.tar.gz 35568 BLAKE2B f63fdd2b3c83dbd3936e36ff57b6ea399b7173fe805c60a6ecbd8e4aef5942f051a8551c259d89885a202c20045f67921b66c4dc9e361aacc8903c6542d7c7b5 SHA512 87887d72bc7343f96fad937b90feb4cc1be1eeaad8b7c01ae090ebe5cb17c30612e63797ea9eb39e6fe4c07870dcba9e153a98777d372923e95163f3219a976c
+DIST spec.alpha-0.2.176.tar.gz 37055 BLAKE2B 0588772e4a47a5b122984abefaf5ef2d0fffbacaf277b22737c94889e646c16a029017d405b72b829e88bcf03b12f689cb2053884b24b47193a26978ab54a318 SHA512 decf0dbff09bf8ee12503e6117ab635b98cd8dd2c389acf7aeebf00f32b5fd8250d66c2ec54cfe5da45e727e39480ae738a3ee7fcad71684d8c3acf464fe21e7
+EBUILD spec-alpha-0.1.143.ebuild 960 BLAKE2B a3534caaf1e4f28a8b892b086c4427f0e6da7dae63232ba7aff769df6737f4fd927b64fd065c92f891267dea0b6eefc46f8ec0c437a0ddd174fd077ecd9bb37f 

Re: [gentoo-dev] Ebuild Generators

2020-02-11 Thread Tom Gillespie
For historical curiosity there was also
https://github.com/domenkozar/g-pypi at one point (similar to
https://github.com/rafaelmartins/g-octave). Having used g-octave, the
primary issue is as Michał says, there are a lot of corner cases that
the generation doesn't handle correctly which lead to broken ebuilds
and maintenance headaches. Speaking for python, catching and
correcting the use of setup_requires and other insanity visited upon
us by the wonders of setuptools makes this a non-starter. If you have
a set a known sane packages you could in theory write an eclass that
captures the regularities of those packages, but I'm not sure eclasses
are suggested for that use case.
Tom

On Mon, Feb 3, 2020 at 5:27 AM Michał Górny  wrote:
>
> 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
>