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.
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.
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
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"
Please show you emeg-cpan
Please show your: $ emerge --info g-cpan $ ls -l /etc/portage/make.conf /usr/share/portage/config/make.globals
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
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
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.
See also: https://github.com/gentoo-perl/g-cpan/issues/26
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.
Try to set both vars (like was in the past) PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage"
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?
When will the PORTDIR issue be fixed?
@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
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.
Guys please check last git revision. By `emerge -av =app-portage/g-cpan-9999` Is it works for you now?
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.
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
$ 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.
Created attachment 453340 [details] output of emerge --info g-cpan
Jack, thank you. Now please for sure: $ ls /usr/local/portage/perl-gcpan/* $ g-cpan -vl
$ 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
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.
Jack, another request. Please run test phase during installation $ FEATURES="test" emerge -1v app-portage/g-cpan
/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.
Created attachment 453936 [details] g-cpan-9999 build.log with FEATURES="test"
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 :)
(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.
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.
(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 $?“
@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.
@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
@Sergiy: I'm away from home, but I'll get your information on Monday. Jack
(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.
Created attachment 454644 [details] output of 'g-cpan -ipvd Image-EXIF && echo $?'
@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.
@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.
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
$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
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.
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.
What's the status of this issue? I just re-emerged g-cpan, and don't see anything different. Thanks.
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.
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?
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.
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.
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(+)
