As xorg-x11-6.8.0-r5 was marked stable i tried to update, but got some message complaining about "cannot write to /usr/lib/X11/locale/lib" It tells I should use "ebuild /usr/portage/x11-base/xorg-x11/xorg-x11-6.8.0-r5.ebuild merge" what results in the same message. When I checked for the path, I found it is a symlink to /emul/linux/x86/usr/lib/X11/locale/lib but that path did not exist. "mkdir /emul/linux/x86/usr/lib/X11/locale/lib" solved the problem Reproducible: Always Steps to Reproduce: 1.emerge --sync 2.emerge -u world Actual Results: the merge of xorg-x11 failed, after trying to shutdown the X Server there was only left a black screen! Even after reboot the screen went immidiately dark as xdm was started at boot. I switched to tty1 and typed all things to stop xdm being started at boot time without seeing what I typed.. not a very comfortable solution ;-) Expected Results: update successfully I was running: gnome thunderbird firefox xchat some terminals hope I didn't miss something
Sounds like a problem in the emul-xlibs.
*** Bug 82007 has been marked as a duplicate of this bug. ***
What version of emul-linux-x86-xlibs are you using? Can you try remerging it please - try version app-emulation/emul-linux-x86-xlibs-1.2-r6. This directory is created and populated.
Actually I was already using emul-linux-x86-xlibs-1.2-r6, because I tried to get wine working (which is still not compiling, but after I emerged that version of emul-xlib at least the -lXext problem was gone) I see in the output of remerging it: --- /emul/linux/x86/usr/lib/X11/locale/ >>> /emul/linux/x86/usr/lib/X11/locale/lib/ >>> /emul/linux/x86/usr/lib/X11/locale/lib/common/ >>> /emul/linux/x86/usr/lib/X11/locale/lib/common/xlibi18n.so.2 -> ../../../../xlibi18n.so.2 >>> /emul/linux/x86/usr/lib/X11/locale/lib/common/xlocale.so.2 -> ../../../../xlocale.so.2 >>> /emul/linux/x86/usr/lib/X11/locale/lib/common/ximcp.so.2 -> ../../../../ximcp.so.2 >>> /emul/linux/x86/usr/lib/X11/locale/lib/common/xlcUTF8Load.so.2 -> ../../../../xlcUTF8Load.so.2 >>> /emul/linux/x86/usr/lib/X11/locale/lib/common/xlcDef.so.2 -> ../../../../xlcDef.so.2 >>> /emul/linux/x86/usr/lib/X11/locale/lib/common/xomGeneric.so.2 -> ../../../../xomGeneric.so.2 --- /emul/linux/x86/usr/lib/X11/locale/C/ >>> /emul/linux/x86/usr/lib/X11/locale/C/XI18N_OBJS >>> /emul/linux/x86/usr/lib/X11/locale/C/XLC_LOCALE this lot of "../"-directory-upwards in front of the path in doubt is somewhat confusing. And actually the directory "/emul/linux/x86/usr/lib/X11/locale/lib" does NOT exist after this remerge. Should I try switching back to app-emulation/emul-linux-x86-xlibs-1.2-r3?
I played around a bit with the emul-xlib ebuild, here's what I found out: at the end of the ebuild we find: pkg_postrm() { # The symlink should be removed too. if [ -h /usr/$(get_libdir)/X11/locale/lib ]; then rm -f /usr/$(get_libdir)/X11/locale/lib fi } I changed the ebuild to find out what $(get_libdir) is, and it actually is just "lib". (I just added ewarn "/usr/$(get_libdir)/X11/locale/lib was removed" to the if block) Well, searched for that file, and obviously it is there: /usr/lib/X11/locale/lib -> /emul/linux/x86/usr/lib/X11/locale/lib What now strikes ist, that it is there although it should have been deleted while processing that if block. So "rm -f /usr/$(get_libdir)/X11/locale/lib" does not delete the symlink itself, but the symlink it points to. Well, back to the problem mentioned above: "cannot write to /usr/lib/X11/locale/lib" why does it TRY to write there if it should have been deleted? This is what I think is the relevant part in xorg-x11-6.8.0-r5.ebuild: # on amd64 we need /usr/lib64/X11/locale/lib to be a symlink # created by the emul lib ebuild in order for adobe acrobat, staroffice, # and a few other apps to work. if [ -z "${MULTILIB_ABIS}" ]; then use amd64 && get_libdir_override lib64 # lib32 isnt a supported configuration (yet?) [ "$(get_libdir)" == "lib32" ] && get_libdir_override lib fi So, if I understand what it does, it checks for /usr/lib/X11/locale/lib being a symlink. As I explained above, this symlink exists, so it tries to write to that symlink, what fails because the thing it pointed to does no longer exist. So, as far as I see, there are three possible solutions: 1) remove pkg_postrm() from emul-linux-x86-xlibs-1.3-r6.ebuild 2) modify that line in pkg_postrm() to remove the correct thing (I don't know how to do) 3) modify the xorg ebuild(s) to check for that link pointing to something that exists, and if not fix the situation Most likely 1) would be the easiest one, but I don't understand what deleting the symlink is good for anyways...
I went with option 2, the logic now checks for the link being a symlink and that the directory it points to does not exist. It was intended to remove a stray symlink no removal of the package, but also did this on upgrade. Should be fixed in emul-linux-x86-xlibs-1.2-r7 if you would like to test it. With regard to the libs etc not being put in place this could be a problem with your file hierarchy under /emul. If the new ebuild still doesn't work please attach the output of 'ls -lR /emul/linux/x86/' to this bug and reopen it.
Created attachment 53059 [details] ls -lR /emul/linux/x86/ > ls-output
I'm sorry, but it is still the same. I didn't try to upgrade to x11-base/xorg-x11-6.8.2-r1, because it will most likely fail without /emul/linux/x86/usr/lib/X11/locale/lib existing. I tried the new ebuild both with and without that directory existing when the merge is started, it results in deleting the directory anyways.
It looks to me like X11 -> ../X11R6/lib/X11 is your problem, as this is not used and should not be there. Try deleting it - 'rm /emul/linux/x86/usr/lib/X11', and then emerge the -r7 release again. It will still delete the symlink if it points to nothing. If that works then I could add a bit of extra logic into the ebuild to check for this erronous symlink and remove it. I have not seen this particular problem on any other systems though.
Yes, you're right. Now it did work! I don't know how this symlink came there, I recently updated from -r3 to -r6, and afterwards it must have been there, probably it was already there before.
It is the first time I have seen that link, but I will put an extra check into the ebuild just in case anyone else is suffering from the same issue. Glad we got to the bottom of this issue - marking as FIXED.
*** Bug 84773 has been marked as a duplicate of this bug. ***
