Hi all, I just update libreoffice to 5.0.4.2 but revdep-rebuild wants to rebuild it. If I use revdep-rebuild.sh it doen't show up. Thanks Reproducible: Always Steps to Reproduce: 1. 2. 3.revdep-rebuild
Created attachment 419930 [details] emerge --info
Is revdep-rebuild searching for libjawt.so (revdep-rebuild -v)? I have the same problem. Trying to find out why...
Seems to be a recurring problem with libreoffice (not finding libjawt.so), see for example quite similar bugs #470804 and #253956
revdep-rebuild -v * This is the new python coded version * Please report any bugs found using it. * The original revdep-rebuild script is installed as revdep-rebuild.sh * Please files bugs at: https://bugs.gentoo.org/ * Found a valid cache, skipping collecting phase * Scanning files * Checking dynamic linking consistency * Broken files that requires: libjawt.so (64 bits) * /usr/lib64/libreoffice/program/libofficebean.so * Assign files to packages * /usr/lib64/libreoffice/program/libofficebean.so -> app-office/libreoffice-5.0.4.2 emerge --verbose --oneshot --complete-graph=y app-office/libreoffice:0 These are the packages that would be merged, in order: Calculating dependencies \... done!
I'm having the same problem with "revdep-rebuild". Revdep-rebuild.sh works OK. Gerard.
I have the same problem. The broken library libofficebean.so # ldd /usr/lib64/libreoffice/program/libofficebean.so linux-vdso.so.1 (0x00007ffee9d95000) libjawt.so => not found libc.so.6 => /lib64/libc.so.6 (0x00007f03b501d000) /lib64/ld-linux-x86-64.so.2 (0x000055c007558000) But libjawt.so exists: # locate libjawt.so /opt/icedtea-bin-7.2.5.5/jre/lib/i386/libjawt.so /opt/icedtea-bin-7.2.6.3/jre/lib/amd64/libjawt.so /opt/oracle-jdk-bin-1.8.0.45/jre/lib/i386/libjawt.so /opt/oracle-jdk-bin-1.8.0.45/lib/i386/libjawt.so /opt/oracle-jdk-bin-1.8.0.66/jre/lib/amd64/libjawt.so /opt/oracle-jdk-bin-1.8.0.66/lib/amd64/libjawt.so /usr/gnu-classpath-0.98/lib/classpath/libjawt.so So libjawt.so is not in the search path. As a workaround, I added the line LDPATH='/usr/gnu-classpath-0.98/lib/classpath/' to a file in "/etc/env.d/" and ran "env-update".
It seems that libjawt.so is "masked" according to "/etc/revdep-rebuild/60-java" LD_LIBRARY_MASK="libjvm.so libjawt.so" The python revdep-rebuild reads the same directory but there could be a bug in the masking logic.
i have same problem too
*** Bug 569658 has been marked as a duplicate of this bug. ***
Same problem for me. I just have one jdk installed: kong ~ # eselect java-vm list Available Java Virtual Machines: [1] oracle-jdk-bin-1.8 system-vm (In reply to email200202 from comment #7) > It seems that libjawt.so is "masked" according to > "/etc/revdep-rebuild/60-java" > > LD_LIBRARY_MASK="libjvm.so libjawt.so" I tried these three changes to that file, but I still see the bug: LD_LIBRARY_MASK="libjvm.so" LD_LIBRARY_MASK="libjjawt.so" LD_LIBRARY_MASK="" I also tried putting this in the environment, with no luck: # LD_LIBRARY_MASK="libjvm.so libjawt.so" revdep-rebuild --ipv So I'm guessing the mask does not work in the new revdep-rebuild. I tried the python 2.7 and 3.5 flavors of revdep-rebuild, same results. LD_LIBRARY_MASK is used in settings.py: kong ~ # fgrep LD_LIBRARY_MASK /usr/lib64/python2.7/site-packages/gentoolkit/revdep_rebuild/ -r /usr/lib64/python2.7/site-packages/gentoolkit/revdep_rebuild/settings.py: masked_files = os.environ.get('LD_LIBRARY_MASK', '') /usr/lib64/python2.7/site-packages/gentoolkit/revdep_rebuild/settings.py: match = re.match('LD_LIBRARY_MASK=\\"([^"]+)\\"', line) LD_LIBRARY_MASK ends up in the var masked_files, which is used in cache.py, collect.py and analyse.py. If I run in debug mode, I see masked_files is set correctly: # revdep-rebuild -ipvd [...] analyse(), masked files: libjava.so libjawt.so libjvm.so libodbc.so libodbcinst.so [...] But no being used properly: [...] * Checking dynamic linking consistency analyse(), Searching for 30195 libs, bins within 38738 libraries and links LibCheck.__init__(), new searchlibs: ['32', '64'] LibCheck.search(), Checking for broken 32 bit libs LibCheck.search(), Checking for broken 64 bit libs LibCheck.search(); FOUND: 64bit, libjawt.so, /usr/lib64/libreoffice/program/libofficebean.so [...] The problem, in 2.7, would seem to be around analyze.py lines 348-355, which call LibCheck() and libcheck.search() and those do not seem to use the masked_files var. Maybe some python savvy person can fix it from there.
Created attachment 421384 [details, diff] masked_file patch Looking at the code, it appears that masked_files were not added together with the masked_dirs for passing in to the collect* functions. My system is consistent except for revdep reporting bacula breakage. I only installed it due to another bug report about it never being fixed on rebuild. Th e patch I am attaching does not fix it's problems even with adding the library in question to the mask. It may be due to too many indirection symlinks that revdep can not/will not follow. For those of you in this bug, please try my attached patch. If it clears things for you. I will commit and push it.
(In reply to Brian Dolbec from comment #11) > Created attachment 421384 [details, diff] [details, diff] > masked_file patch I applied the patch by hand to this file: /usr/lib64/python2.7/site-packages/gentoolkit/revdep_rebuild/analyse.py It will not run for me: kong revdep_rebuild # revdep-rebuild -ipv * This is the new python coded version * Please report any bugs found using it. * The original revdep-rebuild script is installed as revdep-rebuild.sh * Please files bugs at: https://bugs.gentoo.org/ * Collecting system binaries and libraries * Collecting dynamic linking informations Traceback (most recent call last): File "/usr/lib/python-exec/python2.7/revdep-rebuild", line 40, in <module> success = rebuild.main(rebuild.parse_options()) File "/usr/lib64/python2.7/site-packages/gentoolkit/revdep_rebuild/rebuild.py", line 153, in main assigned, orphaned = analyse(settings, logger, _libs_to_check=_libs_to_check) File "/usr/lib64/python2.7/site-packages/gentoolkit/revdep_rebuild/analyse.py", line 345, in analyse (len(libraries), len(libraries_links), len(binaries)) TypeError: object of type 'NoneType' has no len()
I can only assume that you made a small error in your manually applied patch. All of those variable are initialized as a set() then added to and the final value returned to the calling function in analyse.py for example: brian@professor-x ~/Dev/git/gentoolkit $ python Python 3.4.3 (default, Dec 24 2015, 13:46:11) [GCC 5.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> s=set() >>> len(s) 0 >>> brian@professor-x ~/Dev/git/gentoolkit $ python2.7 Python 2.7.11 (default, Dec 24 2015, 13:43:39) [GCC 5.3.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> s=set() >>> len(s) 0 >>> so you should not get that error unless you made a mistake somewhere, modifying the results.
Created attachment 421390 [details] modified analyse.py I've attached my modified file here for your convenience. Just replace the existing file you are getting the error from. If you still get that error, there must be some other corruption causing it. Please re-emerge gentoolkit and re-try the patched file
(In reply to Brian Dolbec from comment #14) > Created attachment 421390 [details] > modified analyse.py > > I've attached my modified file here for your convenience. Just replace the > existing file you are getting the error from. > > If you still get that error, there must be some other corruption causing it. > Please re-emerge gentoolkit and re-try the patched file Same error: dagwood ~ # cp /tmp/analyse.py /usr/lib64/python2.7/site-packages/gentoolkit/revdep_rebuild/analyse.py dagwood ~ # md5sum /usr/lib64/python2.7/site-packages/gentoolkit/revdep_rebuild/analyse.py 4853129b953ad860da6b3dd7e7ac7d54 /usr/lib64/python2.7/site-packages/gentoolkit/revdep_rebuild/analyse.py dagwood ~ # revdep-rebuild -ipvd * This is the new python coded version * Please report any bugs found using it. * The original revdep-rebuild script is installed as revdep-rebuild.sh * Please files bugs at: https://bugs.gentoo.org/ main(), _libs_to_check = set([]) * Collecting system binaries and libraries analyse(), bin directories: /bin /etc/ssl/misc /lib /lib32 /lib64 /opt/android-sdk-update-manager/platform-tools /opt/android-sdk-update-manager/tools /opt/bin /opt/eagle/bin /sbin /usr/bin /usr/games/bin /usr/lib /usr/lib32 /usr/lib64 /usr/lib64/subversion/bin /usr/libexec /usr/sbin /usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0 analyse(), lib directories: /bin /lib /lib32 /lib64 /sbin /usr/bin /usr/games/lib /usr/games/lib32 /usr/games/lib64 /usr/lib /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0 /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/32 /usr/lib32 /usr/lib32/qt4 /usr/lib64 /usr/lib64/OpenCL/vendors/nvidia /usr/lib64/qt4 /usr/libexec /usr/local/lib /usr/local/lib32 /usr/local/lib64 /usr/sbin analyse(), masked directories: /lib/modules /lib32/modules /lib64/modules /opt/android-sdk-update-manager /opt/icedtea-bin-7.2.6.3 /opt/oracle-jdk-bin-1.8.0.66 analyse(), masked files: libjava.so libjawt.so libjvm.so libodbc.so libodbcinst.so time to complete task: 9 milliseconds * Collecting dynamic linking informations all_masks: /lib/modules /lib32/modules /lib64/modules /opt/android-sdk-update-manager /opt/icedtea-bin-7.2.6.3 /opt/oracle-jdk-bin-1.8.0.66 libjava.so libjawt.so libjvm.so libodbc.so libodbcinst.so Exception collecting libraries: [Errno 2] No such file or directory: '/usr/games/lib32' Exception collecting libraries: [Errno 2] No such file or directory: '/usr/games/lib' Exception collecting libraries: [Errno 2] No such file or directory: '/usr/games/lib64' time to complete task: 7605 milliseconds Traceback (most recent call last): File "/usr/lib/python-exec/python2.7/revdep-rebuild", line 40, in <module> success = rebuild.main(rebuild.parse_options()) File "/usr/lib64/python2.7/site-packages/gentoolkit/revdep_rebuild/rebuild.py", line 153, in main assigned, orphaned = analyse(settings, logger, _libs_to_check=_libs_to_check) File "/usr/lib64/python2.7/site-packages/gentoolkit/revdep_rebuild/analyse.py", line 344, in analyse (len(libraries), len(libraries_links), len(binaries)) TypeError: object of type 'NoneType' has no len()
I modified the test anaylyze.p to find the bad var. logger.debug('\tanalyse(), Found %i libraries' % (len(libraries)) ) logger.debug('\tanalyse(), (+%i symlinks) ' % ( len(libraries_links)) ) logger.debug('\tanalyse(), and %i binaries' % (len(binaries)) ) Same rsult, but now I know it is binaries that is empty: time to complete task: 6294 milliseconds analyse(), Found 29486 libraries analyse(), (+8261 symlinks) Traceback (most recent call last): File "/usr/lib/python-exec/python2.7/revdep-rebuild", line 40, in <module> success = rebuild.main(rebuild.parse_options()) File "/usr/lib64/python2.7/site-packages/gentoolkit/revdep_rebuild/rebuild.py", line 153, in main assigned, orphaned = analyse(settings, logger, _libs_to_check=_libs_to_check) File "/usr/lib64/python2.7/site-packages/gentoolkit/revdep_rebuild/analyse.py", line 350, in analyse (len(binaries)) TypeError: object of type 'NoneType' has no len()
Wondering how this bug can still have an UNCONFIRMED status??
At this moment bug still exist for me too, so I'm using revdep-rebuild.sh, because python version unusable. Constantly rebuilding libreoffice looks like bad joke.
C'mon guys - bug seen by many, reported last year, and still listed as UNCONFIRMED? Is there not some protocol in place to move bugs along the status path on a timely basis?
This is the same issue reported in bug #568480 but I won't close this as a duplicate as I believe other issues are being discussed there too.
well, unfortunately, the person that did most of the python revdep work is not available. The other members of our team are also very busy with real life, work and/or health issues. Couple that with other projects also taking up my time. I have not had the time to dedicate to tracing all the issues with library masking and the differences in the scan tools used. If anyone is able to do this troubleshooting, we appreciate any help and patches given. Thank you.
(In reply to Brian Dolbec from comment #21) > I have not had the time to dedicate to tracing all the > issues with library masking and the differences in the scan tools used. > > If anyone is able to do this troubleshooting, we appreciate any help and > patches given. I did say in the other bug that I have found the precise cause and it's nothing hairy like the scan tools. It's simply that LD_LIBRARY_MASK is being ignored entirely.
ah, Sorry, I've had too many different things going on... I did find some of the trouble with masks, but have not had the time to work on it more again. I know they are not being honored, but I haven't figured out why yet. That is something I don't have enough time for during my work week (too many new code bases lately, hard for the brain to keep switching). It'll take a weekend to get back into that code base again to find and fix it.
*** Bug 585396 has been marked as a duplicate of this bug. ***
*** Bug 585480 has been marked as a duplicate of this bug. ***
That's two more duplicates in two days. Would someone *please* do something about this? It affects many users.
Created attachment 437034 [details] analyse.py
Please update your analyse.py with file I've attached, and let us know if that would help.
(In reply to Sławek Lis from comment #28) > Please update your analyse.py with file I've attached, and let us know if > that would help. That does indeed fix the problem, thank you.
*** Bug 586048 has been marked as a duplicate of this bug. ***
Just to pile on. The analyse.py fixed the issue I have been having with revdep-rebuild as well.
(In reply to B Nice from comment #31) > Just to pile on. The analyse.py fixed the issue I have been having with > revdep-rebuild as well. Confirmed, fixes the problem here,too! COULD SOMEONE FINALLY FIX AND UPDATE THE GENTOOLKIT PACKAGE? Pretty please?
yes, we will. There is just a few more fixes in the pipeline to finish and commit.
I appear to have the same problem with openoffice-bin. The older revdep-rebuild.sh does not suggest rebuilding it, but: # revdep-rebuild -pv * This is the new python coded version * Please report any bugs found using it. * The original revdep-rebuild script is installed as revdep-rebuild.sh * Please file bugs at: https://bugs.gentoo.org/ * Collecting system binaries and libraries * Collecting dynamic linking informations * Scanning files * Checking dynamic linking consistency * Broken files that require: libgstinterfaces-0.10.so.0 (64 bits) * /usr/lib64/openoffice/program/libavmediagst.so * Broken files that require: libgstreamer-0.10.so.0 (64 bits) * /usr/lib64/openoffice/program/libavmediagst.so * Broken files that require: libjawt.so (64 bits) * /usr/lib64/openoffice/program/libofficebean.so * Broken files that require: libdb-4.3.so (64 bits) * /usr/lib64/openoffice/program/python-core-2.7.6/lib/lib-dynload/_bsddb.so * /usr/lib64/openoffice/program/python-core-2.7.6/lib/lib-dynload/dbm.so * Assign files to packages * /usr/lib64/openoffice/program/python-core-2.7.6/lib/lib-dynload/dbm.so -> app-office/openoffice-bin-4.1.7 * /usr/lib64/openoffice/program/python-core-2.7.6/lib/lib-dynload/_bsddb.so -> app-office/openoffice-bin-4.1.7 * /usr/lib64/openoffice/program/libofficebean.so -> app-office/openoffice-bin-4.1.7 * /usr/lib64/openoffice/program/libavmediagst.so -> app-office/openoffice-bin-4.1.7 emerge --pretend --verbose --oneshot --complete-graph=y app-office/openoffice-bin:0 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] app-office/openoffice-bin-4.1.7::gentoo USE="-gnome -java" L10N="-ast -bg -ca -ca-valencia -cs -da -de -el -en-GB -es -eu -fi -fr -gd -gl -he -hi -hu -it -ja -km -ko -lt -nb -nl -pl -pt -pt-BR -ru -sk -sl -sr -sv -ta -th -tr -vi -zh-CN -zh-TW" PYTHON_SINGLE_TARGET="python2_7" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB