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

2020-04-05 Thread Michał Górny
On Sun, 2020-04-05 at 22:13 +0100, Marek Szuba wrote:
> On 2020-04-02 15:31, Marek Szuba wrote:
> 
> > 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 an alternative to ocl-icd;
> 
> Quick update on this: today I have attempted to rebuild and test various
> OpenCL-dependent packages using the unified headers and
> dev-libs/opencl-icd-loader. The good news is, they have all been
> perfectly happy with them. The bad news is, I actually had to manually
> symlink all contents
> /usr/lib/OpenCL/vendors/opencl-icd-loader/include/CL/ into
> /usr/include/CL/ for this to work because eselect-opencl contains a
> hard-coded list of expected vendor header files.
> 
> In other words, it will be necessary to either teach eselect-opencl how
> to handle the unified headers or make it possible for it to let the
> contents of /usr/include/CL be. Personally I am leaning towards the
> latter - it doesn't even handle legacy headers that well (it installs
> several versions into /usr/lib/OpenCL/global but in the end offers no
> way of switching between them), and in any case even its description
> suggests its job is to switch between implementations rather than handle
> global headers.

While at it, is there any chance to rewrite eselect-opencl so that it
stops writing into /usr and uses environment approach like eselect-
opengl does?

-- 
Best regards,
Michał Górny



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


[gentoo-dev] package up for grabs: net-news/newsboat

2020-04-05 Thread Georgy Yakovlev
No longer use it.
Needs a minor bump, upstream changed doc dependency to asciidoctor.
Uses custom build system and rust,
may be tricky to maintain, but I can help.

Couple of open bugs: arm keywording and musl related build falure.

net-news/newsboat


-- 
Georgy Yakovlev 


pgpTpfceqLlmO.pgp
Description: PGP signature


