The error on next piping an e-mail to razor (from mutt): Can't locate Digest/SHA1.pm in @INC (@INC contains: lib /usr/lib/perl5/5.8.0/i686-linux /usr/lib/perl5/5.8.0 /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.0/i686-linux /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at /usr/lib/perl5/site_perl/5.6.1/Razor2/String.pm line 4. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.6.1/Razor2/String.pm line 4. Compilation failed in require at (eval 5) line 3. ...propagated at /usr/lib/perl5/5.8.0/base.pm line 64. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.6.1/Razor2/Client/Core.pm line 21. Compilation failed in require at (eval 1) line 3. ...propagated at /usr/lib/perl5/5.8.0/base.pm line 64. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.6.1/Razor2/Client/Agent.pm line 17. Compilation failed in require at /usr/bin/razor-report line 21. BEGIN failed--compilation aborted at /usr/bin/razor-report line 21.
A fresh "emerge razor" also gives the error: # emerge razor Calculating dependencies ...done! >>> emerge (1 of 1) net-mail/razor-2.12 to / >>> md5 ;-) razor-agents-2.12.tar.gz >>> Unpacking source... >>> Unpacking razor-agents-2.12.tar.gz >>> Source unpacked. Checking if your kit is complete... Looks good Warning: prerequisite Digest::SHA1 0 not found. It goes on from there - but probably it shouldn't since it won't end up working without that, right?
have you re-emerged perl (any version) recently? Digest-SHA1 is a dep in razor, so you should have it already installed (or portage thinks you do). The simplest approach here would be emerge Digest-SHA1, then re-tring the razor ebuild. Alternatively, at http://cvs.gentoo.org/~mcummings/perl58.html I have a link to an EXPERIMENTAL bash script that will re-emerge all of your perl modules for you. I stress EXPERIMENTAL not because it is dangerous or really capable of doing any harm - I just want to cover my bases until I have other eyes looking at it (and its successor, already developed, to re-emerge anything compiled against libperl.so, but that's another can of worms).
The pattern was: 5.8.0 showed up as moved to stable. Emerged it, and razor stopped working. Reported bug. Then 5.8.0 moved out of stable. Emerged 5.6.1 again. Razor working normally (with no additional steps taken).
5.8 was pulled back on me until the remerging script is complete. I have a script, in beta right now, awaiting word on how to incorporate it into the ebuild itself (hopefully), that will remerge your perl modules and anything compiled against your old libperl.so. Should you decide to go back to 5.8 in the interim, at http://cvs.gentoo.org/~mcummings/perl58.html there is a link to a script that will rebuild your perl modules (not the libperl stuff though, that's up but not linked yet).
Whit, Can we close this now?
Not a problem after Perl reversion, so close pending your fix on the next bump forward ;)
If the re-emerging script is now in the Perl 5.8 ebuild (which has moved back to stable), it's not effective for razor: Can't locate Digest/SHA1.pm in @INC (@INC contains: lib /usr/lib/perl5/5.8.0/i686-linux /usr/lib/perl5/5.8.0 /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.0/i686-linux /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at /usr/lib/perl5/site_perl/5.6.1/Razor2/String.pm line 4. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.6.1/Razor2/String.pm line 4. Compilation failed in require at (eval 5) line 3. ...propagated at /usr/lib/perl5/5.8.0/base.pm line 64. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.6.1/Razor2/Client/Core.pm line 21. Compilation failed in require at (eval 1) line 3. ...propagated at /usr/lib/perl5/5.8.0/base.pm line 64. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.6.1/Razor2/Client/Agent.pm line 17. Compilation failed in require at /usr/bin/razor-report line 21. BEGIN failed--compilation aborted at /usr/bin/razor-report line 21. Press any key to continue...
The way you phrased that last post, I have to ask - did you actually run the post emerge script?? It doesn't appear so from your output. If you did not, please take a moment to read the tail of the ebuild for perl-5.8.0-r8, as it was displayed on your screen when it finished emerging. If you did run it, I will need to see why it failed to remerge a perl module, the first item on its todo list. Please post a copy of /tmp/system-update.log. Thank you, Michael
As I think is well-known at this point, post emerge scripts that are specified in the tails of ebuilds do not connect with the user in cases where, for instance, the user does an "emerge -u world" and then comes back later when the tail for the particular program is long past. I read that there's a fix for this in development. But I was assuming since the script you mentioned before was necessary to the upgrade that the upgrade would invoke it. Are there cases where someone upgrades Perl and then _wants_ stuff that depends on it to be broken? I'm not being flip; if there's no case where the user shouldn't want to run the script, shouldn't the script just be run automatically? In any case mentioning something in the tail is not presently sufficient unless you can count on the ebuild being run individually, or being the very last item if run as part of a batch. But I'll go dig the instructions for that script out. It's certainly not something that I plan to do for everything I update, though. If there's an explicit design rule that prevents automating this sort of thing, what's the process to challenge the rule?
Your points are valid and would be better suited in a bug report to the portage developers, not me. Here is the short of it: First, no, not all users installing perl 5.8 would want their system to be updated. Say, for instance, those users who are installing a fresh system with perl 5.8. That minor instance aside, it is currently not possible to run a new emerge process from within an ebuild. There is no support in portage at this moment to say "hey, I just installed this, it affects these packages, reinstall them please." That users miss the tail end of of an emerge info section during an emerge -u world (or system, as the case may be) is unfortunate and again, the subject of another bug report. The script isn't a direct part of a perl installation. It merely tries to save you the step of isolating what may have broken during a perl upgrade by re-emerging any perl modules and anything that compiled against libperl. I am actually working on an update to it as I believe I have found a flaw in its logic, namely those packages that install modules into /usr/lib/perl but that neither compiled against libperl nor are part of the general perl module tree. That is not the case with your actual bug report, however. Re-emerging Digest-SHA1 would solve your error message immediately.
Whit, Is your razor running now?
Re-emerging Digest-SHA1 does fix it. Would be nice if that didn't have to be done by hand - if somehow it was covered in the script - but in any case it's a fix.
Whit, I'm going to close this out since you report it fixed. Your comments regarding the post emerge phase are completely valid and are being worked on by the portage team, but are not yet ready for general release. I'm curious why the libperl_rebuilder didn't catch SHA1, but so long as it is working for you that is what counts most atm. Thanks, Michael
