Re: [REPOST] problem upgrading perl
On Tue, 30 Jun 2009 12:45:32 +0400 Boris Samorodov b...@ipt.ru wrote: Scott Bennett benn...@cs.niu.edu writes: The first is, which is the best tool for doing updates with a preference for using packages rather than rebuilds of ports (a la portupgrade -aP)? You may take a look at sysutils/bsdadminscripts which use pkg_upgrade to manage packages. Thank you very much! I just now installed them per your suggestion and will take a close look. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [REPOST] problem upgrading perl
Scott Bennett benn...@cs.niu.edu writes: The first is, which is the best tool for doing updates with a preference for using packages rather than rebuilds of ports (a la portupgrade -aP)? You may take a look at sysutils/bsdadminscripts which use pkg_upgrade to manage packages. WBR -- bsam ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [REPOST] problem upgrading perl
On Thu, 25 Jun 2009 10:48:45 -0700 Doug Barton do...@freebsd.org wrote: Scott Bennett wrote: On Tue, 23 Jun 2009 10:30:11 -0700 Doug Barton do...@freebsd.org wrote: There ought to be an automated way to deal with the package issue that causes the failure of the entire update run just because it wants a human to type make deinstall make reinstall. Sorry I wasn't clear, the inherent problem I described is with perl, not with the ports. Because perl stores its libraries in a file hierarchy based on version number (arguably, a feature) when you do a straight upgrade from one version of perl to another IME the only really good way to do that is to make a list of perl-related stuff you have installed, delete everything, and reinstall. For those that only have a few libraries installed using portmaster/portupgrade -r will probably work, and is certainly worth a try. Okay. Thanks for that explanation. How about a cautionary note to that effect in /usr/ports/UPDATING? Maybe a suggestion also that people not attempt the perl upgrade unless they really need the newer version? Have you tried using the -x option to exclude it? You can also use the -i option, although for a lot of ports that can get annoying. I had not, thanks to my having misread something in the portmaster man page. If you have any suggestions for improving the text I'm open to them. No, it reads just fine. I was just in too great a hurry when I looked at it the first time. However, since reading your reply, I have tried (without -R) # nice +18 portmaster -x perl-threaded-5.10.0 -rv perl-threaded-5.10.0_3 If this is a literal copy of what you did I'm surprised it worked since you've placed the -v option between the -r and its argument. which did rebuild perl Yes, I just checked the code and portmaster does not check the -x argument for the main port specified in the command line. I'll take a look at that. (along with many other already rebuilt ports, of course). At this moment, I have # nice +18 portmaster -x perl-threaded-5.10.0_3 -R -rv perl-threaded-5.10.0_3 running, and it is currently rebuilding perl yet again. So the -x option appears to be useless, at least in this context. You might want to be a little more careful with your adjectives. My feelings aren't hurt but when you're asking for help, especially for something you're not paying anything for, words like useless tend not to make you any friends. Oohh, wow. Looks like you got rather more out of my message than I put into it. No offense was intended, I assure you, but rather expression of a sense of disappointment that the FreeBSD project considers implementation of all the latest and greatest networking facilities and features, as well as new stuff in other areas, to the exclusion of fixing the fragility of the ports system for major release after major release. This is not to say anything disparaging about the implementation of all those nice features, even though I doubt that the vast majority of FreeBSD users ever use a lot of them. The ports subsystem is a major part of what makes FreeBSD an option for many people and is very heavily and widely used, so it's a shame to see its problems neglected for so long. I began using FreeBSD at 5.2.1. Along the way, my other complaints have largely been fixed, but the ports subsystem remains to this day the weakest part of all of FreeBSD. I realize that the problem of coordinating the installation and maintenance of such a widely diverse body of ports and packages is a complex one, Having spent a non-trivial amount of time in the bowels of the ports system I would argue that complex is a dramatic understatement. Ah. Then you do understand why so many of us run into so many problems in trying to use it. Anyway, there is good news to report this time regarding my trials with the perl upgrade. Sometime Thursday afternoon, I appear to have encountered the last make deinstall make reinstall case, after which the upgrade (still using portmaster) ran another five or six hours and completed normally. Many thanks to Sergey Dyatko, Doug Barton, and other respondents for helping me get this done! Now I am left with a couple of questions in dealing with future ports and packages updates. The first is, which is the best tool for doing updates with a preference for using packages rather than rebuilds of ports (a la portupgrade -aP)? The man page for portmaster doesn't seem to allow a way to use packages at all, even if they are as current as their corresponding ports. The man page for portmanager also shows no option to use packages at all. Is portupgrade the only tool that can do this? My concern is over ports that are infamously painful to rebuild (e.g., openoffice.org, math/atlas). (X.org can also be a bad batch of stuff to rebuild, mostly in terms of the time and space required to do it, but it often does need to be rebuilt in
Re: [REPOST] problem upgrading perl
Scott Bennett wrote: On Tue, 23 Jun 2009 10:30:11 -0700 Doug Barton do...@freebsd.org wrote: There ought to be an automated way to deal with the package issue that causes the failure of the entire update run just because it wants a human to type make deinstall make reinstall. Sorry I wasn't clear, the inherent problem I described is with perl, not with the ports. Because perl stores its libraries in a file hierarchy based on version number (arguably, a feature) when you do a straight upgrade from one version of perl to another IME the only really good way to do that is to make a list of perl-related stuff you have installed, delete everything, and reinstall. For those that only have a few libraries installed using portmaster/portupgrade -r will probably work, and is certainly worth a try. Have you tried using the -x option to exclude it? You can also use the -i option, although for a lot of ports that can get annoying. I had not, thanks to my having misread something in the portmaster man page. If you have any suggestions for improving the text I'm open to them. However, since reading your reply, I have tried (without -R) # nice +18 portmaster -x perl-threaded-5.10.0 -rv perl-threaded-5.10.0_3 If this is a literal copy of what you did I'm surprised it worked since you've placed the -v option between the -r and its argument. which did rebuild perl Yes, I just checked the code and portmaster does not check the -x argument for the main port specified in the command line. I'll take a look at that. (along with many other already rebuilt ports, of course). At this moment, I have # nice +18 portmaster -x perl-threaded-5.10.0_3 -R -rv perl-threaded-5.10.0_3 running, and it is currently rebuilding perl yet again. So the -x option appears to be useless, at least in this context. You might want to be a little more careful with your adjectives. My feelings aren't hurt but when you're asking for help, especially for something you're not paying anything for, words like useless tend not to make you any friends. I began using FreeBSD at 5.2.1. Along the way, my other complaints have largely been fixed, but the ports subsystem remains to this day the weakest part of all of FreeBSD. I realize that the problem of coordinating the installation and maintenance of such a widely diverse body of ports and packages is a complex one, Having spent a non-trivial amount of time in the bowels of the ports system I would argue that complex is a dramatic understatement. but the problems the current tools, dependency lists, Makefiles, etc. present to the user are often insoluble by anyone but an expert in the internal workings of each of the pieces of the subsystem. The packages subsystem is in about as bad shape, and in spite of the degree to which the two are intertwined, they really do not play nicely together. Once again, being more careful with your rhetoric would go a long way here. This is a volunteer project, and no one would argue that there is nothing left to improve. Feel free to roll up your sleeves and get to work. :) Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [REPOST] problem upgrading perl
On Tue, 23 Jun 2009 10:30:11 -0700 Doug Barton do...@freebsd.org wrote: Scott Bennett wrote: Thank you for doing that. Unfortunately, it might have been more appropriate to have simply replaced that note with another that cautions anyone attempting the perl upgrade that the upgrade has not been fully tested against all ports that may list the new perl as a build dependency. First off, I'm sorry to hear that you're having problems, particularly that you're having problems with portmaster. In regards to the upgrade process not being tested, with over 20,000 ports it's basically impossible to guarantee that something as complicated as upgrading perl will work 100% of the time for every user and every combination of perl-dependent ports. I think it's sort of a given that beware of dragons is posted over the door. It should also warn that portmaster is *NOT* a good tool to use for this upgrade, even if the note shows how to attempt it. I think it depends on your definition of good, and also how you use the tool. Since I use it every day, including for things like upgrading perl, I happen to think it's a pretty good tool, but YMMV. Using the specific port name for perl when restarting the upgrade process, I was able to resume for a short time. However, portmaster has two design problems that apply here. The first is that if portmaster encounters a port that fails to build properly, it stops cold, rather than continuing to build other ports that do build correctly, summarizing the build errors at the end. Because it's impossible for portmaster to know which are the important errors to a given user I regard this as a feature, rather than a problem. Also, errors like the ones you're experiencing _should_ be rare, so in general this feature/bug/whatever doesn't affect users all that often. There ought to be an automated way to deal with the package issue that causes the failure of the entire update run just because it wants a human to type make deinstall make reinstall. The second design problem is that the -R option, which is supposed to avoid rebuilding ports that have already been successfully rebuilt, nevertheless rebuilds the specified dependency port--in this case, perl-threaded-5.10.0_3--*every single time* without checking to see whether it was already successfully built. Have you tried using the -x option to exclude it? You can also use the -i option, although for a lot of ports that can get annoying. I had not, thanks to my having misread something in the portmaster man page. However, since reading your reply, I have tried (without -R) # nice +18 portmaster -x perl-threaded-5.10.0 -rv perl-threaded-5.10.0_3 which did rebuild perl (along with many other already rebuilt ports, of course). At this moment, I have # nice +18 portmaster -x perl-threaded-5.10.0_3 -R -rv perl-threaded-5.10.0_3 running, and it is currently rebuilding perl yet again. So the -x option appears to be useless, at least in this context. Back to the problems with the builds...a half dozen or more port rebuild failures were correctable by simply entering the failed port's directory, doing a make deinstall make reinstall, and then returning to restart (again) portmaster, which then, of course, began by rebuilding perl another time (sigh). Full testing of the perl upgrade should have made this process unnecessary, it seems to me. Perl is traditionally very twitchy about stuff like this, and the solution you used is often the only one possible. Eventually, though, I encountered a problem with a port called misc/gnome-icon-theme-2.26.0_1. (I do not use and haven't knowingly installed gnome, so I really don't know why this port was installed in the first place. pkg_info -R should give you that information. If someone can tell me how to proceed from here, I'll give it another try. However, once again the ports subsystem is testing my tolerance for frustration, so if there's no real hope of completing the entire rebuilding process for ports with build dependencies upon perl You should probably use the -i option, and only rebuild the actual p5- ports. A lot of ports have what I consider indirect dependencies on perl that make the -r option for portmaster and portupgrade do more work than it probably ought to. However that's a topic for another thread. :) I began using FreeBSD at 5.2.1. Along the way, my other complaints have largely been fixed, but the ports subsystem remains to this day the weakest part of all of FreeBSD. I realize that the problem of coordinating the installation and maintenance of such a widely diverse body of ports and packages is a complex one, but the problems the current tools, dependency lists, Makefiles, etc. present to the user are often insoluble by anyone but an expert in the internal workings of each of the pieces of the subsystem. The packages subsystem is in about as bad shape, and in spite of
Re: [REPOST] problem upgrading perl
On Tue, 23 Jun 2009 08:31:36 +0300 Sergey V. Dyatko sergey.dya...@gmail.com wrote: ÷ Mon, 22 Jun 2009 21:12:17 -0500 (CDT) Scott Bennett benn...@cs.niu.edu ÐÉÛÅÔ: SB On Thu, 18 Jun 2009 11:42:51 -0700 Doug Barton SB do...@freebsd.org wrote: SB Jim Trigg wrote: SB Actually, he was suggesting changing from perl\* to perl-\* so SB it would only match the perl port. SB SB FYI, the \* at the end is not needed, 'portmaster perl-' will work SB just fine. SB SB Unfortunately, that won't work as there is at SB least one other port that will match that -- net/p5-perl-ldap SB (portname perl-ldap). SB SB It's generally a good idea to check your facts before posting to SB the list. Since the glob code goes by the directory names SB in /var/db/pkg, and since the prefix will be there in the SB directory name, this won't be an issue. SB SB In any case, I updated the instructions for this, and the other SB portmaster examples in /usr/ports/UPDATING a couple days ago so SB hopefully no one else will stumble over this. SB SB Thank you for doing that. Unfortunately, it might have been SB more appropriate to have simply replaced that note with another SB that cautions anyone attempting the perl upgrade that the upgrade SB has not been fully tested against all ports that may list the new SB perl as a build dependency. It should also warn that portmaster is SB *NOT* a good tool to use for this upgrade, even if the note shows SB how to attempt it. Using the specific port name for perl when SB restarting the upgrade process, I was able to resume for a short SB time. However, portmaster has two design problems that apply SB here. The first is that if portmaster encounters a port that fails SB to build properly, it stops cold, rather than continuing to build SB other ports that do build correctly, summarizing the build errors SB at the end. This means that each time an error occurs, it requires SB a manual restart (after the error has been corrected) that will run SB only until the next error is encountered. The second design problem SB is that the -R option, which is supposed to avoid rebuilding ports SB that have already been successfully rebuilt, nevertheless rebuilds SB the specified dependency port--in this case, SB perl-threaded-5.10.0_3--*every single time* without checking to see SB whether it was already successfully built. This is terribly SB time-consuming and wasteful. One might argue that the command says SB to rebuild the port specified, but there really needs to be some SB way to tell it not to do so. Back to the problems with the SB builds...a half dozen or more port rebuild failures were SB correctable by simply entering the failed port's directory, doing a SB make deinstall make reinstall, and then returning to restart SB (again) portmaster, which then, of course, began by rebuilding perl SB another time (sigh). Full testing of the perl upgrade should have SB made this process unnecessary, it seems to me. Eventually, though, SB I encountered a problem with a port called SB misc/gnome-icon-theme-2.26.0_1. (I do not use and haven't SB knowingly installed gnome, so I really don't know why this port was SB installed in the first place. OTOH, I also have a strong suspicion SB that it can't simply be eliminated either.) The rebuilding of this SB port aborted thusly: SB SB === Installing for gnome-icon-theme-2.26.0_1 SB === Generating temporary packing list SB === Checking if misc/gnome-icon-theme already installed SB Making install in 8x8 SB gmake[1]: Entering directory SB `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8' SB Making install in emblems gmake[2]: Entering directory SB `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8/emblems' SB gmake[3]: Entering directory SB `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8/emblems' SB gmake[3]: Nothing to be done for `install-exec-am'. test -z SB /usr/local/share/icons/gnome/8x8/emblems || ../.././install-sh -c SB -d /usr/local/share/icons/gnome/8x8/emblems install -o root -g SB wheel -m 444 'emblem-default.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-default.png' SB install -o root -g wheel -m 444 'emblem-new.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-new.png' install SB -o root -g wheel -m 444 'emblem-readonly.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-readonly.png' SB install -o root -g wheel -m 444 'emblem-symbolic-link.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-symbolic-link.png' SB install -o root -g wheel -m 444 'emblem-unreadable.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-unreadable.png' (cd /usr/local/share/icons/gnome/8x8 SB /usr/local/libexec/icon-name-mapping -c emblems) Can't locate SB XML/Simple.pm in @INC (@INC SB contains: /usr/local/lib/perl5/5.10.0/BSDPAN /usr/local/lib/perl5/site_perl/5.10.0/mach /usr/local/lib/perl5/site_perl/5.10.0 /usr/ local/lib/perl5/5.10.0/mach
Re: [REPOST] problem upgrading perl
On Mon, 22 Jun 2009 21:12:17 -0500 (CDT) Scott Bennett benn...@cs.niu.edu wrote: If someone can tell me how to proceed from here, I'll give it another try. However, once again the ports subsystem is testing my tolerance for frustration, so if there's no real hope of completing the entire rebuilding process for ports with build dependencies upon perl, please let me know, so I can try to undo what I've done so far and return to the old perl. Thanks in advance for any help. Again, please copy me in on responses to avoid a delay of up to a day for the next list digest to reach me. Have you tried portmanager? I use irt all the time with great success. portmanager -u -l -y -p It will create a log file so you can see what transpired. I also will check all the ports to see that they are actually built with the correct dependencies, something portupgrade fails to do consistently. I have no idea about portmanster since I have not had great success with it either; abet, that was several versions ago. In any case, update your ports tree just prior to running the update process. If all else fails, you could just run: portmanager -u -f That would rebuild everything although at the expense of considerable time depending on your system. On mine, it is almost a day. -- Jerry ges...@yahoo.com The so-called lessons of history are for the most part the rationalizations of the victors. History is written by the survivors. Max Lerner ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [REPOST] problem upgrading perl
Scott Bennett wrote: Thank you for doing that. Unfortunately, it might have been more appropriate to have simply replaced that note with another that cautions anyone attempting the perl upgrade that the upgrade has not been fully tested against all ports that may list the new perl as a build dependency. First off, I'm sorry to hear that you're having problems, particularly that you're having problems with portmaster. In regards to the upgrade process not being tested, with over 20,000 ports it's basically impossible to guarantee that something as complicated as upgrading perl will work 100% of the time for every user and every combination of perl-dependent ports. I think it's sort of a given that beware of dragons is posted over the door. It should also warn that portmaster is *NOT* a good tool to use for this upgrade, even if the note shows how to attempt it. I think it depends on your definition of good, and also how you use the tool. Since I use it every day, including for things like upgrading perl, I happen to think it's a pretty good tool, but YMMV. Using the specific port name for perl when restarting the upgrade process, I was able to resume for a short time. However, portmaster has two design problems that apply here. The first is that if portmaster encounters a port that fails to build properly, it stops cold, rather than continuing to build other ports that do build correctly, summarizing the build errors at the end. Because it's impossible for portmaster to know which are the important errors to a given user I regard this as a feature, rather than a problem. Also, errors like the ones you're experiencing _should_ be rare, so in general this feature/bug/whatever doesn't affect users all that often. The second design problem is that the -R option, which is supposed to avoid rebuilding ports that have already been successfully rebuilt, nevertheless rebuilds the specified dependency port--in this case, perl-threaded-5.10.0_3--*every single time* without checking to see whether it was already successfully built. Have you tried using the -x option to exclude it? You can also use the -i option, although for a lot of ports that can get annoying. Back to the problems with the builds...a half dozen or more port rebuild failures were correctable by simply entering the failed port's directory, doing a make deinstall make reinstall, and then returning to restart (again) portmaster, which then, of course, began by rebuilding perl another time (sigh). Full testing of the perl upgrade should have made this process unnecessary, it seems to me. Perl is traditionally very twitchy about stuff like this, and the solution you used is often the only one possible. Eventually, though, I encountered a problem with a port called misc/gnome-icon-theme-2.26.0_1. (I do not use and haven't knowingly installed gnome, so I really don't know why this port was installed in the first place. pkg_info -R should give you that information. If someone can tell me how to proceed from here, I'll give it another try. However, once again the ports subsystem is testing my tolerance for frustration, so if there's no real hope of completing the entire rebuilding process for ports with build dependencies upon perl You should probably use the -i option, and only rebuild the actual p5- ports. A lot of ports have what I consider indirect dependencies on perl that make the -r option for portmaster and portupgrade do more work than it probably ought to. However that's a topic for another thread. :) Good luck, Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [REPOST] problem upgrading perl
On Thu, 18 Jun 2009 11:42:51 -0700 Doug Barton do...@freebsd.org wrote: Jim Trigg wrote: Actually, he was suggesting changing from perl\* to perl-\* so it would only match the perl port. FYI, the \* at the end is not needed, 'portmaster perl-' will work just fine. Unfortunately, that won't work as there is at least one other port that will match that -- net/p5-perl-ldap (portname perl-ldap). It's generally a good idea to check your facts before posting to the list. Since the glob code goes by the directory names in /var/db/pkg, and since the prefix will be there in the directory name, this won't be an issue. In any case, I updated the instructions for this, and the other portmaster examples in /usr/ports/UPDATING a couple days ago so hopefully no one else will stumble over this. Thank you for doing that. Unfortunately, it might have been more appropriate to have simply replaced that note with another that cautions anyone attempting the perl upgrade that the upgrade has not been fully tested against all ports that may list the new perl as a build dependency. It should also warn that portmaster is *NOT* a good tool to use for this upgrade, even if the note shows how to attempt it. Using the specific port name for perl when restarting the upgrade process, I was able to resume for a short time. However, portmaster has two design problems that apply here. The first is that if portmaster encounters a port that fails to build properly, it stops cold, rather than continuing to build other ports that do build correctly, summarizing the build errors at the end. This means that each time an error occurs, it requires a manual restart (after the error has been corrected) that will run only until the next error is encountered. The second design problem is that the -R option, which is supposed to avoid rebuilding ports that have already been successfully rebuilt, nevertheless rebuilds the specified dependency port--in this case, perl-threaded-5.10.0_3--*every single time* without checking to see whether it was already successfully built. This is terribly time-consuming and wasteful. One might argue that the command says to rebuild the port specified, but there really needs to be some way to tell it not to do so. Back to the problems with the builds...a half dozen or more port rebuild failures were correctable by simply entering the failed port's directory, doing a make deinstall make reinstall, and then returning to restart (again) portmaster, which then, of course, began by rebuilding perl another time (sigh). Full testing of the perl upgrade should have made this process unnecessary, it seems to me. Eventually, though, I encountered a problem with a port called misc/gnome-icon-theme-2.26.0_1. (I do not use and haven't knowingly installed gnome, so I really don't know why this port was installed in the first place. OTOH, I also have a strong suspicion that it can't simply be eliminated either.) The rebuilding of this port aborted thusly: === Installing for gnome-icon-theme-2.26.0_1 === Generating temporary packing list === Checking if misc/gnome-icon-theme already installed Making install in 8x8 gmake[1]: Entering directory `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8' Making install in emblems gmake[2]: Entering directory `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8/emblems' gmake[3]: Entering directory `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8/emblems' gmake[3]: Nothing to be done for `install-exec-am'. test -z /usr/local/share/icons/gnome/8x8/emblems || ../.././install-sh -c -d /usr/local/share/icons/gnome/8x8/emblems install -o root -g wheel -m 444 'emblem-default.png' '/usr/local/share/icons/gnome/8x8/emblems/emblem-default.png' install -o root -g wheel -m 444 'emblem-new.png' '/usr/local/share/icons/gnome/8x8/emblems/emblem-new.png' install -o root -g wheel -m 444 'emblem-readonly.png' '/usr/local/share/icons/gnome/8x8/emblems/emblem-readonly.png' install -o root -g wheel -m 444 'emblem-symbolic-link.png' '/usr/local/share/icons/gnome/8x8/emblems/emblem-symbolic-link.png' install -o root -g wheel -m 444 'emblem-unreadable.png' '/usr/local/share/icons/gnome/8x8/emblems/emblem-unreadable.png' (cd /usr/local/share/icons/gnome/8x8 /usr/local/libexec/icon-name-mapping -c emblems) Can't locate XML/Simple.pm in @INC (@INC contains: /usr/local/lib/perl5/5.10.0/BSDPAN /usr/local/lib/perl5/site_perl/5.10.0/mach /usr/local/lib/perl5/site_perl/5.10.0 /usr/local/lib/perl5/5.10.0/mach /usr/local/lib/perl5/5.10.0 .) at /usr/local/libexec/icon-name-mapping line 12. BEGIN failed--compilation aborted at /usr/local/libexec/icon-name-mapping line 12. gmake[3]: *** [install-data-local] Error 2 gmake[3]: Leaving directory `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8/emblems' gmake[2]: *** [install-am] Error 2 gmake[2]: Leaving directory
Re: [REPOST] problem upgrading perl
В Mon, 22 Jun 2009 21:12:17 -0500 (CDT) Scott Bennett benn...@cs.niu.edu пишет: SB On Thu, 18 Jun 2009 11:42:51 -0700 Doug Barton SB do...@freebsd.org wrote: SB Jim Trigg wrote: SB Actually, he was suggesting changing from perl\* to perl-\* so SB it would only match the perl port. SB SB FYI, the \* at the end is not needed, 'portmaster perl-' will work SB just fine. SB SB Unfortunately, that won't work as there is at SB least one other port that will match that -- net/p5-perl-ldap SB (portname perl-ldap). SB SB It's generally a good idea to check your facts before posting to SB the list. Since the glob code goes by the directory names SB in /var/db/pkg, and since the prefix will be there in the SB directory name, this won't be an issue. SB SB In any case, I updated the instructions for this, and the other SB portmaster examples in /usr/ports/UPDATING a couple days ago so SB hopefully no one else will stumble over this. SB SB Thank you for doing that. Unfortunately, it might have been SB more appropriate to have simply replaced that note with another SB that cautions anyone attempting the perl upgrade that the upgrade SB has not been fully tested against all ports that may list the new SB perl as a build dependency. It should also warn that portmaster is SB *NOT* a good tool to use for this upgrade, even if the note shows SB how to attempt it. Using the specific port name for perl when SB restarting the upgrade process, I was able to resume for a short SB time. However, portmaster has two design problems that apply SB here. The first is that if portmaster encounters a port that fails SB to build properly, it stops cold, rather than continuing to build SB other ports that do build correctly, summarizing the build errors SB at the end. This means that each time an error occurs, it requires SB a manual restart (after the error has been corrected) that will run SB only until the next error is encountered. The second design problem SB is that the -R option, which is supposed to avoid rebuilding ports SB that have already been successfully rebuilt, nevertheless rebuilds SB the specified dependency port--in this case, SB perl-threaded-5.10.0_3--*every single time* without checking to see SB whether it was already successfully built. This is terribly SB time-consuming and wasteful. One might argue that the command says SB to rebuild the port specified, but there really needs to be some SB way to tell it not to do so. Back to the problems with the SB builds...a half dozen or more port rebuild failures were SB correctable by simply entering the failed port's directory, doing a SB make deinstall make reinstall, and then returning to restart SB (again) portmaster, which then, of course, began by rebuilding perl SB another time (sigh). Full testing of the perl upgrade should have SB made this process unnecessary, it seems to me. Eventually, though, SB I encountered a problem with a port called SB misc/gnome-icon-theme-2.26.0_1. (I do not use and haven't SB knowingly installed gnome, so I really don't know why this port was SB installed in the first place. OTOH, I also have a strong suspicion SB that it can't simply be eliminated either.) The rebuilding of this SB port aborted thusly: SB SB === Installing for gnome-icon-theme-2.26.0_1 SB === Generating temporary packing list SB === Checking if misc/gnome-icon-theme already installed SB Making install in 8x8 SB gmake[1]: Entering directory SB `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8' SB Making install in emblems gmake[2]: Entering directory SB `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8/emblems' SB gmake[3]: Entering directory SB `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8/emblems' SB gmake[3]: Nothing to be done for `install-exec-am'. test -z SB /usr/local/share/icons/gnome/8x8/emblems || ../.././install-sh -c SB -d /usr/local/share/icons/gnome/8x8/emblems install -o root -g SB wheel -m 444 'emblem-default.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-default.png' SB install -o root -g wheel -m 444 'emblem-new.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-new.png' install SB -o root -g wheel -m 444 'emblem-readonly.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-readonly.png' SB install -o root -g wheel -m 444 'emblem-symbolic-link.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-symbolic-link.png' SB install -o root -g wheel -m 444 'emblem-unreadable.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-unreadable.png' (cd /usr/local/share/icons/gnome/8x8 SB /usr/local/libexec/icon-name-mapping -c emblems) Can't locate SB XML/Simple.pm in @INC (@INC SB contains: /usr/local/lib/perl5/5.10.0/BSDPAN /usr/local/lib/perl5/site_perl/5.10.0/mach /usr/local/lib/perl5/site_perl/5.10.0 /usr/ local/lib/perl5/5.10.0/mach /usr/local/lib/perl5/5.10.0 .) that's answer on you question. just reinstall p5-XML-Simple SB at
Re: [REPOST] problem upgrading perl
On Tue, Jun 16, 2009 at 11:44:54PM -0500, Scott Bennett wrote: On Tue, 16 Jun 2009 20:07:26 +0200 Alexey Shuvaev shuv...@physik.uni-wuerzburg.de wrote: Hmmm... Looking at portmaster sources I've got one idea. Can you try more precise command to upgrade everything depending on perl? nice +18 portmaster -v -r perl-threaded-5.10.0_3 The point is that perl\* wildcard gives you both perl-threaded-XXX and perltidy- which might be bad idea. Bingo!! Very nice call. It has now driven me to distraction with dialog boxes for configuration stuff for many ports/packages, and is now busily reinstalling perl intself. If this is the case I think UPDATING entry should be improved to use perl-\* wildcard. I think you meant to *not* use the wildcard, and yes, /usr/ports/UPDATING is clearly wrong in this case and should be fixed. Thanks very much for solving this. I still have to deal with some problems with options on the various packages/ports to be updated, but I can proceed for now. Actually, he was suggesting changing from perl\* to perl-\* so it would only match the perl port. Unfortunately, that won't work as there is at least one other port that will match that -- net/p5-perl-ldap (portname perl-ldap). So it should be revised to instruct users to use the exact portname in /var/db/pkg. Jim -- Jim Trigg, Lord High Everything Else O- /\ \ / ASCII RIBBON CAMPAIGN Hostmaster, Huie Kin family websiteXHELP CURE HTML MAIL Verger, All Saints Church - Sharon Chapel / \ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [REPOST] problem upgrading perl
Jim Trigg wrote: Actually, he was suggesting changing from perl\* to perl-\* so it would only match the perl port. FYI, the \* at the end is not needed, 'portmaster perl-' will work just fine. Unfortunately, that won't work as there is at least one other port that will match that -- net/p5-perl-ldap (portname perl-ldap). It's generally a good idea to check your facts before posting to the list. Since the glob code goes by the directory names in /var/db/pkg, and since the prefix will be there in the directory name, this won't be an issue. In any case, I updated the instructions for this, and the other portmaster examples in /usr/ports/UPDATING a couple days ago so hopefully no one else will stumble over this. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [REPOST] problem upgrading perl
Thanks for sending me your response directly. The digest including your response has yet to appear. On Tue, 16 Jun 2009 04:41:49 -0700 Kent Stewart kstew...@owt.com wrote: On Monday 15 June 2009 08:25:59 pm you wrote: I got no responses when I posted this a few days ago, so I'm reposting it now. I'd really like to finish the perl upgrade process, so I could move on to installing/updating other ports safely, but could use some advice. You ask below what part of upgrading perl with portupgrade I didn't understand in the note in /usr/ports/UPGRADING. Given that I had written-- and you quoted-- Following the instructions in /usr/ports/UPDATING for upgrading from ^ lang/perl5.8 to lang/perl5.10 using portmaster, the first part seems to go I'm not sure I see your point. well. The last line of that process is where the excerpt below begins. The second step, as you will see, fails with the error message shown. /usr/ports/UPDATING neglects to mention what to do next, and the process looks incomplete at this point. If someone could offer instructions for completing the process, I would be grateful. === Upgrade of perl-5.8.9_2 to perl-threaded-5.10.0_3 complete hellas# nice +18 portmaster -v -r perl\* What part of 2) Reinstall everything that depends on Perl: portupgrade -fr perl in /usr/ports/UPDATING didn't you understand :). See above. Having begun the process with portmaster, it seemed wise to finish it with portmaster. The note in /usr/ports/UPDATING says, 20090328: AFFECTS: users of lang/perl* AUTHOR: s...@freebsd.org lang/perl5.10 is out. If you want to switch to it from, for example lang/perl5.8, that is: Portupgrade users: 0) Fix pkgdb.db (for safety): pkgdb -Ff 1) Reinstall perl with new 5.10: portupgrade -o lang/perl5.10 -f perl-5.8.\* 2) Reinstall everything that depends on Perl: portupgrade -fr perl Portmaster users: portmaster -o lang/perl5.10 lang/perl5.8 portmaster -r perl\* So there are only two commands in the process, which seem pretty straightforward to understand, but perhaps I've missed something, in which case I'd appreciate someone pointing it out to me. There may be a couple of things causing problems but -v wouldn't force the I generally use -v because I prefer the extra information in the output. upgrade, which is needed. There is a half page set of instructions in UPDATING that tell you what to do with updating perl to version 5.10. I've included the instructions above. In my original posting, I wrote--and you quoted it, as you can see above--that I was following those instructions w.r.t. upgrading perl with portmaster. Go back and search for 20090328. It has the complete sequence of instructions for both portmaster and portupgrade. There are a lot of people that want to do the updates in a more historical manner but this perl update is a really good example of why the new ways are so much better. Which new ways are you referring to? If they are so much better, then why are they not mentioned in the note in /usr/ports/UPDATING? BTW, I also need to do it but there are a lot of ports that depend on perl and they will all be rebuilt. Exactly. If you (or anyone else) can suggest how to proceed from this point in dealing with the process's complaint about a missing ORIGIN, which you omitted, I would appreciate it. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [REPOST] problem upgrading perl
On Mon, Jun 15, 2009 at 10:25:59PM -0500, Scott Bennett wrote: I got no responses when I posted this a few days ago, so I'm reposting it now. I'd really like to finish the perl upgrade process, so I could move on to installing/updating other ports safely, but could use some advice. Following the instructions in /usr/ports/UPDATING for upgrading from lang/perl5.8 to lang/perl5.10 using portmaster, the first part seems to go well. The last line of that process is where the excerpt below begins. The second step, as you will see, fails with the error message shown. /usr/ports/UPDATING neglects to mention what to do next, and the process looks incomplete at this point. If someone could offer instructions for completing the process, I would be grateful. === Upgrade of perl-5.8.9_2 to perl-threaded-5.10.0_3 complete hellas# nice +18 portmaster -v -r perl\* === No ORIGIN in /var/db/pkg/perl-threaded-5.10.0_3/+CONTENTS:@comment ORIGIN:lang/perl5.10 /var/db/pkg/perltidy-20071205/+CONTENTS:@comment ORIGIN:devel/perltidy/+CONTENTS === Aborting update The something is wrong with packages database in /var/db/pkg or portmaster doesn't like it. Please, show the output from the following commands to start: head /var/db/pkg/perl-threaded-5.10.0_3/+CONTENTS head /var/db/pkg/perltidy-20071205/+CONTENTS Mine is (no perltidy though): ~ head /var/db/pkg/perl-5.10.0_3/+CONTENTS @comment PKG_FORMAT_REVISION:1.1 @name perl-5.10.0_3 @comment ORIGIN:lang/perl5.10 @cwd /usr/local @conflicts perl-5.6.* @conflicts perl-5.8.* @conflicts perl-threaded-5.8.* man/man1/a2p.1.gz @comment MD5:41051bd143f495e113fa136ac0e9cb6f man/man1/c2ph.1.gz Hmmm... Looking at portmaster sources I've got one idea. Can you try more precise command to upgrade everything depending on perl? nice +18 portmaster -v -r perl-threaded-5.10.0_3 The point is that perl\* wildcard gives you both perl-threaded-XXX and perltidy- which might be bad idea. If this is the case I think UPDATING entry should be improved to use perl-\* wildcard. hellas# Please copy me in on any responses. I'm subscribed to the digest form of this list, so responses sent only to the list may take up to a day to be sent to me as part of the digest. Thanks in advance for any assistance in proceeding with the perl upgrade. Just 0.02$, Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [REPOST] problem upgrading perl
=== No ORIGIN in /var/db/pkg/perl-threaded-5.10.0_3/+CONTENTS:@comment ORIGIN:lang/perl5.10 /var/db/pkg/perltidy-20071205/+CONTENTS:@comment ORIGIN:devel/perltidy/+CONTENTS === Aborting update Looks something in your /var/db/pkg got corrupted. Fix it or forcibly remove perltidy and rebuild it later. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Senior Sys Admin- RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [REPOST] problem upgrading perl
Scott Bennett wrote: I got no responses when I posted this a few days ago, so I'm reposting it now. I'd really like to finish the perl upgrade process, so I could move on to installing/updating other ports safely, but could use some advice. Following the instructions in /usr/ports/UPDATING for upgrading from lang/perl5.8 to lang/perl5.10 using portmaster, the first part seems to go well. The last line of that process is where the excerpt below begins. The second step, as you will see, fails with the error message shown. /usr/ports/UPDATING neglects to mention what to do next, and the process looks incomplete at this point. If someone could offer instructions for completing the process, I would be grateful. === Upgrade of perl-5.8.9_2 to perl-threaded-5.10.0_3 complete hellas# nice +18 portmaster -v -r perl\* As someone else already pointed out, the -r option can only take one port, so if the glob matches more than one it won't work. Specifying the specific installed port from the directory in /var/db/pkg is the way to go. hope this helps, Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [REPOST] problem upgrading perl
On Tue, 16 Jun 2009 20:07:26 +0200 Alexey Shuvaev shuv...@physik.uni-wuerzburg.de wrote: On Mon, Jun 15, 2009 at 10:25:59PM -0500, Scott Bennett wrote: I got no responses when I posted this a few days ago, so I'm reposting it now. I'd really like to finish the perl upgrade process, so I could move on to installing/updating other ports safely, but could use some advice. Following the instructions in /usr/ports/UPDATING for upgrading from lang/perl5.8 to lang/perl5.10 using portmaster, the first part seems to go well. The last line of that process is where the excerpt below begins. The second step, as you will see, fails with the error message shown. /usr/ports/UPDATING neglects to mention what to do next, and the process looks incomplete at this point. If someone could offer instructions for completing the process, I would be grateful. === Upgrade of perl-5.8.9_2 to perl-threaded-5.10.0_3 complete hellas# nice +18 portmaster -v -r perl\* === No ORIGIN in /var/db/pkg/perl-threaded-5.10.0_3/+CONTENTS:@comment ORIGIN:lang/perl5.10 /var/db/pkg/perltidy-20071205/+CONTENTS:@comment ORIGIN:devel/perltidy/+CONTENTS === Aborting update The something is wrong with packages database in /var/db/pkg or portmaster doesn't like it. Please, show the output from the following commands to start: head /var/db/pkg/perl-threaded-5.10.0_3/+CONTENTS head /var/db/pkg/perltidy-20071205/+CONTENTS Script started on Tue Jun 16 22:48:33 2009 [hellas] 101 % head /var/db/pkg/perl-threaded-5.10.0_3/+CONTENTS @comment PKG_FORMAT_REVISION:1.1 @name perl-threaded-5.10.0_3 @comment ORIGIN:lang/perl5.10 @cwd /usr/local @pkgdep gdbm-1.8.3_3 @comment DEPORIGIN:databases/gdbm @conflicts perl-5.6.* @conflicts perl-5.8.* @conflicts perl-threaded-5.8.* man/man1/a2p.1.gz [hellas] 102 % head /var/db/pkg/perltidy-20071205/+CONTENTS @comment PKG_FORMAT_REVISION:1.1 @name perltidy-20071205 @comment ORIGIN:devel/perltidy @cwd /usr/local @pkgdep perl-threaded-5.10.0_3 @comment DEPORIGIN:lang/perl5.10 man/man1/perltidy.1.gz @comment MD5:5b629d5917cb885aa24509e40da51b9f lib/perl5/5.8.9/man/man3/Perl::Tidy.3.gz @comment MD5:dcedd0294434f2a88ad1caa048847ce0 [hellas] 103 % exit exit Script done on Tue Jun 16 22:49:49 2009 Mine is (no perltidy though): ~ head /var/db/pkg/perl-5.10.0_3/+CONTENTS @comment PKG_FORMAT_REVISION:1.1 @name perl-5.10.0_3 @comment ORIGIN:lang/perl5.10 @cwd /usr/local @conflicts perl-5.6.* @conflicts perl-5.8.* @conflicts perl-threaded-5.8.* man/man1/a2p.1.gz @comment MD5:41051bd143f495e113fa136ac0e9cb6f man/man1/c2ph.1.gz Hmmm... Looking at portmaster sources I've got one idea. Can you try more precise command to upgrade everything depending on perl? nice +18 portmaster -v -r perl-threaded-5.10.0_3 The point is that perl\* wildcard gives you both perl-threaded-XXX and perltidy- which might be bad idea. Bingo!! Very nice call. It has now driven me to distraction with dialog boxes for configuration stuff for many ports/packages, and is now busily reinstalling perl intself. If this is the case I think UPDATING entry should be improved to use perl-\* wildcard. I think you meant to *not* use the wildcard, and yes, /usr/ports/UPDATING is clearly wrong in this case and should be fixed. Thanks very much for solving this. I still have to deal with some problems with options on the various packages/ports to be updated, but I can proceed for now. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[REPOST] problem upgrading perl
I got no responses when I posted this a few days ago, so I'm reposting it now. I'd really like to finish the perl upgrade process, so I could move on to installing/updating other ports safely, but could use some advice. Following the instructions in /usr/ports/UPDATING for upgrading from lang/perl5.8 to lang/perl5.10 using portmaster, the first part seems to go well. The last line of that process is where the excerpt below begins. The second step, as you will see, fails with the error message shown. /usr/ports/UPDATING neglects to mention what to do next, and the process looks incomplete at this point. If someone could offer instructions for completing the process, I would be grateful. === Upgrade of perl-5.8.9_2 to perl-threaded-5.10.0_3 complete hellas# nice +18 portmaster -v -r perl\* === No ORIGIN in /var/db/pkg/perl-threaded-5.10.0_3/+CONTENTS:@comment ORIGIN:lang/perl5.10 /var/db/pkg/perltidy-20071205/+CONTENTS:@comment ORIGIN:devel/perltidy/+CONTENTS === Aborting update hellas# Please copy me in on any responses. I'm subscribed to the digest form of this list, so responses sent only to the list may take up to a day to be sent to me as part of the digest. Thanks in advance for any assistance in proceeding with the perl upgrade. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
