Re: [gentoo-dev] dev-python/llvmlite update to 0.32
W dniu nie, 10.05.2020 o godzinie 14∶54 -0400, użytkownik Aisha Tammy napisał: > 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. Well, I've noticed it when I checked if they finally stopped requiring 8.*. I presumed they've added it instead of proper support for LLVM 9 but didn't expect it to actually pass tests (modulo two silly tests, one checking version and other exact error message). > > 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 > Well, hardware upgrade was long overdue, so there is the bright side. My plan was to keep the old PC as backup distcc node but I guess it wouldn't amount to much. It was Athlon64 x2 3800+ (from the times when they still called it 'Athlon64'). In any case, I've just tested the version bump and will push it shortly. Thanks! -- Best regards, Michał Górny
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
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 >
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