[gentoo-portage-dev] [PATCH v2] NeededEntry: infer implicit soname from file basename (bug 715162)

2020-04-02 Thread Zac Medico
For dynamic libraries, infer an implicit DT_SONAME setting from the
file basename, which is consistent with dynamic linking behavior in
practice. This makes it possible to resolve soname dependencies for
musl's libc.so which lacks a DT_SONAME setting.

Bug: https://bugs.gentoo.org/715162
Signed-off-by: Zac Medico 
---
[PATCH v2] Use file command to distinguish shared library from PIE executable

 bin/misc-functions.sh   |  6 ++
 lib/portage/util/_dyn_libs/LinkageMapELF.py | 16 
 2 files changed, 22 insertions(+)

diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh
index 4f8a4112d..9efe99b87 100755
--- a/bin/misc-functions.sh
+++ b/bin/misc-functions.sh
@@ -183,6 +183,12 @@ install_qa_check() {
soname=${l%%;*}; l=${l#*;}
rpath=${l%%;*}; l=${l#*;}; [ "${rpath}" = "  -  " ] && 
rpath=""
needed=${l%%;*}; l=${l#*;}
+
+   # Infer implicit soname from basename (bug 715162).
+   if [[ -z ${soname} && $(file "${D%/}${obj}") == *"SB 
shared object"* ]]; then
+   soname=${obj##*/}
+   fi
+
echo "${obj} ${needed}" >> 
"${PORTAGE_BUILDDIR}"/build-info/NEEDED
echo "${arch:3};${obj};${soname};${rpath};${needed}" >> 
"${PORTAGE_BUILDDIR}"/build-info/NEEDED.ELF.2
done }
diff --git a/lib/portage/util/_dyn_libs/LinkageMapELF.py 
b/lib/portage/util/_dyn_libs/LinkageMapELF.py
index 70bec116a..2d4929445 100644
--- a/lib/portage/util/_dyn_libs/LinkageMapELF.py
+++ b/lib/portage/util/_dyn_libs/LinkageMapELF.py
@@ -311,6 +311,22 @@ class LinkageMapELF(object):
raise
# File removed concurrently.
continue
+
+   # Infer implicit soname from basename 
(bug 715162).
+   if not entry.soname:
+   try:
+   proc = 
subprocess.Popen([b'file',
+   
_unicode_encode(entry.filename,
+   
encoding=_encodings['fs'], errors='strict')],
+   
stdout=subprocess.PIPE)
+   out, err = 
proc.communicate()
+   proc.wait()
+   except EnvironmentError:
+   pass
+   else:
+   if b'SB shared object' 
in out:
+   entry.soname = 
os.path.basename(entry.filename)
+
entry.multilib_category = 
compute_multilib_category(elf_header)
entry.filename = 
entry.filename[root_len:]
owner = plibs.pop(entry.filename, None)
-- 
2.24.1




Re: [gentoo-dev] Changes to toolchain.eclass to better support gnat-gpl ebuild

2020-04-02 Thread Mike Gilbert
On Thu, Apr 2, 2020 at 6:52 AM Alfredo Tupone  wrote:
>
> I would like to have the attached changes reviewed and, if possible,
> applied to the toolchain eclass.

Please generate patches using git-format-patch, and send them using
git-send-email. This allows them to be easily reviewed in a mail
client.

> + if use ada; then
> + gcc_do_make "-C gcc gnatlib-shared"
> + ln -s gcc ../build/prev-gcc || die
> + ln -s ${CHOST} ../build/prev-${CHOST} || die
> + gcc_do_make "-C gcc gnattools"
> + fi

You probably want "is_ada" instead of "use ada" here. Otherwise,
portage will error if "ada" is not in IUSE.



[gentoo-dev] Re: Changes to toolchain.eclass to better support gnat-gpl ebuild

2020-04-02 Thread Sergei Trofimovich
On Thu, 2 Apr 2020 12:52:13 +0200
Alfredo Tupone  wrote:

> + # Do not set ADAFLAGS to build the compiler
> + unset ADAFLAGS

Can you clarify in a comment why it's done?

>   # Older gcc versions did not detect bash and re-exec itself, so force 
> the
>   # use of bash.  Newer ones will auto-detect, but this is not harmful.
>   # This needs to be set for compile as well, as it's used in libtool
>   # generation, which will break install otherwise (at least in 3.3.6): 
> #664486
>   CONFIG_SHELL="${EPREFIX}/bin/bash" \
>   gcc_do_make ${GCC_MAKE_TARGET}

> + if use ada; then
> + gcc_do_make "-C gcc gnatlib-shared"
> + ln -s gcc ../build/prev-gcc || die
> + ln -s ${CHOST} ../build/prev-${CHOST} || die
> + gcc_do_make "-C gcc gnattools"
> + fi

Two points:
1. You probably still need CONFIG_SHELL="${EPREFIX}/bin/bash" passed.
2. Can you add an inline comment why it's needed? Why 'make' does not Just Work?

-- 

  Sergei



Re: [gentoo-dev] Re: News item: Deprecation and removal of legacy X11 input drivers.

2020-04-02 Thread Gordon Pettey
On Thu, Apr 2, 2020 at 10:27 AM Piotr Karbowski 
wrote:

> while keeping the long sentence, that even it's long, is still beneficial
> to have
>

Split it for grammatical correctness and ease of human parsing.

The only use for those drivers remain in deployments which intentionally
> opt-out of using udev, as both evdev and libinput require udev during
> runtime, however given that upstream has already removed the Linux
>

Replace with "runtime. Given that upstream"

support from xf86-input-keyboard, future X11 releases will no longer
> support xf86-input-keyboard on Linux rendering those installation
>

installations should be plural


> infeasible to use without udev.
>


[gentoo-dev] Re: News item: Deprecation and removal of legacy X11 input drivers.

2020-04-02 Thread Piotr Karbowski
Hi,

On 02/04/2020 17.26, Piotr Karbowski wrote:
> Hi,
> 
> Updated with what Ulm and Soup pointed out, while keeping the long
> sentence, that even it's long, is still beneficial to have. Revision
> bumped to 2, date bumped to tomorrow's.

My apology, s/Soup/Soap/.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: News item: Deprecation and removal of legacy X11 input drivers.

2020-04-02 Thread Piotr Karbowski
Hi,

Updated with what Ulm and Soup pointed out, while keeping the long
sentence, that even it's long, is still beneficial to have. Revision
bumped to 2, date bumped to tomorrow's.

--- news item below ---

Title: Deprecation of legacy X11 input drivers
Author: Piotr Karbowski 
Posted: 2020-04-03
Revision: 2
News-Item-Format: 2.0
Display-If-Installed: x11-drivers/xf86-input-mouse
Display-If-Installed: x11-drivers/xf86-input-keyboard

The Gentoo X11 Team is announcing the deprecation and future removal of
the legacy X11 input drivers x11-drivers/xf86-input-mouse and
x11-drivers/xf86-input-keyboard. As of 2020-05-01 those input drivers
will be masked for removal.

These drivers have been deprecated for many years, first by
xf86-input-evdev and then by xf86-input-libinput.

The only use for those drivers remain in deployments which intentionally
opt-out of using udev, as both evdev and libinput require udev during
runtime, however given that upstream has already removed the Linux
support from xf86-input-keyboard, future X11 releases will no longer
support xf86-input-keyboard on Linux rendering those installation
infeasible to use without udev.

In order to ensure frictionless upgrade path for future X11 releases, we
have decided to deprecate those drivers that are not in active use by
pretty much any installation of Gentoo.

No action is required from end-users who are already using libinput (or
evdev). To check which driver is in use, one can use

$ grep 'Using input driver' ~/.local/share/xorg/Xorg.0.log

for the systems running xorg-server as regular user (-suid
+elogind/+systemd) or by running

# grep 'Using input driver' /var/log/Xorg.0.log

for those running xorg-server as root.

If however neither libinput or evdev is in use, one should append
'libinput' to the INPUT_DEVICES variable inside /etc/portage/make.conf
while removing 'keyboard' and 'mouse' if present, then update @world
with new USE flags

# emerge -N @world

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] zoom concerns

2020-04-02 Thread Thomas Deutschmann
Hi,

it's true that zoom is currently getting a lot of attention. It all
started with the iOS application using Facebook SDK to provide login
through Facebook and their TOS/privacy statement.

That triggered a lot of (security) researchers who are currently sitting
at home like most people in western world with a lot of time. If
upstream will address all problems this will become one of the best
(free-)audited conference software available ;-)

For this discussion please keep in mind that there are multiple versions
for different platforms. Not every platform is affected by all reported
problems.

Regarding zoom and Gentoo: net-im/zoom doesn't require any special
handling in Gentoo. Package is not even marked stable. We have a lot of
vulnerable packages...

If problems will get confirmed for the available Linux version and
upstream won't provide a fix within ~12 months (depends on severity of
reported vulnerabilities) we maybe decide to last-rite or apply a mask
to force user awareness through forced unmask action in case they need
that software. But again, this software isn't special and doesn't
require further discussion from our P.O.V.


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] RFC: Rethinking virtual/opencl and eselect-opencl

2020-04-02 Thread Marek Szuba
(with many thanks to everyone who mulled on this problem in #gentoo-dev
yesterday, mattst88 in particular)

So, yesterday's attempt to begin phasing support for 32-bit OpenCL out
of Gentoo (which, to remind everyone who may not have followed the
earlier discussion, would essentially acknowledge the status quo of most
OpenCL providers only supporting native amd64 ABI) has failed miserably:
the masking of abi_x86_32 in virtual/opencl on amd64 and of
virtual/opencl as a whole on x86 resulted in breakages in the dependency
graph.

On the one hand, there are several packages keyworded x86 which
unconditionally depend on virtual/opencl:
 - dev-libs/clhpp
 - dev-python/pyopencl
 - net-wireless/cpyrit-opencl
 - sci-libs/clblas
 - sci-libs/clblast
This is the easier part of the problem - seeing as most OpenCL providers
we now have in the tree (the exceptions being proprietary AMD and NVidia
drivers for legacy GPUs) do not support x86 anyway, it should be safe to
simply drop the keyword.

On the other, there is the much hairier issue of multilib-capable packages:
 - dev-libs/cl
 - app-emulation/crossover-bin
 - app-emulation/wine-staging
 - app-emulation/wine-vanilla
 - app-text/tesseract
 - media-libs/opencv
 - media-libs/x264
 - media-video/ffmpeg
for which the consensus of yesterday's discussion seems to be that
assuming the dropping of multilib or opencl support altogether is not an
option, we would have to have separate src_configure (at the very least)
stages for different ABIs.


It seems therefore that the easiest way of phasing out 32-bit OpenCL
would be for virtual/opencl to list a dummy provider that is both
keyworded x86 and multilib-capable, and provides both header files and
libraries reverse dependencies need to build successfully regardless of
what OpenCL devices, if any, are actually available. Fortunately there
already are packages in the tree which do just that - OpenCL ICD
loaders, i.e. dev-libs/ocl-icd (has stable keywords for both amd64 and
x86) and, since yesterday evening, dev-libs/opencl-icd-loader (the
official Khronos Group ICD loader, the first tagged version of which got
released in mid-March).

Then, between mattst88 and myself we have come to the conclusion that it
might in fact make sense to have virtual/opencl provide *only* an ICD
loader and merely inform the users what hardware-specific runtimes are
available. Advantages of this approach:
 - both ocl-icd and opencl-icd-loader are keyworded x86 (actually, I
realised this morning that I have made a mistake with the latter because
it is no longer up to developers to keyword things for x86 themselves -
but I *have* tested this in a 32-bit chroot) and multilib-capable so
they will keep the dependency tree consistent even if there are no
actual OpenCL runtimes capable of supporting abi_x86_32;
 - intel-neo, rocm-opencl-runtime, amdgpu-pro-opencl and mesa[opencl]
all actually *require* an IDC loader to work, intel-ocl-sdk (or at least
version 4 of it) works fine through a loader, and given
nvidia-drivers[uvm] ebuilds install an ICD file, I presume they are fine
with the loader as well;
 - not having to switch between OpenCL runtimes would allow us to phase
out eselect-opencl (similarly to how the introduction of an OpenGL
loader has allowed us to get rid of eselect-opengl), or at the very
least limit it to the management of OpenCL header files;
 - it would make it easier for users to enable out-of-tree runtimes,
e.g. manually installed whole AMDGPU-Pro stack or Beignet from an overlay;
 - the current VIDEO_CARDS-based way of selecting runtimes is quite
often misleading, namely:
* intel-neo only supports Intel GPUs from Broadwell onwards rather
than everything served by the i965 driver;
* amdgpu-pro-opencl is not compatible Vega 10 and newer GPUs, and to
make it worse it causes segfaults rather than simply ignore such GPUs;
* nvidia-drivers[uvm] is actually several sets of drivers, with
different versions appropriate for different GPUs;
* mesa[opencl] only supports some (old) Nvidia GPUs;
* intel-ocl-sdk does not support non-Intel amd64 CPUs.
  Having the options presented to users in human-readable fashion will
IMHO work better.


Therefore, mattst88 and I (or to clarify: the write-up is mine but Matt
has contributed several important points to it) would like to propose
the following steps to take:

1. Introduce a new version of virtual/opencl with RDEPEND consisting
*only* of app-eselect/eselect-opencl and
dev-libs/ocl-icd[khronos-headers], with the list of actual runtimes
moved to a postinst message and expanded to explain what works where;

2. Have all ebuilds of OpenCL runtimes depend on virtual/opencl
(replacing the dependency on dev-libs/ocl-icd wherever it is present)
but do NOT call "eselect opencl" if they currently do;

3. Test if downstream applications are happy with the new unified OpenCL
headers required by the Khronos Group ICD loader and if they are, add
dev-libs/opencl-icd-loader to virtual/opencl as 

[gentoo-dev] About merging "ayatana", "indicator", "libindicate", "appindicator" in one global USE flag

2020-04-02 Thread Pacho Ramos
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


signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH 2/2] sci-libs/fflas-ffpack: new package for finite-field linear algebra.

2020-04-02 Thread Michael Orlitzky
This is a straightforward import of the latest fflas-ffpack-2.4.3.ebuild
that François Bissey has been maintaining in the sage-on-gentoo overlay,
with only a few minor changes:

  * I added a "+" to the LICENSE to match the upstream LGPL-2.1+.

  * I switched the openmp check to use tc-check-openmp() conditionally
on the MERGE_TYPE variable.

  * Added BDEPEND="virtual/pkgconfig" since we patch in a call to
PKG_CHECK_MODULES.

I also removed a warning about build failures with USE=openmp. From what
I can tell, this stems from an older report (upstream Github issue 48)
using gcc-4.9.x that was never fully debugged. If the problems persist,
we can revisit that report, or just mask the flag.

Closes: https://bugs.gentoo.org/show_bug.cgi?id=715678
Package-Manager: Portage-2.3.89, Repoman-2.3.20
Signed-off-by: Michael Orlitzky 
---
 sci-libs/fflas-ffpack/Manifest|  1 +
 .../fflas-ffpack/fflas-ffpack-2.4.3.ebuild| 62 +
 .../files/fflas-ffpack-2.3.2-blaslapack.patch | 90 +++
 sci-libs/fflas-ffpack/metadata.xml| 37 
 4 files changed, 190 insertions(+)
 create mode 100644 sci-libs/fflas-ffpack/Manifest
 create mode 100644 sci-libs/fflas-ffpack/fflas-ffpack-2.4.3.ebuild
 create mode 100644 
sci-libs/fflas-ffpack/files/fflas-ffpack-2.3.2-blaslapack.patch
 create mode 100644 sci-libs/fflas-ffpack/metadata.xml

diff --git a/sci-libs/fflas-ffpack/Manifest b/sci-libs/fflas-ffpack/Manifest
new file mode 100644
index 000..d10a12abc35
--- /dev/null
+++ b/sci-libs/fflas-ffpack/Manifest
@@ -0,0 +1 @@
+DIST fflas-ffpack-2.4.3.tar.gz 1059033 BLAKE2B 
e416429bb426a81cf9c25d54c83380ff9a9d658c711da06e6359d968843d4d9d26cf8389379f9ad4a5cbcee93e0afc9fe0497bb7a8f190e0c72c0b1f7b67de18
 SHA512 
c7620ba5a92e4114a581a6bea32267f9d5a9f0eb7e23fc0a7a97ce4b8124bb7b29f89ff2ad6ad270d97c76489625b57a354e581905b74ee57b35f4ca3e196a44
diff --git a/sci-libs/fflas-ffpack/fflas-ffpack-2.4.3.ebuild 
b/sci-libs/fflas-ffpack/fflas-ffpack-2.4.3.ebuild
new file mode 100644
index 000..4115dc61ace
--- /dev/null
+++ b/sci-libs/fflas-ffpack/fflas-ffpack-2.4.3.ebuild
@@ -0,0 +1,62 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit autotools toolchain-funcs
+
+DESCRIPTION="Library for dense linear algebra over word-size finite fields"
+HOMEPAGE="https://linbox-team.github.io/fflas-ffpack/;
+SRC_URI="https://github.com/linbox-team/${PN}/releases/download/${PV}/${P}.tar.gz;
+
+LICENSE="LGPL-2.1+"
+SLOT="0"
+KEYWORDS="~amd64 ~x86 ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos"
+IUSE="static-libs openmp cpu_flags_x86_fma3 cpu_flags_x86_fma4 
cpu_flags_x86_sse3 cpu_flags_x86_ssse3 cpu_flags_x86_sse4_1 
cpu_flags_x86_sse4_2 cpu_flags_x86_avx cpu_flags_x86_avx2 cpu_flags_x86_avx512f 
cpu_flags_x86_avx512dq cpu_flags_x86_avx512vl"
+
+# Our autotools patch hacks in PKG_CHECK_MODULES calls.
+BDEPEND="virtual/pkgconfig"
+DEPEND="virtual/cblas
+   virtual/blas
+   virtual/lapack
+   dev-libs/gmp[cxx]
+   =sci-libs/givaro-4.1*"
+RDEPEND="${DEPEND}"
+
+PATCHES=( "${FILESDIR}/${PN}-2.3.2-blaslapack.patch" )
+
+pkg_pretend() {
+   [[ "${MERGE_TYPE}" != "binary" ]] && use openmp && tc-check-openmp
+}
+
+pkg_setup(){
+   tc-export PKG_CONFIG
+}
+
+src_prepare(){
+   default
+   eautoreconf
+}
+
+src_configure() {
+   econf \
+   --enable-precompilation \
+   $(use_enable openmp) \
+   $(use_enable cpu_flags_x86_fma3 fma) \
+   $(use_enable cpu_flags_x86_fma4 fma4) \
+   $(use_enable cpu_flags_x86_sse3 sse3) \
+   $(use_enable cpu_flags_x86_ssse3 ssse3) \
+   $(use_enable cpu_flags_x86_sse4_1 sse41) \
+   $(use_enable cpu_flags_x86_sse4_2 sse42) \
+   $(use_enable cpu_flags_x86_avx avx) \
+   $(use_enable cpu_flags_x86_avx2 avx2) \
+   $(use_enable cpu_flags_x86_avx512f avx512f) \
+   $(use_enable cpu_flags_x86_avx512dq avx512dq) \
+   $(use_enable cpu_flags_x86_avx512vl avx512vl) \
+   $(use_enable static-libs static)
+}
+
+src_install(){
+   default
+   find "${ED}" -name '*.la' -delete || die
+}
diff --git a/sci-libs/fflas-ffpack/files/fflas-ffpack-2.3.2-blaslapack.patch 
b/sci-libs/fflas-ffpack/files/fflas-ffpack-2.3.2-blaslapack.patch
new file mode 100644
index 000..3154a261819
--- /dev/null
+++ b/sci-libs/fflas-ffpack/files/fflas-ffpack-2.3.2-blaslapack.patch
@@ -0,0 +1,90 @@
+diff --git a/configure.ac b/configure.ac
+index 5b46b18..5e0264a 100644
+--- a/configure.ac
 b/configure.ac
+@@ -248,49 +248,24 @@ dnl echo 
'**
+ dnl exit 1
+ dnl ])
+ 
+-BLAS_FOUND=false
+-
+-FF_CHECK_BLAS_CFLAGS
+-FF_CHECK_BLAS_LIBS
+-FF_CHECK_MKL
+-FF_CHECK_USER_BLAS
+-FF_CHECK_USER_LAPACK
+-
+-FF_OPENBLAS_NUM_THREADS
+-
+-# 

