Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
On Mon, May 04, 2020 at 11:57:03PM +0100, Andrey Utkin wrote: > Since it is going to be opt-in and optional anyway, we seem to be fine with > having just partial data. > > I assume we have logs of distfiles downloads from Gentoo infrastructure, and > can negotiate access to relevant logs of our mirrors. That constitutes partial > data correlated with users' installation activity, as good as it gets. This assumption is wrong at the root. > If we do have some such data, are we using it in any way for the discussed > purposes? > > If we don't, but could get it, would we be able to use that data for these > purposes? If no, why? > > If we can't get the data, why? Simply put: Gentoo does not run the last-mile edge of distfile distribution. $ dig @ns1.gentoo.org +noall +answer distfiles.gentoo.org IN A distfiles.gentoo.org. 7200IN A 64.50.233.100 distfiles.gentoo.org. 7200IN A 140.211.166.134 distfiles.gentoo.org. 7200IN A 64.50.236.52 $ echo 140.211.166.134 64.50.233.100 64.50.236.52 |fmt -1 |xargs -n1 dig +short -x ftp-osl.osuosl.org. ftp-nyc.osuosl.org. ftp-chi.osuosl.org. And historically also TDS & another provider. Plus all of the regional mirrors that don't even have .gentoo.org hostnames. I would like to replace the legacy http://distfiles.gentoo.org/ functionality with a redirection service, at which point you could have partial data, but it answers a very different question than Goose. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-05-24 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2020-05-24 23:59 UTC. Removals: app-admin/ara 20200523-09:30 mgorny1db2ba29f90 app-admin/installer 20200523-09:30 mgorny09ff3b09b67 app-backup/bup20200523-09:52 mgornyea4ac42ea4f app-backup/kup20200523-09:52 mgorny409d596d048 app-crypt/gkeys 20200523-09:30 mgorny8d2f337ba3e app-crypt/manuale 20200523-09:31 mgorny8b110924d6f app-misc/openastro20200523-09:33 mgorny6c0e233c163 app-misc/openastro-data 20200523-09:33 mgorny21fc9ff1306 app-text/doconce 20200523-09:33 mgorny452767d5ce1 dev-python/cligj 20200523-09:51 mgorny0eecfa6fbed dev-python/demjson20200523-09:44 mgorny9f02499ad61 dev-python/dexml 20200523-09:44 mgorny2102361b72a dev-python/django-durationfield 20200523-09:46 mgornyba90d913751 dev-python/django-setuptest 20200523-09:46 mgornyd5f4d13d414 dev-python/django-spurl 20200523-09:46 mgorny942b64bd6e0 dev-python/fabric 20200523-09:25 mgorny9b095454da9 dev-python/filemagic 20200523-09:47 mgornydd6d8e93656 dev-python/flask-bootstrap20200523-09:44 mgorny0bf915ce1aa dev-python/invoke 20200523-09:26 mgorny439daea00ff dev-python/ipdbplugin 20200523-09:52 mgorny976fe7cf9dc dev-python/junit-xml 20200523-09:52 mgornya94b53f4e2d dev-python/kivy-garden20200523-09:54 mgornybe715c67705 dev-python/potr 20200523-09:27 mgornyfaf686e9ee2 dev-python/pycrypto 20200523-09:28 mgorny09301ae9f54 dev-python/PyDbLite 20200523-09:54 mgornya99a6ac1972 dev-python/rst2pdf20200523-09:43 mgorny8a9bc6d7776 dev-python/URLObject 20200523-09:51 mgornye347f07c429 dev-ruby/libxml 20200523-05:30 graaffad99b66d9fd dev-tcltk/tcl-mccp20200520-13:10 zlogene 3bf80a01ff1 dev-util/bumpversion 20200523-09:34 mgornyaa8d18f29fe dev-util/spec-cleaner 20200523-09:34 mgornyb98f5ed0bea dev-vcs/ghp-import20200523-09:34 mgornyf81936cb8d5 dev-vcs/git-imerge20200523-09:35 mgorny0a9700d7d70 games-misc/OilWar 20200523-08:24 mgornya4560afd406 media-fonts/symbola 20200523-08:27 mgorny62cf7d5a108 media-gfx/qrencode-python 20200523-09:36 mgorny9d872e948bb media-gfx/svg2rlg 20200523-09:43 mgorny870019d3f18 media-sound/lyvi 20200523-09:37 mgorny888bfbefa0f media-video/griffith 20200523-09:44 mgorny176d35ce731 net-misc/gns3-converter 20200524-22:38 bman 2412a2c9f40 net-misc/ssvnc20200523-09:24 mgornyc221e57b59e net-misc/trackma 20200523-09:37 mgornyd0a9de6ebb6 sci-biology/bioruby 20200523-05:30 graaff3ded18d070f sci-geosciences/gpxpy 20200523-09:39 mgorny995a7185504 sci-geosciences/seawater 20200523-09:39 mgornyb9ce9d9f91a sci-libs/Fiona20200523-09:40 mgornybf069f689f7 sys-apps/fwupdate 20200523-08:28 mgorny874ae4c3664 sys-boot/raspberrypi-mkimage 20200523-09:40 mgornye20a0fe53f1 Additions: acct-group/apache 20200518-22:01 dilfridge a051f029599 acct-group/exabgp 20200520-01:13 chutzpah 9767b116546 acct-group/svnusers 20200515-21:56 dilfridge 818b21ac751 acct-user/apache 20200518-22:07 dilfridge 7f5d121b079 acct-user/exabgp 20200520-01:14 chutzpah 391c96e931e acct-user/svn 20200515-21:57 dilfridge 7ba67bfc1b1 app-arch/lxqt-archiver20200427-19:44 asturm57eff76851b app-portage/gander20200519-11:16 mgorny3c390008467 dev-cpp/cpp-taskflow 20200523-07:00 tamikofcb2ebb167a dev-python/pynput 20200522-16:40 zerochaos e21822563d8 dev-python/pyside220200522-16:29 zerochaos 7e19d8487c6 dev-python/python-email-validator 20200519-12:01 mgorny3c0085f33b1 dev-python/shiboken2 20200522-16:33 zerochaos b8a532bc7a5 dev-ruby/brotli 20200523-07:43 graaffaba59edc078 dev-ruby/rantly 20200523-06:56 graaff831d772121d dev-util/webhook 20200521-05:05 robbat2 b09a6f16b76 gui-apps/kanshi 20200518-11:51 bman c6bbd5cfd19 media-libs/elgato-streamdeck 20200519-19:51 zerochaos e2263e63d56 media-video/streamdeck-ui 20200522-16:50 zerochaos e21afa26df4 sci-mathematics/sympow20200516-11:02 mjo fccf8fbb4fe sci-physics/vmc
[gentoo-portage-dev] [PATCH] ecompress: ignore docompress -x files in precompressed QA check (bug 721516)
Ignore files passed to docompress -x in the QA check for
precompressed files.
Bug: https://bugs.gentoo.org/721516
Signed-off-by: Zac Medico
---
bin/ecompress | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/bin/ecompress b/bin/ecompress
index dfa1a0b44..2d74ed07a 100755
--- a/bin/ecompress
+++ b/bin/ecompress
@@ -19,16 +19,28 @@ while [[ $# -gt 0 ]] ; do
shift
skip_dirs=()
+ skip_files=()
for skip; do
if [[ -d ${ED%/}/${skip#/} ]]; then
skip_dirs+=( "${ED%/}/${skip#/}" )
else
rm -f "${ED%/}/${skip#/}.ecompress" || die
+ skip_files+=("${ED%/}/${skip#/}")
fi
done
if [[ ${#skip_dirs[@]} -gt 0 ]]; then
- find "${skip_dirs[@]}" -name '*.ecompress' -delete ||
die
+ while read -r -d ''; do
+ skip_files+=(${REPLY#.ecompress})
+ done < <(find "${skip_dirs[@]}" -name '*.ecompress'
-print0 -delete || die)
+ fi
+
+ if [[ ${#skip_files[@]} -gt 0 && -s
${T}/.ecompress_had_precompressed ]]; then
+ sed_args=()
+ for f in "${skip_files[@]}"; do
+ sed_args+=(-e "s|^${f}\$||")
+ done
+ sed "${sed_args[@]}" -e '/^$/d' -i
"${T}/.ecompress_had_precompressed" || die
fi
exit 0
@@ -176,7 +188,7 @@ find "${ED}" -name '*.ecompress' -delete -print0 |
___parallel_xargs -0 "${PORTAGE_BIN_PATH}"/ecompress-file
ret=${?}
-if [[ -f ${T}/.ecompress_had_precompressed ]]; then
+if [[ -s ${T}/.ecompress_had_precompressed ]]; then
eqawarn "One or more compressed files were found in docompress-ed
directories."
eqawarn "Please fix the ebuild not to install compressed files
(manpages,"
eqawarn "documentation) when automatic compression is used:"
--
2.25.3
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
On 5/24/20 9:40 AM, Daniel Buschke wrote: > Am 24.05.2020 um 14:10 schrieb Daniel Pielmeier: >> Here the bash version takes around 2.9 seconds while the python version >> takes 3.2 seconds. Excluding the portage API it takes 2.8 seconds and >> also excluding the data query it takes 0.3 seconds. So in the python >> version the data query takes 2.5 seconds (probably this is similar for >> the bash version) while all the rest takes 0.7 seconds >> >> My initial tests showed that the bash version is a lot quicker than the >> python version. Somehow I can not reproduce this any more. As mentioned >> previously the data query is the most time consuming part in both the >> bash and the python version. > > Oh dear! I readded the database index for file names. Now the data query > takes ~0.3 seconds *insert self slapping image here* > > Anyway, for some strange reason I cannot reproduce the slothy behaviour > of portage, too. I'm 100% sure the bash version took 1 second while the > python version took 3 seconds. Strange. > > @Zac: Did you add some performance optimizations in the last 30 days? > Maybe Caching? No? Then you fixed this by pure imagination :) No portage changes, but it looks like whatever "big difference" you've observed was probably related to the slowest step which is the remote data query. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Sending from the proper address so this mail also reaches the list! Daniel Buschke schrieb am 24.05.20 um 18:40: > Oh dear! I readded the database index for file names. Now the data query > takes ~0.3 seconds *insert self slapping image here* Good to hear! Now it's way quicker! > Anyway, for some strange reason I cannot reproduce the slothy behaviour > of portage, too. I'm 100% sure the bash version took 1 second while the > python version took 3 seconds. Strange. Me too. The bash version queries another URL than the python version. Could this make a difference? However as of today it does not seem so! > @Zac: Did you add some performance optimizations in the last 30 days? > Maybe Caching? No? Then you fixed this by pure imagination :) Don't think so, as it was the bash version that became slower :-) -- Best Regards Daniel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Am 24.05.2020 um 14:10 schrieb Daniel Pielmeier: Here the bash version takes around 2.9 seconds while the python version takes 3.2 seconds. Excluding the portage API it takes 2.8 seconds and also excluding the data query it takes 0.3 seconds. So in the python version the data query takes 2.5 seconds (probably this is similar for the bash version) while all the rest takes 0.7 seconds My initial tests showed that the bash version is a lot quicker than the python version. Somehow I can not reproduce this any more. As mentioned previously the data query is the most time consuming part in both the bash and the python version. Oh dear! I readded the database index for file names. Now the data query takes ~0.3 seconds *insert self slapping image here* Anyway, for some strange reason I cannot reproduce the slothy behaviour of portage, too. I'm 100% sure the bash version took 1 second while the python version took 3 seconds. Strange. @Zac: Did you add some performance optimizations in the last 30 days? Maybe Caching? No? Then you fixed this by pure imagination :) I will try again later. But currently I broke my system and am unable to install termcolor 'cause of some python3_7 vs python3_6 f*%§up
Re: [gentoo-dev] [RFC] Anti-spam for goose
On Sun, 24 May 2020 13:05:35 + Peter Stuge wrote: > The bar only needs to be raised high enough. Sure. A lot of this is just "think about what could happen in the worst case imaginable". Its very unlikely our worst cases will happen. But we should at least have the ability to easily add mitigations in future if things do get worse. pgpL037xJyqxw.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
Kent Fredric wrote: > > While services such as reCAPTCHA are (as said) massively intrusive, there > > are other, much less intrusive and even terminal-compatible ways to > > construct > > a CAPTCHA. Hello game developers, you have 80x23 "pixels" to render a puzzle > > for a human above the response input line - that's not so bad. > > Well, they kinda have to be, I disagree with that, especially for this service, that was the point I wanted to make. :) > the state of AI is increasing so much that current captcha systems > undoubtedly also develop their own adversarial AI to try beat their > own captcha. > > I don't think we have the sort of power to develop this. In any case I don't think that's required. > And the inherently low entropy of only having 80x23 with so few > (compared to full RGB) bits per pixel, A character doesn't compare too bad to RGB. See aalib, or if you will risk exclusion of color-vision-impaired humans libcaca. > this gives any would-be AI a substantial leg up. > > Using text distortion is amateur hour these days. > > (and there's always mechanical-turk anyway) Except this isn't for some web-scale disruptive startup, it's a statistics/reputation system for an advanced, super-nerdy Linux distribution. Please think more about the threat model, and remember the rate limit knob. The bar only needs to be raised high enough. //Peter
Re: [gentoo-dev] [RFC] Bootloader use in eclean-kernel
Michał Górny wrote: > Hence my question: do you find 'do not remove kernels listed > in bootloader config' feature useful? Do you think it should remain > the default? Do you think it is worthwhile to continue supporting it? I continue to use LILO because simpler and more mature code is good, especially in the boot code path. I used GRUB for a short while but when I saw it fail to boot from one start to another (without any OS changes) I ended that experiment. I also wasn't impressed by the GRUB2 code quality and tendency to become a mini-OS, trendy as that is. I don't use eclean-kernel, but FWIW I think there is clear value in supporting the LILO-style approach with explicit installation/configuration of the bootloader in advance. //Peter
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Daniel Buschke schrieb am 24.05.20 um 00:05: > Am 23.05.2020 um 23:46 schrieb Daniel Pielmeier: >> Hm correct me if I am wrong, but from looking at the patch Zac >> provided I think he meant that the time portage consumes is only one >> second while the "rest" is 3.2 seconds. So there is probably a >> potential in improving the "rest" somehow. > > Yes and no. The difference between the python and bash version is > roughly 2 seconds. One second for importing portage (which Zac patched > away) and another second for the rest of the portage stuff. So using the > portage API adds two additional seconds. > > The python version needs 3.2 seconds on my system. As said the portage > API (or better calling the portage API) consumes ~2 seconds. As this is > the most time intense part the question is if there is a way to optimize > this. > I did run some tests comparing the run time of the bash version, the python version, the python version excluding the portage API and the python version excluding the portage API AND the data query. I run all the commands multiple times for multiple search strings (dropping caches in between) and compared the average times excluding min/max values to account for network hiccups. Here the bash version takes around 2.9 seconds while the python version takes 3.2 seconds. Excluding the portage API it takes 2.8 seconds and also excluding the data query it takes 0.3 seconds. So in the python version the data query takes 2.5 seconds (probably this is similar for the bash version) while all the rest takes 0.7 seconds My initial tests showed that the bash version is a lot quicker than the python version. Somehow I can not reproduce this any more. As mentioned previously the data query is the most time consuming part in both the bash and the python version. So I think the python version can compete with the bash version and it should be okay to switch to it in upcoming pfl releases. -- Best Regards Daniel P :-) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sun, 24 May 2020 09:40:50 +0800
"Pengcheng Xu" wrote:
> > USE=-native-symlinks removes a bunch of links that most packages use by
> > default
> > until are overridden explicitly. Incomplete list is:
> > - /lib/cpp
> > - /usr/bin/{gcc,cc,g++,c++,...}
> > - /usr/bin/{as,ld,ranlib,dwp,...}
> >
> > The rule of thumb is: if a tool does not have ${CTARGET}- prefix it will
> > probably
> > disappear with USE=-native-symlinks.
> >
> > (At least eventually) 'emerge' should still be able to build most of
> > packages
> > in such environment. I expect initial breakage will be huge though.
> >
> > Using './configure && make && make install' style workflow will be more
> > tedious.
> > One workaround at least for gcc is to use something like:
> > $ PATH="$(gcc-config -B):$PATH"
> > It's not perfect. We'll see if toolchain can provide nicer environment.
> >
>
> Do we currently have (or is there a plan for) a mechanism to manage the
> symbolic links and/or create them after merging the package when necessary?
> It's quite tiresome to type in $CHOST-gcc for simple everyday tasks.
There currently is no nice way to get stable path with up-to-date
symlinks for current gcc/binutils. I think of adding a gentoo-specific
directory to manage symlinks similar to what 'gcc-config -B' provides
in a stable path that you can write once into user's PATH.
No concrete implementation yet. Filed https://bugs.gentoo.org/724980
to track it.
--
Sergei
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On 24-05-2020 10:48:47 +0100, Sergei Trofimovich wrote:
> On Sat, 23 May 2020 22:41:02 -0400
> Mike Gilbert wrote:
> > I don't think we
> > want to give people the impression that this is a well-supported
> > configuration. I would only expect people to disable this if they want
> > to break their system intentionally.
>
> Yeah, today it's certainly a way to get your system in a miserable state.
> My hope is that USE=-native-symlinks can get you a working Gentoo in a
> near future by only fixing real package problems and limitations of their
> build systems.
Portage adds PREROOTPATH, ROOTPATH and a standard set of
/usr/{local/,}{s,}bin to PATH in _doebuild_path. That means if you add
something like /usr/bin/native-toolchain to PATH only, users will get
gcc, ld, etc., while root and Portage will lack these. One can wonder
if root should have direct access to compilers, but it's easy enough to
add the compilers to PATH if really necessary.
I guess what I'm trying to say is: you can hide effect of the setup for
users if you'd like. That is, after we had buildbots point out the bulk
of packages that are wrong of course.
Thanks,
Fabian
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sat, 23 May 2020 22:41:02 -0400
Mike Gilbert wrote:
> On Fri, May 22, 2020 at 5:36 PM Sergei Trofimovich wrote:
> >
> > 'tc-directly' tracker https://bugs.gentoo.org/243502 tracks
> > packages that don't respect users' CC/AR/LD flags.
> >
> > I added new USE=-native-symlinks mode for gcc-config and
> > binutils-config to ease detection of such packages.
> >
> > Native symlinks are still installed by default. Nothing should
> > break for users who use default USE flags.
> >
> > USE=-native-symlinks removes a bunch of links that most packages
> > use by default until are overridden explicitly. Incomplete list is:
> > - /lib/cpp
> > - /usr/bin/{gcc,cc,g++,c++,...}
> > - /usr/bin/{as,ld,ranlib,dwp,...}
> >
> > The rule of thumb is: if a tool does not have ${CTARGET}- prefix
> > it will probably disappear with USE=-native-symlinks.
> >
> > (At least eventually) 'emerge' should still be able to build most
> > of packages in such environment. I expect initial breakage will be
> > huge though.
>
> Could you please add this flag to package.use.force?
Added as
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0f8b5b847429642977d4c0497068a93222ff3136
> I don't think we
> want to give people the impression that this is a well-supported
> configuration. I would only expect people to disable this if they want
> to break their system intentionally.
Yeah, today it's certainly a way to get your system in a miserable state.
My hope is that USE=-native-symlinks can get you a working Gentoo in a
near future by only fixing real package problems and limitations of their
build systems.
--
Sergei
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sat, 23 May 2020 23:40:22 -0700 Matt Turner wrote: > On Sat, May 23, 2020 at 10:21 PM Joonas Niilola wrote: > > > > > > On 5/24/20 5:41 AM, Mike Gilbert wrote: > > > Also, people are likely to disable this accidentally via USE="-*". > > > > Counts as > > > > > if they want to break their system intentionally. > > Yes, but unfortunately catalyst's stage1 build does exactly this. > > Suggestions how to avoid doing this would be appreciated, but until > that's resolved we don't have carte blanche to break USE="-*". Ah, I keep forgetting about catalyst. Use-forced flags as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0f8b5b847429642977d4c0497068a93222ff3136 While at it added a page that explains how to turn it back by enthusiasts: https://wiki.gentoo.org/wiki/Project:Toolchain/use_native_symlinks and will collect more details on typical fixes and "this is fine to ignore" pitfalls. -- Sergei
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sun, 24 May 2020 10:33:18 +0200 Michał Górny wrote: > If it creates an invalid environment that is known to break packages > and is not QA-sanctioned, it should be masked. Period. Seems like yet another argument in favour of my initial position, that it probably shouldn't be controlled by a USE flag, and should *only* be controlled by the tool itself via local config persistence. (Where presently, there's no config persistence, the USE flag is all there is) pgpTzObm8wd4R.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sun, 2020-05-24 at 20:15 +1200, Kent Fredric wrote: > On Sat, 23 May 2020 22:41:02 -0400 > Mike Gilbert wrote: > > > Could you please add this flag to package.use.force? I don't think we > > Sounds more like a case for package.use.stable.force or something. > > For non-stable, we don't give guarantees about well-supported, only > that there will be bugs, and they should probably be reported. > > ( It doesn't tend to 'break' your system, it just makes upgrades fail, > runtime itself seems unaffected in general ) If it creates an invalid environment that is known to break packages and is not QA-sanctioned, it should be masked. Period. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sat, 23 May 2020 22:41:02 -0400 Mike Gilbert wrote: > Could you please add this flag to package.use.force? I don't think we Sounds more like a case for package.use.stable.force or something. For non-stable, we don't give guarantees about well-supported, only that there will be bugs, and they should probably be reported. ( It doesn't tend to 'break' your system, it just makes upgrades fail, runtime itself seems unaffected in general ) pgpMHrGzi7ALn.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sun, 24 May 2020 09:40:50 +0800
"Pengcheng Xu" wrote:
> Do we currently have (or is there a plan for) a mechanism to manage the
> symbolic links and/or create them after merging the package when necessary?
> It's quite tiresome to type in $CHOST-gcc for simple everyday tasks.
There are (currently undocumented) methods that work regardless of the
USE flag:
{binutils,gcc}-config --enable-native-links
{binutils,gcc}-config --disable-native-links
All the use flag does is dictate which of those "---native-links"
behaviours occur when no "---native-links" flags are passed.
pgp3N70arox5C.pgp
Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-ruby/rack-mount
# Hans de Graaff (2020-05-24) # No releases since 2011, upstream is gone, fails tests, # no reverse dependencies. # Masked for removal in 30 days. dev-ruby/rack-mount signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sat, May 23, 2020 at 10:21 PM Joonas Niilola wrote: > > > On 5/24/20 5:41 AM, Mike Gilbert wrote: > > Also, people are likely to disable this accidentally via USE="-*". > > Counts as > > > if they want to break their system intentionally. Yes, but unfortunately catalyst's stage1 build does exactly this. Suggestions how to avoid doing this would be appreciated, but until that's resolved we don't have carte blanche to break USE="-*".
