Poudriere for port update try

Not long ago I discovered that the enlightenment desktop does in fact have a considerably more current version available.  I have been using FVWM, I did use enlightenment in the distant past and some years ago, but had to quit due to some flakiness.  I believe it is still BSD licensed and as such this gives it a bit more prestige for me.  I have been using poudriere for a while now and have even corrected some flaws in a number of ports through its built-in testing scrutiny leading to modifying various things (such as, most often, the Makefile) for them directly in the poudriere jail path for the port.  If I were to attempt to get the newer enlightenment to build for either an updated or fresh port, I should attempt this in a clean and unmodified jail.  Poudriere provides purpose-built jails and includes the tools needed to be much more certain that any port would succeed.

My first step, creating a new poudriere jail, I nearly committed but stopped very shortly after since I am sure it would have created, once more, a newer system than the host.

poudriere jail -c -v stable/12 -a amd64 -j 12amd64_porting -m svn+https

I looked at the section of the manpage (man 8 poudriere-jail) describing many ways I could create the install, but decided that perhaps I can simply do a recursive copy of one jail directory which I already have, to a new name in the jail path.  This is likely an over-simplification of what truly needs to be done, now that I take a few moments to think about it.  The trouble is, these options below hint at what I'd like to do but are not explicit enough.  I tried the crazy hackish method because I am not sure that using the path to the jail I already have would result in what I desire.  I will have to try it anyway, and was thinking I'd use the url method until I looked closer at the options.  Look at the src=PATH with -b option, this should let me use the host src directory which is real interesting.

SUBCOMMANDS
     -c           Creates a jail.  See CAVEATS for restrictions on the names
                  of jails.

     -d           Deletes a jail.

                  If the stdin is a TTY then the command is going to ask for
                  confirmation, which defaults to “N” (for “no”).  Othwerwise,
                  the specified jail is deleted without confirmation.

     -i           Show information about a jail.  See also
                  poudriere-status(8).

     -l           List all poudriere jails.

     -n           When combined with -l, only display jail name.

     -s           Starts a jail.

     -k           Kills a jail (stops it).

     -r name      Rename a jail to name.

     -u           Update a jail.

OPTIONS
     Except for -l, all of the subcommands require the -j option (see below).

     -b           Build the source provided with the -m src=PATH option.

     -J number    The number of make jobs will run in parallel for buildworld.
                  Defaults to the number of CPUs reported by:  sysctl hw.ncpu.

     -q           Remove the header when -l is the specified mandatory option.
                  Otherwise, it has no effect.

     -j name      Specifies the name of the jail.

     -v version   Specifies which version of FreeBSD to use in the jail.  If
                  you are using method ftp then the version should in the form
                  of: 9.0-RELEASE.  If you are using method of svn then the
                  version should be in the form of git or svn branches:
                  stable/9 or head for CURRENT.  Other methods only use the
                  value for display.

     -a architecture
                  Specifies which architecture of FreeBSD to use in the jail.
                  (Default: same as host)

     -m method    Specifies which method to use to create the jail.  (default:
                  http)

                  Pre-built distribution options:

                  allbsd         Use http://www.allbsd.org.

                  ftp http       Fetch from configured FREEBSD_HOST variable
                                 from poudriere.conf.

                  ftp-archive    Fetch from http://ftp-archive.freebsd.org.

                  null           This option can be used to import an existing
                                 directory that already contains an installed
                                 system.  The path must be specified with -M
                                 path.  It is expected that this directory be
                                 installed to with the following:

                                       /usr/src# make installworld DESTDIR=PATH DB_FROM_SRC=1
                                       /usr/src# make distrib-dirs DESTDIR=PATH DB_FROM_SRC=1
                                       /usr/src# make distribution DESTDIR=PATH DB_FROM_SRC=1

                                 It will not be copied at the time of running
                                 jail.  Deleting the jail will attempt to
                                 revert any files changed by poudriere.

                  src=PATH       Install from the given src directory at PATH.
                                 This directory will not be built from.  It is
                                 expected that it is already built and maps to
                                 a corresponding /usr/obj directory.

                  tar=PATH       Install from the tarball at the given PATH.
                                 Note that this method requires the tarball
                                 contains the /usr/src files as well if you
                                 plan to build any port containing modules.

                  url=PATH       Fetch from given PATH.  Any URL supported by
                                 fetch(1) can be used.  For example:
                                       url=file:///mirror/10.0

                  Build from source options:

                  git git+http git+https git+ssh
                                 Will use git, the -v flag to set the branch
                                 name and the GIT_BASEURL variable in
                                 poudriere.conf.

                  src=PATH       With the -b flag, the src tree will be copied
                                 into the jail and built.

                  svn svn+file svn+http svn+https
                                 Will use SVN and the SVN_HOST variable in
                                 poudriere.conf.

So that means that after I have used make clean cleanworld in /usr/src to be sure it is not going to have any remnants, I will invoke the following:

poudriere jail -c -v stable/12 -a amd64 -j 12amd64_porting -b -m src=/usr/src

The manpage mentions that the -v part would then only be for display due to obtaining it another way.  Of course this is all possible because I plan to build and use ports from poudriere on the same system.  I blindly used the -a amd64 but this could be left off as the default is to match the host.  This method, of using the host source for the jail will also avoid the issue of the jail ever being more current than the host at creation.  This will be especially helpful if I can also use the -u update with the -m method specifying as I do above, to use the host source sometime after I update the host itself.  The manpage suggests and implies this, but I won't know for certain until the day I test it.  The copying, whether by my hackish attempt which I aborted and cleaned up, or by poudriere itself with the above command, is rather slow but eventually builds.

root@ichigo:~ # poudriere jail -c -v stable/12 -a amd64 -j 12amd64_porting -b -m src=/usr/src
[00:00:00] Creating 12amd64_porting fs at /usr/local/poudriere/jails/12amd64_porting... done
[00:00:00] Copying /usr/src to /usr/local/poudriere/jails/12amd64_porting/usr/src... done
[00:09:16] Starting make buildworld with 4 jobs
[Creating objdir /usr/obj/usr/local/poudriere/jails/12amd64_porting/usr/src/amd64.amd64...]
--- buildworld ---
make[1]: "/usr/local/poudriere/jails/12amd64_porting/usr/src/Makefile.inc1" line 342: SYSTEM_COMPILER: Determined that CC=/usr/local/bin/ccache cc matches the source tree.  Not bootstrapping a cross-compiler.
make[1]: "/usr/local/poudriere/jails/12amd64_porting/usr/src/Makefile.inc1" line 347: SYSTEM_LINKER: Determined that LD=ld matches the source tree.  Not bootstrapping a cross-linker.
--- buildworld_prologue ---
--------------------------------------------------------------
>>> World build started on Wed Oct 28 02:19:26 CDT 2020

As you might see, since my poudriere.conf has settings for only 4 poudriere port building jobs, there are only 4 jobs for the world build.  This is something to make note about because I actually have a 6-core cpu that would speed this up considerably if I temporarily set that at 6 jobs.  The other option is specifically mentioned by the manpage, to set this by way of -J 6 which controls the number of jobs for buildworld, while it says the default is the number of cores, this is only default if settings in your poudriere.conf do not override it like mine does.  There is a lot of output as anyone who has watched much of a world or kernel build would know.  The end of the preparation of the jail looks like this:

--- installconfig_subdir_usr.sbin/wpa/wpa_supplicant ---
===> usr.sbin/wpa/wpa_supplicant (installconfig)
--- installconfig_subdir_usr.sbin/wpa/wpa_cli ---
===> usr.sbin/wpa/wpa_cli (installconfig)
--- installconfig_subdir_usr.sbin/wpa/wpa_passphrase ---
===> usr.sbin/wpa/wpa_passphrase (installconfig)
--- installconfig_subdir_usr.sbin/wpa/hostapd ---
===> usr.sbin/wpa/hostapd (installconfig)
--- installconfig_subdir_usr.sbin/wpa/hostapd_cli ---
===> usr.sbin/wpa/hostapd_cli (installconfig)
--- installconfig_subdir_usr.sbin/wpa/ndis_events ---
===> usr.sbin/wpa/ndis_events (installconfig)
awk: can't open file /sys/param.h
 source line number 1
[03:06:26] Recording filesystem state for clean... done
[03:06:27] Jail 12amd64_porting 12.2-STABLE 1202502 amd64 is ready to be used
root@ichigo:~ #

So it appears that I can begin my attempt to get the more current version of enlightenment desktop testbuilt and eventually finish build, possibly even install it on my pc to play with, although I think I may copy the new directory and Makefile and distinfo files and everything to my usual poudriere build jail.  It turns out that I will have more than enough time to accomplish this.  If I were at all an active coder I have nearly enough time to create something new, including heavily modifying any elightenment thing or making my own addon.

Did you notice the flaw in my plan?  I never said anything about a completely separate ports tree, so this might be something I would need to create.  I should also look into whether I can somehow temporarily include my added ports tree directories (turns out I may need to update efl as well) using some special poudriere option.  There are a number of things which are controlled by additional config files for poudriere which I have not looked at yet.

CUSTOMISATION
     For bulk building, you can customize binary packages produced by
     poudriere by changing build options port by port, and you can also
     specify building directives in a make.conf file.

   Custom build options
     Before building a package, poudriere can mount a directory containing
     option files if available.  poudriere will check for any of these
     directories in this order:

           /usr/local/etc/poudriere.d/<jailname>-<tree>-<setname>-options
           /usr/local/etc/poudriere.d/<jailname>-<setname>-options
           /usr/local/etc/poudriere.d/<jailname>-<tree>-options
           /usr/local/etc/poudriere.d/<tree>-<setname>-options
           /usr/local/etc/poudriere.d/<setname>-options
           /usr/local/etc/poudriere.d/<tree>-options
           /usr/local/etc/poudriere.d/<jailname>-options
           /usr/local/etc/poudriere.d/options

     If a directory with this name exists, it is null-mounted into the
     /var/db/ports/ directory of the jail, thus allowing to build package with
     custom OPTIONS.

     The options subcommand can be used to easily configure options in the
     correct directory.

     This directory has the usual layout for options: it contains one
     directory per port (the name of the port) containing an 'options' file
     with lines similar to:

           WITH_FOO=true
           WITHOUT_BAR=true

     As a starter, you may want to copy an existing /var/db/ports/ to
     /usr/local/etc/poudriere.d/options.

   Blacklist ports
     You can also specify a blacklist which will disallow the lists port
     origins from building on the matched jail.  Any of the following are
     allowed and will all be used in the order shown:

           /usr/local/etc/poudriere.d/blacklist
           /usr/local/etc/poudriere.d/<setname>-blacklist
           /usr/local/etc/poudriere.d/<tree>-blacklist
           /usr/local/etc/poudriere.d/<jailname>-blacklist
           /usr/local/etc/poudriere.d/<tree>-<setname>-blacklist
           /usr/local/etc/poudriere.d/<jailname>-<tree>-blacklist
           /usr/local/etc/poudriere.d/<jailname>-<setname>-blacklist
           /usr/local/etc/poudriere.d/<jailname>-<tree>-<setname>-blacklist

     If QEMU is being used then a special qemu blacklist is also loaded.
           /usr/local/etc/poudriere.d/qemu-blacklist

   Create optional poudriere.conf
     You can also specify an optional poudriere.conf that is pulled in
     depending on the build.  Any of the following are allowed and will all be
     used in the order shown:

           /usr/local/etc/poudriere.d/poudriere.conf
           /usr/local/etc/poudriere.d/<setname>-poudriere.conf
           /usr/local/etc/poudriere.d/<tree>-poudriere.conf
           /usr/local/etc/poudriere.d/<jailname>-poudriere.conf
           /usr/local/etc/poudriere.d/<tree>-<setname>-poudriere.conf
           /usr/local/etc/poudriere.d/<jailname>-<tree>-poudriere.conf
           /usr/local/etc/poudriere.d/<jailname>-<setname>-poudriere.conf
           /usr/local/etc/poudriere.d/<jailname>-<tree>-<setname>-poudriere.conf

   Create optional make.conf
     You can also specify a global make.conf which will be used for all the
     jails.  Any of the following are allowed and will all be used in the
     order shown:

           /usr/local/etc/poudriere.d/make.conf
           /usr/local/etc/poudriere.d/<setname>-make.conf
           /usr/local/etc/poudriere.d/<tree>-make.conf
           /usr/local/etc/poudriere.d/<jailname>-make.conf
           /usr/local/etc/poudriere.d/<tree>-<setname>-make.conf
           /usr/local/etc/poudriere.d/<jailname>-<tree>-make.conf
           /usr/local/etc/poudriere.d/<jailname>-<setname>-make.conf
           /usr/local/etc/poudriere.d/<jailname>-<tree>-<setname>-make.conf
           /usr/local/etc/poudriere.d/hooks/plugins/<plugin>/make.conf

   Create optional src.conf
     You can also specify a global src.conf which will be used for building
     jails with the jail -c subcommand.  Any of the following are allowed and
     will all be used in the order shown:

           /usr/local/etc/poudriere.d/src.conf
           /usr/local/etc/poudriere.d/<setname>-src.conf
           /usr/local/etc/poudriere.d/<jailname>-src.conf

   Create optional src-env.conf
     You can also specify a global src-env.conf which will be used for
     building jails with the jail -c subcommand.  Any of the following are
     allowed and will all be used in the order shown:

           /usr/local/etc/poudriere.d/src-env.conf
           /usr/local/etc/poudriere.d/<setname>-src-env.conf
           /usr/local/etc/poudriere.d/<jailname>-src-env.conf

   Hooks
     Hook scripts may be loaded in any of the following paths:

           /usr/local/etc/poudriere.d/hooks/<hook>.sh
           /usr/local/etc/poudriere.d/hooks/plugins/<plugin>/<hook>.sh

Of the above customization options listed, I will certainly need to avoid my custom make.conf, simply to be certain that defaults are used in the build and not to cause things to be more convoluted.  I am using the same /var/ports/db by way of a symbolic link, so that would need to be set differently in another poudriere.conf file.  Since I am making things complicated now, it may be a good idea to look over how I setup poudriere for my local ports building and see how I would replace the symbolic links with less hackish methods (defined by specific poudriere config files).  The other options available that are mentioned above, I don't think I will need, such as blacklist, src.conf, src-env.conf, or hooks.  The hooks option is intriguing since it sounds like a method to extend poudriere with custom scripts, though at the moment I am unsure what those could be, what I would need or might someday design, but glad the option exists.

Hmm. It appears that enlightenment is fairly up-to-date and efl too, probably.  I may have to be sure to install them all properly and test a bit to see if it still has the same bugs or if i somehow mixed multiple versions and that caused my troubles.  This means that I will probably not be working on enlightenment as I had first intended but might need to dig up some other port to work at getting to function properly on FreeBSD, maybe a game?  I tried to get devel/efl built, and x11-wm/enlightenment built, but it seems that although they are technically more up-to-date, they are failing builds.  I will be investigating them afterall, and have begun with efl which does need an update beyond what is in ports.

The attempt fails unexpectedly with configure, though most things leading up to that step appear to succeed.  I used the command below on my usual jail as such testing would clean up most things anyway.  My only modification to the efl Makefile so far is to adjust the version number, and comment out the 'broken' flag.  The commandline options I added are for verbose and not to kill the process at a failure, so between the two I should find all failures and have enough detail to figure it out.

poudriere testport -v -k -o devel/efl -j 12amd64

Unfortunately, even with all of the detail, it doesn't seem to point at anything obvious, each dependency is sought, built as needed, satisfied, and it continues to the next.  The next step after all of the various dependencies are verified, is for efl to use its build method which looks to be meson.  I accidentally killed the terminal which had the poudriere output, so even if there were other things to add, or even look at more closely, those are in /dev/null.  I have re-started the same poudriere testport for devel/efl but added an option to keep the work directory after it completes.  This may also contain other logs which I did not yet find.  The tail of the output mentions the meson build log and the error which caused the failure.

Run-time dependency libavif found: NO (tried pkgconfig)

src/lib/evas/meson.build:13:0: ERROR: Dependency "libavif" not found, tried pkgconfig

A full log can be found at /wrkdirs/usr/ports/devel/efl/work/efl-1.25.1/_build/meson-logs/meson-log.txt
===>  Script "configure" failed unexpectedly.

I am not sure what it means when it says "tried pkgconfig" with regard to FreeBSD, perhaps it is a Linux thing or maybe it used pkg to check whether that port was installed.  Either way, it looks like I will need to scrutinize the devel/efl Makefile to see whether libavif is missing or whether adding it as a runtime dependency will solve this issue.  As for the work directory saving, the option I added:

     -w           Save WRKDIR on build failure.  The WRKDIR will be tarred up
                  into ${POUDRIERE_DATA}/wrkdirs.

The makefile for devel/efl did not include  "libavif.so:graphics/libavif" in its Run-time dependencies, so I added it.  This is very strange as other times I used poudriere testport it successfully detected missing dependencies, it listed those that were detected as necessary, it checked whether dependencies were set properly.  I am not sure if I possibly missed some sort of option or if poudriere changed or if perhaps this specific port does things just a bit oddly due to the meson build system.  Regardless, the error message fairly clearly indicated what I needed to do and have done now, so I need to wait for results to see if that solved the build failure.  After that attempt, the same error was reported so maybe the dependency line needs to be with the libraries.  I doubt that moving it will solve the problem for the simple fact that graphics/libavif was the first thing built due to it being a dependency in the FreeBSD port Makefile and yet the error, failure remained.  I was wrong, moving the dependency to the libraries solved the error above but only until the build failed with a new error:

ninja: build stopped: subcommand failed.
===> 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 /usr/ports/devel/efl
[00:15:33] Saved devel/efl | efl-1.25.1 wrkdir to: /usr/local/poudriere/data/wrkdirs/12amd64-default/default/efl-1.25.1.tbz
build of devel/efl | efl-1.25.1 ended at Wed Nov 25 07:06:56 CST 2020
build time: 00:17:34
!!! build failure encountered !!!
[00:18:27] Error: Build failed in phase: build
[00:18:27] Cleaning up
12amd64-default: removed
12amd64-default-n: removed
[00:18:27] Unmounting file systems

My next step is to see if any configuration options for devel/efl relate or cause the error to manifest, or if possibly newer versions of any of the dependencies would solve it.  This is the sort of work that occurs with porting anything, although it tends to be from scratch and not begun from the prior version.  Another possible area to investigate is whether any patches might have caused any unforseen issues.  I can test whether permitting it to fail sooner might help identify an earlier error which leads to the last one.  I think this is what I will do first, then check versions of dependencies, and finally look at the configuration.  Progress can be slow but attacking it slowly also makes succeeding a bit more likely, so work step by step and keep notes.

I see the errors below which seem to be an API issue possibly due to the wrong version or some other flaw I likely cannot fix myself.

/wrkdirs/usr/ports/devel/efl/work/efl-1.25.1/src/modules/evas/image_loaders/avif/evas_image_load_avif.c:68:36: error: too many arguments to function call, expected single argument 'decoder', have 2 arguments
   res = avifDecoderParse(decoder, &raw);
         ~~~~~~~~~~~~~~~~          ^~~~
/usr/local/include/avif/avif.h:722:1: note: 'avifDecoderParse' declared here
avifResult avifDecoderParse(avifDecoder * decoder);
^
/wrkdirs/usr/ports/devel/efl/work/efl-1.25.1/src/modules/evas/image_loaders/avif/evas_image_load_avif.c:155:41: error: too many arguments to function call, expected single argument 'decoder', have 2 arguments
        res = avifDecoderParse(decoder, &raw);
              ~~~~~~~~~~~~~~~~          ^~~~
/usr/local/include/avif/avif.h:722:1: note: 'avifDecoderParse' declared here
avifResult avifDecoderParse(avifDecoder * decoder);
^
2 errors generated.

A short time later, the last build command is this which mentions 'loader' and 'psd' a number of times, which I cannot say exactly why it causes a failure.