[gentoo-dev] [PATCH 1/2] profiles/desc/cpu_flags_x86.desc: add avx512dq and avx512vl.

2020-04-02 Thread Michael Orlitzky
These two flags are already supported by cpuid2cpuflags, but so far no
package in ::gentoo uses them. The forthcoming sci-libs/fflas-ffpack
will use them, however, and -- given that they're CPU flags whose names
are fixed -- it seems most sensible to add them globally right away.

Bug: https://bugs.gentoo.org/715678
---
 profiles/desc/cpu_flags_x86.desc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/profiles/desc/cpu_flags_x86.desc b/profiles/desc/cpu_flags_x86.desc
index d891398e7a6..156b677e5a4 100644
--- a/profiles/desc/cpu_flags_x86.desc
+++ b/profiles/desc/cpu_flags_x86.desc
@@ -10,7 +10,9 @@
 aes - Enable support for Intel's AES instruction set (AES-NI)
 avx - Adds support for Advanced Vector Extensions instructions
 avx2 - Adds support for Advanced Vector Extensions 2 instructions
+avx512dq - Use AVX-512 double- and quad-word instructions
 avx512f - Adds support for AVX-512 Foundation instructions
+avx512vl - Use AVX-512 vector-length instructions
 f16c - Adds support for F16C instruction set for converting between 
