Re: [gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Miroslav Rovis]

I must not abbreviate this time...

On 170228-20:07-0500, Harry Putnam wrote:
> Miroslav Rovis  writes:
> 
> > On 170226-09:42-0500, Harry Putnam wrote:
> >> Stroller  writes:
> > ...
> >> 
> >> > Example at the beginning:  [32;01m * 
> >> > Example from the end:   * 
> >> >
> >> > Output to the terminal these would show the text in different colours,
> >> > but the output was redirected to a textfile or mishandled in a
> >> > copy-paste operation (not sure if screen or tmux does this?).
> >> >
> >> > Running emerge with `--color n` would have made this log much more
> >> > readable. Its size already makes it hard to search.
> >> 
> >> Yes, and I am sorry about that, its just that I could not discern what
> >> parts were important.  Still I should have posted only the last
> >> 400-500 lines.
> >> 
> >> Just so you know... I did try that. [--color n] The resulting log
> >> looked exactly the same.  ...
> >
> > This is hard to believe. I just tried, and either:
> >
> > --color n
> >
> > or:
> >
> > --color=n
> >
> > added to the emerge line, worked.
> >
> 
> Are you looking at the Terminal output?  If so that is not what I
> posted. 
> 
> I did mention that yes `--color n' kills the color in terminal output.
> 
> Read the whole paragraph you quote 1 sentence from above. 
> 
> This is the end of that para:
> 
> ". . . . . . . . . . . . . . . . . . . . . . . . I don't expect
> anyone would have noticed the comment... but it does seem a bit off
> that I see no differernce here.  That is, no difference in the actual
> log emerge creates. I do see the difference in the terminal output."

I see now what you mean (and meant, previously)!

> But as I mentioned what I posted was not the terminal output but the
> actual log that emerge creates for you.. and points you to when a
> failure occurs.
> 
> I just checked it again and I know that is what happens.  That is,
> setting `--color n' kills the color ouput at the terminal however the
> `build.log' still contains all the color sequences.
> 
> I'm already viewed dimly for posting so much junk so rather than post
> samples of both ... I'll leave it for you to try yourself.

No, you're not. Because you corrected your mistake.

(Very busy... got to go.)

Regards!

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature

[gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Harry Putnam]

Peter Humphrey  writes:

> On Monday 27 Feb 2017 10:09:34 Harry Putnam wrote:

Harry wrote:
>> I guess I'll try this once more... Its still a big log but I cleaned
>> up the escapes ... it is a fresh try at building
>>   xf86-video-virtualbox-5.1.14

[...]

Peter replied:
> /lib/modules/4.9.10-gentoo/build/include/linux/compiler.h:305:42: error: 
> uninitialized const member in ‘union atomic_read(const 
> atomic_t*)::’
>   union { typeof(x) __val; char __c[1]; } __u;   \
>
> That's similar to what Stroller found the first time, just not quite the 
> same. It looks like a code error in VirtualBox, but it can't be because I've 
> compiled that version here with no trouble. That means something is awry in 
> your setup.
>
> Have you tried setting -j1? I ask because it looks as though components are 
> being compiled in a different order from the last time.
>
> If I have a useful suggestion after some time for thought, I'll offer it 
> then.

I just posted a response to Stroller's comments you may want to look at
it.  In summary I found a bug about it
( https://bugs.gentoo.org/show_bug.cgi?id=603472 ) 

aside: Just curious; what kernel was in play when you succeeded? 

I see now that I should have read more of the comments.. apparantly
someone wrote a patch... but as of the end of the commentary on Feb
23,  They still say there is not much to be done until upstream works
on it.

(And since I've found my own workaround...(also in reply to Stroller))

>From bug report comments
.
,
| Joakim Tjernlund 2017-02-23 14:54:20 UTC
| 
| (In reply to Lars Wendler (Polynomial-C) from comment #31)
| > Wow, I'm really impressed you guys found a working solution. 
| 
| 
| Thanks :)
| 
| > 
| > Unfortunately patching the kernel cannot be added to the
| > virtualbox-guest-additions ebuilds. So we either need to wait till upstream
| > found a sloution, or you guys find a solution that does not involve patching
| > non-virtualbox software.
| 
| 
| Kernel folks are so far reluctant to include C++ fixes in private kernel
| headers. I think gentoo-sources could carry these until a official fix
| is available but not something I am going push forward.
| 
| You could add the vbox ebuild part now, it wont hurt anything.
| 
| Anyone know what Vbox. people are doing? I haven't found anything.
`

 

[gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Harry Putnam]

Miroslav Rovis  writes:

> On 170226-09:42-0500, Harry Putnam wrote:
>> Stroller  writes:
> ...
>> 
>> > Example at the beginning:  [32;01m * 
>> > Example from the end:   * 
>> >
>> > Output to the terminal these would show the text in different colours,
>> > but the output was redirected to a textfile or mishandled in a
>> > copy-paste operation (not sure if screen or tmux does this?).
>> >
>> > Running emerge with `--color n` would have made this log much more
>> > readable. Its size already makes it hard to search.
>> 
>> Yes, and I am sorry about that, its just that I could not discern what
>> parts were important.  Still I should have posted only the last
>> 400-500 lines.
>> 
>> Just so you know... I did try that. [--color n] The resulting log
>> looked exactly the same.  ...
>
> This is hard to believe. I just tried, and either:
>
> --color n
>
> or:
>
> --color=n
>
> added to the emerge line, worked.
>

Are you looking at the Terminal output?  If so that is not what I
posted. 

I did mention that yes `--color n' kills the color in terminal output.

Read the whole paragraph you quote 1 sentence from above. 

This is the end of that para:

". . . . . . . . . . . . . . . . . . . . . . . . I don't expect
anyone would have noticed the comment... but it does seem a bit off
that I see no differernce here.  That is, no difference in the actual
log emerge creates. I do see the difference in the terminal output."

But as I mentioned what I posted was not the terminal output but the
actual log that emerge creates for you.. and points you to when a
failure occurs.

I just checked it again and I know that is what happens.  That is,
setting `--color n' kills the color ouput at the terminal however the
`build.log' still contains all the color sequences.

I'm already viewed dimly for posting so much junk so rather than post
samples of both ... I'll leave it for you to try yourself.

[gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Harry Putnam]

Stroller  writes:

[...]

> I would be looking primarily at the next point the word "error" comes up 
> properly, which is here: 
>
> from 
> /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.14/work/VirtualBox-5.1.14/src/VBox/Runtime/common/alloc/alloc.cpp:34:
> /lib/modules/4.9.10-gentoo/build/arch/x86/include/asm/atomic.h: In 
> function ‘int atomic_read(const atomic_t*)’:
> /lib/modules/4.9.10-gentoo/build/include/linux/compiler.h:305:42: error: 
> uninitialized const member in ‘union atomic_read(const 
> atomic_t*)::’
>   union { typeof(x) __val; char __c[1]; } __u;   \


First off, thanks for the leg work on this.

Using search terms from your finding:
I did find something that might make some difference on the error you
found (above).

https://bugs.gentoo.org/show_bug.cgi?id=603472

It is a bug already on the bug setup... and one of the heavy hitters
there has this to say:

"Lars Wendler (Polynomial-C)  gentoo-dev 2017-02-08 15:44:54 UTC
This is an issue that - according to upstream - will not be fixed anytime soon.
So I suggest to use 4.4 LTS kernel for Gentoo guests VMs for the time being."

Maybe if I backed up to a 4.4 kernel I'd have better luck.

However, I can report that if USER reinstalls the standard vbox
guest-additions that come with each release of vbox (It can be
initiated by the `Devices' menu on the vbox interface (last item =
Insert Guest additions into cdrom )). (And does it enough times) It
seems to work thereafter, (the needed module is present) assuming that
installation finishes with no errors.

