After unmerging wine-0.9.8-r1 these files was not removed: /usr/bin/wine /usr/bin/wineserver /usr/bin/winebuild /usr/bin/wine-pthread /usr/bin/wine-kthread /usr/bin/winedump /usr/bin/wineg++ /usr/bin/winecpp /usr/bin/winegcc /usr/bin/wine-preloader /usr/share/fonts/wine /usr/share/fonts/wine/fonts.scale /usr/share/fonts/wine/fonts.dir /usr/share/fonts/wine/encodings.dir /usr/share/fonts/wine/fonts.cache-1 ... and maybe other files too. This also has side effect in revdep-rebuild messages: broken /usr/bin/wine (requires libwine.so.1) broken /usr/bin/wineserver (requires libwine.so.1 libwine_unicode.so.1) broken /usr/bin/wmc (requires libwine_unicode.so.1) broken /usr/bin/wrc (requires libwine_unicode.so.1)
highly doubt this is a wine bug
Portage doesn't unmerge files if their timestamp or md5 digest doesn't match the value recorded when the files were installed. One thing that can cause this is if the files are prelinked and then prelink is uninstalled without undoing the prelink first. Please post the output of `emerge --info`.
I don't use prelinking - AFAIK it's incompatible with hardened. Portage 2.0.54-r2 (hardened/x86/2.6, gcc-3.4.6, glibc-2.3.6-r3, 2.6.14-hardened-r8 i686) ================================================================= System uname: 2.6.14-hardened-r8 i686 AMD Athlon(tm) XP 3000+ Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: [Not Present] dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -pipe -ftracer -fprefetch-loop-arrays" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /service /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/X11/xkb /usr/share/config /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe -ftracer -fprefetch-loop-arrays" DISTDIR="/usr/portage-distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/ http://130.59.10.34/mirror/gentoo/ http://gentoo.zie.pg.gda.pl" LANG="ru_RU.KOI8-R" LINGUAS="en ru" PKGDIR="/usr/portage-packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/portage-power /usr/local/portage-rusxmms" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X Xaw3d aac acpi aim alsa apache2 arts asf audiofile avi bash-completion berkdb bitmap-fonts bzip2 cdr crypt cscope curl dga divx4linux dlloader dts dvd dvdr dvdread encode esd ethereal exif expat fam ffmpeg flac flash gd gdbm gif glut gnutls gtk gtk2 guile hardened icq idn imagemagick imap imlib irc jabber javascript jpeg kdeenablefinal lcms lirc lm_sensors lzo mad mailbox mbox mmx mmxext mng motif mp3 mpeg msn mysql ncurses nls nptl nptlonly ogg opengl oss pam pcre perl pic png pwdb python qt quicktime rcc readline rss rtc samba sdl silc slang spell sse ssl svg sysfs tcltk tcpd tiff truetype truetype-fonts type1-fonts udev userlocales vorbis win32codecs x86 xine xinetd xml xml2 xmms xv xvid yahoo zlib linguas_en linguas_ru userland_GNU kernel_linux elibc_glibc" Unset: CTARGET, INSTALL_MASK, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS
Are you able to reproduce this problem if you remerge wine and unmerge it again?
Ohh, it need much time to compile it... :( and I don't sure I've found all files not removed by emerge -C wine. Ok, if you need it, I'll manually remove these files, run emerge wine when I'll go to sleep and tomorrow try to use wine a little and then emerge -C it again.
You don't have to manually remove the files. When you reinstall, they will be overwritten anyway. Also, before you uninstall, you can use quickpkg to make a backup binary package in case it's needed for further testing. If you have extra disk space, it a good idea to enable FEATURES="buildpkg" in make.conf so that portage creates binary packages of everything automatically.
(In reply to comment #2) > Portage doesn't unmerge files if their timestamp or md5 digest doesn't match > the value recorded when the files were installed. I've found reason why /usr/bin/wine* files wasn't unmerged: it's because their md5 was changed after executing paxctl (I'm using hardened, as you can see in my emerge --info). About files in /usr/share/fonts/wine/ - I suppose these files was autogenerated and doesn't belong to wine package. So, probably this bug can be closed, but I'm not happy with this idea: portage will not delete files changed by paxctl/chpax!! If some package require paxctl/chpax then this package is weak place in hardened protection... and, finally, when I decide to unmerge that package -- portage will leave binaries with disabled PaX protection on my hard drive without any notice... all hackers should applause here! :-(
Is there some way to reverse the changes that are made by paxctl/chpax? For prelinked files, portage uses `prelink --undo <filename>` in order to ensure that the checksums match.
I think best workaround should be: if emerge detect 'hardened' environment, then apply paxctl/chpax while emerging, at 'install' stage, using rules from /etc/conf.d/chpax. This way: 1) installed binary will already have modified pax flags, so recorded by emerge md5 will not be changed at unmerging unless user manually change PaX flags (I've no idea why user may need this) 2) package will be ready-to-use just after emerge, without need to running /etc/init.d/chpax (or reboot) first - just like all other packages which doesn't require changing PaX flags to work 3) running /etc/init.d/chpax at system startup will not be needed anymore, so /etc/init.d/chpax and /etc/conf.d/chpax can be replaced, for example, by simple script /etc/set_pax: ---cut--- #!/bin/sh chpax -pemrxs /opt/*-{j{,2s}dk-*/{,jre/},jre-*/}bin/* chpax -pemrxs /opt/skype/skype.bin paxctl -pemrxs /usr/bin/Xorg paxctl -pems /usr/bin/{g,}mplayer paxctl -pems /usr/bin/{g,}xine paxctl -m /usr/bin/xmms paxctl -pems /usr/bin/{wine{,build,clipsrv,dump,gcc,server,wrap,-{k,p}thread},w{mc,rc,idl}} ---cut--- and emerge will just execute this script if it exists - there even no need to detect hardened environment.
(In reply to comment #9) > I think best workaround should be: if emerge detect 'hardened' environment, > then apply paxctl/chpax while emerging, at 'install' stage, using rules from > /etc/conf.d/chpax. No this has been talked about before and we decided a long time ago that we do not want to lower peoples security for them. Changing PaX flags from the default would do such a thing. Second old chpax style flags are not strip safe so it has to be done postint. (In reply to comment #8) > Is there some way to reverse the changes that are made by paxctl/chpax? For > prelinked files, portage uses `prelink --undo <filename>` in order to ensure > that the checksums match. The default PT_PAX_FLAGS can be restored using paxctl -zxe however if a maintainer elected to use a compile time flag such as -Wl,-z,--execheap then setting -zxe would be wrong. One way this could be accomplished however would be to record the paxelf settings in the vdb and restore them prior to unmerge if they differ from the recorded ones. (we could revisit this >=2.1.1)
(In reply to comment #10) > No this has been talked about before and we decided a long time ago that we > do not want to lower peoples security for them. Changing PaX flags from > the default would do such a thing. Second old chpax style flags are not > strip safe so it has to be done postint. I agree it isn't good idea to lower security 'by default'. But if user configured his own /etc/set_pax script (or config), then executing it at postinst isn't bad idea. Anyway, we've /etc/init.d/chpax executed on each boot and change pax flags for many binaries 'by default'!! And, lowering security is bad idea, but if user emerge, for example, xmms or java - then he probably wanna use them! But without changing pax flags it's currently impossible to use them, so we force user to run /etc/init.d/chpax anyway, no matter is he wanna lower security or not. So, what's the difference between changing pax flags in postinst (with printing fat big warning to user about lowering security) and manual execution of /etc/init.d/chpax if user has NO CHOICE ANYWAY if he wanna use these packages? > One way this could be accomplished however would be to record the paxelf > settings in the vdb and restore them prior to unmerge if they differ from > the recorded ones. (we could revisit this >=2.1.1) Yep, this solve issue... but this solution is complex (compared to my proposition) and will slowdown already-not-very-fast emerge. :(
(In reply to comment #11) > And, lowering security is bad idea, but if user emerge, for example, xmms or > java - then he probably wanna use them! But perhaps the user (i.e. sysadmin) doesn't realise that PaX will be weakened for the apps; if the ebuilds do it all by magic However ideally PaX should be managed by a MAC (e.g. RBAC, RSBAC, SELinux(?)), not by the file contents. The init.d/chpax running on boot is sort of trying to do the same thing; keeping policy for PaX flags as a system configuration. If a MAC is in play, it doesn't matter what the executable is marked with, and the markings give the sysadmin an easy way to find out what the application itself thinks it needs. I did play with a portage hook for setting flags according to a system configuration file; perhaps it's worth looking at again. It's all the more complex because some stuff won't take paxctl (although that situation has improved significantly), and different kernel configurations pay attention to different types of PaX marking. Alternatively we could save/restore chpax flags around the stripping that portage does, which should simplify things dramatically. Perhaps this would be better discussed on the hardened mailing list.
(In reply to comment #10) > One way this could be accomplished however would be to record the paxelf > settings in the vdb and restore them prior to unmerge if they differ from > the recorded ones. (we could revisit this >=2.1.1) Rather than include specialized support for things like this (chpax, prelink, etc...) in portage, I think it would be cleaner and more worthwhile to implement global reference counting for the unmerge phase. Tools such as qfile (from portage-utils) show that contents lookups can be done quickly even with flat CONTENTS files (as opposed to a real database).
(In reply to comment #11) > Anyway, we've /etc/init.d/chpax executed on each boot > and change pax flags for many binaries 'by default'!! This statement is incorrect/false. The user has to rc-update add chpax <level> to make that happen. It is in no way enabled per default and never will be.
*** This bug has been marked as a duplicate of 16162 ***
In svn r6830 I've added support for FEATURES=unmerge-orphans which causes unmerge to remove files more aggressively. If a file is not claimed by another package in the same slot and it is not protected by CONFIG_PROTECT, unmerge it even if the modification time or checksum differs from the file that was originally installed.
This has been released in 2.1.3_rc1.
*** Bug 187769 has been marked as a duplicate of this bug. ***
