Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Specio CPAN distribution.

Report information
The Basics
Id: 117975
Status: resolved
Priority: 0/
Queue: Specio
People
Owner: Nobody in particular
Requestors: mg.pub [...] gmx.net
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: 0.25
Fixed in: 0.26

History Show all quoted text
  Tue Sep 20 06:19:40 2016 mg.pub [...] gmx.net - Ticket created
Subject: Installation fails on OSX El Capitan
Trying to install Specio 0.25 via cpanm: t/00-report-prereqs.t ... ok Can't resolve method "???" overloading "&{}" in package "Specio::Constraint::Simple" at Specio::Constraint::Simple->new line 35. Compilation failed in require at t/anon.t line 7. BEGIN failed--compilation aborted at t/anon.t line 7. perl -v This is perl 5, version 18, subversion 2 (v5.18.2) built for darwin-thread-multi-2level (with 2 registered patches, see perl -V for more detail) This is the native Perl of OS X El Capitan. Unfortunately this blocks the installation of important modules like DateTime::Locale (and thus DateTime) as well.
  Tue Sep 20 10:45:51 2016 DROLSKY [...] cpan.org - Correspondence added
On 2016-09-20 05:19:40, mgruner wrote: Show quoted text
> Trying to install Specio 0.25 via cpanm: > > t/00-report-prereqs.t ... ok > Can't resolve method "???" overloading "&{}" in package > "Specio::Constraint::Simple" at Specio::Constraint::Simple->new > line 35. > Compilation failed in require at t/anon.t line 7. > BEGIN failed--compilation aborted at t/anon.t line 7. > > perl -v > > This is perl 5, version 18, subversion 2 (v5.18.2) built for darwin- > thread-multi-2level > (with 2 registered patches, see perl -V for more detail) > > This is the native Perl of OS X El Capitan. Unfortunately this blocks > the installation of important modules like DateTime::Locale (and thus > DateTime) as well.
This sounds like some sort of core Perl bug, except that this module works fine with Perl 5.18 in my testing. Does the OSX native Perl have any special patches (look at "perl -V" for details)?
  Tue Sep 20 10:45:51 2016 The RT System itself - Status changed from 'new' to 'open'
  Tue Sep 20 10:54:50 2016 mg.pub [...] gmx.net - Correspondence added
From: mg.pub [...] gmx.net
Thanks for the fast response! Here is the info from my system. I'm not actively using Perlbrew, although it is installed. perl -V Summary of my perl5 (revision 5 version 18 subversion 2) configuration: Platform: osname=darwin, osvers=15.0, archname=darwin-thread-multi-2level uname='darwin osx219.apple.com 15.0 darwin kernel version 15.0.0: fri may 22 22:03:51 pdt 2015; root:xnu-3216.0.0.1.11~1development_x86_64 x86_64 ' config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags= -Dman3ext=3pm -Duseithreads -Duseshrplib -Dinc_version_list=none -Dcc=cc' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-arch i386 -arch x86_64 -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector', optimize='-Os', cppflags='-g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector' ccversion='', gccversion='4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.1)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc -mmacosx-version-min=10.11.3', ldflags ='-arch i386 -arch x86_64 -fstack-protector' libpth=/usr/lib /usr/local/lib libs= perllibs= libc=, so=dylib, useshrplib=true, libperl=libperl.dylib gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-arch i386 -arch x86_64 -bundle -undefined dynamic_lookup -fstack-protector' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_SAWAMPERSAND USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API Locally applied patches: /Library/Perl/Updates/<version> comes before system perl directories installprivlib and installarchlib points to the Updates directory Built under darwin Compiled at Aug 11 2015 04:22:26 %ENV: PERLBREW_BASHRC_VERSION="0.76" PERLBREW_HOME="/Users/martin/.perlbrew" PERLBREW_PATH="/Users/martin/perl5/perlbrew/bin" PERLBREW_ROOT="/Users/martin/perl5/perlbrew" PERLBREW_VERSION="0.73" @INC: /Library/Perl/5.18/darwin-thread-multi-2level /Library/Perl/5.18 /Network/Library/Perl/5.18/darwin-thread-multi-2level /Network/Library/Perl/5.18 /Library/Perl/Updates/5.18.2/darwin-thread-multi-2level /Library/Perl/Updates/5.18.2 /System/Library/Perl/5.18/darwin-thread-multi-2level /System/Library/Perl/5.18 /System/Library/Perl/Extras/5.18/darwin-thread-multi-2level /System/Library/Perl/Extras/5.18 .
  Tue Sep 20 10:57:46 2016 mg.pub [...] gmx.net - Correspondence added
