<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.os.solaris.pca">
    <title>gmane.os.solaris.pca</title>
    <link>http://blog.gmane.org/gmane.os.solaris.pca</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3121"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3118"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3116"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3113"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3110"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3091"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3088"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3083"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3080"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3078"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3072"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3067"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3057"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3053"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3051"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3050"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3043"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3035"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3032"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.pca/3031"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3121">
    <title>New release: 20130502-01</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3121</link>
    <description>&lt;pre&gt;A new release of PCA has just been published. Here's a list of new 
features and changes:

  * Do not pass on Recommended flag with --minimal option
  * Correct patch obsoletions from installed patches with --minimal option
  * Fix rare bug of certain patches not showing up with --minimal option
  * Remove link to patch README on wesunsolve.net in HTML output
  * Temporary workaround for problem with Oracle server and wget from 
OpenCSW
  * Whitelist: add 147143, 147144
  * Whitelist: add 147147, 148148, 148027, 148028
  * Whitelist: add 149173, 149174, 149175, 149176
  * Apply check: add 147416, 147419

Update:
   pca --update now

Download:
   http://www.par.univie.ac.at/solaris/pca/installation.html

MD5: 70c76b041938d4d57ba7f529a783011b


&lt;/pre&gt;</description>
    <dc:creator>Martin Paul</dc:creator>
    <dc:date>2013-05-02T09:22:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3118">
    <title>PCA selects SPARC patch on X86</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3118</link>
    <description>&lt;pre&gt;After installing the Solaris 10 CPU_2013-04 on an X4500 I ran pca -list missingrs.  Patch 147416-02 was listed as missing but the x86 version is 147419-02 is installed.

I do not recall seeing this in the past but I do not patch this server often.

I found the following details:

grep 14741 /var/tmp/patchdiag.xref
147416|02|Dec/03/12| |S| |  |Unbundled|all;sparc;|SUNWsefms:6.9.0,REV=2011.11.13.21.31.38;SUNWstkraidsa:6.9.0,REV=2011.11.13.21.31.44;SUNWse6130ui:6.9.0,REV=2011.11.13.21.32.51;SUNWsesscs:6.9.0,REV=2011.11.13.21.32.51;SUNWstkcamcd:6.9.0,REV=2011.11.13.21.32.51;140064-01;140064-02;140064-03;|SunOS 5.9 5.10 CAM 6.9.0 bug fixes.
147417|02|Dec/03/12| |S| |  |Unbundled|||Windows CAM 6.9.0 bug fixes.
147418|02|Dec/04/12| |S| |  |Unbundled|||Linux RHEL SuSE CAM 6.9.0 bug fixes.
147419|02|Dec/03/12| |S| |  |Unbundled|all;i386;|SUNWsefms:6.9.0,REV=2011.11.13.21.31.38;SUNWstkraidsa:6.9.0,REV=2011.11.13.21.31.44;SUNWse6130ui:6.9.0,REV=2011.11.13.21.32.51;SUNWsesscs:6.9.0,REV=2011.11.13.21.42.41;SUNWstkcamcd:6.9.0,REV=2011.11.13.21.32.51;140064-01;140064-02;140064-03;|SunOS 5.10_x86 CAM 6.9.0 bug fixes.

/var/tmp/pca --list 147416 147419 --root="/.alt.s10u10CPU_2013-04" --patchdir="/var/tmp/pcatmp"
Using /var/tmp/patchdiag.xref from Apr/24/13
Host: beaker (SunOS 5.10/Generic_147441-19/i386/i86pc)
Root: /.alt.s10u10CPU_2013-04
List: 147416 147419 (2/286)

Patch  IR   CR RSB Age Synopsis
------ -- - -- --- --- -------------------------------------------------------
147416 -- &amp;lt; 02 -S- 143 SunOS 5.9 5.10 CAM 6.9.0 bug fixes.
147419 02 = 02 -S- 143 SunOS 5.10_x86 CAM 6.9.0 bug fixes.

/var/tmp/pca --list missingrs --root="/.alt.s10u10CPU_2013-04" --patchdir="/var/tmp/pcatmp" | grep 14741
147416 -- &amp;lt; 02 -S- 143 SunOS 5.9 5.10 CAM 6.9.0 bug fixes.

/var/tmp/pca --version
pca 20120829-01




Glen Gunselman
Systems Software Specialist
Information Technology
Emporia State University
1200 Commerical St
Emporia Kansas 66801

&lt;/pre&gt;</description>
    <dc:creator>Glen Gunselman</dc:creator>
    <dc:date>2013-04-25T21:36:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3116">
    <title>Oracle webserver has an SSL bug -&gt; incompatible with OpenSSL1.0</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3116</link>
    <description>&lt;pre&gt;Hello all,

An heads up:

If you have installed OpenCSW's wget, you might have noticed that for a 
few days, PCA is not working anymore, it cannot download the 
patchdiag.xref file.

This has been analyzed as an issue on the Oracle server side, which 
makes it incompatible with OpenSSL 1.0:

http://lists.opencsw.org/pipermail/users/2013-April/009568.html

https://www.opencsw.org/mantis/view.php?id=5068

A ticket has been open with Oracle, but well, if somebody here has 
faster access to get it fixed, that'd be nice.

Martin, there is a workaround in the first link that you might consider 
to include in PCA when using OpenCSW's wget.

Laurent


&lt;/pre&gt;</description>
    <dc:creator>Laurent Blume</dc:creator>
    <dc:date>2013-04-25T07:47:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3113">
    <title>Query regarding patches currently running</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3113</link>
    <description>&lt;pre&gt;Hi;

While I haven't run into the problem with SUNWastfb - I am encountering
another issue that I haven't seen before.

First, I think I remember seeing that PCA can patch OBP/POST ~
ILOM/ALOM/ELOM. Not sure if that's right (remember I think I saw) &amp;lt;g&amp;gt;

