portupdate xorg-server

2009-03-19 Thread Neal Hogan 
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'
glxdriswrast.c:2

Re: portupdate xorg-server

2009-03-19 Thread Adam Vandemore 

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

2009-03-19 Thread Frank Shute 
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.



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

2009-03-20 Thread Neal Hogan 
On Thu, Mar 19, 2009 at 4:15 PM, Frank Shute  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.
>
> 
>
> 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

2009-03-20 Thread Adam Vandemore 

Neal Hogan wrote:

On Thu, Mar 19, 2009 at 4:15 PM, Frank Shute  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

2009-03-20 Thread Neal Hogan 
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 wrote:

> Neal Hogan wrote:
>
>> On Thu, Mar 19, 2009 at 4:15 PM, Frank Shute  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 spec

Re: portupdate xorg-server

2009-03-20 Thread Frank Shute 
On Fri, Mar 20, 2009 at 10:14:32AM -0500, Neal Hogan wrote:
>
> On Thu, Mar 19, 2009 at 4:15 PM, Frank Shute  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

2009-03-20 Thread Neal Hogan 
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  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  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

2009-03-20 Thread Adam Vandemore 

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*. 
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=ports&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE+and+Ports&format=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

2009-03-20 Thread RW 
On Fri, 20 Mar 2009 17:04:00 -0500
Neal Hogan  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

2009-03-20 Thread Adam Vande More 

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"

Re: portupdate xorg-server

2009-03-21 Thread RW 
On Sat, 21 Mar 2009 00:39:31 -0500
Adam Vande More  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"