From: mg.pub [...] gmx.net
I actually noticed this because our Travis CI scenarios started failing a few days ago, for different versions of Perl (5.14 to 5.22). We install "DateTime" via cpanm with --notest, which works fine, but then causes errors: https://travis-ci.org/OTRS/otrs/jobs/161325250 Message: Kernel::System::DateTime could not be loaded: Attempt to reload DateTime.pm aborted. Compilation failed in require at /home/travis/build/OTRS/otrs/Kernel/System/DateTime.pm line 26. So I'm not sure if this is actually OSX related. Downgrading to versions that don't rely on Specio makes the errors go away again.
  Tue Sep 20 11:25:43 2016 DROLSKY [...] cpan.org - Correspondence added
On 2016-09-20 09:57:46, mgruner wrote: Show quoted text
> I actually noticed this because our Travis CI scenarios started > failing a few days ago, for different versions of Perl (5.14 to 5.22). > We install "DateTime" via cpanm with --notest, which works fine, but > then causes errors: > > https://travis-ci.org/OTRS/otrs/jobs/161325250 > > Message: Kernel::System::DateTime could not be loaded: Attempt to > reload DateTime.pm aborted. > Compilation failed in require at > /home/travis/build/OTRS/otrs/Kernel/System/DateTime.pm line 26. > > So I'm not sure if this is actually OSX related. Downgrading to > versions that don't rely on Specio makes the errors go away again.
That looks like a different issue entirely. Why is your code attempting to reload DateTime? That's an error message from the perl core that I've only seen when something weird happens, and I don't think it's related to the OSX issue. That error happens with code like this: eval { require Foo }; require Foo; If Foo.pm contains some sort of syntax error and the first attempt to load it doesn't cause the program to die, attempting to load it later gives you that error. So why are you trying to load DateTime once, failing to load it, and then trying again? I really don't know. Regardless, this sounds like it could be a bug in OTRS itself.
  Tue Sep 20 12:44:10 2016 mg.pub [...] gmx.net - Correspondence added
