# portmaster won't update ports



## drhowarddrfine (Oct 5, 2015)

Woke up this morning, turned my workstation on that was just updated to version 10.2-RELEASE-p5 yesterday, did a `portsnap` to get updates but, when I tried to update this list of ports, ports-mgmt/portmaster only re-installed them instead. What happened here?


```
gdk-pixbuf2-2.32.1
php56-5.6.14
php56-hash-5.6.14
php56-openssl-5.6.14
php56-phar-5.6.14
automake-1.15_1
...
```


----------



## jrm@ (Oct 5, 2015)

portsnap doesn't seem to reflect these recent port updates yet, at least for me. 


```
jrm@gly ~ % pkg version | egrep "^gdk-pixbuf"
gdk-pixbuf2-2.31.7                 =

jrm@gly ~ % sudo portsnap fetch update; pkg version -Ivl'<'
Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found.
Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done.
Latest snapshot on server matches what we already have.
No updates needed.
Ports tree is already up to date.
```


----------



## jrm@ (Oct 5, 2015)

Updating the ports by svn does grab the updates, so it seems portsnap is lagging behind.  I'm not sure if this is normal lag or not.

Ports tree updated with portsnap

```
jrm@gly ~ % grep PORTVERSION /usr/ports/graphics/gdk-pixbuf2/Makefile 
PORTVERSION=    2.31.7
```

Ports tree updated with svn

```
jrm@storage2 ~ % grep PORTVERSION /usr/local/poudriere/ports/default/graphics/gdk-pixbuf2/Makefile 
PORTVERSION=    2.32.1
```


----------



## SirDice (Oct 5, 2015)

Not sure if it's relevant but 10.2 now uses the quarterly packages by default. This may also be the case for portsnap(8).


----------



## drhowarddrfine (Oct 5, 2015)

And just as quickly, the problem has gone away when re-doing `portsnap`.


----------



## drhowarddrfine (Oct 30, 2015)

So it happened again this morning. I tried to update nghttp2 and vim only to have both re-installed instead.

Someone else had this same issue here.


----------



## talsamon (Oct 30, 2015)

Same - on all systems.


----------



## jrm@ (Oct 30, 2015)

Does the ports tree you are building from have the newer version?  Can you confirm by doing something like `grep PORTVERSION /usr/ports/www/nghttp2/Makefile`?  Maybe your are using an INDEX to tell you a new version is available, but the INDEX is somehow slightly ahead of your tree.


----------



## talsamon (Oct 30, 2015)

How can the INDEX be ahead?


----------



## jrm@ (Oct 30, 2015)

For example, if you ran `portsnap -I update`.

Anyway, without confirmation of what you are running to update the ports tree and what your ports tree looks like, it's hard to do anything other than guess.


----------



## talsamon (Oct 30, 2015)

`portsnap fetch update`. I think I never run `portsnap -I update`. (I know webp ist updated from 0.4.3 to 0.44 and vim from 7.4.898 to 7.4.900). But portsnap shows uptodate. (On one system I have svn, that works correct). I have 4 different FreeBSD systems, and only the one with svn updates.


----------



## jrm@ (Oct 30, 2015)

But what did your ports tree look like when you tried to run ports-mgmt/portmaster after the first `portsnap fetch update`?  If you didn't rerun `portsnap fetch update`, you can tell us with, e.g.,  `grep PORTVERSION /usr/ports/editors/vim/Makefile`.  If your ports tree still has (had) the older version, that will tell us something.

Another question: How did you determine a new version was available?  For example, did you run `pkg version -Ivl'<'`?  The I flag might also tell us something.


----------



## talsamon (Oct 30, 2015)

`pkg version -Ivl'<'`
vim-7.4.898  <  needs updating (index has 7.4.900)  (I have edit it, before it was a paste-error).

```
grep PORTVERSION /usr/ports/editors//vim/Makefile
PORTVERSION=   7.4.898
VIM_VER=   ${PORTNAME}${PORTVERSION:R:S|.||g}
CPE_VERSION=   ${PORTVERSION:R}
```