half-precision and single-precision floats
 fma3 - Use the Fused Multiply Add 3 instruction set ([fma] in cpuinfo)
 fma4 - Use the Fused Multiply Add 4 instruction set
-- 
2.24.1




[gentoo-dev] [PATCH 0/2] New x86 CPU flags and a package to use them.

2020-04-02 Thread Michael Orlitzky
Sending to the list because it adds two new global CPU flags, already
supported by cpuid2cpuflags but not listed in the profiles yet.

Michael Orlitzky (2):
  profiles/desc/cpu_flags_x86.desc: add avx512dq and avx512vl.
  sci-libs/fflas-ffpack: new package for finite-field linear algebra.

 profiles/desc/cpu_flags_x86.desc  |  2 +
 sci-libs/fflas-ffpack/Manifest|  1 +
 .../fflas-ffpack/fflas-ffpack-2.4.3.ebuild| 62 +
 .../files/fflas-ffpack-2.3.2-blaslapack.patch | 90 +++
 sci-libs/fflas-ffpack/metadata.xml| 37 
 5 files changed, 192 insertions(+)
 create mode 100644 sci-libs/fflas-ffpack/Manifest
 create mode 100644 sci-libs/fflas-ffpack/fflas-ffpack-2.4.3.ebuild
 create mode 100644 
