Re: [gentoo-dev] [PATCH] virtual/opencl: new version
On Sat, 2020-04-04 at 22:59 +0100, Marek Szuba wrote:
> Instead of pulling in various OpenCL runtimes, only depend on
> eselect-opencl and an OpenCL ICD loader (dev-libs/ocl-icd) in order
> to provide hardware-independent header files and libraries for
> OpenCL-aware software to build against. Actual runtimes are now simply
> suggested to the user via a postinst message.
>
> Signed-off-by: Marek Szuba
> ---
> virtual/opencl/opencl-3.ebuild | 31 +++
> 1 file changed, 31 insertions(+)
> create mode 100644 virtual/opencl/opencl-3.ebuild
>
> diff --git a/virtual/opencl/opencl-3.ebuild b/virtual/opencl/opencl-3.ebuild
> new file mode 100644
> index 000..9851d1ccbeb
> --- /dev/null
> +++ b/virtual/opencl/opencl-3.ebuild
> @@ -0,0 +1,31 @@
> +# Copyright 1999-2020 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=6
Is there really a good reason to use an old EAPI here?
> +
> +inherit multilib-build
> +
> +DESCRIPTION="Virtual for OpenCL API"
> +SLOT="0"
> +KEYWORDS="~amd64 ~x86"
> +
> +RDEPEND="app-eselect/eselect-opencl
> + dev-libs/ocl-icd[khronos-headers,${MULTILIB_USEDEP}]"
Wouldn't it make sense to remove the virtual and just have stuff depend
on that instead?
> +
> +pkg_postinst() {
> + elog
> + elog "In order to take advantage of OpenCL you will need a runtime for
> your hardware."
> + elog "Currently included in Gentoo are:"
> + elog
> + elog "dev-libs/intel-neo - integrated Intel GPUs from Broadwell
> onwards. Open. 64-bit only"
> + elog "dev-libs/rocm-opencl-runtime - AMD GPUs supported by the
> amdgpu kernel driver. Mostly open [1]. 64-bit only"
> + elog "media-libs/mesa[opencl] - some older AMD GPUs; see [2]. Open.
> 32-bit support"
> + elog "dev-libs/amdgpu-pro-opencl - AMD Polaris GPUs. Proprietary,
> provided as-is. 32-bit support"
> + elog "dev-util/intel-ocl-sdk - Intel CPUs. Proprietary. 64-bit only"
> + elog "x11-drivers/nvidia-drivers[uvm] - Nvidia GPUs; specific
> package versions required for older ones [3]. Proprietary. 32-bit support"
> + elog
> + elog " [1] Proprietary library from dev-libs/hsa-ext-rocr required for
> image support"
> + elog " [2] https://dri.freedesktop.org/wiki/GalliumCompute/";
> + elog " [3] https://www.nvidia.com/en-us/drivers/unix/legacy-gpu/";
> + elog
> +}
This looks like README.gentoo material.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Re: [PATCH] 2020-04-04-new-ppc64le-profiles: Add news item
Clarification: this is just news item for review. Profiles need to be marked stable, before posting news item, but I see no reason not to. Old profiles will be deprecated and removed on June 1st 2020. Tracking bug: https://bugs.gentoo.org/715680 On Sat, 4 Apr 2020 19:37:32 -0700 Georgy Yakovlev wrote: > Signed-off-by: Georgy Yakovlev > --- > .../2020-04-04-new-ppc64le-profiles.en.txt| 25 +++ > 1 file changed, 25 insertions(+) > create mode 100644 > 2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt > > diff --git > a/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt > b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt > new file mode 100644 > index 000..c496154 > --- /dev/null > +++ b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt > @@ -0,0 +1,25 @@ > +Title: new ppc64le (little-endian) profiles > +Author: Georgy Yakovlev > +Posted: 2020-04-04 > +Revision: 1 > +News-Item-Format: 2.0 > +Display-If-Profile: > default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian > +Display-If-Profile: > default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd > + > +A new set of 17.0 ppc64le profiles has been added to the Gentoo repository. > +New profiles are compatible with existing ppc64 little-endian profiles, > +and no additional action required after switching the profile. > + > +Please migrate away from the old profiles: > + > +* Old profiles: > +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian > +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd > + > +* Replaced by: > +default/linux/ppc64le/17.0 > +default/linux/ppc64le/17.0/systemd > + > +Desktop profiles are now also available. > + > +Refer to `eselect profile list` output. > -- > 2.26.0 > -- Georgy Yakovlev pgp4vCSLEyCeW.pgp Description: PGP signature
[gentoo-dev] [PATCH] 2020-04-04-new-ppc64le-profiles: Add news item
Signed-off-by: Georgy Yakovlev --- .../2020-04-04-new-ppc64le-profiles.en.txt| 25 +++ 1 file changed, 25 insertions(+) create mode 100644 2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt diff --git a/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt new file mode 100644 index 000..c496154 --- /dev/null +++ b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt @@ -0,0 +1,25 @@ +Title: new ppc64le (little-endian) profiles +Author: Georgy Yakovlev +Posted: 2020-04-04 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd + +A new set of 17.0 ppc64le profiles has been added to the Gentoo repository. +New profiles are compatible with existing ppc64 little-endian profiles, +and no additional action required after switching the profile. + +Please migrate away from the old profiles: + +* Old profiles: +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd + +* Replaced by: +default/linux/ppc64le/17.0 +default/linux/ppc64le/17.0/systemd + +Desktop profiles are now also available. + +Refer to `eselect profile list` output. -- 2.26.0
[gentoo-dev] [PATCH] Refactor virtual/opencl to provide the API, not an implementation
As proposed in my e-mail to the list from two days ago. Advantage: OpenCL-aware ebuilds will have something to compile and link against regardless of whether the runtime invoked by the ICD loader supports abi_x86_32 or not, or indeed even if there is no suitable runtime in the Gentoo tree.
[gentoo-dev] [PATCH] virtual/opencl: new version
Instead of pulling in various OpenCL runtimes, only depend on
eselect-opencl and an OpenCL ICD loader (dev-libs/ocl-icd) in order
to provide hardware-independent header files and libraries for
OpenCL-aware software to build against. Actual runtimes are now simply
suggested to the user via a postinst message.
Signed-off-by: Marek Szuba
---
virtual/opencl/opencl-3.ebuild | 31 +++
1 file changed, 31 insertions(+)
create mode 100644 virtual/opencl/opencl-3.ebuild
diff --git a/virtual/opencl/opencl-3.ebuild b/virtual/opencl/opencl-3.ebuild
new file mode 100644
index 000..9851d1ccbeb
--- /dev/null
+++ b/virtual/opencl/opencl-3.ebuild
@@ -0,0 +1,31 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=6
+
+inherit multilib-build
+
+DESCRIPTION="Virtual for OpenCL API"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+
+RDEPEND="app-eselect/eselect-opencl
+ dev-libs/ocl-icd[khronos-headers,${MULTILIB_USEDEP}]"
+
+pkg_postinst() {
+ elog
+ elog "In order to take advantage of OpenCL you will need a runtime for
your hardware."
+ elog "Currently included in Gentoo are:"
+ elog
+ elog "dev-libs/intel-neo - integrated Intel GPUs from Broadwell
onwards. Open. 64-bit only"
+ elog "dev-libs/rocm-opencl-runtime - AMD GPUs supported by the
amdgpu kernel driver. Mostly open [1]. 64-bit only"
+ elog "media-libs/mesa[opencl] - some older AMD GPUs; see [2]. Open.
32-bit support"
+ elog "dev-libs/amdgpu-pro-opencl - AMD Polaris GPUs. Proprietary,
provided as-is. 32-bit support"
+ elog "dev-util/intel-ocl-sdk - Intel CPUs. Proprietary. 64-bit only"
+ elog "x11-drivers/nvidia-drivers[uvm] - Nvidia GPUs; specific
package versions required for older ones [3]. Proprietary. 32-bit support"
+ elog
+ elog " [1] Proprietary library from dev-libs/hsa-ext-rocr required for
image support"
+ elog " [2] https://dri.freedesktop.org/wiki/GalliumCompute/";
+ elog " [3] https://www.nvidia.com/en-us/drivers/unix/legacy-gpu/";
+ elog
+}
--
2.24.1
[gentoo-dev] Last rites: dev-python/cryptography-vectors
# Michał Górny (2020-04-04) # Package that used to provide test data for dev-python/cryptography. # The modern versions fetch it via SRC_URI and the last version # needing split vectors has been removed. # Removal in 30 days. Bug #716204. dev-python/cryptography-vectors -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] zoom concerns
On Thu, 2 Apr 2020 10:01:57 +0200 Michal Prívozník wrote: > 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. Depends how concerned you are about VM busting exploits contaminating the host. ( Maybe not Zoom in particular, but with regard to the general theme of "risky apps on a valued system" ) pgpZUwFC4DHyF.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] zoom concerns
On Wed, 1 Apr 2020 17:53:39 -0700 Alec Warner wrote: > you cannot accept arbitrary long > passwords Sure you can, as long as you're not storing them anywhere, and are instead, storing their checksum of some kind. Then the only limitations really are how much memory and time you have to locally buffer your password while the checksum computes it :) Nobody stores passwords right? Right? (/me then socially distances from the internet) pgprEtA_hfOHJ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ceph's static-libs
On Sat, 4 Apr 2020 10:43:26 +0100 James Le Cuirot wrote: > On Sat, 4 Apr 2020 08:12:09 +0200 > Alessandro Barbieri wrote: > > > I was trying to remove static-libs from hwloc and I noticed that the last > > bump of ceph is requiring hwloc:=[static-libs?] > > And I notices it needs also alot of other dependencies with [static-libs?] > > Is there a *valid* reason for having ceph[static-libs] around in the first > > place? > > > > For more context on static-libs see: > > https://projects.gentoo.org/qa/policy-guide/installed-files.html?highlight=static#pg0302 > > https://flameeyes.blog/2011/08/29/useless-flag-static-libs/ > > https://archives.gentoo.org/gentoo-dev/message/2dada80c2b9c85b0e83e6328428bf8ab > > > > I do like to have the option for static-libs where it's not too much > trouble. It's obviously not a mainline use case but I have needed it on > occasions. > > I think these dependencies are wrong though and I've seen the same > thing in other packages. You don't need the dependent static libs > when building other static libs. For example. I have webp[-static-libs] > installed and I can build leptonica[static-libs,webp] just fine. They > are only needed when linking executable binaries and for that, you'll > typically have a static USE flag rather than static-libs. QEMU is a good > example with its static and static-user USE flags. You could force a > package to build static or partially static binaries through toolchain > flags but then it's down to the user to ensure that all the dependent > static libs are in place. > > If the above paragraph is wrong, someone please correct me. :) Damn, I realised just as I hit send that there's a caveat here and that's sub-dependencies. If you're building a partially static binary then I think you're okay. A fully static binary obviously needs all its dependencies to be static and that includes any sub-dependencies. If an executable statically links libwebp.a with JPEG support but you don't have libjpeg.a then you'll end up with undefined references. That probably explains why the ceph dependencies are as they are but the resulting headache makes me think it's not worth the hassle. This is a power user case and I'd leave the users to figure it out. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpSUYY7AIIC8.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ceph's static-libs
On Sat, 4 Apr 2020 08:12:09 +0200 Alessandro Barbieri wrote: > I was trying to remove static-libs from hwloc and I noticed that the last > bump of ceph is requiring hwloc:=[static-libs?] > And I notices it needs also alot of other dependencies with [static-libs?] > Is there a *valid* reason for having ceph[static-libs] around in the first > place? > > For more context on static-libs see: > https://projects.gentoo.org/qa/policy-guide/installed-files.html?highlight=static#pg0302 > https://flameeyes.blog/2011/08/29/useless-flag-static-libs/ > https://archives.gentoo.org/gentoo-dev/message/2dada80c2b9c85b0e83e6328428bf8ab I do like to have the option for static-libs where it's not too much trouble. It's obviously not a mainline use case but I have needed it on occasions. I think these dependencies are wrong though and I've seen the same thing in other packages. You don't need the dependent static libs when building other static libs. For example. I have webp[-static-libs] installed and I can build leptonica[static-libs,webp] just fine. They are only needed when linking executable binaries and for that, you'll typically have a static USE flag rather than static-libs. QEMU is a good example with its static and static-user USE flags. You could force a package to build static or partially static binaries through toolchain flags but then it's down to the user to ensure that all the dependent static libs are in place. If the above paragraph is wrong, someone please correct me. :) -- James Le Cuirot (chewi) Gentoo Linux Developer pgpzFwxdMGt1r.pgp Description: OpenPGP digital signature