[2610/4621] cc -Isrc/modules/evas/image_loaders/libshared_loader_psd.so.p -Isrc/modules/evas/image_loaders -I../src/modules/evas/image_loaders -I. -I.. -Isrc/lib/evil -I../src/lib/evil -Isrc/lib/eina -I../src/lib/eina -Isrc/lib/eo -I../src/lib/eo -Isrc/lib/efl -I../src/lib/efl -Isrc/lib/emile -I../src/lib/emile -Isrc/lib/eet -I../src/lib/eet -Isrc/lib/ecore -I../src/lib/ecore -Isrc/lib/eldbus -I../src/lib/eldbus -Isrc/lib/ecore_audio -I../src/lib/ecore_audio -Isrc/lib/ecore_con -I../src/lib/ecore_con -Isrc/lib/ecore_file -I../src/lib/ecore_file -Isrc/lib/ecore_input -I../src/lib/ecore_input -Isrc/lib/ecore_x -I../src/lib/ecore_x -Isrc/lib/ecore_wl2 -I../src/lib/ecore_wl2 -Isrc/lib/ecore_sdl -I../src/lib/ecore_sdl -Isrc/lib/ecore_win32 -I../src/lib/ecore_win32 -Isrc/lib/ecore_ipc -I../src/lib/ecore_ipc -Isrc/lib/ector -I../src/lib/ector -Isrc/lib/evas/software_generic -I../src/lib/evas/software_generic -I../src/modules/evas/engines/software_generic/filters -Isrc/lib/evas -I../src/lib/evas -Isrc/lib/evas/common -I../src/lib/evas/common -Isrc/lib/evas/include -I../src/lib/evas/include -Isrc/lib/evas/filters -I../src/lib/evas/filters -Isrc/lib/evas/canvas -I../src/lib/evas/canvas -Isrc/lib/efreet -I../src/lib/efreet -Isrc/lib/ecore_input_evas -I../src/lib/ecore_input_evas -Isrc/modules/evas/engines/buffer -I../src/modules/evas/engines/buffer -Isrc/lib/ecore_evas -I../src/lib/ecore_evas -Isrc/lib/ecore_imf -I../src/lib/ecore_imf -Isrc/lib/embryo -I../src/lib/embryo -Isrc/lib/eio -I../src/lib/eio -Isrc/lib/ecore_imf_evas -I../src/lib/ecore_imf_evas -Isrc/lib/ephysics -I../src/lib/ephysics -Isrc/lib/edje -I../src/lib/edje -Isrc/lib/emotion -I../src/lib/emotion -Isrc/lib/ethumb -I../src/lib/ethumb -Isrc/lib/ethumb_client -I../src/lib/ethumb_client -Isrc/lib/elementary -I../src/lib/elementary -Isrc/lib/efl_canvas_wl -I../src/lib/efl_canvas_wl -Isrc/static_libs/buildsystem -I../src/static_libs/buildsystem -Isrc/lib -I../src/lib -Isrc/static_libs/libunibreak -I../src/static_libs/libunibreak -Isrc/wayland_protocol -I../src/wayland_protocol -Isrc/lib/efl/interfaces -Isrc/lib/ector/gl -Isrc/lib/ector/software -Isrc/lib/evas/gesture -I/usr/local/include/luajit-2.0 -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -I/usr/local/include -I/usr/local/include/fribidi -I/usr/local/include/harfbuzz -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/libepoll-shim -Xclang -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -fvisibility=hidden -Wall -Wpointer-arith -Wunused-parameter -Wsign-compare -Wno-missing-field-initializers -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1 -DEFL_BETA_API_SUPPORT=1 -DELM_INTERNAL_API_ARGESFSDFEFC=1 -O2 -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -fPIC -pthread '-DPACKAGE_DATA_DIR="/usr/local/share/evas"' -DNEED_RUN_IN_TREE=1 -DEFL_BUILD=1 -MD -MQ src/modules/evas/image_loaders/libshared_loader_psd.so.p/_wrkdirs_usr_ports_devel_efl_work_efl-1.25.1_src_modules_evas_image_loaders_psd_evas_image_load_psd.c.o -MF src/modules/evas/image_loaders/libshared_loader_psd.so.p/_wrkdirs_usr_ports_devel_efl_work_efl-1.25.1_src_modules_evas_image_loaders_psd_evas_image_load_psd.c.o.d -o src/modules/evas/image_loaders/libshared_loader_psd.so.p/_wrkdirs_usr_ports_devel_efl_work_efl-1.25.1_src_modules_evas_image_loaders_psd_evas_image_load_psd.c.o -c /wrkdirs/usr/ports/devel/efl/work/efl-1.25.1/src/modules/evas/image_loaders/psd/evas_image_load_psd.c
ninja: build stopped: subcommand failed.
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.

What I am taking from those, is the mention of 'raw' and 'psd' which are mentioned in the efl configuration options in the 'loader' section, RAW and PS.  So my next testbuild will have those two configuration options unticked and see what we get next.  Between those two seems to be the issue which is a fatal error but whether attempting to avoid them by a configuration change will solve it or if it might be solved by different versions of the dependencies I cannot say.  The main thing is successfully building to the end, solving the various problems will be second to that.

[2809/4617] cc -Isrc/modules/evas/image_loaders/libshared_loader_tgv.so.p -Isrc/modules/evas/image_loaders -I../src/modules/evas/image_loaders -I. -I.. -Isrc/lib/evil -I../src/lib/evil -Isrc/lib/eina -I../src/lib/eina -Isrc/lib/eo -I../src/lib/eo -Isrc/lib/efl -I../src/lib/efl -Isrc/lib/emile -I../src/lib/emile -Isrc/lib/eet -I../src/lib/eet -Isrc/lib/ecore -I../src/lib/ecore -Isrc/lib/eldbus -I../src/lib/eldbus -Isrc/lib/ecore_audio -I../src/lib/ecore_audio -Isrc/lib/ecore_con -I../src/lib/ecore_con -Isrc/lib/ecore_file -I../src/lib/ecore_file -Isrc/lib/ecore_input -I../src/lib/ecore_input -Isrc/lib/ecore_x -I../src/lib/ecore_x -Isrc/lib/ecore_wl2 -I../src/lib/ecore_wl2 -Isrc/lib/ecore_sdl -I../src/lib/ecore_sdl -Isrc/lib/ecore_win32 -I../src/lib/ecore_win32 -Isrc/lib/ecore_ipc -I../src/lib/ecore_ipc -Isrc/lib/ector -I../src/lib/ector -Isrc/lib/evas/software_generic -I../src/lib/evas/software_generic -I../src/modules/evas/engines/software_generic/filters -Isrc/lib/evas -I../src/lib/evas -Isrc/lib/evas/common -I../src/lib/evas/common -Isrc/lib/evas/include -I../src/lib/evas/include -Isrc/lib/evas/filters -I../src/lib/evas/filters -Isrc/lib/evas/canvas -I../src/lib/evas/canvas -Isrc/lib/efreet -I../src/lib/efreet -Isrc/lib/ecore_input_evas -I../src/lib/ecore_input_evas -Isrc/modules/evas/engines/buffer -I../src/modules/evas/engines/buffer -Isrc/lib/ecore_evas -I../src/lib/ecore_evas -Isrc/lib/ecore_imf -I../src/lib/ecore_imf -Isrc/lib/embryo -I../src/lib/embryo -Isrc/lib/eio -I../src/lib/eio -Isrc/lib/ecore_imf_evas -I../src/lib/ecore_imf_evas -Isrc/lib/ephysics -I../src/lib/ephysics -Isrc/lib/edje -I../src/lib/edje -Isrc/lib/emotion -I../src/lib/emotion -Isrc/lib/ethumb -I../src/lib/ethumb -Isrc/lib/ethumb_client -I../src/lib/ethumb_client -Isrc/lib/elementary -I../src/lib/elementary -Isrc/lib/efl_canvas_wl -I../src/lib/efl_canvas_wl -Isrc/static_libs/buildsystem -I../src/static_libs/buildsystem -Isrc/lib -I../src/lib -Isrc/static_libs/libunibreak -I../src/static_libs/libunibreak -Isrc/wayland_protocol -I../src/wayland_protocol -Isrc/static_libs/rg_etc -I../src/static_libs/rg_etc -Isrc/static_libs/lz4 -I../src/static_libs/lz4 -Isrc/lib/efl/interfaces -Isrc/lib/ector/gl -Isrc/lib/ector/software -Isrc/lib/evas/gesture -I/usr/local/include/luajit-2.0 -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -I/usr/local/include -I/usr/local/include/fribidi -I/usr/local/include/harfbuzz -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/libepoll-shim -Xclang -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -fvisibility=hidden -Wall -Wpointer-arith -Wunused-parameter -Wsign-compare -Wno-missing-field-initializers -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1 -DEFL_BETA_API_SUPPORT=1 -DELM_INTERNAL_API_ARGESFSDFEFC=1 -O2 -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -fPIC -pthread '-DPACKAGE_DATA_DIR="/usr/local/share/evas"' -DNEED_RUN_IN_TREE=1 -DEFL_BUILD=1 -MD -MQ src/modules/evas/image_loaders/libshared_loader_tgv.so.p/.._.._.._static_libs_rg_etc_rg_etc1.c.o -MF src/modules/evas/image_loaders/libshared_loader_tgv.so.p/.._.._.._static_libs_rg_etc_rg_etc1.c.o.d -o src/modules/evas/image_loaders/libshared_loader_tgv.so.p/.._.._.._static_libs_rg_etc_rg_etc1.c.o -c ../src/static_libs/rg_etc/rg_etc1.c
ninja: build stopped: subcommand failed.
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.

