[gentoo-user] Epic list of total FAIL.

[gentoo-user] Epic list of total FAIL.

[Alan Grimes]

My five year old CPU has been working it's ass off the last few days
doing a full --emptytree world to try to purge the system of the ncurses
clusterfuck.

Here is the list of FAIL. A few of these might be stale listings because
I didn't purge the directory before running this. Also a few of these
might work if I tried it again because a document generator was in
ncurses-fail mode when it attempted to build the relevant package. One
of these, however, was OMFGROTFLMFAO funny... You'll see what I mean
below. What does it say about the state of linux when the compiler is
too broken to compile a bug reporter module? =P

I usually tolerate a moderate failure %-age but these packages are far
too important to the things I need to do to be acceptable. =|

tortoise portage # pwd
/var/tmp/portage
tortoise portage # tree -L 2
.
├── app-arch
│   └── rpm-4.12.0.1
├── app-doc
│   └── doxygen-1.8.10-r1
├── app-office
│   ├── libreoffice-4.4.5.2
│   └── texmacs-1.99.2-r1
├── dev-db
│   └── mysql-workbench-6.3.4
├── dev-dotnet
│   └── nuget-2.8.3
├── dev-java
│   └── antlr-3.1.3-r3
├── dev-libs
│   ├── libcdio-0.93
│   ├── libcdio-paranoia-0.93_p1
│   └── libevdev-1.4.3
├── dev-util
│   ├── kdevplatform-1.7.1
│   └── monodevelop-5.9.5.9
├── kde-apps
│   ├── kdesdk-kioslaves-4.14.3
│   └── libkdcraw-4.14.3
├── media-gfx
│   └── digikam-4.12.0
├── media-libs
│   ├── libkface-4.12.0
│   └── mesa-10.6.3
├── media-sound
│   └── playmidi-2.5-r2
├── media-video
│   └── vcdimager-0.7.24
├── sci-libs
│   └── gdal-2.0.0
└── sys-devel
    └── llvm-3.6.2

36 directories, 0 files
tortoise portage #

#######################################################################

In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/functional:55:0,
                 from
/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/Basic/SourceLocation.h:22,
                 from
/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h:18,
                 from
/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src/tools/clang/lib/StaticAnalyzer/Core/BugReporter.cpp:15:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/tuple: In
constructor ‘constexpr std::tuple<_T1, _T2>::tuple(_U1&&, _U2&&) [with
_U1 = clang::ento::LikelyFalsePositiveSuppressionBRVisitor*; _U2 =
std::default_delete<clang::ento::LikelyFalsePositiveSuppressionBRVisitor>;
<template-parameter-2-3> = void; _T1 = clang::ento::BugReporterVisitor*;
_T2 = std::default_delete<clang::ento::BugReporterVisitor>]’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/tuple:539:19:
internal compiler error: Segmentation fault
         constexpr tuple(_U1&& __a1, _U2&& __a2)
                   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.gentoo.org/> for instructions.
/bin/rm: cannot remove
‘/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src-abi_x86_64.amd64/tools/clang/lib/StaticAnalyzer/Core/Release/BugReporter.d.tmp’:
No such file or directory
/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src/Makefile.rules:1514:
recipe for target
'/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src-abi_x86_64.amd64/tools/clang/lib/StaticAnalyzer/Core/Release/BugReporter.o'
failed
make[5]: ***
[/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src-abi_x86_64.amd64/tools/clang/lib/StaticAnalyzer/Core/Release/BugReporter.o]
Error 1
make[5]: *** Waiting for unfinished jobs....

-- 
IQ is a measure of how stupid you feel.

Powers are not rights.

Re: [gentoo-user] Epic list of total FAIL.

[Alan McKinnon]

Let me describe what I see.

This can't be a clusterfuck, as it is affecting only you. No-one else to
my knowledge is reporting problems caused by ncurses.

So, it is then highly likely that you have a setup that the devs did not
consider, and it is rare (if not unique).

So, what exactly did you do to fuck your system up this badly? Don;t say
"I ran emerge world" as lots of other people do that without issue.
Before that, perhaps long ago, what did YOU do that caused this current
issue?

Ranting on the list might make you feel better, but is not likely to fix
your problem. Just saying.






On 20/08/2015 22:26, Alan Grimes wrote:
> My five year old CPU has been working it's ass off the last few days
> doing a full --emptytree world to try to purge the system of the ncurses
> clusterfuck.
> 
> Here is the list of FAIL. A few of these might be stale listings because
> I didn't purge the directory before running this. Also a few of these
> might work if I tried it again because a document generator was in
> ncurses-fail mode when it attempted to build the relevant package. One
> of these, however, was OMFGROTFLMFAO funny... You'll see what I mean
> below. What does it say about the state of linux when the compiler is
> too broken to compile a bug reporter module? =P
> 
> I usually tolerate a moderate failure %-age but these packages are far
> too important to the things I need to do to be acceptable. =|
> 
> tortoise portage # pwd
> /var/tmp/portage
> tortoise portage # tree -L 2
> .
> ├── app-arch
> │   └── rpm-4.12.0.1
> ├── app-doc
> │   └── doxygen-1.8.10-r1
> ├── app-office
> │   ├── libreoffice-4.4.5.2
> │   └── texmacs-1.99.2-r1
> ├── dev-db
> │   └── mysql-workbench-6.3.4
> ├── dev-dotnet
> │   └── nuget-2.8.3
> ├── dev-java
> │   └── antlr-3.1.3-r3
> ├── dev-libs
> │   ├── libcdio-0.93
> │   ├── libcdio-paranoia-0.93_p1
> │   └── libevdev-1.4.3
> ├── dev-util
> │   ├── kdevplatform-1.7.1
> │   └── monodevelop-5.9.5.9
> ├── kde-apps
> │   ├── kdesdk-kioslaves-4.14.3
> │   └── libkdcraw-4.14.3
> ├── media-gfx
> │   └── digikam-4.12.0
> ├── media-libs
> │   ├── libkface-4.12.0
> │   └── mesa-10.6.3
> ├── media-sound
> │   └── playmidi-2.5-r2
> ├── media-video
> │   └── vcdimager-0.7.24
> ├── sci-libs
> │   └── gdal-2.0.0
> └── sys-devel
>     └── llvm-3.6.2
> 
> 36 directories, 0 files
> tortoise portage #
> 
> #######################################################################
> 
> In file included from
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/functional:55:0,
>                  from
> /var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/Basic/SourceLocation.h:22,
>                  from
> /var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h:18,
>                  from
> /var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src/tools/clang/lib/StaticAnalyzer/Core/BugReporter.cpp:15:
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/tuple: In
> constructor ‘constexpr std::tuple<_T1, _T2>::tuple(_U1&&, _U2&&) [with
> _U1 = clang::ento::LikelyFalsePositiveSuppressionBRVisitor*; _U2 =
> std::default_delete<clang::ento::LikelyFalsePositiveSuppressionBRVisitor>;
> <template-parameter-2-3> = void; _T1 = clang::ento::BugReporterVisitor*;
> _T2 = std::default_delete<clang::ento::BugReporterVisitor>]’:
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/tuple:539:19:
> internal compiler error: Segmentation fault
>          constexpr tuple(_U1&& __a1, _U2&& __a2)
>                    ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <https://bugs.gentoo.org/> for instructions.
> /bin/rm: cannot remove
> ‘/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src-abi_x86_64.amd64/tools/clang/lib/StaticAnalyzer/Core/Release/BugReporter.d.tmp’:
> No such file or directory
> /var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src/Makefile.rules:1514:
> recipe for target
> '/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src-abi_x86_64.amd64/tools/clang/lib/StaticAnalyzer/Core/Release/BugReporter.o'
> failed
> make[5]: ***
> [/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src-abi_x86_64.amd64/tools/clang/lib/StaticAnalyzer/Core/Release/BugReporter.o]
> Error 1
> make[5]: *** Waiting for unfinished jobs....
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: Epic list of total FAIL.

[Grant Edwards]

On 2015-08-20, Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> Let me describe what I see.
>
> This can't be a clusterfuck, as it is affecting only you. No-one else to
> my knowledge is reporting problems caused by ncurses.
>
> So, it is then highly likely that you have a setup that the devs did not
> consider, and it is rare (if not unique).
>
> So, what exactly did you do to fuck your system up this badly? Don;t say
> "I ran emerge world" as lots of other people do that without issue.
> Before that, perhaps long ago, what did YOU do that caused this current
> issue?
>
> Ranting on the list might make you feel better, but is not likely to fix
> your problem. Just saying.

In fact, the more you rant and swear and insult people, the fewer
people are going to pay attention and try to help.

-- 
Grant Edwards               grant.b.edwards        Yow! Are we on STRIKE yet?
                                  at               
                              gmail.com            

Re: [gentoo-user] Epic list of total FAIL.

[Terry Z.]

