Re: [gentoo-dev] New category for AI related packages
> > This appears to leave us with sci-ai/* because: > > First, 'AI' seems to be the term that is commonly used (just look at > this mail's subject) and understood. > > Secondly, while others may find sci-ai to buzzwordy, that could also > been seen as an advantage. This. Buzzwordy is kinda fine since categories are a human-oriented interface. I.e., what is the first you think about where you would expect a package... ++ for sci-ai (Now, is it really sci-ai, or should we also come up with dev-ai (for libraries without explicit scientific context) and sys-ai (for accelerator device drivers) in addition? :) > > And finally, maybe there will be non-deep-learning packages which we > then could put under sci-ai/*. > > - Flow > -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: sys-cluster/teleport
# Arthur Zamarin (2025-03-15) # EAPI=7, uses deprecated Go eclasses. Isn't maintained in Gentoo # since 2019, with awaiting version bump (upstream is still active). # Has open security vulnerabilities. # Removal on 2025-04-14. Bugs #951417, #631076, #679948, #695310, #771051, #844727, #880151, #908590, #948207, #813702, #866356. sys-cluster/teleport OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public
On 14/03/2025 17:23, Ionen Wolkens wrote: On Fri, Mar 14, 2025 at 01:48:50PM +0100, Nowa Ammerlaan wrote: eclass/linux-mod-r1.eclass | 7 +++ ftr my opinion on this hasn't changed since the beginning, I was hoping that the idea would be scrapped early rather than more work being put into it. I noted your initial concerns and sam's hesitation, and would have stopped pursuing this further had I not also received positive feedback convincing me that there is indeed some demand for adding DKMS support as an option. I had hoped that the final version of the new eclass, being significantly cleaner and more robust, would have changed your mind. This just feels like a messy half-solution that we're better off without. So NACK from me, both for linux-mod-r1 and adding support to my packages like nvidia-drivers. Not that I'll revert if it gets merged anyway. Is there anything I can say or do to convince you otherwise? I honestly believe that I have addressed all concerns that have been raised so far. Adding support for the DKMS pathway to only a subset of kernel modules is bound to be lead to a confusing end result, so that is not really a state in which I want to merge this in. Best regards, Nowa
Re: [gentoo-dev] New category for AI related packages
Arsen Arsenović writes: > Filip Kobierski writes: > >> On Monday, March 10th, 2025 at 21:40, Alfredo Tupone >> wrote: >>> To declutter sci-libs and dev-libs from most of the "so called" >>> AI packages I think that a new category should be created. >>> Maybe sci-ai/ or dev-ai/ or sci-dl/ (deep-learning) >> >> I really like thi idea. >> For better or worse the field is growing and it would be nice >> to have a separate category for it. >> >> In my opinion the category should begin with "sci": >> - "sci-ai" feels the most general but buzzwordy; >> - "sci-dl" is too specific as not AI is deep learning; >> - "sci-ml" (machie learning) in my opinion would be the >> best choice as it describes the packages listed clearly. > > As was mentioned, sci-ml would be confusing with Meta-Language. > > The term "AI" has a very long and storied history, and covers the entire > field of machine learning and then some. I think 'sci-ai' is most > fitting as a result (and, besides also being more fitting, it also is > not ambiguous). I agree. I can live with sci-ml if the consensus goes the other way, though.
Re: [gentoo-dev] New category for AI related packages
On Wed, Mar 12, 2025 at 08:47:42AM +0100, Florian Schmaus wrote: > On 10/03/2025 21.40, Alfredo Tupone wrote: > > To declutter sci-libs and dev-libs from most of the "so called" > > AI packages I think that a new category should be created. > > Maybe sci-ai/ or dev-ai/ or sci-dl/ (deep-learning) > > Thanks for your proposal. > > I would go with sci-ai/*, even if all packages under that category would > be about deep/machine learning. And while sci-ml would maybe more > suitable, -ml seems to be established to indicate OCaml / ML, and we > should avoid naming inconsistencies. For the same reason I would rule > out sci-machine-learning. > > This appears to leave us with sci-ai/* because: > > First, 'AI' seems to be the term that is commonly used (just look at > this mail's subject) and understood. > > Secondly, while others may find sci-ai to buzzwordy, that could also > been seen as an advantage. > > And finally, maybe there will be non-deep-learning packages which we > then could put under sci-ai/*. From all answers in this thread, this one resonates with me. I prefer sci-ai/* as well. Petr signature.asc Description: PGP signature
[gentoo-dev] [PATCH 1/5] use.desc: document new dkms flag
Signed-off-by: Nowa Ammerlaan --- profiles/use.desc | 1 + 1 file changed, 1 insertion(+) diff --git a/profiles/use.desc b/profiles/use.desc index 36468b321ddb..6e8329009947 100644 --- a/profiles/use.desc +++ b/profiles/use.desc @@ -66,6 +66,7 @@ dedicated - Add support for dedicated game servers (some packages do not provide dga - Add DGA (Direct Graphic Access) support for X dist-kernel - Enable subslot rebuilds on Distribution Kernel upgrades djvu - Support DjVu, a PDF-like document format esp. suited for scanned documents +dkms - Manage external kernel modules with sys-kernel/dkms doc - Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally dri - Enable direct rendering: used for accelerated 3D and some 2D, like DMA dts - Enable DTS Coherent Acoustics decoder support -- 2.48.1
