dev-perl/XML-Parser not in dependencies for gnome-vfs-2.4.2-r1 Reproducible: Always Steps to Reproduce: 1.unmerge dev/perl/XML-Parser 2.emerge gnome-vfs-2.4.2-r1 3. Actual Results: ebuild stops while configure
it deps on >=intltool-0.29 which deps on XML-Parser.
emerging gnome-vfs-2.4.2-r1: ******************************************************************* checking for perl... /usr/bin/perl configure: error: XML::Parser perl module is required for intltool !!! ERROR: gnome-base/gnome-vfs-2.4.2-r1 failed. !!! Function econf, Line 365, Exitcode 1 !!! econf failed ******************************************************************* Running the test from gnome-vfs ./configure script: ******************************************************************* # perl -e "require XML::Parser" 2>&1 | tr ' ' '\n' Can't locate XML/Parser.pm in @INC (@INC contains: /etc/perl /usr/lib/perl5/site_perl/5.8.2/i686-linux /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl/5.8.0/i686-linux /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.2/i686-linux /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl/5.8.0/i686-linux /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.2/i686-linux /usr/lib/perl5/5.8.2 /usr/local/lib/site_perl /usr/lib/perl5/site_perl/5.8.0/i686-linux /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl/5.6.1 .) at -e line 1. ******************************************************************* Location of XML-Parser: ******************************************************************* # qpkg -l XML-Parser | grep Parser.pm /usr/lib/perl5/site_perl/5.6.1/i686-linux/XML/Parser.pm /usr/lib/perl5/site_perl/5.6.1/i686-linux/XML/Parser.pm ******************************************************************* Seems like the problem is that /usr/lib/perl5/site_perl/5.6.1/i686-linux is missing from the @INC-thingy. I know nothing about perl, so I don't know how to trace the bug further (who has forgotten to include the directory; perl? XML-Parser?) Trying to re-emerge XML-Parser... ...and now it works! Seems like it installed itself into a new location: ******************************************************************* # qpkg -l XML-Parser | grep Parser.pm /usr/lib/perl5/site_perl/5.6.1/i686-linux/XML/Parser.pm /usr/lib/perl5/vendor_perl/5.8.2/i686-linux/XML/Parser.pm ******************************************************************* Conclusion: Something perl needs to be fixed.
perl problem needs explanation.
The problem is that the warning, issued at the end of all installs of the perl-5.8 series, and discussed to no end on the mailing lists a year or so ago now, was not heeded. When upgrading from a major point release of perl, modules and executable code compiled against the 5.6.X version of perl must be re-installed. The location of XML-Parser, in this case, is in a perl 5.6.1 directory which is not part of the user's @INC anymore. This is not a gentoo perl issue.
Timo - for what it's worth, there is a script in <PORTAGE>/dev-lang/perl/files/ called libperl_rebuilder which does a decent attempt at helping out. It isn't perfect, but what it does is to essentially look for any perl related ebuilds you have installed (modules, etc) and attempt to re-emerge them. Hope this helps!] -Mike
Sorry for all the posts, its the work of coffee in my system this morning. Timo/foser - the problem with XML::Parser is that it is compiled as xs code, i.e. against libperl and the libxml libraries to produce a binary module that is usable by perl. When upgrading from 5.6.X to 5.8 (and if you're playing with the beta releases, within some of the 5.8.x tree as well) the API used by perl to interface between external libraries and the perl intrepeter has changed. The rebuilder script I mentioned rebuilds any perl modules and perl dependant items that you have emerged in the past to overcome this change. It is at best a hack (I can say that as I wrote at least the first incarcation of it) and may be overkill in this case. Re-emerging the XML::Parser and related modules will solve your problem in the short term, but the long term problem is that any module you installed under 5.6.1 that isn't *pure* perl but that instead links to something external will fail until rebuilt. This is actually covered in the perl release notes and easily verified. I hope this helps, -Mike
*** Bug 42579 has been marked as a duplicate of this bug. ***
ok closing again after the conclusive explanation by mcummings (thnx). This is not our problem.
*** Bug 45433 has been marked as a duplicate of this bug. ***
*** Bug 48387 has been marked as a duplicate of this bug. ***
*** Bug 49869 has been marked as a duplicate of this bug. ***
*** Bug 50944 has been marked as a duplicate of this bug. ***
*** Bug 52668 has been marked as a duplicate of this bug. ***
*** Bug 54863 has been marked as a duplicate of this bug. ***
*** Bug 65754 has been marked as a duplicate of this bug. ***
*** Bug 71125 has been marked as a duplicate of this bug. ***
*** Bug 54195 has been marked as a duplicate of this bug. ***
*** Bug 71081 has been marked as a duplicate of this bug. ***
*** Bug 71222 has been marked as a duplicate of this bug. ***
*** Bug 71329 has been marked as a duplicate of this bug. ***
*** Bug 72256 has been marked as a duplicate of this bug. ***
*** Bug 72683 has been marked as a duplicate of this bug. ***
*** Bug 72743 has been marked as a duplicate of this bug. ***
The package required to be emerged is dev-perl/XML-Parser and not XML::Parser. emerge XML-Parser
*** Bug 72793 has been marked as a duplicate of this bug. ***
*** Bug 73005 has been marked as a duplicate of this bug. ***
*** Bug 73577 has been marked as a duplicate of this bug. ***
*** Bug 73690 has been marked as a duplicate of this bug. ***
*** Bug 73773 has been marked as a duplicate of this bug. ***
*** Bug 73776 has been marked as a duplicate of this bug. ***
*** Bug 73789 has been marked as a duplicate of this bug. ***
*** Bug 73892 has been marked as a duplicate of this bug. ***
due to this amount of bug-reports maybe we should add a XML-Parser dependency directly?
The packages already dep on xml-parser via intltool. The problem is xml-parser _needs_ to be rebuild after a perl update, but there is no way to tell that to portage. Portage sees the xml-parser package as already being installed and moves on to the next dep. Adding xml-parser as a direct dep would have no effect towards that.
Ok, but I've never had perl 5.6 on this system, so I'm not sure why it would have caused a problem.
*** Bug 74143 has been marked as a duplicate of this bug. ***
*** Bug 74919 has been marked as a duplicate of this bug. ***
*** Bug 75226 has been marked as a duplicate of this bug. ***
*** Bug 75688 has been marked as a duplicate of this bug. ***
*** Bug 75915 has been marked as a duplicate of this bug. ***
*** Bug 76080 has been marked as a duplicate of this bug. ***
*** Bug 80013 has been marked as a duplicate of this bug. ***
*** Bug 80237 has been marked as a duplicate of this bug. ***
*** Bug 82156 has been marked as a duplicate of this bug. ***
*** Bug 82213 has been marked as a duplicate of this bug. ***
I wonder how feasable it would be to incorporate interoperability between either portage and CPAN or each ebuild working with CPAN. I'm new to gentoo, but CPAN would seem ideal. Although I do remember cpan being a kinda nasty last time I used it with slackware 10
*** Bug 82586 has been marked as a duplicate of this bug. ***
*** Bug 82880 has been marked as a duplicate of this bug. ***
*** Bug 88019 has been marked as a duplicate of this bug. ***
Because people still add themselves to this bug, a note (over a year later). libperl_rebuilder has been replaced with perl-cleaner, which is by most accounts cleaner, faster, --oneshot, and guaranteed to make your hair grow (maybe not the last part).
*** Bug 88260 has been marked as a duplicate of this bug. ***
*** Bug 91488 has been marked as a duplicate of this bug. ***
*** Bug 91822 has been marked as a duplicate of this bug. ***
*** Bug 92462 has been marked as a duplicate of this bug. ***
*** Bug 92547 has been marked as a duplicate of this bug. ***
*** Bug 92562 has been marked as a duplicate of this bug. ***
*** Bug 93705 has been marked as a duplicate of this bug. ***
*** Bug 94526 has been marked as a duplicate of this bug. ***
*** Bug 95992 has been marked as a duplicate of this bug. ***
*** Bug 96247 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Timo - for what it's worth, there is a script in > <PORTAGE>/dev-lang/perl/files/ called libperl_rebuilder which does a decent > attempt at helping out. It isn't perfect, but what it does is to essentially > look for any perl related ebuilds you have installed (modules, etc) and > attempt to re-emerge them. Hope this helps!] in my 2005.0 system, there is no libperl_rebuilder around, but instead, we shall use: /usr/portage/dev-lang/perl/files/perl-cleaner all what may do a bit too much, but which will hopefully fix the bug the Gentoo way. I write this repport at once, and hope this script will fix my box before tonight. Note that XML::Parser is the perl module. In any case, NOBODY should ever try emerge XML::Parser thats a very strange mistake. :: is the module seperator for Perl, not the package descriptor for portage !!! I dont even think emerge XML-Parser should ever be run, since perl-cleaner is alreade THE SCRIPT designed to solve the actual problem. BUT: I think that updates of perl should warn and remind to run perl-cleaner to rebuild everything cleanly.
(In reply to comment #61) > BUT: I think that updates of perl should warn and remind to run perl-cleaner to > rebuild everything cleanly. Perl does and has for over a year now. The problem is that it gets lost in the shuffle of mass updates (no solution available to that). Also, perl-cleaner has been broken out from that version and is now emergeable as its own application (for future inclusion as an option to revdep_rebuild).
*** Bug 97653 has been marked as a duplicate of this bug. ***
Okay. What is an end user (such as me who filed the above bug (and apparently wasted my time)) supposed to do? It appears this has been a problem for a very long time. Over a year.
(In reply to comment #64) > Okay. What is an end user (such as me who filed the above bug (and apparently > wasted my time)) supposed to do? Run perl-cleaner...
*** Bug 97840 has been marked as a duplicate of this bug. ***
*** Bug 97901 has been marked as a duplicate of this bug. ***
*** Bug 98016 has been marked as a duplicate of this bug. ***
*** Bug 100768 has been marked as a duplicate of this bug. ***
*** Bug 101016 has been marked as a duplicate of this bug. ***
*** Bug 101316 has been marked as a duplicate of this bug. ***
*** Bug 101385 has been marked as a duplicate of this bug. ***
(In reply to comment #65) > (In reply to comment #64) > > Okay. What is an end user (such as me who filed the above bug (and apparently > > wasted my time)) supposed to do? > > Run perl-cleaner... well i did and nothing changed.
*** Bug 103527 has been marked as a duplicate of this bug. ***
*** Bug 103646 has been marked as a duplicate of this bug. ***
*** Bug 103730 has been marked as a duplicate of this bug. ***
*** Bug 107524 has been marked as a duplicate of this bug. ***
(In reply to comment #73) > (In reply to comment #65) > > (In reply to comment #64) > > > Okay. What is an end user (such as me who filed the above bug (and apparently > > > wasted my time)) supposed to do? > > > > Run perl-cleaner... > > well i did and nothing changed. perl-cleaner modules worked for me but I never saw the message to run this as my update went by as part of an emerge -uD world. Perhaps there could be a portage enhancement to summarise these types of messages at the end of an emerge operation?
*** Bug 107655 has been marked as a duplicate of this bug. ***
*** Bug 108273 has been marked as a duplicate of this bug. ***
*** Bug 108423 has been marked as a duplicate of this bug. ***
*** Bug 108979 has been marked as a duplicate of this bug. ***
*** Bug 109603 has been marked as a duplicate of this bug. ***
*** Bug 110075 has been marked as a duplicate of this bug. ***
Oh, god. Why don't we just add an explicit dependency on XML-Parser on the said Gnome packages' ebuild? That might not be the solution for people doing emerge syncs (see Comment #78, for example), but it will at least solve issues with *fresh* GRP 2005.1 installations. Is it *that* hard to put an extra line on the RDEPEND entry in the ebuild?
reply @ #85 Its not that simple. all of theese people already have XML-Parser installed. -all- of them. They also failed to rebuild it when they updated perl, so the module wasn't found with the current perl install. This is a symptomous bug in the current setup where an upgrade cannot force rebuilds of all sub-dependancies. Nothing will be solved by the added DEPEND.
Does perl have the equivilant of python-updater or revdep-rebuild? Could it be run automatically when perl is upgraded?
there is perl-cleaner, but it cannot be automated. We don't invoke "emerge" from inside "emerge" , that would cause a horrid can of worms to come into being. And really, perl is too big to just PDEPEND on everything ever built and linked against it... I'm sure you wouldn't want to open that mess either, right? you -get- told to run perl-cleaner, but the problem here is once more, that of people not seeing/Caring about the notes given to them post-emerge.
I can certainly understand not wanting to run emerge from within emerge. Maybe ebuild needs an "after" function, that schedules some program to be run after emerge ends? The, that could run things like revdep-rebuild, perl-cleaner, python-updater... Nah, we can just say "run perl-cleaner" and close the bug.
we probably don't want to do that sort of thing from a stability standpoint. Ie, since many of the "after" tools could well require human supervision, Double installs of python and such items come to mind, then we don't just want to be there and force things down their throats. Anyhow, this is digressing into a portage featurism discussion. Solution: run perl-cleaner. dupe bug 41124
*** Bug 110800 has been marked as a duplicate of this bug. ***
*** Bug 110842 has been marked as a duplicate of this bug. ***
*** Bug 111467 has been marked as a duplicate of this bug. ***
*** Bug 111632 has been marked as a duplicate of this bug. ***
*** Bug 116296 has been marked as a duplicate of this bug. ***
Jakub, why did you remove everybody from the CC list?
(In reply to comment #96) > Jakub, why did you remove everybody from the CC list? Hint: So that I wouldn't bugspam tens of people everytime someone does not bother w/ reading ebuild instructions after perl upgrade and/or searching for dupes? :P
*** Bug 116625 has been marked as a duplicate of this bug. ***
*** Bug 120818 has been marked as a duplicate of this bug. ***
*** Bug 123413 has been marked as a duplicate of this bug. ***
*** Bug 124535 has been marked as a duplicate of this bug. ***
*** Bug 124957 has been marked as a duplicate of this bug. ***
I have a fresh AMD64 install, an intended upgrade. I copied over my world file and had ebuild work through it... and guess what I find. Somehow intltool is built, perl is rebuilt, and XML::Parser is missing. With the amount of duplicates here, I think forcing a XML::Parser dependency is a good idea. The module is specifically searched for in (for example) gnome-mime-data's ./configure. As described above, intltool will bring it in, but if it's already installed but perl's moved around or reinstalled, XML::Parser dies. Maybe emerge needs to know more about Perl...
*** Bug 125064 has been marked as a duplicate of this bug. ***
(In reply to comment #103) Won't help anything at all, it's already installed. You *must* run perl-cleaner after upgrading perl.
*** Bug 125811 has been marked as a duplicate of this bug. ***
"perl is rebuilt" means recompiled from the same version. When I was doing the emerges to rebuild my rig for AMD64, Perl would alternate between 5.8.7 and 5.8.8 many times. It would downgrade, then upgrade, then downgrade, then upgrade, and I hadn't touched my /etc/make.conf and /etc/portage/package.keywords. Even if I hit perl-cleaner to reinstall XML::Parser (it was installed before), XML::Parser was missing. Yes, I know XML::Parser's required for intltool, but we are running into a situation in which gnome-vfs is *specifically asking* for XML::Parser and not just intltool. It's directly asking Perl if it has it, and folks are filing bugs that are proving that we cannot be 100% sure between the time intltool gets installed and gnome-vfs is emerged that XML::Parser is going to exist. We know we *should* have it, but should and actually have are two different things. It's like the hearsay rules in a court of law -- what one person hears another say has much less weight than what that latter person actually said (we get it from the horse's mouth, hay breath and all).
Just a 2cents worth - you could always check in unpack with something like: perl -MXML::Parser -e 'print "$XML::Parser::VERSION"' to make sure it comes back with a value and stop if not.
*** Bug 127804 has been marked as a duplicate of this bug. ***
*** Bug 128199 has been marked as a duplicate of this bug. ***
*** Bug 128280 has been marked as a duplicate of this bug. ***
*** Bug 128312 has been marked as a duplicate of this bug. ***
What's needed is a way of producing upgrade/update notes at the End of a mass-update instead of per package. Very few have the time or forethought to log an entire emerge, and then check it's output for detailed update notes. Instead an update log should be produced, and if there is a likelyhood that something needs to be run, the user should be told... '!!! IMPORTANT !!! You must read ~/emerge-update.DATESTAMP.txt it contains vital post-update instructions for keeping your system working.' Also, why doesn't emerging perl force a 'perl-clean modules' it looks like that invocation is Supposed to fix exactly this problem, and re-emerging perl IS one of the steps I tried after manually running cpan and being told it was already installed... I'd never have thought to look for an XML-Parser ebuild since that should upgrade as well.
(In reply to comment #113) > What's needed is a way of producing upgrade/update notes at the End of a > mass-update instead of per package. Very few have the time or forethought to > log an entire emerge, and then check it's output for detailed update notes. > > Instead an update log should be produced, and if there is a likelyhood that > something needs to be run, the user should be told... > > '!!! IMPORTANT !!! You must read ~/emerge-update.DATESTAMP.txt it contains > vital post-update instructions for keeping your system working.' > Unfortunately, that doesn't handle the case in which perl is being recompiled before gnome-vfs while running an emerge --deep --update --newuse world. > Also, why doesn't emerging perl force a 'perl-clean modules' it looks like that > invocation is Supposed to fix exactly this problem, and re-emerging perl IS one > of the steps I tried after manually running cpan and being told it was already > installed... I'd never have thought to look for an XML-Parser ebuild since > that should upgrade as well. > I'm for that, but I'm also for adding dev-perl/XML-Parser in the dependencies of gnome-vfs for reasons I stated above (gnome-vfs specifically checks for it, the dependency-of-a-dependency is similar to heresay in legal circles, and it's Perl -- assume the user is too lazy to run perl-cleaner, too impatient to run perl-cleaner, and has the hubris to say the above).
"...assume the user is too lazy to run perl-cleaner, too impatient to run perl-cleaner..." Assume the is NOT to lazy to run perl-cleaner, and is NOT to impatient to run perl-cleaner. Assume that the user doesn't REALIZE he needs to run perl-cleaner because the message has scrolled off the screen, or doesn't stand out in the morass of text that continually spews out of emerge. Assume that the message that tells the user to perl-cleaner doesn't tell them what option(s) they need to run it with. Assume that's a lot more like the reality of 99.44% of the users who hit this problem.
*** Bug 128582 has been marked as a duplicate of this bug. ***
*** Bug 128676 has been marked as a duplicate of this bug. ***
(In reply to comment #113) > What's needed is a way of producing upgrade/update notes at the End of a > mass-update instead of per package. Very few have the time or forethought to > log an entire emerge, and then check it's output for detailed update notes. At least for my sys-apps/portage-2.1_pre7-r4, the ELOG features described in /etc/make.conf.example do this quite well. They send me an email for every warning or error message encountered while running some ebuild. So this feature is coming, although it might not have reached stable status yet.
*** Bug 129476 has been marked as a duplicate of this bug. ***
*** Bug 129647 has been marked as a duplicate of this bug. ***
*** Bug 81077 has been marked as a duplicate of this bug. ***
*** Bug 131049 has been marked as a duplicate of this bug. ***
*** Bug 131172 has been marked as a duplicate of this bug. ***
*** Bug 131868 has been marked as a duplicate of this bug. ***
I believe that for me a dependency intltools-->XML-Parser would have cured my "emerge --update world" problem, as it seems as if XML-Parser has not been installed on my system (at least emerge did not report a previous module and did not try to remove something after emerging XML-Parser). True, this dependency does not solve the problem of Perl-Updates, but it may solve an other problem.
*** Bug 132233 has been marked as a duplicate of this bug. ***
If you have 5 Packages listed in emerge -pu world, do you bother scrolling up for each of the compile stuff and look if there *could* be an info? I once suggested that important messages about ebuilds should be output at the *end* of *all* ebuilds, along with their package names.
*** Bug 132684 has been marked as a duplicate of this bug. ***
*** Bug 133160 has been marked as a duplicate of this bug. ***
Just to add to the long bug... XML-Parser was never on my system at all. When I ran "emerge -pv XML-Parser" (because I saw xkeyboard-config explode when XML::Parser.pm file was missing) it was going to be a "n" new ebuild. My system is was a pretty fresh install.
*** Bug 133652 has been marked as a duplicate of this bug. ***
*** Bug 133886 has been marked as a duplicate of this bug. ***
*** Bug 134361 has been marked as a duplicate of this bug. ***
*** Bug 134421 has been marked as a duplicate of this bug. ***
*** Bug 135425 has been marked as a duplicate of this bug. ***
*** Bug 135628 has been marked as a duplicate of this bug. ***
(In reply to comment #136) > *** Bug 135628 has been marked as a duplicate of this bug. *** > Hi sorry can you provide a summary of steps to solve/workaround the problem? I've tried to do what I thought was the solution: 1.unmerge dev/perl/XML-Parser 2.emerge gnome-vfs-2.4.2-r1 even run perl-cleaner all but again when I try to emerge gnome-vfs it fails with same sort of error checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool !!! Please attach the following file when filing a report to bugs.gentoo.org: !!! /var/tmp/portage/gnome-vfs-2.14.1/work/gnome-vfs-2.14.1/config.log !!! ERROR: gnome-base/gnome-vfs-2.14.1 failed. Call stack: ebuild.sh, line 1539: Called dyn_compile ebuild.sh, line 939: Called src_compile ebuild.sh, line 1248: Called gnome2_src_compile gnome2.eclass, line 57: Called gnome2_src_configure gnome2.eclass, line 53: Called econf '--disable-schemas-install' '--disable-howl' '--enable-http-neon' '--enable-openssl' '--disable-gnutls' '--enable-samba' '--enable-ipv6' '--disable-hal' '--disable-avahi' '--disable-gtk-doc' ebuild.sh, line 541: Called die !!! econf failed
Ok, it worked now, I needed to update the intltool, otherwise it wouldn't work. So my steps where, 1.unmerge dev/perl/XML-Parser 2.perl-cleaner all 3.emerge intltool (a new version was available and XMLParser was emerged) 4.emerge gnome-vfs 5.Restart doing what I was doing upgrade to x11 modular. Thanks, Pablo (In reply to comment #137) > (In reply to comment #136) > > *** Bug 135628 has been marked as a duplicate of this bug. *** > > > Hi sorry can you provide a summary of steps to solve/workaround the problem? > I've tried to do what I thought was the solution: > 1.unmerge dev/perl/XML-Parser > 2.emerge gnome-vfs-2.4.2-r1 > > even run perl-cleaner all > but again when I try to emerge gnome-vfs it fails with same sort of error > > > checking for XML::Parser... configure: error: XML::Parser perl module is > required for intltool > > !!! Please attach the following file when filing a report to bugs.gentoo.org: > !!! /var/tmp/portage/gnome-vfs-2.14.1/work/gnome-vfs-2.14.1/config.log > > !!! ERROR: gnome-base/gnome-vfs-2.14.1 failed. > Call stack: > ebuild.sh, line 1539: Called dyn_compile > ebuild.sh, line 939: Called src_compile > ebuild.sh, line 1248: Called gnome2_src_compile > gnome2.eclass, line 57: Called gnome2_src_configure > gnome2.eclass, line 53: Called econf '--disable-schemas-install' > '--disable-howl' '--enable-http-neon' '--enable-openssl' '--disable-gnutls' > '--enable-samba' '--enable-ipv6' '--disable-hal' '--disable-avahi' > '--disable-gtk-doc' > ebuild.sh, line 541: Called die > > !!! econf failed >
*** Bug 136462 has been marked as a duplicate of this bug. ***
*** Bug 136764 has been marked as a duplicate of this bug. ***
*** Bug 138529 has been marked as a duplicate of this bug. ***
*** Bug 139078 has been marked as a duplicate of this bug. ***
*** Bug 139896 has been marked as a duplicate of this bug. ***
*** Bug 141548 has been marked as a duplicate of this bug. ***
*** Bug 141787 has been marked as a duplicate of this bug. ***
*** Bug 142736 has been marked as a duplicate of this bug. ***
*** Bug 142895 has been marked as a duplicate of this bug. ***
*** Bug 143215 has been marked as a duplicate of this bug. ***
*** Bug 145230 has been marked as a duplicate of this bug. ***
*** Bug 145451 has been marked as a duplicate of this bug. ***
*** Bug 145678 has been marked as a duplicate of this bug. ***
*** Bug 146919 has been marked as a duplicate of this bug. ***
*** Bug 148800 has been marked as a duplicate of this bug. ***
*** Bug 149430 has been marked as a duplicate of this bug. ***
*** Bug 150765 has been marked as a duplicate of this bug. ***
*** Bug 151110 has been marked as a duplicate of this bug. ***
I tracked the source of the error and I have noticed that the bug actually reproduced each time dev-libs/expat is changed (upgraded/downgraded). It gives : # perl -e 'use XML::Parser' Can't load '/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/XML/Parser/Expat/Expat.so' for module XML::Parser::Expat: libexpat.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.8/i686-linux/DynaLoader.pm line 230. at /usr/lib/perl5/vendor_perl/5.8.8/i686-linux/XML/Parser.pm line 14 Compilation failed in require at /usr/lib/perl5/vendor_perl/5.8.8/i686-linux/XML/Parser.pm line 14. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.8.8/i686-linux/XML/Parser.pm line 18. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. or something along this line. The fix I have is to re-emerge dev-perl/XML-Parser after each and every time dev-libs/expat is changed (upgraded/downgraded) : # emerge XML-Parser fixes it. I believe there should be something put in the dev-libs/expat e-build to do this. Kind feedback welcome.
*** Bug 153408 has been marked as a duplicate of this bug. ***
(In addition to comment #157) This bug is today the second most duplicated, as shown on - either http://bugs.gentoo.org/duplicates.cgi - or https://bugs.gentoo.org/duplicates.cgi Could someone add "XML-Parser expat" to the summary of this bug so that the relevant developers get to know about it ?
*** Bug 156091 has been marked as a duplicate of this bug. ***
(In reply to comment #159) > (In addition to comment #157) > > This bug is today the second most duplicated, as shown on > - either http://bugs.gentoo.org/duplicates.cgi > - or https://bugs.gentoo.org/duplicates.cgi > > Could someone add "XML-Parser expat" to the summary of this bug so that the > relevant developers get to know about it ? Funny thing is that you only need to add XML-Parser as dependancy and it will SOLVE every new instance. Again waiting almost two years... and it hit me again today.
*** Bug 158642 has been marked as a duplicate of this bug. ***
*** Bug 162692 has been marked as a duplicate of this bug. ***
*** Bug 168199 has been marked as a duplicate of this bug. ***
gnome-base/libgtop should depend on dev-perl/XML-Parser, otherwise gnome-base/libgtop fails with an error message
*** Bug 172507 has been marked as a duplicate of this bug. ***
*** Bug 172924 has been marked as a duplicate of this bug. ***
Yay, just hit this again on a fresh install. What part about 'indirect dependencies are a Bad Thing' do you guys not get?
Come on people. If you consider how much time you are costing yourselves as well as others, the price of fixing the solution is much smaller than the problem itself. It's things like this that give groups bad reps and make people not want to use an OS / infrastructure. Either that or are you hanging on to a glimmer of hope that maybe everything bad will go away in perl6? Good luck.. perl's a good language but I doubt the capability of its maintainers for coming out with a good product after the 5.x interpreter series. Over 2 years, the least you can do is resolve this.
Come on people. If you consider how much time you are costing yourselves as well as others, the price of fixing the solution is much smaller than the problem itself. It's things like this that give groups bad reps and make people not want to use an OS / infrastructure. Either that or are you hanging on to a glimmer of hope that maybe everything bad will go away in perl6? Good luck.. perl's a good language but I doubt the capability of its maintainers for coming out with a good product after the 5.x interpreter series. Over 3 years, the least you can do is resolve this.
*** Bug 173287 has been marked as a duplicate of this bug. ***
*** Bug 180331 has been marked as a duplicate of this bug. ***
*** Bug 180978 has been marked as a duplicate of this bug. ***
*** Bug 182384 has been marked as a duplicate of this bug. ***
*** Bug 183262 has been marked as a duplicate of this bug. ***
*** Bug 183533 has been marked as a duplicate of this bug. ***
Is perl a required dependency of the install CD? Does gentoo 2006 install an old version of perl? If not, then to blame the user for fscking up a perl install is probably unfair in the extreme. the following sequence of events will probably cause this error to occur... Install gentoo emerge xorg emerge kde-base emerge mozilla-firefox (note that, at the time ie just before 2007 came out, I was installing the latest (afaik) available gentoo). imho it's pretty crap for a gentoo newbie (like me) to be left wondering what the hell is going on, over what should be something nice and simple
*** Bug 185589 has been marked as a duplicate of this bug. ***
*** Bug 186388 has been marked as a duplicate of this bug. ***
*** Bug 187063 has been marked as a duplicate of this bug. ***
*** Bug 187870 has been marked as a duplicate of this bug. ***
*** Bug 188359 has been marked as a duplicate of this bug. ***
For all the people getting here via dupes on gnome 2.18 upgrades: This is because of the expat upgrade. You need to run: revdep-rebuild -X which is in the gentoolkit package.
*** Bug 188372 has been marked as a duplicate of this bug. ***
*** Bug 188392 has been marked as a duplicate of this bug. ***
*** Bug 188396 has been marked as a duplicate of this bug. ***
*** Bug 188419 has been marked as a duplicate of this bug. ***
*** Bug 188427 has been marked as a duplicate of this bug. ***
I just run into this with gnome-base/gnome-vfs-2.18.1 during regular emerge -avuDN world ... and nearly filed duplicate, because this did not show when searching for "gnome-vfs" bugs how can this be marked RESOLVED-INVALID when people keep running into this again and again? if system is b0rken on regular update (or even on install? - comment #177) then it is a bug!
*** Bug 188495 has been marked as a duplicate of this bug. ***
*** Bug 188525 has been marked as a duplicate of this bug. ***
*** Bug 188540 has been marked as a duplicate of this bug. ***
*** Bug 188565 has been marked as a duplicate of this bug. ***
*** Bug 188575 has been marked as a duplicate of this bug. ***
*** Bug 188593 has been marked as a duplicate of this bug. ***
(In reply to comment #189) > how can this be marked RESOLVED-INVALID when people keep running into this > again and again? if system is b0rken on regular update (or even on install? - > comment #177) then it is a bug! Because you didn't read the instructions provided by expat ebuild on upgrade, as already noted in Comment #183. That's not a bug but a user failure. Anyway, we are forcing people to recompile this now because of the horrible flood of duplicate bugs. 17:07:13 <+CIA-15> drac * gentoo-x86/dev-perl/XML-Parser/ (3 files in 2 dirs): 17:07:13 <+CIA-15> Revision bump XML-Parser to avoid problems with expat upgrade. No changes made to ebuild itself. So, even if you have already recompiled this, you'll be forced to do it again on next emerge --sync, because people simply don't read whatever messages that are provided, and don't search for duplicate bugs before filing one. Sorry.
I did emerge --system and couldn't notice the message.. Shouldn't these critical messages be appended to the end of the emerge output via functions in ebuilds like einfo(), ewarn() and eerror()??
(In reply to comment #197) > I did emerge --system and couldn't notice the message.. > Shouldn't these critical messages be appended to the end of the emerge output > via functions in ebuilds like einfo(), ewarn() and eerror()?? emerge --system --> emerge --update system
*** Bug 188609 has been marked as a duplicate of this bug. ***
(In reply to comment #197) Maybe you should read /etc/make.conf.example and use the ELOG features that have been available for just over 1 1/2 year now.
Yeah, thanks, I already use it. Apparently it doesn't do its job all that well. Anyway, this is getting rather off topic. I've filed a feature request. Jakub, feel free to reply at bug #188623
(In reply to comment #201) > Yeah, thanks, I already use it. Apparently it doesn't do its job all that well. Yeah, fails to read the messages for you, you have to do it yourself. If you can't be bothered to do even that, then kindly stop blaming portage for this.
*** Bug 188629 has been marked as a duplicate of this bug. ***
*** Bug 188635 has been marked as a duplicate of this bug. ***
*** Bug 188639 has been marked as a duplicate of this bug. ***
*** Bug 188640 has been marked as a duplicate of this bug. ***
*** Bug 188643 has been marked as a duplicate of this bug. ***
*** Bug 188657 has been marked as a duplicate of this bug. ***
*** Bug 188660 has been marked as a duplicate of this bug. ***
Jakub, why do you keep on removing people from the CC list?
*** Bug 188681 has been marked as a duplicate of this bug. ***
(In reply to comment #210) > why do you keep on removing people from the CC list? So that we wouldn't generate 200 bugspams everytime someone fails to search for duplicates.
*** Bug 188701 has been marked as a duplicate of this bug. ***
*** Bug 188702 has been marked as a duplicate of this bug. ***
Hi Jakub, I notice you and others have repeatedly stressed that people should read the output of emerge, so that they would notice that they have to run perl-cleaner in order to prevent these problems. However, as is posted by Anthony Youngman (#177) and some others, the error can occur during one emerge run. If both perl and a package depending on XML::Parser get updated during one "emerge -uDN world" command, then emerge would fail on this bug, without it being "the users' fault". I do understand that this is not a simple issue to solve, and I don't have a simple suggestion for the solution. But I do feel the current perl-cleaner workaround is not a sufficient solution, so I do think this issue deserves some more thought. I don't know if this bug (currently having status CLOSED INVALID) is the right place for it, but I would like to humbly request that this ticket is taken into account for a new feature in Portage, so that this can be solved in a decent manner. Kind regards, Erik Logtenberg.
*** Bug 188705 has been marked as a duplicate of this bug. ***
*** Bug 188712 has been marked as a duplicate of this bug. ***
*** Bug 188789 has been marked as a duplicate of this bug. ***
*** Bug 188773 has been marked as a duplicate of this bug. ***
*** Bug 188775 has been marked as a duplicate of this bug. ***
*** Bug 188805 has been marked as a duplicate of this bug. ***
*** Bug 188815 has been marked as a duplicate of this bug. ***
*** Bug 188813 has been marked as a duplicate of this bug. ***
*** Bug 188864 has been marked as a duplicate of this bug. ***
*** Bug 188893 has been marked as a duplicate of this bug. ***
Oh please. don't blame the user to use ELOG if it is not enabled per default. Those messages SHOULD be summerized at the end of the emerge process... i just ran into this problem. Startet perl-cleaner, didn't do the job. Ops... XML-Parser isn't even installed! Merged XML-Parser manually, but got another error. At the moment i'm trying to run "revdep-rebuild -X".
well if you're not a fan of watching compilation lines all the day, you should really know about this feature. About summary at the end of the merge, next stable portage release will have it (I've been told it's in ~arch but I somehow can't see it's effect), I don't know if it'll solve the breaks in the middle of an update though.
*** Bug 188964 has been marked as a duplicate of this bug. ***
(In reply to comment #196) > (In reply to comment #189) > Because you didn't read the instructions provided by expat ebuild on upgrade, > as already noted in Comment #183. That's not a bug but a user failure. ok, so you say that Gentoo does not allow non-interactive upgrades? - quite a new for me ... until today I thought that user attention should be needed when changing profile (which may upgrade gcc etc) but not on regular emerge -u something ... btw, on _default config_ without redirecting stdout there is no way how to read it (any other than to sit in front of monitor and really quickly read the messages printed on screen) - but I see (bug 188623 comments) that it changes, so you are aware of the problem ... how can you blame user if you know that this really _is_ a problem?
I think the number of duplicates and interest in this bug speaks for itself. When this many people are affected by the same thing it's not right to blame the user. I think this bug needs to be reopened, and a better solution (even that writing all the warnings at the end, because an emerge shouldn't ever fail if everything is working properly, and it will in certain cases before the user has a chance to run revdep-rebuild -X if certain combinations of packages are pulled in at once) What is it about Perl that makes it special anyway? As oppose to Python or Java?
I'm yet another victim of this bug on a big update world. I don't understand which of these command I must launch : "revdep-rebuild -X" or the perl cleaner script ? both ?
*** Bug 189453 has been marked as a duplicate of this bug. ***
*** Bug 189491 has been marked as a duplicate of this bug. ***
(In reply to comment #231) > I'm yet another victim of this bug on a big update world. > I don't understand which of these command I must launch : "revdep-rebuild -X" > or the perl cleaner script ? both ? I guess you would not do anything bad running both; from my understanding, you need to run the perl-cleaner only on certain setup, while you need to run revdep-rebuild to repair all the packages broken by the removal of the old version of libexpat (it is a good idea to run revdep-rebuild ocassionaly anyway). Btw, there may be some chain dependencies, e.g. what happended in my case - I've rebuilt subversion but the svn command was still missing libexpat ... I wondered what the hell is that, how it can be built depending on the library which was not in the system while building, then it turned out that the problem is with apr which is used by svn ...
*** Bug 189851 has been marked as a duplicate of this bug. ***
*** Bug 190286 has been marked as a duplicate of this bug. ***
*** Bug 190648 has been marked as a duplicate of this bug. ***
*** Bug 190935 has been marked as a duplicate of this bug. ***
*** Bug 191242 has been marked as a duplicate of this bug. ***
*** Bug 192236 has been marked as a duplicate of this bug. ***
*** Bug 192709 has been marked as a duplicate of this bug. ***
*** Bug 193673 has been marked as a duplicate of this bug. ***
*** Bug 197619 has been marked as a duplicate of this bug. ***
*** Bug 198082 has been marked as a duplicate of this bug. ***
*** Bug 198619 has been marked as a duplicate of this bug. ***
Same problem here, but "revdep-rebuild" or "perl-cleaner" don't help. "emerge XML_parser" give the solution.
Well, I just installed Gentoo from liveCD 2007.7 (networkless, as other methods failed), then set USE flags, run emerge --sync emerge -DubN world and the emerge failed. I know, that Perl is root of (nearly) all evil, but isn't here some way to manage the beast from destroing emerges for inoncent users?
(In reply to comment #247) No, there's no way at all unless Bug 192319 is implemented. This bug is closed, dead and nothing will happen here.
*** Bug 206277 has been marked as a duplicate of this bug. ***
*** Bug 208458 has been marked as a duplicate of this bug. ***
*** Bug 209492 has been marked as a duplicate of this bug. ***
*** Bug 210108 has been marked as a duplicate of this bug. ***
*** Bug 210847 has been marked as a duplicate of this bug. ***
*** Bug 212848 has been marked as a duplicate of this bug. ***
*** Bug 213447 has been marked as a duplicate of this bug. ***
*** Bug 213498 has been marked as a duplicate of this bug. ***
*** Bug 215727 has been marked as a duplicate of this bug. ***
*** Bug 222259 has been marked as a duplicate of this bug. ***
*** Bug 225571 has been marked as a duplicate of this bug. ***
*** Bug 228869 has been marked as a duplicate of this bug. ***
*** Bug 230858 has been marked as a duplicate of this bug. ***
*** Bug 246415 has been marked as a duplicate of this bug. ***
*** Bug 284281 has been marked as a duplicate of this bug. ***
*** Bug 305009 has been marked as a duplicate of this bug. ***
*** Bug 305199 has been marked as a duplicate of this bug. ***
*** Bug 305233 has been marked as a duplicate of this bug. ***
*** Bug 305225 has been marked as a duplicate of this bug. ***
*** Bug 305291 has been marked as a duplicate of this bug. ***
*** Bug 305485 has been marked as a duplicate of this bug. ***
*** Bug 309413 has been marked as a duplicate of this bug. ***
*** Bug 311125 has been marked as a duplicate of this bug. ***
*** Bug 314683 has been marked as a duplicate of this bug. ***
*** Bug 323989 has been marked as a duplicate of this bug. ***
*** Bug 324853 has been marked as a duplicate of this bug. ***
I am hitting this issue via x11-libs/vte-0.24.3 and net-libs/gtk-vnc-0.4.1. Please reopen!
(In reply to comment #275) > I am hitting this issue via x11-libs/vte-0.24.3 and net-libs/gtk-vnc-0.4.1. > Please reopen! As well as gnome-base/gnome-vfs-2.24.3-r1
(In reply to comment #276) > (In reply to comment #275) > > I am hitting this issue via x11-libs/vte-0.24.3 and net-libs/gtk-vnc-0.4.1. > > Please reopen! > As well as gnome-base/gnome-vfs-2.24.3-r1 And net-print/libgnomecups-0.2.3
(In reply to comment #277) > (In reply to comment #276) > > (In reply to comment #275) > > > I am hitting this issue via x11-libs/vte-0.24.3 and net-libs/gtk-vnc-0.4.1. > > > Please reopen! > > As well as gnome-base/gnome-vfs-2.24.3-r1 > And net-print/libgnomecups-0.2.3 Dear lord... And gnome-base/libgnomeprint-2.18.7
(In reply to comment #278) > (In reply to comment #277) > > (In reply to comment #276) > > > (In reply to comment #275) > > > > I am hitting this issue via x11-libs/vte-0.24.3 and net-libs/gtk-vnc-0.4.1. > > > > Please reopen! > > > As well as gnome-base/gnome-vfs-2.24.3-r1 > > And net-print/libgnomecups-0.2.3 > Dear lord... And gnome-base/libgnomeprint-2.18.7 > Did you run perl-cleaner --all when you updated perl?
Yes, to fix this issue, running the following command is required: perl-cleaner --all This took a while, together with the @preserved-rebuild afterwards, hence the delay in my answer.
Could not portage die if perl is updated and requires the modules rebuild or is this specific to gnome? It breaks imagemagick too at the least iirc and the failure at a later point just leaves users searching until they find the fix. (elogv is a nice app people) Dying after the perl update and requiring the fix before proceeding would seem preferable.
*** Bug 330495 has been marked as a duplicate of this bug. ***
*** Bug 334871 has been marked as a duplicate of this bug. ***
*** Bug 337968 has been marked as a duplicate of this bug. ***
*** Bug 342339 has been marked as a duplicate of this bug. ***
*** Bug 342809 has been marked as a duplicate of this bug. ***
*** Bug 342921 has been marked as a duplicate of this bug. ***
*** Bug 343647 has been marked as a duplicate of this bug. ***
*** Bug 343687 has been marked as a duplicate of this bug. ***
*** Bug 343787 has been marked as a duplicate of this bug. ***
*** Bug 344237 has been marked as a duplicate of this bug. ***
*** Bug 344927 has been marked as a duplicate of this bug. ***
*** Bug 344931 has been marked as a duplicate of this bug. ***
*** Bug 346507 has been marked as a duplicate of this bug. ***
Erm, why were CCs removed? Reopening because this isn't a GNOME bug.
*** Bug 391779 has been marked as a duplicate of this bug. ***
*** Bug 391959 has been marked as a duplicate of this bug. ***
*bump* I'm resolved this bug. Need run perl-cleaner all. 1. perl-cleaner all ----------------------------- i'm run emerge gnome-vfs: no bugs i'm run emerge app-arch/file-roller: no bugs resolved bug: Bug 391959 and Bug 391779
also my system x86 stable. ok.
*** Bug 421331 has been marked as a duplicate of this bug. ***
*** Bug 421339 has been marked as a duplicate of this bug. ***
*** Bug 422179 has been marked as a duplicate of this bug. ***
*** Bug 425064 has been marked as a duplicate of this bug. ***
*** Bug 436090 has been marked as a duplicate of this bug. ***
*** Bug 483782 has been marked as a duplicate of this bug. ***
*** Bug 483990 has been marked as a duplicate of this bug. ***
*** Bug 463898 has been marked as a duplicate of this bug. ***
*** Bug 454130 has been marked as a duplicate of this bug. ***
*** Bug 421567 has been marked as a duplicate of this bug. ***
*** Bug 421041 has been marked as a duplicate of this bug. ***
*** Bug 484004 has been marked as a duplicate of this bug. ***
*** Bug 484136 has been marked as a duplicate of this bug. ***
*** Bug 484272 has been marked as a duplicate of this bug. ***
*** Bug 484382 has been marked as a duplicate of this bug. ***
*** Bug 484612 has been marked as a duplicate of this bug. ***
*** Bug 486266 has been marked as a duplicate of this bug. ***
*** Bug 486780 has been marked as a duplicate of this bug. ***
*** Bug 486976 has been marked as a duplicate of this bug. ***
Really perl-cleaner on a FRESH install?...... from a stage3?
I request that perl cleaner is run on the stage3 kit that is available for download then..
how is this bug invalid? I had this problem just now trying to build systemd, had to emerge the perl xml parser module manually before it would pass configure. Seems like if it were necessary for configure it would need to be listed as a build dependency or something.
*** Bug 490026 has been marked as a duplicate of this bug. ***
*** Bug 490674 has been marked as a duplicate of this bug. ***
*** Bug 491710 has been marked as a duplicate of this bug. ***
*** Bug 493928 has been marked as a duplicate of this bug. ***
*** Bug 494354 has been marked as a duplicate of this bug. ***
*** Bug 494378 has been marked as a duplicate of this bug. ***
*** Bug 494386 has been marked as a duplicate of this bug. ***
*** Bug 494432 has been marked as a duplicate of this bug. ***
*** Bug 494516 has been marked as a duplicate of this bug. ***
*** Bug 494504 has been marked as a duplicate of this bug. ***
*** Bug 494588 has been marked as a duplicate of this bug. ***
*** Bug 494746 has been marked as a duplicate of this bug. ***
*** Bug 219955 has been marked as a duplicate of this bug. ***
*** Bug 305801 has been marked as a duplicate of this bug. ***
*** Bug 305099 has been marked as a duplicate of this bug. ***
*** Bug 281676 has been marked as a duplicate of this bug. ***
*** Bug 127591 has been marked as a duplicate of this bug. ***
*** Bug 481686 has been marked as a duplicate of this bug. ***
*** Bug 369277 has been marked as a duplicate of this bug. ***
*** Bug 361835 has been marked as a duplicate of this bug. ***
*** Bug 336483 has been marked as a duplicate of this bug. ***
*** Bug 321373 has been marked as a duplicate of this bug. ***
*** Bug 310133 has been marked as a duplicate of this bug. ***
*** Bug 351154 has been marked as a duplicate of this bug. ***
*** Bug 307805 has been marked as a duplicate of this bug. ***
*** Bug 303857 has been marked as a duplicate of this bug. ***
*** Bug 247110 has been marked as a duplicate of this bug. ***
For whatever reason the gentoo-dev groupthink seems to be that the clueless luzers need to run perl-cleaner before and after every emerge action. Whereas, when a package explicitly checks for Perl::Package in its configure stage and the ebuild thereof does not list Perl::Package as a dependency, there is a clear problem. I can only assume hubris would keep it this way so long. There is no other logical rationale.
(In reply to Justin Findlay from comment #349) > For whatever reason the gentoo-dev groupthink seems to be that the clueless > luzers need to run perl-cleaner before and after every emerge action. A logical reason stated multiple times here and on the gentoo-dev ML; it has to be run only after a Perl upgrade, as instructed by its post install message. > Whereas, when a package explicitly checks for Perl::Package in its configure > stage Even with the dependency listed, a Perl upgrade will cause the symptom again. > and the ebuild thereof does not list Perl::Package as a dependency, If the packages do list them as direct dependencies instead of indirect dependencies, that could lead to a lot of Perl ebuilds listing a lot of unnecessary direct Perl packages as dependencies; that in itself is a clear problem. Now, even if we would list these dependencies; they don't fix the symptom, because it needs to be rebuild as Perl upgrades. A random Perl library depending on a random Perl library is unaffected by that; and thus, the dependency would not fix this symptom. > there is a clear problem. I can only assume hubris would keep it this way so long. There is no other logical rationale. The post installation message on the Perl upgrade covers this clear problem. TL;DR: Emerging dev-perl/XML-Parser or similar is only a temporary fix for that Perl upgrade, but as the next Perl upgrade comes you get this symptom again regardless of the listed dependencies. `perl-cleaner` covers that; just like you have `python-updater`, `emerge @module-rebuild`, `emerge @x11-module-rebuild`, `emerge @preserved-rebuild` (former `revdep-rebuild`) and so on... Note: Can you please discuss this on the gentoo-dev ML if you have a working and tested solution? A lot of users get mailed on this bug; and thus, we avoid discussion on tracker bugs like these to avoid unnecessary mass mails.
*** Bug 495054 has been marked as a duplicate of this bug. ***
*** Bug 495980 has been marked as a duplicate of this bug. ***
*** Bug 496004 has been marked as a duplicate of this bug. ***
*** Bug 496052 has been marked as a duplicate of this bug. ***
*** Bug 496156 has been marked as a duplicate of this bug. ***
*** Bug 496234 has been marked as a duplicate of this bug. ***
*** Bug 496450 has been marked as a duplicate of this bug. ***
*** Bug 496700 has been marked as a duplicate of this bug. ***
*** Bug 496756 has been marked as a duplicate of this bug. ***
*** Bug 497506 has been marked as a duplicate of this bug. ***
*** Bug 497568 has been marked as a duplicate of this bug. ***
*** Bug 497828 has been marked as a duplicate of this bug. ***
*** Bug 498568 has been marked as a duplicate of this bug. ***
*** Bug 498700 has been marked as a duplicate of this bug. ***
*** Bug 499582 has been marked as a duplicate of this bug. ***
*** Bug 499696 has been marked as a duplicate of this bug. ***
*** Bug 499564 has been marked as a duplicate of this bug. ***
*** Bug 501242 has been marked as a duplicate of this bug. ***
*** Bug 501368 has been marked as a duplicate of this bug. ***
*** Bug 502438 has been marked as a duplicate of this bug. ***
*** Bug 503292 has been marked as a duplicate of this bug. ***
*** Bug 505342 has been marked as a duplicate of this bug. ***
*** Bug 505288 has been marked as a duplicate of this bug. ***
*** Bug 505390 has been marked as a duplicate of this bug. ***
*** Bug 506492 has been marked as a duplicate of this bug. ***
*** Bug 506812 has been marked as a duplicate of this bug. ***
*** Bug 506752 has been marked as a duplicate of this bug. ***
*** Bug 507018 has been marked as a duplicate of this bug. ***
*** Bug 71897 has been marked as a duplicate of this bug. ***
*** Bug 507198 has been marked as a duplicate of this bug. ***
*** Bug 63035 has been marked as a duplicate of this bug. ***
*** Bug 78148 has been marked as a duplicate of this bug. ***
*** Bug 55772 has been marked as a duplicate of this bug. ***
*** Bug 375483 has been marked as a duplicate of this bug. ***
*** Bug 266966 has been marked as a duplicate of this bug. ***
*** Bug 513532 has been marked as a duplicate of this bug. ***
*** Bug 518450 has been marked as a duplicate of this bug. ***
*** Bug 518520 has been marked as a duplicate of this bug. ***
*** Bug 518548 has been marked as a duplicate of this bug. ***
*** Bug 519086 has been marked as a duplicate of this bug. ***
*** Bug 519510 has been marked as a duplicate of this bug. ***
*** Bug 519672 has been marked as a duplicate of this bug. ***
*** Bug 519896 has been marked as a duplicate of this bug. ***
*** Bug 520698 has been marked as a duplicate of this bug. ***
*** Bug 522058 has been marked as a duplicate of this bug. ***
*** Bug 522378 has been marked as a duplicate of this bug. ***
*** Bug 522806 has been marked as a duplicate of this bug. ***
*** Bug 523606 has been marked as a duplicate of this bug. ***
Hi, A lot of tickets are being marked as a dupe of this ticket, which has been closed invalid way back when, but it's still causing problems. Do we have no other option other than manually remerging dev-perl/XML-Parser? In some cases in order to update perl to some of the newer version I quite literally have to unmerge all dev-perl/* and lang-perl/* packages in order to get perl updated, and these missing dependencies then causes problems. If XML-Parser is *broken* that's one thing - but not pulling it in if the package depends on it is completely another.
*** Bug 524070 has been marked as a duplicate of this bug. ***
*** Bug 525034 has been marked as a duplicate of this bug. ***
*** Bug 525672 has been marked as a duplicate of this bug. ***
*** Bug 526170 has been marked as a duplicate of this bug. ***
*** Bug 531578 has been marked as a duplicate of this bug. ***
*** Bug 531956 has been marked as a duplicate of this bug. ***
*** Bug 533092 has been marked as a duplicate of this bug. ***
*** Bug 531712 has been marked as a duplicate of this bug. ***
*** Bug 533266 has been marked as a duplicate of this bug. ***
*** Bug 563810 has been marked as a duplicate of this bug. ***
*** Bug 563738 has been marked as a duplicate of this bug. ***
*** Bug 566770 has been marked as a duplicate of this bug. ***
*** Bug 567552 has been marked as a duplicate of this bug. ***
*** Bug 568470 has been marked as a duplicate of this bug. ***
*** Bug 570460 has been marked as a duplicate of this bug. ***
*** Bug 582046 has been marked as a duplicate of this bug. ***
*** Bug 584848 has been marked as a duplicate of this bug. ***
Please stop marking things as duplicate here. perl-cleaner *should* not be necessary for upgrades anymore, since the perl upgrade *should* force a rebuild of XML-Parser. If that doesn't work, it's a different bug.
(In reply to Andreas K. Hüttel from comment #419) > Please stop marking things as duplicate here. > > perl-cleaner *should* not be necessary for upgrades anymore, since the perl > upgrade *should* force a rebuild of XML-Parser. Even upgrading dev-lang/perl is a problem when tons of installed packages have recorded the previous SLOT. > If that doesn't work, it's a different bug. It doesn't work. What bug is that?
*** Bug 588116 has been marked as a duplicate of this bug. ***
*** Bug 593348 has been marked as a duplicate of this bug. ***
*** Bug 596640 has been marked as a duplicate of this bug. ***
(In reply to Andreas K. Hüttel from comment #419) > Please stop marking things as duplicate here. > > perl-cleaner *should* not be necessary for upgrades anymore, since the perl > upgrade *should* force a rebuild of XML-Parser. > > If that doesn't work, it's a different bug. ... > It doesn't work. What bug is that? It doesn't work, but the problem is hard to nail down a specific bug for, because the *real* problem is in Portage itself failing to resolve dependencies correctly and tracking slot rebuilds. Unfortunately *that* problem is so general, that this bug is now a *reduction* of that problem. And we could have dozens such reductions. Bug #592880 ( #Locale-gettext ) is the "Clearest" reduction that is specific enough to be understood. But there's no point in glomming all the intltool + XML-Parser problems onto that either.
New bug added, #596664 File duplicates against things that fail with XML::Parser/intltool combinations there, not here.
*** Bug 645134 has been marked as a duplicate of this bug. ***
*** Bug 646236 has been marked as a duplicate of this bug. ***
*** Bug 675328 has been marked as a duplicate of this bug. ***
*** Bug 688132 has been marked as a duplicate of this bug. ***
*** Bug 704082 has been marked as a duplicate of this bug. ***
*** Bug 785253 has been marked as a duplicate of this bug. ***
*** Bug 913216 has been marked as a duplicate of this bug. ***
*** Bug 913214 has been marked as a duplicate of this bug. ***
