Aw: Re: [gentoo-user] Updating portage, continued

[n952162]

Thanks for the good link

> Gesendet: Donnerstag, 30. Mai 2019 um 00:52 Uhr
> Von: "Neil Bothwick" 
> An: gentoo-user@lists.gentoo.org
> Betreff: Re: [gentoo-user] Updating portage, continued
>
> On Thu, 30 May 2019 00:37:14 +0200, n952...@web.de wrote:
>
> > The next section of the response to my attempt to update portage is a
> > long list of packages, each terminated with a "(masked by: something or
> > other)".
> >
> > What does that tell me.  If it's masked, it shouldn't be available,
> > right?  But, I've got it:
> >
> > - virtual/perl-parent-0.234.0-r1::gentoo (masked by: package.mask)
> >
> > ls virtual/perl-parent/perl-parent-0.234.0-r1.ebuild
> > virtual/perl-parent/perl-parent-0.234.0-r1.ebuild
> >
> > Can I get rid of it?  Is perl-parent always masked?
>
> grep perl-parent -r /etc/portage
>
> will tell you whether one of your config files is masking it.
>
> Since you have already admitted not updating config files for quite a
> while, I would tackle that task first, it may remove some of your other
> problems. You should read up on this in the Handbook
> https://wiki.gentoo.org/wiki/Handbook:AMD64/Portage/Tools
>
>
> --
> Neil Bothwick
>
> Guns don't kill people--it's those little pieces of lead.
>

Re: Aw: Re: [gentoo-user] upgrading (profiles, too)

[Dale]

n952...@web.de wrote:
>> Gesendet: Donnerstag, 30. Mai 2019 um 00:20 Uhr
>> Von: "Dale" 
>> I've done upgrades that skip quite a ways using make oldconfig.  I've
>> never had any issues.  If it were me, I'd just make the jump but make
>> sure to keep the old kernel around just in case something doesn't work. 
>> At least that way one can boot it and fix it.
> good idea!
> Is the kernel enough?  Don't you have to have the initrd, and the modules 
> list and all the modules and and and?
>


If you have one, yes you need to save that too.  The biggest thing, make
sure the entry is still in whatever bootloader you use.  I use grub and
it picks them up automatically when I run the updater. 


>> ...  Switch to the
>> new17.1 profile, run emerge -puDN world and see if the changes look OK. 
>> If you don't like or it breaks something, switch to 17.0 and run emerge
>> -puDN world and see what it looks like.  Pick the one that you feel
>> safest with.  ...
> I haven't a clue what unsafe is...
>
>


I haven't tested the 17.1 profile yet.  If you are unsure, I'd just use
17.0 and wait until 17.1 is released. 

Dale

:-)  :-) 

Re: Re: [gentoo-user] upgrading (profiles, too)

[Adam Carter]

On Thu, May 30, 2019 at 8:41 AM  wrote:

> > Gesendet: Donnerstag, 30. Mai 2019 um 00:20 Uhr
> > Von: "Dale" 
> > I've done upgrades that skip quite a ways using make oldconfig.  I've
> > never had any issues.  If it were me, I'd just make the jump but make
> > sure to keep the old kernel around just in case something doesn't work.
> > At least that way one can boot it and fix it.
>
> good idea!
> Is the kernel enough?  Don't you have to have the initrd, and the modules
> list and all the modules and and and?
>
>
https://wiki.gentoo.org/wiki/Kernel/Upgrade should help.


>
> > ...  Switch to the
> > new17.1 profile, run emerge -puDN world and see if the changes look OK.
> > If you don't like or it breaks something, switch to 17.0 and run emerge
> > -puDN world and see what it looks like.  Pick the one that you feel
> > safest with.  ...
>
> I haven't a clue what unsafe is...
>
> Pick the one that most closely matches your requirements.

Re: [gentoo-user] slot conflict when updating portage

[Neil Bothwick]

