i would like to assume that freebsd's libc doesn't have this issue: securityonline.info/cve-2024-2961-g…or-to-php-attacks-patch-immediately

Title: CVE-2024-2961 - glibc Vulnerability Opens Door to PHP Attacks: Patch Immediately

freebsd libc is not glibc

flibc.

glibc: all the C with none of the portability!

what's a typical build time on things like rust and gcc? i've got poudriere-devel running, and the those two have been going for 2 hours now. i've only ever compiled things before with synth, and on a lower spec'ed system i don't recall it taking this long.

markmcb: bootstrapped or no?

rust is building it's own copy of llvm during that, so expect some hours

TommyC: i don't know what that is, so i'm guessing no

angry_vincent: thanks, i'll just let it run then

markmcb: rust could be 2-4 hours, or more, depends a lot on your cpu. gcc is usually a bit quicker. make sure you're using ccache as it can significantly improve subsequent build times

lw: thanks, not sure i'm using ccache, will look into it

i see there is ccache and ccache4 available. stay with ccache?

i am apparently using 3.x, i don't know if poudriere supports 4

i would be really nice if we could more broadly test WITH_PORT_LLVM, and make it the default.

Morning all. I notice when I add a .vimrc to set mouse-a all of the other config disapears and I cant seem to find a default vimrc config in /etc. Any ideas where it gets its main settings from?

P-NuT, have you checked under /usr/local/etc?

if it does not exist there.. sometimes $HOME/.vimrc or maybe even $HOME/.config/vim/.vimrc

pkg-static: py311-werkzeug-3.0.2 conflicts with py311-werkzeug2-2.3.8 (installs files into the same place). Problematic file: /usr/local/lib/python3.11/site-packages/werkzeug/__init__.py

for poudriere, is there a ratio of cpu:ram that works better? e.g., if ram is constrained, is it better to have 8 cpus at 4G each, or 2 cpus with 16G each?

I don't think RAM is divided among CPUs that way. In both cases, what you would have is 32GB RAM shared, with all your CPUs having access to all of the RAM.

markmcb: if you're using the default settings with tmpfs, except wild swings in memory use that make it almost impossible to budget memory-per-core in a useful way... you can improve this by disabling tempfs for certain very large ports, like rust

s/except/expect

(also electron, chromium, things like that)

unfortunately because of the way poudriere works it's very hard to tune it to make efficient use of available resources - you have to just tune it so the worst case situation doesn't break the build

oh, i was just looking through the settings. MAX_MEMORY and PARALLEL_JOBS make it seem this is tunable. I ask because with no limits set on 8 cpus and 24G of ram, the bhyve instance running poudriere crashed twice processing rust with memory errors.

i set it to 2 cpus and 10G max mem (with 24G total still) ... will see how it goes

i don't think MAX_MEMORY does what you want, won't that just cause the jail to swap if it exceeds the limit?

markmcb: TMPFS_BLACKLIST is the setting you want to stop large packages using tmpfs

also with PARALLEL_JOBS, you need to tune this at the same time as MAKE_JOBS_NUMBER in your poudriere make.conf... the most efficient setting is with MAKE_JOBS_NUMBEr=1 and PARALLEL_JOBS around the number of CPUs, but you'll find this doesn't work well with packages that take a long time to build (like, again, rust), so you need to wait ALLOW_MAKE_JOBS a bit and reduce PARALLEL_JOBS proportionally

er, s/wait ALLOW_MAKE_JOBS/raise MAKE_JOBS_NUMBER/

i find MAKE_NUMBERS_NUMBER=4 and PARALLEL_JOBS between (ncpus/4) and (ncpus/3) works okay

MAKE_JOBS_NUMBER=4

who the heck came up with MAKE_NUMBERS_NUMBER ?

that's a crime against , i dunno, æsthetics and semantics at the same time.

meena: i believe that was lw making a typo :P

indeed it was me who accidentally invented this setting just now :-) should have been MAKE_JOBS_NUMBER. i just woke up...

lw: which timezone do you live, relative your body?

i was about to acuse one of the frenchmen of inventing that variable, but I'm glad it's just lw

pas moi

meena: my days are about 26-30 hours long usually so it varies over time

i forgot this is a big your mom joke, xkcd.com/320 i only remember the smallprint.

Title: xkcd: 28-Hour Day

hm, which port contains an EFI firmware for qemu-system-x86_64?

oh, it comes with qemu, nm

lw: sorry, had to step away, thanks for that, i'll adjust my config accordingly and see how it goes

hmm, what's going on here le-fay.org/tmp/30d/Eikfy1.txt

ah needs -cpu max

lw: confirming that only setting MAX_MEMORY still resulted in a crash. i set TMPFS_LIMIT and will see what happens. i don't see a setting MAKE_JOBS_NUMBER in the example config, but it says MAKE_JOBS is disabled by default so i'll keep with that for now and see if the tmpfs limit helps

markmcb: enable MAKE_JOBS in poudriere.conf then you set MAKE_JOBS_NUMBER in /usr/local/etc/poudriere.d/make.conf

since that's a ports setting rather than a poudriere setting

ah, got it

the problem is, poudriere doesn't know how many jobs each jail is running, so if you set both MAKE_JOBS_NUMBEr and PARALLEL_JOBS to ncpu, you will end up with ncpu^2 jobs which is not what you want - so you need to balance those two settings

(the lower PARALLEL_JOBS is, the more overhead you get due to jail setup/teardown which reduces efficiency, but the lower MAKE_JOBS_NUMBERS is, the higher the total build time for one package can be)

weird that i have 32GB of memory, not VMs running, and yet zfs arc is only 5GB. top says 12GB of memory is 'inact'

how do you start dhcp on a bridge interface? i tried this, but it seems to never actually start dhclient: ifconfig_bridge0="addm vtnet0 addm epair0a addm epair1a up DHCP"

ok curious, using SYNCDHCP works

jbo: ping, ping. ping. pung.

jbo jbo jbo

how do i boot FreeBSD/powerpc under qemu? obvious attempt fails: le-fay.org/tmp/30d/jUbr85.txt

ok nm wiki.freebsd.org/QemuRecipes says this just doesn't work

Title: QemuRecipes - FreeBSD Wiki