Re: [gentoo-user] Re: Problem understanding "eix"

[james]

On 4/22/20 6:41 AM, Dr Rainer Woitok wrote:
> Martin,
>
> On Tuesday, 2020-04-21 18:02:37 -0000, you wrote:
>
>> ...
>> DEFAULT_ARCH is normally not used, because it should be set in
>> the profile. Does
>>    eix --print ARCH
>> also show amd64?
>
> BINGO!  No, it doesn't:
>
>     $ eix --print ARCH
>     x86_64
>     $
>
> And that rings a bell: for historical reasons my "~/.profile" initializ-
> ation script contains the line
>
>     export ARCH=$(arch || uname -m) 2> /dev/null
>
> which helped me  getting my  personal environment right  on every of the
> computing center's zillions of hosts I had to login in my previous life.
>
> Thankyou so much for hunting this down for me :-)
>
> But unsetting ARCH  or setting it to amd64  doesn't change things, prob-
> ably because  the wrong value meanwhile  is part of the database used by
> "eix".  Will it suffice to run "eix-update" with "ARCH" being unset?
>
>> ...
>>>     app-crypt/tpm2-tss	2.2.3-r2	1 1
>>>     app-crypt/tpm2-tss	2.3.3	1 1
>>
>> This is strange: Both versions are only ~amd64, and in your previous
>> posting the output for {isstable} was indeed 0.
>
> No.  It was only 0 in the output of the "installedversions" call, where-
> as the lines quoted above  originated from the "availableversions" call.
> And the problem is  that "{isstable}"  and "{isunstable}"  must not be 1
> at the same time, even if ARCH is erroneously set to "x86_64".
>
> So this might finally be a bug in "eix" ...
>
> Sincerely,
>    Rainer
>

Hello Rainer,
'
I'd install and check out the latest version of 'eix' (0.33.11) on my 
sytems; but I have not updated in over a week. Often bugs are fix and 
the fix is first available in the latest version of the (gentoo) 
package. If no fix, then file a bug; or at least that's how I roll.

Not a recommendation, just what "I" do.

try 'eix -R eix'

hth,
James