[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] SHA-1 has just been broken

[Miroslav Rovis]

On 170227-21:59-0500, Rich Freeman wrote:
> On Mon, Feb 27, 2017 at 8:10 PM, Miroslav Rovis
>  wrote:
> > Apologies for my not being able to reply sooner!
> >
> > On 170227-18:18+0300, Andrew Savchenko wrote:
> >
> >> > And via a new private big business, the Github. Giving over all users to
> >> > big Github brother.
> >>
> >> ???
> >> Github is entirely optional and is only for those who want to use it
> >> (we have both users and devs willing so), but in no way anyone
> >> demands its usage.
> > Yeah! Still, it would be great if git was used in distributed way, and
> > not from a central private business...
> >
> 
> Git can pretty-much ONLY be used in a distributed way.
Correct, in that sense. But I didn't express clearly what I meant.

I really meant in this sense (invented quotations in this paragraph):
> Git was intended for everyone to run their own little git server  and
> pull from each other. Git was NOT invented for centralized  commercial
> social networking clouds such as github!

That was from:
https://wiki.gentoo.org/wiki/Overlay:Youbroketheinternet

> In the sync
> workflow github is basically just a mirror.  A lot of our mirrors are
> run by private businesses, and nobody knows what OS they're even
> hosted on, let alone whether the firmware and CPU microcode are FOSS
> along with their hard drive firmware.
I understand that. And I support any honess business. What I hate is
examples like Google, Oracle, Microsoft, IBM is a little more honest, I
think... The few at the control of those ruined so much in computing and
the internet.

GNU and FOSS, to lesser extent OSi, are good, even beautiful, socially
and philosophically.

> As far as distribution goes I think github is the wrong thing to worry
> about.  What you want is traceable signatures from dev to user.  Once
> you have that you can download from an NSA mirror and there shouldn't
> be any risk.  All a mirror does is replicate data, and if
> modifications are detectable the worst they can do is a DoS.
I see. 
> Most of the concerns that people tend to have with github is that you
> can become dependent on them for issue and pull request tracking and
> then if they decide to pull the plug you lose all that data.  We try
> to minimize the use of these features and not make it a core part of
> the dev workflow.
Good practice!

> But, we do use pull requests and in theory we could
> lose those someday.  The actual code itself gets pushed to the Gentoo
> infra Repo from a developer's box using plain old git after they've
> inspected/tested/etc it.  So, there isn't really any way for Github to
> go injecting commits into the repositories we actually use.  I guess
> they could do it for anybody using our github mirrors on the
> distribution side, but that's only because we don't have that all
> locked down and the same issue applies with any other mirror (rsync,
> etc).  Again, you really need end-to-end signature checking to make
> any of these things truly safe.
Absolutely! I did figure that out since long!
> -- 
> Rich
> 

And what I've spent some time doing today, is figuring out about the
info that I finally got from you people!

About time! My rattling was all about whether there was or wasn't a way
to do what is still in the title of that mail that I linked to, and gave
Message-ID of, to do this:

Is it safe to switch from webrsync to the git repo now?

And finally Andrew Shavchenko pointed me to gkeys !

Here's the answer to my query (ah, just the beginning of, my
implementation of it will take time):

emerge -tuDN app-crypt/gkeys app-crypt/gkeys-gen

# equery f gkeys-gen
...
/usr/share/doc/gkeys-gen-0.2/README.md.bz2
...

(
NOTE: The:
/usr/share/doc/gkeys-0.2/README.md.bz2
of the gkeys package is identical.
)

# bzcat /usr/share/doc/gkeys-gen-0.2/README.md.bz2 

Gentoo Keys
---

### About 

 Gentoo Keys is a Python based project that aims to manage the GPG keys used
 for validation on users and Gentoo's infrastracutre servers. Gentoo Keys will 
be able
 to verify GPG keys used for Gentoo's release media, such as installation CD's,
 Live DVD's, packages and other GPG signed documents. It will also be used by
 Gentoo infrastructure to achieve GPG signed git commits in the forthcoming git
 migration of the main CVS tree.

### License

Gentoo Keys is under GPL-2 License
#

But do I read this correctly?:

 ...Gentoo Keys will be able
 to verify GPG keys used for Gentoo's release media, such as installation CD's,
 Live DVD's, packages and other GPG signed documents.

Again, about this (syntactical) object (in the sentence), with other
objects removed:

 ...Gentoo Keys will be able
 to verify GPG keys used for ...
 ... packages...

Does that mean what I read? That with gkeys any user will be able to get
packages via git, and somehow automatically gpg -verify the signature of
each package that (s)he got when (s)he, say:

emerge -tuDN world

?

Does that mean that?

And then, to achieve true