On Thu, 30 May 2019 00:52:31 +0200, n952...@web.de wrote:

> !!! Your current profile is deprecated and not supported anymore.
> !!! Use eselect profile to update your profile.
> !!! Please upgrade to the following profile if possible:
> 
> default/linux/amd64/17.0/desktop
> 
> You may use the following command to upgrade:
> 
> eselect profile set default/linux/amd64/17.0/desktop
> 
> 
>  * IMPORTANT: 6 news items need reading for repository 'gentoo'.
>  * Use eselect news read to view new items.
> 
> 
>  * IMPORTANT: 26 config files in '/etc/portage' need updating.
>  * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
>  * sections of the emerge man page to learn how to update config files.

You should deal with these issues first. Ignoring news items, failing to
update config files and running a deprecated profile are all good ways of
making problems for yourself.


-- 
Neil Bothwick

C Error #011: First C Program, huh?


pgpooUiKQcWQA.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Updating portage, continued

[Neil Bothwick]

On Thu, 30 May 2019 00:37:14 +0200, n952...@web.de wrote:

> The next section of the response to my attempt to update portage is a
> long list of packages, each terminated with a "(masked by: something or
> other)".
> 
> What does that tell me.  If it's masked, it shouldn't be available,
> right?  But, I've got it:
> 
> - virtual/perl-parent-0.234.0-r1::gentoo (masked by: package.mask)
> 
> ls virtual/perl-parent/perl-parent-0.234.0-r1.ebuild
> virtual/perl-parent/perl-parent-0.234.0-r1.ebuild
> 
> Can I get rid of it?  Is perl-parent always masked?

grep perl-parent -r /etc/portage

will tell you whether one of your config files is masking it.

Since you have already admitted not updating config files for quite a
while, I would tackle that task first, it may remove some of your other
problems. You should read up on this in the Handbook
https://wiki.gentoo.org/wiki/Handbook:AMD64/Portage/Tools


-- 
Neil Bothwick

Guns don't kill people--it's those little pieces of lead.


pgpbDSxZPU4fo.pgp
Description: OpenPGP digital signature

Aw: Re: [gentoo-user] slot conflict when updating portage

[n952162]

Oh, I wish I'd use .txt as an extension.  Here's one in the raw:


10~>sudo emerge   --oneshot portage
Password: 

!!! Your current profile is deprecated and not supported anymore.
!!! Use eselect profile to update your profile.
!!! Please upgrade to the following profile if possible:

default/linux/amd64/17.0/desktop

You may use the following command to upgrade:

eselect profile set default/linux/amd64/17.0/desktop


 * IMPORTANT: 6 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.


 * IMPORTANT: 26 config files in '/etc/portage' need updating.
 * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
 * sections of the emerge man page to learn how to update config files.
Calculating dependencies... done!
[ebuild  N ] app-crypt/openpgp-keys-gentoo-release-20190427  USE="{-test}" 
[ebuild  N ] dev-python/bz2file-0.98  PYTHON_TARGETS="python2_7 (-pypy)" 
[ebuild U  ] dev-libs/libgpg-error-1.29 [1.27-r1]
[ebuild  NS] dev-lang/python-3.6.5 [2.7.14-r1, 3.5.4-r1] USE="gdbm ipv6 
ncurses readline ssl (threads) xml -build -examples -hardened -libressl -sqlite 
{-test} -tk -wininst" 
[ebuild U  ] dev-python/setuptools-40.6.3 [36.7.2] 
PYTHON_TARGETS="python3_6* -python3_5* (-python3_7)" 
[ebuild U  ] dev-python/certifi-2018.4.16 [2017.4.17] 
PYTHON_TARGETS="python3_6* -python3_5* (-python3_7)" 
[ebuild U  ] app-crypt/gnupg-2.2.10 [2.2.4] USE="ssl%*" 
[ebuild  N ] app-portage/gemato-14.1  USE="blake2 bzip2 gpg -lzma -sha3 
{-test} -tools" PYTHON_TARGETS="python2_7 python3_6 (-pypy) -python3_5 
(-python3_7)" 
[ebuild U ~] sys-apps/portage-2.3.67 [2.3.13-r1] USE="rsync-verify%* 
-gentoo-dev%" PYTHON_TARGETS="python3_6* -python3_5* -python3_7%" 

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

