OK, it's quiet in here so I'll share - 15.1 went fine, and this old clunker still can play videos in youtube. I don't have speakers plugged-in, so not sure it's got audio, but the mixer/volume widget is there... i.imgur.com/W6E3Hta.jpeg

8GB RAM, ancient nvidia GeForce 9500 GT, core i3 (I thought it was a core2duo, but got it confused with other junk pcs).

so python in pkgs has a security vulnerability... but its' the latest available version wtf?

kerneldove: about your squid problem, I would assume that packages failing to properly install with pkg -r is a bug with the port and open a problem report, also that pkg-install file seems unnessesary complex to me and like something that should be possible via pkg-plist, but I just skimmed it, not tested to convert it to pkg-plist (that *.default stuff should be possible via @sample for example)

it seems to work with -c so i just switched to that

the weird fix kevans pointed me to was making sure the jail has /etc/resolve.conf nameserver entry, even tho the jail doesn't have inet, and the host's inet is what's used

seems totally buggy nimaje

like why tf not use host's inet to retrieve pkg, then chroot and install?

jail shouldn't need /etc/resolv.conf

kerneldove: because you could want to use different name servers inside that chroot or different pkg.conf, a chroot is there to isolate the filesystem and thus configurations, the network stack will be the one from the host, but the configuration which name server to use comes from the chroot

Hi! Is poudriere broken (again) on main (main-n287945-495826f69d96)? I am getting: [00:00:02] Recording filesystem state for prepkg...mtree: ./bin: No such file or directory. [ERROR] Unhandled error!

Reverting to n287929-3a6bf8a72d49 resolves the issue. git bisect?

4bd01d6ae01632501b63438b8d9a401db9744a78 is the first 'bad' commit

Rebuilding poudriere does not resolve the issue. But after reverting this commit I had to rebuild poudriere again.

nimaje ya and i'm saying that's a lame model. -j is there for when you want to function as the jail. the way -c works mixes host and jail up in a weird way

to me it seems what you want is handled by -r except for a bug in that port, why should --chroot work different than than how a chroot works?

well, maybe an option that is like --jail but uses hosts networking would be good for jails without networking or when they are on a different network then the pkg repo, not sure what the full differences between -r and -j are

I think that at some point there's just a misunderstanding of what a chroot is and how it works. The resolv.conf thing makes perfect sense and other behavior would go against the way chroots have worked for decades.

fair enough, but point is there needs to be a way to isolate a pkg's behavior to operating against a jail, but fetching using host's networking

kerneldove: it's not really weird, resolver configuration is only read when needed because most things aren't resolving names

it would be weird to preload that from the parent before going in

maybe as how chroots work it's not weird, but as a user that doesn't know every internal, just wanting to point pkg at a jail and have it work on that, but use host's networking, there's nothing intuitive about it

i've been coding for 20 years and using freebsd for just as long. so i'm not an expert but also not a noob