portmaster won't update ports

[protocelt]

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]

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

 

[fernandel]

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@]

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]

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]

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

 

[talsamon]

Same for me.

 

[protocelt]

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]

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]

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

 

[chrbr]

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]

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.