From Newsgroup: muc.lists.freebsd.ports

How does one "cross the bridge" between FreeBSD 15 and FreeBSD 16 when using poudriere to maintain a package repository on a host tracking -current?

Now that -current has gone from 15 to 16, searching for local packages reports root@nemesis:/usr/local/poudriere # pkg search bash
pkg: repository FreeBSD-ports-kmods contains packages for wrong OS version: FreeBSD:16:aarch64
pkg: wrong architecture: FreeBSD:15:aarch64 instead of FreeBSD:16:aarch64
pkg: repository custom contains packages with wrong ABI: FreeBSD:15:aarch64

despite the fact that the shells/bash package was compiled after the transition.

It looks as if the pkg command expects the entire repository to be maintained under a single major version number. In this case the repository contains only pakcages needed for the local system, built one-at-a-time as found necessary.

What's the best way to restore normal operation? Something like
poudriere bulk -a
might work if it builds only existing packages, but the man page
says "all packages in the tree" which seems to imply it'll build
the entire ports tree, far too much for a Raspberry Pi (even a 4).

Thanks for reading!

bob prohaska



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

bob prohaska <fbsd@www.zefox.net> writes:

What's the best way to restore normal operation? Something like
poudriere bulk -a

poudriere bulk $(pkg query -e '%#r == 0' '%o')
DES
--
Dag-Erling Sm|+rgrav - des@FreeBSD.org
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On 16 Dec, Dag-Erling Smorgrav wrote:

bob prohaska <fbsd@www.zefox.net> writes:

What's the best way to restore normal operation? Something like
poudriere bulk -a

poudriere bulk $(pkg query -e '%#r == 0' '%o')

I do:
poudriere bulk `pkg prime-origins`
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

bob prohaska <fbsd_at_www.zefox.net> wrote on
Date: Tue, 16 Dec 2025 23:47:14 UTC :

On Tue, Dec 16, 2025 at 08:49:06PM +0100, Dag-Erling Sm|+rgrav wrote:

bob prohaska <fbsd@www.zefox.net> writes:

What's the best way to restore normal operation? Something like poudriere bulk -a

poudriere bulk $(pkg query -e '%#r == 0' '%o')

Something's amiss. A simple copy-paste of the command yields
"Illegal variable name.", maybe I'm using the wrong shell.

And older --and possibly less shell dependent-- notation
would be the use of a pair of backquotes:
poudriere bulk `pkg query -e '%#r == 0' '%o'`
(That notation is not so nice for usage that involves
wanting nested usage.)

However, it appears that pkg query -e '%#r == 0' '%o'
generates a list of built packages, so I tried running
pkg query -e '%#r == 0' '%o' > package.list
which worked, followed by
poudriere bulk -j main -f package.list

That got off to a good start but didn't end well:

[00:00:01] Creating the reference jail... done
[00:00:54] Mounting system devices for main-default
[00:00:54] Mounting ports/packages/distfiles
[00:00:54] Stashing existing package repository
[00:00:58] Mounting packages from: /usr/local/poudriere/data/packages/main-default
/etc/resolv.conf -> /usr/local/poudriere/data/.m/main-default/ref/etc/resolv.conf
[00:00:58] Starting jail main-default
[00:01:10] Logs: /usr/local/poudriere/data/logs/bulk/main-default/2025-12-16_15h32m41s
[00:01:10] Loading MOVED for /usr/local/poudriere/data/.m/main-default/ref/usr/ports
[00:01:25] Ports supports: FLAVORS SUBPACKAGES SELECTED_OPTIONS
[00:01:25] Gathering ports metadata
[00:01:25] Error: MOVED: devel/libpthread-stubs 2023-03-12 No consumers left and never supported pthread stubs in libc on FreeBSD
[00:01:25] Warning: MOVED: devel/pygobject3-common renamed to devel/pygobject-common
[00:01:25] Warning: MOVED: net/openldap24-client renamed to net/openldap25-client
[00:01:25] Error: MOVED: x11-fonts/gentium-basic 2025-12-04 Has expired: Superceeded by Gentium-7.000 https://software.sil.org/gentium/download/
[00:01:25] Warning: MOVED: x11-themes/kf5-oxygen-icons5 renamed to x11-themes/oxygen-icons
[00:01:25] Error: Fatal errors encountered gathering initial ports metadata [00:01:25] Cleaning up
[00:01:25] Unmounting file systems
root@nemesis:/usr/local/poudriere #

The reaction to errors is surprising; it seems like both have enough context to handle.
The first package can be omitted, and the second package can be replaced.

What am I missing?

Sounds like you can remove devel/libpthread-stubs from
package.list and can pkg delete it?
Sounds like you can replace x11-fonts/gentium-basic with
x11-fonts/gentium in package.list and can:
pkg delete x11-fonts/gentium-basic
Then try the bulk build again based on the updated file.
===
Mark Millard
marklmi at yahoo.com
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

bob prohaska <fbsd@www.zefox.net> writes:

The reaction to errors is surprising; it seems like both have enough context to handle.
The first package can be omitted, and the second package can be replaced.

What am I missing?

Poudriere does what you tell it to, not what you mean. If it encounters
a problem it will tell you about it and expect you to fix it. So fix
your pacakge list and run poudriere again.
DES
--
Dag-Erling Sm|+rgrav - des@FreeBSD.org
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Don Lewis <truckman@FreeBSD.org> writes:

I do:
poudriere bulk `pkg prime-origins`

That's an alias. Not everybody has it.
DES
--
Dag-Erling Sm|+rgrav - des@FreeBSD.org
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Dec 17, 2025, at 06:30, bob prohaska <fbsd@www.zefox.net> wrote:

On Tue, Dec 16, 2025 at 05:45:03PM -0800, Mark Millard wrote:

bob prohaska <fbsd_at_www.zefox.net> wrote on
Date: Tue, 16 Dec 2025 23:47:14 UTC :

On Tue, Dec 16, 2025 at 08:49:06PM +0100, Dag-Erling Sm|+rgrav wrote:

bob prohaska <fbsd@www.zefox.net> writes:

What's the best way to restore normal operation? Something like
poudriere bulk -a

poudriere bulk $(pkg query -e '%#r == 0' '%o')

Something's amiss. A simple copy-paste of the command yields
"Illegal variable name.", maybe I'm using the wrong shell.

And older --and possibly less shell dependent-- notation
would be the use of a pair of backquotes:

poudriere bulk `pkg query -e '%#r == 0' '%o'`

(That notation is not so nice for usage that involves
wanting nested usage.)

However, it appears that pkg query -e '%#r == 0' '%o'
generates a list of built packages, so I tried running
pkg query -e '%#r == 0' '%o' > package.list
which worked, followed by
poudriere bulk -j main -f package.list

That got off to a good start but didn't end well:

[00:00:01] Creating the reference jail... done
[00:00:54] Mounting system devices for main-default
[00:00:54] Mounting ports/packages/distfiles
[00:00:54] Stashing existing package repository
[00:00:58] Mounting packages from: /usr/local/poudriere/data/packages/main-default
/etc/resolv.conf -> /usr/local/poudriere/data/.m/main-default/ref/etc/resolv.conf
[00:00:58] Starting jail main-default
[00:01:10] Logs: /usr/local/poudriere/data/logs/bulk/main-default/2025-12-16_15h32m41s
[00:01:10] Loading MOVED for /usr/local/poudriere/data/.m/main-default/ref/usr/ports
[00:01:25] Ports supports: FLAVORS SUBPACKAGES SELECTED_OPTIONS
[00:01:25] Gathering ports metadata
[00:01:25] Error: MOVED: devel/libpthread-stubs 2023-03-12 No consumers left and never supported pthread stubs in libc on FreeBSD
[00:01:25] Warning: MOVED: devel/pygobject3-common renamed to devel/pygobject-common
[00:01:25] Warning: MOVED: net/openldap24-client renamed to net/openldap25-client
[00:01:25] Error: MOVED: x11-fonts/gentium-basic 2025-12-04 Has expired: Superceeded by Gentium-7.000 https://software.sil.org/gentium/download/

