AUR install packages with Perl broken again

update

#1

After recent system upgrade, once again, Shutter, Gscan2pdf is broken again…

Launching Shutter I get the following;

Can't locate Gnome2.pm in @INC (you may need to install the Gnome2 module) (@INC contains: /usr/lib/perl5/5.26/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/5.26/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/5.26/core_perl /usr/share/perl5/core_perl) at /usr/bin/shutter line 37.
BEGIN failed--compilation aborted at /usr/bin/shutter line 37.

Launching Gscan2pdf I get;

Can't locate Goo/Canvas.pm in @INC (you may need to install the Goo::Canvas module) (@INC contains: /usr/lib/perl5/5.26/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/5.26/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/5.26/core_perl /usr/share/perl5/core_perl) at /usr/share/perl5/vendor_perl/Gscan2pdf/Canvas.pm line 7.
BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/Gscan2pdf/Canvas.pm line 7.
Compilation failed in require at /usr/bin/vendor_perl/gscan2pdf line 58.
BEGIN failed--compilation aborted at /usr/bin/vendor_perl/gscan2pdf line 58.

Anyone have any ideas, here is what I have tried so far:
pacaur -Syu --rebuild --foreign

sudo pacman -S perl


Cannot install gscan2pdf from AUR
#2

According to this announcement perl got a rebuild/update.

So I will suggest you re-compile your AUR packages that use Perl.
And if that does not work, then you need to wait for the AUR maintainers to update their pkgbuilds.


#3

Good practice to flag it out of date and add a comment informing other users of this issue, assuming it has not already been done.

Timely reminder that AUR packages are user maintained, and not distro maintained.


#4

The problem here is: Perl first gets into Arch testing, then into Arch stable, then into Manjaro unstable, testing, stable. So users are affected by the update at several different points in time and maintainers of perl related AUR packages would have to bump their packages’ revisions at each of these points to ensure a clean update for everybody. On the other hand, with such many bumps, people would have to rebuild the packages several times at each perl update. Therefore I actually stopped bumping the revisions of my perl related packages at some point leaving it to the users to rebuild packages which get broken after perl updates. In particular, I pinned a comment at Shutter’s AUR page giving instructions how to do so: https://aur.archlinux.org/packages/shutter/

But I am open for proposals how to handle this problem in a better way! :slight_smile:


Automatic update of broken Perl packages from AUR
#5

Makes perfect sense.


#6

More news about perl can be found here.


#7

For the less techie that want their system to work again, here is what you do;

Run the following command: pacman -Qqo '/usr/lib/perl5/vendor_perl'

It will generate a list of packages that need to be rebuilt, take that list and append it to this command;
pacaur -Syu --rebuild *****-***** *****-******

For my system, I had to use the the following command;
pacaur -Syu --rebuild gnome-perl gnome-vfs-perl gnomecanvas-perl perl-config-general perl-gnome2-wnck perl-goo-canvas perl-gtk2-ex-simple-list perl-gtk2-imageview perl-gtk2-unique perl-pdf-api2 perl-set-intspan

Note: If you don’t have pacaur installed, install it first.


#8

I had to do

pacman -Qqo '/usr/lib/perl5/5.26/vendor_perl'

Thank you for information


#9

@banjo, I believe the versioned paths don’t need to be rebuilt. Those are precisely part of the new perl versioning path for compiled modules. So, any module present in a version-named path inside /usr/lib/perl5/ is a module that has already been compiled to the version in the directly name.

With this initial update to 5.26, you should only worry about any modules in the old non-versioned path, as described in @Joao post. Many users won’t have anything in there.

With subsequent updates it is my understanding (but I would need someone to confirm this) that for Manjaro packages, you don’t have to worry as any perl modules explicitly or implicitly installed will be updated for you. But any perl modules installed by AUR (aka foreign packages), will need to be updated manually. For this you will need to run the above command, replacing the 5.26 path with the version prior to the update.


#10

With https://www.archlinux.org/news/perl-library-path-change/ in place, what is the expected output of perl -e "print qq(@INC)"?

For me it is currently:

$ perl -e "print qq(@INC)"
/usr/lib/perl5/site_perl 
/usr/share/perl5/site_perl 
/usr/lib/perl5/vendor_perl 
/usr/share/perl5/vendor_perl 
/usr/lib/perl5/core_perl 
/usr/share/perl5/core_perl

Which is leading to build-errors for example with gimp-png (AUR) which requires Parser::XML which is installed under /usr/lib/perl5/5.26/vendor_perl/ as required by the new module paths.

Since I can install gimp-apng just fine with PERL5LIB=/usr/lib/perl5/5.26/vendor_perl/ pacaur -S gimp-apng my guess is that my default perl include paths are not up-to-date yet for some reason?

$ perl -v

This is perl 5, version 26, subversion 0 (v5.26.0) built for x86_64-linux-thread-multi

#11

I have all paths updated to the versioned path:

$ printf '%s\n' $(perl -e "print qq(@INC)")
/usr/lib/perl5/5.26/site_perl
/usr/share/perl5/site_perl
/usr/lib/perl5/5.26/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib/perl5/5.26/core_perl
/usr/share/perl5/core_perl

What’s your output for $ pacman -Q perl?


#12

On my work computer where perl shows outdated INC paths it is:

$ pacman -Q perl
perl 5.26.0-1

while on my personal computer it is:

$ pacman -Q perl
perl 5.26.0-4

while both are up-to-date after running pacman -Syu, weird…

Addendum - Fixed:
Seems like my system was somehow out-of-sync, but after running pacman -Syyuu I now get

$ printf '%s\n' $(perl -e "print qq(@INC)")
/usr/lib/perl5/5.26/site_perl
/usr/share/perl5/site_perl
/usr/lib/perl5/5.26/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib/perl5/5.26/core_perl
/usr/share/perl5/core_perl

$ pacman -Q perl
perl 5.26.0-4

Edit:
What caused this sudden inspiration was that as of today pacman -Syu failed to update lib32-glibc due to missing dependencies:

$ pacaur -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
:: Starting full system upgrade...
resolving dependencies...
warning: cannot resolve "glibc>=2.26", a dependency of "lib32-glibc"
:: The following package cannot be upgraded due to unresolvable dependencies:
      lib32-glibc

:: Do you want to skip the above package for this upgrade? [y/N] n
error: failed to prepare transaction (could not satisfy dependencies)
:: lib32-glibc: requires glibc>=2.26

I’m unsure how my system got out-of-sync, since I’m not using any testing-repository. Luckily both issues where finally fixed by pacman -Syyuu. Hope this might also help somebody else… :smile: