@dvl I always chose the pkgbase method when using poudriere to create a jail.

Historically (before FreeBSD 16.0-CURRENT):

poudriere jail -c -v 15 -j main -m pkgbase=base_latest -U https://pkg.freebsd.org/

โ€“ from <https://www.reddit.com/r/freebsd/comments/1cmffhu/poudriere_jail_method_pkgbase/l3atzzs/> (you were in a different thread under the same post).

poudriere-jail(8) and pkgbase: FreeBSD-base package cache accumulation: <https://github.com/freebsd/poudriere/discussions/1276>

#FreeBSD #poudriere #pkgbase

pkg.FreeBSD.org

Well wouldja lookit that. It actually did need that much memory, and with a bit more configuration I got it to build the package that I wanted. ๐Ÿ˜ฒ

A little more mucking about with setting up a bare-bones local package repository and it's done. It works, as far as I can tell.

Of course after building over 350 packages, when I went to install it, it only needed 4 packages to satisfy everything.

Will I get significant mileage out of the new application? Hard to tell. But at least I'm in a place where I can perform decent builds to plug the odd gap in the quarterly package repository.

Thank you #FreeBSD and #poudriere.

I had been thinking of what to do with the 2012 #MacPro that I crammed full of 64 GB of memory.

I found something in #FreeBSD #ports that I wanted to build, and my newer machines with 32 GB of memory each couldn't handle it. Somewhere within the giant dependency graph of over 350 ports, there are two versions of LLVM as well as all of Node and Rust. A #slow process would be one way to describe it, but that might be underselling it a bit.

I guess I'm #reducing #waste a little bit, maybe? I don't know. I don't know if what I'm building will even work or be useful. But hey, at least I get a little experience with #poudriere so I guess it can't be all bad?

Today I removed devel/freebsd-git-devtools from a buildlist I have in #poudriere - it has been renamed.

I removed it because it wasn't installed on any of my hosts.

I conclude that by this query:

samdrucker=# select host from hostswithpackageshowversion('freebsd-git-devtools');
host
------
(0 rows)

Then I got to thinking: where was it installed and when?

The comment in the buildlist said:

-# for working on FreeBSD
-
-devel/freebsd-git-devtools

I went back to the SamDrucker database and struggled parsing the JSON for a while. Eventually I came up with this inefficient but effective query:

samdrucker=# select date_added, client_ip from incoming_packages where data::text like '%freebsd-git-devtools%' order by date_added desc;
date_added | client_ip
----------------------------+---------------
2024-01-17 03:05:26.208061 | 10.55.0.29/32
2024-01-16 03:24:16.145212 | 10.55.0.29/32
2024-01-15 03:39:19.388747 | 10.55.0.29/32
2024-01-14 03:58:35.967538 | 10.55.0.29/32
...
2023-04-01 03:35:54.836752 | 10.55.0.29/32
2023-03-31 03:59:51.397951 | 10.55.0.29/32
2023-03-30 03:52:11.768713 | 10.55.0.29/32

That tells me it was installed on one host for about 10 months. That host is pkg01, my package build server.

This type of search was one of the orignal goals for SamDrucker, but having historical data has helped me here.

SamDrucker was written for FreeBSD, but it wouldn't take much to port. Both client and server are lightweight and easily understood.

The PostgreSQL function might take a bit of work if you want to migrate away from that choice. The reset is all shell/lua.

https://github.com/dlangille/SamDrucker

GitHub - dlangille/SamDrucker: Stores lists of packages installed on hosts

Stores lists of packages installed on hosts. Contribute to dlangille/SamDrucker development by creating an account on GitHub.

GitHub
I am running #FreeBSD RELEASE 15.0 with #pkg for package management, no #ports at all. It appeared to me that the Joe's Window Manager port, x11-wm/jwm, was built without #SVG image support by default. However svg files are actually widely used by multiple icon themes, meaning that many of them will not work under #JWM . Should I simply compile it manually out of ports tree? I mean getting the ports tree is not difficult but setting up #poudriere and all just for one package seems tedious. Are there any other simpler waysnto achieve this?


#AskFedi #BSD #RunBSD #unix #WM

New ๐—™๐—ฟ๐—ฒ๐—ฒ๐—•๐—ฆ๐—— ๐—ฎ๐—ป๐—ฑ ๐—ฃ๐—ผ๐˜‚๐—ฑ๐—ฟ๐—ถ๐—ฒ๐—ฟ๐—ฒ ๐—ถ๐—ป ๐—›๐—ถ๐—ด๐—ต ๐—ฆ๐—ฒ๐—ฐ๐˜‚๐—ฟ๐—ถ๐˜๐˜† ๐—˜๐—ป๐˜ƒ๐—ถ๐—ฟ๐—ผ๐—ป๐—บ๐—ฒ๐—ป๐˜๐˜€ [FreeBSD and Poudriere in High Security Environments] article on vermaden.wordpress.com blog.

https://vermaden.wordpress.com/2026/01/07/freebsd-and-poudriere-in-high-security-environments/

#verblog #freebsd #harvester #pkg #poudriere #server

New ๐—™๐—ฟ๐—ฒ๐—ฒ๐—•๐—ฆ๐—— ๐—ฎ๐—ป๐—ฑ ๐—ฃ๐—ผ๐˜‚๐—ฑ๐—ฟ๐—ถ๐—ฒ๐—ฟ๐—ฒ ๐—ถ๐—ป ๐—›๐—ถ๐—ด๐—ต ๐—ฆ๐—ฒ๐—ฐ๐˜‚๐—ฟ๐—ถ๐˜๐˜† ๐—˜๐—ป๐˜ƒ๐—ถ๐—ฟ๐—ผ๐—ป๐—บ๐—ฒ๐—ป๐˜๐˜€ [FreeBSD and Poudriere in High Security Environments] article on vermaden.wordpress.com blog.

https://vermaden.wordpress.com/2026/01/07/freebsd-and-poudriere-in-high-security-environments/

#verblog #freebsd #harvester #pkg #poudriere #server

For those of your with your own #poudriere installation, did you upgrade to 15.x via freebsd-update or pkg?

I can't build 15 packages before I'm on 15....

so I guess at least one host will always update using #FreeBSD provided packages, forever.

Hm, did something change how #poudriere remembers progress? Normally, I rsync poudriere/data from one machine to the other, but now the new machine says "pkg bootstrap missing: unable to inspect existing packages, cleaning all packages... done", what am I missing? #FreeBSD
The upgrade to #php 8.4 made #mediawiki a total dumpster fire. Currently rebuilding #nextcloud-php83 on #poudriere so I downgrade back to php 8.3