After wards I saw the glad tidings:

reader > sudo lsmod
Module  Size  Used by
vboxvideo  36795  2
vboxguest 201560  4 vboxvideo
ttm69735  1 vboxvideo

It seems to matter when you install the vbox [not from portage]
guest-additions because I did so several times during my efforts to
get X working.  Finally it made a difference.

You are expected to re-install them after any kernel build but I did
that as well and still it only worked after a certain point... maybe
once I managed to get enough stuff installed from emerge.

So, to summarize  It appears you are not likely to get things working
with too new a kernel but can possibly fall back on repeated
reinstalls of the vbox guest-additions.

In my case I've succesfully built a 4.9.10 kernel and managed to get X
working even though two virtual-box packages from portage failed to
build
   x11-drivers/xf86-video-virtualbox-5.1.14
   app-emulations/virtualbox-guest-additionsvirtualbox-guest-additions

So, I've got X up and successfully installed my desktop of choice
lxde.  Things are looking up.

Re: [gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Peter Humphrey]

On Monday 27 Feb 2017 10:09:34 Harry Putnam wrote:

> I guess I'll try this once more... Its still a big log but I cleaned
> up the escapes ... it is a fresh try at building
>   xf86-video-virtualbox-5.1.14
> 
> Still failing in the same way and still not seeing clues in the
> log... probably my own fault.

