Please run an exp-run with WITH_PKG=devel to test 2.5.99.1 which will become 2.6.0
please hold, there is a last minute fix, I ll make a 2.5.99.2
done
One more regression: https://github.com/freebsd/pkg/issues/2607
this tegression does not impact the exp-run (well should not)
(In reply to Baptiste Daroussin from comment #4) FWIW, own local mini exp-run of ~1500 packages (+ pkgbase outside of poudriere-devel) went fine with 2.5.99.3 and pkg upgrade -f is OK as well with latest ports and base. (I did local speculative bump of ports-mgmt/pkg-devel to 2.5.99.3 with GH_TAGNAME set to b3bdad1ff553 prior to 2.5.99.3 being tagged.)
When using poudriere in qa mode, there is often a build fs violation detected that didn't happen previously: =>> Checking for filesystem violations... done =>> Error: Filesystem touched during build: extra: var/db/pkg/local.sqlite-shm extra: var/db/pkg/local.sqlite-wal a few examples (there are thousands): https://pkg-status.freebsd.org/gohan06/data/143amd64-default-foo/2026-02-15_17h20m29s/logs/errors/massxpert-6.0.3_1.log https://pkg-status.freebsd.org/gohan06/data/143amd64-default-foo/2026-02-15_17h20m29s/logs/errors/xload-1.2.0.log https://pkg-status.freebsd.org/gohan06/data/143amd64-default-foo/2026-02-15_17h20m29s/logs/errors/lidia-2.3.0_3.log
this change is expected, but yes we need to make sure thise cases are ignored.
Apart from the violation in var/db/pkg/local.sqlite* , exp-run looks fine
it is weird I cannot reproduce the fs violation issue: I tried with bulk -t x11/xload
I also posted on https://github.com/freebsd/pkg/issues/2615 . Running `pkg delete -nf py314-numpy-1.26.4_12,1` will also remove the following dependencies: --- pkg delete -nf py314-numpy-1.26.4_12,1 Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 3 packages (of 0 packages in the universe): Installed packages to be REMOVED: inkscape: 1.4.3_2 opencv: 4.13.0_3 py314-numpy: 1.26.4_12,1 Number of packages to be removed: 3 The operation will free 339 MiB. --- Isn't this different from the expected behavior?
(In reply to Ken DEGUCHI from comment #10) Yes. Already discussed on the mailing list. I think the fix will come soon.
2.6.1 committed.
(In reply to Baptiste Daroussin from comment #9) I guess the filesystem violation issue occurs only when BUILD_AS_NON_ROOT in poudriere.conf is set to "no". (My poudriere setup uses ccache so the value is set to "no" and has been hit by the same issue recently.) Can you try with BUILD_AS_NON_ROOT=no to see if the issue is reproduced?
thanks for the hint, I can reproduce and fix now! note: I wonder why the cluster defaults to build as root?
(In reply to Ken DEGUCHI from comment #10) Yeah, this just nuked my system earlier on after attempting to perform a security update on png, which I'd presumed would be a straightforward, er, "experience". I hadn't even asked for pkg to be included but it's somehow "essential" so it came along anyway with this new and untested alpha version of 2.6. Which then decided it would be a laugh if it deleted most of my installed packages without warning, and certainly without asking. Fortunately I was able to roll-back to an earlier ZFS snapshot but it still took a lot of tidying up (and also locked up the entire system pretty hard because rolling back a live filesystem turns out to make the swapper unhappy, perhaps unsurprisingly, but it was already in a terminal mess thanks to half the running processes no longer having any tangible presence on the filesystem before the rollback) so I am definitely not feeling in a very friendly mood towards pkg 2.6. D: I'll have to fudge the database for the foreseeable future to keep it at 2.5.