sci-libs/fflas-ffpack/files/fflas-ffpack-2.3.2-blaslapack.patch
 create mode 100644 sci-libs/fflas-ffpack/metadata.xml

-- 
2.24.1




Re: [gentoo-dev] zoom concerns

2020-04-02 Thread Ulrich Mueller
> On Thu, 02 Apr 2020, Rich Freeman wrote:

> I guess we could stick an einfo in the post-install messages,

Not sure if that's necessary. Zoom is a proprietary, closed-source,
fetch-restricted package, so users should know that they cannot expect
the same level of quality as for free software. (In the default
configuration, it is license-masked, so users must explicitly unmask
it before installation.)

> but if you're joining a zoom meeting are you going to be any more
> secure if you manually install the files instead? I can't imagine that
> people are going to stop attending meetings just because they picked
> the wrong software to host them. Plus a few of those concerns apply to
> MANY packages - such as a lack of end-to-end encryption, or ever
> having had a zero day.

> I'm not intending to endorse Zoom here, but Gentoo isn't really
> intended as a purist distro that will never include a package if it is
> associated with a service that might collect user data and so on.  In
> fact, we have many packages with these associations.  Ultimately users
> can decide what they want to run, and we're just providing the files
> in the most convenient and secure manner possible.  For example, when
> the zero day is fixed if you're using Gentoo you'll benefit from our
> security policy, while you would not if you had just manually
> installed some files/etc...

