Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
David, I never said anything about stablizing. But that is fine, thank you for the answers. Blueness, When are you proposing to making the changes. As we are about to drop sparc from security supported arches, so we might as well add PPC to the list. On 5/10/17 11:50 PM, David Seifert wrote: > If there really is a dedicated team up > to the task and demonstrably active in keywording/stablereq'ing, we can > reconsider. -- Yury German Gentoo Security Team Lead | Gentoo Infrastructure | Planet Gentoo Email: bluekni...@gentoo.org GPG Fingerprint: 8858 89D6 C0C4 75C4 D0DD FA00 EEAF ED89 024C 043 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Thu, May 11, 2017 at 8:50 AM, David Seifert wrote: > 1. ppc(= 32 bit) will be massively dekeyworded, ppc64 will stay > unchanged (also given that it is an active arch in general and gets CPU > upgrades from IBM/OpenPOWER). Sounds good. You started the thread also talking about ia64 and sparc. What about those? Cheers, Dirkjan
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
Hi, Few janitorial notes for a start: 1. please fix your line wrapping since your messages are wrapped twice now, and it's really hard to read with single words on every second line; 2. hardcore Python topics belong on gentoo-python@ but I guess we'll continue here, 3. please keep your messages brief. The first three paragraphs tell a thing that could be told in one sentence. On czw, 2017-05-11 at 11:47 +0700, Alex Turbov wrote: > Thus generally specking, Sphinx dependencies have no relations to `DEPEND` > of particular > `dev-python/*` ebuilds! So, in simple case there is should be enough to > specify > > DEPEND=( doc? ( dev-python/sphinx ) ) > > for that ebuilds. In some rare cases (like > https://bugs.gentoo.org/show_bug.cgi?id=618162) > Sphinx could use some extensions (plugins) and they also have no any > relation to `PYTHON_COMPAT` > of particular `dev-python/*` ebuild! That plugins to work need just the > same `PYTHON_TARGETS` > as used to build Sphinx. Unfortunately I can't find appropriate helper > function(s) in any > currently present Python reelated eclasses (or am I miss smth?), so I used > the following > dependency spec: > > DEPEND=( doc? > || ( > ( > dev-python/sphinx[python_targets_python2_7] > # NOTE This packages provide extensions for Sphinx > dev-python/rst-linker[python_targets_python2_7] > dev-python/jaraco-packaging[python_targets_python2_7] > ) > ( > dev-python/sphinx[python_targets_python3_5] > dev-python/rst-linker[python_targets_python3_5] > dev-python/jaraco-packaging[python_targets_python3_5] > ) > ( > dev-python/sphinx[python_targets_python3_6] > dev-python/rst-linker[python_targets_python3_6] > dev-python/jaraco-packaging[python_targets_python3_6] > ) > ) > ) You can't use python_targets directly since it will break when the old implementations are disabled (and also make it PITA for others to add new impls). > > So, my questions are: > > 0. am I missed smth? (and there are some other cases, I don't know about) > 1. am I missed smth? (and there are some helper functions exist in eclasses > to expess that kind >of dependencies) > 2. I think it would be nice to have some support for Sphinx in eclasses to > simplify ebuilds writing >(if #1 is false) > > Ideas/comments/opinions are really welcome... Long story short, it's not worth the effort. Yes, most of the time people specify PYTHON_USEDEP on sphinx needlessly. There are two other major cases when you need it though: 1. things like autointerface that interface with packages' code, 2. and packages calling sphinx via 'python /usr/bin/sphinx ...' (i.e. requiring impl match between python in use and sphinx). However, tracking the other uses down and figuring them is not worth the effort. In the end, someone will probably add it back thinking someone must've missed it. It's too hard to get it right. In fact, I'm personally leaning towards not building docs at all in ebuilds. It's practically a wasted effort since most of the time users read docs online anyway. Building Sphinx with less implementations than its reverse dependencies is a corner case. It's not really worth spending hours making sure depends are 100% strictly correct. The more important goal is to have things working reliably, and overspecified deps are reliable, i.e. packages won't fail to build because of them. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] [RFC] New global USE flag: unwind
Suggested description: Add support for stack traces and function name resolution via sys-libs/libunwind That description is a little unwieldy though, better suggestions are welcome. Currently in use by the following packages: dev-cpp/glog:unwind - Use sys-libs/libunwind for stack unwinding instead of glibc/gcc (may be more reliable on x86_64) dev-libs/efl:unwind - Enable debug support via sys-libs/libunwind dev-libs/weston:unwind - Enable libunwind usage for backtraces dev-util/ltrace:unwind - Use sys-libs/libunwind for frame unwinding support dev-util/perf:unwind - Use sys-libs/libunwind for frame unwinding support. dev-util/strace:unwind - Enable stack backtraces (-k flag) via sys-libs/libunwind media-libs/gstreamer:unwind - Enable sys-libs/libunwind usage for better backtrace support in leaks tracer module www-apache/mod_backtrace:unwind - Use sys-libs/libunwind to provide better resolution of function names. x11-apps/intel-gpu-tools:unwind - Provide automatic stack traces on test failures x11-base/xorg-server:unwind - Enable libunwind usage for backtraces I understand that dev-cpp/glog uses the unwind flag differently from the other packages. If that is an issue that package's flag could be renamed to "libunwind" as sys-libs/libcxx et al. currently use. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Re: [RFC] News item: GCC 6 defaults to USE="pie ssp"
Hanno Böck wrote: > > I could add my voice that I ran pie by default for a while I can confirm that the situation apparently has changed drastically since my last attempt. My previous assertion is no longer valid: Currently, I recompile world on x86 system with default pie, so far with only one issue caused implicitly by clisp. Afterwards, I will recompile world on amd64 and will report back in case the situation should be very different. > We have a tracker bug for default-pie-problems in bugzilla: I reported the clisp issue and will report if I meet further. At the time when this tracker bug was opened, I had so many issues with default pie that I decided to switch it off since reporting so much would have been too time-consuming for me. I do not know what is the reason for this change. Perhaps the first gcc versions with default pie had another bug.
Re: [gentoo-dev] [RFC] New global USE flag: unwind
Ühel kenal päeval, N, 11.05.2017 kell 11:29, kirjutas Chí-Thanh Christopher Nguyễn: > Suggested description: Add support for stack traces and function > name > resolution via sys-libs/libunwind > > That description is a little unwieldy though, better suggestions are > welcome. I think it's usually used to be able to grab function names and such for crash backtraces or whatnot into logs, even if the binaries are rather optimized? > Currently in use by the following packages: > > dev-cpp/glog:unwind - Use sys-libs/libunwind for stack unwinding > instead > of glibc/gcc (may be more reliable on x86_64) > dev-libs/efl:unwind - Enable debug support via sys-libs/libunwind > dev-libs/weston:unwind - Enable libunwind usage for backtraces > dev-util/ltrace:unwind - Use sys-libs/libunwind for frame unwinding > support > dev-util/perf:unwind - Use sys-libs/libunwind for frame unwinding > support. > dev-util/strace:unwind - Enable stack backtraces (-k flag) via > sys-libs/libunwind > media-libs/gstreamer:unwind - Enable sys-libs/libunwind usage for > better > backtrace support in leaks tracer module > www-apache/mod_backtrace:unwind - Use sys-libs/libunwind to provide > better resolution of function names. > x11-apps/intel-gpu-tools:unwind - Provide automatic stack traces on > test > failures > x11-base/xorg-server:unwind - Enable libunwind usage for backtraces > > I understand that dev-cpp/glog uses the unwind flag differently from > the > other packages. If that is an issue that package's flag could be > renamed > to "libunwind" as sys-libs/libcxx et al. currently use. For gstreamer 1.12 I will also need one for libdw for DWARF unwind to avoid automagic deps. Maybe it'd be OK to control both (and so both libraries) via USE=unwind too instead of some local USE=dwarf or USE=libdw or USE=dw or whatnot? Mart
Re: [gentoo-dev] [RFC] New global USE flag: unwind
On czw, 2017-05-11 at 11:29 +0200, Chí-Thanh Christopher Nguyễn wrote: > Suggested description: Add support for stack traces and function name > resolution via sys-libs/libunwind Maybe skip the library name. Note that there's also llvm-libunwind, and some packages may be actually happy with libgcc_s. > That description is a little unwieldy though, better suggestions are > welcome. > > Currently in use by the following packages: > > dev-cpp/glog:unwind - Use sys-libs/libunwind for stack unwinding instead > of glibc/gcc (may be more reliable on x86_64) > dev-libs/efl:unwind - Enable debug support via sys-libs/libunwind > dev-libs/weston:unwind - Enable libunwind usage for backtraces > dev-util/ltrace:unwind - Use sys-libs/libunwind for frame unwinding support > dev-util/perf:unwind - Use sys-libs/libunwind for frame unwinding support. > dev-util/strace:unwind - Enable stack backtraces (-k flag) via > sys-libs/libunwind > media-libs/gstreamer:unwind - Enable sys-libs/libunwind usage for better > backtrace support in leaks tracer module > www-apache/mod_backtrace:unwind - Use sys-libs/libunwind to provide > better resolution of function names. > x11-apps/intel-gpu-tools:unwind - Provide automatic stack traces on test > failures > x11-base/xorg-server:unwind - Enable libunwind usage for backtraces > > I understand that dev-cpp/glog uses the unwind flag differently from the > other packages. If that is an issue that package's flag could be renamed > to "libunwind" as sys-libs/libcxx et al. currently use. > Yeah, that makes sense. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] New global USE flag: unwind
Michał Górny schrieb: On czw, 2017-05-11 at 11:29 +0200, Chí-Thanh Christopher Nguyễn wrote: Suggested description: Add support for stack traces and function name resolution via sys-libs/libunwind Maybe skip the library name. Note that there's also llvm-libunwind, and some packages may be actually happy with libgcc_s. Ok, then how about: "Add support for stack trace unwinding and function name resolution" I understand that dev-cpp/glog uses the unwind flag differently from the other packages. If that is an issue that package's flag could be renamed to "libunwind" as sys-libs/libcxx et al. currently use. Yeah, that makes sense. Reported: https://bugs.gentoo.org/show_bug.cgi?id=618190 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On 5/11/17 3:17 AM, Yury German wrote: > David, > > I never said anything about stablizing. But that is fine, thank you for > the answers. > > Blueness, > > When are you proposing to making the changes. As we are about to drop > sparc from security supported arches, so we might as well add PPC to the > list. > > On 5/10/17 11:50 PM, David Seifert wrote: >> If there really is a dedicated team up >> to the task and demonstrably active in keywording/stablereq'ing, we can >> reconsider. > Soap is working on the dekeywording. I just jumped in because I wanted to make sure we didn't break the catalyst runs for stage3's and he came up with the dekeywording solution which I like. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] Removal of rxvt
Hi folks, Rxvt is ancient. It's been replace by rxvt-unicode. Rxvt hasn't seen updates in years. Recently it's been the subject of a security vulnerability, and I suspect it's filled with other potential vulnerabilities. Rxvt has no upstream. I tried reaching out to the former upstream, and it's evident everybody has moved on and has no interest in further maintenance. It doesn't even have a Gentoo maintainer! Given this, I'd like to remove rxvt from Gentoo, with the usual mask-for-30-days process. Does anybody have any objections to me doing this? (I'll wait a week from now before taking any actions.) Regards, Jason -- Jason A. Donenfeld Gentoo Linux Security zx...@gentoo.org www.zx2c4.com zx2c4.com/keys/A28BEDE08F1744E16037514806C4536755758000.asc
[gentoo-dev] Re: [RFC] News item: GCC 6 defaults to USE="pie ssp"
Luis Ressel wrote: > Martin Vaeth wrote: > >> For instance, you cannot even compile the kernel without special >> patches (which disable pie) if you use a gcc which default-enables >> pie. > > Now I'm curious. Wouldn't that also affect the hardened gcc? I would guess so, but I did not try: I didn't use hardened gcc since years, because (a) I had to switch profiles too often because of forced pie which used to break compilation for almost every second package (some years ago). (b) -fstack-protector-all slowed down my system too much, especially since the security improvement over -fstack-protector-strong (or with older gcc versions -fstack-protector) is rather negligible. > I've never had any issues compiling vanilla-sources The experience I had reported was with the first non-beta versions of gcc-6[pie] from the hardened overlay and several (at that time current) versions of hardened-sources. I retried now with gcc-7.1.0-r1[pie] and current gentoo-sources, and it turned out that the issue does no longer exist. I do not know whether the reason is due to the change hardened-sources -> gentoo-sources, due to an upstream kernel fix, or due to a fix in the pie support of gcc (compared to the first gcc-6 versions).
Re: [gentoo-dev] Removal of rxvt
On 05/11/2017 08:57 AM, Jason A. Donenfeld wrote: > Hi folks, > > Rxvt is ancient. It's been replace by rxvt-unicode. Rxvt hasn't seen > updates in years. Recently it's been the subject of a security > vulnerability, and I suspect it's filled with other potential > vulnerabilities. Rxvt has no upstream. I tried reaching out to the > former upstream, and it's evident everybody has moved on and has no > interest in further maintenance. It doesn't even have a Gentoo > maintainer! > > Given this, I'd like to remove rxvt from Gentoo, with the usual > mask-for-30-days process. > > Does anybody have any objections to me doing this? (I'll wait a week > from now before taking any actions.) > > Regards, > Jason > Sounds sane to me. It might be helpful to ask if anyone in gentoo-user is interested in proxying, but as far as I know anyone who used rxvt migrated to rxvt-unicode once it was stable. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Removal of rxvt
On Thu, May 11, 2017, at 10:57 CDT, "Jason A. Donenfeld" wrote: > Does anybody have any objections to me doing this? (I'll wait a week > from now before taking any actions.) There is a clear and easy upgrade path to rxvt-unicode, so please mask right away. Best, Matthias
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp", v2
On Tue, May 09, 2017 at 06:58:42PM -0500, Matthias Maier wrote > This is a reworded news item (assuming we proceed with the plan to > default-enable USE=pie). Suggestions for improving the emerge command to > fix static archives is highly welcomed. > > Matthias > > > > Title: GCC 6 defaults to USE="pie ssp" > Author: Matthias Maier > Content-Type: text/plain > Posted: 2017-05-09 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: >=sys-devel/gcc-6.3.0 > > In Gentoo, several GCC features can be default disabled or enabled > via use-flags of sys-devel/gcc. Starting with gcc-4.8.3 we have already > enabled default SSP [1]. Since the PIE patchset for default position > independent executable support was integrated upstream [2,3], starting > with gcc-6.3 we are also enabling PIE by default (via a default-enabled > use-flag pie) in regular (non-hardened) profiles. Has anyone checked 32-bit systems? "emerge -pv =sys-devel/gcc-6.3.0" on a 2008 Core2duo 32-bit install (my GCC 6.3.0 testbed) shows "(-pie)". I read that as the "pie" USE flag being hard-masked out. On my 64-bit desktop, "pie" is the default. -- Walter Dnes I don't run "desktop environments"; I run useful applications
[gentoo-dev] [PATCH] profiles: update pie use-flag masks for sys-devel/gcc
- mask pie for sys-devel/gcc unconditionally in base/ - selectively unmask pie use-flag for hardened/linux and hardened/linux/musl profiles --- profiles/arch/amd64/package.use.mask| 4 profiles/arch/base/package.use.mask | 4 profiles/base/package.use.mask | 4 profiles/hardened/linux/musl/amd64/package.use.mask | 4 profiles/hardened/linux/musl/package.use.mask | 4 profiles/hardened/linux/package.use.mask| 4 6 files changed, 12 insertions(+), 12 deletions(-) diff --git a/profiles/arch/amd64/package.use.mask b/profiles/arch/amd64/package.use.mask index 372ea9c..cb0fafd 100644 --- a/profiles/arch/amd64/package.use.mask +++ b/profiles/arch/amd64/package.use.mask @@ -34,10 +34,6 @@ dev-lang/ocaml -spacetime # nvidia drivers are unmasked here media-video/ffmpeg -nvenc -# Magnus Granberg (18 Jan 2017) -# masked in base, unmask for amd64 ->=sys-devel/gcc-6.3.0 -pie - # Luke Dashjr (04 Jan 2017) # Assembly optimisations are supported on amd64 for all versions dev-libs/libsecp256k1 -asm diff --git a/profiles/arch/base/package.use.mask b/profiles/arch/base/package.use.mask index 5adfb6a..a9d8a52 100644 --- a/profiles/arch/base/package.use.mask +++ b/profiles/arch/base/package.use.mask @@ -22,10 +22,6 @@ media-video/ffmpeg nvenc # media-libs/raspberrypi-userland not keyworded media-video/motion mmal -# Magnus Granberg (18 Jan 2017) -# Mask it globally, unmask it on supported arch ->=sys-devel/gcc-6.2.0 pie - # Luke Dashjr (04 Jan 2017) # Mask assembly optimisations that are platform-specific dev-libs/libsecp256k1 asm diff --git a/profiles/base/package.use.mask b/profiles/base/package.use.mask index 9f55b27..68fe87a 100644 --- a/profiles/base/package.use.mask +++ b/profiles/base/package.use.mask @@ -7,6 +7,10 @@ # This file is only for generic masks. For arch-specific masks (i.e. # mask everywhere, unmask on arch/*) use arch/base. +# Matthias Maier (11 May 2017) +# Globally mask pie use flag. Selectively unmask on specific profiles. +sys-devel/gcc pie + # Mike Gilbert (28 Apr 2017) # Needs sandbox-2.11 (masked) >=www-client/chromium-59 tcmalloc diff --git a/profiles/hardened/linux/musl/amd64/package.use.mask b/profiles/hardened/linux/musl/amd64/package.use.mask index e2d77b0..49830f8 100644 --- a/profiles/hardened/linux/musl/amd64/package.use.mask +++ b/profiles/hardened/linux/musl/amd64/package.use.mask @@ -1,6 +1,2 @@ # Copyright 1999-2017 Gentoo Foundation. # Distributed under the terms of the GNU General Public License v2 - -# Matthias Maier (07 May 2017) -# masked in arch/base, unmask for hardened/musl/amd64 ->=sys-devel/gcc-6.3.0 -pie diff --git a/profiles/hardened/linux/musl/package.use.mask b/profiles/hardened/linux/musl/package.use.mask index 9078b7c..d66f247 100644 --- a/profiles/hardened/linux/musl/package.use.mask +++ b/profiles/hardened/linux/musl/package.use.mask @@ -1,6 +1,10 @@ # Copyright 1999-2015 Gentoo Foundation. # Distributed under the terms of the GNU General Public License v2 +# Matthias Maier (11 May 2017) +# masked in base, unmask for hardened/musl/ +sys-devel/gcc -pie + # See bug #504200 sys-devel/gcc sanitize diff --git a/profiles/hardened/linux/package.use.mask b/profiles/hardened/linux/package.use.mask index 4178151..4a80418 100644 --- a/profiles/hardened/linux/package.use.mask +++ b/profiles/hardened/linux/package.use.mask @@ -1,6 +1,10 @@ # Copyright 1999-2017 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 +# Matthias Maier (11 May 2017) +# masked in base, unmask for hardened profiles +sys-devel/gcc -pie + # Ilya Tumaykin (19 Jan 2017) # Requires x11-drivers/nvidia-drivers. Needs testing first. media-video/mpv cuda -- 2.10.2
[gentoo-dev] [PATCH] profiles: update pie use-flag masks for sys-devel/gcc
Hello all, In light of the recent discussion, I will restore the status quo for the pie use-flag: masked on non-hardened profiles, unmasked and forced on hardened profiles. The next step will be to switch the pie use-flag on default profiles from masked to unmasked/forced with a profile update. Best, Matthias
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp", v2
> Has anyone checked 32-bit systems? "emerge -pv =sys-devel/gcc-6.3.0" > on a 2008 Core2duo 32-bit install (my GCC 6.3.0 testbed) shows "(-pie)". > I read that as the "pie" USE flag being hard-masked out. On my 64-bit > desktop, "pie" is the default. Yes, we are aware of this. Unfortunately, determining the course of action took a bit of time. Will be fixed with a small profile update within the next 24h. Best, Matthias
[gentoo-dev] Re: [PATCH] profiles: update pie use-flag masks for sys-devel/gcc
Matthias Maier posted on Thu, 11 May 2017 19:17:51 -0500 as excerpted: > In light of the recent discussion, I will restore the status quo for the > pie use-flag: masked on non-hardened profiles, unmasked and forced on > hardened profiles. > > The next step will be to switch the pie use-flag on default profiles > from masked to unmasked/forced with a profile update. For those of us who already have a default-pie system and now that we do, don't want to go back, what's the prescribed override? I've never felt the need to override a masked flag like that, before. (I'm sure I could find the general documentation and handle it myself, but I'm equally sure that there's likely to be others in my situation by now, and we shouldn't /all/ need to figure it out on our own.) (As some may remember, yes, I do have USE="-* ..." set, so didn't get pie with the initial gcc6 emerge and @world rebuild, but I was persuaded by the discussion here to try it, second global rebuild, and so far it works. So both because it's supposed to be safer and because I don't want to do now a /third/ global rebuild, I strongly prefer to keep it, now that I have it, and no issues so far.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: [PATCH] profiles: update pie use-flag masks for sys-devel/gcc
On 05/11/2017 10:45 PM, Duncan wrote:
> Matthias Maier posted on Thu, 11 May 2017 19:17:51 -0500 as excerpted:
>
>> In light of the recent discussion, I will restore the status quo for the
>> pie use-flag: masked on non-hardened profiles, unmasked and forced on
>> hardened profiles.
>>
>> The next step will be to switch the pie use-flag on default profiles
>> from masked to unmasked/forced with a profile update.
>
> For those of us who already have a default-pie system and now that we do,
> don't want to go back, what's the prescribed override? I've never felt
> the need to override a masked flag like that, before.
>
> (I'm sure I could find the general documentation and handle it myself,
> but I'm equally sure that there's likely to be others in my situation by
> now, and we shouldn't /all/ need to figure it out on our own.)
>
> (As some may remember, yes, I do have USE="-* ..." set, so didn't get pie
> with the initial gcc6 emerge and @world rebuild, but I was persuaded by
> the discussion here to try it, second global rebuild, and so far it
> works. So both because it's supposed to be safer and because I don't
> want to do now a /third/ global rebuild, I strongly prefer to keep it,
> now that I have it, and no issues so far.)
>
In general, to override a package.use{,.stable}.{mask,force} entry in
your profile, you add an entry to the same file in /etc/portage/profile/
that turns off the mask/force value in the profile. In this case, you
would add a line like:
>=sys-devel/gcc-6.3.0 -pie
to the /etc/portage/profile/package.use.mask file (creating the
file/parent directory as needed). If a flag is masked/forced for all
packages in use.{mask,force}, then you would add a line like "-foo" to
the use.{mask,force} file in /etc/portage/profile/.
--
Jonathan Callen
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH] profiles: update pie use-flag masks for sys-devel/gcc
Jonathan Callen posted on Thu, 11 May 2017 23:25:24 -0400 as excerpted:
> In this case, you would add a line like:
>
> >=sys-devel/gcc-6.3.0 -pie
>
> to the /etc/portage/profile/package.use.mask file (creating the
> file/parent directory as needed). If a flag is masked/forced for all
> packages in use.{mask,force}, then you would add a line like "-foo" to
> the use.{mask,force} file in /etc/portage/profile/.
Thanks. As I said I doubt I'm the only one who will find this useful.
=:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
On Thu, May 11, 2017 at 2:51 PM, Michał Górny wrote: > Hi, > > Few janitorial notes for a start: > > 1. please fix your line wrapping since your messages are wrapped twice > now, and it's really hard to read with single words on every second > line; > sorry, I don't understand what are you talking about... probably some problem with your email client (or whatever you use). I'm using gmail's web UI and see no double wraps... > > 2. hardcore Python topics belong on gentoo-python@ but I guess we'll > continue here, > I don't see this ML here: https://gentoo.org/get-involved/mailing-lists/ so I decided to use `gentoo-dev` > > 3. please keep your messages brief. The first three paragraphs tell > a thing that could be told in one sentence. > I've got no idea what message format is "usual" in this ML... from my experience talking to various "tech support" and bug trackers ppl usually asking a lot of stupid questions if I wrote just "one sentence"... > > You can't use python_targets directly since it will break when the old > implementations are disabled (and also make it PITA for others to add > new impls). > Ok, what I can use instead? > > > Long story short, it's not worth the effort. > > Yes, most of the time people specify PYTHON_USEDEP on sphinx needlessly. > There are two other major cases when you need it though: > > 1. things like autointerface that interface with packages' code, > what are you talking about? ( https://pypi.python.org/pypi/repoze.sphinx.autointerface/ ??) > > 2. and packages calling sphinx via 'python /usr/bin/sphinx ...' (i.e. > requiring impl match between python in use and sphinx). > do you mean they are doing it from ebuild? > > In fact, I'm personally leaning towards not building docs at all > in ebuilds. It's practically a wasted effort since most of the time > users read docs online anyway. > unfortunately I'm travelling a lot and really often in places where Internet connection is far from good. it is why I like to have offline docs for some packages. moreover I really hate when some docs are not really offline and want to load google fonts or JS :( > > However, tracking the other uses down and figuring them is not worth > the effort. In the end, someone will probably add it back thinking > someone must've missed it. It's too hard to get it right. > I didn't get what are you talking about... > Building Sphinx with less implementations than its reverse dependencies > is a corner case. It's not really worth spending hours making sure > depends are 100% strictly correct. The more important goal is to have > things working reliably, and overspecified deps are reliable, i.e. > packages won't fail to build because of them. > > Ok, seems I've got your point of view, but can't agree w/ it... Well, I would fight alone w/ it > -- > Best regards, > Michał Górny >