sys-apps/portage:0

  (sys-apps/portage-2.3.67:0/0::gentoo, ebuild scheduled for merge) pulled in by
sys-apps/portage (Argument)

  (sys-apps/portage-2.3.13-r1:0/0::gentoo, installed) pulled in by

sys-apps/portage[python_targets_python2_7(-),python_targets_python3_5(-),-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-)]
 required by (app-portage/gentoolkit-0.4.0:0/0::gentoo, installed)




  

dev-python/setuptools:0

  (dev-python/setuptools-40.6.3:0/0::gentoo, ebuild scheduled for merge) pulled 
in by

dev-python/setuptools[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]
 required by (app-portage/gemato-14.1:0/0::gentoo, ebuild scheduled for merge)





   

dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]
 required by (dev-python/certifi-2018.4.16:0/0::gentoo, ebuild scheduled for 
merge)

Aw: Re: [gentoo-user] slot conflict when updating portage

[n952162]

Okay, gladly.  In fact, I ran it 3 times, one after another, because I wasn't 
even sure if there were fatal problems or not ... trying to attach these text 
files...

But I'm going to bed then.  Good night.


> Gesendet: Donnerstag, 30. Mai 2019 um 00:38 Uhr
> Von: "Dale" 
> An: gentoo-user@lists.gentoo.org
> Betreff: Re: [gentoo-user] slot conflict when updating portage
>
> n952...@web.de wrote:
> > !!! Multiple package instances within a single package slot have been pulled
> > !!! into the dependency graph, resulting in a slot conflict:
> >
> > sys-apps/portage:0
> >
> > How should I go about handling this?
> >
> > Slot are explained somewhere as allowing multiple packages to have 
> > different versions of the same providing package.  Why should there be 
> > conflicts?  Is there a limited number of slots or something?  Why is a slot 
> > conflict a problem - each dependent package can use its own slot ...
> >
> > Following this message there are a number of "paragraphs", each introduced 
> > with a line like the "sys-apps/portage:0" line, above.  Each paragraph 
> > contains multiple "clauses", apparently representing different versions of 
> > the package starting the "paragraph"
> >
> > Each seems to be terminated with a status:
> > - argument
> > - installed
> > - ebuild scheduled for merge
> >
> > Where's the problem?
> >
> > There must be a problem because it goes on to say:
> >
> > "It may be possible to solve this problem by using package.mask to
> > prevent one of those packages from being selected. However, it is also
> > possible that conflicting dependencies exist such that they are
> > impossible to satisfy simultaneously.  If such a conflict exists in
> > the dependencies of two different packages, then those packages can
> > not be installed simultaneously."
> >
> > I can solve the problem by preventing *one* of the packages from being 
> > selected?
> > Let's see, I have 3 such paragraphs, two with 2 clauses each and one with 6 
> > clauses.  If I pick one, everything will be fine?
> >
> > It then suggests looking at the MASKED PACKAGES section of the emerge man 
> > page.  But that has to do with experimental or development packages.  My 
> > profile is "stable" - there's no reason why I should have any of those, is 
> > there?
> >
> > It goes on, but I think those are other issues which I will raise in a 
> > subsequent post.
> >
> >
> 
> 
> You need to post the whole output so others can see what is causing the
> conflict.  There are a few on this list who are very good at parsing the
> output and finding a way to work through it. 
> 
> Dale
> 
> :-) :-) 
> 
>

emerge-0.out
Description: Binary data