I don't know what tgv could be, there is nothing in the configuration which is similar to that.  I think I will untick all of the items in the loader section and see whether we can get past this section of errors.

FAILED: src/modules/evas/image_loaders/libshared_loader_avif.so.p/_wrkdirs_usr_ports_devel_efl_work_efl-1.25.1_src_modules_evas_image_loaders_avif_evas_image_load_avif.c.o
cc -Isrc/modules/evas/image_loaders/libshared_loader_avif.so.p -Isrc/modules/evas/image_loaders -I../src/modules/evas/image_loaders -I. -I.. -Isrc/lib/evil -I../src/lib/evil -Isrc/lib/eina -I../src/lib/eina -Isrc/lib/eo -I../src/lib/eo -Isrc/lib/efl -I../src/lib/efl -Isrc/lib/emile -I../src/lib/emile -Isrc/lib/eet -I../src/lib/eet -Isrc/lib/ecore -I../src/lib/ecore -Isrc/lib/eldbus -I../src/lib/eldbus -Isrc/lib/ecore_audio -I../src/lib/ecore_audio -Isrc/lib/ecore_con -I../src/lib/ecore_con -Isrc/lib/ecore_file -I../src/lib/ecore_file -Isrc/lib/ecore_input -I../src/lib/ecore_input -Isrc/lib/ecore_x -I../src/lib/ecore_x -Isrc/lib/ecore_wl2 -I../src/lib/ecore_wl2 -Isrc/lib/ecore_sdl -I../src/lib/ecore_sdl -Isrc/lib/ecore_win32 -I../src/lib/ecore_win32 -Isrc/lib/ecore_ipc -I../src/lib/ecore_ipc -Isrc/lib/ector -I../src/lib/ector -Isrc/lib/evas/software_generic -I../src/lib/evas/software_generic -I../src/modules/evas/engines/software_generic/filters -Isrc/lib/evas -I../src/lib/evas -Isrc/lib/evas/common -I../src/lib/evas/common -Isrc/lib/evas/include -I../src/lib/evas/include -Isrc/lib/evas/filters -I../src/lib/evas/filters -Isrc/lib/evas/canvas -I../src/lib/evas/canvas -Isrc/lib/efreet -I../src/lib/efreet -Isrc/lib/ecore_input_evas -I../src/lib/ecore_input_evas -Isrc/modules/evas/engines/buffer -I../src/modules/evas/engines/buffer -Isrc/lib/ecore_evas -I../src/lib/ecore_evas -Isrc/lib/ecore_imf -I../src/lib/ecore_imf -Isrc/lib/embryo -I../src/lib/embryo -Isrc/lib/eio -I../src/lib/eio -Isrc/lib/ecore_imf_evas -I../src/lib/ecore_imf_evas -Isrc/lib/ephysics -I../src/lib/ephysics -Isrc/lib/edje -I../src/lib/edje -Isrc/lib/emotion -I../src/lib/emotion -Isrc/lib/ethumb -I../src/lib/ethumb -Isrc/lib/ethumb_client -I../src/lib/ethumb_client -Isrc/lib/elementary -I../src/lib/elementary -Isrc/lib/efl_canvas_wl -I../src/lib/efl_canvas_wl -Isrc/static_libs/buildsystem -I../src/static_libs/buildsystem -Isrc/lib -I../src/lib -Isrc/static_libs/libunibreak -I../src/static_libs/libunibreak -Isrc/wayland_protocol -I../src/wayland_protocol -Isrc/lib/efl/interfaces -Isrc/lib/ector/gl -Isrc/lib/ector/software -Isrc/lib/evas/gesture -I/usr/local/include/luajit-2.0 -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -I/usr/local/include -I/usr/local/include/fribidi -I/usr/local/include/harfbuzz -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/libepoll-shim -Xclang -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -fvisibility=hidden -Wall -Wpointer-arith -Wunused-parameter -Wsign-compare -Wno-missing-field-initializers -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1 -DEFL_BETA_API_SUPPORT=1 -DELM_INTERNAL_API_ARGESFSDFEFC=1 -O2 -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -fPIC -pthread '-DPACKAGE_DATA_DIR="/usr/local/share/evas"' -DNEED_RUN_IN_TREE=1 -DEFL_BUILD=1 -MD -MQ src/modules/evas/image_loaders/libshared_loader_avif.so.p/_wrkdirs_usr_ports_devel_efl_work_efl-1.25.1_src_modules_evas_image_loaders_avif_evas_image_load_avif.c.o -MF src/modules/evas/image_loaders/libshared_loader_avif.so.p/_wrkdirs_usr_ports_devel_efl_work_efl-1.25.1_src_modules_evas_image_loaders_avif_evas_image_load_avif.c.o.d -o src/modules/evas/image_loaders/libshared_loader_avif.so.p/_wrkdirs_usr_ports_devel_efl_work_efl-1.25.1_src_modules_evas_image_loaders_avif_evas_image_load_avif.c.o -c /wrkdirs/usr/ports/devel/efl/work/efl-1.25.1/src/modules/evas/image_loaders/avif/evas_image_load_avif.c
/wrkdirs/usr/ports/devel/efl/work/efl-1.25.1/src/modules/evas/image_loaders/avif/evas_image_load_avif.c:68:36: error: too many arguments to function call, expected single argument 'decoder', have 2 arguments
   res = avifDecoderParse(decoder, &raw);
         ~~~~~~~~~~~~~~~~          ^~~~
/usr/local/include/avif/avif.h:722:1: note: 'avifDecoderParse' declared here
avifResult avifDecoderParse(avifDecoder * decoder);
^
/wrkdirs/usr/ports/devel/efl/work/efl-1.25.1/src/modules/evas/image_loaders/avif/evas_image_load_avif.c:155:41: error: too many arguments to function call, expected single argument 'decoder', have 2 arguments
        res = avifDecoderParse(decoder, &raw);
              ~~~~~~~~~~~~~~~~          ^~~~
