Poudriere after a time

Poudriere is not perfect but it is brilliant and a powerful tool.  I think that it may have already become my primary ports build method as for the most part it does what I expect it to do.  With poudriere and pkg, used together and only my poudriere repo enabled, I can be fairly certain that what I install will be built how I wish it to be built.  I can go to any individual poudriere port directory in /usr/local/poudriere/ports/default to modify or manipulate the port build as I desire.  I have my minetest build adjustments copied to its poudriere path, the modified Makefile and hide or remove a patch in its files.  Whether something succeeds to build or not only affects what I will later install with pkg, and not necessarily cause other breakage or removals.

The testport function is very helpful and may one day assist me with porting something to FreeBSD.  This also helps to detect mistakes in the ports tree members we already have.  This capability can be enabled for bulk builds as well but sometimes requires skirting a problematic port.  One recent issue is a sort of build system regression which may only affect a subset of ports and as such it is not something I can solve.  The only way around it is to successfully build those ports which fail while ignoring the problem, then once built and in the poudriere cache the test mode can be reenabled.  Other ports which poudriere points out 'portlint' type errors are easily fixed, as most involve errors in the Makefile itself such as the preferred order of lines or missing dependencies, or typos.

I have been keeping an updated installed-pkgs list since this seems to be one of the few aspects of many of the other ports-mgmt tools that poudriere does not automate directly.  It is a very simple thing to do, to create this list, and even though poudriere chooses its own preferred build order, I still organize my list alphabetically for my own ease of use.  Below is how I periodically create the file.

pkg origin | sort -u -d > installed-pkgs

This works quite well.  One may believe that the pkg origin command would deliver a concise list but it seems to include a number of duplicates.  Even if it was my own mistake causing the duplicates, it is likely a good idea to guard against them anyway.

There is one flaw of poudriere which if addressed would cover one further step I need to take for that list to be used without problems.  My system contains a number of ports which have since vanished from the tree.  I would have expected that placing their port origins into the blacklist file would solve the issue but it does not.  The peculiar thing about the blacklist file is that poudriere uses it to ignore buildable ports listed but still fails on those ports if they do not exist in the tree.  If the blacklist also filtered those ports from the set of files in the bulk build list given to it, we could add them to the blacklist once and forget about them with successive lists created with the instruction above.  This small flaw was not caused by adding anything else to the poudriere bulkbuild command, such as the -t which would cause other testing of each port, because I did not use it.  The only other possible cause is that my poudriere config file enables portlint scrutiny which I had not enabled, however, I still believe the blacklist ought to first filter the bulkbuild list as just described.  Instead of the desired expected function of the blacklist, I have to find and remove those specific presently non-existent ports from the buildlist.  Maybe I had built and installed something which had a directory in the ports tree (perhaps a new unsubmitted port), so pkg gains the registration of the port, then an update (such as fetch extract) or other rewrite of the ports tree causes it to vanish.  It might be speedier to add a port origin to avoid in the blacklist file than to go to the parent Makefile to add or remove a directory.  The point being, that the blacklist ought to be a universal exclude.  Below, when those port origins are not removed from the installed-pkgs file is an example output and its failure to build due to the flaw:

root@ichigo:~ # poudriere bulk -f ~/installed-pkgs -j 12amd64
[00:00:00] Creating the reference jail... done
[00:00:01] Mounting system devices for 12amd64-default
[00:00:01] Mounting ports/packages/distfiles
[00:00:01] Using packages from previously failed build: /usr/local/poudriere/data/packages/12amd64-default/.building
[00:00:01] Mounting ccache from: /var/cache/ccache
[00:00:01] Mounting packages from: /usr/local/poudriere/data/packages/12amd64-default
[00:00:01] Copying /var/db/ports from: /var/db/ports
[00:00:01] Appending to make.conf: /etc/make.conf
[00:00:01] Warning: Blacklisting (from /usr/local/etc/poudriere.d/12amd64-blacklist): sysutils/pcbsd-libsh
[00:00:01] Warning: Blacklisting (from /usr/local/etc/poudriere.d/12amd64-blacklist): x11-fonts/font-bitstream-speedo
[00:00:01] Warning: Blacklisting (from /usr/local/etc/poudriere.d/12amd64-blacklist): x11-fonts/fontconfig-reference
[00:00:01] Warning: Blacklisting (from /usr/local/etc/poudriere.d/12amd64-blacklist): x11-wm/fvwm-crystal
/etc/resolv.conf -> /usr/local/poudriere/data/.m/12amd64-default/ref/etc/resolv.conf
[00:00:01] Starting jail 12amd64-default
[00:00:01] Copying host static ccache from /usr/local/bin/ccache
[00:00:03] Logs: /usr/local/poudriere/data/logs/bulk/12amd64-default/2020-10-19_00h09m04s
[00:00:03] Loading MOVED for /usr/local/poudriere/data/.m/12amd64-default/ref/usr/ports<
[00:00:05] Ports supports: FLAVORS SELECTED_OPTIONS
[00:00:05] Gathering ports metadata
[00:00:05] Error: MOVED: x11-fonts/font-bitstream-speedo 2019-10-15 Deprecatd upstream
[00:00:05] Error: MOVED: x11-fonts/fontconfig-reference 2020-09-19 Remove outdated reference documentation
[00:00:05] Error: MOVED: x11-wm/fvwm-crystal 2020-09-19 Has expired: Uses deprecated version of python
[00:00:05] Error: Fatal errors encountered gathering initial ports metadata
[00:00:05] Cleaning up
12amd64-default: removed
12amd64-default-n: removed
[00:00:05] Unmounting file systems
root@ichigo:~ #