Anyway, I'm using patchdiag.xref from Mar/18/13.

For the systems I have that are listing themselves as downrev (OBP/POST ~
ILOM/ALOM/ELOM) I'm finding that the ILOM's are freezing during the
patching process.

Since I background PCA and reboot later, it might be a few days before ILOM
service is restored. The only other thought I have is that a full power off
/ on may be required to restore them. Any ideas here (I haven't seen this
behaviour before).

Also, I'm seeing with the S10_u11 update that you can't fully update a
system with running zones. There are workarounds I can use, but I'm curious
if the above could be related.

Thanks,


Drew.
&lt;/pre&gt;</description>
    <dc:creator>Drew Skinner</dc:creator>
    <dc:date>2013-04-19T15:33:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3110">
    <title>"Bad patch installed" and "does not match"</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3110</link>
    <description>&lt;pre&gt;Two questions regarding pca output and patches as of today.

pca in verbose mode says today:
------------
osname from uname: SunOS
Reading from /usr/bin/showrev -p  2&amp;gt;/dev/null
patchdiag.xref size: 2303118
Using /var/tmp/patchdiag.xref from Apr/11/13
*Bad patch installed: 144560-04*
SUNWswmt patches: 108987 108988 110763 112951 114194 119254 119255
120201-04 required by 125719: already installed
*142373-03 required by 125719*
*142373-03 required by 125719: does not match*
144500-19 required by 125719: already installed
Host: sb2000 (SunOS 5.10/Generic_148888-02/sparc/sun4u)
List: missing (1/1)

Patch  IR   CR RSB Age Synopsis
------ -- - -- --- --- 
-------------------------------------------------------
125719 48 &amp;lt; 49 RS-   1 X11 6.8.0: Xorg server patch

Looking for 125719-49 (1/1)
Found patch file
------------------------------------------------------------------------------
Download Summary: 1 total, 0 successful, 1 skipped, 0 failed


Trying to get rid of the "Bad patch" I get

root&amp;lt; at &amp;gt;sb2000:/  patchrm 144560-04

...

The following requested patches will not be removed because
they have been made obsolete by other patches already
installed on the system

            0 Patch 144560-04 is obsoleted by 147147-26, which has 
already been installed on the system. It should be removed first.

Is it correct, that 144560-04 is listed as bad patch?
How should I deal with this situation? Remove 147147-26 then 144560-04 
and then reapply 147147-26 again?



root&amp;lt; at &amp;gt;sb2000:/home/langfr/Patches ksh pca -in
Using /var/tmp/patchdiag.xref from Apr/11/13
Host: sb2000 (SunOS 5.10/Generic_148888-02/sparc/sun4u)
List: missing (1/1)

Patch  IR   CR RSB Age Synopsis
------ -- - -- --- --- 
-------------------------------------------------------
125719 48 &amp;lt; 49 RS-   1 X11 6.8.0: Xorg server patch

Looking for 125719-49 (1/1)
Found patch file

Installing 125719-49 (1/1)
Unzipping patch
Running patchadd

....

The following requested patches will not be installed because
at least one required patch is not installed on this system.

            0 For patch 125719-49, required patch 142373-03 does not exist.

The missing patch is in patchdiag.ref
142373|03|Apr/11/13| | | | 
|10|sparc;|SUNWastfb:10.0.0,REV=2009.02.20;SUNWastfbcf:10.0.0,REV=2009.02.26;|SunOS 
5.10: AST Graphics Patch

What does "does not match" mean?



&lt;/pre&gt;</description>
    <dc:creator>Frank Langelage</dc:creator>
    <dc:date>2013-04-12T18:38:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3091">
    <title>patch 118666-42 fails on sparse root zones</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3091</link>
    <description>&lt;pre&gt;When I patch my global zone with 118666-42, it installs OK in the global zone, then it installs OK when it does the whole root zones.
But, when there are sparse root zones, where the /usr partition is inherited from the global zone, it fails due to read-only file system.
The good news is that despite the failure, and the subsequent back-out of the partial patch, when I run "java -version" it stills sees the "new" version because its inheriting the patched version from the global zone.

My concern here is that errors show up in the PCA install log (for the failed patch) and the reports that show missing patches (pca -l) make it look like there is a missing patch. Auditors don't like this. Clearly, the patch isn't truly missing if the patched version is installed and runnable as shown below.

This looks like a bug in the patch itself causing it to not handle sparse zones in a user friendly way. Note that the three other Java patches do not have this issue.  I don't think there is a problem with PCA itself; its simply reporting the errors that patchadd is reporting back.

$ /usr/jdk/jdk1.5.0_40/bin/java -version
java version "1.5.0_40"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_40-b02)
Java HotSpot(TM) Server VM (build 1.5.0_40-b02, mixed mode)

$ ../pca -l --minimal missingr
Using /var/tmp/patchdiag.xref from Mar/03/13
Host: V210_sparse_zone (SunOS 5.10/Generic_147147-26/sparc/sun4u)
List: missingr-minimal (1/14)

Patch  IR   CR RSB Age Synopsis
------ -- - -- --- --- -------------------------------------------------------
118666 38 &amp;lt; 42 RS-  14 JavaSE 5.0: update 40 patch (equivalent to JDK 5.0u40)

