| 1 |
> On 2018-06-26, at 16:18, Jack <ostroffjh@×××××××××××××××××.net> wrote: |
| 2 |
> |
| 3 |
> On 2018.06.26 15:44, Christoph Böhmwalder wrote: |
| 4 |
>> On Tue, Jun 26, 2018 at 03:15:09PM -0400, Andrew Udvare wrote: |
| 5 |
>> > It should not be accessing this location in any case. What is the environment like? What does env show? emerge --config output? |
| 6 |
>> > |
| 7 |
>> > It would almost seem like you have $HOME set to /home/christoph while Portage is running (as root). |
| 8 |
>> The only thing that stands out about `env` is that XDG_CONFIG_HOME is set to /home/christoph/.config (running as root). I'm not sure if it's supposed to be this way, but I didn't find anything in my dotfiles that would suggest that I'm overwriting it. |
| 9 |
> That's a normal setting for you. The problem is that when you did sudo or su to run emerge, it simply stayed in the environment, causing this problem. When you su or sudo to run emerge (or just log in directly as root) you need to be sure to do so in a way that cleans out your environment. I keep thinking to file a bug to request emerge to sanitize the environment, or at least add an option to make it do so. I often forget to use them, but I created scripts (cleanemerge and cleanebuild) to do that for me. |
| 10 |
|
| 11 |
I had a similar issue with BC_ENV_ARGS being set while running Portage. If you have this set, some packages (I forget which) that use bc will try to read your .bcrc file and they will most likely fail. The scripts I used to use would unset this variable before calling emerge. |
| 12 |
|
| 13 |
I wrote Pezu ( https://github.com/Tatsh/pezu ) as a replacement for said scripts. It isolates the environment automatically since everything is run with the Subprocess module in Python (which does not inherit the environment by default). I run into less issues this way. |
| 14 |
|
| 15 |
Andrew |
Archives