I created a script to iterate through the config of each port in the buildlist outside of the poudriere jail.  As you may recall, I setup the port config directory and the /etc/make.conf as symbolic links for poudriere, so any changes I would make to port options or the make.conf will affect any other ports builds including poudriere.  The make.conf file has become quite extensive, and will be mentioned in another blog post.  Each port config option has a keyword which I may add to OPTIONS_UNSET+= or OPTIONS_SET+= in the make.conf.  Many of these keywords are unique but a lot are used across multiple ports, sometimes with the same purpose, sometimes not, and sometimes the same purpose is triggered by multiple keywords.

When I use poudriere to build my ports, I am primarily using the content of my make.conf file to configure them, because the last step is another script which removes the saved configuration options for each port in the buildlist.  This technique works rather well, except when an option causes a cascade of failed or skipped ports builds.  The other wrinkle with this, is when two ports share some options but one of them uses all tick boxes and the other uses radio buttons.  This is easy to fix but it takes a moment to discover the issue and then code the exception into the make.conf.

Except for the possible build system flaw, using either -t with bulkbuild, or testport for individual ports will help triage problems.  With nearly 2000 ports listed as installed, it takes a LONG time to manually check the options for conflicts, as well as deciding which keywords need to be added into the make.conf before sending it to poudriere.  The config script helps with simply iterating through the list, taking away the need to repeatedly type the command make -C /path/to/port/origin config but I still have to verify that no new keywords affect my overall choices.  The config removal script works without prompting through all ports in the list and takes a bit of time though I can do other things until it finishes.

I choose not to use pulseaudio if possible, and rather have alsa or oss or both.  Other port option choices take a bit more investigation about which one to prefer, such as if ports are identical other than license, or author's philosophy, or if one is lighter or more efficient or more capable, or if any is a dependency for a larger percentage of other ports.  The default port config options are nice but it is a one-size-fits-all approach and tends not to favor something other than oss, or may include nVidia enhancements which I cannot use, or is not adapted for my processor or gpu.  I am likely not alone as an admin of my own system or a FreeBSD user, in that both tend to prefer a greater level of control, or we'd be using something else.

The combination of poudriere, no saved port configs, and a rather large, detailed make.conf (once it and the buildlist are mostly finalized) mean that I can have semi-regular updates to the ports I use with few surprises.  I can set the job to run while I am asleep and much of the time have it nearly finished before I wake.  If something doesn't build, the older pkg remains in cache, and pkg upgrade will not bite me.  Maybe eventually I will investigate the poudriere daemon option or using a cron job to get things a bit more automated, but this is how I relate to poudriere at the moment.  It is a reliable tool I can keep using.

Revisiting the powder keg

I've just decided to install poudriere.  I used it many years ago during a time when the config for it or pkg or both were seemingly in a bit of flux.  Back then, I had set it up and liked how it worked, but I had some troubles over time.  All that I recall now, as its been quite a number of years, is that something relating to the configuration of something caused it to break, I fixed that config but it broke again.  It could be that part of the trouble was my own mistakes.  Whatever it was, I abandoned poudriere for other ports management tools which worked, or none at all.  I believe I went back to portmaster or portupgrade for some time, until having issues with those as well.  So for a while I also used the ports build mechanism directly which had always been rock solid and always should be rock solid, period.

For the last few years I have used synth or direct builds.  Since there have been in this last year or so, a bit of inconsistency with either the ports system itself or flaws with the build which synth cannot parse, I have also made a number of personal scripts.  These scripts help me to rebuild all ports which had been built with dependencies that I wish to remove, dependencies which may or may not have exposed configs.  One can remove a dependency with pkg, and it lists all the ports dependent upon it, but there is no way to reconfigure or rebuild each of them in turn so that an undesirable dependency is eliminated-- especially one not exposed by its config or Makefile.

The same situation is involved when switching default versions of python for example.  I realize that in the distant past (while using PC-BSD as an initial base os) I used a port origin change with portmaster or portupgrade, and I know pkg has something like this. The trouble being, I do not use the first two tools, and I suspect that pkg would affect which pkgs are installed, and may not do everything I desire.  That is, even if I were to instruct any of those ports management tools at invocation that any certain thing would have a port origin change, it would not necessarily rebuild everything involved.  I am not aware of a way to do it with synth alone, either, so went to my own scripts.

I am certainly not expert with #!/bin/sh scripting, and sometimes my errors or changes to tools I use within my scripts cause unintended catastrophic failures.  Recently though a failure lead to getting my GUI functioning again, since the error caused all of libdrm and dependents to be removed.  The script failed to capture the list of what might be removed before it did so, the removal part was intended of course.  I had no idea that libdrm needed to be rebuilt after a kernel rebuild, as I had not needed to do so in the past, it is now in the list of things to rebuild when I ever do so.  Much easier than trying to determine which of any number of things becomes broken, I simply force a reinstall of all candidates.

I had introduced this post with poudriere , which I have now installed, soon I will see what builds with it that fails with synth or which should always succeed with a direct build but does not.  I am uncertain whether any cruft remains from the previous attempt to use poudriere, but whether it is present or not, I still have to look at proper configuration for my system.  The manpage for poudriere mentions a sample self-documented config file /usr/local/etc/poudriere.conf.sample which would be a good beginning and is often what I use initially if such a file exists.  All I need to do (as root since any ports installs, management, and certain directory permissions would require it) is: cp /usr/local/etc/poudriere.conf.sample /usr/local/etc/poudriere.conf

