On 3/11/26 07:07, Baptiste Daroussin wrote: > On Wed 11 Mar 13:45, Kirill Ponomarev wrote: >> On 03/11, Yuri wrote: >>> Many ports fail with fs_violation: >>> =>> Error: Filesystem touched during build: >>> extra: var/db/pkg/local.sqlite-shm >>> extra: var/db/pkg/local.sqlite-wal >>> >>> >>> >>> It looks like pkg is malfunctioning in poudriere because these files are >>> only opened by pkg. >> >> Add this to your /usr/local/etc/poudriere.conf: >> LOCAL_MTREE_EXCLUDES="/var/db/pkg" >> >> This tells poudriere to ignore changes under /var/db/pkg when checking >> for filesystem violations after build. The sqlite-shm and sqlite-wal >> files are WAL-mode artifacts left by pkg and are harmless. I guess >> that came with pkg 2.6.2, it now uses SQLite WAL mode which leaves >> behind -shm and -wal files after operations on >> /var/db/pkg/local.sqlite > > This is not needed all poudriere version available in the ports tree > are handling this fine, just use a version up to date. > > Best regards, > Bapt > >
ampere2's from-scratch rebuilds of main-arm64 in 2026 have taken (only latest is built for main, not quarterly): 237:11:07 242:53:19 256:16:05 ampere2's successful 2026 incremental builds of main-arm64 in 2026 have taken: 174:51:18 185:22:02 (There is also the distribution time after a build.) If the port is upgraded just after such a build starts, it can take the sum of time from a sequence of builds/distributions for an update to be available in binary form, depending on the relative timing of the commit: So a notable time delay. ampere3 building alternately 135arm64-default (a.k.a. latest) and 135arm64-quarterly can lead to even longer intervals between updating a specific binary. Another issue is that the port tree vintage used only updates once per cycle-of-2, not after each prior build. (ampere4 and ampere5 do not take as long but have the sequence-of-builds based on relative timing structural properties as well.) -- === Mark Millard marklmi at yahoo.com