Turns out the above line was because the MOVED line for it
was incorrect. That has been fixed to also list
x11-fonts/gentium as what to use instead:
Wed, 17 Dec 2025
rCo git: 24b7568ff29c - main - MOVED: x11-fonts/gentium-basic is superceeded by x11-fonts/gentium Matthew Seaman

[00:01:25] Warning: MOVED: x11-themes/kf5-oxygen-icons5 renamed to x11-themes/oxygen-icons
[00:01:25] Error: Fatal errors encountered gathering initial ports metadata >>> [00:01:25] Cleaning up
[00:01:25] Unmounting file systems
root@nemesis:/usr/local/poudriere #

The reaction to errors is surprising; it seems like both have enough context to handle.
The first package can be omitted, and the second package can be replaced. >>

What am I missing?

Sounds like you can remove devel/libpthread-stubs from
package.list and can pkg delete it?

Yes to both.

Sounds like you can replace x11-fonts/gentium-basic with
x11-fonts/gentium in package.list and can:

pkg delete x11-fonts/gentium-basic

Yes to both.

Then try the bulk build again based on the updated file.

Looks like it's working.....Oops, maybe not:
00:11:32] [03] [00:02:29] Saved devel/autoconf | autoconf-2.72 wrkdir to: /usr/local/poudriere/data/wrkdirs/main-default/default/autoconf-2.72.tbz
[00:11:37] [03] [00:02:34] Finished devel/autoconf | autoconf-2.72: Failed: run-depends
[00:11:49] [03] [00:02:46] Skipping graphics/GraphicsMagick | GraphicsMagick-1.3.43_3,1: Dependent port devel/autoconf | autoconf-2.72 failed
followed by a torrent of "Skipping.....[various port names]"
lines.

I'll let it run until advised to intervene. For now it doesn't look promising.

Failed: run-depends
The autoconf-2.72 related poudriere build log file will need
to be investigated for evidence about that.

Thank you for the guidance. I've never seen poudriere complain about
changes or invite manual intervention, thus my caution about tampering.
The manual changes don't look obviously related to the apparent problems.

===
Mark Millard
marklmi at yahoo.com
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Dec 17, 2025, at 10:46, bob prohaska <fbsd@www.zefox.net> wrote:

On Wed, Dec 17, 2025 at 09:29:50AM -0800, Mark Millard wrote:

On Dec 17, 2025, at 06:30, bob prohaska <fbsd@www.zefox.net> wrote:

On Tue, Dec 16, 2025 at 05:45:03PM -0800, Mark Millard wrote:

bob prohaska <fbsd_at_www.zefox.net> wrote on
Date: Tue, 16 Dec 2025 23:47:14 UTC :

On Tue, Dec 16, 2025 at 08:49:06PM +0100, Dag-Erling Sm|+rgrav wrote: >>>>>> bob prohaska <fbsd@www.zefox.net> writes:

What's the best way to restore normal operation? Something like >>>>>>> poudriere bulk -a

poudriere bulk $(pkg query -e '%#r == 0' '%o')

Something's amiss. A simple copy-paste of the command yields
"Illegal variable name.", maybe I'm using the wrong shell.

And older --and possibly less shell dependent-- notation
would be the use of a pair of backquotes:

poudriere bulk `pkg query -e '%#r == 0' '%o'`

(That notation is not so nice for usage that involves
wanting nested usage.)

However, it appears that pkg query -e '%#r == 0' '%o'
generates a list of built packages, so I tried running
pkg query -e '%#r == 0' '%o' > package.list
which worked, followed by
poudriere bulk -j main -f package.list

That got off to a good start but didn't end well:

[00:00:01] Creating the reference jail... done
[00:00:54] Mounting system devices for main-default
[00:00:54] Mounting ports/packages/distfiles
[00:00:54] Stashing existing package repository
[00:00:58] Mounting packages from: /usr/local/poudriere/data/packages/main-default
/etc/resolv.conf -> /usr/local/poudriere/data/.m/main-default/ref/etc/resolv.conf
[00:00:58] Starting jail main-default
[00:01:10] Logs: /usr/local/poudriere/data/logs/bulk/main-default/2025-12-16_15h32m41s
[00:01:10] Loading MOVED for /usr/local/poudriere/data/.m/main-default/ref/usr/ports
[00:01:25] Ports supports: FLAVORS SUBPACKAGES SELECTED_OPTIONS
[00:01:25] Gathering ports metadata
[00:01:25] Error: MOVED: devel/libpthread-stubs 2023-03-12 No consumers left and never supported pthread stubs in libc on FreeBSD
[00:01:25] Warning: MOVED: devel/pygobject3-common renamed to devel/pygobject-common
[00:01:25] Warning: MOVED: net/openldap24-client renamed to net/openldap25-client
[00:01:25] Error: MOVED: x11-fonts/gentium-basic 2025-12-04 Has expired: Superceeded by Gentium-7.000 https://software.sil.org/gentium/download/

Turns out the above line was because the MOVED line for it
was incorrect. That has been fixed to also list
x11-fonts/gentium as what to use instead:

Wed, 17 Dec 2025

rCo git: 24b7568ff29c - main - MOVED: x11-fonts/gentium-basic is superceeded by x11-fonts/gentium Matthew Seaman

[00:01:25] Warning: MOVED: x11-themes/kf5-oxygen-icons5 renamed to x11-themes/oxygen-icons
[00:01:25] Error: Fatal errors encountered gathering initial ports metadata
[00:01:25] Cleaning up
[00:01:25] Unmounting file systems
root@nemesis:/usr/local/poudriere #

The reaction to errors is surprising; it seems like both have enough context to handle.
The first package can be omitted, and the second package can be replaced. >>>>

What am I missing?

Sounds like you can remove devel/libpthread-stubs from
package.list and can pkg delete it?

Yes to both.

Sounds like you can replace x11-fonts/gentium-basic with
x11-fonts/gentium in package.list and can:

pkg delete x11-fonts/gentium-basic

Yes to both.

Then try the bulk build again based on the updated file.

Looks like it's working.....Oops, maybe not:
00:11:32] [03] [00:02:29] Saved devel/autoconf | autoconf-2.72 wrkdir to: /usr/local/poudriere/data/wrkdirs/main-default/default/autoconf-2.72.tbz
[00:11:37] [03] [00:02:34] Finished devel/autoconf | autoconf-2.72: Failed: run-depends
[00:11:49] [03] [00:02:46] Skipping graphics/GraphicsMagick | GraphicsMagick-1.3.43_3,1: Dependent port devel/autoconf | autoconf-2.72 failed
followed by a torrent of "Skipping.....[various port names]"
lines.

I'll let it run until advised to intervene. For now it doesn't look promising.

Failed: run-depends

The autoconf-2.72 related poudriere build log file will need
to be investigated for evidence about that.

