Solved [Solved] pkg version -l "<" strange results

dcbdbis

dcbdbis

Good Morning Everyone,

FreeBSD 10.0 Release-P7, x64.

For the last month or so, I have been getting a list of 6 packages that are supposed to be upgraded as tagged by pkg version -l "<". When I issue a
portsnap fetch update followed by a portmaster -a, these very files and their dependencies get rebuilt....but post build/install/reboot, pkg version -l "<" still returns these same packages as needing upgrading.

I took the next step and did a pkg info <packagename>|grep Version...to validate the version data. The pkg version is the same version in the pkg db, and the ports tree as well when I look there. This shows that there are in truth no upgrades necessary nor available.

The specific packages that complain that they are perpetually in need of upgrading are:
Code: 
[dcbdbis@Curly-Sr ~]$ pkg version -l "<"
dri-7.6.1_4,2                      <
libGL-7.6.1_4                      <
libdrm-2.4.17_1,1                  <
xf86-video-ati-6.14.6_3            <
xf86-video-intel-2.7.1_8           <
xorg-server-1.7.7_13,1             <

Can someone enlighten me on what may be going on here?

FYI: I am using the NVidia proprietary driver from the pkg repo, not the ports tree.

Thank You for any assistance you can provide.


Sincerely and respectfully,

Dave
 
Re: pkg version -l "<" strange results

