In D56474#1336929, @ivy wrote:

In D56474#1317500, @markj wrote:

I don't really see how this is going to stay up-to-date: this seems to depend on developers remembering to update the file each time they add a dependency.

i agree and i object to landing this as-is; this simply isn't a workable solution.

when the original SBOM proposal was announced, i was disappointed when FF declared that pkgbase was out-of-scope for that work, but it seems like this and pkgbase and trying to solve similar problems when it comes to dependencies. can we not find a solution that works for both without requiring manual upkeep?

No longer build bomtool(1) and spdxtool(1) with NO_SHARED in the tooling phase. (Reported by imp@, thanks!)

This should fix the cross-compilation of libpkgconf while building bomtool(1) and spdxtool(1) as tools.

I just saw that this breaks cross-compilation, when building libpkgconf early for bomtool(1) and spdxtool(1) as tools for SBOM generation:

Generate SPDX files in version 3.0.1 as well by default, now that spdxtool(1) has been imported into the base system.
Sets the correct version of FreeBSD automatically into the SBOM files generated for FreeBSD's own software.

Removed use of NO_SHARED for the test binaries.

In D58034#1333641, @markj wrote:

Are the tests all passing now?

Copied missing data.
Registered the missing test directories in etc/mtree/BSD.tests.dist.
Forced a C locale to avoid the UTF-8 test. (Original test file removed from our import because of UTF-8 filename)

Now copying most of the test data required: only 2 tests do not pass on my local setup (the spdxtool binary is required and I have not installed it yet).

Also hooked the serialisation test for spdxtool.

Added the SPDX license header.
Added discovery mechanism for the location of the test executables.

Imported more tests from the 2.9.93 release.
Some still remain to be integrated, like for spdxtool specifically.

Fixed inconsistent indentation in etc/mtree/BSD.tests.dist.

• Update wording for packages/pkgconf/pkgconf.ucl, as per Mark's suggestion.

• List SRCS and INCS with one line per file, as per Mark's suggestion.
• Clarify where the information was gathered from.

Build a missing file for spdxtool(1).

Imported in ebcc78644e0cbc4141807c0887ef8d902cb91bb4.

Removed a test folder in tests/lib1 which broke the generation of source packages (UTF-8).

In D57628#1321573, @markj wrote:

How does one verify that a given executable is compiled with FORTIFY_SOURCE > 0?

Imported adjustments from Tuukka.

Remove redundant code, as suggested by des@. (Thanks!)

Removed redundant braces.

Simplified the code obtaining LOCALBASE as per @des' suggestion. (Thanks!)

• Avoid file conflicts in the -lib32 base packages (no duplicate installation of SPDX files)
• Rename the PCFILE variable to SBOMFILE to avoid confusion with PCFILES
• Fix typo in libmd.pc (thanks stephane.rochoy_stormshield.eu for the heads up!)

Use a stack buffer of MAXPATHLEN for localbase, as suggested by @des.

This update takes care of PERSONALITY_PATH in addition to PKG_DEFAULT_PATH.

In D56404#1309826, @markmi_dsl-only.net wrote:

What is the relationship of this type of change to use of ${PREFIX} when ports install themselves and it is not the /usr/local default value? (There is also a linux compatibility related standard default for PREFIX and folks can specify things like /opt .) There was a later change to use /usr/local/ when LOCALBASE was undefined.

But in response to that last change there is now from eduardo@freebsd.org :

This change doens't honour PREFIX when it is set to other path than
default "/usr/local/"

(Due to the message Nuno picked to reply to I ended up listed as the "To:", des and the lists Cc:'d.)

I figured I could at least ask the question here of the folks involved in the original review so that the question is not completely lost.

In D56474#1308969, @ivy wrote:

a couple of comments:

• i'm not sure this should be in release/, since it doesn't seem specific to building releases. iiuc, any src build will include the SBOM data if enabled.

In D56474#1309051, @ziaee wrote:

One thing we may want to investigate is building the SBOM files into the ELF headers instead. Sony has compiler extensions to do that -- https://github.com/sony/esstra/tree/poc/rust-llvm

• The SPDX files are now placed in their respective base packages.
• The source .pc files from illuusio were imported into release/sbom.

LGTM, thanks!

In D56591#1296034, @khorben wrote:

In D56591#1295928, @khorben wrote:

The latest update (with WARNS?=3) built correctly with clang; I am still testing with GCC 14.

It built correctly with GCC 14 as well.

Reverted the copyright to myself, and the license to ISC.

In D56589#1296262, @ngie wrote:

In D56589#1296252, @khorben wrote:

I gave the copyright back to pkgconf, as the comment and description primarily come from the pkgconf project.

While there, I also updated the SPDX-License-Identifier to pkgconf, as per the discussion here, and confirmed at https://spdx.org/licenses/pkgconf.html.

Does that mean that you need to credit DuckDuckGo or Google whenever you find a result?

I gave the copyright back to pkgconf, as the comment and description primarily come from the pkgconf project.

Updated the copyright, license text, and added the licenses = [ "pkgconf" ] as per ngie's advice; thank you!

In D56591#1295928, @khorben wrote:

The latest update (with WARNS?=3) built correctly with clang; I am still testing with GCC 14.

This is already in D56589; which version is best?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294724 confirms this patch to be fixing the build issue.

The latest update (with WARNS?=3) built correctly with clang; I am still testing with GCC 14.

Disable stricter warnings for the moment for libpkgconf, bomtool(1), and pkgconf(1) as suggested by ngie. Thanks!

This should address feedback from ivy:

Imported in 6294b6ab217a2d5f1d2bc23a64505a228294c508.

This addresses feedback from ivy, moving /usr/include/pkgconf into the pkgconf-dev package.
It also adds the files in /usr/include/pkgconf to the list of obsolete files when disabling the pkgconf option.

This update addresses feedback from bapt, more precisely:

In D56373#1291176, @bapt wrote:

I don't understand the point of merging both version why not only the latest ?

This patch adds /usr/local/etc/pkgconfig/personality.d to -DPERSONALITY_PATH in lib/libpkgconfig/Makefile, as requested by bapt at https://ron-dev.freebsd.org/FreeBSD/src/pulls/9.