[arch-general] ImportError: libssl.so.0.9.8: -- do I just rebuild the AUR packages?
Guys, After the latest openssl updates, the AUR packages for createrepo and repoview are failing. I know it must be the result of the openssl changes. My question is, "in situations like this do I just try rebuilding the AUR packages, or does the maintainer have to make updates to accommodate the changes?" The errors received are: Checking for presence of sqlite metadata in /home/backup/rpms/factory_11.0 sqlite metadata tables found --> updating Update of metadata (sqlite) --> Failed Signing the repository after update... OK Updating/Creating repoview index and HTML pages... Traceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 26, in <module> import rpm File "/usr/lib/python2.6/site-packages/rpm/__init__.py", line 7, in <module> from _rpm import * ImportError: libssl.so.0.9.8: cannot open shared object file: No such file or directory gpg: no default secret key: bad passphrase gpg: signing failed: bad passphrase Traceback (most recent call last): File "/usr/bin/repoview", line 46, in <module> from rpmUtils.miscutils import compareEVR File "/usr/lib/python2.6/site-packages/rpmUtils/miscutils.py", line 18, in <module> of which: "ImportError: libssl.so.0.9.8: cannot open shared object file: No such file or directory" seems to be the primary error. I am not familiar enough with openssl to know if this can be cured by a simple rebuild, a symlink, or whether the openssl changes were significant enough to require a reworking of the AUR package by the maintainer. What say the gurus? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Thu, Apr 15, 2010 at 12:02 PM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
Guys,
After the latest openssl updates, the AUR packages for createrepo and repoview are failing. I know it must be the result of the openssl changes. My question is, "in situations like this do I just try rebuilding the AUR packages, or does the maintainer have to make updates to accommodate the changes?"
The errors received are:
Checking for presence of sqlite metadata in /home/backup/rpms/factory_11.0
sqlite metadata tables found --> updating
Update of metadata (sqlite) --> Failed
Signing the repository after update... OK
Updating/Creating repoview index and HTML pages... Traceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 26, in <module> import rpm File "/usr/lib/python2.6/site-packages/rpm/__init__.py", line 7, in <module> from _rpm import * ImportError: libssl.so.0.9.8: cannot open shared object file: No such file or directory gpg: no default secret key: bad passphrase gpg: signing failed: bad passphrase Traceback (most recent call last): File "/usr/bin/repoview", line 46, in <module> from rpmUtils.miscutils import compareEVR File "/usr/lib/python2.6/site-packages/rpmUtils/miscutils.py", line 18, in <module>
of which:
"ImportError: libssl.so.0.9.8: cannot open shared object file: No such file or directory"
seems to be the primary error. I am not familiar enough with openssl to know if this can be cured by a simple rebuild, a symlink, or whether the openssl changes were significant enough to require a reworking of the AUR package by the maintainer. What say the gurus?
Same as any other so-name bump. It's AUR, so you'll need to rebuild the package yourself. If it fails because of an incompatibility with the new library, look for a patch or other fix. If no patch/fix can be found, bug report upstream.
On 04/15/2010 11:26 AM, dave reisner wrote:
On Thu, Apr 15, 2010 at 12:02 PM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
Guys,
After the latest openssl updates, the AUR packages for createrepo and repoview are failing.
<snip>
Same as any other so-name bump. It's AUR, so you'll need to rebuild the package yourself. If it fails because of an incompatibility with the new library, look for a patch or other fix. If no patch/fix can be found, bug report upstream.
Dave, DR, Thank you for your help. I solved the libssl issue by installing libssl-compatibility from AUR. However -- that brought to light another problem brought on by recent updates that moved libssl.so.25 to libssl.so.26. I've checked AUR and there isn't a compatibility package. The error received from the createrepo app was: [12:57 nirvana:/usr/lib] # createrepo -h Traceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 26, in <module> import rpm File "/usr/lib/python2.6/site-packages/rpm/__init__.py", line 7, in <module> from _rpm import * ImportError: libkrb5.so.25: cannot open shared object file: No such file or directory Crossing my fingers that the libraries would be backwards compatible for the purposes of 'createrepo', I just did: ln -s libkrb5.so.26 libkrb5.so.25 which did work with createrepo, but this feels like a cluge. In this situation, what is the proper solution? 'createrepo' is a python package (python is a snake to me), so do we grep on libkrb5.so.25 and change to 26? Do we issue a report or request for some type of compatibility package for libkrb5? Or did we just develop a compatibility package with the symlink? All help always appreciated, thanks :-) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Sat, Apr 17, 2010 at 2:05 PM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
Thank you for your help. I solved the libssl issue by installing libssl-compatibility from AUR. However -- that brought to light another problem brought on by recent updates that moved libssl.so.25 to libssl.so.26. I've checked AUR and there isn't a compatibility package. The error received from the createrepo app was:
[12:57 nirvana:/usr/lib] # createrepo -h Traceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 26, in <module> import rpm File "/usr/lib/python2.6/site-packages/rpm/__init__.py", line 7, in <module> from _rpm import * ImportError: libkrb5.so.25: cannot open shared object file: No such file or directory
Crossing my fingers that the libraries would be backwards compatible for the purposes of 'createrepo', I just did:
ln -s libkrb5.so.26 libkrb5.so.25
which did work with createrepo, but this feels like a cluge. In this situation, what is the proper solution? 'createrepo' is a python package (python is a snake to me), so do we grep on libkrb5.so.25 and change to 26? Do we issue a report or request for some type of compatibility package for libkrb5? Or did we just develop a compatibility package with the symlink?
Symlinking so's is unadvisable as it's bound to get you in trouble sooner or later -- clearly in your case it's sooner. The only reason I can think of to install a compatibility package is one of two reasons: 1) The package is a closed source binary and you're waiting for upstream to rebuild it for you. 2) The package won't build against the new .so and you're waiting for a patch from upstream. Is one of these stopping you from rebuilding the package rather than applying all manner of bandaids? d
On 04/17/2010 01:14 PM, dave reisner wrote: <snip>
Symlinking so's is unadvisable as it's bound to get you in trouble sooner or later -- clearly in your case it's sooner.
The only reason I can think of to install a compatibility package is one of two reasons:
1) The package is a closed source binary and you're waiting for upstream to rebuild it for you. 2) The package won't build against the new .so and you're waiting for a patch from upstream.
Is one of these stopping you from rebuilding the package rather than applying all manner of bandaids?
None of the above... Lack of knowledge of python is stopping me from rebuilding and has me applying all manner of bandaids :p Seriously, though, the createrepo package in AUR is the development version and cannot be used. I am using the last stable version of createrepo (4.11) from: http://createrepo.baseurl.org/ <quote> Get Createrepo ΒΆ * createrepo: o 0.4.11 - Latest 'stable' series o 0.9.8 - Latest 'development' series - Requires yum >= 3.2.23 </quote> So that leaves me with just the python source for the stable version which I have no idea how to patch or fix (thus the comment "python is a snake to me" earlier :). If it were c based, then I'd have at least a 50/50 shot at being able to locate where the problem is. So, I guess I'm looking for suggestions. If I can just search the python code for where the library gets called and change it to look for the new library (which is working perfectly with the sym link so it is evidently compatible with the new lib), then I think I can just fix it. I updated my rpm repository of just over 6200 rpms and it worked just fine. If this is also not advisable, then I'm kinda stuck. What do you suggest? With a bit of guidance to get me pointed in the right direction with this python package, I think I can get this thing done correctly. If so, maybe we can add the stable release of createrepo to AUR. What's the Cliff's notes version of what you do to cure a python problem like this? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On 04/15/2010 12:02 PM, David C. Rankin wrote:
Guys,
After the latest openssl updates, the AUR packages for createrepo and repoview are failing. I know it must be the result of the openssl changes.
"ImportError: libssl.so.0.9.8: cannot open shared object file: No such file or directory"
seems to be the primary error. I am not familiar enough with openssl to know if this can be cured by a simple rebuild, a symlink, or whether the openssl changes were significant enough to require a reworking of the AUR package by the maintainer. What say the gurus?
I don't know those packages, so can't speak intelligently about them specifically. As to the general question, though: 1) Try rebuilding the packages. If you're lucky they'll build against the new ssl. 2) If not, install the openssl-compatibility package from AUR. It provides openssl 0.9.8. Repeat step 1. And of course if you had to resort to step 2, you should probably enter a comment on the packages' AUR pages about the problem. HTH, DR
On Thu, Apr 15, 2010 at 11:02:55AM -0500, David C. Rankin wrote:
Traceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 26, in <module> import rpm File "/usr/lib/python2.6/site-packages/rpm/__init__.py", line 7, in <module> from _rpm import * ImportError: libssl.so.0.9.8: cannot open shared object file: No such file or directory
It looks like the python bindings for rpm are broken, you'll probably want to rebuild whatever package owns /usr/lib/python2.6/site-packages/rpm/__init__.py. -- Byron Clark
On 04/17/2010 02:09 PM, Byron Clark wrote:
On Thu, Apr 15, 2010 at 11:02:55AM -0500, David C. Rankin wrote:
Traceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 26, in <module> import rpm File "/usr/lib/python2.6/site-packages/rpm/__init__.py", line 7, in <module> from _rpm import * ImportError: libssl.so.0.9.8: cannot open shared object file: No such file or directory
It looks like the python bindings for rpm are broken, you'll probably want to rebuild whatever package owns /usr/lib/python2.6/site-packages/rpm/__init__.py.
Thanks Byron, The issue ended up being a new libssl version. Thankfully there was a libssl-compatibility package in AUR that provided libssl.so.0.9.8. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Sat, Apr 17, 2010 at 05:59:33PM -0500, David C. Rankin wrote:
On 04/17/2010 02:09 PM, Byron Clark wrote:
On Thu, Apr 15, 2010 at 11:02:55AM -0500, David C. Rankin wrote:
Traceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 26, in <module> import rpm File "/usr/lib/python2.6/site-packages/rpm/__init__.py", line 7, in <module> from _rpm import * ImportError: libssl.so.0.9.8: cannot open shared object file: No such file or directory
It looks like the python bindings for rpm are broken, you'll probably want to rebuild whatever package owns /usr/lib/python2.6/site-packages/rpm/__init__.py.
Thanks Byron,
The issue ended up being a new libssl version. Thankfully there was a libssl-compatibility package in AUR that provided libssl.so.0.9.8.
That's one way to fix it. The other way is to rebuild rpm or whichever of its dependencies link to libssl.so. -- Byron Clark
On 04/17/2010 06:49 PM, Byron Clark wrote:
Thanks Byron,
The issue ended up being a new libssl version. Thankfully there was a libssl-compatibility package in AUR that provided libssl.so.0.9.8. That's one way to fix it. The other way is to rebuild rpm or whichever of its dependencies link to libssl.so.
That's where I have to get smarter and find out what tools I need to use to figure that answer out. Right now there are several dependencies for createrepo and I don't know which calls libssl or libkrb5: createrepo | +-- rpm | +-- yum-createrepo | +-- yum | +-- yum-metadata-parser | +-- python-iniparse I guess one way would just be to rebuild everything and see if it fixes it, but there has to be some debugging tool that can ID who calls what. What say the experts? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On 04/17/2010 08:44 PM, David C. Rankin wrote:
Thanks Byron,
<snip> I guess one way would just be to rebuild everything and see if it fixes it, but
On 04/17/2010 06:49 PM, Byron Clark wrote: there has to be some debugging tool that can ID who calls what. What say the experts?
I also posted to the list for createrepo to see if I could get an answer there: rpm-metadata@lists.baseurl.org -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Sat, Apr 17, 2010 at 08:44:09PM -0500, David C. Rankin wrote:
On 04/17/2010 06:49 PM, Byron Clark wrote:
Thanks Byron,
The issue ended up being a new libssl version. Thankfully there was a libssl-compatibility package in AUR that provided libssl.so.0.9.8. That's one way to fix it. The other way is to rebuild rpm or whichever of its dependencies link to libssl.so.
That's where I have to get smarter and find out what tools I need to use to figure that answer out. Right now there are several dependencies for createrepo and I don't know which calls libssl or libkrb5:
Here's one way to find out. The original error was thrown in /usr/lib/python2.6/site-packages/rpm/__init__.py. % pacman -Qo /usr/lib/python2.6/site-packages/rpm/__init__.py /usr/lib/python2.6/site-packages/rpm/__init__.py is owned by rpm 5.1.9-1
From the line that threw the exception, is looks like the rpm python module is importing a C extension module. Let's see if we can find it.
From there, just run ldd on /usr/lib/python2.6/site-packages/rpm/_rpmmodule.so. You'll find that it
% pacman -Ql rpm | grep python | grep .so$ rpm /usr/lib/python2.6/site-packages/rpm/_rpmmodule.so links to libssl and libkrb5. So, rebuild that rpm package and you should be able to get rid of libssl-compatibility. -- Byron Clark
On 18/04/10 11:44, David C. Rankin wrote:
On 04/17/2010 06:49 PM, Byron Clark wrote:
Thanks Byron,
The issue ended up being a new libssl version. Thankfully there was a libssl-compatibility package in AUR that provided libssl.so.0.9.8. That's one way to fix it. The other way is to rebuild rpm or whichever of its dependencies link to libssl.so.
That's where I have to get smarter and find out what tools I need to use to figure that answer out. Right now there are several dependencies for createrepo and I don't know which calls libssl or libkrb5:
createrepo | +-- rpm | +-- yum-createrepo | +-- yum | +-- yum-metadata-parser | +-- python-iniparse
I guess one way would just be to rebuild everything and see if it fixes it, but there has to be some debugging tool that can ID who calls what. What say the experts?
readelf -d $(pacman -Qql <pkg>) 2>/dev/null | grep libssl.so.0
On 04/17/2010 09:50 PM, Allan McRae wrote:
On 18/04/10 11:44, David C. Rankin wrote:
I guess one way would just be to rebuild everything and see if it fixes it, but there has to be some debugging tool that can ID who calls what. What say the experts?
readelf -d $(pacman -Qql <pkg>) 2>/dev/null | grep libssl.so.0
Allan, Byron, Thanks. Good to be with the smart guys :p -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
participants (5)
-
Allan McRae
-
Byron Clark
-
dave reisner
-
David C. Rankin
-
David Rosenstrauch