[gentoo-user] adobe flash
I have a couple of systems with flash that are always a pain to update because the checksums fail so you have to manually force a manifest rebuild first. As I have to update them anyway, is there a ways to override the portage checksums and say install anyway? Because this package always fails anyway, I cant see any security gain by having a manual update every-time anyway. BillK
Re: [gentoo-user] adobe flash
On Tuesday, July 22, 2014 05:05:43 PM Bill Kenworthy wrote: I have a couple of systems with flash that are always a pain to update because the checksums fail so you have to manually force a manifest rebuild first. As I have to update them anyway, is there a ways to override the portage checksums and say install anyway? Because this package always fails anyway, I cant see any security gain by having a manual update every-time anyway. I would be more interested in finding out why it fails? I use adobe flash myself and never experience a checksum issue with it. -- Joost
Re: [gentoo-user] adobe flash
On Tue, 22 Jul 2014 17:05:43 +0800, Bill Kenworthy wrote: I have a couple of systems with flash that are always a pain to update because the checksums fail so you have to manually force a manifest rebuild first. As I have to update them anyway, is there a ways to override the portage checksums and say install anyway? Because this package always fails anyway, I cant see any security gain by having a manual update every-time anyway. It looks like FEATURES=digests will do what you want, but don't enable it globally. man make.conf for more info. -- Neil Bothwick Most problems go away if you just wait long enough. It might look like I'm standing motionless but I'm actively waiting for our problems to go away. I don't know why this works but it does. Scott Adams, Dilbert comic signature.asc Description: PGP signature
Re: [gentoo-user] adobe flash
J. Roeleveld wrote: On Tuesday, July 22, 2014 05:05:43 PM Bill Kenworthy wrote: I have a couple of systems with flash that are always a pain to update because the checksums fail so you have to manually force a manifest rebuild first. As I have to update them anyway, is there a ways to override the portage checksums and say install anyway? Because this package always fails anyway, I cant see any security gain by having a manual update every-time anyway. I would be more interested in finding out why it fails? I use adobe flash myself and never experience a checksum issue with it. -- Joost . Same here. I have it installed here and don't recall ever having a digest issue. It could be that something is off somewhere. If so, I'd rethink bypassing the checks. Dale :-) :-)
Re: [gentoo-user] adobe flash
On 22/07/14 19:03, Dale wrote: J. Roeleveld wrote: On Tuesday, July 22, 2014 05:05:43 PM Bill Kenworthy wrote: I have a couple of systems with flash that are always a pain to update because the checksums fail so you have to manually force a manifest rebuild first. As I have to update them anyway, is there a ways to override the portage checksums and say install anyway? Because this package always fails anyway, I cant see any security gain by having a manual update every-time anyway. I would be more interested in finding out why it fails? I use adobe flash myself and never experience a checksum issue with it. -- Joost . Same here. I have it installed here and don't recall ever having a digest issue. It could be that something is off somewhere. If so, I'd rethink bypassing the checks. Dale :-) :-) Hmm, that's interesting. Caused me to look closer ... I am pulling from http-replicator which doesnt update the package if it cant see a name change (and adobe don't change the name on the package - just the directory its pulled from) so of course it fails checksum. Thanks for the hints to track this down. BillK
Re: [gentoo-user] adobe flash
On Tuesday, July 22, 2014 07:31:35 PM Bill Kenworthy wrote: On 22/07/14 19:03, Dale wrote: J. Roeleveld wrote: On Tuesday, July 22, 2014 05:05:43 PM Bill Kenworthy wrote: I have a couple of systems with flash that are always a pain to update because the checksums fail so you have to manually force a manifest rebuild first. As I have to update them anyway, is there a ways to override the portage checksums and say install anyway? Because this package always fails anyway, I cant see any security gain by having a manual update every-time anyway. I would be more interested in finding out why it fails? I use adobe flash myself and never experience a checksum issue with it. -- Joost . Same here. I have it installed here and don't recall ever having a digest issue. It could be that something is off somewhere. If so, I'd rethink bypassing the checks. Dale :-) :-) Hmm, that's interesting. Caused me to look closer ... I am pulling from http-replicator which doesnt update the package if it cant see a name change (and adobe don't change the name on the package - just the directory its pulled from) so of course it fails checksum. Thanks for the hints to track this down. Sounds like you might have been running a very old version without realising? I personally would consider it a bug in http-replicator that it doesn't take the actual location or filedate into account. -- Joost
Re: [gentoo-user] adobe flash
Bill Kenworthy wrote: On 22/07/14 19:03, Dale wrote: J. Roeleveld wrote: On Tuesday, July 22, 2014 05:05:43 PM Bill Kenworthy wrote: I have a couple of systems with flash that are always a pain to update because the checksums fail so you have to manually force a manifest rebuild first. As I have to update them anyway, is there a ways to override the portage checksums and say install anyway? Because this package always fails anyway, I cant see any security gain by having a manual update every-time anyway. I would be more interested in finding out why it fails? I use adobe flash myself and never experience a checksum issue with it. -- Joost . Same here. I have it installed here and don't recall ever having a digest issue. It could be that something is off somewhere. If so, I'd rethink bypassing the checks. Dale :-) :-) Hmm, that's interesting. Caused me to look closer ... I am pulling from http-replicator which doesnt update the package if it cant see a name change (and adobe don't change the name on the package - just the directory its pulled from) so of course it fails checksum. Thanks for the hints to track this down. BillK Welcome. I wonder if http-replicator needs to check more than the name? I use it at times when I have more than one rig running and sounds like maybe it needs a new feature. Dale :-) :-)
Re: [gentoo-user] adobe flash
On 22/07/14 19:48, Dale wrote: Bill Kenworthy wrote: On 22/07/14 19:03, Dale wrote: J. Roeleveld wrote: On Tuesday, July 22, 2014 05:05:43 PM Bill Kenworthy wrote: I have a couple of systems with flash that are always a pain to update because the checksums fail so you have to manually force a manifest rebuild first. As I have to update them anyway, is there a ways to override the portage checksums and say install anyway? Because this package always fails anyway, I cant see any security gain by having a manual update every-time anyway. I would be more interested in finding out why it fails? I use adobe flash myself and never experience a checksum issue with it. -- Joost . Same here. I have it installed here and don't recall ever having a digest issue. It could be that something is off somewhere. If so, I'd rethink bypassing the checks. Dale :-) :-) Hmm, that's interesting. Caused me to look closer ... I am pulling from http-replicator which doesnt update the package if it cant see a name change (and adobe don't change the name on the package - just the directory its pulled from) so of course it fails checksum. Thanks for the hints to track this down. BillK Welcome. I wonder if http-replicator needs to check more than the name? I use it at times when I have more than one rig running and sounds like maybe it needs a new feature. Dale :-) :-) The saving grace is that I have only seen the behaviour with this one package so its something easily dealt with - now I know. Plus flash is dieing so I might be able to do away with it before much longer - unfortunately the OSS packages just are not as good. I've used http-replicator for distfiles since it came out in ~2004 and its always just worked. Oh well ... BillK
[gentoo-user] glibc (and gcc) build fails: /bin/sh: /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/cross-rpcgen: No such file or directory
Not sure what relevant information to provide. My system works and I can compile other ebuilds normally, except, it seems, gcc and glibc. Searching for the error in the tile doesn't give me much - what it does give me doesn't seem to apply to my instance of the error, or at least what I know about it (patches, etc). A common solution is to switch to a non-multilib profile, but I need multilib. I am using the hardened profile with selinux, but it doesn't seem to be an issue with either of those (it's usually pretty obvious if it is). `MAKEOPTS=-j1 emerge glibc`: x86_64-pc-linux-gnu-gcc -m32 rpcgen.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-stack-protector -fno-strict-aliasing -frounding-math -pipe -Wstrict-prototypes -Wa,-mtune=i686-U_FORTIFY_SOURCE -DPIC -DPIC -DPIC -D_RPC_THREAD_SAFE_ -I../include -I/var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc -I/var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/i386/nptl -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu/multiarch -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686/multiarch -I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/x86/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/x86 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib32/include -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1-D_RPC_THREAD_SAFE_ -o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o x86_64-pc-linux-gnu-gcc -m32 -pie -Wl,-O1 -nostdlib -nostartfiles -o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen -Wl,-dynamic-linker=/lib32/ld-linux.so.2 -Wl,-O1 -Wl,--as-needed -Wl,-z,combreloc -Wl,-z,relro /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/Scrt1.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/crti.o `x86_64-pc-linux-gnu-gcc -m32 --print-file-name=crtbeginS.o` /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_main.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_hout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_cout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_parse.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_scan.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_util.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_svcout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_clntout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_tblout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_sample.o
Re: [gentoo-user] glibc (and gcc) build fails: /bin/sh: /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/cross-rpcgen: No such file or directory
I've had some problems with this in the past on non-hardened... you have IA32 emulation turned on in the kernel right? Also, not sure if this is just me, but the really long lines (like the top 4) run off the end of my screen and I can't see them at all. Alec On Tue 22 Jul 2014 09:48:54 AM EDT, Sid S wrote: Not sure what relevant information to provide. My system works and I can compile other ebuilds normally, except, it seems, gcc and glibc. Searching for the error in the tile doesn't give me much - what it does give me doesn't seem to apply to my instance of the error, or at least what I know about it (patches, etc). A common solution is to switch to a non-multilib profile, but I need multilib. I am using the hardened profile with selinux, but it doesn't seem to be an issue with either of those (it's usually pretty obvious if it is). `MAKEOPTS=-j1 emerge glibc`: x86_64-pc-linux-gnu-gcc -m32 rpcgen.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-stack-protector -fno-strict-aliasing -frounding-math -pipe -Wstrict-prototypes -Wa,-mtune=i686-U_FORTIFY_SOURCE -DPIC -DPIC -DPIC -D_RPC_THREAD_SAFE_ -I../include -I/var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc -I/var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/i386/nptl -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv - I ../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu/multiarch -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686/multiarch -I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/x86/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/x86 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib32/include -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1-D_RPC_THREAD_SAFE_ -o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o -MD -MP -MF /var/tmp/portage/sys-libs/gl i bc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o x86_64-pc-linux-gnu-gcc -m32 -pie -Wl,-O1 -nostdlib -nostartfiles -o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen -Wl,-dynamic-linker=/lib32/ld-linux.so.2 -Wl,-O1 -Wl,--as-needed -Wl,-z,combreloc -Wl,-z,relro /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/Scrt1.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/crti.o `x86_64-pc-linux-gnu-gcc -m32 --print-file-name=crtbeginS.o` /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_main.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_hout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_cout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_parse.o /var/tmp/portage/sys-libs / glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_scan.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_util.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_svcout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_clntout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_tblout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_sample.o
Re: [gentoo-user] glibc (and gcc) build fails: /bin/sh: /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/cross-rpcgen: No such file or directory
I have IA32 emulation enabled but none of its suboptions (I read I don't need them). Sorry about the lines running off, my client does not auto-wrap with newlines and it seems yours does not either. . On Tue, Jul 22, 2014 at 8:58 AM, Alec Ten Harmsel a...@alectenharmsel.com wrote: I've had some problems with this in the past on non-hardened... you have IA32 emulation turned on in the kernel right? Also, not sure if this is just me, but the really long lines (like the top 4) run off the end of my screen and I can't see them at all. Alec On Tue 22 Jul 2014 09:48:54 AM EDT, Sid S wrote: Not sure what relevant information to provide. My system works and I can compile other ebuilds normally, except, it seems, gcc and glibc. Searching for the error in the tile doesn't give me much - what it does give me doesn't seem to apply to my instance of the error, or at least what I know about it (patches, etc). A common solution is to switch to a non-multilib profile, but I need multilib. I am using the hardened profile with selinux, but it doesn't seem to be an issue with either of those (it's usually pretty obvious if it is). `MAKEOPTS=-j1 emerge glibc`: x86_64-pc-linux-gnu-gcc -m32 rpcgen.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-stack-protector -fno-strict-aliasing -frounding-math -pipe -Wstrict-prototypes -Wa,-mtune=i686-U_FORTIFY_SOURCE -DPIC -DPIC -DPIC -D_RPC_THREAD_SAFE_ -I../include -I/var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc -I/var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/i386/nptl -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv - I ../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu/multiarch -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686/multiarch -I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/x86/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/x86 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib32/include -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -D_RPC_THREAD_SAFE_ -o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o -MD -MP -MF /var/tmp/portage/sys-libs/gl i bc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o x86_64-pc-linux-gnu-gcc -m32 -pie -Wl,-O1 -nostdlib -nostartfiles -o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen -Wl,-dynamic-linker=/lib32/ld-linux.so.2 -Wl,-O1 -Wl,--as-needed -Wl,-z,combreloc -Wl,-z,relro /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/Scrt1.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/crti.o `x86_64-pc-linux-gnu-gcc -m32 --print-file-name=crtbeginS.o` /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_main.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_hout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_cout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_parse.o /var/tmp/portage/sys-libs / glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_scan.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_util.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_svcout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_clntout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_tblout.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_sample.o
Re: [gentoo-user] glibc (and gcc) build fails: /bin/sh: /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/cross-rpcgen: No such file or directory
Yeah, Thunderbird doesn't handle long lines well, I guess. Hmmm... I have no experience with Gentoo Hardened, but the file that caused failure due to not existing, 'cross-rpcgen', is created by gcc the step immediately before without error. There really shouldn't be a problem. Are you in the process of switching to hardened right now? Why are you rebuilding glibc and gcc? I'm not sure I'll be able to help, but getting a bit more background might shed some light on something. Alec On Tue 22 Jul 2014 10:50:20 AM EDT, Sid S wrote: I have IA32 emulation enabled but none of its suboptions (I read I don't need them). Sorry about the lines running off, my client does not auto-wrap with newlines and it seems yours does not either. . On Tue, Jul 22, 2014 at 8:58 AM, Alec Ten Harmsel a...@alectenharmsel.com mailto:a...@alectenharmsel.com wrote: I've had some problems with this in the past on non-hardened... you have IA32 emulation turned on in the kernel right? Also, not sure if this is just me, but the really long lines (like the top 4) run off the end of my screen and I can't see them at all. Alec On Tue 22 Jul 2014 09:48:54 AM EDT, Sid S wrote: Not sure what relevant information to provide. My system works and I can compile other ebuilds normally, except, it seems, gcc and glibc. Searching for the error in the tile doesn't give me much - what it does give me doesn't seem to apply to my instance of the error, or at least what I know about it (patches, etc). A common solution is to switch to a non-multilib profile, but I need multilib. I am using the hardened profile with selinux, but it doesn't seem to be an issue with either of those (it's usually pretty obvious if it is). `MAKEOPTS=-j1 emerge glibc`: x86_64-pc-linux-gnu-gcc -m32 rpcgen.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-stack-protector -fno-strict-aliasing -frounding-math -pipe -Wstrict-prototypes -Wa,-mtune=i686 -U_FORTIFY_SOURCE -DPIC -DPIC -DPIC -D_RPC_THREAD_SAFE_ -I../include -I/var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc -I/var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/i386/nptl -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv - I ../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu/multiarch -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686/multiarch -I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/x86/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/x86 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib32/include -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1-D_RPC_THREAD_SAFE_ -o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o -MD -MP -MF /var/tmp/portage/sys-libs/gl i bc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o x86_64-pc-linux-gnu-gcc -m32 -pie -Wl,-O1 -nostdlib -nostartfiles -o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen -Wl,-dynamic-linker=/lib32/ld-linux.so.2 -Wl,-O1 -Wl,--as-needed -Wl,-z,combreloc -Wl,-z,relro /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/Scrt1.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/crti.o `x86_64-pc-linux-gnu-gcc -m32 --print-file-name=crtbeginS.o` /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen.o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpc_main.o
Re: [gentoo-user] glibc (and gcc) build fails: /bin/sh: /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/cross-rpcgen: No such file or directory
On Tue, 22 July 2014, at 2:48 pm, Sid S r03...@gmail.com wrote: ... The build log is kind of large, tell me if the whole thing is needed. The file you sent would have been half the size, if you'll excuse me nagging, if you'd sent it in plaintext, rather than HTML. Stroller.
Re: [gentoo-user] glibc (and gcc) build fails: /bin/sh: /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/cross-rpcgen: No such file or directory
Are you in the process of switching to hardened right now? Why are you rebuilding glibc and gcc? No, I set up my system as hardened. They originally got rebuilt (and I noticed the failure) when I set up a package set for running some games (using the steam client) and rebuilt the package set. They are the packages listed here: http://wiki.gentoo.org/wiki/Steam. The file you sent would have been half the size, if you'll excuse me nagging, if you'd sent it in plaintext, rather than HTML. Did something strange happen? I figured the code blocks would just be surrounded by styling tags. Sorry about that. On Tue, Jul 22, 2014 at 10:36 AM, Stroller strol...@stellar.eclipse.co.uk wrote: On Tue, 22 July 2014, at 2:48 pm, Sid S r03...@gmail.com wrote: ... The build log is kind of large, tell me if the whole thing is needed. The file you sent would have been half the size, if you'll excuse me nagging, if you'd sent it in plaintext, rather than HTML. Stroller.
Re: [gentoo-user] glibc (and gcc) build fails: /bin/sh: /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/cross-rpcgen: No such file or directory
Wow, running Steam on Hardened. Seems ambitious. I'll try and help as much as possible. Can you: 1. Reply with a list of actions/commands you did that led up to this point 2. Attach the full build log Also They originally got rebuilt (and I noticed the failure) Do you mean I tried to install @steam and it failed once it got to glibc, or were you running with --keep-going and figured it out in hindsight? Did you do a deep update before doing all of this? I've only been running Gentoo for a couple of years, so sorry for asking all these questions. Most of the time a build fails on my machine it's because I've done something really, really stupid, so just don't want to make the mistake of diving in way too deep and then figuring out it was a simple issue. Alec On Tue 22 Jul 2014 12:15:08 PM EDT, Sid S wrote: Are you in the process of switching to hardened right now? Why are you rebuilding glibc and gcc? No, I set up my system as hardened. They originally got rebuilt (and I noticed the failure) when I set up a package set for running some games (using the steam client) and rebuilt the package set. They are the packages listed here: http://wiki.gentoo.org/wiki/Steam. The file you sent would have been half the size, if you'll excuse me nagging, if you'd sent it in plaintext, rather than HTML. Did something strange happen? I figured the code blocks would just be surrounded by styling tags. Sorry about that. On Tue, Jul 22, 2014 at 10:36 AM, Stroller strol...@stellar.eclipse.co.uk mailto:strol...@stellar.eclipse.co.uk wrote: On Tue, 22 July 2014, at 2:48 pm, Sid S r03...@gmail.com mailto:r03...@gmail.com wrote: ... The build log is kind of large, tell me if the whole thing is needed. The file you sent would have been half the size, if you'll excuse me nagging, if you'd sent it in plaintext, rather than HTML. Stroller.
