In D53807#1232338, @fernape wrote:

Is there anything else that needs to be done here at the moment?

@vishwin Have you had time to check the updated patch? The distutils approach is now behind a switch, being an opt-in.

Remove obsolete patch

rebase onto main

In D53807#1230956, @fernape wrote:

autofirma.jar contains directories linux/windows/osx (sic!) with a binary-bundled certutil, I bet this is libnss3-tools and maybe need to provide certutil.

I don't know the use of that. At least for my simple use (either stand alone or via web) it works fine for me.

I would at least strip all of those foreign binaries from the JAR since they bloat the package w/o any benefit.

I did not inspect the .jar files internally. In orther to do that, I assume I should unpack it and repack the .jar with only the relevant files?

In D53807#1230948, @fernape wrote:

In D53807#1230515, @michaelo wrote:

This port made me curious, though I don't live in Spain:

• Why the hell did they pack a deb package in a ZIP file, clowns
• The data.tar has some interesting things you like have missed:
  • Autofirma.js is for Firefox which will autoinject into prefs.js, it is user.js for Autofirma. You didn't handle this at all. It contains also a path which needs to be fixed for LOCALBASE

Do I need to? The file is packed in case someone wants to install it in his/her home preferences.

This port made me curious, though I don't live in Spain:

• Why the hell did they pack a deb package in a ZIP file, clowns
• The data.tar has some interesting things you like have missed:
  • Autofirma.js is for Firefox which will autoinject into prefs.js, it is user.js for Autofirma. You didn't handle this at all. It contains also a path which needs to be fixed for LOCALBASE
  • What happened to autofirmaConfigurador.jar?
  • Autofirma.png is located next to the JAR, will it be found in a different location?
  • You did not patch afirma.desktop
  • es.gob.afirma.metainfo.xml isn't required? ...and it clearly states that is depends on libnss3-tools

Out of curiousity, since I see Mozilla and NSS here, does the library internally use NSS for something? Does it perform System#loadLibrary()? If yes, you might want to depend on NSS as well. Maybe you should investigate...

In D46236#1225446, @mandree wrote:

How many years is this going to take?

Rework to "git describe --tags"

In D53837#1230021, @driesm wrote:

@michaelo, I rather we keep the bellow fields. You can get them from using git describe --tags.

DISTVERSION= 1.6.2-34
DISTVERSIONSUFFIX= -g73b127

In D53837#1230008, @driesm wrote:

So when I'm understanding correctly, we switch to the ISO timestamp forever.
And in the future when the -devel and normal port diverge more, we use the commit hash and update the iso timestamp to the commit hash in question?

Seems fine for me.

In D53837#1230006, @driesm wrote:

So if we return to using a commit hash, it keeps working with versioning, then it seems reasonable to me.

In D53837#1229977, @meta wrote:

I still want to use DISTVERSION=1.7.0 and not overwrite the version in post-patch. Because the commit e2ebcea and the tag v1.7.0 are identical, and point to the same commit. At this point, the tarball can be shared between vm-bhyve and vm-bhyve-devel. There is no need to keep tarballs with different checksums in distfiles when their contents are identical.

However, this version is now acceptable to me. Feel free to land if it looks good to @driesm.

Update distname and tag name according to Porter's Handbook: https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-master_sites-github-ex2

In D53833#1229951, @driesm wrote:

Sounds good, go for it!! Lets MFQ the -devel port as @meta suggested.

In D53833#1229926, @meta wrote:

I think we can update sysutils/vm-bhyve-devel to 1.7.0 as well. Both are currently at the same version since only a few commits have been added after the release.

If we update the quarterly branch as well, how about updating sysutils/vm-bhyve-devel in 2025Q4 and keeping sysutils/vm-bhyve as it is until the next quarter? This is just a suggestion, though.

Sync with vm-bhyve-devel

In D53813#1229885, @adrian wrote:

In D53813#1229884, @michaelo wrote:

Isn't it better not to have a driver at all rather than having one which is six years old, a preview and heck knows working at all reasonably?

no?

We can always delete it and replace it with another if it doesn't pan out but people have the hardware now and we should have something.

Isn't it better not to have a driver at all rather than having one which is six years old, a preview and heck knows working at all reasonably?

Maintainer, any objection?

Maintainer, any objection?

Just experienced the inconsistency with distutils myself:

In D53766#1228004, @yuri wrote:

I am sorry that I didn't notice this review.

Maintainer has ignored my review and updated the port.

It took me countless hours, but these do build:

archivers/py-cramjam chinese/py-rjieba databases/py-datafusion databases/py-sqlglotrs databases/py-sqloxide devel/py-tox-toml-fmt devel/py-deptry devel/py-qcs-sdk-python devel/py-regress devel/py-rpds-py devel/py-ruff devel/py-pyperscan devel/py-pyproject-fmt-rust devel/py-jellyfish devel/py-orjson devel/py-pendulum devel/py-pydantic-core devel/py-pyproject-fmt devel/py-ty devel/py-watchfiles devel/py-pycrdt devel/py-dbt-extractor devel/py-ormsgpack devel/py-fastuuid devel/py-uv-build08 lang/py-dhall math/py-clarabel math/py-pcodec misc/py-lazrs misc/py-hf-xet misc/py-polars misc/py-pyqir misc/py-safetensors www/py-adblock www/py-jh2 www/py-nh3 www/py-qh3 www/py-granian www/py-pywry www/py-primp security/py-cryptography textproc/py-pycddl textproc/py-jiter textproc/py-tokenizers textproc/py-textual-speedups x11-fonts/py-shaperglot

In D53687#1226367, @kai wrote:

Please check beforehand whether devel/py-maturin builds on all Tier1 FreeBSD releases (maybe CURRENT as well, if possible) and that the consumers (retrievable e.g. with portgrep -o -s -d py-maturin) also builds fine.
Otherwise, LGTM and thank you very much!

Now use "make cargo-crates"

Recreate crates list

In D53686#1226200, @tagattie wrote:

Hi @michaelo, thanks for an update to the port.

It appears some updates to CARGO_CRATES and distinfo are missing.

Can you update Makefile.crates using make cargo-crates and resubmit the patch?

Thanks!

truss output:

root@135-release-amd64-default-head:/usr/ports/devel/uv # grep /usr/local/etc --color out
read(3,"includedir /usr/local/etc/libmap"...,35) = 35 (0x23)
open("/usr/local/etc/libmap.d",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0165) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/usr/local/etc/xdg/uv/uv.toml",0x348e6c167210,0x0) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/usr/local/etc/uv/uv.toml",0x348e6c167210,0x0) ERR#2 'No such file or directory'
root@135-release-amd64-default-head:/usr/ports/devel/uv #

Creates file produced by:

awk '/name = / { gsub(/"/, "", $3); name=$3 } /version = / { gsub(/"/, "", $3); print "\t\t" name "-" $3 " \\" }' Cargo.lock | sort -u > ../../Makefile.crates

Manually applied by maintainer.

Updating the patch making bdist_wheel opt-in.

In D53489#1225670, @mikael wrote:

It's not possible to mfh it, rust is at 1.89.0 in Q4.
It's probably possible to do a direct commit in Q4 but I've never done that. Feel free to do it if you think Q4 needs this patch.

Reivew has been ignored by maintainer.

Reivew has been ignored by maintainer.

In D53489#1224813, @mikael wrote:

I'll commit your patch prior to landing rust 1.91.0 (to not bump rust too frequently, people will get mad at me otherwise)
I'll drop the version in the file name (it's a pain to maintain in the long run) -> files/patch-vendor_openssl-probe_src_lib.rs

In D53489#1224804, @mikael wrote:

There are 2 version of openssl-probe (openssl-probe-0.1.5/ openssl-probe-0.1.6), only 0.1.6 needs to be patched?

Both patches apply cleanly here.

In D53489#1224730, @mikael wrote:

I'm updating rust to 1.91.0, does it apply to this version ?

@mikael Any objections? This has also been incorporated into devel/uv, upstream patch is in discussion.

In D53433#1224443, @vishwin wrote:

In D53433#1224442, @michaelo wrote:

In D53433#1224438, @vishwin wrote:

USES=distutils is going away because upstream is removing support for this entirely. It had been deprecated for quite some time but they are finally pulling the switch.

I know, this is why I said that with PEP 517 wheels already there, they just need to be in a distinct, explicit place for consumption.

Can you explain why this change needs revision? ATM, I don't see a way to make it even simple than this. Again, I don't expect you do upload anthing to PyPI. It is just a possible usecaes. I am happy if people can host their own indexes with this.

From a meta-/framework perspective, building wheels from USE_PYTHON=distutils (ie direct setup.py invocation) is not reliable unless you don't pass any flags or variables at all. This stems from setuptools themselves continuing to deal with a littany of legacy code and design which is frustrating to rid for modernity and maintenance sakes. Trying to build a binary wheel from built artefacts in this case may result in those artefacts getting wrongly rebuilt. (I had some local modifications where USE_PYTHON=distutils only built binary wheels and eliminated its do-install in favour of the PEP-517 do-install.)

