[gentoo-user] Problem understanding "eix"

[gentoo-user] Problem understanding "eix"

[Dr Rainer Woitok]

Greetings,

after several days of manpage reading, head scratching,  and testing the
reactions of "eix" to various input  I'm giving up  and ask the combined
wisdom of the Gentoo list.

Here's the version of "eix" I'm using, my test script, and its output:

   $ eix --version
   0.33.9
   $ cat test-script
   #! /bin/sh
   export EIX_LIMIT=0 OVERLAYS_LIST=false PRINT_COUNT_ALWAYS=never
   export FMT="<category>/<name>\t<version>\t{isstable}1{else}0{} {!isunstable}1{else}0{}\n"
   echo in:
   eix --format '<installedversions:FMT>' \
       --category-name --regex 'app-crypt/tpm2-tss$|acct-group/input'
   echo av:
   eix --format '<availableversions:FMT>' \
       --category-name --regex 'app-crypt/tpm2-tss$|acct-group/input'
   $ ./test-script
   in:
   acct-group/input	0	0 1
   app-crypt/tpm2-tss	2.3.3	0 1
   av:
   acct-group/input	0	1 1
   app-crypt/tpm2-tss	2.2.3-r2	1 0
   app-crypt/tpm2-tss	2.3.3	1 0
   $

And finally here are my questions:

1. Why do the  package properties  "isstable"  and  "!isunstable" differ
   from each other in four out of five output lines?

2. Why does the package property "isstable" return different values, de-
   pending on whether it is called  via the "<installedversions:...>" or
   "<availableversions:...>" property?

3. How can I reliably retrieve the correct information whether a package
   is "stable" or "testing"  for both properties,  "<installedversions>"
   and "<availableversions>"?

Any information appreciated.

Sincerely,
  Rainer

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

[Martin Vaeth]

Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:

> 1. Why do the  package properties  "isstable"  and  "!isunstable" differ
>    from each other in four out of five output lines?

isstable means that a package is ARCH,
isunstable means that it is ~ARCH (for your ARCH).
For other arches there is isalienstable.
Your particular package

>    app-crypt/tpm2-tss	2.3.3	0 1

fails to be ARCH for any value of ARCH, and it is
~ARCH only if ARCH=amd64. So the first 0 is not
surprising. The second value depends on your ARCH;
Since {isunstable} fails, I suppose that your ARCH is not amd64.
If you would use {isalienstable} the test would be positive.

> 2. Why does the package property "isstable" return different values, de-
>    pending on whether it is called  via the "<installedversions:...>" or
>    "<availableversions:...>" property?

installedversion returns the details of the version in /var/db.
Note that there need not even be an ebuild anymore for that version,
so this is really all information which one can rely on for that
version.

But /vat/db does not contain any information whether the version
is stable, unstable, or alienstable, so these tests do not make
any sense for installed versions.

eix does not print an error if you query that information anyway,
but the return value for any such test (isstable, isunstable,
isalienstable, etc) is always empty (false).

> 3. How can I reliably retrieve the correct information whether a package
>    is "stable" or "testing"  for both properties,  "<installedversions>"
>    and "<availableversions>"?

I suppose that this question is answered with the above ones.

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

[Dr Rainer Woitok]

Martin,

On Monday, 2020-04-20 18:21:00 -0000, you wrote:

> ...
> >    app-crypt/tpm2-tss	2.3.3	0 1
> ...
>             The second value depends on your ARCH;
> Since {isunstable} fails, I suppose that your ARCH is not amd64.

   $ eix --dump | grep DEFAULT_ARCH
   DEFAULT_ARCH="amd64"
   $

So no, that's a wrong assumption.

> ...
> installedversion returns the details of the version in /var/db.

You may be right on this one: the description  of the "--installed" opt-
ion in the  "eix" manual page  contains a faint hint  pointing into this
direction by explaining that

   --format '<installedversions:NAMEVERSION>' --pure-packages

would produce the same result as "equery"  while using the "--installed"
option might not.   But the description of  "installedversions:VARIABLE"
farther down just tersly notes  "This is analogous  to availableversions
with the difference that only installed versions are printed".