But also of course, I shall look at the copy for what I might need to adjust, enable, disable.  It is good practice to keep the original and revise a copy, or make a backup before revising the original.  Either way, re-obtaining a file is at least a hassle and at most (worst case) impossible, we cannot guarantee remembering all the details.  I tend to refer to instructions for tasks I've done innumerable times like updating kernel & world, and though I sometimes recall some details, I know that "how to update the locate database" is near the end of its manpage, some bad habits I suppose but they remain.  Another recommendation which can be very helpful, is if any config file has a method for including comments or non-operative text, to add a comment to explain to your future self why you made any certain adjustment, possibly add where the tip was discovered.

One of the first things I notice is that poudriere can take advantage of my ZFS filesystem, so I toggle the appropriate settings.  It appears that one MUST adjust this config if adapting the sample file, because the download address for fetch needs to be defined, below is what you get to start.

# Suggested: https://download.FreeBSD.org
FREEBSD_HOST=_PROTO_://_CHANGE_THIS_

I am okay with the suggestion for now, so I substitute that.  Next, I uncomment the data location line and enable portlint with a change from 'no' to 'yes' because why not?

POUDRIERE_DATA=${BASEFS}/data
# Use portlint to check ports sanity
USE_PORTLINT=yes

For the most part I kept the defaults because they are a good starting point or meet my needs.  I chose to enable some debug type capabilities and limited it to 4 of my 6 processors.  I expect that this poudriere config will itself change over time, so this is why I am not providing it in whole nor commenting on every value.  I may list the few items I modified, but for now I believe I could try using poudriere , or perhaps not.  Proof the manpage might need a slight bit of update in that yes it is still technically a valid example but has been unsupported since July 31, 2012:

First you have to create a jail, which will hold all the building infrastructure needs.

poudriere jail -c -v 8.2-RELEASE -a amd64 -j 82amd64

I was about to use 12.1-RELEASE since that is closest to what I have installed on my system, it is actually 12-STABLE or should be-- I need to verify this, because not only do I see my gkrellm showing 12.2 but it says 12.2-PRERELEASE which seems odd if I actually have 12-STABLE installed now.  Maybe I need to make some adjustment to my /usr/src so it will be the newer -STABLE?  Because of these inconsistencies and to verify whether 12-STABLE is a thing for poudriere, I did a google search and found, https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html#testing-poudriere-setup which gives me proof and a bit different syntax below.  The porters-handbook page appears to have been last modified September 11, 2020, 10:26:43 AM CDT, while the manpage is from March 4, 2019

poudriere jail -c -j 11i386 -v stable/11 -a i386 -m svn+https

I will adjust to my needs, and also arrange it to more closely match the command the manpage gave for easier comparison.  This creates a jail, using version STABLE-12, architecture amd64, jailname 12amd64, and mode svn over https.

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

The above seems to work, though I do not like that it sits there not providing more feedback than "Checking out the sources with svn+https..." and after a while that part finally ends while I am not watching, to transition into a full buildkernel and buildworld it seems.  I suspect that had I used a RELEASE version, It would simply download and unpack.  The next step is to create the ports tree for it:

poudriere ports -c

So, now I am nearly ready to test it or do a full-blown run of things I would update on my system.  The manpage tells me to create a plain text file with one port origin per line.  This would be sysutils/gkrellm2 for example, followed by audio/asunder on the next line, and the same for a series of port origins of things I want to build.  Lucky me, due to various struggles with things becoming uninstalled for one reason or other, I already have a number of file lists with this same formatting, both my scripts and synth use these when I have need of them.  In order to begin a bulk build, I reference the file list when I invoke poudriere , pkglist in my home directory is the list used, and the jail for the building is 12amd64:

poudriere bulk -f ~/pkglist -j 12amd64

I chose one of the various file lists, happened to be 'Bunch-of-games' and discovered that I will have to rebuild the kernel and world of the host.  I realize there is probably another way to solve the issue, but it is about time to update anyhow.  This will also guarantee that I have a most updated and proper /usr/src.  The error below is unlikely to occur if a RELEASE version is used since those do not fundamentally change with any applied updates, and such updates are rare in comparison to -STABLE.

[00:00:01] Warning: !!! Jail is newer than host. (Jail: 1202500, Host: 1201523) !!!
[00:00:01] Warning: This is not supported.
[00:00:01] Warning: Host kernel must be same or newer than jail.

In the process of writing another blog post relating to updating kernel and world, I verified that although oddly gkrellm says '12.2-PRERELEASE' my source directory is correct, as the output below shows.  However, even more oddly, gkrellm now shows '12.2-STABLE' after a recent update around the time of writing that blog post.

root@ichigo:/usr/src # svn info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn0.us-west.freebsd.org/base/stable/12
Relative URL: ^/stable/12
Repository Root: https://svn0.us-west.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 365688
Node Kind: directory
Schedule: normal
Last Changed Author: kevans
Last Changed Rev: 365682
Last Changed Date: 2020-09-12 20:44:31 -0500 (Sat, 12 Sep 2020)

And so back to that previous command which was interrupted due to the poudriere jail install being newer than my host system.

poudriere bulk -f ~/pkglist -j 12amd64

Didn't I mention that often there always seems to be yet one more error to correct?  This is especially true in the process of doing something new, setting up a new tool or process.  Here is another interruption, another error.  I chose to use ccache and have used it with synth or with ordinary (direct) port builds too, but now a config for poudriere needs adjusting, or the ccache config, or the ccache install itself.

[00:00:00] Creating the reference jail... done
[00:00:01] Mounting system devices for 12amd64-default
[00:00:01] Mounting ports/packages/distfiles
[00:00:01] Using packages from previously failed build: /usr/local/poudriere/data/packages/12amd64-default/.building
[00:00:01] Mounting ccache from: /var/cache/ccache
[00:00:01] Mounting packages from: /usr/local/poudriere/data/packages/12amd64-default
/etc/resolv.conf -> /usr/local/poudriere/data/.m/12amd64-default/ref/etc/resolv.conf
[00:00:01] Starting jail 12amd64-default

