Re: [gentoo-dev] [RFC] New category: dev-doc (?)
> On Sun, 07 Jan 2024, Michał Górny wrote: > On Sun, 2024-01-07 at 17:58 +0100, Ulrich Mueller wrote: >> I cannot really see a delineation between app-text and [dev]-doc. >> >> For example, packages like psmark, xmlto, or even texi2html are general >> format manipulation/conversion tools and IMHO app-text is the right >> category for them. Also, why would you keep pandoc and manpager in >> app-text but move xmlto and mandoc out of it? > It's a bit blurry. My original idea was to keep app-text/ for general- > purpose text tools (like text editors), while make dev-doc/ focused on > formats specific to documentation (like code documentation, manpages). We already have app-editors for text editors. For the rest, it seems very blurry indeed and would leave us with (IMHO too many) borderline cases. You certainly have a point that document processing tools are misplaced in app-doc. Maybe just move them to app-text, which would be a more minimal change? Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] New category: dev-build
On Sun, 07 Jan 2024 17:20:25 +0100 Michał Górny wrote: > On Sun, 2024-01-07 at 09:50 -0500, Yuan Liao (Leo3418) wrote: > > On Sun, Jan 07, 2024 at 03:46:23PM +0100, Michał Górny wrote: > > > Hi, > > > > > > Another idea for a new category: dev-build. Proposed description: > > > > > > Build systems and related tools. > > > > Have you considered the name 'dev-buildsys'? More straightforward > > in my opinion, with the cost of a longer length. > > I have but I don't like the idea of half-shortcuts. Also, we are > really including some "building" tools like make that aren't really > "systems". > I suggest that ninja, samurai, bmake, pmake and make are all in the same category. Currently the first two are in dev-util while the rest are in sys-devel while they are all build tools that fill a similar need.
Re: [gentoo-dev] [RFC] global USE=gpg
we have many local gpg useflags which basically just enable gpg. Should we merge these to one global useflag? Additionally we have a few gpgme useflags. See also https://bugs.gentoo.org/679634 What are your ideas? We have also have a bunch of USE=pgp and USE=openpgp, both of which are more correct than USE=gpg. Yeah, typical case of "formally correct thing being way more difficult to understand than colloquially practical thing" ... You are right. I would prefer the formally correct "OpenPGP" after reading a bit more. This is how it is named in the RFCs [1] and this is what we mean. If we use either gpg or pgp it will raise new questions and confuse the users. It is better to write 4 additional characters and make it simple and precise. We can explain all details in the description then. [1] https://datatracker.ietf.org/doc/html/rfc4880 -- Best, Jonas OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] New category: dev-doc (?)
On Sun, 2024-01-07 at 17:58 +0100, Ulrich Mueller wrote: > > > > > > On Sun, 07 Jan 2024, Michał Górny wrote: > > > Here's another idea, a new dev-doc category (though I suppose we could > > try to find a better name), dedicated to: > > > Tools to generate, convert, view and process documentation. > > > This is notably meant to move software out of app-doc/ which is > > specifically dedicated to "documentation collections". Candidates: > > > app-doc/NaturalDocs > > app-doc/doxygen > > app-doc/halibut > > app-doc/psmark > > app-doc/xmltoman > > app-doc/zeal > > app-text/mandoc > > app-text/texi2html > > app-text/xchm > > app-text/xml2rfc > > app-text/xmlto > > I cannot really see a delineation between app-text and app-doc. > > For example, packages like psmark, xmlto, or even texi2html are general > format manipulation/conversion tools and IMHO app-text is the right > category for them. Also, why would you keep pandoc and manpager in > app-text but move xmlto and mandoc out of it? > It's a bit blurry. My original idea was to keep app-text/ for general- purpose text tools (like text editors), while make dev-doc/ focused on formats specific to documentation (like code documentation, manpages). -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] install-qa-check.d/60python-site: Check for deprecated .egg* files
Check for deprecated .egg and .egg-info files. While at it, fix stray
file check not to barf on *.egg files.
Signed-off-by: Michał Górny
---
metadata/install-qa-check.d/60python-site | 20
1 file changed, 20 insertions(+)
diff --git a/metadata/install-qa-check.d/60python-site
b/metadata/install-qa-check.d/60python-site
index afef445ad715..e4748b75fdfe 100644
--- a/metadata/install-qa-check.d/60python-site
+++ b/metadata/install-qa-check.d/60python-site
@@ -31,6 +31,7 @@ python_site_check() {
local stray=()
local bad_versions=()
+ local eggs=()
local outside_site=()
local stray_packages=()
@@ -79,11 +80,22 @@ python_site_check() {
')' -print0
)
+ # check for deprecated egg format
+ while IFS= read -d $'\0' -r f; do
+ eggs+=( "${f#${ED}}" )
+ done < <(
+ find "${sitedir}" -maxdepth 1 '(' \
+ -name '*.egg-info' -o \
+ -name '*.egg' \
+ ')' -print0
+ )
+
# check for stray files in site-packages
while IFS= read -d $'\0' -r f; do
stray_packages+=( "${f#${ED}}" )
done < <(
find "${sitedir}" -maxdepth 1 -type f '!' '(' \
+ -name '*.egg' -o \
-name '*.egg-info' -o \
-name '*.pth' -o \
-name '*.py' -o \
@@ -194,6 +206,14 @@ python_site_check() {
eqatag -v python-site.bad_version "${bad_versions[@]}"
fi
+ if [[ ${eggs[@]} ]]; then
+ eqawarn
+ eqawarn "QA Notice: The following deprecated .egg or .egg-info
files were found."
+ eqawarn "Please migrate the ebuild to use the PEP517 build."
+ eqawarn
+ eqatag -v python-site.egg "${eggs[@]}"
+ fi
+
if [[ ${stray_packages[@]} ]]; then
eqawarn
eqawarn "QA Notice: The following unexpected files/directories
were found"
--
2.43.0
Re: [gentoo-dev] [RFC] New category: dev-doc (?)
> On Sun, 07 Jan 2024, Ulrich Mueller wrote: > I cannot really see a delineation between app-text and app-doc. Sorry, this should read "between app-text and dev-doc", of course. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] New category: dev-doc (?)
> On Sun, 07 Jan 2024, Michał Górny wrote: > Here's another idea, a new dev-doc category (though I suppose we could > try to find a better name), dedicated to: > Tools to generate, convert, view and process documentation. > This is notably meant to move software out of app-doc/ which is > specifically dedicated to "documentation collections". Candidates: > app-doc/NaturalDocs > app-doc/doxygen > app-doc/halibut > app-doc/psmark > app-doc/xmltoman > app-doc/zeal > app-text/mandoc > app-text/texi2html > app-text/xchm > app-text/xml2rfc > app-text/xmlto I cannot really see a delineation between app-text and app-doc. For example, packages like psmark, xmlto, or even texi2html are general format manipulation/conversion tools and IMHO app-text is the right category for them. Also, why would you keep pandoc and manpager in app-text but move xmlto and mandoc out of it? > dev-util/gi-docgen > dev-util/gtk-doc > dev-util/source-highlight > sys-apps/man-db > sys-apps/texinfo signature.asc Description: PGP signature
[gentoo-dev] [PATCH] kernel-build.eclass: allow overriding UKI cmdline
From 0f33e78d05f5e50f4734f5493255232ce1c647fa Mon Sep 17 00:00:00 2001
From: Andrew Ammerlaan
Date: Wed, 3 Jan 2024 11:31:15 +0100
Subject: [PATCH] kernel-build.eclass: allow overriding UKI cmdline
Signed-off-by: Andrew Ammerlaan
---
eclass/kernel-build.eclass | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
index 28f111ec998bb..120056c5c26b2 100644
--- a/eclass/kernel-build.eclass
+++ b/eclass/kernel-build.eclass
@@ -1,4 +1,4 @@
-# Copyright 2020-2023 Gentoo Authors
+# Copyright 2020-2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: kernel-build.eclass
@@ -99,6 +99,14 @@ IUSE="+strip"
# key in PEM format to use. Must be specified if MODULES_SIGN_KEY
# is set to a path of a file that only contains the private key.
+# @ECLASS_VARIABLE: KERNEL_GENERIC_UKI_CMDLINE
+# @USER_VARIABLE
+# @DESCRIPTION:
+# If KERNEL_IUSE_GENERIC_UKI is set, this variable allows setting the
+# built-in kernel command line for the UKI. If unset, the default is
+# root=/dev/gpt-auto-root ro
+: "${KERNEL_GENERIC_UKI_CMDLINE:="root=/dev/gpt-auto-root ro"}"
+
if [[ ${KERNEL_IUSE_MODULES_SIGN} ]]; then
IUSE+=" modules-sign"
REQUIRED_USE="secureboot? ( modules-sign )"
@@ -435,7 +443,7 @@ kernel-build_src_install() {
local ukify_args=(
--linux="${image}"
--initrd="${image%/*}/initrd"
- --cmdline="root=/dev/gpt-auto-root ro"
+ --cmdline="${KERNEL_GENERIC_UKI_CMDLINE}"
--uname="${dir_ver}"
--output="${image%/*}/uki.efi"
)
[gentoo-dev] [PATCH] eclass/(dist-)kernel-*.eclass: drop installkernel-gentoo-7
Part of https://github.com/gentoo/gentoo/pull/33727
From 0878f48e492b2c7bfd4b58c8f6dcfbfdbd642d8a Mon Sep 17 00:00:00 2001
From: Andrew Ammerlaan
Date: Wed, 15 Nov 2023 19:59:06 +0100
Subject: [PATCH] eclass/(dist-)kernel-*.eclass: drop installkernel-gentoo-7
because we drop the generation of the initrd/uki here
we can remove KERNEL_IUSE_SECUREBOOT since this is now
exactly the same as KERNEL_IUSE_MODULES_SIGN
Signed-off-by: Andrew Ammerlaan
---
eclass/dist-kernel-utils.eclass | 78 -
eclass/kernel-build.eclass | 13 +++---
eclass/kernel-install.eclass| 39 +
3 files changed, 17 insertions(+), 113 deletions(-)
diff --git a/eclass/dist-kernel-utils.eclass
b/eclass/dist-kernel-utils.eclass
index 8ccffd0384742..13137f8c863c8 100644
--- a/eclass/dist-kernel-utils.eclass
+++ b/eclass/dist-kernel-utils.eclass
@@ -12,13 +12,6 @@
# This eclass provides various utility functions related to Distribution
# Kernels.
-# @ECLASS_VARIABLE: KERNEL_IUSE_SECUREBOOT
-# @PRE_INHERIT
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# If set to a non-null value, inherits secureboot.eclass
-# and allows signing of generated kernel images.
-
# @ECLASS_VARIABLE: KERNEL_EFI_ZBOOT
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -35,43 +28,6 @@ esac
inherit toolchain-funcs
-if [[ ${KERNEL_IUSE_SECUREBOOT} ]]; then
- inherit secureboot
-fi
-
-# @FUNCTION: dist-kernel_build_initramfs
-# @USAGE:
-# @DESCRIPTION:
-# Build an initramfs for the kernel. specifies the absolute
-# path where initramfs will be created, while specifies
-# the kernel version, used to find modules.
-#
-# Note: while this function uses dracut at the moment, other initramfs
-# variants may be supported in the future.
-dist-kernel_build_initramfs() {
- debug-print-function ${FUNCNAME} "${@}"
-
- [[ ${#} -eq 2 ]] || die "${FUNCNAME}: invalid arguments"
- local output=${1}
- local version=${2}
-
- local rel_image_path=$(dist-kernel_get_image_path)
- local image=${output%/*}/${rel_image_path##*/}
-
- local args=(
- --force
- # if uefi=yes is used, dracut needs to locate the kernel image
- --kernel-image "${image}"
-
- # positional arguments
- "${output}" "${version}"
- )
-
- ebegin "Building initramfs via dracut"
- dracut "${args[@]}"
- eend ${?} || die -n "Building initramfs failed"
-}
-
# @FUNCTION: dist-kernel_get_image_path
# @DESCRIPTION:
# Get relative kernel image path specific to the current ${ARCH}.
@@ -123,26 +79,6 @@ dist-kernel_install_kernel() {
local image=${2}
local map=${3}
- if has_version "<=sys-kernel/installkernel-gentoo-7"; then
- # if dracut is used in uefi=yes mode, initrd will actually
- # be a combined kernel+initramfs UEFI executable. we can easily
- # recognize it by PE magic (vs cpio for a regular initramfs)
- local initrd=${image%/*}/initrd
- local magic
- [[ -s ${initrd} ]] && read -n 2 magic < "${initrd}"
- if [[ ${magic} == MZ ]]; then
- einfo "Combined UEFI kernel+initramfs executable found"
- # install the combined executable in place of kernel
- image=${initrd%/*}/uki.efi
- mv "${initrd}" "${image}" || die
-
- if [[ ${KERNEL_IUSE_SECUREBOOT} ]]; then
- # Ensure the uki is signed if dracut hasn't
already done so.
- secureboot_sign_efi_file "${image}"
- fi
- fi
- fi
-
ebegin "Installing the kernel via installkernel"
# note: .config is taken relatively to System.map;
# initrd relatively to bzImage
@@ -159,10 +95,6 @@ dist-kernel_install_kernel() {
# The function will determine whether is actually
# a dist-kernel, and whether initramfs was used.
#
-# With sys-kernel/installkernel-systemd, or version 8 or greater of
-# sys-kernel/installkernel-gentoo, the generation of the initrd via dracut
-# is handled by kernel-install instead.
-#
# This function is to be used in pkg_postinst() of ebuilds installing
# kernel modules that are included in the initramfs.
dist-kernel_reinstall_initramfs() {
@@ -180,16 +112,6 @@ dist-kernel_reinstall_initramfs() {
return
fi
- if has_version "<=sys-kernel/installkernel-gentoo-7"; then
- local initramfs_path=${image_path%/*}/initrd
- if [[ ! -f ${initramfs_path} && ! -f ${initramfs_path%/*}/uki.efi ]];
then
- einfo "No initramfs or uki found at ${image_path}"
- return
- fi
-
- dist-kernel_build_initramfs "${initramfs_path}" "${ver}"
- fi
-
dist-kernel_install_kernel "${ver}" "${image_path}" \
[gentoo-dev] [RFC] New category: dev-doc (?)
Hi, Here's another idea, a new dev-doc category (though I suppose we could try to find a better name), dedicated to: Tools to generate, convert, view and process documentation. This is notably meant to move software out of app-doc/ which is specifically dedicated to "documentation collections". Candidates: app-doc/NaturalDocs app-doc/doxygen app-doc/halibut app-doc/psmark app-doc/xmltoman app-doc/zeal app-text/mandoc app-text/texi2html app-text/xchm app-text/xml2rfc app-text/xmlto dev-util/gi-docgen dev-util/gtk-doc dev-util/source-highlight sys-apps/man-db sys-apps/texinfo -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: sys-devel/ucpp
# Michał Górny (2024-01-07) # A Gentoo fork of an abandoned library that was historically used # by app-office/libreoffice. No revdeps left. # Removal on 2024-02-06. Bug #921576. sys-devel/ucpp -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] New category: dev-build
On Sun, 2024-01-07 at 09:50 -0500, Yuan Liao (Leo3418) wrote: > On Sun, Jan 07, 2024 at 03:46:23PM +0100, Michał Górny wrote: > > Hi, > > > > Another idea for a new category: dev-build. Proposed description: > > > > Build systems and related tools. > > Have you considered the name 'dev-buildsys'? More straightforward in my > opinion, with the cost of a longer length. I have but I don't like the idea of half-shortcuts. Also, we are really including some "building" tools like make that aren't really "systems". -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] New category: dev-build
[2024-01-07 15:46:23+0100] Michał Górny: Hi, Another idea for a new category: dev-build. Proposed description: Build systems and related tools. Some candidates (there are more): [snip] sys-devel/gettext (not 100% sure about it) I think that's the only one I wouldn't include as gettext seems to fit pretty well in sys-devel/ as it's main purpose is to manipulate .po/pot files and compile them in .mo files. (gettext(3) et al being provided either by glibc/musl or by dev-libs/libintl)
Re: [gentoo-dev] [RFC] New category: dev-build
Hi! Michał Górny writes: > Hi, > > Another idea for a new category: dev-build. Proposed description: > > Build systems and related tools. > > Some candidates (there are more): > > dev-util/bazel > dev-util/cmake > dev-util/cmake-fedora > dev-util/gn > dev-util/gtk-doc-am > dev-util/gyp > dev-util/meson > dev-util/muon > dev-util/netsurf-buildsystem > dev-util/ninja > dev-util/samurai > dev-util/tup > sys-devel/autoconf* > sys-devel/automake* > sys-devel/bmake > sys-devel/cons > sys-devel/gettext (not 100% sure about it) That's a bit of a toss-up, but I think I lean more towards the side of sys-libs or so (since, while it indeed provides build-time tools, it is not really a build system component, and it provides a few other libs). > sys-devel/libtool > sys-devel/make > sys-devel/pmake > sys-devel/qconf > sys-devel/slibtool I like the idea. Have a lovely day! -- Arsen Arsenović signature.asc Description: PGP signature
[gentoo-dev] [PATCH 2/2] cmake.eclass: Set CMAKE_DISABLE_PRECOMPILE_HEADERS=ON
This is already committed in kde overlay for testing (e.g. via eclass-
overrides).
Bug: https://bugs.gentoo.org/920845
Signed-off-by: Andreas Sturmlechner
---
eclass/cmake.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index c29dcfe413..f4a0d6506c 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -459,6 +459,7 @@ cmake_src_configure() {
set(BUILD_SHARED_LIBS ON CACHE BOOL "")
set(Python3_FIND_UNVERSIONED_NAMES FIRST CACHE STRING "")
set(FETCHCONTENT_FULLY_DISCONNECTED ON CACHE BOOL "")
+ set(CMAKE_DISABLE_PRECOMPILE_HEADERS ON CACHE BOOL "")
_EOF_
if [[ -n ${_ECM_ECLASS} ]]; then
--
2.43.0
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] [PATCH 1/2] cmake.eclass: Set FETCHCONTENT_FULLY_DISCONNECTED=ON
This is already committed in kde overlay for testing (e.g. via eclass-
overrides).
Bug: https://bugs.gentoo.org/920846
Signed-off-by: Andreas Sturmlechner
---
eclass/cmake.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 41aebeee53..c29dcfe413 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -458,6 +458,7 @@ cmake_src_configure() {
set(CMAKE_INSTALL_DOCDIR "${EPREFIX}/usr/share/doc/${PF}"
CACHE PATH "")
set(BUILD_SHARED_LIBS ON CACHE BOOL "")
set(Python3_FIND_UNVERSIONED_NAMES FIRST CACHE STRING "")
+ set(FETCHCONTENT_FULLY_DISCONNECTED ON CACHE BOOL "")
_EOF_
if [[ -n ${_ECM_ECLASS} ]]; then
--
2.43.0
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] New category: dev-build
On Sun, Jan 07, 2024 at 03:46:23PM +0100, Michał Górny wrote: > Hi, > > Another idea for a new category: dev-build. Proposed description: > > Build systems and related tools. Have you considered the name 'dev-buildsys'? More straightforward in my opinion, with the cost of a longer length. Best regards, Leo3418 signature.asc Description: PGP signature
[gentoo-dev] [RFC] New category: dev-build
Hi, Another idea for a new category: dev-build. Proposed description: Build systems and related tools. Some candidates (there are more): dev-util/bazel dev-util/cmake dev-util/cmake-fedora dev-util/gn dev-util/gtk-doc-am dev-util/gyp dev-util/meson dev-util/muon dev-util/netsurf-buildsystem dev-util/ninja dev-util/samurai dev-util/tup sys-devel/autoconf* sys-devel/automake* sys-devel/bmake sys-devel/cons sys-devel/gettext (not 100% sure about it) sys-devel/libtool sys-devel/make sys-devel/pmake sys-devel/qconf sys-devel/slibtool -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] New category: dev-debug
On Sun, 2024-01-07 at 13:20 +, Sam James wrote: > > > > This was originally prompted by bug 920438 [1], pointing out that LLDB > > and GDB belong to the same category. dev-util/ currently carries 428 > > packages, so I suppose it makes sense to split it some more, especially > > when we can clearly distinguish some more specific groups. > > > > Does anything dominate dev-util post-move or is it a real mix? Nothing immediately stands out but there might be too many packages to see a pattern. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] New category: dev-debug
Michał Górny writes: > [[PGP Signed Part:Undecided]] > Hi, > > I'd like to propose adding a new dev-debug category. The description > could be: > > Code debuggers and debugging-related tools. Sounds good. > > Potential candidates include: > > [...] dev-util/seer as well would be a good fit. > > This was originally prompted by bug 920438 [1], pointing out that LLDB > and GDB belong to the same category. dev-util/ currently carries 428 > packages, so I suppose it makes sense to split it some more, especially > when we can clearly distinguish some more specific groups. > Does anything dominate dev-util post-move or is it a real mix? > [1] https://bugs.gentoo.org/920438
[gentoo-dev] [RFC] New category: dev-debug
Hi, I'd like to propose adding a new dev-debug category. The description could be: Code debuggers and debugging-related tools. Potential candidates include: dev-util/ald: Assembly Language Debugger dev-util/apitrace: Tool for tracing, analyzing, and debugging graphics APIs dev-util/bpftrace: High-level tracing language for eBPF dev-util/cgdb: A curses front-end for GDB, the GNU debugger dev-util/d-feet: D-Feet is a powerful D-Bus debugger dev-util/d-spy: D-spy is a blisteringly fast D-Bus debugger dev-util/ddd: Graphical front-end for command-line debuggers dev-util/edb-debugger: edb is a cross platform x86/x86-64 debugger, inspired by Ollydbg dev-util/kdbg: Graphical debugger interface dev-util/leaktracer: Trace and analyze memory leaks in C++ programs dev-util/lldb: The LLVM debugger dev-util/ltrace: trace library calls made at runtime dev-util/pretrace: start dynamically linked applications under debugging environment dev-util/pwndbg: A GDB plug-in that makes debugging with GDB suck less dev-util/strace: Useful diagnostic, instructional, and debugging tool dev-util/sysdig: A system exploration and troubleshooting tool dev-util/systemtap: A linux trace/probe tool dev-util/valgrind: An open-source memory debugger for GNU/Linux media-gfx/renderdoc: A stand-alone graphics debugging tool sys-devel/gdb: GNU debugger sys-devel/gdb-apple: Apple branch of the GNU Debugger, Developer Tools 4.3 This was originally prompted by bug 920438 [1], pointing out that LLDB and GDB belong to the same category. dev-util/ currently carries 428 packages, so I suppose it makes sense to split it some more, especially when we can clearly distinguish some more specific groups. [1] https://bugs.gentoo.org/920438 -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
