View previous topic :: View next topic |
Author |
Message |
Whissi Retired Dev
Joined: 12 Jan 2011 Posts: 222
|
Posted: Fri Oct 11, 2013 4:34 pm Post subject: What is eix-diff's output telling me? |
|
|
Hi,
I don't understand the following eix-diff output:
[<] == app-misc/foo (0.9.1{tbz2}@10/10/2013; 99999 -> 0.9.1^m{tbz2}) [1]: Dummy description
I understand that app-misc/foo in version 0.9.1 is installed and also available as binpkg.
But,- what does "[<]" mean (and why is it red)?
- what does "99999 -> 0.9.1^m" mean?
- what does "^m" mean?
And BTW I am wondering at all why app-misc/foo is in the listing, because the overlay with app-misc/foo hasn't changed. I can only guess that it is in the listing, because yesterday (10/10/2013) I rebuild @world with "--buildpkg y" parameter.
Thanks.
PS: app-misc/foo-99999 has no keywords set (not in the ebuild, not in /etc/portage/*) and wasn't installed at any time . And again, the overlay with app-misc/foo hasn't changed since the last 3 diffs. _________________ Regards,
Whissi |
|
Back to top |
|
|
eyoung100 Veteran
Joined: 23 Jan 2004 Posts: 1428
|
Posted: Fri Oct 11, 2013 6:59 pm Post subject: |
|
|
Your Current Version 0.9.1 is less than the live CVS Version 9999 ->(which will replace) Version 0.9.1 , but the live CVS Version 9999 is masked and in an overlay. _________________ The Birth and Growth of Science is the Death and Atrophy of Art -- Unknown
Registerd Linux User #363735
Adopt a Post | Strip Comments| Emerge Wrapper |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Fri Oct 11, 2013 8:14 pm Post subject: |
|
|
eix-diff is telling you that your previous eix cache contains a non-masked version 99999 of package foo while in your current eix cache the version 99999 is not available or masked.
It might be that eix-diff's assumption about the previous mask is wrong: eix does not store all mask information in the database but partially reads it from your current profile(s) which is not available anymore when eix-diff is called, i.e. eix-diff reconstructs the previous state from incomplete (mixed old and new) information.
You can check with and Code: | EIX_CACHEFILE=/var/cache/eix/previous.eix app-misc/foo | whether the versions really have not changed: Usually you see something as the above if version 99999 together with the mask for version 99999 was removed: Since eix-diff then has no information about any mask for that version, it shows that 99999 is unmasked. |
|
Back to top |
|
|
Whissi Retired Dev
Joined: 12 Jan 2011 Posts: 222
|
Posted: Sat Oct 12, 2013 10:57 am Post subject: |
|
|
Hi,
thank you for your answers! I am still wondering why eix-diff is reporting app-misc/foo has changed:
# eix app-misc/foo
[I] app-misc/foo [1]
Available versions: 0.9.0^m 0.9.1^m{tbz2} **99999
Installed versions: 0.9.1^m{tbz2}(04:39:31 PM 10/10/2013)
Homepage: https://example.org/foo
Description: Dummy description
[1] "my-overlay" /usr/local/portage
vs.
# EIX_CACHEFILE=/var/cache/eix/previous.eix eix app-misc/foo
[U] app-misc/foo [1]
Available versions: 0.9.0^m 0.9.1^m{tbz2} 99999
Installed versions: 0.9.1^m{tbz2}(04:39:31 PM 10/10/2013)
Homepage: https://example.org/foo
Description: Dummy description
[1] "my-overlay" /usr/local/portage
(The "[I]", "[U]" and "0.9.1" have a background color, but because I cannot show a background color in this forum, I am using font colors)
So I don't understand why **99999 became 99999. Now it is **99999 which seems to be correct. When this will change again (without an actual change), I'll report back.
But to get back to my origin question:
What's the meaning of ^m? _________________ Regards,
Whissi |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat Oct 12, 2013 4:01 pm Post subject: |
|
|
Whissi wrote: | So I don't understand why **99999 became 99999. |
So it is not about masking but about keywords. Then it is another story, indicating that the metadata was not up-to-date (or not available) when the previous eix cachefile was created. I suggest that you change your setup correspondingly so that this will not happen again:
More verbose explanation: Probably the foo-99999.ebuild sets KEYWORDS depending on some conditions. The "parse" cache method of eix is too heuristic to understand these conditions and thus will probably provide wrong (stable) keyword information if this cache method is used. On the other hand, if you have correct metadata, eix will not use the "parse" cache method but instead get the correct (not-keyworded) information from the metadata.
You should regularly call e.g. egencache, see the section "SPEEDUP" on the eix manpage. |
|
Back to top |
|
|
Whissi Retired Dev
Joined: 12 Jan 2011 Posts: 222
|
Posted: Tue Oct 15, 2013 12:35 pm Post subject: |
|
|
Hi,
Quote: | Probably the foo-99999.ebuild sets KEYWORDS depending on some conditions. |
Good guess!
Both ebuilds (foo-0.9.1 and foo-99999) start with
Code: | EAPI="5"
inherit eutils
if [[ ${PV} == 9999* ]] ; then
EGIT_REPO_URI="git://github.com/foo/${PN}.git
https://github.com/foo/${PN}.git"
inherit git-2
SRC_URI=""
KEYWORDS=""
else
SRC_URI="https://github.com/foo/${PN}/archive/v${PV}.tar.gz -> ${P}.tar.gz"
KEYWORDS="~alpha amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc x86"
fi | and I am also not using a cache for the overlay, so eix uses "parse". BUT:
I run "eix-sync -0 -u" multiple times (>10). I expected to see at least one run, where eix-diff stated the package would have changed again due to wrong keyword information from parse. But I am unable to reproduce.
Anyway, I will set up a cache. But I am not sure if I should add the cache to the overlay (=call egencache before committing a change) or if this should be done by eix when updating... on client side.
Thanks. _________________ Regards,
Whissi |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Tue Oct 15, 2013 1:30 pm Post subject: |
|
|
Whissi wrote: | But I am unable to reproduce. |
If the filestamps and checksums of the ebuild and metadata files do not change, either the metadata is always considered up-to-date or not.
Quote: | But I am not sure if I should add the cache to the overlay (=call egencache before committing a change) or if this should be done by eix when updating... on client side. |
I would not make it public: Whenever an eclass (even in the main tree!) changes, the metadata is already outdated, so if somebody downloads it before you commited after the change, he will get obsolete metadata.
Since the metadata changes so often (with every eclass change), I would not even keep it under versioncontrol. |
|
Back to top |
|
|
Whissi Retired Dev
Joined: 12 Jan 2011 Posts: 222
|
Posted: Tue Oct 15, 2013 3:01 pm Post subject: |
|
|
mv wrote: | I would not make it public: Whenever an eclass (even in the main tree!) changes, the metadata is already outdated, so if somebody downloads it before you commited after the change, he will get obsolete metadata. | That's a good point. I would call egencache before I commit, but yes, eclasses the ebuilds in the overlay are using from master may change..
What I have done now:
- Added metadata/md5-cache to .gitignore in my overlay
- Added an "@egencache --repo=my-overlay --update" hook to /etc/eix-sync.conf
Now I hope I'll not run into this "issue" again. Thanks for your help! _________________ Regards,
Whissi |
|
Back to top |
|
|
Sakaki Guru
Joined: 21 May 2014 Posts: 409
|
Posted: Wed May 21, 2014 9:25 pm Post subject: |
|
|
Whissi wrote: | But to get back to my origin question:
What's the meaning of ^m? |
It's because you have RESTRICT="mirror" set in your ebuild
If you run Code: | eix --xml app-misc/foo | you will get a slightly less cryptic output (--xml doesn't work with eix-diff, though). |
|
Back to top |
|
|
|