[00:00:02] Error: CCACHE_STATIC_PREFIX used but /usr/local/bin/ccache is not static.

[00:00:02] Cleaning up
12amd64-default: removed
12amd64-default-n: removed
[00:00:02] Unmounting file systems

According to the error above, I believe the issue is that /usr/local/bin/ccache is a symlink, but I will have to check this to be certain and then I need to look at whether the poudriere config is what needs adjusting in some way to relate to it differently.

My first thought was wrong, static meant built with integral libraries instead of shared libraries, so the fix is an adjustment to the poudriere config, or a reconfigure and rebuild of ccache.  I want to use ccache, and I should have read the poudriere configuration file more closely because it describes my mistake perfectly.  My ccache was not built statically, so I will need to rebuild it.  Hopefully a statically build ccache will not cause trouble with any other use of it as with synth or direct port builds.  We usually learn more from our mistakes, but without this blog post I might not remember from one time to the next.  So the rebuild of ccache with the revised 'static' config option enabled went much faster than I would have ever expected.

Now one last time to repeat that same command to initiate the build of some games, the list renamed to pkglist.  No errors, it gets past the last hiccup and begins the building of those ports in the list.  It seems that pkg itself had updated since the last time I built any ports by any method recently, so it is the first thing poudriere builds.

[00:00:00] Creating the reference jail... done
[00:00:01] Mounting system devices for 12amd64-default
[00:00:01] Mounting ports/packages/distfiles
[00:00:01] Using packages from previously failed build: /usr/local/poudriere/data/packages/12amd64-default/.building
[00:00:01] Mounting ccache from: /var/cache/ccache
[00:00:01] Mounting packages from: /usr/local/poudriere/data/packages/12amd64-default
/etc/resolv.conf -> /usr/local/poudriere/data/.m/12amd64-default/ref/etc/resolv.conf
[00:00:01] Starting jail 12amd64-default
[00:00:01] Copying host static ccache from /usr/local/bin/ccache
[00:00:03] Logs: /usr/local/poudriere/data/logs/bulk/12amd64-default/2020-09-16_17h59m11s
[00:00:03] Loading MOVED for /usr/local/poudriere/data/.m/12amd64-default/ref/usr/ports
[00:00:04] Ports supports: FLAVORS SELECTED_OPTIONS
[00:00:04] Gathering ports metadata
[00:00:12] Calculating ports order and dependencies
[00:00:13] pkg package missing, skipping sanity
[00:00:13] Skipping incremental rebuild and repository sanity checks
[00:00:13] Cleaning the build queue
[00:00:13] Sanity checking build queue
[00:00:14] Processing PRIORITY_BOOST
[00:00:14] Balancing pool
[00:00:14] Recording filesystem state for prepkg... done
[00:00:15] Building 534 packages using 4 builders
[00:00:15] Starting/Cloning builders
[00:00:16] Hit CTRL+t at any time to see build progress and stats
[00:00:16] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.15.4
[00:02:11] [01] [00:01:55] Finished ports-mgmt/pkg | pkg-1.15.4: Success

Once this finally finishes, the next thing to figure out is how I will use the ports that poudriere builds into pkgs on the host system for poudriere, or in other words, how I can build with poudriere and use the pkgs it creates on the same box where they are built.  This could be sticky, I believe it is mostly how pkg repos are configured, and I believe I can simply add one more repo definition to those already present in the configuration file.  My system seems mostly responsive during this build of 534 packages, the list I gave was not even forty games, but gkrellm shows all six processor cores at above 90% use and top so far says load average of about 13!

In all fairness, right now I have firefox running with multiple windows, probably a hundred tabs, and one has a flash game in a tab.  I'd exit firefox to see but since things are responsive I'm not too concerned right now.  So far, 122 ports built in about 30 minutes with my loaded firefox running.  Since I am more curious, I will now quit firefox to see what the difference will be.  There was no drastic change as I may have expected.  The load average depending upon what was being built reached as high as 20, often hovering around 18, and gkrellm showed the processors at 90% much of the time.  All this means that firefox was not itself causing the high load averages or processor use.

The build finished and the last lines are below which followed a huge paragraph listing all the ports successfully built.

[07:18:43] Failed ports: lang/rust:build
[07:18:43] Skipped ports: games/veloren
[12amd64-default] [2020-09-16_17h59m11s] [committing:] Queued: 534 Built: 532 Failed: 1   Skipped: 1   Ignored: 0   Tobuild: 0    Time: 07:18:40
[07:18:43] Logs: /usr/local/poudriere/data/logs/bulk/12amd64-default/2020-09-16_17h59m11s
[07:18:43] Cleaning up
12amd64-default: removed
12amd64-default-n: removed
[07:18:43] Unmounting file systems

I cannot say right now whether my /etc/make.conf which is normally used would have meant that every port would build, or that port configurations which stray from default (as is often my preference) would affect the build either.  There is mention, I believe in the poudriere manpage about copying a directory or linking it into the poudriere jail which would cause those port configurations to be used.  I also realized after initiating the poudriere build that I forgot to set it up to use my make.conf as well.  This means that although all those ports built on my system, they all used defaults, and therefore any number of them would be incompatible with what I have installed now.  So I will need to correct those missing items I described and then do another build of the same things or other things.  The good part is that having been run once, some things will be in its cache or that of ccache and the successive runs should each be a little faster, especially when dependencies are satisfied without needing to be built or rebuilt.  There are quite a number of ports I build which use a default configuration.

First lets see what needs to be done for the port configs and then for the make.conf.  Once those are set properly, I will also need to investigate how the repo built by poudriere would be accessed so as to install those packages, and set that in the appropriate pkg configuration file.

