I've traced python calls to identify the exact issue:
In pm.py, the unzip command is called:
pm.py(62):                 cmdstr = "unzip -u %s -d %s" % (path, tdir)
pm.py(63):                 ret, x = commands.getstatusoutput(cmdstr)

This call returns correctly.
Then, still in pm.py, a ZipFile instance is created:
pm.py(65):                 if ret != 0:
pm.py(69):                 zf = zipfile.ZipFile(path)

And this call fails, as ZIP64 extensions are missing:
--- modulename: zipfile, funcname: __init__
zipfile.py(184):         if compression == ZIP_STORED:
zipfile.py(185):             pass
zipfile.py(192):         self.debug = 0  # Level of printing: 0 through 3
zipfile.py(193):         self.NameToInfo = {}    # Find file info given name
zipfile.py(194):         self.filelist = []      # List of ZipInfo instances for archive
zipfile.py(195):         self.compression = compression  # Method of compression
zipfile.py(196):         self.mode = key = mode.replace('b', '')[0]
zipfile.py(199):         if isinstance(file, basestring):
zipfile.py(200):             self._filePassed = 0
zipfile.py(201):             self.filename = file
zipfile.py(202):             modeDict = {'r' : 'rb', 'w': 'wb', 'a' : 'r+b'}
zipfile.py(203):             self.fp = open(file, modeDict[mode])
zipfile.py(209):         if key == 'r':
zipfile.py(210):             self._GetContents()
 --- modulename: zipfile, funcname: _GetContents
zipfile.py(229):         try:
zipfile.py(230):             self._RealGetContents()
 --- modulename: zipfile, funcname: _RealGetContents
zipfile.py(239):         fp = self.fp
zipfile.py(240):         endrec = _EndRecData(fp)
 --- modulename: zipfile, funcname: _EndRecData
zipfile.py(83):     fpin.seek(-22, 2)               # Assume no archive comment.
zipfile.py(84):     filesize = fpin.tell() + 22     # Get file size
zipfile.py(85):     data = fpin.read()
zipfile.py(86):     if data[0:4] == stringEndArchive and data[-2:] == "\000\000":
zipfile.py(87):         endrec = struct.unpack(structEndArchive, data)
zipfile.py(88):         endrec = list(endrec)
zipfile.py(89):         endrec.append("")               # Append the archive comment
zipfile.py(90):         endrec.append(filesize - 22)    # Append the record start offset
zipfile.py(91):         return endrec
zipfile.py(241):         if not endrec:
zipfile.py(243):         if self.debug > 1:
zipfile.py(245):         size_cd = endrec[5]             # bytes in central directory
zipfile.py(246):         offset_cd = endrec[6]   # offset of central directory
zipfile.py(247):         self.comment = endrec[8]        # archive comment
zipfile.py(249):         x = endrec[9] - size_cd
zipfile.py(251):         concat = x - offset_cd
zipfile.py(252):         if self.debug > 2:
zipfile.py(255):         self.start_dir = offset_cd + concat
zipfile.py(256):         fp.seek(self.start_dir, 0)
zipfile.py(257):         total = 0
zipfile.py(258):         while total < size_cd:
zipfile.py(259):             centdir = fp.read(46)
zipfile.py(260):             total = total + 46
zipfile.py(261):             if centdir[0:4] != stringCentralDir:
zipfile.py(262):                 raise BadZipfile, "Bad magic number for central directory"


I attach the part of the trace showing the error.

Created attachment 601912 [details]
Python trace when opening the zip file

One last comment, looking at pm.py code, I think the problem can be adressed in two ways.
The problem is in these lines:

cmdstr = "unzip -u %s -d %s" % (path, tdir)
ret, x = commands.getstatusoutput(cmdstr)

if ret != 0:
   raise UnzipException("patch %s: unzip of %s into %s failed: %s" % \
          pkg.name, path, tdir, x))
zf = zipfile.ZipFile(path)
pd = zf.namelist()[0].split('/')[0]
zf.close()
pkgdir = os.path.join(tdir, pd)

If I understand well, the ZipFile is only created to list the patches included in the patch cluster.
One note: this is time consuming! Just after launching unzip command, the code recreates zipfile object from a 2GB file!

