Re: [gentoo-dev] Packages up for grabs: net-mail/notmuch, dev-python/..., erlang related, ...
On 5/10/20 8:35 PM, Ralph Seichter wrote: > * aide...@gentoo.org: > >> net-mail/muchsync >> net-mail/notmuch > > I can take both. I already maintain these two for MacPorts, and I use > notmuch daily (as in: right now). > awesome, thanks a lot for your work. > -Ralph > I take back my previous request in that case :) Aisha
[gentoo-portage-dev] [PATCH] Enable FEATURES=parallel-install by default (bug 715110)
The feature enables finer grained locks for install operations, and
everyone agrees that it's safe to enable by default.
Bug: https://bugs.gentoo.org/715110
Signed-off-by: Zac Medico
---
cnf/make.globals | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cnf/make.globals b/cnf/make.globals
index 4a59dbe3c..5ba1ac6fa 100644
--- a/cnf/make.globals
+++ b/cnf/make.globals
@@ -55,7 +55,7 @@ FETCHCOMMAND_SFTP="bash -c \"x=\\\${2#sftp://} ;
host=\\\${x%%/*} ; port=\\\${ho
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs
config-protect-if-modified distlocks ebuild-locks
fixlafiles ipc-sandbox merge-sync multilib-strict
- network-sandbox news parallel-fetch pid-sandbox
+ network-sandbox news parallel-fetch parallel-install pid-sandbox
preserve-libs protect-owned qa-unresolved-soname-deps
sandbox sfperms strict
unknown-features-warn unmerge-logs unmerge-orphans userfetch
--
2.25.3
Re: [gentoo-dev] Packages up for grabs: net-mail/notmuch, dev-python/..., erlang related, ...
On 5/10/20 5:59 PM, aide...@gentoo.org wrote: > Hi, > > The following packages are up for grabs: > > app-misc/tek > app-misc/timew > app-text/dbacl > dev-python/dkimpy > dev-python/potr > dev-python/precis-i18n > dev-python/urwidtrees > dev-util/rebar-bin > net-mail/muchsync > net-mail/notmuch > sys-apps/biosdevname > > due to my retirement. > > I'd like to highlight net-main/notmuch which has a great upstream devs. > > Can I take not-much through proxy-maint? I have another package that needs it. Cheers, Aisha > Cheers, > -- aidecoe >
[gentoo-portage-dev] [PATCH] Default BINPKG_COMPRESSION to zstd (bug 715108)
This includes a _compat_upgrade.binpkg_compression script that the
ebuild can call in pkg_preinst in order to maintain a backward-compatible
bzip2 default when appropriate, ensuring that binary package consumers
are not caught off guard.
Bug: https://bugs.gentoo.org/715108
Signed-off-by: Zac Medico
---
.travis.yml | 4 ++
cnf/make.globals | 5 ++-
.../_compat_upgrade/binpkg_compression.py | 40 +++
.../tests/resolver/ResolverPlayground.py | 1 +
man/make.conf.5 | 4 +-
5 files changed, 50 insertions(+), 4 deletions(-)
create mode 100644 lib/portage/_compat_upgrade/binpkg_compression.py
diff --git a/.travis.yml b/.travis.yml
index 9269d4034..2132c8c87 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -1,3 +1,4 @@
+dist: bionic
language: python
python:
- 2.7
@@ -8,6 +9,9 @@ python:
- pypy3
# command to install dependencies
+before_install:
+# Use "dist: bionic" to get a zstd with --long support.
+- sudo apt-get -y install zstd
install:
- pip install tox
diff --git a/cnf/make.globals b/cnf/make.globals
index 4a59dbe3c..dd3f28f70 100644
--- a/cnf/make.globals
+++ b/cnf/make.globals
@@ -34,8 +34,9 @@ RPMDIR="/var/cache/rpm"
# Temporary build directory
PORTAGE_TMPDIR="/var/tmp"
-# The compression used for binary packages. Defaults to zstd when USE=zstd is
enabled.
-BINPKG_COMPRESS="bzip2"
+# The compression used for binary packages. Defaults to zstd except for
+# existing installs where bzip2 is used for backward compatibility.
+BINPKG_COMPRESS="zstd"
# Fetching command (3 tries, passive ftp for firewall compatibility)
FETCHCOMMAND="wget -t 3 -T 60 --passive-ftp -O \"\${DISTDIR}/\${FILE}\"
\"\${URI}\""
diff --git a/lib/portage/_compat_upgrade/binpkg_compression.py
b/lib/portage/_compat_upgrade/binpkg_compression.py
new file mode 100644
index 0..0f5704733
--- /dev/null
+++ b/lib/portage/_compat_upgrade/binpkg_compression.py
@@ -0,0 +1,40 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+import re
+
+import portage
+from portage import os
+from portage.const import GLOBAL_CONFIG_PATH
+
+COMPAT_BINPKG_COMPRESS = 'bzip2'
+
+
+def main():
+ """
+ If the current installation is still configured to use the old
+ default BINPKG_COMPRESS=bzip2 setting, then patch make.globals
+ inside ${ED} to maintain backward compatibility, ensuring that
+ binary package consumers are not caught off guard. This is
+ intended to be called from the ebuild as follows:
+
+ pkg_preinst() {
+ python_setup
+ env -u BINPKG_COMPRESS
+
PYTHONPATH="${D%/}$(python_get_sitedir)${PYTHONPATH:+:${PYTHONPATH}}" \
+ "${PYTHON}" -m
portage._compat_upgrade.binpkg_compression || die
+ }
+ """
+ if portage.settings.get('BINPKG_COMPRESS', COMPAT_BINPKG_COMPRESS) ==
COMPAT_BINPKG_COMPRESS:
+ config_path = os.path.join(os.environ['ED'],
GLOBAL_CONFIG_PATH.lstrip(os.sep), 'make.globals')
+ with open(config_path) as f:
+ content = f.read()
+ compat_setting =
'BINPKG_COMPRESS="{}"'.format(COMPAT_BINPKG_COMPRESS)
+ portage.output.EOutput().einfo('Setting make.globals
default {} for backward compatibility'.format(compat_setting))
+ content = re.sub('^BINPKG_COMPRESS=.*$',
compat_setting, content, flags=re.MULTILINE)
+ with open(config_path, 'wt') as f:
+ f.write(content)
+
+
+if __name__ == '__main__':
+ main()
diff --git a/lib/portage/tests/resolver/ResolverPlayground.py
b/lib/portage/tests/resolver/ResolverPlayground.py
index 98831e000..de80a0cc1 100644
--- a/lib/portage/tests/resolver/ResolverPlayground.py
+++ b/lib/portage/tests/resolver/ResolverPlayground.py
@@ -112,6 +112,7 @@ class ResolverPlayground(object):
"uname",
"uniq",
"xargs",
+ "zstd",
)
# Exclude internal wrappers from PATH lookup.
orig_path = os.environ['PATH']
diff --git a/man/make.conf.5 b/man/make.conf.5
index f82fed65a..a3bd662ae 100644
--- a/man/make.conf.5
+++ b/man/make.conf.5
@@ -1,4 +1,4 @@
-.TH "MAKE.CONF" "5" "Nov 2019" "Portage VERSION" "Portage"
+.TH "MAKE.CONF" "5" "May 2020" "Portage VERSION" "Portage"
.SH "NAME"
make.conf \- custom settings for Portage
.SH "SYNOPSIS"
@@ -115,7 +115,7 @@ This variable is used to determine the compression used for
\fIbinary
packages\fR. Supported settings and compression algorithms are: bzip2, gzip,
lz4, lzip, lzop, xz, zstd.
.br
-Defaults to "bzip2".
+Defaults to "zstd".
.br
.I Example:
.nf
--
2.25.3
Re: [gentoo-dev] Packages up for grabs: net-mail/notmuch, dev-python/..., erlang related, ...
* aide...@gentoo.org: > net-mail/muchsync > net-mail/notmuch I can take both. I already maintain these two for MacPorts, and I use notmuch daily (as in: right now). -Ralph
[gentoo-dev] Re: Opennebula ebuild
Hi, I finally manage to get opennebula-5.10.4[1] hotfix version working, compiling everything from source. This includes also the documentation. If use flags docker or sunstone are selected, build will require network-sandbox disabled. emerge will fail in pretend and setup phase if network-sandbox was not authorized by the user. I hope this ebuild to be useful and I'm glad to share it for Gentoo community. Best, Samuel [1] https://cgit.gentoo.org/repo/user/ssnb.git/tree/app-emulation/opennebula On 5/4/20 2:00 PM, Samuel Bernardo wrote: > Hi, > > I start to thanks all your advices from previous emails related to > ebuild development. > > I send you this email to let off steam about the big mess to have latest > OpenNebula version available in my Gentoo overlay[1]. This was the > problems I had to deal with: > > - patch many source files with sed to change /usr/lib into /usr/lib64 > - pretend phase fails for use flag docker because requires > -network-sandbox (I don't see value in the effort to use the > docker-machine driver in opennebula, besides it was possible to get all > required dependencies using EGO_SUM) > - pretend phase fails for use flag sunstone in case of an hotfix release > because it requires -network-sandbox (in this case is just impossible to > manage npm and bower) > - missing parser source files from official archive that I solved using > archive from same github tag using ebuild files to add them > - some files in /usr/lib64/one, /usr/share/one and /var/lib/one with > executable permissions (I need to use cp -a to copy this directories to > the image because the file permissions are set by their build tool, and > there are so many that I haven't the time to review them in each release > using the required Gentoo install functions) > > I send an email to upstream with all my complaints, asking them that all > required dependencies for the source code must be present in the archive > and not being downloaded during build. > > There are also compile problems for sunstone minified files using hotfix > release, and that's the reason why I have those ebuilds hard masked. > > I also do a big improvement in ebuild code from the previous versions > that I had removed since they are insecure. > > So in summary, is possible to install opennebula with network-sandbox > but without docker-machine driver and only using stable releases without > hotfixes. Anyway, the pretend phase tests for use flags docker and > sunstone, and fails in case it requires -network-sandbox. So is an user > decision in the end to allow -network-sandbox. > > Best, > > [1] https://cgit.gentoo.org/repo/user/ssnb.git/tree/app-emulation/opennebula > signature.asc Description: OpenPGP digital signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-05-10 23:59 UTC
20200222-12:10 juippis4ca00603c66 acct-group/simplevirt 20200506-20:36 rafaelmartins 9c002c448d4 acct-group/tsm 20200506-20:16 dilfridge ed554b3a00c acct-user/bareos 20200509-04:12 mschiff4dddaa87549 acct-user/bitlbee 20200210-22:43 juippis3a6ba13b1d1 acct-user/monitorix20200222-12:12 juippis1b428a5fb98 acct-user/tvheadend20200510-22:12 chewi af16b671f62 app-vim/vim-clang-format 20200507-05:45 chutzpah b04fe1156d3 dev-perl/B-COW 20200506-14:33 kentnl 5d58a96a847 dev-python/asgiref 20200505-19:47 mgorny 14d51704438 dev-python/cbor2 20200508-23:59 dolsen 4b6aede9bf1 dev-python/flatbuffers 20200428-01:15 dolsen 9eca2aef50e dev-python/picklemagic 20200510-10:52 bircoph8a4b2930cb6 dev-python/pypugjs 20200508-17:44 dolsen 9d22a12cd7b dev-python/snapshottest20200506-23:46 chutzpah eff6347a414 dev-python/sphinxcontrib-httpexample 20200507-00:16 chutzpah b8ac5bbac19 dev-util/unrpyc20200510-11:04 bircoph670b891301e games-action/rive 20200508-21:59 chewi 7b594507ca4 games-emulation/dosbox-staging 20200509-15:38 voyageur 45fb4facbf6 games-util/eureka 20200508-11:06 chewi 7c6510c0076 net-analyzer/snallygaster 20200506-06:50 hanno 88e6eb7431b net-libs/xrootd-ceph 20200508-21:00 mareckifcf660f89dc sci-libs/linbox20200504-12:21 mjo 87e61bbe8bc sys-apps/hw-probe 20200510-19:24 conikost 867401aadf9 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: app-antivirus/clamav-unofficial-sigs,removed,mjo,20200508-12:45,b77e04b43db dev-python/ip-associations-python-novaclient-ext,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/nose-testconfig,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/os-networksv2-python-novaclient-ext,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/os-virtual-interfacesv2-python-novaclient-ext,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/osc-placement,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/positional,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/posix_ipc,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/rackspace-auth-openstack,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/rackspace-novaclient,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/rax-default-network-flags-python-novaclient-ext,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/rax-scheduled-images-python-novaclient-ext,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/repoze-who,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/tablib,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/zake,removed,prometheanfire,20200508-02:58,1d73c13da8f dev-python/cryptography-vectors,removed,mgorny,20200507-12:18,aebe01409a4 dev-ruby/postgres_ext,removed,graaff,20200505-07:55,17ab1a07c32 dev-ruby/protected_attributes,removed,graaff,20200505-07:54,05f88aa1129 dev-ruby/metasploit-concern,removed,graaff,20200505-07:50,15fe687020a dev-ruby/metasploit-credential,removed,graaff,20200505-07:50,15fe687020a dev-ruby/metasploit-model,removed,graaff,20200505-07:50,15fe687020a dev-ruby/metasploit-payloads,removed,graaff,20200505-07:50,15fe687020a dev-ruby/metasploit_data_models,removed,graaff,20200505-07:50,15fe687020a dev-ruby/metasploit_payloads-mettle,removed,graaff,20200505-07:50,15fe687020a net-analyzer/metasploit,removed,graaff,20200505-07:50,af8f89d9b9f dev-ruby/rex-arch,removed,graaff,20200505-07:49,8665c57fd0c dev-ruby/rex-bin_tools,removed,graaff,20200505-07:49,8665c57fd0c dev-ruby/rex-core,removed,graaff,20200505-07:49,8665c57fd0c dev-ruby/rex-encoder,removed,graaff,20200505-07:49,8665c57fd0c dev-ruby/rex-exploitation,removed,graaff,20200505-07:49,8665c57fd0c dev-ruby/rex-java,removed,graaff,20200505-07:49,8665c57fd0c dev-ruby/rex-mime,removed,graaff,20200505-07:49,8665c57fd0c dev-ruby/rex-nop,removed,graaff
Re: [gentoo-dev] dev-python/llvmlite update to 0.32
On 5/10/20 2:11 PM, Michał Górny wrote: > W dniu nie, 10.05.2020 o godzinie 07∶21 -0400, użytkownik Aisha Tammy > napisał: >> On 5/10/20 2:02 AM, Michał Górny wrote: >>> W dniu sob, 09.05.2020 o godzinie 22∶39 -0400, użytkownik Aisha >>> Tammy >>> napisał: Hey all, I was hoping to upgrade the dev-python/numba jit compiler in proxy- maint but it depends on dev-python/llvmlite >=0.31 Current version of llvmlite is stuck at 0.30 which is preventing the numba package from being upgraded. It is at a risk of last rite retiring because its stuck at 3.6 >>> >>> It is more likely to be last rited because upstream still didn't >>> manage >>> to port it to LLVM 9. I don't have LLVM 8 anymore, and I don't >>> have >>> the resources to build 3 different LLVM versions. >>> >> The following issue tells that LLVM 9 is now supported :) >> https://github.com/numba/llvmlite/issues/523 >> >> They haven't updated their documentation correctly. > > I suppose this means using the fancy variable to disable LLVM version > checks, correct? > lol, you seem to be experienced with this kind of behaviour :P . I won't even ask how many times this may have burned you XD . Indeed, they have changed the version checking feature pretty recently though nothing too coherent has been given out yet. Here's to hoping they do it over summer. >> >> PS: regarding lack of resources. >> I have a spare computer and am willing to use that to do some testing >> for >> interesting packages like these. I hope it can help us keep a few >> more >> packages that would otherwise be killed off. > > Well, my hardware died two days ago, so I should have more resources > mid-next week. Until then, only minimal work that can be done with > backup hardware. > That sucks, hardware failure is the bane of everyones existence T.T Cheers and hope things get better, Aisha
[gentoo-dev] Packages up for grabs: net-mail/notmuch, dev-python/..., erlang related, ...
Hi, The following packages are up for grabs: app-misc/tek app-misc/timew app-text/dbacl dev-python/dkimpy dev-python/potr dev-python/precis-i18n dev-python/urwidtrees dev-util/rebar-bin net-mail/muchsync net-mail/notmuch sys-apps/biosdevname due to my retirement. I'd like to highlight net-main/notmuch which has a great upstream devs. Cheers, -- aidecoe signature.asc Description: PGP signature
[gentoo-dev] [PATCH 1/1] eclass/go-module.eclass: remove EGO_VENDOR support
Signed-off-by: William Hubbs
---
eclass/go-module.eclass | 81 +++--
1 file changed, 6 insertions(+), 75 deletions(-)
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 17d37494f15..7b66c3e2b1e 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -120,29 +120,6 @@ EXPORT_FUNCTIONS src_unpack pkg_postinst
# This decision does NOT weaken Go module security, as Go will verify the
# go.sum copy of the Hash1 values during building of the package.
-# @ECLASS-VARIABLE: EGO_VENDOR
-# @DESCRIPTION:
-# This variable is deprecated and should no longer be used. Please
-# convert your ebuilds to use EGO_SUM.
-
-# @FUNCTION: go-module_vendor_uris
-# @DESCRIPTION:
-# This function is deprecated.
-go-module_vendor_uris() {
- local hash import line repo x
- for line in "${EGO_VENDOR[@]}"; do
- read -r import hash repo x <<< "${line}"
- if [[ -n ${x} ]]; then
- eerror "Trailing information in EGO_VENDOR in
${P}.ebuild"
- eerror "${line}"
- eerror "Trailing information is: \"${x}\""
- die "Invalid EGO_VENDOR format"
- fi
- : "${repo:=${import}}"
- echo "https://${repo}/archive/${hash}.tar.gz ->
${repo//\//-}-${hash}.tar.gz"
- done
-}
-
# @ECLASS-VARIABLE: _GOMODULE_GOPROXY_BASEURI
# @DESCRIPTION:
# Golang module proxy service to fetch module files from. Note that the module
@@ -261,17 +238,16 @@ go-module_set_globals() {
# @FUNCTION: go-module_src_unpack
# @DESCRIPTION:
-# - If EGO_VENDOR is set, use the deprecated function to unpack the base
-# tarballs and the tarballs indicated in EGO_VENDOR to the correct
-# locations.
-# - Otherwise, if EGO_SUM is set, unpack the base tarball(s) and set up the
+# If EGO_SUM is set, unpack the base tarball(s) and set up the
# local go proxy.
+# - Otherwise, if EGO_VENDOR is set, bail out.
# - Otherwise do a normal unpack.
go-module_src_unpack() {
- if [[ "${#EGO_VENDOR[@]}" -gt 0 ]]; then
- _go-module_src_unpack_vendor
- elif [[ "${#EGO_SUM[@]}" -gt 0 ]]; then
+ if [[ "${#EGO_SUM[@]}" -gt 0 ]]; then
_go-module_src_unpack_gosum
+ elif [[ "${#EGO_VENDOR[@]}" -gt 0 ]]; then
+ eerror "${EBUILD} is using EGO_VENDOR which is no longer
supported"
+ die "Please update this ebuild"
else
default
fi
@@ -350,51 +326,6 @@ _go-module_gosum_synthesize_files() {
fi
}
-# @FUNCTION: _go-module_src_unpack_vendor
-# @DESCRIPTION:
-# Extract all archives in ${a} which are not nentioned in ${EGO_VENDOR}
-# to their usual locations then extract all archives mentioned in
-# ${EGO_VENDOR} to ${S}/vendor.
-_go-module_src_unpack_vendor() {
- # shellcheck disable=SC2120
- debug-print-function "${FUNCNAME}" "$@"
- local f hash import line repo tarball vendor_tarballs x
- vendor_tarballs=()
- for line in "${EGO_VENDOR[@]}"; do
- read -r import hash repo x <<< "${line}"
- if [[ -n ${x} ]]; then
- eerror "Trailing information in EGO_VENDOR in
${P}.ebuild"
- eerror "${line}"
- die "Invalid EGO_VENDOR format"
- fi
- : "${repo:=${import}}"
- vendor_tarballs+=("${repo//\//-}-${hash}.tar.gz")
- done
- for f in ${A}; do
- [[ -n ${vendor_tarballs[*]} ]] && has "${f}"
"${vendor_tarballs[@]}" &&
- continue
- unpack "${f}"
- done
-
- [[ -z ${vendor_tarballs[*]} ]] && return
- for line in "${EGO_VENDOR[@]}"; do
- read -r import hash repo _ <<< "${line}"
- : "${repo:=${import}}"
- tarball=${repo//\//-}-${hash}.tar.gz
- ebegin "Vendoring ${import} ${tarball}"
- rm -fr "${S}/vendor/${import}" || die
- mkdir -p "${S}/vendor/${import}" || die
- tar -C "${S}/vendor/${import}" -x --strip-components 1 \
- -f "${DISTDIR}/${tarball}" || die
- eend
- done
- # replace GOFLAGS if EGO_VENDOR is being used
- [[ ${#EGO_VENDOR[@]} -gt 0 ]] &&
- GOFLAGS="-v -x -mod=vendor"
- eqawarn "${P}.ebuild: EGO_VENDOR will be removed in the future."
- eqawarn "Please request that the author migrate to EGO_SUM."
-}
-
# @FUNCTION: _go-module_src_unpack_verify_gosum
# @DESCRIPTION:
# Validate the Go modules declared by EGO_SUM are sufficient to cover building
--
2.26.2
[gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass
All, now that go 1.14.2 is stable, I want to remove the EGO_VENDOR support from go-module.eclass. This was kept when the EGO_SUM support was added on 4 Mar, with a qa warning advising people to migrate their ebuilds to EGO_SUM. This patch makes migrating mandatory by forcing ebuilds to die if they have EGO_VENDOR set and are using go-module.eclass. Thoughts? William Hubbs (1): eclass/go-module.eclass: remove EGO_VENDOR support eclass/go-module.eclass | 81 +++-- 1 file changed, 6 insertions(+), 75 deletions(-) -- 2.26.2
[gentoo-dev] New eclass "dune"
Hi, I am working on a PR to update some dependencies for libguestfs in dev-ml:
https://github.com/gentoo/gentoo/pull/15421
I made a new eclass "dune" for the OCaml Dune build system, it is
based on the "oasis" eclass for the Oasis build system for OCaml.
I was told I need to post it to this list for review, so here it is:
# Copyright 1999-2020 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: dune.eclass
# @MAINTAINER:
# maintainer-nee...@gentoo.org
# @AUTHOR:
# Rafael Kitover
# @SUPPORTED_EAPIS: 5 6 7
# @BLURB: Provides functions for installing dune packages.
# @DESCRIPTION:
# Provides dependencies on dune and ocaml and default src_compile, src_test and
# src_install for dune-based packages.
# @ECLASS-VARIABLE: DUNE_PKG_NAME
# @DESCRIPTION:
# Sets the actual dune package name, if different from gentoo package name.
# Set before inheriting the eclass.
case ${EAPI:-0} in
5|6|7) ;;
*) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
esac
RDEPEND=">=dev-lang/ocaml-4:="
DEPEND="${RDEPEND}
dev-ml/dune"
dune_src_compile() {
dune build @install || die
}
dune_src_test() {
dune runtest || die
}
# @FUNCTION: dune-install
# @USAGE:
# @DESCRIPTION:
# Installs the dune packages given as arguments. For each "${pkg}" element in
# that list, "${pkg}.install" must be readable from "${PWD}/_build/default"
dune-install() {
local pkg
for pkg ; do
dune install \
--prefix="${ED%/}/usr" \
--libdir="${D%/}$(ocamlc -where)" \
"${pkg}" || die
done
}
dune_src_install() {
local pkg="${1:-${DUNE_PKG_NAME:-${PN}}}"
dune-install "${pkg}"
# Move docs to the appropriate place.
if [ -d "${ED%/}/usr/doc/${pkg}" ] ; then
mkdir -p "${ED%/}/usr/share/doc/${PF}/" || die
mv "${ED%/}/usr/doc/${pkg}/"*
"${ED%/}/usr/share/doc/${PF}/" || die
rm -rf "${ED%/}/usr/doc" || die
fi
}
EXPORT_FUNCTIONS src_compile src_test src_install
Re: [gentoo-dev] dev-python/llvmlite update to 0.32
W dniu nie, 10.05.2020 o godzinie 07∶21 -0400, użytkownik Aisha Tammy napisał: > On 5/10/20 2:02 AM, Michał Górny wrote: > > W dniu sob, 09.05.2020 o godzinie 22∶39 -0400, użytkownik Aisha > > Tammy > > napisał: > > > Hey all, > > > I was hoping to upgrade the dev-python/numba jit compiler in > > > proxy- > > > maint but it depends on dev-python/llvmlite >=0.31 > > > Current version of llvmlite is stuck at 0.30 which is preventing > > > the > > > numba package from being upgraded. > > > It is at a risk of last rite retiring because its stuck at 3.6 > > > > It is more likely to be last rited because upstream still didn't > > manage > > to port it to LLVM 9. I don't have LLVM 8 anymore, and I don't > > have > > the resources to build 3 different LLVM versions. > > > The following issue tells that LLVM 9 is now supported :) > https://github.com/numba/llvmlite/issues/523 > > They haven't updated their documentation correctly. I suppose this means using the fancy variable to disable LLVM version checks, correct? > > PS: regarding lack of resources. > I have a spare computer and am willing to use that to do some testing > for > interesting packages like these. I hope it can help us keep a few > more > packages that would otherwise be killed off. Well, my hardware died two days ago, so I should have more resources mid-next week. Until then, only minimal work that can be done with backup hardware. -- Best regards, Michał Górny
Re: [gentoo-dev] dev-python/llvmlite update to 0.32
On 10/05/2020 13:21, Aisha Tammy wrote: On 5/10/20 2:02 AM, Michał Górny wrote: W dniu sob, 09.05.2020 o godzinie 22∶39 -0400, użytkownik Aisha Tammy napisał: Hey all, I was hoping to upgrade the dev-python/numba jit compiler in proxy- maint but it depends on dev-python/llvmlite >=0.31 Current version of llvmlite is stuck at 0.30 which is preventing the numba package from being upgraded. It is at a risk of last rite retiring because its stuck at 3.6 It is more likely to be last rited because upstream still didn't manage to port it to LLVM 9. I don't have LLVM 8 anymore, and I don't have the resources to build 3 different LLVM versions. The following issue tells that LLVM 9 is now supported :) https://github.com/numba/llvmlite/issues/523 They haven't updated their documentation correctly. PS: regarding lack of resources. I have a spare computer and am willing to use that to do some testing for interesting packages like these. I hope it can help us keep a few more packages that would otherwise be killed off. PPS: an aside, but i was always curious where the term last rited came from. I feel like I am part of the mafia when I use that term XD It is more about being an undertaker :) lu
Re: [gentoo-dev] dev-python/llvmlite update to 0.32
On 5/10/20 7:21 AM, Aisha Tammy wrote: > On 5/10/20 2:02 AM, Michał Górny wrote: >> W dniu sob, 09.05.2020 o godzinie 22∶39 -0400, użytkownik Aisha Tammy >> napisał: >>> Hey all, >>> I was hoping to upgrade the dev-python/numba jit compiler in proxy- >>> maint but it depends on dev-python/llvmlite >=0.31 >>> Current version of llvmlite is stuck at 0.30 which is preventing the >>> numba package from being upgraded. >>> It is at a risk of last rite retiring because its stuck at 3.6 >> >> It is more likely to be last rited because upstream still didn't manage >> to port it to LLVM 9. I don't have LLVM 8 anymore, and I don't have >> the resources to build 3 different LLVM versions. >> > The following issue tells that LLVM 9 is now supported :) > https://github.com/numba/llvmlite/issues/523 > another issue which shows that even tests are now working :) https://github.com/easybuilders/easybuild-easyconfigs/pull/10133 Aisha > They haven't updated their documentation correctly. > > PS: regarding lack of resources. > I have a spare computer and am willing to use that to do some testing for > interesting packages like these. I hope it can help us keep a few more > packages that would otherwise be killed off. > > PPS: an aside, but i was always curious where the term last rited came from. > I feel like I am part of the mafia when I use that term XD > > Cheers, > Aisha >
Re: [gentoo-dev] dev-python/llvmlite update to 0.32
On 5/10/20 2:02 AM, Michał Górny wrote: > W dniu sob, 09.05.2020 o godzinie 22∶39 -0400, użytkownik Aisha Tammy > napisał: >> Hey all, >> I was hoping to upgrade the dev-python/numba jit compiler in proxy- >> maint but it depends on dev-python/llvmlite >=0.31 >> Current version of llvmlite is stuck at 0.30 which is preventing the >> numba package from being upgraded. >> It is at a risk of last rite retiring because its stuck at 3.6 > > It is more likely to be last rited because upstream still didn't manage > to port it to LLVM 9. I don't have LLVM 8 anymore, and I don't have > the resources to build 3 different LLVM versions. > The following issue tells that LLVM 9 is now supported :) https://github.com/numba/llvmlite/issues/523 They haven't updated their documentation correctly. PS: regarding lack of resources. I have a spare computer and am willing to use that to do some testing for interesting packages like these. I hope it can help us keep a few more packages that would otherwise be killed off. PPS: an aside, but i was always curious where the term last rited came from. I feel like I am part of the mafia when I use that term XD Cheers, Aisha
Re: [gentoo-dev] [PATCH v2 01/10] ruby-ng-gnome2.eclass: drop support for 0.19.x
On Mon, 2020-05-04 at 11:22 +0900, Naohiro Aota wrote: > The official tree no longer have ruby-gnome2 packages with 0.19.x. > Drop > support for them. All of these patches look fine to me. Please go ahead and merge. Hans signature.asc Description: This is a digitally signed message part
[gentoo-dev] dev-python/llvmlite update to 0.32
Hey all, I was hoping to upgrade the dev-python/numba jit compiler in proxy-maint but it depends on dev-python/llvmlite >=0.31 Current version of llvmlite is stuck at 0.30 which is preventing the numba package from being upgraded. It is at a risk of last rite retiring because its stuck at 3.6 Can anyone bump it to 0.32.1? It just came out 2 days ago so might be best to just work with that. additional information: don't use the 0.33.* releases as they are testing releases and prone to breaking. Thanks a lot for the work, Aisha
Re: [gentoo-dev] dev-python/llvmlite update to 0.32
W dniu sob, 09.05.2020 o godzinie 22∶39 -0400, użytkownik Aisha Tammy napisał: > Hey all, > I was hoping to upgrade the dev-python/numba jit compiler in proxy- > maint but it depends on dev-python/llvmlite >=0.31 > Current version of llvmlite is stuck at 0.30 which is preventing the > numba package from being upgraded. > It is at a risk of last rite retiring because its stuck at 3.6 It is more likely to be last rited because upstream still didn't manage to port it to LLVM 9. I don't have LLVM 8 anymore, and I don't have the resources to build 3 different LLVM versions. -- Best regards, Michał Górny
