Bugzilla Bug 98762

.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 an attachment (id=63344) [edit]
emerge log

This is for scanning through to find possible packages which own file
'path_dps.m4'.

Created an attachment (id=63345) [edit]
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 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. ***