So it boils down to the question what precisely "analogous" means here.

> ...
> But /vat/db does not contain any information whether the version
> is stable, unstable, or alienstable, so these tests do not make
> any sense for installed versions.

   $ cd /var/db/pkg
   $ cat acct-group/input-0/KEYWORDS app-crypt/tpm2-tss-2.3.3/KEYWORDS |
     xargs -n1 | grep '^~?amd64$'
   amd64
   ~amd64
   $

So the information is clearly there.

> eix does not print an error if you query that information anyway,
> but the return value for any such test (isstable, isunstable,
> isalienstable, etc) is always empty (false).

From that it follows that the "isstable" and "isunstable" properties may
both return "0" at the same time  because the information just isn't av-
ailable, but may never both return "1".   So for clarity I slightly mod-
ified my test script  by removing the  "!" prefix  from the "isunstable"
property:

   $ cat test-script
   #! /bin/sh
   export EIX_LIMIT=0 OVERLAYS_LIST=false PRINT_COUNT_ALWAYS=never
   export FMT="<category>/<name>\t<version>\t{isstable}1{else}0{} {isunstable}1{else}0{}\n"
   echo in:
   eix --format '<installedversions:FMT>' \
       --category-name --regex 'app-crypt/tpm2-tss$|acct-group/input'
   echo av:
   eix --format '<availableversions:FMT>' \
       --category-name --regex 'app-crypt/tpm2-tss$|acct-group/input'
   $ ./test-script
   in:
   acct-group/input	0	0 0
   app-crypt/tpm2-tss	2.3.3	0 0
   av:
   acct-group/input	0	1 0
   app-crypt/tpm2-tss	2.2.3-r2	1 1
   app-crypt/tpm2-tss	2.3.3	1 1
   $

So it seems that  even though the information  is available in "/var/db/
pkg/" "eix" just doesn't look there when processing "installedversions".
This may be a documentation problem rather than a bug (even though I my-
self would prefer a correction in "eix" itself rather than in its docum-
entation :-).   The manual mentions in another place that the  "test for
markedversions always fails  in the context of <installedversions:...>",
but aparently there are also other properties  than just "markedversion"
that always fail in this context.

But why does "<availableversions:...>"  only return a correct result for
installed  virtual package  "acct-group/input-0"  but incorrect  results
(stable and unstable at the same time) for both, the not installed pack-
age "app-crypt/tpm2-tss-2.2.3-r2"  and the installed package "app-crypt/
tpm2-tss-2.3.3"?

Still puzzled :-/

Sincerely,
  Rainer

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

[Martin Vaeth]

Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
> Martin,
>
> On Monday, 2020-04-20 18:21:00 -0000, you wrote:
>
>> ...
>> >    app-crypt/tpm2-tss	2.3.3	0 1
>> ...
>>             The second value depends on your ARCH;
>> Since {isunstable} fails, I suppose that your ARCH is not amd64.
>
>    $ eix --dump | grep DEFAULT_ARCH
>    DEFAULT_ARCH="amd64"
>    $
>
> So no, that's a wrong assumption.

DEFAULT_ARCH is normally not used, because it should be set in
the profile. Does
  eix --print ARCH
also show amd64?

> farther down just tersly notes  "This is analogous  to availableversions
> with the difference that only installed versions are printed".
>
> So it boils down to the question what precisely "analogous" means

It means that it refers to the installed versions (which have a
different set of data than the available versions).

>    $ cat acct-group/input-0/KEYWORDS app-crypt/tpm2-tss-2.3.3/KEYWORDS |
>      xargs -n1 | grep '^~?amd64$'
>    amd64
>    ~amd64
>    $
>
> So the information is clearly there.

Yes, but it has no meaning (except in *.tbz2 files).
Therefore eix ignores it. There are no plans to change this.

>    export FMT="<category>/<name>\t<version>\t{isstable}1{else}0{} "
>    FMT=$FMT"{isunstable}1{else}0{}\n"
>    eix --format '<availableversions:FMT>' \
>        --category-name --regex 'app-crypt/tpm2-tss$|acct-group/input'

