On Dec 21, 2025, at 08:03, bob prohaska <[email protected]> wrote:
> 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:
>>
>>>> . . .
>>> 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