----------



## jrm@ (Oct 30, 2015)

NOTE: This post is no longer relevant since you corrected the previous post.

So `pkg version` is saying you have nothing new to update, and you ran `portmaster`, specifying a port.  From portmaster(8): 





> By default portmaster updates the port you specify on the command line.  This will occur whether there is a new version for it or not.


  This is all expected behaviour.  The only thing of note is that `portsnap` is lagging a bit behind.


----------



## talsamon (Oct 30, 2015)

Sorry I have edit the last post `pkg version` has output (was a pasteerror).


----------



## jrm@ (Oct 30, 2015)

So now we're back to the other theory that the INDEX is indeed ahead of your tree.  I think it says it all in the output.  Your INDEX refers to 7.4.900, but your tree still has 7.4.898.


----------



## talsamon (Oct 30, 2015)

> Your INDEX refers to 7.4.900


Yes, maybe - but portsnap don't fetch the update. As you see vim has already 7.4.898.


----------



## drhowarddrfine (Oct 30, 2015)

Same here.


----------



## jrm@ (Oct 30, 2015)

Right.  We've come to the same conclusion.  Why?  I don't know, but considering there are at least two of you seeing the problem, I'd say it's something worth reporting.


----------



## talsamon (Oct 30, 2015)

Ok 204158.
Was on the wrong place now PR 204160.


----------



## chrbr (Oct 30, 2015)

On my system 7.4.898 is reported as up to date as well. I have no problem with beeing some time behind head. For myself it is just interesting to know how things work.
According to https://svnweb.freebsd.org/ports/head/editors/vim/?view=log
the step from 7.4.898 to 7.4.900 is just a few hours ago. I am not sure if everything can be synchronized by 100%. Is it possible that the index file comes from one source and portsnap gets its data from a different source?


----------



## fernandel (Oct 30, 2015)

I have the same problem:
	
	



```
portsnap fetch update
Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found.
Fetching snapshot tag from your-org.portsnap.freebsd.org... done.
Latest snapshot on server matches what we already have.
No updates needed.
Ports tree is already up to date.
```


----------



## talsamon (Oct 31, 2015)

If I comment out the sanity check of the date in /usr/sbin/portsnap, I get:

```
Updating from Fri Oct 30 09:04:12 UTC 2015 to Thu Oct 29 03:18:28 UTC 2015.
```


----------



## protocelt (Oct 31, 2015)

My first guess would be the portsnap(8) mirrors are probably just slow to sync. It'll probably back to normal by tomorrow if not sooner I would think.


----------



## jrm@ (Oct 31, 2015)

protocelt, that seems likely, but their INDEX files shouldn't be ahead like that.


----------



## protocelt (Oct 31, 2015)

jrm said:


> protocelt, that seems likely, but their INDEX files shouldn't be ahead like that.



Hmm, `grep PORTVERSION /usr/ports/editors/vim/Makefile` returns the following on my machine:

```
PORTVERSION=    7.4.900
VIM_VER=    ${PORTNAME}${PORTVERSION:R:S|.||g}
CPE_VERSION=    ${PORTVERSION:R}
```
This is correct as the editors/vim port was updated to version 7.4.900 in the ports tree earlier this morning. I'm not sure it's an INDEX issue though can't rule it out either. talsamon filed a PR so hopefully this will get solved in short order.


----------



## talsamon (Oct 31, 2015)

If your ports-tree is ok, tell us which server you use (or you use svn and have overlooked this)


----------



## fernandel (Oct 31, 2015)

I am using portsnap all the time and I got:

```
grep PORTVERSION /usr/ports/editors/vim/Makefile
PORTVERSION=   7.4.898
VIM_VER=   ${PORTNAME}${PORTVERSION:R:S|.||g}
CPE_VERSION=   ${PORTVERSION:R}
```


----------



## jrm@ (Oct 31, 2015)

