Summary: | webapp-config-1.50.x method to determine libdir on multilib capable arches is b0rked | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | kfm |
Component: | [OLD] Unspecified | Assignee: | Gentoo Web Application Packages Maintainers <web-apps> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | ragnaroc |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info output
webapp-config-1.50.12-multilib.patch |
Description
kfm
2006-03-05 16:59:13 UTC
Created attachment 81471 [details]
emerge --info output
emerge --info output from the affected system
Hi Kerin! Thanks for the report. This problem is not related to the /var/db/webapps issue. The problem here is the way we initialize the sandbox. webapp-config currently does the following: self.__path = ['/usr/lib/libsandbox.so', '/lib/libsandbox.so'] and at a later point: for i in self.__path: if os.access(i, os.R_OK): self.sandbox = i break So it checks the two paths above for presence of the library. I am no amd64 user but if I understand it correctly, your libdir is /usr/lib64 right? While we could probably add this to our list of paths it would be a bad hack. I looked at the webapp-config-1.11 fix you suggested for amd64 and it looks like we would just need to retrieve the value of ABI from portage. We access the portage settings in webapp-config anyhow and so I added the following section to the portage wrapper: if 'ABI' in portage.settings.keys(): config_abi = portage.settings['ABI'] else: config_abi = '/usr/lib' And this to the sandbox wrapper: self.__path = ['/usr/lib/libsandbox.so', '/lib/libsandbox.so', config_abi + '/libsandbox.so'] I added these fixes as webapp-config-1.50.12 to the tree. Can you re-test? In case I based this fix on false assumptions I'd be happy about a correction :) Hi Gunnar. Thanks for your help on this but unfortunately the changes don't quite make the cut. ABI can be used to determine the variable which must be read but does not, in itself, contain the correct name of the libdir. However, you've given me sufficient insight to knock up something which I think is suitable for inclusion :) The attached patch makes the routine work as follows (pretty much the same way as I suggested in bug 120532): if 'ABI' in portage.settings.keys(): config_abi = portage.settings['ABI'] if 'LIBDIR_' + config_abi in portage.settings.keys(): config_libdir = '/usr/' + portage.settings['LIBDIR_' + config_abi] else: # This shouldn't happen but we want to know if it ever does OUT.die('Failed to determine libdir from portage.settings[\'LIBDIR_' + config_abi + '\']\n') else: config_libdir = '/usr/lib' That's actually enough to fix it but the patch also re-works the sandbox wrapper so that it looks like: self.__path = [config_libdir + '/libsandbox.so', '/usr/lib/libsandbox.so', '/lib/libsandbox.so'] This doesn't make it any more or less reliable. It just shunts the value of config_libdir to the front (because 99.99% of the time we should now avoid iterating through to the 2nd or 3rd items in that list now). For example, in my problematic amd64 case the list will evaluate as [ '/usr/lib64/libsandbox.so', '/usr/lib/libsandbox.so', '/lib/libsandbox.so' ] which is good. And in the case of, say, x86 it will be [ '/usr/lib/libsandbox.so', '/usr/lib/libsandbox.so', '/lib/libsandbox.so' ] which looks a bit odd but it will still hit it on the first pass. Anyhow, after applying this patch it works well here. What do you think? Created attachment 81555 [details, diff]
webapp-config-1.50.12-multilib.patch
Here it is - thanks for the help in tracking it down.
*** Bug 125032 has been marked as a duplicate of this bug. *** Great! Thanks for the patch. I added webapp-config-1.50.13 to the tree. If you confirm that it works on amd64 I'll start a second round of webapp-config stabilization :) Tested and yes, it works fine. I don't have any further gripes now ;) |