search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.99k stars 559 forks source link

perlbug included #15955

Closed p5pRT closed 7 years ago

p5pRT commented 7 years ago

Migrated from rt.perl.org#131169 (status was 'rejected')

Searchable as RT131169$

p5pRT commented 7 years ago

From law@tlinx.org

Created by perl-diddler@tlinx.org

In testing for Spiffy.pm\, "base.pm" fails with​:

X.pm did not return a true value at /usr/lib/perl5/5.22/base.pm line 99.   ...propagated at /usr/lib/perl5/5.22/base.pm line 108. BEGIN failed--compilation aborted at t/mixin.t line 14.

This causes Spiffy to fail.   causing Test​::Base to fail.   causing Test​::YAML to fail.   causing YAML to fail.   causing the new CPAN to fail...

Most of that wasn't initially reported\, because Test​::Reporter couldn't use Test​::Reporter​::Transport​::Metabase.
That failed for multiple reasons\, but finally led down to a module

Data​::UUID -- which is broken due to the author having no testing on cygwin (which the thought was some type of windows platform\, not realizing it was a POSIX (linux) platform.

I modifyed UUID.{c\,h} to allow it to build by doing a substitute on all lines​:   %s/__cygwin__/__pygwin__/

Which disabled the code that classified cygwin w/other windows platforms and treated it like a generic linux/unix platform.

That allowed Data​::GUID to build... and ultimately the reporting machinery to start working.

That led to some other bug in base.pm showing up in 5.22.

Basically\, because Data​::UUID was broken (it looked for a header\, 'windows.h'\, which doesn't exist on unix platforms)\, no reports have come from cygwin\, it seems\, for some time\, so other bugs in Perl's base\, it seems\, weren't tested.

MANY of the modules that wouldn't build didn't build due to problems in those modules not handling error conditions 'gracefully' (if at all).

As has been mentioned on the cpan tester's list (Kent Fredric\, 2017-03-26)\, many modules are not being tested for other reasons\, but here\, whether modules are tested or not\, cygwin-testing has been completely blocked due to the error in Data​::UUID.

After I found that\, I prioritized getting the reporting to work\, since I could either get my last-perl-install's modules installed\, or write a bunch more bugs\, which I don't really enjoy\, as they are often ignored\, rejected or they are fixed too late to be of any use to me. AFAIK\, no one else has reported this problem of broken reporting on cygwin (?).

Of note no reports could come out of the cygwin platform due since Data​::UUID was added to the requirment chain for reports on cygwin.

In addition to the utils that couldn't build due to Data​::UUID\, the lack of testing seems to have allowed the bug in base.pm in 5.22 to slip by.

Perl Info ``` Flags: category=core severity=critical This perlbug was built using Perl 5.24.1 - Sat Apr 8 14:50:39 CEST 2017 It is being executed now by Perl 5.22.3 - Sun Jan 15 13:05:43 CET 2017. Site configuration information for perl 5.22.3: Configured by ASSI at Sun Jan 15 13:05:43 CET 2017. Summary of my perl5 (revision 5 version 22 subversion 3) configuration: Platform: osname=cygwin, osvers=2.6.1(0.30553), archname=cygwin-thread-multi uname='cygwin_nt-6.3 cygwin 2.6.1(0.30553) 2016-12-16 11:55 x86_64 cygwin ' config_args='-des -Dprefix=/usr -Dmksymlinks -Darchname=x86_64-cygwin-threads -Dlibperl=cygperl5_22.dll -Dcc=gcc -Dld=g++ -Accflags=-ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/mnt/share/maint/perl.x86_64/build=/usr/src/debug/perl-5.22.3-1 -fdebug-prefix-map=/mnt/share/maint/perl.x86_64/src/perl-5.22.3=/usr/src/debug/perl-5.22.3-1 -fwrapv' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -D_GNU_SOURCE -U__STRICT_ANSI__ -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/mnt/share/maint/perl.x86_64/build=/usr/src/debug/perl-5.22.3-1 -fdebug-prefix-map=/mnt/share/maint/perl.x86_64/src/perl-5.22.3=/usr/src/debug/perl-5.22.3-1 -fwrapv -fno-strict-aliasing -fstack-protector-strong -D_FORTIFY_SOURCE=2', optimize='-O3', cppflags='-DPERL_USE_SAFE_PUTENV -D_GNU_SOURCE -U__STRICT_ANSI__ -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/mnt/share/maint/perl.x86_64/build=/usr/src/debug/perl-5.22.3-1 -fdebug-prefix-map=/mnt/share/maint/perl.x86_64/src/perl-5.22.3=/usr/src/debug/perl-5.22.3-1 -fwrapv -fno-strict-aliasing -fstack-protector-strong' ccversion='', gccversion='5.4.0', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='g++', ldflags =' -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector-strong' libpth=/usr/lib libs=-lpthread -lgdbm -ldb -ldl -lcrypt -lgdbm_compat perllibs=-lpthread -ldl -lcrypt libc=/usr/lib/libcygwin.a, so=dll, useshrplib=true, libperl=cygperl5_22.dll gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' --shared -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector-strong' @INC for perl 5.22.3: /Users/law.Bliss/bin/lib /usr/lib/perl5/site_perl/5.22/x86_64-cygwin-threads /usr/lib/perl5/site_perl/5.22 /usr/lib/perl5/vendor_perl/5.22/x86_64-cygwin-threads /usr/lib/perl5/vendor_perl/5.22 /usr/lib/perl5/5.22/x86_64-cygwin-threads /usr/lib/perl5/5.22 Environment for perl 5.22.3: CYGWIN=system nodosfilewarning winsymlinks:native export HOME=/Users/law.Bliss LANG (unset) LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_US.UTF-8 LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=.:.:/sbin:/Windows:/Windows/system32:/Windows/System32/Wbem:/prog64/vim/current:/Prog64/VanDyke:/Prog/Sysinternals/cmd:/Prog/Sysinternals:/Prog/Common:/Windows/System32/WindowsPowerShell/v1.0:/Prog/QuickTime:/Prog/QuickTime/QTSystem:/ProgramData/Oracle/Java/javapath:/Prog/NVIDIA:/Prog64/Razer:/Prog/Razer:/usr/sbin:/Users/law.Bliss/bin:/bin:/usr/local/bin:/etc/local/func_lib:/Users/law.Bliss/bin/lib PERL5OPT=-Mutf8 -CSA -I/Users/law.Bliss/bin/lib PERL_BADLANG (unset) SHELL=C:/Bin/Bash.exe ```
p5pRT commented 7 years ago

From @jkeenan

On Tue\, 18 Apr 2017 02​:27​:28 GMT\, law@​tlinx.org wrote​:

Reply-To​: perl-diddler@​tlinx.org Subject​: base.pm broken (no one is testing on cygwin\, BTW...) From​: perl-diddler@​tlinx.org Message-Id​: \5\.22\.3\_3640\_1492475179@​ATHENAE\.hs\.tlinx\.org To​: perlbug@​perl.org Cc​: ASSI@​cygwin.nonet

This is a bug report for perl from perl-diddler@​tlinx.org\, generated with the help of perlbug 1.40 running under perl 5.22.3.

----------------------------------------------------------------- [Please describe your issue here]

In testing for Spiffy.pm\, "base.pm" fails with​:

X.pm did not return a true value at /usr/lib/perl5/5.22/base.pm line 99. ...propagated at /usr/lib/perl5/5.22/base.pm line 108. BEGIN failed--compilation aborted at t/mixin.t line 14.

This causes Spiffy to fail. causing Test​::Base to fail. causing Test​::YAML to fail. causing YAML to fail. causing the new CPAN to fail...

Most of that wasn't initially reported\, because Test​::Reporter couldn't use Test​::Reporter​::Transport​::Metabase. That failed for multiple reasons\, but finally led down to a module

Data​::UUID -- which is broken due to the author having no testing on cygwin (which the thought was some type of windows platform\, not realizing it was a POSIX (linux) platform.

I modifyed UUID.{c\,h} to allow it to build by doing a substitute on all lines​: %s/__cygwin__/__pygwin__/

Which disabled the code that classified cygwin w/other windows platforms and treated it like a generic linux/unix platform.

That allowed Data​::GUID to build... and ultimately the reporting machinery to start working.

That led to some other bug in base.pm showing up in 5.22.

Basically\, because Data​::UUID was broken (it looked for a header\, 'windows.h'\, which doesn't exist on unix platforms)\, no reports have come from cygwin\, it seems\, for some time\, so other bugs in Perl's base\, it seems\, weren't tested.

MANY of the modules that wouldn't build didn't build due to problems in those modules not handling error conditions 'gracefully' (if at all).

As has been mentioned on the cpan tester's list (Kent Fredric\, 2017- 03-26)\, many modules are not being tested for other reasons\, but here\, whether modules are tested or not\, cygwin-testing has been completely blocked due to the error in Data​::UUID.

After I found that\, I prioritized getting the reporting to work\, since I could either get my last-perl-install's modules installed\, or write a bunch more bugs\, which I don't really enjoy\, as they are often ignored\, rejected or they are fixed too late to be of any use to me. AFAIK\, no one else has reported this problem of broken reporting on cygwin (?).

Of note no reports could come out of the cygwin platform due since Data​::UUID was added to the requirment chain for reports on cygwin.

In addition to the utils that couldn't build due to Data​::UUID\, the lack of testing seems to have allowed the bug in base.pm in 5.22 to slip by.

Can you provide us with a code sample which focuses strictly on the bug you believe is present in base.pm in perl-5.22?

None of the other core libraries you cite are part of the Perl 5 core distribution\, so they're out of our jurisdiction.

Thank you very much. Jim Keenan

[Please do not change anything below this line] ----------------------------------------------------------------- --- Flags​: category=core severity=critical --- This perlbug was built using Perl 5.24.1 - Sat Apr 8 14​:50​:39 CEST 2017 It is being executed now by Perl 5.22.3 - Sun Jan 15 13​:05​:43 CET 2017.

Site configuration information for perl 5.22.3​:

Configured by ASSI at Sun Jan 15 13​:05​:43 CET 2017.

Summary of my perl5 (revision 5 version 22 subversion 3) configuration​:

Platform​: osname=cygwin\, osvers=2.6.1(0.30553)\, archname=cygwin-thread-multi uname='cygwin_nt-6.3 cygwin 2.6.1(0.30553) 2016-12-16 11​:55 x86_64 cygwin ' config_args='-des -Dprefix=/usr -Dmksymlinks -Darchname=x86_64- cygwin-threads -Dlibperl=cygperl5_22.dll -Dcc=gcc -Dld=g++ -Accflags=- ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix- map=/mnt/share/maint/perl.x86_64/build=/usr/src/debug/perl-5.22.3-1 -fdebug-prefix-map=/mnt/share/maint/perl.x86_64/src/perl- 5.22.3=/usr/src/debug/perl-5.22.3-1 -fwrapv' hint=recommended\, useposix=true\, d_sigaction=define useithreads=define\, usemultiplicity=define use64bitint=define\, use64bitall=define\, uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler​: cc='gcc'\, ccflags ='-DPERL_USE_SAFE_PUTENV -D_GNU_SOURCE -U__STRICT_ANSI__ -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix- map=/mnt/share/maint/perl.x86_64/build=/usr/src/debug/perl-5.22.3-1 -fdebug-prefix-map=/mnt/share/maint/perl.x86_64/src/perl- 5.22.3=/usr/src/debug/perl-5.22.3-1 -fwrapv -fno-strict-aliasing -fstack-protector-strong -D_FORTIFY_SOURCE=2'\, optimize='-O3'\, cppflags='-DPERL_USE_SAFE_PUTENV -D_GNU_SOURCE -U__STRICT_ANSI__ -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix- map=/mnt/share/maint/perl.x86_64/build=/usr/src/debug/perl-5.22.3-1 -fdebug-prefix-map=/mnt/share/maint/perl.x86_64/src/perl- 5.22.3=/usr/src/debug/perl-5.22.3-1 -fwrapv -fno-strict-aliasing -fstack-protector-strong' ccversion=''\, gccversion='5.4.0'\, gccosandvers='' intsize=4\, longsize=8\, ptrsize=8\, doublesize=8\, byteorder=12345678\, doublekind=3 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=16\, longdblkind=3 ivtype='long'\, ivsize=8\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=8 alignbytes=8\, prototype=define Linker and Libraries​: ld='g++'\, ldflags =' -Wl\,--enable-auto-import -Wl\,--export-all- symbols -Wl\,--enable-auto-image-base -fstack-protector-strong' libpth=/usr/lib libs=-lpthread -lgdbm -ldb -ldl -lcrypt -lgdbm_compat perllibs=-lpthread -ldl -lcrypt libc=/usr/lib/libcygwin.a\, so=dll\, useshrplib=true\, libperl=cygperl5_22.dll gnulibc_version='' Dynamic Linking​: dlsrc=dl_dlopen.xs\, dlext=dll\, d_dlsymun=undef\, ccdlflags=' ' cccdlflags=' '\, lddlflags=' --shared -Wl\,--enable-auto-import -Wl\,--export-all-symbols -Wl\,--enable-auto-image-base -fstack- protector-strong'

--- @​INC for perl 5.22.3​: /Users/law.Bliss/bin/lib /usr/lib/perl5/site_perl/5.22/x86_64-cygwin-threads /usr/lib/perl5/site_perl/5.22 /usr/lib/perl5/vendor_perl/5.22/x86_64-cygwin-threads /usr/lib/perl5/vendor_perl/5.22 /usr/lib/perl5/5.22/x86_64-cygwin-threads /usr/lib/perl5/5.22

--- Environment for perl 5.22.3​: CYGWIN=system nodosfilewarning winsymlinks​:native export HOME=/Users/law.Bliss LANG (unset) LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_US.UTF-8 LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=.​:.​:/sbin​:/Windows​:/Windows/system32​:/Windows/System32/Wbem​:/prog64/vim/current​:/Prog64/VanDyke​:/Prog/Sysinternals/cmd​:/Prog/Sysinternals​:/Prog/Common​:/Windows/System32/WindowsPowerShell/v1.0​:/Prog/QuickTime​:/Prog/QuickTime/QTSystem​:/ProgramData/Oracle/Java/javapath​:/Prog/NVIDIA​:/Prog64/Razer​:/Prog/Razer​:/usr/sbin​:/Users/law.Bliss/bin​:/bin​:/usr/local/bin​:/etc/local/func_lib​:/Users/law.Bliss/bin/lib PERL5OPT=-Mutf8 -CSA -I/Users/law.Bliss/bin/lib PERL_BADLANG (unset) SHELL=C​:/Bin/Bash.exe

-- James E Keenan (jkeenan@​cpan.org)

p5pRT commented 7 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 7 years ago

From perl-diddler@tlinx.org

James E Keenan via RT wrote​:

On Tue\, 18 Apr 2017 02​:27​:28 GMT\, law@​tlinx.org wrote​:

Reply-To​: perl-diddler@​tlinx.org Subject​: base.pm broken (no one is testing on cygwin\, BTW...) From​: perl-diddler@​tlinx.org Message-Id​: \5\.22\.3\_3640\_1492475179@​ATHENAE\.hs\.tlinx\.org To​: perlbug@​perl.org Cc​: ASSI@​cygwin.nonet

This is a bug report for perl from perl-diddler@​tlinx.org\, generated with the help of perlbug 1.40 running under perl 5.22.3.

----------------------------------------------------------------- [Please describe your issue here]

In testing for Spiffy.pm\, "base.pm" fails with​:

X.pm did not return a true value at /usr/lib/perl5/5.22/base.pm line 99. ...propagated at /usr/lib/perl5/5.22/base.pm line 108. BEGIN failed--compilation aborted at t/mixin.t line 14.

Can you provide us with a code sample which focuses strictly on the bug you believe is present in base.pm in perl-5.22?

  I don't know. Isn't cpan part of core? It told me to re-install it\, (which I did by trying to install Bundle​::CPAN).

  I suppose the other question is whether or not cygwin is a supported platform. Considering that test-reporting on cygwin is disabled due to the bug in Data​::UUID\, how is perl's functionality in using the cpan-core functionality\, evaluated if the reporting is broken?

None of the other core libraries you cite are part of the Perl 5 core distribution\, so they're out of our jurisdiction.

  Perhaps that line would be more clear if cpan wasn't part of the core distribution. As it was\, when I tried installing modules using it\, I got a diagnostic w/each module that test-reporting was non-functional because it wasn't installed. That prompted me to fix that problem. What type of functionality do you expect from cpan when it tells you to update various modules?

Thank you very much. Jim Keenan

You're welcome.

p5pRT commented 7 years ago

From @jkeenan

On 04/18/2017 03​:43 PM\, Linda W wrote​:

James E Keenan via RT wrote​:

On Tue\, 18 Apr 2017 02​:27​:28 GMT\, law@​tlinx.org wrote​:

Reply-To​: perl-diddler@​tlinx.org Subject​: base.pm broken (no one is testing on cygwin\, BTW...) From​: perl-diddler@​tlinx.org Message-Id​: \5\.22\.3\_3640\_1492475179@​ATHENAE\.hs\.tlinx\.org To​: perlbug@​perl.org Cc​: ASSI@​cygwin.nonet

This is a bug report for perl from perl-diddler@​tlinx.org\, generated with the help of perlbug 1.40 running under perl 5.22.3.

----------------------------------------------------------------- [Please describe your issue here]

In testing for Spiffy.pm\, "base.pm" fails with​:

X.pm did not return a true value at /usr/lib/perl5/5.22/base.pm line 99. ...propagated at /usr/lib/perl5/5.22/base.pm line 108. BEGIN failed--compilation aborted at t/mixin.t line 14.

Can you provide us with a code sample which focuses strictly on the bug you believe is present in base.pm in perl-5.22?

I don't know. Isn't cpan part of core? It told me to re-install it\, (which I did by trying to install Bundle​::CPAN).

I suppose the other question is whether or not cygwin is a supported platform. Considering that test-reporting on cygwin is disabled due to the bug in Data​::UUID\, how is perl's functionality in using the cpan-core functionality\, evaluated if the reporting is broken?

In that case the way to begin would be to report the problem at​:

https://github.com/rjbs/Data-UUID/issues

None of the other core libraries you cite are part of the Perl 5 core distribution\, so they're out of our jurisdiction.

---- Perhaps that line would be more clear if cpan wasn't part of the core distribution. As it was\, when I tried installing modules using it\, I got a diagnostic w/each module that test-reporting was non-functional because it wasn't installed. That prompted me to fix that problem. What type of functionality do you expect from cpan when it tells you to update various modules?

Thank you very much. Jim Keenan

You're welcome.

p5pRT commented 7 years ago

From @iabyn

On Tue\, Apr 18\, 2017 at 12​:43​:46PM -0700\, Linda W wrote​:

James E Keenan via RT wrote​:

On Tue\, 18 Apr 2017 02​:27​:28 GMT\, law@​tlinx.org wrote​:

Reply-To​: perl-diddler@​tlinx.org Subject​: base.pm broken (no one is testing on cygwin\, BTW...) From​: perl-diddler@​tlinx.org Message-Id​: \5\.22\.3\_3640\_1492475179@​ATHENAE\.hs\.tlinx\.org To​: perlbug@​perl.org Cc​: ASSI@​cygwin.nonet

This is a bug report for perl from perl-diddler@​tlinx.org\, generated with the help of perlbug 1.40 running under perl 5.22.3.

----------------------------------------------------------------- [Please describe your issue here]

In testing for Spiffy.pm\, "base.pm" fails with​:

X.pm did not return a true value at /usr/lib/perl5/5.22/base.pm line 99. ...propagated at /usr/lib/perl5/5.22/base.pm line 108. BEGIN failed--compilation aborted at t/mixin.t line 14.

Can you provide us with a code sample which focuses strictly on the bug you believe is present in base.pm in perl-5.22? I don't know. Isn't cpan part of core? It told me to re-install it\, (which I did by trying to install Bundle​::CPAN).

If I understand you correctly\, you are discussing two related issues. The first is that\, because Data​::UUID is broken under Cygwin\, this causes a cascade of failures when the cpan utility tries to install a newer version of CPAN.pm when you invoke 'install Bundle​::CPAN'. (That should trigger installing newer versions of various distributions that were included with the original perl installation.

However\, it shouldn't trigger the installation of Data​::UUID (at least it doesn't on my linux platform)\, so I can't really comment any further on that issue.

The second issue is that you say there is a bug in base.pm\, but it's very hard for me to understand from your description what exactly the bug is\, which will make diagnosing the issue impossible. This is why James asked for a code sample which demonstrates the bug. If it's not possible for you to provide this\, could you instead provide a detailed description of what behaviour base.pm is doing incorrectly\, and what the correct behaviour should be\, thanks.

-- Music lesson​: a symbiotic relationship whereby a pupil's embellishments concerning the amount of practice performed since the last lesson are rewarded with embellishments from the teacher concerning the pupil's progress over the corresponding period.

p5pRT commented 7 years ago

From Stromeko@nexgo.de

"James E Keenan via RT" writes​:

--- This perlbug was built using Perl 5.24.1 - Sat Apr 8 14​:50​:39 CEST 2017 It is being executed now by Perl 5.22.3 - Sun Jan 15 13​:05​:43 CET 2017.

It looks like Linda was using the 5.24 test version previously\, then partially switched back to the current 5.22 version on Cygwin. This may affect her results. Spiffy builds and tests just fine on both versions of Perl on Cygwin\, as does Data​::UUID. I have no indication of a problem in base.pm on either version.

Regards\, Achim. -- +\<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+\, Q and microQ​: http​://Synth.Stromeko.net/Downloads.html#WaldorfSounds

p5pRT commented 7 years ago

From perl-diddler@tlinx.org

Achim Gratz via RT wrote​:

"James E Keenan via RT" writes​:

--- This perlbug was built using Perl 5.24.1 - Sat Apr 8 14​:50​:39 CEST 2017 It is being executed now by Perl 5.22.3 - Sun Jan 15 13​:05​:43 CET 2017.

It looks like Linda was using the 5.24 test version previously\, then partially switched back to the current 5.22 version on Cygwin. This may affect her results. Spiffy builds and tests just fine on both versions of Perl on Cygwin\, as does Data​::UUID. I have no indication of a problem in base.pm on either version.

  I had to run perlbug on my linux workstation\, which had the later perl version on it (the cygwin email executable wasn't functioning).

  I looked at the base.pm in perl 5.22.3 when I ran the test and didn't see why it was behaving the way it did.

  FWIW -- was trying to see what happened to the bug report for UUID (GUID?) that was submitted for cygwin by my machine. Unfortunately\, the test machine was backed up (at least that theory was put forward when I asked where the report might be) and I haven't had a chance to get back to it yet.

  What makes the UUID bug rather pernacious\, is that it can pass -- but I don't know what it is using for UUIDs. The problem with the UUID module is that it calls GUID on a windows platform\, but cygwin is a POSIX/*nix (~linux) platform.

To make GUID work a few includes that are expected on windows platforms (maybe mingw(32/64) platforms as well) don't necessarily exist running under cygwin. Files with the same name MAY exist\, so the test may pass for some -- but what results are produced\, considering the real windows includes & libs aren't there isn't known to me).

It *MAY* becausing some random effects that generate an indeterminant state that cause base to fail. That would not be my first explanation\, but it is certainly possible.

Meanwhile\, I'm just sorta guessing\, but the bug report submitted from my system over the module _should_ be listed on the test page (last I looked was 4/19) when I tried running the install for the module again\, but was told it was a duplicate report. Posted to cpan-testers asking where the original might be... that's when I was told it might be in a queue somewhere.

The other problem with duplicating it -- is when I tried to update my cpan\, many of the modules failed due to not being able to make deps... Some installed... As it finished an install pass I'd go in and look at a base-class module to find out why it failed to see if I could manually install it (look @​ cpan build dir\, and run the steps manually).

It was doing that when i found the UUID prob\, which I worked around as I explained in the bug report\, by editing the source.

My primary desire at that point was to get the reporter stuff installed so reports could be submitted about things that really were broken.

Does that give you a better picture of the overall problem? (not necessarily base.pm\, but how the failure of UUID was affecting all the cpan mods that directly or indirectly depended on it -- one being the cpan reporter stuff)?

p5pRT commented 7 years ago

From Stromeko@nexgo.de

Linda W writes​:

I looked at the base.pm in perl 5.22.3 when I ran the test and didn't see why it was behaving the way it did.

I'm pretty sure it's a red herring.

What makes the UUID bug rather pernacious\, is that it can pass -- but I don't know what it is using for UUIDs. The problem with the UUID module is that it calls GUID on a windows platform\, but cygwin is a POSIX/*nix (~linux) platform.

Again\, those two UUID/GUID modules (and the dependency chain up to Spiffy and CPAN-Reporter you mentioned already is in Cygwin proper and as best I can tell work just fine. Other modules depend on them and they are also working.

So as far as I am concerned unless you can show me a reproducible recipe it's most likely a problem on your side. For starters\, cut the Windows stuff from your path and keep the system paths in fornt like they're supposed to be while building stuff in Cygwin and see if that helps. Ideally you just have PATH=/usr/bin set. You will probably want to set LANG to something sensible as well and you don't want to include perl libraries from your home directory\, if you must do this\, consider using local​::lib instead. You will also want to have a recent Module-Corelist before diving into anything that tries to pull in dependencies.

Does that give you a better picture of the overall problem?

Not at all\, as I can't reproduce.

Regards\, Achim. -- +\<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1​: http​://Synth.Stromeko.net/Downloads.html#WaldorfSDada

p5pRT commented 7 years ago

From perl-diddler@tlinx.org

Achim Gratz via RT wrote​:

Linda W writes​:

I looked at the base.pm in perl 5.22.3 when I ran the test and didn't see why it was behaving the way it did.

I'm pretty sure it's a red herring.

What makes the UUID bug rather pernacious\, is that it can pass -- but I don't know what it is using for UUIDs. The problem with the UUID module is that it calls GUID on a windows platform\, but cygwin is a POSIX/*nix (~linux) platform.

Again\, those two UUID/GUID modules (and the dependency chain up to Spiffy and CPAN-Reporter you mentioned already is in Cygwin proper and as best I can tell work just fine. Other modules depend on them and they are also working.

That's what I mean by the bug being pernicious. Those who don't know the cygwin platform\, and who don't look at the code of UUID won't see the problem. To repeat what I wrote above\, cygwin is being lumped in with other Windows platforms\, but it is not a windows platform\, it is a posix (or linux like) platform. The bug report says if you change the places where the #ifdefs check for 'cygwin' to be a check for "somethingelse"\, then it does work -- as reliably as any linux or unix platform.

If you use the code as is\, then UUID will try to call the windows-only GUID module\, and will fail\, "semi-randomly" based on whether or not you have windows header files in you /usr/include tree. If you look at other failures for GUID on cygwin\, you'll see that they failed on not being able to pull in some non-posix header.

So as far as I am concerned unless you can show me a reproducible recipe it's most likely a problem on your side. You mean like this​:

env -i PATH=/bin cpan -i Data​::UUID Loading internal null logger. Install Log​::Log4perl for logging messages CPAN​::SQLite not installed\, trying to work without CPAN​: Storable loaded ok (v2.53_02) Reading '/var/cache/CPAN/Metadata'   Database was generated on Tue\, 25 Apr 2017 22​:17​:02 GMT CPAN​: Module​::CoreList loaded ok (v5.20170114_22) Data​::UUID is up to date (1.221). law.Bliss> env -i PATH=/bin cpan -f -i Data​::UUID Loading internal null logger. Install Log​::Log4perl for logging messages CPAN​::SQLite not installed\, trying to work without CPAN​: Storable loaded ok (v2.53_02) Reading '/var/cache/CPAN/Metadata'   Database was generated on Tue\, 25 Apr 2017 22​:17​:02 GMT CPAN​: Module​::CoreList loaded ok (v5.20170114_22) Running install for module 'Data​::UUID' CPAN​: Digest​::SHA loaded ok (v5.96) CPAN​: Compress​::Zlib loaded ok (v2.074) Checksum for /Share/CPAN/sources/authors/id/R/RJ/RJBS/Data-UUID-1.221.tar.gz ok CPAN​: Archive​::Tar loaded ok (v2.24) 'YAML' not installed\, will not store persistent state CPAN​: CPAN​::Meta​::Requirements loaded ok (v2.132) CPAN​: Parse​::CPAN​::Meta loaded ok (v2.150010) CPAN​: CPAN​::Meta loaded ok (v2.150010) Configuring R/RJ/RJBS/Data-UUID-1.221.tar.gz with Makefile.PL CPAN​: CPAN​::Reporter loaded ok (v1.2018) Checking if your kit is complete... Looks good Configured options (run perl Makefile.PL --help for how to change this)​:   UUID state storage​: /tmp   default umask​: 0007 Generating a Unix-style Makefile Writing Makefile for Data​::UUID Writing MYMETA.yml and MYMETA.json (/usr/bin/perl Makefile.PL exited with 0) CPAN​::Reporter​: Makefile.PL result is 'pass'\, No errors.   RJBS/Data-UUID-1.221.tar.gz   /usr/bin/perl Makefile.PL -- OK Running make for R/RJ/RJBS/Data-UUID-1.221.tar.gz cp UUID.pm blib/lib/Data/UUID.pm Running Mkbootstrap for UUID () chmod 644 "UUID.bs" "/usr/bin/perl.exe" -MExtUtils​::Command​::MM -e 'cp_nonempty' -- UUID.bs blib/arch/auto/Data/UUID/UUID.bs 644 "/usr/bin/perl.exe" "/usr/lib/perl5/5.22/ExtUtils/xsubpp" -typemap '/usr/lib/perl5/5.22/ExtUtils/typemap' -typemap '/var/cache/CPAN/build/Data-UUID-1.221-6/typemap' UUID.xs > UUID.xsc mv UUID.xsc UUID.c gcc -c -DPERL_USE_SAFE_PUTENV -D_GNU_SOURCE -U__STRICT_ANSI__ -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/mnt/share/maint/perl.x86_64/build=/usr/src/debug/perl-5.22.3-1 -fdebug-prefix-map=/mnt/share/maint/perl.x86_64/src/perl-5.22.3=/usr/src/debug/perl-5.22.3-1 -fwrapv -fno-strict-aliasing -fstack-protector-strong -D_FORTIFY_SOURCE=2 -DUSEIMPORTLIB -O3 -DVERSION=\"1.221\" -DXS_VERSION=\"1.221\"
"-I/usr/lib/perl5/5.22/x86_64-cygwin-threads/CORE" -D_STDIR=\"/tmp\" -D__cygwin__ -D_DEFAULT_UMASK=0007 UUID.c In file included from UUID.xs​:4​:0​: UUID.h​:37​:21​: fatal error​: windows.h​: No such file or directory compilation terminated. make​: *** [Makefile​:342​: UUID.o] Error 1 (make.exe exited with 512) CPAN​::Reporter​: make result is 'unknown'\, Stopped with an error. CPAN​::Reporter​: preparing a CPAN Testers report for Data-UUID-1.221

CPAN​::Reporter​: this appears to be a duplicate report for the make phase​: UNKNOWN Data-UUID-1.221 cygwin-thread-multi 2.6.1(0.30553)

Test report will not be sent.

  RJBS/Data-UUID-1.221.tar.gz

Does that give you a better picture of the overall problem?

Not at all\, as I can't reproduce.

It's pretty simple.

FYI\, on cygwin\, /bin is mounted on /usr/bin.

If it passes on your system\, then where is your the file /usr/include/windows.h coming from. It's not a posix file.

Use​: 'cygcheck -f \' You should see something like​:

cygcheck -f /bin/bash bash-4.4.12-3 cygcheck -f /usr/include/windows.h

p5pRT commented 7 years ago

From Stromeko@nexgo.de

Linda W writes​:

That's what I mean by the bug being pernicious. Those who don't know the cygwin platform\, and who don't look at the code of UUID won't see the problem. To repeat what I wrote above\, cygwin is being lumped in with other Windows platforms\, but it is not a windows platform\, it is a posix (or linux like) platform.

I am the current Cygwin Perl maintainer if you are wondering why I responded. I also maintain or co-maintain around 300 Perl distribution packages for Cygwin. So let's assume I know all that\, OK?

The bug report says if you change the places where the #ifdefs check for 'cygwin' to be a check for "somethingelse"\, then it does work -- as reliably as any linux or unix platform.

I have patched many modules to remove impervious assumptions that anything *win must be MS Windows. I agree that it would be cleaner if that particular module was treating Cygwin like Linux and I will probably just patch it for the next release if upstream doesn't do (which happens).

If you use the code as is\, then UUID will try to call the windows-only GUID module\, and will fail\, "semi-randomly" based on whether or not you have windows header files in you /usr/include tree. If you look at other failures for GUID on cygwin\, you'll see that they failed on not being able to pull in some non-posix header.

How is that different from missing any other build dependency? If anything it's a bug in the configury for that module since it doesn't test for the presence of the header before it's attempted to be used.

UUID.h​:37​:21​: fatal error​: windows.h​: No such file or directory compilation terminated.

~ (2001) find /usr/include -name windows.h /usr/include/w32api/windows.h ~ (2002) cygcheck -p /usr/include/w32api/windows.h Found 2 matches for /usr/include/w32api/windows.h cygwin64-w32api-headers-3.2.0-1 - cygwin64-w32api-headers​: Win32 API headers for Cygwin 64bit toolchain (installed binaries and support files) cygwin64-w32api-headers-4.0.4-1 - cygwin64-w32api-headers​: Win32 API headers for Cygwin 64bit toolchain (installed binaries and support files)

FYI\, on cygwin\, /bin is mounted on /usr/bin.

Thanks\, but that knowledge shouldn't lure you into configuring that path into packages inadvertently\, the canonical path is still /usr/bin.

So now after all this discussion about building some unrelated module (even as a build dependency)\, how about getting back to this bug report\, which presumably was about something in core? Is there still anything you think is buggy there and if so how to reproduce that?

Regards\, Achim. -- +\<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9​: http​://Synth.Stromeko.net/Downloads.html#KorgSDada

p5pRT commented 7 years ago

From perl-diddler@tlinx.org

Achim Gratz via RT wrote​:

Linda W writes​:

That's what I mean by the bug being pernicious. Those who don't know the cygwin platform\, and who don't look at the code of UUID won't see the problem. To repeat what I wrote above\, cygwin is being lumped in with other Windows platforms\, but it is not a windows platform\, it is a posix (or linux like) platform.

I am the current Cygwin Perl maintainer if you are wondering why I responded. I also maintain or co-maintain around 300 Perl distribution packages for Cygwin. So let's assume I know all that\, OK?

  Hi. Glad to meet you. I state the bit about cygwin\, because many people might tend to classify it w/windows platforms rather than linux platforms.

The bug report says if you change the places where the #ifdefs check for 'cygwin' to be a check for "somethingelse"\, then it does work -- as reliably as any linux or unix platform.

I have patched many modules to remove impervious assumptions that anything *win must be MS Windows. I agree that it would be cleaner if that particular module was treating Cygwin like Linux and I will probably just patch it for the next release if upstream doesn't do (which happens).

If you use the code as is\, then UUID will try to call the windows-only GUID module\, and will fail\, "semi-randomly" based on whether or not you have windows header files in you /usr/include tree. If you look at other failures for GUID on cygwin\, you'll see that they failed on not being able to pull in some non-posix header.

How is that different from missing any other build dependency?

  If cygwin was designed to be a windows platform\, it wouldn't. Since it is intended to be a unix-type (posix) platform\, it's a misconfiguration for UUID to depend on GUID on a non-windows platform. If you look at other reports for UUID\, they had other missing includes like one having 'crypt' in the name. Perhaps they had one include and not the other. Others\, like you\, 'passed' when you first tested. I don't know how that affects anything that depends on this module when compared with other unix-like platforms. All I saw\, at first\, was this module blocking the installation of reporting. That sorta freaked me out. That it works for some people\, I find "disturbing".

  How did it pass for you?

UUID.h​:37​:21​: fatal error​: windows.h​: No such file or directory compilation terminated.

~ (2001) find /usr/include -name windows.h /usr/include/w32api/windows.h ~ (2002) cygcheck -p /usr/include/w32api/windows.h Found 2 matches for /usr/include/w32api/windows.h cygwin64-w32api-headers-3.2.0-1 - cygwin64-w32api-headers​: Win32 API headers for Cygwin 64bit toolchain (installed binaries and support files) cygwin64-w32api-headers-4.0.4-1 - cygwin64-w32api-headers​: Win32 API headers for Cygwin 64bit toolchain (installed binaries and support files)

  ?? I only asked you for the source if it passed. Where they are shouldn't be a problem unless someone include the w32api dir in their 'include path' for perl mods. Where it's at

FYI\, on cygwin\, /bin is mounted on /usr/bin.

Thanks\, but that knowledge shouldn't lure you into configuring that path into packages inadvertently\, the canonical path is still /usr/bin.

  Not really. /usr/bin is a duplication of /bin. The actual location of the files is in "/bin". The canonical path is usually defined as the actual\, physical location of the path. "/usr/bin" has always been a compatibility mount -- not a canonical one. On a standard install\, users who attempt to invoke cygwin binaries using the usr-bin path will get a not-found\, but they will find them invokable from the \-bin path.

So now after all this discussion about building some unrelated module (even as a build dependency)\, how about getting back to this bug report\, which presumably was about something in core? Is there still anything you think is buggy there and if so how to reproduce that?

  I think I already answered that. Given the various random failures and partial installs as some modules installed and some did not\, I would be hard pressed to spend another afternoon the same way and get the exact same results.

  From someone who has worked in QA -- just because someone can't reproduce a bug-report\, on demand\, doesn't mean it didn't happen. If it isn't reproducible\, then closing it as "not reproducible" would be the best action\, as it saves the data for possible correlation with other bug reports. The only time I spent on this was reproducing the root-cause of other modules not installing.

  I'm sure I'll eventually get around to making sure my perl tool chain is working on windows\, but its not my primary development platform. I just recently got around to updating cygwin for the first time in a few years (which led to the new perl & needing to reinstall/remake cpan modules).

  BTW\, you mentioned installing "an up-to-date" Core? Wouldn't that have happened when I installed the perl-5.22 package on cygwin? FWIW\, you may think that's something "that should be done"\, but that depends on what distro you are running. Some get very testy if you update "their[sic] system files" (on your system). But that's a whole nother topic.

*cheers* -linda

p5pRT commented 7 years ago

From Stromeko@nexgo.de

Linda W writes​:

How is that different from missing any other build dependency? --- If cygwin was designed to be a windows platform\, it wouldn't. Since it is intended to be a unix-type (posix) platform\, it's a misconfiguration for UUID to depend on GUID on a non-windows platform

Cygwin is a POSIX platform designed to interoperate with Windows. For Data​::UUID it simply isn't necessary to use the underlying platform that is Windows (I already said I agree with you that this module would be better off using the UNIX branch of the code)\, but if you satisfy the build dependencies (again\, not correctly checked for) then everything just works.

If you look at other reports for UUID\, they had other missing includes like one having 'crypt' in the name.

Yes\, there are infinitely many ways to fail at the same thing. To build a binary Perl distribution you need to have the build environment set up correctly. It's not the fault of the distribution if you don't do that\, it should tell you what it needs\, though.

Not really. /usr/bin is a duplication of /bin. […]

That's so off-topic here that I'm not going to respond any further.

I think I already answered that. Given the various random failures and partial installs as some modules installed and some did not\, I would be hard pressed to spend another afternoon the same way and get the exact same results.

So\, given that the last three posts from you revolved solely around some shortcoming of the configury of Data​::UUID and no further evidence of something buggy in Perl core has been forthcoming\, I think it's time to close this bugreport\, then.

I'm sure I'll eventually get around to making sure my perl tool chain is working on windows\, but its not my primary development platform. I just recently got around to updating cygwin for the first time in a few years (which led to the new perl & needing to reinstall/remake cpan modules).

It's your prerogative to do this if you want\, but if you insist on building from CPAN instead of using what's packaged for Cygwin you will have to re-do a lot of the things I've already done. You'll have the same problem on any Linux distribution should you decide to shun the packaged distributions and bootstrap your own modules\, so this doesn't have anything to do with Cygwin\, really.

BTW\, you mentioned installing "an up-to-date" Core?

No\, I said you should start with installing local​::lib and then the latest Module-CoreList before diving into CPAN.

FWIW\, you may think that's something "that should be done"\, but that depends on what distro you are running. Some get very testy if you update "their[sic] system files" (on your system).

You might have noticed by now that the "system files" get installed to perl_vendor\, while locally built modules would end up either in site_perl or wherever you told local​::lib to place them. And yes\, you're not supposed to update the "system files" unless you accept that any breakage introduced that way is yours alone. But again getting off-topic here\, so I'll stop.

Regards\, Achim. -- +\<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld​: http​://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

p5pRT commented 7 years ago

From @jkeenan

Closing per recommendation of Cygwin maintainer. -- James E Keenan (jkeenan@​cpan.org)

p5pRT commented 7 years ago

@jkeenan - Status changed from 'open' to 'rejected'

p5pRT commented 7 years ago

From perl-diddler@tlinx.org

Achim Gratz via RT wrote​:

Yes\, there are infinitely many ways to fail at the same thing. To build a binary Perl distribution you need to have the build environment set up correctly. It's not the fault of the distribution if you don't do that\, it should tell you what it needs\, though.

  It's the responsibility of the distribution (UUID) to require pre-reqs. In this case\, UUID\, as it is\, is requiring a windows-native environment. That's incorrect on Cygwin.

Not really. /usr/bin is a duplication of /bin.

[…]

That's so off-topic here that I'm not going to respond any further.

You are the one that brought it up.

I think I already answered that. Given the various random failures and partial installs as some modules installed and some did not\, I would be hard pressed to spend another afternoon the same way and get the exact same results.

So\, given that the last three posts from you revolved solely around some shortcoming of the configury of Data​::UUID and no further evidence of something buggy in Perl core has been forthcoming\, I think it's time to close this bugreport\, then.

Only problem I mentioned in the perl was in the original bug report\, which I said I had no idea of how to reproduce due to the many and varied cpan-mod install failures.

I'm sure I'll eventually get around to making sure my perl tool chain is working on windows\, but its not my primary development platform. I just recently got around to updating cygwin for the first time in a few years (which led to the new perl & needing to reinstall/remake cpan modules).

It's your prerogative to do this if you want\, but if you insist on building from CPAN instead of using what's packaged for Cygwin you will have to re-do a lot of the things I've already done.

I'm not insisting on anything. I was trying to install the cpan-reporting modules and it was pulling in pre-reqs. Are you saying that the cpan reporting module and all its prereqs are in a cygwin package? I've never noticed that. If that's the case\, then my bad. But if it isn't then how else would I install modules?

You'll have the same problem on any Linux distribution should you decide to shun the packaged distributions and bootstrap your own modules\, so this doesn't have anything to do with Cygwin\, really.

BTW\, you mentioned installing "an up-to-date" Core?

No\, I said you should start with installing local​::lib and then the latest Module-CoreList before diving into CPAN.

local​::lib? What do you mean? Why was it you thought I should install that? If you are referring to perl-mods in my home directory/lib\, that's where my private workspace -- not where I install perlmods. Module-Corelist? What did you mean by that? I was installing both newer cpan and it pulled in reqs\, some of which were failing. I also saw that reporting was 'offline'\, so I prioritized getting that online before I retried cpan-reqs. You might have noticed by now that the "system files" get installed to perl_vendor\, while locally built modules would end up either in site_perl or wherever you told local​::lib to place them. And yes\, you're not supposed to update the "system files" unless you accept that any breakage introduced that way is yours alone. But again getting off-topic here\, so I'll stop.

Ahhh... I see what you are referring to. When I install from CPAN\, if what I'm installing needs newer modules\, how are the system modules updated? While it's not a problem as much for cygwin\, on a linux system\, wouldn't it be more of a problem trying to get alternate UID's (like root) to use some the newer installed versions?

As for installing modules\, why should "any breakage" -- shouldn't the modules in cpan work? Or are you just patching them and not reporting compatibility problems as bugs as you indicated you might do with UUID?

If you aren't going to report them\, then how do you expect them to get fixed or even reported for that matter unless users don't simply "accept any breakage"\, and report the bug?

Cheers... -linda