Re: [gentoo-dev] [PATCH] toolchain.eclass: fix crossdev powerpc-*-musl builds
> On 27 Dec 2021, at 05:24, Georgy Yakovlev wrote:
>
> otherwise initial build may fail with:
> unknown long double size, cannot define BFP_FMT
If possible, would you mind filing a bug with the build log
of it failing (and brief steps on how to get it) just so
we can easily test if we can drop it in future?
(We have a lot of hacks like this where I worry
we'll never be able to drop them with confidence)
If it takes a huge amount of work to get there, then don't
bother, as it's negligible gain.
>
> Signed-off-by: Georgy Yakovlev
> ---
> eclass/toolchain.eclass | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index fd03ba176276..1102c4fc5d56 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -1099,6 +1099,11 @@ toolchain_src_configure() {
> # Set up defaults based on current CFLAGS
> is-flagq -mfloat-gprs=double && confgcc+=( --enable-e500-double
> )
> [[ ${CTARGET//_/-} == *-e500v2-* ]] && confgcc+=(
> --enable-e500-double )
> + if [[ ${CTARGET} == powerpc-*-musl ]]; then
> + # fix: unknown long double size, cannot define BFP_FMT
> + confgcc+=( --disable-decimal-float )
> + export gcc_cv_target_ldbl128=no
> + fi
> ;;
> ppc64)
> # On ppc64 big endian target gcc assumes elfv1 by default,
> --
> 2.34.1
>
>
Looks fine otherwise though.
best,
sam
signature.asc
Description: Message signed with OpenPGP
[gentoo-dev] [PATCH] toolchain.eclass: fix crossdev powerpc-*-musl builds
otherwise initial build may fail with:
unknown long double size, cannot define BFP_FMT
Signed-off-by: Georgy Yakovlev
---
eclass/toolchain.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index fd03ba176276..1102c4fc5d56 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1099,6 +1099,11 @@ toolchain_src_configure() {
# Set up defaults based on current CFLAGS
is-flagq -mfloat-gprs=double && confgcc+=( --enable-e500-double
)
[[ ${CTARGET//_/-} == *-e500v2-* ]] && confgcc+=(
--enable-e500-double )
+ if [[ ${CTARGET} == powerpc-*-musl ]]; then
+ # fix: unknown long double size, cannot define BFP_FMT
+ confgcc+=( --disable-decimal-float )
+ export gcc_cv_target_ldbl128=no
+ fi
;;
ppc64)
# On ppc64 big endian target gcc assumes elfv1 by default,
--
2.34.1
[gentoo-dev] [PATCH] profiles/base/make.defaults: treat dtbs like modules
when dist-kernel gets uninstalled, /lib/modules/
is left behind on purpose. However, on some systems kernels also install
device-tree files to /boot/dtbs/
leaving /lib/modules, but removing device-tree file may leave system
unbootable, so let's treat dtbs directory similar to modules.
Signed-off-by: Georgy Yakovlev
---
profiles/base/make.defaults | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
index f25074f9d81a..be5651f0ac43 100644
--- a/profiles/base/make.defaults
+++ b/profiles/base/make.defaults
@@ -134,11 +134,11 @@ PYTHON_SINGLE_TARGET="python3_9"
# Michał Górny (2013-08-10)
# Moved from portage's make.globals.
-# 1) do not uninstall kernel modules and therefore allow replacing them,
+# 1) do not uninstall kernel modules/dtbs and therefore allow replacing them,
# 2,3) removed wrt bug #663170,
# 4) protect /var/{run,lock} symlinks for bug 519620
-COLLISION_IGNORE="/lib/modules/*"
-UNINSTALL_IGNORE="/lib/modules/* /var/run /var/lock"
+COLLISION_IGNORE="/boot/dtbs/* /lib/modules/*"
+UNINSTALL_IGNORE="/boot/dtbs/* /lib/modules/* /var/run /var/lock"
# Andreas K. Hüttel (2013-08-23)
# Make emerge messages default to English as per Council decision
--
2.34.1
Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp
Ühel kenal päeval, P, 26.12.2021 kell 10:50, kirjutas Michał Górny: > On Sun, 2021-12-26 at 09:44 +, Marek Szuba wrote: > > > > On 13 December 2021 17:24:18 UTC, Mart Raudsepp > > wrote: > > > > > Actually I kind of preferred a static name over straight mktemp, > > > because emktemp supported other cases than a pure mktemp usage > > > does. > > > But I don't know if it could ever clash things in some weird > > > situations. > > > > That last part is the message I tried to convey in my e-mail, sorry > > if I wasn't clear enough. > > > > Anyway, could anyone with more Postage/PMS experience weigh in on > > this? If it is indeed safe then the eclass could be modified > > further, e.g. to use static names with EAPI-8+ but stick with > > mktemp for older EAPIs just to be safe. > > I suppose it's not specified strictly but T should be safe for all > sane > uses. If it weren't, we'd already be in deep trouble and gnome2- > utils > would be the least of our concerns. > > That said, making this EAPI-conditional is just an unnecessary > complexity. It's already hardcoded to $T via using mktemp instead of emktemp (which supported lack of $T or mktemp utility, unlike the replacement that was merged) - so if $T and mktemp is guaranteed, we are good there. It was introduced with mktemp in the first place and then vapier changed it to emktemp without any reason given beyond probably just doing it for everything to support lack of mktemp on the system or some such. Now the question was, can we hardcode the name instead - is it possible for it to be running things in parallel and clash on the name, e.g.: * postinst and postrm ran at the same time on replacement: is it doing ._unmerge dir in portage an implementation detail that we shouldn't rely on it? * postinst and/or postrm ran with multilib support: could they be running in parallel in the future for the different ABIs -- should we include the ABI in the static filename at least to avoid clashes there? Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] USE-flag gnome-keyring isn't accurate anymore
"keyring" conveys the appropriate meaning, imho. On Sat, Dec 25, 2021, 5:19 AM Marek Szuba wrote: > > > On 24 December 2021 08:48:08 UTC, Pacho Ramos wrote: > > >> > I think “secret” may be too generic and “libsecret” is not ideal in > case > >> > an implemention comes along that is named differently. How about > >> > “secret-service”? > >> > >> I think this is a good idea. > >> > > > >And "keyring"? I am not sure if users not familiar with "libsecret" will > >understand what "secret*" means in this context > > Definitely a good idea. And I second "keyring", seeing as this term is > also in use on other OSes. > > -- > Marecki > >
Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp
On Sun, 2021-12-26 at 09:44 +, Marek Szuba wrote: > > On 13 December 2021 17:24:18 UTC, Mart Raudsepp wrote: > > > Actually I kind of preferred a static name over straight mktemp, > > because emktemp supported other cases than a pure mktemp usage does. > > But I don't know if it could ever clash things in some weird > > situations. > > That last part is the message I tried to convey in my e-mail, sorry if I > wasn't clear enough. > > Anyway, could anyone with more Postage/PMS experience weigh in on this? If it > is indeed safe then the eclass could be modified further, e.g. to use static > names with EAPI-8+ but stick with mktemp for older EAPIs just to be safe. I suppose it's not specified strictly but T should be safe for all sane uses. If it weren't, we'd already be in deep trouble and gnome2-utils would be the least of our concerns. That said, making this EAPI-conditional is just an unnecessary complexity. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp
On 13 December 2021 17:24:18 UTC, Mart Raudsepp wrote: >Actually I kind of preferred a static name over straight mktemp, >because emktemp supported other cases than a pure mktemp usage does. >But I don't know if it could ever clash things in some weird >situations. That last part is the message I tried to convey in my e-mail, sorry if I wasn't clear enough. Anyway, could anyone with more Postage/PMS experience weigh in on this? If it is indeed safe then the eclass could be modified further, e.g. to use static names with EAPI-8+ but stick with mktemp for older EAPIs just to be safe. -- Marecki
