Re: [pca] patchdiag.xref
Am 01.12.2014 18:43, schrieb Tim Hosfelt: Is there a way to get older patchdiag.xref files from Oracle - I'd like to get ones from early to mid September and October. No, unfortunately Oracle doesn't provide an archive. Many PCA users do so, though, so if you post specific dates here I'm sure someone can help. hth, Martin.
[pca] patchdiag.xref
Is there a way to get older patchdiag.xref files from Oracle - I'd like to get ones from early to mid September and October.
Re: [pca] patchdiag.xref
There is dates in the file you might be able to exclude patches from the file. We grab a copy daily and store it for 1 year. So we can pick the date we want to pin our primary proxy server to. There is a flag for age --minage=DAYS List only patches which are at least DAYS old. Billy Pearson From: pca [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Tim Hosfelt Sent: Monday, December 01, 2014 11:43 AM To: pca@lists.univie.ac.at Subject: [pca] patchdiag.xref Is there a way to get older patchdiag.xref files from Oracle - I'd like to get ones from early to mid September and October. -- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
Re: [pca] patchdiag.xref download broken
Am 22.07.2013 10:42, schrieb Jan Holzhueter: seems like the patchdiag.xref download is broken atm. I didn't try it in the last 72 hours, but as of now it seems to work again. Martin.
[pca] patchdiag.xref download broken
Hi, seems like the patchdiag.xref download is broken atm. ./pca.perl -l -V Option list: 1 Option patchdir: /home/jh/patches/. Option debug: 1 Command: ./pca.perl ARGV: missing Version: 20120829-01 CWD: /home/jh/patches Found /usr/sfw/bin/wget (1.12, 11200, https) Found /usr/bin/wget (1.12, 11200, https) Using /usr/sfw/bin/wget Found /usr/bin/uname Prerequisites for threads not met, setting threads to 0 Never update Expanded patch list: missing Downloading xref file to /var/tmp/patchdiag.xref Trying Oracle Trying https://getupdates.oracle.com/ (1/1) src: oracle, srcurl: /usr/sfw/bin/wget --progress=dot:binary --ca-certificate=./pca.perl -O /var/tmp/patchdiag.xref https://getupdates.oracle.com/reports/patchdiag.xref; --2013-07-22 10:40:07-- https://getupdates.oracle.com/reports/patchdiag.xref Resolving getupdates.oracle.com (getupdates.oracle.com)... 141.146.44.51 Connecting to getupdates.oracle.com (getupdates.oracle.com)|141.146.44.51|:443... connected. HTTP request sent, awaiting response... 302 Found Cookie coming from updates.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?FilePath=/21808/patches/patchroot/reports/patchdiag.xrefFile=patchdiag.xrefparams=bUd4YWV1NlRaS0k1bTRlUGNmTkRBZzpzdW5fbWV0YWRhdGFfZmlsZT0vMjE4MDgvcGF0Y2hlcy9wYXRjaHJvb3QvcmVwb3J0cy9wYXRjaGRpYWcueHJlZg@@GroupName=SWUPAuthParam=1374482528_f07ba0e5539a3f5fb45c9207a424fd6a [following] --2013-07-22 10:40:08-- https://a248.e.akamai.net/f/248/21808/15m/sun.download.akamai.com/21808/patches/patchroot/reports/patchdiag.xref?FilePath=/21808/patches/patchroot/reports/patchdiag.xrefFile=patchdiag.xrefparams=bUd4YWV1NlRaS0k1bTRlUGNmTkRBZzpzdW5fbWV0YWRhdGFfZmlsZT0vMjE4MDgvcGF0Y2hlcy9wYXRjaHJvb3QvcmVwb3J0cy9wYXRjaGRpYWcueHJlZg@@GroupName=SWUPAuthParam=1374482528_f07ba0e5539a3f5fb45c9207a424fd6a Resolving a248.e.akamai.net (a248.e.akamai.net)... 213.158.112.136, 213.158.112.137 Connecting to a248.e.akamai.net (a248.e.akamai.net)|213.158.112.136|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2013-07-22 10:40:08 ERROR 403: Forbidden. Failed (Error 403: Forbidden) Failed (patchdiag.xref not found) osname from uname: SunOS ERROR: Can't open xref file /var/tmp/patchdiag.xref (No such file or directory) Greetings Jan
Re: [pca] patchdiag.xref changes broken for 2 days.
Am 21.02.2013 16:38, schrieb Brookins, Neil (Philadelphia): 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. Confirmed. Thanks for noticing this and especially the amount of details you provided, this helped a lot when looking at the issue. I've put a fix into the development release of PCA - you can try that with the xref file AS OF Feb/18/13. Comparing output of pca --minimal missingr between the stable and development releases of PCA, you'll notice that the fixed version will now show the last recommended revision of the Java patches. 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. Actually, Oracle does that. In xref AS OF Feb/18/13, they add a new revision of 118666 (42), which is marked S but not R. The previous revision (41) is marked O (obsolete), but keeps the R flag. With --minimal, PCA is supposed to ignore the O flag on rev. 41 and use that. The problem was that there are two other revisions of 118666 in xref, 19 and 34, and both are marked R/S/O as well. No idea why, and I really think that these should be removed by Oracle (the Java patches were the only ones I found with that pattern). The bug in PCA was that it used the first of these revisions (19) and not the last (41). That's what I've fixed now. Thanks again for the report, Martin.
[pca] patchdiag.xref changes broken for 2 days.
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 41 RS- 14 JavaSE 5.0: update 39 patch (equivalent to JDK 5.0u39) 118667 38 41 RS- 14 JavaSE 5.0: update 39 patch (equivalent to JDK 5.0u39), 64bit 125136 31 42 RS- 11 JavaSE 6: update 39 patch (equivalent to JDK 6u39) 125137 31 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 42 RS- 3 JavaSE 5.0: update 40 patch (equivalent to JDK 5.0u40) 118667 38 42 RS- 3 JavaSE 5.0: update 40 patch (equivalent to JDK 5.0u40), 64bit 125136 31 44 RS- 3 JavaSE 6: update 41 patch (equivalent to JDK 6u41) 125137 31 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.brook...@towerswatson.commailto:neil.brook...@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.
Re: [pca] patchdiag.xref inconsistency
Don O'Malley wrote: That said, something has happened to trigger 119081-25 being marked as obsolete (I suspect this is a result of an internal process). In the current patchdiag.xref (Oct/02/11) the state of 119081-25 has been reverted to active (not obsolete) again. Same for the other 7 patches that were affected (106922, 108982, 109082, 109647, 117662, 117851, 119070). So everything is fine again. I also checked for other possible problematic patches with this command: grep '|O|' patchdiag.xref | egrep -vi Obsoleted by|withdrawn It only comes up with 4 old revisions of 118822 now, which are marked Obsolete and Bad, which is not a problem. If you ever find an explanation for how this happened, I'd be interested to hear about it! Martin.
Re: [pca] patchdiag.xref inconsistency
Hi Martin, I followed up with the team that generates patchdiag on Friday. There was a recent code change to better handle EOL patches that triggered the issue you reported on Friday. All should be fixed now. Best, -Don On 03/10/11 08:12, Martin Paul wrote: Don O'Malley wrote: That said, something has happened to trigger 119081-25 being marked as obsolete (I suspect this is a result of an internal process). In the current patchdiag.xref (Oct/02/11) the state of 119081-25 has been reverted to active (not obsolete) again. Same for the other 7 patches that were affected (106922, 108982, 109082, 109647, 117662, 117851, 119070). So everything is fine again. I also checked for other possible problematic patches with this command: grep '|O|' patchdiag.xref | egrep -vi "Obsoleted by|withdrawn" It only comes up with 4 old revisions of 118822 now, which are marked Obsolete and Bad, which is not a problem. If you ever find an explanation for how this happened, I'd be interested to hear about it! Martin. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
[pca] patchdiag.xref inconsistency
In today's patchdiag.xref, patch 119081-25 is suddenly marked as Obsolete. nut there is no sign by which patch it would have been obsoleted: usually, the synopsis (last column in xref file) contains a note Obsoleted by xx-xx. As there are two patches which require 119081-25 (namely 124628-14 and 124630-58) this leads to a situation, where patch dependencies can not be resolved. Don - can you check whether the obsoletion of 119081-25 was an error? Or maybe 124628-14 obsoletes 119081-25, but its README and patchinfo file contradict. Martin.
Re: [pca] patchdiag.xref inconsistency
Hi Martin, I'll investigate. In a nutshell the relationship between patches 119081-25 124628-14 is that patch 119081-xx was rejuvenated into patch 124628-xx. Patch rejuvenation is explained a the top of http://blogs.oracle.com/patch/entry/solaris_10_kernel_patchid_progression That said, something has happened to trigger 119081-25 being marked as obsolete (I suspect this is a result of an internal process). I can confirm that there is no patch that obsoletes 124628-xx. Stay Tuned! Best, -Don Martin Paul wrote: In today's patchdiag.xref, patch 119081-25 is suddenly marked as "Obsolete". nut there is no sign by which patch it would have been obsoleted: usually, the synopsis (last column in xref file) contains a note "Obsoleted by xx-xx". As there are two patches which require 119081-25 (namely 124628-14 and 124630-58) this leads to a situation, where patch dependencies can not be resolved. Don - can you check whether the obsoletion of 119081-25 was an error? Or maybe 124628-14 obsoletes 119081-25, but its README and patchinfo file contradict. Martin. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] patchdiag.xref feature request for Don
Sorry for the delay replying to this mail... I do maintain a 'patchdiag.xref wishlist' myself too :-) On 08/09/11 08:59, Martin Paul wrote: dpecka wrote: i'm suggesting to think about these fields: - patch bundle I have raised discussions about creating a patchdiag.xref corresponding to each Solaris Update patch bundle previously. I assume that's what is meant by patch bundle above, right? I couldn't get commitment to create them. I thought that someone on the PCA alias had come up with a mechanism to create a patchdiag.xref from any given set of patches? That aside, by installing the Patchsets that Oracle create you do get the benefit of the installpatchset script that my team created. - readme md5sum These are not generated anywhere currently AFAIK. - zipped patch md5sum Available from: https://updates.oracle.com/reports/CHECKSUMS or on a per-patch basis - eg. https://updates.oracle.com/Orion/Services/search?bug=120068-02 (see http://blogs.oracle.com/patch/entry/useful_patch_related_downloads for further info). Agree it would be useful in patchdiag.xref too. I'll add these from my wishlist: - patch properties (rebootafter, etc.) Already have this one on my list! - patch size (zipped/unzipped) I have this on my list (definitely the zipped filesize anyway). - a new flag "always install first" for the patch utilities patches etc. So, what you need is a patch utilities flag then! Patches required for Live Upgrade to function correctly too perhaps? I can't think of any other "always install first" scenarios off-hand. - include all patch revisions, not just the latest Would this not make it more difficult for you to extract the latest rev? It'll certainly grow the filesize considerably (We have 30,000 patches currently available). and then make PCA the official Solaris patch tool. and BTW, peace on earth would be nice, too :) :-) Best, -Don Martin. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] patchdiag.xref feature request for Don
dpecka wrote: i'm suggesting to think about these fields: - patch bundle - readme md5sum - zipped patch md5sum I'll add these from my wishlist: - patch properties (rebootafter, etc.) - patch size (zipped/unzipped) - a new flag always install first for the patch utilities patches etc. - include all patch revisions, not just the latest and then make PCA the official Solaris patch tool. and BTW, peace on earth would be nice, too :) Martin.
Re: [pca] patchdiag.xref feature request for Don
Martin, On Thu, 08 Sep 2011 09:59:27 +0200 Martin Paul mar...@par.univie.ac.at wrote: - include all patch revisions, not just the latest I wonder if this feature could be integrated into We Sun Solve website, as from the patchdiag.xref archive, I could generate a patchdiag.xref with latest revision as base and then add older revision of patches into it by looking at patchdiag.xref archive. Is this could be useful for you ? (and for others ?!) Do you see any other feature like this one who also might interest people ? Regards, Thomas -- Gouverneur Thomas t...@ians.be
Re: [pca] patchdiag.xref feature request for Don
Thomas, I wonder if this feature could be integrated into We Sun Solve website, as from the patchdiag.xref archive, I could generate a patchdiag.xref with latest revision as base and then add older revision of patches into it by looking at patchdiag.xref archive. Yes, you're right. Theoretically one should be able to build a master xref file by joining the old copies, which could then be used to show patch dependencies for older revisions as well. One problem is that a simple cat */patchdiag.xref | sort | uniq won't be enough. One would have to take care of the R/S/O flags on past patch revisions. and it would be very hard (or, impossible) to verify whether the result is actually consistent. As far as PCA is concerned, there's another problem - its data structures assume that there is only one revision per patch (the main array is indexed by patch-ID only). Changing this would require a re-write of big parts of the code. Martin.
Re: [pca] patchdiag.xref feature request for Don
This would be a massive file, maybe 10-20 times the size of the current patchdiag.xref. What about an online version, using some sort of database? Put in a date as a parameter and it returns the patchdiag.xref constructed for that date? Or a patch number and you get the whole history for that patch, including all versions, supercedes, etc? Just trying to think a little bit laterally here... regards, -glenn On 09/08/11 23:37, Martin Paul wrote: Thomas, I wonder if this feature could be integrated into We Sun Solve website, as from the patchdiag.xref archive, I could generate a patchdiag.xref with latest revision as base and then add older revision of patches into it by looking at patchdiag.xref archive. Yes, you're right. Theoretically one should be able to build a master xref file by joining the old copies, which could then be used to show patch dependencies for older revisions as well. One problem is that a simple cat */patchdiag.xref | sort | uniq won't be enough. One would have to take care of the R/S/O flags on past patch revisions. and it would be very hard (or, impossible) to verify whether the result is actually consistent. As far as PCA is concerned, there's another problem - its data structures assume that there is only one revision per patch (the main array is indexed by patch-ID only). Changing this would require a re-write of big parts of the code. Martin.
[pca] patchdiag.xref feature request for Don
hello Don, hello boys isn't possible to incorporate in patchdiag.xref as a new field some kind of info if that patch is also shipped with patch some bundle ? well, i know that it's not so easy hence the releases increment but just think about it. i'm suggesting to think about these fields: - patch bundle - readme md5sum - zipped patch md5sum regards, daniel -- Best Regards / S Pozdravem Daniel Pecka -- SunOS Specialist, UNIX Administrator www.techniservit.cz mailto:dpe...@techniservit.cz callto:+0420603166533
Re: [pca] patchdiag.xref archive
Anything before september 2008 would interest me! You can consult eventual gaps in the archive there: http://wesunsolve.net/patchdiag the drop down list is containing every archive I have. Thanks to all! Thomas On Thu, 18 Aug 2011 17:02:49 -0400 Rajiv Gunja opn.src.ro...@gmail.com wrote: So which year Xref are you looking for? I can share 2009 (233) and some of 2008(78). Let me know. Thanks -GGR -- Rajiv G Gunja Blog: http://ossrocks.blogspot.com On Thu, Aug 18, 2011 at 09:31, Dennis Clarke dcla...@blastwave.org wrote: Dennis, This is ok for theses one, I already got them all ;) I thought you had more xrefs from earlier than 2009 ;) Well, I do but I will have to go get a backup tape from .. somewhere. -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+ -- Gouverneur Thomas t...@ians.be
Re: [pca] patchdiag.xref archive
Nothing received yet, Do you need a FTP server if the file is big so you can upload it ? Regards, Thomas On Wed, 17 Aug 2011 01:21:34 -0400 (EDT) Dennis Clarke dcla...@blastwave.org wrote: Hello world! As Martin advised me to ask directly on the whole list, I'm there! I'm building an online archives of old patchdiag.xref (http://wesunsolve.net/patchdiag) and thus, I've collected some patchdiags that various people gave me. If you have missing patchdiag's (older ones), theses could be of some interest so don't hesitate to send them to me (zip by email or url for archive to be downloaded, or I can even setup an ftp account, let me know). I'll tar up the ones I have and then email. -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+ -- Gouverneur Thomas t...@ians.be
Re: [pca] patchdiag.xref archive
Nothing received yet, Do you need a FTP server if the file is big so you can upload it ? No. I just have not gotten around to it :-) I don't have a huge stack of them .. but a few : # ls $PCA_XREFDIR getupdates.pem patchdiag.CHECKSUMS patchdiag.CHECKSUMS.old patchdiag.CHECKSUMS_05_May_2011 patchdiag.CHECKSUMS_10_Apr_2011 patchdiag.CHECKSUMS_11_Jun_2011 patchdiag.CHECKSUMS_19_Mar_2011 patchdiag.CHECKSUMS_2001-07-07 patchdiag.CHECKSUMS_2011-05-12 patchdiag.CHECKSUMS_23_May_2011 patchdiag.md5 patchdiag.xref patchdiag.xref_01_May_2010 patchdiag.xref_01_Nov_2010 patchdiag.xref_01_Oct_2010 patchdiag.xref_02_Apr_2010 patchdiag.xref_03_Jul_2010 patchdiag.xref_04_Aug_2010 patchdiag.xref_04_May_2010 patchdiag.xref_04_Nov_2010 patchdiag.xref_05_Aug_2010 patchdiag.xref_06_Jul_2010 patchdiag.xref_06_May_2010_0004HRS_GMT patchdiag.xref_07_Aug_2010 patchdiag.xref_07_July_2010 patchdiag.xref_08_May_2010 patchdiag.xref_09_Apr_2010 patchdiag.xref_09_Oct_2010 patchdiag.xref_10_Sep_2010 patchdiag.xref_11_Aug_2010 patchdiag.xref_11_Jun_2010 patchdiag.xref_11_Sep_2010 patchdiag.xref_12_Nov_2010 patchdiag.xref_14_Aug_2010 patchdiag.xref_14_May_2010 patchdiag.xref_14_Oct_2010 patchdiag.xref_14_Sep_2010 patchdiag.xref_15_Apr_2010 patchdiag.xref_15_Jul_2010 patchdiag.xref_15_Jun_2010 patchdiag.xref_15_Nov_2010 patchdiag.xref_16_Jul_2010 patchdiag.xref_16_Jun_2010 patchdiag.xref_17_Apr_2010 patchdiag.xref_17_Dec_2010_02:02:06_GMT patchdiag.xref_17_Jul_2010 patchdiag.xref_18_May_2010 patchdiag.xref_18_Nov_2010 patchdiag.xref_18_Sep_2010 patchdiag.xref_19_Jun_2010 patchdiag.xref_19_Nov_2010 patchdiag.xref_2009-07-20 patchdiag.xref_2009-07-21 patchdiag.xref_2009-07-23 patchdiag.xref_2009-08-09 patchdiag.xref_2009-08-10 patchdiag.xref_2009-08-27 patchdiag.xref_2009-08-29 patchdiag.xref_2009-10-12 patchdiag.xref_2009-11-05 patchdiag.xref_2009-11-07 patchdiag.xref_2009-11-11 patchdiag.xref_2009-11-21 patchdiag.xref_2009-12-03 patchdiag.xref_2009-12-11 patchdiag.xref_2009-12-15 patchdiag.xref_2009-12-19 patchdiag.xref_2009-12-29 patchdiag.xref_2009-12-31 patchdiag.xref_2010-12-19 patchdiag.xref_2010-12-28 patchdiag.xref_2010-12-30 patchdiag.xref_2010_01_01 patchdiag.xref_2010_01_06 patchdiag.xref_2010_01_21 patchdiag.xref_2010_01_30 patchdiag.xref_2010_02_03 patchdiag.xref_2010_02_05 patchdiag.xref_2010_02_06 patchdiag.xref_2010_02_09 patchdiag.xref_2010_02_10 patchdiag.xref_2010_02_17 patchdiag.xref_2010_02_24 patchdiag.xref_2010_02_26 patchdiag.xref_2010_03_02 patchdiag.xref_2010_03_04 patchdiag.xref_2010_03_05 patchdiag.xref_2010_03_06 patchdiag.xref_2010_03_12 patchdiag.xref_2010_03_16 patchdiag.xref_2010_03_19 patchdiag.xref_2010_03_20 patchdiag.xref_2010_03_23 patchdiag.xref_2010_03_26 patchdiag.xref_2011-01-01 patchdiag.xref_2011-01-12 patchdiag.xref_2011-01-31 patchdiag.xref_2011-02-05 patchdiag.xref_2011-02-10 patchdiag.xref_2011-02-12 patchdiag.xref_2011-02-17 patchdiag.xref_2011-02-23 patchdiag.xref_2011-02-26 patchdiag.xref_2011-02-28 patchdiag.xref_2011-03-02 patchdiag.xref_2011-03-12 patchdiag.xref_2011-03-17 patchdiag.xref_2011-03-19 patchdiag.xref_2011-03-28 patchdiag.xref_2011-03-30 patchdiag.xref_2011-04-05 patchdiag.xref_2011-04-07 patchdiag.xref_2011-04-08 patchdiag.xref_2011-04-11 patchdiag.xref_2011-04-19 patchdiag.xref_2011-05-05 patchdiag.xref_2011-05-12 patchdiag.xref_2011-05-23 patchdiag.xref_2011-06-07 patchdiag.xref_2011-06-11 patchdiag.xref_2011-06-18 patchdiag.xref_2011-06-23 patchdiag.xref_2011-07-07 patchdiag.xref_2011-07-21 patchdiag.xref_2011-08-02 patchdiag.xref_20_Dec_2010_15:53:07_GMT patchdiag.xref_20_May_2010 patchdiag.xref_21_May_2010 patchdiag.xref_22_May_2010 patchdiag.xref_23_Mar_2011 patchdiag.xref_23_Nov_2010 patchdiag.xref_23_Oct_2010 patchdiag.xref_24_Apr_2010 patchdiag.xref_24_Aug_2010 patchdiag.xref_24_Nov_2010 patchdiag.xref_25_Jun_2010 patchdiag.xref_25_May_2010 patchdiag.xref_25_Sep_2010 patchdiag.xref_26_Nov_2010 patchdiag.xref_28_Jul_2010 patchdiag.xref_29_May_2010 patchdiag.xref_30_Apr_2010 patchdiag.xref_30_Mar_2010 patchdiag.xref_30_Oct_2010 patchdiag.xref_31_Jul_2010 patchdiag.xref_31_Mar_2010 I think I nuked away my stuff from 05 upwards to 2010. I'll get them to you one way or another. -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: [pca] patchdiag.xref archive
Dennis, This is ok for theses one, I already got them all ;) I thought you had more xrefs from earlier than 2009 ;) Thanks anyway ! On Thu, 18 Aug 2011 08:13:59 -0400 (EDT) Dennis Clarke dcla...@blastwave.org wrote: Nothing received yet, Do you need a FTP server if the file is big so you can upload it ? No. I just have not gotten around to it :-) I don't have a huge stack of them .. but a few : # ls $PCA_XREFDIR getupdates.pem patchdiag.CHECKSUMS patchdiag.CHECKSUMS.old patchdiag.CHECKSUMS_05_May_2011 patchdiag.CHECKSUMS_10_Apr_2011 patchdiag.CHECKSUMS_11_Jun_2011 patchdiag.CHECKSUMS_19_Mar_2011 patchdiag.CHECKSUMS_2001-07-07 patchdiag.CHECKSUMS_2011-05-12 patchdiag.CHECKSUMS_23_May_2011 patchdiag.md5 patchdiag.xref patchdiag.xref_01_May_2010 patchdiag.xref_01_Nov_2010 patchdiag.xref_01_Oct_2010 patchdiag.xref_02_Apr_2010 patchdiag.xref_03_Jul_2010 patchdiag.xref_04_Aug_2010 patchdiag.xref_04_May_2010 patchdiag.xref_04_Nov_2010 patchdiag.xref_05_Aug_2010 patchdiag.xref_06_Jul_2010 patchdiag.xref_06_May_2010_0004HRS_GMT patchdiag.xref_07_Aug_2010 patchdiag.xref_07_July_2010 patchdiag.xref_08_May_2010 patchdiag.xref_09_Apr_2010 patchdiag.xref_09_Oct_2010 patchdiag.xref_10_Sep_2010 patchdiag.xref_11_Aug_2010 patchdiag.xref_11_Jun_2010 patchdiag.xref_11_Sep_2010 patchdiag.xref_12_Nov_2010 patchdiag.xref_14_Aug_2010 patchdiag.xref_14_May_2010 patchdiag.xref_14_Oct_2010 patchdiag.xref_14_Sep_2010 patchdiag.xref_15_Apr_2010 patchdiag.xref_15_Jul_2010 patchdiag.xref_15_Jun_2010 patchdiag.xref_15_Nov_2010 patchdiag.xref_16_Jul_2010 patchdiag.xref_16_Jun_2010 patchdiag.xref_17_Apr_2010 patchdiag.xref_17_Dec_2010_02:02:06_GMT patchdiag.xref_17_Jul_2010 patchdiag.xref_18_May_2010 patchdiag.xref_18_Nov_2010 patchdiag.xref_18_Sep_2010 patchdiag.xref_19_Jun_2010 patchdiag.xref_19_Nov_2010 patchdiag.xref_2009-07-20 patchdiag.xref_2009-07-21 patchdiag.xref_2009-07-23 patchdiag.xref_2009-08-09 patchdiag.xref_2009-08-10 patchdiag.xref_2009-08-27 patchdiag.xref_2009-08-29 patchdiag.xref_2009-10-12 patchdiag.xref_2009-11-05 patchdiag.xref_2009-11-07 patchdiag.xref_2009-11-11 patchdiag.xref_2009-11-21 patchdiag.xref_2009-12-03 patchdiag.xref_2009-12-11 patchdiag.xref_2009-12-15 patchdiag.xref_2009-12-19 patchdiag.xref_2009-12-29 patchdiag.xref_2009-12-31 patchdiag.xref_2010-12-19 patchdiag.xref_2010-12-28 patchdiag.xref_2010-12-30 patchdiag.xref_2010_01_01 patchdiag.xref_2010_01_06 patchdiag.xref_2010_01_21 patchdiag.xref_2010_01_30 patchdiag.xref_2010_02_03 patchdiag.xref_2010_02_05 patchdiag.xref_2010_02_06 patchdiag.xref_2010_02_09 patchdiag.xref_2010_02_10 patchdiag.xref_2010_02_17 patchdiag.xref_2010_02_24 patchdiag.xref_2010_02_26 patchdiag.xref_2010_03_02 patchdiag.xref_2010_03_04 patchdiag.xref_2010_03_05 patchdiag.xref_2010_03_06 patchdiag.xref_2010_03_12 patchdiag.xref_2010_03_16 patchdiag.xref_2010_03_19 patchdiag.xref_2010_03_20 patchdiag.xref_2010_03_23 patchdiag.xref_2010_03_26 patchdiag.xref_2011-01-01 patchdiag.xref_2011-01-12 patchdiag.xref_2011-01-31 patchdiag.xref_2011-02-05 patchdiag.xref_2011-02-10 patchdiag.xref_2011-02-12 patchdiag.xref_2011-02-17 patchdiag.xref_2011-02-23 patchdiag.xref_2011-02-26 patchdiag.xref_2011-02-28 patchdiag.xref_2011-03-02 patchdiag.xref_2011-03-12 patchdiag.xref_2011-03-17 patchdiag.xref_2011-03-19 patchdiag.xref_2011-03-28 patchdiag.xref_2011-03-30 patchdiag.xref_2011-04-05 patchdiag.xref_2011-04-07 patchdiag.xref_2011-04-08 patchdiag.xref_2011-04-11 patchdiag.xref_2011-04-19 patchdiag.xref_2011-05-05 patchdiag.xref_2011-05-12 patchdiag.xref_2011-05-23 patchdiag.xref_2011-06-07 patchdiag.xref_2011-06-11 patchdiag.xref_2011-06-18 patchdiag.xref_2011-06-23 patchdiag.xref_2011-07-07 patchdiag.xref_2011-07-21 patchdiag.xref_2011-08-02 patchdiag.xref_20_Dec_2010_15:53:07_GMT patchdiag.xref_20_May_2010 patchdiag.xref_21_May_2010 patchdiag.xref_22_May_2010 patchdiag.xref_23_Mar_2011 patchdiag.xref_23_Nov_2010 patchdiag.xref_23_Oct_2010 patchdiag.xref_24_Apr_2010 patchdiag.xref_24_Aug_2010 patchdiag.xref_24_Nov_2010 patchdiag.xref_25_Jun_2010 patchdiag.xref_25_May_2010 patchdiag.xref_25_Sep_2010 patchdiag.xref_26_Nov_2010 patchdiag.xref_28_Jul_2010 patchdiag.xref_29_May_2010 patchdiag.xref_30_Apr_2010 patchdiag.xref_30_Mar_2010 patchdiag.xref_30_Oct_2010 patchdiag.xref_31_Jul_2010 patchdiag.xref_31_Mar_2010 I think I nuked away my stuff from 05 upwards to 2010. I'll get them to you one way or another. -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+ -- Gouverneur Thomas t...@ians.be
Re: [pca] patchdiag.xref archive
Dennis, This is ok for theses one, I already got them all ;) I thought you had more xrefs from earlier than 2009 ;) Well, I do but I will have to go get a backup tape from .. somewhere. -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
[pca] patchdiag.xref archive
Hello world! As Martin advised me to ask directly on the whole list, I'm there! I'm building an online archives of old patchdiag.xref (http://wesunsolve.net/patchdiag) and thus, I've collected some patchdiags that various people gave me. If you have missing patchdiag's (older ones), theses could be of some interest so don't hesitate to send them to me (zip by email or url for archive to be downloaded, or I can even setup an ftp account, let me know). Thanks in advance, -- Gouverneur Thomas t...@ians.be
Re: [pca] patchdiag.xref archive
Hello world! As Martin advised me to ask directly on the whole list, I'm there! I'm building an online archives of old patchdiag.xref (http://wesunsolve.net/patchdiag) and thus, I've collected some patchdiags that various people gave me. If you have missing patchdiag's (older ones), theses could be of some interest so don't hesitate to send them to me (zip by email or url for archive to be downloaded, or I can even setup an ftp account, let me know). I'll tar up the ones I have and then email. -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: [pca] patchdiag.xref shrunk
Hi Martin,
When we first migrated patch metadata to MOS (in June 2009) we
never included metadata for patches for products that were EOSL.
As part of the recent MOS 5.3 release we have aligned patchdiag.xref
with the metadata available from MOS.
All of the patches that have disappeared have been for "housekeeping"
reasons, and IMO this is actually an improvement in patchdiag.xref.
We have endeavored to ensure that no dependency chains have been broken
in the cleanup, but if anyone spots any problems with the "cleaned"
patchdiag.xref, please let me know and I'll investigate.
Best,
-Don
Martin Paul wrote:
With
today's patchdiag.xref ("AS OF Jul/12/11") many patches have
disappeared from the file.
At a quick glance, it seems that it affects patches for old Solaris
versions (up to Solaris 7), patches for old unbundled software and
nearly all of the over 5000 unbundled "PTF/RMLS" patches. There are too
many diffs to check all of them manually, but I'm pretty sure that no
patches for reasonably recent software is affected.
Maybe Don can provide more detail, on which groups of patches have been
removed and why?
BTW - a quick comparison of the runtime of a typical PCA command shows
a speedup of about 40%, due to the reduced number of patches to
analyze.
Martin.
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Re: [pca] patchdiag.xref shrunk
Don O'Malley wrote:
Hi Martin,
When we first migrated patch metadata to MOS (in June 2009) we
never included metadata for patches for products that were EOSL.
That should be June 2010!
As part of the recent MOS 5.3 release we have aligned patchdiag.xref
with the metadata available from MOS.
All of the patches that have disappeared have been for "housekeeping"
reasons, and IMO this is actually an improvement in patchdiag.xref.
We have endeavored to ensure that no dependency chains have been broken
in the cleanup, but if anyone spots any problems with the "cleaned"
patchdiag.xref, please let me know and I'll investigate.
Best,
-Don
Martin Paul wrote:
With
today's patchdiag.xref ("AS OF Jul/12/11") many patches have
disappeared from the file.
At a quick glance, it seems that it affects patches for old Solaris
versions (up to Solaris 7), patches for old unbundled software and
nearly all of the over 5000 unbundled "PTF/RMLS" patches. There are too
many diffs to check all of them manually, but I'm pretty sure that no
patches for reasonably recent software is affected.
Maybe Don can provide more detail, on which groups of patches have been
removed and why?
BTW - a quick comparison of the runtime of a typical PCA command shows
a speedup of about 40%, due to the reduced number of patches to
analyze.
Martin.
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] patchdiag.xref for CPU
Something that comes to mind as a good use for this if it were integrated into pca is a way to get around the problems associated with specifying a version of a patch that isn't in the current patchdiag.xref. As an example, say I want to install a back revision of the kernel patch, 144488-11. Currently if I were to do pca -i 144488-11, it wouldn't do any dependency checking and just try to install 144488-11. A new procedure would have pca download a copy of 144488-11, grab the dependency info from within the zip, replace the info in a temporary patchdiag.xref, and then do the normal dependency checks. This would take longer since it would have to pre-download patches before doing a final dependency check and possibly downloading some additional patches, but I don't see why it wouldn't work. On Fri, Jun 17, 2011 at 6:21 AM, Martin Paul mar...@par.univie.ac.atwrote: Jeff, Thanks a lot for giving the script a try and reporting the results. I'm surprised that it worked so fine on the first attempt. Using it with the Update cluster is an interesting application, too - good idea! I have now put the mkxref script on the Contrib section of the PCA webpage. If others use it and find any bugs, please let me know. If this proves to be useful and I get more feedback from other admins, I might later integrate the functionality into PCA itself. Martin. Jeff wrote: OK, I tested this and it works great. Using the patchdiag created from the CPU, I was able to download, install and reboot the server in the amount of time it would take me to copy the 2GB tarball and start extracting it, and instead of having to try installing each of the 200+ patches like the installcluster script, I installed only what I needed. A huge time savings, and the end results were the same patches got installed whether I used pca with the custom patchdiag or the installcluster script. I also tried the same thing using the Update 9 patch cluster. The patch cluster contains 648 patches, that was knocked down to 120 patches, so you can definitely see a huge timesavings there. Only thing I had to do was install patch 144401-09 manually, which is only available in the Update 9 cluster, not downloadable from MOS. That patch modifies the /etc/release file to reflect that you are running at the patch equivalent of Update 9. Awesome job Martin, great solution to the problem. On Thu, Jun 16, 2011 at 9:41 AM, Jeff variver...@gmail.com wrote: Just to add another thought. Another great use for this would be with the bundles that are created to patch to a update level rather then doing a LiveUpgrade. I'll try it against the Update 9 patch bundle and see what happens. On Thu, Jun 16, 2011 at 9:37 AM, Jeff variver...@gmail.com wrote: This is awesome Martin, my guess is it might make a patchdiag file more accurate then the real one since it would use the info that patchadd would use to decide if it needs to be installed. I'll give it a test and see if the results match if I installed the CPU from the bundled install scripts, but I think this is a great solution. On Thu, Jun 16, 2011 at 8:26 AM, Martin Paul mar...@par.univie.ac.at wrote: After the idea came up to create a special patchdiag.xref which only includes the patches of a Critical Patch Cluster (CPU), I couldn't resist and gave it a try. I downloaded the CPU OS Cluster 2011/04 Solaris 10 SPARC and hacked up a script (mkxref, see attachment) which extracts the necessary information from the patch READMEs, patchinfo and pkginfo files and creates a patchdiag.xref file. The idea is that this can then be used with PCA to patch systems to the state of the CPU without actually having to download the +2GB file (on every system). Take care: The script is mostly untested. It's hard to verify whether the patchdiag.xref it creates is 100% correct. It works with PCA, and I've compared a few sample patches with their entries in the real xref file, and they looked fine. The Recommended/Security flags are missing (they are not in the patchinfo file), but this shouldn't matter. I'm including both the script and the patchdiag.xref file I created from the above mentioned CPU. If anybody does some experiments with it, I'd be happy to hear about it. Theoretically, one can generate xref files for any set of patches with the script, which might be of use in other regards than with the CPU as well. Martin. -- Jeff -- Jeff -- Jeff
Re: [pca] patchdiag.xref for CPU
Jeff wrote: A new procedure would have pca download a copy of 144488-11, grab the dependency info from within the zip, replace the info in a temporary patchdiag.xref, and then do the normal dependency checks. Not that I wouldn't have thought about that before :) I'm not sure how practical it would be, though, as even with a local caching proxy this might take forever for patches with many requirements. And then I start thinking whether it wouldn't be better to cache the information, or even collect it centrally (so not every user has to extract it on his own), and then I end up thinking about what we really need: A master patchdiag.xref with all patch revisions. But Oracle doesn't produce it, and they most probably won't allow anybody else to compile (from patchinfo, or a collection of past xref files) and distribute it for legal reasons. Martin.
Re: [pca] patchdiag.xref for CPU
Maybe these guys can build and host it: http://sunsolve.espix.org/ They seem to be bringing back all the patch research functionality we lost when Oracle shutdown Sunsolve. Hopefully they don't get sued into oblivion, but since they don't host the patches, just point to them in MOS, they are probably OK. On Fri, Jun 17, 2011 at 10:23 AM, Martin Paul mar...@par.univie.ac.atwrote: Jeff wrote: A new procedure would have pca download a copy of 144488-11, grab the dependency info from within the zip, replace the info in a temporary patchdiag.xref, and then do the normal dependency checks. Not that I wouldn't have thought about that before :) I'm not sure how practical it would be, though, as even with a local caching proxy this might take forever for patches with many requirements. And then I start thinking whether it wouldn't be better to cache the information, or even collect it centrally (so not every user has to extract it on his own), and then I end up thinking about what we really need: A master patchdiag.xref with all patch revisions. But Oracle doesn't produce it, and they most probably won't allow anybody else to compile (from patchinfo, or a collection of past xref files) and distribute it for legal reasons. Martin. -- Jeff
Re: [pca] patchdiag.xref for CPU
Martin, It's called the Ops Center (or UCE) Knowledge Base, for which you have spend large sums of money. And then it isn't always right either. John
Re: [pca] patchdiag.xref for CPU
Just to add another thought. Another great use for this would be with the bundles that are created to patch to a update level rather then doing a LiveUpgrade. I'll try it against the Update 9 patch bundle and see what happens. On Thu, Jun 16, 2011 at 9:37 AM, Jeff variver...@gmail.com wrote: This is awesome Martin, my guess is it might make a patchdiag file more accurate then the real one since it would use the info that patchadd would use to decide if it needs to be installed. I'll give it a test and see if the results match if I installed the CPU from the bundled install scripts, but I think this is a great solution. On Thu, Jun 16, 2011 at 8:26 AM, Martin Paul mar...@par.univie.ac.atwrote: After the idea came up to create a special patchdiag.xref which only includes the patches of a Critical Patch Cluster (CPU), I couldn't resist and gave it a try. I downloaded the CPU OS Cluster 2011/04 Solaris 10 SPARC and hacked up a script (mkxref, see attachment) which extracts the necessary information from the patch READMEs, patchinfo and pkginfo files and creates a patchdiag.xref file. The idea is that this can then be used with PCA to patch systems to the state of the CPU without actually having to download the +2GB file (on every system). Take care: The script is mostly untested. It's hard to verify whether the patchdiag.xref it creates is 100% correct. It works with PCA, and I've compared a few sample patches with their entries in the real xref file, and they looked fine. The Recommended/Security flags are missing (they are not in the patchinfo file), but this shouldn't matter. I'm including both the script and the patchdiag.xref file I created from the above mentioned CPU. If anybody does some experiments with it, I'd be happy to hear about it. Theoretically, one can generate xref files for any set of patches with the script, which might be of use in other regards than with the CPU as well. Martin. -- Jeff -- Jeff
Re: [pca] patchdiag.xref for CPU
OK, I tested this and it works great. Using the patchdiag created from the CPU, I was able to download, install and reboot the server in the amount of time it would take me to copy the 2GB tarball and start extracting it, and instead of having to try installing each of the 200+ patches like the installcluster script, I installed only what I needed. A huge time savings, and the end results were the same patches got installed whether I used pca with the custom patchdiag or the installcluster script. I also tried the same thing using the Update 9 patch cluster. The patch cluster contains 648 patches, that was knocked down to 120 patches, so you can definitely see a huge timesavings there. Only thing I had to do was install patch 144401-09 manually, which is only available in the Update 9 cluster, not downloadable from MOS. That patch modifies the /etc/release file to reflect that you are running at the patch equivalent of Update 9. Awesome job Martin, great solution to the problem. On Thu, Jun 16, 2011 at 9:41 AM, Jeff variver...@gmail.com wrote: Just to add another thought. Another great use for this would be with the bundles that are created to patch to a update level rather then doing a LiveUpgrade. I'll try it against the Update 9 patch bundle and see what happens. On Thu, Jun 16, 2011 at 9:37 AM, Jeff variver...@gmail.com wrote: This is awesome Martin, my guess is it might make a patchdiag file more accurate then the real one since it would use the info that patchadd would use to decide if it needs to be installed. I'll give it a test and see if the results match if I installed the CPU from the bundled install scripts, but I think this is a great solution. On Thu, Jun 16, 2011 at 8:26 AM, Martin Paul mar...@par.univie.ac.atwrote: After the idea came up to create a special patchdiag.xref which only includes the patches of a Critical Patch Cluster (CPU), I couldn't resist and gave it a try. I downloaded the CPU OS Cluster 2011/04 Solaris 10 SPARC and hacked up a script (mkxref, see attachment) which extracts the necessary information from the patch READMEs, patchinfo and pkginfo files and creates a patchdiag.xref file. The idea is that this can then be used with PCA to patch systems to the state of the CPU without actually having to download the +2GB file (on every system). Take care: The script is mostly untested. It's hard to verify whether the patchdiag.xref it creates is 100% correct. It works with PCA, and I've compared a few sample patches with their entries in the real xref file, and they looked fine. The Recommended/Security flags are missing (they are not in the patchinfo file), but this shouldn't matter. I'm including both the script and the patchdiag.xref file I created from the above mentioned CPU. If anybody does some experiments with it, I'd be happy to hear about it. Theoretically, one can generate xref files for any set of patches with the script, which might be of use in other regards than with the CPU as well. Martin. -- Jeff -- Jeff -- Jeff
[pca] patchdiag.xref from March 2009
Hi, Solaris 8 entered EOL phase 2 by 1st April 2009. Does anybody still have a patchdiag.xref from March 2009, where all the Solaris 8 Patches can be downloaded with a regular support contract? Ihsan -- ih...@dogan.ch http://blog.dogan.ch/
Re: [pca] patchdiag.xref from March 2009
On 04/ 8/11 09:00 AM, İhsan Doğan wrote: Solaris 8 entered EOL phase 2 by 1st April 2009. Does anybody still have a patchdiag.xref from March 2009, where all the Solaris 8 Patches can be downloaded with a regular support contract? Thanks to everybody who have sent me the file so quickly. Ihsan -- ih...@dogan.ch http://blog.dogan.ch/
Re: [pca] patchdiag.xref from March 2009
By the way, for some reason, April 10th 2009 was the last valid Sol 8 Xref file I can use. If you want that, I can send it over. -GGR -- Rajiv G Gunja Blog: http://ossrocks.blogspot.com 2011/4/8 İhsan Doğan ih...@dogan.ch On 04/ 8/11 09:00 AM, İhsan Doğan wrote: Solaris 8 entered EOL phase 2 by 1st April 2009. Does anybody still have a patchdiag.xref from March 2009, where all the Solaris 8 Patches can be downloaded with a regular support contract? Thanks to everybody who have sent me the file so quickly. Ihsan -- ih...@dogan.ch http://blog.dogan.ch/
[pca] patchdiag.xref from Mar 31st, 2009
I've been asked for a copy of patchdiag.xref from the date before the Solaris 8 Vintage support has been introduced. I don't have one myself, can anybody provide a copy (by personal e-mail)? I guess there should be a: ## PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF Mar/31/09 ## but anything a few days before/past that date would be fine, too. Martin.
Re: [pca] patchdiag.xref from Mar 31st, 2009
Martin Paul wrote: I've been asked for a copy of patchdiag.xref from the date before the Solaris 8 Vintage support has been introduced. I don't have one myself, can anybody provide a copy (by personal e-mail)? Got it, thanks to Dagobert and Rajiv! Martin.
[pca] patchdiag.xref
Just FYI - it seems as if updates to the patchdiag.xref have been suspended once again. The most recent file I get is: ## PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF Mar/20/09 ## Martin.
Re: [pca] patchdiag.xref
I'll follow up... Best, -Don Martin Paul wrote: Just FYI - it seems as if updates to the patchdiag.xref have been suspended once again. The most recent file I get is: ## PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF Mar/20/09 ## Martin.
Re: [pca] patchdiag.xref
Hi All, The patchdiag.xref file is up to date again. Sorry for any inconvenience. Best, -Don Don O'Malley wrote: I'll follow up... Best, -Don Martin Paul wrote: Just FYI - it seems as if updates to the patchdiag.xref have been suspended once again. The most recent file I get is: ## PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF Mar/20/09 ## Martin.
Re: [pca] patchdiag.xref changes
On Wed, 15 Oct 2008, Laurent Blume wrote: ; Hi all, ; ; I've noticed that patchdiag.xref hasn't been updated in a week, and ; wondered if it's related to the planned changes: I'd assumed it was due to Solaris 10u6 being very imminent (this week hopefully!). That's also presumably why there have only been half a dozen Solaris 10 patches over the last month.
Re: [pca] patchdiag.xref changes
Laurent Blume wrote: With the release of SunSolve in October 2008, ... This sounds like a bigger change on sunsolve.sun.com, so this really might be the root cause. I've sent a message to Gerry Haskins, but he's currently out of the office. Thanks for the link to the InfoDoc - I didn't know that it existed. Martin.
[pca] patchdiag.xref -- got all versions
Hello, Thank you all for sending me you patchdiag files. I have the files from those 2 days I want. I have started archive all new patchdiag.xref files released by SUN. If anyone needs from a particular date to comply with their OS or company needs, please drop me a line. Thanks -GGR --- Rajiv G Gunja
[pca] patchdiag.xref
Hello, This might come across as a strange request: If anyone has archived their patchdiag.xref file from SUN, I need this file at two different dates: 1. Around Feb 28th 2008 2. Around May 31st 2008 Thanks in advance. -GGR --- Rajiv G Gunja