Aye, there's the rub: ===========================================================================> =======================<phase: run-depends >============================

autoconf-2.72 depends on package: autoconf-switch>=0 - not found
Installing existing package /packages/All/autoconf-switch-20220527.pkg

[main-default-job-03] Installing autoconf-switch-20220527...
pkg-static: wrong architecture: FreeBSD:15:* instead of FreeBSD:16:aarch64

Yea, poudriere is only rebuilding the specific ports
listed in the file and ones that had updates in the
dependencies. Merely being for :15: instead of :16:
is not leading to an automatic rebuild.
You will likely want to:
Delete all the packages that are :15: based and then
run another bulk based on your file.
The following sort of command would list the packages
that need to be deleted/updated (for example):
# pkg-static query -e '%q ~ *:15:*' %n-%v
u-boot-tools-2020.07
unzip-6.0_8
usbtop-1.0_7
You may want to review the list to be sure there are
no surprises. pkg itself being listed would be an
issue, for example. If the list looks okay:
# pkg-static delete `pkg-static query -e '%q ~ *:15:*' %n-%v`
should do sufficient deletes to avoid use of :15:
vintage builds in the later poudriere bulk run.

That's what I thought was being fixed 8-(

Failed to install the following 1 package(s): /packages/All/autoconf-switch-20220527.pkg
*** Error code 1

Stop.
make: stopped making "run-depends" in /usr/ports/devel/autoconf

Cleaning up wrkdir

Cleaning for autoconf-2.72

build of devel/autoconf | autoconf-2.72 ended at Wed Dec 17 06:21:44 PST 2025 build time: 00:02:37
!!! build failure encountered !!!

Seems like a chicken-or-egg sort of problem. But, that objection is
also true of many ports presently being rebuilt successfully. Is
autoconf somehow special?

===
Mark Millard
marklmi at yahoo.com
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Dec 17, 2025, at 12:35, bob prohaska <fbsd@www.zefox.net> wrote:

On Wed, Dec 17, 2025 at 11:12:50AM -0800, Mark Millard wrote:

On Dec 17, 2025, at 10:46, bob prohaska <fbsd@www.zefox.net> wrote:

On Wed, Dec 17, 2025 at 09:29:50AM -0800, Mark Millard wrote:

On Dec 17, 2025, at 06:30, bob prohaska <fbsd@www.zefox.net> wrote:

On Tue, Dec 16, 2025 at 05:45:03PM -0800, Mark Millard wrote:

bob prohaska <fbsd_at_www.zefox.net> wrote on
Date: Tue, 16 Dec 2025 23:47:14 UTC :

On Tue, Dec 16, 2025 at 08:49:06PM +0100, Dag-Erling Sm|+rgrav wrote: >>>>>>>> bob prohaska <fbsd@www.zefox.net> writes:

What's the best way to restore normal operation? Something like >>>>>>>>> poudriere bulk -a

poudriere bulk $(pkg query -e '%#r == 0' '%o')

Something's amiss. A simple copy-paste of the command yields
"Illegal variable name.", maybe I'm using the wrong shell.

And older --and possibly less shell dependent-- notation
would be the use of a pair of backquotes:

poudriere bulk `pkg query -e '%#r == 0' '%o'`

(That notation is not so nice for usage that involves
wanting nested usage.)

However, it appears that pkg query -e '%#r == 0' '%o'
generates a list of built packages, so I tried running
pkg query -e '%#r == 0' '%o' > package.list
which worked, followed by
poudriere bulk -j main -f package.list

That got off to a good start but didn't end well:

[00:00:01] Creating the reference jail... done
[00:00:54] Mounting system devices for main-default
[00:00:54] Mounting ports/packages/distfiles
[00:00:54] Stashing existing package repository
[00:00:58] Mounting packages from: /usr/local/poudriere/data/packages/main-default
/etc/resolv.conf -> /usr/local/poudriere/data/.m/main-default/ref/etc/resolv.conf
[00:00:58] Starting jail main-default
[00:01:10] Logs: /usr/local/poudriere/data/logs/bulk/main-default/2025-12-16_15h32m41s
[00:01:10] Loading MOVED for /usr/local/poudriere/data/.m/main-default/ref/usr/ports
[00:01:25] Ports supports: FLAVORS SUBPACKAGES SELECTED_OPTIONS
[00:01:25] Gathering ports metadata
[00:01:25] Error: MOVED: devel/libpthread-stubs 2023-03-12 No consumers left and never supported pthread stubs in libc on FreeBSD
[00:01:25] Warning: MOVED: devel/pygobject3-common renamed to devel/pygobject-common
[00:01:25] Warning: MOVED: net/openldap24-client renamed to net/openldap25-client
[00:01:25] Error: MOVED: x11-fonts/gentium-basic 2025-12-04 Has expired: Superceeded by Gentium-7.000 https://software.sil.org/gentium/download/

Turns out the above line was because the MOVED line for it
was incorrect. That has been fixed to also list
x11-fonts/gentium as what to use instead:

Wed, 17 Dec 2025

rCo git: 24b7568ff29c - main - MOVED: x11-fonts/gentium-basic is superceeded by x11-fonts/gentium Matthew Seaman

[00:01:25] Warning: MOVED: x11-themes/kf5-oxygen-icons5 renamed to x11-themes/oxygen-icons
[00:01:25] Error: Fatal errors encountered gathering initial ports metadata
[00:01:25] Cleaning up
[00:01:25] Unmounting file systems
root@nemesis:/usr/local/poudriere #

The reaction to errors is surprising; it seems like both have enough context to handle.
The first package can be omitted, and the second package can be replaced.


What am I missing?

Sounds like you can remove devel/libpthread-stubs from
package.list and can pkg delete it?

Yes to both.

Sounds like you can replace x11-fonts/gentium-basic with
x11-fonts/gentium in package.list and can:

pkg delete x11-fonts/gentium-basic

Yes to both.

Then try the bulk build again based on the updated file.

Looks like it's working.....Oops, maybe not:
00:11:32] [03] [00:02:29] Saved devel/autoconf | autoconf-2.72 wrkdir to: /usr/local/poudriere/data/wrkdirs/main-default/default/autoconf-2.72.tbz
[00:11:37] [03] [00:02:34] Finished devel/autoconf | autoconf-2.72: Failed: run-depends
[00:11:49] [03] [00:02:46] Skipping graphics/GraphicsMagick | GraphicsMagick-1.3.43_3,1: Dependent port devel/autoconf | autoconf-2.72 failed
followed by a torrent of "Skipping.....[various port names]"
lines.

I'll let it run until advised to intervene. For now it doesn't look promising.

Failed: run-depends

The autoconf-2.72 related poudriere build log file will need
to be investigated for evidence about that.

Aye, there's the rub:
===========================================================================>>> =======================<phase: run-depends >============================

autoconf-2.72 depends on package: autoconf-switch>=0 - not found
Installing existing package /packages/All/autoconf-switch-20220527.pkg

[main-default-job-03] Installing autoconf-switch-20220527...
pkg-static: wrong architecture: FreeBSD:15:* instead of FreeBSD:16:aarch64 >>

Yea, poudriere is only rebuilding the specific ports
listed in the file and ones that had updates in the
dependencies. Merely being for :15: instead of :16:
is not leading to an automatic rebuild.

You will likely want to:

Delete all the packages that are :15: based and then
run another bulk based on your file.

The following sort of command would list the packages
that need to be deleted/updated (for example):

