Re: [gentoo-dev] Changing policy about -Werror
On Sat, Sep 22, 2018 at 1:33 AM Chí-Thanh Christopher Nguyễn wrote: > > Richard Yao schrieb: > > >> To make code behave differently it needs substantial amount of code > >> to provide you an example. You need to him O2<->O3 behaviour delta > >> after all. But I will try (for a different warning, it should not matter > >> much). > > Thanks. I had been incorrect about -O3 giving not us some additional > > information for warnings. My apologies for the confusion. > >> > >> Below is a reduced example of a larger C++ program. > >> Many thanks to Ulya for providing recent example! > > Not that it matters now, but there are examples of packages building at -O2 > but failing to build at -O3 optimization levels, due to -Werror. > > One is dev-libs/libcss: https://bugs.gentoo.org/626752 > It is matter, and shows that for selected packages in which upstream has strict policy of no warning, each warning should be investigated as it may be a true issue. The tool compiler provide to find these edge condition should not be ignored nor overridden. The fact that a package "builds" does not mean it is free of bugs. Regards, Alon
Re: [gentoo-dev] [PATCH] eclass/linux-mod.eclass: add module signing support
On Friday, September 21, 2018 3:59:26 PM PDT Chí-Thanh Christopher Nguyễn
wrote:
> Alexander Tsoy schrieb:
> >> + sign_binary_path="${KV_OUT_DIR}/scripts/sign-file"
> >
> > Yet another way to screw up modules building. It relies on some binary
> > in the kernel build dir that may break after openssl update (e.g.
> > soname change).
>
> Maybe the sign-file application could be packaged, for example as part of
> sys-apps/linux-misc-apps.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
linux-mod.eclass already relies on full kernel build dir to be available to
build modules.
and depending on another ebuild means that it has to be keyworded on different
arches to actually support signing on those arches.
simple kbuild approach is better IMO, if a system can build a kernel and
modules means it can sign it.
Maintaining separate package, especially with kernel update pace will be a
nightmare.
--
Regads,
Georgy Yakovlev
Gentoo Linux Developer
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] eclass/linux-mod.eclass: add module signing support
On Friday, September 21, 2018 5:58:00 AM PDT Alexander Tsoy wrote:
> В Чт, 20/09/2018 в 22:13 -0700, Georgy Yakovlev пишет:
> > ->%---
> > @@ -144,13 +158,16 @@ esac
> >
> > 0) die "EAPI=${EAPI} is not supported with
> >
> > MODULES_OPTIONAL_USE_IUSE_DEFAULT due to lack of IUSE defaults" ;;
> >
> > esac
> >
> > -IUSE="kernel_linux
> > ${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODUL
> > ES_OPTIONAL_USE}"
> > +IUSE="module-sign kernel_linux
> > ${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODUL
> > ES_OPTIONAL_USE}"
> >
> > SLOT="0"
> > RDEPEND="${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (}
> >
> > kernel_linux? ( virtual/modutils ) ${MODULES_OPTIONAL_USE:+)}"
> >
> > DEPEND="${RDEPEND}
> >
> > ${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (}
> >
> > sys-apps/sed
> >
> > - kernel_linux? ( virtual/linux-sources virtual/libelf )
> > + kernel_linux? (
> > + virtual/linux-sources virtual/libelf
> > + module-sign? ( || ( dev-libs/openssl dev-
> > libs/libressl ) )
> > + )
>
> It should depend on the proper openssl slot: dev-libs/openssl:0
Thanks for suggestion.
Not sure, all it does is it makes sure -lcrypto works while building module.
libcrypto is not required to load the module.
Adding slot build dep to a package with a module does not make a lot of sense
to me, but probably does not hurt either.
>
> > ${MODULES_OPTIONAL_USE:+)}"
> >
> > # eclass utilities
> >
> > @@ -352,6 +369,84 @@ get-KERNEL_CC() {
> >
> > echo "${kernel_cc}"
> >
> > }
> >
> > +# @FUNCTION: _check_sig_force
> > +# @INTERNAL
> > +# @DESCRIPTION:
> > +# Check if kernel requires module signing and die
> > +# if modules are not going to be signed.
> > +_check_sig_force() {
> > + debug-print-function ${FUNCNAME} "${@}"
> > +
> > + if linux_chkconfig_present MODULE_SIG_FORCE; then
> > + if use !module-sign; then
> > + eerror "kernel .config has
> > MODULE_SIG_FORCE=y option set"
> > + eerror "This means that kernel requires all
> > modules"
> > + eerror "to be signed and verified before
> > loading"
> > + eerror "please enable USE=\"module-sign\" or
> > reconfigure your kernel"
> > + eerror "otherwise loading the module will
> > fail"
> > + die "signature required"
> > + fi
> > + fi
> > +}
> > +
> > +# @FUNCTION: _sign_module
> > +# @INTERNAL
> > +# @USAGE:
> > +# @DESCRIPTION:
> > +# Sign a kernel module
> > +_sign_module() {
> > + debug-print-function ${FUNCNAME} "${@}"
> > +
> > + local dotconfig_sig_hash dotconfig_sig_key
> > + local sign_binary_path sig_key_path sig_x509_path
> > + local module
> > +
> > + # extract values from kernel .config
> > + # extracted key path is not full, e.g.
> > "certs/signing_key.pem"
> > + dotconfig_sig_hash="$(linux_chkconfig_string
> > MODULE_SIG_HASH)"
> > + dotconfig_sig_key="$(linux_chkconfig_string MODULE_SIG_KEY)"
> > +
> > + # sign-file binary chokes on double quotes
> > + dotconfig_sig_hash=${dotconfig_sig_hash//\"/}
> > + dotconfig_sig_key=${dotconfig_sig_key//\"/}
> > +
> > + sign_binary_path="${KV_OUT_DIR}/scripts/sign-file"
>
> Yet another way to screw up modules building. It relies on some binary
> in the kernel build dir that may break after openssl update (e.g.
> soname change).
openssl soname rarely changes and a user likely to build kernel first (thus
re-building sign-file binary) and update modules later (probably with @module-
rebuild).
Last ABI change was in 2016 (still masked in gentoo), and in 2010 before that.
It's unlikely to encounter an abi changing openssl upgrade and a random module
rebuild while updating unless a user updates very infrequently.
simple workaround:
cd /usr/src/linux && rm scripts/sign-file && make scripts
I can probably add this to die message and/or create a news item/wiki article.
The whole eclass relies on kernel build dir to be available with exact same
configuration to build modules, not just the signing part.
As an example, using kernel gcc plugins situation is much worse, but still not
a big deal, just rebuild a kernel after upgrading gcc to be able to build out-
of tree modules.
sign-file binary is rather simple and is not that picky and rarely breaks. At
least what's what I observe while testing this patch.
I build kernels weekly (and rebuilding modules) and have not seen a single
problem related to signing.
I'll post rebased/updated patch with latest changes happened to eclass to
support EAPI7.
--
Regads,
Georgy Yakovlev
Gentoo Linux Developer
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] eclass/linux-mod.eclass: add module signing support
Alexander Tsoy schrieb:
+ sign_binary_path="${KV_OUT_DIR}/scripts/sign-file"
Yet another way to screw up modules building. It relies on some binary
in the kernel build dir that may break after openssl update (e.g.
soname change).
Maybe the sign-file application could be packaged, for example as part of
sys-apps/linux-misc-apps.
Best regards,
Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
Mike Auty schrieb: Installation will proceed, but the user will get a big fat warning that the sys-fs/zfs package is potentially broken. This seems like a sure-fire way to make users paranoid and/or desensitized? People will learn to ignore warnings if we make them big red and flashing but then say they're only potential breakages (and they subsequently discover that most everything runs fine). If they learn to ignore big red flashing warnings it'll be more difficult when they're not potential breakages but actual ones we've accurately identified... Maybe "big fat warning" was a bit of an overstatement. I meant the same kind of notice that @preserved-rebuild set produces today. Or the "configuration files need updating" message. Much like the aforementioned, the affected package might continue to work totally fine, or be broken in subtle ways. It might bother the user enough to report a bug, but hopefully not enough to turn them away from Gentoo. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
Richard Yao schrieb: To make code behave differently it needs substantial amount of code to provide you an example. You need to him O2<->O3 behaviour delta after all. But I will try (for a different warning, it should not matter much). Thanks. I had been incorrect about -O3 giving not us some additional information for warnings. My apologies for the confusion. Below is a reduced example of a larger C++ program. Many thanks to Ulya for providing recent example! Not that it matters now, but there are examples of packages building at -O2 but failing to build at -O3 optimization levels, due to -Werror. One is dev-libs/libcss: https://bugs.gentoo.org/626752 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [PATCH 1/3] check-reqs.eclass: update to EAPI7
All three of these patches are now in the tree :)
-- Jason
On Tue, Sep 18, 2018 at 02:38:15PM +0800, Jason Zaman wrote:
> Signed-off-by: Jason Zaman
> ---
> eclass/check-reqs.eclass | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
> index d1ed395c8b1..689944c8770 100644
> --- a/eclass/check-reqs.eclass
> +++ b/eclass/check-reqs.eclass
> @@ -7,7 +7,7 @@
> # @AUTHOR:
> # Bo Ørsted Andresen
> # Original Author: Ciaran McCreesh
> -# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6
> +# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
> # @BLURB: Provides a uniform way of handling ebuild which have very high
> build requirements
> # @DESCRIPTION:
> # This eclass provides a uniform way of handling ebuilds which have very high
> @@ -63,7 +63,7 @@ if [[ ! ${_CHECK_REQS_ECLASS_} ]]; then
> EXPORT_FUNCTIONS pkg_setup
> case "${EAPI:-0}" in
> 0|1|2|3) ;;
> - 4|5|6) EXPORT_FUNCTIONS pkg_pretend ;;
> + 4|5|6|7) EXPORT_FUNCTIONS pkg_pretend ;;
> *) die "EAPI=${EAPI} is not supported" ;;
> esac
>
> --
> 2.16.4
>
>
Re: [gentoo-dev] [PATCH] eclass/waf-utils.eclass: add parameters to compile and install
On Fri, 2018-09-21 at 18:51 +0300, Victor Kustov wrote:
> [1] https://github.com/gentoo/gentoo/pull/9533#discussion_r211739558
>
> This patch add parameters to compile and install phases in waf-utils
> eclass. Need to solve [1]
>
> ---
> eclass/waf-utils.eclass | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/eclass/waf-utils.eclass b/eclass/waf-utils.eclass
> index 4d02483a927..33515b883b5 100644
> --- a/eclass/waf-utils.eclass
> +++ b/eclass/waf-utils.eclass
> @@ -102,8 +102,8 @@ waf-utils_src_compile() {
> [[ ${WAF_VERBOSE} == ON ]] && _mywafconfig="--verbose"
>
> local jobs="--jobs=$(makeopts_jobs)"
> - echo "\"${WAF_BINARY}\" build ${_mywafconfig} ${jobs}"
> - "${WAF_BINARY}" ${_mywafconfig} ${jobs} || die "build failed"
> + echo "\"${WAF_BINARY}\" $@ build ${_mywafconfig} ${jobs}"
> + "${WAF_BINARY}" $@ ${_mywafconfig} ${jobs} || die "build failed"
"${@}" i.e. quote it or this is going to spew into a mess.
> }
>
> # @FUNCTION: waf-utils_src_install
> @@ -112,8 +112,8 @@ waf-utils_src_compile() {
> waf-utils_src_install() {
> debug-print-function ${FUNCNAME} "$@"
>
> - echo "\"${WAF_BINARY}\" --destdir=\"${D}\" install"
> - "${WAF_BINARY}" --destdir="${D}" install || die "Make install failed"
> + echo "\"${WAF_BINARY}\" --destdir=\"${D}\" \"$@\" install"
> + "${WAF_BINARY}" --destdir="${D}" "$@" install || die "Make install
> failed"
Likewise.
>
> # Manual document installation
> einstalldocs
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH] eclass/waf-utils.eclass: add parameters to compile and install
[1] https://github.com/gentoo/gentoo/pull/9533#discussion_r211739558
This patch add parameters to compile and install phases in waf-utils
eclass. Need to solve [1]
---
eclass/waf-utils.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/waf-utils.eclass b/eclass/waf-utils.eclass
index 4d02483a927..33515b883b5 100644
--- a/eclass/waf-utils.eclass
+++ b/eclass/waf-utils.eclass
@@ -102,8 +102,8 @@ waf-utils_src_compile() {
[[ ${WAF_VERBOSE} == ON ]] && _mywafconfig="--verbose"
local jobs="--jobs=$(makeopts_jobs)"
- echo "\"${WAF_BINARY}\" build ${_mywafconfig} ${jobs}"
- "${WAF_BINARY}" ${_mywafconfig} ${jobs} || die "build failed"
+ echo "\"${WAF_BINARY}\" $@ build ${_mywafconfig} ${jobs}"
+ "${WAF_BINARY}" $@ ${_mywafconfig} ${jobs} || die "build failed"
}
# @FUNCTION: waf-utils_src_install
@@ -112,8 +112,8 @@ waf-utils_src_compile() {
waf-utils_src_install() {
debug-print-function ${FUNCNAME} "$@"
- echo "\"${WAF_BINARY}\" --destdir=\"${D}\" install"
- "${WAF_BINARY}" --destdir="${D}" install || die "Make install failed"
+ echo "\"${WAF_BINARY}\" --destdir=\"${D}\" \"$@\" install"
+ "${WAF_BINARY}" --destdir="${D}" "$@" install || die "Make install
failed"
# Manual document installation
einstalldocs
--
2.16.4
Re: [gentoo-dev] [PATCH] eclass/linux-mod.eclass: add module signing support
В Чт, 20/09/2018 в 22:13 -0700, Georgy Yakovlev пишет:
> ->%---
> @@ -144,13 +158,16 @@ esac
> 0) die "EAPI=${EAPI} is not supported with
> MODULES_OPTIONAL_USE_IUSE_DEFAULT due to lack of IUSE defaults" ;;
> esac
>
> -IUSE="kernel_linux
> ${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODUL
> ES_OPTIONAL_USE}"
> +IUSE="module-sign kernel_linux
> ${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODUL
> ES_OPTIONAL_USE}"
> SLOT="0"
> RDEPEND="${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (}
> kernel_linux? ( virtual/modutils ) ${MODULES_OPTIONAL_USE:+)}"
> DEPEND="${RDEPEND}
> ${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (}
> sys-apps/sed
> - kernel_linux? ( virtual/linux-sources virtual/libelf )
> + kernel_linux? (
> + virtual/linux-sources virtual/libelf
> + module-sign? ( || ( dev-libs/openssl dev-
> libs/libressl ) )
> + )
It should depend on the proper openssl slot: dev-libs/openssl:0
> ${MODULES_OPTIONAL_USE:+)}"
>
> # eclass utilities
> @@ -352,6 +369,84 @@ get-KERNEL_CC() {
> echo "${kernel_cc}"
> }
>
> +# @FUNCTION: _check_sig_force
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Check if kernel requires module signing and die
> +# if modules are not going to be signed.
> +_check_sig_force() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + if linux_chkconfig_present MODULE_SIG_FORCE; then
> + if use !module-sign; then
> + eerror "kernel .config has
> MODULE_SIG_FORCE=y option set"
> + eerror "This means that kernel requires all
> modules"
> + eerror "to be signed and verified before
> loading"
> + eerror "please enable USE=\"module-sign\" or
> reconfigure your kernel"
> + eerror "otherwise loading the module will
> fail"
> + die "signature required"
> + fi
> + fi
> +}
> +
> +# @FUNCTION: _sign_module
> +# @INTERNAL
> +# @USAGE:
> +# @DESCRIPTION:
> +# Sign a kernel module
> +_sign_module() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + local dotconfig_sig_hash dotconfig_sig_key
> + local sign_binary_path sig_key_path sig_x509_path
> + local module
> +
> + # extract values from kernel .config
> + # extracted key path is not full, e.g.
> "certs/signing_key.pem"
> + dotconfig_sig_hash="$(linux_chkconfig_string
> MODULE_SIG_HASH)"
> + dotconfig_sig_key="$(linux_chkconfig_string MODULE_SIG_KEY)"
> +
> + # sign-file binary chokes on double quotes
> + dotconfig_sig_hash=${dotconfig_sig_hash//\"/}
> + dotconfig_sig_key=${dotconfig_sig_key//\"/}
> +
> + sign_binary_path="${KV_OUT_DIR}/scripts/sign-file"
Yet another way to screw up modules building. It relies on some binary
in the kernel build dir that may break after openssl update (e.g.
soname change).
Re: [gentoo-dev] [RFC] C++ standard in ebuilds
On Tuesday, 18 September 2018 16:31:23 CEST Guilherme Amadio wrote:
> On Mon, Sep 17, 2018 at 10:24:48AM -0700, Matt Turner wrote:
> > I don't understand what a potential solution would be.
> >
> > The various projects use -std=c++XXX because that's what their code
> > requires. -std=c++XXX can't generally be changed. If a dependent
> > project is incompatible that's no different than any other case of
> > incompatible dependencies in Gentoo.
> >
> > I think -std=c++XXX discussions before happened because gcc changed
> > the C++ ABI with -std=c++11. I don't think that's particularly
> > relevant here, since as far as I know different -std=c++XXX values
> > don't change the ABI with current gcc.
> >
> > So I guess my understanding is that there isn't a problem different
> > than existing incompatible dependencies, but maybe I have
> > misunderstood you.
>
> My concern is with, say, package foo that depends on both bar and baz,
> and bar and baz support from C++11 to C++17, but must be compiled with
> the same version of the standard so that foo can link against both of
> them without having a broken ABI. I think that depending on bar[c++14],
> or having a similar mechanism to Python to handle "same version of the
> standard" with ${CXXSTD_REQUIRED_USE} or similar in an eclass would be
> nice.
Maybe add a CXXABI USE_EXPAND variable and then handle this case similar to
python-single-r1.eclass packages with CXXABI_COMPAT and CXXABI_USEDEP?
signature.asc
Description: This is a digitally signed message part.
