Re: [gentoo-dev] [PATCH] Have x11-drivers/nvidia-drivers use an ICD loader
On 4/19/20 11:40 PM, Marek Szuba wrote: > As previously mentioned, x11-drivers/nvidia-drivers is the last OpenCL > runtime we have got in the tree to be migrated to the "must use an ICD > loader" approach to virtual/opencl. Unfortunately I have so far failed > to reach the maintainer of this package (jer) by either e-mail, > Bugzilla, or IRC - so I'm submitting this for review here. > > > He has been on devaway for a while. I would've much rather seen the differences between -r0 -r1 ebuilds to focus on what is actually done there. Not that I have any say what will be done in the end, but it's easier for the eyes... -- juippis signature.asc Description: OpenPGP digital signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-04-19 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2020-04-19 23:59 UTC. Removals: app-admin/packagekit20200419-06:50 mgorny e773cec5d96 app-admin/packagekit-base 20200419-06:50 mgorny 686422cba11 app-admin/packagekit-gtk20200419-06:49 mgorny 1b1b7642268 app-admin/packagekit-qt 20200419-06:48 mgorny dcf33fc7f0a app-backup/buttersink 20200419-07:24 mgorny 5e215cd9b24 app-backup/deja-dup 20200419-06:43 mgorny 874908215f8 app-portage/euscan 20200419-06:52 mgorny 9d503e2bc05 dev-python/gnome-python-base20200419-07:32 mgorny d5346fd01bf dev-python/gnome-python-desktop-base20200419-09:04 mgorny 5307dde9e7b dev-python/gnome-python-extras-base 20200419-07:31 mgorny e3beee2445c dev-python/gnome-vfs-python 20200419-07:31 mgorny 5fb2c2d6301 dev-python/gtkspell-python 20200419-07:31 mgorny 142b45448b0 dev-python/libbonobo-python 20200419-07:29 mgorny cc2b56ed17d dev-python/libgnomecanvas-python20200419-07:30 mgorny e69a34e909c dev-python/libgnome-python 20200419-07:28 mgorny 0dd06decc30 dev-python/librsvg-python 20200419-07:30 mgorny 35b6122fba8 dev-python/pyorbit 20200419-07:29 mgorny 5a885cd3d9e dev-python/soappy 20200419-07:23 mgorny 59b4885b229 dev-vcs/hgsubversion20200419-07:14 mgorny b21a2ee9bc0 dev-vcs/hgsvn 20200419-07:13 mgorny 90963adbb05 dev-vcs/hgview 20200419-07:13 mgorny 5a99ad4eb46 dev-vcs/mercurial-server20200419-07:12 mgorny c1e2593dc5e gnome-extra/gnome-packagekit20200419-06:44 mgorny e8033684d8e mail-filter/spambayes 20200419-07:22 mgorny 8040a597f24 media-libs/pyliblo 20200419-06:54 mgorny 7e2ab3e3c33 media-sound/gtklick 20200419-06:54 mgorny 25aee341fcb net-ftp/pybootd 20200419-07:25 mgorny 4bf0f052dc3 net-mail/automx 20200419-07:23 mgorny aada62d05ac sci-electronics/geda-xgsch2pcb 20200419-07:25 mgorny e9ffdafc7a9 sci-physics/espresso++ 20200419-07:33 mgorny d2049ce9200 www-apps/trac-accountmanager20200419-07:16 mgorny 0b2738079ec www-apps/trac-mercurial 20200419-07:16 mgorny f40f5c1492d www-apps/trac-tags 20200419-07:15 mgorny 5ae9f1f3934 Additions: acct-group/atheme-services 20200415-04:52 juippis ba731aee772 acct-group/consul 20200417-19:31 williamh 0871e0497e6 acct-group/gpib 20200418-14:36 dilfridge 8a19e46805f acct-group/vault20200417-23:12 williamh f9612ad0002 acct-user/atheme-services 20200415-04:59 juippis 5c6791a0964 acct-user/consul20200417-19:34 williamh 3c6027f9fe0 acct-user/vault 20200417-23:18 williamh 7e718b45c79 dev-perl/Dist-Zilla-Plugin-CheckExtraTests 20200416-16:00 kentnl 7c8e09a84f2 dev-perl/Dist-Zilla-Plugin-ContributorsFile 20200416-13:31 kentnl ea13fb6b6ee dev-perl/Dist-Zilla-Plugin-Git-Contributors 20200416-14:06 kentnl d840ce933a2 dev-perl/Dist-Zilla-Plugin-Meta-Contributors20200416-14:19 kentnl 63e3cf8ee5e dev-perl/Dist-Zilla-Plugin-NextVersion-Semantic 20200416-14:34 kentnl d1bec0891fd dev-perl/Dist-Zilla-Plugin-Run 20200416-14:56 kentnl 35f6c778048 dev-perl/Dist-Zilla-Plugin-Test-CPAN-Changes20200416-16:19 kentnl b6b1643b63d dev-perl/Path-Iterator-Rule 20200416-15:51 kentnl 0df6092e78b dev-perl/Test-Filename 20200416-15:43 kentnl deb6b70dc3d dev-python/distlib 20200418-15:07 mgorny 8603f6637a8 dev-python/gnome-python-base20200419-09:03 mgorny 8d845ac6c61 dev-python/mkautodoc20200410-10:04 juippis ddb72bf65a2 games-strategy/settlers-2-gold-data 20200418-20:46 chewi 0d98dd4b892 net-libs/libnma 20200419-15:34 leio a88483ae162 net-libs/libslirp 20200419-22:10 zmedico 33cd6352693 net-p2p/tremc 20200414-03:04 mgorny 8f786fdd9d3 sys-firmware/broadcom-bt
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
Hi Michael, On 4/19/20 9:09 PM, Michael Orlitzky wrote: > You can do whatever you want in an overlay, but you can't introduce > security vulnerabilities and license issues into thousands of peoples' > homes and businesses through ::gentoo because it makes your life a tiny > bit easier. > > The job description of distribution developer is, ultimately, to fix all > the dumb things that upstream does before packaging the result so that > your users get a consistent, usable, reliable, and secure product. But > the first step isn't optional. Re-packaging garbage is easy -- that's a > service nobody needs. > > Using ebuilds this way is also simply a waste of your time. If you're > not going to package the dependencies, then you're better off using the > upstream bundling tool. At least then you can update the hundreds of > bundled dependencies afterwards. With an ebuild that's not possible. I agree, I have the same concern and that's why I prefer to have an ebuild instead of using the docker container or running blindly the provided upstream bundling tool. Avoiding to package all unnecessary dependencies and keeping away the garbage can only be possible as you mentioned using the distribution tools. At least, with a Gentoo overlay, I can have software better than upstream provided and continue my work. > I don't mean to discourage you any more than necessary. I'm glad you > want to help. But please quit looking to Go as an example of anything > anyone should be doing. Thanks for your advice, but I believe that we win more with the ebuild for the development tools and base services, even if it will only be available in the overlay. Is better to have the eyes of experienced maintainers, Gentoo QA and sharing information, instead of keeping it standalone, perpetuating the bad procedures and software usage. I really feel like scoring when reviewing what I need to do for the ebuild, also when it makes me spent some more time. The profit comes afterwards! Best, Samuel signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH] x11-drivers/nvidia-drivers: migrate to >=virtual-opencl-3
Revbump each driver branch, with the following changes:
* drop keywords to ~arch where applicable
* do not depend on app-eselect/eselect-opencl
* if USE='kernel_linux uvm' [1,2], depend on >=virtual/opencl-3
* do not call 'eselect opencl nvidia'
[1] only USE=kernel_linux for 340.108 due to lack of IUSE=uvm
[2] check for kernel_linux because virtual/opencl is not, and now
likely never will be, keyworded for FreeBSD
Closes: https://bugs.gentoo.org/717042
Signed-off-by: Marek Szuba
---
.../nvidia-drivers-340.108-r1.ebuild | 497 +++
.../nvidia-drivers-390.132-r3.ebuild | 582 ++
.../nvidia-drivers-430.64-r2.ebuild | 553 +
.../nvidia-drivers-435.21-r2.ebuild | 571 +
.../nvidia-drivers-440.64-r1.ebuild | 577 +
.../nvidia-drivers-440.82-r1.ebuild | 577 +
6 files changed, 3357 insertions(+)
create mode 100644 x11-drivers/nvidia-drivers/nvidia-drivers-340.108-r1.ebuild
create mode 100644 x11-drivers/nvidia-drivers/nvidia-drivers-390.132-r3.ebuild
create mode 100644 x11-drivers/nvidia-drivers/nvidia-drivers-430.64-r2.ebuild
create mode 100644 x11-drivers/nvidia-drivers/nvidia-drivers-435.21-r2.ebuild
create mode 100644 x11-drivers/nvidia-drivers/nvidia-drivers-440.64-r1.ebuild
create mode 100644 x11-drivers/nvidia-drivers/nvidia-drivers-440.82-r1.ebuild
diff --git a/x11-drivers/nvidia-drivers/nvidia-drivers-340.108-r1.ebuild
b/x11-drivers/nvidia-drivers/nvidia-drivers-340.108-r1.ebuild
new file mode 100644
index 000..63c4692b345
--- /dev/null
+++ b/x11-drivers/nvidia-drivers/nvidia-drivers-340.108-r1.ebuild
@@ -0,0 +1,497 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+inherit desktop flag-o-matic linux-info linux-mod multilib-minimal \
+ nvidia-driver portability toolchain-funcs unpacker udev
+
+NV_URI="https://us.download.nvidia.com/XFree86/";
+X86_NV_PACKAGE="NVIDIA-Linux-x86-${PV}"
+AMD64_NV_PACKAGE="NVIDIA-Linux-x86_64-${PV}"
+X86_FBSD_NV_PACKAGE="NVIDIA-FreeBSD-x86-${PV}"
+AMD64_FBSD_NV_PACKAGE="NVIDIA-FreeBSD-x86_64-${PV}"
+
+DESCRIPTION="NVIDIA Accelerated Graphics Driver"
+HOMEPAGE="https://www.nvidia.com/";
+SRC_URI="
+ amd64-fbsd? (
${NV_URI}FreeBSD-x86_64/${PV}/${AMD64_FBSD_NV_PACKAGE}.tar.gz )
+ amd64? ( ${NV_URI}Linux-x86_64/${PV}/${AMD64_NV_PACKAGE}.run )
+ x86-fbsd? ( ${NV_URI}FreeBSD-x86/${PV}/${X86_FBSD_NV_PACKAGE}.tar.gz )
+ x86? ( ${NV_URI}Linux-x86/${PV}/${X86_NV_PACKAGE}.run )
+ tools? (
+
https://download.nvidia.com/XFree86/nvidia-settings/nvidia-settings-${PV}.tar.bz2
+ )
+"
+
+EMULTILIB_PKG="true"
+IUSE="acpi multilib kernel_FreeBSD kernel_linux static-libs +tools +X"
+KEYWORDS="-* ~amd64 ~x86"
+LICENSE="GPL-2 NVIDIA-r2"
+SLOT="0/${PV%.*}"
+
+COMMON="
+ kernel_linux? (
+ >=virtual/opencl-3
+ >=sys-libs/glibc-2.6.1
+ acct-group/video
+ )
+ tools? (
+ >=x11-libs/gtk+-2.4:2
+ dev-libs/atk
+ dev-libs/glib:2
+ dev-libs/jansson
+ x11-libs/gdk-pixbuf[X]
+ x11-libs/libX11
+ x11-libs/libXext
+ x11-libs/libXv
+ x11-libs/pango[X]
+ )
+ X? (
+ >=app-eselect/eselect-opengl-1.0.9
+ )
+"
+DEPEND="
+ ${COMMON}
+ app-arch/xz-utils
+ kernel_linux? ( virtual/linux-sources )
+"
+RDEPEND="
+ ${COMMON}
+ acpi? ( sys-power/acpid )
+ tools? ( !media-video/nvidia-settings )
+ X? (
+ =x11-libs/libvdpau-0.3-r1
+ sys-libs/zlib[${MULTILIB_USEDEP}]
+ multilib? (
+ >=x11-libs/libX11-1.6.2[${MULTILIB_USEDEP}]
+ >=x11-libs/libXext-1.3.2[${MULTILIB_USEDEP}]
+ )
+ )
+"
+REQUIRED_USE="tools? ( X )"
+QA_PREBUILT="opt/* usr/lib*"
+S=${WORKDIR}/
+NV_KV_MAX_PLUS="5.5"
+CONFIG_CHECK="!DEBUG_MUTEXES ~!LOCKDEP ~MTRR ~SYSVIPC ~ZONE_DMA"
+
+pkg_pretend() {
+ use x86 && CONFIG_CHECK+=" ~HIGHMEM"
+ nvidia-driver_check
+}
+
+pkg_setup() {
+ use x86 && CONFIG_CHECK+=" ~HIGHMEM"
+ nvidia-driver_check
+
+ # try to turn off distcc and ccache for people that have a problem with
it
+ export DISTCC_DISABLE=1
+ export CCACHE_DISABLE=1
+
+ if use kernel_linux; then
+ MODULE_NAMES="nvidia(video:${S}/kernel)"
+
+ # This needs to run after MODULE_NAMES (so that the eclass
checks
+ # whether the kernel supports loadable modules) but before
BUILD_PARAMS
+ # is set (so that KV_DIR is populated).
+ linux-mod_pkg_setup
+
+ BUILD_PARAMS="IGNORE_CC_MISMATCH=yes V=1 SYSSRC=${KV_DIR} \
+ SYSOUT=${KV_OUT_DIR} CC=$(tc-getBUILD_CC)"
+
+ # l
[gentoo-dev] [PATCH] Have x11-drivers/nvidia-drivers use an ICD loader
As previously mentioned, x11-drivers/nvidia-drivers is the last OpenCL runtime we have got in the tree to be migrated to the "must use an ICD loader" approach to virtual/opencl. Unfortunately I have so far failed to reach the maintainer of this package (jer) by either e-mail, Bugzilla, or IRC - so I'm submitting this for review here.
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: net-proxy/mitmproxy
I’ll try look at this. > On 19 Apr 2020, at 21:05, Michał Górny wrote: > > # Michał Górny (2020-04-19) > # Unmaintained. Stuck on Python 3.6. Needs version bump. > # Removal in 30 days. Bug #718458. > net-proxy/mitmproxy > > -- > Best regards, > Michał Górny >
Re: [gentoo-dev] Last rites: net-proxy/mitmproxy
On 19/04/2020 22.05, Michał Górny wrote: > # Michał Górny (2020-04-19) > # Unmaintained. Stuck on Python 3.6. Needs version bump. > # Removal in 30 days. Bug #718458. > net-proxy/mitmproxy Upstream claims it works with Py 3.8 https://github.com/mitmproxy/mitmproxy I can not look into that one, but it would be sad to see mitmproxy go. It has many users. -- Best, Jonas
[gentoo-dev] Last rites: x11-terms/roxterm
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. # Removal in 30 days. Bug #718548. x11-terms/roxterm -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: sys-boot/raspberrypi-mkimage
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. # Removal in 30 days. Bug #718530. sys-boot/raspberrypi-mkimage -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: sci-libs/Fiona
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. Some releases behind. # Removal in 30 days. Bug #718498. sci-libs/Fiona -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: sci-geosciences/seawater
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. # Removal in 30 days. Bug #718488. sci-geosciences/seawater -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: sci-geosciences/gpxpy
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. Numerous releases behind. # Removal in 30 days. Bug #718486. sci-geosciences/gpxpy -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On 4/19/20 3:41 PM, Samuel Bernardo wrote: >> >> EGO_SUM is not a legitimate approach to packaging. You have to create >> packages for each package. I know, it sounds crazy when you say it. >> > I understand what you mean, but deem this dependencies as internal > project dependencies where those libraries doesn't worth the effort to > package them all. I mean, most of these projects have an immutable > deployment approach that are not feasable to be packaged. The problem > starts from upstream... You can do whatever you want in an overlay, but you can't introduce security vulnerabilities and license issues into thousands of peoples' homes and businesses through ::gentoo because it makes your life a tiny bit easier. The job description of distribution developer is, ultimately, to fix all the dumb things that upstream does before packaging the result so that your users get a consistent, usable, reliable, and secure product. But the first step isn't optional. Re-packaging garbage is easy -- that's a service nobody needs. Using ebuilds this way is also simply a waste of your time. If you're not going to package the dependencies, then you're better off using the upstream bundling tool. At least then you can update the hundreds of bundled dependencies afterwards. With an ebuild that's not possible. I don't mean to discourage you any more than necessary. I'm glad you want to help. But please quit looking to Go as an example of anything anyone should be doing.
[gentoo-dev] Last rites: net-proxy/mitmproxy
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. Needs version bump. # Removal in 30 days. Bug #718458. net-proxy/mitmproxy -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: net-misc/trackma
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. # Removal in 30 days. Bug #718452. net-misc/trackma -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: net-analyzer/ripe-atlas-tools, net-libs/ripe-atlas-sagan, www-client/ripe-atlas-cousteau
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. In need of bump since 2016. # Removal in 30 days. Bug #718426. net-analyzer/ripe-atlas-tools net-libs/ripe-atlas-sagan www-client/ripe-atlas-cousteau -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: media-video/subliminal
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. Last release in 2016. # Removal in 30 days. Bug #718410. media-video/subliminal -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: media-sound/lyvi
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. Last release in 2014. # Removal in 30 days. Bug #718402. media-sound/lyvi -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: media-sound/beets
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. Has a few bugs reported, # including indication of poor ebuild state. # Removal in 30 days. Bug #718398. media-sound/beets -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On 2020-04-19 16:37, Michael Orlitzky wrote: > On 4/19/20 10:55 AM, Samuel Bernardo wrote: >> Taking into account the network sandbox requirement, sbt.eclass needs to >> download all dependencies with some approach like EGO_SUM implementation >> in go-module.eclass[1]. >> > EGO_SUM is not a legitimate approach to packaging. You have to create > packages for each package. I know, it sounds crazy when you say it. > I understand what you mean, but deem this dependencies as internal project dependencies where those libraries doesn't worth the effort to package them all. I mean, most of these projects have an immutable deployment approach that are not feasable to be packaged. The problem starts from upstream... Maybe that's the reason why docker is so popular in this cases... But to install the base development tools and services I prefer to have ebuilds rather than dockers. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About merging "ayatana", "indicator", "libindicate", "appindicator" in one global USE flag
Ühel kenal päeval, P, 19.04.2020 kell 20:20, kirjutas Mart Raudsepp: > > Personally I would opt for global "appindicator" as it seems to be > > more widely > > used and I think it is a bit more self-explanatory :/ > > So I assume we can have* > consensus here, so I'll start off with renaming it > in nm-applet as part of other changes, and assume this ends up as a > global USE flag eventually. Note that ayatana already is a global USE flag, but I agree with migrating that over to appindicator instead, just a global USE flag to remove then later as well. Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About merging "ayatana", "indicator", "libindicate", "appindicator" in one global USE flag
Ühel kenal päeval, E, 06.04.2020 kell 15:23, kirjutas Pacho Ramos: > El jue, 02-04-2020 a las 16:28 +0200, Pacho Ramos escribió: > > Hello, > > > > I was reviewing about how to enable globally on my system the usage > > of > > libappindicator and I realized that we have multiple names for that > > in the > > tree. > > "ayatana" is the only global one, while other packages are using > > "indicator", > > "libindicate", "appindicator"... > > > > Personally I would merge all them in only one, and I wonder if > > maybe > > "indicator" > > or "appindicator" would be more meaningful for most users than > > "ayatana", what > > do you think? > > > > Thanks > > Personally I would opt for global "appindicator" as it seems to be > more widely > used and I think it is a bit more self-explanatory :/ So I assume we can consensus here, so I'll start off with renaming it in nm-applet as part of other changes, and assume this ends up as a global USE flag eventually. Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On Sun, Apr 19, 2020 at 8:37 AM Michael Orlitzky wrote: > On 4/19/20 10:55 AM, Samuel Bernardo wrote: > > > > Taking into account the network sandbox requirement, sbt.eclass needs to > > download all dependencies with some approach like EGO_SUM implementation > > in go-module.eclass[1]. > > > > EGO_SUM is not a legitimate approach to packaging. You have to create > packages for each package. I know, it sounds crazy when you say it. > > EGO_SUM is great! -A
Re: [gentoo-dev] News item review: Python 3.7 to become the default target
On Sun, Apr 19, 2020 at 01:01:22PM +0200, Michał Górny wrote: > Hi, > > It's finally time to move away from 3.6. The news item is roughly based > on the one for 3.6, with some grammar fixes and removal of the EOL part. > [snip] lgtm. -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On 4/19/20 10:55 AM, Samuel Bernardo wrote: > > Taking into account the network sandbox requirement, sbt.eclass needs to > download all dependencies with some approach like EGO_SUM implementation > in go-module.eclass[1]. > EGO_SUM is not a legitimate approach to packaging. You have to create packages for each package. I know, it sounds crazy when you say it.
[gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
Hi Benda, Thanks for the reference to Java Packing policy since I haven't read it before. I also forget to mention maven build system in last email, but for now I'm only focused on scala and sbt. On 4/19/20 5:31 AM, Benda Xu wrote: > That's a good idea. What's your plan to realize the eclasses? Taking into account the network sandbox requirement, sbt.eclass needs to download all dependencies with some approach like EGO_SUM implementation in go-module.eclass[1]. Looking in more detail to scala ebuild[2] as a reference, as a quick brainstorm, I think that could be defined: sbt.eclass - ESBTV = This would set the DEPEND for sbt and set the necessary steps to java-pkg-2_pkg_setup, check-reqs_pkg_setup, check-reqs_pkg_pretend, java-pkg_getjars and do the substitution of SBTV in build.properties if required - envset parameters (src_prepare): definition of parameters to set necessary environment for sbt wrapper that use defined ESBTV - ESBT_SUM = - esbt_compile, esbt_run, esbt_package functions: to run sbt using envset wrapper in compile, test and install as necessary scala.eclass - ESCALAV = - ... to be defined as required Best, Samuel [1] https://devmanual.gentoo.org/eclass-reference/go-module.eclass/index.html [2] https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/scala/scala-2.12.10.ebuild signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: media-gfx/qrencode-python
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. No revdeps. Last release # in 2016. # Removal in 30 days. Bug #718340. media-gfx/qrencode-python -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: games-misc/doge
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. Last release in 2014. # Removal in 30 days. Bug #718312. games-misc/doge -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-vcs/git-imerge
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. # Removal in 30 days. Bug #718308. dev-vcs/git-imerge -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-vcs/ghp-import
# Michał Górny (2020-04-19) # Unmaintained. Stuck at Python 3.6. Many versions behind upstream. # Removal in 30 days. Bug #718300. dev-vcs/ghp-import -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-util/spec-cleaner
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. A few releases behind upstream. # Removal in 30 days. Bug #718296. dev-util/spec-cleaner -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-util/bumpversion
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. Missing tests. No revdeps. # Removal in 30 days. Bug #718288. dev-util/bumpversion -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-libs/stfl, net-news/newsboat
# Michał Górny (2020-04-19) # Both packages are unmaintained and have unresolved bugs. stfl # is stuck on Python 3.6 and newsboat is its only revdep. # Removal in 30 days. Bug #718286. dev-libs/stfl net-news/newsboat -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-text/doconce
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. A few releases behind upstream. # Removal in 30 days. Bug #718268. app-text/doconce -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-misc/openastro, app-misc/openastro-data
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. # Removal in 30 days. Bug #718238. app-misc/openastro app-misc/openastro-data -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-i18n/transifex-client
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. A few releases behind upstream. # Removal in 30 days. Bug #718222. app-i18n/transifex-client -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-crypt/manuale
# Michał Górny (2020-04-19) # Unmaintained. Discontinued upstream. Uses old ACMEv1 API. # Stuck on Python 3.6. # Removal in 30 days. Bug #718204. app-crypt/manuale -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-crypt/gkeys
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. Large number of unresolved bugs. # Removal in 30 days. Bug #702430. app-crypt/gkeys -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-admin/ngxtop
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. Last upstream activity in 2015. # Removal in 30 days. Bug #718184. app-admin/ngxtop -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-admin/installer
# Michał Górny (2020-04-19) # The maintainer retired and ceased the development. Stuck # on Python 3.6. # Removal in 30 days. Bug #718182. app-admin/installer -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-admin/ara
# Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. Multiple versions behind # upstream. # Removal in 30 days. Bug #718166. app-admin/ara -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] News item review: Python 3.7 to become the default target
Hi, It's finally time to move away from 3.6. The news item is roughly based on the one for 3.6, with some grammar fixes and removal of the EOL part. Please also note that this is the *last* call to port packages to Python 3.7 *and* 3.8. Python 3.6 is no longer receiving bugfixes for a long time now, and 3.7 will stop receiving them in June. That's how far behind we are. I would personally prefer going straight to 3.8 if that was realistically possible in less than 2 years. --- Title: Python 3.7 to become the default target Author: Michał Górny Posted: 2020-04-19 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: dev-lang/python:3.6 On 2020-05-04, Python 3.7 will replace Python 3.6 as one of the default Python target for Gentoo systems. The new default targets will be: PYTHON_TARGETS="python2_7 python3_7" PYTHON_SINGLE_TARGET="python3_7" If you have not overriden the value of those variables on your system, then your package manager will switch to the new targets immediately. In order to prevent dependency conflicts, please clean stray packages and rebuild/upgrade all packages with USE flag changes after the change, e.g.: emerge --depclean emerge -1vUD @world emerge --depclean Please note that upgrading dependencies in place may cause some of the package dependencies to be temporarily missing. While this should not affect scripts that are already fully loaded, it may cause ImportErrors while starting Python scripts or loading additional modules (only scripts running Python 3.6 are affected). In order to improve stability of the upgrade, you may choose to temporarily enable both targets, i.e. set in /etc/portage/make.conf or its equivalent: PYTHON_TARGETS="python2_7 python3_6 python3_7" PYTHON_SINGLE_TARGET="python3_6" This will cause the dependencies to include both Python 3.6 and 3.7 support on the next system upgrade. Once all packages are updated, you can restart your scripts, remove the custom setting and run another upgrade to remove support for Python 3.6. If you would like to postpone the switch to Python 3.7, you can copy the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET to /etc/portage/make.conf or its equivalent: PYTHON_TARGETS="python2_7 python3_6" PYTHON_SINGLE_TARGET="python3_6" If you would like to migrate your systems earlier, you can do the same with the new value. Please note that the switch is long overdue. Python 3.6 is no longer receiving bug fixes. Its planned end-of-life is 2021-12-23 but we will probably remove it earlier than that. [1] [1]:https://devguide.python.org/#status-of-python-branches -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: dev-java/oracle-{jdk,jre}-bin and revdeps
On Sun, 19 Apr 2020 11:30:25 +0200 "Haelwenn (lanodan) Monnier" wrote: > [2020-04-18 21:10:45-0700] Georgy Yakovlev: > > # Georgy Yakovlev (2020-04-18) > > # Unmaintained, vulnerable oracle java ebuilds, even fetching distfiles > > # requires agreement to restrictive license > > # Revdeps that still depend on oracle variants require javafx > > # Please use icedtea or openjdk instead. > > # Removal in 30 days. > > # https://bugs.gentoo.org/681828 > > dev-java/oracle-jdk-bin > > dev-java/oracle-jre-bin > > app-forensics/sleuthkit > > app-text/jabref-bin > > dev-java/netbeans-platform > > dev-java/netbeans-harness > > games-util/pogo-manager-bin > > net-p2p/bisq > > sci-mathematics/geogebra > > The mask on app-forensics/sleuthkit seems to be faulty/overkill: > optionally depends on java, only uses oracle-jdk on 4.7.0. > Thanks! my grep misfired. I removed it from package.mask, and masked java useflag for 4.7.0 instead. -- Georgy Yakovlev pgpAH_4mWfNs3.pgp Description: PGP signature
Re: [gentoo-dev] Last rites: dev-java/oracle-{jdk,jre}-bin and revdeps
[2020-04-18 21:10:45-0700] Georgy Yakovlev: > # Georgy Yakovlev (2020-04-18) > # Unmaintained, vulnerable oracle java ebuilds, even fetching distfiles > # requires agreement to restrictive license > # Revdeps that still depend on oracle variants require javafx > # Please use icedtea or openjdk instead. > # Removal in 30 days. > # https://bugs.gentoo.org/681828 > dev-java/oracle-jdk-bin > dev-java/oracle-jre-bin > app-forensics/sleuthkit > app-text/jabref-bin > dev-java/netbeans-platform > dev-java/netbeans-harness > games-util/pogo-manager-bin > net-p2p/bisq > sci-mathematics/geogebra The mask on app-forensics/sleuthkit seems to be faulty/overkill: optionally depends on java, only uses oracle-jdk on 4.7.0.
