mpeg4ip requires IPv6?

Michael C. Shultz reso3w83 at
Thu Jan 6 12:03:34 PST 2005

On Thursday 06 January 2005 10:38 am, Scott I. Remick wrote:
> Ah, the useful information starts pouring in!
> On Thu, 6 Jan 2005 08:51:49 -0800, Michael C. Shultz wrote:
> > Just a suggestion here, two ways you can go about this
> > so here is the hard way first:
> >
> > Rename /usr/src/lib/compat to /usr/src/lib/compat-HOLD or something
> > like that, then what ever programs are linked against them will
> > fail and these need to be rebuilt.
> I'd be willing to do this... but... is it possible to cheat a little
> and determine proactively what ports are linked against them? See the
> output in the other post I made earlier today (the huge one).
> > The easier but much longer way, download sysutils/portmanager and
> > run portmanager -u.
> I'm unclear the difference between "portmanager -s" and "portversion
> -v"? They seem to output the same results, more or less, neither
> being the dramatic list of apps linked to old libraries. Instead it's
> simply a list of what I have installed that has newer versions in the
> ports tree.

did you try portmanager -u?
> su-2.05b# portmanager -s | grep OLD
> have:mplayer-gtk2-esound-0.99.5_4 status: OLD
> available:mplayer-gtk2-esound-0.99.5_5 multimedia/mplayer
> have:linux-sun-jdk-    status: OLD
> available:linux-sun-jdk-  java/linux-sun-jdk14
> have:xorg-server-6.8.1         status: OLD
> available:xorg-server-6.8.1_1 x11-servers/xorg-server
> have:SimGear-0.3.5             status: OLD available:SimGear-0.3.7
>   devel/simgear
> have:FlightGear-0.9.3_1        status: OLD available:FlightGear-0.9.6
>   games/flightgear
> have:gnumeric2-1.4.1           status: OLD requires downgrade!
> available:gnumeric-1.4.1            math/gnumeric
> have:gnomemeeting-0.98.5_2     status: OLD
> available:gnomemeeting-0.98.5_4 net/gnomemeeting
> have:gnofract4d-1.9_2          status: OLD available:gnofract4d-1.9_3
>   graphics/gnofract4d
> have:gnomenettool-1.0.0,1      status: OLD
> available:gnomenettool-1.0.0_1,1 net/gnomenettool
> have:nvidia-driver-1.0.6113_2  status: OLD
> available:nvidia-driver-1.0.6113_3  x11/nvidia-driver
> have:firefox-1.0_6,1           status: OLD available:firefox-1.0_7,1
>   www/firefox
> have:gtkam-gnome-0.1.12_2      status: OLD
> available:gtkam-gnome-0.1.12_3 graphics/gtkam
> have:openoffice- status: OLD
> available:openoffice- editors/openoffice-1.1-devel
> status report finished
> su-2.05b# portversion -v -l \<
> [Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 534
> packages found (-0 +1) . done]
> FlightGear-0.9.3_1          <  needs updating (port has 0.9.6)
> SimGear-0.3.5               <  needs updating (port has 0.3.7)
> firefox-1.0_6,1             <  needs updating (port has 1.0_7,1)
> gnofract4d-1.9_2            <  needs updating (port has 1.9_3)
> gnomemeeting-0.98.5_2       <  needs updating (port has 0.98.5_4)
> gnomenettool-1.0.0,1        <  needs updating (port has 1.0.0_1,1)
> gtkam-gnome-0.1.12_2        <  needs updating (port has 0.1.12_3)
> linux-sun-jdk-      <  needs updating (port has
> mplayer-gtk2-esound-0.99.5_4  <  needs updating (port has 0.99.5_5)
> nvidia-driver-1.0.6113_2    <  needs updating (port has 1.0.6113_3)
> openoffice-   <  [held] needs updating (port has
> xorg-server-6.8.1           <  needs updating (port has 6.8.1_1)
> > It will update the out of date dependencies but if you
> > have been running pkgdb -F from portupgrade then portmanager may
> > miss a few because pkgdb screws up the ports registration data
> > base.
> I have. :( Do the outputs above suggest that using portmanager isn't
> going to do much for me?

It won't get your system perfect at first because it isn't picking up 
many of the lower dependencies, likely because pkgdb made too many 
changes to the registry,  I say you should run portmanager anyways 
because it will start getting things right over time and never ever run 
pkgdb again.  As the lower dependencies (like gettext, glib, gtk etc) 
are updated in CVS and you get them with cvsup, then running 
portmanager will get everthing built correctly that use those updated 
dependencies, so in the long run things will improve for you.

about open office:

There is going to be a change in portmanager to allow ports like 
openoffice to be ignored, but until that happens if you don't want 
portmanager updating it you have to mv or rename /var/db/openoffice* to 
something else so the ports system doesn't know its installed.  Other
than this one hassle with openoffice I think portmanager is your best 
option for getting the dependencies on your system fixed.

> > Anything that fails should be pkg_deleted then rebuilt manually.
> Instead of deleting, would a portupgrade -fR make more sense, that
> way you catch all the dependencies in case it's one of THEM that's
> causing the app to fail?

I agree with you here, portupgrade -fR would be a better way to go,
providing you can run it without needing to run pkgdb -F first. 

> > Once everything works without the /usr/src/lib/compat libraries I'd
> > recommend deleteing them and in /etc/make.conf comment out the
> > following:
> >
> > COMPAT1X=      yes
> > COMPAT20=      yes
> > COMPAT21=      yes
> > COMPAT22=      yes
> > COMPAT3X=      yes
> > COMPAT4X=      yes
> I don't have any of those in my make.conf

Why are they on your system then?
> > still it will save you many headaches down the road to get every
> > thing linked to the new c libraries and not the compat ones.
> Agreed. That's my goal.
> > I've noticed a few posts recently complaining open office won't
> > build on 5.3 stable so I'm trying it on my system, the thing has
> > been building for 24 hours now and still isn't finished!
> 24+ hours sounds about normal. Only reason I have 1.1.3 right now is
> I used a package this morn (I had a homebuilt 1.1.0 earlier). Haven't
> tested it yet. Considering the portversion/portmanager output above,
> I think I got the devel version. :(
> > What I'm hoping to be able to tell you, is after your system is
> > fully up to date with portmanager that building openoffice will be
> > no problem,
> That'd be really nice. I've been stuck on 1.1.0 for a long while.
> 1.1.3 is much prettier.

If its working, I say be happy with it.
> > one thing I had to do
> > to get openoffice to at least start compiling was to set up the
> > following in /etc/make.conf:
> >
> > .if ${.CURDIR:M*/editors/openoffice-1.1}
> > .endif
> >
> > because it fails early on if mozilla isn't disabled. I keep my
> > special port settings in /etc/make.conf so if I manually install
> > ports or do so with portmanager or portupgrade I know the correct
> > switches will always be used.
> Hmm I didn't know you could do conditional statements like that in
> /etc/make.conf. That's nice. I actually already use both those values
> though.
> > Hope my advice helps you some, but really I can do much better if I
> > see specific instances of a failure like the one you posted to the
> > mail list, everything I said above, you may have a special
> > circumstance that makes what I said wrong.
> Sounds good... just trying to make sure we're certain where to go
> from here first before we start busting apps by whacking old
> libraries. You might want to take a look at that other long post I
> made earlier today that I mentioned and see if it provides you any
> additional information.
> Thanks so much for your help!


More information about the freebsd-ports mailing list