On Thu, Dec 18, 2025 at 09:14:34AM -0800, Mark Millard wrote:
> On Dec 18, 2025, at 07:51, bob prohaska <[email protected]> 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 <[email protected]> wrote:
> >>
> >>> bob prohaska <[email protected]> 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
>
The poudriereupscript is run after finishing a world/kernel install. Thinking
it over, the update commands seem the same as the setup commands so apparently
the answer is "yes".
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 #
> >> 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.)
>
It sounds like a 1 is the appropriate priority for the custom repository.
> >> 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.
>
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.
> > 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
>
[examples snipped]
> (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.)
>
I've fixed the meta mode references but don't understand the reference
to old vs new naming conventions. Could you clarify?
> 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?
> 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 . . .
>
Is it feasible to rebuild the jail each time poudriere is updated?
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.
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.
Thanks very much for reading!
bob prohaska