/usr/local/include/avif/avif.h:722:1: note: 'avifDecoderParse' declared here
avifResult avifDecoderParse(avifDecoder * decoder);
^
2 errors generated.
[2546/4604] c++  -o src/examples/eina/eina_hash_07 src/examples/eina/eina_hash_07.p/eina_hash_07.c.o -I/usr/local/include/libepoll-shim -L/usr/local/lib -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -Wl,--start-group -lepoll-shim -Wl,-rpath,/usr/local/lib -fstack-protector-strong libefl-one.so.1.25.1 -Wl,--end-group -pthread '-Wl,-rpath,$ORIGIN/../../..' -Wl,-rpath-link,/wrkdirs/usr/ports/devel/efl/work/efl-1.25.1/_build/
[2547/4604] c++  -o src/examples/eina/eina_hash_06 src/examples/eina/eina_hash_06.p/eina_hash_06.c.o -I/usr/local/include/libepoll-shim -L/usr/local/lib -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -Wl,--start-group -lepoll-shim -Wl,-rpath,/usr/local/lib -fstack-protector-strong libefl-one.so.1.25.1 -Wl,--end-group -pthread '-Wl,-rpath,$ORIGIN/../../..' -Wl,-rpath-link,/wrkdirs/usr/ports/devel/efl/work/efl-1.25.1/_build/
[2548/4604] c++  -o src/examples/eina/eina_hash_08 src/examples/eina/eina_hash_08.p/eina_hash_08.c.o -I/usr/local/include/libepoll-shim -L/usr/local/lib -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -Wl,--start-group -lepoll-shim -Wl,-rpath,/usr/local/lib -fstack-protector-strong libefl-one.so.1.25.1 -Wl,--end-group -pthread '-Wl,-rpath,$ORIGIN/../../..' -Wl,-rpath-link,/wrkdirs/usr/ports/devel/efl/work/efl-1.25.1/_build/
[2549/4604] c++  -o src/examples/eina/eina_list_01 src/examples/eina/eina_list_01.p/eina_list_01.c.o -I/usr/local/include/libepoll-shim -L/usr/local/lib -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -Wl,--start-group -lepoll-shim -Wl,-rpath,/usr/local/lib -fstack-protector-strong libefl-one.so.1.25.1 -Wl,--end-group -pthread '-Wl,-rpath,$ORIGIN/../../..' -Wl,-rpath-link,/wrkdirs/usr/ports/devel/efl/work/efl-1.25.1/_build/
[2550/4604] c++  -o src/examples/eina/eina_iterator_01 src/examples/eina/eina_iterator_01.p/eina_iterator_01.c.o -I/usr/local/include/libepoll-shim -L/usr/local/lib -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -Wl,--start-group -lepoll-shim -Wl,-rpath,/usr/local/lib -fstack-protector-strong libefl-one.so.1.25.1 -Wl,--end-group -pthread '-Wl,-rpath,$ORIGIN/../../..' -Wl,-rpath-link,/wrkdirs/usr/ports/devel/efl/work/efl-1.25.1/_build/
ninja: build stopped: subcommand failed.
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.

This may not look like the progress that it is.  After eliminating all of the items in the loader section, the culprit that has been there through all of this is more obvious.  The next step is to look into whether I can and whether it matters, if devel/libavif is updated to a more recent version.  Another possibility is that libavif may need its own options changed so I ticked them all and will see if that solves it.  One more thing I noticed in the above output, is that even without the options for those various loader types (ps, raw, etc.) being unticked, I think the build still seems to call on them in the arguments.  Adjusting the options for libavif is not as simple as ticking them all, as a couple options are broken (yeah I know, unticking them for default pkg build is not a solution), and it seems I certainly need the decode options set.  

No joy.  I will have to look at whether a newer version of libavif solves it, but if not then I seem to be at a dead end.  The strange part is that if the instructions for building with FreeBSD on the Enlightenment site are accurate, there is no mention of libavif, but I suspect those are out of date too.  There is no newer version, so all I can try is other configuration options as the last possible solution, and then I can do no more it seems.  Looking at libavif it mentions AOM, and looking at the git site for libavif it also mentions AOM, so I wonder if the dependency is actually multimedia/aom instead.  I will try this and see, but there doesn't seem to be much chance that I will get devel/efl built.  Unfortunately multimedia/aom as a dependency in the Makefile was not the solution it could have been. I erred in saying that libavif was as current as it could be, I misread the git page for it, version 0.8.4 is available.

The update for devel/libavif needed the version number in the Makefile changed and comment out portrevision line, then hide distinfo and do a fetch, recreate the distinfo with make makesum, and finally hide and update the pkg-plist with make makeplist.  The pkg-plist was a little more work than the rest, since it doesn't actually create the file and the result needs to be checked.  I compared the old pkg-plist to the new information and adjusted things to match.  So now we will have a newer version of one of the dependencies for devel/efl but will this now solve the issue?  It seems I can do no more, though I might revisit this in the future or at any point I feel a need to scuff my forehead.  Right now I am out of ideas.

During this whole attempt to update Enlightenment I didn't use a seperate poudriere jail as I had suggested at the outset.  I also did not make or configure another ports tree just in case for use with the modifications, nor did I revise any other configuration for poudriere as I suggested I might.  It all didn't feel necessary since the changes were relatively minor, the ports involved (aside from devel/libavif) do not succeed to build anyhow, and as it turns out, since the project was a failure beyond my ability, any future ports tree update (via svn) will wipe out the modifications, all of them-- although I discovered, a caveat in that things got wonky until I wiped out the libavif directory before the svn update.  These are the frustrating updates or porting attempts which elude and evade and deny solution.  Maybe an update of something by the developers will solve the issue, I cannot even guess whether what I see is unique to me or an actual bug but it does appear so.

Bogus vulnerability

You may have read about my weird network failure during which only firefox seemed to reach anything on the internet.  The portsnap fetch function does work but in a sort of spotty inconsistent maybe not at all fashion.  I had to resort to using svn to update ports, so I am now back to being able to update my ports whether directly or with poudriere.  One of the things I know to do when websites strangely fail to connect is to update security/css_root_nss along with possibly a quick close and restart of firefox, until this time.  I saw one of the most odd error messages:

recert

===>  Deinstalling for ca_root_nss
===>   ca_root_nss not installed, skipping
pkg-static: unable to open vulnxml file (null): Invalid argument
===>  ca_root_nss-3.58 has known vulnerabilities:

=> Please update your ports tree and try again.
=> Note: Vulnerable ports are marked as such even if there is no update available.
=> If you wish to ignore this vulnerability rebuild with 'make DISABLE_VULNERABILITIES=yes'
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/security/ca_root_nss
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/security/ca_root_nss
*** Error code 1

Stop.
make: stopped in /usr/ports/security/ca_root_nss

Yeah, recert is a simple alias to make the updating quick and a bit easier.  Inside my root ~/.cshrc

# quickly re-install certificates
alias recert    make -C  /usr/ports/security/ca_root_nss reinstall clean

