[gentoo-user] Using kconfig-hardened-check.py - no sound
I have used the kernel config checking script from https://github.com/a13xp0p0v/kconfig-hardened-check/blob/master/kconfig-hardened-check.py on three systems. Two are fine, but one has lost audio. The driver is loaded, but aplay -L and /dev/snd are missing devices. Here's the changes in the new, broken audio, config. Any suspects for the breakage? # diff config-23jun2018-pre-hardening config-25jun2018 | grep ^\> > # CONFIG_BPF_SYSCALL is not set > CONFIG_SLUB_DEBUG=y > # CONFIG_SLUB_MEMCG_SYSFS_ON is not set > # CONFIG_SLAB is not set > CONFIG_SLUB=y > CONFIG_SLAB_FREELIST_RANDOM=y > CONFIG_SLAB_FREELIST_HARDENED=y > CONFIG_SLUB_CPU_PARTIAL=y > CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y > CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y > CONFIG_MODULE_SIG=y > CONFIG_MODULE_SIG_FORCE=y > CONFIG_MODULE_SIG_ALL=y > # CONFIG_MODULE_SIG_SHA1 is not set > # CONFIG_MODULE_SIG_SHA224 is not set > # CONFIG_MODULE_SIG_SHA256 is not set > # CONFIG_MODULE_SIG_SHA384 is not set > CONFIG_MODULE_SIG_SHA512=y > CONFIG_MODULE_SIG_HASH="sha512" > # CONFIG_X86_VSYSCALL_EMULATION is not set > CONFIG_DEFAULT_MMAP_MIN_ADDR=65536 > # CONFIG_KEXEC is not set > # CONFIG_KEXEC_FILE is not set > # CONFIG_LEGACY_VSYSCALL_EMULATE is not set > CONFIG_LEGACY_VSYSCALL_NONE=y > # CONFIG_MODIFY_LDT_SYSCALL is not set > # CONFIG_IA32_EMULATION is not set > # CONFIG_DEVKMEM is not set > CONFIG_PAGE_POISONING=y > # CONFIG_PAGE_POISONING_NO_SANITY is not set > # CONFIG_PAGE_POISONING_ZERO is not set > CONFIG_SLUB_DEBUG_ON=y > # CONFIG_SLUB_STATS is not set > CONFIG_SCHED_STACK_END_CHECK=y > CONFIG_DEBUG_LIST=y > CONFIG_DEBUG_SG=y > CONFIG_DEBUG_NOTIFIERS=y > CONFIG_DEBUG_CREDENTIALS=y > # CONFIG_FTRACE is not set > # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set > # CONFIG_RUNTIME_TESTING_MENU is not set > CONFIG_BUG_ON_DATA_CORRUPTION=y > CONFIG_STRICT_DEVMEM=y > CONFIG_IO_STRICT_DEVMEM=y > CONFIG_X86_PTDUMP_CORE=y > CONFIG_DEBUG_WX=y > CONFIG_SECURITY_DMESG_RESTRICT=y > CONFIG_STATIC_USERMODEHELPER=y > CONFIG_STATIC_USERMODEHELPER_PATH="/sbin/usermode-helper" > CONFIG_SECURITY_YAMA=y > CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
Re: [gentoo-user] warning (different signature type) when doing ssh
On Monday, 25 June 2018 22:40:48 BST allan gottlieb wrote: > On Mon, Jun 25 2018, Mick wrote: > > On Monday, 25 June 2018 10:19:07 BST Marc Joliet wrote: > >> Am Montag, 25. Juni 2018, 03:10:57 CEST schrieb allan gottlieb: > >> > I have two laptops call them A and B both running gentoo. > >> > I recently did on each an emerge --sync after a long absence. > >> > > >> > The large emerge --update @world's finally finished on each machine. > >> > One > >> > new behavior is that > >> > > >> > If I use the console to log into A and then ssh to B, I get > >> > > >> > warning: agent returned different signature type ssh-rsa (expected > >> > rsa-sha2-512) > >> > > >> > If I use the console to log into B and then ssh to A, > >> > I get the same warning. > >> > > >> > I see no ill effects. > >> > > >> > Need I take any action? > >> > > >> > thanks in advance, > >> > allan > >> > >> I saw the same, but it was temporary. I use gpg-agent instead of > >> ssh-agent, so I assumed it had to do with that, and then the warning > >> disappeared after upgrading gnupg, but perhaps that was just a > >> coincidence? > > > > This warning message is generated when you are using gpg-agent as > > ssh-agent > > and there is a mismatch on the ciphers between the two - i.e. when > > gpg-agent can't/won't use the ciphers expected by sshd. > > > > Do you get the same warning when you exclude the agent from the equation? > > > > ssh -a -i $HOME/.ssh/Your_SSH_Key user@host > > Yes, thanks. > allan > > gottlieb@E7450 /local/allan/gottlieb $ ssh -a -i $HOME/.ssh/id_rsa E6430 > warning: agent returned different signature type ssh-rsa (expected > rsa-sha2-512) You have new mail in folder /var/mail/gottlieb. When you kill the agent on the local PC and try to connect, I assume you no longer receive the same warning? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Slow python execution
The results are even more sever when using the same python version on the same system. I did call `python2 -m cProfile -s $sort =ansible-doc -l` twice on both systems. Once with tottime and the second time with cumulative as $sort. The results are 66 seconds on Debian and 736 seconds on Gentoo. I attach the full output to this mail. Same results I see with every python program. To do a emerge update takes ages just for dependency scans. (although there is no comparing tool in Debian) Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C results.tar.xz Description: application/xz signature.asc Description: PGP signature
Re: [gentoo-user] Problems updating glibc-2.26-r7
Mike Gilbert wrote: [...] > >> You're trying to make a multilib glibc, and your kernel does not > >> support one of the resulting ABIs (most likely > >> CONFIG_IA32_EMULATION needs to be turned on in the kernel > >> configuration to be able to run x86 binaries on an amd64 install). > >> > >> (That said, this is a rather stupid bug in the glibc build system > >> and needs to be fixed eventually.) > > > > Thank you very much for your answer. > > > > You are right. Compiling the kernel with CONFIG_IA32_EMULATION > > solved the problem. I switched from hardened kernel to gentoo > > standard kernel some time ago and just forget to compile it with > > that option. > > > > IIRC I build a multilib system many years ago because of grub. But > > maybe I don't need multilib anymore. How can I find out if I have > > x86 binaries installed? > > This should give you a good start: > > scanelf -M > 32 /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin /opt Thank you very much. So I find out that it is still grub that requires multilib on my system. -- Regards wabe
Re: [gentoo-user] warning (different signature type) when doing ssh
On Mon, Jun 25 2018, Mick wrote: > On Monday, 25 June 2018 10:19:07 BST Marc Joliet wrote: >> Am Montag, 25. Juni 2018, 03:10:57 CEST schrieb allan gottlieb: >> > I have two laptops call them A and B both running gentoo. >> > I recently did on each an emerge --sync after a long absence. >> > >> > The large emerge --update @world's finally finished on each machine. One >> > new behavior is that >> > >> > If I use the console to log into A and then ssh to B, I get >> > >> > warning: agent returned different signature type ssh-rsa (expected >> > rsa-sha2-512) >> > >> > If I use the console to log into B and then ssh to A, >> > I get the same warning. >> > >> > I see no ill effects. >> > >> > Need I take any action? >> > >> > thanks in advance, >> > allan >> >> I saw the same, but it was temporary. I use gpg-agent instead of ssh-agent, >> so I assumed it had to do with that, and then the warning disappeared after >> upgrading gnupg, but perhaps that was just a coincidence? > > This warning message is generated when you are using gpg-agent as ssh-agent > and there is a mismatch on the ciphers between the two - i.e. when gpg-agent > can't/won't use the ciphers expected by sshd. > > Do you get the same warning when you exclude the agent from the equation? > > ssh -a -i $HOME/.ssh/Your_SSH_Key user@host Yes, thanks. allan gottlieb@E7450 /local/allan/gottlieb $ ssh -a -i $HOME/.ssh/id_rsa E6430 warning: agent returned different signature type ssh-rsa (expected rsa-sha2-512) You have new mail in folder /var/mail/gottlieb.
Re: [gentoo-user] Re: Slow python execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Am Mo den 25. Jun 2018 um 22:02 schrieb Ian Zimmerman: > > I did some profiling now. > > > Any idea why there is that difference in call time? > > Is it the same upstream version of python? You never really stated this > in the thread. I did profiling with python 2.7 and 3.5. As 3.5 is slightly slower than 2.7, it doesn't matter to much. Also I tried to compare the different function calls between 2.7 and 3.5, but they are the same. So, the output I posted was in fact from 3.5 on Gentoo and 2.7 on Debian but as the difference of 2.7 and 3.5 is just around 5% - 10% I did not mentioned that (apology about that, I even seen my fault here after the post). What I can try is to do them on the same machine. On one of my systems I saved the old debian volume so I could just chroot into the debian tree and do the same over there. But as the results so far are that catastrophically, I think that it will be not that difference overall. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Comment: Charset: ISO-8859-1 iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlsxXaAACgkQpnwKsYAZ 9qx5oAv/QsUsNaGKORsD7l16cVPiJYknkOTo/L9GwKpql3AWGQbZJ89Rk+Nf0id+ ggRN7dd5fAn9IbF6VKSNl87Jp5Gon40q5LBPuVnzK5wSmXoDElqhK85RqE7Zj4Ak DlZJnOJI7q9jC0s1vvji22cNV7dcteQoK/JteVBQ6T1a4m4BRuCtUqjGT6L5lZ1t UgxwBHVIumMyl4HL24bcpvze8sGtXTHHU5d3nrH5rtQ4g2OBy9ycnCtUNhh37R6g IxQ2qHjbPRYpabXLXNG6NvH7mVEKoOdogBECjFFweXyeq9ZsaJwAXSpF18qO9bP/ MQKDZyfGuSZFJeuTb2ifulFM/ptTFDcUPtuJxHrZs4F8fxjf/fG3N6tbU/XMgmx0 E5Bq8SwS/+4G23NAsX0JE236uFarf0fgcGTVisdeR4EHqvUUI5SV7hRgxXmgR9B8 ZUhKpuHfnhs0Xl1Vmq6rapM3xkszwjzl0xClPWNWNdyquTAXhVBNfAAiHBcDk1Cc txKS70sk =H7kt -END PGP SIGNATURE-
Re: [gentoo-user] Problems updating glibc-2.26-r7
On Sat, Jun 23, 2018 at 1:21 PM, wabe wrote: > "Andreas K. Huettel" wrote: > >> Am Freitag, 22. Juni 2018, 20:11:51 CEST schrieb wabe: >> > Hi folks, >> > >> > I have a problem and didn't find a solution yet. >> > >> > Upgrading glibc from 2.25-r11 to 2.26-r7 doesn't work. It says >> > >> > /var/tmp/portage/portage/sys-libs/glibc-2.26-r7/work/build-x86-x86_64-pc-lin >> > ux-gnu-nptl/elf/sln >> > /var/tmp/portage/portage/sys-libs/glibc-2.26-r7/work/build-x86-x86_64-pc-li >> > nux-gnu-nptl/elf/symlink.list >> > /var/tmp/portage/portage/sys-libs/glibc-2.26-r7/work/build-x86-x86_64-pc-li >> > nux-gnu-nptl/elf/sln: >> > /var/tmp/portage/portage/sys-libs/glibc-2.26-r7/work/build-x86-x86_64-pc-li >> > nux-gnu-nptl/elf/sln: cannot execute binary file make[1]: *** >> > [Makefile:106: install-symbolic-link] Error 126 >> > >> > Compiling other packages is no problem. However when I try to >> > reinstall glibc-2.25-r11 it also exits with an similar error at the >> > end: >> >> [...] >> >> You're trying to make a multilib glibc, and your kernel does not >> support one of the resulting ABIs (most likely CONFIG_IA32_EMULATION >> needs to be turned on in the kernel configuration to be able to run >> x86 binaries on an amd64 install). >> >> (That said, this is a rather stupid bug in the glibc build system and >> needs to be fixed eventually.) > > Thank you very much for your answer. > > You are right. Compiling the kernel with CONFIG_IA32_EMULATION solved > the problem. I switched from hardened kernel to gentoo standard kernel > some time ago and just forget to compile it with that option. > > IIRC I build a multilib system many years ago because of grub. But maybe > I don't need multilib anymore. How can I find out if I have x86 binaries > installed? This should give you a good start: scanelf -M 32 /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin /opt
[gentoo-user] Re: Slow python execution
On 2018-06-25 20:37, Klaus Ethgen wrote: > I did some profiling now. > Any idea why there is that difference in call time? Is it the same upstream version of python? You never really stated this in the thread. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Slow python execution
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I did some profiling now.
`ansible-doc -l` that runs on debian under 10 seconds, need around 60
seconds on Gentoo.
The top most stuff on Gentoo is:
ncalls tottime percall cumtime percall filename:lineno(function)
384/10.0200.000 81.471 81.471 {built-in method builtins.exec}
10.0000.000 81.471 81.471 ansible-doc:11()
10.0000.000 81.463 81.463 :21()
10.0010.001 79.903 79.903 doc.py:85(run)
10.0940.094 79.628 79.628
doc.py:239(get_plugin_list_text)
16520.4140.000 79.1500.048
plugin_docs.py:111(get_docstring)
28660.0100.000 74.7840.026
constructor.py:33(get_single_data)
28660.0150.000 71.2400.025 composer.py:29(get_single_node)
28660.0110.000 70.7630.025
composer.py:50(compose_document)
261720/28661.2040.000 70.7220.025 composer.py:63(compose_node)
30138/28660.5360.000 70.3240.025
composer.py:117(compose_mapping_node)
8492691.2390.000 66.6180.000 parser.py:94(check_event)
21293303.3420.000 56.5050.000 scanner.py:113(check_token)
16520.2650.000 50.2780.030
plugin_docs.py:22(read_docstring)
3659031.7500.000 45.4700.000
scanner.py:153(fetch_more_tokens)
36013/360100.3490.000 35.2740.001
composer.py:99(compose_sequence_node)
1742380.4000.000 30.8470.000 scanner.py:665(fetch_plain)
1742387.9000.000 29.0590.000 scanner.py:1266(scan_plain)
16520.0990.000 28.4580.017
plugin_docs.py:61(add_fragments)
631080.2740.000 27.1820.000
parser.py:381(parse_block_sequence_entry)
260430.0680.000 18.6670.001
parser.py:376(parse_block_sequence_first_entry)
1006630.3540.000 17.3800.000
parser.py:446(parse_block_mapping_value)
1304060.5180.000 13.1480.000
parser.py:427(parse_block_mapping_key)
2910923 10.5250.000 10.9340.000 reader.py:99(forward)
2617082.2370.000 10.5980.000 parser.py:273(parse_node)
34137354.1020.0009.3270.000
scanner.py:142(need_more_tokens)
6850373.3540.0008.9330.000
scanner.py:1313(scan_plain_spaces)
2013140.2430.0008.6600.000
parser.py:270(parse_block_node_or_indentless_sequence)
126696955.8000.0005.8010.000 reader.py:87(peek)
3659031.6850.0004.8730.000
scanner.py:749(scan_to_next_token)
35000354.6060.0004.6060.000
scanner.py:276(stale_possible_simple_keys)
14828212.6200.0004.0960.000 reader.py:114(get_mark)
16540.0060.0003.9300.002 ast.py:30(parse)
16573.9250.0023.9260.002 {built-in method
builtins.compile}
95490.0390.0003.6530.000
parser.py:402(parse_indentless_sequence_entry)
28660.1050.0003.5350.001
constructor.py:40(construct_document)
5815380.9510.0002.9280.000 scanner.py:132(get_token)
17519572.4950.0002.8020.000 reader.py:94(prefix)
209510.0500.0002.5590.000
scanner.py:654(fetch_flow_scalar)
59190/324600.1030.0002.4810.000
constructor.py:46(construct_yaml_map)
198160.0910.0002.3900.000
parser.py:476(parse_flow_sequence_entry)
209510.2740.0002.3660.000
scanner.py:1131(scan_flow_scalar)
2617200.8380.0002.3580.000
constructor.py:53(construct_object)
295950.3600.0002.3260.000
constructor.py:53(construct_mapping)
1011970.8110.0002.0630.000 scanner.py:542(fetch_value)
297430.0600.0001.9660.000
parser.py:422(parse_block_mapping_first_key)
1955690.7970.0001.9160.000
composer.py:88(compose_scalar_node)
110240.0100.0001.9130.000 scanner.py:651(fetch_double)
461070.0640.0001.7500.000 parser.py:264(parse_block_node)
5399580.7320.0001.7360.000
scanner.py:1418(scan_line_break)
While the top most costy calls on debian are:
ncalls tottime percall cumtime percall filename:lineno(function)
10.0020.0027.8817.881 ansible-doc:21()
10.0000.0007.3787.378 doc.py:85(run)
10.0500.0507.2447.244
doc.py:239(get_plugin_list_text)
16520.1930.0007.0260.004
plugin_docs.py:111(get_docstring)
16520.0830.0005.5890.003
plugin_docs.py:22(read_docstring)
28660.0050.0003.5030.001
constructor.py:35(get_single_data)
16540.003
Re: [gentoo-user] Re: gcc failed to compile, mpfr-4 compiled successfully...
On 06/25 12:33, Nikos Chantziaras wrote: > On 25/06/18 09:37, Arve Barsnes wrote: > > On 25 June 2018 at 04:19, wrote: > > > I think, my attempt to play with words despite the fact that I am no > > > native speaker ;) has spent some confusion (or I understand something > > > wrong right now: > > > > > > In my make,conf this is set > > > > > > ACCEPT_KEYWORDS="~amd64" > > > > > > so I am on unstable. > > > > The actual error, in case anyone knows the fix: > > > > /var/tmp/portage/sys-devel/gcc-7.3.0-r3/work/gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:157:10: > > fatal error: sys/ustat.h: No such file or directory > > #include > > > > So maybe rebuild glibc or something? > > Is the file there? It's "/usr/include/sys/ustat.h" and qfile says it's from > glibc: > > $ qfile /usr/include/sys/ustat.h > sys-libs/glibc (/usr/include/sys/ustat.h) > > I'm on glibc-2.27-r4. > > If you can't get rid of the error, it might be worth trying disabling the > "sanitize" USE of gcc. > > Hi Nikos, I am on glibc-(2.2) and the qfile command does not find that file. Before switching off the sanitizer...for it is used? Not that I replace one visible error with a non visible random error, which is even harder to trace down... Cheers Meino
Re: [gentoo-user] warning (different signature type) when doing ssh
On Monday, 25 June 2018 10:19:07 BST Marc Joliet wrote: > Am Montag, 25. Juni 2018, 03:10:57 CEST schrieb allan gottlieb: > > I have two laptops call them A and B both running gentoo. > > I recently did on each an emerge --sync after a long absence. > > > > The large emerge --update @world's finally finished on each machine. One > > new behavior is that > > > > If I use the console to log into A and then ssh to B, I get > > > > warning: agent returned different signature type ssh-rsa (expected > > rsa-sha2-512) > > > > If I use the console to log into B and then ssh to A, > > I get the same warning. > > > > I see no ill effects. > > > > Need I take any action? > > > > thanks in advance, > > allan > > I saw the same, but it was temporary. I use gpg-agent instead of ssh-agent, > so I assumed it had to do with that, and then the warning disappeared after > upgrading gnupg, but perhaps that was just a coincidence? This warning message is generated when you are using gpg-agent as ssh-agent and there is a mismatch on the ciphers between the two - i.e. when gpg-agent can't/won't use the ciphers expected by sshd. Do you get the same warning when you exclude the agent from the equation? ssh -a -i $HOME/.ssh/Your_SSH_Key user@host -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: gcc failed to compile, mpfr-4 compiled successfully...
On 25/06/18 09:37, Arve Barsnes wrote: On 25 June 2018 at 04:19, wrote: I think, my attempt to play with words despite the fact that I am no native speaker ;) has spent some confusion (or I understand something wrong right now: In my make,conf this is set ACCEPT_KEYWORDS="~amd64" so I am on unstable. The actual error, in case anyone knows the fix: /var/tmp/portage/sys-devel/gcc-7.3.0-r3/work/gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:157:10: fatal error: sys/ustat.h: No such file or directory #include So maybe rebuild glibc or something? Is the file there? It's "/usr/include/sys/ustat.h" and qfile says it's from glibc: $ qfile /usr/include/sys/ustat.h sys-libs/glibc (/usr/include/sys/ustat.h) I'm on glibc-2.27-r4. If you can't get rid of the error, it might be worth trying disabling the "sanitize" USE of gcc.
Re: [gentoo-user] warning (different signature type) when doing ssh
Am Montag, 25. Juni 2018, 03:10:57 CEST schrieb allan gottlieb: > I have two laptops call them A and B both running gentoo. > I recently did on each an emerge --sync after a long absence. > > The large emerge --update @world's finally finished on each machine. One > new behavior is that > > If I use the console to log into A and then ssh to B, I get > > warning: agent returned different signature type ssh-rsa (expected > rsa-sha2-512) > > If I use the console to log into B and then ssh to A, > I get the same warning. > > I see no ill effects. > > Need I take any action? > > thanks in advance, > allan I saw the same, but it was temporary. I use gpg-agent instead of ssh-agent, so I assumed it had to do with that, and then the warning disappeared after upgrading gnupg, but perhaps that was just a coincidence? -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] gcc failed to compile, mpfr-4 compiled successfully...
On Sunday, 24 June 2018 19:49:02 BST Rich Freeman wrote: > On Sun, Jun 24, 2018 at 2:28 PM wrote: > > Since the unstable packages of today are the stable packages of > > tommorrow one needs to bite the bullet (and hopefully this sentence > > is not complete nonsense...I am no native speaker...not at all!) > > Presumably if you're running stable on a host you probably wouldn't > want to be biting the bullet on that particular host. > > In any case, it seems likely that the news item shouldn't have been > displayed to stable users, or should have had instructions pertaining > to who it was targeted at. Well, on my stable system I went and keyworded mpfr-4.0.1 and mpc-1.1.0-r1, then followed the instructions. I did that because I didn't want to find, later, that I'd been left behind by those versions becoming stable and not remembering the news item. I saw a good chance of inexplicable failures in that case. > Of course, it shouldn't have been displayed for anybody considering it > was never reviewed as required by GLEP 42. Stuff like this is the > reason these are supposed to be reviewed... I'll leave those concerned to wrestle with that one...;) -- Regards, Peter.
Re: [gentoo-user] gcc failed to compile, mpfr-4 compiled successfully...
On 25 June 2018 at 04:19, wrote: > I think, my attempt to play with words despite the fact that I am no > native speaker ;) has spent some confusion (or I understand something > wrong right now: > > In my make,conf this is set > > ACCEPT_KEYWORDS="~amd64" > > so I am on unstable. The actual error, in case anyone knows the fix: /var/tmp/portage/sys-devel/gcc-7.3.0-r3/work/gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:157:10: fatal error: sys/ustat.h: No such file or directory #include So maybe rebuild glibc or something? Cheers, Arve
