Not using the portlint command I go ahead and copied the package to my pfsense box and install it successfully.

So this is it.  Thank you all for your help.

Thanks - perfect answer. (Maybe add the info in the last 2 answers to dev package documentation?)

Thank you for reply…

I use 2.2.3 repo and the path /home/pfsense/tools/pfPorts/www/pecl-APC is exist, my make try result:

root@FBSD101X64:/home/pfsense/tools/pfPorts/www/pecl-APC # make
===>  License PHP301 accepted by the user
===>  Found saved configuration for pecl-APC-3.1.14_1
===>  pecl-APC-3.1.14_1 depends on file: /usr/local/sbin/pkg - found
===>  Fetching all distfiles required by pecl-APC-3.1.14_1 for building
===>  Extracting for pecl-APC-3.1.14_1
===>  SHA256 Checksum OK for PECL/APC-3.1.13.tgz.
===>  Patching for pecl-APC-3.1.14_1
===>  Applying extra patch /home/pfsense/tools/pfPorts/www/pecl-APC/files/extra-patch-fix-build-55
===>  Configuring for pecl-APC-3.1.14_1
===>  Building for pecl-APC-3.1.14_1
make[2]: cannot open Makefile.

make[2]: stopped in /home/pfsense/tools/pfPorts/www/pecl-APC/work/APC-3.1.13
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
Stop.
make[1]: stopped in /home/pfsense/tools/pfPorts/www/pecl-APC
*** Error code 1
Stop.
make: stopped in /home/pfsense/tools/pfPorts/www/pecl-APC

Next try with option MAKE_JOBS_UNSAFE=yes
root@FBSD101X64:/home/pfsense/tools/pfPorts/www/pecl-APC # make MAKE_JOBS_UNSAFE=yes install
===>  Building for pecl-APC-3.1.14_1
make[2]: cannot open Makefile.

make[2]: stopped in /home/pfsense/tools/pfPorts/www/pecl-APC/work/APC-3.1.13
*** Error code 1
Stop.
make[1]: stopped in /home/pfsense/tools/pfPorts/www/pecl-APC
*** Error code 1
Stop.
make: stopped in /home/pfsense/tools/pfPorts/www/pecl-APC

root@FBSD101X64:/home/pfsense/tools/pfPorts/devel/php55-pfSense-module # make

mkdir -p /home/pfsense/tools/pfPorts/devel/php55-pfSense-module/work/pfSense-0.1
cp -r files/* /home/pfsense/tools/pfPorts/devel/php55-pfSense-module/work/pfSense-0.1
===>  Patching for php55-pfSense-module-0.1_2
===>  Configuring for php55-pfSense-module-0.1_2
===>  Building for php55-pfSense-module-0.1_2
make[1]: cannot open Makefile.

make[1]: stopped in /home/pfsense/tools/pfPorts/devel/php55-pfSense-module/work/pfSense-0.1
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
Stop.
make: stopped in /home/pfsense/tools/pfPorts/devel/php55-pfSense-module
Next try with option MAKE_JOBS_UNSAFE=yes

root@FBSD101X64:/home/pfsense/tools/pfPorts/devel/php55-pfSense-module # make MAKE_JOBS_UNSAFE=yes
===>  Building for php55-pfSense-module-0.1_2
make[1]: cannot open Makefile.

make[1]: stopped in /home/pfsense/tools/pfPorts/devel/php55-pfSense-module/work/pfSense-0.1
*** Error code 1
Stop.
make: stopped in /home/pfsense/tools/pfPorts/devel/php55-pfSense-module
root@FBSD101X64:/home/pfsense/tools/pfPorts/devel/php55-pfSense-module #

Can you help me please?!

Not currently. The update check is only performed when your browser loads the page. To do so on a regular basis for notifications would place a much, much higher load on our servers for very minimal benefits. Unless a package has a security problem, is misbehaving, or you need a new feature, most of the time you don't need to upgrade it immediately.

Yep, follow those rules in the style guide, make the edits on GitHub (or in a local Git repo that you make on your system) in a separate branch and do a pull request to the master branch of the pfSense repo(s). The ESF guys will back-port to old branches if appropriate.

Even without using ALTQ, we could just use limiters with fq_codel for a "set it and forget it" AQM config with fair queuing and AQM (sort of like sqmscripts for OpenWRT/LEDE). Sure, this wouldn't be for everyone, but I can see it as being quite valuable for many folks.

The login beep isn't an action that happens on purpose, it's a byproduct of the way the login is logged.

It would be possible to make an option for this but it would likely turn out to be annoying for most. You may as well hand edit a call to beep into rc.newwanip to beep when it's called.

@kpa:

@stilez:

@kpa:

2. Forget the idea of localizing those IDs, it's not going to happen.

That might be a misunderstanding. It's the plain-text descriptions, not the sysctls themselves, that I referred to.

I started to wonder if that's what you meant  :)

It's that the config file "sysctls" section currently looks like this:

<tunable>vfs.read_max</tunable> <value>default</value>

but the meaning of vfs.read_max should be moved out of the config file and read as needed from the system itself, or stored as strings/gettext() in the router code.

Not usually.

You can run that script and if the diff looks sane (just your own update), submit that as a PR as well, perhaps the same PR as the other change, but it's something we usually run before each release anyhow to make sure things are caught up.

Sometimes that file gets inadvertently hand-edited and the diffs make less sense so they need manual review, but at the moment things are quite good there. Running the script produced only a one-line diff.

Thank you.

Just for the record to others.
The sign.sh is a script describe in pkg repo manual from freebsd.
The line in builder can be replaced to this local script.

@cmb:

Having all the history does come in handy on occasion, and doesn't have any negative impacts for me.

That poor SSD getting hammered every time checking out a branch, for the sake of occasional ancient history.

As a diagnostic learning tool, take a look at the comprehensive output of status.php.  (I don't think it's a gui menu choice, just go to https://192.168.1.1/status.php, for example).

Find an area you want to learn about, then read through /usr/local/www/status.php and see how that output was generated.  A far cry from what you are asking for, but still a good place to learn

I have managed to successfully build and run the above simple example as well as the pfctl. For those interested, here are the steps I took:

a) downloaded source from https://github.com/pfsense/FreeBSD-src
b) make buildworld
c) compiled the above test with```
clang -I/usr/obj/usr/home/ethicius/develop/FreeBSD-src/tmp/usr/include -o sample sample.c

~~I still don't quite understand what the underlying problem is. Could it be that the _IOWR macro constructs a different number? I might have to disassemble those two files to find the culprit…~~ It's simply just a different API. pfSense has modified sys/pfvar.h and related files.