Instead of using that I successfully installed ca_root_nss by including the DISABLE_VULNERABILITIES=yes with make as was suggested.  This is still not a very good situation so to fix it I assumed that I needed to install something else, but saw the same issue again.

root@ichigo:/usr/ports/security/vuxml # make install clean
pkg-static: unable to open vulnxml file (null): Invalid argument
===>  vuxml-1.1_5 has known vulnerabilities:

=> Please update your ports tree and try again.
=> Note: Vulnerable ports are marked as such even if there is no update available.
=> If you wish to ignore this vulnerability rebuild with 'make DISABLE_VULNERABILITIES=yes'
*** Error code 1

Stop.
make: stopped in /usr/ports/security/vuxml

Even after using the same override method to get this installed, trying to install ca_root_nss I saw the same error mentioned above.  Maybe something for vuxml was not installed, so I checked the pkg-plist for it and verified the locations to see if things were indeed installed.

more /usr/ports/security/vuxml/pkg-plist

@xmlcatmgr share/xml/dtd/vuxml/catalog
@xmlcatmgr share/xml/dtd/vuxml/catalog.xml
share/xml/dtd/vuxml/vuxml-10.dtd
share/xml/dtd/vuxml/vuxml-11.dtd
share/xml/dtd/vuxml/vuxml-model-10.mod
share/xml/dtd/vuxml/vuxml-model-11.mod
share/xml/dtd/vuxml/xml1.dcl
root@ichigo:~ # cd /usr/local/share/xml/dtd/vuxml
/usr/local/share/xml/dtd/vuxml: No such file or directory.
root@ichigo:~ # cd /usr/share/xml/dtd/vuxml
/usr/share/xml/dtd/vuxml: No such file or directory.

This is strange.  I finally got smart and did an online search for "pkg-static: unable to open vulnxml file (null): Invalid argument" which brought me to an old mailing list reply which gave me the answer.  I guess that due to my attempts to recover from the portsnap failing a few things were erased that I needed, the fix was easy:

pkg audit -F

Fetching vuln.xml.bz2: 100%  891 KiB 912.8kB/s    00:01
linux-c7-libsndfile-1.0.25_5 is vulnerable:
libsndfile -- out-of-bounds reads
CVE: CVE-2017-17457
CVE: CVE-2017-17456
CVE: CVE-2017-14246
CVE: CVE-2017-14245
WWW: https://vuxml.FreeBSD.org/freebsd/30704aba-1da4-11e8-b6aa-4ccc6adda413.html

linux-c7-libsndfile-1.0.25_5 is vulnerable:
libsndfile -- multiple vulnerabilities
CVE: CVE-2017-14634
CVE: CVE-2017-12562
CVE: CVE-2017-8365
CVE: CVE-2017-8363
CVE: CVE-2017-8362
CVE: CVE-2017-8361
WWW: https://vuxml.FreeBSD.org/freebsd/2b386075-1d9c-11e8-b6aa-4ccc6adda413.html

linux-c7-libsndfile-1.0.25_5 is vulnerable:
libsndfile -- out-of-bounds read memory access
CVE: CVE-2017-6892
WWW: https://vuxml.FreeBSD.org/freebsd/004debf9-1d16-11e8-b6aa-4ccc6adda413.html

linux-c7-libsndfile-1.0.25_5 is vulnerable:
libsndfile -- multiple vulnerabilities
CVE: CVE-2017-7742
CVE: CVE-2017-7741
CVE: CVE-2017-7586
CVE: CVE-2017-7585
WWW: https://vuxml.FreeBSD.org/freebsd/5a97805e-93ef-4dcb-8d5e-dbcac263bfc2.html

apache-openoffice-4.1.7_3 is vulnerable:
Apache OpenOffice -- Unrestricted actions leads to arbitrary code execution in crafted documents
CVE: CVE-2020-13958
WWW: https://vuxml.FreeBSD.org/freebsd/4f15ca7b-23ae-11eb-9f59-1c1b0d9ea7e6.html

5 problem(s) in 2 installed package(s) found.

This command seems to have created the files that were needed, since after the update output above I could install security/vuxml or security/ca_root_nss without issue.  I've mentioned before that I seem to very frequently encounter strange errors and weird issues with my FreeBSD machine.  They're all learning experiences and with this blog to help document them hopefully you learn from them as well, but surely I'll keep discovering random bizarre "ghost in the machine" style issues.  You may be more lucky than me to either not run into any of these things, or less nice, yours will be completely different from mine.

Only Firefox? Really?

I have been struggling lately with what I could say are strange network issues, but as networking tends to be arcane magic anyway, that things ever break is truly a bit too normal.  In the past my difficulties were involving the task of setting up a firewall/router device.  My OPNsense router has been working fine and was not the open source solution that caused me troubles.  Any issues I have had have been my own mistakes or a mitigation default which was incompatible with AMD chips.

My initial difficulties were that VLC suddenly began to fail nearly all streaming audio stations.  I am not sure if my network issues are causing the streaming audio station problems since strangely AAC sites seem to work while others fail to connect.  It may be coincidental that those AAC format streams also favor a different connectivity method but I have not looked into that to be certain.

The next trouble I ran into was that minetest servers would not connect to my client.  For a while I could see the list of servers including my favorites even though I could not reach any of them to play.  I could also update or browse any of the content addons for minetest if I so chose.  Now things are broken enough that I can do neither, I cannot connect to the contentdb nor to game servers.

These weird network-related issues have progressed.  Any ping from my personal box out to locations on the internet, now fails.  I can direct OPNsense on my firewall box to ping anywhere and it succeeds.  This implies that the failure is something on my personal box or is blocked by the firewall.  I have checked both, made certain that no firewall rule could possibly deny pings and even added an explicit enable for port 7 which is ping.  I have turned off pf on my personal box and looked at items in the sysctl.conf, to be sure they should not impede network connectivity.

The most recent failure is portsnap.  I am fairly baffled.  There should be nothing that would prevent any of these things in the OPNsense firewall box nor the Xfinity Arris device.  I disabled the firewall entirely on the Xfinity device so I am certain that it cannot be part of my troubles.  I am running out of ideas.  I attempt to open access wider but more things become blocked, this is so bizarre.  Oh, I nearly forgot.  Somewhere in all of the above progressively broken network story is the failure of nntp to connect which makes perfect sense since why should it work if nothing else does.

Do you know what the kicker is though?  Firefox has its own methods, its own self-contained networking and configuration, and it continues to work during all of this. The exceptions to that are when Comcast is screwing up, or the ssl certs need updates, or firefox itself apparently updated in the background.  Yes it is good that Firefox seems to work no matter what, but it fails to be a method for diagnosing the problem itself.  Firefox does not tell me ANYTHING about why everything else is broken, it keeps working oblivious to all other network failings on my box.

Should I hold my breath expecting that nothing will need to be updated or rebuilt due to bugs or other issues?  Surely NOW is when something will fail and make my broken portsnap (and connectivity) become a real problem.  I guess the only way out of this twisty passage of passages all alike is to look at every possible function and config which may possibly ever have a chance at affecting any bit of networking.  I am nearly at a point in my frustration when I might begin to consider just wiping everything to start over fresh from scratch, yes that aggravated.  I cannot.  I am stuck solving this though while also reporting on it here, because I have excess time on my hands and a partially functional situation does not actually call for it.  Although an exorcist could be helpful since some of the more obvious solutions have either made things progressively worse or have done nothing at all, and I have yet to find any common thread.

