Re: [gentoo-portage-dev] [PATCH] Disarm FEATURES=distcc-pump
On Tue, Jul 17, 2018 at 11:28 PM Michał Górny wrote: > > Sure, provided that they are warned that any suspicious bug reports will > be rejected. Developers have better things to do than try to figure out > whether some unmaintained-for-years, half-broken feature may have been > the cause of a misbehaving system. Yes, even a strong warning like "Warning: Usage of distcc-pump can lead to broken builds. Any bug report that involves a package or a package dependency of any level that is compiled with the use of distcc-pump will unconditionally be rejected. You might as well just rebuild your system without distcc-pump to make a valid bug report." is very agreeable to me. -- konsolebox
[gentoo-portage-dev] Objections to renaming pym directory to lib?
Are there any objections to renaming the pym directory to lib [1]? Note that the git log --follow option makes this kind of rename fairly painless. [1] https://github.com/gentoo/portage/pull/343 -- Thanks, Zac signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH] linux-info.eclass: fix for prematurely merged patch
https://github.com/gentoo/gentoo/pull/9222 was merged prematurely, and
included the first iteration of my linux-info EAPI 7 patch, and requires
this patch on top to avoid a double slash.
---
eclass/linux-info.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 31464766038..6cd64457edd 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -554,7 +554,7 @@ get_version() {
# caught before this if they are.
if [[ -z ${OUTPUT_DIR} ]] ; then
# Try to locate a kernel that is most relevant for us.
- for OUTPUT_DIR in "${SYSROOT}" "${ROOT%/}/" "" ; do
+ for OUTPUT_DIR in "${SYSROOT}" "${ROOT%/}" "" ; do
OUTPUT_DIR+="/lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build"
if [[ -e ${OUTPUT_DIR} ]] ; then
break
--
2.18.0
Re: [gentoo-dev] Developer commit timeline updates
W dniu pon, 25.06.2018 o godzinie 08∶22 +0200, użytkownik Fabian Groffen napisał: > On 24-06-2018 00:36:28 +0200, Michał Górny wrote: > > I'd like to just make a short announcement that I've updated > > the developer commit timeline [1]. > > Very nice stats, thanks for that. > > Suggestion: perhaps this can be cron-jobbed and updated every month or > so? It is done! Now it's part of qa-reports [1], and (since it takes less than a minute to update) it's updated daily. [1]:http://qa-reports.gentoo.org/ -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH] Disarm FEATURES=distcc-pump
W dniu wto, 17.07.2018 o godzinie 23∶11 +0800, użytkownik konsolebox napisał: > On Tue, Jul 17, 2018 at 4:45 AM Michał Górny wrote: > > > > W dniu pon, 16.07.2018 o godzinie 13∶16 -0700, użytkownik Zac Medico > > napisał: > > > On 07/16/2018 02:26 AM, Michał Górny wrote: > > > > The pump mode of distcc has been causing issues for years now, > > > > and upstream does even attempt to fix it. Disarm the FEATURES so that > > > > people do not have to do that themselves after discovering all the bugs. > > > > --- > > > > bin/phase-functions.sh | 17 - > > > > man/make.conf.5| 5 - > > > > pym/_emerge/EbuildPhase.py | 2 +- > > > > 3 files changed, 5 insertions(+), 19 deletions(-) > > > > > > Maybe we should simply support RESTRICT="distcc-pump" so that > > > incompatible ebuilds can disable it? I don't see that many bug reports > > > about it, and a forums search turned up this recent thread which > > > suggests that some people may be using it: > > > > I did. There are only two reasons you don't see them often: > > > > 1. because not that many people use distcc, > > > > 2. because when they do, they quickly learn how broken it is and disable > > it. > > It's been just a month and a half since I rebuilt a Gentoo system with > distcc-pump, and that system ended up running well. > > I don't disable distcc-pump quickly. At least not globally. I only > disable it in packages that don't compile with it. > > > RESTRICT won't be helpful because distcc-pump is also capable of silent > > miscompilations and indirect breakage. If you used it at least once, my > > only advice is to rebuild your entire system. > > I believe giving a general warning whenever distcc-pump is used is > enough. Users should be allowed to decide whether they'll use it or > not. There are users who know when to use it, and are capable of > managing build-time inconsistencies. Sure, provided that they are warned that any suspicious bug reports will be rejected. Developers have better things to do than try to figure out whether some unmaintained-for-years, half-broken feature may have been the cause of a misbehaving system. > > Saying that distcc-pump is capable of silent miscompilations and > indirect breakage I think is also an aggressive and ungrounded > presumption. It's not a 'presumption', it's experience. Yes, it's possible that the breakages I've seen don't happen at the moment. But given the generic idea that distcc-pump can cause configure checks to misfire without actually causing build-time breakage, it's entirely possible. > Also, if upstream suddenly decides to fix whatever needs to be fixed > on this, it would need another request to put the feature back, which > I find would be very hard to be granted. > > I also agree that making specific packages use RESTRICT is more appropriate. > -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH] Disarm FEATURES=distcc-pump
On Tue, Jul 17, 2018 at 4:45 AM Michał Górny wrote: > > W dniu pon, 16.07.2018 o godzinie 13∶16 -0700, użytkownik Zac Medico > napisał: > > On 07/16/2018 02:26 AM, Michał Górny wrote: > > > The pump mode of distcc has been causing issues for years now, > > > and upstream does even attempt to fix it. Disarm the FEATURES so that > > > people do not have to do that themselves after discovering all the bugs. > > > --- > > > bin/phase-functions.sh | 17 - > > > man/make.conf.5| 5 - > > > pym/_emerge/EbuildPhase.py | 2 +- > > > 3 files changed, 5 insertions(+), 19 deletions(-) > > > > Maybe we should simply support RESTRICT="distcc-pump" so that > > incompatible ebuilds can disable it? I don't see that many bug reports > > about it, and a forums search turned up this recent thread which > > suggests that some people may be using it: > > I did. There are only two reasons you don't see them often: > > 1. because not that many people use distcc, > > 2. because when they do, they quickly learn how broken it is and disable > it. It's been just a month and a half since I rebuilt a Gentoo system with distcc-pump, and that system ended up running well. I don't disable distcc-pump quickly. At least not globally. I only disable it in packages that don't compile with it. > RESTRICT won't be helpful because distcc-pump is also capable of silent > miscompilations and indirect breakage. If you used it at least once, my > only advice is to rebuild your entire system. I believe giving a general warning whenever distcc-pump is used is enough. Users should be allowed to decide whether they'll use it or not. There are users who know when to use it, and are capable of managing build-time inconsistencies. Saying that distcc-pump is capable of silent miscompilations and indirect breakage I think is also an aggressive and ungrounded presumption. Also, if upstream suddenly decides to fix whatever needs to be fixed on this, it would need another request to put the feature back, which I find would be very hard to be granted. I also agree that making specific packages use RESTRICT is more appropriate. -- konsolebox
Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Enable parallel builds in py3.5+
W dniu wto, 17.07.2018 o godzinie 10∶40 -0400, użytkownik Mike Gilbert napisał: > On Tue, Jul 17, 2018 at 4:41 AM, Michał Górny wrote: > > Python 3.5+ introduces parallel build support in distutils. Take > > advantage of that by passing appropriate -j option. Since distutils > > does not support an equivalent of --load-average, default to the number > > of CPUs+1 when unspecified. > > How do we disable this in individual ebuilds when we inevitably run > into problematic packages? My guess would be, same as emake: distutils-r1_python_compile -j1 (I haven't tested it though) -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Enable parallel builds in py3.5+
On Tue, Jul 17, 2018 at 4:41 AM, Michał Górny wrote: > Python 3.5+ introduces parallel build support in distutils. Take > advantage of that by passing appropriate -j option. Since distutils > does not support an equivalent of --load-average, default to the number > of CPUs+1 when unspecified. How do we disable this in individual ebuilds when we inevitably run into problematic packages?
[gentoo-dev] [PATCH] distutils-r1.eclass: Enable parallel builds in py3.5+
Python 3.5+ introduces parallel build support in distutils. Take
advantage of that by passing appropriate -j option. Since distutils
does not support an equivalent of --load-average, default to the number
of CPUs+1 when unspecified.
---
eclass/distutils-r1.eclass | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 975383acc09b..4d8aa3ca6677 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -80,10 +80,10 @@ if [[ ! ${_DISTUTILS_R1} ]]; then
[[ ${EAPI} == [45] ]] && inherit eutils
[[ ${EAPI} == [56] ]] && inherit xdg-utils
-inherit toolchain-funcs
+inherit multiprocessing toolchain-funcs
if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
- inherit multiprocessing python-r1
+ inherit python-r1
else
inherit python-single-r1
fi
@@ -454,7 +454,18 @@ distutils-r1_python_compile() {
_distutils-r1_copy_egg_info
- esetup.py build "${@}"
+ local build_args=()
+ # distutils is parallel-capable since py3.5
+ if python_is_python3 && [[ ${EPYTHON} != python3.4 ]]; then
+ local jobs=$(makeopts_jobs "${MAKEOPTS}" INF)
+ if [[ ${jobs} == INF ]]; then
+ local nproc=$(get_nproc)
+ jobs=$(( nproc + 1 ))
+ fi
+ build_args+=( -j "${jobs}" )
+ fi
+
+ esetup.py build "${build_args[@]}" "${@}"
}
# @FUNCTION: _distutils-r1_wrap_scripts
--
2.18.0
