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
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
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
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:
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
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
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
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
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: 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
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
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]
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]
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]
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: 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.
Re: perl-dbi / dbd:oracle
--On Thursday, November 06, 2003 14:20:43 +0100 Eike Lohmann [EMAIL PROTECTED] wrote: this seems to be the reason! /opt/ic3s/bin/perl: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped The main problem lies in the fact that with the 9.0.2 Oracle Client the 32bit libs has been moved to the directory lib32/. The DBD-Oracle seems not able to handle this without changes in the Makefile.PL, but due to my limited understanding of the Makefile.PL I wasn't able to fix this. Could somebody take a look at this issue? 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-dbi and Oracle
--On Thursday, September 11, 2003 00:44:23 +0200 Michael van Elst [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2003 at 11:06:38PM +0200, Steffen Weinreich wrote: Steffen, build the oracle package from the cvs. But this fails since there is no product directory in the Oracle Base directory of our Oracle 9.2 Client directory. here the oracle client installs under base_prefix/product/920/. Hmm, for now I havent done a OraClient install myself, I will have a look on this... The oracle meta package should detect an oracle installation correctly if you set the ORACLE_HOME environment variable. after removing the query for the product directory, I was able to build the package. Thinking this over and over again, I got the idea to include the complete client in an openpkg package. I'm not sure if this is a good idea but OTOS our colleagues haven't to thru the install process on every machine over and over again. Ary comments on this? cheerio Steve -- Space currenty for rent __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: perl ``locale'' on FreeBSD 4.8
On Sat, Aug 16, 2003 at 01:03:48PM -0700, Bill Campbell wrote: Running perl-5.8.0-1.3.0 on FreeBSD 4.8 STABLE, I frequently see a message from perl scripts saying that it can't find the ``locale'' program. It doens't seem to hurt anything, but is a bit annoying. Is there something simple that I'm missing here? I don't know about FreeBSD. But from my experience this points to the fact that the $LANG or $LC_*-variables are not defined in the environment or have a setting, that the localization functions do not recognize. Look, whether you have a man locale. I always set LC_ALL=C; export LC_ALL in shell scripts, for example, because this most of the time gives the expected results. (mk) -- Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47 Im prämotorischen Cortex kann jeder ein Held sein. (bdw) __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: perl 5.8 problem
Michael van Elst wrote: On Wed, Jun 18, 2003, julien Touche wrote: i'm trying to use cpan with perl 5.8 Apparently you mix different installations of perl. One is in /opt/sso. base install, sun Another is in /users/www/local. openpkg hierarchy Maybe you could clarify under what path you installed OpenPKG, wether you run the OpenPKG perl at all and where you look up perl modules (PERL5PATH comes to my mind). PATH is on good perl ok, it work with PERL5LIB=/users/www/local/lib/perl/5.8.0 sorry for the alert :) thanks __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: perl requires gcc at runtime?
On Tue, Feb 25, 2003, Ralf S. Engelschall wrote: On Tue, Feb 25, 2003, Andrews, Martin wrote: I notices that gcc is getting installed on all my machines because perl (perl-5.8.0-1.2.0) has gcc as a runtime dependency. Is that right? I've put this into the FAQ. http://www.openpkg.org/faq.html#perl-gcc -- [EMAIL PROTECTED] Development Team, Operations Northern Europe, Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: perl requires gcc at runtime?
On Tue, Feb 25, 2003, Andrews, Martin wrote: I notices that gcc is getting installed on all my machines because perl (perl-5.8.0-1.2.0) has gcc as a runtime dependency. Is that right? Unfortunately, yes. The point is that Perl modules with XS parts require _exactly_ the C compiler under build-time which was used at the built-time of Perl. The build-time of a module (usually in package perl-xxx) is the run-time of perl, hence the perl package requires under both build- and run-time to gcc. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