emerge-1.out
Description: Binary data


emerge-2.out
Description: Binary data

[gentoo-user] Updating portage, continued

[n952162]

The next section of the response to my attempt to update portage is a long list 
of packages, each terminated with a "(masked by: something or other)".

What does that tell me.  If it's masked, it shouldn't be available, right?  
But, I've got it:

- virtual/perl-parent-0.234.0-r1::gentoo (masked by: package.mask)

ls virtual/perl-parent/perl-parent-0.234.0-r1.ebuild
virtual/perl-parent/perl-parent-0.234.0-r1.ebuild

Can I get rid of it?  Is perl-parent always masked?

Aw: Re: [gentoo-user] upgrading (profiles, too)

[n952162]

> Gesendet: Donnerstag, 30. Mai 2019 um 00:20 Uhr
> Von: "Dale" 
> I've done upgrades that skip quite a ways using make oldconfig.  I've
> never had any issues.  If it were me, I'd just make the jump but make
> sure to keep the old kernel around just in case something doesn't work. 
> At least that way one can boot it and fix it.

good idea!
Is the kernel enough?  Don't you have to have the initrd, and the modules list 
and all the modules and and and?


> ...  Switch to the
> new17.1 profile, run emerge -puDN world and see if the changes look OK. 
> If you don't like or it breaks something, switch to 17.0 and run emerge
> -puDN world and see what it looks like.  Pick the one that you feel
> safest with.  ...

I haven't a clue what unsafe is...

Re: [gentoo-user] slot conflict when updating portage

[Dale]

n952...@web.de wrote:
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
>
> sys-apps/portage:0
>
> How should I go about handling this?
>
> Slot are explained somewhere as allowing multiple packages to have different 
> versions of the same providing package.  Why should there be conflicts?  Is 
> there a limited number of slots or something?  Why is a slot conflict a 
> problem - each dependent package can use its own slot ...
>
> Following this message there are a number of "paragraphs", each introduced 
> with a line like the "sys-apps/portage:0" line, above.  Each paragraph 
> contains multiple "clauses", apparently representing different versions of 
> the package starting the "paragraph"
>
> Each seems to be terminated with a status:
> - argument
> - installed
> - ebuild scheduled for merge
>
> Where's the problem?
>
> There must be a problem because it goes on to say:
>
> "It may be possible to solve this problem by using package.mask to
> prevent one of those packages from being selected. However, it is also
> possible that conflicting dependencies exist such that they are
> impossible to satisfy simultaneously.  If such a conflict exists in
> the dependencies of two different packages, then those packages can
> not be installed simultaneously."
>
> I can solve the problem by preventing *one* of the packages from being 
> selected?
> Let's see, I have 3 such paragraphs, two with 2 clauses each and one with 6 
> clauses.  If I pick one, everything will be fine?
>
> It then suggests looking at the MASKED PACKAGES section of the emerge man 
> page.  But that has to do with experimental or development packages.  My 
> profile is "stable" - there's no reason why I should have any of those, is 
> there?
>
> It goes on, but I think those are other issues which I will raise in a 
> subsequent post.
>
>


You need to post the whole output so others can see what is causing the
conflict.  There are a few on this list who are very good at parsing the
output and finding a way to work through it. 

Dale

:-) :-) 

[gentoo-user] slot conflict when updating portage

[n952162]

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

sys-apps/portage:0

How should I go about handling this?

Slot are explained somewhere as allowing multiple packages to have different 
versions of the same providing package.  Why should there be conflicts?  Is 
there a limited number of slots or something?  Why is a slot conflict a problem 
- each dependent package can use its own slot ...

Following this message there are a number of "paragraphs", each introduced with 
a line like the "sys-apps/portage:0" line, above.  Each paragraph contains 
multiple "clauses", apparently representing different versions of the package 
starting the "paragraph"

