Bump PORTREVISION

In D16605#353032, @koobs wrote:

Except for this probably requiring a PORTREVISION bump since the package contents are changed, it appears fine, assuming *all* the lines being removed are relevant to that GCC_RUNTIME.

Though I can make a few assumptions (guesses), I'm not familiar enough with the port or that ex.script mechanism to know

Updated patch for devel/ipython

In D16508#351167, @rm wrote:

There are some ports except the jupyter that depend upon ipython and some of them may be python 2.x only, so need to check that too

In D16508#351170, @koobs wrote:

@farrokhi Can you rebase your changes after @rm's commit and update the diff here

Thanks @rm. Could you please then repocopy ipython to ipython5 so that we can apply this patch to ipython?
I am currently testing to make sure these two ports are not installing conflicting files and if they can be installed concurrently.

While we were working on this, @rm committed an update to devel/ipython. It seems he is maintaining 5.x series [2] (which still supports python 2.7) , while the new 6.x series [3] are not still in ports tree.
Now should we repocopy the devel/ipython to devel/ipython6 and turn this patch into a new port?

In D16508#350796, @mat wrote:

The only time you can remove concurrent is when a port supports only one version of Python, say, USES=python:2.7. In any other combination, here, for examples, packages for 3.4, 3.5, 3.6 and 3.7 can be built at the same time.

Restore concurrent flag

In D16378#349810, @dbn wrote:

FYI, commit messages require the full path to this review (your draft message [I assume] only includes the review number)

Remove unnecessary version check for FreeBSD < 10

Remove another unrelated patch that was accidentally slipped in

Changes in pfvar.h and removal of rwlock.h includes broke the build (noted by @kristof). This updated patch unbreaks the build.

In D15502#327153, @kristof wrote:

Looks good at first glance.
I like the move of the sys/rmlock.h include into pfvar.h, so the header becomes more self-contained (i.e. you don't need extra includes to make your include of pfvar.h work). I'm running test builds for that, because I thought it broke when I tried. Perhaps I messed something else up though.

For others and for context: Olivier has tested this change and saw a 65% increase in packets per second through pf. We really, really want this change.

In D11072#237288, @emaste wrote:

Be sure to send these upstream as well

Improve the logic when detecting when whether or not we should reverse byte order for ip_len and ip_off.

Use a less intrusive method to find out if we should include "pcap-int.h"