You are not logged in.
If you need more info, feel free to ask.
Do you see the same error message when you type "cpan4pacman --help" ?
And if you did configure cpanplus, did you do so as normal user (coz then it it should have created ~/.cpanplus/ and put some config and data files in it).
Offline
Yes, that gives me the same error messages.
Yes, I tried it as a normal user as well as a super user and I got the same problem.
But tomorrow I'll have a better look and try to search for a solution
Offline
Pieter: I think I found the problem. You probably do not have an abs tree on your system. Run "sudo abs" to create it and then try "cpan4pacman" again and then things should work (but tell me if not). You should see the file perl_abs.yml in your .cpanplus directory, which contains a database of perl packages in the Arch repos.
Actually there should be a warning message asking the user to update abs before running cpan4pacman for the first time. I'll fix that in the next version.
General remark: Another point on my TODO list is to catch CPAN packages that require interactive setup (at the "perl Makefile.PL" stage) so that they are not automatically built. A warning should then tell the user to customize the configure options in the PKGBUILD by hand (an good example is the Template-Toolkit, which however is available on AUR).
Offline
I think I found the problem. You probably do not have an abs tree on your system. Run "sudo abs" to create it and then try "cpan4pacman" again and then things should work (but tell me if not). You should see the file perl_abs.yml in your .cpanplus directory, which contains a database of perl packages in the Arch repos.
Hello, That didn't solve my problem because I did that at the beginning (I was ordered to do so in the install script). But when I try
cpan4pacman --abs-cache
I get the same error
YAML Error: Couldn't open /home/pieter/.cpanplus/ for output:nBad file descriptor
Code: YAML_DUMP_ERR_FILE_OUTPUT
The perl_abs.yml does not exist in my folder
Hope this can help you a bit
Offline
I have abs, and i've added the server to pacman.conf (very recent -Sy). My output from issuing cpan4pacman --abs-cache is as follows:
Use of uninitialized value in substitution (s///) at /usr/lib/perl5/5.8.8/File/Spec/Unix.pm line 59.
Use of uninitialized value in substitution (s///) at /usr/lib/perl5/5.8.8/File/Spec/Unix.pm line 60.
Use of uninitialized value in string eq at /usr/lib/perl5/5.8.8/File/Spec/Unix.pm line 61.
Use of uninitialized value in substitution (s///) at /usr/lib/perl5/5.8.8/File/Spec/Unix.pm line 61.
Use of uninitialized value in substitution (s///) at /usr/lib/perl5/5.8.8/File/Spec/Unix.pm line 62.
Use of uninitialized value in substitution (s///) at /usr/lib/perl5/5.8.8/File/Spec/Unix.pm line 63.
Use of uninitialized value in string eq at /usr/lib/perl5/5.8.8/File/Spec/Unix.pm line 64.
Use of uninitialized value in substitution (s///) at /usr/lib/perl5/5.8.8/File/Spec/Unix.pm line 64.
Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/5.8.8/File/Spec/Unix.pm line 65.
YAML Error: Couldn't open /root/.cpanplus/ for output:nBad file descriptor
Code: YAML_DUMP_ERR_FILE_OUTPUT
at /usr/bin/cpan4pacman line 27
Compilation failed in require at /usr/bin/cpan4pacman line 27.
BEGIN failed--compilation aborted at /usr/bin/cpan4pacman line 27.
What's wrong?
Offline
I have abs, and i've added the server to pacman.conf (very recent -Sy). My output from issuing cpan4pacman --abs-cache is as follows:
<...>
What's wrong?
Sorry for replying a bit late. Quite busy these days.
Question: do all three directories /var/abs/system, /var/abs/extra and /var/abs/community exist on your system? If not, the abs-cache will not work.
Comment: the output indicates you are running cpan4pacman --abs-cache as superuser, as it tries to write to /root/.cpanplus/ ... Run it again as normal user.
The above may not solve the issue, though, and I will try to fix the problem as soon as I get some time. As a temporary work-around you can download an uptodate abs cache from http://ankabut.net/varia/perl_abs.yml.gz which you can then gunzip and copy to your ~/.cpanplus directory.
Hope it helps!
Offline
i'm also getting the same problem as pieterO and ootput. the work around doesn't appear to work.
Offline
Hi folks,
thanks for your bug reports and your patience.
I have just uploaded version 0.2.3 on my repo.
This version should now be free of the bug reported above. It was nothing but a typo in the default configuration file (cpan4pacman.yml) ... :oops: I had not noticed myself because the typo only surfaced in version 0.2, so only users with a fresh install were affected. Apologies to all for that.
Now things should work more smoothly.
Offline
perl-cpanplus-pacman and all its dependencies are now available on AUR.
Offline
Will you still be maintaining the cpanplus repo?
Offline
Will you still be maintaining the cpanplus repo?
Yes, of course, I will! (I hope some day many of the packages in my repo, which represent some of the latest highlights in advanced Perl programming, will migrate to the community repo, but until then I will try to actively maintain it.)
You may already have noticed that I have just updated several packages to my cpanplus repo, in sync with my uploads to AUR:
* perl-cpanplus-pacman -> ver 0.2.4 (fixes the problem with relative path in --basedir you raised on May 29)
* perl-cpanplus -> version 0.72 (with an easier configuration system).
* minor updates of a few more dependencies.
* perl-cpanplus now needs perl-package-constants.
* NB: perl-ipc-run is no longer required by perl-cpanplus, so you can remove it if you wish.
BE AWARE OF THE CHANGES IN THE CONFIGURATION OF CPANPLUS.
The message displayed during install/update should be clear. Tell me if not.
Offline
Some more feedback, Firmicus. I'm currently using cpan4pacman to build around 30 modules required for WebGUI. It's going well, but I've had a couple of hitches, which I'll describe here in case you want to do anything about them.
Firstly, modules that use Build.PL instead of Makefile.PL do not build correctly, even with the --nomakefile flag. However, the script still produces a package, which is of course broken, and very misleading. The examples I have are DateTime::TimeZone and DateTime::Format::Mail. In both cases, I had to modify the automated PKGBUILD to produce successful packages - the results are here and here, and they're a bit kludgy, but at least they work.
Secondly, if a requested module has prereqs, it seems that it is sometimes necessary for them to be actually installed before the build is completely successful. The example here is Net::LDAP, which depends on Convert::ASN1. If neither is installed, and
cpan4pacman NET::LDAP
is run, the build process checks for Convert::ASN1, uses CPAN to get it, and incorporates it into the resulting perl-ldap package, with an incorrect /5.8.8 path instead of /current. cpan4pacman then proceeds to create a separate perl-convert-asn1 package, so we end up with duplicate files. However, if perl-convert-asn1 is built and installed first, perl-ldap builds correctly.
Finally, a feature request. Can you automate the decision about the package description i.e. if LWP::Simple and XML::XPath are present, get the description, if not, use the module name? The user interaction required at the moment rules out unattended creation of multiple packages.
Offline
Hi Tomk,
your feedback is much appreciated. I am sorry for replying nearly a month later. I was travelling during the last month and I did not notice your posting. I had actually fixed the issues you raised concerning packages that rely on the the Build.PL mechanism is early August, but because I was about to leave I somehow forgot to upload my latest version. Now it is done. I had myself created a PKGBUILD for DateTime::TimeZone last month, which built successfully. Try to generate it again with cpan4pacman version 0.2.5. Your output should look like this.
Thus to avoid your sed hacks, you can simply give the following parameters:
perl Build.PL destdir=$startdir/pkg
--install_path lib=/usr/lib/perl5/site_perl/current
--install_path arch=/usr/lib/perl5/site_perl/current/${archname}
followed by the usual
./Build
./Build install
Sorry again, for if I had uploaded my fix last month, that would have save you from some trouble...
I'll look at the other two issues you raised ASAP. The second one (non-interactive retrieval of package description) will be easy.
Best,
F
Offline
Thanks Firmicus, and no apology necessary. Life is more important than coding - I hope your travels went well.
I've installed 0.2.5, and I'm still having problems. The PKGBUILD is still trying to use Makefile.PL, and failing as before. Is there any chance you uploaded an incorrect version?
Offline
I just discovered this tool and it's great. I've been installing newer modules in my homedir and telling pacman.conf to ignore many of the perl modules provided by arch, but this little tool eliminated all of those workarounds.
As an experiment, I compiled every perl module in the pacman database, along with all of the modules I use personally and created a local repo. It's working flawlessly!
Thanks for creating this.
Offline
Charles: thanks a lot for your warm comments! I am glad to hear it is useful.
Tomk and all others: Apologies for the VERY LONG interruption! :?
I have resumed work on this tool. A new version (0.2.6) is available on my repository, with the following changes:
* spurious line depends=('') no longer generated in PKGBUILD
when package has no dependencies
* missing pkg description now automatically fetched from search.cpan.org
when required modules (from packages perl-libwww and perl-xml-xpath) are available
Tomk: do you still have problems with packages that work with the Build.PL mechanism? They compile correctly here...
Offline
Great Script!
You should add to PKGBUILD this dependencies:
perl-log-message
perl-params-check
perl-module-load
perl-package-constants
Offline
same dependencies as Cagnulein here.
after installing i updated abs then run 'cpan4pacman --abs-cache' i get:
Base class package "Object::Accessor" is empty.
(Perhaps you need to 'use' the module which defines that package first.)
at /usr/lib/perl5/site_perl/5.8.8/CPANPLUS/Config.pm line 6
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.8/CPANPLUS/Config.pm line 6.
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.8/CPANPLUS/Configure.pm line 7.
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.8/CPANPLUS/Configure.pm line 7.
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.8/CPANPLUS/Backend.pm line 7.
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.8/CPANPLUS/Backend.pm line 7.
Compilation failed in require at /usr/bin/cpan4pacman line 24.
BEGIN failed--compilation aborted at /usr/bin/cpan4pacman line 24.
what am i missing here?
Offline
It seems to me those dependencies are for perl-cpanplus, which is out of date. Just to run cpanp I needed to install the following packages, in addition to those listed above:
perl-object-accessor
perl-module-load-conditional
perl-ipc-cmd
perl-module-loaded
perl-archive-extract
perl-file-fetch
perl-module-pluggable
perl-term-ui
Note that the Object::Accessor error goes away after installing perl-object-accessor.
Once those are installed, cpanp worked. Then I installed the following for cpan4pacman to work:
perl-module-corelist
After I installed all those, cpan4pacman worked great! Thanks Firmicus!
Last edited by jcasper (2007-08-01 23:31:25)
Offline
Xterminus has been doing work on perl packages under arch:
See here:
http://wiki.archlinux.org/index.php/PerlCPAN_Repository
http://xtermin.us/journal/
James
Offline
perl-cpanplus-pacman has been updated to 0.2.9 and is now in community. My cpanplus repository is closed.
@iphitus: Yes, xterminus has done a good work, but his automated generation of PKGBUILDs was not unproblematic, and his packages in community have not been updated since a few months.
Offline
Found a bug in perl-cpanplus-pacman. Output:
> cpan4pacman Text::Kakasi
<snip>
Kakasi.xs:33:23: error: libkakasi.h: No such file or directory
Kakasi.xs: In function 'XS_Text__Kakasi_xs_do_kakasi':
Kakasi.xs:62: warning: assignment makes pointer from integer without a cast
make: *** [Kakasi.o] Error 1
==> ERROR: Build Failed. Aborting...
Package perl-text-kakasi built successfully.
You can now install it with pacman
Obviously it didn't build successfully...
Offline
Found a bug in perl-cpanplus-pacman. Output:
> cpan4pacman Text::Kakasi <snip> Kakasi.xs:33:23: error: libkakasi.h: No such file or directory Kakasi.xs: In function 'XS_Text__Kakasi_xs_do_kakasi': Kakasi.xs:62: warning: assignment makes pointer from integer without a cast make: *** [Kakasi.o] Error 1 ==> ERROR: Build Failed. Aborting... Package perl-text-kakasi built successfully. You can now install it with pacman
Obviously it didn't build successfully...
I am aware of that. Well, it's not really a bug, more a missing feature! cpan4pacman should really catch error codes issued by makepkg. So far it does not, hence the spurious message. I'll try to fix that for the next version (should be straightforward with IPC::Run).
Note that cpan4pacman is just a tool to make it easier to write Perl-related PKGBUILDs. It can't solve all problems, especially those occurring with very complicated CPAN distributions or external dependencies, or upstream bugs...
Usually I use it with the option --nobuild and I check the README and the PKGBUILD before calling makepkg by hand.
It your case it seems that kakasi (http://kakasi.namazu.org/) is a dependency of this module. Oh! Now I see that you have fixed these things yourself and uploaded perl-text-kakasi and kakasi to AUR All right then!
Offline
This may be of interest to you:
http://bugs.archlinux.org/task/10274
[git] | [AURpkgs] | [arch-games]
Offline
I noticed a package created with cpan4pacman http://repos.archlinux.org/viewvc.cgi/m … iew=markup
Two things:
1) It uses the exact same string for 2 variables. Isnt that kind of pointless? AFAIK its OK to use ${_pkgname} instead of ${_realname} so why use them both?
2) 'x64_86' is not an architecture.
Maybe the above are just tomk's fault and not the scripts. I havent used/tested/read its code
There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums. That is why we avoid it. -- ewaller (arch linux forum moderator)
Offline