[reformatted slighly to avoid length restriction]

>    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. So there appears to be
a contradiction with your previous posting.
Also the output of {isunstable} is the opposite of your previous posting.
I re-checked, and the keywords have not changed in the gentoo
repository. Do you use a different repository or do you have modified
something?

> The manual mentions in another place that the  "test for
> markedversions always fails  in the context of <installedversions:...>",
> but aparently there are also other properties  than just "markedversion"
> that always fail in this context.

Yes.

> But why does "<availableversions:...>"  only return a correct result for
> installed  virtual package  "acct-group/input-0"  but incorrect  results
> (stable and unstable at the same time) for both, the not installed pack-
> age "app-crypt/tpm2-tss-2.2.3-r2"  and the installed package "app-crypt/
> tpm2-tss-2.3.3"?

I don't know why the script now breaks for you:
For me the above script works: On amd64, I get the output

acct-group/input        0       1 0
app-crypt/tpm2-tss      2.2.3-r2        0 1
app-crypt/tpm2-tss      2.3.3   0 1

and on x86, I get the output

acct-group/input        0       1 0
app-crypt/tpm2-tss      2.2.3-r2        0 0
app-crypt/tpm2-tss      2.3.3   0 0

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

[Dr Rainer Woitok]

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

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

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

[Martin Vaeth]

Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
>> >    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.

You are right. It is mysterious why <isstable> is 1 for you.
I still cannot reproduce it.

> even if ARCH is erroneously set to "x86_64".

I exported ARCH="x86_64" and did eix-update, but still:

% F='<version>:<isstable>\n' eix --format '<availableversions:F>' -e tpm2-tss
2.2.3-r2:
2.3.3:

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

[Dr Rainer Woitok]

Martin,

On Wednesday, 2020-04-22 19:48:47 -0000, you wrote:

> ...
> I exported ARCH="x86_64" and did eix-update, but still:
> 
> % F='<version>:<isstable>\n' eix --format '<availableversions:F>' -e tpm2-tss
> 2.2.3-r2:
> 2.3.3:

Did you check with "eix --print ARCH"?  I start suspecting that it's not
the value  of environment  variable "ARCH"  but rather  what the command
"arch" is returning.

And on my laptop that's still

   $ arch
   x86_64
   $

even though I followed the instructions at

   https://wiki.gentoo.org/wiki/Handbook:Main_Page

which says: "The two most  prominent architectures  in the desktop world
are the x86 architecture  and the x86_64 architecture  (for which Gentoo
uses the amd64 notation) ... A note for new Gentoo users:  if the CPU is
less than  five years old  and the manufacturer  is either Intel or AMD,
choosing the AMD64 Handbook is probably the correct route".

Did I overlook something  during my initial install?   Is there a way to
teach the kernel to have "arch" output "amd64"?

