Re: perl-comp module fixes
On Thu, Oct 08, 2009, steve muskiewicz wrote: Looks like the perl-comp package is still pulling a bunch of older module versions, probably due to the fact that the Compress::Zlib and various IO::Compress::* modules seem to have now been rolled into a single distribution called IO::Compress http://search.cpan.org/~pmqs/IO-Compress-2.021/ Can this package be updated so that it uses the newer modules? Sure, now done. Thanks for the hint. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
perl-comp module fixes
Hi, Looks like the perl-comp package is still pulling a bunch of older module versions, probably due to the fact that the Compress::Zlib and various IO::Compress::* modules seem to have now been rolled into a single distribution called IO::Compress http://search.cpan.org/~pmqs/IO-Compress-2.021/ Can this package be updated so that it uses the newer modules? thanks! -steve
outdated module in perl-devel
Hi, The Devel::StackTrace module in perl-devel in CURRENT is outdated. Latest version is 1.20, the package still has 1.1902 thanks -steve
Re: missing perl dep for Archive::Tar
On Tue, May 05, 2009, steve muskiewicz wrote: The latest Archive::Tar module (1.48) in perl-sys requires the Package::Constants module, which doesn't appear to be provided by any of the perl-* packages in openpkg CURRENT. Can this module be added to whichever perl-* package is appropriate? Ok, Package::Constants now added to perl-util and perl-util now required by perl-sys. Thanks for the hint. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: outdated module in perl-devel
On Thu, May 07, 2009, steve muskiewicz wrote: The Devel::StackTrace module in perl-devel in CURRENT is outdated. Latest version is 1.20, the package still has 1.1902 Ok, module now upgraded. Thanks for the hint. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
missing perl dep for Archive::Tar
Hi, The latest Archive::Tar module (1.48) in perl-sys requires the Package::Constants module, which doesn't appear to be provided by any of the perl-* packages in openpkg CURRENT. Can this module be added to whichever perl-* package is appropriate? thanks -steve
perl-ole package has outdated Spreadsheet::ParseExcel
FYI - the perl-ole package appears to have a significantly older version (0.32) of the Spreadsheet::ParseExcel module than the current one (0.49)
DateTime outdated in perl-time
Hi, The DateTime module is currently at 0.45 however the version in the perl-time package is still at 0.4401, probably due to the regex in the track session that appears to be expecting 4 digits in the version number. Can this be fixed/updated? thanks -steve
missing Perl prereq for Data::Compare
I tried to use the Data::Compare module from perl-util, but find that it is missing the pre-requisite module File::Find::Rule (as listed in META.yml/Makefile.PL for the Data::Compare module). Can this module be added to the appropriate perl-* package in OpenPKG CURRENT? thanks -steve
Re: Perl package issues on RHEL4
On Thu, Jun 12, 2008, steve muskiewicz wrote:
I'm currently building OpenPKG CURRENT on RHEL4, found a minor issue with the
perl:
The way the libdirs assignment is done causes a leading space to get added
to
the contents. This appears to be enough to break the perl -v and perl -V
output (in this case, it reports the Perl details from the RHEL4 package, ie.
the libs from /usr/lib/perl). I fixed it by changing this:
for dir in %{l_prefix}/lib /lib64 /usr/lib64 /lib /usr/lib /usr/ccs/lib;
do
[ -d $dir ] libdirs=$libdirs $dir
done
to this:
for dir in %{l_prefix}/lib /lib64 /usr/lib64 /lib /usr/lib /usr/ccs/lib;
do
[ -d $dir ] libdirs=${libdirs}${dir}
done
Now fixed. Thanks for reporting.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: perl-xml and ncurses minor issues on sol 10
On Fri, May 09, 2008, Scott Cruzen wrote: perl-xml contains HTML-Table-2.08.tar.gz which has a funky gid value that /openpkg/lib/openpkg/tar refuses to extract. I fixed it by recreating the tar file. I've applied a workaround to the perl-xml package which should fix this. ncurses fails to build because it can't find libm because there's no static libm on Solaris 10. Fixed by adding --with-shared to the spec file. Now also fixed by not building the test/ stuff at all from Ncurses. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
perl-xml and ncurses minor issues on sol 10
perl-xml contains HTML-Table-2.08.tar.gz which has a funky gid value that /openpkg/lib/openpkg/tar refuses to extract. I fixed it by recreating the tar file. ncurses fails to build because it can't find libm because there's no static libm on Solaris 10. Fixed by adding --with-shared to the spec file. __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
updated Spreadsheet::ParseExcel module in perl-ole?
Hello, It looks like there is a newer release (0.32) of the Perl Spreadsheet::ParseExcel module on CPAN. Can the perl-ole package be updated to use the newer version? (currently still using 0.2603 which is a couple of years old.) thanks -steve
Re: updated Spreadsheet::ParseExcel module in perl-ole?
On Mon, Apr 07, 2008, steve muskiewicz wrote: It looks like there is a newer release (0.32) of the Perl Spreadsheet::ParseExcel module on CPAN. Can the perl-ole package be updated to use the newer version? (currently still using 0.2603 which is a couple of years old.) Now updated. Thanks for the hint. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: CURRENT: 00INDEX.rdf.bz2 multiple entries for perl-openpkg
On Tue, Jan 08, 2008, Scott Cruzen wrote: There's two entries for perl-openpkg in the 00INDEX.rdf.bz2 file. One starts on line 11120 and mentions perl-openpkg-5.10.0-20080101. The other starts on line 60339 and refers to perl-openpkg-5.10.0-20080107. The url of the second points to the 00UPLOAD directory, which is inaccessible. I think that there's probably some bug in the process that generates 00INDEX.rdf.bz2, or my openpkg build command doesn't know that it should ignore the second entry. Oh, my fault. The file in 00UPLOAD was not picked up and filed into the proper subdir on the FTP server because it was alreay rolled with RPM 5 ;-) Sorry, should be fixed once the index is updated in about 30 minutes. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: conflicting files perl vs. perl-module
On Thu, Jan 03, 2008, Thomas Moschny wrote: Ralf S. Engelschall wrote: The conflicting files are from Module::Build which now seems to ship also with Perl itself. As perl-module always contains the latest version, I'm now removing those files in perl. So, issue now fixed. Thanks. While you're at it, here are two more overlaps: /openpkg/bin/ptar and /openpkg/bin/ptardiff for perl and perl-sys and /openpkg/bin/shasum for perl and perl-crypto. Thanks for those hints, too. Now fixed, too. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Upgrade from Perl 5.8 to 5.10
For your information: We upgraded Perl in OpenPKG CURRENT from version 5.8 to version 5.10. There are a few upgrade issues which require that you upgrade your existing packages in the right order: 1. Upgrade perl 2. Upgrade perl-openpkg 3. Upgrade perl-module 4. Upgrade all other perl-* modules The reason is that perl-openpkg contains a bugfix which is essential to make perl-openpkg(1) working under Perl 5.10 and perl-module has to be rebuilt/reinstalled in order to allow XS-based modules in perl-* to correctly build again (as a header in the C API is gone). If you just to a usual openpkg build -Ua this order will be not the case as the tool doesn't know those constrains. Hence please use openpkg build perl | sh; openpkg build perl-openpkg perl-module | sh once before you do your openpkg build -Ua. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
CGI::FormBuilder in perl-www
Hi, It looks like the CGI::FormBuilder module has changed its source file name (from .tar.gz to .tgz). As a result the version in the perl-www module is out of date (3.0302 vs. 3.0501). Any chance this can be updated? thanks! -steve
Re: CGI::FormBuilder in perl-www
On Mon, Sep 17, 2007, steve muskiewicz wrote: It looks like the CGI::FormBuilder module has changed its source file name (from .tar.gz to .tgz). As a result the version in the perl-www module is out of date (3.0302 vs. 3.0501). Any chance this can be updated? Sure, now done. Thanks for the hint. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: PERL Modules Build Issues - UPDATES?
On Tue, Sep 04, 2007, Doug Summers wrote: Ralf S. Engelschall wrote: On Wed, Aug 29, 2007, Doug Summers wrote: Ralf S. Engelschall wrote: On Tue, Aug 28, 2007, Doug Summers wrote: (On RHEL4-AMD64) Getting this after upgrading to openpkg-20070718-20070718 perl-5.8.8-20070714: Executing(%install): env -i /openpkg/lib/openpkg/bash --norc --noprofile --posix -e /openpkg/RPM/TMP/rpm-tmp.33953 + cd /openpkg/RPM/TMP + cd perl-util-5.8.8 + rm -rf /openpkg/RPM/TMP/perl-util-5.8.8-root + /openpkg/bin/perl-openpkg prepare IO object version 1.22 does not match bootstrap parameter 1.23 at /openpkg/lib/perl/5.8.8/x86_64-linux/DynaLoader.pm line 253. Compilation failed in require at /openpkg/bin/perl-openpkg line 29. BEGIN failed--compilation aborted at /openpkg/bin/perl-openpkg line 29. This is happening with perl-module as well. RHEL4-I386 doesn't have this problem. AFAIK this error occurs if the version in the IO.pm is different from what is in the IO.bs/IO.so. I've no clue how this can happen, but perhaps Perl under amd64-linux loads the wrong files. We have IO in perl (version 1.22) and in perl-sys (version 1.23). Seems like Perl on amd64-linux loads IO.pm from perl but IO.so from perl-sys. Can you show me the output of perl -V and especially its @INC output at the end? Perhaps there is a wrong @INC on this platform... Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under linux Compiled at Aug 28 2007 15:46:33 @INC: /openpkg/lib/perl/site_perl/5.8.8/x86_64-linux /openpkg/lib/perl/site_perl/5.8.8 /openpkg/lib/perl/site_perl /openpkg/lib/perl/vendor_perl/5.8.8/x86_64-linux /openpkg/lib/perl/vendor_perl/5.8.8 /openpkg/lib/perl/vendor_perl /openpkg/lib/perl/5.8.8/x86_64-linux /openpkg/lib/perl/5.8.8 SNIP Anything I can try? I'm at a standstill... Puhhh... well, we only know that the wrong files are loaded although @INC is correct. I've currently no clue what causes this and especially why this happens under just this particular platform. When I find time I'll try to repeat it under an amd64-linux box myself. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: PERL Modules Build Issues - UPDATES?
On Wed, Sep 05, 2007, Ralf S. Engelschall wrote: [...] IO object version 1.22 does not match bootstrap parameter 1.23 at /openpkg/lib/perl/5.8.8/x86_64-linux/DynaLoader.pm line 253. Compilation failed in require at /openpkg/bin/perl-openpkg line 29. BEGIN failed--compilation aborted at /openpkg/bin/perl-openpkg line 29. This is happening with perl-module as well. RHEL4-I386 doesn't have this problem. AFAIK this error occurs if the version in the IO.pm is different from what is in the IO.bs/IO.so. I've no clue how this can happen, but perhaps Perl under amd64-linux loads the wrong files. We have IO in perl (version 1.22) and in perl-sys (version 1.23). Seems like Perl on amd64-linux loads IO.pm from perl but IO.so from perl-sys. Can you show me the output of perl -V and especially its @INC output at the end? Perhaps there is a wrong @INC on this platform... Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under linux Compiled at Aug 28 2007 15:46:33 @INC: /openpkg/lib/perl/site_perl/5.8.8/x86_64-linux /openpkg/lib/perl/site_perl/5.8.8 /openpkg/lib/perl/site_perl /openpkg/lib/perl/vendor_perl/5.8.8/x86_64-linux /openpkg/lib/perl/vendor_perl/5.8.8 /openpkg/lib/perl/vendor_perl /openpkg/lib/perl/5.8.8/x86_64-linux /openpkg/lib/perl/5.8.8 SNIP Anything I can try? I'm at a standstill... Puhhh... well, we only know that the wrong files are loaded although @INC is correct. I've currently no clue what causes this and especially why this happens under just this particular platform. When I find time I'll try to repeat it under an amd64-linux box myself. Ok, I tried it myself on a Debian 4.0 AMD64 box (amd64-linux) with the latest OpenPKG CURRENT packages and the problem is _NOT_ repeatable there: | $ uname -a | Linux s15260669 2.6.22.1 #1 SMP Wed Aug 1 21:02:26 UTC 2007 x86_64 GNU/Linux | $ /usr/opkg/bin/openpkg rpm -qa |grep perl | perl-util-5.8.8-20070829 | perl-5.8.8-20070714 | perl-module-5.8.8-20070807 | $ /usr/opkg/bin/perl -e 'use IO;' | $ No error on loading the IO module although I have perl and perl-util installed. So, this seems to be a local problem. What I would do is to openpkg rpm -e all(!) perl* modules, then a rm -rf prefix/lib/perl to be sure no orphaned files are staying around and then reinstall the perl* stuff with openpkg build perl [...] | sh again. Either the problem is then finally gone or you are faced with a RHEL specific bug -- I guess somewhere outside of Perl. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: PERL Modules Build Issues - FIXED!
Ralf S. Engelschall wrote: On Wed, Sep 05, 2007, Ralf S. Engelschall wrote: [...] IO object version 1.22 does not match bootstrap parameter 1.23 at /openpkg/lib/perl/5.8.8/x86_64-linux/DynaLoader.pm line 253. Compilation failed in require at /openpkg/bin/perl-openpkg line 29. BEGIN failed--compilation aborted at /openpkg/bin/perl-openpkg line 29. This is happening with perl-module as well. RHEL4-I386 doesn't have this problem. AFAIK this error occurs if the version in the IO.pm is different from what is in the IO.bs/IO.so. I've no clue how this can happen, but perhaps Perl under amd64-linux loads the wrong files. We have IO in perl (version 1.22) and in perl-sys (version 1.23). Seems like Perl on amd64-linux loads IO.pm from perl but IO.so from perl-sys. Can you show me the output of perl -V and especially its @INC output at the end? Perhaps there is a wrong @INC on this platform... Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under linux Compiled at Aug 28 2007 15:46:33 @INC: /openpkg/lib/perl/site_perl/5.8.8/x86_64-linux /openpkg/lib/perl/site_perl/5.8.8 /openpkg/lib/perl/site_perl /openpkg/lib/perl/vendor_perl/5.8.8/x86_64-linux /openpkg/lib/perl/vendor_perl/5.8.8 /openpkg/lib/perl/vendor_perl /openpkg/lib/perl/5.8.8/x86_64-linux /openpkg/lib/perl/5.8.8 SNIP Anything I can try? I'm at a standstill... Puhhh... well, we only know that the wrong files are loaded although @INC is correct. I've currently no clue what causes this and especially why this happens under just this particular platform. When I find time I'll try to repeat it under an amd64-linux box myself. Ok, I tried it myself on a Debian 4.0 AMD64 box (amd64-linux) with the latest OpenPKG CURRENT packages and the problem is _NOT_ repeatable there: | $ uname -a | Linux s15260669 2.6.22.1 #1 SMP Wed Aug 1 21:02:26 UTC 2007 x86_64 GNU/Linux | $ /usr/opkg/bin/openpkg rpm -qa |grep perl | perl-util-5.8.8-20070829 | perl-5.8.8-20070714 | perl-module-5.8.8-20070807 | $ /usr/opkg/bin/perl -e 'use IO;' | $ No error on loading the IO module although I have perl and perl-util installed. So, this seems to be a local problem. What I would do is to openpkg rpm -e all(!) perl* modules, then a rm -rf prefix/lib/perl to be sure no orphaned files are staying around and then reinstall the perl* stuff with openpkg build perl [...] | sh again. Either the problem is then finally gone or you are faced with a RHEL specific bug -- I guess somewhere outside of Perl. Thanks, Ralph. That did the trick. __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: PERL Modules Build Issues
Ralf S. Engelschall wrote: On Wed, Aug 29, 2007, Doug Summers wrote: Ralf S. Engelschall wrote: On Tue, Aug 28, 2007, Doug Summers wrote: (On RHEL4-AMD64) Getting this after upgrading to openpkg-20070718-20070718 perl-5.8.8-20070714: Executing(%install): env -i /openpkg/lib/openpkg/bash --norc --noprofile --posix -e /openpkg/RPM/TMP/rpm-tmp.33953 + cd /openpkg/RPM/TMP + cd perl-util-5.8.8 + rm -rf /openpkg/RPM/TMP/perl-util-5.8.8-root + /openpkg/bin/perl-openpkg prepare IO object version 1.22 does not match bootstrap parameter 1.23 at /openpkg/lib/perl/5.8.8/x86_64-linux/DynaLoader.pm line 253. Compilation failed in require at /openpkg/bin/perl-openpkg line 29. BEGIN failed--compilation aborted at /openpkg/bin/perl-openpkg line 29. This is happening with perl-module as well. RHEL4-I386 doesn't have this problem. AFAIK this error occurs if the version in the IO.pm is different from what is in the IO.bs/IO.so. I've no clue how this can happen, but perhaps Perl under amd64-linux loads the wrong files. We have IO in perl (version 1.22) and in perl-sys (version 1.23). Seems like Perl on amd64-linux loads IO.pm from perl but IO.so from perl-sys. Can you show me the output of perl -V and especially its @INC output at the end? Perhaps there is a wrong @INC on this platform... Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under linux Compiled at Aug 28 2007 15:46:33 @INC: /openpkg/lib/perl/site_perl/5.8.8/x86_64-linux /openpkg/lib/perl/site_perl/5.8.8 /openpkg/lib/perl/site_perl /openpkg/lib/perl/vendor_perl/5.8.8/x86_64-linux /openpkg/lib/perl/vendor_perl/5.8.8 /openpkg/lib/perl/vendor_perl /openpkg/lib/perl/5.8.8/x86_64-linux /openpkg/lib/perl/5.8.8 This looks good and hence cannot be the problem. Hmmm... then you have perhaps an old IO.so flying around in the wrong location. Do a... | $ find /openpkg/lib/perl -name IO.so -print ...and check how many files you see. I receive: | /openpkg/lib/perl/5.8.8/i386-freebsd/auto/IO/IO.so | /openpkg/lib/perl/vendor_perl/5.8.8/i386-freebsd/auto/IO/IO.so Perhaps you have more than those two... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org perl-sys is definitely the problem. I forced its removal and the perl-* packages that aren't dependent on it build just fine. Any idea where to proceed from here? __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: PERL Modules Build Issues
On Tue, Aug 28, 2007, Doug Summers wrote: (On RHEL4-AMD64) Getting this after upgrading to openpkg-20070718-20070718 perl-5.8.8-20070714: Executing(%install): env -i /openpkg/lib/openpkg/bash --norc --noprofile --posix -e /openpkg/RPM/TMP/rpm-tmp.33953 + cd /openpkg/RPM/TMP + cd perl-util-5.8.8 + rm -rf /openpkg/RPM/TMP/perl-util-5.8.8-root + /openpkg/bin/perl-openpkg prepare IO object version 1.22 does not match bootstrap parameter 1.23 at /openpkg/lib/perl/5.8.8/x86_64-linux/DynaLoader.pm line 253. Compilation failed in require at /openpkg/bin/perl-openpkg line 29. BEGIN failed--compilation aborted at /openpkg/bin/perl-openpkg line 29. This is happening with perl-module as well. RHEL4-I386 doesn't have this problem. AFAIK this error occurs if the version in the IO.pm is different from what is in the IO.bs/IO.so. I've no clue how this can happen, but perhaps Perl under amd64-linux loads the wrong files. We have IO in perl (version 1.22) and in perl-sys (version 1.23). Seems like Perl on amd64-linux loads IO.pm from perl but IO.so from perl-sys. Can you show me the output of perl -V and especially its @INC output at the end? Perhaps there is a wrong @INC on this platform... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: PERL Modules Build Issues
Ralf S. Engelschall wrote: On Tue, Aug 28, 2007, Doug Summers wrote: (On RHEL4-AMD64) Getting this after upgrading to openpkg-20070718-20070718 perl-5.8.8-20070714: Executing(%install): env -i /openpkg/lib/openpkg/bash --norc --noprofile --posix -e /openpkg/RPM/TMP/rpm-tmp.33953 + cd /openpkg/RPM/TMP + cd perl-util-5.8.8 + rm -rf /openpkg/RPM/TMP/perl-util-5.8.8-root + /openpkg/bin/perl-openpkg prepare IO object version 1.22 does not match bootstrap parameter 1.23 at /openpkg/lib/perl/5.8.8/x86_64-linux/DynaLoader.pm line 253. Compilation failed in require at /openpkg/bin/perl-openpkg line 29. BEGIN failed--compilation aborted at /openpkg/bin/perl-openpkg line 29. This is happening with perl-module as well. RHEL4-I386 doesn't have this problem. AFAIK this error occurs if the version in the IO.pm is different from what is in the IO.bs/IO.so. I've no clue how this can happen, but perhaps Perl under amd64-linux loads the wrong files. We have IO in perl (version 1.22) and in perl-sys (version 1.23). Seems like Perl on amd64-linux loads IO.pm from perl but IO.so from perl-sys. Can you show me the output of perl -V and especially its @INC output at the end? Perhaps there is a wrong @INC on this platform... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under linux Compiled at Aug 28 2007 15:46:33 @INC: /openpkg/lib/perl/site_perl/5.8.8/x86_64-linux /openpkg/lib/perl/site_perl/5.8.8 /openpkg/lib/perl/site_perl /openpkg/lib/perl/vendor_perl/5.8.8/x86_64-linux /openpkg/lib/perl/vendor_perl/5.8.8 /openpkg/lib/perl/vendor_perl /openpkg/lib/perl/5.8.8/x86_64-linux /openpkg/lib/perl/5.8.8 __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: PERL Modules Build Issues
On Wed, Aug 29, 2007, Doug Summers wrote: Ralf S. Engelschall wrote: On Tue, Aug 28, 2007, Doug Summers wrote: (On RHEL4-AMD64) Getting this after upgrading to openpkg-20070718-20070718 perl-5.8.8-20070714: Executing(%install): env -i /openpkg/lib/openpkg/bash --norc --noprofile --posix -e /openpkg/RPM/TMP/rpm-tmp.33953 + cd /openpkg/RPM/TMP + cd perl-util-5.8.8 + rm -rf /openpkg/RPM/TMP/perl-util-5.8.8-root + /openpkg/bin/perl-openpkg prepare IO object version 1.22 does not match bootstrap parameter 1.23 at /openpkg/lib/perl/5.8.8/x86_64-linux/DynaLoader.pm line 253. Compilation failed in require at /openpkg/bin/perl-openpkg line 29. BEGIN failed--compilation aborted at /openpkg/bin/perl-openpkg line 29. This is happening with perl-module as well. RHEL4-I386 doesn't have this problem. AFAIK this error occurs if the version in the IO.pm is different from what is in the IO.bs/IO.so. I've no clue how this can happen, but perhaps Perl under amd64-linux loads the wrong files. We have IO in perl (version 1.22) and in perl-sys (version 1.23). Seems like Perl on amd64-linux loads IO.pm from perl but IO.so from perl-sys. Can you show me the output of perl -V and especially its @INC output at the end? Perhaps there is a wrong @INC on this platform... Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under linux Compiled at Aug 28 2007 15:46:33 @INC: /openpkg/lib/perl/site_perl/5.8.8/x86_64-linux /openpkg/lib/perl/site_perl/5.8.8 /openpkg/lib/perl/site_perl /openpkg/lib/perl/vendor_perl/5.8.8/x86_64-linux /openpkg/lib/perl/vendor_perl/5.8.8 /openpkg/lib/perl/vendor_perl /openpkg/lib/perl/5.8.8/x86_64-linux /openpkg/lib/perl/5.8.8 This looks good and hence cannot be the problem. Hmmm... then you have perhaps an old IO.so flying around in the wrong location. Do a... | $ find /openpkg/lib/perl -name IO.so -print ...and check how many files you see. I receive: | /openpkg/lib/perl/5.8.8/i386-freebsd/auto/IO/IO.so | /openpkg/lib/perl/vendor_perl/5.8.8/i386-freebsd/auto/IO/IO.so Perhaps you have more than those two... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: PERL Modules Build Issues
Ralf S. Engelschall wrote: On Wed, Aug 29, 2007, Doug Summers wrote: Ralf S. Engelschall wrote: On Tue, Aug 28, 2007, Doug Summers wrote: (On RHEL4-AMD64) Getting this after upgrading to openpkg-20070718-20070718 perl-5.8.8-20070714: Executing(%install): env -i /openpkg/lib/openpkg/bash --norc --noprofile --posix -e /openpkg/RPM/TMP/rpm-tmp.33953 + cd /openpkg/RPM/TMP + cd perl-util-5.8.8 + rm -rf /openpkg/RPM/TMP/perl-util-5.8.8-root + /openpkg/bin/perl-openpkg prepare IO object version 1.22 does not match bootstrap parameter 1.23 at /openpkg/lib/perl/5.8.8/x86_64-linux/DynaLoader.pm line 253. Compilation failed in require at /openpkg/bin/perl-openpkg line 29. BEGIN failed--compilation aborted at /openpkg/bin/perl-openpkg line 29. This is happening with perl-module as well. RHEL4-I386 doesn't have this problem. AFAIK this error occurs if the version in the IO.pm is different from what is in the IO.bs/IO.so. I've no clue how this can happen, but perhaps Perl under amd64-linux loads the wrong files. We have IO in perl (version 1.22) and in perl-sys (version 1.23). Seems like Perl on amd64-linux loads IO.pm from perl but IO.so from perl-sys. Can you show me the output of perl -V and especially its @INC output at the end? Perhaps there is a wrong @INC on this platform... Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under linux Compiled at Aug 28 2007 15:46:33 @INC: /openpkg/lib/perl/site_perl/5.8.8/x86_64-linux /openpkg/lib/perl/site_perl/5.8.8 /openpkg/lib/perl/site_perl /openpkg/lib/perl/vendor_perl/5.8.8/x86_64-linux /openpkg/lib/perl/vendor_perl/5.8.8 /openpkg/lib/perl/vendor_perl /openpkg/lib/perl/5.8.8/x86_64-linux /openpkg/lib/perl/5.8.8 This looks good and hence cannot be the problem. Hmmm... then you have perhaps an old IO.so flying around in the wrong location. Do a... | $ find /openpkg/lib/perl -name IO.so -print ...and check how many files you see. I receive: | /openpkg/lib/perl/5.8.8/i386-freebsd/auto/IO/IO.so | /openpkg/lib/perl/vendor_perl/5.8.8/i386-freebsd/auto/IO/IO.so Perhaps you have more than those two... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org Nope... /openpkg/lib/perl/5.8.8/x86_64-linux/auto/IO/IO.so /openpkg/lib/perl/vendor_perl/5.8.8/x86_64-linux/auto/IO/IO.so __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: perl-net fails to build on Solaris (bad Net-DHCP tar file)
On Wed, Aug 29, 2007, Caleb Epstein wrote: From the openpkg build output: + /openpkg-current/lib/openpkg/gzip -dc /openpkg-current/RPM/SRC/perl-net/Net-DHCP-0.66.tar.gz + /openpkg-current/lib/openpkg/tar -xf - /openpkg-current/lib/openpkg/tar: Archive value 4294967295 is out of gid_t range -2147483648..2147483647 [...] Ah, I see. Bad attributes in the upstream distribution tarball. I've applied a workaround to the perl-net package and it now builds just fine again also under Solaris. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
PERL Modules Build Issues
(On RHEL4-AMD64) Getting this after upgrading to openpkg-20070718-20070718 perl-5.8.8-20070714: Executing(%install): env -i /openpkg/lib/openpkg/bash --norc --noprofile --posix -e /openpkg/RPM/TMP/rpm-tmp.33953 + cd /openpkg/RPM/TMP + cd perl-util-5.8.8 + rm -rf /openpkg/RPM/TMP/perl-util-5.8.8-root + /openpkg/bin/perl-openpkg prepare IO object version 1.22 does not match bootstrap parameter 1.23 at /openpkg/lib/perl/5.8.8/x86_64-linux/DynaLoader.pm line 253. Compilation failed in require at /openpkg/bin/perl-openpkg line 29. BEGIN failed--compilation aborted at /openpkg/bin/perl-openpkg line 29. This is happening with perl-module as well. RHEL4-I386 doesn't have this problem. I'm using perl-openpkg-5.8.8-20061013. __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Problems compiling perl-stats
Hi, I'm having problems compiling the perl-stats RPM package on Ubuntu 7.04. When I try a openpkg rpm -bb perl-stats.spec, the following error appears: [EMAIL PROTECTED] openpkg rpm -bb perl-stats/perl-stats.spec Executing(%prep): env -i /opt/local/lib/openpkg/bash --norc --noprofile --posix -e /opt/local/RPM/TMP/rpm-tmp.31381 Executing(%build): env -i /opt/local/lib/openpkg/bash --norc --noprofile --posix -e /opt/local/RPM/TMP/rpm-tmp.31381 Executing(%install): env -i /opt/local/lib/openpkg/bash --norc --noprofile --posix -e /opt/local/RPM/TMP/rpm-tmp.31381 Processing files: perl-stats-5.8.8-20070708 error: Could not open %files file /opt/local/RPM/TMP/perl-stats-5.8.8/files: No such file or directory RPM build errors: Could not open %files file /opt/local/RPM/TMP/perl-stats-5.8.8/files: No such file or directory [EMAIL PROTECTED] Best Regards, Peter Zimmer __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: outdated CGI::Application::Plugin modules in perl-www
On Wed, Jun 20, 2007, steve muskiewicz wrote:
Thanks for the quick response on this!
One more module in perl-dbix (sorry I forgot to mention this one in the
original email): looks like Class::DBI now has a v in the source file name
(before the version number), can it be updated to the latest (3.0.16)?
The updated source URL now looks like:
http://www.cpan.org/modules/by-module/Class/Class-DBI-v%{V_class_dbi}.tar.gz
Now fixed, too. Thanks.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
outdated CGI::Application::Plugin modules in perl-www
Hello, It appears that some of the CGI::Application::Plugin::* modules in perl-www in CURRENT are rather out of date. For example: cpan[1] m CGI::Application::Plugin::Session CPAN: Storable loaded ok (v2.15) Going to read /opkg25/RPM/TMP/.cpan/Metadata Database was generated on Tue, 19 Jun 2007 09:07:59 GMT Module id = CGI::Application::Plugin::Session CPAN_USERID CEESHEK (Cees Hek [EMAIL PROTECTED]) CPAN_VERSION 1.02 CPAN_FILEC/CE/CEESHEK/CGI-Application-Plugin-Session-1.02.tar.gz UPLOAD_DATE 2006-05-23 MANPAGE CGI::Application::Plugin::Session - Add CGI::Session support to CGI::Application INST_FILE /opkg25/lib/perl/vendor_perl/5.8.8/CGI/Application/Plugin/Session.pm INST_VERSION 0.09 cpan[2] m CGI::Application::Plugin::DBH Module id = CGI::Application::Plugin::DBH CPAN_USERID MARKSTOS (Mark Stosberg [EMAIL PROTECTED]) CPAN_VERSION 4.00 CPAN_FILEM/MA/MARKSTOS/CGI-Application-Plugin-DBH-4.00.tar.gz UPLOAD_DATE 2005-11-03 MANPAGE CGI::Application::Plugin::DBH - Easy DBI access from CGI::Application INST_FILE/opkg25/lib/perl/vendor_perl/5.8.8/CGI/Application/Plugin/DBH.pm INST_VERSION 3.00 My guess is this is because it looks like those modules never made it into the %track section of the spec file, therefore they aren't being flagged for newer versions by vcheck ?? On a related note, there is also an update to the Ima::DBI module (0.35, released a few weeks back) in perl-dbix that hasn't yet shown up in CURRENT, in this case I think it's because the author for this version has changed, so now the URL in the %track section would be: http://www.cpan.org/modules/by-authors/id/P/PE/PERRIN/ Could these modules be updated at some point? thanks! -steve
Re: outdated CGI::Application::Plugin modules in perl-www
On Tue, Jun 19, 2007, steve muskiewicz wrote: It appears that some of the CGI::Application::Plugin::* modules in perl-www in CURRENT are rather out of date. For example: cpan[1] m CGI::Application::Plugin::Session CPAN: Storable loaded ok (v2.15) Going to read /opkg25/RPM/TMP/.cpan/Metadata Database was generated on Tue, 19 Jun 2007 09:07:59 GMT Module id = CGI::Application::Plugin::Session CPAN_USERID CEESHEK (Cees Hek [EMAIL PROTECTED]) CPAN_VERSION 1.02 CPAN_FILEC/CE/CEESHEK/CGI-Application-Plugin-Session-1.02.tar.gz UPLOAD_DATE 2006-05-23 MANPAGE CGI::Application::Plugin::Session - Add CGI::Session support to CGI::Application INST_FILE/opkg25/lib/perl/vendor_perl/5.8.8/CGI/Application/Plugin/ Session.pm INST_VERSION 0.09 cpan[2] m CGI::Application::Plugin::DBH Module id = CGI::Application::Plugin::DBH CPAN_USERID MARKSTOS (Mark Stosberg [EMAIL PROTECTED]) CPAN_VERSION 4.00 CPAN_FILEM/MA/MARKSTOS/CGI-Application-Plugin-DBH-4.00.tar.gz UPLOAD_DATE 2005-11-03 MANPAGE CGI::Application::Plugin::DBH - Easy DBI access from CGI::Application INST_FILE/opkg25/lib/perl/vendor_perl/5.8.8/CGI/Application/Plugin/ DBH.pm INST_VERSION 3.00 My guess is this is because it looks like those modules never made it into the %track section of the spec file, therefore they aren't being flagged for newer versions by vcheck ?? Yes, good catch. On a related note, there is also an update to the Ima::DBI module (0.35, released a few weeks back) in perl-dbix that hasn't yet shown up in CURRENT, in this case I think it's because the author for this version has changed, so now the URL in the %track section would be: http://www.cpan.org/modules/by-authors/ id/P/PE/PERRIN/ Done. Could these modules be updated at some point? Sure, both packages now fixed. Thanks for your feedback. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
perl 5.8.8 / current .. build failure while upgrading openpkg
Hello List ! trying to build bind on current / FC2 fails at building perl 5.8.8 .. don't know if the package is in cause of the problem or my personnal openpkg setup, as I just upgraded from an earlier openpkg release with openpkg build openpkg | sh (did not find any other solution, but this one is rather nice :-) ) I'm sorry I did not take time to investigate on the problem yet. Here is the build log if someone want to look at it; http://pastebin.ca/493015 Olivier Kaloudoff Saint Raphael __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: PERL-UTIL Build Stuck on RHEL4-AMD64 - (Also on AIX 5.3)
FYI I have a similar issue on AIX 5.3 so I guess the issue is generic.
The point at which things go wrong appears to be that Class-Factory-Util
requires Module::Build.
See below.
[snip first part of /openpkg build perl-utils] (and using
perl-util-5.8.8-20070508.src.rpm)
...
cp lib/Test/Harness/Straps.pm blib/lib/Test/Harness/Straps.pm
cp bin/prove blib/script/prove
/openpkg/b1/RPM/TMP/opkg-perl-openpkg-perl-util/perl.sh -MExtUtils::MY -e
MY-fixin(shift) blib/script/prove
++ step 4: install
++ installing module via ExtUtils::MakeMaker environment
Installing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/Test/Harness.pm
Installing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/Test/Harness/Results.pm
Installing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/Test/Harness/TAP.pod
Installing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/Test/Harness/Point.pm
Installing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/Test/Harness/Util.pm
Installing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/Test/Harness/Iterator.pm
Installing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/Test/Harness/Assert.pm
Installing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/Test/Harness/Straps.pm
Installing /openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/bin/prove
Writing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/aix/auto/Test/Harness/.packlist
++ cleaning up environment
+ /openpkg/b1/bin/perl-openpkg -d
/openpkg/b1/RPM/SRC/perl-util/Alias-2.32.tar.gz configure build install
++ OpenPKG perl-openpkg 2.0.1 (03-Dec-2004)
++ determined RPM program: /openpkg/b1/libexec/openpkg/rpm (4.2.1)
++ determined Perl program: /openpkg/b1/bin/perl (5.8.8)
++ step 2: configure
++ configuring module via ExtUtils::MakeMaker environment
Checking if your kit is complete...
Looks good
Writing Makefile for Alias
++ step 3: build
++ building module via ExtUtils::MakeMaker environment
cp Alias.pm blib/lib/Alias.pm
/openpkg/b1/RPM/TMP/opkg-perl-openpkg-perl-util/perl.sh -e 'use
ExtUtils::Mksymlists; Mksymlists(NAME = Alias, DL_FUNCS = { },
FUNCLIST = [], DL_VARS = []);'
/openpkg/b1/RPM/TMP/opkg-perl-openpkg-perl-util/perl.sh
/openpkg/b1/lib/perl/5.8.8/ExtUtils/xsubpp -typemap
/openpkg/b1/lib/perl/5.8.8/ExtUtils/typemap Alias.xs Alias.xsc mv
Alias.xsc Alias.c
/openpkg/b1/bin/gcc -c -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE
-DUSE_NATIVE_DLOPEN -fno-strict-aliasing -pipe -Wdeclaration-after-statement
-I/openpkg/b1/include -D_LARGE_FILES-DVERSION=\2.32\
-DXS_VERSION=\2.32\ -I/openpkg/b1/lib/perl/5.8.8/aix/CORE Alias.c
Running Mkbootstrap for Alias ()
chmod 644 Alias.bs
rm -f blib/arch/auto/Alias/Alias.so
/openpkg/b1/bin/gcc -Wl,-bhalt:4 -Wl,-bexpall -Wl,-G -Wl,-bnoentry -lc
-L/openpkg/b1/lib Alias.o -o blib/arch/auto/Alias/Alias.so \
chmod 755 blib/arch/auto/Alias/Alias.so
cp Alias.bs blib/arch/auto/Alias/Alias.bs
chmod 644 blib/arch/auto/Alias/Alias.bs
++ step 4: install
++ installing module via ExtUtils::MakeMaker environment
Installing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/aix/auto/Alias/Alias.so
Installing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/aix/auto/Alias/Alias.bs
Files found in blib/arch: installing files in blib/lib into architecture
dependent library tree
Installing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/aix/Alias.pm
Writing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/aix/auto/Alias/.packlist
++ cleaning up environment
+ /openpkg/b1/bin/perl-openpkg -d
/openpkg/b1/RPM/SRC/perl-util/Attribute-Handlers-0.78.tar.gz configure build
install
++ OpenPKG perl-openpkg 2.0.1 (03-Dec-2004)
++ determined RPM program: /openpkg/b1/libexec/openpkg/rpm (4.2.1)
++ determined Perl program: /openpkg/b1/bin/perl (5.8.8)
++ step 2: configure
++ configuring module via ExtUtils::MakeMaker environment
Checking if your kit is complete...
Looks good
Writing Makefile for Attribute::Handlers
++ step 3: build
++ building module via ExtUtils::MakeMaker environment
cp lib/Attribute/Handlers.pm blib/lib/Attribute/Handlers.pm
++ step 4: install
++ installing module via ExtUtils::MakeMaker environment
Installing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/Attribute/Handlers.pm
Writing
/openpkg/b1/RPM/TMP/perl-util-5.8.8-root/openpkg/b1/lib/perl/vendor_perl/5.8.8/aix/auto/Attribute/Handlers/.packlist
++ cleaning up environment
+ /openpkg/b1/bin/perl-openpkg -d
/openpkg/b1/RPM/SRC/perl-util/Params-Validate-0.88.tar.gz configure build
install
++ OpenPKG perl-openpkg 2.0.1 (03-Dec-2004)
++ determined RPM program: /openpkg/b1
Re: PERL-UTIL Build Stuck on RHEL4-AMD64 - (Also on AIX 5.3)
Simon Mudd (Mailing address) wrote: FYI I have a similar issue on AIX 5.3 so I guess the issue is generic. The point at which things go wrong appears to be that Class-Factory-Util requires Module::Build. See below. snip When you said Module I tried rebuilding perl-util AFTER installing only perl-module perl-openpkg. On my RHEL4-I386 machine this worked. I will be testing Solaris 9 AIX 5.1 later on today. __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
RE: Perl-Util Dependency
I can confirm that this also works on AIX 5.3 IF perl-module is built first. In my case I have the following perl modules installed: perl-db-5.8.8-20070205 perl-module-5.8.8-20070509 perl-5.8.8-20070419 perl-openpkg-5.8.8-20061013 perl-util-5.8.8-20070509 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Doug Summers Sent: 10 May 2007 00:06 To: openpkg-users@openpkg.org Subject: Perl-Util Dependency I've been able to get perl-util-5.8.8-20070420 to build on rhel4-i386 and solaris-9-sparc64 if I build perl-module-5.8.8-20070423 first. Does this dependency need to be added to perl-util? __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Perl-Util Dependency
On Wed, May 09, 2007, Doug Summers wrote: I've been able to get perl-util-5.8.8-20070420 to build on rhel4-i386 and solaris-9-sparc64 if I build perl-module-5.8.8-20070423 first. Does this dependency need to be added to perl-util? Yes, seems like some newer versions of modules contained in perl-util require Module::Build from perl-module. I've added the dependency now. Thanks for figuring out the problem. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
missing Perl module dependency in CURRENT: Readonly
Hi, It looks like perl-locale in CURRENT has a missing Perl module dependency. The Locale::KeyedText module appears to need the Readonly in order to load successfully. I discovered this when I couldn't get perl-dbi to rebuild: % openpkg rpmbuild -ba perl-dbi.spec snip + /opkg25/bin/perl-openpkg -d /opkg25/RPM/SRC/perl-dbi/SQL-Routine-v0.70.3.tar.gz configure build install ++ OpenPKG perl-openpkg 2.0.1 (03-Dec-2004) ++ determined RPM program: /opkg25/libexec/openpkg/rpm (4.2.1) ++ determined Perl program: /opkg25/bin/perl (5.8.8) ++ step 2: configure ++ configuring module via ExtUtils::MakeMaker environment Checking if your kit is complete... Looks good Locale::KeyedText defines neither package nor VERSION--version check failed at /opkg25/lib/perl/vendor_perl/5.8.8/ExtUtils/MakeMaker.pm line 394 ++ step 3: build perl-openpkg:ERROR: neither Build nor Makefile found in working directory (No such file or directory) error: Bad exit status from /opkg25/RPM/TMP/rpm-tmp.30397 (% install) % perl -e 'use Locale::KeyedText' Can't locate desired version of Readonly in @INC: - only:Readonly:/opkg25/lib/perl/version/5.8.8 - /opkg25/lib/perl/site_perl/5.8.8/sun4-solaris - /opkg25/lib/perl/site_perl/5.8.8 - /opkg25/lib/perl/site_perl - /opkg25/lib/perl/vendor_perl/5.8.8/sun4-solaris - /opkg25/lib/perl/vendor_perl/5.8.8 - /opkg25/lib/perl/vendor_perl - /opkg25/lib/perl/5.8.8/sun4-solaris - /opkg25/lib/perl/5.8.8 - . at /opkg25/lib/perl/vendor_perl/5.8.8/Locale/KeyedText.pm line 14 BEGIN failed--compilation aborted at /opkg25/lib/perl/vendor_perl/5.8.8/Locale/KeyedText.pm line 14. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. I searched but couldn't find the Readonly module anywhere in the CURRENT package index data. Can it be added somewhere (perl-util?) to fix this issue? thanks! Steve
perl-ssl broken in CURRENT (Crypt-SSLeay patch)
It appears the format of the Makefile.PL for the Crypt-SSLeay library
has changed since the perl-ssl.spec file was written. This
substitution no longer works:
( cd Crypt-SSLeay-%{V_crypt_ssleay}
%{l_shtool} subst \
-e 's;^\(my @POSSIBLE_SSL_DIRS =
qw(\)[^)]*\().*\)$;\1%{l_prefix}\2;' \
Makefile.PL
) || exit $?
I changed it to this and got the desired behavior:
( cd Crypt-SSLeay-%{V_crypt_ssleay}
%{l_shtool} subst \
-e 's;/usr$;%{l_prefix};' \
Makefile.PL
) || exit $?
Clearly this is a bit of a brute force substitution, but I'm pressed
for time :-)
--
Caleb Epstein
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: perl-net: Please add IO::Socket::Multicast
On Thu, Mar 01, 2007, Caleb Epstein wrote: Would you consider adding the module IO::Socket::Multicast to the perl-net package? Its quite useful! Yes, IO::Socket::Multicast certainly is a decent module, so I've added it to CURRENT's perl-net now: http://cvs.openpkg.org/chngview?cn=34269 Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Perl (5.8.8-2.20061018) build prob on Solaris 8/SPARC
It's been a couple of years since I touched openpkg ... just tried building a basic setup with perl on a Solaris 8/SPARC system and ran into the following: --- # openpkg rpmbuild --rebuild ./perl-5.8.8-2.20061018.src.rpm Installing ./perl-5.8.8-2.20061018.src.rpm Executing(%prep): env -i /export/apps/opkg/2.x/lib/openpkg/bash --norc --noprofile --posix -e /export/apps/opkg/2.x/RPM/TMP/rpm-tmp.1439 + cd /export/apps/opkg/2.x/RPM/TMP . . . Making DynaLoader (static) make[2]: [extras.install] Error 1 (ignored) ./perl installman --destdir=/export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root WARNING: You've never run 'make test'!!! (Installing anyway.) /export/apps/opkg/2.x/man/man1/perl.1 /export/apps/opkg/2.x/man/man1/perl5004delta.1 /export/apps/opkg/2.x/man/man1/perl5005delta.1 . . . /export/apps/opkg/2.x/man/man1/splain.1 /export/apps/opkg/2.x/man/man1/xsubpp.1 /export/apps/opkg/2.x/man/man1/a2p.1 /export/apps/opkg/2.x/man/man1/find2perl.1 /export/apps/opkg/2.x/man/man1/s2p.1 + case sun4u-sunos5.8 in + cd /usr/include + PERL5LIB=/export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/lib/perl + export PERL5LIB ++ /export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/bin/perl -V:installarchlib + eval 'installarchlib='\''/export/apps/opkg/2.x/lib/perl/5.8.8/sun4-solaris'\'';' ++ installarchlib=/export/apps/opkg/2.x/lib/perl/5.8.8/sun4-solaris + xargs /export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/bin/perl /export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/bin/h2ph -h -d /export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/lib/perl/5.8.8/sun4-solaris + echo aio.h alloca.h apptrace.h apptrace_impl.h ar.h archives.h arm.h assert.h auth_attr.h bzlib.h cmqbc.h cmqc.h cmqcfc.h cmqpsc.h cmqxc.h cmqzc.h config_admin.h cpio.h crypt.h ctype.h curses.h deflt.h demangle.h devid.h devmgmt.h devpoll.h dial.h dirent.h dlfcn.h door.h elf.h errno.h eti.h euc.h exacct.h exacct_impl.h exec_attr.h fatal.h fcntl.h float.h floatingpoint.h fmtmsg.h fnmatch.h form.h ftw.h gelf.h .. sys/xti_osi.h sys/xti_xtiopt.h sys/zsdev.h aio.h - aio.ph alloca.h - alloca.ph apptrace.h - apptrace.ph apptrace_impl.h - apptrace_impl.ph ar.h - ar.ph archives.h - archives.ph arm.h - arm.ph . . . assert.h - assert.ph auth_attr.h - auth_attr.ph bzlib.h - bzlib.ph cmqbc.h - cmqbc.ph Can't open cmqbc.h: No such file or directory cmqc.h - cmqc.ph Can't open cmqc.h: No such file or directory cmqcfc.h - cmqcfc.ph Can't open cmqcfc.h: No such file or directory cmqpsc.h - cmqpsc.ph Can't open cmqpsc.h: No such file or directory cmqxc.h - cmqxc.ph Can't open cmqxc.h: No such file or directory cmqzc.h - cmqzc.ph Can't open cmqzc.h: No such file or directory config_admin.h - config_admin.ph cpio.h - cpio.ph crypt.h - crypt.ph . . . sys/xti_inet.h - sys/xti_inet.ph sys/xti_osi.h - sys/xti_osi.ph sys/xti_xtiopt.h - sys/xti_xtiopt.ph sys/zsdev.h - sys/zsdev.ph + exit 1 error: Bad exit status from /export/apps/opkg/2.x/RPM/TMP/rpm-tmp.32719 (%install) RPM build errors: Bad exit status from /export/apps/opkg/2.x/RPM/TMP/rpm-tmp.32719 (%install) --- I tried manually running h2ph but it looks OK at first glance. --- # cd /usr/include # PERL5LIB=/export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/lib/perl # export PERL5LIB # /export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/bin/perl /export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/bin/h2ph -h -d /export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/lib/perl/5.8.8/sun4-sol aris sys/zsdev.h # echo $? 0 # --- Any ideas? Thanks, VK __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Perl (5.8.8-2.20061018) build prob on Solaris 8/SPARC
On Sun, Oct 29, 2006, Vinod Kutty wrote: [...] /export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/bin/h2ph -h -d /export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/lib/perl/5.8.8/sun4-solaris + echo aio.h alloca.h apptrace.h apptrace_impl.h ar.h archives.h arm.h assert.h auth_attr.h bzlib.h cmqbc.h cmqc.h cmqcfc.h cmqpsc.h cmqxc.h cmqzc.h config_admin.h cpio.h crypt.h ctype.h curses.h deflt.h demangle.h devid.h devmgmt.h devpoll.h dial.h dirent.h dlfcn.h door.h elf.h errno.h eti.h euc.h exacct.h exacct_impl.h exec_attr.h fatal.h fcntl.h float.h floatingpoint.h fmtmsg.h fnmatch.h form.h ftw.h gelf.h .. sys/xti_osi.h sys/xti_xtiopt.h sys/zsdev.h aio.h - aio.ph alloca.h - alloca.ph apptrace.h - apptrace.ph apptrace_impl.h - apptrace_impl.ph ar.h - ar.ph archives.h - archives.ph arm.h - arm.ph . assert.h - assert.ph auth_attr.h - auth_attr.ph bzlib.h - bzlib.ph cmqbc.h - cmqbc.ph Can't open cmqbc.h: No such file or directory cmqc.h - cmqc.ph Can't open cmqc.h: No such file or directory cmqcfc.h - cmqcfc.ph Can't open cmqcfc.h: No such file or directory cmqpsc.h - cmqpsc.ph Can't open cmqpsc.h: No such file or directory cmqxc.h - cmqxc.ph Can't open cmqxc.h: No such file or directory cmqzc.h - cmqzc.ph Can't open cmqzc.h: No such file or directory config_admin.h - config_admin.ph cpio.h - cpio.ph crypt.h - crypt.ph . sys/xti_inet.h - sys/xti_inet.ph sys/xti_osi.h - sys/xti_osi.ph sys/xti_xtiopt.h - sys/xti_xtiopt.ph sys/zsdev.h - sys/zsdev.ph + exit 1 error: Bad exit status from /export/apps/opkg/2.x/RPM/TMP/rpm-tmp.32719 (%install) [...] I tried manually running h2ph but it looks OK at first glance. --- # cd /usr/include # PERL5LIB=/export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/lib/perl # export PERL5LIB # /export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/bin/perl /export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/bin/h2ph -h -d /export/apps/opkg/2.x/RPM/TMP/perl-5.8.8-root/export/apps/opkg/2.x/lib/perl/5.8.8/sun4-sol aris sys/zsdev.h # echo $? 0 # --- Any ideas? If the error doesn't occur for you when you do it manually, I guess it is some sort of a permission problem. I guess you tried as root and the files cmq*.h are not readable by the management user under which the RPM package is rebuilt, right? BTW, on my Solaris 8 installation the cmq*.h files not even exists, so I cannot check the permissions issue myself. But I'm sure your files /usr/include/cmq*.h are not world-readable... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Perl (5.8.8-2.20061018) build prob on Solaris 8/SPARC
I was running as root, but su'd to my 'opkg' user ... But you're right about those files being problematic ... It looks like /usr/include/cmq*h were broken symlinks from an old MQ Series software install. So the key observation is that the error is actually the cumulative return code. I'm cleaning up and will try again. Thanks for your quick response! I'll let you know what happens. -- VK On Sun, 29 Oct 2006, Ralf S. Engelschall wrote: If the error doesn't occur for you when you do it manually, I guess it is some sort of a permission problem. I guess you tried as root and the files cmq*.h are not readable by the management user under which the RPM package is rebuilt, right? BTW, on my Solaris 8 installation the cmq*.h files not even exists, so I cannot check the permissions issue myself. But I'm sure your files /usr/include/cmq*.h are not world-readable... __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Perl (5.8.8-2.20061018) build prob on Solaris 8/SPARC
That fixed it. Thanks! On Sun, 29 Oct 2006, Vinod Kutty wrote: I'm cleaning up and will try again. Thanks for your quick response! I'll let you know what happens. __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: perl-time and DateTime?
On Mon, Oct 09, 2006, Adam D. Morley wrote: I believe perl-time now includes DateTime. This is cool. However, it doesn't seem to work: Can't locate DateTime/Locale.pm in @INC (@INC contains: /opt/openpkg/lib/perl/site_perl/5.8.8/sun4-solaris /opt/openpkg/lib/perl/site_perl/5.8.8 /opt/openpkg/lib/perl/site_perl /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris /opt/openpkg/lib/perl/vendor_perl/5.8.8 /opt/openpkg/lib/perl/vendor_perl/5.8.7/sun4-solaris /opt/openpkg/lib/perl/vendor_perl/5.8.7 /opt/openpkg/lib/perl/vendor_perl /opt/openpkg/lib/perl/5.8.8/sun4-solaris /opt/openpkg/lib/perl/5.8.8) at /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/DateTime.pm line 51. BEGIN failed--compilation aborted at /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/DateTime.pm line 51. Compilation failed in require at ./test.pl line 13. BEGIN failed--compilation aborted at ./test.pl line 13. Line 51 of DateTime.pm says: use DateTime::Locale; And: # find /opt/openpkg/ -name Locale* /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/Locale /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/Locale /opt/openpkg/lib/perl/vendor_perl/5.8.8/Locale /opt/openpkg/lib/perl/5.8.8/Locale I didn't see anything in the cvs logs that would indicate that this has been fixed in -current, but I might've missed something. Or I might've done something wrong completely. Although this is a little unusual for Perl modules on CPAN, it seems the DateTime module has DateTime::Locale as its dependency (not vice versa). I've added DateTime::Locale to perl-time in CURRENT and now this is fixed with perl-time-5.8.8-20061010 and higher. See http://cvs.openpkg.org/chngview?cn=30597 for details. Thanks for the hint. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
perl-time and DateTime?
Hi, I believe perl-time now includes DateTime. This is cool. However, it doesn't seem to work: Can't locate DateTime/Locale.pm in @INC (@INC contains: /opt/openpkg/lib/perl/site_perl/5.8.8/sun4-solaris /opt/openpkg/lib/perl/site_perl/5.8.8 /opt/openpkg/lib/perl/site_perl /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris /opt/openpkg/lib/perl/vendor_perl/5.8.8 /opt/openpkg/lib/perl/vendor_perl/5.8.7/sun4-solaris /opt/openpkg/lib/perl/vendor_perl/5.8.7 /opt/openpkg/lib/perl/vendor_perl /opt/openpkg/lib/perl/5.8.8/sun4-solaris /opt/openpkg/lib/perl/5.8.8) at /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/DateTime.pm line 51. BEGIN failed--compilation aborted at /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/DateTime.pm line 51. Compilation failed in require at ./test.pl line 13. BEGIN failed--compilation aborted at ./test.pl line 13. Line 51 of DateTime.pm says: use DateTime::Locale; And: # find /opt/openpkg/ -name Locale* /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/Locale /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/Locale /opt/openpkg/lib/perl/vendor_perl/5.8.8/Locale /opt/openpkg/lib/perl/5.8.8/Locale I didn't see anything in the cvs logs that would indicate that this has been fixed in -current, but I might've missed something. Or I might've done something wrong completely. Thanks, -- adam __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: perl-dbix 2.20060622 asks for input?
On Tue, Sep 19, 2006, Adam D. Morley wrote: On Tue, Sep 19, 2006 at 07:36:07AM +0200, Ralf S. Engelschall wrote: On Mon, Sep 18, 2006, Adam D. Morley wrote: So somewhere from the upgrade to 2.5 to 2.20060622, openpkg build seems to have missed the addition of sqlite as a requirement for perl-dbi. Likely because 2.5's perl-dbi has with_dbd_sqlite set to no, so the build script must not consider this possibility? Yes, seems like openpkg build has no possibility here. The default was no in 2.5 and is yes in 2.20060622. So, openpkg build thinks that the no in 2.5 was _manually_ set and correctly forward passes-through this value to the build of 2.20060622. There is real solution for this dependency-change-on-upgrade dilemma as RPM doesn't safe information whether an option was _explicitly_ set or not (and this way is set to the default). But I've now at least added the dependency perl-dbi::with_dbd_sqlite=yes to perl-dbix. Hmm. Does this mean an upgrade from 2.5 - 2.20060622 will now break when it sees perl-dbi installed with with_dbd_sqlite=no? Mostly, I'm just concerned about others upgrading from 2.5, as this is the one time I'll have to do it. Yes, seems like this is a nasty upgrade pitfall everyone can jump into. It at least hurts for those who used perl-dbix. But the solution is simple: one just has to _know_ to pass -Dwith_dbd_sqlite=yes on the openpkg build command when upgrading. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: perl-dbix 2.20060622 asks for input?
On Tue, Sep 19, 2006, Adam D. Morley wrote: [...] Ah. At least I know my perl-dbi is broken: This should now be also fixed in OpenPKG-CURRENT. Please take the latest and greatest perl-dbi from there in the meantime. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: perl-dbix 2.20060622 asks for input?
On Tue, Sep 19, 2006, Ralf S. Engelschall wrote: On Tue, Sep 19, 2006, Adam D. Morley wrote: ... Yes, seems like this is a nasty upgrade pitfall everyone can jump into. It at least hurts for those who used perl-dbix. But the solution is simple: one just has to _know_ to pass -Dwith_dbd_sqlite=yes on the openpkg build command when upgrading. See the rpmgetopts.pl script I just posted as it helps avoid problems like this by helpinb build an ~/.openpkg/build file with ALL the -D options for installed packages. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Systems, Inc. UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation. -- Johnny Hart __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: perl-dbix 2.20060622 asks for input?
On 9/19/06, Adam D. Morley [EMAIL PROTECTED] wrote: On Tue, Sep 19, 2006 at 08:10:49PM +0200, Ralf S. Engelschall wrote: On Tue, Sep 19, 2006, Adam D. Morley wrote: [...] Ah. At least I know my perl-dbi is broken: This should now be also fixed in OpenPKG-CURRENT. Please take the latest and greatest perl-dbi from there in the meantime. Ok. I grabbed perl-dbi-5.8.8-20060919.src.rpm from ftp.openpkg.org in current/SRC and built. I get: [root perl-dbi]# /opt/openpkg/bin/perl -e 'use DBI; use DBD::SQLite;' Can't load '/opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBD/SQLite/SQLite.so' for module DBD::SQLite: ld.so.1: perl: fatal: relocation error: file /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBD/SQLite/SQLite.so: symbol sqlite3_version: referenced symbol not found at /opt/openpkg/lib/perl/5.8.8/sun4-solaris/DynaLoader.pm line 230. I think you might need to rebuild/update the sqlite package first to fix this. -- Caleb Epstein __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: perl-dbix 2.20060622 asks for input?
On Tue, Sep 19, 2006, Adam D. Morley wrote: On Tue, Sep 19, 2006 at 08:10:49PM +0200, Ralf S. Engelschall wrote: On Tue, Sep 19, 2006, Adam D. Morley wrote: [...] Ah. At least I know my perl-dbi is broken: This should now be also fixed in OpenPKG-CURRENT. Please take the latest and greatest perl-dbi from there in the meantime. Ok. I grabbed perl-dbi-5.8.8-20060919.src.rpm from ftp.openpkg.org in current/SRC and built. I get: [root perl-dbi]# /opt/openpkg/bin/perl -e 'use DBI; use DBD::SQLite;' Can't load '/opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBD/SQLite/SQLite.so' for module DBD::SQLite: ld.so.1: perl: fatal: relocation error: file /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBD/SQLite/SQLite.so: symbol sqlite3_version: referenced symbol not found at /opt/openpkg/lib/perl/5.8.8/sun4-solaris/DynaLoader.pm line 230. at -e line 1 Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. But sqlite built fine (see attached log). Was there a second 0919 I was supposed to use, or do I need to upgrade perl-openpkg too? I did twiddle perl-dbi.spec so it wouldn't error on build: [...] /opt/openpkg/bin/cc -Wl,-E -G -L/opt/openpkg/lib SQLite.o dbdimp.o -o blib/arch/auto/DBD/SQLite/SQLite.so \ \ [...] Ops, for unknown reasons there is no -lsqlite3 at all on this line. Can you show me the output of the command $ /opt/openpkg/bin/pkg-config sqlite3 --libs on your side? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: perl-dbix 2.20060622 asks for input?
On Mon, Sep 18, 2006 at 02:56:34PM -0700, Adam D. Morley wrote:
On Mon, Sep 18, 2006 at 09:47:12PM +0200, Ralf S. Engelschall wrote:
On Mon, Sep 18, 2006, Adam D. Morley wrote:
I'm upgrading a 2.5 OpenPKG instance on Solaris 10 to 2.20060622.
Everything has gone fine so far, but when openpkg build tries to build
perl-dbix, it starts asking for input. First, it can't find the
MIRRORED.BY file, since it isn't detecting http_proxy from the
environment (see MIRRORED.BY.log). I'm guessing this is the same bug as
the RPM 4.4 bug?
If I manually download MIRRORED.BY to /opt/openpkg/.cpan/sources, I get
asked (in a loop) for where I am in the world (see locale.loop.log) by
CPAN's Config.pm.
Other perl packages have been built fine, so I'm wondering if I'm doing
something wrong, or if perl-dbix is the only one that uses CPAN. It
seems odd to use CPAN, but I don't know much about perl-dbix's source
rpm. Can building perl-dbix be made to not require user
input/configuration of CPAN? Or do I just need to configure CPAN
manually? If so, how do I get OpenPKG to tell me all the values it was
going to manually program CPAN with?
Thanks,
--
adam
/var/tmp/opkg/SRC/perl-dbix-5.8.8-2.20060622.src.rpm
Installing /var/tmp/opkg/SRC/perl-dbix-5.8.8-2.20060622.src.rpm
Executing(%prep): env -i /opt/openpkg/lib/openpkg/bash --norc --noprofile
--posix -e /opt/openpkg/RPM/TMP/rpm-tmp.12743
[...]
[Core Features]
- Test::More ...loaded. (0.62 = 0.52)
- DBD::SQLite...missing.
- DBI...loaded. (1.51)
- Want ...loaded. (0.10)
- Encode ...loaded. (2.18)
- Class::ReturnValue ...loaded. (0.53 = 0.4)
- Cache::MemoryCache ...loaded. (0)
- Clone ...loaded. (0.20)
== Auto-install the 1 mandatory module(s) from CPAN? [Y/n] y
[Lower case API]
[...]
OpenPKG packages never should download anything their own. The issue is
That's kind of what I expected, which is why I was surprised.
not related to RPM. It is just that the CPAN stuff detected that for
whatever obscure reasons DBD::SQLite is missing here. The perl-dbix
package depends on the perl-dbi package which in turn provides
DBD::SQLite by default. Please check your perl-dbi package. Either
it has build-option with_dbd_sqlite set to no (which is _NOT_ the
default) or something failed during building of DBD::SQLite in this
package. Just rebuild perl-dbi again and watch for errors.
[this is slightly rambly, as I was trying to figure out what's going on]
It does indeed have with_dbd_sqlite set to no. Here's the tail end of
the output of openpkg build -z -r /var/tmp/opkg perl-dbi
(/var/tmp/opkg is a local cache of ftp.openpkg.org, circa last Thursday
or so, since we're behind a proxy. without -r, the results are the
same):
echo /var/tmp/opkg/SRC/perl-dbi-5.8.8-2.20060622.src.rpm
/opt/openpkg/bin/openpkg rpm --define 'with_dbd_sqlite no' --rebuild
/var/tmp/opkg/SRC/perl-dbi-5.8.8-2.20060622.src.rpm || exit $?
/opt/openpkg/bin/openpkg rpm --force -Uvh
/opt/openpkg/RPM/PKG/perl-dbi-5.8.8-2.20060622.sparc64-solaris10-oop.rpm
|| exit $?
echo /var/tmp/opkg/SRC/perl-dbi-5.8.8-2.20060622.src.rpm = $?
The problem is: I built the package normally with 2.5. Further,
another system running the exact same version of OpenPKG that I'm
upgrading from reports the following from openpkg build -z perl-dbi:
echo
ftp://ftp.openpkg.org/release/2.5/SRC/perl-dbi-5.8.7-2.5.0.src.rpm
/opt/openpkg/bin/openpkg rpm --rebuild
ftp://ftp.openpkg.org/release/2.5/SRC/perl-dbi-5.8.7-2.5.0.src.rpm ||
exit $?
/opt/openpkg/bin/openpkg rpm --force -Uvh
/opt/openpkg/RPM/PKG/perl-dbi-5.8.7-2.5.0.sparc64-solaris10-oop.rpm ||
exit $?
echo
ftp://ftp.openpkg.org/release/2.5/SRC/perl-dbi-5.8.7-2.5.0.src.rpm = $?
So somewhere, the option got twiddled. I do know that the src rpm I
downloaded for 2.20060622 has the option set correctly at yes. But,
upon trying to manually build the package from the source rpm, I get:
[root perl-dbi]# openpkg rpm -bb perl-dbi.spec
error: Failed build dependencies:
sqlite is needed by perl-dbi-5.8.8-2.20060622
So somewhere from the upgrade to 2.5 to 2.20060622, openpkg build seems
to have missed the addition of sqlite as a requirement for perl-dbi.
Likely because 2.5's perl-dbi has with_dbd_sqlite set to no, so the
build script must not consider this possibility? I take it the best way
to reset the option is to manually build sqlite, then rebuild perl-dbi
manually, and then continue with the -ZaKB?
Ah. Even after I manually built gawk, sqlite, and perl-dbi, perl-dbix still
fails:
[Core Features]
- Test::More ...loaded. (0.62 = 0.52)
- DBD::SQLite...missing.
- DBI...loaded. (1.51)
- Want ...loaded. (0.10)
- Encode
Re: perl-dbix 2.20060622 asks for input?
On Mon, Sep 18, 2006 at 04:51:24PM -0700, Adam D. Morley wrote: On Mon, Sep 18, 2006 at 02:56:34PM -0700, Adam D. Morley wrote: So somewhere from the upgrade to 2.5 to 2.20060622, openpkg build seems to have missed the addition of sqlite as a requirement for perl-dbi. Likely because 2.5's perl-dbi has with_dbd_sqlite set to no, so the build script must not consider this possibility? I take it the best way to reset the option is to manually build sqlite, then rebuild perl-dbi manually, and then continue with the -ZaKB? Ah. Even after I manually built gawk, sqlite, and perl-dbi, perl-dbix still fails: [Core Features] - Test::More ...loaded. (0.62 = 0.52) - DBD::SQLite...missing. - DBI...loaded. (1.51) - Want ...loaded. (0.10) - Encode ...loaded. (2.18) - Class::ReturnValue ...loaded. (0.53 = 0.4) - Cache::MemoryCache ...loaded. (0) - Clone ...loaded. (0.20) == Auto-install the 1 mandatory module(s) from CPAN? [Y/n] y [Lower case API] - capitalization ...missing. (would need 0.03) == Auto-install the 1 optional module(s) from CPAN? [y/N] n [Schema generation] - DBIx::DBSchema ...loaded. (0.31) - Class::Accessor...loaded. (0.25) But it seems perl-dbi built SQLLite fine? (see attached) And openpkg This time, with attachment. build -z perl-dbi shows (after I rm the binary rpm): ... echo ftp://ftp.openpkg.org/stable/2.20060622/SRC/perl-dbi-5.8.8-2.20060622.src.rpm /opt/openpkg/bin/openpkg rpm --rebuild ftp://ftp.openpkg.org/stable/2.20060622/SRC/perl-dbi-5.8.8-2.20060622.src.rpm || exit $? /opt/openpkg/bin/openpkg rpm --force -Uvh /opt/openpkg/RPM/PKG/perl-dbi-5.8.8-2.20060622.sparc64-solaris10-oop.rpm || exit $? echo ftp://ftp.openpkg.org/stable/2.20060622/SRC/perl-dbi-5.8.8-2.20060622.src.rpm = $? I'm clearly doing something wrong here. Any ideas? -- adam __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org -- adam ... + /opt/openpkg/bin/perl-openpkg configure build install ++ OpenPKG perl-openpkg 2.0.1 (03-Dec-2004) ++ determined RPM program: /opt/openpkg/libexec/openpkg/rpm (4.2.1) ++ determined Perl program: /opt/openpkg/bin/perl (5.8.8) ++ step 2: configure ++ configuring module via ExtUtils::MakeMaker environment Checking installed SQLite version... SQLite version must be at least 3.1.3. No header file at that version or higher was found. Using the local version instead. Checking if your kit is complete... Looks good Multiple copies of Driver.xst found in: /opt/openpkg/RPM/TMP/perl-dbi-5.8.8-root/opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBI/ /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBI/ at ./Makefile.PL line 106 Using DBI 1.51 (for perl 5.008008 on sun4-solaris) installed in /opt/openpkg/RPM/TMP/perl-dbi-5.8.8-root/opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBI/ Writing Makefile for DBD::SQLite ++ step 3: build ++ building module via ExtUtils::MakeMaker environment cp lib/DBD/SQLite.pm blib/lib/DBD/SQLite.pm /opt/openpkg/RPM/TMP/adam-perl-openpkg-perl-dbi/perl.sh -p -e s/~DRIVER~/SQLite/g /opt/openpkg/RPM/TMP/perl-dbi-5.8.8-root/opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBI/Driver.xst SQLite.xsi /opt/openpkg/RPM/TMP/adam-perl-openpkg-perl-dbi/perl.sh /opt/openpkg/lib/perl/5.8.8/ExtUtils/xsubpp -typemap /opt/openpkg/lib/perl/5.8.8/ExtUtils/typemap SQLite.xs SQLite.xsc mv SQLite.xsc SQLite.c /opt/openpkg/bin/cc -c -I/opt/openpkg/include -I/opt/openpkg/RPM/TMP/perl-dbi-5.8.8-root/opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBI -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/openpkg/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV -O2 -DVERSION=\1.12\ -DXS_VERSION=\1.12\ -fPIC -I/opt/openpkg/lib/perl/5.8.8/sun4-solaris/CORE -DNDEBUG=1 -DSQLITE_PTR_SZ=4 -DHAVE_USLEEP=1 SQLite.c /opt/openpkg/bin/cc -c -I/opt/openpkg/include -I/opt/openpkg/RPM/TMP/perl-dbi-5.8.8-root/opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBI -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/openpkg/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV -O2 -DVERSION=\1.12\ -DXS_VERSION=\1.12\ -fPIC -I/opt/openpkg/lib/perl/5.8.8/sun4-solaris/CORE -DNDEBUG=1 -DSQLITE_PTR_SZ=4 -DHAVE_USLEEP=1 dbdimp.c Running Mkbootstrap for DBD::SQLite () chmod 644 SQLite.bs rm -f blib/arch/auto/DBD/SQLite/SQLite.so /opt/openpkg/bin/cc -Wl,-E -G -L/opt/openpkg/lib SQLite.o dbdimp.o -o blib/arch/auto/DBD/SQLite/SQLite.so \ -L/opt/openpkg/lib -lsqlite3 \ chmod 755 blib/arch/auto/DBD/SQLite/SQLite.so cp SQLite.bs blib/arch/auto/DBD/SQLite/SQLite.bs chmod 644 blib/arch/auto/DBD/SQLite/SQLite.bs
Re: perl-dbix 2.20060622 asks for input?
On Mon, Sep 18, 2006, Adam D. Morley wrote: [...] It does indeed have with_dbd_sqlite set to no. Here's the tail end of the output of openpkg build -z -r /var/tmp/opkg perl-dbi (/var/tmp/opkg is a local cache of ftp.openpkg.org, circa last Thursday or so, since we're behind a proxy. without -r, the results are the same): echo /var/tmp/opkg/SRC/perl-dbi-5.8.8-2.20060622.src.rpm /opt/openpkg/bin/openpkg rpm --define 'with_dbd_sqlite no' --rebuild /var/tmp/opkg/SRC/perl-dbi-5.8.8-2.20060622.src.rpm || exit $? /opt/openpkg/bin/openpkg rpm --force -Uvh /opt/openpkg/RPM/PKG/perl-dbi-5.8.8-2.20060622.sparc64-solaris10-oop.rpm || exit $? echo /var/tmp/opkg/SRC/perl-dbi-5.8.8-2.20060622.src.rpm = $? The problem is: I built the package normally with 2.5. Further, another system running the exact same version of OpenPKG that I'm upgrading from reports the following from openpkg build -z perl-dbi: echo ftp://ftp.openpkg.org/release/2.5/SRC/perl-dbi-5.8.7-2.5.0.src.rpm /opt/openpkg/bin/openpkg rpm --rebuild ftp://ftp.openpkg.org/release/2.5/SRC/perl-dbi-5.8.7-2.5.0.src.rpm || exit $? /opt/openpkg/bin/openpkg rpm --force -Uvh /opt/openpkg/RPM/PKG/perl-dbi-5.8.7-2.5.0.sparc64-solaris10-oop.rpm || exit $? echo ftp://ftp.openpkg.org/release/2.5/SRC/perl-dbi-5.8.7-2.5.0.src.rpm = $? So somewhere, the option got twiddled. I do know that the src rpm I downloaded for 2.20060622 has the option set correctly at yes. But, upon trying to manually build the package from the source rpm, I get: [root perl-dbi]# openpkg rpm -bb perl-dbi.spec error: Failed build dependencies: sqlite is needed by perl-dbi-5.8.8-2.20060622 So somewhere from the upgrade to 2.5 to 2.20060622, openpkg build seems to have missed the addition of sqlite as a requirement for perl-dbi. Likely because 2.5's perl-dbi has with_dbd_sqlite set to no, so the build script must not consider this possibility? Yes, seems like openpkg build has no possibility here. The default was no in 2.5 and is yes in 2.20060622. So, openpkg build thinks that the no in 2.5 was _manually_ set and correctly forward passes-through this value to the build of 2.20060622. There is real solution for this dependency-change-on-upgrade dilemma as RPM doesn't safe information whether an option was _explicitly_ set or not (and this way is set to the default). But I've now at least added the dependency perl-dbi::with_dbd_sqlite=yes to perl-dbix. I take it the best way to reset the option is to manually build sqlite, then rebuild perl-dbi manually, and then continue with the -ZaKB? [...] You can easily fix those situations with openpkg build -g -Dwith_dbd_sqlite=yes perl-dbi | sh as shown in the manual page which you can read via openpkg man build. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Perl-XML on Solaris 9
On Wed, Sep 13, 2006, Caleb Epstein wrote: On 9/13/06, Caleb Epstein [EMAIL PROTECTED] wrote: I'm unable to build this package on Solaris 10 due to weird UID/GID values in the WWW-Search tar file: Sorry, I guess this was perl-www, not perl-xml but the problem still stands. Openpkg's built-in tar doesn't appear to be able to handle the WWW-Search tarball. Solaris /bin/tar is fine with it. I think its a signed/unsigned integer issue: Yes, the value 4294967295 tar complains about is (2^32)-1. BSD tar, GNU tar and star all seem to at least _see_ that the WWW-Search-2.489.tar.gz tarball has some strange things in it. But I've no clue why Solaris tar happily displays 400/401 here. As the tarballs nevertheless unpack correctly (except for the user/group ownerships which are of no interest to us anyway) I've now applied two really ugly workarounds to resolve this issue: http://cvs.openpkg.org/chngview?cn=30041 Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Perl-XML on Solaris 9
Ralf S. Engelschall wrote: On Wed, Sep 13, 2006, Caleb Epstein wrote: On 9/13/06, Caleb Epstein [EMAIL PROTECTED] wrote: I'm unable to build this package on Solaris 10 due to weird UID/GID values in the WWW-Search tar file: Sorry, I guess this was perl-www, not perl-xml but the problem still stands. Openpkg's built-in tar doesn't appear to be able to handle the WWW-Search tarball. Solaris /bin/tar is fine with it. I think its a signed/unsigned integer issue: Yes, the value 4294967295 tar complains about is (2^32)-1. BSD tar, GNU tar and star all seem to at least _see_ that the WWW-Search-2.489.tar.gz tarball has some strange things in it. But I've no clue why Solaris tar happily displays 400/401 here. As the tarballs nevertheless unpack correctly (except for the user/group ownerships which are of no interest to us anyway) I've now applied two really ugly workarounds to resolve this issue: http://cvs.openpkg.org/chngview?cn=30041 Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org Ralph - the tar I removed was the separate rpm package, not the built-in one if that makes a difference. Doug __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Perl-XML on Solaris 9
On 9/12/06, Ralf S. Engelschall [EMAIL PROTECTED] wrote: On Mon, Sep 11, 2006, Doug Summers wrote: Getting this, although it's not consistent (built this fine on another system but in a different directory): + /openpkg/bin/perl-openpkg -d /openpkg/RPM/SRC/perl-xml/XML-RSS-Parser-4.0.tar.gz configure build install ++ OpenPKG perl-openpkg 2.0.1 (03-Dec-2004) ++ determined RPM program: /openpkg/libexec/openpkg/rpm (4.2.1) ++ determined Perl program: /openpkg/bin/perl (5.8.8) ++ step 2: configure ++ configuring module via ExtUtils::MakeMaker environment syntax error at ./Makefile.PL line 7, at EOF Execution of ./Makefile.PL aborted due to compilation errors. ++ step 3: build perl-openpkg:ERROR: neither Build nor Makefile found in working directory (No such file or directory) H I guess our tar was unable to correctly unpack the tarball of this module. Look at the beginning of the build procedure. I'm sure the problem is _there_. I'm unable to build this package on Solaris 10 due to weird UID/GID values in the WWW-Search tar file: [snip] + /openpkg/lib/openpkg/gzip -dc /openpkg/RPM/SRC/perl-www/WWW-Search-2.489.tar.gz + /openpkg/lib/openpkg/tar -xf - /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of uid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of gid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of uid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of gid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of uid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of gid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of uid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of gid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of uid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of gid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of uid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of gid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of uid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of gid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of uid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of gid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of uid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of gid_t range -2147483648.2147483647 /openpkg/lib/openpkg/tar: Archive value 4294967295 is out of uid_t range -2147483648.2147483647 [openpkg rpm bails out] I believe I reported this back in June with no effect. -- Caleb Epstein __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Perl-XML on Solaris 9
Ralf S. Engelschall wrote: On Mon, Sep 11, 2006, Doug Summers wrote: Getting this, although it's not consistent (built this fine on another system but in a different directory): + /openpkg/bin/perl-openpkg -d /openpkg/RPM/SRC/perl-xml/XML-RSS-Parser-4.0.tar.gz configure build install ++ OpenPKG perl-openpkg 2.0.1 (03-Dec-2004) ++ determined RPM program: /openpkg/libexec/openpkg/rpm (4.2.1) ++ determined Perl program: /openpkg/bin/perl (5.8.8) ++ step 2: configure ++ configuring module via ExtUtils::MakeMaker environment syntax error at ./Makefile.PL line 7, at EOF Execution of ./Makefile.PL aborted due to compilation errors. ++ step 3: build perl-openpkg:ERROR: neither Build nor Makefile found in working directory (No such file or directory) H I guess our tar was unable to correctly unpack the tarball of this module. Look at the beginning of the build procedure. I'm sure the problem is _there_. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org Good guess. I removed tar and perl-xml built fine. Doug __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Perl-XML on Solaris 9
On 9/13/06, Caleb Epstein [EMAIL PROTECTED] wrote: I'm unable to build this package on Solaris 10 due to weird UID/GID values in the WWW-Search tar file: Sorry, I guess this was perl-www, not perl-xml but the problem still stands. Openpkg's built-in tar doesn't appear to be able to handle the WWW-Search tarball. Solaris /bin/tar is fine with it. I think its a signed/unsigned integer issue: OpenPKG tar: [15:47] cae @ moma 524% gzip -dc WWW-Search-2.489.tar.gz|/openpkg/lib/openpkg/tar tvf -|head drwxrwxrwx Daddy/mkpasswd0 2006-07-30 23:27:05 WWW-Search-2.489/ -rwxrwxrwx / 659 2005-02-19 21:57:47 WWW-Search-2.489/AutoSearch.PL -rwxrwxrwx / 41085 2006-07-30 22:28:36 WWW-Search-2.489/Changes drwxrwxrwx Daddy/mkpasswd0 2006-07-30 23:27:05 WWW-Search-2.489/code/ -rwxrwxrwx / 69854 2006-04-22 09:48:39 WWW-Search-2.489/code/AutoSearch-code.pl -rwxrwxrwx / 12553 2005-01-15 23:20:21 WWW-Search-2.489/code/WebSearch-code.pl Solaris tar: [15:47] cae @ moma 525% gzip -dc WWW-Search-2.489.tar.gz|/bin/tar tvf -|head /openpkg/RPM/SRC/perl-www -rwxrwxrwx 400/401 0 Jul 30 23:27 2006 WWW-Search-2.489/ -rwxrwxrwx 400/401659 Feb 19 21:57 2005 WWW-Search-2.489/AutoSearch.PL -rwxrwxrwx 400/401 41085 Jul 30 22:28 2006 WWW-Search-2.489/Changes -rwxrwxrwx 400/401 0 Jul 30 23:27 2006 WWW-Search-2.489/code/ -rwxrwxrwx 400/401 69854 Apr 22 09:48 2006 WWW-Search-2.489/code/AutoSearch-code.pl -rwxrwxrwx 400/401 12553 Jan 15 23:20 2005 WWW-Search-2.489/code/WebSearch-code.pl -rwxrwxrwx 400/401 0 Jul 30 23:27 2006 WWW-Search-2.489/inc/ -rwxrwxrwx 400/401 0 Jul 30 23:27 2006 WWW-Search-2.489/inc/Module/ -rwxrwxrwx 400/401 0 Jul 30 23:27 2006 WWW-Search-2.489/inc/Module/Install/ -rwxrwxrwx 400/401 1123 Jul 30 23:26 2006 WWW-Search-2.489/inc/Module/Install/Base.pm -- Caleb Epstein __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Perl-XML on Solaris 9
On Mon, Sep 11, 2006, Doug Summers wrote: Getting this, although it's not consistent (built this fine on another system but in a different directory): + /openpkg/bin/perl-openpkg -d /openpkg/RPM/SRC/perl-xml/XML-RSS-Parser-4.0.tar.gz configure build install ++ OpenPKG perl-openpkg 2.0.1 (03-Dec-2004) ++ determined RPM program: /openpkg/libexec/openpkg/rpm (4.2.1) ++ determined Perl program: /openpkg/bin/perl (5.8.8) ++ step 2: configure ++ configuring module via ExtUtils::MakeMaker environment syntax error at ./Makefile.PL line 7, at EOF Execution of ./Makefile.PL aborted due to compilation errors. ++ step 3: build perl-openpkg:ERROR: neither Build nor Makefile found in working directory (No such file or directory) H I guess our tar was unable to correctly unpack the tarball of this module. Look at the beginning of the build procedure. I'm sure the problem is _there_. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
perl module man pages
Hello, all.
First, kudos on creating such a comprehensive system for portably
building and installing unix software. I've found it incredibly useful
for my day job, as well as for some personal projects at home. I can't
say enough good things about the system, as several of my friends and
coworkers will attest. :-)
Anyway...I'm in the process of writing spec files for various
applications I'm installing inside OpenPKG. One of the is a perl module
with a man page, for which I would like to have the man page installed.
I noticed that when I called Makefile.PL outside of OpenPKG, the man
page was created and installed properly, but when I installed via the
perl-openpkg script, the man page was not installed. After further
investigation, I think I have identified the reason:
a chunk of perl-openpkg:
--
# STEP: 4. install
if (grep { eq install } @steps_run) {
verbose(step 4: install);
# sanity check
if (not -f Makefile) {
die file \Makefile\ not found in working directory;
}
# determine make(1) command and flags
my = ;
=~ s|\n+$||s;
my = PERL= FULLPERL=;
# execute make(1)
runcmd( pure_install);
}
--
Perl-openpkg calls the 'pure_install' target instead of the 'install'
target, in the module's generated Makefile. As far as I can tell, the
only difference between these targets is that 'pure_install' does not
install documentation. This seems like it was a conscious decision...if
you don't mind, may I ask what the rationale was? Is this something
that should be changed in perl-openpkg, or is it better for me to
manually call pod2man in my spec file?
Thanks!
--
Larry Lansing
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: perl module man pages
Ralf S. Engelschall wrote: The reason simply is that with our myriad of Perl modules in the various perl-xxx packages the prefix/man/ area would be totally _flooded_ with _copies_ of files A-ha! I knew there must be a good reason. Well, I think we should keep perl-openpkg as is or at maximum add an option which allows it to use make install instead of make pure_install if wished. But unless we have more packages which need this option I think it would be best to simply run pod2man(1) in your *.spec file... Works for me. Thanks! -- Larry Lansing __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Strange Error Building Perl - Tru64 5.1
On Wed, Jan 04, 2006, Doug Summers wrote: Using the contributed Zen 2.1 binaries I was able to build the following packages for Tru64 5.1: openpkg-2.5.1-2.5.1 m4-1.4.3-2.5.0 binutils-2.16.1-2.5.0 make-3.80-2.5.0 libiconv-1.10-2.5.0 gcc-4.0.2-2.5.0 I'm stuck building perl (seems to be a major sticking point with the fringe OS's as I'm also stuck on HPUX for Itanium), getting the neverending message: (Feeding myself to /bin/sh to avoid Digital UNIX' ksh.) Any idea how to avoid this??? Seems that is is exec'ing itself again and again with the /bin/sh as it thinks it is running under /bin/ksh but on your platform /bin/sh is actually already KSH. The Perl Configure script has an explicit code for Tru64/OSF1 in line 128ff, including some strange $BIN_SH things. I don't know why this code doesn't work as expected on your Tru64 5.1, but as the code seems to be for a rather old OSF1 version (and Tru64 5.1 should no longer have such a broken KSH) I would just try to remove the whole lines 128-134 with a patch hunk and try again. Or even more precise: patch the if test X`/usr/bin/uname -s` = XOSF1; then to something like if test X`/usr/bin/uname -s` = XOSF1 test X`/usr/bin/uname -r` = X5.1; then. But check the output of your /usr/bin/uname -r first. If it works I can commit such a patch to the perl package. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Strange Error Building Perl - Tru64 5.1
Using the contributed Zen 2.1 binaries I was able to build the following packages for Tru64 5.1: openpkg-2.5.1-2.5.1 m4-1.4.3-2.5.0 binutils-2.16.1-2.5.0 make-3.80-2.5.0 libiconv-1.10-2.5.0 gcc-4.0.2-2.5.0 I'm stuck building perl (seems to be a major sticking point with the fringe OS's as I'm also stuck on HPUX for Itanium), getting the neverending message: (Feeding myself to /bin/sh to avoid Digital UNIX' ksh.) Any idea how to avoid this??? Doug __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Perl module
On Tue, Oct 25, 2005, Ralf S. Engelschall wrote: On Tue, Oct 25, 2005, Metromsi wrote: I have a quick question is the Module::Build available under openpkg? This is a new build method for creating perl modules. Since ExtUtils::MakeMaker is somewhat dated and CPAN has support for Module::Build. It is still not available. Mainly because it has some really nasty dependencies to other modules which currently would require to break our perl-xxx packaging layout. But I'm planning to add Module::Build, in the worst case into a perl-build package which just contains this module. Ok, I've today finally packaged Module::Build into a perl-module package of OpenPKG-CURRENT. Feel free to replace your manual installation with this package, but keep in mind that you also need the latest perl-openpkg package. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Perl module
I have a quick question is the Module::Build available under openpkg? This is a new build method for creating perl modules. Since ExtUtils::MakeMaker is somewhat dated and CPAN has support for Module::Build. Thanks
Re: Perl module
On Tue, Oct 25, 2005, Metromsi wrote: I have a quick question is the Module::Build available under openpkg? This is a new build method for creating perl modules. Since ExtUtils::MakeMaker is somewhat dated and CPAN has support for Module::Build. It is still not available. Mainly because it has some really nasty dependencies to other modules which currently would require to break our perl-xxx packaging layout. But I'm planning to add Module::Build, in the worst case into a perl-build package which just contains this module. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Perl module
That would be great to just have the perl-build module available. What time frame were you looking to do this? and would this module be (dev)? I really want to move away from ExtUtils::MakeMaker even the developer of the software suite does not want maintain it no more. http://www.makemaker.org/ * click on MakeMaker is DOOMED! really kind of silly why we want to continue to use MakeMaker any way just my $0.02 worth. I may volunteer an module for this and you could make modifications to it if you so desire. Thanks for a quick response.On 10/25/05, Ralf S. Engelschall [EMAIL PROTECTED] wrote: On Tue, Oct 25, 2005, Metromsi wrote: I have a quick question is the Module::Build available under openpkg? This is a new build method for creating perl modules. Since ExtUtils::MakeMaker is somewhat dated and CPAN has support for Module::Build.It is still not available. Mainly because it has some really nastydependencies to other modules which currently would require to breakour perl-xxx packaging layout. But I'm planning to add Module::Build, in the worst case into a perl-build package which just contains thismodule. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com__The OpenPKG Projectwww.openpkg.orgUser Communication Listopenpkg-users@openpkg.org
Re: perl-openpkg and perl.req ?
On Sun, Apr 10, 2005, Shawn Walker wrote: I had created my own spec file to build mod_perl 2 RC4, and everything worked in the build right until just after the three passes that happen at the end for cleanup and the like. rpmbuild exited with an error about not being able to find ~/lib/openpkg/perl.req, what is this file and how can I get it? Seems like you created either your .spec file from scratch or used a non-OpenPKG .spec as the base. The perl.req stuff is not used in OpenPKG, hence you need in the .spec file: AutoReq: no AutoReqProv: no I guess this is missing there. Please compare your .spec to the other over 850 .spec files in OpenPKG to better see what features of RPM we are using and which we aren't. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: perl-openpkg and perl.req ?
On Apr 10, 2005 11:36 AM, Ralf S. Engelschall [EMAIL PROTECTED] wrote:On Sun, Apr 10, 2005, Shawn Walker wrote: I had created my own spec file to build mod_perl 2 RC4, and everything worked in the build right until just after the three passes that happen at the end for cleanup and the like. rpmbuild exited with an error about not being able to find ~/lib/openpkg/perl.req, what is this file and how can I get it?Seems like you created either your .spec file from scratch or useda non-OpenPKG .spec as the base. The perl.req stuff is not used inOpenPKG, hence you need in the .spec file:AutoReq:noAutoReqProv:noI guess this is missing there. Please compare your .spec to the otherover 850 .spec files in OpenPKG to better see what features of RPM weare using and which we aren't. Oh, I've been comparing files, but it's not obvious which features work and which ones do not. There are only a few documented in the Handbook as being abandoned. Nevertheless... so that's what that's for. A lot of exising perl module .spec files use the AutoReq functionality, was there a specific reason that OpenPKG opted to not include this functionality? Not criticising, just wanting to understand... Thanks!-- Shawn Walker, Software and Systems Analyst[EMAIL PROTECTED] - http://binarycrusader.blogspot.com/
Re: perl-openpkg and perl.req ?
On Sun, Apr 10, 2005, Shawn Walker wrote: On Apr 10, 2005 11:36 AM, Ralf S. Engelschall [EMAIL PROTECTED] wrote: ... Oh, I've been comparing files, but it's not obvious which features work and which ones do not. There are only a few documented in the Handbook as being abandoned. Nevertheless... so that's what that's for. A lot of exising perl module .spec files use the AutoReq functionality, was there a specific reason that OpenPKG opted to not include this functionality? Not criticising, just wanting to understand... The AutoReq checking generally turns up dependencies on things like the system libc shared libraries, and possibly other things independent of the OpenPKG instance. This can result in dependency failures when attempting to install packages. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ It's very glamorous to raise millions of dollars, until it's time for the venture capitalist to suck your eyeballs out. -- Peter Kennedy, chairman of Kraft Kennedy. __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
perl-openpkg PRERIX is not supported
Hi
When we try to build a OpenPKG package for some perl modules, we get the
error Sorry, PREFIX is not supported.
How can we omit the PREFIX option. Or ist there another sulution.
Thanks
Enrico
.
.
+ /opt/local/opkg/bin/perl-openpkg -v -d
/opt/local/opkg/RPM/SRC/perl-datetime/Module-Build-0.2607.tar.gz
configure build install
++ OpenPKG perl-openpkg 2.0.0 (26-Jan-2004)
++ determined RPM program: /opt/local/opkg/libexec/openpkg/rpm (4.2.1)
++ determined Perl program: /opt/local/opkg/bin/perl (5.8.4)
++ step 2: configure
$ chmod -R u+rw Makefile.PL
$ cp Makefile.PL Makefile.PL.orig
$ sed -e
s:\$^X:'/opt/local/opkg/RPM/TMP/joe-perl-openpkg-perl-datetime/perl.sh':g
Makefile.PL.orig Makefile.PL
$ /opt/local/opkg/RPM/TMP/joe-perl-openpkg-perl-datetime/perl.sh
Makefile.PL
PERL=/opt/local/opkg/RPM/TMP/joe-perl-openpkg-perl-datetime/perl.sh
FULLPERL=/opt/local/opkg/RPM/TMP/joe-perl-openpkg-perl-datetime/perl.sh
INSTALLDIRS=vendor INSTALLMAN3DIR=none INSTALLSITEMAN3DIR=none
INSTALLVENDORMAN3DIR=none
DESTDIR=/opt/local/opkg/RPM/TMP/perl-datetime-5.8.4-root
PREFIX=/opt/local/opkg /dev/null
Sorry, PREFIX is not supported. See the Module::Build
documentation for 'destdir' or 'install_base' instead.
++ step 3: build
perl-openpkg:ERROR: file Makefile not found in working directory at
/opt/local/opkg/bin/perl-openpkg line 376.
(No such file or directory)
error: Bad exit status from /opt/local/opkg/RPM/TMP/rpm-tmp.30801 (%install)
RPM build errors:
Bad exit status from /opt/local/opkg/RPM/TMP/rpm-tmp.30801 (%install)
[EMAIL PROTECTED]
our spec file:
# package information
Name: perl-datetime
# list of sources
Source0:
http://search.cpan.org/CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-%{V_perl_module_build}.tar.gz
%prep
%setup -q -c
%setup -q -T -D -a 0
%build
%install
rm -rf $RPM_BUILD_ROOT
%{l_prefix}/bin/perl-openpkg prepare
%{l_prefix}/bin/perl-openpkg -d %{SOURCE0} configure build install
install
%{l_rpmtool} files -v -ofiles -r$RPM_BUILD_ROOT %{l_files_std} `cat
perl-openpkg-files`
%files -f files
%clean
rm -rf $RPM_BUILD_ROOT
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: perl-openpkg PRERIX is not supported
On Tue, Dec 21, 2004, Enrico John wrote: When we try to build a OpenPKG package for some perl modules, we get the error Sorry, PREFIX is not supported. How can we omit the PREFIX option. Or ist there another sulution. Your problem is that this module depends on Module::Build intead of ExtUtils::MakeMaker and perl-openpkg still does not support Module::Build. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Perl cmopiling on FedoraCore 2
On Fri, Oct 22, 2004, Georgy Goshin wrote: Now I can't check, I did't save the output but I started the procedure from root account, so it should not be permission problem.Maybe it could be cause because of not standart prefix used (/usr/local)? No, any filesystem prefix is equally ok for OpenPKG instances. All OpenPKG packages work equally well with an arbitrary prefix. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Perl cmopiling on FedoraCore 2
--On Donnerstag, Oktober 21, 2004 21:56:40 +0200 Ralf S. Engelschall [EMAIL PROTECTED] wrote: On Thu, Oct 21, 2004, Georgy Goshin wrote: Found alson one trouble with release 2.2 on Fedora Core 2, here is the result of compilation of perl: sys/vtimes.h - sys/vtimes.ph sys/wait.h - sys/wait.ph sys/xattr.h - sys/xattr.ph + exit 123 error: Bad exit status from /usr/local/RPM/TMP/rpm-tmp.94239 (%install) [...] What can cause this? This is because Perl's h2ph(1) seems to have failed. Isn't there a descriptive error message a few lines before the ones you tell us here? Perhaps something like permission denied (because a /usr/include header is not readable) or similar? I have seen this already on a Fedora Core 2 with OpenPkg 2.1, I also had contact with Thomas regarding this problem and he got some log's from me. I solved it for me locally by changing the spec file to ignore the error code (which is in generally not a good idea (TM) :-) ) cheerio Steve -- Steh auf wenn Du am Boden bist! Steh auf auch wenn Du unten liegst ! Steh auf, es wird schon irgendwie weitergeh'n. -- DtH, 2002 __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Perl cmopiling on FedoraCore 2
I resolved this by rebuilding the full instllation with /openpkg prefix and installed perl from the binary :) Steffen Weinreich [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] --On Donnerstag, Oktober 21, 2004 21:56:40 +0200 Ralf S. Engelschall [EMAIL PROTECTED] wrote: On Thu, Oct 21, 2004, Georgy Goshin wrote: Found alson one trouble with release 2.2 on Fedora Core 2, here is the result of compilation of perl: sys/vtimes.h - sys/vtimes.ph sys/wait.h - sys/wait.ph sys/xattr.h - sys/xattr.ph + exit 123 error: Bad exit status from /usr/local/RPM/TMP/rpm-tmp.94239 (%install) [...] What can cause this? This is because Perl's h2ph(1) seems to have failed. Isn't there a descriptive error message a few lines before the ones you tell us here? Perhaps something like permission denied (because a /usr/include header is not readable) or similar? I have seen this already on a Fedora Core 2 with OpenPkg 2.1, I also had contact with Thomas regarding this problem and he got some log's from me. I solved it for me locally by changing the spec file to ignore the error code (which is in generally not a good idea (TM) :-) ) cheerio Steve -- Steh auf wenn Du am Boden bist! Steh auf auch wenn Du unten liegst ! Steh auf, es wird schon irgendwie weitergeh'n. -- DtH, 2002 __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Perl cmopiling on FedoraCore 2
Hi, Found alson one trouble with release 2.2 on Fedora Core 2, here is the result of compilation of perl: sys/sysctl.h - sys/sysctl.ph sys/sysinfo.h - sys/sysinfo.ph sys/syslog.h - sys/syslog.ph sys/sysmacros.h - sys/sysmacros.ph sys/termios.h - sys/termios.ph sys/time.h - sys/time.ph sys/timeb.h - sys/timeb.ph sys/times.h - sys/times.ph sys/timex.h - sys/timex.ph sys/ttychars.h - sys/ttychars.ph sys/ttydefaults.h - sys/ttydefaults.ph sys/types.h - sys/types.ph sys/ucontext.h - sys/ucontext.ph sys/uio.h - sys/uio.ph sys/ultrasound.h - sys/ultrasound.ph sys/un.h - sys/un.ph sys/unistd.h - sys/unistd.ph sys/user.h - sys/user.ph sys/ustat.h - sys/ustat.ph sys/utsname.h - sys/utsname.ph sys/vfs.h - sys/vfs.ph sys/vlimit.h - sys/vlimit.ph sys/vm86.h - sys/vm86.ph sys/vt.h - sys/vt.ph sys/vtimes.h - sys/vtimes.ph sys/wait.h - sys/wait.ph sys/xattr.h - sys/xattr.ph + exit 123 error: Bad exit status from /usr/local/RPM/TMP/rpm-tmp.94239 (%install) RPM build errors: Bad exit status from /usr/local/RPM/TMP/rpm-tmp.94239 (%install) What can cause this? Georgy. __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Perl cmopiling on FedoraCore 2
On Thu, Oct 21, 2004, Georgy Goshin wrote: Found alson one trouble with release 2.2 on Fedora Core 2, here is the result of compilation of perl: sys/sysctl.h - sys/sysctl.ph sys/sysinfo.h - sys/sysinfo.ph sys/syslog.h - sys/syslog.ph sys/sysmacros.h - sys/sysmacros.ph sys/termios.h - sys/termios.ph sys/time.h - sys/time.ph sys/timeb.h - sys/timeb.ph sys/times.h - sys/times.ph sys/timex.h - sys/timex.ph sys/ttychars.h - sys/ttychars.ph sys/ttydefaults.h - sys/ttydefaults.ph sys/types.h - sys/types.ph sys/ucontext.h - sys/ucontext.ph sys/uio.h - sys/uio.ph sys/ultrasound.h - sys/ultrasound.ph sys/un.h - sys/un.ph sys/unistd.h - sys/unistd.ph sys/user.h - sys/user.ph sys/ustat.h - sys/ustat.ph sys/utsname.h - sys/utsname.ph sys/vfs.h - sys/vfs.ph sys/vlimit.h - sys/vlimit.ph sys/vm86.h - sys/vm86.ph sys/vt.h - sys/vt.ph sys/vtimes.h - sys/vtimes.ph sys/wait.h - sys/wait.ph sys/xattr.h - sys/xattr.ph + exit 123 error: Bad exit status from /usr/local/RPM/TMP/rpm-tmp.94239 (%install) [...] What can cause this? This is because Perl's h2ph(1) seems to have failed. Isn't there a descriptive error message a few lines before the ones you tell us here? Perhaps something like permission denied (because a /usr/include header is not readable) or similar? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Perl cmopiling on FedoraCore 2
Could you stop sending me the e-mails, please? Tried I few times to stop them but it is not working. Thanks in advance . . . . . . . . . . . . . On Thursday 21 October 2004 14:56, Ralf S. Engelschall wrote: On Thu, Oct 21, 2004, Georgy Goshin wrote: Found alson one trouble with release 2.2 on Fedora Core 2, here is the result of compilation of perl: sys/sysctl.h - sys/sysctl.ph sys/sysinfo.h - sys/sysinfo.ph sys/syslog.h - sys/syslog.ph sys/sysmacros.h - sys/sysmacros.ph sys/termios.h - sys/termios.ph sys/time.h - sys/time.ph sys/timeb.h - sys/timeb.ph sys/times.h - sys/times.ph sys/timex.h - sys/timex.ph sys/ttychars.h - sys/ttychars.ph sys/ttydefaults.h - sys/ttydefaults.ph sys/types.h - sys/types.ph sys/ucontext.h - sys/ucontext.ph sys/uio.h - sys/uio.ph sys/ultrasound.h - sys/ultrasound.ph sys/un.h - sys/un.ph sys/unistd.h - sys/unistd.ph sys/user.h - sys/user.ph sys/ustat.h - sys/ustat.ph sys/utsname.h - sys/utsname.ph sys/vfs.h - sys/vfs.ph sys/vlimit.h - sys/vlimit.ph sys/vm86.h - sys/vm86.ph sys/vt.h - sys/vt.ph sys/vtimes.h - sys/vtimes.ph sys/wait.h - sys/wait.ph sys/xattr.h - sys/xattr.ph + exit 123 error: Bad exit status from /usr/local/RPM/TMP/rpm-tmp.94239 (%install) [...] What can cause this? This is because Perl's h2ph(1) seems to have failed. Isn't there a descriptive error message a few lines before the ones you tell us here? Perhaps something like permission denied (because a /usr/include header is not readable) or similar? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED] -- Vriendelijke groeten, / Kind regards, Ruud Koendering, De Wickelaan 11, 2265 DG Leidschendam, Nederland / Netherlands T: +31(0)703271506, M: +31(0)641372381 , E: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Perl cmopiling on FedoraCore 2
Now I can't check, I did't save the output but I started the procedure from root account, so it should not be permission problem.Maybe it could be cause because of not standart prefix used (/usr/local)? Ralf S. Engelschall [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Thu, Oct 21, 2004, Georgy Goshin wrote: Found alson one trouble with release 2.2 on Fedora Core 2, here is the result of compilation of perl: __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
perl error in openpkg build -Ua
I'm suddenly getting a perl error executing openpkg build -Ua. I don't recall making any changes that might have caused this. I was playing w/ ImageMagick awhile back the last time I had some free time, but I only recall adding packages of all sorts, not removing any. Here is the error I'm getting: [EMAIL PROTECTED] openpkg build -Ua update.sh no element found at line 1, column 0, byte 0 at /cw/lib/perl/vendor_perl/5.8.4/i386-freebsd/XML/Parser.pm line 187 ...any help would be appreciated. Thanks, Frank __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: perl error in openpkg build -Ua
On Fri, Oct 15, 2004 at 02:18:17AM -0500, F. Even wrote: [EMAIL PROTECTED] openpkg build -Ua update.sh no element found at line 1, column 0, byte 0 at /cw/lib/perl/vendor_perl/5.8.4/i386-freebsd/XML/Parser.pm line 187 The XML parser cannot decode the index, probably because you cannot fetch it correctly (firewalls? NAT?) or because the index is defective. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] A potential Snark may lurk in every tree. __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: perl error in openpkg build -Ua
F. Even wrote: I'm suddenly getting a perl error executing openpkg build -Ua. I don't recall making any changes that might have caused this. I was playing w/ ImageMagick awhile back the last time I had some free time, but I only recall adding packages of all sorts, not removing any. Here is the error I'm getting: [EMAIL PROTECTED] openpkg build -Ua update.sh no element found at line 1, column 0, byte 0 at /cw/lib/perl/vendor_perl/5.8.4/i386-freebsd/XML/Parser.pm line 187 OKI've tried it a couple more timesand now it is suddenly working. Not sure I understand why...I have not changed anything. Could the error have come if ftp.openpkg.org was unavailable to me for some odd reason? That's the only thing I can think of. Thanks! __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: perl-net
On Thu, Oct 14, 2004, Ralf S. Engelschall wrote: On Thu, Oct 14, 2004, Aaron Bostick wrote: I would like to be able to use a cpan module called Net::Jabber but the perl-net src rpm does not provide for this particular. I realize there are tons of cpan Net modules, so I am wondering if the ones included with openpkg are chosen specifically or can new modules be added to the rpm on request? The spec file looks straightforward to modify. If the module looks reasonable programmed enough and doesn't have much external dependencies, we can easy add it, of course. I'll look at this if time permits. And if not, is it common practice to just install modules from the cpan shell. I know if I do it that way, those files will not be under rpm control. Any bad side effects from this? Since OpenPKG 2.0 you can use the CPAN shell for installing arbitrary modules yourself side-by-side to the packaged ones. Except that they are not known by RPM and this have to be upgraded manually, there are no known side-effects. Net::Jabber is now part of OpenPKG CURRENT's perl-net-5.8.5-20041015 and higher. It will not become part of OpenPKG 2.2 because the 2.2 brach is already frozen. But it will be part of OpenPKG 2.3, of course. In the meantime you have to use CURRENT if you need Net::Jabber. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
perl-net
I would like to be able to use a cpan module called Net::Jabber but the perl-net src rpm does not provide for this particular. I realize there are tons of cpan Net modules, so I am wondering if the ones included with openpkg are chosen specifically or can new modules be added to the rpm on request? The spec file looks straightforward to modify. And if not, is it common practice to just install modules from the cpan shell. I know if I do it that way, those files will not be under rpm control. Any bad side effects from this? Thanks, Aaron __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: perl-net
On Thu, Oct 14, 2004, Aaron Bostick wrote: I would like to be able to use a cpan module called Net::Jabber but the perl-net src rpm does not provide for this particular. I realize there are tons of cpan Net modules, so I am wondering if the ones included with openpkg are chosen specifically or can new modules be added to the rpm on request? The spec file looks straightforward to modify. If the module looks reasonable programmed enough and doesn't have much external dependencies, we can easy add it, of course. I'll look at this if time permits. And if not, is it common practice to just install modules from the cpan shell. I know if I do it that way, those files will not be under rpm control. Any bad side effects from this? Since OpenPKG 2.0 you can use the CPAN shell for installing arbitrary modules yourself side-by-side to the packaged ones. Except that they are not known by RPM and this have to be upgraded manually, there are no known side-effects. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Problem with the Perl package (Installing kolab2 (20040817))
--On Wednesday, August 25, 2004 08:42:07 +0200 Thomas Lotterer [EMAIL PROTECTED] wrote: On Wed, Aug 25, 2004, Martin Brodbeck wrote: Ah, you moved from the Kolab list. Welcome. I tried to install a kolab2 snapshot but there seems to be a problem with the openpkg perl package perl-5.8.4-2.1.0.src.rpm. Trying to rebuild the src.rpm I got the following error message. [...] I use Fedora Core 2. Does somebody know what the problem can be? FC2 is fully supported. Please build manually and send me the full log along with a /bin/rpm -qa and /kolab/bin/openpkg rpm -qa output so I better know your environment. $ /kolab/bin/openpkg rpm --rebuild /path/to/perl-5.8.4-2.1.0.src.rpm 21 | tee log I have the sane problem on my FC2 Workstation. It is a FC2 Fullinstall with all recent updates installed. Logfile is attached. cheerio Steve -- Steh auf wenn Du am Boden bist! Steh auf auch wenn Du unten liegst ! Steh auf, es wird schon irgendwie weitergeh'n. -- DtH, 2002 perl-build.log.gz Description: GNU Zip compressed data
Problem with the Perl package (Installing kolab2 (20040817))
Hello, I tried to install a kolab2 snapshot but there seems to be a problem with the openpkg perl package perl-5.8.4-2.1.0.src.rpm. Trying to rebuild the src.rpm I got the following error message. --- snip --- [...] sys/vt.h - sys/vt.ph sys/vtimes.h - sys/vtimes.ph sys/wait.h - sys/wait.ph sys/xattr.h - sys/xattr.ph + exit 123 error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.88159 (%install) RPM build errors: Bad exit status from /kolab/RPM/TMP/rpm-tmp.88159 (%install) --- snap --- I use Fedora Core 2. Does somebody know what the problem can be? Thanks Martin __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Problem with the Perl package (Installing kolab2 (20040817))
On Wed, Aug 25, 2004, Martin Brodbeck wrote: Ah, you moved from the Kolab list. Welcome. I tried to install a kolab2 snapshot but there seems to be a problem with the openpkg perl package perl-5.8.4-2.1.0.src.rpm. Trying to rebuild the src.rpm I got the following error message. [...] I use Fedora Core 2. Does somebody know what the problem can be? FC2 is fully supported. Please build manually and send me the full log along with a /bin/rpm -qa and /kolab/bin/openpkg rpm -qa output so I better know your environment. $ /kolab/bin/openpkg rpm --rebuild /path/to/perl-5.8.4-2.1.0.src.rpm 21 | tee log -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: OpenPKG perl and CPAN
On Tue, Aug 10, 2004, Alexander Belck wrote: I'm realy anewby with perl. The install instruction of the project I whant to run I'm asked to update perl with CPAN. The sequence I should do was: perl -MCPAN -eshell CPAN install MD5 CPAN install Bundle::CPAN While trying to do this with OpenPKG version of perl I got a recursive error: : : Writing /opkg/lib/perl/5.8.4/i686-linux/auto/Cwd/.packlist Appending installation info to /opkg/lib/perl/5.8.4/i686-linux/perllocal.pod /opkg/bin/make install -- OK Recursive dependency detected: Cwd = K/KW/KWILLIAMS/Cwd-2.20.tar.gz = File::Spec = K/KW/KWILLIAMS/File-Spec-0.88.tar.gz = Cwd. Cannot continue. Is this a perl::CPAN error or does I configured thanthing wrong in the 'perl -MCPAN -eshell` configuration that leads to this error ? At one step it asked for prefix I'm unshure how to set (used defaulte). Hmmm... I've never used the CPAN shell, because our perl-xxx packages contain mostly everything one needs. But to me it looks like a problem in this CPAN shell. Nevertheless, the MD5 stuff you should find in the OpenPKG perl-crypto package. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
OpenPKG perl and CPAN
I'm realy anewby with perl. The install instruction of the project I whant to run I'm asked to update perl with CPAN. The sequence I should do was: perl -MCPAN -eshell CPAN install MD5 CPAN install Bundle::CPAN While trying to do this with OpenPKG version of perl I got a recursive error: : : Writing /opkg/lib/perl/5.8.4/i686-linux/auto/Cwd/.packlist Appending installation info to /opkg/lib/perl/5.8.4/i686-linux/perllocal.pod /opkg/bin/make install -- OK Recursive dependency detected: Cwd = K/KW/KWILLIAMS/Cwd-2.20.tar.gz = File::Spec = K/KW/KWILLIAMS/File-Spec-0.88.tar.gz = Cwd. Cannot continue. Is this a perl::CPAN error or does I configured thanthing wrong in the 'perl -MCPAN -eshell` configuration that leads to this error ? At one step it asked for prefix I'm unshure how to set (used defaulte). Thanks, Alex -- ATIX Tecnologia e Com Ltda Tel.: +55-(11) 4667-5900 This message was sent using IMP, the Internet Messaging Program. __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Perl
On Thu, Aug 05, 2004, Bill Campbell wrote: On Thu, Aug 05, 2004, Alexander Belck wrote: Some perl scripts use #!/usr/bin/perl I recommend you replace that with /opkg/bin/perl. Could I just symlink ln -s /opkg/bin/perl /usr/bin/ ? I do not recommend replacing such a critical part of the OS with OpenPKG stuff. You must assume strange side effects. Last week I had to fix an application of mine which worked well with perl-5.8.3 but ran into a infinite loop with perl-5.8.4. It was neither a bug in the app nor in perl. It was just a subtle little intentional change in perls behavior where my code expected something else. Now imagine how badly you break many of you vendors maintenance scripts by replacing an ancient perl with the latest and greatest version. Do not even try. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Perl
I thought that being able to use the most up to date version of perl should avoid bug or security problems corrected in newer versions (while correct scripts should further run as the language syntax and standarts should not change). Yes, but it can also break existing scripts that depend on older versions of perl. You're far better off to leave the original perl alone, letting existing scripts use the version they expect. New things like ISPman can be built under the OpenPKG system where they will use the most current versions built in a consistent environment (not of of Red Hat's strong suits :-). So how should I make ISPman use the OpenPKG perl ? ISPman has about 100 perl scripts, constantly updating over cvs, and all start with: #!/usr/bin/perl Can you suggest me what to do ? Also, Ralf Engelschall replied to my environment saying thats OK just to run a OpenPKG binary giving the full path, so coult I just use #!/opkg/bin/perl ? I realy don't understant what is all done by /opkg/etc/rc --eval all env. I see that the PATH, LD_LIBRARY_PATH, MANPATH and INFOPATH are prepend with /opkg_paths, but don't know if other things are changed. Thanks again, Alex-- ATIX Tecnologia e Com Ltda Tel.: +55-(11) 4667-5900 This message was sent using IMP, the Internet Messaging Program. __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Perl
On Thu, Aug 05, 2004, Alexander Belck wrote: Some perl scripts use #!/usr/bin/perl Could I just symlink ln -s /opkg/bin/perl /usr/bin/ ? I've done this with links to /usr/local/bin/perl with reasonable success. Most of the systems we use already have /usr/bin/perl (e.g. they're Linux). If the perl script is executed by a user that DO NOT have previosly run /opkg/etc/rc --evall all env This depends on whether the perl scripts make system() calls that depend on the PATH that's set (and spelling --eval correctly :-). Most of the scripts I write check to see if the OpenPKG environment has been set, and if it hasn't, they set it explicitly. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ When only cops have guns, it's called a ``police state''. -- Claire Wolfe, 101 Things To Do Until The Revolution __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Perl
I'm using linux too (but relative old RH 7.3) and I thought using OpenPKG wersions of softwares would give me a longer updated live. If my thinking is correct, I would like to use OpenPKG version of perl and not the RH73 one. Could I write a small script that I name /usr/bin/perl with something like: #/bin/sh if [ OPKG-ENV_NOT_SET ]; then /opkg/etc/rc --eval all env fi /opkg/bin/perl $* Also I don't know how to check if OPKG_ENV_NOT_SET. Should grabing opkg in $PATH be enouth ? Thanks, Alex Citando Bill Campbell [EMAIL PROTECTED]: On Thu, Aug 05, 2004, Alexander Belck wrote: Some perl scripts use #!/usr/bin/perl Could I just symlink ln -s /opkg/bin/perl /usr/bin/ ? I've done this with links to /usr/local/bin/perl with reasonable success. Most of the systems we use already have /usr/bin/perl (e.g. they're Linux). If the perl script is executed by a user that DO NOT have previosly run /opkg/etc/rc --evall all env This depends on whether the perl scripts make system() calls that depend on the PATH that's set (and spelling --eval correctly :-). Most of the scripts I write check to see if the OpenPKG environment has been set, and if it hasn't, they set it explicitly. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ When only cops have guns, it's called a ``police state''. -- Claire Wolfe, 101 Things To Do Until The Revolution __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED] This message was sent using IMP, the Internet Messaging Program. __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Perl
I don´t understand your point (or expirience). For me, perl is just a interpretated programing languagues that is developed independent of RH, Suse,Conectiva... I whant to run ISPman, that use LDAP to hold ISP data and perl to mantain that information. This project doesn´t presume that perl comes from distr A, B or C (and I think that noone should do a propram in any language presuming that the interpreter/compiler has been bundled by A, B or C). I thought that being able to use the most up to date version of perl should avoid bug or security problems corrected in newer versions (while correct scripts should further run as the language syntax and standarts should not change). If I understand right you worries that some tasks of RH7.3 depends specificaly on his perl distribution and changing /usr/bin/perl could render to problems. Eaven I could not think where this can happen (I thought also I could upgrade perl from the developers site independent if RH upgrades), presuming this problems can happen with som script from RH, could I at least make the scripts from ISPman use OpenPKG perl ? If this sounds resonable could you point me out how to change the execution of the main ISPman script (that invokes all other) to corretly prepare the environment for OpenPKG ? Thanks, Alex Citando Bill Campbell [EMAIL PROTECTED]: On Thu, Aug 05, 2004, [EMAIL PROTECTED] wrote: I'm using linux too (but relative old RH 7.3) and I thought using OpenPKG wersions of softwares would give me a longer updated live. If my thinking is correct, I would like to use OpenPKG version of perl and not the RH73 one. That's probably a Bad Idea(tm) as RH 7.3 may well have things that depend on their particular version of perl and its associated modules. One of the major advantages of OpenPKG is that the OpenPKG instance(s) are independent of the vendor's underlying packaging system and other installed software. I have systems running OpenPKG Release 2.0 under Caldera eDesktop 2.4 which is about the same vintage as RH 7.3 with good results. Leave the RH stuff alone, and use OpenPKG for everthing else. Typically I set systems up so that root logins don't have the OpenPKG environment set by default to avoid problems with the vendor's maintenance scripts and updates. I have to manually execute a command that invokes the OpenPKG eval when logged in as root. This is less of a problem since OpenPKG Release 2.0 removed ``rpm'' from the PATH, but there are still potential problems if one has the OpenPKG executables in the PATH before the default system directories. Could I write a small script that I name /usr/bin/perl with something like: #/bin/sh if [ OPKG-ENV_NOT_SET ]; then /opkg/etc/rc --eval all env fi /opkg/bin/perl $* Also I don't know how to check if OPKG_ENV_NOT_SET. Should grabing opkg in $PATH be enouth ? Thanks, Alex Citando Bill Campbell [EMAIL PROTECTED]: On Thu, Aug 05, 2004, Alexander Belck wrote: Some perl scripts use #!/usr/bin/perl Could I just symlink ln -s /opkg/bin/perl /usr/bin/ ? I've done this with links to /usr/local/bin/perl with reasonable success. Most of the systems we use already have /usr/bin/perl (e.g. they're Linux). If the perl script is executed by a user that DO NOT have previosly run /opkg/etc/rc --evall all env This depends on whether the perl scripts make system() calls that depend on the PATH that's set (and spelling --eval correctly :-). Most of the scripts I write check to see if the OpenPKG environment has been set, and if it hasn't, they set it explicitly. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ When only cops have guns, it's called a ``police state''. -- Claire Wolfe, 101 Things To Do Until The Revolution __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED] This message was sent using IMP, the Internet Messaging Program. __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED] -- Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup
FYI: snmpdx issues (perl incompatiblity and dns probe)
Folks, there are two issues with the EVAL classified snmpdx package you should be aware of. INFINITE LOOP A compatiblity problem between snmpdx and perl. Problematic version combinations cause a infinite loop in snmpdx that consumes large amounts of CPU horsepower and fills the logging filesystem at a very fast rate as far as it will go. snmpdx perl = 0.2.8 = 5.8.3 ok = 0.2.8 = 5.8.4 problem = 0.2.9 5.8.x ok Please either - keep your old perl-5.8.3 or earlier version or - upgrade to snmdx-0.2.9 or later or - apply OSSP patch [1] for locally modified packages BIND PROBE Also note that today snmpdx-0.2.10 was released which adds a swBind probe for monitoring named(8). In order to get this new probe to work the statistics-file in named.conf(5) must be configured as shown in the CURRENT named package [2]. This is not the default case for any existing RELEASE. There are no plans for issuing an UPD bind package because a modified named.conf file will inadvertently create a named.conf.rpmsave and cause problems for people running automated update environments. [1] http://cvs.ossp.org/chngview?cn=4652 [2] http://cvs.openpkg.org/chngview?cn=18358 -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Build Failures in Perl modules
Hi! I've recently stubled two times over building perl packages where some linking fails but the RPM build process doesnt stop. One ist the perl-gd which will not link without the X11 Libs, and the other one is perl-dbi with Oracle Support when the build process doesnt fiddle out the Ora-Libs. It is a little bit annoying to find such an build error after the install of the Binary-RPM :-) For the perl-gd I have a logfile at hand... ftp://ftp.openpkg.org/current/SRC/perl-gd-5.8.3-20040318.src.rpm Installing ftp://ftp.openpkg.org/current/SRC/perl-gd-5.8.3-20040318.src.rpm Executing(%prep): env -i /opt/stw/lib/openpkg/bash --norc --noprofile --posix -e /opt/stw/RPM/TMP/rpm-tmp.72628 + cd /opt/stw/RPM/TMP + cd /opt/stw/RPM/TMP + rm -rf perl-gd-5.8.3 + /opt/stw/lib/openpkg/shtool mkdir -f -p -m 755 -p perl-gd-5.8.3 + cd perl-gd-5.8.3 + /opt/stw/lib/openpkg/gzip -dc /opt/stw/RPM/SRC/perl-gd/GD-2.12.tar.gz + /opt/stw/lib/openpkg/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd /opt/stw/RPM/TMP + cd perl-gd-5.8.3 + /opt/stw/lib/openpkg/gzip -dc /opt/stw/RPM/SRC/perl-gd/GDTextUtil-0.86.tar.gz + /opt/stw/lib/openpkg/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd /opt/stw/RPM/TMP + cd perl-gd-5.8.3 + /opt/stw/lib/openpkg/gzip -dc /opt/stw/RPM/SRC/perl-gd/GD-Barcode-1.14.tar.gz + /opt/stw/lib/openpkg/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd /opt/stw/RPM/TMP + cd perl-gd-5.8.3 + /opt/stw/lib/openpkg/gzip -dc /opt/stw/RPM/SRC/perl-gd/GDGraph-1.43.tar.gz + /opt/stw/lib/openpkg/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd /opt/stw/RPM/TMP + cd perl-gd-5.8.3 + /opt/stw/lib/openpkg/gzip -dc /opt/stw/RPM/SRC/perl-gd/GDGraph3d-0.56.tar.gz + /opt/stw/lib/openpkg/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd /opt/stw/RPM/TMP + cd perl-gd-5.8.3 + /opt/stw/lib/openpkg/gzip -dc /opt/stw/RPM/SRC/perl-gd/GDGraph-Map-1.05.tgz + /opt/stw/lib/openpkg/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd /opt/stw/RPM/TMP + cd perl-gd-5.8.3 + /opt/stw/lib/openpkg/gzip -dc /opt/stw/RPM/SRC/perl-gd/Chart-2.3.tar.gz + /opt/stw/lib/openpkg/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd /opt/stw/RPM/TMP + cd perl-gd-5.8.3 + /opt/stw/lib/openpkg/gzip -dc /opt/stw/RPM/SRC/perl-gd/Chart-ThreeD-0.01.tar.gz + /opt/stw/lib/openpkg/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd /opt/stw/RPM/TMP + cd perl-gd-5.8.3 + /opt/stw/lib/openpkg/gzip -dc /opt/stw/RPM/SRC/perl-gd/Chart-Plot-0.11.tar.gz + /opt/stw/lib/openpkg/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd /opt/stw/RPM/TMP + cd perl-gd-5.8.3 + /opt/stw/lib/openpkg/gzip -dc /opt/stw/RPM/SRC/perl-gd/Image-Timeline-0.11.tar.gz + /opt/stw/lib/openpkg/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + exit 0 Executing(%build): env -i /opt/stw/lib/openpkg/bash --norc --noprofile --posix -e /opt/stw/RPM/TMP/rpm-tmp.38005 + cd /opt/stw/RPM/TMP + cd perl-gd-5.8.3 + exit 0 Executing(%install): env -i /opt/stw/lib/openpkg/bash --norc --noprofile --posix -e /opt/stw/RPM/TMP/rpm-tmp.38005 + cd /opt/stw/RPM/TMP + cd perl-gd-5.8.3 + /opt/stw/bin/perl-openpkg prepare ++ OpenPKG perl-openpkg 2.0.0 (26-Jan-2004) ++ determined RPM program: /opt/stw/libexec/openpkg/rpm (4.2.1) ++ determined Perl program: /opt/stw/bin/perl (5.8.3) ++ step 1: prepare ++ cleaning up environment + /opt/stw/bin/perl-openpkg -d /opt/stw/RPM/SRC/perl-gd/GD-2.12.tar.gz configure build install ++ OpenPKG perl-openpkg 2.0.0 (26-Jan-2004) ++ determined RPM program: /opt/stw/libexec/openpkg/rpm (4.2.1) ++ determined Perl program: /opt/stw/bin/perl (5.8.3) ++ step 2: configure Where is libgd installed? [/usr/lib] /usr/lib Please choose the features that match how libgd was built: Build JPEG support? [y] y Build FreeType support? [y] y Build XPM support? [y] y If you experience compile problems, please check the @INC, @LIBPATH and @LIBS arrays defined in Makefile.PL and manually adjust, if necessary. Checking if your kit is complete... Looks good Writing Makefile for GD ++ step 3: build cp GD/Polyline.pm blib/lib/GD/Polyline.pm cp qd.pl blib/lib/qd.pl cp GD.pm blib/lib/GD.pm AutoSplitting blib/lib/GD.pm (blib/lib/auto/GD) /opt/stw/RPM/TMP/root-perl-openpkg-perl-gd/perl.sh /opt/stw/lib/perl/5.8.3/ExtUtils/xsubpp -typemap /opt/stw/lib/perl/5.8.3/ExtUtils/typemap -typemap typemap GD.xs GD.xsc mv GD.xsc GD.c /opt/stw/bin/cc -c -I/usr/local/include -I/usr/local/include/gd -fno-strict-aliasing -I/opt/stw/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -pipe -DVERSION=\2.12\ -DXS_VERSION=\2.12\ -fpic -I/opt/stw/lib/perl/5.8.3/i686-linux/CORE -DHAVE_JPEG -DHAVE_FT -DHAVE_XPM GD.c Running Mkbootstrap for GD () chmod 644 GD.bs rm -f blib/arch/auto/GD/GD.so LD_RUN_PATH=/usr/X11R6/lib /opt/stw/bin/cc -shared -L/opt/stw/lib GD.o -o blib/arch/auto/GD/GD.so -L/usr/lib/X11 -L/usr/X11R6/lib -L/usr/local/lib -lgd -lpng -lz -lfreetype -ljpeg -lm -lX11 -lXpm /opt/stw/bin/ld: cannot find -lX11 collect2: ld returned 1 exit status make: *** [blib/arch/auto/GD/GD.so] Error 1 ++ step 4: install Installing /opt/stw/RPM/TMP
Re: FSL and Perl
On Tue, Jan 20, 2004, Stephan Buys wrote: On Tuesday 20 January 2004 12:50, Thomas Lotterer wrote: On Tue, Jan 20, 2004, Stephan Buys wrote: Could you provide me with a short C program that would demostrate how to use FSL directly? I could then provide the Perl wrapper for that C code. The fsl tarball contains a fsl_test.c. It contains no fsl specific code! Why? Because fsl emulates syslog(2) API. To integrate fsl, see SYNOPSIS in the fsl.pod file. As I suspected, so I guess the challenge here is to get the Sys::Syslog module of Perl to also use fsl. I noticed that there were no options for the OpenPKG perl package to use fsl, maybe this is the right place to start? I would love to see a with_fsl option there but I was afraid implementing it would cause havoc to all perl modules so I kept my hands off. Go for it! -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