Each seems to be terminated with a status:
- argument
- installed
- ebuild scheduled for merge

Where's the problem?

There must be a problem because it goes on to say:

"It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously."

I can solve the problem by preventing *one* of the packages from being selected?
Let's see, I have 3 such paragraphs, two with 2 clauses each and one with 6 
clauses.  If I pick one, everything will be fine?

It then suggests looking at the MASKED PACKAGES section of the emerge man page. 
 But that has to do with experimental or development packages.  My profile is 
"stable" - there's no reason why I should have any of those, is there?

It goes on, but I think those are other issues which I will raise in a 
subsequent post.

Re: [gentoo-user] Fw: updating /etc/package.accept_keywords

[Dale]

n952...@web.de wrote:
> And, what are the consequences that I'm suffering, that I haven't done that 
> before, for over a year?
>
>> Gesendet: Mittwoch, 29. Mai 2019 um 23:55 Uhr
>> Von: n952...@web.de
>> An: gentoo-user@lists.gentoo.org
>> Betreff: updating /etc/package.accept_keywords
>>
>> I have many files like ._cfg_package.accept_keywords.
>> Is the right way to handle this to do something like:
>>
>> sort -u ._cfg_package.accept_keywords >| package.accept_keywords
>


Look into etc-update, dispatch-conf and other commands that help with
updating those.  I admit, I'm bad to let them sit to because I usually
manually update important stuff.  I don't wait that long tho.  Keep in
mind, there is a small chance that a bad config could result in
something not working when you reboot or not being able to completely
boot at all.  It depends on what files are not updated. 

Hope that helps.

Dale

:-)  :-) 

Re: [gentoo-user] upgrading (profiles, too)

[Dale]

Michael Jones wrote:
>
>
> On Wed, May 29, 2019 at 2:46 PM  > wrote:
>
> Hi,
>
> I'm currently at 4.14.65-gentoo and I understand my cheap hp
> laptop's amdgpu could finally get better support if I upgrade to
> 4.16 or 4.17.1.
> Can I just do that, or would it be better (or even possible) to go
> in smaller increments?
>
> Also, something's always complaining to me about my profile,
> default/linux/amd64/13.0/desktop, being out-of-date.  Should I
> upgrade to 17 at the same time?  I've seen lots about the
> differences between different types of profiles but not about the
> differences between different versions of a profile type.  What's
> different?
>
> Thanks for any thoughts.
>
>
> You can change kernel versions in any way you see fit. You're unlikely
> to run into any significant issues from upgrading by 2 or 3 releases
> at once.

I've done upgrades that skip quite a ways using make oldconfig.  I've
never had any issues.  If it were me, I'd just make the jump but make
sure to keep the old kernel around just in case something doesn't work. 
At least that way one can boot it and fix it.


>
> My personal recommendation is to conduct the profile update as a
> separate task from the kernel update, simply because they are not
> really related to each other.
>

I would do them separately as well.  I'm not sure if it matters but I
might would do the profile upgrade first.  I'm not sure why but my brain
is making me think that may be a better way.  Generally, profile changes
don't change a whole lot.  Also, I think 17.1 is coming soon and 17.0
will be leaving.  If one feels safe doing it, it may be worth going
straight to 17.1.  That way one wouldn't have to do the same thing again
soon-ish.  It's marked as dev but this is what I'd do.  Switch to the
new17.1 profile, run emerge -puDN world and see if the changes look OK. 
If you don't like or it breaks something, switch to 17.0 and run emerge
-puDN world and see what it looks like.  Pick the one that you feel
safest with.  Just keep in mind, 17.1 is coming at some point.

Just my thoughts.

Dale

:-)  :-) 

[gentoo-user] updating /etc/package.accept_keywords

[n952162]

I have many files like ._cfg_package.accept_keywords.
Is the right way to handle this to do something like:

sort -u ._cfg_package.accept_keywords >| package.accept_keywords