[-- Attachment #1: Type: text/plain, Size: 4772 bytes --]

Seeing segfaults in a compile like that makes me question your hardware
rather than the gentoo tools.  Are you sure your hardware is in a
functional state?  I update my world fairly often and am running ~amd64 and
have not experienced the issue you are experiencing. :(

On Thu, Aug 20, 2015 at 4:26 PM, Alan Grimes <ALONZOTG@verizon.net> wrote:

> My five year old CPU has been working it's ass off the last few days
> doing a full --emptytree world to try to purge the system of the ncurses
> clusterfuck.
>
> Here is the list of FAIL. A few of these might be stale listings because
> I didn't purge the directory before running this. Also a few of these
> might work if I tried it again because a document generator was in
> ncurses-fail mode when it attempted to build the relevant package. One
> of these, however, was OMFGROTFLMFAO funny... You'll see what I mean
> below. What does it say about the state of linux when the compiler is
> too broken to compile a bug reporter module? =P
>
> I usually tolerate a moderate failure %-age but these packages are far
> too important to the things I need to do to be acceptable. =|
>
> tortoise portage # pwd
> /var/tmp/portage
> tortoise portage # tree -L 2
> .
> ├── app-arch
> │   └── rpm-4.12.0.1
> ├── app-doc
> │   └── doxygen-1.8.10-r1
> ├── app-office
> │   ├── libreoffice-4.4.5.2
> │   └── texmacs-1.99.2-r1
> ├── dev-db
> │   └── mysql-workbench-6.3.4
> ├── dev-dotnet
> │   └── nuget-2.8.3
> ├── dev-java
> │   └── antlr-3.1.3-r3
> ├── dev-libs
> │   ├── libcdio-0.93
> │   ├── libcdio-paranoia-0.93_p1
> │   └── libevdev-1.4.3
> ├── dev-util
> │   ├── kdevplatform-1.7.1
> │   └── monodevelop-5.9.5.9
> ├── kde-apps
> │   ├── kdesdk-kioslaves-4.14.3
> │   └── libkdcraw-4.14.3
> ├── media-gfx
> │   └── digikam-4.12.0
> ├── media-libs
> │   ├── libkface-4.12.0
> │   └── mesa-10.6.3
> ├── media-sound
> │   └── playmidi-2.5-r2
> ├── media-video
> │   └── vcdimager-0.7.24
> ├── sci-libs
> │   └── gdal-2.0.0
> └── sys-devel
>     └── llvm-3.6.2
>
> 36 directories, 0 files
> tortoise portage #
>
> #######################################################################
>
> In file included from
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/functional:55:0,
>                  from
>
> /var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/Basic/SourceLocation.h:22,
>                  from
>
> /var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h:18,
>                  from
>
> /var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src/tools/clang/lib/StaticAnalyzer/Core/BugReporter.cpp:15:
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/tuple: In
> constructor ‘constexpr std::tuple<_T1, _T2>::tuple(_U1&&, _U2&&) [with
> _U1 = clang::ento::LikelyFalsePositiveSuppressionBRVisitor*; _U2 =
> std::default_delete<clang::ento::LikelyFalsePositiveSuppressionBRVisitor>;
> <template-parameter-2-3> = void; _T1 = clang::ento::BugReporterVisitor*;
> _T2 = std::default_delete<clang::ento::BugReporterVisitor>]’:
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/tuple:539:19:
> internal compiler error: Segmentation fault
>          constexpr tuple(_U1&& __a1, _U2&& __a2)
>                    ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <https://bugs.gentoo.org/> for instructions.
> /bin/rm: cannot remove
>
> ‘/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src-abi_x86_64.amd64/tools/clang/lib/StaticAnalyzer/Core/Release/BugReporter.d.tmp’:
> No such file or directory
>
> /var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src/Makefile.rules:1514:
> recipe for target
>
> '/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src-abi_x86_64.amd64/tools/clang/lib/StaticAnalyzer/Core/Release/BugReporter.o'
> failed
> make[5]: ***
>
> [/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src-abi_x86_64.amd64/tools/clang/lib/StaticAnalyzer/Core/Release/BugReporter.o]
> Error 1
> make[5]: *** Waiting for unfinished jobs....
>
> --
> IQ is a measure of how stupid you feel.
>
> Powers are not rights.
>
>
>


-- 
The irony is that Bill Gates claims to be making a stable operating system
and Linus Torvalds claims to be trying to take over the world.
-- seen on the net

[-- Attachment #2: Type: text/html, Size: 5612 bytes --]

Re: [gentoo-user] Epic list of total FAIL.

[Emanuele Rusconi]

On 20 August 2015 at 22:37, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> Ranting on the list might make you feel better, but is not likely to fix
> your problem. Just saying.

Don't worry, in his previous thread, named with the insightful subject
"!!!!", the OP just didn't care to reply after several people chimed
in to help, so I doubt that fixing the problem is what the OP really
wants.

Here is a quote from the other thread, just to set the tone:
> GOOD JOB, PENGUINS!!!
> I won't even be able to reboot my machine!!!
>
> A+ configuration management....

Re: [gentoo-user] Epic list of total FAIL.

[Fernando Rodriguez]

On Thursday, August 20, 2015 4:26:08 PM Alan Grimes wrote:
> My five year old CPU has been working it's ass off the last few days
> doing a full --emptytree world to try to purge the system of the ncurses
> clusterfuck.
> 
> Here is the list of FAIL. A few of these might be stale listings because
> I didn't purge the directory before running this. Also a few of these
> might work if I tried it again because a document generator was in
> ncurses-fail mode when it attempted to build the relevant package. One
> of these, however, was OMFGROTFLMFAO funny... You'll see what I mean
> below. What does it say about the state of linux when the compiler is
> too broken to compile a bug reporter module? =P
> 
> I usually tolerate a moderate failure %-age but these packages are far
> too important to the things I need to do to be acceptable. =|
> 
> tortoise portage # pwd
> /var/tmp/portage
> tortoise portage # tree -L 2
> .
> ├── app-arch
> │   └── rpm-4.12.0.1
> ├── app-doc
> │   └── doxygen-1.8.10-r1
> ├── app-office
> │   ├── libreoffice-4.4.5.2
> │   └── texmacs-1.99.2-r1
> ├── dev-db
> │   └── mysql-workbench-6.3.4
> ├── dev-dotnet
> │   └── nuget-2.8.3
> ├── dev-java
> │   └── antlr-3.1.3-r3
> ├── dev-libs
> │   ├── libcdio-0.93
> │   ├── libcdio-paranoia-0.93_p1
> │   └── libevdev-1.4.3
> ├── dev-util
> │   ├── kdevplatform-1.7.1
> │   └── monodevelop-5.9.5.9
> ├── kde-apps
> │   ├── kdesdk-kioslaves-4.14.3
> │   └── libkdcraw-4.14.3
> ├── media-gfx
> │   └── digikam-4.12.0
> ├── media-libs
> │   ├── libkface-4.12.0
> │   └── mesa-10.6.3
> ├── media-sound
> │   └── playmidi-2.5-r2
> ├── media-video
> │   └── vcdimager-0.7.24
> ├── sci-libs
> │   └── gdal-2.0.0
> └── sys-devel
>     └── llvm-3.6.2
> 
> 36 directories, 0 files
> tortoise portage #
> 
> #######################################################################
> 
> In file included from
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/functional:55:0,
>                  from
> /var/tmp/portage/sys-
devel/llvm-3.6.2/work/llvm-3.6.2.src/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/Basic/SourceLocation.h:22,
>                  from
> /var/tmp/portage/sys-
devel/llvm-3.6.2/work/llvm-3.6.2.src/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h:18,
>                  from
> /var/tmp/portage/sys-
devel/llvm-3.6.2/work/llvm-3.6.2.src/tools/clang/lib/StaticAnalyzer/Core/BugReporter.cpp:15:
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/tuple: In
> constructor ‘constexpr std::tuple<_T1, _T2>::tuple(_U1&&, _U2&&) [with
> _U1 = clang::ento::LikelyFalsePositiveSuppressionBRVisitor*; _U2 =
> std::default_delete<clang::ento::LikelyFalsePositiveSuppressionBRVisitor>;
> <template-parameter-2-3> = void; _T1 = clang::ento::BugReporterVisitor*;
> _T2 = std::default_delete<clang::ento::BugReporterVisitor>]’:
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/tuple:539:19:
> internal compiler error: Segmentation fault
>          constexpr tuple(_U1&& __a1, _U2&& __a2)
>                    ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <https://bugs.gentoo.org/> for instructions.
> /bin/rm: cannot remove
> ‘/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src-
abi_x86_64.amd64/tools/clang/lib/StaticAnalyzer/Core/Release/BugReporter.d.tmp’:
> No such file or directory
> /var/tmp/portage/sys-
devel/llvm-3.6.2/work/llvm-3.6.2.src/Makefile.rules:1514:
> recipe for target
> '/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src-
abi_x86_64.amd64/tools/clang/lib/StaticAnalyzer/Core/Release/BugReporter.o'
> failed
> make[5]: ***
> [/var/tmp/portage/sys-devel/llvm-3.6.2/work/llvm-3.6.2.src-
abi_x86_64.amd64/tools/clang/lib/StaticAnalyzer/Core/Release/BugReporter.o]
> Error 1
> make[5]: *** Waiting for unfinished jobs....

The ncurses ebuild is indeed broken, I ran into the same problem before.

But you received good advice on your last thread (build libtinfo on another 
system and copy it or just try symlinking it to ncurses), if you'd followed it 
you would a got your system back up in a few minutes.

Good luck,

-- 
Fernando Rodriguez

Re: [gentoo-user] Epic list of total FAIL.

[Alan Grimes]

Fernando Rodriguez wrote:
> The ncurses ebuild is indeed broken, I ran into the same problem before.
>
> But you received good advice on your last thread (build libtinfo on another 
> system and copy it or just try symlinking it to ncurses), if you'd followed it 
> you would a got your system back up in a few minutes.

ppl seem to be antsy to hear what I actually did, so I'll respond....

1. I got my grubby mitts on a stage 3 tarball, I always keep one on hand
for this reason. =\

2. I grepped everything in /bin and /lib for tinfo and copied over from
the tarball where necessary.

3. Started --emptytree world.

4. waited.

5. kicked it each time it stopped,

6. kicked it some more.

7. kicked it a few more times.

8, got to the end of the list about two and a half days later (which is
par for my machine.)

9. published the results.

10. rebooted.

-- 
IQ is a measure of how stupid you feel.

Powers are not rights.

Re: [gentoo-user] Epic list of total FAIL.

[wraeth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/08/15 08:31, Alan Grimes wrote:
> Fernando Rodriguez wrote:
>> The ncurses ebuild is indeed broken, I ran into the same problem
>> before.
>> 
>> But you received good advice on your last thread (build libtinfo
>> on another system and copy it or just try symlinking it to
>> ncurses), if you'd followed it you would a got your system back
>> up in a few minutes.
> 
> ppl seem to be antsy to hear what I actually did, so I'll
> respond....

Because we try to avoid flame wars and needless name-calling/swearing
when looking for and providing support to people. Also because we kind
of expect the original poster to respond to queries in a thread that
they started.

> 1. I got my grubby mitts on a stage 3 tarball, I always keep one on
> hand for this reason. =\
> 
> 2. I grepped everything in /bin and /lib for tinfo and copied over
> from the tarball where necessary.

This is kind of dangerous. It would be safer to create/use a binary
package.

- From a running Gentoo system (including a stage3) you can create a
binary package of an installed program by running

  quickpkg <category>/<package>

This will place it in /usr/portage/packages by default (see PKGDIR in
`man make.conf`). This is better than just randomly copying files from
another system. There are also online hosts available that provide
some packages (see my post in your previous thread).

> 3. Started --emptytree world.
> 
> 4. waited.
> 
> 5. kicked it each time it stopped,
> 
> 6. kicked it some more.
> 
> 7. kicked it a few more times.

Emerge's '--keep-going' option may be of use to you here...

> 8, got to the end of the list about two and a half days later
> (which is par for my machine.)
> 
> 9. published the results.
> 
> 10. rebooted.

So what you're saying is that you did an '--emptytree' build for which
there were a number of failures; *one* of which was a segfault; some
of which may not be valid; after arbitrarily copying some files from a
stage3 of unknown age.

Don't get me wrong, providing feedback and letting others know is
good, but unless there's a baseline and/or more is known about what is
going on (see Alan McKinnon's comment about others not getting this
and something about your environment potentially causing this), we
can't do much with it.

More information about your environment, such as an `emerge --info`
and relevant flags/settings for a specific package that is failing
would go a fair way to giving us the information we need (and have
asked for) to be able to help you.

- -- 
wraeth <wraeth@wraeth.id.au>
GnuPG Key: B2D9F759
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXWfM0ACgkQXcRKerLZ91k95wD/U7JAoA8RcjlJZfhEVTaHZZ/a
wUdEi3bSFFQfaNVcZW4A/icPoS+XgpMIRAEnxbilUJwbWZoMsEpkLFK4YtdxjFbH
=alwZ
-----END PGP SIGNATURE-----

Re: [gentoo-user] Epic list of total FAIL.

[Fernando Rodriguez]

On Thursday, August 20, 2015 6:31:48 PM Alan Grimes wrote:
> Fernando Rodriguez wrote:
> > The ncurses ebuild is indeed broken, I ran into the same problem before.
> >
> > But you received good advice on your last thread (build libtinfo on 
another 
> > system and copy it or just try symlinking it to ncurses), if you'd 
followed it 
> > you would a got your system back up in a few minutes.
> 
> ppl seem to be antsy to hear what I actually did, so I'll respond....
> 
> 1. I got my grubby mitts on a stage 3 tarball, I always keep one on hand
> for this reason. =\
>
>
> 2. I grepped everything in /bin and /lib for tinfo and copied over from
> the tarball where necessary.

You can not blindly mix and match files like that, this is likely what broke 
your compiler (if you copied only some gcc related files)! You where advised to 
copy the bash binary, or libtinfo.so (from another system), or symlink it to 
libncurses.so. All good advice but you chose to do something dumb. Now you may 
need to unpack a whole stage3, start over, and wait another 3 days.

 
> 3. Started --emptytree world.
> 
> 4. waited.
> 
> 5. kicked it each time it stopped,
> 
> 6. kicked it some more.
> 
> 7. kicked it a few more times.
> 
> 8, got to the end of the list about two and a half days later (which is
> par for my machine.)
> 
> 9. published the results.
> 
> 10. rebooted.
> 
> 

-- 
Fernando Rodriguez

Re: [gentoo-user] Epic list of total FAIL.

[Alan Grimes]

tortoise ~ # emerge --info
Portage 2.2.20.1 (python 3.4.3-final-0,
default/linux/amd64/13.0/desktop, gcc-4.9.3, glibc-2.21-r1, 4.1.6 x86_64)
=================================================================
System uname:
Linux-4.1.6-x86_64-AMD_Phenom-tm-_II_X6_1090T_Processor-with-gentoo-2.2
KiB Mem:    32877940 total,   3190276 free
KiB Swap:    8000364 total,   8000364 free
Timestamp of repository gentoo: Thu, 20 Aug 2015 21:05:01 +0000
sh bash 4.3_p42
ld GNU ld (Gentoo 2.25.1 p1.0) 2.25.1
app-shells/bash:          4.3_p42::gentoo
dev-java/java-config:     2.2.0::gentoo
dev-lang/perl:            5.22.0::gentoo
dev-lang/python:          2.7.10::gentoo, 3.3.5-r1::gentoo, 3.4.3::gentoo
dev-util/cmake:           3.3.1::gentoo
dev-util/pkgconfig:       0.28-r3::gentoo
sys-apps/baselayout:      2.2::gentoo
sys-apps/openrc:          0.17::gentoo
sys-apps/sandbox:         2.6-r1::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69-r1::gentoo
sys-devel/automake:       1.10.3-r1::gentoo, 1.11.6-r1::gentoo,
1.12.6::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo
sys-devel/binutils:       2.25.1::gentoo
sys-devel/gcc:            4.9.3::gentoo
sys-devel/gcc-config:     1.8::gentoo
sys-devel/libtool:        2.4.6-r1::gentoo
sys-devel/make:           4.1-r1::gentoo
sys-kernel/linux-headers: 4.1::gentoo (virtual/os-headers)
sys-libs/glibc:           2.21-r1::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000

hasufell
    location: /var/lib/layman/hasufell
    masters: gentoo
    priority:
50                                                                                                            

                                                                                                                            

spike-community-overlay                                                                                                     

    location:
/var/lib/layman/spike-community-overlay                                                                       

    masters:
gentoo                                                                                                         

    priority:
50                                                                                                            

                                                                                                                            

steam-overlay                                                                                                               

    location:
/var/lib/layman/steam-overlay                                                                                 

    masters:
gentoo                                                                                                         

    priority:
50                                                                                                            

                                                                                                                            

wichtounet                                                                                                                  

    location:
/var/lib/layman/wichtounet                                                                                    

    masters:
gentoo                                                                                                         

    priority:
50                                                                                                            

                                                                                                                            

ABI="amd64"                                                                                                                 

ABI_X86="64
32"                                                                                                             

ACCEPT_KEYWORDS="amd64
~amd64"                                                                                              

ACCEPT_LICENSE="*"                                                                                                          

ACCEPT_PROPERTIES="*"                                                                                                       

ACCEPT_RESTRICT="*"                                                                                                         

ADA_INCLUDE_PATH="/usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.6/adainclude"                                                   

ADA_OBJECTS_PATH="/usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.6/adalib"                                                       

ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci
emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0
intel8x0m maestro3 trident usb-audio via82xx via82xx-modem
ymfpci"                                                   
ANT_HOME="/usr/share/ant"                                                                                                   

APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias
auth_basic authn_alias authn_anon authn_dbm authn_default authn_file
authz_dbm authz_default authz_groupfile authz_host authz_owner
authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir
disk_cache env expires ext_filter file_cache filter headers include info
log_config logio mem_cache mime mime_magic negotiation rewrite setenvif
speling status unique_id userdir usertrack vhost_alias"
ARCH="amd64"
AUTOCLEAN="yes"
BOOTSTRAP_USE="cxx unicode internal-glib python_targets_python3_4
python_targets_python2_7 multilib"
CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon
braindump author"
CAMERAS="ptp2"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O3 -march=native -pipe "
CFLAGS_amd64="-m64"
CFLAGS_x32="-mx32"
CFLAGS_x86="-m32"
CG_COMPILER_EXE="/opt/bin/cgc"
CG_INC_PATH="/opt/nvidia-cg-toolkit/include"
CG_LIB_PATH="/opt/nvidia-cg-toolkit/lib64:/opt/nvidia-cg-toolkit/lib32"
CHOST="x86_64-pc-linux-gnu"
CHOST_amd64="x86_64-pc-linux-gnu"
CHOST_x32="x86_64-pc-linux-gnux32"
CHOST_x86="i686-pc-linux-gnu"
CLEAN_DELAY="5"
COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog"
COLLISION_IGNORE="/lib/modules/* *.py[co] *$py.class */dropin.cache"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc
/usr/share/config /usr/share/gnupg/qualified.txt
/usr/share/maven-bin-3.2/conf /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d
/etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild
/etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d
/etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CPU_FLAGS_X86="mmx mmxext sse2_4way 3dnow 3dnowext sse sse2 sse3 sse4"
CVS_RSH="ssh"
CXXFLAGS="-O3 -march=native -pipe "
DEFAULT_ABI="amd64"
DISABLED=" "
DISPLAY=":0.1"
DISTDIR="/usr/portage/distfiles"
EDITOR="/bin/nano"
ELIBC="glibc"
EMERGE_DEFAULT_OPTS="--jobs=1 --quiet-build=n --verbose"
EMERGE_WARNING_DELAY="10"
ENABLED=" /var/lib/layman/hasufell /var/lib/layman/steam-overlay "
EPREFIX=""
EROOT="/"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified
distlocks ebuild-locks fixlafiles merge-sync news nostrip parallel-fetch
protect-owned sandbox sfperms splitdebug strict unknown-features-warn
unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FETCHCOMMAND="wget -t 3 -T 60 --passive-ftp -O "${DISTDIR}/${FILE}"
"${URI}""
FETCHCOMMAND_RSYNC="rsync -avP "${URI}" "${DISTDIR}/${FILE}""
FETCHCOMMAND_SFTP="bash -c "x=\${2#sftp://} ; host=\${x%%/*} ;
port=\${host##*:} ; host=\${host%:*} ; [[ \${host} = \${port} ]] &&
port=22 ; eval \"declare -a ssh_opts=(\${3})\" ; exec sftp -P \${port}
\"\${ssh_opts[@]}\" \"\${host}:/\${x#*/}\" \"\$1\"" sftp
"${DISTDIR}/${FILE}" "${URI}" "${PORTAGE_SSH_OPTS}""
FETCHCOMMAND_SSH="bash -c "x=\${2#ssh://} ; host=\${x%%/*} ;
port=\${host##*:} ; host=\${host%:*} ; [[ \${host} = \${port} ]] &&
port=22 ; exec rsync --rsh=\"ssh -p\${port} \${3}\" -avP
\"\${host}:/\${x#*/}\" \"\$1\"" rsync "${DISTDIR}/${FILE}" "${URI}"
"${PORTAGE_SSH_OPTS}""
FFLAGS="-O2 -pipe"
FLTK_DOCDIR="/usr/share/doc/fltk-1.3.2_p10088/html"
GCC_SPECS=""
GENTOO_MIRRORS="ftp://gentoo.mirrors.pair.com/"
GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt
gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore
rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx"
GRUB_PLATFORMS="pc efi-64"
GSETTINGS_BACKEND="dconf"
GUILE_LOAD_PATH="/usr/share/guile/1.8"
HG="/usr/bin/hg"
HOME="/root"
INFOPATH="/usr/share/info:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.3/info:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.25.1/info:/usr/share/info/emacs-24:/usr/share/gnat-gcc-data/x86_64-pc-linux-gnu/4.6/info"
INPUT_DEVICES="keyboard mouse"
IUSE_IMPLICIT="abi_x86_64 prefix prefix-guest"
JAVAC="/etc/java-config-2/current-system-vm/bin/javac"
JAVA_HOME="/etc/java-config-2/current-system-vm"
JDK_HOME="/etc/java-config-2/current-system-vm"
KERNEL="linux"
LANG="en_US.utf8"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb
ncurses text"
LC_MESSAGES="C"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LDFLAGS_amd64="-m elf_x86_64"
LDFLAGS_x32="-m elf32_x86_64"
LDFLAGS_x86="-m elf_i386"
LESS="-R -M --shift 5"
LESSOPEN="|lesspipe %s"
LIBDIR_amd64="lib64"
LIBDIR_amd64_fbsd="lib64"
LIBDIR_arm="lib"
LIBDIR_arm64="lib64"
LIBDIR_n32="lib32"
LIBDIR_n64="lib64"
LIBDIR_o32="lib"
LIBDIR_ppc="lib32"
LIBDIR_ppc64="lib64"
LIBDIR_s390="lib32"
LIBDIR_s390x="lib64"
LIBDIR_sparc32="lib32"
LIBDIR_sparc64="lib64"
LIBDIR_x32="libx32"
LIBDIR_x86="lib32"
LIBDIR_x86_fbsd="lib32"
LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer"
LINGUAS="en en_US"
LOGNAME="root"
LS_COLORS="rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.cfg=00;32:*.conf=00;32:*.diff=00;32:*.doc=00;32:*.ini=00;32:*.log=00;32:*.patch=00;32:*.pdf=00;32:*.ps=00;32:*.tex=00;32:*.txt=00;32:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:"
MAKEOPTS="-j 6"
MANPATH="/etc/java-config-2/current-system-vm/man:/usr/local/share/man:/usr/share/man:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.3/man:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.25.1/man:/etc/java-config-2/current-system-vm/man/:/usr/share/gnat-gcc-data/x86_64-pc-linux-gnu/4.6/man"
MULTILIB_ABIS="amd64 x86"
MULTILIB_STRICT_DENY="64-bit.*shared object"
MULTILIB_STRICT_DIRS="/lib32 /lib /usr/lib32 /usr/lib /usr/kde/*/lib32
/usr/kde/*/lib /usr/qt/*/lib32 /usr/qt/*/lib /usr/X11R6/lib32
/usr/X11R6/lib"
MULTILIB_STRICT_EXEMPT="(perl5|gcc|gcc-lib|binutils|eclipse-3|debug|portage|udev|systemd|clang|python-exec)"
NETBEANS="apisupport cnd groovy gsf harness ide identity j2ee java
mobility nb php profiler soa visualweb webcommon websvccommon xml"
OFFICE_IMPLEMENTATION="libreoffice"
OPENCL_PROFILE="nvidia"
OPENGL_PROFILE="nvidia"
PAGER="/usr/bin/less"
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3:/usr/x86_64-pc-linux-gnu/gnat-gcc-bin/4.6:/usr/libexec/gnat-gcc/x86_64-pc-linux-gnu/4.6:/opt/nvidia-cg-toolkit/bin:/usr/lib64/subversion/bin"
PHP_TARGETS="php5-5"
PKGDIR="/usr/portage/packages"
PORTAGE_ARCHLIST="alpha amd64 amd64-fbsd amd64-linux arm arm-linux arm64
hppa hppa-hpux ia64 ia64-hpux ia64-linux m68k m68k-mint mips nios2 ppc
ppc-aix ppc-macos ppc-openbsd ppc64 ppc64-linux s390 sh sparc sparc-fbsd
sparc-solaris sparc64-freebsd sparc64-solaris x64-cygwin x64-freebsd
x64-macos x64-openbsd x64-solaris x86 x86-cygwin x86-fbsd x86-freebsd
x86-interix x86-linux x86-macos x86-netbsd x86-openbsd x86-solaris
x86-winnt"
PORTAGE_BIN_PATH="/usr/lib/portage/python3.4"
PORTAGE_COMPRESS_EXCLUDE_SUFFIXES="css gif htm[l]? jp[e]?g js pdf png"
PORTAGE_CONFIGROOT="/"
PORTAGE_DEBUG="0"
PORTAGE_DEPCACHEDIR="/var/cache/edb/dep"
PORTAGE_ELOG_CLASSES="log warn error"
PORTAGE_ELOG_MAILFROM="portage@localhost"
PORTAGE_ELOG_MAILSUBJECT="[portage] ebuild log for ${PACKAGE} on ${HOST}"
PORTAGE_ELOG_MAILURI="root"
PORTAGE_ELOG_SYSTEM="save_summary:log,warn,error,qa echo"
PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS="5"
PORTAGE_FETCH_RESUME_MIN_SIZE="350K"
PORTAGE_GID="250"
PORTAGE_GPG_SIGNING_COMMAND="gpg --sign --digest-algo SHA256 --clearsign
--yes --default-key "${PORTAGE_GPG_KEY}" --homedir "${PORTAGE_GPG_DIR}"
"${FILE}""
PORTAGE_INST_GID="0"
PORTAGE_INST_UID="0"
PORTAGE_INTERNAL_CALLER="1"
PORTAGE_OVERRIDE_EPREFIX=""
PORTAGE_PYM_PATH="/usr/lib64/python3.4/site-packages"
PORTAGE_PYTHONPATH="/usr/lib64/python3.4/site-packages"
PORTAGE_RSYNC_EXTRA_OPTS="--progress"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times
--omit-dir-times --compress --force --whole-file --delete --stats
--human-readable --timeout=180 --exclude=/distfiles --exclude=/local
--exclude=/packages"
PORTAGE_RSYNC_RETRIES="-1"
PORTAGE_SYNC_STALE="30"
PORTAGE_TMPDIR="/var/tmp"
PORTAGE_VERBOSE="1"
PORTAGE_WORKDIR_MODE="0700"
PORTAGE_XATTR_EXCLUDE="btrfs.* security.evm security.ima       
security.selinux system.nfs4_acl"
PORT_LOGDIR_CLEAN="find "${PORT_LOGDIR}" -type f ! -name "summary.log*"
-mtime +7 -delete"
PRELINK_PATH_MASK="/usr/lib64/klibc:/usr/lib64/libfreebl3.so:/usr/lib64/libnssdbm3.so:/usr/lib64/libsoftokn3.so:/usr/lib32/libfreebl3.so:/usr/lib32/libnssdbm3.so:/usr/lib32/libsoftokn3.so:/opt/bin/skype"
PROFILE_ONLY_VARIABLES="ARCH ELIBC IUSE_IMPLICIT KERNEL USERLAND
USE_EXPAND_IMPLICIT USE_EXPAND_UNPREFIXED USE_EXPAND_VALUES_ARCH
USE_EXPAND_VALUES_ELIBC USE_EXPAND_VALUES_KERNEL USE_EXPAND_VALUES_USERLAND"
PWD="/root"
PYTHONDONTWRITEBYTECODE="1"
PYTHON_SINGLE_TARGET="python2_7"
PYTHON_TARGETS="python2_7 python3_4 python2_7 python3_4"
QT_GRAPHICSSYSTEM="raster"
QT_PLUGIN_PATH="/usr/lib64/kde4/plugins"
RESUMECOMMAND="wget -c -t 3 -T 60 --passive-ftp -O "${DISTDIR}/${FILE}"
"${URI}""
RESUMECOMMAND_RSYNC="rsync -avP "${URI}" "${DISTDIR}/${FILE}""
RESUMECOMMAND_SSH="bash -c "x=\${2#ssh://} ; host=\${x%%/*} ;
port=\${host##*:} ; host=\${host%:*} ; [[ \${host} = \${port} ]] &&
port=22 ; exec rsync --rsh=\"ssh -p\${port} \${3}\" -avP
\"\${host}:/\${x#*/}\" \"\$1\"" rsync "${DISTDIR}/${FILE}" "${URI}"
"${PORTAGE_SSH_OPTS}""
ROOT="/"
ROOTPATH="/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3:/usr/x86_64-pc-linux-gnu/gnat-gcc-bin/4.6:/usr/libexec/gnat-gcc/x86_64-pc-linux-gnu/4.6:/opt/nvidia-cg-toolkit/bin:/usr/lib64/subversion/bin"
RPMDIR="/usr/portage/rpm"
RUBY_TARGETS="ruby19 ruby20 ruby21 ruby22 ruby24"
R_HOME="/usr/lib64/R"
SCHEME_LIBRARY_PATH="/usr/share/slib/"
SHELL="/bin/bash"
SHLVL="1"
SYMLINK_LIB="yes"
TERM="xterm"
UNINSTALL_IGNORE="/lib/modules/* /var/run /var/lock"
USE="3dnow 3dnowext X a52 aac acl acpi alsa amd64 amr apache2 ares
audiofile autoipd avahi berkdb bittorrent blender-game bmp boost
branding bzip2 c++0x cairo caps cdda cdr cg cgi clang cli consolekit
cpudetection cracklib crypt css cups curl custom-cflags custom-tune cxx
dbus debugger declarative device-mapper dga discouraged dolbyinrec
double-precision dri drm dts dvd dvdr emboss encode evdev exif expat
extras fam fbcon ffcall ffmpeg fftw firefox firmware flac fluidsynth
fontconfig foomaticdb fortran freeimage ftp g3dvl gbm gdbm gflags
gfortran ggz gif gl glade glamor glut gmp gnome gnome-keyring gphoto2
gpm graphviz gsl gstreamer gtk gtk3 heterogeneous high-ints hpijs hwdb
iconv icu ide imlib ipv6 ithreads jadetex java jit joystick jpeg jpeg2k
kde kdrive lame lapack lcms ldap libffi libkms libnotify libwww
llvm-shared-libs lm_sensors lua lzo mad matroska mdnsresponder-compat
metis midi minizip mmap mms mmx mmxext mng modules mozilla mp3 mp3rtp
mp4 mpeg mpeg2 multicore multilib multislot mysql nas natspec ncurses
netpbm nls nowin nptl nsplugin ode ogg ogre ois okteta openal opencl
openexr opengl openmp openssl opus orc pae pam pango parport pch pcre
pcre16 pdf perl pgo plasma png policykit posix postproc povray ppds
private-headers pulseaudio python python3 qml qt3support qt4 qthelp
quicktime r600-llvm-compiler readline reiserfs script sdk sdl seamonkey
seccomp secure-delete semantic-desktop server session sftp sip smp
soprano spell sql sqlite sse sse2 sse3 sse4 ssl startup-notification
static-ppds subversion svg system-boost system-cairo system-icu
system-jpeg system-libvpx system-sqlite t1lib tcpd theora threads
threadsafe threadsonly tiff tinfo tk truetype udev udisks unicode
unlock-notify upnp upnp-av upower usb userlocales utempter uuid uvm uxa
v4l vcd video videos vnc vorbis webkit wxwidgets x264 xcb xine xml xmp
xv xvfb xvid xvmc yuv4mpeg zeroconf zlib" ABI_X86="64 32"
ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci
emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0
intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci"
APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias
auth_basic authn_alias authn_anon authn_dbm authn_default authn_file
authz_dbm authz_default authz_groupfile authz_host authz_owner
authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir
disk_cache env expires ext_filter file_cache filter headers include info
log_config logio mem_cache mime mime_magic negotiation rewrite setenvif
speling status unique_id userdir usertrack vhost_alias"
CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon
braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load
memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse2_4way 3dnow
3dnowext sse sse2 sse3 sse4" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm
earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea
ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf
superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc
efi-64" INPUT_DEVICES="keyboard mouse" KERNEL="linux"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb
ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console
presenter-minimizer" LINGUAS="en en_US"
OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5"
PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4
python2_7 python3_4" RUBY_TARGETS="ruby19 ruby20 ruby21 ruby22 ruby24"
USERLAND="GNU" VIDEO_CARDS="nvidia radeonsi radeon"
XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p
iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark
dhcpmac delude chaos account"
USER="root"
USERLAND="GNU"
USE_EXPAND="ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ALSA_CARDS APACHE2_MODULES
APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_X86
CROSSCOMPILE_OPTS CURL_SSL DRACUT_MODULES DVB_CARDS ELIBC
ENLIGHTENMENT_MODULES FCDSL_CARDS FFTOOLS FOO2ZJS_DEVICES
FRITZCAPI_CARDS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL
LCD_DEVICES LIBREOFFICE_EXTENSIONS LINGUAS LIRC_DEVICES MONKEYD_PLUGINS
NETBEANS_MODULES NGINX_MODULES_HTTP NGINX_MODULES_MAIL OFED_DRIVERS
OFFICE_IMPLEMENTATION OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM
PHP_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS
QEMU_USER_TARGETS RUBY_TARGETS SANE_BACKENDS USERLAND UWSGI_PLUGINS
VIDEO_CARDS VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS"
USE_EXPAND_HIDDEN="ABI_MIPS ABI_PPC ABI_S390 CROSSCOMPILE_OPTS ELIBC
KERNEL USERLAND"
USE_EXPAND_IMPLICIT="ARCH ELIBC KERNEL USERLAND"
USE_EXPAND_UNPREFIXED="ARCH"
USE_EXPAND_VALUES_ARCH="alpha amd64 amd64-fbsd amd64-linux arm arm-linux
arm64 hppa hppa-hpux ia64 ia64-hpux ia64-linux m68k m68k-mint mips nios2
ppc ppc64 ppc64-linux ppc-aix ppc-macos ppc-openbsd s390 sh sparc
sparc64-freebsd sparc64-solaris sparc-fbsd sparc-solaris x64-cygwin
x64-freebsd x64-macos x64-openbsd x64-solaris x86 x86-cygwin x86-fbsd
x86-freebsd x86-interix x86-linux x86-macos x86-netbsd x86-openbsd
x86-solaris x86-winnt"
USE_EXPAND_VALUES_ELIBC="AIX Cygwin Darwin DragonFly FreeBSD glibc HPUX
Interix mintlib musl NetBSD OpenBSD SunOS uclibc Winnt"
USE_EXPAND_VALUES_KERNEL="AIX Darwin FreeBSD freemint HPUX linux NetBSD
OpenBSD SunOS Winnt"
USE_EXPAND_VALUES_USERLAND="BSD GNU"
USE_ORDER="env:pkg:conf:defaults:pkginternal:repo:env.d"
USE_PYTHON="2.7 3.4"
VIDEO_CARDS="nvidia radeonsi radeon"
VISUAL="/bin/nano"
XAUTHORITY="/root/.xauthPN2t0f"
XDG_CONFIG_DIRS="/etc/xdg"
XDG_DATA_DIRS="/usr/local/share:/usr/share"
XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p
iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark
dhcpmac delude chaos account"

tortoise ~ #





wraeth wrote:
> On 21/08/15 08:31, Alan Grimes wrote:
> > Fernando Rodriguez wrote:
> >> The ncurses ebuild is indeed broken, I ran into the same problem
> >> before.
> >>
> >> But you received good advice on your last thread (build libtinfo
> >> on another system and copy it or just try symlinking it to
> >> ncurses), if you'd followed it you would a got your system back
> >> up in a few minutes.
>
> > ppl seem to be antsy to hear what I actually did, so I'll
> > respond....
>
> Because we try to avoid flame wars and needless name-calling/swearing
> when looking for and providing support to people. Also because we kind
> of expect the original poster to respond to queries in a thread that
> they started.
>
> > 1. I got my grubby mitts on a stage 3 tarball, I always keep one on
> > hand for this reason. =\
>
> > 2. I grepped everything in /bin and /lib for tinfo and copied over
> > from the tarball where necessary.
>
> This is kind of dangerous. It would be safer to create/use a binary
> package.
>
> - From a running Gentoo system (including a stage3) you can create a
> binary package of an installed program by running
>
>   quickpkg <category>/<package>
>
> This will place it in /usr/portage/packages by default (see PKGDIR in
> `man make.conf`). This is better than just randomly copying files from
> another system. There are also online hosts available that provide
> some packages (see my post in your previous thread).
>
> > 3. Started --emptytree world.
>
> > 4. waited.
>
> > 5. kicked it each time it stopped,
>
> > 6. kicked it some more.
>
> > 7. kicked it a few more times.
>
> Emerge's '--keep-going' option may be of use to you here...
>
> > 8, got to the end of the list about two and a half days later
> > (which is par for my machine.)
>
> > 9. published the results.
>
> > 10. rebooted.
>
> So what you're saying is that you did an '--emptytree' build for which
> there were a number of failures; *one* of which was a segfault; some
> of which may not be valid; after arbitrarily copying some files from a
> stage3 of unknown age.
>
> Don't get me wrong, providing feedback and letting others know is
> good, but unless there's a baseline and/or more is known about what is
> going on (see Alan McKinnon's comment about others not getting this
> and something about your environment potentially causing this), we
> can't do much with it.
>
> More information about your environment, such as an `emerge --info`
> and relevant flags/settings for a specific package that is failing
> would go a fair way to giving us the information we need (and have
> asked for) to be able to help you.
>
>
>

-- 
IQ is a measure of how stupid you feel.

Powers are not rights.

Re: [gentoo-user] Epic list of total FAIL.

[wraeth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/08/15 11:49, Alan Grimes wrote:
> tortoise ~ # emerge --info ... Repositories:

You have a fair number of overlays. It probably doesn't need to be
said, but you should watch out for packages being pulled in from an
overlay instead of the default Gentoo repository.

> CFLAGS="-O3 -march=native -pipe " CXXFLAGS="-O3 -march=native -pipe
> "

C{XX}FLAGS="-O3" is known to cause some issues [1]. If you've done an
- --emptytree rebuild with "-O3" then this could be the cause of the
segfaults.

> wraeth wrote:
>> More information about your environment, such as an `emerge
>> --info` and relevant flags/settings for a specific package that
>> is failing would go a fair way to giving us the information we
>> need (and have asked for) to be able to help you.

The `emerge --info` helps, but you haven't listed an explicit build
failure or details about that package.
- -- 
wraeth <wraeth@wraeth.id.au>
GnuPG Key: B2D9F759
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXWj8oACgkQXcRKerLZ91lljwD/Uyqx4Izxy7+BQdyYn3hk7CDO
NZa1wUqS1ZQ4YVl7jEsA/2FqG5d5608HTm1KfKCbjkJobXbx4jL9xB0EP+2o5eBI
=Bm1J
-----END PGP SIGNATURE-----

Re: [gentoo-user] Epic list of total FAIL.

[Alan McKinnon]

On 21/08/2015 04:41, wraeth wrote:
> On 21/08/15 11:49, Alan Grimes wrote:
>> tortoise ~ # emerge --info ... Repositories:
> 
> You have a fair number of overlays. It probably doesn't need to be
> said, but you should watch out for packages being pulled in from an
> overlay instead of the default Gentoo repository.
> 
>> CFLAGS="-O3 -march=native -pipe " CXXFLAGS="-O3 -march=native -pipe
>> "
> 
> C{XX}FLAGS="-O3" is known to cause some issues [1]. If you've done an
> --emptytree rebuild with "-O3" then this could be the cause of the
> segfaults.


Earlier I saw segfaults in gcc, and another poster pointed it out.

When gcc segfaults, it is always suspicious mostly because the compiler
is an app where we know the devs take extraordinary measures to prevent it.

The most common cause is faulty hardware (most often memory) as gcc
tends to use all of it in ways no other app does. The usual procedure at
this point is to run memtest for an extended period - say 48 hours, or
even 72 for an older slow machine.


> 
>> wraeth wrote:
>>> More information about your environment, such as an `emerge
>>> --info` and relevant flags/settings for a specific package that
>>> is failing would go a fair way to giving us the information we
>>> need (and have asked for) to be able to help you.
> 
> The `emerge --info` helps, but you haven't listed an explicit build
> failure or details about that package.
> 

-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: Epic list of total FAIL.

[James]

Alan Grimes <ALONZOTG <at> verizon.net> writes:


> 8, got to the end of the list about two and a half days later (which is
> par for my machine.)


Hello Alan Grimes,


You seem to imply you are running hardware less that some version
of the latest 4/8 processor monster?

Perhaps something lighter then the kde5 for the QT family, there is
lxqt(1.0) Fairly young but very fast even on older hardware. It's using
QT5 so if you are 'qt centric' in your needs, then you might just
like lxqt as many others do.


O3
I also saw that option. On older systems, I often find that Os runs
very fast, as the smaller size of the resulting binaries allows
ram to function more appropriately. 

hth,
James

[gentoo-user] Re: Epic list of total FAIL.

[Grant Edwards]

On 2015-08-21, Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> Earlier I saw segfaults in gcc, and another poster pointed it out.
>
> When gcc segfaults, it is always suspicious mostly because the compiler
> is an app where we know the devs take extraordinary measures to prevent it.
>
> The most common cause is faulty hardware (most often memory) as gcc
> tends to use all of it in ways no other app does. The usual procedure
> at this point is to run memtest for an extended period - say 48
> hours, or even 72 for an older slow machine.

That is definitely good advice.  I've run into this situation several
times.  A machine had bad RAM that didn't seem to cause any problems
under "normal" operation.  But, when trying to compile something large
like gcc, I would see non-repeatable segfaults (it wouldn't always
segfault at the exact same point).  In those cases, I could often run
memtest for several passes and not see an error. But, _eventually_
ramtest would catch it.  Run memtest for a few days.  Really.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm having an
                                  at               EMOTIONAL OUTBURST!!  But,
                              gmail.com            uh, WHY is there a WAFFLE
                                                   in my PAJAMA POCKET??

Re: [gentoo-user] Re: Epic list of total FAIL.

[Alan Grimes]

Grant Edwards wrote:
> On 2015-08-21, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
>> Earlier I saw segfaults in gcc, and another poster pointed it out.
>>
>> When gcc segfaults, it is always suspicious mostly because the compiler
>> is an app where we know the devs take extraordinary measures to prevent it.
>>
>> The most common cause is faulty hardware (most often memory) as gcc
>> tends to use all of it in ways no other app does. The usual procedure
>> at this point is to run memtest for an extended period - say 48
>> hours, or even 72 for an older slow machine.
> That is definitely good advice.  I've run into this situation several
> times.  A machine had bad RAM that didn't seem to cause any problems
> under "normal" operation.  But, when trying to compile something large
> like gcc, I would see non-repeatable segfaults (it wouldn't always
> segfault at the exact same point).  In those cases, I could often run
> memtest for several passes and not see an error. But, _eventually_
> ramtest would catch it.  Run memtest for a few days.  Really.

Yeah, I know there's a single bit error out at the end of RAM that will
appear on the third or fourth pass...

I have already RMA'd half of the ram in this machine because it was
giving a whole fist-full of errors across two sticks... I run the rusty
old bus on the CPU ( SIX CORES!!!!)  a bit harder than it was intended
in order to keep up with the new junk. My previous machine had ECC.   =(

I was advised to just jack the voltage a little bit and live with it. I
guess I'd better run more tests and see what the situation is....

It just doesn't seem reasonable to demand that every bit in a 32
gigabyte memory bank be absolutely perfect....

-- 
IQ is a measure of how stupid you feel.

Powers are not rights.

[gentoo-user] Re: Epic list of total FAIL.

[Grant Edwards]

On 2015-08-21, Alan Grimes <ALONZOTG@verizon.net> wrote:
> Grant Edwards wrote:
>> On 2015-08-21, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>
>>> Earlier I saw segfaults in gcc, and another poster pointed it out.
>>>
>>> When gcc segfaults, it is always suspicious mostly because the compiler
>>> is an app where we know the devs take extraordinary measures to prevent it.
>>>
>>> The most common cause is faulty hardware (most often memory) as gcc
>>> tends to use all of it in ways no other app does. The usual procedure
>>> at this point is to run memtest for an extended period - say 48
>>> hours, or even 72 for an older slow machine.
>> That is definitely good advice.  I've run into this situation several
>> times.  A machine had bad RAM that didn't seem to cause any problems
>> under "normal" operation.  But, when trying to compile something large
>> like gcc, I would see non-repeatable segfaults (it wouldn't always
>> segfault at the exact same point).  In those cases, I could often run
>> memtest for several passes and not see an error. But, _eventually_
>> ramtest would catch it.  Run memtest for a few days.  Really.
>
> Yeah, I know there's a single bit error out at the end of RAM that
> will appear on the third or fourth pass...

And you're still using it?  And when it doesn't work, you blame
blaming _us_?

**PLONK**

> It just doesn't seem reasonable to demand that every bit in a 32
> gigabyte memory bank be absolutely perfect....

Idiot.

Of _course_ software expects memory to work.  Why don't you stop
bothering us and go write an OS that doesn't depend on RAM working
properly.

-- 
Grant Edwards               grant.b.edwards        Yow! Now KEN and BARBIE
                                  at               are PERMANENTLY ADDICTED to
                              gmail.com            MIND-ALTERING DRUGS ...

Re: [gentoo-user] Re: Epic list of total FAIL.

[J. Roeleveld]

On Friday, August 21, 2015 11:00:16 AM Alan Grimes wrote:
> Grant Edwards wrote:
> Yeah, I know there's a single bit error out at the end of RAM that will
> appear on the third or fourth pass...

Replace it

> I have already RMA'd half of the ram in this machine because it was
> giving a whole fist-full of errors across two sticks... I run the rusty
> old bus on the CPU ( SIX CORES!!!!)  a bit harder than it was intended
> in order to keep up with the new junk. My previous machine had ECC.   =(
> 
> I was advised to just jack the voltage a little bit and live with it. I
> guess I'd better run more tests and see what the situation is....

Advised by who?

> It just doesn't seem reasonable to demand that every bit in a 32
> gigabyte memory bank be absolutely perfect....

I have machines with a lot more and all of them work perfectly.

Please don't bother this list with more of your complaining until you grow up 
and learn how to use computers properly.

Re: [gentoo-user] Re: Epic list of total FAIL.

[Dale]

Alan Grimes wrote:
> Grant Edwards wrote:
>> On 2015-08-21, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>
>>> Earlier I saw segfaults in gcc, and another poster pointed it out.
>>>
>>> When gcc segfaults, it is always suspicious mostly because the compiler
>>> is an app where we know the devs take extraordinary measures to prevent it.
>>>
>>> The most common cause is faulty hardware (most often memory) as gcc
>>> tends to use all of it in ways no other app does. The usual procedure
>>> at this point is to run memtest for an extended period - say 48
>>> hours, or even 72 for an older slow machine.
>> That is definitely good advice.  I've run into this situation several
>> times.  A machine had bad RAM that didn't seem to cause any problems
>> under "normal" operation.  But, when trying to compile something large
>> like gcc, I would see non-repeatable segfaults (it wouldn't always
>> segfault at the exact same point).  In those cases, I could often run
>> memtest for several passes and not see an error. But, _eventually_
>> ramtest would catch it.  Run memtest for a few days.  Really.
> Yeah, I know there's a single bit error out at the end of RAM that will
> appear on the third or fourth pass...
>
> I have already RMA'd half of the ram in this machine because it was
> giving a whole fist-full of errors across two sticks... I run the rusty
> old bus on the CPU ( SIX CORES!!!!)  a bit harder than it was intended
> in order to keep up with the new junk. My previous machine had ECC.   =(
>
> I was advised to just jack the voltage a little bit and live with it. I
> guess I'd better run more tests and see what the situation is....
>
> It just doesn't seem reasonable to demand that every bit in a 32
> gigabyte memory bank be absolutely perfect....
>


You know those multi terabyte hard drives they make, every bit of those
platters that are actively in use must work perfectly.  If just one
thing, just one tiny bit, is not working correctly, you get bad data. 
With computers, one bit of bad data means something doesn't work be it
hard drives or memory or even the CPU.  You may can live with it on
widoze but not Linux.  Linus maximizes the use of memory more so than
windoze.   I have 16Gbs of ram here.  Even if I don't compile anything,
eventually all my memory will be used by cache if nothing else.  Once
that cache hits a bad spot, there is trouble.

Might I also add, whoever told you to live with it, I hope they don't
work on airplanes and I wouldn't take advice from them to much on puter
stuff in the future. 

Just my $0.02 worth.

Dale

:-)  :-) 

Re: [gentoo-user] Re: Epic list of total FAIL.

[Fernando Rodriguez]

On Friday, August 21, 2015 11:00:16 AM Alan Grimes wrote:
> Grant Edwards wrote:
> > On 2015-08-21, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> >
> >> Earlier I saw segfaults in gcc, and another poster pointed it out.
> >>
> >> When gcc segfaults, it is always suspicious mostly because the compiler
> >> is an app where we know the devs take extraordinary measures to prevent 
it.
> >>
> >> The most common cause is faulty hardware (most often memory) as gcc
> >> tends to use all of it in ways no other app does. The usual procedure
> >> at this point is to run memtest for an extended period - say 48
> >> hours, or even 72 for an older slow machine.
> > That is definitely good advice.  I've run into this situation several
> > times.  A machine had bad RAM that didn't seem to cause any problems
> > under "normal" operation.  But, when trying to compile something large
> > like gcc, I would see non-repeatable segfaults (it wouldn't always
> > segfault at the exact same point).  In those cases, I could often run
> > memtest for several passes and not see an error. But, _eventually_
> > ramtest would catch it.  Run memtest for a few days.  Really.
> 
> Yeah, I know there's a single bit error out at the end of RAM that will
> appear on the third or fourth pass...
> 
> I have already RMA'd half of the ram in this machine because it was
> giving a whole fist-full of errors across two sticks... I run the rusty
> old bus on the CPU ( SIX CORES!!!!)  a bit harder than it was intended
> in order to keep up with the new junk. My previous machine had ECC.   =(
> 
> I was advised to just jack the voltage a little bit and live with it. I
> guess I'd better run more tests and see what the situation is....
> 
> It just doesn't seem reasonable to demand that every bit in a 32
> gigabyte memory bank be absolutely perfect....

LOL. It's perfectly reasonable.
If it's under warranty, return it. And get a different brand cause it sounds 
like what you got is crap.

If it's not under warranty and after running the test for an extended period 
as adviced you're sure that it's only a single bad bit at the highest end you 
can boot with the mem= option. Also see memmap and memtest.

https://www.kernel.org/doc/Documentation/kernel-parameters.txt

-- 
Fernando Rodriguez

Re: [gentoo-user] Re: Epic list of total FAIL.

[Alan Grimes]

J. Roeleveld wrote:
> Please don't bother this list with more of your complaining until you grow up 
> and learn how to use computers properly.

I built my first machine nearly a quarter century ago. =|

That said, I spent the day doing diagnostics:


Findings:

1. There were a hell of a lot more memory errors than I had seen before.
2. There was a smudge on one of the dimm's contacts and some of the
usual dust on the CPU-facing one.
3. The motherboard was not developed by sane engineers. In a sane world,
there are two types of variables: measured variables and controlled
variables.
The RAM voltage would appear to be a controlled variable but it is also
a measured variable. In order to achieve a close approximation of 1.5v,
I had to set it to 1.530 volts. WTF...

4. an AMD K10 processor cannot successfully drive 8-ranks of high
density ram at 2x800 mhz -- BUT IT WILL TRY!!! I found all dimms to be
good either individually or in pairs, but the entire ram compliment of
four dims cannot be run at full speed at once with the CPU/motherboard I
have installed.

5. I found a set of settings that went through memtest fine but caused
linux to segfault and die. I backed off the FSB a few notches while
adjusting the multipliers to stay within the specified frequency for the
processor and it seems to be OK now.



-- 
IQ is a measure of how stupid you feel.

Powers are not rights.

Re: [gentoo-user] Re: Epic list of total FAIL.

[Fernando Rodriguez]

On Saturday, August 22, 2015 1:52:00 AM Alan Grimes wrote:
> J. Roeleveld wrote:
> > Please don't bother this list with more of your complaining until you grow 
up 
> > and learn how to use computers properly.
> 
> I built my first machine nearly a quarter century ago. =|

Shame!

> That said, I spent the day doing diagnostics:
> 
> 
> Findings:
> 
> 1. There were a hell of a lot more memory errors than I had seen before.
> 2. There was a smudge on one of the dimm's contacts and some of the
> usual dust on the CPU-facing one.
> 3. The motherboard was not developed by sane engineers. In a sane world,
> there are two types of variables: measured variables and controlled
> variables.
> The RAM voltage would appear to be a controlled variable but it is also
> a measured variable. In order to achieve a close approximation of 1.5v,
> I had to set it to 1.530 volts. WTF...
> 
> 4. an AMD K10 processor cannot successfully drive 8-ranks of high
> density ram at 2x800 mhz -- BUT IT WILL TRY!!! I found all dimms to be
> good either individually or in pairs, but the entire ram compliment of
> four dims cannot be run at full speed at once with the CPU/motherboard I
> have installed.

Findings 3 & 4 sound like a faulty or underrated PSU...or a bad motherboard. 
Start by unplugging everything that you don't need to boot from a live CD and 
run some tests.

> 5. I found a set of settings that went through memtest fine but caused
> linux to segfault and die. I backed off the FSB a few notches while
> adjusting the multipliers to stay within the specified frequency for the
> processor and it seems to be OK now.

-- 
Fernando Rodriguez

Re: [gentoo-user] Re: Epic list of total FAIL.

[Dale]

Fernando Rodriguez wrote:
> On Saturday, August 22, 2015 1:52:00 AM Alan Grimes wrote:
>
>> That said, I spent the day doing diagnostics:
>>
>>
>> Findings:
>>
>> 1. There were a hell of a lot more memory errors than I had seen before.
>> 2. There was a smudge on one of the dimm's contacts and some of the
>> usual dust on the CPU-facing one.
>> 3. The motherboard was not developed by sane engineers. In a sane world,
>> there are two types of variables: measured variables and controlled
>> variables.
>> The RAM voltage would appear to be a controlled variable but it is also
>> a measured variable. In order to achieve a close approximation of 1.5v,
>> I had to set it to 1.530 volts. WTF...
>>
>> 4. an AMD K10 processor cannot successfully drive 8-ranks of high
>> density ram at 2x800 mhz -- BUT IT WILL TRY!!! I found all dimms to be
>> good either individually or in pairs, but the entire ram compliment of
>> four dims cannot be run at full speed at once with the CPU/motherboard I
>> have installed.
> Findings 3 & 4 sound like a faulty or underrated PSU...or a bad motherboard. 
> Start by unplugging everything that you don't need to boot from a live CD and 
> run some tests.
>


It sure does.  A weak power supply will certainly cause some issues.  If
he can remove a few power hogs and it works, then the memory may be OK
and just short on power.  Plus, if the power supply is weak, that could
show up in other places too. 

OP, maybe you should give this site a look see:

http://www.jonnyguru.com/modules.php?name=NDReviews&op=Review_Cat&recatnum=13 


This one just reviewed had a perfect score, if it has enough power for
what you are running.

http://www.jonnyguru.com/modules.php?name=NDReviews&op=Review_Cat&recatnum=13 


This site below lists them by wattage.  They test them pretty hard too. 
If it isn't a well built unit, they'll find the problem. 

http://www.overclockers.com/forums/showthread.php/589708-Recommended-PSU-s-True-Tested


Hope one of those helps or maybe all of them. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Epic list of total FAIL.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1863 bytes --]

On Saturday 22 Aug 2015 09:18:05 Dale wrote:
> Fernando Rodriguez wrote:
> > On Saturday, August 22, 2015 1:52:00 AM Alan Grimes wrote:
> >> That said, I spent the day doing diagnostics:
> >> 
> >> 
> >> Findings:
> >> 
> >> 1. There were a hell of a lot more memory errors than I had seen before.
> >> 2. There was a smudge on one of the dimm's contacts and some of the
> >> usual dust on the CPU-facing one.
> >> 3. The motherboard was not developed by sane engineers. In a sane world,
> >> there are two types of variables: measured variables and controlled
> >> variables.
> >> The RAM voltage would appear to be a controlled variable but it is also
> >> a measured variable. In order to achieve a close approximation of 1.5v,
> >> I had to set it to 1.530 volts. WTF...
> >> 
> >> 4. an AMD K10 processor cannot successfully drive 8-ranks of high
> >> density ram at 2x800 mhz -- BUT IT WILL TRY!!! I found all dimms to be
> >> good either individually or in pairs, but the entire ram compliment of
> >> four dims cannot be run at full speed at once with the CPU/motherboard I
> >> have installed.
> > 
> > Findings 3 & 4 sound like a faulty or underrated PSU...or a bad
> > motherboard. Start by unplugging everything that you don't need to boot
> > from a live CD and run some tests.
> 
> It sure does.  A weak power supply will certainly cause some issues.

I also concur that the most likely cause of this problem is the PSU but first, 
I would clean the RAM contacts.  

Then try a replacement PSU if you have a spare one, or take your multimeter 
and measure the output, checking for lower voltage values and fluctuations.  
If you get bad measurements, then take your soldering iron out and for a few 
pence inspect and replace any domed, or all capacitors on the secondary 
(output) side.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Re: Epic list of total FAIL.

[Alan McKinnon]

On 22/08/2015 13:25, Mick wrote:
> On Saturday 22 Aug 2015 09:18:05 Dale wrote:
>> Fernando Rodriguez wrote:
>>> On Saturday, August 22, 2015 1:52:00 AM Alan Grimes wrote:
>>>> That said, I spent the day doing diagnostics:
>>>>
>>>>
>>>> Findings:
>>>>
>>>> 1. There were a hell of a lot more memory errors than I had seen before.
>>>> 2. There was a smudge on one of the dimm's contacts and some of the
>>>> usual dust on the CPU-facing one.
>>>> 3. The motherboard was not developed by sane engineers. In a sane world,
>>>> there are two types of variables: measured variables and controlled
>>>> variables.
>>>> The RAM voltage would appear to be a controlled variable but it is also
>>>> a measured variable. In order to achieve a close approximation of 1.5v,
>>>> I had to set it to 1.530 volts. WTF...
>>>>
>>>> 4. an AMD K10 processor cannot successfully drive 8-ranks of high
>>>> density ram at 2x800 mhz -- BUT IT WILL TRY!!! I found all dimms to be
>>>> good either individually or in pairs, but the entire ram compliment of
>>>> four dims cannot be run at full speed at once with the CPU/motherboard I
>>>> have installed.
>>>
>>> Findings 3 & 4 sound like a faulty or underrated PSU...or a bad
>>> motherboard. Start by unplugging everything that you don't need to boot
>>> from a live CD and run some tests.
>>
>> It sure does.  A weak power supply will certainly cause some issues.
> 
> I also concur that the most likely cause of this problem is the PSU but first, 
> I would clean the RAM contacts.  
> 
> Then try a replacement PSU if you have a spare one, or take your multimeter 
> and measure the output, checking for lower voltage values and fluctuations.  
> If you get bad measurements, then take your soldering iron out and for a few 
> pence inspect and replace any domed, or all capacitors on the secondary 
> (output) side.


<nitpick>
A multimeter is not really a valid test. If say the 5V rail is dodgy,
then the output will still be a solid 5V. What's happening is that the
PSU regulator circuitry can't keep up so the output averages 5V (that's
what the transformer gives out) with large amounts of high-frequency
ripple superimposed. Your multimeter average's that out and displays ...
5V! When things get really bad the output may dip momentarily when load
is drawn, but by that stage the PSU has been struggling for a long time
already.

Use an oscilloscope instead, and you see immediately what condition the
output is in.
</nitpick>

Few IT techs just happen to have an expensive oscilloscope just lying
around, so a good recommendation is to replace the PSU anyway every 2
years or so - more if the thing runs hot. I consider these as wearing
items, sorta like oil filters



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Epic list of total FAIL.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2347 bytes --]

On Saturday 22 Aug 2015 12:47:52 Alan McKinnon wrote:
> On 22/08/2015 13:25, Mick wrote:

> > Then try a replacement PSU if you have a spare one, or take your
> > multimeter and measure the output, checking for lower voltage values and
> > fluctuations. If you get bad measurements, then take your soldering iron
> > out and for a few pence inspect and replace any domed, or all capacitors
> > on the secondary (output) side.
> 
> <nitpick>
> A multimeter is not really a valid test. If say the 5V rail is dodgy,
> then the output will still be a solid 5V. What's happening is that the
> PSU regulator circuitry can't keep up so the output averages 5V (that's
> what the transformer gives out) with large amounts of high-frequency
> ripple superimposed. Your multimeter average's that out and displays ...
> 5V! When things get really bad the output may dip momentarily when load
> is drawn, but by that stage the PSU has been struggling for a long time
> already.
> 
> Use an oscilloscope instead, and you see immediately what condition the
> output is in.
> </nitpick>

Valid nitpick, esp. if an oscilloscope is available.  Anecdotally, I have seen 
the amplitude of the ripple almost double *after* a repair than before.  
Admittedly, I think I used a capacitor with higher voltage rating, because 
that's all I could find at the time. Nevertheless, the PC worked fine after 
the repair, because the voltage output was at the right value and would hold 
steady under load.  BTW, I've seen voltage values look reasonable when not 
connected to a load and collapse when load is applied.  


> Few IT techs just happen to have an expensive oscilloscope just lying
> around, so a good recommendation is to replace the PSU anyway every 2
> years or so - more if the thing runs hot. I consider these as wearing
> items, sorta like oil filters

Yes, most electrolytic capacitors 'wear out' as time passes and drift from 
their original tolerance, which is quite wide to start with.  I have repaired 
half a dozen of PSUs over the years with good results and unless I have a 
spare PSU available I resort to replacing the capacitors.

It used to be the case that PSUs with (Japanese made) Hitachi caps could be 
relied upon for a build, but I don't know what comes out of China today.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Re: Epic list of total FAIL.

[Alan Grimes]

The PSU is an Antec EarthWatts 750.

Biggest hoggs outside the motherboard are the, um, er, well [nvidia 980
gpu] and an aging Western Digital Velociraptor boot drive. There is also
a 3TB drive for all my p***, er kerbals   ( Kerbal Space Program ) .
There is one optical drive and four chassis fans in the system. All fans
are operating perfectly.

As far as I know the operating conditions for the PSU are nearly ideal....

I did have some noise issues with it a few years ago but it seemed to
settle down and hasn't really given me any grief since.


Dale wrote:
> Fernando Rodriguez wrote:
>> On Saturday, August 22, 2015 1:52:00 AM Alan Grimes wrote:
>>
>> Findings 3 & 4 sound like a faulty or underrated PSU...or a bad
>> motherboard. Start by unplugging everything that you don't need to
>> boot from a live CD and run some tests. 
> It sure does.  A weak power supply will certainly cause some issues.  If
> he can remove a few power hogs and it works, then the memory may be OK
> and just short on power.  Plus, if the power supply is weak, that could
> show up in other places too. 
>
> OP, maybe you should give this site a look see:
>
> http://www.jonnyguru.com/modules.php?name=NDReviews&op=Review_Cat&recatnum=13 
>
>
> This one just reviewed had a perfect score, if it has enough power for
> what you are running.
>
> http://www.jonnyguru.com/modules.php?name=NDReviews&op=Review_Cat&recatnum=13 
>
>
> This site below lists them by wattage.  They test them pretty hard too. 
> If it isn't a well built unit, they'll find the problem. 
>
> http://www.overclockers.com/forums/showthread.php/589708-Recommended-PSU-s-True-Tested
>
>
> Hope one of those helps or maybe all of them. 
>
> Dale
>


-- 
IQ is a measure of how stupid you feel.

Powers are not rights.

Re: [gentoo-user] Re: Epic list of total FAIL.

[Alan McKinnon]

On 22/08/2015 18:40, Alan Grimes wrote:
> The PSU is an Antec EarthWatts 750.
> 
> Biggest hoggs outside the motherboard are the, um, er, well [nvidia 980
> gpu] and an aging Western Digital Velociraptor boot drive. There is also
> a 3TB drive for all my p***, er kerbals   ( Kerbal Space Program ) .
> There is one optical drive and four chassis fans in the system. All fans
> are operating perfectly.
> 
> As far as I know the operating conditions for the PSU are nearly ideal....
> 
> I did have some noise issues with it a few years ago but it seemed to
> settle down and hasn't really given me any grief since.



Maybe you should assume less and test more.

This is good advice, replace the power supply despite your thoughts.
They *are* the cost common failure item.



> 
> 
> Dale wrote:
>> Fernando Rodriguez wrote:
>>> On Saturday, August 22, 2015 1:52:00 AM Alan Grimes wrote:
>>>
>>> Findings 3 & 4 sound like a faulty or underrated PSU...or a bad
>>> motherboard. Start by unplugging everything that you don't need to
>>> boot from a live CD and run some tests. 
>> It sure does.  A weak power supply will certainly cause some issues.  If
>> he can remove a few power hogs and it works, then the memory may be OK
>> and just short on power.  Plus, if the power supply is weak, that could
>> show up in other places too. 
>>
>> OP, maybe you should give this site a look see:
>>
>> http://www.jonnyguru.com/modules.php?name=NDReviews&op=Review_Cat&recatnum=13 
>>
>>
>> This one just reviewed had a perfect score, if it has enough power for
>> what you are running.
>>
>> http://www.jonnyguru.com/modules.php?name=NDReviews&op=Review_Cat&recatnum=13 
>>
>>
>> This site below lists them by wattage.  They test them pretty hard too. 
>> If it isn't a well built unit, they'll find the problem. 
>>
>> http://www.overclockers.com/forums/showthread.php/589708-Recommended-PSU-s-True-Tested
>>
>>
>> Hope one of those helps or maybe all of them. 
>>
>> Dale
>>
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Epic list of total FAIL.

[Dale]

Alan Grimes wrote:
> The PSU is an Antec EarthWatts 750.
>
> Biggest hoggs outside the motherboard are the, um, er, well [nvidia 980
> gpu] and an aging Western Digital Velociraptor boot drive. There is also
> a 3TB drive for all my p***, er kerbals   ( Kerbal Space Program ) .
> There is one optical drive and four chassis fans in the system. All fans
> are operating perfectly.
>
> As far as I know the operating conditions for the PSU are nearly ideal....
>
> I did have some noise issues with it a few years ago but it seemed to
> settle down and hasn't really given me any grief since.
>
>


That noise could be what the problem was.  Just a example.  A fan's
bearings starts making noise.  Eventually, the bearings lock up and the
noise stops.  Guess what, the fan has stopped too.  Of course, the noise
is gone now but that doesn't mean the problem is gone does it?  Odds
are, some component was making noise because it was under pressure or
age was catching up or whatever.  When the noise stopped, it had likely
stopped working at all.  This sounds like a capacitor to me.  They will
make weird noises sometimes before they fail.  I used to work on TVs a
lot years ago, you know, the old tube type stuff.  Anyway, those caps
did all sorts of weird things.  Some would swell up until they were
shaped like a hot air balloon or something.  Some would blow out the
bottom and maybe even stink real bad.  I've even seen some that blew the
metal can completely off and the TV is full of that sticky paper stuff,
which also stinks, and the foil part.  Some just smoke and make a
hissing sound, then all heck breaks out in the TV.  Usually it stops
filtering and the rest of the TV is now getting a unfiltered DC which is
about like A/C.  Some components like those tubes don't like that much. 
They tend to revolt.  FET type components, when they go, they usually go
quick, with a bit of stink or smoke.  Usually. 

Yea, I'd be looking for a new power supply.  Some of those on that last
link I posted aren't that expensive.  Just calculate up what power you
need.  I tend to add at least 50% to that, for future expansion and
start up power.  Doubling it wouldn't hurt.  It just means your P/S is
running at half power most of the time.  On my current P/S, it is a 650
watt unit.  According to my UPS, my entire computer system pulls about
150 watts idle and about 160 to 170 when compiling the crap out of
something like GCC, Libreoffice etc.  Now that includes my monitor,
router, modem and speakers.  If I were to guess, the puter itself only
pulls around 100 to 120 watts.  My power supply has some overkill issues
for sure.  I could likely easily use a 300 watt unit but would likely
replace with a 400 watt since they are more available.  Technically, I
could use a 200 watt if the power supply was a well built model. 

As it is, my power supply likely never even gets warm.  Add in that it
is in a Cooler Master HAF-932 case and I'm sure the fan gets bored.  The
key thing on power supplies.  If you are going to buy cheap, buy big. 
Cheapos tend to overrate themselves, sometimes a LOT.  If you buy a well
known and well tested brand, it will likely deliver what it claims and
you can pick closer to your actual ratings.  Of course, that cheapo P/S
will likely fail you at some point.  That means risking losing a lot
more than just the P/S too.  It could mean a new CPU, mobo, memory and
whatever else it takes with it.  When cutting costs, protection is one
place to do it and by the time you realize it, it's to late.  I've
bought cases with P/Ss built in.  They get removed and disassembled for
little junky projects.  I mostly get heat sinks and such since most of
the components aren't reliable anyway. 

Hope you get this fixed soon. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Epic list of total FAIL.

[Frank Steinmetzger]

On Sat, Aug 22, 2015 at 06:28:45PM -0500, Dale wrote:

> Alan Grimes wrote:
> > The PSU is an Antec EarthWatts 750.
> >
> > Biggest hoggs outside the motherboard are the, um, er, well [nvidia 980
> > gpu] and an aging Western Digital Velociraptor boot drive. There is also
> > a 3TB drive for all my p***, er kerbals   ( Kerbal Space Program ) .

> It just means your P/S is running at half power most of the time.

Which may be a good idea, since then it’d be running at optimum efficiency.

> On my current P/S, it is a 650 watt unit.  According to my UPS, my entire
> computer system pulls about 150 watts idle and about 160 to 170 when
> compiling the crap out of something like GCC, Libreoffice etc.  Now that
> includes my monitor, router, modem and speakers.  If I were to guess, the
> puter itself only pulls around 100 to 120 watts.

Getting OT here:
Didn’t you say (waay back) that you run AMD? Because in that case those
numbers don’t add up (they also don’t for a medium-range intel). 120 W @
idle (which in itself is a lot) and then only 30-ish more for full CPU load?

> My power supply has some overkill issues
> for sure.  I could likely easily use a 300 watt unit but would likely
> replace with a 400 watt since they are more available.  Technically, I
> could use a 200 watt if the power supply was a well built model.

If only such models were actually available. The lowest value you can get in
a reasonable-quality build is 300 W, which is far too much for silent, small
home PCs for simple usess like office or media centre. Such mini systems
barely reach 20 W. Even at full load they won’t get past 60 or 70 W. This is
just at the start of the 80+ efficiency range wich begins at 20%.

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

The problem with Perl jokes is that only the teller understands them.

Re: [gentoo-user] Re: Epic list of total FAIL.

[Dale]

Frank Steinmetzger wrote:
> On Sat, Aug 22, 2015 at 06:28:45PM -0500, Dale wrote:
>
>> Alan Grimes wrote:
>>> The PSU is an Antec EarthWatts 750.
>>>
>>> Biggest hoggs outside the motherboard are the, um, er, well [nvidia 980
>>> gpu] and an aging Western Digital Velociraptor boot drive. There is also
>>> a 3TB drive for all my p***, er kerbals   ( Kerbal Space Program ) .
>> It just means your P/S is running at half power most of the time.
> Which may be a good idea, since then it’d be running at optimum efficiency.


Yep.  I would not buy a P/S that didn't have at least 30 or 40% of
headroom.  If nothing else, as the P/S ages, it wouldn't be so stressed
on those older components.  Also, I would only do that if I know I won't
ever add to that rig.  I usually aim for half load or even a little
less.  I almost always end up adding something or upgrading something
before I retire a system. 


>
>> On my current P/S, it is a 650 watt unit.  According to my UPS, my entire
>> computer system pulls about 150 watts idle and about 160 to 170 when
>> compiling the crap out of something like GCC, Libreoffice etc.  Now that
>> includes my monitor, router, modem and speakers.  If I were to guess, the
>> puter itself only pulls around 100 to 120 watts.
> Getting OT here:
> Didn’t you say (waay back) that you run AMD? Because in that case those
> numbers don’t add up (they also don’t for a medium-range intel). 120 W @
> idle (which in itself is a lot) and then only 30-ish more for full CPU load?
>

I got those numbers from the UPS.  Just for giggles, I disconnected my
A/C, plugged the UPS into that plug and measured them with a clamp on
meter at the breaker box.  Doing the math, I got about the same numbers
as the UPS gives me.  The difference might run a night light, maybe. 
The most I have ever seen this system pull is about 200 watts.  I think
I was printing and doing some updates at the same time.  I remember
thinking about that being the biggest load I ever seen.   Oh, my A/C is
on a dedicated circuit.  Nothing else is on that line.  The plug the UPS
usually plugs into only has my TV and some lights on it. 

From the UPS and confirmed by a clamp on meter just in the past few
minutes. 

Idle:  146 watts
Load, well into a gcc compile with all four cores running at close to
100% and drive activity:  186 watts

Keep in mind, my A/C is off and it's warming up here.  If I listen
close, I can tell the fans are spinning a bit faster.  Of course, it's
hard to hear those huge fans.  That HAF-932 is quiet but still moves a
lot of air.


>> My power supply has some overkill issues
>> for sure.  I could likely easily use a 300 watt unit but would likely
>> replace with a 400 watt since they are more available.  Technically, I
>> could use a 200 watt if the power supply was a well built model.
> If only such models were actually available. The lowest value you can get in
> a reasonable-quality build is 300 W, which is far too much for silent, small
> home PCs for simple usess like office or media centre. Such mini systems
> barely reach 20 W. Even at full load they won’t get past 60 or 70 W. This is
> just at the start of the 80+ efficiency range wich begins at 20%.
>

That was my point.  Most P/Ss that are that size or smaller than that
are either old or junky made.  Basically, something I would not buy or
recommend.  Finding a quality P/S that is 350 or less would be
difficult.  I don't recall seeing any in a long while, not that I have
actually tried to find one tho. 

Keep in mind, I didn't build this system to be green.  When I first
built this thing, I figured it would pull at least double what it
actually does if not much more.  My old rig pulled about 400 watts I
think and it is nothing compared to the speed this rig has.  While
having more processing power, it sure doesn't use more energy. 

Dale

:-)  :-)