Subject: Re: [rt.cpan.org #117975] Installation fails on OSX El Capitan
Date: Tue, 20 Sep 2016 18:43:54 +0200
To: bug-Specio [...] rt.cpan.org
From: Martin Gruner <mg.pub [...] gmx.net>
Hello Dave, this might really be unrelated, but it is another issue that started showing up just recently. What we do in our unit tests at some places is to first delete DateTime.pm from %INC (as it had been loaded before in the tested code) and then requiring it again to make sure it catches a globally overriden CORE::GLOBAL::time and similar functions to simulate a fixed time in our tests - we found this reload neccessary so far. It worked fine until just recently, with the latest version of DateTime this no longer works. Would you have a clue about this? Best regards, Martin Show quoted text
> Am 20.09.2016 um 17:25 schrieb Dave Rolsky via RT <bug-Specio@rt.cpan.org>: > > <URL: https://rt.cpan.org/Ticket/Display.html?id=117975 > > > On 2016-09-20 09:57:46, mgruner wrote:
>> I actually noticed this because our Travis CI scenarios started >> failing a few days ago, for different versions of Perl (5.14 to 5.22). >> We install "DateTime" via cpanm with --notest, which works fine, but >> then causes errors: >> >> https://travis-ci.org/OTRS/otrs/jobs/161325250 >> >> Message: Kernel::System::DateTime could not be loaded: Attempt to >> reload DateTime.pm aborted. >> Compilation failed in require at >> /home/travis/build/OTRS/otrs/Kernel/System/DateTime.pm line 26. >> >> So I'm not sure if this is actually OSX related. Downgrading to >> versions that don't rely on Specio makes the errors go away again.
> > That looks like a different issue entirely. Why is your code attempting to reload DateTime? That's an error message from the perl core that I've only seen when something weird happens, and I don't think it's related to the OSX issue. > > That error happens with code like this: > > eval { require Foo }; > require Foo; > > If Foo.pm contains some sort of syntax error and the first attempt to load it doesn't cause the program to die, attempting to load it later gives you that error. > > So why are you trying to load DateTime once, failing to load it, and then trying again? I really don't know. Regardless, this sounds like it could be a bug in OTRS itself.
  Tue Sep 20 12:46:11 2016 DROLSKY [...] cpan.org - Correspondence added
On 2016-09-20 11:44:10, mgruner wrote: Show quoted text
> Hello Dave, > > this might really be unrelated, but it is another issue that started > showing up just recently. What we do in our unit tests at some places > is to first delete DateTime.pm from %INC (as it had been loaded before > in the tested code) and then requiring it again to make sure it > catches a globally overriden CORE::GLOBAL::time and similar functions > to simulate a fixed time in our tests - we found this reload > neccessary so far. It worked fine until just recently, with the latest > version of DateTime this no longer works. Would you have a clue about > this?
This is definitely not related, and it's really not supported very well by Perl itself. It sort of works, but generally speaking reloading an existing module is asking for trouble.
  Wed Sep 21 04:25:53 2016 mg.pub [...] gmx.net - Correspondence added
From: mg.pub [...] gmx.net
Hello Dave, thanks for your advice. I believe I was able to sort the reload problem by not reloading any more and instead overriding DateTime::_core_time instead, seems to work fine. Thanks! Best regards, Martin Am Di 20. Sep 2016, 12:46:11, DROLSKY schrieb: Show quoted text
> On 2016-09-20 11:44:10, mgruner wrote:
> > Hello Dave, > > > > this might really be unrelated, but it is another issue that started > > showing up just recently. What we do in our unit tests at some places > > is to first delete DateTime.pm from %INC (as it had been loaded > > before > > in the tested code) and then requiring it again to make sure it > > catches a globally overriden CORE::GLOBAL::time and similar functions > > to simulate a fixed time in our tests - we found this reload > > neccessary so far. It worked fine until just recently, with the > > latest > > version of DateTime this no longer works. Would you have a clue about > > this?
> > This is definitely not related, and it's really not supported very > well by Perl itself. It sort of works, but generally speaking > reloading an existing module is asking for trouble.
  Sun Sep 25 01:36:45 2016 DROLSKY [...] cpan.org - Correspondence added
I realized that this was because I needed to depend on Role::Tiny 1.003003. This should be fixed in the latest release.
  Sun Sep 25 01:36:50 2016 DROLSKY [...] cpan.org - Status changed from 'open' to 'resolved'
  Sun Sep 25 01:37:00 2016 DROLSKY [...] cpan.org - Fixed in 0.26 added
  Mon Sep 26 03:19:53 2016 mg.pub [...] gmx.net - Correspondence added
Subject: Re: [rt.cpan.org #117975] Installation fails on OSX El Capitan
Date: Mon, 26 Sep 2016 09:19:41 +0200
To: bug-Specio [...] rt.cpan.org
From: Martin Gruner <mg.pub [...] gmx.net>
I can confirm that this issue is now fixed. Thank you very much! Show quoted text
> Am 25.09.2016 um 07:36 schrieb Dave Rolsky via RT <bug-Specio@rt.cpan.org>: > > <URL: https://rt.cpan.org/Ticket/Display.html?id=117975 > > > I realized that this was because I needed to depend on Role::Tiny 1.003003. This should be fixed in the latest release.