That's all. But it's more then enough. After emerging wine-any /bin/bash changed from file to directory with -* file in it containing some LD_LIBRARY_ magic. Fortunately it was NFS-booted system and I found original bash binary renamed to bash.backup.0000
emerge --info please
(In reply to Jan Psota from comment #0) > That's all. But it's more then enough. > > After emerging wine-any /bin/bash changed from file to directory with -* > file in it containing some LD_LIBRARY_ magic. Fortunately it was NFS-booted > system and I found original bash binary renamed to bash.backup.0000 I'm going to need more information, like actual logs. It is very difficult to discern anything without system information, package information, logs, specifics on what you had as the replacement (instead of just "magic", etc. Most likely the eselect module, but won't know for sure until we go digging further into the issue. I'd recommend that we copy the package to a local overlay and comment out the "eselect wine update" lines in pkg_postinst and pkg_prerm. The other alternative would be to manually call the eselect module to unset and set links and see if it happens again to you (but given the report, that seems riskier) I'm particularly having trouble figuring out what LD_LIBRARY magic you might have meant, but as I said above, you really need to provide me with as much detail as you can as I haven't encountered anything like this with any of my testers (myself included)
Sounds like all the new stuff should be masked while you figure it out.
(In reply to Michał Górny from comment #3) > Sounds like all the new stuff should be masked while you figure it out. A mask was added before it was even added >_< https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fc950477fe4e7c4529d83647ecaee8ba34308ee2
Created attachment 469672 [details] bash/-*
I'm sorry, I was merely looking at the bug.
[ebuild R #] app-emulation/wine-any-2.5:2.5::gentoo USE="X alsa cups custom-cflags d3d9 fontconfig gecko gphoto2 jpeg lcms mono ncurses netapi nls odbc opencl opengl osmesa perl pipelight png pulseaudio realtime run-exes s3tc samba ssl staging threads truetype udev udisks v4l vaapi xcomposite xml -capi -dos -gsm -gstreamer -ldap -mp3 -openal -oss -pcap -prelink -scanner (-selinux) {-test} -themes -xinerama" ABI_X86="32 (64) (-x32)" LINGUAS="pl" Logs pending.
Created attachment 469674 [details] build.log
Created attachment 469676 [details] build-abi_x86_32.x86.log
Created attachment 469678 [details] build-abi_x86_64.amd64.log.gz
Created attachment 469680 [details] eclass-debug.log
(In reply to Jan Psota from comment #11) > Created attachment 469680 [details] > eclass-debug.log Thanks. I'm going to look over all of this in ~8 hours after some sleep. If you do any testing of the package sans eselect update calls, or manualy test the eselect module, please let me know if you gain any additional information in case the issue is there as opposed to here. Also, just in case you are able, I should be available much of the day later today in #gentoo-wine on freenode. Just ping me if you join the channel.
Looks like the source of the issue is MY_PREFIX being unset in multilib_src_install_all. I can't see any reason why that should be the case. Are you using bash hooks or something fancy in your setup? Can you please paste emerge --info?
(In reply to NP-Hardass from comment #13) > Looks like the source of the issue is MY_PREFIX being unset in > multilib_src_install_all. I can't see any reason why that should be the > case. Are you using bash hooks or something fancy in your setup? Can you > please paste emerge --info? I have no access to that system now. I don't use any bash hooks and never had any problems with merging. The only change I did in ebuild was removing: # respect LINGUAS when installing man pages, #469418 for l in de fr pl; do use linguas_${l} || rm -r "${D%/}${MY_MANDIR}"/${l}* done for m in "${D%/}${MY_MANDIR}"/*/*; do new_man=${m##*/} new_man=${new_man%%.1} newman "${m}" ${new_man##*/}-${WINE_VARIANT}.1 done ... - last part of multilib_src_install_all because emerge failed on newman.
(In reply to Jan Psota from comment #14) > (In reply to NP-Hardass from comment #13) > > Looks like the source of the issue is MY_PREFIX being unset in > > multilib_src_install_all. I can't see any reason why that should be the > > case. Are you using bash hooks or something fancy in your setup? Can you > > please paste emerge --info? > > I have no access to that system now. I don't use any bash hooks and never > had any problems with merging. The only change I did in ebuild was removing: > > # respect LINGUAS when installing man pages, #469418 > for l in de fr pl; do > use linguas_${l} || rm -r "${D%/}${MY_MANDIR}"/${l}* > done > > for m in "${D%/}${MY_MANDIR}"/*/*; do > new_man=${m##*/} > new_man=${new_man%%.1} > newman "${m}" ${new_man##*/}-${WINE_VARIANT}.1 > done > > ... - last part of multilib_src_install_all because emerge failed on newman. That probably failed for the same variables issue going on. In addition to the emerge --info, can you also please provide the full build.log (as opposed to just the installation portion), as well as environment file at the end of the configure phase and at the end of the install phase? On the original ebuild file, run ebuild /path/to/wine-any-2.5.ebuild clean configure (paste environment file) ebuild /path/to/wine-any-2.5.ebuild clean install (paste environment file and full build log) And if you can, set LC_MESSAGES=C so I don't have to learn polish :P ( I mean, I could, but it'd slow us down quite a bit XD )
Updated to include failglob which should prevent overwriting bash when the glob initially fails, but still looking for more info so we can find out why the variables are null.
Created attachment 469778 [details] temp from merge + emerge --info
OK, so, it looks like your build shows that the variables look good, everything went swimmingly up to the point where newman fails (you said you tweaked the ebuild to work around that, and I'm going to move forward under the assumption that the change caused the nuking of the variable which lead to the make_wrapper call nuking /bin/bash, particularly because various parts of multilib_src_install_all now succeeded where previously they failed. As mentioned previously, added a safeguard to prevent that in the event that the vars are nuked again... QA team, you can remove yourselves at this point if you see no further need to be onboard. That just leaves the original issue, the newman failure, which I've replicated here and will work on a fix ASAP.
Uuuu! I wouldn't think, that removing "man" part of pkg_install in any ebuild can break my system... ;-) I didn't even remember when and why I turned off protect-owned... My fault. Sorry for making your hair curl ;-)
(In reply to Jan Psota from comment #19) > Uuuu! I wouldn't think, that removing "man" part of pkg_install in any > ebuild can break my system... ;-) I didn't even remember when and why I > turned off protect-owned... My fault. Sorry for making your hair curl ;-) No worries :P I'm just glad that that issue is all sorted. So, I'm going to make a change to the eselect module and the wine package, and bump both. Will post back here when I've completed that. Will be fairly straight forward.
Should be fixed in 935d4378807140c01d0b232c64092e09e1440420. Update your eselect module, and then try emerging wine-any:2.5. Let me know if you run into any other problems.
Works like magic! :-) (People! Do not disable protect-owned... ;-)