Slightly worried by now :-(

Sincerely,
  Rainer

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

[Martin Vaeth]

Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
>
>> ...
>> I exported ARCH="x86_64" and did eix-update, but still:
>>
>> % F='<version>:<isstable>\n' eix --format '<availableversions:F>' -e tpm2-tss
>> 2.2.3-r2:
>> 2.3.3:
>
> Did you check with "eix --print ARCH"?

Sure.

> but rather what the command "arch" is returning.

No. It's what it gets from the profile.

Maybe you run an unstable system, that is ACCEPT_KEYWORDS='~amd64'?
Or do you have a corresponding entry in package.{accept_,}keywords?

[gentoo-user] Help working around a bug...

["Chris Phillips"@T O]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

Hi
I am a relative newbee to GenToo (*though familiar with all sorts of 
Unix/Linux/BSD OS)
I am currently unable to complete a sync / build @world cycle because of a
bug building enchant-2.2.8 , compile fails because it doesn't recognize the
ObjC "@" syntax.  There is a bug filed :
https://bugs.gentoo.org/show_bug.cgi?id=718634
that has a suggested fix that looks appropriate:

./configure --without-applespell --without-aspell --enable-relocatable

(Not sure about the --without-aspell bit, and I think this bug may have 
some relation to
using GNUstep bits)

How do I override the ./configure options for emerge  [-r] ?

Chris

--


[-- Attachment #2: Type: text/html, Size: 1083 bytes --]

Re: [gentoo-user] Help working around a bug...

[Michael Orlitzky]

On 4/25/20 11:20 AM, "Chris Phillips"@T O wrote:
> 
> How do I override the ./configure options for emerge  [-r] ?
> 

If it's a one-time thing, you can set the EXTRA_ECONF environment
variable to contain the extra arguments to ./configure. The contents of
EXTRA_ECONF are appended to the end of the usual command, so yours
should take precedence. Just be sure to set it only while emerging
enchant (and not, for example, during emerge @world).

Re: [gentoo-user] Help working around a bug...

["Chris Phillips"@T O]

Hi,

On 25/04/20 11:27 AM, Michael Orlitzky wrote:
> On 4/25/20 11:20 AM, "Chris Phillips"@T O wrote:
>> How do I override the ./configure options for emerge  [-r] ?
>>
> If it's a one-time thing, you can set the EXTRA_ECONF environment
> variable to contain the extra arguments to ./configure. The contents of
> EXTRA_ECONF are appended to the end of the usual command, so yours
> should take precedence. Just be sure to set it only while emerging
> enchant (and not, for example, during emerge @world).
>
>
>
>
Thanks! That did the trick:

EXTRA_ECONF="--without-applespell --enable-relocatable" emerge --verbose 
app-text/enchant

Cheers!
Chris

Re: https://bugs.gentoo.org/show_bug.cgi?id=718634

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

[Dr Rainer Woitok]

Martin,

On Friday, 2020-04-24 17:32:09 -0000, you wrote:

> ...
> Maybe you run an unstable system, that is ACCEPT_KEYWORDS='~amd64'?

No.

> Or do you have a corresponding entry in package.{accept_,}keywords?

Yes.  To satisfy the requirements of package "sys-apps/fwupd" I long ago
added the line

   >=app-crypt/tpm2-tss-2.2.3-r1 ~amd64

But this only means  that I accept  an unstable  package here,  not that
these versions  are regarded stable.   After all,  the property is named
"{isstable}" and not "{isaccepted}".

Sincerely,
  Rainer

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

[Martin Vaeth]

Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
>
> Yes.  To satisfy the requirements of package "sys-apps/fwupd" I long ago
> added the line
>
>    >=app-crypt/tpm2-tss-2.2.3-r1 ~amd64

Ah! That explains it.

> But this only means  that I accept  an unstable  package here,  not that
> these versions  are regarded stable.

It is stabe according to the local configuration on your system.
What you look for is perhaps {wasstable} which returns the value
according to the default configuration.

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

[Dr Rainer Woitok]

Martin,

On Thursday, 2020-04-30 17:20:08 -0000, you wrote:

> ...
> >    >=app-crypt/tpm2-tss-2.2.3-r1 ~amd64
> 
> Ah! That explains it.
> 
> > But this only means  that I accept  an unstable  package here,  not that
> > these versions  are regarded stable.
> 
> It is stabe according to the local configuration on your system.

I STRONGLY beg to disagree!   The "~amd64" notation  is used to ACCEPT a
package even though it is  (still) classified as UNSTABLE.  And yes, the
"{isunstable}" property does in fact still return "True".   Phrases like
the one above only try to conver-up sloppy programming, sloppy document-
ation, or both.   If "{!isstable}"  isn't equivalent to  "{isunstable}",
there's a severe logical problem involved.

> What you look for is perhaps {wasstable} which returns the value
> according to the default configuration.

That property is indeed mentioned in "man eix" but never explained, like
plenty of other properties, too.   Besides, in my book "was stable" sort
of means "is no longer stable",  but again, that's most probaly not what
"{wasstable}" means in Eix-speak.

But apart from that: you helped me solve my problem, and I thank you for
that :-)

Sincerely,
  Rainer

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

[Martin Vaeth]

Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
> I STRONGLY beg to disagree!   The "~amd64" notation  is used to ACCEPT a
> package even though it is  (still) classified as UNSTABLE.

This is package-manager terminology which has much less states since
a package manager needs no fine distinctions about the reasons of
accepting or rejecting a package and which of these reasons are caused
by your local configuration.
In eix there's several configurations: The default (repository) one
and the local one (actually even another one with a local profile
override).
A lot of states (stable, masked, package-masked, etc) can change between
these configurations. You can of course invent a new term for each of the
several dozens or more possible combination of states,
but it is much simpler and more natural to allow all checks separately
and use terms for the individual properties which are similar to that of
portage. For the optical output, eix displays less information which
are more similar to portage.

> If "{!isstable}"  isn't equivalent to  "{isunstable}",
> there's a severe logical problem involved.

There would be a severe information problem if there were just a
few such states and the natural term "unstable" with the analogous
"alienunstable" would have been reserved for a mere negation.

> Besides, in my book "was stable" sort of means "is no longer stable"

It means it was stable before your local overrides. It may or not be
stable after your local overrides. Analogously for alienstable,
alienunstable, masked, etc.

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

[Dr Rainer Woitok]

Martin,

On Sunday, 2020-05-03 15:55:59 -0000, you wrote:

> ...
> > I STRONGLY beg to disagree!   The "~amd64" notation  is used to ACCEPT a
> > package even though it is  (still) classified as UNSTABLE.
> 
> This is package-manager terminology which has much less states since
> a package manager needs no fine distinctions about the reasons of
> accepting or rejecting a package and which of these reasons are caused
> by your local configuration.

No it's USER terminology.  It's what users are confronted with when they
set-up their Portage configuration and when they deal with commands like
"emerge",  "equery", and ilk.   In your mail dating  2020-04-24 17:32:09
-0000 even you said  "Maybe you run an unstable system,  that is ACCEPT_
KEYWORDS='~amd64'?" because you knew  that on an "unstable" system (user
terminology)  property "{isstable}" ("eix" developers' terminology) will
always return True.

But if I learned anything about software development  in my former life,
it's that everything a user or administrator  passes as option or argum-
ent to some command  or inserts into  some configuration file  has to be
described in the manuals using USER terminology.

Brilliant programmers  may write  brilliant software,  but if they write
sloppy documentation or use counterintuitive terminology therein, only a
few stubborn people  will use this software  in a few special cases they
have struggled to understand,  and all the brilliance goes mainly unnot-
iced and is thus  more or less wasted.   No software  can be better than
its documentation!

> ...
> There would be a severe information problem if there were just a
> few such states and the natural term "unstable" with the analogous
> "alienunstable" would have been reserved for a mere negation.

It's not a matter  of the number of states  but a matter of choosing in-
tuitive names for them.   Simply due to  USER EXPECTATION  the term "un-
stable" HAS to be  the opposite of  "isstable"  (and thus is unnecessary
because there is also "!isstable").  And if finer granularity is needed,
more (but carefully chosen) property names  have to be introduced.   But
if every state introduced  isn't clearly  and precisely  defined in some
manual,  it's not too surprising  that only few people manage to use the
software.

Sincerely,
  Rainer

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

[Martin Vaeth]

Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
>> ...
>> > I STRONGLY beg to disagree!   The "~amd64" notation  is used to ACCEPT a
>> > package even though it is  (still) classified as UNSTABLE.
>> 
>> This is package-manager terminology [...]
>
> No it's USER terminology.  It's what users are confronted with when they
> set-up their Portage configuration and when they deal with commands like
> "emerge",  "equery", and ilk.

So it is not package-manager terminology, but the terminology which
is used by users when they use the package-manager. I cannot see any
difference, but it doesn't matter. This discussion leads to nothing.

> Simply due to  USER EXPECTATION  the term "unstable" HAS to be
> the opposite of  "isstable"

Not in gentoo. There ARCH is called the stable keyword and ~ARCH
is called the unstable keyword.
Again, this discussion leads to nothing. I will stop it here.