Re: [gentoo-dev] [PATCH] Have x11-drivers/nvidia-drivers use an ICD loader

2020-04-19 Thread Joonas Niilola

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

2020-04-19 Thread Robin H. Johnson
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

2020-04-19 Thread Samuel Bernardo
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

2020-04-19 Thread Marek Szuba
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)"
+
+   # 

[gentoo-dev] [PATCH] Have x11-drivers/nvidia-drivers use an ICD loader

2020-04-19 Thread Marek Szuba
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

2020-04-19 Thread Sam James
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

2020-04-19 Thread Jonas Stein
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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michael Orlitzky
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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Samuel Bernardo
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

2020-04-19 Thread Mart Raudsepp
Ü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

2020-04-19 Thread Mart Raudsepp
Ü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

2020-04-19 Thread Alec Warner
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

2020-04-19 Thread Aaron Bauman
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

2020-04-19 Thread Michael Orlitzky
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

2020-04-19 Thread Samuel Bernardo
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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
# 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

2020-04-19 Thread Michał Górny
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

2020-04-19 Thread Georgy Yakovlev
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-19 Thread Haelwenn (lanodan) Monnier
[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.