The port configs that I already have been using, that have been set by having built them at least once can be copied, the manpage says this:

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

My customized make.conf can also be used by making a symbolic link because then all methods I might use for building will remain synchronized.  It would probably be better that the ports configuration directory be made accessible to poudriere as a symbolic link as well, but maybe I should have a seperate vanilla poudriere jail which would use default configurations.  The manpage mentions the make.conf as below:

    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

There are additional filenames which poudriere will use but the above is the first one and the most simple which I believe is the global one.  If I were to set one per jail I would use a slightly different name:

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

Now that I know how to get the port configs and my custom make.conf into the poudriere build system, there remains one more thing to clarify.  My minetest Makefile is modified, so do I modify the copy in the ports tree of the poudriere jail or use some other method?  Since I cannot find anything in the manpage that directly and specifically covers this situation in any other manner, I will copy or symbolic link to the modified Makefile for minetest or for any other port which has a custom Makefile I create.

Now that all of the details are finally set properly for that same list of games to be rebuilt, I can initiate a repeat poudriere build, but after I update the ports tree since it has been a few days.  The only remaining task is to configure the pkg repo.  Below, the manpage does mention the location of the poudriere created pkgs, the jailname will be different of course.

    [Find your packages]

     Once the bulk build is over, you can meet your shiny new packages here:

           /usr/local/poudriere/data/packages/81i386

     with 81i386 as the name of the jail.

The manpage for pkg mentions to see pkg.conf(5), which means:

man 5 pkg.conf

which gives you its manpage and contains the applicable instruction below:

REPOSITORY CONFIGURATION
     To use a repository you will need at least one repository configuration
     file.

     Repository configuration files are searched for in order of the
     directories listed in the REPOS_DIR array, which defaults to /etc/pkg/
     and /usr/local/etc/pkg/repos/.

     Filenames are arbitrary, but should end in ‘.conf’ For example
     /usr/local/etc/pkg/repos/myrepo.conf.

There is also mention of an example file /usr/local/etc/pkg/repos/example.conf and details for how the repo.conf file should be constructed using ucl format, as well as a repo.conf example in the manpage text itself.  Personally, I have more trouble adapting a rather specific example to my own needs than I do with adapting a generalized example or picking and choosing options in a very well commented configuration file.  I often have a weird corner case as my need which is different than much of the documentation examples or I expect to do something which is not illustrated.

So my next step is to get the make.conf file set:

ln -s /etc/make.conf /usr/local/etc/poudriere.d/12amd64-make.conf

Lets try to use a symbolic link for the ports config below, I believe this should work but the manpage was slightly unclear whether I should copy the contents or the directory into the poudriere location.  I will simply link the two, which would be more like copying the contents.  The options directory does not yet exist, even after the previous ports build so i can be rather certain they were all built with defaults.

ln -s /var/db/ports /usr/local/etc/poudriere.d/options

I am usually confused about the order of the two when I create a symbolic link, I happened to be right for the first one and used the same order for the second one.  If I do a long list for each of those two symbolic links, this is what I see which is correct:

# ls -l /usr/local/etc/poudriere.d/12amd64-make.conf
lrwxr-xr-x  1 root  wheel  14 Sep 19 14:26 /usr/local/etc/poudriere.d/12amd64-make.conf -> /etc/make.conf

# ls -l /usr/local/etc/poudriere.d/options
lrwxr-xr-x  1 root  wheel  13 Sep 19 14:45 /usr/local/etc/poudriere.d/options -> /var/db/ports

Since using the packages which poudriere builds involves the last step and would be pointless if the most recent changes fail, I am going to test those two symbolic links by having poudriere build that same list of games, the command was:

poudriere bulk -f ~/pkglist -j 12amd64

The two symbolic links work.  I am pleased that poudriere can handle an include at the end of one file to extend the make.conf with a second file, however, poudriere halts and gives the error message below:

make: "/etc/make.conf" line 67: Cannot open /usr/local/etc/synth/LiveSystem-make.conf
make: Fatal errors encountered -- cannot continue make: Unknown modifier ':'
make: Unknown modifier ':'
make: "/etc/make.conf" line 67: Cannot open /usr/local/etc/synth/LiveSystem-make.conf
make: Fatal errors encountered -- cannot continue eval: make:: not found
export: make:: bad variable name

After a little investigation I discover that where poudriere will balk, the error is otherwise ignored as far as I know, or it might silently fail and the lines that follow it are then ignored.  What it was, is a non-existent port which is referenced in my make.conf and due to no longer being present, the variable is invalid which poudriere doesn't like and halts.  This should be true regardless, but possibly another variable construction would silently fail as it should because in this section of my make.conf I am only offering potential areas which may require kerberos which is an issue for some builds.  Until I can figure out the new variable construction, I will leave things as they are and remove the lines which cause the failure.  The line given as the error is after the actual error which is interesting and can lead to frustration, so either look to the line prior to the error or doublecheck any such variables which rely upon existence of a directory in the ports tree.  The lines I removed from the/usr/local/etc/synth/LiveSystem-make.conf file are below, I highlighted the part which is the variable construction.

.if ${.CURDIR:M*/ports/devel/electron8}
  OPTIONS_UNSET+=KERBEROS
.endif

I'll try once more and see if poudriere will build.  Did I ever mention that I am rather gifted at discovering unexplainable errors?  So, the error above is something which did trip up poudriere, BUT, and this is the weird part: if I combine the two files which comprise my make.conf, the error which poudriere tells me still remains on the same line number will no longer be an error and the build will start just fine.  It looks like I will need to look closely at the two files, one which is rather tiny has an include for the second file which adds the bulk of my adjustments, and figure out what to do about having them both and whether synth needs them that way, or any other building needs them split.  Until I decide, and in order to finally succeed with poudriere, I am going to combine the files into one large make.conf, and be done with it for now.

