On Wed, Jun 29, 2011 at 09:02:22PM -0700, Steve Holmes wrote:

On Thu, Jun 30, 2011 at 06:36:37AM +0530, gt wrote:

...

Did you look at the post installation message, when you upgraded perl.

It should have something like this:

-------------------------------------------------------------------------

The directories /usr/lib/perl5/current, /usr/lib/perl5/site_perl/current, /usr/lib/perl5/site_perl/5.10.1, and /usr/share/perl5/site_perl/5.10.1 have been removed from @INC. The script/binary directories are now /usr/bin/*_perl instead of /usr/lib/perl5/*_perl/bin which will be eventually removed.

Yes I did and why I suspect the breakage. Though these directories were removed, that doesn't tell me what I need to do to fix the problem I have now with basic programs like automake. What am I missing here?

Did you try re-installing automake?

On Thu, Jun 30, 2011 at 09:13:31AM +0300, Ionut Biru wrote:

On 06/30/2011 03:35 AM, Steve Holmes wrote:

...

I think when perl was upgraded to 5.14, something broke with one of its libraries. Whenever I type 'automake' or attempt to recompile several perl packages from AUR, I get the following error message: /usr/bin/perl: symbol lookup error: /usr/lib/perl5/vendor_perl/auto/List/Util/Util.so: undefined symbol: Perl_Istack_sp_ptr

Thoughts anyone? I see this as a show stopper for any development right now.

Thanks.

pacman -Qo /usr/lib/perl5/vendor_perl/auto/List/Util/Util.so

maybe you installed some perl modules outside of pacman

perl-scalar-list-utils - found in AUR; it is required by perl-eval-closure and replaces perl-scalar-utils.

On 06/30/2011 02:32 AM, Thomas Bächler wrote:

Am 30.06.2011 02:35, schrieb Steve Holmes:

...

/usr/bin/perl: symbol lookup error: /usr/lib/perl5/vendor_perl/auto/List/Util/Util.so: undefined symbol: Perl_Istack_sp_ptr That file is not part of any package in the Arch repositories.

I'm seeing this during boot: Wed Jun 29 14:48:09 2011: XSLoader::load('Your::Module', $Your::Module::VERSION) at /usr/lib/perl5/core_perl/XSLoader.pm line 25. Wed Jun 29 14:48:09 2011: Compilation failed in require at /etc/rc.d/ptal-init line 115. Wed Jun 29 14:48:09 2011: BEGIN failed--compilation aborted at /etc/rc.d/ptal-init line 11 with regard to the ptal-init for my hp officejet. Is this related? Bog standard arch 64 box updated to current updates as of 6/29/11...no issues other than this, but it breaks the printer. Casey

On 06/30/2011 03:33 AM, Thomas Bächler wrote:

Am 30.06.2011 11:09, schrieb Casey Peter:

...

I'm seeing this during boot:

Wed Jun 29 14:48:09 2011: XSLoader::load('Your::Module', $Your::Module::VERSION) at /usr/lib/perl5/core_perl/XSLoader.pm line 25. Wed Jun 29 14:48:09 2011: Compilation failed in require at /etc/rc.d/ptal-init line 115. Wed Jun 29 14:48:09 2011: BEGIN failed--compilation aborted at /etc/rc.d/ptal-init line 11

with regard to the ptal-init for my hp officejet. Is this related? This file is not part of any Arch package either.

Actually, it is. It is a script required for the officejet series of printers included in this package: @Kandalf ~]$ pacman -Ss hpoj extra/hpoj 0.91-16 [installed] Hewlett-Packard OfficeJet, PSC, LaserJet, and PhotoSmart printer multi-function peripherals (MFPs) drivers and is placed in the rc.conf to initialize the printer. example: DAEMONS=(syslog-ng !hwclcock crond dbus networkmanager ntpd !alsa avahi-daemon_ptal-ini_t @cups clamav sensors dropboxd netfs) Casey

On 06/30/2011 12:51 PM, Thomas Bächler wrote:

Am 30.06.2011 11:54, schrieb Casey Peter:

...

On 06/30/2011 03:33 AM, Thomas Bächler wrote:

...

Am 30.06.2011 11:09, schrieb Casey Peter:

...

I'm seeing this during boot:

Wed Jun 29 14:48:09 2011: XSLoader::load('Your::Module', $Your::Module::VERSION) at /usr/lib/perl5/core_perl/XSLoader.pm line 25. Wed Jun 29 14:48:09 2011: Compilation failed in require at /etc/rc.d/ptal-init line 115. Wed Jun 29 14:48:09 2011: BEGIN failed--compilation aborted at /etc/rc.d/ptal-init line 11

with regard to the ptal-init for my hp officejet. Is this related? This file is not part of any Arch package either.

Actually, it is. It is a script required for the officejet series of printers included in this package: I am talking about /usr/lib/perl5/core_perl/XSLoader.pm.

This discussion needs more info: pacman -Q perl mod_perl those two provide XSLoader.pm. Btw i can't see that hpoj has been rebuild for perl, but it doesn't fail here with /etc/rc.d/ptal-init -- Jelle van der Waa

On 06/30/2011 05:08 AM, Thomas Bächler wrote:

Am 30.06.2011 12:59, schrieb Jelle van der Waa:

...

This discussion needs more info: pacman -Q perl mod_perl those two provide XSLoader.pm. They provide it, but at a different path. The file mentioned here is not contained in any package we built.

Not a clue at this point. Yesterday, ptal-init worked fine. perl upgrade and now that error on boot up. Just passing the info along. I do have a few AUR packages on my system, but no breakages from anything other than ptal-init as reported. C

On 06/30/2011 05:52 AM, John K Pate wrote:

...

I do have a few AUR packages on my system, but no breakages from anything other than ptal-init as reported. I had a breakage (with the same error message) with rxvt-unicode-chinese from the AUR, but it was resolved upon upgrading to the new version. I don't know if the fix was due to recompiling or the new version, however.

== John K Pate http://homepages.inf.ed.ac.uk/s0930006/

Trouble with this is...breakage is not AUR related (that I'm aware of)...nor was any of the package(s) updated AUR related. The reboot was for the kernel, or I might not have seen this for a bit. :-/ C

clemens fischer wrote:

% urxvt urxvt: symbol lookup error: /usr/lib/perl5/site_perl/auto/List/Util/Util.so: undefined symbol: Perl_Istack_sp_ptr

I moved Util.so elsewhere and urxvt started working again.

But:

# cpanp Data::Dumper object version 2.130_02 does not match $Data::Dumper::VERSION 2.126 at /usr/lib/perl5/core_perl/DynaLoader.pm line 213. Compilation failed in require at /usr/share/perl5/core_perl/Params/Check.pm line 8. BEGIN failed--compilation aborted at /usr/share/perl5/core_perl/Params/Check.pm line 8. Compilation failed in require at /usr/share/perl5/core_perl/Log/Message.pm line 5. BEGIN failed--compilation aborted at /usr/share/perl5/core_perl/Log/Message.pm line 5. Compilation failed in require at /usr/share/perl5/core_perl/CPANPLUS/Error.pm line 5. BEGIN failed--compilation aborted at /usr/share/perl5/core_perl/CPANPLUS/Error.pm line 5. Compilation failed in require at /usr/share/perl5/core_perl/CPANPLUS.pm line 6. BEGIN failed--compilation aborted at /usr/share/perl5/core_perl/CPANPLUS.pm line 6. Compilation failed in require at /usr/bin/core_perl/cpanp line 11. BEGIN failed--compilation aborted at /usr/bin/core_perl/cpanp line 11.

out of curiosity, I did:

# mmv /usr/lib/perl5/core_perl/ /usr/lib/perl5/core_perl-old `/usr/lib/perl5/core_perl/' -> `/usr/lib/perl5/core_perl-old' ~ 0 3 # cpanp /usr/bin/perl: error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory ~ # locate -i libperl.so (no output) ~ # find /usr/bin/core_perl/ -type f ( -name *libperl* ) (no output)

thanks for looking into this. I had to rename /usr/lib/perl5/site_perl (to /usr/lib/perl5/site_perl-old) to make things like automake and cpanplus work again. clemens

On Thu, Jun 30, 2011 at 02:23:23PM +0200, Thomas Bächler wrote:

Am 30.06.2011 13:25, schrieb Casey Peter:

...

On 06/30/2011 05:08 AM, Thomas Bächler wrote:

...

Am 30.06.2011 12:59, schrieb Jelle van der Waa:

...

This discussion needs more info: pacman -Q perl mod_perl those two provide XSLoader.pm. They provide it, but at a different path. The file mentioned here is not contained in any package we built.

Not a clue at this point. Yesterday, ptal-init worked fine. perl upgrade and now that error on boot up.

You have a file on your system that causes breakage, and is either not tracked by pacman, or contained in a non-official package. Isn't the solution obvious here? In the first case, delete the file, in the second case, delete the broken package.

After plowing through this thread, I am replying to say that the library in question belongs to perl-scalar-list-utils which can be found in AUr. It is required by other packages like perl-eval-closure. It is all part of a long list of cascading dependencies for perl-moos and perl-net-twitter. One other thing I observe with this package is that perl-scalar-list-utils has a 'replaces' entry, replacing perl-scalar-utils; I don't see that name in any repos nor my system at the moment.

On 6/30/11, gt wrote:

On Thu, Jun 30, 2011 at 05:42:47AM -0700, Steve Holmes wrote:

...

After plowing through this thread, I am replying to say that the library in question belongs to perl-scalar-list-utils which can be found in AUr. It is required by other packages like perl-eval-closure. It is all part of a long list of cascading dependencies for perl-moos and perl-net-twitter.

One other thing I observe with this package is that perl-scalar-list-utils has a 'replaces' entry, replacing perl-scalar-utils; I don't see that name in any repos nor my system at the moment.

perl-scalar-utils was available in aur earlier i think. But it was removed sometime back.

Yeah, I figure this package replaced that one. Anyway, it contains the library that is causing my problems. I wouldn't mind merely removing this package but then the packages requiring perl-scalar-list-utils will start complaining so I feel like I might be getting trapped in dependency hell. If that library is indeed a part of other standard packages, then at least automake should start working again.

On Fri, Jul 01, 2011 at 09:40:22AM +0530, gt wrote:

Did you try rebuilding perl-scalar-list-utils?

I did again just now and re-installed. automake still works but I still can't compile perl-moose but I get another lookup error so I rebuilt the package that owns the library causing the error but still no go. At least automake works so I can build other packages. I have never seen such a colamity of errors with changes to perl though. I guess I will post a bug report to the perl-moose package in AUR to see how to resolve it. I'm not heavy waited enough in perl to be able track down these root causes without some help from my friends:).

On 7/1/11, Florian Pritz wrote:

On 01.07.2011 14:38, Steve Holmes wrote:

...

I still can't compile perl-moose but I get another lookup error so I rebuilt the package that owns the library causing the error but still no go. At least automake works so I can build other packages. I have never seen such a colamity of errors with changes to perl though.

I guess I will post a bug report to the perl-moose package in AUR to see how to resolve it. I'm not heavy waited enough in perl to be able track down these root causes without some help from my friends:).

`cpanp i Moose` works fine here.

IMHO you should install perl-cpanpplus-dist-arch (run setupdistarch as your user afterwards) and use cpanp to generate and install pacman perl packages. It's way easier to use than AUR.

This is what I did: pacman -Qm | grep "^perl-" > perlpkgs pacman -Rcs $(

-- Florian Pritz

Hey, that sounds like an excellent alternative. That day I setup perl-net-twitter, I think I had to install over 30 dependencies before the day was done! Is this cpanp package also available in AUR or is this something separate?

On Fri, Jul 01, 2011 at 03:20:31PM +0200, Florian Pritz wrote:

`cpanp i Moose` works fine here.

It doesn't for me. I'll describe below.

IMHO you should install perl-cpanpplus-dist-arch (run setupdistarch as your user afterwards) and use cpanp to generate and install pacman perl packages. It's way easier to use than AUR.

Been there, done that. I did the setup and the appropriate directory was built successfully in my home directory - .cpanplus is the root of cpanplus app[arently.

This is what I did: pacman -Qm | grep "^perl-" > perlpkgs pacman -Rcs $(

Once the perlpkgs file was built, I had to go in and manually remove all the version numbers; otherwise, pacman threw errors; it could not recognize them as additional packages.

use cpanp to reinstall everything in perlpkgs that you still need

Do you need to be root to do this installation? I ask this because after building the .cpanplus resources under my home directory, I figured I would have to do 'cpanp -i Net::Twitter' from my normal user account. But nothing got installed and the packages all complained about missing dependencies. I read the documentation (what little there was) and I can't figure out what else I need to do to get this working. It appears a bunch of packages got download and expanded into ./cpanplus/lib/5.14.1 but they all failed because none of the other dependencies were installed yet. What do I need to do here?

On 03.07.2011 07:45, Steve Holmes wrote:

...

This is what I did: pacman -Qm | grep "^perl-" > perlpkgs pacman -Rcs $(

Once the perlpkgs file was built, I had to go in and manually remove all the version numbers; otherwise, pacman threw errors; it could not recognize them as additional packages.

Oops, that should have been pacman -Qqm.

...

use cpanp to reinstall everything in perlpkgs that you still need

Do you need to be root to do this installation? I ask this because after building the .cpanplus resources under my home directory, I figured I would have to do 'cpanp -i Net::Twitter' from my normal user account. But nothing got installed and the packages all complained about missing dependencies. I read the documentation (what little there was) and I can't figure out what else I need to do to get this working. It appears a bunch of packages got download and expanded into ./cpanplus/lib/5.14.1 but they all failed because none of the other dependencies were installed yet.

What do I need to do here?

I had the problem that old packages interfered with the dependency resolution and led to build failures for the new ones. If you have anything left over (aur packages, old ones install by cpan), try removing that. This might be solved quicker if you ask folks on irc. -- Florian Pritz

On 04.07.2011 02:02, Steve Holmes wrote:

Where does cpanp get the information to generate a properly configured PKGBUILD for a module?

From the META.yml [1] file on cpan.

Right now, I cannot use cpanp to build Params::Util because it keeps sticking a bad dependency in the PKGBUILD for perl.

Well, perl guys tend to loose the dots so 5.14.1 would be 5.014001. You can test that using `perl -v` or `perl -e 'print $^V'` and `perl -e 'print $]'`. "$]" and "$^V" contain the perl version you're running in different formats. I have no idea why there are two formats though.

I have cpanplusdistarch configured to autogenerate the arch package. Should I not be doing this? When I tried installing CPANPLUS::Dist::Arch by using cpanp, it put the scripts in the wrong place so I couldn't execute them. Instead, I removed that install and installed the perl-cpanplus-dist-arch from AUR; that way the scripts are in the right place.

Works fine for me. [1] http://cpansearch.perl.org/src/ADAMK/Params-Util-1.04/META.yml -- Florian Pritz