[gentoo-user] Fw: updating /etc/package.accept_keywords

[n952162]

And, what are the consequences that I'm suffering, that I haven't done that 
before, for over a year?

> Gesendet: Mittwoch, 29. Mai 2019 um 23:55 Uhr
> Von: n952...@web.de
> An: gentoo-user@lists.gentoo.org
> Betreff: updating /etc/package.accept_keywords
>
> I have many files like ._cfg_package.accept_keywords.
> Is the right way to handle this to do something like:
>
> sort -u ._cfg_package.accept_keywords >| package.accept_keywords

Re: [gentoo-user] upgrading (profiles, too)

[Michael Jones]

On Wed, May 29, 2019 at 2:46 PM  wrote:

> Hi,
>
> I'm currently at 4.14.65-gentoo and I understand my cheap hp laptop's
> amdgpu could finally get better support if I upgrade to 4.16 or 4.17.1.
> Can I just do that, or would it be better (or even possible) to go in
> smaller increments?
>
> Also, something's always complaining to me about my profile,
> default/linux/amd64/13.0/desktop, being out-of-date.  Should I upgrade to
> 17 at the same time?  I've seen lots about the differences between
> different types of profiles but not about the differences between different
> versions of a profile type.  What's different?
>
> Thanks for any thoughts.
>
>
You can change kernel versions in any way you see fit. You're unlikely to
run into any significant issues from upgrading by 2 or 3 releases at once.

My personal recommendation is to conduct the profile update as a separate
task from the kernel update, simply because they are not really related to
each other.

[gentoo-user] upgrading (profiles, too)

[n952162]

Hi,

I'm currently at 4.14.65-gentoo and I understand my cheap hp laptop's amdgpu 
could finally get better support if I upgrade to 4.16 or 4.17.1.
Can I just do that, or would it be better (or even possible) to go in smaller 
increments?

Also, something's always complaining to me about my profile, 
default/linux/amd64/13.0/desktop, being out-of-date.  Should I upgrade to 17 at 
the same time?  I've seen lots about the differences between different types of 
profiles but not about the differences between different versions of a profile 
type.  What's different?

Thanks for any thoughts.

Re: [gentoo-user] emerge with alternate ROOT=

[Corentin “Nado” Pazdera]

May 28, 2019 9:20 PM, "tedheadster"  wrote:

> I am having problems trying to rebuild a slave disk with ROOT=/mnt/gentoo.
> 
> While it is _sort_ of working, it does something very unexpected. It
> rebuilds 154 packages on the _host_ system.
> 
> Oddly, it does notice that I have different CFLAGS set in
> /etc/portage/make.conf and rebuilds the host system packages
> correctly. But why does it rebuild them at all?
> 
> Here is a sample of the emerge output:
> 
> [ebuild R ] sys-apps/systemd-241-r1 to /mnt/gentoo/
> [ebuild R ] sys-process/procps-3.3.15-r1 to /mnt/gentoo/
> [ebuild R ] sys-apps/gentoo-systemd-integration-7 to /mnt/gentoo/
> [ebuild R ] virtual/service-manager-0 to /mnt/gentoo/
> [ebuild R ] sys-apps/attr-2.4.47-r2
> [ebuild R ] sys-devel/patch-2.7.6-r3
> [ebuild R ] sys-apps/systemd-241-r1
> [ebuild R ] sys-apps/gentoo-systemd-integration-7
> 
> Why the heck is the _host_ sys-apps/systemd being recompiled?
> 
> Here is my command:
> 
> export ROOT="/mnt/gentoo"
> export DISTDIR="/mnt/gentoo/usr/portage/distfiles"
> export PKGDIR="/mnt/gentoo/usr/portage/packages"
> export PORTAGE_CONFIGROOT="/mnt/gentoo/"
> export PORTAGE_TMPDIR="/var/tmp"
> export PORTDIR="/mnt/gentoo/usr/portage"
> export EMERGE_LOG_DIR="/mnt/gentoo/var/log"
> 
> emerge --root=/mnt/gentoo --root-deps --color n --ask -e @world
> 
> - Matthew