+1

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] zoom concerns

2020-04-02 Thread Ulrich Mueller
> On Thu, 02 Apr 2020, Alessandro Barbieri wrote:

> I have concerns about the inclusion of zoom in ::gentoo. For me it's
> more like a malware.

Gentoo is about choice. If users want to use Zoom (or have to, because
their employer schedules a meeting using that platform) then it is not
our call to stop them.

> From the hacker news feed you'll find out that:

> [1] zero day vulnerability found
> [2] passwords are truncated to 32 bit
> [3] previously sent data to facebook
> [4] end to end traffic isn't encrypted
> [5] signed binary run unsigned script

> 1 https://techcrunch.com/2020/04/01/zoom-doom/?guccounter=1
> 2 https://news.ycombinator.com/item?id=22749706
> 3 
> https://www.vice.com/en_us/article/z3b745/zoom-removes-code-that-sends-data-to-facebook
> 4 https://theintercept.com/2020/03/31/zoom-meeting-encryption/
> 5 https://news.ycombinator.com/item?id=22746764

Right, and I (as its Gentoo maintainer) won't recommend Zoom to anyone,
nor use it myself unless I am forced to.

However, if we would remove the package from the Gentoo repo, users
would inevitably install it from one of the overlays listed at
https://gpo.zugaina.org/net-im/zoom-bin (there are even more, named
net-im/zoom or app-office/zoom), which vary in quality. Most of them
install bundled libraries which are old and vulnerable, e.g. Qt 5.9.6.