# pkg-static query -e '%q ~ *:15:*' %n-%v
u-boot-tools-2020.07
unzip-6.0_8
usbtop-1.0_7

You may want to review the list to be sure there are
no surprises. pkg itself being listed would be an
issue, for example. If the list looks okay:

# pkg-static delete `pkg-static query -e '%q ~ *:15:*' %n-%v`

should do sufficient deletes to avoid use of :15:
vintage builds in the later poudriere bulk run.

It looks as if the logs/error directory is collecting
a list of ports that report "wrong architecture.."
None of them are things I specifically wanted installed,
they were just "part of the furniture":

autoconf-2.72.log libxshmfence-1.3.3.log
boehm-gc-8.2.10.log py311-evdev-1.9.1_1.log cmake-core-3.31.10.log py311-libevdev-0.11_2.log
groff-1.23.0_5.log py311-pyudev-0.24.1_1.log
libXau-1.0.12.log py311-pyyaml-6.0.3.log libpciaccess-0.18.1_1.log xtrans-1.6.0_1.log
[so far; the list is likely to grow]

Using autoconf as an example: it built but failed
to find usable some run dependency(s) and so was
rejected. What has the "wrong architecture.." is
the dependency, instead of it being autoconf that
was wrong.
Deleting autoconf would not help. The
autoconf-2.72.log content:
QUOTE
[main-default-job-03] Installing autoconf-switch-20220527...
pkg-static: wrong architecture: FreeBSD:15:* instead of FreeBSD:16:aarch64
END QUOTE
indicates that autoconf-switch needs to be deleted
instead. (There could be more to delete but only
the first such is reported in the log file.)
Similar points are likely true of many or all of
the rest of the log-file names: they are likely not
indicating what to delete. You would need to look
inside the log files to find some of what to delete
if you use the log files to figure such out.

My thought is to simply delete them and re-build any packages
needed that are missing.

If "them" was based on the content of the
logs it would help --but might not provide a
list of everything to delete.
If you let the existing bulk run finish
(or stop it) and then do the:
# pkg-static query -e '%q ~ *:15:*' %n-%v
it should produce the appropriate list of
what to delete as things are at that point.

Am I setting another trap for myself?

It looks to me like you were expecting to
delete the wrong list of port-package
names. I suggest using:
# pkg-static query -e '%q ~ *:15:*' %n-%v
to get the list of what to delete.
===
Mark Millard
marklmi at yahoo.com
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Thu, Dec 18, 2025 at 01:45:10AM +0000, void wrote:

It's the default, at least it is in >FreeBSD-14.3-STABLE-amd64-20251211-0ce6b2f829dc-272983-disc1.iso

by that I mean "prime-origins is not a user-defined alias of pkg, it
present by default"
--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

bob prohaska <fbsd@www.zefox.net> writes:

Is the sanctioned approach to delete everything and start
over once the host system identifies itself as 16 rather
than 15? In hindsight it looks like less work.

You know that poudriere does not build on the host, right? What matters
is the OS version in your poudriere jail (the host just needs to be the
same version as or newer than your newest jail), and you're not supposed
to upgrade a poudriere jail from one ABI to another, you're supposed to
create a new jail with the new ABI.
DES
--
Dag-Erling Sm|+rgrav - des@FreeBSD.org
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

void <void@f-m.fm> writes:

Dag-Erling Sm|+rgrav <des@FreeBSD.org> writes:

Don Lewis <truckman@FreeBSD.org> writes:

poudriere bulk `pkg prime-origins`

That's an alias. Not everybody has it.

It's the default, [...] by that I mean "prime-origins is not a
user-defined alias of pkg, it present by default"

It is present if you install pkg on a new system and don't modify
pkg.conf. It is not present if you've upgraded from a system that
predates the introduction of that alias, or if your pkg.conf is managed
by something like ansible.
DES
--
Dag-Erling Sm|+rgrav - des@FreeBSD.org
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Thu, Dec 18, 2025 at 2:06rC>PM Dag-Erling Sm|+rgrav <des@freebsd.org> wrote:

you're not supposed
to upgrade a poudriere jail from one ABI to another, you're supposed to create a new jail with the new ABI.

This is the first time I hear about that. Is this documented
somewhere? It feels wrong, because "poudriere jail" has flags to
perform jail upgrades and I've been using it for a long time.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Gleb Popov <arrowd@freebsd.org> writes:

Dag-Erling Sm|+rgrav <des@freebsd.org> writes:

you're not supposed to upgrade a poudriere jail from one ABI to
another, you're supposed to create a new jail with the new ABI.

This is the first time I hear about that. Is this documented
somewhere? It feels wrong, because "poudriere jail" has flags to
perform jail upgrades and I've been using it for a long time.

The name of the jail is also the name of the repository. Reusing the
same jail for a different ABI means you either end up with a mixed
repository, which isn't supported, or your clients must all be upgraded
at the same time as the jail, which is impractical.
Besides, creating a new jail is much faster than upgrading an existing
one (though pkgbase may change that).
By the way, poudriere will normally delete all packages when it detects
that the jail has been upgraded, but it can only delete packages that it
knows about, meaning the packages you ask it to build and all their dependencies. Since Bob is using poudriere to build just one or two
packages at a time instead of giving it a list of all the packages he
cares about, a lot of packages that should have been deleted weren't.
DES
--
Dag-Erling Sm|+rgrav - des@FreeBSD.org
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Dec 17, 2025, at 16:40, bob prohaska <fbsd@www.zefox.net> wrote:

On Wed, Dec 17, 2025 at 02:36:05PM -0800, Mark Millard wrote:

On Dec 17, 2025, at 12:35, bob prohaska <fbsd@www.zefox.net> wrote:

On Wed, Dec 17, 2025 at 11:12:50AM -0800, Mark Millard wrote:

On Dec 17, 2025, at 10:46, bob prohaska <fbsd@www.zefox.net> wrote:

On Wed, Dec 17, 2025 at 09:29:50AM -0800, Mark Millard wrote:

On Dec 17, 2025, at 06:30, bob prohaska <fbsd@www.zefox.net> wrote: >>>>>>

On Tue, Dec 16, 2025 at 05:45:03PM -0800, Mark Millard wrote:

bob prohaska <fbsd_at_www.zefox.net> wrote on
Date: Tue, 16 Dec 2025 23:47:14 UTC :

On Tue, Dec 16, 2025 at 08:49:06PM +0100, Dag-Erling Sm|+rgrav wrote: >>>>>>>>>> bob prohaska <fbsd@www.zefox.net> writes:

What's the best way to restore normal operation? Something like >>>>>>>>>>> poudriere bulk -a

poudriere bulk $(pkg query -e '%#r == 0' '%o')

Something's amiss. A simple copy-paste of the command yields >>>>>>>>> "Illegal variable name.", maybe I'm using the wrong shell.

And older --and possibly less shell dependent-- notation
would be the use of a pair of backquotes:

poudriere bulk `pkg query -e '%#r == 0' '%o'`

(That notation is not so nice for usage that involves
wanting nested usage.)

However, it appears that pkg query -e '%#r == 0' '%o'
generates a list of built packages, so I tried running
pkg query -e '%#r == 0' '%o' > package.list
which worked, followed by
poudriere bulk -j main -f package.list

That got off to a good start but didn't end well:

