Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 581490 - app-portage/g-cpan-0.16.6 pulls PORTDIR from the environment instead of using portageq
Summary: app-portage/g-cpan-0.16.6 pulls PORTDIR from the environment instead of using...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Sergiy Borodych
URL:
Whiteboard: v0.17.0
Keywords:
Depends on:
Blocks: 546210
  Show dependency tree
 
Reported: 2016-04-28 22:00 UTC by Jack
Modified: 2020-04-11 05:15 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
output of emerge --info g-cpan (emerge_info_g-cpan,18.28 KB, text/plain)
2016-05-06 15:33 UTC, Jack
Details
output of emerge --info g-cpan (emeinggcp,18.24 KB, text/plain)
2016-11-15 01:32 UTC, Jack
Details
g-cpan-9999 build.log with FEATURES="test" (g-cpan-9999.build.log,5.97 KB, application/download)
2016-11-20 20:07 UTC, Nils Freydank
Details
output of 'g-cpan -ipvd Image-EXIF && echo $?' (g-cpan_output,6.93 KB, text/plain)
2016-11-28 23:00 UTC, Jack
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jack 2016-04-28 22:00:57 UTC
g-cpan gets the root of the portage tree with 'my $PORTAGE_DIR = $gcpan_run->getEnv('PORTDIR');' which doesn't work if you don't define PORTDIR, which has been deprecated in favor of using repos.  If you don't have PORTDIR set anywhere, g-cpan gets a null value and fails with 'ERROR READING /profiles/arch.list: No such file or directory'.  The suggested means of getting PORTDIR is apparently 'PORTDIR="$(portageq get_repo_path $(portageq envvar EROOT) gentoo)"' but I'm not quite sure the best way to embed this in the perl script, or I'd actually submit this as a patch.
Comment 1 Sergiy Borodych 2016-04-29 17:15:04 UTC
Your issue is seems like mix-up of two.

1. bug #432992, location of make.globals
was fixed, and will be delivered in the next version (soon I hope)
https://github.com/gentoo-perl/g-cpan/commit/467d74ba8bd737cabb061b50f192dd90fb11bf77

2. enhancement: support of repos.conf
There is opened issue
 https://github.com/gentoo-perl/g-cpan/issues/26
And I'm still thinking how to manage it nicely.
And thanks for another idea ;)

Please test =app-portage/g-cpan-9999 version.
At least it should not produce such error for you.
Comment 2 Jack 2016-04-29 21:54:13 UTC
I know I have more than one issue, but tried to only address one here.  I'm away from home, and will try the update on Monday.  The idea for getting PORTDIR came from my forum post https://forums.gentoo.org/viewtopic-t-1043736.html.

Manually setting PORTDIR does avoid the error, but gcpan -l does not seem to know of what it already did - perhaps because it's using the wrong overlay?  I'll confirm this first fix, and deal with that separately, unless you want those details here also (after Monday.)

Thanks
Comment 3 Jack 2016-05-02 16:10:51 UTC
I just emerged =app-portage/g-cpan-9999 and I still get the same error: " * ERROR READING /profiles/arch.list: No such file or directory"
Comment 4 Sergiy Borodych 2016-05-06 08:16:15 UTC
Please show you emeg-cpan
Comment 5 Sergiy Borodych 2016-05-06 08:17:55 UTC
Please show your:
$ emerge --info g-cpan
$ ls -l /etc/portage/make.conf /usr/share/portage/config/make.globals
Comment 6 Jack 2016-05-06 15:33:38 UTC
Created attachment 433432 [details]
output of emerge --info g-cpan

output of emerge --info g-cpan attached, bugzilla complained it was too long to paste.

jack:~ $ls -l /etc/portage/make.conf /usr/share/portage/config/make.globals
-rw-r--r-- 1 root root 2411 Feb 23 17:14 /etc/portage/make.conf
-rw-r--r-- 1 root root 6035 Jan  3 16:10 /usr/share/portage/config/make.globals
Comment 7 Sergiy Borodych 2016-05-06 19:27:15 UTC
seems like I missed the moment
https://bugs.gentoo.org/show_bug.cgi?id=546210