I believe that the number of overlays (more than a dozen) containing the
package shows that there is demand for it. In the main tree we have at
least a chance to address bug reports.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] News item: Deprecation and removal of legacy X11 input drivers.

2020-04-02 Thread Ulrich Mueller
> On Thu, 02 Apr 2020, Piotr Karbowski wrote:

> Title: Deprecation and removal of legacy X11 input drivers.

Title has 52 chars which is too long (omit the full stop for a start).

> Author: Piotr Karbowski 
> Posted: 2020-04-02
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: x11-drivers/xf86-input-mouse
> Display-If-Installed: x11-drivers/xf86-input-keyboard

> The Gentoo X11 Team is announcing the deprecation and future removal of
> the legacy X11 input drivers x11-drivers/xf86-input-mouse and
> x11-drivers/xf86-input-keyboard. As of 2020-05-01 those input drivers
> will be masked for removal.

> These drivers have been deprecated for many years, first by
> xf86-input-evdev and

Why the line break here?

> then by xf86-input-libinput.

> The only use for those drivers remain in deployments which intentionally
> opt-out of using udev, as both evdev and libinput require udev during
> runtime, however given that upstream has already removed the Linux
> support from xf86-input-keyboard, future X11 releases will no longer
> support xf86-input-keyboard on Linux rendering those installation
> infeasible to use without udev.

