# Portsnap skipping many ports on fetch



## gladiola (Oct 9, 2015)

I just ran `portsnap fetch` and noticed that  only 1207 of 3748 new ports were fetched.  I did not apply them yet.

When I look over /usr/ports/UPDATING, I don't really see anything that gets my attention.  I take it that seeing these "skipping" messages means just what they say:  that they were skipped.  Yet, a more detailed explanation for why they were skipped is not listed.  

The output also does not tell me in plain language which ones were skipped, so I have little idea of what didn't work right.

During the fetch, the std out showed text like this:


```
3e6220ccd9d93552a12b702b56b490afc7db2bcc7ceae80763ce8d98cc4d (3540 of  3748 p  
Skipping 731d1e65ba139aa128355a61c289cb9bacd81e4dcc6b07a1452f015d6e12be69-45b3
```

What's the best way of determining why this skipping happened?  I would like to know if this is an indication of a problem with my system that needs troubleshooting.


----------



## free-and-bsd (Jan 16, 2016)

Yea, I'd like to know that too. Giving off this much of output on the screen must mean something?


----------



## Chris_H (Jan 21, 2016)

I don't use portsnap(8), so I'm really going by it's intended function, based on it's man(1) page ( portsnap(8) ). But isn't it really only interested in updating/replacing files based on their having been modified/changed? Meaning (in your case) it's _only_ going to get the files it _actually needs_? So in other words; why would it download _everything_ if you only need _some_ files? 

HTH

--Chris


----------



## mb2015 (Mar 29, 2016)

Normally, portsnap(8) does not produce this output. I never saw it happen on my system until today. It is actually happening during the "Applying patches" stage of the fetch; i.e. it is not skipping the downloading, just the application of some patches to the compressed ports tree snapshot.

There's some discussion in another forum which speculates that the skipped patches are a transient error that only happens when the portsnap server you're fetching from is in the middle of a sync. It was observed that the problem did not recur when trying the fetch later.

I noticed that immediately retrying `portsnap fetch update` tells me that my tree is already up-to-date, an assumption apparently based on tags, not by examining the actual content of the tree. So if those patches shouldn't have been skipped (I have no way of knowing for sure), it's possible that now my tree is corrupt. I don't have time to research the portsnap ecosystem to figure out whether there's really a problem, so I decided not to risk it. I obliterated my entire ports tree and started from scratch:

`rm -fr /var/db/portsnap /usr/ports`
`mkdir /var/db/portsnap /usr/ports`
`portsnap fetch extract`


----------



## gladiola (Apr 1, 2016)

I never had any serious consequences of this, I just thought it was unusual.  I think Chris is probably right.


----------



## mb2015 (Apr 10, 2016)

Well, Chris assumed portsnap was saying it was skipping the downloading of unneeded patches. But that is not what is happening. portsnap thought it needed a large set of patches, so it did download them...but then for some reason decided not to apply them to your local snapshot. We don't know any more than that.


----------



## mb2015 (Nov 21, 2016)

Followup: Thread 58029 and PR 213418

(short answer: your-org.portsnap.freebsd.org is having problems; workaround is to use another server)


----------



## drhowarddrfine (Nov 21, 2016)

I wonder how many years we can drag this thread out.


----------