[00:00:01] Creating the reference jail... done
[00:00:54] Mounting system devices for main-default
[00:00:54] Mounting ports/packages/distfiles
[00:00:54] Stashing existing package repository
[00:00:58] Mounting packages from: /usr/local/poudriere/data/packages/main-default
/etc/resolv.conf -> /usr/local/poudriere/data/.m/main-default/ref/etc/resolv.conf
[00:00:58] Starting jail main-default
[00:01:10] Logs: /usr/local/poudriere/data/logs/bulk/main-default/2025-12-16_15h32m41s
[00:01:10] Loading MOVED for /usr/local/poudriere/data/.m/main-default/ref/usr/ports
[00:01:25] Ports supports: FLAVORS SUBPACKAGES SELECTED_OPTIONS >>>>>>>>> [00:01:25] Gathering ports metadata
[00:01:25] Error: MOVED: devel/libpthread-stubs 2023-03-12 No consumers left and never supported pthread stubs in libc on FreeBSD
[00:01:25] Warning: MOVED: devel/pygobject3-common renamed to devel/pygobject-common
[00:01:25] Warning: MOVED: net/openldap24-client renamed to net/openldap25-client
[00:01:25] Error: MOVED: x11-fonts/gentium-basic 2025-12-04 Has expired: Superceeded by Gentium-7.000 https://software.sil.org/gentium/download/

Turns out the above line was because the MOVED line for it
was incorrect. That has been fixed to also list
x11-fonts/gentium as what to use instead:

Wed, 17 Dec 2025

rCo git: 24b7568ff29c - main - MOVED: x11-fonts/gentium-basic is superceeded by x11-fonts/gentium Matthew Seaman

[00:01:25] Warning: MOVED: x11-themes/kf5-oxygen-icons5 renamed to x11-themes/oxygen-icons
[00:01:25] Error: Fatal errors encountered gathering initial ports metadata
[00:01:25] Cleaning up
[00:01:25] Unmounting file systems
root@nemesis:/usr/local/poudriere #

The reaction to errors is surprising; it seems like both have enough context to handle.
The first package can be omitted, and the second package can be replaced.


What am I missing?

Sounds like you can remove devel/libpthread-stubs from
package.list and can pkg delete it?

Yes to both.

Sounds like you can replace x11-fonts/gentium-basic with
x11-fonts/gentium in package.list and can:

pkg delete x11-fonts/gentium-basic

Yes to both.

Then try the bulk build again based on the updated file.

Looks like it's working.....Oops, maybe not:
00:11:32] [03] [00:02:29] Saved devel/autoconf | autoconf-2.72 wrkdir to: /usr/local/poudriere/data/wrkdirs/main-default/default/autoconf-2.72.tbz
[00:11:37] [03] [00:02:34] Finished devel/autoconf | autoconf-2.72: Failed: run-depends
[00:11:49] [03] [00:02:46] Skipping graphics/GraphicsMagick | GraphicsMagick-1.3.43_3,1: Dependent port devel/autoconf | autoconf-2.72 failed
followed by a torrent of "Skipping.....[various port names]"
lines.

I'll let it run until advised to intervene. For now it doesn't look promising.

Failed: run-depends

The autoconf-2.72 related poudriere build log file will need
to be investigated for evidence about that.

Aye, there's the rub:
===========================================================================>>>>> =======================<phase: run-depends >============================

autoconf-2.72 depends on package: autoconf-switch>=0 - not found >>>>> ===> Installing existing package /packages/All/autoconf-switch-20220527.pkg

[main-default-job-03] Installing autoconf-switch-20220527...
pkg-static: wrong architecture: FreeBSD:15:* instead of FreeBSD:16:aarch64

Yea, poudriere is only rebuilding the specific ports
listed in the file and ones that had updates in the
dependencies. Merely being for :15: instead of :16:
is not leading to an automatic rebuild.

You will likely want to:

Delete all the packages that are :15: based and then
run another bulk based on your file.

The following sort of command would list the packages
that need to be deleted/updated (for example):

# pkg-static query -e '%q ~ *:15:*' %n-%v
u-boot-tools-2020.07
unzip-6.0_8
usbtop-1.0_7

You may want to review the list to be sure there are
no surprises. pkg itself being listed would be an
issue, for example. If the list looks okay:

# pkg-static delete `pkg-static query -e '%q ~ *:15:*' %n-%v`

should do sufficient deletes to avoid use of :15:
vintage builds in the later poudriere bulk run.

It looks as if the logs/error directory is collecting
a list of ports that report "wrong architecture.."
None of them are things I specifically wanted installed,
they were just "part of the furniture":

autoconf-2.72.log libxshmfence-1.3.3.log
boehm-gc-8.2.10.log py311-evdev-1.9.1_1.log
cmake-core-3.31.10.log py311-libevdev-0.11_2.log
groff-1.23.0_5.log py311-pyudev-0.24.1_1.log
libXau-1.0.12.log py311-pyyaml-6.0.3.log
libpciaccess-0.18.1_1.log xtrans-1.6.0_1.log
[so far; the list is likely to grow]

Using autoconf as an example: it built but failed
to find usable some run dependency(s) and so was
rejected. What has the "wrong architecture.." is
the dependency, instead of it being autoconf that
was wrong.

Deleting autoconf would not help. The
autoconf-2.72.log content:

QUOTE
[main-default-job-03] Installing autoconf-switch-20220527...
pkg-static: wrong architecture: FreeBSD:15:* instead of FreeBSD:16:aarch64 >> END QUOTE

indicates that autoconf-switch needs to be deleted
instead. (There could be more to delete but only
the first such is reported in the log file.)

Similar points are likely true of many or all of
the rest of the log-file names: they are likely not
indicating what to delete. You would need to look
inside the log files to find some of what to delete
if you use the log files to figure such out.

My thought is to simply delete them and re-build any packages
needed that are missing.

If "them" was based on the content of the
logs it would help --but might not provide a
list of everything to delete.

If you let the existing bulk run finish
(or stop it) and then do the:

# pkg-static query -e '%q ~ *:15:*' %n-%v

it should produce the appropriate list of
what to delete as things are at that point.

Am I setting another trap for myself?

It looks to me like you were expecting to
delete the wrong list of port-package
names. I suggest using:

# pkg-static query -e '%q ~ *:15:*' %n-%v

to get the list of what to delete.

Thank you for a most important clarification; I completely
misunderstood what's wrong. Now it's a little less cloudy.

I'm still confused about use of the word "architecture".
It connotes hardware, rather than software, to me, with
15 vs 16 being software versions upgradeable in place.

There is a FreeBSD list:
https://lists.freebsd.org/archives/freebsd-arch/
"arch" is short for "archtecture" as I understand.
"Software Architecture" has long been an in-use terminology
as well. FreeBSD 4.0 (not 14.0) and FreeBSD 15 have a lot
of differences, some of which would likely be called
differences of Software Architecture in various areas,
where things sgificnatly change for how things are
structured and operate. But this does not happen all at
once on that scale.
And, remember, that FreeBSD has platform specific code
(such as aarch64 vs. powerpc64).
FreeBSD:15:aarch64 vs. FreeBSD:16:powerpc64 notation
combines both the software and hardware in what it
is refering to. The same message would show up for

Is the sanctioned approach to delete everything and start
over once the host system identifies itself as 16 rather
than 15? In hindsight it looks like less work.

===
Mark Millard
marklmi at yahoo.com
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Dec 18, 2025, at 03:06, Dag-Erling Sm|+rgrav <des@FreeBSD.org> wrote:

bob prohaska <fbsd@www.zefox.net> writes:

Is the sanctioned approach to delete everything and start
over once the host system identifies itself as 16 rather
than 15? In hindsight it looks like less work.