$ more /var/tmp/118666-42.log.11833
...
rm: /a/usr/jdk/jdk1.5.0_40 not removed: Read-only file system
rm: /a/usr/jdk/jdk1.5.0_40 not removed: Read-only file system
ln: cannot create /a/usr/jdk/jdk1.5.0_40/jdk1.5.0: Read-only file system
ln: cannot create /a/usr/java/jdk1.5.0_40: Read-only file system
ln: cannot create /a/usr/bin/javaws: Read-only file system
/a/var/sadm/pkg/SUNWj5rt/install/postinstall: /a/usr/share/control-center-2.0/ca
pplets/sun_java.desktop: cannot create
chmod: WARNING: can't change /a/usr/share/control-center-2.0/capplets/sun_java.d
esktop
chown: /a/usr/share/control-center-2.0/capplets/sun_java.desktop: Read-only file
system
chgrp: /a/usr/share/control-center-2.0/capplets/sun_java.desktop: Read-only file
system
cp: cannot create /a/usr/share/pixmaps/sun-java.png: Read-only file system
cp: cannot create /a/usr/share/icons/HighContrast/48x48/apps/sun-java.png: Read-
only file system
cp: cannot create /a/usr/share/icons/HighContrastInverse/48x48/apps/sun-java.png
: Read-only file system
cp: cannot create /a/usr/share/icons/LowContrast/48x48/apps/sun-java.png: Read-o
nly file system
/a/var/sadm/pkg/SUNWj5rt/install/postinstall: /a/usr/share/gnome/mime-info/java-
archive.keys: cannot create
pkgadd: ERROR: postinstall script did not complete successfully

Installation of &amp;lt;SUNWj5rt&amp;gt; failed.

Neil G. Brookins
Identity and Authentication Solutions - IT Global Solutions
Towers Watson
1500 Market Street | Philadelphia, PA 19102
Phone: +1 215 246 6046
neil.brookins&amp;lt; at &amp;gt;towerswatson.com&amp;lt;mailto:neil.brookins&amp;lt; at &amp;gt;towerswatson.com&amp;gt;

Notice of Confidentiality
This transmission contains information that may be confidential. It has been prepared for the sole and exclusive use of the intended recipient and on the basis agreed with that person. If you are not the intended recipient of the message (or authorized to receive it for the intended recipient), you should notify us immediately; you should delete it from your system and may not disclose its contents to anyone else.