Hi,

Are any of them listed as build time dependency perhaps?
If there are then they will be built for the host as it the host who's 
compiling and needs them.

Kind regards,
Corentin “Nado” Pazdera

Re: [gentoo-user] sys-apps/dtc-1.5.0 install failure

[Jack]

On 2019.05.29 11:41, k...@aspodata.se wrote:

Francesco Turco:
> On Wed, May 29, 2019, at 13:30, k...@aspodata.se wrote:
> > Part of portage_tmpdir/portage/sys-apps/dtc-1.5.0/temp/build.log:
> > ...
...
> > copying build/lib.linux-x86_64-2.7/libfdt.py ->
> > /usr/lib64/python2.7/site-packages
> >  * ACCESS DENIED:  fopen_wr:
> > /usr/lib64/python2.7/site-packages/libfdt.py
> > error: [Errno 13] Permission denied:
...
> > Why does the install fail, I have no problem creating that file  
by hand

> > (as in touch ), why does a simple thing like copy fail ?
>
> I don't know how to solve this problem, but it has already been  
reported:

>
> https://bugs.gentoo.org/686852

Thanks for the info.
In the meantime you can walk around the problem by not using the
sandbox like:

FEATURES="-sandbox -usersandbox" emerge -aqv sys-apps/dtc

Regards,
/Karl Hammar
That's weird.  It emerges fine for me, with no error or complaint, and  
I certainly have sandbox enabled.  (I have other packages that fail due  
to sandbox write errors, but not this one.)
Note one difference between this report (the failed file is libfdt.py)  
and the bug report (file is _libdft.so).  Also, my  
/usr/lib64/python2.7/site-packages has no files at all "*fdt*".


Jack

Re: [gentoo-user] sys-apps/dtc-1.5.0 install failure

[karl]

Francesco Turco:
> On Wed, May 29, 2019, at 13:30, k...@aspodata.se wrote:
> > Part of portage_tmpdir/portage/sys-apps/dtc-1.5.0/temp/build.log:
> > ...
...
> > copying build/lib.linux-x86_64-2.7/libfdt.py -> 
> > /usr/lib64/python2.7/site-packages
> >  * ACCESS DENIED:  fopen_wr: 
> > /usr/lib64/python2.7/site-packages/libfdt.py
> > error: [Errno 13] Permission denied: 
...
> > Why does the install fail, I have no problem creating that file by hand 
> > (as in touch ), why does a simple thing like copy fail ?
> 
> I don't know how to solve this problem, but it has already been reported:
> 
> https://bugs.gentoo.org/686852

Thanks for the info.
In the meantime you can walk around the problem by not using the 
sandbox like:

FEATURES="-sandbox -usersandbox" emerge -aqv sys-apps/dtc

Regards,
/Karl Hammar

Re: [gentoo-user] sys-apps/dtc-1.5.0 install failure

[Francesco Turco]