You know that poudriere does not build on the host, right? What matters
is the OS version in your poudriere jail (the host just needs to be the
same version as or newer than your newest jail), and you're not supposed
to upgrade a poudriere jail from one ABI to another, you're supposed to create a new jail with the new ABI.

Bob provided evidence that he has a FreeBSD:16:aarch64
jail as I understand it: a log message's text lines
that he quoted included
QUOTE
[main-default-job-03] Installing autoconf-switch-20220527...
pkg-static: wrong architecture: FreeBSD:15:* instead of FreeBSD:16:aarch64
END QUOTE
That would not be produced in a FreeBSD:15:aarch64
poudriere jail as I understand things.
I also do not know if Bob uses METHOD null and builds
his own poudriere jails or not these days. The output
from
# poudriere jail -l
would answer such questions. (null mounted jail updates
do not necessarily report VERSION and OSVERSION accurately
when the jail is updated outside poudriere unless
something more is done, such as deletion and recreation
of the jail afterwords or the files for tracking such
for the jail are manually updated.)
But the original message also had a quoted line about
FreeBSD-ports-kmods that I've not dealt with at all.
It did say:
QUOTE
pkg: repository FreeBSD-ports-kmods contains packages for wrong OS version: FreeBSD:16:aarch64
END QUOTE
That reads to me like the context was not FreeBSD:16:aarch64
but FreeBSD-ports-kmods was for FreeBSD:16:aarch64 .
Bob should probably report the output of:
# pkg repos -e
I do wonder if he has some explicit :15: text
in some *.conf file(s).
===
Mark Millard
marklmi at yahoo.com
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Dec 18, 2025, at 07:51, bob prohaska <fbsd@www.zefox.net> wrote:

On Thu, Dec 18, 2025 at 05:44:07AM -0800, Mark Millard wrote:

On Dec 18, 2025, at 03:06, Dag-Erling Sm|+rgrav <des@FreeBSD.org> wrote:

bob prohaska <fbsd@www.zefox.net> writes:

Is the sanctioned approach to delete everything and start
over once the host system identifies itself as 16 rather
than 15? In hindsight it looks like less work.

You know that poudriere does not build on the host, right? What matters >>> is the OS version in your poudriere jail (the host just needs to be the
same version as or newer than your newest jail), and you're not supposed >>> to upgrade a poudriere jail from one ABI to another, you're supposed to
create a new jail with the new ABI.

To my ancient thinking, a host is a piece of machinery with a name and IP number
that can be handled. The idea of subdividing it into "virtual" hosts remains alien.
To me a "jail" is a subdivision within that hardware, of which I'm only dimly aware
and in this case forgot completely. The difference between jail and virtual host is
even less clear.

The forgetting is entirely my fault.

Bob provided evidence that he has a FreeBSD:16:aarch64
jail as I understand it: a log message's text lines
that he quoted included

QUOTE
[main-default-job-03] Installing autoconf-switch-20220527...
pkg-static: wrong architecture: FreeBSD:15:* instead of FreeBSD:16:aarch64 >> END QUOTE

That would not be produced in a FreeBSD:15:aarch64
poudriere jail as I understand things.

I also do not know if Bob uses METHOD null and builds
his own poudriere jails or not these days. The output
from

# poudriere jail -l

root@nemesis:/usr/local/poudriere # poudriere jail -l
JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
main 15.0-CURRENT arm64.aarch64 null 2023-08-29 11:22:20 /usr/local/poudriere/poudriere-system
root@nemesis:/usr/local/poudriere #

So you are using METHOD null still and building your own
poudriere jail content.
Did you rebuild /usr/local/poudriere/poudriere-system to be
16.0-CURRENT instead of 15.0-CURRENT ? (Doing so does not
automtically update the VERSION reported above. Same for
TIMESTAMP.)
A cross check on that could be the output from:
# file /usr/local/poudriere/poudriere-system/bin/sh
I expect that you did, based on that message:
pkg-static: wrong architecture: FreeBSD:15:* instead of FreeBSD:16:aarch64

would answer such questions. (null mounted jail updates
do not necessarily report VERSION and OSVERSION accurately
when the jail is updated outside poudriere unless
something more is done, such as deletion and recreation
of the jail afterwords or the files for tracking such
for the jail are manually updated.)

Poudriere was set up under 14-current with a single jail, main.

But the original message also had a quoted line about
FreeBSD-ports-kmods that I've not dealt with at all.
It did say:

QUOTE
pkg: repository FreeBSD-ports-kmods contains packages for wrong OS version: FreeBSD:16:aarch64
END QUOTE

That reads to me like the context was not FreeBSD:16:aarch64
but FreeBSD-ports-kmods was for FreeBSD:16:aarch64 .

Bob should probably report the output of:

# pkg repos -e

Maybe that's the culprit:
root@nemesis:/usr/local/poudriere # pkg repos -e
FreeBSD-ports: {
url : "pkg+https://pkg.FreeBSD.org/FreeBSD:16:aarch64/latest",
enabled : yes,
priority : 0,
mirror_type : "SRV",
signature_type : "FINGERPRINTS",
fingerprints : "/usr/share/keys/pkg"
}
FreeBSD-ports-kmods: {
url : "pkg+https://pkg.FreeBSD.org/FreeBSD:16:aarch64/kmods_latest",
enabled : yes,
priority : 0,
mirror_type : "SRV",
signature_type : "FINGERPRINTS",
fingerprints : "/usr/share/keys/pkg"
}
custom: {
url : "file:///usr/local/poudriere/data/packages/main-default/",
enabled : yes,
priority : 0
}

The pkg repos command shows after substitution of ABI
(if such is involved).

root@nemesis:/usr/local/poudriere #

All three priorities are the same. The custom one was meant to be the highest priority. Would that be 1, or -1 ?

Modern allows using negative numbers to mean lower
priority than the default (0) and positive numbers
to mean higher priority than the default. negative
was added in pkg 2.3.0 . This was to avoid the
prior status where "a negative priority is
interpreted as a very high unsigned priority" and
"[b]ut as a user of my computer I was surprised that
it is not possible to configure a lower priority
than the default".
See: https://github.com/freebsd/pkg/issues/2455
(2.3.0 was not released until 2025-Sep.)

I do wonder if he has some explicit :15: text
in some *.conf file(s).

Not for the enabled repositories based on the
output you report.

I've tampered with poudriere.conf and repos, but think that's all.

And you do your own poudriere jail builds, used via
METHOD null .
When I use my own kernel+world builds they are
based on modified source code. I have poudriere
jails for building based on the same world
build --that works via METHOD null use as well.
But I'm not sure if you actually have source
updates involved in your context vs. you just
like to build locally in general.

Besides the need to fix repository priorities listed above, it appears
the expected course of action by poudriere was delete and re-make the jail
in use when kernel and world incremented major version.

True for METHOD null if nothing is done to cause
VERSION 16.0-CURRENT ( as reported by
poudriere jail -l ).
Using examples from my context. . .
# head /usr/local/etc/poudriere.d/jails/*/version

/usr/local/etc/poudriere.d/jails/main-CA7-bulk_a/version <==

15.0-CURRENT

/usr/local/etc/poudriere.d/jails/main-CA7/version <==

15.0-CURRENT

/usr/local/etc/poudriere.d/jails/main-CA76-bulk_a/version <==

15.0-CURRENT

/usr/local/etc/poudriere.d/jails/main-CA76/version <==