This e-mail has come to you from Towers Watson Delaware Inc.
&lt;/pre&gt;</description>
    <dc:creator>Brookins, Neil (Philadelphia</dc:creator>
    <dc:date>2013-03-04T14:57:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3088">
    <title>pca recommends non-recommended patch</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3088</link>
    <description>&lt;pre&gt;I have a newly installed Solaris 10 U11 host.  I patched it a couple days ago with "pca --minimal missingr"
Today, when I run "pca -l --minimal missingr" using the new xref it says:

Using /var/tmp/patchdiag.xref from Feb/28/13
Host: T2000_hostname (SunOS 5.10/Generic_147147-26/sparc/sun4v)
List: missingr-minimal (1/1)

Patch  IR   CR RSB Age Synopsis
------ -- - -- --- --- -------------------------------------------------------
148338 -- &amp;lt; 03 R--   1 SunOS 5.10: s9_brand patch

The host has 148161-02 installed because it's in the U11 release.

Here is the trace of the patch obsolescence in order,
starting from the current recommended through the newest:
139944-01 has the "R" flag.             It was obsoleted by 148161-02
148161-02 does NOT have "R" flag. It was obsoleted by 148338-03.
148338-03 does NOT have "R" flag.

Based on my understanding, PCA's recommendation to install 148338-03 is not correct when using the --minimal flag.
It should have seen that the currently installed version, 148161-02, was already newer than the recommended, 139944-01 version, therefore no newer patch is needed.

This behavior occurs in all recent versions of PCA, both development and stable.

Neil G. Brookins
Identity and Authentication Solutions - IT Global Solutions
Towers Watson
1500 Market Street | Philadelphia, PA 19102
Phone: +1 215 246 6046
neil.brookins&amp;lt; at &amp;gt;towerswatson.com&amp;lt;mailto:neil.brookins&amp;lt; at &amp;gt;towerswatson.com&amp;gt;

Notice of Confidentiality
This transmission contains information that may be confidential. It has been prepared for the sole and exclusive use of the intended recipient and on the basis agreed with that person. If you are not the intended recipient of the message (or authorized to receive it for the intended recipient), you should notify us immediately; you should delete it from your system and may not disclose its contents to anyone else.


This e-mail has come to you from Towers Watson Delaware Inc.
&lt;/pre&gt;</description>
    <dc:creator>Brookins, Neil (Philadelphia</dc:creator>
    <dc:date>2013-03-01T17:41:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3083">
    <title>patch install fail</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3083</link>
    <description>&lt;pre&gt;I just built a new T2000 using Solaris10 U11.
I then patched it with "pca --install --minimal missingr"
The following six patches failed to install:

# ./pca -l --minimal missingr
Using /var/tmp/patches/./patchdiag.xref from Feb/26/13
Host: xxxxxx (SunOS 5.10/Generic_147147-26/sparc/sun4v)
List: missingr-minimal (6/3818)

Patch  IR   CR RSB Age Synopsis
------ -- - -- --- --- -------------------------------------------------------
138876 -- &amp;lt; 01 RS- 999 Obsoleted by: 138876-02 SunOS 5.10: usr/lib/inet/in.dhcpd patch
145929 -- &amp;lt; 05 R-- 573 Obsoleted by: 145929-06 SunOS 5.10: igb driver Patch
145953 -- &amp;lt; 06 R-- 573 Obsoleted by: 145953-07 SunOS 5.10: emlxs driver Patch
146232 -- &amp;lt; 21 RS- 149 Obsoleted by: 146232-22 SunOS 5.10: iSCSI patch
146954 -- &amp;lt; 03 R-- 573 Obsoleted by: 146954-04 SunOS 5.10: routed patch
148169 -- &amp;lt; 03 R-- 376 Obsoleted by: 148169-04 SunOS 5.10: ixgbe patch

I picked "emlxs driver Patch" to trace the trail of "Obsoleted by...:" to confirm that a newer patch was already installed.
The xref file shows 145953-06 is Obsoleted by: 145953-07
The xref file shows 145953-07 is Obsoleted by: 149173-03
The "showrev -p" shows that Patch: 149173-03 is installed.
Therefore, 145953-06 is not needed.

Next I look at "igb driver Patch" to trace the trail...
The xref shows 145929-05 is Obsoleted by: 145929-06
The xref does not have 145929-06 listed.
But the xref does list 145929-09 so we know -06 is obsoleted by -09 which in turn is Obsoleted by: 148035-06
The "showrev -p" shows that Patch: 148035-06 is installed.
Therefore, 145929-05 is not needed.

In the above 2 cases, we can easily trace the trail using only the xref file. I assume that the other 4 cases are similar.
We do not have to download any additional data to derive the path of obsolescence.
I'd like to automate this process in such a way that the tool would automatically know that these patches are not needed to be installed and avoid having the failures. The goal would be that patches are not attempted to be installed if they are already obsoleted by any newer patch. Would this new functionality be something that PCA could be enhanced to perform?

Neil G. Brookins
Identity and Authentication Solutions - IT Global Solutions
Towers Watson
1500 Market Street | Philadelphia, PA 19102
Phone: +1 215 246 6046
neil.brookins&amp;lt; at &amp;gt;towerswatson.com&amp;lt;mailto:neil.brookins&amp;lt; at &amp;gt;towerswatson.com&amp;gt;

Notice of Confidentiality
This transmission contains information that may be confidential. It has been prepared for the sole and exclusive use of the intended recipient and on the basis agreed with that person. If you are not the intended recipient of the message (or authorized to receive it for the intended recipient), you should notify us immediately; you should delete it from your system and may not disclose its contents to anyone else.


This e-mail has come to you from Towers Watson Delaware Inc.
&lt;/pre&gt;</description>
    <dc:creator>Brookins, Neil (Philadelphia</dc:creator>
    <dc:date>2013-02-27T17:58:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3080">
    <title>Missing sconadm on Solaris 10 1/13</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3080</link>
    <description>&lt;pre&gt;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? :)

Martin.


&lt;/pre&gt;</description>
    <dc:creator>Martin Paul</dc:creator>
    <dc:date>2013-02-26T09:10:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3078">
    <title>patchdiag.xref changes broken for 2 days.</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3078</link>
    <description>&lt;pre&gt;I've been closely watching the daily changes in the patchdiag.xref in the past 2 weeks.
I've found a serious problem that will result in PCA not applying patches that should be applied if certain versions of patchdiag.xref are used.
This is a timing/race issue where recommended patches are removed from the patchdiag.xref; then two days elapse; then the new patch is added.
If PCA is used to install patches over that two day period, neither the old recommended patch nor the new recommended patch that replaced it is installed.

Let's look at four specific instances of this issue as it appeared this week.
We run the command, "pca -l --minimal missingr" on one host, over a period of 4 days, on February 18, 19, 20, 21.
The patchdiag.xref used was retrieved each morning, and has the dates: February 17, 18, 19, 20 respectively.
We are not actually installing patches in this example. This example is for reporting purposes only.

On the Feb. 18th report, we grep for patch "11866[67]|12513[67]"
118666 38 &amp;lt; 41 RS-  14 JavaSE 5.0: update 39 patch (equivalent to JDK 5.0u39)
118667 38 &amp;lt; 41 RS-  14 JavaSE 5.0: update 39 patch (equivalent to JDK 5.0u39), 64bit
125136 31 &amp;lt; 42 RS-  11 JavaSE 6: update 39 patch (equivalent to JDK 6u39)
125137 31 &amp;lt; 42 RS-  11 JavaSE 6: update 39 patch (equivalent to JDK 6u39), 64bit

On the Feb. 19th report, the above four patches do not appear.
On the Feb. 20th report, the above four patches do not appear.

On the Feb. 21st report, we grep for the same patches:
118666 38 &amp;lt; 42 RS-   3 JavaSE 5.0: update 40 patch (equivalent to JDK 5.0u40)
118667 38 &amp;lt; 42 RS-   3 JavaSE 5.0: update 40 patch (equivalent to JDK 5.0u40), 64bit
125136 31 &amp;lt; 44 RS-   3 JavaSE 6: update 41 patch (equivalent to JDK 6u41)
125137 31 &amp;lt; 44 RS-   3 JavaSE 6: update 41 patch (equivalent to JDK 6u41), 64bit

Please understand that I'm not complaining about the 2 days delay before the new patches show up as recommended in the patchdiag.xref file.
I know that these new patch appearance delays are part of the release process and are inevitable.
My complaint is only that the "old" patch is prematurely removed from the recommended list before the "new" one is added.
This premature removal is breaking the patching process on my hosts.
I'm patching hosts on February 19th and 20th with all the "Recommended patches" as of that date,
but these hosts now have a version of Java that is older than other hosts which were patched on Feb 18th. That's not right.

The solution to this problem is to keep the older Java patch listed as recommended in the patchdiag.xref until the new patch is added to the same file.
I can't do this myself, Sun/Oracle needs to change the timing of the removal and add to be on the same date. Its OK if this date is 3 days after the patch is released.

Neil G. Brookins
Identity and Authentication Solutions - IT Global Solutions
Towers Watson
1500 Market Street | Philadelphia, PA 19102
Phone: +1 215 246 6046
neil.brookins&amp;lt; at &amp;gt;towerswatson.com&amp;lt;mailto:neil.brookins&amp;lt; at &amp;gt;towerswatson.com&amp;gt;


Notice of Confidentiality
This transmission contains information that may be confidential. It has been prepared for the sole and exclusive use of the intended recipient and on the basis agreed with that person. If you are not the intended recipient of the message (or authorized to receive it for the intended recipient), you should notify us immediately; you should delete it from your system and may not disclose its contents to anyone else.


This e-mail has come to you from Towers Watson Delaware Inc.
&lt;/pre&gt;</description>
    <dc:creator>Brookins, Neil (Philadelphia</dc:creator>
    <dc:date>2013-02-21T15:38:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3072">
    <title>Solaris 10 1/13 preinstalled patches</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3072</link>
    <description>&lt;pre&gt;Hi Don/all,

A PCA user, who already installed Solaris 10 1/13, wondered why some 
rather old patches are not pre-installed (see below). As I've seen that 
happen with previous update releases, too, I've wondered about the same 
thing - does anybody have an idea about why certain - really old - 
patches are excluded?

Martin.

Patch  IR   CR RSB Age Synopsis
------ -- - -- --- --- 
-------------------------------------------------------
118666 34 &amp;lt; 41 RS-   7 JavaSE 5.0: update 39 patch (equivalent to JDK 
5.0u39)
118667 34 &amp;lt; 41 RS-   7 JavaSE 5.0: update 39 patch (equivalent to JDK 
5.0u39), 64bit
118683 07 &amp;lt; 08 --- 200 SunOS 5.10: Patch for profiling libraries and 
assembler
119213 26 &amp;lt; 27 RS- 369 NSS_NSPR_JSS 3.13.1: NSPR 4.8.9 / NSS 3.13.1 / 
JSS 4.3.2
119788 -- &amp;lt; 12 --- 119 SunOS 5.10: Sun Update Connection Proxy 1.0.9
119963 24 &amp;lt; 27 R-- 145 SunOS 5.10: Shared library patch for C++
121081 06 &amp;lt; 08 R-- 999 SunOS 5.10: Connected Customer Agents 1.1.0
121118 19 &amp;lt; 20 RS- 173 SunOS 5.10: Update Connection System Client 1.0.20
123893 50 &amp;lt; 52 R--  76 SunOS 5.8 5.9 5.10 Common Agent Container (cacao) 
runtime 2.3.1.2
125136 39 &amp;lt; 42 RS-   4 JavaSE 6: update 39 patch (equivalent to JDK 6u39)
125137 39 &amp;lt; 42 RS-   4 JavaSE 6: update 39 patch (equivalent to JDK 
6u39), 64bit
145078 -- &amp;lt; 01 --- 829 SunOS 5.10: Firefox plugins patch
148150 02 &amp;lt; 03 --- 124 SunOS 5.10: Tomcat 4 removal patch
148861 -- &amp;lt; 01 --- 129 SunOS 5.10: Sun XVR-2500 Graphics Accelerator 
Patch (post-S10U8)
149453 -- &amp;lt; 02 RS- 133 SunOS 5.10: CCR Update


&lt;/pre&gt;</description>
    <dc:creator>Martin Paul</dc:creator>
    <dc:date>2013-02-11T11:28:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3067">
    <title>patch flood</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3067</link>
    <description>&lt;pre&gt;Judging from today's patch flood, it's pretty sure that Solaris 10U11 is 
right around the corner :)

As usual, I installed all the new patches with PCA on both sparc and x86 
- works fine. Users of PCA's "--safe" option might want to get the 
current development release, where I added some whitelist entries.

Martin.


&lt;/pre&gt;</description>
    <dc:creator>Martin Paul</dc:creator>
    <dc:date>2013-02-08T09:54:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3057">
    <title>forcing https? (UNCLASSIFIED)</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3057</link>
    <description>&lt;pre&gt;Classification: UNCLASSIFIED
Caveats: NONE



I'm moving an existing patch server from solaris to linux and also upgrading the pca from Dec 2010 to Aug 2012 AND also from http to https.

From the output of the pca session I can see that it is picking up the ssprot=https from the conf file.  And successfully gets an updated patchdiag.xref using http.

But at the end, the session redirects to http://aru-akam.oracle.com and I get a connection refused.



Any suggestions on how to keep all the connections on https?  One of the requirements was for us to use only https.



Thanks,

Michael

session copy below:



root:/var/tmp/pca# ./pca -Vd 147440-27

Option download: 1

Option xrefdir: /var/tmp/pca

Option patchdir: /var/tmp/pca

Option user: &amp;lt;user&amp;gt;

Option passwd: &amp;lt;passwd&amp;gt;

Option ignore: 146363 119044 119812

Option syslog: user

Option ssprot: https

Option debug: 1

Command: ./pca

ARGV: 147440-27

Version: 20120829-01

CWD: /var/tmp/pca

Config files: /etc/pca.conf

Found /usr/sfw/bin/wget (1.11.4, 11104, https)

Found /usr/bin/wget (1.11.4, 11104, https)

Using /usr/sfw/bin/wget

Found /bin/uname

Prerequisites for threads not met, setting threads to 0

Never update

Expanded patch list: 147440-27

Downloading xref file to /var/tmp/pca/patchdiag.xref

Trying Oracle

Trying https://getupdates.oracle.com/ (1/1)

src: oracle, srcurl:

/usr/sfw/bin/wget --progress=dot:binary --ca-certificate=./pca -O /var/tmp/pca/patchdiag.xref "https://getupdates.oracle.com/reports/patchdiag.xref"

--2013-01-16 17:32:27--  https://getupdates.oracle.com/reports/patchdiag.xref

Resolving getupdates.oracle.com... 141.146.44.51

Connecting to getupdates.oracle.com|141.146.44.51|:443... connected.

HTTP request sent, awaiting response... 302 Found

Cookie coming from getupdates.oracle.com attempted to set domain to updates.oracle.com

Location: https://a248.e.akamai.net/f/248/21808/15m/sun.download.akamai.com/21808/patches/patchroot/reports/patchdiag.xref?AuthParam=1358375667_cc087299c8e2a0d0a32ba85c3e528a66&amp;amp;GroupName=SWUP&amp;amp;FilePath=/21808/patches/patchroot/reports/patchdiag.xref&amp;amp;File=patchdiag.xref&amp;amp;params=bUd4YWV1NlRaS0k1bTRlUGNmTkRBZzpzdW5fbWV0YWRhdGFfZmlsZT0vMjE4MDgvcGF0Y2hlcy9wYXRjaHJvb3QvcmVwb3J0cy9wYXRjaGRpYWcueHJlZg&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; [following]

--2013-01-16 17:32:28--  https://a248.e.akamai.net/f/248/21808/15m/sun.download.akamai.com/21808/patches/patchroot/reports/patchdiag.xref?AuthParam=1358375667_cc087299c8e2a0d0a32ba85c3e528a66&amp;amp;GroupName=SWUP&amp;amp;FilePath=/21808/patches/patchroot/reports/patchdiag.xref&amp;amp;File=patchdiag.xref&amp;amp;params=bUd4YWV1NlRaS0k1bTRlUGNmTkRBZzpzdW5fbWV0YWRhdGFfZmlsZT0vMjE4MDgvcGF0Y2hlcy9wYXRjaHJvb3QvcmVwb3J0cy9wYXRjaGRpYWcueHJlZg&amp;lt; at &amp;gt;&amp;lt; at &amp;gt;

Resolving a248.e.akamai.net... 204.0.3.10, 204.0.3.50

Connecting to a248.e.akamai.net|204.0.3.10|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: 2243692 (2.1M) [text/plain]

Saving to: `/var/tmp/pca/patchdiag.xref'



     0K ................ ................ ................ 17%  502K 4s

   384K ................ ................ ................ 35%  451K 3s

   768K ................ ................ ................ 52%  215K 3s

  1152K ................ ................ ................ 70%  301K 2s

  1536K ................ ................ ................ 87%  282K 1s

  1920K ................ ................ .               100%  213K=7.3s



2013-01-16 17:32:38 (300 KB/s) - `/var/tmp/pca/patchdiag.xref' saved [2243692/2243692]



osname from uname: Linux

patchdiag.xref size: 2243692

Using /var/tmp/pca/patchdiag.xref from Jan/15/13

All operands are fully qualified patch IDs plus revisions

Host: radfa0131v01670 (Linux ?/?/?/?)

List: 147440-27 (1/0)



Patch  IR   CR RSB Age Synopsis

------ -- - -- --- --- -------------------------------------------------------

147440 -- &amp;lt; 27 RS-  47 SunOS 5.10: Solaris kernel patch



Looking for 147440-27 (1/1)

Trying Oracle

Trying https://getupdates.oracle.com/ (1/1)

src: oracle, srcurl:

Adding to /tmp/pca.404322: header=Authorization: Basic &amp;lt;base64-user-passwd&amp;gt;

/usr/sfw/bin/wget --progress=dot:binary --ca-certificate=./pca -O /var/tmp/pca/147440-27.zip "https://getupdates.oracle.com/all_unsigned/147440-27.zip"

--2013-01-16 17:32:38--  https://getupdates.oracle.com/all_unsigned/147440-27.zip

Resolving getupdates.oracle.com... 141.146.44.51

Connecting to getupdates.oracle.com|141.146.44.51|:443... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Cookie coming from getupdates.oracle.com attempted to set domain to updates.oracle.com

Location: https://login.oracle.com/pls/orasso/orasso.wwsso_app_admin.ls_login?site2pstoretoken=v1.2~E4066BF0~C396FF23ADF97418618FF7856DF60917EAF550ADBD7CEFBE29998B1F92F888B05FF6D93135C3E79A852876B2A0CDF5217C153836E1AC503338B5C2CD5D9BB24564A3153F02DC806425F02D38EE6EC64D6DB168463D3FD22B04789CACE107FFE0BEE4675824B40C0E118929368F602D41ECFC9B55A3CAA8D8A114A35983F52CEC56DB6628A312FD5EC44A871F169D7CDF3D0F6B6DDCA7E13CF26A15E2B75126CAEDD37C2C3C9D771CB96D4F1257C5C46EEE5BA71D8CA8564B [following]

--2013-01-16 17:32:41--  https://login.oracle.com/pls/orasso/orasso.wwsso_app_admin.ls_login?site2pstoretoken=v1.2~E4066BF0~C396FF23ADF97418618FF7856DF60917EAF550ADBD7CEFBE29998B1F92F888B05FF6D93135C3E79A852876B2A0CDF5217C153836E1AC503338B5C2CD5D9BB24564A3153F02DC806425F02D38EE6EC64D6DB168463D3FD22B04789CACE107FFE0BEE4675824B40C0E118929368F602D41ECFC9B55A3CAA8D8A114A35983F52CEC56DB6628A312FD5EC44A871F169D7CDF3D0F6B6DDCA7E13CF26A15E2B75126CAEDD37C2C3C9D771CB96D4F1257C5C46EEE5BA71D8CA8564B

Resolving login.oracle.com... 148.87.121.98

Connecting to login.oracle.com|148.87.121.98|:443... connected.

HTTP request sent, awaiting response... 302 Moved Temporarily

Location: https://updates.oracle.com/osso_login_success?urlc=v1.2%7E5A6A934437C2549738A4FB71D49BFCC4FB49501F87C74DA935D33B2F362E9D959AF1FCB2D47ACB7FD291A718B23AA6368634C561607317A20F78A7D0DA2569A015BA8332AC35DA5FE8403F883391342BC6BA8A13AAD637D5D424801ED633D55FBAD3DE41C68C2691DD849789E123A8B51F2414BBCCB0E51D5CD4CCCE755EAE0EFE13E8526E17D4031B375E41FEBEE76655DC7C23D41292FB888E6855901B514FB44A0758F0A3FDBA978744F41605C1721051C462C30939BCA85ADD7B82E3A504CC4C9AE19F683A02B0BFF1F4170316E2971D6C23B807EEE9F672E0AED74B1F29F70E04350DB8131C065D72A88EC8506C981348C3DC11BBBEE3A0CE86DF117FB65BE1AC40703272CE898A4D40298E2F0E748A5AF5B703649F5A93D6E51825F6CC9C923B8B3EFD93102DFA9AD17C98B016DF9ED0CC98AB43C2C822CD07E7F61D38BCEF01930BB4EC747837FDD2B77AE8796BF218BB57D388D088EA4064A5EED696B44163F0CEFAE78B [following]

--2013-01-16 17:32:42--  https://updates.oracle.com/osso_login_success?urlc=v1.2%7E5A6A934437C2549738A4FB71D49BFCC4FB49501F87C74DA935D33B2F362E9D959AF1FCB2D47ACB7FD291A718B23AA6368634C561607317A20F78A7D0DA2569A015BA8332AC35DA5FE8403F883391342BC6BA8A13AAD637D5D424801ED633D55FBAD3DE41C68C2691DD849789E123A8B51F2414BBCCB0E51D5CD4CCCE755EAE0EFE13E8526E17D4031B375E41FEBEE76655DC7C23D41292FB888E6855901B514FB44A0758F0A3FDBA978744F41605C1721051C462C30939BCA85ADD7B82E3A504CC4C9AE19F683A02B0BFF1F4170316E2971D6C23B807EEE9F672E0AED74B1F29F70E04350DB8131C065D72A88EC8506C981348C3DC11BBBEE3A0CE86DF117FB65BE1AC40703272CE898A4D40298E2F0E748A5AF5B703649F5A93D6E51825F6CC9C923B8B3EFD93102DFA9AD17C98B016DF9ED0CC98AB43C2C822CD07E7F61D38BCEF01930BB4EC747837FDD2B77AE8796BF218BB57D388D088EA4064A5EED696B44163F0CEFAE78B

Resolving updates.oracle.com... 141.146.44.51

Connecting to updates.oracle.com|141.146.44.51|:443... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Location: https://updates.oracle.com/all_unsigned/147440-27.zip [following]

--2013-01-16 17:32:43--  https://updates.oracle.com/all_unsigned/147440-27.zip

Connecting to updates.oracle.com|141.146.44.51|:443... connected.

HTTP request sent, awaiting response... 302 Found

Location: http://aru-akam.oracle.com/adcarurepos/vol/patch40/PLATFORM/Solaris-32/R4000001100000/147440-27.zip?AuthParam=1358375684_1a50ddead5418836f3e5fff0a5762756&amp;amp;FilePath=/adcarurepos/vol/patch40/PLATFORM/Solaris-32/R4000001100000/147440-27.zip&amp;amp;File=147440-27.zip&amp;amp;params=YlZDMzN3czdBQmQrRWFDUDJaNjg3ZzphcnU9MTU4MTYyNTImZW1haWw9dXNhcm15LnJhZGZvcmQucGVvLWVpcy5saXN0LnVuaXgtdGVhbUBtYWlsLm1pbCZmaWxlX2lkPTU3MjIzMjY4JnBhdGNoX2ZpbGU9MTQ3NDQwLTI3LnppcCZ1c2VyaWQ9by11c2FybXkucmFkZm9yZC5wZW8tZWlzLmxpc3QudW5peC10ZWFtQG1haWwubWlsJnNpemU9MzUyMjgxODMmY29udGV4dD1BQDEwK0hAYWFydXZtdHAwMS5vcmFjbGUuY29tK1BAJmRvd25sb2FkX2lkPTYxNTc5MDQx [following]

--2013-01-16 17:32:43--  http://aru-akam.oracle.com/adcarurepos/vol/patch40/PLATFORM/Solaris-32/R4000001100000/147440-27.zip?AuthParam=1358375684_1a50ddead5418836f3e5fff0a5762756&amp;amp;FilePath=/adcarurepos/vol/patch40/PLATFORM/Solaris-32/R4000001100000/147440-27.zip&amp;amp;File=147440-27.zip&amp;amp;params=YlZDMzN3czdBQmQrRWFDUDJaNjg3ZzphcnU9MTU4MTYyNTImZW1haWw9dXNhcm15LnJhZGZvcmQucGVvLWVpcy5saXN0LnVuaXgtdGVhbUBtYWlsLm1pbCZmaWxlX2lkPTU3MjIzMjY4JnBhdGNoX2ZpbGU9MTQ3NDQwLTI3LnppcCZ1c2VyaWQ9by11c2FybXkucmFkZm9yZC5wZW8tZWlzLmxpc3QudW5peC10ZWFtQG1haWwubWlsJnNpemU9MzUyMjgxODMmY29udGV4dD1BQDEwK0hAYWFydXZtdHAwMS5vcmFjbGUuY29tK1BAJmRvd25sb2FkX2lkPTYxNTc5MDQx

Resolving aru-akam.oracle.com... 64.212.100.116, 64.212.100.110

Connecting to aru-akam.oracle.com|64.212.100.116|:80... failed: Connection refused.

Connecting to aru-akam.oracle.com|64.212.100.110|:80... failed: Connection refused.

Removing /tmp/pca.404322

Failed (Unknown Error)

Failed (patch not found)

------------------------------------------------------------------------------

Download Summary: 1 total, 0 successful, 0 skipped, 1 failed




Classification: UNCLASSIFIED
Caveats: NONE


&lt;/pre&gt;</description>
    <dc:creator>Gale, Michael D CTR (US</dc:creator>
    <dc:date>2013-01-16T23:02:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3053">
    <title>different directory for patches</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3053</link>
    <description>&lt;pre&gt;Is there a way I can force patchadd to look in a different directory than the default /var/sadm/pkg directory? We created a softlink from /var/sadm/pkg to /apps/sadm/pkg (due to space issues), but now patchadd always fails:

Directory is expected, found link - /var/sadm/pkg.
Failed (exit code 1)

Showrev -p does fine; and downloading the patches with pca -d does fine as well. It's just the actual installation of the patches where it fails. I'm pretty sure I had this fixed before, but honestly, I don't remember what I did (plan to DOCUMENT what I do this time!). Any ideas/suggestions would be greatly appreciated! Thanks!

Jamen McGranahan
Systems Services Librarian
Vanderbilt University LIbrary
Central Library
Room 811
419 21st Avenue South
Nashville, TN 37214

&lt;/pre&gt;</description>
    <dc:creator>McGranahan, Jamen</dc:creator>
    <dc:date>2013-01-16T18:38:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3051">
    <title>assistance finding document?</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3051</link>
    <description>&lt;pre&gt;
Can anyone on the list help us find this document, please?

Navigating for Sun info sure isn't what it used to be...

 From README 147440-27 Note 7:

For more information check MOS document 1501499.1 (UltraSPARC
          T2-based Systems Hang On Boot After Upgrade to Kernel Patch
          147440-25 OR Solaris 11 update 1).

thanks in advance!

&lt;/pre&gt;</description>
    <dc:creator>Diana Orrick</dc:creator>
    <dc:date>2012-12-10T16:52:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3050">
    <title>(no subject)</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3050</link>
    <description>&lt;pre&gt;http://capfitted.com/wp-content/yepyepop.php&lt;/pre&gt;</description>
    <dc:creator>Gyula Szekely</dc:creator>
    <dc:date>2012-12-04T20:29:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3043">
    <title>Patch 147440-25 issue</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3043</link>
    <description>&lt;pre&gt;Recently installed 147440-25 on a t5120 which rendered it unbootable.  After no help from Oracle on the matter I removed the patch and regained access to the system.  Oracle's response is that because I am not patching with the patch cluster the patches are being installed in the wrong order.  Even if I ignored the history of 147400 I don't believe that's true.  I've been using PCA for years and haven't had a problem till now.  Having said all that, is there any validity to the idea that the order of patch install may be a factor?

Mike

&lt;/pre&gt;</description>
    <dc:creator>Culver, Michael</dc:creator>
    <dc:date>2012-10-17T19:01:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3035">
    <title>wesunsolve.net closed</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3035</link>
    <description>&lt;pre&gt;Just saw that...

Ouch... Well Thomas, sorry to see that, your site helped quite a bit while
it lasted...

Thanks for all your time and dedication trying to help the community...
Regards
&lt;/pre&gt;</description>
    <dc:creator>Gael Martinez</dc:creator>
    <dc:date>2012-09-19T22:05:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3032">
    <title>Explorer Output</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3032</link>
    <description>&lt;pre&gt;Who else is using explorer outputs to create patch lists? looking for a
little direction.

Looking at our explorer output i have a few directories underneath..

/patch+pkg which contains showrev-p.out and pkginfo-i.out
/sysconfig contains uname -a.out.

I'm trying to figure out a clean way to pull all this together and run pca
on my explorer directory to find patches for each server.
&lt;/pre&gt;</description>
    <dc:creator>Jeremy Loukinas</dc:creator>
    <dc:date>2012-09-12T16:21:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3031">
    <title>New release: 20120829-01</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3031</link>
    <description>&lt;pre&gt;A new release of PCA has just been published. Here's a list of new 
features and changes:

  * Check for wget in update function
  * Ignore non-executable wget binaries
  * Whitelist: replace 145957 with 146232
  * Whitelist: replace 145958 with 146233
  * Apply check: add 119303, 119304, 119305
  * Apply check: add 147992, 147993
  * Apply check: add 112762
  * Apply check: add 112443

Update:
   pca --update now

Download:
   http://www.par.univie.ac.at/solaris/pca/installation.html

MD5: 5741bdb76e7b28495673bf82d44fccdf


&lt;/pre&gt;</description>
    <dc:creator>Martin Paul</dc:creator>
    <dc:date>2012-08-29T12:58:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.pca/3028">
    <title>option --rec=xxx not working?</title>
    <link>http://comments.gmane.org/gmane.os.solaris.pca/3028</link>
    <description>&lt;pre&gt;I just tried to use the --rec=118777-18 option which I expected to cause PCA to install this patch along with all the other patches.
But it appears to not have installed this extra patch. 
Can  the --rec option be used with the --minimal option?  Or, is my use of --minimal causing the elimination of the extra patch from the result set?
I had wanted to install the entire group of patches with one invocation of PCA, but I got it to work by running the extra patch separately. See below.

# lucreate -n 2012Q3_patches
# lumount 2012Q3_patches
# cd /var/tmp/patches
# nohup ./pca --install --root=/.alt.2012Q3_patches --download --ignore=121430-72 --rec=118777-18 --nocheckxref --xrefdir=. --patchdir=. --minimal missingr &amp;gt;pca.log 2&amp;gt;&amp;amp;1 &amp;amp;
# tail -f pca.log

The above command installed about 70 patches, but not 118777-18.
Then, I tried to install the patch by itself, and it worked fine:

# ./pca --install --user=xxxxxx --passwd=yyyyyy --root=/.alt.2012Q3_patches --download --nocheckxref --xrefdir=. --patchdir=. 118777-18
...
Running patchadd
Successful (10:18:10/00:00:48/00:01:04, 1/1, 1/0/0)
Reboot recommended
------------------------------------------------------------------------------
Download Summary: 1 total, 1 successful, 0 skipped, 0 failed
Install Summary : 1 total, 1 successful, 0 skipped, 0 failed


Neil G. Brookins
Identity and Authentication Solutions - IT Global Solutions
Towers Watson
1500 Market Street | Philadelphia, PA 19102
Phone: +1 215 246 6046
neil.brookins&amp;lt; at &amp;gt;towerswatson.com


Notice of Confidentiality 
This transmission contains information that may be confidential.  It has been prepared for the sole and exclusive use of the intended recipient and on the basis agreed with that person.  If you are not the intended recipient of the message (or authorized to receive it for the intended recipient), you should notify us immediately; you should delete it from your system and may not disclose its contents to anyone else.

This e-mail has come to you from Towers Watson Delaware Inc.



&lt;/pre&gt;</description>
    <dc:creator>Brookins, Neil (Philadelphia</dc:creator>
    <dc:date>2012-08-22T15:02:25</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.os.solaris.pca">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.os.solaris.pca</link>
  </textinput>
</rdf:RDF>
