I disagree and fixed the stup of developers@ so now it accepts mails in BCC? if not, please ping me.

In D53539#1222315, @des wrote:

I don't think this is the correct solution either. For one, it is a local fix for a problem that affects all libxo consumers. For another, it will use the wrong decimal separators when emitting HTML (which should be localized, but won't if this patch is committed). I think libxo should be modified to always use the C locale when formatting numbers in json output, and bd490be57438 should be reverted.

you should probably also add this manually to the non unicode "frozen" locales

if we want to be pendantic we need to keep those dependencies as the boostrap java really need those, the reason they are not in lib depends in the port is probably because the sole purpose of the boostrap java is to be used as a bootstrap tool to build other jav implémentation which works even without X11.

SHLIB_REQUIRE_IGNORE_GLOB=* should do what you expect

well it claims it has no dependency but it does have, so what you want here is to entirely prevent analysing the elf files if any. We might want to still require the one from base.

None of the libraries listed as required here are bundled, so it has done the right thing and the bootstrap now do not provide lib anymore so it will never be proposed instead of a regular openjdk

sorry this tool is confusing, and swallowing your properly formatted patch, maybe it is just me would do not know how to properly retrieve this patch properly, in the mean time if you can send it to me by email, I will be able to push it straight thanks.

good catch thank you, can you provide me a git format-patch generated file so you can get proper credit ?

Considering that if one sets UseBlocklist yes and blocklistd is not installed at all, will just result with the same behaviour as with blocklistd installed but not started I think the is ok to split the packages this way.

the ports tree is a framework to build packages, if we are to build sbom on a distribution of packages we don't want to work on the framework which builds repositories, but on the package repository side. Meaning in the ports tree we need to make sure we collect enough metadata so that packages themselves have enough metadata for a tool like this one to collect the informations from the packages directly and not from the sources.

to be honnest I am not a big fan of this being adding to the ports tree, because usually the sbom analysis (my use case at least is on what would be reployed, so it needs to happen and the packaging level more than at the source level imho.

LGTM and I like @kevans proposal.

should fix the issues spotted by scaleway people as well

this is not for all case because people may have multiple checkouts of the source tree (other than /usr/src) this is good only for releases.