| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Gene Hannan wrote: |
| 5 |
|
| 6 |
> I'm seeing a quirk in portpeek on one of two machines with similar |
| 7 |
> installations. Portpeek responds with, for example, |
| 8 |
> |
| 9 |
> package.keywords: |
| 10 |
> Could not find file etc/portage/package.keywords |
| 11 |
> |
| 12 |
> Note the absence of an initial slash. The program executes correctly |
| 13 |
> from "/" as a working directory. |
| 14 |
> |
| 15 |
> The system is up to date, x86 with ~x86 as required for KDE-4.2 and a |
| 16 |
> handful of others. Python 2.5.4 is the only version installed, and the |
| 17 |
> behavior is the same with eselect-python-20090801 or -20090804. |
| 18 |
> |
| 19 |
> I've tried simply re-emerging portage, portpeek, eselect, and |
| 20 |
> python-eselect with no effect, and seen the same behavior with |
| 21 |
> gentoo-sources-2.6.28-r5 and 2.6/30-r4. |
| 22 |
> |
| 23 |
> My other machine with the same versions of the packages that are likely |
| 24 |
> to be related executes portpeek from any working directory, as did the |
| 25 |
> machine in question until a few weeks ago. Any tips on where to look |
| 26 |
> next? |
| 27 |
|
| 28 |
That looks like it may be a bug in portpeek that only is appearing now |
| 29 |
because portage changed some of its internals to simplify things in portage, |
| 30 |
but packages using portage's internal APIs incorrectly stopped working. |
| 31 |
|
| 32 |
- -- |
| 33 |
ABCD |
| 34 |
-----BEGIN PGP SIGNATURE----- |
| 35 |
Version: GnuPG v2.0.11 (GNU/Linux) |
| 36 |
|
| 37 |
iEYEARECAAYFAkqArRkACgkQOypDUo0oQOpDeACdFYr7P+9iTuJZBdRRuGMponhP |
| 38 |
ckgAoLbaR0AsoqlVkOLq1NaObpJp1eHC |
| 39 |
=Px69 |
| 40 |
-----END PGP SIGNATURE----- |
Archives