Summary: | app-portage/gentoolkit-0.3.2-r1: new revdep-rebuild: false positive !!! Broken orphaned files | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Yarda <zbox> |
Component: | Current packages | Assignee: | Portage Tools Team <tools-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | jstein, norman.shulman |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Content of /etc/revdep-rebuild |
Description
Yarda
2016-12-29 20:12:20 UTC
Hmm, I'm interested in this error: !! Failed to read /var/db/pkg/x11-themes/vdr-channel-logos-0.2/CONTENTS !! Error was:'utf8' codec can't decode byte 0xea in position 1942: invalid continuation byte Please attach the file it mentions so we can see about fixing that. For the virtualbox ones, please list the contents of /etc/revdep-rebuild and in detail any files involved with virtualbox masks. Also please test the 0.3.3 release from earlier today. It fixed a number of revdep problems with masked directories being one of them. There is a chance it will be fixed in that version. (In reply to Brian Dolbec from comment #1) > Hmm, I'm interested in this error: > > !! Failed to read /var/db/pkg/x11-themes/vdr-channel-logos-0.2/CONTENTS > !! Error was:'utf8' codec can't decode byte 0xea in position 1942: invalid > continuation byte > > Please attach the file it mentions so we can see about fixing that. I filled this as another bug 604070. > > For the virtualbox ones, please list the contents of /etc/revdep-rebuild and > in detail any files involved with virtualbox masks. > > Also please test the 0.3.3 release from earlier today. It fixed a number of > revdep problems with masked directories being one of them. There is a > chance it will be fixed in that version. With 0.3.3 the virtualbox orphans seems to be fixed, but the following remains: !!! Broken orphaned files: No installed package was found for the following: * /usr/lib64/gcc/mipsel-unknown-linux-uclibc/4.1.2/libgcc_s.so.1 * /usr/lib64/gcc/mipsel-softfloat-linux-uclibc/4.1.2/libgfortran.so.1.0.0 * /usr/lib64/gcc/mipsel-unknown-linux-uclibc/4.1.2/libgfortran.so.1.0.0 * /usr/lib64/gcc/mipsel-unknown-linux-uclibc/4.1.2/libstdc++.so.6.0.8 * /usr/lib64/gcc/mipsel-softfloat-linux-uclibc/4.1.2/libstdc++.so.6.0.8 * /usr/lib64/gcc/mipsel-softfloat-linux-uclibc/4.1.2/libgcc_s.so.1 There is nothing to emerge. Exiting. Old revdep-rebuild doesn't complain. The above content were generated by 'crossdev'. Content of revdep-rebuild attached. It's probably bloated over time, but the crossdev dirs doesn't seem to be there. Maybe the crossdev dirs are hard-coded in old revdep-rebuild. Created attachment 457970 [details]
Content of /etc/revdep-rebuild
Seems the new revdep-rebuild doesn't deal with a crossdev environment: !!! Broken orphaned files: No installed package was found for the following: * /usr/lib64/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.4/libgomp.so.1.0.0 * /usr/lib64/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.4/libasan.so.1.0.0 * /usr/lib64/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.4/libstdc++.so.6.0.20 * /opt/android-sdk-update-manager/tools/lib64/gles_mesa/libGL.so.1 * /usr/lib64/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.3/libitm.so.1.0.0 * /opt/android-sdk-update-manager/tools/lib64/gles_mesa/libGL.so * /usr/lib64/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.4/libatomic.so.1.1.0 * /usr/lib64/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.3/libgomp.so.1.0.0 * /usr/lib64/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.3/libatomic.so.1.1.0 * /usr/lib64/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.3/libubsan.so.0.0.0 * /usr/lib64/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.3/libstdc++.so.6.0.20 * /usr/lib64/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.4/libitm.so.1.0.0 * /usr/lib64/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.3/libasan.so.1.0.0 * /usr/lib64/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.4/libubsan.so.0.0.0 There actually isn't any special code in revdep-rebuild.sh to handle the crossdev environment. I'm thinking the difference is actually due to it being based off of ldd instead of scanelf to find the breakage. Can you please run 'revdep-rebuild.sh --ignore --pretend --verbose' and put the output from the revdep-rebuild environment section in the bug, so I can confirm? If that is the case, then we will need to either mask the crossdev directories or figure out how we modify the directories that are searched in order to exclude them. (In reply to Paul Varner from comment #5) > There actually isn't any special code in revdep-rebuild.sh to handle the > crossdev environment. I'm thinking the difference is actually due to it > being based off of ldd instead of scanelf to find the breakage. > > Can you please run 'revdep-rebuild.sh --ignore --pretend --verbose' and put > the output from the revdep-rebuild environment section in the bug, so I can > confirm? > > If that is the case, then we will need to either mask the crossdev > directories or figure out how we modify the directories that are searched in > order to exclude them. # revdep-rebuild.sh --ignore --pretend --verbose * Configuring search environment for revdep-rebuild * Temporary cache files are located in /var/cache/revdep-rebuild revdep-rebuild environment: SEARCH_DIRS="/bin /lib /lib32 /lib64 /opt/android-ndk /opt/bin /opt/cuda/bin /opt/cuda/lib /opt/cuda/lib64 /opt/cuda/nvvm/lib64 /opt/fmodex/api/lib /opt/xxe /opt/xxe/bin /sbin /usr/bin /usr/games/bin /usr/games/lib /usr/games/lib32 /usr/games/lib64 /usr/lib /usr/libexec /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.4/32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/32 /usr/lib32 /usr/lib32/OpenCL/vendors/nvidia /usr/lib32/opengl/nvidia/lib /usr/lib64 /usr/lib64/fltk /usr/lib64/hamlib /usr/lib64/OpenCL/vendors/nvidia /usr/lib64/opengl/nvidia/lib /usr/lib64/qt4 /usr/local/lib /usr/local/lib32 /usr/local/lib64 /usr/qt/3 /usr/qt/3/bin /usr/qt/3/lib /usr/qt/3/lib32 /usr/qt/3/lib64 /usr/sbin /usr/x86_64-pc-linux-gnu/arm-unknown-linux-gnu/gcc-bin/4.2.4 /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.4 /usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-bin/4.2.4 /usr/x86_64-pc-linux-gnu/mipsel-softfloat-linux-uclibc/gcc-bin/4.1.2 /usr/x86_64-pc-linux-gnu/mipsel-unknown-linux-uclibc/gcc-bin/4.1.2" SEARCH_DIRS_MASK="/lib/modules /lib64/modules /opt/android-ndk /opt/android-sdk-update-manager /opt/icedtea-bin-3.1.0 /opt/icedtea-bin-7.2.6.8 /opt/oracle-jdk-bin-1.8.0.121 /usr/lib/seamonkey/components /usr/lib64/opera /usr/lib64/seamonkey /usr/lib64/seamonkey/components /usr/lib64/seamonkey-devel /usr/lib64/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack" LD_LIBRARY_MASK="libjava.so libjawt.so libjvm.so libodbcinst.so libodbc.so /usr/lib/seamonkey/plugin-container /usr/lib64/seamonkey/plugin-container" PORTAGE_ROOT="/" EMERGE_OPTIONS="" ORDER_PKGS="1" FULL_LD_PATH="1" * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 100% ] * Dynamic linking on your system is consistent... All done. revdep-rebuild environment: SEARCH_DIRS="/bin /lib /lib32 /lib64 /opt/Adobe/Reader9/Reader/intellinux/lib /opt/bin /sbin /usr/bin /usr/lib /usr/lib32 /usr/lib32/OpenCL/vendors/nvidia /usr/lib32/opengl/nvidia/lib /usr/lib32/qt4 /usr/lib64 /usr/lib64/OpenCL/vendors/nvidia /usr/lib64/opengl/nvidia/lib /usr/lib64/qt4 /usr/libexec /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/32 /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0 /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/32 /usr/local/lib /usr/local/lib32 /usr/local/lib64 /usr/sbin /usr/x86_64-pc-linux-gnu/armv7a-hardfloat-linux-gnueabihf/gcc-bin/4.9.4 /usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0" SEARCH_DIRS_MASK="/lib64/modules /lib/modules /opt/android-sdk-update-manager /opt/icedtea-bin-3.3.0 /opt/icedtea-bin-7.2.6.8 /usr/armv7a-hardfloat-linux-gnueabihf" LD_LIBRARY_MASK="libjava.so libjawt.so libjvm.so libodbcinst.so libodbc.so" PORTAGE_ROOT="/" EMERGE_OPTIONS="" ORDER_PKGS="1" FULL_LD_PATH="1" Thanks, that does confirm that revdep-rebuild.sh is working because of using ldd, the immediate solution is to add the crossdev directories to SEARCH_DIRS_MASK. This can be done by a user by adding the to make.conf or creating a file in /etc/revdep-rebuild that contains the paths to ignore. The long term solution is to have the crossdev ebuild create the /etc/revdep-rebuild file when installing the package. (In reply to Paul Varner from comment #8) > Thanks, that does confirm that revdep-rebuild.sh is working because of using > ldd, the immediate solution is to add the crossdev directories to > SEARCH_DIRS_MASK. > > This can be done by a user by adding the to make.conf or creating a file in > /etc/revdep-rebuild that contains the paths to ignore. > > The long term solution is to have the crossdev ebuild create the > /etc/revdep-rebuild file when installing the package. Thanks for info, it seems the error is harmless. Thus custom file in /etc/revdep-rebuild or just ignoring the error in short term should work. In long term it needs to be addressed. Fixing the crossdev to install /etc/revdep-rebuild is probably (according to my opinion) the most clean solution that will not introduce non-system ad hoc hacks. Well, it will not cover existing crossdev environments, but it's probably acceptable. (In reply to Paul Varner from comment #8) > Thanks, that does confirm that revdep-rebuild.sh is working because of using > ldd, the immediate solution is to add the crossdev directories to > SEARCH_DIRS_MASK. > > This can be done by a user by adding the to make.conf or creating a file in > /etc/revdep-rebuild that contains the paths to ignore. > > The long term solution is to have the crossdev ebuild create the > /etc/revdep-rebuild file when installing the package. Looks like the crossdev ebuild already created such a file: $ cat /etc/revdep-rebuild/05cross-armv7a-hardfloat-linux-gnueabihf SEARCH_DIRS_MASK=/usr/armv7a-hardfloat-linux-gnueabihf But it doesn't contain /usr/x86_64-pc-linux-gnu/armv7a-hardfloat-linux-gnueabihf I'll add it. Thanks. Also added /usr/lib64/gcc/armv7a-hardfloat-linux-gnueabihf |