Maybe it could be that ? (But it's longer ago, than a month).

/usr/ports/UPDATING:
Code: 
20140416:
  AFFECTS: users of x11/xorg graphics/dri graphics/libGL and related ports
  AUTHOR: x11@FreeBSD.org

  The default xorg version has been switched on FreeBSD 10-STABLE and
  FreeBSD 9-STABLE.

  To upgrade graphics/libGL, graphics/dri and related MESA ports, it is
  necessary to first remove the old versions of those ports.
  No special upgrade procedure is needed for xorg ports but it is
  necessary to recompile all xorg drivers (xf86-*) and other ports that
  depend on the xserver version, including
  emulators/virtualbox-ose-additions.  Portrevisions have been bumped
  where needed, but users of drivers not in the ports tree will need to
  recompile those.

  If it is important to stay on the old versions, it is possible to
  specify WITHOUT_NEW_XORG= in /etc/make.conf to get the old xorg
  distribution.

  For users in need of working console when using KMS drivers (intel and
  radeon graphics cards) please use the new vt(9) console driver.
  For more information, see https://wiki.freebsd.org/Graphics and
  https://wiki.freebsd.org/Newcons .

  To update:

  # pkg_delete -f libGL-\* dri-\*
    or
  # pkg delete -f libGL dri
    followed by
  # portmaster graphics/dri graphics/libGL
    or
  # portupgrade graphics/dri graphics/libGL
    and then
  # portmaster -a
    or
  # portupgrade -a
 
Re: pkg version -l "<" strange results

Thank you for the post.

I did indeed follow this procedure that you posted, unfortunately the number of ports showing needing upgrade have increased now.

Code: 
[dcbdbis@Curly-Sr ~]$ sudo pkg version -l "<"
dri-7.6.1_4,2                      <
libGL-7.6.1_4                      <
libdrm-2.4.17_1,1                  <
libxfce4util-4.10.1_1              <
linux-f10-gtk2-2.14.7_4            <
rarian-0.8.1_1                     <
xorg-server-1.7.7_13,1             <

Does anyone have any idea what is going on?

Info: I have a laptop that is not needed at the moment. I hard-wiped the HDD and installed FreeBSD to the laptop,...Did all the usual updates to bring it current with my desktop (both are x64).....and the same files show up there as well....So whatever is going on, it is not specific to my desktop.

Thank you for any assistance,

Sincerely and respectfully,


Dave

Edit: I have most of my system installed via precompiled packages....with a the few that I need that are not in binary form (yet) from ports. Could mixing packages and ports have something confused in my system?

And having said that...I can't find in the man packages how to tell either portmaster nor pkg to rebuild and reindex their databases manually...to see if that solves my issue.
 
Re: pkg version -l "<" strange results

ports-mgmt/portmaster does not use a separate database, just what the ports system provides. ports-mgmt/portupgrade has the pkgdb command. I don't remember how to rebuild that.

Some of those ports listed do have new versions. For example, the X ports and libraries show you have the old version, not the new KMS version. That could be from using packages. I don't know, I don't use packages.
 
Re: pkg version -l "<" strange results

I have the same thing going on, but I assumed it was because 10.0 Release uses the older xorg by default. I have only used ports, no prebuilt packages.

I was coming here (after an extensive search) to ask if all that is necessary to update is to put WITH_NEW_XORG=YES in /etc/make.conf and run portmaster -a over them. Will it automatically rebuild all the dependent ports, or do I need to run run portmaster -ar? Do all dependent ports need to be rebuilt?

Is there any reason not to update to the newer xorg on 10.0 Release? And have I missed thinking about anything I'd need to do, if I were to update?
 
Re: pkg version -l "<" strange results

Thanks for the pointer.

I have a GeForce GTX 560 Ti video card, which is marked as "works" for the nvidia proprietary driver, which is what I use. No onboard video on my motherboard. Since it says "To have a working console with the Radeon and Intel KMS drivers, please read the vt(4) page," does that mean vt is not a problem for the nvidia driver, or that there is no working console for the nvidia driver, and no workaround?

In my case, using pkg version -v |grep "<" shows the following:
Code: 
# pkg version -v|grep "<"
dri-7.6.1_4,2                      <   needs updating (index has 9.1.7_4,2)
libGL-7.6.1_4                      <   needs updating (index has 9.1.7_1)
libdrm-2.4.17_1,1                  <   needs updating (index has 2.4.52,1)
xf86-video-ati-6.14.6_3            <   needs updating (index has 7.2.0_3)
xf86-video-intel-2.7.1_8           <   needs updating (index has 2.21.15_3)
xorg-server-1.7.7_13,1             <   needs updating (index has 1.12.4_8,1)

where portmaster -L does not show the updates for them. I guess this is because pkg is not looking at make.conf, whereas portmaster is. Unlike the OP, my portmaster -a does not rebuild these, just skips them.

I have no pressing need to update (that I know of), and only considered it because, like with the OP, it recently began showing up in my pkg version -v |grep "<"s. I'm a casual desktop user, but FreeBSD is my daily desktop (and has been since 2007). If this might turn into one of those nightmarish situations where my main computer is disabled till Ifigure out what's wrong and how to fix it, I'll wait till the 10.1 Release is out.

What do you think? Will this be relatively trouble free, or should I wait?
 
Re: pkg version -l "<" strange results

I'd expect the Nvidia cards to work with the later versions of X, but have not tried them. I avoid them because of the closed drivers.
 
Re: pkg version -l "<" strange results

I thank all of you for your feedback and for the discussion in general.

It appears that what I am experiencing is not unique...and like another poster, my system is operating just fine. So just because a few packages are flagged out of date when they really aren't....I don't feel like nit-picking this.

I wish that the nouveau drivers were better than they are, but they're not. I have always had trouble with the nouveau stuff including up to the most current experience in FreeBSD. As a result I will continue to use the NVidia proprietary drivers until I upgrade my system and go with a different card, or until nouveau can finish maturing. For me, personally...I am more about solid system function that a pure FOSS system. I do CAD work, so I really have to have a solid graphical subsystem.

I am not going to mark this post as solved (yet). We have clues, but no concrete answers yet. And if it is not solved (or unsolvable) until 10.1 goes general release....I am not going to really stress about it. My system is performing perfectly...I can easily deal with a little errata from a tool or two.

Again, great discussion all!

Thank you.

Sincerely and respectfully,


Dave
 
Re: pkg version -l "<" strange results

I too have been happy with the proprietary nvidia driver, and am glad they provide one specific to FreeBSD, proprietary or not.

I think, given the uncertainties of upgrading Xorg while using 10.0 Release, although from my reading, the problems seem to be more associated with Radeon and Intel, I will stick with the version that's working for me now. I would welcome further discussion, though, or to hear from someone using 10.0 Release and the proprietary nvidia driver about any problems they may have experienced.

Thanks for your input, @wblock and @uzsolt. Right after the thread you pointed to, @uzsolt, is another person commenting about the same thing @dcbdbis and I noticed: https://lists.freebsd.org/pipermail/fre ... 14500.html

Dave, what a coincidence - I also do CAD work, but have only used AutoCAD until recently, because that's what my employer required. I have not investigated the different CAD software available for FreeBSD; what do you use? Feel free to PM me if this is off-topic enough to get us in trouble here. :r
 
Last edited by a moderator:
Re: pkg version -l "<" strange results

Update:

I did the make.confthing @ https://wiki.freebsd.org/Graphics#Installing_KMS_Ports and tried the new server. What a mistake! This server is clearly targeted at certain chipsets.

By my actions, I completely broke "X", and have spent the whole afternoon getting it back up. I had to surgically remove "X" and all it's parts and pieces. Delete the /etc/make.conf file. Then reinstall. I chose ports this time.

I still have one vestige left, about a 45 second delay after I type startx, before I get a screen, whereas I would have a screen up in < 1 sec before I borked my "X" installation.

So I would recommend the Intel and Gallium stuff for those who have those specific chipsets. For others who don't. I recommend remaining on the current "X" and leaving it be, and just ignoring the update info.

@alias, please let me get my system totally fixed and I'll PM you on your CAD question. It may be tomorrow.


Sincerely and respectfully,

Dave
 
Last edited by a moderator:
Re: pkg version -l "<" strange results

A long delay at X startup generally means DNS resolution is failing for the hostname.

As far as what is required for the Nvidia proprietary drivers, it depends on Nvidia. There is an open driver, nv, which has reach surprising levels of function despite Nvidia refusing to release any programming information. It is still lacking compared to what is needed, though.

I've used the KMS drivers on Intel and Radeon chipsets. They work very well for the supported chipsets. The most recent chipsets (Haswell and Radeon 8000- and later) are either unsupported, or only partly supported.
 
Re: pkg version -l "<" strange results

@wblock, I wish it was as simple as that, but it isn't. Things went ballistic when I installed the new X server. I rapidly retreated.

I removed the line in /etc/make.conf, then manually removed everything having to do with "X" by pkg delete -f <package name>. I manually removed the dri, libGL, libdrm, dbus, and hal as well. Then I got a little desperate to get my desktop back as I had a client call in, so I performed a portmaster -f dri libGL libdrm xorg mate dbus hal. It was building for about 2 hours.

I have my desktop back, but I still have ~ 45 second delay after a call to startx.

The relevant portion of my /etc/rc.conf is

Code: 
hostname="freebsd.dbis.net"

and the relevant lines from /etc/hosts are

Code: 
127.0.0.1		localhost 	localhost.my.domain
127.0.0.1		freebsd	freebsd.dbis.net

If you have any ideas or pointers, man I am all ears!

Sincerely and respectfully,

Dave
 
Last edited by a moderator:
All is solved. The update issue, and the slow startup issue.

Lets document:

a) The original post was about a strange result in pkg version. I found it to indeed be related to the new xorg issue which I tried, and broke my system. Well, only partially true...I experienced that it was HAL that broke my new xorg install. Once I decided to use ports and not packages, coupled with the new xorg setting....Normal operation of FreeBSD was restored. I did have to issue portmaster --force-config -f to deeply go into the dependencies, and give me the option to remove hal from every port that had it in the config.