[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-04-05 23:59 UTC

2020-04-05 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-05 23:59 UTC.

Removals:
dev-go/ed25519 20200403-18:53 marecki   
6a02720bdc2
dev-libs/yaml-cpp  20200403-02:12 chutzpah  
aff9434d4a7
dev-python/scikit-learn20200403-03:29 chutzpah  
6c6ad913cdf

Additions:
app-portage/nattka 20200401-13:08 mgorny
f02867d2f8c
dev-erlang/p1_acme 20200401-10:28 hanno 
e50bcb76481
dev-libs/libjcat   20200330-14:28 marecki   
c9213e24cce
dev-libs/opencl-icd-loader 20200401-23:49 marecki   
d1e684dfb02
dev-libs/yaml-cpp  20200401-00:47 chutzpah  
1c44179b7a2
dev-python/mongomock   20200404-02:09 gyakovlev 
db0818a9fe2
dev-python/scikit-learn20200401-21:02 chutzpah  
fbcfc13e1a4
dev-python/sentinels   20200404-00:54 gyakovlev 
55dd40bfe97
dev-python/threadpoolctl   20200401-20:03 chutzpah  
9cda95ce84a
dev-util/cargo-c   20200404-15:41 lu_zero   
1aa5977995b
dev-util/opencl-headers20200401-22:36 marecki   
2285b1c8376
games-simulation/slime-rancher 20200401-21:19 chewi 
00b5384e280
gnome-extra/gnome-shell-extension-appindicator 20200402-18:54 pacho 
43b79f16187
net-misc/asterisk-opus 20200321-18:30 juippis   
15674585042
net-vpn/ocserv 20200403-04:12 floppym   
0b4cb431553
net-vpn/tailscale  20200331-02:58 chutzpah  
ed5ccfe9186
net-wireless/dump978   20200402-19:21 zerochaos 
4eac9d917f7
sci-libs/fflas-ffpack  20200401-23:59 mjo   
8db3670e790
sci-mathematics/flintqs20200327-19:38 mjo   
1e6e5e555c6
sys-cluster/kubernetes 20200330-21:31 williamh  
5fa5afed555
sys-fs/sandboxfs   20200401-09:03 gyakovlev 
f663bdc6560

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
dev-go/ed25519,removed,marecki,20200403-18:53,6a02720bdc2
dev-python/scikit-learn,removed,chutzpah,20200403-03:29,6c6ad913cdf
dev-libs/yaml-cpp,removed,chutzpah,20200403-02:12,aff9434d4a7
Added Packages:
dev-python/mongomock,added,gyakovlev,20200404-02:09,db0818a9fe2
dev-python/sentinels,added,gyakovlev,20200404-00:54,55dd40bfe97
dev-util/cargo-c,added,lu_zero,20200404-15:41,1aa5977995b
sci-libs/fflas-ffpack,added,mjo,20200401-23:59,8db3670e790
net-vpn/ocserv,added,floppym,20200403-04:12,0b4cb431553
net-wireless/dump978,added,zerochaos,20200402-19:21,4eac9d917f7
gnome-extra/gnome-shell-extension-appindicator,added,pacho,20200402-18:54,43b79f16187
dev-libs/opencl-icd-loader,added,marecki,20200401-23:49,d1e684dfb02
dev-util/opencl-headers,added,marecki,20200401-22:36,2285b1c8376
games-simulation/slime-rancher,added,chewi,20200401-21:19,00b5384e280
dev-python/scikit-learn,added,chutzpah,20200401-21:02,fbcfc13e1a4
dev-python/threadpoolctl,added,chutzpah,20200401-20:03,9cda95ce84a
dev-libs/yaml-cpp,added,chutzpah,20200401-00:47,1c44179b7a2
app-portage/nattka,added,mgorny,20200401-13:08,f02867d2f8c
dev-erlang/p1_acme,added,hanno,20200401-10:28,e50bcb76481
sys-fs/sandboxfs,added,gyakovlev,20200401-09:03,f663bdc6560
net-misc/asterisk-opus,added,juippis,20200321-18:30,15674585042
net-vpn/tailscale,added,chutzpah,20200331-02:58,ed5ccfe9186
sys-cluster/kubernetes,added,williamh,20200330-21:31,5fa5afed555
dev-libs/libjcat,added,marecki,20200330-14:28,c9213e24cce
sci-mathematics/flintqs,added,mjo,20200327-19:38,1e6e5e555c6

Done.

Re: [gentoo-dev] ceph's static-libs

2020-04-05 Thread James Le Cuirot
On Sun, 5 Apr 2020 17:20:07 +
Peter Stuge  wrote:

> James Le Cuirot wrote:
> > 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.  
> 
> Note that there isn't really a way to express "partially static" to the
> toolchain when building a binary.
> 
> If you link a binary -static then that is always "fully static". No .so
> will satisfy any -l options.
> 
> The only way a "partially static" binary gets created is when linking
> *without* -static but some -l libraries only exist as static libraries,
> or if a library/object archive is specified with full .a filename,
> without using -l.
> 
> And "partially static" also only means that some dependencies were
> included into the binary, but unlike "fully static" the binary is
> not runnable without ld.so and a fitting libc.

Yeah, I am aware and was glossing over the details slightly but thanks
for clarifying.

You can force static when linking specific libraries with -Wl,-static
and then undo this with -Wl,-dynamic. I don't know whether it's
feasible to do this with flags passed to Portage though, haven't tried.
Another approach might be to use INSTALL_MASK to filter out the share
libraries you don't want but that may have issues too.

> > That probably explains why the ceph dependencies are as they are  
> 
> I think USE=static-libs is nice to have, and ideally (IMHO) it would
> be a global USE flag, respected by every package that installs a
> library. The flag says nothing about consumers, it only promises
> availability of the .a files, which I think is nice.

Agreed, I think this is a reasonable position to take.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpvl5NR5ynXt.pgp
Description: OpenPGP digital signature


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

2020-04-05 Thread Marek Szuba
On 2020-04-02 15:31, Marek Szuba wrote:

> 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 an alternative to ocl-icd;

Quick update on this: today I have attempted to rebuild and test various
OpenCL-dependent packages using the unified headers and
dev-libs/opencl-icd-loader. The good news is, they have all been
perfectly happy with them. The bad news is, I actually had to manually
symlink all contents
/usr/lib/OpenCL/vendors/opencl-icd-loader/include/CL/ into
/usr/include/CL/ for this to work because eselect-opencl contains a
hard-coded list of expected vendor header files.

In other words, it will be necessary to either teach eselect-opencl how
to handle the unified headers or make it possible for it to let the
contents of /usr/include/CL be. Personally I am leaning towards the
latter - it doesn't even handle legacy headers that well (it installs
several versions into /usr/lib/OpenCL/global but in the end offers no
way of switching between them), and in any case even its description
suggests its job is to switch between implementations rather than handle
global headers.

-- 
MS



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] virtual/opencl: new version

2020-04-05 Thread Marek Szuba
On 2020-04-05 06:44, Michał Górny wrote:

>> +EAPI=6
> Is there really a good reason to use an old EAPI here?

None other than me having assumed that there must have been an important
reason why such a simple ebuild had not been bumped to EAPI 7 yet. Will
change this in the next iteration.

>> +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?

It would if there only were only one ICD loader in the tree - but there
are two, this one and dev-libs/opencl-icd-loader. Overall it seems the
latter might be preferable in the long run (official Khronos Group
loader, much smaller output library, supports the new unified headers,
the last ocl-icd release came out in November 2017 and there has been
minimal repo activity since then) but with it having only been
officially released in mid-March and with me having only just added it
to Gentoo, I feel I'd rather test it for a while before listing it as an
alternative in the virtual.