For those ports that still have a setup.py without a corresponding or replacement pyproject.toml that doesn't need to have flags or variables passed into configure or build, PEP-517 already provides that setuptools is implicitly the build backend. Those ports can switch to USE_PYTHON=pep517. For ports that need to pass flags and variables, setuptools still doesn't support config settings passed from a build frontend like devel/py-build.

In D53370#1224466, @john_saltant.com wrote:

Thank you for your contribution.

In D53433#1224457, @arrowd wrote:

In D53433#1224456, @michaelo wrote:

I don't know whether it can be compiled on 13.5 and run older minor versions.

It can't generally. But this is not a problem, because the support window between two consecutive minor releases is usually tight and the official cluster always builds packages on the lowest minor version supported.

In D53433#1224455, @vishwin wrote:

In D53433#1223609, @arrowd wrote:

In D53433#1223585, @michaelo wrote:

Here is the definition: https://packaging.python.org/en/latest/specifications/binary-distribution-format/

There is a notion of a "platform tag" which denotes the platform for which the wheel has been built if it contains native code, by default it does "$(os}_${release}_${arch}". Run " pip debug --verbose" and see for compatible tags. If a wheel has been compiled with 13.5-RELEASE-p5 it won't be consumed by 13.5-RELEASE-p6. "wheel tags --remove --platform-tag=..." renames the file for multiplatform AND modfies the metadata (Tag: ) in WHEEL file. So I am not rebuilding, I am retagging. I first assumed a bug in poudriere: https://github.com/freebsd/poudriere/issues/1277, but then realized otherwise.

Well, to me it is the python part that should be fixed. FreeBSD guarantees ABI compatibility between minor releases, so the tag should look like py310-none-freebsd_13_amd64. This is the same how pkg handles our native packages ABI.

Re-tagging is not necessary as they are already correct. Not every wheel will have specific platform tags, in fact most if not all ports specifying NO_ARCH will have py3-none-any which allows consumption on anything with any implementation/distribution. Patch levels are not part of specific platform tags, only minor releases, like cp312-cp312-freebsd_14_3_release_amd64 (denotes compatibility with CPython >= 3.12 on 14.3-RELEASE amd64), cp37-abi3-freebsd_16_0_current_amd64 (CPython >= 3.7 ABI 3 on -CURRENT amd64). (If we enable building ports under other implementations like lang/rustpython, that's another can of worms entirely…) Note that 3.13 and later have differing ABIs wrt free-threaded mode or not, like cp313-cp313t-freebsd_16_0_current_amd64.

In D53433#1224443, @vishwin wrote:

In D53433#1224442, @michaelo wrote:

In D53433#1224438, @vishwin wrote:

USES=distutils is going away because upstream is removing support for this entirely. It had been deprecated for quite some time but they are finally pulling the switch.

I know, this is why I said that with PEP 517 wheels already there, they just need to be in a distinct, explicit place for consumption.

Can you explain why this change needs revision? ATM, I don't see a way to make it even simple than this. Again, I don't expect you do upload anthing to PyPI. It is just a possible usecaes. I am happy if people can host their own indexes with this.

From a meta-/framework perspective, building wheels from USE_PYTHON=distutils (ie direct setup.py invocation) is not reliable unless you don't pass any flags or variables at all. This stems from setuptools themselves continuing to deal with a littany of legacy code and design which is frustrating to rid for modernity and maintenance sakes. Trying to build a binary wheel from built artefacts in this case may result in those artefacts getting wrongly rebuilt. (I had some local modifications where USE_PYTHON=distutils only built binary wheels and eliminated its do-install in favour of the PEP-517 do-install.)

For those ports that still have a setup.py without a corresponding or replacement pyproject.toml that doesn't need to have flags or variables passed into configure or build, PEP-517 already provides that setuptools is implicitly the build backend. Those ports can switch to USE_PYTHON=pep517. For ports that need to pass flags and variables, setuptools still doesn't support config settings passed from a build frontend like devel/py-build.

In D53433#1224438, @vishwin wrote:

In D53433#1223076, @michaelo wrote:

My ideal longterm goal: The Project hosts canonical poudriere builds and these could produce FreeBSD-specific wheels which could be uploaded to PyPI and would dramatically improve the situation for the Python ecosystem on FreeBSD.

Not happening. We already build artefacts for ports with non-standard flags and such, which are inappropriate to share to PyPI.

In D53433#1224026, @arrowd wrote:

This looks OK to me, but I'm a python hat wearer.