15.0-CURRENT

/usr/local/etc/poudriere.d/jails/main-aarch64/version <==

16.0-CURRENT

/usr/local/etc/poudriere.d/jails/main-armv7/version <==

16.0-CURRENT

/usr/local/etc/poudriere.d/jails/official-aarch64/version <==

15.0-STABLE

/usr/local/etc/poudriere.d/jails/official-armv7/version <==

15.0-STABLE

/usr/local/etc/poudriere.d/jails/official14-aarch64/version <==14.3-STABLE /usr/local/etc/poudriere.d/jails/official14-armv7/version <==

14.3-STABLE

/usr/local/etc/poudriere.d/jails/release-aarch64/version <==

15.0-RELEASE

/usr/local/etc/poudriere.d/jails/release-armv7/version <==

15.0-RELEASE

/usr/local/etc/poudriere.d/jails/release14-aarch64/version <==14.3-RELEASE-p6

(I've not updated the main-CA*-* ones in months: I've not been
using personal kernel+world builds in that time. The others
are not METHOD null based and update VERSION more automatically.)
So you could adjust your: /usr/local/etc/poudriere.d/jails/poudriere-system/version
to indicate:
16.0-CURRENT

There are some "notes to self" at http://www.zefox.net/~fbsd/poudriere_on_rpi4
Obviously, I forgot my note about "...Freebsd's version will increment...", though it's not the only mistake revealed in the present discussion.

(Those notes have the -DWITH_META_MODE mistake as well and have
old naming for FreeBSD vs. FreeBSD-ports and the like.)
For the likes of the "I ended up deleting and re-creating the
jail with the new -v value" I have scripts, such as the below
example:
# more ~/poud-jail-create-main-CA76-pouds.sh
#! /bin/sh
poudriere jail -d -jmain-CA76
poudriere jail -c -jmain-CA76 -m null -M /usr/obj/DESTDIRs/main-CA76-poud -S /usr/main-src -v 16.0-CURRENT
poudriere jail -d -jmain-CA76-bulk_a
poudriere jail -c -jmain-CA76-bulk_a -m null -M /usr/obj/DESTDIRs/main-CA76-poud-bulk_a -S /usr/main-src -v 16.0-CURRENT
(Note the reference to my modified source tree as well.)
(The bulk_a one is for alternate bulk experiments, on rare occasion
that is a "build -a" build seqeuence.)

It looks as if fixing those two errors (duplicate repository priorities and failure to update the jail on major version increments) should put things right.
If anybody's willing to offer improvement please do.

I'm still hazy on what happens when the jail is re-created with a new major version number. Are old package repositories deleted, or simply left behind?

Package repositories record what VERSION they were built with
when poudriere builds them. Later builds compare against the
VERSION indicated for the poudriere jail. If it finds they
are different, then all the port-packages are rebuilt.
Showing the recorded jail version information in the
repositories . . .
# head /usr/local/poudriere/data/packages/*/.jailversion

/usr/local/poudriere/data/packages/main-CA7-bulk_a-default/.jailversion <==

15.0-CURRENT

/usr/local/poudriere/data/packages/main-CA7-default/.jailversion <==

15.0-CURRENT

/usr/local/poudriere/data/packages/main-CA76-bulk_a-default/.jailversion <==

15.0-CURRENT

/usr/local/poudriere/data/packages/main-CA76-default/.jailversion <==

15.0-CURRENT

/usr/local/poudriere/data/packages/main-aarch64-default/.jailversion <==16.0-CURRENT
/usr/local/poudriere/data/packages/main-armv7-default/.jailversion <==16.0-CURRENT
/usr/local/poudriere/data/packages/main-min-devel-lib32-aarch64-default/.jailversion <==

16.0-CURRENT

/usr/local/poudriere/data/packages/official-aarch64-default/.jailversion <==

15.0-STABLE

/usr/local/poudriere/data/packages/official-armv7-default/.jailversion <==

15.0-STABLE

/usr/local/poudriere/data/packages/official14-aarch64-default/.jailversion <==

14.3-STABLE

/usr/local/poudriere/data/packages/official14-armv7-default/.jailversion <==

14.3-STABLE

/usr/local/poudriere/data/packages/release-aarch64-default/.jailversion <==

15.0-RELEASE

/usr/local/poudriere/data/packages/release-armv7-default/.jailversion <==

15.0-RELEASE

/usr/local/poudriere/data/packages/release14-aarch64-default/.jailversion <==

14.3-RELEASE-p6
Compare that to what I reported earlier above for:
# head /usr/local/etc/poudriere.d/jails/*/version
I will note that something like 14.3-RELEASE vs.
14.3-RELEASE-p6 counts as different and leads to
complete rebuilds, when almost always nothing
needs to be rebuilt for a change just in the -p?
part of the text when the rest is the same.
===
Mark Millard
marklmi at yahoo.com
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Dec 21, 2025, at 08:03, bob prohaska <fbsd@www.zefox.net> wrote:

On Thu, Dec 18, 2025 at 09:14:34AM -0800, Mark Millard wrote:

On Dec 18, 2025, at 07:51, bob prohaska <fbsd@www.zefox.net> wrote:

. . .

root@nemesis:/usr/local/poudriere # poudriere jail -l
JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
main 15.0-CURRENT arm64.aarch64 null 2023-08-29 11:22:20 /usr/local/poudriere/poudriere-system
root@nemesis:/usr/local/poudriere #

So you are using METHOD null still and building your own
poudriere jail content.

Did you rebuild /usr/local/poudriere/poudriere-system to be
16.0-CURRENT instead of 15.0-CURRENT ? (Doing so does not
automtically update the VERSION reported above. Same for
TIMESTAMP.)

A cross check on that could be the output from:

# file /usr/local/poudriere/poudriere-system/bin/sh

. . .

. . .

root@nemesis:/usr/local/poudriere # file /usr/local/poudriere/poudriere-system/bin/sh
/usr/local/poudriere/poudriere-system/bin/sh: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 16.0 (1600004), FreeBSD-style, stripped
root@nemesis:/usr/local/poudriere #

So your poudriere jail contains FreeBSD 16, despite what
VERSION showed.
(Later material below deals with updating the jail
in a way that gets teh meta-data update too.)

. . .
Bob should probably report the output of:

# pkg repos -e

Maybe that's the culprit:
root@nemesis:/usr/local/poudriere # pkg repos -e
FreeBSD-ports: {
url : "pkg+https://pkg.FreeBSD.org/FreeBSD:16:aarch64/latest",
enabled : yes,
priority : 0,
mirror_type : "SRV",
signature_type : "FINGERPRINTS",
fingerprints : "/usr/share/keys/pkg"
}
FreeBSD-ports-kmods: {
url : "pkg+https://pkg.FreeBSD.org/FreeBSD:16:aarch64/kmods_latest",
enabled : yes,
priority : 0,
mirror_type : "SRV",
signature_type : "FINGERPRINTS",
fingerprints : "/usr/share/keys/pkg"
}
custom: {
url : "file:///usr/local/poudriere/data/packages/main-default/",
enabled : yes,
priority : 0
}

The pkg repos command shows after substitution of ABI
(if such is involved).

root@nemesis:/usr/local/poudriere #

All three priorities are the same. The custom one was meant to be the highest
priority. Would that be 1, or -1 ?