Once more I have forgotten about the modified minetest Makefile, so the build poudriere is working on now will not be all that I would wish it to create.  It will be good enough for proof of build and for accessing as a pkg repo.  When it finally finishes after less than seven hours I expect, I can look at the pkg repo access part, those docs for it I really do not like.  I saw a BastilleBSD arrangement which would have poudriere building ports for a bastille jail, so maybe I can look at any repo configuration it has, except of course the rule of google says that any half-remembered data can not easily be re-found.

It built about 3 hours faster the second time but a number of things failed also.  I believe a good chunk of those items which did not build were due to my own port configuration choices.  Yes I am avoiding the pkg repo step.  Since I set poudriere to use the same ports options database as the ports tree outside of poudriere , I was able to adjust a couple ports which i saw failed to build.  Now I will try to get more successful builds in four hours or less but first lets update the poudriere ports tree:

poudriere ports -u

[00:00:00] Updating portstree "default" with portsnap...Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found.
Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Updating from Fri Sep 11 14:55:09 CDT 2020 to Sat Sep 19 20:36:39 CDT 2020.
Fetching 4 metadata patches... done.
Applying metadata patches... done.
Fetching 4 metadata files... done.
Fetching 839 patches.
(839/839) 100.00%  done.

Perhaps I should have updated the ports tree before the first attempt?  We are nearing another FreeBSD release but 839 patches to the ports tree seems like a rather large number to have all at once.  After some port config tweaks which I can do from outside of poudriere (because of the symlink to the ports config directory) all but one of the games successfully builds.

The last step, getting access to the built packages repo.  The answer seems to have always been present.  In /usr/local/etc/pkg/repos is a file for the synth repo which describes itself as automatically generated, and has all the information I need to create a repo file for the poudriere packages.  What it began as is below:

# Automatically generated.

Synth: {
url      : file:///var/synth/live_packages,
 priority : 0,
 enabled  : yes,
}

What I modified it to be for the new file called my_poudriere_repo.conf looks like this:

# Set for test 9-20-20 8:20pm

poudriere: {
  url      : file:///usr/local/poudriere/data/packages/12amd64,
  priority : 0,
  enabled  : yes,
}

I believe that when something is found by pkg for install it will place the name (highlighted) into square brackets.  This means that those names could be anything descriptive or useful but I would limit them to one word to be safe, spaces might need to be handled a special way but its easier to just keep the name simple.  The priority can be adjusted to make the new repo more important if I increase that value in the synth repo file.  It seems like most things are working but when I test the new pkg repo, it gives me an error:

root@ichigo:~ # pkg install minetest
Updating Synth repository catalogue...
Synth repository is up to date.
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating poudriere repository catalogue...
pkg: file:///usr/local/poudriere/data/packages/12amd64/meta.txz: No such file or directory
repository poudriere has no meta file, using default settings
pkg: file:///usr/local/poudriere/data/packages/12amd64/packagesite.txz: No such file or directory
Unable to update repository poudriere
Error updating repositories!

I believe this was a sticking point when I used poudriere years ago.  I will have to look into how those files can be generated after any update to the built packages.  I would have hoped it might be automatic.  I looked in the poudriere.conf file and did not see anything right away.  I didn't notice that there was a slight error with the pkg repo path, which means the manpage for poudriere needs another adjustment for accuracy, so in order for it to work, I need to modify that repo file slightly to look like this:

poudriere: {
  url      : file:///usr/local/poudriere/data/packages/12amd64
  priority : 0,
  enabled  : yes,
}

I discovered the error because I was attempting the command below which I believe is what will finally initialize the repo as an accessible pkg repo on the system.  This might also automatically occur if the file above had been correct when I tried to install a pkg.  I am not sure whether this is now final and I will not need to repeat the command below, or if I should execute it periodically.  If I am right that pkg will self-update each repo when attempting to install a pkg, then I am done.

pkg repo /usr/local/poudriere/data/packages/12amd64-default

So now I will again attempt to install minetest and see what it does.

The following 3 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        libgee: 0.20.1 [poudriere]
        openblas: 0.3.10,1 [FreeBSD]

Installed packages to be REINSTALLED:
        minetest-5.3.0 [Synth] (direct dependency changed: jsoncpp)

Number of packages to be installed: 2
Number of packages to be reinstalled: 1

The process will require 87 MiB more space.
7 MiB to be downloaded.

Proceed with this action? [y/N]:

This is very interesting.  Three different pkg repos will be or could be used to satisfy the install.  I know that the FreeBSD repo is remote and uses all defaults, the synth and poudriere repos are local and both use my port configurations (not default) or modifications.  This also indicates to me that I may want to look at jsoncpp a little more closely.

Now I have multiple options to obtain a pkg to install as well as multiple methods for building them.  I do not have any definite plans on which method I will use most but I'm sure that eventually I may favor one over the others, possibly poudriere, and I still need to copy that minetest Makefile into the poudriere jail, and I should not forget to hide the patch file as well (all this mentioned in Minetest better).  The applicable directory is /usr/local/poudriere/ports/default/games/minetest but note default in the path, which I believe means I could possibly have a modified ports tree or other custom poudriere, and likely ties to the above mentioned repo config.

One other thing I have discovered while writing this blog post over the last week or so, is that it helped me be a bit more meticulous and detail oriented from start to finish because I wanted to provide all that information for anyone who may read this.  Writing about it nearly step by step meant that I could keep track of my progress and know where I left off when I had to put the project on hold.  I may have eventually succeeded but this process helped me work in a less random "scattershot" way.  I think I should write a blog post about any new things I attempt as it will be useful to us both.

