[gentoo-dev] Re: [PATCH 2/2] rebar3.eclass: add new eclass
On 2024-07-10 09:19, Florian Schmaus wrote:
From: Florian Schmaus
Add a new eclass for dev-util/rebar:3, based on the work of Anna
Vyalkova in ::guru (thanks!).
There's also rebar3.eclass in lanodanOverlay, hereby CC-ing Haelwenn on
this.
The Erlang/OTP ecosystem is moving to Rebar3. Upstreams start to drop
support for Rebar2, or at least consider it.
Signed-off-by: Florian Schmaus
---
eclass/rebar3.eclass | 204 +++
1 file changed, 204 insertions(+)
create mode 100644 eclass/rebar3.eclass
diff --git a/eclass/rebar3.eclass b/eclass/rebar3.eclass
new file mode 100644
index ..83363ab54602
--- /dev/null
+++ b/eclass/rebar3.eclass
@@ -0,0 +1,204 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: rebar3.eclass
+# @MAINTAINER:
+# Florian Schmaus
+# @AUTHOR:
+# Amadeusz Żołnowski
+# Anna (cybertailor) Vyalkova
+# @SUPPORTED_EAPIS: 8
+# @PROVIDES: rebar-utils
+# @BLURB: Build Erlang/OTP projects using dev-util/rebar:3.
+# @DESCRIPTION:
+# An eclass providing functions to build Erlang/OTP projects using
+# dev-util/rebar:3.
+#
+# rebar is a tool which tries to resolve dependencies itself which is by
+# cloning remote git repositories. Dependent projects are usually expected to
+# be in sub-directory 'deps' rather than looking at system Erlang lib
+# directory. Projects relying on rebar usually don't have 'install' make
+# targets. The eclass workarounds some of these problems. It handles
+# installation in a generic way for Erlang/OTP structured projects.
+
+case ${EAPI} in
+ 8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+if [[ -z ${_REBAR3_ECLASS} ]]; then
+_REBAR3_ECLASS=1
+
+inherit edo rebar-utils
+
+RDEPEND="dev-lang/erlang:="
+DEPEND="${RDEPEND}"
+BDEPEND="
+ dev-util/rebar:3
+ >=sys-apps/gawk-4.1
+"
+
+# @ECLASS_VARIABLE: REBAR_PROFILE
+# @DESCRIPTION:
+# Rebar profile to use.
+: "${REBAR_PROFILE:=default}"
+
+# @ECLASS_VARIABLE: REBAR_APP_SRC
+# @DESCRIPTION:
+# Relative path to .app.src description file.
+: "${REBAR_APP_SRC:=src/${PN}.app.src}"
+
+# @FUNCTION: get_erl_libs
+# @RETURN: the path to Erlang lib directory
+# @DESCRIPTION:
+# Get the full path without EPREFIX to Erlang lib directory.
+get_erl_libs() {
+ echo "/usr/$(get_libdir)/erlang/lib"
+}
+
+# @FUNCTION: _rebar_find_dep
+# @INTERNAL
+# @USAGE:
+# @RETURN: 0 success, 1 dependency not found, 2 multiple versions found
+# @DESCRIPTION:
+# Find a Erlang package/project by name in Erlang lib directory. Project
+# directory is usually suffixed with version. It is matched to ''
+# or '-*'.
+_rebar_find_dep() {
+ local pn="${1}"
+ local p
+ local result
+
+ pushd "${EPREFIX}$(get_erl_libs)" >/dev/null || return 1
+ for p in ${pn} ${pn}-*; do
+ if [[ -d ${p} ]]; then
+ # Ensure there's at most one matching.
+ [[ ${result} ]] && return 2
+ result="${p}"
+ fi
+ done
+ popd >/dev/null || die
+
+ [[ ${result} ]] || return 1
+ echo "${result}"
+}
+
+# @FUNCTION: erebar3
+# @USAGE:
+# @DESCRIPTION:
+# Run rebar with verbose flag. Die on failure.
+erebar3() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ (( $# > 0 )) || die "erebar: at least one target is required"
Oversight, should be ${FUNCNAME} instead of "erebar" (old name).
+
+ case ${1} in
+ eunit|ct)
+ local -x ERL_LIBS="." ;;
+ *)
+ local -x ERL_LIBS="${EPREFIX}$(get_erl_libs)" ;;
+ esac
+
+ edo rebar3 "$@"
+}
+
+# @FUNCTION: rebar3_src_prepare
+# @DESCRIPTION:
+# Prevent rebar from fetching and compiling dependencies. Set version in
Ditto.
+# project description file if it's not set.
+#
+# Existence of rebar.config is optional, but file description file must exist
+# at 'src/${PN}.app.src'.
+rebar3_src_prepare() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ default_src_prepare
+ rebar_set_vsn
+
+ if [[ -f rebar.lock ]]; then
+ rm rebar.lock || die
+ fi
+
+ if [[ -f rebar.config ]]; then
+ rebar_disable_coverage
+ rebar_remove_deps
+ fi
+}
+
+# @FUNCTION: rebar3_src_configure
+# @DESCRIPTION:
+# Configure with ERL_LIBS set.
+rebar3_src_configure() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ local -x ERL_LIBS="${EPREFIX}$(get_erl_libs)"
+ default_src_configure
+}
+
+# @FUNCTION: rebar3_src_compile
+# @DESCRIPTION:
+# Compile project with rebar.
Ditto.
+r
[gentoo-dev] [ANN] find-work utility: discover ebuilds to improve
TL;DR: Install: # eselect repository enable guru && emaint sync -r guru # emerge dev-util/find-work Browse documentation: $ xdg-open https://find-work.sysrq.in/ $ man find-work Backstory - I used to be very active in ::guru, trying to fix every bug. This led me to a burnout, so after some months of rest I decided to care only about packages that are actually installed on my system. I used a couple of scripts for that, and after writing yet another one I realized they have a common purpose: fetch all available work and filter it to show only things I will be interested in. That's how this utility was born. What's next? v0.3.0 has initial support for Repology, Bugzilla and packages.gentoo.org as data sources. It can filter results by installed status and/or by maintainer email. However the development can't move forward without your feedback, so I encourage you to report bug and feature requests on my bugzilla, chat rooms or via email. Everyone is also welcome to contribute.
Re: [gentoo-dev] I have a question about dependent packages.
On 2023-07-11 08:41, TrakRailySurely wrote: > Hello Everyone. > > When one package has another library that only depends on that package, > should that library be statically linked? > For example, the library aws-crt-cpp on which aws-sdk-cpp depends. > This package only depends on aws-sdk-cpp. Dynamic linking is preferred in Gentoo. https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/
[gentoo-dev] Announcing a utility for updating metadata.xml files
Hi lists, You might know about the `app-portage/metagen` utility that generates metadata.xml files with your name and email. But there was no tool that autofilled upstream information, so I wrote it. Using it is as simple as: $ gentle foo-0.1.ebuild You can install it as `app-portage/gentle` from the ::guru repository or download it from PyPI: https://pypi.org/project/gentle-mxml/ The tool uses Portage API to unpack source code into a temporary directory and guess from that data. Pkgcraft will be supported once its bindings gain ability to call phase functions. There are problems with Pkgcore, so it's not supported. Contributions (especially fixing bugs and adding new generators) are welcome! P.S. There's a similar project called upstream-ontologist[0]. I didn't know about it when I started the project and now it's too late. [0]: https://pypi.org/project/upstream-ontologist/
[gentoo-dev] Re: EGO_SUM
On 2023-05-30 17:52, Florian Schmaus wrote: > To prevent harm from Gentoo, we should reach an agreement that everyone > can live with. To achieve a consensus, and since I can not rule out that > I missed a post that includes specific numbers, please share your ideas > on how EGO_SUM could be reinstated in ::gentoo by replying to this mail. Instate a policy to allow EGO_SUM in the gentoo tree: 1) from proxied maintainers 2) if there are no more than N entries and disallow use otherwise.
Re: [gentoo-dev] Portage and languages with built-in cache support
On 2023-04-25 16:09, Maciej Barć wrote:
> You would also have to have correct permissions on cache dirs
> (root:portage or portage:portage) this also means that the cache dir
> will have to be set during build explicitly.
> Do both Nim and Go support setting it?
Yes. For Nim it would be something like that:
# nim.cfg
--nimcache:"${EPREFIX}/var/cache/nim/${CATEGORY}/${PN}"
And for Go:
export GOCACHE="${EPREFIX}/var/cache/go"
on some condition.
The only problem is, they don't support cleaning cache automatically. So
it needs to be done manually or with cron.
[gentoo-dev] Portage and languages with built-in cache support
Hello,
Portage can use ccache and sccache to speed up builds, but some
languages (like Go and Nim) support caches out-of-the-box. It's not fair
that we can't use them.
I'd like to start discussion on this topic. What should be the preferred
method of handling build caches?
I think adding more stuff to Portage is a bad idea, and caches should be
handled by corresponding "${lang}-utils" eclasses. It can be as simple
as checking some variable, passing necessary flags and placing a couple
of 'addwrite' calls for sandbox.
Of course, such feature needs to be strictly opt-in.
[gentoo-dev] Re: EGO_SUM
On 2023-04-17 09:37, Florian Schmaus wrote: > The EGO_SUM alternatives > - do not have the same level of trust and therefore have a negative > impact on security (a dubious tarball someone put somewhere, especially > when proxy-maint) Solution: generate release tarballs in upstream CI/CD. > - are not easily verifiable `go mod verify` (called by eclass) does part of the job. > - require additional effort when developing ebuilds Generating EGO_SUM needs effort on every bump too. > - hinder the packaging and Gentoo's adoption of Go-based projects, which > is worrisome as Go is very popular Go's approach to package management is the prime cause after all. Downstream can only choose what workaround to apply. > - prevent Go modules from being shared as DISTFILES on the mirrors > across various packages Go modules often use pinned commits, so only a small share is reused. > Last but not least, we have the same situation in the Rust ecosystem, > but we allow the EGO_SUM "equivalent" there. Rust crates are not such a disaster as Go modules.
Re: [gentoo-dev] [PATCH 2/2] eclass/ruby-fakegem.eclass: add support for sus test runner
On 2023-03-25 09:18, Hans de Graaff wrote:
> Signed-off-by: Hans de Graaff
> ---
> eclass/ruby-fakegem.eclass | 9 +
> eclass/ruby-ng.eclass | 25 +
> 2 files changed, 34 insertions(+)
>
> diff --git a/eclass/ruby-fakegem.eclass b/eclass/ruby-fakegem.eclass
> index 08e3ccf588ac..4ad1d8eca683 100644
> --- a/eclass/ruby-fakegem.eclass
> +++ b/eclass/ruby-fakegem.eclass
> @@ -44,6 +44,7 @@ RUBY_FAKEGEM_TASK_DOC="${RUBY_FAKEGEM_TASK_DOC-rdoc}"
> # - rspec3 (calls ruby-ng_rspec, adds dev-ruby/rspec:3 to the dependencies)
> # - cucumber (calls ruby-ng_cucumber, adds dev-util/cucumber to the
> #dependencies)
> +# - sus (calls ruby-ng_sus, adds dev-ruby/sus to the dependencies)
> # - none
> RUBY_FAKEGEM_RECIPE_TEST="${RUBY_FAKEGEM_RECIPE_TEST-rake}"
>
> @@ -193,6 +194,11 @@ case ${RUBY_FAKEGEM_RECIPE_TEST} in
> RESTRICT+=" !test? ( test )"
> ruby_add_bdepend "test? ( dev-util/cucumber )"
> ;;
> + sus)
> + IUSE+=" test"
> + RESTRICT+=" !test? ( test )"
> + ruby_add_bdepend "test? ( dev-ruby/sus )"
> + ;;
> none)
> ;;
> *)
> @@ -566,6 +572,9 @@ each_fakegem_test() {
> cucumber)
> ruby-ng_cucumber
> ;;
> + sus)
> + ruby-ng_sus
> + ;;
> none)
> ewarn "each_fakegem_test called, but
> \${RUBY_FAKEGEM_RECIPE_TEST} is 'none'"
> ;;
> diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
> index f85a933f81d9..c273a431c5b1 100644
> --- a/eclass/ruby-ng.eclass
> +++ b/eclass/ruby-ng.eclass
> @@ -757,6 +757,31 @@ ruby-ng_cucumber() {
> CUCUMBER_PUBLISH_QUIET=true ${RUBY} -S cucumber ${cucumber_params} "$@"
> || die -n "cucumber failed"
> }
>
> +# @FUNCTION: ruby-ng_sus
> +# @DESCRIPTION:
> +# This is simply a wrapper around the sus-parallel command (executed by
> $RUBY})
> +# which also respects TEST_VERBOSE and NOCOLOR environment variables.
> +ruby-ng_sus() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + if [[ "${DEPEND}${BDEPEND}" != *"dev-ruby/sus"* ]]; then
> + ewarn "Missing test dependency dev-ruby/sus"
> + fi
> +
> + local sus_params=
How about making it a bash array?
> + # sus has a --verbose argument but it does not seem to impact the
> output (yet?)
> + case ${TEST_VERBOSE} in
> + 1|yes|true)
> + sus_params+=" --verbose"
> + ;;
> + *)
> + ;;
> + esac
> +
> + ${RUBY} -S sus-parallel ${sus_params} "$@" || die -n "sus failed"
> +}
> +
> # @FUNCTION: ruby-ng_testrb-2
> # @DESCRIPTION:
> # This is simply a replacement for the testrb command that load the test
> --
> 2.39.2
>
>
Re: [gentoo-dev] [PATCH] New pre-GLEP: TEST_SUITE_PRESENT variable
Is it better than RESTRICT="test" ?
[gentoo-dev] Re: Packages up for grabs: sys-apps/bat, app-misc/physlock, dev-lang/crystal, dev-util/shards
> dev-lang/crystal > dev-util/shards These packages are only used in ::guru, so they could be moved there.
Re: [gentoo-dev] [PATCH] pypi.eclass: A new eclass to aid creating PyPI SRC_URIs
Much wanted eclass. Thanks!
Re: [gentoo-dev] dev-python/ package naming policy?
On 2023-01-30 12:00, Michał Górny wrote: > However, there's a can of worms around the corner -- should we also > allow normalizing "-" and "_" across different packages (see dev- > python/sphinx*)? PyPI treats "-" and "_" separators as the same, so I'd not use underscores for in-repo consistency.
Re: [gentoo-dev] dev-python/ package naming policy?
On 2023-01-28 19:02, Ulrich Mueller wrote: > > On Sat, 28 Jan 2023, Michał Górny wrote: > >> However, it's been pointed out that this makes it hard for people to > >> find packages they're looking for. > > I don't understand this argument. Why would all-lowercase make finding a > package harder? It doesn't. `eix` search is case-insensitive.
Re: [gentoo-dev] dev-python/ package naming policy?
I'd prefer if PyPI names are guidelines, not a strict policy. I don't
like CamelCase and separators other than dash ("-") :P
Also I don't like when packages are named "dev-python/python-foo"
instead of just "dev-python/foo".
[gentoo-dev] Re: Python 3.9 removal and Python 3.11 stable
No objections. Lots of work though :)
Re: [gentoo-dev] [RFC] www-nginx/ category and nginx-module.eclass for nginx modules
On 2023-01-24 18:11, Michał Górny wrote: > How many packages do you expect to add to this new category? It's not > customary to create a new category for one package. Look at www-servers/nginx package, it's huge! Lots of modules (many of them are 3rd-party) could be separate packages.
