.oOo. Good - your configure finished. Start make now cd . && /bin/sh /var/tmp/portage/kiso-0.8.2c/work/kiso-0.8.2/admin/missing --run aclocal-1.9 /usr/share/aclocal/wxwin.m4:36: warning: underquoted definition of AM_OPTIONS_WXCONFIG run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/share/aclocal/wxwin.m4:59: warning: underquoted definition of AM_PATH_WXCONFIG /usr/share/aclocal/vdk-2.m4:7: warning: underquoted definition of AM_PATH_VDK_2 /usr/share/aclocal/sigc++.m4:8: warning: underquoted definition of AM_PATH_SIGC /usr/share/aclocal/pth.m4:43: warning: underquoted definition of _AC_PTH_ERROR /usr/share/aclocal/pth.m4:54: warning: underquoted definition of _AC_PTH_VERBOSE /usr/share/aclocal/pth.m4:60: warning: underquoted definition of AC_CHECK_PTH /usr/share/aclocal/pstoedit.m4:7: warning: underquoted definition of AM_PATH_PSTOEDIT /usr/share/aclocal/pilot-link.m4:1: warning: underquoted definition of AC_PILOT_LINK_HOOK /usr/share/aclocal/path_dps.m4:202: warning: underquoted definition of AC_PATH_DPS_GUESS_GNUSTEP /usr/share/aclocal/path_dps.m4:239: warning: underquoted definition of AC_PATH_DPS_GUESS /usr/share/aclocal/path_dps.m4:333: warning: underquoted definition of AC_PATH_DPS_CHECK_LIB /usr/share/aclocal/path_dps.m4:405: warning: underquoted definition of AC_PATH_DPS_CHECK_HEADER /usr/share/aclocal/path_dps.m4:440: warning: underquoted definition of AC_PATH_DPS_CHECK /usr/share/aclocal/path_dps.m4:450: warning: underquoted definition of AC_PATH_DPS /usr/share/aclocal/path_dps.m4:525: warning: underquoted definition of AC_CHECK_DPS_NXAGENT /usr/share/aclocal/path_dps.m4:558: warning: underquoted definition of AC_PATH_DPSET /usr/share/aclocal/path_dps.m4:579: warning: underquoted definition of AC_PROG_PSWRAP /usr/share/aclocal/path_dps.m4:172: file `path_dps.m4' does not exist make: *** [aclocal.m4] Error 1 !!! ERROR: app-cdr/kiso-0.8.2c failed. !!! Function kde_src_compile, Line 164, Exitcode 2 !!! died running emake, kde_src_compile:make .oOo. diagnostic message refers the user to this URL: http://sources.redhat.com/automake/automake.html#Extending-aclocal Reproducible: Always Steps to Reproduce: 1. emerge -v kiso Actual Results: ebuild died for underquoted macros. Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 2.6.12.1 i686) ================================================================= System uname: 2.6.12.1 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.6.12 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.10 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 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-mtune=athlon-xp -O2 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-mtune=athlon-xp -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://mirror.datapipe.net/gentoo ftp://206.75.217.181/ ftp://gentoo.ccccom.com" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow X Xaw3d aalib accessibility alsa apache2 apm arts audiofile avi berkdb bitmap-fonts bonobo cdr crypt cups curl dga directfb divx4linux doc dvd dvdr eds emboss encode esd ethereal fam fbcon flac font-server foomaticdb fortran freetds gd gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml guile icq imagemagic imagemagick imlib innodb ipv6 jabber java jikes jpeg junit kde lcms ldap lesstiff libg++ libwww mad maildir mikmod mmx motif mozilla mp3 mpeg mysql nas ncurses nls odbc offensive ogg oggvorbis opengl oss pam pda pdflib perl png postgres ppds python qt quicktime readline samba scanner sdl slang speex spell ssl svga tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts unicode usb vorbis winf wxwindows xeo xine xinerama xml xml2 xmms xv yahoo zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Does it help if you move away /usr/share/aclocal/path_dps.m4? (what package does it come from, by the way?)
"Does it help if you move away /usr/share/aclocal/path_dps.m4?" I'm sorry. I don't understand this question. Could you rephrase it differently?
You should run "qpkg -f /usr/share/aclocal/path_dps.m4" to find what package owns that file (run "emerge gentoolkit" first if you don't have qpkg). Then you can see if unmerging that package (or moving away that file, e.g. by doing "mv /usr/share/aclocal/path_dps.m4 /tmp/") makes it possible to emerge kiso without error.
First, thank you for the expanded instructions. Second, I believe qpkg is deprecated and superceded by equery. Yes, I know your the programmer and I'm just Joe Dumb User, but ... :-) Third, moving the file to another location resulted in success. THANK YOU!! I haven't a clue where the file came from to begin with. In addition to the information below, I'm attaching my package log. Finally, I understand English is a second language for you. I'm changing your suggestion so you can see how to say it more clearly. "Does it help if you move away /usr/share/aclocal/path_dps.m4?" to "Does is help to move /usr/share/aclocal/path_dps.m4 to a temporary directory?" I hope the following information is useful. .oOo. dragonfyre ~ # emerge -p gentoolkit These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] app-portage/gentoolkit-0.2.1_pre4 dragonfyre ~ # .oOo. The results of equery are: dragonfyre ~ # equery belongs path_dps.m4 [ Searching for file(s) path_dps.m4 in *... ] dragonfyre ~ # equery belongs /usr/share/aclocal/path_dps.m4 [ Searching for file(s) /usr/share/aclocal/path_dps.m4 in *... ] dragonfyre ~ # .oOo. dragonfyre ~ # mv /usr/share/aclocal/path_dps.m4 /tmp/ dragonfyre ~ # ls -l /usr/share/aclocal/pa* ls: /usr/share/aclocal/pa*: No such file or directory dragonfyre ~ # ls -l /tmp/pa* -rw-r--r-- 1 root root 23332 Jun 5 2004 /tmp/path_dps.m4 dragonfyre ~ # dragonfyre ~ # emerge -uDv kiso Calculating dependencies ...done! >>> emerge (1 of 1) app-cdr/kiso-0.8.2c to / >>> md5 files ;-) kiso-0.8.2c.ebuild >>> md5 files ;-) kiso-0.8.1.ebuild >>> md5 files ;-) files/digest-kiso-0.8.1 >>> md5 files ;-) files/digest-kiso-0.8.2c >>> md5 src_uri ;-) kiso-0.8.2c.tar.bz2 >>> Unpacking source... >>> Unpacking kiso-0.8.2c.tar.bz2 to /var/tmp/portage/kiso-0.8.2c/work >>> Source unpacked. ... config.pl: fast created 6 file(s). config.status: creating config.h config.status: executing depfiles commands Good - your configure finished. Start make now cd . && /bin/sh /var/tmp/portage/kiso-0.8.2c/work/kiso-0.8.2/admin/missing --run aclocal-1.9 /usr/share/aclocal/vdk-2.m4:7: warning: underquoted definition of AM_PATH_VDK_2 run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/share/aclocal/sigc++.m4:8: warning: underquoted definition of AM_PATH_SIGC ... /usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE /usr/share/aclocal/ORBit.m4:4: warning: underquoted definition of AM_PATH_ORBIT cd . && rm -f configure cd . && make -f admin/Makefile.common configure make[1]: Entering directory `/var/tmp/portage/kiso-0.8.2c/work/kiso-0.8.2' cd . && /bin/sh /var/tmp/portage/kiso-0.8.2c/work/kiso-0.8.2/admin/missing --run automake-1.9 --gnu make[1]: Leaving directory `/var/tmp/portage/kiso-0.8.2c/work/kiso-0.8.2' /bin/sh ./config.status --recheck ... --- !targe sym /usr/share/doc/HTML/en/kiso/common >>> Regenerating /etc/ld.so.cache... >>> Regenerating /etc/ld.so.cache... >>> Auto-cleaning packages ... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date.
Created attachment 63344 [details] emerge log This is for scanning through to find possible packages which own file 'path_dps.m4'.
Created attachment 63345 [details] compressed emerge log - ignore first attachment Sorry about this. I initially tried to upload the log as text, got the message it was too big. So compressed it and forgot to change the type setting to binary file.
Thanks for the information. I'm quite sure the responsible package is app-text/dgs, which is an obsolete package that was removed from portage long time ago. For some reason it left path_dps.m4 as an orphaned file, but now that dgs is gone the error should not be reproducible anymore, so I'm closing the bug. I think you can safely remove the file from your system now.
*** Bug 99052 has been marked as a duplicate of this bug. ***
*** Bug 99293 has been marked as a duplicate of this bug. ***
*** Bug 99448 has been marked as a duplicate of this bug. ***
*** Bug 99488 has been marked as a duplicate of this bug. ***
Reopening, obviously this bug was triggered by some recent event... If anyone has an idea that can explain where does this file (/usr/share/aclocal/path_dps.m4) come from and why it started to show up now, it would be greatly appreciated.
(In reply to comment #12) > Reopening, obviously this bug was triggered by some recent event... > > If anyone has an idea that can explain where does this file > (/usr/share/aclocal/path_dps.m4) come from and why it started to show up now, > it would be greatly appreciated. > Greg, The file appeared on my system on June 4, 2004. This is why I included my (compressed) emerge log. I think the file has been there all along. It's just that now it appears to make a difference. The problem may be due to recent changes in 'aclocal-1.9' combined with this historical artifact being present. Or perhaps the 'missing' script run by the kiso emerge may be new or work differently than expected. Since I'm not a programmer, I can't check this. From a logical standpoint, I can't think of anything else. YMMV. :-)
I had the same error that kept me from updating my system (because of lazyness not to care of file a bugreport) for some weeks. I became lazy recently and didn't update as frequently as before. It's about a few months I've updated my system the last time. And I first installed it about 3 years ago. Hence, the error might not have appearead just "recently". >>qpkg -f /usr/share/aclocal/path_dps.m4 app-text/dgs * Well, so dgs is the bad boy after all.
Well, recently for me means: within the last 2 weeks. But it's a rather strange error indeed: If I look at the final fatal error: "/usr/share/aclocal/path_dps.m4:172: file `path_dps.m4' does not exist" And then have a look at line 172 of path_dps.m4: The line starts with "dnl", so it's a comment! The seemingly fatal directive "include('path_dps.m4`)" is in that comment. Irrespective of why the file gets parsed, it even gets parsed in a wrong way! So the error might be in aclocal or even m4, and this file just triggers it. Or some file that was parsed before left something open, i.e. didn't complete a statement.
*** Bug 99588 has been marked as a duplicate of this bug. ***
I am seeing this problem while trying to upgrade libdvdcss. At first it was complaining about m4 files belonging to xmms; as I don't use xmms, I removed it, but now emerging libdvdcss is complaining about m4 files belonging to pth. I notice in my emerge log that m4 was recently upgraded during one of my regular "emerge -Du world"s. I re-emerged pth, and the "emerge libdvdcss" stopped complaining about that particular file; I am going through the process of re-emerging all the packages that own the pther 15-20 m4 files that it's complaining about now.
For what it's worth: The last emerge of 'm4-1.4.3' on my system was April 9 2005 The last emerge of 'libtool-1.5.8-r1' on my system was July 2 2005 Perhaps directing attention to libtool might be fruitful.
*** Bug 100087 has been marked as a duplicate of this bug. ***
*** Bug 100532 has been marked as a duplicate of this bug. ***
*** Bug 101575 has been marked as a duplicate of this bug. ***
No idea why this comes up now - app-text/dgs has been buried nine months ago - but keeping /usr/share/aclocal/ clean is not a kde issue.
so delete the file
*** Bug 101668 has been marked as a duplicate of this bug. ***
*** Bug 101689 has been marked as a duplicate of this bug. ***
*** Bug 103328 has been marked as a duplicate of this bug. ***
At this point, nearly every package I try to emerge gives me this. Please let me know what information I can provide to help get this resolved. RESOLVED/WORKSFORME is totally inappropriate here given how many bugs are marked as duplicates of this one.
There was a workaround given (probably in one of the other bug reports, I can't find it now) which was to add the following to /etc/portage/bashrc: export VARTEXFONTS="${T}" TEXMFVAR="${T}" USE_TEXMFVAR=1 I've no idea what it does, but this problem went away when I put this in. This still doesn't answer the wider questions "why did this happen in the first place" and "what is the correct way to fix it", and I'm also somewhat perplexed as to why this bug has been marked "resolved" when it clearly isn't.
*** Bug 103731 has been marked as a duplicate of this bug. ***
(In reply to comment #28) > "what is the correct way to fix it", and I'm also somewhat perplexed > as to why this bug has been marked "resolved" when it clearly isn't. Delete /usr/share/aclocal/path_dps.m4
(In reply to comment #30) > (In reply to comment #28) > > "what is the correct way to fix it", and I'm also somewhat perplexed > > as to why this bug has been marked "resolved" when it clearly isn't. > > Delete /usr/share/aclocal/path_dps.m4 Er, NO. Haven't you been reading the other bug reports? This is happening to HUNDREDS of files. Why? You expect me to go and delete every single one? Until I put that bashrc fix in place, I would have had to go and delete 20-30 files for each of about 15 packages that caused this error to appear. This problem just appeared out of the blue, there was no problem with this files before. Please stop being so dismissive. It is rather frustrating when a developer won't acknowledge that there's even a problem.
really have no idea what you're talking about, all the other bug reports refer to path_dps.m4 not sure why you think exporting tetex related variables would fix automake related bugs
(In reply to comment #32) > really have no idea what you're talking about, all the other bug reports refer > to path_dps.m4 > > not sure why you think exporting tetex related variables would fix automake > related bugs Hmm .. ok, maybe I am confused about the bashrc thing. My original post to this bug said: "I am seeing this problem while trying to upgrade libdvdcss. At first it was complaining about m4 files belonging to xmms..." I had trouble emerging libdvdcss because of an m4 file belonging to xmms. I removed xmms and then the emerge started complaining about pth. Why did it start complaining about these m4 files, which were perfectly fine before? It was more than just the pth m4 files that were affected, even when I re-emerged pth and moved those dud m4 files out of the way I was getting further complaints from other m4 files belonging to other packages. Anyway, I can't seem to recall what I did to fix it, and I don't see the problem now (can't replicate it), so forget about it.
*** Bug 103909 has been marked as a duplicate of this bug. ***
*** Bug 104023 has been marked as a duplicate of this bug. ***
*** Bug 104063 has been marked as a duplicate of this bug. ***
*** Bug 104146 has been marked as a duplicate of this bug. ***
*** Bug 104323 has been marked as a duplicate of this bug. ***
Just FYI: Another success report here: emerge -C dgs did the trick for me (thanks to Jakub for dupe-marking my original bug report - should have searched harder :) ). The problem happend on my oldest Gentoo install, from Sun Mar 30 14:58:18 2003.
> emerge -C dgs This worked for me too. I had an old gentoo box (last update about a year ago) suffer this issue. Shouldn't the "dgs" package be removed automatically if it disappears from portage? Or at least some mechanism to report that the you have obsoleted ebuilds installed?
*** Bug 104590 has been marked as a duplicate of this bug. ***
*** Bug 104686 has been marked as a duplicate of this bug. ***
*** Bug 104726 has been marked as a duplicate of this bug. ***
now i can resume my ricing. woowhoo!
*** Bug 104817 has been marked as a duplicate of this bug. ***
I also experienced this bug. I recently upgraded automake, so I propose that the new version of automake, 1.9.6, may be to blame. Trying this theory: emerge -av =sys-devel/automake-1.9.5 Yes! This fixed it! Automake-1.9.6 should have blocked "app-text/dgs" We will need an -r1 version of automake I think, just to force users to deinstall dgs.
*** Bug 104230 has been marked as a duplicate of this bug. ***
*** Bug 105053 has been marked as a duplicate of this bug. ***
Same Problem here. Unmerging dgs works.
*** Bug 105506 has been marked as a duplicate of this bug. ***
I am also having this problem as well, with the same file. I noticed the line: <<< obj /usr/share/aclocal/path_dps.m4 In the unmerge of dgs (though i'm sure 'qpkg -f /usr/share/aclocal/path_dps.m4' would have told me the same). I don't know what the precise cause is, but there is definately a bug here. app-text/dgs isn't even a package anymore, it should be marked as a blocker for automake-1.9.6. I had this problem immediately after upgrading. An error in the file /usr/share/aclocal/path_dps.m4 from app-text/dgs is probably either causing a bug in automake, or is just so broken that it causes automake to die.
*** Bug 105550 has been marked as a duplicate of this bug. ***
*** Bug 105592 has been marked as a duplicate of this bug. ***
*** Bug 105275 has been marked as a duplicate of this bug. ***
*** Bug 105914 has been marked as a duplicate of this bug. ***
*** Bug 105965 has been marked as a duplicate of this bug. ***
*** Bug 105989 has been marked as a duplicate of this bug. ***
OK, can we package.mask app-text/dgs to make people unmerge the damned thing and see if it stops these bug reports? This bug has already zillion duplicates w/ lots of packages that have mostly nothing in common w/ each other. Still wondering why the issue appeared just now and not earlier.
Hmm OK, the above won't work b/c nothing depends on it. Besides some crazy things like blocking app-text/dgs in sys-devel/automake, out of ideas. Bleh... :(
Since this appears to affect users with long-running Gentoo systems, perhaps an official announcement might help? Or a forum sticky?
i dont know who is the maintainer of this package was but i dont see why we cant install a dummy ebuild (say dgs-1234) which is empty and thus the upgrade forces the removal of the package ... or have it call 'die' and be like 'HEY USER PLZ UNMERGE ME KTHX'
I shouldn't think that you'd need a maintainer to do #61, since the pacakge is, right now, no longer in Portage, right? All it would take is a harried dev to make the fake pacakge, add it to the tree, and delight in their newfound freedom from this silly bug. ;)
added a fake dgs-1234 ebuild
*** Bug 106111 has been marked as a duplicate of this bug. ***
*** Bug 106419 has been marked as a duplicate of this bug. ***
*** Bug 107058 has been marked as a duplicate of this bug. ***
*** Bug 107117 has been marked as a duplicate of this bug. ***
*** Bug 107455 has been marked as a duplicate of this bug. ***
*** Bug 107466 has been marked as a duplicate of this bug. ***
*** Bug 107639 has been marked as a duplicate of this bug. ***
*** Bug 107695 has been marked as a duplicate of this bug. ***
*** Bug 107985 has been marked as a duplicate of this bug. ***
(In reply to comment #63) > added a fake dgs-1234 ebuild I'm not sure this will help very much, since any ebuilds that an "emerge world" tries before the fake dgs will still die - Portage needs to give a "compile-time" error that shows up *before* anything else happens, and I think this can only be done with some sort of block between automake and dgs.
*** Bug 108107 has been marked as a duplicate of this bug. ***
I've just run into this problem too, during an emerge -e world after moving to gcc 3.4 The problem is I didn't explicitly emerge dgs so it's never been updated to the new fake ebuild, and for some reason it tried to emerge libtool before the fage dgs. I agree with the other comments that dgs should be marked as blocking other packages that are affected by this bug. From the looks of things you've gotten a nice list already from all the duplicates :)
*** Bug 108908 has been marked as a duplicate of this bug. ***
Argh, is there really no way in portage to force people to unmerge that dgs crap *immediately*? :(
*** Bug 108934 has been marked as a duplicate of this bug. ***
*** Bug 109100 has been marked as a duplicate of this bug. ***
*** Bug 109342 has been marked as a duplicate of this bug. ***
*** Bug 109398 has been marked as a duplicate of this bug. ***
*** Bug 109412 has been marked as a duplicate of this bug. ***
*** Bug 109520 has been marked as a duplicate of this bug. ***
(In reply to comment #77) > Argh, is there really no way in portage to force people to unmerge that dgs crap > *immediately*? :( > Looking at the issues other people have been having, and the number of duplicates that continue to be filed, surely we can find something to do about this? It's not that this bug only surfaces when emerging odd packages - it blocked libtool for me today (I originally reported when it blocked gnome-spell). Would blocking a newer version of autoconf-wrapper be ok (on the basis that nobody much cares if they have to re-emerge autoconf-wrapper given how lightweight it is?)
I think this warrants a HEADLINE in #gentoo*, a sticky on all related boards on forums.gentoo.org, a headline on the newsletter, a note on the webpage, a headline note on gentoo-wiki, posts on Gentoo-announce and on every other (rational) user-facing gentoo mailing list. It's embarassing but we should go a long way towards solving the problem so that people can be proactive about it instead of getting bitten and possibly cursing Gentoo all the more.
Comments about the inappropriateness of WORKSFORME have been made, and I realize that bugzilla's status/resolution states don't lend themselves very well to this kind of bug, so I won't retread that. However, I do want to point out that you would not receive so many duplicates if the bug was not closed, as the default bugzilla search is for open bugs.
A question: (I'm just a dumb Gentoo user, but just asking) Is there a possibility to fix this in the portage tool itself? Once, before I could emerge any other thing, I got a message saying I should update portage to some newer version than I had, though I don't know which system caused this message. My way of using portage, is downloading the compressed snapshot-portage dir, and if this would ask the user to update portage before anything else, and portage makes sure dgs is gone, the bug could be solved for many people I think.
*** Bug 109563 has been marked as a duplicate of this bug. ***
*** Bug 109696 has been marked as a duplicate of this bug. ***
This errror struck me during the "emerge -uv world" I did last night. Unfortunately you can't find this bug report very easy so I suggest opening the bug again. For me it was libtool which caused the error, after removing dgs everything works fine.
*** Bug 109052 has been marked as a duplicate of this bug. ***
*** Bug 110123 has been marked as a duplicate of this bug. ***
*** Bug 110125 has been marked as a duplicate of this bug. ***
*** Bug 110310 has been marked as a duplicate of this bug. ***
*** Bug 110342 has been marked as a duplicate of this bug. ***
Luft was better than me at finding this bug report. This sort of thing needs to be cross-indexed in bugzilla to the various packages which it will cause to fail. The most usual way to file a failed-emerge type bug report is under a Summary that names the package that failed. If you're going to expect people to find a particular error message (from among many in this case) that links to an obscure report like this ... well, that's why you get all the marked duplicates here that make this one a mess to read even when you get here. But instead of _encouraging_ cross indexing (which at least marking things a dups clumsily accomplished) I got blamed for not being skilled enough at deducing what to search for. That's counterproductive. If I hadn't filed the report, the cross-indexing from the package where this actually shows up for some of us wouldn't be in the database.
Sorry, this is just ridiculous! I just stumbled over this bug and reading this bug report can really drive a Gentoo user mad. You know that an orphaned package is causing the bug. You know that the latest version of automake triggers it. So what in hell makes you think that a fake dgs-ebuild will resolve this bug for the average user? How should _anyone_ who didn't read this bug report get the idea to emerge this ebuild? I'm pretty sure no one ever installed dgs consciously, so no one will have it in the world file. So an "emerge -u world" won't do. As no current package depends on dgs, "emerge -uD world" also doesn't do the trick. So of what use is the fake ebuild after all? I'm reading complaints that there should be a way in portage to tell users to unmerge blocking packages like the orphaned dgs. Damn, this way already exists! It's called "blocking" and it has been working satisfactorily for years. I don't know if making dgs a blocker of automake will resolve this for everyone, but judging from the duplicates and the comments on this bug it should be worth a try! Putting up notes in forums, newsletters and the like is a bad "solution". A Gentoo user expects portage to report problems like this one, so why don't you just put a dgs-blocking automake-1.9.6-r2 into the portage tree NOW? Sorry for the bad English and the screaming, but this feels really arghlglgl...
*** Bug 111260 has been marked as a duplicate of this bug. ***
*** Bug 111417 has been marked as a duplicate of this bug. ***
I agree that having dgs block automake feels right. I for one saw the problem with dev-lang/php-5.0.5-r1. I looked up the offending file in /var/db/pkg (yeahyeah, but equery is too slow) and tried emerge dgs, which gave me a new package with polite information about this bug. If you know that packages provide .m4 files in the aclocal directory, it's fairly natural to try to re-emerge/update a package whose m4-file is causing problems. But sure, it would be nice if users didn't have to know that. :)
*** Bug 111469 has been marked as a duplicate of this bug. ***
*** Bug 111977 has been marked as a duplicate of this bug. ***
*** Bug 118895 has been marked as a duplicate of this bug. ***
*** Bug 104700 has been marked as a duplicate of this bug. ***
*** Bug 118989 has been marked as a duplicate of this bug. ***
*** Bug 118990 has been marked as a duplicate of this bug. ***
*** Bug 121675 has been marked as a duplicate of this bug. ***
*** Bug 121930 has been marked as a duplicate of this bug. ***
*** Bug 132661 has been marked as a duplicate of this bug. ***
*** Bug 140814 has been marked as a duplicate of this bug. ***
