Re: [gentoo-dev] [PATCH] enable build of gnat compiler in the toolchain eclass
On Fri, 3 Apr 2020 08:25:35 +0200 Tupone Alfredo wrote: > --- > eclass/toolchain.eclass | 25 ++--- > 1 file changed, 22 insertions(+), 3 deletions(-) Looks good! -- Sergei
[gentoo-dev] [PATCH] enable build of gnat compiler in the toolchain eclass
---
eclass/toolchain.eclass | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index ee466ee4d904..b003dc20cc5a 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -184,7 +184,7 @@ if [[ ${PN} != "kgcc64" && ${PN} != gcc-* ]] ; then
tc_version_is_at_least 6.5 &&
IUSE+=" graphite" TC_FEATURES+=(graphite)
tc_version_is_between 4.9 8 && IUSE+=" cilk"
- tc_version_is_at_least 4.9 && IUSE+=" +vtv"
+ tc_version_is_at_least 4.9 && IUSE+=" ada +vtv"
tc_version_is_at_least 5.0 && IUSE+=" jit"
tc_version_is_between 5.0 9 && IUSE+=" mpx"
tc_version_is_at_least 6.0 && IUSE+=" +pie +ssp +pch"
@@ -909,8 +909,7 @@ toolchain_src_configure() {
is_f77 && GCC_LANG+=",f77"
is_f95 && GCC_LANG+=",f95"
- # We do NOT want 'ADA support' in here!
- # is_ada && GCC_LANG+=",ada"
+ is_ada && GCC_LANG+=",ada"
confgcc+=( --enable-languages=${GCC_LANG} )
@@ -1270,6 +1269,10 @@ toolchain_src_configure() {
fi
fi
+ if in_iuse ada ; then
+ confgcc+=( --disable-libada )
+ fi
+
if in_iuse cilk ; then
confgcc+=( $(use_enable cilk libcilkrts) )
fi
@@ -1663,6 +1666,11 @@ toolchain_src_compile() {
[[ ! -x /usr/bin/perl ]] \
&& find "${WORKDIR}"/build -name '*.[17]' -exec touch {} +
+ # To compile ada library standard files special compiler options are
passed
+ # via ADAFLAGS in the Makefile.
+ # Unset ADAFLAGS as setting this override the options
+ 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
@@ -1731,6 +1739,17 @@ gcc_do_make() {
${GCC_MAKE_TARGET} \
|| die "emake failed with ${GCC_MAKE_TARGET}"
+ if is_ada; then
+ # Building standard ada library
+ emake -C gcc gnatlib-shared
+ # Without these links it is not getting the good compiler
+ # Need to check why
+ ln -s gcc ../build/prev-gcc || die
+ ln -s ${CHOST} ../build/prev-${CHOST} || die
+ # Building gnat toold
+ emake -C gcc gnattools
+ fi
+
if ! is_crosscompile && use_if_iuse cxx && use_if_iuse doc ; then
if type -p doxygen > /dev/null ; then
if tc_version_is_at_least 4.3 ; then
--
2.24.1
Re: [gentoo-dev] Changes to toolchain.eclass to better support gnat-gpl ebuild
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
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.
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.
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.
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
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
(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 a
[gentoo-dev] About merging "ayatana", "indicator", "libindicate", "appindicator" in one global USE flag
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.
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
+-
+-# FF_CHECK_
[gentoo-dev] [PATCH 1/2] profiles/desc/cpu_flags_x86.desc: add avx512dq and avx512vl.
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.
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
> 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
> 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.
> 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
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.
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
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