Modern allows using negative numbers to mean lower
priority than the default (0) and positive numbers
to mean higher priority than the default. negative
was added in pkg 2.3.0 . This was to avoid the
prior status where "a negative priority is
interpreted as a very high unsigned priority" and
"[b]ut as a user of my computer I was surprised that
it is not possible to configure a lower priority
than the default".

See: https://github.com/freebsd/pkg/issues/2455

(2.3.0 was not released until 2025-Sep.)

It sounds like a 1 is the appropriate priority for the custom repository.

Sounds reasonable to me.
But I'm not sure if you ever what to get packages from
FreeBSD-ports instead of locally built ones. It could
be that you want FreeBSD-ports disabled so you only
get locally built packages.
I also do not know if you ever what to get anything from
FreeBSD-ports-kmods . It could be that you want
FreeBSD-ports-kmods disabled so you only get locally built
packages that that type as well (if any).

. . .

But I'm not sure if you actually have source
updates involved in your context vs. you just
like to build locally in general.

If by source updates you mean local customization,
generally no. It's just a philosophical preference
to use locally-compiled sources. Mostly an exercise.
All I'm really trying to do is replace the use of
make in /usr/ports, which frequently fails. It just
occurred to me that a "replace make in /usr/ports"
option in poudriere's makefile would very neatly
define the situation I'm trying to create.

In other words: you use poudriere (or poudriere-devel)
for its clean builds in its isolated builders.

Besides the need to fix repository priorities listed above, it appears
the expected course of action by poudriere was delete and re-make the jail >>> in use when kernel and world incremented major version.

True for METHOD null if nothing is done to cause
VERSION 16.0-CURRENT ( as reported by
poudriere jail -l ).
. . .

There are some "notes to self" at
http://www.zefox.net/~fbsd/poudriere_on_rpi4
Obviously, I forgot my note about "...Freebsd's version will increment...", >>> though it's not the only mistake revealed in the present discussion.

(Those notes have the -DWITH_META_MODE mistake as well and have
old naming for FreeBSD vs. FreeBSD-ports and the like.)

I've fixed the meta mode references but don't understand the reference
to old vs new naming conventions. Could you clarify?

There used to be ( note FreeBSD: vs. FreeBSD-ports: ):
FreeBSD: {
url : "pkg+https://pkg.FreeBSD.org/${ABI}/latest",
enabled : yes,
priority : 0,
mirror_type : "SRV",
signature_type : "FINGERPRINTS",
fingerprints : "/usr/share/keys/pkg"
}
Now there is instead:
FreeBSD-ports: {
url : "pkg+https://pkg.FreeBSD.org/${ABI}/latest",
enabled : yes,
priority : 0,
mirror_type : "SRV",
signature_type : "FINGERPRINTS",
fingerprints : "/usr/share/keys/pkg"
}
There used to be ( note FreeBSD-kmods: vs. FreeBSD-ports-kmods: ): FreeBSD-kmods: {
url : "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_latest",
enabled : yes,
priority : 0,
mirror_type : "SRV",
signature_type : "FINGERPRINTS",
fingerprints : "/usr/share/keys/pkg"
}
Now there is instead:
FreeBSD-ports-kmods: {
url : "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_latest",
enabled : yes,
priority : 0,
mirror_type : "SRV",
signature_type : "FINGERPRINTS",
fingerprints : "/usr/share/keys/pkg"
}

For the likes of the "I ended up deleting and re-creating the
jail with the new -v value" I have scripts, such as the below
example:

# more ~/poud-jail-create-main-CA76-pouds.sh
#! /bin/sh
poudriere jail -d -jmain-CA76
poudriere jail -c -jmain-CA76 -m null -M /usr/obj/DESTDIRs/main-CA76-poud -S /usr/main-src -v 16.0-CURRENT

But, that requires a hard-coded version name. Could the command be modified to read
the current name of the running system?

Presuming that you booted with a kernel of the vintage matching
the poudriere jail content:
# poudriere jail -d -jmain
# poudriere jail -c -jmain -m null -M /usr/local/poudriere/poudriere-system -S /usr/src -v `uname -r`
But nothing says that poudriere jails can not be for older
systems than you booted: the above depends on such a
local usage property.
For reference, an example:
# uname -r
16.0-CURRENT

. . .

Is it feasible to rebuild the jail each time poudriere is updated?

Do you mean the null mounted jail being updated/replaced?
(So: updating the jail's world to match the environment?)
Or do you mean that you updated the ports tree and it got
an update to the poudriere* port that you use? This case
normally does not require rebuilding the jail at all.

It's unclear to me what happens to the package library accumulated
up to that point, which I'd rather not discard if it's still usable.

For the likes of 15.0-CURRENT before and 16.0-CURRENT
after the upgrade: little or nothing could be preserved.
For updates to 16.0-CURRENT to a newer 16.0-CURRENT,
preservation works. Note that for -CURRENT this type
of update does not changea the 16.0-CURRENT text.
(Something like 15.0-RELEASE to 15.0-RELEASE-p1 is a
name change.)
It is possible that when the FreeBSD OS goes from the
likes of 1600004 to 1600005 for 16.0-CURRENT that you
might have some port(s) that you build package(s) from
that depends on tracking that distinction. (Unlikely
for your usage?) If so, the jail should be updated
again to have 1600005 materials.
Ports from FreeBSD-ports-kmods are more likely to have
such issues --but FreeBSD-ports-kmods does not include
all *-kmod* ports (last I knew).
If one wants to build kernel module ports, the jail
also needs a copy of usr/src/sys/ (not all of
usr/src/). Even the non-null METHODS are a mix for
if usr/src/sys/ is included or not. METHOD pkgbase
does include such, as does METHOD ftp-archive .
METHOD freebsdci does not include such. And so on.
Needing usr/src/sys/ in the poudriere jail implies
needing it to track updates related to the likes of
1600004 vs. 1600005 .
I do not build kmods or anything requiring a
usr/src/sys/ tree so my METHOD null jails have
never included a usr/src/sys/ copy. The instructions
for METHOD null in the poudriere-devel man pages
do not mention the usr/src/sys/ issue.
FOr reference, showing the usr/src/sys/modules/
subdirectory in my poudreire jails ( that I have that
use METHOD pkgbase or METHOD ftp-archive ):
# ls -dC1 /usr/local/poudriere/jails/*/usr/src/sys/modules/ /usr/local/poudriere/jails/main-aarch64/usr/src/sys/modules/ /usr/local/poudriere/jails/main-armv7/usr/src/sys/modules/ /usr/local/poudriere/jails/official-aarch64/usr/src/sys/modules/ /usr/local/poudriere/jails/official-armv7/usr/src/sys/modules/ /usr/local/poudriere/jails/release-aarch64/usr/src/sys/modules/ /usr/local/poudriere/jails/release-armv7/usr/src/sys/modules/ /usr/local/poudriere/jails/release14-aarch64/usr/src/sys/modules/

All I'm trying to do is supply ports for the local host running the
local operating system.

Something like
jail -r main
followed by
poudriere jail -c -j main -m null -M /usr/local/poudriere/poudriere-system -S /usr/src -v [present version]
would do what I'm suggesting, but I don't know what to put in the brackets.

For example, for updating to 16.0-CURRENT from 15.0-CURRENT,
presuming that you have booted 16.0-CURRENT:
# poudriere jail -d -jmain
# poudriere jail -c -jmain -m null -M /usr/local/poudriere/poudriere-system -S /usr/src -v `uname -r`
That presumes that you booted with a kernel matching your
poudriere jail's world vintage.
===
Mark Millard
marklmi at yahoo.com
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2