Re: portupdate xorg-server
On Sat, 21 Mar 2009 00:39:31 -0500 Adam Vande More amvandem...@gmail.com wrote: RW wrote: IMO this doesn't make any sense. If portupgrade is failing on a port where manual make install works, then portupgrade simply has a bug. Any port upgrading tool belongs in a port, because it's more important that it responds to changes in the ports system than changes in the base system. As to upgrading piecemeal rather than with -a, I don't see how that helps, and it may actually make things worse by not building in dependency order. ___ As to the first part of your msg, what you said doesn't make any sense to me either. Never did I claim portupgrade fails where a normal make install would succeed. I would appreciate it if you could take my example as I state it instead adding stuff to make it sound implausible. And I would appreciate it if you actually read what I posted before you accuse me of making things up. My reply wasn't to your email it was to Neil Hogan, who did say that. Also after you get some experience in ports, you'll be able to understand that you can't depend on it compiling all the time. .. Hope that clears up the confusion for you. Since you are the one that sees problems, and I find the whole thing to be generally straightforward, I don't really think you are in a position to be condescending. Many problems that are seen after a portupgrade -R will go away after after a portupgrade -a, so why waste time in debugging them. In my experience a failed portupgrade -a scarcely ever leads to runtime problems and most build problems are resolved after running csup. Personally I don't find fault-finding signifiantly harder after a portupgrade -a than after a portupgrade -R YMMV. The really important thing is to read UPDATING, but if you don't update frequently enough you can run into a state where it's difficult to conflate the entries into a single recipe. If I ever let things slide to the point where I was faced with two really complex metaport updates, I *might* be tempted to take the tree back to the point when the first update stablised and do them sequentially in that way. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: portupdate xorg-server
On Thu, Mar 19, 2009 at 4:15 PM, Frank Shute fr...@shute.org.uk wrote: On Thu, Mar 19, 2009 at 03:21:05PM -0500, Neal Hogan wrote: The last couple of days I've been running portupgrade -av and am to the point where I'd like to move onto something else, but there is one package that won't upgrade . . . xorg-server. As you can see below, it claims that there is a missing header and there are a fair amount of reported errors. I'm not the best at deciphering the stuff below. I've tried make deinstalling/reinstalling and individually portupgrading it to no avail. suggestions? glxdriswrast.c:39:39: error: GL/internal/dri_interface.h: No such file or directory $ pkg_info -W /usr/local/include/GL/internal/dri_interface.h /usr/local/include/GL/internal/dri_interface.h was installed by package xf86driproto-2.0.3 I wish to not only that Frank for his patience and subtle hand-holding, but also address the rest of the list. First, concerning the issue Mr. Shute responded to . . . I reinstalled xf86driproto, which installed the dri_interface.h, which allowed me to pkg_add xorg-server. However, it was the older version of xorg-server. So, I ran portupgrade on it and it, again, claims that there is no dri_interface.h. According to pkg_version, all xorg and xf86 ports are up-to-date, except xorg-server of which there is a newer version. That said, I was hoping that you can help me understand the portupgrade process b/c it can be a bit frustrating when it runs for a LONG time only to have upgrades fail. Please don't take my tone to be anything other than one coming from a sense of curiosity. I don't mean to suggest anything about the fBSD ports system. Perhaps my experience is the result of my own oversight. Just to be clear, here are the steps I took: 1) #portsnap fetch 2) #portsnap extract 3) #portsnap update 4) #pkgdb -u 5) #pkgdb -F 6) #portupgrade -av As I noted in another post, some ports fail to upgrade when using portupgrade -a, no matter how many times it is run. However, they (those that fail), along with their dependencies, do upgrade when portupgraded individually (or de/reinstalled). I thought the purpose of having a ports system, where you install the ports tree and use portupgrade, was to make the install/upgrade easy and rather painless, such that all ports and their dependencies are taken care of. As I write this I am running portupgrade individually, on those ports that failed to upgrade with -a option, but have (so far) succeeded in upgrading individually. I am simply looking at the output of pkg_version to find those that are not up-to-date. I could see if ports failed to upgrade or were ignored due to there being no diff between what's installed and that which is in the updated tree. Can someone shed some light on this? Thanks a lot for taking the time. -Neal HTH. snip Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html -- www.nealhogan.net www.lambdaserver.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: portupdate xorg-server
Neal Hogan wrote: On Thu, Mar 19, 2009 at 4:15 PM, Frank Shute fr...@shute.org.uk wrote: On Thu, Mar 19, 2009 at 03:21:05PM -0500, Neal Hogan wrote: The last couple of days I've been running portupgrade -av and am to the point where I'd like to move onto something else, but there is one package that won't upgrade . . . xorg-server. As you can see below, it claims that there is a missing header and there are a fair amount of reported errors. I'm not the best at deciphering the stuff below. I've tried make deinstalling/reinstalling and individually portupgrading it to no avail. suggestions? glxdriswrast.c:39:39: error: GL/internal/dri_interface.h: No such file or directory $ pkg_info -W /usr/local/include/GL/internal/dri_interface.h /usr/local/include/GL/internal/dri_interface.h was installed by package xf86driproto-2.0.3 I wish to not only that Frank for his patience and subtle hand-holding, but also address the rest of the list. First, concerning the issue Mr. Shute responded to . . . I reinstalled xf86driproto, which installed the dri_interface.h, which allowed me to pkg_add xorg-server. However, it was the older version of xorg-server. So, I ran portupgrade on it and it, again, claims that there is no dri_interface.h. According to pkg_version, all xorg and xf86 ports are up-to-date, except xorg-server of which there is a newer version. That said, I was hoping that you can help me understand the portupgrade process b/c it can be a bit frustrating when it runs for a LONG time only to have upgrades fail. Please don't take my tone to be anything other than one coming from a sense of curiosity. I don't mean to suggest anything about the fBSD ports system. Perhaps my experience is the result of my own oversight. Just to be clear, here are the steps I took: 1) #portsnap fetch 2) #portsnap extract 3) #portsnap update 4) #pkgdb -u 5) #pkgdb -F 6) #portupgrade -av As I noted in another post, some ports fail to upgrade when using portupgrade -a, no matter how many times it is run. However, they (those that fail), along with their dependencies, do upgrade when portupgraded individually (or de/reinstalled). I thought the purpose of having a ports system, where you install the ports tree and use portupgrade, was to make the install/upgrade easy and rather painless, such that all ports and their dependencies are taken care of. As I write this I am running portupgrade individually, on those ports that failed to upgrade with -a option, but have (so far) succeeded in upgrading individually. I am simply looking at the output of pkg_version to find those that are not up-to-date. I could see if ports failed to upgrade or were ignored due to there being no diff between what's installed and that which is in the updated tree. Can someone shed some light on this? Thanks a lot for taking the time. -Neal Part of the issue is that portupgrade is not a core part of the freebsd ports. It is itself a port, an addon that adds in it own set of complexities -- see it's man page. It's a wonderful utility but not perfect. When I run into issues using portupgrade, I find it easiest to fix what failed using standard port tools, not an addon, then resume the portupgrade after I fixed errors manually. Generally the process is relatively quick, but on something big like kde4 it can take quite awhile. As for specific events, you can post the errors and someone should be able help like before. Another rule of thumb I use is that I don't use portupgrade -a on system with a massive graphical enviro installedtoo many areas to fail. So in a situation like yours I might start with a portupgrade -Rf xorg-server and see how far it gets. Once completed, I'll go onto other major apps to upgrade until I get to the end. There may certainly be better ways to handle, just what I've found works best for me. 1) portsnap fetch update 2) portupgrade -Rf xorg-server Should really be all you need to do to upgrade it. portupgrade will automatically detect stale entries and do the pkgdb -u and tell you if you need to run pkgdb -F. Other options like pre-fetching, config recursive, and ignoring errors can also help save time. Used incorrectly, ignoring error can significantly increase time though. -- Adam Vandemore Systems Administrator IMED Mobility (605) 498-1610 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: portupdate xorg-server
In light of Adam's comment and thinking about the comment he's responding to, I realize that I may have been rather obnoxious. I appreciate Adam setting that aside to give me and the list some of his time. I'm rather new to fBSD (obvious) and I've got my parent's machine on it, which is hundreds of miles away and they have put in requests that led me to upgrade their system, including ports (and when X gets messed up from a remote position, it can be frustrating). So, I apologize if my comments came across in such a way that annoyed you. Not being a dev (or anywhere close), I have little room to act that way. But, I wonder what the most efficient way is to update ports. I appreciate Adam's point about the fact that portupgrade (and portmanager and portmaster) are ports themselves and are going to not be as reliable as what is in base. However, the fBSD documentation on updating ports (i.e., the handbook) only suggests the above three as ways to update ports. Is there a way to update ports from a base app? Given that a basic setup will have quite a few ports (hundreds), I was wondering if there was another way to update all (including their dependencies), rather that a one-by-one *make update* or *portupgrade*. On Fri, Mar 20, 2009 at 12:23 PM, Adam Vandemore amvandem...@gmail.comwrote: Neal Hogan wrote: On Thu, Mar 19, 2009 at 4:15 PM, Frank Shute fr...@shute.org.uk wrote: On Thu, Mar 19, 2009 at 03:21:05PM -0500, Neal Hogan wrote: The last couple of days I've been running portupgrade -av and am to the point where I'd like to move onto something else, but there is one package that won't upgrade . . . xorg-server. As you can see below, it claims that there is a missing header and there are a fair amount of reported errors. I'm not the best at deciphering the stuff below. I've tried make deinstalling/reinstalling and individually portupgrading it to no avail. suggestions? glxdriswrast.c:39:39: error: GL/internal/dri_interface.h: No such file or directory $ pkg_info -W /usr/local/include/GL/internal/dri_interface.h /usr/local/include/GL/internal/dri_interface.h was installed by package xf86driproto-2.0.3 I wish to not only that Frank for his patience and subtle hand-holding, but also address the rest of the list. First, concerning the issue Mr. Shute responded to . . . I reinstalled xf86driproto, which installed the dri_interface.h, which allowed me to pkg_add xorg-server. However, it was the older version of xorg-server. So, I ran portupgrade on it and it, again, claims that there is no dri_interface.h. According to pkg_version, all xorg and xf86 ports are up-to-date, except xorg-server of which there is a newer version. That said, I was hoping that you can help me understand the portupgrade process b/c it can be a bit frustrating when it runs for a LONG time only to have upgrades fail. Please don't take my tone to be anything other than one coming from a sense of curiosity. I don't mean to suggest anything about the fBSD ports system. Perhaps my experience is the result of my own oversight. Just to be clear, here are the steps I took: 1) #portsnap fetch 2) #portsnap extract 3) #portsnap update 4) #pkgdb -u 5) #pkgdb -F 6) #portupgrade -av As I noted in another post, some ports fail to upgrade when using portupgrade -a, no matter how many times it is run. However, they (those that fail), along with their dependencies, do upgrade when portupgraded individually (or de/reinstalled). I thought the purpose of having a ports system, where you install the ports tree and use portupgrade, was to make the install/upgrade easy and rather painless, such that all ports and their dependencies are taken care of. As I write this I am running portupgrade individually, on those ports that failed to upgrade with -a option, but have (so far) succeeded in upgrading individually. I am simply looking at the output of pkg_version to find those that are not up-to-date. I could see if ports failed to upgrade or were ignored due to there being no diff between what's installed and that which is in the updated tree. Can someone shed some light on this? Thanks a lot for taking the time. -Neal Part of the issue is that portupgrade is not a core part of the freebsd ports. It is itself a port, an addon that adds in it own set of complexities -- see it's man page. It's a wonderful utility but not perfect. When I run into issues using portupgrade, I find it easiest to fix what failed using standard port tools, not an addon, then resume the portupgrade after I fixed errors manually. Generally the process is relatively quick, but on something big like kde4 it can take quite awhile. As for specific events, you can post the errors and someone should be able help like before. Another rule of thumb I use is that I don't use portupgrade -a on system with a massive graphical enviro installedtoo many areas to fail. So in a
Re: portupdate xorg-server
On Fri, Mar 20, 2009 at 10:14:32AM -0500, Neal Hogan wrote: On Thu, Mar 19, 2009 at 4:15 PM, Frank Shute fr...@shute.org.uk wrote: On Thu, Mar 19, 2009 at 03:21:05PM -0500, Neal Hogan wrote: The last couple of days I've been running portupgrade -av and am to the point where I'd like to move onto something else, but there is one package that won't upgrade . . . xorg-server. As you can see below, it claims that there is a missing header and there are a fair amount of reported errors. I'm not the best at deciphering the stuff below. I've tried make deinstalling/reinstalling and individually portupgrading it to no avail. suggestions? glxdriswrast.c:39:39: error: GL/internal/dri_interface.h: No such file or directory $ pkg_info -W /usr/local/include/GL/internal/dri_interface.h /usr/local/include/GL/internal/dri_interface.h was installed by package xf86driproto-2.0.3 I wish to not only that Frank for his patience and subtle hand-holding, but also address the rest of the list. Thanks a lot *takes bow* ;) First, concerning the issue Mr. Shute responded to . . . I reinstalled xf86driproto, which installed the dri_interface.h, which allowed me to pkg_add xorg-server. However, it was the older version of xorg-server. So, I ran portupgrade on it and it, again, claims that there is no dri_interface.h. According to pkg_version, all xorg and xf86 ports are up-to-date, except xorg-server of which there is a newer version. What I wouldn't do is mix and match packages with ports. The xorg-server package is likely to have been built against older ports. IMO, it's always best to stick with ports. So: # pkg_deinstall -f xorg-server # portupgrade -Nv xorg-server should fix things for you and bring your xorg-server uptodate. That said, I was hoping that you can help me understand the portupgrade process b/c it can be a bit frustrating when it runs for a LONG time only to have upgrades fail. Please don't take my tone to be anything other than one coming from a sense of curiosity. I don't mean to suggest anything about the fBSD ports system. Perhaps my experience is the result of my own oversight. Just to be clear, here are the steps I took: 1) #portsnap fetch 2) #portsnap extract 3) #portsnap update 4) #pkgdb -u 5) #pkgdb -F 6) #portupgrade -av That looks OK to me (I don't use portsnap, mind you). As I noted in another post, some ports fail to upgrade when using portupgrade -a, no matter how many times it is run. However, they (those that fail), along with their dependencies, do upgrade when portupgraded individually (or de/reinstalled). I thought the purpose of having a ports system, where you install the ports tree and use portupgrade, was to make the install/upgrade easy and rather painless, such that all ports and their dependencies are taken care of. If you do: $ pkg_info | wc -l you'll see that you've got a lot of ports and portupgrade does a pretty good job of upgrading the vast majority of them without any hand holding. Keeping application software uptodate on any platform is problematic and there are inevitably some bits that you have to troubleshoot. As I write this I am running portupgrade individually, on those ports that failed to upgrade with -a option, but have (so far) succeeded in upgrading individually. I am simply looking at the output of pkg_version to find those that are not up-to-date. Use portversion (it's quicker): $ portversion | grep I could see if ports failed to upgrade or were ignored due to there being no diff between what's installed and that which is in the updated tree. Can someone shed some light on this? Thanks a lot for taking the time. -Neal Neal, you're doing OK! You just mixed up packages and ports. Whilst theoretically possible, in practice it results in problems - certainly with portupgrade. portupgrade is a good tool and if you stick to it with just ports you wont go far wrong. Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: portupdate xorg-server
Well Frank, if/when you read my most recent comment, you'll notice that I've probably confused ports and packages again. As has been the case for the past week or so, thanks for taking the time. On Fri, Mar 20, 2009 at 5:17 PM, Frank Shute fr...@shute.org.uk wrote: On Fri, Mar 20, 2009 at 10:14:32AM -0500, Neal Hogan wrote: On Thu, Mar 19, 2009 at 4:15 PM, Frank Shute fr...@shute.org.uk wrote: On Thu, Mar 19, 2009 at 03:21:05PM -0500, Neal Hogan wrote: The last couple of days I've been running portupgrade -av and am to the point where I'd like to move onto something else, but there is one package that won't upgrade . . . xorg-server. As you can see below, it claims that there is a missing header and there are a fair amount of reported errors. I'm not the best at deciphering the stuff below. I've tried make deinstalling/reinstalling and individually portupgrading it to no avail. suggestions? glxdriswrast.c:39:39: error: GL/internal/dri_interface.h: No such file or directory $ pkg_info -W /usr/local/include/GL/internal/dri_interface.h /usr/local/include/GL/internal/dri_interface.h was installed by package xf86driproto-2.0.3 I wish to not only that Frank for his patience and subtle hand-holding, but also address the rest of the list. Thanks a lot *takes bow* ;) First, concerning the issue Mr. Shute responded to . . . I reinstalled xf86driproto, which installed the dri_interface.h, which allowed me to pkg_add xorg-server. However, it was the older version of xorg-server. So, I ran portupgrade on it and it, again, claims that there is no dri_interface.h. According to pkg_version, all xorg and xf86 ports are up-to-date, except xorg-server of which there is a newer version. What I wouldn't do is mix and match packages with ports. The xorg-server package is likely to have been built against older ports. IMO, it's always best to stick with ports. So: # pkg_deinstall -f xorg-server # portupgrade -Nv xorg-server should fix things for you and bring your xorg-server uptodate. That said, I was hoping that you can help me understand the portupgrade process b/c it can be a bit frustrating when it runs for a LONG time only to have upgrades fail. Please don't take my tone to be anything other than one coming from a sense of curiosity. I don't mean to suggest anything about the fBSD ports system. Perhaps my experience is the result of my own oversight. Just to be clear, here are the steps I took: 1) #portsnap fetch 2) #portsnap extract 3) #portsnap update 4) #pkgdb -u 5) #pkgdb -F 6) #portupgrade -av That looks OK to me (I don't use portsnap, mind you). As I noted in another post, some ports fail to upgrade when using portupgrade -a, no matter how many times it is run. However, they (those that fail), along with their dependencies, do upgrade when portupgraded individually (or de/reinstalled). I thought the purpose of having a ports system, where you install the ports tree and use portupgrade, was to make the install/upgrade easy and rather painless, such that all ports and their dependencies are taken care of. If you do: $ pkg_info | wc -l you'll see that you've got a lot of ports and portupgrade does a pretty good job of upgrading the vast majority of them without any hand holding. Keeping application software uptodate on any platform is problematic and there are inevitably some bits that you have to troubleshoot. As I write this I am running portupgrade individually, on those ports that failed to upgrade with -a option, but have (so far) succeeded in upgrading individually. I am simply looking at the output of pkg_version to find those that are not up-to-date. Use portversion (it's quicker): $ portversion | grep I could see if ports failed to upgrade or were ignored due to there being no diff between what's installed and that which is in the updated tree. Can someone shed some light on this? Thanks a lot for taking the time. -Neal Neal, you're doing OK! You just mixed up packages and ports. Whilst theoretically possible, in practice it results in problems - certainly with portupgrade. portupgrade is a good tool and if you stick to it with just ports you wont go far wrong. Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html -- www.nealhogan.net www.lambdaserver.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: portupdate xorg-server
Neal Hogan wrote: In light of Adam's comment and thinking about the comment he's responding to, I realize that I may have been rather obnoxious. I appreciate Adam setting that aside to give me and the list some of his time. I'm rather new to fBSD (obvious) and I've got my parent's machine on it, which is hundreds of miles away and they have put in requests that led me to upgrade their system, including ports (and when X gets messed up from a remote position, it can be frustrating). So, I apologize if my comments came across in such a way that annoyed you. Not being a dev (or anywhere close), I have little room to act that way. But, I wonder what the most efficient way is to update ports. I appreciate Adam's point about the fact that portupgrade (and portmanager and portmaster) are ports themselves and are going to not be as reliable as what is in base. However, the fBSD documentation on updating ports (i.e., the handbook) only suggests the above three as ways to update ports. Is there a way to update ports from a base app? Given that a basic setup will have quite a few ports (hundreds), I was wondering if there was another way to update all (including their dependencies), rather that a one-by-one *make update* or *portupgrade*. http://www.lambdaserver.com If you are asking for a failsafe method of doing this, I'm afraid there isn't one totally issue free. If you are going to restrict yourself to known good fulling working apps, you should limit yourself to packages not ports where possible. This will insure you've pkg's that run correctly under GENERIC for your release. If you go to a stable or current branch, it's expected you'll be able to take care of yourself to some degree. Base system tools for what you are talking about consists of things like pkg_add and pkg_delete. pkg_deinstall and the like are not past of base system. There are also loads of options under ports man page. If you haven't reviewed it, you should. It does provide some of the functionality of other port management tools as part of base system. Please don't misunderstand my earlier post however, you can still easily run into dependency issues with any port tools so just because the port make options include things like depends it doesn't mean that you'll have 100% success rate. Again, best chance of that is sticking w/ packages at the expense of not running latest version of software. http://www.freebsd.org/cgi/man.cgi?query=portsapropos=0sektion=0manpath=FreeBSD+7.1-RELEASE+and+Portsformat=html Options like cd /usr/ports make readmes aren't well known to most newcomers to whom things like that would be the most benefit. Something like portcheckout may help you a lot, just getting starting in FBSD is much harder than actually maintaining a running system once you're familiar with how things work. #1 rule is of course RTFM, which just leaves you with which M to actually FR. That is often the hardest part of getting started. Best command to get started is man man just to make sure you're using it effectively. apropos also very important for digging up clues if lost. -- Adam Vandemore Systems Administrator IMED Mobility (605) 498-1610 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: portupdate xorg-server
On Fri, 20 Mar 2009 17:04:00 -0500 Neal Hogan nealho...@gmail.com wrote: But, I wonder what the most efficient way is to update ports. I appreciate Adam's point about the fact that portupgrade (and portmanager and portmaster) are ports themselves and are going to not be as reliable as what is in base. IMO this doesn't make any sense. If portupgrade is failing on a port where manual make install works, then portupgrade simply has a bug. Any port upgrading tool belongs in a port, because it's more important that it responds to changes in the ports system than changes in the base system. As to upgrading piecemeal rather than with -a, I don't see how that helps, and it may actually make things worse by not building in dependency order. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: portupdate xorg-server
RW wrote: IMO this doesn't make any sense. If portupgrade is failing on a port where manual make install works, then portupgrade simply has a bug. Any port upgrading tool belongs in a port, because it's more important that it responds to changes in the ports system than changes in the base system. As to upgrading piecemeal rather than with -a, I don't see how that helps, and it may actually make things worse by not building in dependency order. ___ As to the first part of your msg, what you said doesn't make any sense to me either. Never did I claim portupgrade fails where a normal make install would succeed. I would appreciate it if you could take my example as I state it instead adding stuff to make it sound implausible. Thanks. When you're doing a massive update, and you run into to depedancy issues, you'll know what I'm talking. Also after you get some experience in ports, you'll be able to understand that you can't depend on it compiling all the time. Want an example? Try compiling misc/wanpipe w/ misc/zaptel right now and tell me how far you get. Doing a portupgrade -a on system w/ 1000+ packages installed and there's a pretty good chance you'll run into more than one issue with something like that or it's lesser cousin. Upgrading in smaller chunks is easier. It's actually a fairly common principle. http://en.wikipedia.org/wiki/Divide_and_conquer_algorithm One practical example is xorg 1.4 -- 1.5 a lot of us had issues with a couple months ago or whenever it was. Many users wrote in after doing something like a portupgrade -a and blaming their display problem from xorg on whatever WM they happened to be using. Had they done it in smaller segments, they would easily be able to identify source. And no, it doesn't bring you into dependency hell, it brings you out of it easier. Hope that clears up the confusion for you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
portupdate xorg-server
The last couple of days I've been running portupgrade -av and am to the point where I'd like to move onto something else, but there is one package that won't upgrade . . . xorg-server. As you can see below, it claims that there is a missing header and there are a fair amount of reported errors. I'm not the best at deciphering the stuff below. I've tried make deinstalling/reinstalling and individually portupgrading it to no avail. suggestions? glxdriswrast.c:39:39: error: GL/internal/dri_interface.h: No such file or directory In file included from glxdriswrast.c:49: glxdricommon.h:32: error: expected ':', ',', ';', '}' or '__attribute__' before '*' token glxdricommon.h:36: warning: type defaults to 'int' in declaration of '__DRIcoreExtension' glxdricommon.h:36: error: expected ';', ',' or ')' before '*' token glxdricommon.h:38: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'systemTimeExtension' glxdriswrast.c:64: error: expected specifier-qualifier-list before '__DRIscreen' glxdriswrast.c:75: error: expected specifier-qualifier-list before '__DRIcontext' glxdriswrast.c:80: error: expected specifier-qualifier-list before '__DRIdrawable' glxdriswrast.c: In function '__glXDRIdrawableDestroy': glxdriswrast.c:92: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token glxdriswrast.c:92: error: 'core' undeclared (first use in this function) glxdriswrast.c:92: error: (Each undeclared identifier is reported only once glxdriswrast.c:92: error: for each function it appears in.) glxdriswrast.c:92: error: '__GLXDRIdrawable' has no member named 'screen' glxdriswrast.c:94: error: '__GLXDRIdrawable' has no member named 'driDrawable' glxdriswrast.c:96: error: '__GLXDRIdrawable' has no member named 'gc' glxdriswrast.c:97: error: '__GLXDRIdrawable' has no member named 'cleargc' glxdriswrast.c:98: error: '__GLXDRIdrawable' has no member named 'swapgc' glxdriswrast.c: In function '__glXDRIdrawableSwapBuffers': glxdriswrast.c:116: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token glxdriswrast.c:116: error: 'core' undeclared (first use in this function) glxdriswrast.c:116: error: '__GLXDRIdrawable' has no member named 'screen' glxdriswrast.c:118: error: '__GLXDRIdrawable' has no member named 'driDrawable' glxdriswrast.c: In function '__glXDRIdrawableCopySubBuffer': glxdriswrast.c:128: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token glxdriswrast.c:128: error: 'copySubBuffer' undeclared (first use in this function) glxdriswrast.c:129: error: '__GLXDRIdrawable' has no member named 'screen' glxdriswrast.c:132: error: '__GLXDRIdrawable' has no member named 'driDrawable' glxdriswrast.c: In function '__glXDRIcontextDestroy': glxdriswrast.c:141: error: '__GLXDRIscreen' has no member named 'core' glxdriswrast.c:141: error: '__GLXDRIcontext' has no member named 'driContext' glxdriswrast.c: In function '__glXDRIcontextMakeCurrent': glxdriswrast.c:154: error: '__GLXDRIscreen' has no member named 'core' glxdriswrast.c:154: error: '__GLXDRIcontext' has no member named 'driContext' glxdriswrast.c:155: error: '__GLXDRIdrawable' has no member named 'driDrawable' glxdriswrast.c:156: error: '__GLXDRIdrawable' has no member named 'driDrawable' glxdriswrast.c: In function '__glXDRIcontextLoseCurrent': glxdriswrast.c:165: error: '__GLXDRIscreen' has no member named 'core' glxdriswrast.c:165: error: '__GLXDRIcontext' has no member named 'driContext' glxdriswrast.c: In function '__glXDRIcontextCopy': glxdriswrast.c:176: error: '__GLXDRIscreen' has no member named 'core' glxdriswrast.c:176: error: '__GLXDRIcontext' has no member named 'driContext' glxdriswrast.c:177: error: '__GLXDRIcontext' has no member named 'driContext' glxdriswrast.c: In function '__glXDRIcontextForceCurrent': glxdriswrast.c:188: error: '__GLXDRIscreen' has no member named 'core' glxdriswrast.c:188: error: '__GLXDRIcontext' has no member named 'driContext' glxdriswrast.c:189: error: '__GLXDRIdrawable' has no member named 'driDrawable' glxdriswrast.c:190: error: '__GLXDRIdrawable' has no member named 'driDrawable' glxdriswrast.c: In function '__glXDRIscreenDestroy': glxdriswrast.c:253: error: '__GLXDRIscreen' has no member named 'core' glxdriswrast.c:253: error: '__GLXDRIscreen' has no member named 'driScreen' glxdriswrast.c:255: error: '__GLXDRIscreen' has no member named 'driver' glxdriswrast.c: In function '__glXDRIscreenCreateContext': glxdriswrast.c:270: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token glxdriswrast.c:270: error: 'core' undeclared (first use in this function) glxdriswrast.c:270: error: '__GLXDRIscreen' has no member named 'core' glxdriswrast.c:271: error: '__DRIcontext' undeclared (first use in this function) glxdriswrast.c:271: error: 'driShare' undeclared (first use in this function) glxdriswrast.c:275: error: '__GLXDRIcontext' has no member named 'driContext' glxdriswrast.c:291: error: '__GLXDRIcontext' has no member named 'driContext'
Re: portupdate xorg-server
Neal Hogan wrote: Stop in /usr/ports/x11-servers/xorg-server/work/xorg-server-1.5.3/glx. *** Error code 1 Stop in /usr/ports/x11-servers/xorg-server/work/xorg-server-1.5.3. *** Error code 1 Stop in /usr/ports/x11-servers/xorg-server. *** Error code 1 Stop in /usr/ports/x11-servers/xorg-server. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20090319-55106-13es25h-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=xorg-server-1.4.2,1 UPGRADE_PORT_VER=1.4.2,1 make ** Fix the problem and try again. --- Build of x11-servers/xorg-server ended at: Thu, 19 Mar 2009 15:10:40 -0500 (consumed 00:11:17) --- Upgrade of x11-servers/xorg-server ended at: Thu, 19 Mar 2009 15:10:40 -0500 (consumed 00:11:17) --- ** Upgrade tasks 1: 0 done, 0 ignored, 0 skipped and 1 failed --- Listing the results (+:done / -:ignored / *:skipped / !:failed) ! x11-servers/xorg-server (xorg-server-1.4.2,1)(missing header) --- Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed --- Session ended at: Thu, 19 Mar 2009 15:10:40 -0500 (consumed 00:11:21) Sometimes doing a cd /usr/ports/x11-servers/xorg-server make clean deinstall reintall or a make distclean to redownload tar -- Adam Vandemore Systems Administrator IMED Mobility (605) 498-1610 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: portupdate xorg-server
On Thu, Mar 19, 2009 at 03:21:05PM -0500, Neal Hogan wrote: The last couple of days I've been running portupgrade -av and am to the point where I'd like to move onto something else, but there is one package that won't upgrade . . . xorg-server. As you can see below, it claims that there is a missing header and there are a fair amount of reported errors. I'm not the best at deciphering the stuff below. I've tried make deinstalling/reinstalling and individually portupgrading it to no avail. suggestions? glxdriswrast.c:39:39: error: GL/internal/dri_interface.h: No such file or directory $ pkg_info -W /usr/local/include/GL/internal/dri_interface.h /usr/local/include/GL/internal/dri_interface.h was installed by package xf86driproto-2.0.3 HTH. snip Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
