[gentoo-user] Good news for once...
I guess I should mention that after the revdep rebuild and a kernel bump, everything's back, including steam. Anomalies noted: I think my memory gremlin is back, init took a dump and I had to reboot the machine, it wasn't scheduling the processeses I needed it to and it wouldn't clean up a zombie chromium. I had to unmerge a handful of much beloved packages to get emerge --depclean to work, even more pain to get most things back installed but I got my mast pointed at the sky again and my keel under me. I had to mask libcdio, it's never going to work on this machine -- ever. I'm now on 4.5.18... Since I manually downloaded portage won't uninstall it for me... (grumble grumble). The last package fail takes a bit of explaining Many long years ago I spent way too much money on this box that makes noise when sent bytes... U can hook it up by MIDI or ordinary serial port... It has a mess of chips in it that can be programmed with a "sound font" or (an instrument wavetable) and then will play notes when bytes come down the wire. So basically ur midi player just reads a MIDI file, then tacks on the address of the chip you want to use to play it... (you can play as many sets of notes as you like until you run out of chips to address), and then sends it to the kernel level driver... Now the kernel level driver is buggy as hell and the buffer code is an absolute atrocity, I've worked on it myself, -- it's the wrongest code I ever did see, so when you run two different instances of the midi player against two different chip addresses, the notes get jumbled together because the buffer code is BROKEN. I don't really use this rig much anymore but I like to keep it in working order. =\ So, naturally, nobody's maintaining playmidi anymore so it barfs # Now creating playmidi.h with your defaults...Done. make -j 8 -j1 CC=x86_64-pc-linux-gnu-gcc 'CFLAGS=-march=native -pipe -O3 ' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed' depend clean for i in *.c; do x86_64-pc-linux-gnu-gcc -E -M -march=native -pipe -O3 -I/usr/include/ncurses -I/usr/include -DNARROWPROTO -I/usr/include -DVOXWARE_CONTROLLER_7_WORKING -I. $i; done >.depend io_gtk.c:19:10: fatal error: gtk/gtk.h: No such file or directory #include ^~~ compilation terminated. io_svgalib.c:17:10: fatal error: vga.h: No such file or directory #include ^~~ compilation terminated. rm -f *.o playmidi splaymidi xplaymidi a.out toy seq2mid beat That's the only broken thing on my system right now. -- Please report bounces from this address to a...@numentics.com Powers are not rights.
Re: [gentoo-user] Layout problem in latest KDE apps
I'm not an expert on KDE internals, but I would guess that it's either a problem with the theme or the rendering of the theme. The easier one to test is the former - perhaps emerge kde-plasma/breeze, select the breeze theme from KDE control panel and log out / back in again. If that doesn't work, I'm afraid you've hit the limit of my helpfulness, fwiw. -d On July 31, 2018 03:01:15 Peter Humphrey wrote: On Monday, 30 July 2018 17:11:16 BST Davyd McColl wrote: Those spaces look like where I have icons. Perhaps try changing theme? And change back? Perhaps it's just a theming issue. The icons disappeared at the last update: kde-frameworks, I think it was. I've rebooted several times since then, but the icons haven't reappeared. And the silly spacing has remained. I also had a bunch of KDE updates last night, but I'm not seeing any odd behavior, even after a log out / log back in again. Not sure what versions yours are, but my KDE is stable. Mine too. -- Regards, Peter.
Re: [gentoo-user] Layout problem in latest KDE apps
On Monday, 30 July 2018 17:11:16 BST Davyd McColl wrote: > Those spaces look like where I have icons. Perhaps try changing theme? And > change back? Perhaps it's just a theming issue. The icons disappeared at the last update: kde-frameworks, I think it was. I've rebooted several times since then, but the icons haven't reappeared. And the silly spacing has remained. > I also had a bunch of KDE updates last night, but I'm not seeing any odd > behavior, even after a log out / log back in again. > Not sure what versions yours are, but my KDE is stable. Mine too. -- Regards, Peter.
[gentoo-user] [SOLVED] Please help with `C compiler cannot create executables'
Martin Vaeth writes: > So "normally" the correct solution would be to clean up /usr/local/. > Of course, if you intentionally installed something there, this > might be wrong. But your problem is very likely caused by this. This was indeed the cause, thank you. Further comments made for the reference, in case someone has the same issue. >>> cc1: fatal error: /usr/local/include/stdc-predef.h: Permission denied > > It seems that you have this file but that it is not readable > by user/group portage:portage. There is no such file. I posted the relevant ls output in the original message. > The main question is: Why do you have something in /usr/local/ at all? > If you did not install anything outside of portage, this directory > should be empty (up to some perhaps empty directories). Indeed, I did install something outside of portage. Found no appropriate ebuilds (ebuild repositories included); instead of writing my own, just followed the procedure as described upstream. This was likely a bad idea. Gentoo keeps /usr/local in the list of paths for gcc. If /usr/local is missing something crucial, gcc becomes broken, I guess. In my case, I removed directories and symlinks /usr/local/include /usr/local/lib /usr/local/lib64 /usr/local/share that were all created at the time of outside-portage installation. GCC works fine now. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Please help with `C compiler cannot create executables'
You did do sudo chown -R $(whoami) /usr/local ? On Mon, Jul 30, 2018 at 2:13 PM, Martin Vaeth wrote: > Akater wrote: > > > >> configure:3753: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe > >> -Wl,-O1 -Wl,--as-needed conftest.c >&5 > > This should succeed. So the problem is probably this: > > >> cc1: fatal error: /usr/local/include/stdc-predef.h: Permission denied > > It seems that you have this file but that it is not readable > by user/group portage:portage. > > The main question is: Why do you have something in /usr/local/ at all? > If you did not install anything outside of portage, this directory > should be empty (up to some perhaps empty directories). > > So "normally" the correct solution would be to clean up /usr/local/. > Of course, if you intentionally installed something there, this > might be wrong. But your problem is very likely caused by this. > > >
[gentoo-user] Re: Please help with `C compiler cannot create executables'
Akater wrote: > >> configure:3753: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe >> -Wl,-O1 -Wl,--as-needed conftest.c >&5 This should succeed. So the problem is probably this: >> cc1: fatal error: /usr/local/include/stdc-predef.h: Permission denied It seems that you have this file but that it is not readable by user/group portage:portage. The main question is: Why do you have something in /usr/local/ at all? If you did not install anything outside of portage, this directory should be empty (up to some perhaps empty directories). So "normally" the correct solution would be to clean up /usr/local/. Of course, if you intentionally installed something there, this might be wrong. But your problem is very likely caused by this.
Re: [gentoo-user] Please help with `C compiler cannot create executables'
There are typos/errors in the configure script. From your error log I can
see that -V and -qversion are passed into gcc instead of -v and --version.
Hung
On Mon, Jul 30, 2018 at 1:40 PM Akater wrote:
> This came unexpectedly. An excerpt from compile.log is posted
> below. (I'll post more if necessary of course.) I'm not very experienced
> with C compilers in general and gcc in particular so I hope for some
> directions on what the cause of the issue might be. I tried removing
> CFLAGS settings from make.conf, to no effect.
> (CFLAGS is `-march=native -O2 -pipe')
>
> I upgraded GCC recently; world, kernel rebuilt successfully and gcc had
> been working just fine for some time since then.
>
> I did not do anything particularly weird with the system that could
> cause this. However,
> (1) I do use a somewhat old profile:
> hardened/linux/amd64 (stable).
> (2) I recently had a build conflict with
> util-linux and rfkill: the latter had been included in the former but I
> was not aware of that at the time and updated some packages (don't
> remember which ones) while masking the corresponding util-linux version
> and newer versions. Still, it was a normal portage update and no
> warnings were issued.
> (3) The kernel sources used are non-standard.
>
> A relevant bit from compile.log (the package is sys-apps/file):
>
> > gcc version 7.3.0 (Gentoo Hardened 7.3.0-r3 p1.4)
> > configure:3711: $? = 0
> > configure:3700: x86_64-pc-linux-gnu-gcc -V >&5
> > x86_64-pc-linux-gnu-gcc: error: unrecognized command line option '-V'
> > x86_64-pc-linux-gnu-gcc: fatal error: no input files
> > compilation terminated.
> > configure:3711: $? = 1
> > configure:3700: x86_64-pc-linux-gnu-gcc -qversion >&5
> > x86_64-pc-linux-gnu-gcc: error: unrecognized command line option
> '-qversion'; did you mean '--version'?
> > x86_64-pc-linux-gnu-gcc: fatal error: no input files
> > compilation terminated.
> > configure:3711: $? = 1
> > configure:3731: checking whether the C compiler works
> > configure:3753: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -Wl,-O1
> -Wl,--as-needed conftest.c >&5
> > cc1: fatal error: /usr/local/include/stdc-predef.h: Permission denied
> > compilation terminated.
> > configure:3757: $? = 1
> > configure:3795: result: no
> > configure: failed program was:
> > | /* confdefs.h */
> > | #define PACKAGE_NAME "file"
> > | #define PACKAGE_TARNAME "file"
> > | #define PACKAGE_VERSION "5.33"
> > | #define PACKAGE_STRING "file 5.33"
> > | #define PACKAGE_BUGREPORT "chris...@astron.com"
> > | #define PACKAGE_URL ""
> > | #define PACKAGE "file"
> > | #define VERSION "5.33"
> > | #define BUILTIN_ELF 1
> > | #define ELFCORE 1
> > | /* end confdefs.h. */
> > |
> > | int
> > | main ()
> > | {
> > |
> > | ;
> > | return 0;
> > | }
> > configure:3800: error: in
> `/var/tmp/portage/sys-apps/file-5.33-r4/work/file-5.33-abi_x86_64.amd64':
> > configure:3802: error: C compiler cannot create executables
>
> Note:
>
> > ~ $ sudo ls -la /usr/local/include
> > total 12
> > drwxr-x--- 3 root root 4096 Jul 24 02:12 .
> > drwxr-xr-x 8 root root 4096 Jul 24 02:12 ..
> > drwxr-x--- 2 root root 4096 Jul 24 02:12 ykpers-1
>
> Thank you.
>
[gentoo-user] Please help with `C compiler cannot create executables'
This came unexpectedly. An excerpt from compile.log is posted
below. (I'll post more if necessary of course.) I'm not very experienced
with C compilers in general and gcc in particular so I hope for some
directions on what the cause of the issue might be. I tried removing
CFLAGS settings from make.conf, to no effect.
(CFLAGS is `-march=native -O2 -pipe')
I upgraded GCC recently; world, kernel rebuilt successfully and gcc had
been working just fine for some time since then.
I did not do anything particularly weird with the system that could
cause this. However,
(1) I do use a somewhat old profile:
hardened/linux/amd64 (stable).
(2) I recently had a build conflict with
util-linux and rfkill: the latter had been included in the former but I
was not aware of that at the time and updated some packages (don't
remember which ones) while masking the corresponding util-linux version
and newer versions. Still, it was a normal portage update and no
warnings were issued.
(3) The kernel sources used are non-standard.
A relevant bit from compile.log (the package is sys-apps/file):
> gcc version 7.3.0 (Gentoo Hardened 7.3.0-r3 p1.4)
> configure:3711: $? = 0
> configure:3700: x86_64-pc-linux-gnu-gcc -V >&5
> x86_64-pc-linux-gnu-gcc: error: unrecognized command line option '-V'
> x86_64-pc-linux-gnu-gcc: fatal error: no input files
> compilation terminated.
> configure:3711: $? = 1
> configure:3700: x86_64-pc-linux-gnu-gcc -qversion >&5
> x86_64-pc-linux-gnu-gcc: error: unrecognized command line option '-qversion';
> did you mean '--version'?
> x86_64-pc-linux-gnu-gcc: fatal error: no input files
> compilation terminated.
> configure:3711: $? = 1
> configure:3731: checking whether the C compiler works
> configure:3753: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -Wl,-O1
> -Wl,--as-needed conftest.c >&5
> cc1: fatal error: /usr/local/include/stdc-predef.h: Permission denied
> compilation terminated.
> configure:3757: $? = 1
> configure:3795: result: no
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "file"
> | #define PACKAGE_TARNAME "file"
> | #define PACKAGE_VERSION "5.33"
> | #define PACKAGE_STRING "file 5.33"
> | #define PACKAGE_BUGREPORT "chris...@astron.com"
> | #define PACKAGE_URL ""
> | #define PACKAGE "file"
> | #define VERSION "5.33"
> | #define BUILTIN_ELF 1
> | #define ELFCORE 1
> | /* end confdefs.h. */
> |
> | int
> | main ()
> | {
> |
> | ;
> | return 0;
> | }
> configure:3800: error: in
> `/var/tmp/portage/sys-apps/file-5.33-r4/work/file-5.33-abi_x86_64.amd64':
> configure:3802: error: C compiler cannot create executables
Note:
> ~ $ sudo ls -la /usr/local/include
> total 12
> drwxr-x--- 3 root root 4096 Jul 24 02:12 .
> drwxr-xr-x 8 root root 4096 Jul 24 02:12 ..
> drwxr-x--- 2 root root 4096 Jul 24 02:12 ykpers-1
Thank you.
signature.asc
Description: PGP signature
Re: [gentoo-user] Layout problem in latest KDE apps
Those spaces look like where I have icons. Perhaps try changing theme? And change back? Perhaps it's just a theming issue. I also had a bunch of KDE updates last night, but I'm not seeing any odd behavior, even after a log out / log back in again. Not sure what versions yours are, but my KDE is stable. -d On July 30, 2018 12:18:37 Peter Humphrey wrote: Hello list, My daily update yesterday included 100 kde-apps/* . Now dolphin and konqueror-as-a-file-manager have their panels laid out with extremely wide spacing (example attached). Is this my fault or theirs? -- Regards, Peter.
Re: [gentoo-user] net-misc/openssh-7.7_p1-r4 switched off hpn use flag
On Monday, 30 July 2018 14:07:24 BST Andrew Savchenko wrote: > Hi! > > On Wed, 13 Jun 2018 09:21:45 +0100 Mick wrote: > > Any idea why the latest openssh has set USE="-hpn"? > > > > PS. The multi-threaded AES-CTR is broken and disabled, which is OK, but > > the > > larger buffer used by single threaded HPN can still be useful in some > > cases. > It is enabled in openssh-7.7_p1-r6. > > Sometimes hpn becomes disabled for the latest openssh because hpn > patch is not yet ready. So better stick to older or stable versions > if you need hpn to be always available. > > > Best regards, > Andrew Savchenko I didn't know this, it makes sense. Thanks for letting me know. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] net-misc/openssh-7.7_p1-r4 switched off hpn use flag
Hi! On Wed, 13 Jun 2018 09:21:45 +0100 Mick wrote: > Any idea why the latest openssh has set USE="-hpn"? > > PS. The multi-threaded AES-CTR is broken and disabled, which is OK, but the > larger buffer used by single threaded HPN can still be useful in some cases. It is enabled in openssh-7.7_p1-r6. Sometimes hpn becomes disabled for the latest openssh because hpn patch is not yet ready. So better stick to older or stable versions if you need hpn to be always available. Best regards, Andrew Savchenko pgpwUdv2q2goh.pgp Description: PGP signature
