After upgrading to dev-libs/popt-1.14, gnome-base/libgnomeui-2.22.1 fails to emerge. Reproducible: Always Steps to Reproduce: 1. emerge -1 '=dev-libs/popt-1.14' 2. emerge -1 '=gnome-base/libgnomeui-2.22.1' Actual Results: (cd .libs && rm -f libgnomeui-2.so && ln -s libgnomeui-2.so.0.2201.0 libgnomeui-2.so) x86_64-pc-linux-gnu-ar cru .libs/libgnomeui-2.a libgnomeui-access.o gnometypebuiltins.o gnome-about.o gnome-app.o gnome-app-helper.o gnome-app-util.o gnome-appbar.o gnome-stock-icons.o gnome-client.o gnome-color-picker.o gnome-dateedit.o gnome-dialog.o gnome-dialog-util.o gnome-druid.o gnome-druid-page.o gnome-druid-page-edge.o gnome-druid-page-standard.o gnome-entry.o gnome-file-entry.o gnome-font-picker.o gnome-gconf-ui.o gnome-href.o gnome-ice.o gnome-marshal-main.o gnome-messagebox.o gnome-mdi.o gnome-mdi-child.o gnome-mdi-generic-child.o gnome-mdi-session.o gnome-multiscreen.o gnome-pixmap.o gnome-pixmap-entry.o gnome-popup-menu.o gnome-propertybox.o gnome-scores.o gnome-theme-parser.o gnome-thumbnail.o gnome-thumbnail-pixbuf-utils.o gnome-ui-init.o gnometypes.o gnome-icon-entry.o gnome-icon-item.o gnome-icon-list.o gnome-icon-lookup.o gnome-icon-sel.o gnome-icon-theme.o gnome-vfs-util.o gnome-window.o gnome-window-icon.o gnome-password-dialog.o gnome-authentication-manager.o x86_64-pc-linux-gnu-ranlib .libs/libgnomeui-2.a creating libgnomeui-2.la /bin/sed: can't read /usr/lib64/libpopt.la: No such file or directory libtool: link: `/usr/lib64/libpopt.la' is not a valid libtool archive make[4]: *** [libgnomeui-2.la] Error 1 make[4]: Leaving directory `/var/tmp/portage/gnome-base/libgnomeui-2.22.1/work/libgnomeui-2.22.1/libgnomeui' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/tmp/portage/gnome-base/libgnomeui-2.22.1/work/libgnomeui-2.22.1/libgnomeui' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/gnome-base/libgnomeui-2.22.1/work/libgnomeui-2.22.1/libgnomeui' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/gnome-base/libgnomeui-2.22.1/work/libgnomeui-2.22.1' make: *** [all] Error 2 * * ERROR: gnome-base/libgnomeui-2.22.1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2637: Called gnome2_src_compile * environment, line 2013: Called die * The specific snippet of code: * emake || die "compile failure" * The die message: * compile failure Expected Results: It should have built successfully. Portage 2.1.5_rc4 (default-linux/amd64/2007.0/desktop, gcc-4.2.3, glibc-2.7-r2, 2.6.24-gentoo-r4-ija1 x86_64) ================================================================= System uname: 2.6.24-gentoo-r4-ija1 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ Timestamp of tree: Fri, 18 Apr 2008 09:45:02 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.5 dev-lang/python: 2.5.1-r5 sys-apps/baselayout: 1.12.12 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.62 sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.24 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-mtune=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-mtune=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" LDFLAGS="" LINGUAS="en en_GB" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/desktop-effects /usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aac acl acpi adns alsa amd64 arts avahi berkdb bzip2 cairo cdr cjk cli cracklib crypt cups curl dbus doc dri dv dvd dvdr dvdread eds emboss encode esd evo expat fam firefox flac flash fortran gdbm gif glut gmp gnome gnutls gpm graphviz gstreamer gtk gtkhtml hal iconv idn imagemagick imap imlib ipv6 isdnlog java jpeg kde kerberos lcms ldap mad midi mikmod mmx mng mono motif mozsvg mp3 mpeg mudflap ncurses nls no-helper nptl nptlonly nsplugin offensive ogg opengl openmp oss pam pcre pdf perl plotutils png ppds pppd python qt3 qt3support qt4 quicktime readline reflection samba sdl session slang snmp spell spl sqlite sse sse2 ssl svg tcltk tcpd tetex threads tiff truetype unicode usb vorbis x264 xine xml xorg xv zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_GB" USERLAND="GNU" VIDEO_CARDS="radeon ati vesa fbdev" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Looking at the difference between the ebuilds for popt-1.13 and popt-1.14, I see this addition in src_install(): + + find "${D}" -name '*.la' -delete I think that's the culprit!
Cc'ing flameeyes since he says "Bugs about _this version_ can come my way for now" in the CVS log for popt-1.14.
This is not libgnomeui's fault. Since popt-1.14 doesn't provide .la files anymore, you _have_ to use revdep-rebuild (and it's probable it's gonna be the hard way anyway but it can't be helped).
and for the record, I've mostly finished rebuilding gnome 2.22 on my box following this popt upgrade so I can tell you it shouldn't be a problem for gnome packages.
*** Bug 218319 has been marked as a duplicate of this bug. ***
I didn't think to use revdep-rebuild since I was only halfway through an 'emerge -DuN world' when I hit the problem with libgnomeui (I was upgrading, not rebuilding). Is that common usage for revdep-rebuild now? For the record, modifying the popt-1.14 ebuild to keep the .la file and then reemerging popt also allows libgnomeui to build successfully. I've undone my changes and am trying it your way with revdep-rebuild now... It looks like it's going to take a while.... only 36 broken packages to go.... and it worked!
*** Bug 218315 has been marked as a duplicate of this bug. ***
*** Bug 218364 has been marked as a duplicate of this bug. ***
Reassigning, since this is going to cause lots of dupes, and useless spam for the gnome folks.
*** Bug 218399 has been marked as a duplicate of this bug. ***
*** Bug 218372 has been marked as a duplicate of this bug. ***
@flameeyes: It would have been nice if you had discussed (or at least announced) your plans to remove .la files, instead of just breaking users' systems.
It doesn't _break_ systems. It just requires them to run revdep-rebuild, or to know how to deal with that in other ways, like using sed. Note that the same would have happen if the projects switched to cmake, pure makefile or anything else not providing libtool .la files. And I did announce it, sort of..
(In reply to comment #13) > And I did announce it, sort of.. Where? Local planning department in Alpha Centauri?
nope, another planet... Planet Gentoo :P Anyway it doesn't seem to me such a huge fuss... it's not like it hasn't been done in at least one case before (gcc), and not much different than changing a soname.
(In reply to comment #15) > nope, another planet... Planet Gentoo :P It would have been nice if there was a einfo/ewarn/e something which told me to run revdep-rebuild! The same applies to libogg, libmad, libmpcdec and pulseaudio.
*** Bug 218429 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > nope, another planet... Planet Gentoo :P Your blog is about as relevant to Gentoo development as you deem .la files to be. You know, we have *mailinglists* for such stuff. > Anyway it doesn't seem to me such a huge fuss... it's not like it hasn't been > done in at least one case before (gcc), and not much different than changing a > soname. You're going to be forcing everyone to rebuild lots of stuff all the time for dubious benefit. That's annoying, especially when you don't properly mail such stuff to -dev@ first. You've been told that last time you pulled off such a stunt with metadata so when will you finally start doing things properly (and, no, you thinking you're doing just that doesn't count)?
*** Bug 218445 has been marked as a duplicate of this bug. ***
revdep-rebuild with what arguments?
With no arguments. Please note that this is not a distribution-wide change, this is just a change for a few libraries for which I know for sure the libtool file is not needed. I don't see any reason why it should have been announced more than, say, a version bump, or a build fix, or adding a new USE flag or... I'm not going to discuss every time I make a change to a package. For sure I did expect users to be able to find the solution by themselves, or at least devs could be able to search for bugs...
(In reply to comment #21) > For sure I did expect users to be able to find the solution by themselves, or > at least devs could be able to search for bugs... You are missing the point. If one was informed upfront and on installing the new package you would not have so many bug reports and dissapointed users/devs. Rebuilding 56 packages (this includes openoffice :( ) just because you decided remove .la files is a large change which should be communicated better!
openoffice?!? what the hell is openoffice doing with that, are you sure of it being part of _this_ problem? it does _not_ install any .la file on my system at least. By the way you're not exactly forced to rebuild all of them, eh...
*** Bug 218499 has been marked as a duplicate of this bug. ***
When I run revdep-rebuild this is what I get * /usr/lib64/python2.5/site-packages/gtk-2.0/bonobo/ui.la -> dev-python/gnome-python * /usr/lib64/python2.5/site-packages/gtk-2.0/egg/recent.la -> dev-python/gnome-python-extras * /usr/lib64/python2.5/site-packages/gtk-2.0/gnome/_gnome.la -> dev-python/gnome-python * /usr/lib64/python2.5/site-packages/gtk-2.0/gnome/ui.la -> dev-python/gnome-python * /usr/lib64/python2.5/site-packages/gtk-2.0/gnomeapplet.la -> dev-python/gnome-python-desktop * /usr/lib64/python2.5/site-packages/gtk-2.0/gnomedesktop/_gnomedesktop.la -> dev-python/gnome-python-desktop * /usr/lib64/python2.5/site-packages/gtk-2.0/mediaprofiles.la -> dev-python/gnome-python-desktop * /usr/lib64/window-manager-settings/libmetacity.la -> gnome-base/control-center * Generated new /root/.revdep-rebuild.4_packages_raw and /root/.revdep-rebuild.4_package_owners * Cleaning list of packages to rebuild * Generated new /root/.revdep-rebuild.4_packages * Assigning packages to ebuilds * Generated new /root/.revdep-rebuild.4_ebuilds * Evaluating package order * * Warning: Failed to resolve package order. * Will merge in arbitrary order * Possible reasons: - An ebuild is no longer in the portage tree. - An ebuild is masked, use /etc/portage/packages.keyword and/or /etc/portage/package.unmask to unmask it ..... * All prepared. Starting rebuild emerge --oneshot =app-editors/gedit:0 =app-office/abiword-plugins:0 =app-text/evince:0 =app-text/gnome-spell:1 =dev-cpp/libgnomemm:2.6 =dev-cpp/libgnomeuimm:2.6 =dev-python/gnome-python-desktop:0 =dev-python/gnome-python-extras:0 =dev-python/gnome-python:2 =gnome-base/control-center:2 =gnome-base/eel:2 =gnome-base/gnome-desktop:0 =gnome-base/gnome-mount:0 =gnome-base/gnome-panel:0 =gnome-base/libbonoboui:0 =gnome-base/libgnome:0 =gnome-base/libgnomeui:0 =gnome-extra/deskbar-applet:0 =gnome-extra/evolution-data-server:0 =gnome-extra/gnome-media:2 =gnome-extra/gtkhtml:3.14 =gnome-extra/gtkhtml:3.8 =gnome-extra/gucharmap:0 =gnome-extra/nautilus-cd-burner:0 =mail-client/evolution:2.0 =media-gfx/graphviz:0 =media-libs/gst-plugins:0.8 =media-libs/gstreamer:0.8 =media-plugins/gst-plugins-a52dec:0.8 =media-plugins/gst-plugins-alsa:0.8 =media-plugins/gst-plugins-cdparanoia:0.8 =media-plugins/gst-plugins-dvdnav:0.8 =media-plugins/gst-plugins-dvdread:0.8 =media-plugins/gst-plugins-esd:0.8 =media-plugins/gst-plugins-gnomevfs:0.8 =media-plugins/gst-plugins-mad:0.8 =media-plugins/gst-plugins-mpeg2dec:0.8 =media-plugins/gst-plugins-ogg:0.8 =media-plugins/gst-plugins-oss:0.8 =media-plugins/gst-plugins-pango:0.8 =media-plugins/gst-plugins-vorbis:0.8 =media-plugins/gst-plugins-xvideo:0.8 =media-video/totem:0 =net-print/gnome-cups-manager:0 =x11-libs/goffice:0.2 =x11-libs/goffice:0.4 =x11-libs/goffice:0.6 .......... Calculating dependencies | !!! '=app-editors/gedit:0' is not a valid package atom. !!! Please check ebuild(5) for full details. !!! (Did you specify a version but forget to prefix with '='?) * * revdep-rebuild failed to emerge all packages. * you have the following choices: * - If emerge failed during the build, fix the problems and re-run revdep-rebuild. * - Use /etc/portage/package.keywords to unmask a newer version of the package. * (and remove /root/.revdep-rebuild.5_order to be evaluated again) * - Modify the above emerge command and run it manually. * - Compile or unmerge unsatisfied packages manually, * remove temporary files, and try again. * (you can edit package/ebuild list first) * * To remove temporary files, please run: * rm /root/.revdep-rebuild*.?_* This sucks!
(In reply to comment #25) > * Warning: Failed to resolve package order. > * Will merge in arbitrary order > !!! '=app-editors/gedit:0' is not a valid package atom. > This sucks! Looks like you are hit by bug 213328 here. As a workaround, update world and run revdep-rebuild again.
Shouldn't we also do a sync first to downgrade packages to the ones that contain the *.la files?
*** Bug 218514 has been marked as a duplicate of this bug. ***
*** Bug 218548 has been marked as a duplicate of this bug. ***
What is the possible advantage to removing .la files? I mean, I understand that gentoo devs like to break things with no warning to users, and I've grown used to it over the years. But usually, there's good reason (i.e., the apache2 change a couple of years ago that screwed over anybody running apache+php with no warning). However, la files are a couple of kilobytes, and I've never seen them break anything...
(In reply to comment #30) > What is the possible advantage to removing .la files? It makes Diego think he's doing something useful. It's an advanced form of ricing where, rather than breaking your own box, you break everyone else's.
(In reply to comment #31) > (In reply to comment #30) > > What is the possible advantage to removing .la files? > > It makes Diego think he's doing something useful. It's an advanced form of > ricing where, rather than breaking your own box, you break everyone else's. i do believe he had his reasons, and whether or not he did it the right way, you might find them in his "sort of" announcement, his blog.
*** Bug 218745 has been marked as a duplicate of this bug. ***
Hmm one of our users just got hit by this, but it's nothing like expat. Personally I'm glad to see some innovation around code rather than constant arguments about compiling it (since people are weighing in with non-technical aspects.) As for users being able to run revdep, it's been standard advice for as long as I've been around to always run revdep at the end of every -uDN world. I agree there should be a big fat "please run revdep-rebuild on libfoo.so.N" warning though, with everything like this. That's become much more prevalent in the last 6 or 7 months from what I've seen. /me votes to cut the guy some slack.
*** Bug 219385 has been marked as a duplicate of this bug. ***
*** Bug 219398 has been marked as a duplicate of this bug. ***
Created attachment 151230 [details] Shell-script to fix removed .la files For those who is too lazy to revdep-rebuild (for me thats 75 packages including OO) that shell-script generates ed-script. I recommend you to do: ./la-fix.sh /usr/lib64 > <ed-script> sed -n 's/^e //p' <ed-script> > /tmp/la-updates.txt tar -cj -T /tmp/la-updates.txt -f <backup>.tar.bz2 Sorry, you actually need to look into file before using it for your safety.
Comment on attachment 151230 [details] Shell-script to fix removed .la files It also fucks with CONTENTS in the VDB.
(In reply to comment #15) > nope, another planet... Planet Gentoo :P You might wish to make your blog posting the URL of this bug report here. http://blog.flameeyes.eu/articles/2008/04/14/what-about-those-la-files If this helps with bug 125728, then good riddance, but right now, it is rather annoying to rebuild half my system, especially a bunch of kde3 packages, for depending on libmad. (In reply to comment #13) > It doesn't _break_ systems. It just requires them to run revdep-rebuild, or to > know how to deal with that in other ways, like using sed. (In reply to comment #23) > By the way you're not exactly forced to rebuild all of them, eh... The alternative being? To manually sed the la files of intermediate packages would in my eyes raise the chances of stale orphaned la files lying around all over the system, as portage won't remove modified files. Some cleaner and faster solution would be needed before this hits stable, imho.
qcheck -u will fix the vdb for you and avoid orphaned files.
*** Bug 219886 has been marked as a duplicate of this bug. ***
*** Bug 220054 has been marked as a duplicate of this bug. ***
*** Bug 220861 has been marked as a duplicate of this bug. ***
I'm hit bit this .la issue, but I can't get rid of it by a simple revdep-rebuild. it happens to me while emerging kdelibs, but I guess it's not strictly related to kdelibs itself. Any hint, besides from creating .la files to avoid cluttering? thanks. /bin/sh ../../libtool --silent --tag=CXX --mode=link i686-pc-linux-gnu-g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2 -march=pentium-m -msse2 -mfpmath=sse -fomit-frame-pointer -pipe -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -o libartskde.la -rpath /usr/kde/3.5/lib -L/usr/kde/3.5/lib -L/usr/qt/3/lib -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined -version-info 3:0:2 artskde.lo kioinputstream_impl.lo kplayobject.lo kplayobjectfactory.lo kartsfloatwatch.lo kartsdispatcher.lo kaudiorecordstream.lo kaudioplaystream.lo kartsserver.lo kdatarequest_impl.lo kaudioconverter.lo kvideowidget.lo kplayobjectcreator.lo kaudiomanagerplay.lo ../../kio/libkio.la -lqtmcop -lsoundserver_idl grep: /usr/lib/libmad.la: No such file or directory /bin/sed: can't read /usr/lib/libmad.la: No such file or directory libtool: link: `/usr/lib/libmad.la' is not a valid libtool archive make[3]: *** [libartskde.la] Error 1
*** Bug 264351 has been marked as a duplicate of this bug. ***
And again... libogg-1.1.4.ebuild: find "${D}" -name '*.la' -delete wtf?
Please reopen bug.
http://bugs.gentoo.org/show_bug.cgi?id=276915 > (In reply to comment #1) > > Dupe: http://bugs.gentoo.org/show_bug.cgi?id=218286 > > > > I could it fix here by running > > lafilefixer --justfixit > > (from package dev-util/lafilefixer) >
Cross reference: bug #271129 might fix these issues here in the long run.
Still a problem. mkdir .libs libtool: link: cannot find the library `/usr/lib64/libogg.la' or unhandled argument `/usr/lib64/libogg.la' make[3]: *** [easytag] Error 1 make[3]: Leaving directory `/var/tmp/portage/media-sound/easytag-2.1.6-r2/work/easytag-2.1.6/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/media-sound/easytag-2.1.6-r2/work/easytag-2.1.6/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/media-sound/easytag-2.1.6-r2/work/easytag-2.1.6' make: *** [all] Error 2 * * ERROR: media-sound/easytag-2.1.6-r2 failed.
(In reply to comment #50) > Still a problem. > > mkdir .libs > libtool: link: cannot find the library `/usr/lib64/libogg.la' or unhandled > argument `/usr/lib64/libogg.la' > make[3]: *** [easytag] Error 1 > make[3]: Leaving directory > `/var/tmp/portage/media-sound/easytag-2.1.6-r2/work/easytag-2.1.6/src' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/var/tmp/portage/media-sound/easytag-2.1.6-r2/work/easytag-2.1.6/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/var/tmp/portage/media-sound/easytag-2.1.6-r2/work/easytag-2.1.6' > make: *** [all] Error 2 > * > * ERROR: media-sound/easytag-2.1.6-r2 failed. > Ok, lafilefixer fixed it.
*** Bug 277799 has been marked as a duplicate of this bug. ***
*** Bug 278152 has been marked as a duplicate of this bug. ***
*** Bug 281430 has been marked as a duplicate of this bug. ***
*** Bug 286908 has been marked as a duplicate of this bug. ***
*** Bug 289575 has been marked as a duplicate of this bug. ***
*** Bug 289598 has been marked as a duplicate of this bug. ***
*** Bug 289816 has been marked as a duplicate of this bug. ***
*** Bug 289832 has been marked as a duplicate of this bug. ***
*** Bug 289838 has been marked as a duplicate of this bug. ***
*** Bug 289864 has been marked as a duplicate of this bug. ***
*** Bug 289899 has been marked as a duplicate of this bug. ***
*** Bug 290017 has been marked as a duplicate of this bug. ***
*** Bug 291050 has been marked as a duplicate of this bug. ***
*** Bug 291550 has been marked as a duplicate of this bug. ***
The following should be added to the Gentoo GCC upgrade or other relevant Gentoo doc or wiki. Solutions especially like this should be well documented if a bug relies on an outside source and uses to mark the bug fixed. # emerge dev-util/lafilefixer # lafilefixer --justfixit This is just my suggestion as it would definitely add some sanity to these reoccurring bugs. And searching Google really didn't show any popular pages with lafilefixer documented. As such, these bugs might be more appropriately marked as "hack works for me (screw everybody who can't search this bug site)"??
> # emerge dev-util/lafilefixer > > # lafilefixer --justfixit This has obviously generated a HUGE amount of needless bug reports and wasted lots of people's time. Why can't portage automate this? Couldn't portage temporarily install lafilefixer when gcc is upgraded, and then run it after the install? Or...some other automated solution?
(In reply to comment #67) > Why can't portage automate this? See bug #271129 about having this in portage.
*** Bug 313843 has been marked as a duplicate of this bug. ***