Kernel and world rebuild

I prefer to use the -STABLE branch which means there are many more updates compared to RELEASE.  I try to do an update once a week or at least a couple times a month.  This is not a particularly difficult task but I still refer to a printout of a tutorial page from an old BSD Now podcast.  I have a number of customizations which I have used in the past along with a custom kernel, but I have not used them lately, or at least not the customized KERNCONF.  This entire process will need to be done as root due to standard default permissions.

** Please note that FreeBSD switched to git and so svn is not the method since Dec 18th 2020 or so. **

If you have not done so already, you will need to obtain the source for the build you intend to use.

git clone -b master --single-branch --depth 1 git://github.com/freebsd/freebsd.git /usr/src

 Github changed security in September 2021 

git clone -b master --single-branch --depth 1  https://github.com/freebsd/freebsd.git /usr/src

and then to prepare now for future updates do:

git config pull.rebase true

Since I use the stable branch of version 12, below is how I obtain a specific branch:

git clone -b stable/12 --single-branch --depth 1 git://github.com/freebsd/freebsd.git /usr/src

git clone -b stable/12 --single-branch --depth 1 https://github.com/freebsd/freebsd.git /usr/src

Assuming you hadn't just completed the above, or sometime next week you choose to rebuild, one of the first steps is to update /usr/src.  This can be as easy as changing to the directory /usr/src then type git pull.  Either before or directly after this step, it is very important not to have any leftover remnants from the previous builds, use the command make cleanworld, and then to be sure, the command make clean, prior to any building.

Now that the preparations have been made, we can begin.  You can take advantage of multiple cores in your system by setting one job per core or cpu.  If you are uncertain you can check by sysctl -n hw.ncpu and place the resulting number after -j for the number of jobs.  Wow, I just realized that I hadn't used all my six cores the last time I rebuilt my kernel and world.  I would have had I used the command below, because it will always provide the correct number, supposing I have 8 cores sometime in the future I wouldn't be using only six for the build.

make -j `sysctl -n hw.ncpu` buildworld

Now that that is complete, I can do the next step. This one I discovered can be combined with the step after it, as below.  This explicitly defines the kernel configuration file, which must reside in /usr/src/sys/amd64/conf as a real fle, or a symlink to it from your home directory which is a good way to keep it against accidental erasure. By using kernel rather than buildkernel the scripts involved will build and install the kernel in the default location, so this is particularly helpful if the process is unattended such as a slow task handled while the admin is sleeping or handling other matters.

make -j `sysctl -n hw.ncpu` kernel KERNCONF=GENERIC

Although I have had a custom kernel in the past, and I still have the modified kernconf file, I am using GENERIC because shockingly, I had some difficulties. My troubles with booting and with kernel builds have been primarily related to graphics. I think I have a decent handle on them now, but rather than use the monolithic configuration I made, I want to take a closer look at how it compares to GENERIC and also discover which items can be built as kernel objects. Once I know that, I would limit kernel object builds to those I need or might use, and reduce rather than increase the kernel by removing things I never use.

The next step is to go to single user.  This I do with a reboot which also verifies that the kernel I just installed functions as intended to that point.

reboot

Watch for the FreeBSD startup menu, press space as needed to pause it -- it may be set to be a very short countdown here, then choose 'singleuser' by hitting '2'.  It is NOT recommended to use another shell for handling the buildworld or buildkernel processes, so when it finishes and shows the prompt below, tap the return or enter key.

Enter full pathname of shell or RETURN for /bin/sh

As I mentioned in another blog post, now I can't boot the way to access /usr/src again requires some mounting actions, below mounts all items in /etc/fstab as read-write.

mount -u /

and then if your system is ZFS rather than UFS, this mounts all datasets:

zfs mount -a

Once in /usr/src there are a few more things to do and then we can reboot into the new system.  First, what the manpage calls a pre-buildworld mode mergemaster which compares the installed /etc/group and /etc/master.passwd with the new defaults so that you can choose what to adjust as needed, and then the install command.

 Mergemaster removed Nov 20, 2023 replaced by etcupdate. 

Function of etcupdate is essentially the same, pre-buildworld option remains -p for this step.

mergemaster -p

etcupdate -p

make installworld

Should you see the message below, which can appear,

At installworld Make: "/usr/src/Makefile" line 360: Check your date/time

it is a simple fix, type the following command to continue:

adjkerntz -i

Now that the error is corrected, finish the command that was interrupted:

make installworld

The next steps will help update configuration files, allow you to merge your customized lines with the new file as needed, while automatically handling those files which are essentially identical or have not been user-modified.

mergemaster -iUF

etcupdate -n

     -n             Enable “dry-run” mode.  Do not merge any changes to the
                    destination directory.  Instead, report what actions would
                    be taken during a merge

etcupdate

It is good practice to be certain old libraries and other assorted files are not left around to cause problems, especially true between updates of major versions, so the next two commands will help remove all of them automatically. The command below, yes repeats 'y' to fulfill prompts, thus agreeing to each deletion which automates the script.  Yes as described by its manpage can be used to repeat any text.

yes|make delete-old

yes|make delete-old-libs

Now that everything is finished, you can reboot one last time to load up and use your newly updated system.  If for any reason there is a failure with booting, refer to now I can't boot for some steps to help solve it.

Goin High Def

I recently made a significant upgrade to the monitor my primary system uses.  I knew there would be a bit of adjustment to make, but when I unplugged the HDMI cable from the retired Samsung TV and attached it to the new Samsung 4k monitor, everything seemed to be about the same.  There was nothing to adjust, no issues with the display that I could see.  This all changed when I decided to reboot my pc.

