everytime i started revdep rebuild it starts to rebuild openoffice-bin(-1.1.0), even if it was rebuild by revdep. revdep-output: dd: warning: you do not have execution permission for `/opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/_tkinter.so' broken /opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/_tkinter.so (requires libtk8.3.so libtcl8.3.so) ldd: warning: you do not have execution permission for `/opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/bsddb.so' broken /opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/bsddb.so (requires libdb-3.1.so) ldd: warning: you do not have execution permission for `/opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/mpz.so' broken /opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/mpz.so (requires libgmp.so.3) done. Reproducible: Always Steps to Reproduce: 1. 2. 3.
This is a broken dependency issue - I have the same problem. Also, the execute bit should be set on these three files. I don't know what the libraries that this depends on are, but we could do with finding out...
Revdep rebuild searches it hardly everywhere. And tcl/tk-8.3 is not in unstable profile for about than half year. There are only two chances: 1) Library is provided in special way in normal binary (Java does it, bu I do not beleive it is the case). 2) Those libraries are really broken. In this case openoffice-bin ebuild is broken. I gues it is. Solutions: a) new updated binary package or b) install old tcl/tk to /opt/OpenOffice.org1.1.0 or c) these libraries are probably not essential (tk support in built in python) => remove them, if not needed.
The missing libraries belong to: =dev-lang/tcl-8.3* =dev-lang/tk-8.3* =sys-libs/db-3.1* dev-libs/gmp Unfortunately, there isn't a db-3.1* in portage any more. I've hacked together a db-3.1.17 ebuild, although this clearly is NOT an ideal solution, as many people will have db-3.2.9-r9 or db-3.2.9-r10 installed instead. I will attach an ebuild for app-office/openoffice-bin-1.1.0 as well as one for sys-libs/db-3.1.17. The openoffice-bin ebuild contains fixes for the broken dependencies and permissions. The db-3.1.17 ebuild is required, or the openoffice-bin ebuild is effectively useless. Note that everything compiles and works fine here - I've only tested this, however, on one machine. You'll need to rebuild the digest for sys-libs/db-3.1.17 too. If anyone has any problems with this, please reply here.
Created attachment 20358 [details] Updated ebuild for openoffice-bin-1.1.0
Created attachment 20359 [details] Ebuild for db-3.1.17 This ebuild is necessary for the openoffice-bin libdb-3.1.so dependency fix.
Oh, I should also point out that in the updated openoffice-bin ebuild, I've also added the fix described in bug #32492 for the sed script.
Any news on this one? It is installing a broken package into the stable profile here, so this should probably be fixed as a matter of some serious urgency...
*Bump* Is the problem with this fix the fact that it requires an ebuild for an outdated (if very stable) package to be shoved into portage in the stable profile? Really, though, this package is by no means stable for ANY arch when there are broken dependencies, as this breaks revdep-rebuild quite obviously. Any news?
openoffice-bin provides it's own libraries for many things, including those mentioned. In any case rebuilding it is pointless as it is a binary package.
It doesn't provide its own libraries for tcl, tk, db and gmp - otherwise, revdep-rebuild wouldn't be trying to update them would it? There is nothing wrong with this ebuild, as far as I can see - whilst things are obviously broken in the one currently in portage. What exactly are the objections to this updated ebuild?
openoffice-bin provides it's own version of db, building db-3.1.17 is not necessary, if anything this is a bug (or missing feature) in revdep-rebuild. So either we close this or hand it over to the Portage team
Weird. Are you absolutely sure about that? What is it that revdep-rebuild does that it shouldn't?
Basically it is caused by revdep-rebuild not knowing that openoffice uses it's own db. This is basically caused by the nature of the revdep-rebuild tool. Except real reverse dependency and rebuild support in portage there is probably not much that can be done against this except maybe adding some rule to revdep-rebuild to tell it openoffice-bin does not need to be rebuild (pointless anyway with binary packages)
*** Bug 42440 has been marked as a duplicate of this bug. ***
*** Bug 48389 has been marked as a duplicate of this bug. ***
For what it's worth, I'm working on a new, from-scratch revdep-rebuild that should eliminate the problems above.
I have a similar problem on my machine: revdep-rebuild rebuilds "opera" everytime I run it.
*** Bug 61189 has been marked as a duplicate of this bug. ***
Feel free to update LD_LIBRARY_MASK in revdep-rebuild for your needs. I am not any longer actively maintaining it.
Is this only a problem with revdep-rebuild, or is there also a problem with openoffice-bin-1.1.3 ? revdep-rebuild complains about three missing libraries, two are available in other versions, but one (libgmp.so.3) is missing alltogether. Does openoffice-bin lack a dependency for the latter, or does it just provide the files somewhere else? I have not noticed anything wrong with openoffice, but then this is a new machine and I have hardly used it yet. /Jakob
No, it's only a revdep rebuild error. It doesn't know that openoffice-bin is binary, and also uses it's own libraries. Openoffice has no problems, just be carefull with revdep-rebuild as it is not 100% correct.
*** Bug 77821 has been marked as a duplicate of this bug. ***
*** Bug 89599 has been marked as a duplicate of this bug. ***
FYI, this is now happening with openoffice-bin-1.9.128: broken /usr/lib/openoffice/program/python-core-2.3.4/lib/lib-dynload/_bsddb.so (requires libdb-3.1.so) broken /usr/lib/openoffice/program/python-core-2.3.4/lib/lib-dynload/bz2.so (requires libbz2.so.0) broken /usr/lib/openoffice/program/python-core-2.3.4/lib/lib-dynload/mpz.so (requires libgmp.so.3) broken /usr/lib/openoffice/program/python-core-2.3.4/lib/lib-dynload/_tkinter.so (requires libBLT24.so libtcl8.3.so libtk8.3.so) done. (/root/.revdep-rebuild.3_rebuild)
Does anyone know if there is any intent to fix revdep-rebuilds behavior in regards to binaries like this? This bug is almost two years old.
It is fixed in gentoolkit-0.2.1_pre7, although with the most recent openoffice-bin, you will need to add /usr/lib/openoffice to SEARCH_DIRS_MASK
@Paul: Could you please add /usr/lib/openoffice to the default SEARCH_DIRS_MASK this is going to be the new default install dir for OOo 2.0
Is /usr/lib/openoffice going to be used only by openoffice-bin? If the openoffice ebuild also uses that directory, then it isn't a good idea to have revdep-rebuild mask the directory by default for everybody.
/usr/lib/openoffice is going to be used by all OOo-ebuilds, true that this is a little bit of a problem. On the other hand, now both source and -bin use /opt/OpenOffice.org so this is the same situation. Don't know how to solve this, cause using different install dirs for -bin and source is not an option, as this would break the user install and complicate the switch between both versions
I am not much of Gentoo Developer, but I am fairly active at sending bugs and prodding here and there, occasionally doing my own ebuild. If I say nonsense, please disregard. Maybe a REVDEP_IGNORE=true (or maybe REVDEP_IGNORE="/opt/OpenOffice.org", also allowing multiple dirs and even specific files, for maximum flexibility) flag could be added to the bin ebuild. When revdep-rebuild runs, it will find the file, then look for all possible providers, excluding the REVDEP_IGNORE=true ebuilds. If no ebuilds who produce the file are found, it will do nothing. revdep-rebuild would be changed to look for this flag, as well as each ebuild.
Created attachment 69219 [details] 99revdep-rebuild Starting with the next release of gentoolkit. I will be reading variables from files in /etc/revdep-rebuild/. If an ebuild author wants to adjust the behavior of revdep-rebuild, place a file in that directory. I am attaching the file that I will be using to set the defaults for revdep-rebuild.
I think adding a file would be a good solution. One question. Will these files be accumulating all values mentioned? (Should SEARCH_DIRS_MASK="$SEARCH_DIRS_MASK:/usr/lib/openoffice" be used?
The variables are accumulated in the following order: * Environment * /etc/make.conf * /etc/revdep-rebuild/*
*** Bug 110261 has been marked as a duplicate of this bug. ***
I have released gentoolkit-0.2.1_pre9 which supports the placing of a environment file for revdep-rebuild in /etc/revdep-rebuild. On my system I have the file /etc/revdep-rebuild/10openoffice-bin which contains SEARCH_DIRS_MASK="/usr/lib/openoffice"
@Paul: Great! So can we close that bug now? ;)
I don't want to actually close the bug until gentoolkit-0.2.1 goes stable since experience has shown me that people will keep opening bugs about it. Feel free to remove yourself from the CC list.
I had the same problem, so I've created a patch for revdep-rebuild to exclude bin packages from /root/.revdep-rebuild.4_ebuilds. It assumes only binary packages end with -bin. It's contents is below. hope it's of use. #----BEGIN REVDEP-REBUILD PATCH---- --- revdep-rebuild 2005-10-19 10:55:29.000000000 +0000 +++ /usr/bin/revdep-rebuild 2005-11-06 23:49:27.000000000 +0000 @@ -257,7 +257,7 @@ echo -n > $LLIST.4_ebuilds fi fi - + grep -- -bin$ < $LLIST.4_ebuilds > $LLIST.4_ebuilds RAW_REBUILD_LIST="$(cat $LLIST.4_ebuilds | sed s/^/=/ | tr '\n' ' ')" fi #----BEGIN REVDEP-REBUILD PATCH----
*** Bug 87829 has been marked as a duplicate of this bug. ***
Definitely /etc/revdep-rebuild/10openoffice-bin should be created by the ebuild of openoffice-bin (and removed at unmerge). Working fine here after manual addition.
(In reply to comment #35) > I have released gentoolkit-0.2.1_pre9 which supports the placing of a > environment file for revdep-rebuild in /etc/revdep-rebuild. On my system I have > the file /etc/revdep-rebuild/10openoffice-bin which contains > SEARCH_DIRS_MASK="/usr/lib/openoffice" > A late reply, but: If someone changes from openoffice-bin to openoffice, this would result in openoffice not being checked anymore as that file won't get removed due to the config-file protections, right?
That is correct. I'll update gentoolkit to CONFIG_PROTECT_MASK /etc/revdep-rebuild/ in next releases. For now, the only thing that I can think of to help is to put an einfo at the end of the unmerge of openoffice-bin to remove the file.
(In reply to comment #41) > (In reply to comment #35) > > I have released gentoolkit-0.2.1_pre9 which supports the placing of a > > environment file for revdep-rebuild in /etc/revdep-rebuild. On my system I have > > the file /etc/revdep-rebuild/10openoffice-bin which contains > > SEARCH_DIRS_MASK="/usr/lib/openoffice" > > > > A late reply, but: If someone changes from openoffice-bin to openoffice, this > would result in openoffice not being checked anymore as that file won't get > removed due to the config-file protections, right? > It works like a charm, however, for amd64 it's SEARCH_DIRS_MASK="/usr/lib32/openoffice"
*** Bug 128067 has been marked as a duplicate of this bug. ***
*** Bug 131620 has been marked as a duplicate of this bug. ***
(In reply to comment #42) > That is correct. I'll update gentoolkit to CONFIG_PROTECT_MASK > /etc/revdep-rebuild/ in next releases. > Any news on this, Paul?
(In reply to comment #46) > (In reply to comment #42) > > That is correct. I'll update gentoolkit to CONFIG_PROTECT_MASK > > /etc/revdep-rebuild/ in next releases. > > > > Any news on this, Paul? > Well: app-portage/gentoolkit-0.2.2_rc1 # emerge --info | grep CONFIG_PROTECT_MASK CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/env.d" So... what's holding this back?
(In reply to comment #47) > So... what's holding this back? Me not knowing about this? ;) I've added this now to the ebuild for 2.0.3_rc4, masses will get it with the release of 2.0.3. So finally closing this :))))))))))))
It is in >=gentoolkit-0.2.2_pre3. Since portage-2.1 is in the process of going stable, I am getting ready to release gentoolkit-0.2.2 for stable as well.