Re: [gentoo-dev] [PATCH 1/2] ninja-utils.eclass: Add NINJA_VERBOSE
On Mon, Jul 17, 2023 at 11:21 AM Matt Turner wrote: > > ninja operates in one of three modes: > - verbose (with -v): prints build commands > - quiet (with --quiet): prints nothing > - normal: prints [XX/YY]-style build status updates > > samurai works the same way, except it does not have a quiet mode. > > Thus we can't simply override ninja-utils' hard-coded flag from callers > of eninja. Seems ok to me.
[gentoo-dev] [PATCH v2] meson.eclass: allow disabling verbose compilation
From: Jonas Rakebrandt
This works similar to cmake.eclass's ${CMAKE_VERBOSE}.
Closes: https://github.com/gentoo/gentoo/pull/28942
Signed-off-by: Jonas Rakebrandt
Signed-off-by: Matt Turner
---
eclass/meson.eclass | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 2c274b213191..3b30f66bf30a 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -55,6 +55,12 @@ BDEPEND=">=dev-util/meson-0.62.2
# Build directory, location where all generated files should be placed.
# If this isn't set, it defaults to ${WORKDIR}/${P}-build.
+# @ECLASS_VARIABLE: MESON_VERBOSE
+# @USER_VARIABLE
+# @DESCRIPTION:
+# Set to OFF to disable verbose messages during compilation
+: "${MESON_VERBOSE:=ON}"
+
# @ECLASS_VARIABLE: EMESON_BUILDTYPE
# @DESCRIPTION:
# The buildtype value to pass to meson setup.
@@ -385,10 +391,15 @@ meson_src_compile() {
-C "${BUILD_DIR}"
--jobs "$(makeopts_jobs "${MAKEOPTS}" 0)"
--load-average "$(makeopts_loadavg "${MAKEOPTS}" 0)"
- --verbose
- "$@"
)
+ case ${MESON_VERBOSE} in
+ OFF) ;;
+ *) mesoncompileargs+=( --verbose ) ;;
+ esac
+
+ mesoncompileargs+=( "$@" )
+
set -- meson compile "${mesoncompileargs[@]}"
echo "$@" >&2
"$@" || die "compile failed"
--
2.41.0
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
Sam James writes: > [[PGP Signed Part:Undecided]] > > Florian Schmaus writes: > >> [[PGP Signed Part:Undecided]] >> On 18/07/2023 11.56, Sam James wrote: >>> Mike Gilbert writes: >>> On Mon, Jul 17, 2023 at 4:27 PM Sam James wrote: >> Haven't we been keeping these because we still need to decide on a >> policy about what to do with dead acct-*/* packages? > > Right. https://bugs.gentoo.org/781881 is still open. Flow could ping > the QA team and ask if it should be closed, given the opinion there > seems to be that there's no need to keep them, but I think it's wrong > to do this pre-empting a policy decision, given it essentially forces > the "don't keep them" path. The bug has been open for several months without comment. If a policy were going to materialize, I think it would have happened by now. Forcing the issue by sending this last rites notice seems acceptable to me. >>> Pinging someone rather than "forcing the issue" as a first-step is >>> customary. >> >> I am sorry, but it seems that I have to clarify something. >> >> First, I have "pinged someone." > > Ping on IRC (in #gentoo-qa, or could PM me), or again on the bug? > > Someone asked the QA team to make a decision. We haven't yet, as I'd > forgot about it. It seems wrong to then just pretend that didn't happen. > > At least try to get it resolved on that end by pinging again / asking us? Just to be super duper clear: it's fine with me if we just move on and don't keep the packages, but I think a quick /msg #gentoo-qa "hey guys, nothing seems to be happening with the bug, do you mind if we just close it?" wouldn't have gone amiss. That is _all_ I'm asking for here. And then when we get onto talk of "incentives" and "illegitimate shadow policies", I become very confused indeed. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
Florian Schmaus writes: > [[PGP Signed Part:Undecided]] > On 18/07/2023 11.56, Sam James wrote: >> Mike Gilbert writes: >> >>> On Mon, Jul 17, 2023 at 4:27 PM Sam James wrote: > Haven't we been keeping these because we still need to decide on a > policy about what to do with dead acct-*/* packages? Right. https://bugs.gentoo.org/781881 is still open. Flow could ping the QA team and ask if it should be closed, given the opinion there seems to be that there's no need to keep them, but I think it's wrong to do this pre-empting a policy decision, given it essentially forces the "don't keep them" path. >>> >>> The bug has been open for several months without comment. If a policy >>> were going to materialize, I think it would have happened by now. >>> >>> Forcing the issue by sending this last rites notice seems acceptable to me. >> Pinging someone rather than "forcing the issue" as a first-step is >> customary. > > I am sorry, but it seems that I have to clarify something. > > First, I have "pinged someone." Ping on IRC (in #gentoo-qa, or could PM me), or again on the bug? Someone asked the QA team to make a decision. We haven't yet, as I'd forgot about it. It seems wrong to then just pretend that didn't happen. At least try to get it resolved on that end by pinging again / asking us? > > As of writing this, I was the last to comment on the QA bug about five > months ago, asking why we would want to keep unused acct-* packages > [1]. Since then, this has not been answered, and there have been zero > other replies. That signaled me that there was no interest in pursuing > the matter further. In addition, we have already removed acct-* > packages in the past. > I'm sorry that somebody missed a ping in a FOSS project. But this is probably not the first time it's happened to you. > Secondly, nobody immediately forces anything. > I'm saying that speaking to someone works better than committing something and then asking for discussion. > Sam, I am afraid, but I believe that the situation is different from > how you frame it. > > > The proponents of keeping obsolete acct-* packages have the inventive > to establish their preferred policy. It's a bit aggressive to take action, without pinging before doing so (you did several months ago, that's not really the same thing), to "incentivise" someone. > > Accusing me of not facilitating a QA bug that deals with establishing > a policy I do not favor seems unfair. > I'm not sure I'm doing that. I'm saying that doing this preempts a decision and that a ping would've been polite. > Do you think that a QA bug that has not seen progress in nearly five > months should be able to establish an illegitimate shadow policy? > Come on. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
On 18/07/2023 11.56, Sam James wrote: Mike Gilbert writes: On Mon, Jul 17, 2023 at 4:27 PM Sam James wrote: Haven't we been keeping these because we still need to decide on a policy about what to do with dead acct-*/* packages? Right. https://bugs.gentoo.org/781881 is still open. Flow could ping the QA team and ask if it should be closed, given the opinion there seems to be that there's no need to keep them, but I think it's wrong to do this pre-empting a policy decision, given it essentially forces the "don't keep them" path. The bug has been open for several months without comment. If a policy were going to materialize, I think it would have happened by now. Forcing the issue by sending this last rites notice seems acceptable to me. Pinging someone rather than "forcing the issue" as a first-step is customary. I am sorry, but it seems that I have to clarify something. First, I have "pinged someone." As of writing this, I was the last to comment on the QA bug about five months ago, asking why we would want to keep unused acct-* packages [1]. Since then, this has not been answered, and there have been zero other replies. That signaled me that there was no interest in pursuing the matter further. In addition, we have already removed acct-* packages in the past. Secondly, nobody immediately forces anything. The removal date for the acct-* packages is one month from now. One month is hopefully enough time to decide whether we want such a policy. Sam, I am afraid, but I believe that the situation is different from how you frame it. The proponents of keeping obsolete acct-* packages have the inventive to establish their preferred policy. Accusing me of not facilitating a QA bug that deals with establishing a policy I do not favor seems unfair. Do you think that a QA bug that has not seen progress in nearly five months should be able to establish an illegitimate shadow policy? Currently, acct-* packages are governed by our current policy regarding package removal. If we decide to change this, we can also revert the acct-* package removals. - Flow 1: https://bugs.gentoo.org/781881#c7 OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
Mike Gilbert writes: > On Mon, Jul 17, 2023 at 4:27 PM Sam James wrote: >> > Haven't we been keeping these because we still need to decide on a >> > policy about what to do with dead acct-*/* packages? >> >> Right. https://bugs.gentoo.org/781881 is still open. Flow could ping >> the QA team and ask if it should be closed, given the opinion there >> seems to be that there's no need to keep them, but I think it's wrong >> to do this pre-empting a policy decision, given it essentially forces >> the "don't keep them" path. > > The bug has been open for several months without comment. If a policy > were going to materialize, I think it would have happened by now. > > Forcing the issue by sending this last rites notice seems acceptable to me. Pinging someone rather than "forcing the issue" as a first-step is customary. signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-ruby/hamster
# Hans de Graaff (2023-07-18) # Obsolete rubu30-only package, previously a dependency of nanoc. No # longer maintained upstream. Masked for removal on 2023-08-18. dev-ruby/hamster signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
On 18-07-2023 11:42:39 +0300, Зураб Квачадзе wrote: > How do we handle this case, then. > Imagine we have a leaf package acct-user/foo, which has a reserved UID of 123. > It gets last rited and its entry is removed from uid-gid.txt. After a while > appears a new package acct-user/bar, which takes the 123 UID. Then a user, say > Bob, updates their system, which haven't been updated for some time. What if > they still have acct-user/foo, when acct-user/bar with the same UID is > installed? Should we even care about such cases? IMO we should, thus 123 should not be removed from uid-gid.txt, and instead be marked as reserved or something with a date. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
Well, this configuration is reasonable, I am for the change On Tue, 18 Jul 2023 at 11:55 Florian Schmaus wrote: > On 18/07/2023 10.42, Зураб Квачадзе wrote: > > How do we handle this case, then. > > Imagine we have a leaf package acct-user/foo, which has a reserved UID > > of 123. It gets last rited and its entry is removed from uid-gid.txt. > > Nobody is proposing that the uid-gid.txt entry is removed. Ideally, it > would be marked as 'historical', together with the date it went historical. > > > > After a while appears a new package acct-user/bar, which takes the 123 > > UID. Then a user, say Bob, updates their system, which haven't been > > updated for some time. What if they still have acct-user/foo, when > > acct-user/bar with the same UID is installed? > > If a UID/GID is in use, then acct-*.eclass will find the next suitable > ID (unless, e.g. ACCT_USER_ENFORCE_ID is set, we is usually not the case). > > - Flow >
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
On 18/07/2023 10.42, Зураб Квачадзе wrote: How do we handle this case, then. Imagine we have a leaf package acct-user/foo, which has a reserved UID of 123. It gets last rited and its entry is removed from uid-gid.txt. Nobody is proposing that the uid-gid.txt entry is removed. Ideally, it would be marked as 'historical', together with the date it went historical. After a while appears a new package acct-user/bar, which takes the 123 UID. Then a user, say Bob, updates their system, which haven't been updated for some time. What if they still have acct-user/foo, when > acct-user/bar with the same UID is installed? If a UID/GID is in use, then acct-*.eclass will find the next suitable ID (unless, e.g. ACCT_USER_ENFORCE_ID is set, we is usually not the case). - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
How do we handle this case, then. Imagine we have a leaf package acct-user/foo, which has a reserved UID of 123. It gets last rited and its entry is removed from uid-gid.txt. After a while appears a new package acct-user/bar, which takes the 123 UID. Then a user, say Bob, updates their system, which haven't been updated for some time. What if they still have acct-user/foo, when acct-user/bar with the same UID is installed? Should we even care about such cases? On Tue, 18 Jul 2023 at 11:22 Pacho Ramos wrote: > El jue, 01-01-1970 a las 00:00 +, Ulrich Mueller escribió: > > > > > > > On Mon, 17 Jul 2023, Mike Gilbert wrote: > > > > > On Mon, Jul 17, 2023 at 4:27 PM Sam James wrote: > > > > > Haven't we been keeping these because we still need to decide > > > > > on a > > > > > policy about what to do with dead acct-*/* packages? > > > > > > > > Right. https://bugs.gentoo.org/781881 is still open. Flow could > > > > ping > > > > the QA team and ask if it should be closed, given the opinion > > > > there > > > > seems to be that there's no need to keep them, but I think it's > > > > wrong > > > > to do this pre-empting a policy decision, given it essentially > > > > forces > > > > the "don't keep them" path. > > > > > The bug has been open for several months without comment. If a > > > policy > > > were going to materialize, I think it would have happened by now. > > > > > Forcing the issue by sending this last rites notice seems > > > acceptable > > > to me. > > > > I'd say we remove the packages, because system user and group ids are > > a somewhat scarce resource. > > I agree because of the same reasons > >
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
El jue, 01-01-1970 a las 00:00 +, Ulrich Mueller escribió: > > > > > > On Mon, 17 Jul 2023, Mike Gilbert wrote: > > > On Mon, Jul 17, 2023 at 4:27 PM Sam James wrote: > > > > Haven't we been keeping these because we still need to decide > > > > on a > > > > policy about what to do with dead acct-*/* packages? > > > > > > Right. https://bugs.gentoo.org/781881 is still open. Flow could > > > ping > > > the QA team and ask if it should be closed, given the opinion > > > there > > > seems to be that there's no need to keep them, but I think it's > > > wrong > > > to do this pre-empting a policy decision, given it essentially > > > forces > > > the "don't keep them" path. > > > The bug has been open for several months without comment. If a > > policy > > were going to materialize, I think it would have happened by now. > > > Forcing the issue by sending this last rites notice seems > > acceptable > > to me. > > I'd say we remove the packages, because system user and group ids are > a somewhat scarce resource. I agree because of the same reasons signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/5 v2]: secureboot.eclass: add new eclass
v2 is mostly just some style fixes and simplifications. The only major
difference is that secureboot_auto_sign now also finds .efi32, .efi64 in
addition to .efi files. Furthermore, the find is now case insensitive.
Best regards,
Andrew
From 5fa9c00477917b07cbecd1619506d6db8e978cfd Mon Sep 17 00:00:00 2001
From: Andrew Ammerlaan
Date: Tue, 11 Jul 2023 19:47:52 +0200
Subject: [PATCH] eclass/secureboot.eclass: add new eclass
Signed-off-by: Andrew Ammerlaan
---
eclass/secureboot.eclass | 173 +++
1 file changed, 173 insertions(+)
create mode 100644 eclass/secureboot.eclass
diff --git a/eclass/secureboot.eclass b/eclass/secureboot.eclass
new file mode 100644
index 0..477722a83bb3b
--- /dev/null
+++ b/eclass/secureboot.eclass
@@ -0,0 +1,173 @@
+# Copyright 1999-2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: secureboot.eclass
+# @MAINTAINER:
+# Andrew Ammerlaan
+# @AUTHOR:
+# Author: Andrew Ammerlaan
+# @SUPPORTED_EAPIS: 7 8
+# @BLURB: A small eclass to sign efi files for Secure Boot
+# @DESCRIPTION:
+# Eclass for packages that install .efi files. A use flag and two user
+# variables allow signing these .efi files for use on systems with
Secure Boot
+# enabled.
+#
+# Signing the files during emerge ensures that any tooling that actually
+# installs the bootloaders and kernels to ESP always uses a signed version.
+# This prevents Secure Boot from accidentally breaking when upgrading the
+# kernel or the bootloader.
+#
+# Example use
+# @CODE
+# src_install() {
+# default
+# secureboot_sign_efi_file in.efi out.efi.signed
+# }
+# @CODE
+#
+# Or
+# @CODE
+# src_install() {
+# default
+# secureboot_auto_sign
+# }
+# @CODE
+#
+# Some tools will automatically detect and use EFI executables with the
.signed
+# suffix. For tools that do not do this the --in-place argument for
+# secureboot_auto_sign can be used to ensure that the signed version is
used.
+
+case ${EAPI} in
+ 7|8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+IUSE="secureboot"
+BDEPEND="secureboot? ( app-crypt/sbsigntools )"
+
+# @ECLASS_VARIABLE: SECUREBOOT_SIGN_KEY
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Used with USE=secureboot. Should be set to the path of the private
+# key in PEM format to use, or a PKCS#11 URI.
+#
+# @ECLASS_VARIABLE: SECUREBOOT_SIGN_CERT
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Used with USE=secureboot. Should be set to the path of the public
+# key certificate in PEM format to use.
+
+if [[ -z ${_SECUREBOOT_ECLASS} ]]; then
+_SECUREBOOT_ECLASS=1
+
+# @FUNCTION: _secureboot_die_if_unset
+# @INTERNAL
+# @DESCRIPTION:
+# If USE=secureboot is enabled die if the required user variables are unset
+# and die if the keys can't be found.
+_secureboot_die_if_unset() {
+ debug-print-function ${FUNCNAME[0]} "${@}"
+ use secureboot || return
+
+ if [[ -z ${SECUREBOOT_SIGN_KEY} || -z ${SECUREBOOT_SIGN_CERT} ]]; then
+ die "USE=secureboot enabled but SECUREBOOT_SIGN_KEY and/or
SECUREBOOT_SIGN_CERT not set."
+ fi
+ if [[ ! ${SECUREBOOT_SIGN_KEY} == pkcs11:* && ! -f
${SECUREBOOT_SIGN_KEY} ]]; then
+ die "SECUREBOOT_SIGN_KEY=${SECUREBOOT_SIGN_KEY} not found"
+ fi
+ if [[ ! -f ${SECUREBOOT_SIGN_CERT} ]];then
+ die "SECUREBOOT_SIGN_CERT=${SECUREBOOT_SIGN_CERT} not found"
+ fi
+}
+
+# @FUNCTION: secureboot_pkg_setup
+# @DESCRIPTION:
+# Checks if required user variables are set before starting the build
+secureboot_pkg_setup() {
+ debug-print-function ${FUNCNAME[0]} "${@}"
+ use secureboot || return
+
+ # If we are merging a binary then the files in this binary
+ # are already signed, no need to check the variables.
+ if [[ ${MERGE_TYPE} != binary ]]; then
+ _secureboot_die_if_unset
+ fi
+}
+
+# @FUNCTION: secureboot_sign_efi_file
+# @USAGE:
+# @DESCRIPTION:
+# Sign a file using sbsign and the requested key/certificate.
+# If the file is already signed with our key then skip.
+secureboot_sign_efi_file() {
+ debug-print-function ${FUNCNAME[0]} "${@}"
+ use secureboot || return
+
+ local input_file=${1}
+ local output_file=${2}
+
+ _secureboot_die_if_unset
+
+ ebegin "Signing ${input_file}"
+ local return=1
+ if sbverify "${input_file}" --cert "${SECUREBOOT_SIGN_CERT}" &>
/dev/null; then
+ ewarn "${input_file} already signed, skipping"
+ return=0
+ else
+ local args=(
+ "--key=${SECUREBOOT_SIGN_KEY}"
+ "--cert=${SECUREBOOT_SIGN_CERT}"
+ )
+ if [[ ${SECUREBOOT_SIGN_KEY} == pkcs11:* ]]; then
+ args+=( --engine=pkcs11 )
+ fi
+
+ sbsign "${args[@]}" "${input_file}" --output "${output_file}"
+ return=${?}
+
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
> On Mon, 17 Jul 2023, Mike Gilbert wrote: > On Mon, Jul 17, 2023 at 4:27 PM Sam James wrote: >> > Haven't we been keeping these because we still need to decide on a >> > policy about what to do with dead acct-*/* packages? >> >> Right. https://bugs.gentoo.org/781881 is still open. Flow could ping >> the QA team and ask if it should be closed, given the opinion there >> seems to be that there's no need to keep them, but I think it's wrong >> to do this pre-empting a policy decision, given it essentially forces >> the "don't keep them" path. > The bug has been open for several months without comment. If a policy > were going to materialize, I think it would have happened by now. > Forcing the issue by sending this last rites notice seems acceptable > to me. I'd say we remove the packages, because system user and group ids are a somewhat scarce resource. The ids in uid-gid.txt (in data/api.git) need to be updated as well, i.e. they should be kept for now but changed to historical. Ulrich signature.asc Description: PGP signature