I see this, starting at line 3324 in your newly attached log:

In file included from /var/tmp/portage/x11-drivers/xf86-video-
virtualbox-5.1.14/work/VirtualBox-5.1.14/include/iprt/types.h:140:0,
 from /var/tmp/portage/x11-drivers/xf86-video-
virtualbox-5.1.14/work/VirtualBox-5.1.14/include/iprt/mem.h:31,
 from /var/tmp/portage/x11-drivers/xf86-video-
virtualbox-5.1.14/work/VirtualBox-5.1.14/src/VBox/Runtime/common/alloc/alloc.cpp:34:
/lib/modules/4.9.10-gentoo/build/arch/x86/include/asm/atomic.h: In function 
‘int atomic_read(const atomic_t*)’:
/lib/modules/4.9.10-gentoo/build/include/linux/compiler.h:305:42: error: 
uninitialized const member in ‘union atomic_read(const 
atomic_t*)::’
  union { typeof(x) __val; char __c[1]; } __u;   \

That's similar to what Stroller found the first time, just not quite the 
same. It looks like a code error in VirtualBox, but it can't be because I've 
compiled that version here with no trouble. That means something is awry in 
your setup.

Have you tried setting -j1? I ask because it looks as though components are 
being compiled in a different order from the last time.

If I have a useful suggestion after some time for thought, I'll offer it 
then.

-- 
Regards
Peter

Re: [gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Peter Humphrey]

On Monday 27 Feb 2017 10:09:34 Harry Putnam wrote:

> I guess I'll try this once more... Its still a big log but I cleaned
> up the escapes ... it is a fresh try at building
>   xf86-video-virtualbox-5.1.14
> 
> Still failing in the same way and still not seeing clues in the
> log... probably my own fault.

I see this, starting at line 3324 in your newly attached log:

In file included from /var/tmp/portage/x11-drivers/xf86-video-
virtualbox-5.1.14/work/VirtualBox-5.1.14/include/iprt/types.h:140:0,
 from /var/tmp/portage/x11-drivers/xf86-video-
virtualbox-5.1.14/work/VirtualBox-5.1.14/include/iprt/mem.h:31,
 from /var/tmp/portage/x11-drivers/xf86-video-
virtualbox-5.1.14/work/VirtualBox-5.1.14/src/VBox/Runtime/common/alloc/alloc.cpp:34:
/lib/modules/4.9.10-gentoo/build/arch/x86/include/asm/atomic.h: In function 
‘int atomic_read(const atomic_t*)’:
/lib/modules/4.9.10-gentoo/build/include/linux/compiler.h:305:42: error: 
uninitialized const member in ‘union atomic_read(const 
atomic_t*)::’
  union { typeof(x) __val; char __c[1]; } __u;   \

That's similar to what Stroller found the first time, just not quite the 
same. It looks like a code error in VirtualBox, but it can't be because I've 
compiled that version here with no trouble. That means something is awry in 
your setup.

Have you tried setting -j1? I ask because it looks as though components are 
being compiled in a different order from the last time.

If I have a useful suggestion after some time for thought, I'll offer it 
then.