Very long sentence which is hard to read.

> In order to ensure fraction-less upgrade path for future X11 releases,
> we have decided to deprecate those drivers that are not in active use by
> pretty much any installation of Gentoo.

> No action is required from end-users who are already using libinput (or
> evdev). To check which driver is in use, one can use

> $ grep 'Using input driver' ~/.local/share/xorg/Xorg.0.log

> For the systems running xorg-server as regular user (-suid

You don't start a new sentence here, so s/For/for/.

> +elogind/+systemd) or by running

> # grep 'Using input driver' /var/log/Xorg.0.log

> for those that still runs xorg-server as root.

s/that still runs/running/

> If however neither libinput or evdev is in use, one should append
> 'libinput' to the INPUT_DEVICES variable inside /etc/portage/make.conf
> and update @world with new USE flags

> # emerge -N @world

Shouldn't users remove "keyboard" and "mouse" from their INPUT_DEVICES?

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Changes to toolchain.eclass to better support gnat-gpl ebuild

2020-04-02 Thread Alfredo Tupone
I would like to have the attached changes reviewed and, if possible,
applied to the toolchain eclass.

This will simplify the gnat-gpl ebuild and is a step to add ada to
sys-devel/gcc

And also I suggest temporary to mask the ada flag for sys-devel/gcc

Thanks