There didn't seem to be anything I could do to make my GUI behave the same as it once had, to fill the whole of my new monitor without first having black bars on the left and right, then later it was all simply a horribly bad dpi on a formerly HD monitor.  One of the first things I tried, was in hopes that the solution was simple, that for whatever dumb reason my video card couldn't see the proper screen size and by extension wasn't reporting this to the OS.

My interim solution prior to this was to temporarily power up my old monitor, attach it by HDMI to my pc, then reboot and let the software set things up as they had been.  After X was up on the old monitor, I could plug the HDMI cable into the new display which would then retain the better dpi until a reboot.

I bought a new DisplayPort cable because it has more capability than even my supposedly HD capable HDMI cable which I bought because an older cable began to fail.  I plugged in the new cable, rebooted to get the graphics card to use the proper port, and nothing, things were no better.

The next change was in many ways a fluke, because it was an adjustment I made which had been working just fine so I had no idea that it could be the one detail to begin to get everything working right, finally.  Before this change, I tried variations on two lines for the kldload of the correct driver, first radeon and then amdgpu and back again.  When that was eliminated as the reason (and it was working though still bad resolution etc.) I removed the comments from what ultimately cured nearly everything.

#WITHOUT_DRM_MODULE="YES"
#WITHOUT_DRM2_MODULE="YES"

And now we both see why I am baffled.  I swear I had enabled those two lines which lead to the solution, but to write this blog post I just went to the /etc/rc.conf file to discover them commented out!  Did I not do as I believed I did?  Or maybe somehow something automatically recommented them out?  I have no idea, so I guess I will have to continue with the other issues which I solved and assume that I must have forgot, that the driver was the issue perhaps.

I regretfully do not have any screenshots to show, which would describe the remaining issues.

Nearly everything about firefox was extremely tiny.  Most webpages rendered with what appeared to be maybe an 8px font instead of a more legible 12px.  It took a bit of time to finally stumble upon the solution because we all know how easy it is to find technical answers with google.

What I discovered is that yet again firefox does things itself rather than abide by the host or its environment.  The fix is done by adjusting an about:config setting.  I discovered that mine had been set to .9 which may be default and this could be reason for some oddness in how firefox is different than other browsers.  The setting below seems pretty close to perfect.

layout.css.devPixelsPerPx 1.50

That was the first adjustment for firefox, as it still insisted upon using a second set of mouse cursors and at much larger size than my fvwm desktop UI, which was distracting and annoying.

It seems that at least for the *nix/*bsd world that gtk3 is used by firefox and this is what is overriding the mouse cursor settings.  So to fix this, or get rid of the gtk choice, I edit a file to remove one line.  Edit ~/.config/gtk-3.0/settings.ini to remove the line which defines it:

gtk-cursor-theme-name=whiteglass

So now that my firefox was looking almost normal again, I could work on the remaining GUI issues.  One is to adjust fvwm to have a larger mouse cursor as it is just barely usable size.  I figured out how to make whiteglass mouse cursor theme as an overall default on my desktop as I've always liked its style.  These changes were made for X and fvwm honors them.

Edit ~/.Xdefaults or ~/.Xresources to include lines:

Xcursor.theme: whiteglass
Xcursor.size: 22

My default font size for xterm was also modified by adding the line below to ~/.Xdefaults which may still be a little small but it is much better than what would be.

XTerm*Font:-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1

Beastie says 'hello world'?

Hey there!

Once upon a time, in a galaxy far far away, there was..

It has been a long time since I wrote a BSD blog, specifically FreeBSD, but it was under nearly the same name.  Long ago in this galaxy, on Earth, there was an OS called PC-BSD.  I came to it from Windows because of a weird motherboard hiccup which invalidated the onboard ethernet.  I have no idea whether it was a hardware malfunction or what but suddenly I had no ethernet.  I had an old 10/100/1000 ethernet card (I think it was 3com) which I believed should work, so I installed it and booted up.

Windows pretended the card was not there, so I tried for a short while to get it to work with my Windows 7.  When it became obvious that I couldn't manage that, I knew I would find a solution from open source.  I'm uncertain how I stumbled across PC-BSD, but it seemed like something that would be easier and a reasonable GUIfied experience.  I had used FreeBSD 2.2.6 in the distant past, so it was a return to something I knew --though I didn't know how substantially different that was from the version PC-BSD based itself upon.

Not too long after getting PC-BSD working on my box and having used version 8.0 for a while, I was asked to be involved with their forum site.  I had also been doing some work with the documentation wiki so I was okay with other efforts to help the project.  I ended up an admin and moderator there, created a decent theme to improve the layout and appearance of the site.  While PC-BSD was an active project, there was a sort of side site which allowed me to create a blog there.  That blog had almost the same name as this one, sadly all the content has gone but that is fine as much of it would be woefully out of date now.  PC-BSD has since ended, I've become active as admin and mod for the FreeNAS forums, now iX Community.  Near the end of PC-BSD, I chose to switch to FreeBSD, the stable branch, and have been using it ever since.

Perhaps you know me from FreeNAS, or PC-BSD, or twitter, or maybe you've encountered a bug report I've submitted.  Maybe you met me at a BBS get together, or a local ISP "wump", or we chatted on any number of BBSes that were so very cool in the early days of the internet.  I chose this nick long ago.  I have another blog which has languished a bit.

Here I am writing about FreeBSD, my experiences and troubles, solutions and tips, and the occasional rant.  If I have discovered something cool, or new, even if it is not directly related to FreeBSD but is usable from it, I'll post about it here.  This is going to be technical at times but I hope to offer as clear and precise directions as I can when appropriate.  I welcome comments, requests, and opinions.  I intend to label these posts in a suitable way so that it should be easier to find things later, so that this blog can be a resource in the years to follow.