Re: [pca] Date issue
Hi Stuart and Ken
Looks like a default date
$p{$id}{reldate}= 'Jan/01/71';
is now translated to 2071
it works here if I change to
$p{$id}{reldate}= 'Jan/01/75';
Best regards,
Marcel
Am 17.08.2022 um 16:49 schrieb Stuart Biggar:
[titan : /tank/patch : 5 ] ./pca -l missing
Using /var/tmp/patchdiag.xref from Aug/16/22
Host: titan (SunOS 5.10/Generic_153153-06/sparc/sun4u)
List: missing (0/0)
[titan : /tank/patch : 6 ] ./pca -l all
Using /var/tmp/patchdiag.xref from Aug/16/22
Cannot handle date (0, 0, 0, 01, 0, 2071) at ./pca line 2515
[titan : /tank/patch : 7 ]
I have never tried all before - I typically install using “missing”.
Stuart
On Aug 17, 2022, at 07:29, Marcel Hofstetter wrote:
Hi Stuart
and pca -l all works?
Am 17.08.2022 um 16:20 schrieb Stuart Biggar:
Seems to work on an ancient Solaris 10 SPARC system (with the built-in perl
version as far as I know):
[titan : /etc : 3 ] cat release
Solaris 10 8/07 s10s_u4wos_12b SPARC
Copyright 2007 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 16 August 2007
[titan : /etc : 4 ] cd /tank/patch
[titan : /tank/patch : 5 ] perl -v
This is perl, v5.8.4 built for sun4-solaris-64int
(with 47 registered patches, see perl -V for more detail)
Copyright 1987-2004, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.
[titan : /tank/patch : 6 ] ./pca -d missing
Using /var/tmp/patchdiag.xref from Aug/16/22
Host: titan (SunOS 5.10/Generic_153153-06/sparc/sun4u)
List: missing (0/0)
[titan : /tank/patch : 10 ] ./pca -v
pca 20190715-02
I used pca to update the system to the current level about 15 days ago. Worked
OK then and doesn’t find anything to download this morning. Granted this is a
really old SPARC system - we do have 11.4 on newer intel machines but don’t use
pca there.
Stuart
On Aug 17, 2022, at 07:09, Ken Harford wrote:
Thanks Marcel for the information. I guess the question is does it work for
Solaris 10 anymore? I don’t have the option of updating to Solaris 11.
Ken
On Aug 17, 2022, at 9:06 AM, Marcel Hofstetter wrote:
Hi Ken
I can confirm, we have the same problem on Solaris 10.
It works on Solaris 11 with newer perl version
-bash-5.1$ perl -v
This is perl 5, version 32, subversion 0 (v5.32.0) built for
sun4-solaris-thread-multi-64
Copyright 1987-2020, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
Best regards,
Marcel Hofstetter
JomaSoft GmbH
Am 16.08.2022 um 21:00 schrieb Ken Harford:
Addendum
I have updated perl to 5.10 and now this is what I receive as an error message:
Using /var/tmp/patchdiag.xref from Aug/15/22
Day too big - 36890 > 24853
Cannot handle date (0, 0, 0, 01, 0, 2071) at ./pca line 2511
perl -V
Summary of my perl5 (revision 5 version 10 subversion 1) configuration:
Platform:
osname=solaris, osvers=2.10, archname=i86pc-solaris
uname='sunos wdpv2vilv01 5.10 generic_150401-28 i86pc i386 i86pc '
config_args='-Dcc=gcc'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV',
optimize='-O',
cppflags='-fno-strict-aliasing -pipe -I/usr/local/include'
ccversion='', gccversion='3.4.6', gccosandvers='solaris2.10'
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib '
libpth=/usr/local/lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -ldl -lm -lc
perllibs=-lsocket -lnsl -ldl -lm -lc
libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_ve
Re: [pca] Date issue
Hi Stuart and pca -l all works? Am 17.08.2022 um 16:20 schrieb Stuart Biggar: Seems to work on an ancient Solaris 10 SPARC system (with the built-in perl version as far as I know): [titan : /etc : 3 ] cat release Solaris 10 8/07 s10s_u4wos_12b SPARC Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 16 August 2007 [titan : /etc : 4 ] cd /tank/patch [titan : /tank/patch : 5 ] perl -v This is perl, v5.8.4 built for sun4-solaris-64int (with 47 registered patches, see perl -V for more detail) Copyright 1987-2004, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. [titan : /tank/patch : 6 ] ./pca -d missing Using /var/tmp/patchdiag.xref from Aug/16/22 Host: titan (SunOS 5.10/Generic_153153-06/sparc/sun4u) List: missing (0/0) [titan : /tank/patch : 10 ] ./pca -v pca 20190715-02 I used pca to update the system to the current level about 15 days ago. Worked OK then and doesn’t find anything to download this morning. Granted this is a really old SPARC system - we do have 11.4 on newer intel machines but don’t use pca there. Stuart On Aug 17, 2022, at 07:09, Ken Harford wrote: Thanks Marcel for the information. I guess the question is does it work for Solaris 10 anymore? I don’t have the option of updating to Solaris 11. Ken On Aug 17, 2022, at 9:06 AM, Marcel Hofstetter wrote: Hi Ken I can confirm, we have the same problem on Solaris 10. It works on Solaris 11 with newer perl version -bash-5.1$ perl -v This is perl 5, version 32, subversion 0 (v5.32.0) built for sun4-solaris-thread-multi-64 Copyright 1987-2020, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. Best regards, Marcel Hofstetter JomaSoft GmbH Am 16.08.2022 um 21:00 schrieb Ken Harford: Addendum I have updated perl to 5.10 and now this is what I receive as an error message: Using /var/tmp/patchdiag.xref from Aug/15/22 Day too big - 36890 > 24853 Cannot handle date (0, 0, 0, 01, 0, 2071) at ./pca line 2511 perl -V Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: osname=solaris, osvers=2.10, archname=i86pc-solaris uname='sunos wdpv2vilv01 5.10 generic_150401-28 i86pc i386 i86pc ' config_args='-Dcc=gcc' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV', optimize='-O', cppflags='-fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.4.6', gccosandvers='solaris2.10' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib ' libpth=/usr/local/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP PERL_USE_SAFE_PUTENV USE_LARGE_FILES USE_PERLIO Built under solaris Compiled at Aug 16 2022 14:51:12 Ken On Aug 16, 2022, at 11:47 AM, Ken Harford wrote: Hi All, This already may have been addressed but I am new here When running "pca -l all” on Solaris 10 I get the following error: Using /var/tmp/patchdiag.xref from Aug/15/22 Cannot handle date (0, 0, 0, 01, 0, 2071) at ./pca line 2511 Has anybody else run into this? And if so is there a workaround? Thanks Ken
Re: [pca] Date issue
pca without options works here on s10. pca -l works here, too not sure what -l all means Am 17.08.2022 um 16:09 schrieb Ken Harford: Thanks Marcel for the information. I guess the question is does it work for Solaris 10 anymore? I don’t have the option of updating to Solaris 11. Ken On Aug 17, 2022, at 9:06 AM, Marcel Hofstetter wrote: Hi Ken I can confirm, we have the same problem on Solaris 10. It works on Solaris 11 with newer perl version -bash-5.1$ perl -v This is perl 5, version 32, subversion 0 (v5.32.0) built for sun4-solaris-thread-multi-64 Copyright 1987-2020, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. Best regards, Marcel Hofstetter JomaSoft GmbH Am 16.08.2022 um 21:00 schrieb Ken Harford: Addendum I have updated perl to 5.10 and now this is what I receive as an error message: Using /var/tmp/patchdiag.xref from Aug/15/22 Day too big - 36890 > 24853 Cannot handle date (0, 0, 0, 01, 0, 2071) at ./pca line 2511 perl -V Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: osname=solaris, osvers=2.10, archname=i86pc-solaris uname='sunos wdpv2vilv01 5.10 generic_150401-28 i86pc i386 i86pc ' config_args='-Dcc=gcc' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV', optimize='-O', cppflags='-fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.4.6', gccosandvers='solaris2.10' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib ' libpth=/usr/local/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP PERL_USE_SAFE_PUTENV USE_LARGE_FILES USE_PERLIO Built under solaris Compiled at Aug 16 2022 14:51:12 Ken On Aug 16, 2022, at 11:47 AM, Ken Harford wrote: Hi All, This already may have been addressed but I am new here When running "pca -l all” on Solaris 10 I get the following error: Using /var/tmp/patchdiag.xref from Aug/15/22 Cannot handle date (0, 0, 0, 01, 0, 2071) at ./pca line 2511 Has anybody else run into this? And if so is there a workaround? Thanks Ken
Re: [pca] Date issue
Hi Ken I can confirm, we have the same problem on Solaris 10. It works on Solaris 11 with newer perl version -bash-5.1$ perl -v This is perl 5, version 32, subversion 0 (v5.32.0) built for sun4-solaris-thread-multi-64 Copyright 1987-2020, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. Best regards, Marcel Hofstetter JomaSoft GmbH Am 16.08.2022 um 21:00 schrieb Ken Harford: Addendum I have updated perl to 5.10 and now this is what I receive as an error message: Using /var/tmp/patchdiag.xref from Aug/15/22 Day too big - 36890 > 24853 Cannot handle date (0, 0, 0, 01, 0, 2071) at ./pca line 2511 perl -V Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: osname=solaris, osvers=2.10, archname=i86pc-solaris uname='sunos wdpv2vilv01 5.10 generic_150401-28 i86pc i386 i86pc ' config_args='-Dcc=gcc' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV', optimize='-O', cppflags='-fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.4.6', gccosandvers='solaris2.10' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib ' libpth=/usr/local/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP PERL_USE_SAFE_PUTENV USE_LARGE_FILES USE_PERLIO Built under solaris Compiled at Aug 16 2022 14:51:12 Ken On Aug 16, 2022, at 11:47 AM, Ken Harford wrote: Hi All, This already may have been addressed but I am new here When running "pca -l all” on Solaris 10 I get the following error: Using /var/tmp/patchdiag.xref from Aug/15/22 Cannot handle date (0, 0, 0, 01, 0, 2071) at ./pca line 2511 Has anybody else run into this? And if so is there a workaround? Thanks Ken
Re: [pca] Download host name changed
Hi all Oracle stopped supporting smpatch which used getupdates.oracle.com. A few MOS Docs are already updated. updates.oracle.com is the new URL for patchdiag.xref and for patch download. Best regards, Marcel Hofstetter JomaSoft GmbH Am 14.12.2021 um 11:06 schrieb Martin Paul: Hi Jeff (and everybody still reading this), it’s been a long time since messages popped up on this mailing list :) I took a look, and it seems as if getupdates.oracle.com <http://getupdates.oracle.com> still exists, but the SSL certificate is invalid for that hostname: /usr/bin/wget --progress=dot:binary --ca-certificate=./pca -O /var/tmp/patchdiag.xref "https://getupdates.oracle.com/reports/patchdiag.xref <https://getupdates.oracle.com/reports/patchdiag.xref>" --2021-12-14 10:44:10-- https://getupdates.oracle.com/reports/patchdiag.xref <https://getupdates.oracle.com/reports/patchdiag.xref> Resolving getupdates.oracle.com <http://getupdates.oracle.com> (getupdates.oracle.com <http://getupdates.oracle.com>)... 104.96.155.106, 2a02:26f0:ea:48d::4425, 2a02:26f0:ea:486::4425 Connecting to getupdates.oracle.com <http://getupdates.oracle.com> (getupdates.oracle.com <http://getupdates.oracle.com>)|104.96.155.106|:443... connected. ERROR: no certificate subject alternative name matches requested host name 'getupdates.oracle.com <http://getupdates.oracle.com>'. To connect to getupdates.oracle.com <http://getupdates.oracle.com> insecurely, use `--no-check-certificate’. I looked at the certificate details of https://getupdates.oracle.com <https://getupdates.oracle.com> in the browser, and it seems as if the certificate is for peo-eas-esps-prod.oracle.com <http://peo-eas-esps-prod.oracle.com> and has a lot of alternative names (e.g. updates.oracle.com <http://updates.oracle.com>), but getupdates.oracle.com <http://getupdates.oracle.com> is missing in this list, and the certificate is therefore not valid for that hostname. Unfortunately Don O’Malley doesn’t seem to work for Oracle anymore, but back in 2018 he told me about two other guys working for the patch team. I contacted them, let’s see if they can get the certficate fixed so PCA would work out of the box again. Until then, everybody still using PCA can use Jeff’s workaround. Best, Martin. Am 10.12.2021 um 16:59 schrieb Jeff Wieland <mailto:wiel...@purdue.edu>>: The hostname for downloading patchdiag.xref appears to have changed from getupdates.oracle.com <http://getupdates.oracle.com> to updates.oracle.com <http://updates.oracle.com>. Of course you can fix this by adding the following to your .pca file: ohost=updates.oracle.com <http://updates.oracle.com> -- Jeff Wieland, UNIX Systems Administrator Purdue University IT Infrastructure Services UNIX Platforms
Re: [pca] Missing sconadm on Solaris 10 1/13
Hi Martin > Check out Oracle Support Document 1528698.1 (How to register smpatch on > Solaris 10 1/13): > > https://support.oracle.com/epmos/faces/DocumentDisplay?id=1528698.1 > > "As sconadm has been removed in Solaris 10 1/13 and there unfortunately > is no working replacement at the moment, this document offers a > workaround how to get Solaris 10 1/13 registered to be able to use > smpatch." > > So there's no out-of-the-box working patch tool in Solaris 10 1/13. On > the other hand - was there ever any? :) You typically only register one system and then use the patchsvr there. No need to register all systems ... ;) Best regards, Marcel
