Package Details: perl-devel-repl 1.003028-3

Git Clone URL: (read-only, click to copy)
Package Base: perl-devel-repl
Description: a modern perl interactive shell
Upstream URL:
Licenses: GPL, PerlArtistic
Submitter: xenoterracide
Maintainer: mbunkus
Last Packager: mbunkus
Votes: 6
Popularity: 0.000043
First Submitted: 2010-05-02 14:42
Last Updated: 2018-08-23 16:02

Latest Comments

1 2 3 Next › Last »

mbunkus commented on 2018-08-24 15:33

The warnings while building perl-getopt-long-descriptive don't indicate that the package won't work. They only indicate that the package uses deprecated features that will be gone in Perl 5.32. You can simply build perl-getopt-long-descriptive without the tests, install it and continue with perl-moosex-getopt.

Additionally you should probably file a bug report with Getopt::Long::Descriptive.

hexadecagram commented on 2018-08-24 03:08

Thanks for the tips, @mbunkus, I did as you prescribed.

When I reach step 4, it says that it wants perl-getopt-long-descriptive, which also fails testing.

mbunkus commented on 2018-08-23 16:04

I am aware of the Perl update. The problem is, as you've noticed, that its dependency perl-moosex-getopt doesn't test cleanly. A new version has already been released upstream that does compile, and perl-moosex-getopt has appropriately flagged as outdated.

So here's your solution:

  1. Clone perl-moosex-getopt
  2. Adjust its PKGBUILD to build 0.72 instead of 0.71
  3. Install perl-test-needs, a new dependency of MooseX::Getopt 0.72
  4. Build & install your modified perl-moosex-getopt
  5. Build perl-devel-repl

I've just pushed a new version of perl-devel-repl that not only bumps the pkgrel, but also depends on perl-moosex-getopt>=0.72 in order to make this explicit.

hexadecagram commented on 2018-08-23 09:20

ArchLinux Perl got updated from 5.26 to 5.28 recently, and as a result this package is b0rken.

pacman does not upgrade perl modules when a new base version is released, so to force a reinstall of all the modules, I run:

LC_ALL=C find "/usr/lib/perl5/site_perl" -type f -exec pacman -Qqo {} + |& sed -n 's/^error: No package owns \(.*\)$/\1/p'

as prescribed.

Some packages lag behind, such as perl-task-weaken and perl-getopt-long-descriptive. The former continues to install in /usr/lib/perl5/5.26 where as the latter just flatly fails to pass the testing phase.

Also, I made a comment for perl-data-dump-streamer which is one of the complaints fires at me when it starts. It seems to want this package even though it doesn't seem strictly necessary (I've gotten it to run without it).

The only solution right now is to pacman -Rccs perl-devel-repl and hope that some kind user can help me get it reinstalled. ;-)

jnbek commented on 2016-04-08 14:27

Also, regarding my Jenkins builder, I'll Open Source it when it's ready. It will scan your aur4/ root for new dirs, changes to PKGBUILDs etc using Inotify and trigger builds, create new builds if a new directory appears in the root, delete builds when a dir is removed ( say deleted pkgbuilds etc ). That way, it'll help those of us with a cpl hundred thousand PKGBUILDs to stay ahead of problems. I hope to have it done before Perl 5.24 releases, since core perl always makes for funtimes for perlaur :-P Email me, or add me on FB and we'll coordinate testing etc.

jnbek commented on 2016-04-08 14:23

Err, no, I'm very active with Maintainership of the AUR. I do rely heavily on the users to inform me when things break, even with an autobuilder, new deps can easily get missed, since I probably have hte dependency installed, but if the utility fails to catch the dep and put it in the pkgbuild, I'm ignorant to it, I only become aware of problems when either a) my build breaks or b) y'all tell me :D In other news, I'm working on a Jenkins build environment that will email me failures and can help me to notice problems a bit better, but even still, it won't be perfect. Just ping me if any of my PKGBUILDs are broken/out of date. I almost always get to them the same day I see the email.

mbunkus commented on 2016-04-08 07:07

Absolutely. If the package is orphaned I'll adopt it.

hexadecagram commented on 2016-04-08 04:44

The latest update to perl-devel-repl seems to address whatever issue I was having building it, which I'm struggling to remember, but I think the following is pretty accurate.

You are correct that perl-devel-repl should not add a dependency on perl-module-pluggable.

IIRC, I commented because I was able to get perl-devel-repl to build and install WITHOUT perl-moosex-object-pluggable if I manually installed perl-module-pluggable.

perl-module-pluggable is still missing from perl-moosex-object-pluggable's dependency list. I seem to remember commenting about that but obviously it's not there. I'll ping jnbek, but it seems his participation in AUR package maintainership ceased 2015-6-16. Would you be willing to take over that package if necessary?

mbunkus commented on 2016-02-10 11:46

I disagree. The META.json[1] directly includes MooseX::Object::Pluggable as a runtime dependency. That MooseX::Object::Pluggable depends on Object::Pluggable is not my problem; it should be declared as a dependency in perl-moosex-object-pluggable instead. That's what I've pointed out in 2014 already[2] as a comment for that particular package.

Why do you think those dependencies should be changed?


hexadecagram commented on 2016-02-10 10:49

Dependency on perl-moose-x-object-pluggable>=0.0009 needs to be replaced with perl-module-pluggable.