[gentoo-dev] Last-rite: mask www-misc/zoneminder
# 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
Re: [gentoo-dev] [PATCH] enable build of gnat compiler in the toolchain eclass
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! >
Re: [gentoo-dev] Last-rite: mask www-misc/zoneminder
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] zoom concerns
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] ceph's static-libs
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] [PATCH] virtual/opencl: new version
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] RFC: Rethinking virtual/opencl and eselect-opencl
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] ceph's static-libs
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
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-04-05 23:59 UTC
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.
[gentoo-dev] package up for grabs: net-news/newsboat
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
Re: [gentoo-dev] RFC: Rethinking virtual/opencl and eselect-opencl
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] NATTkA (open source stable-bot replacement) deployment
Hello, everyone. It is my pleasure to announce that Infra is ready to deploy NATTkA and will do so as soon as we're able to synchronize with stable-bot owner. TL;DR: expect bot handling kwreq/streq to change, please report any bugs you notice, please start testing 'nattka apply' as a replacement for getatoms.py. What is NATTkA? === NATTkA is a rewrite of stable-bot, resulting from my frustration with unresolved issues, limitations and negligence to publish source code of stable-bot. Currently, it is a program with two commands: 'process-bugs' that replaces stable-bot itself, and 'apply' that replaces getatoms.py. It remains backwards compatible with stable-bot right now but I will start working on new features soonish, and then getatoms.py will probably be unable to work on bugs using them. stable-bot replacement == The main differences that will be visible after the deployment are: - NATTkA will run on shorter schedule (right now we're testing every 4-8 minutes), so new bugs should be handled much faster. - old bugs will be rechecked periodically (right now: every 12 hours), so if package lists run out of date, you will know before slacking arch teams notice. - if bug specifies all keywords in the package list, it will be checked before arch teams are CC-ed, so you won't have to spam them with bugs that aren't ready. - if you file rekeywording request and need to add dependencies, you no longer have to worry about specifying exact keywords for all of them. Unlike stable-bot, NATTkA does not try to downgrade stable keywords to ~arch as part of keywording. NATTkA should yield the same results as stable-bot (except in the cases outlined above). However, the failure messages change, so expect one- time re-reporting of all sanity-check- bugs. There also might be bugs, so if results don't make sense, please ping me. In the new feature I'm planning to relax package list syntax for keywordreqs and add new shorthands for specifying keywords in order to make our lives easier. These will not be backwards compatible. getatoms.py replacement === 'nattka apply' is quite fresh but it should be already equally functional to getatoms.py. I'd like to ask arch teams to start testing it ASAP, as using it (or well, updating the other tools) will be necessary to make use of new package list features. Short usage instructions follow. Docs provide a bit more details on all command-line options. 'nattka apply' applies keywords to the git repo checkout in the current directory and prints output telling you which packages had the keyword added. By default it works on the current ARCH (as determined from Portage config/profile). To apply keywords from specific bug: nattka apply 123456 To apply keywords from all bugs of specific category: nattka apply --keywordreq nattka apply --stablereq nattka apply --security To just print the list without modifying ebuilds: nattka apply -n ... Normally, NATTkA skips bugs that did not pass sanity-check or have unresolved deps. To change that: nattka apply --ignore-sanity-check ... nattka apply --ignore-dependencies ... To run for another arch: nattka apply -a arm64 ... To run for all arches CC-ed to the bugs: nattka apply -a '*' ... ALLARCHES is not currently respected but certainly will be in the future. If you need more features or notice any bugs, please ping me or file a bug at [1]. Enjoy! [1] https://github.com/mgorny/nattka/issues -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