Alfredo Tupone
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index ee466ee4d904..c18864b60ded 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -172,31 +172,31 @@ if [[ ${PN} != "kgcc64" && ${PN} != gcc-* ]] ; then
 	tc_version_is_at_least 4.2 && IUSE+=" +openmp"
 	tc_version_is_at_least 4.3 && IUSE+=" fixed-point"
 	tc_version_is_at_least 4.7 && IUSE+=" go"
 	# sanitizer support appeared in gcc-4.8, but  src_compile <
 
 toolchain_src_compile() {
 	touch "${S}"/gcc/c-gperf.h
 
 	# Do not make manpages if we do not have perl ...
 	[[ ! -x /usr/bin/perl ]] \
 		&& find "${WORKDIR}"/build -name '*.[17]' -exec touch {} +
 
+	# Do not set ADAFLAGS to build the compiler
+	unset ADAFLAGS
+
 	# Older gcc versions did not detect bash and re-exec itself, so force the
 	# use of bash.  Newer ones will auto-detect, but this is not harmful.
 	# This needs to be set for compile as well, as it's used in libtool
 	# generation, which will break install otherwise (at least in 3.3.6): #664486
 	CONFIG_SHELL="${EPREFIX}/bin/bash" \
 	gcc_do_make ${GCC_MAKE_TARGET}
+	if use ada; then
+		gcc_do_make "-C gcc gnatlib-shared"
+		ln -s gcc ../build/prev-gcc || die
+		ln -s ${CHOST} ../build/prev-${CHOST} || die
+		gcc_do_make "-C gcc gnattools"
+	fi
 }
 
 gcc_do_make() {
 	# This function accepts one optional argument, the make target to be used.
 	# If omitted, gcc_do_make will try to guess whether it should use all,
 	# or bootstrap-lean depending on CTARGET and arch.
 	# An example of how to use this function:
 	#
 	#	gcc_do_make all-target-libstdc++-v3
 
 	[[ -n ${1} ]] && GCC_MAKE_TARGET=${1}
 
 	# default target
 	if is_crosscompile || tc-is-cross-compiler ; then
 		# 3 stage bootstrapping doesnt quite work when you cant run the


Re: [gentoo-dev] News item: Deprecation and removal of legacy X11 input drivers.

2020-04-02 Thread David Seifert
On Thu, 2020-04-02 at 00:44 +0200, Piotr Karbowski wrote:
> Title: Deprecation and removal of legacy X11 input drivers.
> Author: Piotr Karbowski 
> Posted: 2020-04-02
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: x11-drivers/xf86-input-mouse
> Display-If-Installed: x11-drivers/xf86-input-keyboard
> 
> The Gentoo X11 Team is announcing the deprecation and future removal of
> the legacy X11 input drivers x11-drivers/xf86-input-mouse and
> x11-drivers/xf86-input-keyboard. As of 2020-05-01 those input drivers
> will be masked for removal.
> 
> These drivers have been deprecated for many years, first by
> xf86-input-evdev and
> then by xf86-input-libinput.
> 
> The only use for those drivers remain in deployments which intentionally
> opt-out of using udev, as both evdev and libinput require udev during
> runtime, however given that upstream has already removed the Linux
> support from xf86-input-keyboard, future X11 releases will no longer
> support xf86-input-keyboard on Linux rendering those installation
> infeasible to use without udev.
> 
> In order to ensure fraction-less upgrade path for future X11 releases,

nice Freudian there ;)

> we have decided to deprecate those drivers that are not in active use by
> pretty much any installation of Gentoo.
> 
> No action is required from end-users who are already using libinput (or
> evdev). To check which driver is in use, one can use
> 
> $ grep 'Using input driver' ~/.local/share/xorg/Xorg.0.log
> 
> For the systems running xorg-server as regular user (-suid
> +elogind/+systemd) or by running
> 
> # grep 'Using input driver' /var/log/Xorg.0.log
> 
> for those that still runs xorg-server as root.
> 
> If however neither libinput or evdev is in use, one should append
> 'libinput' to the INPUT_DEVICES variable inside /etc/portage/make.conf
> and update @world with new USE flags
> 
> # emerge -N @world
> 
> 




Re: [gentoo-dev] zoom concerns

2020-04-02 Thread Michal Prívozník
On 2. 4. 2020 7:51, Michał Górny wrote:
> On Thu, 2020-04-02 at 10:13 +0800, William Kenworthy wrote:
>> And I would like to add that sometimes you don't have a choice - if 
>> someone who is paying you says to use zoom, there is no choice
> 
> You always have a choice.  You can live poor and happy!  ;-)
> 
>>  - but I 
>> would rather use gentoo than fire up the MS laptop..
> 
> ...and here's where we disagree.  It's better to run risky apps
> on a throwaway system than let them damage or crack your primary system.
> 

Alternatively, you can set up a VM that contains nothing but the bare
minimum required to run app X and assign webcam to it, for instance.
Having said that, I'd still love the packaging system to install the app
as it resolves all the dependencies, etc.

Michal