[gentoo-dev] [PATCH] pypi.eclass: _pypi_translate_version _pre to .dev
Hi,
I am sending this patch to pypi.eclass to this list per mgorny's
request. Best!
Tom
https://github.com/gentoo/gentoo/pull/31861
From 6910a990f221986d1b5c0cc3900bd2ba64b9a017 Mon Sep 17 00:00:00 2001
From: Tom Gillespie
Date: Wed, 12 Jul 2023 18:55:39 -0700
Subject: [PATCH] pypi.eclass: _pypi_translate_version _pre to .dev
Implement automatic translation _pre to .dev for pypi SRC_URIs.
Signed-off-by: Tom Gillespie
---
eclass/pypi.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/pypi.eclass b/eclass/pypi.eclass
index 594216a7fd96..b80ff9c95d36 100644
--- a/eclass/pypi.eclass
+++ b/eclass/pypi.eclass
@@ -105,6 +105,7 @@ _pypi_translate_version() {
local version=${1}
version=${version/_alpha/a}
version=${version/_beta/b}
+ version=${version/_pre/.dev}
version=${version/_rc/rc}
_PYPI_TRANSLATED_VERSION=${version/_p/.post}
}
--
2.41.0
Re: [gentoo-dev] musl, sbcl, and ros
> The sbcl ebuild from the Gentoo tree is useless on musl. And hence it should be masked. Otherwise somebody would think that [s]he can simply emerge sbcl on a musl profile, and will be disappointed. Ah, I see. That makes sense, and I think I can just unmask it in my custom musl profile. Thanks! Tom
Re: [gentoo-dev] musl, sbcl, and ros
For the record I've had sbcl building and running on musl for months without issue (at one point I even had static linking working). You have to cross compile a musl version and then side load the binary instead of using one of the distributed binaries. See https://github.com/tgbugs/dockerfiles/blob/master/source.org#sbcl-bootstrap for reference. See also https://hub.docker.com/r/tgbugs/musl/tags?page=1=sbcl. Thus I'd very much appreciate if it sbcl were not masked on those profiles. Best, Tom
[gentoo-dev] Review request for dev-lang/clojure
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
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 >