It seems that something I did has rendered all streams broken for VLC.  Perhaps previously it had been a VLC issue somehow, but now that none play it is obviously another victim of my network issues.  Of course since I continue adding text to this blog post, firefox continues to act like nothing is wrong.  Until I took a few moments to test the first of the potential trouble files, /etc/sysctl.conf which I trimmed back to what I thought were the essentials but not so for my present system.  The reduced file meant that for a while a simple firefox startup would panic the system.  No choice, I had to restore the prior /etc/sysctl.conf and will need to look into lines which may affect firefox.  The line I suspect had a comment suggesting it was only needed for chrome.

This decision to look closely at files on my primary box was due to one change I made to my /boot/loader.conf file which caused booting to fail.  What I added and subsequently commented out was:

vfs.root.mountfrom="zfs:zroot"

This ended up forcing me to use NomadBSD to fix the issue, but while I had that booted, I checked whether I could ping google and I could.  Even though it seemed like my router/firewall could be blocking pings from my box, this proved it was not, and so the beginning of scrutiny of files.  I doubt that anything is missing, as things essentially work other than specific networking-related programs as mentioned above.  If firefox also failed completely, then I surely have zero connectivity and likely something significant is broken.  I'm rather glad that the boot failure was a specific line in a file that I added moments before and not due to any weird escalation of problems.

Is it possible that any of my network problems could be related to my attempts to use both ports on my intel dual gigabit ethernet card?  This is one of the changes I have been attempting to get functioning (somewhat for the heck of it) prior to some of my network issues.  One may think that it shouldn't be an issue, that FreeBSD being a server oriented operating system should be able to handle it.  I set each interface with its own IP, so surely there are no "collisions" as far as I know.  What I will have to do is comment out some lines in my /etc/rc.conf and disconnect one ethernet cable and see if anything changes.  Of course that would be too easy, too simple a fix.

Not sure if I was remembering correctly about the ping while using NomadBSD, I went to doublecheck.  This time I had connection issues but I believe some were partly due to NomadBSD somehow expecting and using IPv6 for all ethernet connections.  I decided that the failure was due to disabling IPv6 on the router, so I looked at the rc.conf on my box again.  I found an error which did not cause any issues because it was commented out.  This was most likely a copy-paste mistake which inserted what some call fancy quotes around a YES.  I am unsure quite why I could see them this time as \xe2\x80\x9d but now that I know that line had an error, looking more closely it was easy to see the fancy quote characters.

I'm sorry, it seems that innumerable lines of this blog post were lost due to the glorious caveat that editor windows for remote sites may seem like they are fully functional but if there is any disconnection your recent work can be lost.  This emphasizes the need to use a local editor from which I can paste each blog post.  I will therefore need to finish this from memory (my own, not the computer's unfortunately) and although I did finally discover the reason for my troubles, some of the previous details may be missed. OPNsense: Firewall > NAT > Outbound:

It turns out that much if not all of my troubles are due to NAT being disabled on my router.  I also tested a few different settings on the Xfinity Arris device for its included firewall.  Their options are limited but their 'Maximum security' setting will prevent connection to minetest servers and denies VLC to connect to most (http) streaming audio, both due to the ports involved and the security block of them.  The Arris ipv4 firewall settings that will not work for me:

Perhaps when I have motivation sometime after I have forgotten the frustration of this challenging network difficulty I might look into what exactly firefox does for itself which keeps it so nearly perfectly insulated from all the failures that might surround it on all sides.

Now I can't boot

There have been plenty of times by now that I have made some sort of adjustment on my system and then it doesn't boot.  We know the usual suspects are /etc/rc.conf and /boot/loader.conf but I'm sure there are others, possibly even a badly thought out recently built and installed custom kernel.  So now we are stuck, we have one box and it fails to boot but the way to solve the problem is to get online from it.  The situation with the broken kernel might be sidestepped easily, simply choose the option from the boot menu to use a different kernel.  If there were also mistakes with the buildworld, and lack of items means no booting, then there needs to be another way.

If you can get to single-user mode (another boot menu item), the changes will be easy to apply.  First, mount -u / and then if your filesystem is ZFS rather than UFS, zfs mount -a and now you can re-edit the typo out of your /boot/loader.conf or some other file, but what if your situation is a bit more complex?

You can use a usb stick to boot and from there mount the drives in your pc, make needed adjustments and get everything back to normal again.  This is where it can be fun, and when I say fun I mean not quite a nightmare though it is a real special pain.  You can probably use any bootable BSD which offers shell access to the machine, but since discovering NomadBSD, it has become my preference.  What NomadBSD has is a complete system which is self-contained within the usb media.  So if you are short of time and cannot fix your system, you can use it to get online to do something important, such as check your work schedule.  Of course, this immediate need situation means that you previously setup a web browser and installed and configured an addon (such as blur by Abine) which stores your passwords, and you had made any other needed adjustments to suit your needs.  So, getting online you have the solution to the problem and you've written it down and now you need to fix whatever is wrong on the HDD of your system.

What you need to do is mount the HDD of your system into the usb media that is loaded.  There should be a directory /media present already, if not, create via mkdir /media because this will be the mount point to reach inside your system HDD.  I would assume that you are already in a shell window (xterm perhaps) or you used shell access from the menu when you booted the usb.  We have two pieces of the puzzle, the solution and the system running with a shell, what we need to do in order to make the changes is get to the drive.

With ZFS, there is a special command which will do what we need, change zroot to the name of your pool.

zpool import -f -R /media zroot

Many times the mistake was made or is corrected in either /etc or /boot, so now to reach those directories or any others on your HDD, you would prefix the desired directory with /media such as below.  Work slowly, re-read the command you've typed before committing to it by pressing return or enter.  While your HDD is mounted to your usb stick, /media is the/ (root) directory of your HDD, and / is the root directory of the usb stick itself.  Entering the specific directory in order to edit a file, such as rc.conf or loader.conf, may be better than remembering every time to prefix with /media, but always pay attention to your current working directory or path.

cd /media/etc

or

cd /media/boot

Only you can know what the problem and solution are.  Now that you have access  to your HDD you can make the corrections and reboot.  That zpool import command is only viable until you reboot and does not need to be turned off or disabled.  We have not made any permanent changes to how your drives are mounted in order to fix the problem, unless of course your problem and solution specifically involves a permanent adjustment to how your drives are mounted.  Right now I do not have any examples handy of the dumb things I have done which resulted in being unable to boot along with how they were fixed.

While tinkering with your system in ways that can only truly be done when it is open source, because you use FreeBSD for your need of control over all of it, you are setting yourself up with the potential for mistakes.  There is nothing wrong with unintentionally doing something incorrectly, it is the surest way to learn.  We may read somewhere how to do something but unknowingly miss a step or configure something wrong or assume their technique will work on our system.  The worst of these experiences involve Boot blockers and unfortunately they can at least temporarily halt all further progress.