Moreover, for the time being we still need eselect-opencl here even if
we are no longer to use to switch between implementations because
somewhat surprisingly (to me anyway), the package in questions installs
OpenCL header files too.

> This looks like README.gentoo material.

Will do.

-- 
MS



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] ceph's static-libs

2020-04-05 Thread Peter Stuge
James Le Cuirot wrote:
> 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.

Note that there isn't really a way to express "partially static" to the
toolchain when building a binary.

If you link a binary -static then that is always "fully static". No .so
will satisfy any -l options.

The only way a "partially static" binary gets created is when linking
*without* -static but some -l libraries only exist as static libraries,
or if a library/object archive is specified with full .a filename,
without using -l.

And "partially static" also only means that some dependencies were
included into the binary, but unlike "fully static" the binary is
not runnable without ld.so and a fitting libc.


> 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.

It's a bit more complicated..

Assume: ( note: without -static )

gcc -o binary source.c /usr/lib/libwebp.a

If libwebp requires libjpeg, and libwebp was not built to include
libjpeg.a then the above will not build. So we try:

gcc -o binary source.c /usr/lib/libwebp.a /usr/lib/libjpeg.a

If both .a exist this builds, but binary is still *not* linked statically,
at a minimum, ld.so and libc are still required to run it.

If we do:

gcc -o binary source.c /usr/lib/libwebp.a -ljpeg

Then the compiler will pick any libjpeg that is available, preferably
.so but if that can't be found then it will also look for .a. binary is
still *not* static.


Finally consider:

gcc -static -o binary source.c -lwebp -ljpeg
gcc -static -o binary source.c /usr/lib/libwebp.a /usr/lib/libjpeg.a

The above two are equivalent, but only thanks to -static. This fails
if either library .a is not found. When this succeeds, we have a static
binary, which runs anywhere regardless of ld.so and libc.


pkg-config .pc files for libraries are a very convenient solution to
the problem of sub-dependencies. In the above case, libwebp.pc would
perhaps have -lwebp in Libs and libjpeg in Requires.private (or maybe
-ljpeg in Libs.private).


> That probably explains why the ceph dependencies are as they are

I think USE=static-libs is nice to have, and ideally (IMHO) it would
be a global USE flag, respected by every package that installs a
library. The flag says nothing about consumers, it only promises
availability of the .a files, which I think is nice.

One technical reason for a consumer to DEPEND on libotherpackage[static-libs]
would be if an upstream Makefile has /usr/lib/libother.a instead of -lother,
arguably it would make more sense to apply a patch to the Makefile then.

Another technical reason would be that libotherpackage doesn't adhere to
common sense/best practice for library ABI/API compatibility, and make
the static library *different* from the shared object. If libotherpackage
maintainer heroines have made it possible to have one SLOT installed as
static library and another, incompatible, SLOT installed as shared object
and the consumer maintainer might know that only the static variant works.
This one is very hard to do anything about about in Gentoo, but it is also
a very construed case. The closest I've seen to this is giflib, which
changed API and ABI without bumping SONAME.


//Peter



Re: [gentoo-dev] zoom concerns

2020-04-05 Thread Samuel Bernardo
On 2020-04-04 15:57, Kent Fredric wrote:
> 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" )

Sorry about my comment, but couldn't that be solved choosing the right
profile or opting for an official overlay, raking the assurance level of
those?

Moving away the goodwill of those maintainers that get software into
Gentoo I think is not the good way...

Giving my opinion, maybe it should be useful to have QA classification
in future Gentoo Build System, where each overlay and profile could get
their ranking (from the automatic classifiers along with optional human
review)... Just a thought




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Last-rite: mask www-misc/zoneminder

2020-04-05 Thread The Bit Pit

On 4/5/20 5:54 AM, Joonas Niilola wrote:

# Not maintained in Gentoo, doesn't build for 2 years, has only
# deprecated version present in Gentoo. Has a huge number of open
# bugs. Removal in 30 days. #642952
www-misc/zoneminder
This appears to be an active project.  There is a plugin for 
*zoneminder* and *zmserver* in *mythtvplugin**s*.  When I finish the 
*mythtv* version 31.0 bump I will start maintaining this package.


Re: [gentoo-dev] [PATCH] enable build of gnat compiler in the toolchain eclass

2020-04-05 Thread Luke A. Guest
No it doesn't. Where's the bootstrap toolchain you need to build?

On 03/04/2020 07:48, Sergei Trofimovich wrote:
> 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!
> 



[gentoo-dev] Last-rite: mask www-misc/zoneminder

2020-04-05 Thread Joonas Niilola
# Not maintained in Gentoo, doesn't build for 2 years, has only
# deprecated version present in Gentoo. Has a huge number of open
# bugs. Removal in 30 days. #642952
www-misc/zoneminder


signature.asc
Description: OpenPGP digital signature