protocelt, does your entry in /usr/ports/INDEX-10 match?

On my servers, where I use portsnap, nothing is out of sync, but I still see 7.4.898 in both tree and INDEX, so while things are slow, they are generally OK.  Where I use svn to update the tree I see the newer version in the tree (I don't have any INDEX files there), so everything is OK.  We have clear evidence from talsamon that he has a mismatch.  The question is, how did talsamon get an INDEX file ahead of the tree?  talsamon, are you sure you didn't use anything other than portsnap to get a new INDEX?  Nothing with svn?

ADDED: It's not so useful if anyone posts just the version in his tree, but it would be useful if we could get a second report of a mismatch.  drhowarddrfine, you said you have the old version in the tree.  Can you let us know what version you have in your /usr/ports/INDEX-10?


----------



## drhowarddrfine (Oct 31, 2015)

jrm The vim version there is 7.4.898.

On another note, I did a portsnap just now. On my workstation, I have new updates every day for something. This morning, there is nothing new there other than vim and webp, which were the problems I had before I started this thread back up.

EDIT: On my server, I just did portsnap and it said my ports tree is up to date. I don't think that has ever happened before.


----------



## drhowarddrfine (Oct 31, 2015)

As of this minute, I did a portsnap and was able to update all my ports.


----------



## talsamon (Oct 31, 2015)

Same for me.


----------



## protocelt (Oct 31, 2015)

jrm said:


> protocelt, does your entry in /usr/ports/INDEX-10 match?
> 
> On my servers, where I use portsnap, nothing is out of sync, but I still see 7.4.898 in both tree and INDEX, so while things are slow, they are generally OK.  Where I use svn to update the tree I see the newer version in the tree (I don't have any INDEX files there), so everything is OK.  We have clear evidence from talsamon that he has a mismatch.  The question is, how did talsamon get an INDEX file ahead of the tree?  talsamon, are you sure you didn't use anything other than portsnap to get a new INDEX?  Nothing with svn?
> 
> ADDED: It's not so useful if anyone posts just the version in his tree, but it would be useful if we could get a second report of a mismatch.  drhowarddrfine, you said you have the old version in the tree.  Can you let us know what version you have in your /usr/ports/INDEX-10?


My apologies, I didn't realize I was on 11-CURRENT in which I use svn(1). I mainly use CURRENT but keep and update the 10 branch as well to keep up with what is going on.

So it looks like the portsnap(8) mirrors are finally updated. As far as the INDEX file being ahead, I have a suspicion that might be portmaster(8)'s fault. If I remember correctly, it fetches the INDEX file remotely by default and may not always match the local file. That could be an incorrect assumption as well. I didn't check.


----------



## talsamon (Oct 31, 2015)

```
portmaster
--no-index-fetch
skip fetching the INDEX file
--index
use INDEX-[7-9] exclusively to check if a port is up to date
--index-first
use the INDEX for status, but double-check with the port
```
and

```
portsnap
-I For the update command, update INDEX files, but not the rest
of the ports tree.
```

Why should portmaster fetch the INDEX, if portsnap can do this? (And I think this would make no sense). And if I understand the code right in the portsnap script, portsnap fetches it.


----------



## talsamon (Oct 31, 2015)

Oh, seems I am wrong, it seems both are fetching the index, maybe this is the crux?


----------



## chrbr (Oct 31, 2015)

I just updated net/rsync just for curiosity. Any time stamp in /usr/ports/ has been updated. Therefore portmaster might not update the index. Running `portsnap fetch update` changed the time stamp of the index files and some port directories.


----------



## protocelt (Oct 31, 2015)

I think this is really just a case of the portsnap(1) server(s) being a bit behind. The INDEX file portmaster(8) fetched and parsed while checking for updates was newer than what the portsnap(1) server(s) had available, hence the discrepancy and cause of the issue.

Personally, I think using svnlite(1) is a better choice than portsnap(1) for people who want to compile their ports from source.


----------