In my point of view, it can be adressed in two ways:
1) upgrade to python 2.6 in /opt/redhat, and remove unzip command to use python 2.6 ZipFile.extract command, and then ZipFile.namelist()
2) using os module, it should be possible to create the pkglist

I cn test any patch to test the correction on my solaris test boxes

If the unzip extracts the content of the "path" zipfile to "tdir" directory, can't we get the list of the patches (the "pd") directly from the directory? Or perhaps do another call to unzip to do it for us?

This was my second proposition in comment number 3.
You've set the status to NEEDINFO. What information do you need from me?
All I can say is that when the client crashes, the complete archive has been extracted to tdir. So it should be possible to get a list of patches, without using ZipFile.

Well yes, I kinda asked what we can do with just unzip and that extracted directory. I don't have Solaris around so I'm just assuming here, looking at the code. Is the only purpose of that zf to get the name of the sole directory which should be in that zip?

OK, so I've been looking around a bit more.
ZipFile objects are used twice:
- in pm.py, the zf object is created only to get the name of the directory
- in loader.py, in function getPatchData, which is called only when a "patch" is detected

So, I've been doing some more tests.
1) I've extracted using unzip command the 10_recommended.zip file (the patch cluster so)
unzip -d /data/recom/ /tmp/10_Recommended.zip
ls -l /data/recom
drwxr-xr-x 3 casenovp casenovp 4096 Apr 13  2012 10_Recommended

2) I've been executing a sample python script with only this code:
zf = zipfile.ZipFile("/tmp/10_Recommended.zip")
pd = zf.namelist()[0].split('/')[0]
print pd
zf.close()

Which gives: 10_Recommended

This is equivalent to 
pd= os.listdir(tdir)
print pd[0]

If you are okay with this, I can modify pm.py on my setup to call os.listdir instead of creating the ZipFile object and try to deploy the patch cluster.

Nod, this is exactly what I had in mind.

At the same time, the

                if not os.path.isdir(pkgdir):
                    raise UnzipException( \
                        "patch %s contained more than 1 directory: %s" % \
                            (pkg.name, pkgdir))

part seems suspicious as well -- the patch contains more than one
directory exactly if the os.listdir returns multiple directory
entries. So it could benefit from the full os.listdir list too.

I'll modify the client code and get back to you ASAP (not before tomorrow though).
But I'm not sure I understood exactly your last point: do you want to modify the python code so that if os.listdir returns more than 1 directory, the exception is raised?
I can do that as well.

(In reply to comment #9)
> But I'm not sure I understood exactly your last point: do you want to modify
> the python code so that if os.listdir returns more than 1 directory, the
> exception is raised?

Yes, that's what that exception seems to be about.

I've implemented the corrections listed above:
pd= os.listdir(tdir)
pkgdir = os.path.join(tdir, pd)
if len(pd) > 1:
    raise UnzipException( \
           "patch %s contained more than 1 directory: %s" % \
                (pkg.name, pkgdir))

I attach the patch to the post.

And now, I get the following error:

D: Sending back response (102, "Patch cluster install failed: 'list' object has no attribute 'startswith'", {'version': 0, 'name': 'solarispkgs.patchClusterInstall'})

The unzip command went well and the process crashed further. I need to trace python once again to track down the issue!

Created attachment 649197 [details]
Patch to avoid using ZipFile

My patch was buggy in fact.
I attach the correct patch.
Could you regenerate the Solaris packages and the tar files at http://spacewalk.redhat.com/solaris/ ?

Created attachment 649550 [details]
Correct patch to avoid using ZipFile

(In reply to comment #14)
> Created attachment 649550 [details]
> Correct patch to avoid using ZipFile

Committed to Spacewalk master, 23b4dc4de7760f2ecda937cd08b3283f4c12064b.

Marking bug as ON_QA since tonight's build of Spacewalk nightly is a release candidate for Spacewalk 1.9.

The patch is in spacewalk master, but the issue is in the spacewalk Solaris clients.
The packages available for download on http://spacewalk.redhat.com/solaris/ have not been regenerated.
So the BZ is not completely corrected, until the .pkg files gets updated

Spacewalk 1.9 has been released.

https://fedorahosted.org/spacewalk/wiki/ReleaseNotes19