On Wed, May 29, 2019, at 13:30, k...@aspodata.se wrote:
> Part of portage_tmpdir/portage/sys-apps/dtc-1.5.0/temp/build.log:
> ...
> x86_64-pc-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,--as-needed -L. 
> -Wl,-O1 -Wl,--as-needed -O2 -pipe -fPIC -Wall -Wpointer-arith 
> -Wcast-qual -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes 
> -Wredundant-decls -Wshadow -I/usr/include/valgrind -fPIC -Wall 
> -Wpointer-arith -Wcast-qual -Wnested-externs -Wstrict-prototypes 
> -Wmissing-prototypes -Wredundant-decls -Wshadow -I/usr/include/valgrind 
> build/temp.linux-x86_64-2.7/libfdt_wrap.o -L../libfdt -L/usr/lib64 
> -lfdt -lpython2.7 -o build/lib.linux-x86_64-2.7/_libfdt.so
> running install_lib
> copying build/lib.linux-x86_64-2.7/libfdt.py -> 
> /usr/lib64/python2.7/site-packages
>  * ACCESS DENIED:  fopen_wr: 
> /usr/lib64/python2.7/site-packages/libfdt.py
> error: [Errno 13] Permission denied: 
> '/usr/lib64/python2.7/site-packages/libfdt.py'
> make[1]: *** [pylibfdt/Makefile.pylibfdt:24: install_pylibfdt] Error 1
> make[1]: Leaving directory 
> '/Net/portage_tmpdir/portage/sys-apps/dtc-1.5.0/work/dtc-1.5.0'
> make: *** [Makefile:231: maybe_install_pylibfdt] Error 2
>  * ERROR: sys-apps/dtc-1.5.0::gentoo failed (install phase):
>  *   emake failed
>  * 
> ...
> 
> Why does the install fail, I have no problem creating that file by hand 
> (as in touch ), why does a simple thing like copy fail ?

I don't know how to solve this problem, but it has already been reported:

https://bugs.gentoo.org/686852

-- 
https://fturco.gitlab.io/

[gentoo-user] sys-apps/dtc-1.5.0 install failure

[karl]

Part of portage_tmpdir/portage/sys-apps/dtc-1.5.0/temp/build.log:
...
x86_64-pc-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,--as-needed -L. -Wl,-O1 
-Wl,--as-needed -O2 -pipe -fPIC -Wall -Wpointer-arith -Wcast-qual 
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls 
-Wshadow -I/usr/include/valgrind -fPIC -Wall -Wpointer-arith -Wcast-qual 
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls 
-Wshadow -I/usr/include/valgrind build/temp.linux-x86_64-2.7/libfdt_wrap.o 
-L../libfdt -L/usr/lib64 -lfdt -lpython2.7 -o 
build/lib.linux-x86_64-2.7/_libfdt.so
running install_lib
copying build/lib.linux-x86_64-2.7/libfdt.py -> 
/usr/lib64/python2.7/site-packages
 * ACCESS DENIED:  fopen_wr: /usr/lib64/python2.7/site-packages/libfdt.py
error: [Errno 13] Permission denied: 
'/usr/lib64/python2.7/site-packages/libfdt.py'
make[1]: *** [pylibfdt/Makefile.pylibfdt:24: install_pylibfdt] Error 1
make[1]: Leaving directory 
'/Net/portage_tmpdir/portage/sys-apps/dtc-1.5.0/work/dtc-1.5.0'
make: *** [Makefile:231: maybe_install_pylibfdt] Error 2
 * ERROR: sys-apps/dtc-1.5.0::gentoo failed (install phase):
 *   emake failed
 * 
...

Why does the install fail, I have no problem creating that file by hand 
(as in touch ), why does a simple thing like copy fail ?

Have it something with sandboxing to do ?

How do I go arond this ?

Regards,
/Karl Hammar

Re: [gentoo-user] point and click in vim stopped working

[Raffaele Belardi]

Raffaele Belardi wrote:

Philip Webb wrote:

190523 Raffaele Belardi wrote:

No problem with Gvim.  With raw Vim in a Konsole or Xterm
scrolling moves the pointer  3  lines, but clicking doesn't move it ;
with ':set mouse=a' in raw Vim, the pointer moves with a click,
but scrolling scrolls the full display.

If you want to use a mouse with Vim, why don't you use Gvim ?
I've had a desktop devoted to Gvim always open for many years.



I guess I'll need to downgrade packages till I find the one causing the change in the 
behaviour. I was thinking to start with vim and libinput.


Looks like it's a terminal issue, not vim. Same vim version executed from urxvt instead of 
lxterminal has no problems with point and click.


raffaele