-- 
Regards
Peter

[gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Harry Putnam]

Stroller  writes:

>> On 25 Feb 2017, at 14:19, Harry Putnam  wrote:
>> 
>> I've attached a hefty log of some 4000 lines and hope someone will be
>> patient enough to try to identify what is causing the problem. 
>
> I took a look at this, but the broken colour codes throughout the log make it 
> quite hard to read.
>
> Example at the beginning:  [32;01m * 
> Example from the end:   * 
>
> Output to the terminal these would show the text in different colours,
> but the output was redirected to a textfile or mishandled in a
> copy-paste operation (not sure if screen or tmux does this?).
>
> Running emerge with `--color n` would have made this log much more readable. 
> Its size already makes it hard to search.

I guess I'll try this once more... Its still a big log but I cleaned
up the escapes ... it is a fresh try at building
  xf86-video-virtualbox-5.1.14

Still failing in the same way and still not seeing clues in the
log... probably my own fault.



xf86-video-virtualbox-5.1.14_emerge-170227_094550.log.gz
Description: Failed emerge of  xf86-video-virtualbox-5.1.14

[gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Harry Putnam]

Dale  writes:

> Harry Putnam wrote:
>>
>> Just so you know... I did try that. [--color n] The resulting log
>> looked exactly the same.  I posted that fact in an earlier request for
>> help a week or so ago in which I remarked how using the no-color
>> emerge option didn't seem to make a bit of difference. I don't expect
>> anyone would have noticed the comment... but it does seem a bit off
>> that I see no differernce here.  That is, no difference in the actual
>> log emerge creates. I do see the difference in the terminal output.
>>
>>
>>
>
> I think it may be your PS1 variable that is broken.  That is here for me
> at least:
>
> /etc/bash/bashrc
>
> I think it can be in other places as well.  If you recall changing the
> setting, it should look something like this:
>
> PS1+='\[\033[01;31m\]\u@\h \[\033[01;34m\]\w \$ \[\033[00m\]'
>
> It may be that you are missing the ' on the end or some other character
> is missing.  If you copy mine, it will look like this:
>
> root@fireball / #
>
> Either way, you likely just have something missing or out of place and
> it is throwing it off.  Maybe this will help you fix it, maybe. 
>
> Dale
>

I'm a bit lost here.  What makes you think something is broken?

I mean other than than a failed compile of some pkgs?

I guess you mean the fact that there are escapes in the log I
posted...  as I've said that was the log as emerge created it.  The
`build.log' from /var/tmp [...]

my PS1 looks similar with a few diffeneces from yours but the quoting
is intact: See below from the machine where the log was created:


,
| [Intended to pass muster for either USER or ROOT]
| 
| if [ ${UID} -gt 0 ];then
|sign='>'
| else
|sign='#'
| fi
| PS1='\[\033[01;31m\]HOST:\h \[\033[01;32m\]\w\n\u ${sign} 
\[\033[00m\]';export PS1
| 
| PS4='$LINENO: ';export PS4
`

Re: [gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Miroslav Rovis]

On 170226-09:42-0500, Harry Putnam wrote:
> Stroller  writes:
...
> 
> > Example at the beginning:  [32;01m * 
> > Example from the end:   * 
> >
> > Output to the terminal these would show the text in different colours,
> > but the output was redirected to a textfile or mishandled in a
> > copy-paste operation (not sure if screen or tmux does this?).
> >
> > Running emerge with `--color n` would have made this log much more
> > readable. Its size already makes it hard to search.
> 
> Yes, and I am sorry about that, its just that I could not discern what
> parts were important.  Still I should have posted only the last
> 400-500 lines.
> 
> Just so you know... I did try that. [--color n] The resulting log
> looked exactly the same.  ...

This is hard to believe. I just tried, and either:

--color n

or:

--color=n

added to the emerge line, worked.

These:

--color no   # throws help on you

--color=no   # throws help on you

didn't work.

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature

Re: [gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Dale]

Harry Putnam wrote:
>
> Just so you know... I did try that. [--color n] The resulting log
> looked exactly the same.  I posted that fact in an earlier request for
> help a week or so ago in which I remarked how using the no-color
> emerge option didn't seem to make a bit of difference. I don't expect
> anyone would have noticed the comment... but it does seem a bit off
> that I see no differernce here.  That is, no difference in the actual
> log emerge creates. I do see the difference in the terminal output.
>
>
>

I think it may be your PS1 variable that is broken.  That is here for me
at least:

/etc/bash/bashrc

I think it can be in other places as well.  If you recall changing the
setting, it should look something like this:

PS1+='\[\033[01;31m\]\u@\h \[\033[01;34m\]\w \$ \[\033[00m\]'

It may be that you are missing the ' on the end or some other character
is missing.  If you copy mine, it will look like this:

root@fireball / #

Either way, you likely just have something missing or out of place and
it is throwing it off.  Maybe this will help you fix it, maybe. 

Dale

:-)  :-) 

[gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Harry Putnam]

Miroslav Rovis  writes:

> On 170225-09:19-0500, Harry Putnam wrote:
>> Setup: VBox vm running gentoo(amd64) guest on a win-10 (64bit) host
>>  Hardware: HP xw8600 - 2x Xeon  CPU X5450 @ 3.00GHz - 32 GB ram
>> 
>  [ some cca. 80k text cut here ]
>
> Go for the guides, in which you will find that sending 5.5M log in an
> email is plain wrong.

Pretty dim not to have thought of that... thanks.

So do you recommend posting something like that online?  I wasn't
kidding when I said I could not determine what the log might mean,

Do you think there is really any chance a prospective helpful reader
will follow a hyperlink to these massive logs and actually try to see
what is going on?

I've decided to first work out a regex that will allow me to clean the
darn things up... get all those escape sequences out and then post
them on my web pages.

> Read e.g. how to post bugs on Bugzilla. shouldn't be hard to find.

Now, I've often wondered about the question of when to go to the bug
lists.

At my very low skill level chances are good that my problem is
actually some kind of pilot error. So, I think it makes sense to first
try to determine if there is really a bug at all.

Those folks that work on bugs can't be very tickled to get piles of
data that is really about some simple minded pilot error.

Seems to me, something should go thru the list a bit first before
hitting the bug setup... No? Many folks here will know a bug when they
see it, I'm not one of them.

[gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Harry Putnam]

Stroller  writes:

>> On 25 Feb 2017, at 14:19, Harry Putnam  wrote:
>> 
>> I've attached a hefty log of some 4000 lines and hope someone will be
>> patient enough to try to identify what is causing the problem. 
>
> I took a look at this, but the broken colour codes throughout the
> log make it quite hard to read.

Thanks for taking the time ... It was asking quite a lot. 

> Example at the beginning:  [32;01m * 
> Example from the end:   * 
>
> Output to the terminal these would show the text in different colours,
> but the output was redirected to a textfile or mishandled in a
> copy-paste operation (not sure if screen or tmux does this?).
>
> Running emerge with `--color n` would have made this log much more
> readable. Its size already makes it hard to search.

Yes, and I am sorry about that, its just that I could not discern what
parts were important.  Still I should have posted only the last
400-500 lines.

Just so you know... I did try that. [--color n] The resulting log
looked exactly the same.  I posted that fact in an earlier request for
help a week or so ago in which I remarked how using the no-color
emerge option didn't seem to make a bit of difference. I don't expect
anyone would have noticed the comment... but it does seem a bit off
that I see no differernce here.  That is, no difference in the actual
log emerge creates. I do see the difference in the terminal output.

You mentioned `screen' and I am working in a screen terminal.

What you see is the actual log emerge left behind, when the emerge
failed.  Not something copy/pasted. I'm working on something to remove
all that bunk.  When I get to it, I will post a much reduced version
with no escapes. And only including the last 400 lines or so.

My biggest trouble is that I just don't see anything looking like a
clue that I recognize as such in those logs.

I'm not really up on how terminals decode that stuff, But when I do a
`cat' on those logs... into my screen terminal... I see the
highlighted text... no escapes.

Makes it a bit hard to see what my perl script is trying to remove... hehe.