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