This one may need a Makefile patch to remove -I/usr/local/include and -L/usr/local/lib. Check if it then compiles without USES=localbase; after all, it seems to be using pkg-config to find its dependencies. I recommend USES=localbase:ldflags instead of USES=localbase.

Would it be a good idea to ship the glyph builder python script?

Category misc seems weird. Maybe x11 (remember, wayland stuff too goes into x11), deskutils, or graphics?

Did you test your ports with Poudriere? If yes, what architectures and operating system versions did you test?

In D59517#1365748, @fuz wrote:

This one may need a Makefile patch to remove -I/usr/local/include and -L/usr/local/lib. Check if it then compiles without USES=localbase; after all, it seems to be using pkg-config to find its dependencies. I recommend USES=localbase:ldflags instead of USES=localbase.

I control the upstream, so I can adjust things to better suit ports (read: avoiding a local patch). FreeBSD ports is the first class target of this software, and currently I'm not worried about supporting any other Operating System or build environment (this is squarely for my work with the Framework Laptop 12 system integration -- largely for supporting the media function keys on the Framework keyboards and providing immediate responsive feedback to the user when a key is pressed).

Would it be a good idea to ship the glyph builder python script?

Absolutely, I just had not decided on where to put it yet, and I wanted to bundle an example with it too. I'll make that a priority for 4.0 before I update the review again.

Category misc seems weird. Maybe x11 (remember, wayland stuff too goes into x11), deskutils, or graphics?

You're right, my list of choices to conform to other OSD libraries/utilities was:

a. deskutils
b. misc
c. sysutils
d. x11

Based on what we've already ported:

$ ls -1d /usr/ports/*/{xob,dunst,*osd}
/usr/ports/deskutils/notify-osd/
/usr/ports/misc/xosd/
/usr/ports/sysutils/dunst/
/usr/ports/sysutils/nbosd/
/usr/ports/x11/xob/

Thanks for clarifying that we can stuff Wayland compatible solutions into x11 as well (I intend to support Wayland)

I'll move it to x11

Did you test your ports with Poudriere? If yes, what architectures and operating system versions did you test?

I tested them without poudriere. My test process currently is:

1. portclippy Makefile
2. portfmt -D Makefile
3. make package
4. pkg install -f work/pkg/*.pkg
5. pkg list <name>
6. Exercise the software some

But you are absolutely right, and I was thinking about a lot about how Florence went. That the missing dependencies that I had to add to Florence would have been immediately caught by poudriere because it would have built in a jail without visibility of what's installed on my system.

I'm new to poudriere and getting more comfortable with it. I'll work in a testport run with this before next update.

ASIDE: My first exposure to poudriere was in D58855 wherein I was asked to make sure that the test process for security/linux-rl9-ca-certificates did not break against the kernel VFS patchset

I control the upstream, so I can adjust things to better suit ports (read: avoiding a local patch). FreeBSD ports is the first class target of this software, and currently I'm not worried about supporting any other Operating System or build environment (this is squarely for my work with the Framework Laptop 12 system integration -- largely for supporting the media function keys on the Framework keyboards and providing immediate responsive feedback to the user when a key is pressed).

That's great! So the thing is that LOCALBASE and PREFIX are both user-overrideable, so it's best if the software doesn't add /usr/local on its own. USES=localbase does that correctly.

This fails to build because it expects a python3 binary, which isn't guaranteed to be installed. https://pkg.ftfl.ca/build.html?mastername=16amd64-default&build=2026-09-13_06h47m11s

This is a good example of why testing in the pristine environment poudriere provides is important.

A simple fix is to add BINARY_ALIAS= python3=${PYTHON_CMD} to the port.

In D59517#1368403, @jrm wrote:

This fails to build because it expects a python3 binary, which isn't guaranteed to be installed. https://pkg.ftfl.ca/build.html?mastername=16amd64-default&build=2026-09-13_06h47m11s

This is a good example of why testing in the pristine environment poudriere provides is important.

For the record, 6.0 tested clean in poudriere.

I had not had a chance to re-run test port against 9.1 after adding the build of the examples.

Why? Becuase it was midnight and I had to go to bed

A simple fix is to add BINARY_ALIAS= python3=${PYTHON_CMD} to the port.

It’s 4A.

I’ll handle the updates when I wake up. I just had to feed the babies (nightly; every day between 2A and 4A).

Going back to bed for another 3 hours of sleep.

Will handle the other things after breakfast

In D59517#1368403, @jrm wrote:

This fails to build because it expects a python3 binary, which isn't guaranteed to be installed. https://pkg.ftfl.ca/build.html?mastername=16amd64-default&build=2026-09-13_06h47m11s

This is a good example of why testing in the pristine environment poudriere provides is important.

A simple fix is to add BINARY_ALIAS= python3=${PYTHON_CMD} to the port.

Please use USES=pathfix if possible. We have that USES for exactly this purpose.