Re: [gentoo-dev] [PATCH v2] kernel-2.eclass: Respect portage CC & AR variables
On Friday, 17 December 2021 8:29:18 AM NZDT Adrian Ratiu wrote:
> Hi Andrew,
>
> On Thu, 16 Dec 2021, Andrew Savchenko wrote:
> > On Thu, 16 Dec 2021 03:32:10 +0300 Andrew Savchenko wrote:
> >> On Wed, 15 Dec 2021 16:58:26 +0200 Adrian Ratiu wrote:
> >> > Starting with kernel>=v5.7 the build system can override the
> >> > tools vars by setting LLVM=1 [1], but older kernels still use
> >> > the default GNU tools, so to be able to use a full LLVM/Clang
> >> > build, CC should be set together with AR to the portage set
> >> > values. Doing this avoids situations like building the
> >> > kernel with clang (using the set HOSTCC) but using gcc/gnu-ar
> >> > for headers. [1] a0d1c951ef08 kbuild: support LLVM=1 to
> >> > switch the default tools to Clang/LLVM Co-authored-by: Manoj
> >> > Gupta Signed-off-by: Adrian Ratiu
> >> > ---
> >> >
> >> > eclass/kernel-2.eclass | 2 +- 1 file changed, 1
> >> > insertion(+), 1 deletion(-)
> >> > diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> >> >
> >> > index adc1425bc2e..caeec86ff59 100644 ---
> >> > a/eclass/kernel-2.eclass +++ b/eclass/kernel-2.eclass @@
> >> > -692,7 +692,7 @@ env_setup_xmakeopts() {
> >> >
> >> > elif type -p ${CHOST}-ar >/dev/null; then
> >> >
> >> > xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-" fi
> >> >
> >> > -xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)" +
> >> > xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)
> >> > CC=$(tc-getCC) AR=$(tc-getAR)"
> >>
> >> OBJDUMP should be exported as well (e.g. used by
> >>
> >> scripts/Makefile.build)
> >
> > And LD as well.
>
> Thank you very much for the suggestions!
>
> I only set CC and AR because there were the two which failed in my
> testing, but yes, it is a good idea to be prudent and set them all
> if nobody is oopposed to it.
>
I assume by set them all you're referring to what the kernel makefile uses? I
think CC, LD, AR, NM, OBJCOPY, OBJDUMP, READELF, and STRIP is the exhaustive
list for the kernel. (would match the new clang profile feature too)
Thanks
> I will leave this patch on the ML a bit in case there is more
> feedback (it is also EoY season so people might be busy), then I
> will send a v3 with the new variables included.
>
> Thanks again,
> Adrian
>
> >> > export xmakeopts
> >> >
> >> > }
> >>
> >> Best regards,
> >> Andrew Savchenko
> >
> > Best regards,
> > Andrew Savchenko
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH v2] kernel-2.eclass: Respect portage CC & AR variables
On Thursday, 16 December 2021 3:58:26 AM NZDT Adrian Ratiu wrote:
> Starting with kernel>=v5.7 the build system can override the
> tools vars by setting LLVM=1 [1], but older kernels still use
> the default GNU tools, so to be able to use a full LLVM/Clang
> build, CC should be set together with AR to the portage set
> values.
>
> Doing this avoids situations like building the kernel with
> clang (using the set HOSTCC) but using gcc/gnu-ar for headers.
>
> [1] a0d1c951ef08 kbuild: support LLVM=1 to switch the default tools to
> Clang/LLVM
>
> Co-authored-by: Manoj Gupta
> Signed-off-by: Adrian Ratiu
> ---
> eclass/kernel-2.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index adc1425bc2e..caeec86ff59 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -692,7 +692,7 @@ env_setup_xmakeopts() {
> elif type -p ${CHOST}-ar >/dev/null; then
> xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
> fi
> - xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
> + xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC)
> AR=$(tc-getAR)" export xmakeopts
> }
What's the reason for not using $LLVM here? To preserve building with clang
for kernels < 5.7 ?
I might be missing the point, but wouldn't something along the lines of
"LLVM=$(! [[ $(tc-getCC) =~ clang ]]; echo $?)" work to preserve the correct
compiler tools?
Cheers
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] portage.output: Replace darkblue colors with teal
On Saturday, 4 December 2021 10:47:53 PM NZDT Fabian Groffen wrote: > On 04-12-2021 10:24:23 +0100, Michał Górny wrote: > > On Sat, 2021-12-04 at 10:15 +0100, Fabian Groffen wrote: > > > On 04-12-2021 10:13:09 +0100, Michał Górny wrote: > > > > On Sat, 2021-12-04 at 09:56 +0100, Fabian Groffen wrote: > > > > > Why don't you change your color.map instead of changing the default > > > > > for > > > > > everyone? > > > > > > > > Why should we keep a stupid default? Should we optimize Gentoo for > > > > people who don't want to be able to read Portage's output? > > > > > > You're assuming everyone uses the terminal in the way you do. I simply > > > don't think that's how the world looks like. > > > > On the other hand, you're assuming that everyone uses the terminal > > in the way you do. > > It eludes me how you came to that conclusion. > > > > No need for calling things stupid, IMO. > > > > Using dark blue on black background is stupid. > > ... then don't use black background or dark blue text? > > Now, if you would make a supported claim that all terminals we install > use a black background by default, your change becomes more valid. > Well IMO, teal is still easy to read against a black & white background, where darkblue is almost impossible on black. This just seems like a sensible default > However, we then still don't know if people leave that default or use > something else, but we could make some educated guess about the amount > of people not changing the default. > > My point, because I think this wasn't clear to you, is and always was, > how many people is this change going to be disruptive to. And should > we make a hint to users when they install this version of Portage that > they can revert/change this by altering color.map (and how)? > > Thanks, > Fabian signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Un-slotting LLVM
On Tuesday, 9 November 2021 2:41:53 PM NZDT Sam James wrote: > > On 8 Nov 2021, at 11:18, Michał Górny wrote: > > Hi, > > A few years back I've slotted LLVM and Clang to make the life with > > revdeps easier. Long story short, every major LLVM release (which > > happens twice a year) breaks API and it takes some time for revdeps to > > adjust. Slotting made it possible to install multiple versions > > simultaneously, and therefore let "faster" packages use newer LLVM > > without being blocked by "slower" packages on the user's system. > > > > Unfortunately, this ended up pretty bothersome to maintain. Besides > > making ebuilds quite complex (and prone to mistakes), I'm hearing more > > and more reports of programs being broken through getting multiple LLVM > > versions in the link chain. > > I think this might just be Blender and friends which are especially fragile. > > We may be able to get away with just coordinating those together. > > > WDYT? > > If we can help it, I'd really really prefer we don't. Being able to test > various different various of Clang quickly (just like gcc) is really > helpful. > I agree. Personally, it's allowed me to narrow down a few bugs in programs/ test suites which only occur with specific LLVM/Clang versions. While I could just build the different versions locally, slotting in combination with package.env really has made testing easier. > (especially given one day, we might dare to dream of using Clang > for the system toolchain. It becomes a lot easier to check for > regressions if you can just flip the version.) > I'd love to see this one day :-) > Best, > sam signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 0/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test
On Wednesday, 20 October 2021 10:34:47 PM NZDT Alexey Sokolov wrote: > 20.10.2021 09:40, James Beddek пишет: > > As part of transitioning to using Clang as my system compiler, I have been > > running tests on most packages to determine if they still properly > > function. However, this has introduced a problem where some KDE package > > tests segfault. > > Unfortunately, this launches DrKonqi in the virtx display to display a > > backtrace. > > > > This results in the test phase hanging as DrKonqi is presumably waiting > > for user input.> > > See below for an instance of a test phase hanging as seen through `top -b -c -n 1 -u portage`: > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ > > COMMAND > > > > 3441869 portage 30 102360 1560 1400 S 0.0 0.0 0:00.00 > > [kde-apps/ark-21.08.2] sandbox /usr/lib/portage/python3.9/ebuild.sh test > > 3441870 portage 30 10 12896 7688 3592 S 0.0 0.0 0:00.01 > > /bin/bash /usr/lib/portage/python3.9/ebuild.sh test 3441886 portage 30 > > 10 13036 6296 2064 S 0.0 0.0 0:00.01 /bin/bash > > /usr/lib/portage/python3.9/ebuild.sh test 3441908 portage 30 10 > > 150436 59128 44836 S 0.0 0.1 0:00.03 /usr/bin/Xvfb :16 -screen 0 > > 1280x1024x24 +extension RANDR 3441936 portage 30 10 55000 15512 > > 13416 S 0.0 0.0 0:00.02 ctest -j 16 --test-load 999 3441938 portage > > 30 10 487364 58044 46480 T 0.0 0.1 0:00.20 > > /var/tmp/portage/kde-apps/ark-21.08.2/work/ark-21.08.2_build/bin/addtoarc > > hivetest 3442262 portage 30 109176 2336 1600 S 0.0 0.0 > > 0:00.00 dbus-launch --autolaunch 8d4328e526b647a5a2e029d1e0814ba6 > > --binary-syntax --close-stderr 3442279 portage 30 109460 4180 > > 3408 S 0.0 0.0 0:00.00 /usr/bin/dbus-daemon --syslog-only --fork > > --print-pid 5 --print-address 7 --session 3444712 portage 30 10 > > 350068 94032 78820 S 0.0 0.1 0:00.15 /usr/lib64/libexec/drkonqi > > --platform xcb --display :16 --appname addtoarchivetest ___ > > > > As far as I can tell, without sending SIGKILL to the test being traced > > (addtoarchivetest in this instance), the test phase never exits. > > > > KDE provides a variable, KDE_DEBUG [1], which when set disables the > > DrKonqi crash handler. Using this results in the tests segfaulting and > > the test phase simply failing, rather than hanging. > Do crashes of other (non-ecm) tests trigger DrKonqi too? What's the > reason to add this variable only to ecm.eclass? > As far as I can tell only packages that use ecm.eclass trigger DrKonqi upon a test segfault. However, this may just be to me not experiencing crashes in other test suites. To the best of my knowledge it's purely the KDE/ecm packages. Cheers > > Most of the crashing tests are a result of kde-frameworks/kjs being built > > with Clang. I have opened a bug report about this on bugs.kde.org [2]. > > > > Hopefully this is an acceptable solution. I have submitted a corresponding > > GitHub PR [3]. Cheers > > > > [1]: > > https://userbase.kde.org/KDE_System_Administration/Environment_Variables# > > KDE_DEBUG [2]: https://bugs.kde.org/show_bug.cgi?id=444003#c5 > > [3]: https://github.com/gentoo/gentoo/pull/22643 > > > > James Beddek (1): > > ecm.eclass: set KDE_DEBUG=1 for ecm_src_test > > > > eclass/ecm.eclass | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [PATCH 0/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test
As part of transitioning to using Clang as my system compiler, I have been running tests on most packages to determine if they still properly function. However, this has introduced a problem where some KDE package tests segfault. Unfortunately, this launches DrKonqi in the virtx display to display a backtrace. This results in the test phase hanging as DrKonqi is presumably waiting for user input. See below for an instance of a test phase hanging as seen through `top -b -c -n 1 -u portage`: PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 3441869 portage 30 102360 1560 1400 S 0.0 0.0 0:00.00 [kde-apps/ark-21.08.2] sandbox /usr/lib/portage/python3.9/ebuild.sh test 3441870 portage 30 10 12896 7688 3592 S 0.0 0.0 0:00.01 /bin/bash /usr/lib/portage/python3.9/ebuild.sh test 3441886 portage 30 10 13036 6296 2064 S 0.0 0.0 0:00.01 /bin/bash /usr/lib/portage/python3.9/ebuild.sh test 3441908 portage 30 10 150436 59128 44836 S 0.0 0.1 0:00.03 /usr/bin/Xvfb :16 -screen 0 1280x1024x24 +extension RANDR 3441936 portage 30 10 55000 15512 13416 S 0.0 0.0 0:00.02 ctest -j 16 --test-load 999 3441938 portage 30 10 487364 58044 46480 T 0.0 0.1 0:00.20 /var/tmp/portage/kde-apps/ark-21.08.2/work/ark-21.08.2_build/bin/addtoarchivetest 3442262 portage 30 109176 2336 1600 S 0.0 0.0 0:00.00 dbus-launch --autolaunch 8d4328e526b647a5a2e029d1e0814ba6 --binary-syntax --close-stderr 3442279 portage 30 109460 4180 3408 S 0.0 0.0 0:00.00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session 3444712 portage 30 10 350068 94032 78820 S 0.0 0.1 0:00.15 /usr/lib64/libexec/drkonqi --platform xcb --display :16 --appname addtoarchivetest ___ As far as I can tell, without sending SIGKILL to the test being traced (addtoarchivetest in this instance), the test phase never exits. KDE provides a variable, KDE_DEBUG [1], which when set disables the DrKonqi crash handler. Using this results in the tests segfaulting and the test phase simply failing, rather than hanging. Most of the crashing tests are a result of kde-frameworks/kjs being built with Clang. I have opened a bug report about this on bugs.kde.org [2]. Hopefully this is an acceptable solution. I have submitted a corresponding GitHub PR [3]. Cheers [1]: https://userbase.kde.org/KDE_System_Administration/Environment_Variables#KDE_DEBUG [2]: https://bugs.kde.org/show_bug.cgi?id=444003#c5 [3]: https://github.com/gentoo/gentoo/pull/22643 James Beddek (1): ecm.eclass: set KDE_DEBUG=1 for ecm_src_test eclass/ecm.eclass | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.33.1
[gentoo-dev] [PATCH 1/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test
The KDE_DEBUG variable [1] prevents crash handlers such as DrKonqi from
launching
if a test were to segfault.
This prevents a hanging test phase where DrKonqi has launched and is waiting
for input on the virtx display.
[1]:
https://userbase.kde.org/KDE_System_Administration/Environment_Variables#KDE_DEBUG
Signed-off-by: James Beddek
---
eclass/ecm.eclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/eclass/ecm.eclass b/eclass/ecm.eclass
index a2c8ed1c954..5ae6e73401e 100644
--- a/eclass/ecm.eclass
+++ b/eclass/ecm.eclass
@@ -508,7 +508,8 @@ ecm_src_test() {
export $(dbus-launch)
fi
- cmake_src_test
+ # KDE_DEBUG stops crash handlers from launching and hanging the
test phase
+ KDE_DEBUG=1 cmake_src_test
}
# When run as normal user during ebuild development with the ebuild
command,
--
2.33.1
Re: [gentoo-dev] thev00d00's packages up for grabs
On Sunday, 3 October 2021 8:09:13 PM NZDT Joonas Niilola wrote: > Hey, > > Due to retirement these are now up for grabs: > acct-group/gerbera > acct-user/gerbera > dev-lang/duktape > dev-libs/libcec > dev-libs/libplatform > dev-python/rarfile > dev-python/tvdb_api > media-tv/tvnamer > media-video/handbrake > net-libs/libupnp > net-misc/gerbera > sys-apps/sensei-raw-ctl > x11-themes/kvantum > > pkgcheck doesn't report anything radical for these, mostly > PythonCompatUpdates, then a couple of DeprecatedEapis, > DeprecatedEclasses, VariableScopes and UnusedInherits. > > -- juippis I'm interested in taking handbrake as part of proxy-maint. > media-video/handbrake I'll set up a PR in a few days if no one else gets to it first :-) 0xBE6CC0BAAABB40BAAE5383C1A60BDA4E71876063.asc Description: application/pgp-keys signature.asc Description: This is a digitally signed message part.
