[gentoo-dev] [PATCH 2/2] eclass/gstreamer.eclass: drop ltprune inherit
Dropping ltprune eclass and replacing it with
a simple find command, as suggested alternatively.
Signed-off-by: Conrad Kostecki
---
eclass/gstreamer.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/gstreamer.eclass b/eclass/gstreamer.eclass
index 301d0874106..d5adb8f6423 100644
--- a/eclass/gstreamer.eclass
+++ b/eclass/gstreamer.eclass
@@ -23,7 +23,7 @@
# plugin, consider adding media-plugins/gst-plugins-meta dependency, but
# also list any packages that provide explicitly requested plugins.
-inherit eutils ltprune multilib multilib-minimal toolchain-funcs versionator
xdg-utils
+inherit eutils multilib multilib-minimal toolchain-funcs versionator xdg-utils
case "${EAPI:-0}" in
5|6)
@@ -264,5 +264,5 @@ gstreamer_multilib_src_install_all() {
[[ -e ${dir}/README ]] && dodoc "${dir}"/README
done
- prune_libtool_files --modules
+ find "${ED}" -name '*.la' -delete || die
}
--
2.32.0
[gentoo-dev] [PATCH 1/2] eclass/eutils.eclass: drop ltprune inherit
No ebuilds remaining to call directly prune_libtool_files,
so we could drop the ltprune inherit in eutils.
Signed-off-by: Conrad Kostecki
---
eclass/eutils.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index 207d05e7f97..8a7cb6bde53 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -25,7 +25,7 @@ _EUTILS_ECLASS=1
# implicitly inherited (now split) eclasses
case ${EAPI} in
5|6)
- inherit desktop edos2unix epatch estack ltprune multilib \
+ inherit desktop edos2unix epatch estack multilib \
preserve-libs strip-linguas toolchain-funcs vcs-clean
wrapper
;;
7) inherit edos2unix strip-linguas wrapper ;;
--
2.32.0
Re: [gentoo-dev] Guarantees of unstable architectures
On Mon, 2021-07-26 at 17:23 +0100, Marek Szuba wrote: > Dear everyone, > > During the open-floor part of this month's Council meeting I asked > whether there is any official policy regarding what is or is not > guaranteed for hardware architectures we do not consider stable in > Gentoo. For reference, according to the current version of > profiles/arches.desc (commit 7bdebec50c44c0222bf76334c34926b593e94dd4, > dated 2021-04-05) this means: alpha, ia64, m68k, mips, riscv, s390, > and all Prefix arches. For a start, your list includes architectures that have profiles with various levels of stability. Rules for stable/dev profiles are different than rules for exp profiles, and therefore all architectures that do not have stable/dev profiles give lower stability guarantees. As for the remaining architectures, I don't think the rules for architecture that doesn't have stable keywords should be different than rules for ~arch packages on an architecture with stable keywords. > As it turns out, we do not in fact have any such policy. On the other > hand, during my time as a Gentoo developer I have heard from other > developers a fairly wide range of opinions on the subject - from > insisting on clean QA results, passing tests etc. regardless of whether > an arch is stable or not to assuming we guarantee nothing for unstable > arches. > > Anyway, it has been decided that it makes sense to discuss this on the > mailing list before making it a Council matter. Therefore - what do you > all think here? I think the rough rule of thumb should be: 1. For stable keywords, we try really hard not to break anything. When doing somewhat risky stuff, we drop keywords to ~arch. We generally try to test stuff properly before things go stable. 2. For ~arch keywords, we don't guarantee things won't break but we also don't break them deliberately. When doing very risky stuff, we use masks or drop keywords entirely. Breakage can still sneak in. 3. For pure exp architectures, we don't guarantee any stability. We can drop keywords or break depgraph. -- Best regards, Michał Górny
[gentoo-dev] [PATCH v3 5/5] check-reqs.eclass: Introduce CHECKREQS_DONOTHING
Replacement for I_KNOW_WHAT_I_AM_DOING with backwards compatibility.
Signed-off-by: Andreas Sturmlechner
---
eclass/check-reqs.eclass | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
index 39e4bad1363..2130e2e3491 100644
--- a/eclass/check-reqs.eclass
+++ b/eclass/check-reqs.eclass
@@ -68,6 +68,14 @@ _CHECK_REQS_ECLASS=1
# @DESCRIPTION:
# How much space is needed in /var? Eg.: CHECKREQS_DISK_VAR=3000M
+# @ECLASS-VARIABLE: CHECKREQS_DONOTHING
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Do not error out in _check-reqs_output if requirements are not met.
+# This is a user flag and should under _no circumstances_ be set in the ebuild.
+[[ -n ${I_KNOW_WHAT_I_AM_DOING} ]] && CHECKREQS_DONOTHING=1
+
# @FUNCTION: check-reqs_pkg_setup
# @DESCRIPTION:
# Exported function running the resources checks in pkg_setup phase.
@@ -276,7 +284,7 @@ _check-reqs_output() {
local msg="ewarn"
- [[ ${EBUILD_PHASE} == "pretend" && -z ${I_KNOW_WHAT_I_AM_DOING} ]] &&
msg="eerror"
+ [[ ${EBUILD_PHASE} == "pretend" && -z ${CHECKREQS_DONOTHING} ]] &&
msg="eerror"
if [[ -n ${CHECKREQS_FAILED} ]]; then
${msg}
${msg} "Space constraints set in the ebuild were not met!"
@@ -284,7 +292,7 @@ _check-reqs_output() {
${msg} "as per failed tests."
${msg}
- [[ ${EBUILD_PHASE} == "pretend" && -z ${I_KNOW_WHAT_I_AM_DOING}
]] && \
+ [[ ${EBUILD_PHASE} == "pretend" && -z ${CHECKREQS_DONOTHING} ]]
&& \
die "Build requirements not met!"
fi
}
@@ -446,7 +454,7 @@ _check-reqs_unsatisfied() {
local location=${2}
local sizeunit="$(_check-reqs_get_number ${size})
$(_check-reqs_get_unit ${size})"
- [[ ${EBUILD_PHASE} == "pretend" && -z ${I_KNOW_WHAT_I_AM_DOING} ]] &&
msg="eerror"
+ [[ ${EBUILD_PHASE} == "pretend" && -z ${CHECKREQS_DONOTHING} ]] &&
msg="eerror"
${msg} "There is NOT at least ${sizeunit} ${location}"
# @ECLASS-VARIABLE: CHECKREQS_FAILED
--
2.32.0
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Guarantees of unstable architectures
26.07.2021 17:23, Marek Szuba пишет: > Dear everyone, > > During the open-floor part of this month's Council meeting I asked > whether there is any official policy regarding what is or is not > guaranteed for hardware architectures we do not consider stable in > Gentoo. For reference, according to the current version of > profiles/arches.desc (commit 7bdebec50c44c0222bf76334c34926b593e94dd4, > dated 2021-04-05) this means: alpha, ia64, m68k, mips, riscv, s390, > and all Prefix arches. Only the non-RAP one (amd64-linux etc). The prefix installation on amd64 now supports using stable amd64 keyword: https://bugs.gentoo.org/759424 > > As it turns out, we do not in fact have any such policy. On the other > hand, during my time as a Gentoo developer I have heard from other > developers a fairly wide range of opinions on the subject - from > insisting on clean QA results, passing tests etc. regardless of whether > an arch is stable or not to assuming we guarantee nothing for unstable > arches. > > Anyway, it has been decided that it makes sense to discuss this on the > mailing list before making it a Council matter. Therefore - what do you > all think here? > -- Best regards, Alexey "DarthGandalf" Sokolov
[gentoo-dev] Guarantees of unstable architectures
Dear everyone, During the open-floor part of this month's Council meeting I asked whether there is any official policy regarding what is or is not guaranteed for hardware architectures we do not consider stable in Gentoo. For reference, according to the current version of profiles/arches.desc (commit 7bdebec50c44c0222bf76334c34926b593e94dd4, dated 2021-04-05) this means: alpha, ia64, m68k, mips, riscv, s390, and all Prefix arches. As it turns out, we do not in fact have any such policy. On the other hand, during my time as a Gentoo developer I have heard from other developers a fairly wide range of opinions on the subject - from insisting on clean QA results, passing tests etc. regardless of whether an arch is stable or not to assuming we guarantee nothing for unstable arches. Anyway, it has been decided that it makes sense to discuss this on the mailing list before making it a Council matter. Therefore - what do you all think here? -- Marecki
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 2021-07-25 08:27, Michał Górny wrote: On Sun, 2021-07-25 at 01:12 +0200, Thomas Deutschmann wrote: I don't understand. Isn't it the same motion we put down just 2 months ago [1]? Or is this something new? If this isn't something new, what has changed since May [2]? Apparently it has not been 'put down' because it came back via open bugs. Open bugs? Could you please link them here? To remember: Currently we have two different hashes for every distfile. If we are going to throw this data away, we should really have good reasons to do that. Like said during that council meeting, BLAKE2B and SHA512 are competing hashes. What's wrong with having a backup plan even for a very unlikely scenario, that BLAKE2B will get broken? Define 'broken'. To quote from chapter 9 of the Handbook of Applied Cryptography, by Menezes, van Oorschot and Vanstone: If, for a given hash function, an attack is found, which, by exploiting special details of how the hash function operates, finds a preimage, a second preimage or a collision faster than the corresponding generic attack, then the hash function is said to be "broken". This happened publicly for SHA1 in 2017. Remember that verify-sig.eclass I criticized last year? Of course some scenarios I outlined were very unlikely and I never expected that I can run around in near future saying "I told you". But in January 2021, CVE-2021-3345 happened in libgcrypt... I don't see how this is relevant either. Are you admitting that you're criticizing all my ideas because I just happen to propose them? No, I am not criticizing ideas because *you* proposed them. I share my criticism when I have some concerns or believe the proposal has some flaws. You maybe have that impression because you are very active and most proposals are coming from you. In the end, we both are hopefully sharing the same goal to make Gentoo better... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
On 7/25/2021 19:19, Sam James wrote:
>
>
>> On 22 Jul 2021, at 16:00, Alice wrote:
>>
>>
>> Signed-off-by: Alice Ferrazzi
>> ---
>> eclass/kernel-2.eclass | 13 +
>> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> Alice, thanks for taking the initiative to get this done and drop Python 2.7
> here.
>
> It's much appreciated!
>
>>
>> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
>> index f94dd9c..05f8161 100644
>> --- a/eclass/kernel-2.eclass
>> +++ b/eclass/kernel-2.eclass
>> @@ -605,7 +605,7 @@ if [[ ${ETYPE} == sources ]]; then
>>kernel_is le 2 6 ${DEBLOB_MAX_VERSION} && \
>>K_DEBLOB_AVAILABLE=1
>>if [[ ${K_DEBLOB_AVAILABLE} == 1 ]]; then
>> - PYTHON_COMPAT=( python2_7 )
>> + PYTHON_COMPAT=( python3_{7..10} )
>
> I think others already said this, but Python 3.7 is a noop (eclasses ignore
> it), so just drop it.
>
>>
>>inherit python-any-r1
>>
>> @@ -1489,9 +1489,14 @@ kernel-2_src_compile() {
>>[[ ${ETYPE} == headers ]] && compile_headers
>>
>>if [[ ${K_DEBLOB_AVAILABLE} == 1 ]] && use deblob; then
>> - einfo ">>> Running deblob script ..."
>> - python_setup
>> - sh "${T}/${DEBLOB_A}" --force || die "Deblob script failed
>> to run!!!"
>> + # deblob less than 5.10 require python 2.7
>> + if kernel_is lt 5 10; then
>> + ewarn "we don't support deblob for kernel less then
>> 5.10"
>> + else
>> + einfo ">>> Running deblob script ..."
>> + python_setup
>> + sh "${T}/${DEBLOB_A}" --force || die "Deblob script
>> failed to run!!!"
>> + fi
>>fi
>> }
>>
>
> I'd still prefer it if we just didn't provide the USE flag on irrelevant
> kernels (it's too confusing) but if you plan on removing this
> message at some point, I guess we can keep it?
I think the message text for the ewarn case could be a bit better. How
about instead of:
"we don't support deblob for kernel less then 5.10"
Something like:
"Deblob support requires a Linux kernel >=5.10"
Is used instead?
Also, the die message text can drop the triple exclamation marks. One
exclamation mark is enough.
And someone correct me if wrong, as I am reading this thread late, but
deblobbing is disabled by setting K_DEBLOB_AVAILABLE=0 in a kernel-2
inheritor ebuild, right? mips-sources can't support deblobbing, as several
of the SGI machines (IP27, IP30) are literally unbootable off of internal
drive bays if specific Qlogic firmware blobs don't get included in the
kernel image.
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