b) I have the new version of xorg installed (I use proprietary NVidia drivers) where I have WITH_NEW_XORG=yes in my /etc/make.conf.. The slow startup issue was found to be related to hal. I reconfigured my xorg-server to use devd instead of hal (despite it's experimental status, and only after reading another's success story with it). I did a really deep rebuild as mentioned previously. Yes...it took a while.

And the result is that I am on the new xorg, with proprietary NVidia drivers., and my VT's operate correctly, with no 45ish second delay, no files being erroneously flagged as needing upgrades. I can also validate that "X" is running fine with devd.

Lastly I removed the line in my /etc/rc.conf that starts hal, and used pkg delete -f to remove hal from my system.

Everything is back to normal, working perfectly, and I have no packages being flagged as needing upgrading.

Hope this helps sum it all up,


Sincerely and respectfully,


Dave

Edit: I am not saying that these exact steps are needed. I am too junior with FreeBSD to make such a claim. I am simply documenting what I did to resolve the issue, and to restore normal operation. Other more senior members than me may post better ways to accomplish what I did the hard way.....
 
Wow @dcbdbis, really sorry to hear about the broken machine at first, but glad you got it sorted out. Since you're reporting good results now that you've switched from HAL to devd, perhaps I will give this update a try now. (Thanks for being the "guinea pig"!)

Would you (or any of the more experienced readers) suggest that it might be good to switch everything over to devd first, then do the update? Or would that really matter?
 
Last edited by a moderator:
alias said:
Would you (or any of the more experienced readers) suggest that it might be good to switch everything over to devd first, then do the update? Or would that really matter?
Click to expand...

Please start a new thread, this one has strayed far from the original subject of pkg version results.
 
You must log in or register to reply here.
Back
Top