and now the var is deprecated and even already removed from make.globals
ok, there is a need a different kind of fix
Comment 8 Jack 2016-05-07 02:22:44 UTC
If you look at the forum post I linked, there is a suggested way to get the information.  I was just not sure how to essentially embed it in the current code, or I would have offered a patch.
Comment 9 Sergiy Borodych 2016-07-28 14:39:54 UTC
See also: https://github.com/gentoo-perl/g-cpan/issues/26
Comment 10 Jack 2016-07-28 20:09:02 UTC
If I export PORTDIR pointing to my main perl tree, 'g-cpan -l' shows nothing.  I assume that is because perl-gcpan is in my local overlay.  However, if I point PORTDIR to the local overlay, 'g-cpan -l' complains "* ERROR READING /usr/local/portage/profiles/arch.list: No such file or directory".  Making a symlink there to the real arch.list avoids that error, but still doesn't list anything.  (I DO have one package under /usr/local/portage/perl-gcpan.  I don't know for sure if this is actually related to this bug, but it certainly seems like it to me.
Comment 11 Sergiy Borodych 2016-07-29 13:53:14 UTC
Try to set both vars (like was in the past)

PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
Comment 12 Jack 2016-07-29 18:29:38 UTC
Something is still not right.  
I have exported PORTDIR_OVERLAY=/usr/local/portage and PORTDIR=/usr/portag/tree. 'g-cpan -l' lists nothing, but 'g-cpan -v -s Image-EXIF' shows it is looking in /usr/portage/tree and in /var/lib/layman/kde (which is my only layman overlay) but not in /usr/local/portage.
If I change to PORTDIR=/usr/local/portage (and copy or link arches.lst to the profiles directory there) then 'g-cpan -l' still  lists nothing, but 'g-cpan -v -s Image-EXIF' finds perl-gcpan/AImage-EXIF, although it then gives:
Use of uninitialized value $key in hash element at /usr/bin/g-cpan line 879.
Use of uninitialized value $key in substitution (s///) at /usr/bin/g-cpan line 889.
Use of uninitialized value $key in substitution (s///) at /usr/bin/g-cpan line 892.
Use of uninitialized value $key in substitution (s///) at /usr/bin/g-cpan line 892.
Am I expecting the wrong think from -l, or is this a separate (or related) bug - or might I have some garbled cache?
Comment 13 Wolfram Schlich (RETIRED) gentoo-dev 2016-09-20 15:32:21 UTC
When will the PORTDIR issue be fixed?
Comment 14 Sergiy Borodych 2016-09-22 07:42:33 UTC
@Jack seems like I forgot one more var.
This is full setup:

PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
GCPAN_OVERLAY="/usr/local/portage"

And if it not help please put your output somewhere (pastebin,etc).

@Wolfram I have started this, but have no a lot of free time now.
Anyway I will try to make more progress.
The initial idea here
https://github.com/bor/g-cpan/tree/feature/portageq
Comment 15 Jack 2016-09-22 15:57:49 UTC
Setting all three variables avoids any error messages.  Oddly, however, 'g-cpan -l' does not list anything. Adding a -v only adds '* Cleaning temporary space' to the output.

'g-cpan -p Image-EXIF' does find it and correctly says it would be a reinstall.  (That is the only package I have installed by g-cpan.)  However, it shows it is looking in /usr/portage/tree (my main tree) and /var/lib/layman (overlays) so it appears g-cpan does not know it is already installed, but emerge does. (perl/g-cpan is under /usr/local/portage).

Doing (with the three vars defined) 'g-cpan -i Image-EXIF' does the reinstall, but after that -l still lists nothing.
Comment 16 Sergiy Borodych 2016-11-13 16:21:51 UTC
Guys please check last git revision.

By `emerge -av =app-portage/g-cpan-9999`

Is it works for you now?
Comment 17 Jack 2016-11-13 20:46:31 UTC
There seems to be new dependencies on dev-perl/Config-Tiny, dev-perl/Path-Tiny.  Should the ebuild be updated as well?

Anyway - no change in bahavior.  g-cpan -l still doesn't list anything, and adding -v only says Cleaning temporary space.
Comment 18 Sergiy Borodych 2016-11-14 06:40:55 UTC
The deps was added, please sync your portage tree.

And for further investigation please provide your output

$ egrep 'PORTDIR|OVERLAY' /etc/portage/make.conf
$ ls -l /etc/portage/make.profile
$ cat ~/.gcpanrc
$ portageq get_repos `portageq envvar EROOT`
$ emerge --info g-cpan
Comment 19 Jack 2016-11-15 01:31:02 UTC
$ egrep 'PORTDIR|OVERLAY' /etc/portage/make.conf
## PORTDIR="/usr/portage/tree"
## PORTDIR_OVERLAY="/usr/local/portage"
GCPAN_OVERLAY="/usr/local/portage"

$ ls -l /etc/portage/make.profile
lrwxrwxrwx 1 root root 51 Feb 18  2013 /etc/portage/make.profile -> /usr/portage/tree/profiles/default/linux/amd64/13.0

$ cat ~/.gcpanrc
GCPAN_OVERLAY=/usr/local/portage

$ portageq get_repos `portageq envvar EROOT`
local kde gentoo

$ emerge --info g-cpan
I will attach, per earlier complaint it is too long.
Comment 20 Jack 2016-11-15 01:32:34 UTC
Created attachment 453340 [details]
output of emerge --info g-cpan
Comment 21 Sergiy Borodych 2016-11-15 15:51:06 UTC
Jack, thank you.
Now please for sure:

$ ls /usr/local/portage/perl-gcpan/*
$ g-cpan -vl
Comment 22 Jack 2016-11-15 19:16:41 UTC
$ ls /usr/local/portage/perl-gcpan/*
Image-EXIF-2.01.ebuild  Manifest  files 

Image-EXIF is the only package I have installed with g-cpan.  The files folder is empty.


$ g-cpan -vl
 * Cleaning temporary space
Comment 23 Sergiy Borodych 2016-11-16 11:26:32 UTC
Oddly.
Are you sure what you using the last git revision?

And you last `ls` output is weird also.
Please give me

$ ls /usr/local/portage/perl-gcpan/


I will try to emulate the case on my side later.
Comment 24 Sergiy Borodych 2016-11-16 11:42:27 UTC
Jack, another request.
Please run test phase during installation

$ FEATURES="test" emerge -1v app-portage/g-cpan
Comment 25 Jack 2016-11-16 20:19:44 UTC
/usr/local/portage/g-cpan contains only one folder: Image-EXIF.  The files I listed are those in that directory.

I re-emerged with test enabled.  
t/00_Gentoo.t ............ ok   
t/01_Gentoo_Portage_Q.t .. ok   
t/05_Gentoo_Portage.t .... ok   
t/10cpan_packages.t ...... skipped: since network activity is disabled (NO_NETWORK_TESTING is set)
t/11_App_gcpan.t ......... ok   
t/98_changes.t ........... skipped: Developer's tests not required for installation
t/98_eol.t ............... skipped: Developer's tests not required for installation
t/98_manifest.t .......... skipped: Developer's tests not required for installation
t/98_pod_spelling.t ...... skipped: Developer's tests not required for installation
t/98_pod_syntax.t ........ skipped: Developer's tests not required for installation
All tests successful.
Files=10, Tests=17, 14 wallclock secs ( 0.13 usr  0.05 sys +  2.21 cusr  1.35 csys =  3.74 CPU)
Result: PASS

No change in results of running g-cpan.
Comment 26 Nils Freydank 2016-11-20 20:07:34 UTC
Created attachment 453936 [details]
g-cpan-9999 build.log with FEATURES="test"
Comment 27 Nils Freydank 2016-11-20 20:11:21 UTC
Thanks for fixing this script!

g-cpan-9999 works for me with commit acecf684da00fcdc798902ca2e49abb6a8ee9919,
build.log with FEATURES="test" is attached (fails).

“g-cpan -i Image-EXIF“ seems to work fine, here, too. If I can assist with more
informations, tell me :)
Comment 28 Nils Freydank 2016-11-20 20:18:01 UTC
(In reply to Jack from comment #25)
> /usr/local/portage/g-cpan contains only one folder: Image-EXIF.  The files I
> listed are those in that directory.
> [...]

This represents the normal structure of the portage tree (and overlays):
<tree>/<section>/<package>/ with:
 1. package-version.ebuild,
 2. Manifest with checksums of the distfiles
 3. files dir for patches if needed
 4. metadata.xml for maintainer informations and so on.

To me it looks as the script just throws empty files dirs, but doesn’t really hurt anyone.
Comment 29 Jack 2016-11-20 23:20:31 UTC
I agree that directory looks fine.  I posted it because Sergiy asked for it.  The problem for me is that gcpan -l exits with no output, even though it should list Image-EXIF, which is the only package it has installed.
Comment 30 Nils Freydank 2016-11-23 10:23:51 UTC
(In reply to Jack from comment #29)
> I agree that directory looks fine.  I posted it because Sergiy asked for it.
> The problem for me is that gcpan -l exits with no output, even though it
> should list Image-EXIF, which is the only package it has installed.

I can’t reproduce this:

% g-cpan -l
 * OVERLAY: /usr/local/portage/perl-gcpan
 * perl-gcpan/IPC-Run3-Shell
 * perl-gcpan/Shell-Tools
 * perl-gcpan/Verilog-Perl
 * perl-gcpan/Image-EXIF

↑ user prompt.

Could you please check with latest git commit and check the return value of g-cpan?

“emerge -1 g-cpan; g-cpan -l; echo $?“
Comment 31 Sergiy Borodych 2016-11-25 08:49:06 UTC
@Nils thank you for report.

@Jack I will provide some new commits with more debug output and will ask you again to run it.
Because I can't reproduce the bug itself.
Comment 32 Sergiy Borodych 2016-11-25 10:56:40 UTC
@Jack I'm asking again, please do

$ FEATURES="test" emerge -1v app-portage/g-cpan
$ g-cpan -lvd && echo $?
$ g-cpan -ipvd Image-EXIF && echo $?

P.S.
-d is a non-public (hidden) argument for debugging
Comment 33 Jack 2016-11-25 15:00:12 UTC
@Sergiy:  I'm away from home, but I'll get your information on Monday.

Jack
Comment 34 Jack 2016-11-28 22:59:03 UTC
(In reply to Sergiy Borodych from comment #32)
> $ FEATURES="test" emerge -1v app-portage/g-cpan
no errors, but skipped t/06_Gentoo_CPAN.t since  network activity disabled and skipped all t/98 Developer's tests not required for installation

> $ g-cpan -lvd && echo $?
In main (/usr/bin/g-cpan:207:
$VAR1 = bless( {
                 'portage_bases' => {},
                 'debug' => 1,
                 'modules' => {},
                 'cpan_reload' => undef,
                 'portage_categories' => []
               }, 'Gentoo' );
$VAR2 = {
          'PORTDIR_OVERLAY' => '/var/lib/layman/kde',
          'PORTDIR' => '/usr/portage/tree',
          'DISTDIR' => '/usr/portage/tree/distfiles',
          'ACCEPT_KEYWORDS' => 'amd64',
          'GCPAN_CAT' => 'perl-gcpan',
          'GCPAN_OVERLAY' => '/usr/local/portage'
        };
 * Cleaning temporary space
0

Those directories seem correct to me.

> $ g-cpan -ipvd Image-EXIF && echo $?
I'll attach the output, as I'm not sure it would be readable here.
Comment 35 Jack 2016-11-28 23:00:52 UTC
Created attachment 454644 [details]
output of 'g-cpan -ipvd Image-EXIF && echo $?'
Comment 36 Sergiy Borodych 2016-11-30 08:04:31 UTC
@Jack thank you for so detailed reporting.
Seems like I've found the source of the issue.

I've added additional check and now you will get warning like:

 * Your "GCPAN_OVERLAY" is not present in overlays/repos list
 * Bear in mind what you will not have ability to manage generated ebuilds by "-l", "-u" options

It's because you don't have '/usr/local/portage' not in both PORTDIR_OVERLAY or repos.conf setup.

For sure please give me again (now) output of

$ portageq get_repos `portageq envvar EROOT`
$ grep -r '/usr/local/portage' /etc/portage/

Because in your previous output the repo 'local' was present.
Comment 37 Jack 2016-11-30 17:43:15 UTC
@Sergiy

I'm not sure now whether I'm not using a correct configuration, or you are not detecting it correctly.  My eix-sync works fine, and eix and emerge certainly recognize my local overlay.


$ portageq get_repos `portageq envvar EROOT`
local kde gentoo

$ grep -r '/usr/local/portage' /etc/portage/
/etc/portage/make.conf:## PORTDIR_OVERLAY="/usr/local/portage"
/etc/portage/make.conf:GCPAN_OVERLAY="/usr/local/portage"
/etc/portage/repos.conf/local.conf:location = /usr/local/portage

The commented out line in make.conf is probably from when I moved to use repos.conf.


Is this perhaps an issue that I have a respos.conf directory, and not a single file?  I'm pretty sure this is valid.
Comment 38 Sergiy Borodych 2016-11-30 22:36:51 UTC
Ok, seems like g-cpan can't detect the configuration for'local' repo.
Dir is ok.
Another request: please provide:
$ cat /etc/portage/repos.conf/local.conf
Comment 39 Jack 2016-11-30 23:34:36 UTC
$cat /etc/portage/repos.conf/local.conf
[local]
location = /usr/local/portage
auto-sync = no

just for completeness

$cat /etc/portage/repos.conf/gentoo.conf
[DEFAULT]
main-repo = gentoo

[gentoo]
location = /usr/portage/tree
sync-type = rsync
sync-uri = rsync://rsync5.us.gentoo.org/gentoo-portage
auto-sync = true
Comment 40 Sergiy Borodych 2016-12-01 11:59:20 UTC
Ok, I see now the source of issue.
AFAIU you have layman & setup it in make.conf as like:

source /var/lib/layman/make.conf

so you have PORTDIR_OVERLAY set by it.
And g-cpan doesn't check for repos if PORTDIR_OVERLAY is set.
But portage (AFAIU) collects from both sources, so I need to do the same.
Please wait a little and I will switch to the same approach.
Comment 41 Jack 2016-12-01 21:16:19 UTC
And the only thing in /var/lib/layman.conf is:
-----
PORTDIR_OVERLAY="
/var/lib/layman/kde
$PORTDIR_OVERLAY
"
-----

Both portage and eix seem to deal with this correctly.
Comment 42 Jack 2017-05-08 16:31:53 UTC
What's the status of this issue?  I just re-emerged g-cpan, and don't see anything different.

Thanks.
Comment 43 Jack 2018-02-14 17:24:28 UTC
I just tried again, and did not get any errors.  (I only have one package installed by g-cpan, and it is up to date.)  However, I no longer have "source /var/lib/layman/make.conf: in my make.conf, so I dont' know if I have just avoided the error or it has been fixed.
Comment 44 Jack 2018-07-27 20:40:20 UTC
I just tried "g-cpan -up" and although it seems to find my one g-cpan installed module Image-EXIF, it fails trying to create /var/lib/layman/dotnet/perl-gcpan (yes, I do use the dotet layman overlay) even though GCPAN_OVERLAY is set in /etc/portage/make.conf to /usr/local/portage.

Output of "c-cpan -upv" (run as myself, not root, and I do have full perms on /usr/local/portage)

 * OVERLAY: /usr/local/portage/perl-gcpan
 * Getting CPAN Info for Image::EXIF
-Reading '/home/jack/.cpan/Metadata'
  Database was generated on Fri, 27 Jul 2018 15:17:03 GMT
|Checksum for /home/jack/.cpan/sources/authors/id/A/AR/ARC/Image-EXIF-2.01.tar.gz ok
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Image::EXIF
Writing MYMETA.yml and MYMETA.json
 * Skipping ExtUtils::MakeMaker dependency
 * Image-EXIF already up to date
 * Create directory '/var/lib/layman/dotnet/perl-gcpan'
 * Couldn't create folder /var/lib/layman/dotnet/perl-gcpan: Permission denied
 * Cleaning temporary space

Should I file this as a new bug?
Comment 45 Jack 2019-05-28 19:13:40 UTC
Well, I seem to have made the mistake of running g-cpan as root, as part of installing quite a number of perl CPAN modules, so now when I run g-cpan -l, I show ebuilds in three different overlays.  One layman overlay has four, and another (dotnet) has 22, and all of them are included in my local overlay.  As far as I can tell, only the ones in my local overlay are actually installed, so I'm going to chance simply deleting the perl-gcpan category from both layman overlays.
Comment 46 Sergiy Borodych 2020-04-03 15:40:52 UTC
g-cpan-0.17.0 on a way and will be in portage shortly.

The bug report should be closed I think shortly as well.
And bug about GCPAN_OVERLAY reported separately.
Comment 47 Larry the Git Cow gentoo-dev 2020-04-10 23:31:15 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=119f9d6ab000d8f7b53867c852e03404500ddf71

commit 119f9d6ab000d8f7b53867c852e03404500ddf71
Author:     Sergiy Borodych <Sergiy.Borodych@gmail.com>
AuthorDate: 2020-04-04 07:46:27 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2020-04-10 23:31:00 +0000

    app-portage/g-cpan: version bump to 0.17.0
    
    Bug: https://bugs.gentoo.org/581490
    Closes: https://github.com/gentoo-perl/g-cpan/issues/26
    Signed-off-by: Sergiy Borodych <Sergiy.Borodych@gmail.com>
    Closes: https://github.com/gentoo/gentoo/pull/15214
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 app-portage/g-cpan/Manifest             |  1 +
 app-portage/g-cpan/g-cpan-0.17.0.ebuild | 62 +++++++++++++++++++++++++++++++++
 2 files changed, 63 insertions(+)