is kern.geom.eli.threads applied per partition or as a total?

phryk: should be per-partition, it looks likke

thanks for confirming, kevans :)

just wondering, anyone here uses bhyve CPU pinning feature?

i.ibb.co/hJS5B26v/IMG-20260128-225325827.jpg && i.ibb.co/Q3hw5YXX/IMG-20260128-225323213.jpg <-- sorry for blurry, camera's totally fubared. new bread recipe, hope it's ok

dvl: I *may* have done something stupid by (hard) linking to that file or mis-copying from/to /etc/localtime. But then again, base.txz is only available for -RELEASE, not patched versions. It's strange there's no `freebsd-install repair <path>` (which could also fix permission issues... had a lot of those too). Luckily I have another machine where the zoneinfo file is not broken, so I'll use that

hey, is there a website/url where I can track where the pkg build pipeline is currently at?

I'd like to see when I can get the new rust version as a binary, because now my poudriere wants to compile it, and I don't want my production server to churn at 150% CPU for half an hour

next year when freebsd-update is deprecated, will the sets in the src tree be removed?

I am happy to compile from src, but I cant think of any decent way to install freebsd (even manually) if the build script stops making the base tarballs

I still need to attempt a bsdinstall-less install

install directly from source without bsdinstall, simply because I can :3

i've been doing that a few times now

AmyMalik: yeah I used to like doing it for Linux its just so much fun being able to decide on everything yourself

to be honest, I could even script my own installations to bypass the inevitable end of the freebsd base

as long as I can compile the base as a single entity, and not packages, there is hope :p

meh. I don't really care about the details as long as it works.

15 was released prematurely, i hold.

karolyi: hm, as I understand your problem you want to always build the git commit the repo build last (so poudriere can fetch everything you haven't changed the options for), which you could find in data.pkg in the file data as port_git_hash as far as I understand

nimaje: something along those lines, yes. I compile a couple things for myself (with options changed) and some dependencies are recompiled when they aren't available as pkgs yet, which is the case with rust right now

nimaje: but how do I specify that git hash for poudriere to work with?

extracting that hash is doable with a bit of jq magic

you could just go into the repo and do a git checkout but no idea if poudriere has a proper way for that, I didn't see any with a quick skim of poudriere-ports(8)

hmm, just a sec

yes, probably going to the repo and reseting to that hash is the most viable option

thanks

AmyMalik: how so?

what issues do you have with 15.0?

nimaje: that port_git_hash you mentioned, is assigned to every package and varies. is there an information somewhere of what's the latest git hash the data.pkg is built from? that is, what's the latest ports commit the pkg repo is built with?

the same applies to ports_top_git_hash

hm, no idea I have only found port_git_hash, but that is per package, so not what we want here

lounge.swee.codes/uploads/0ac86cd663fadda7/image.png even if so much memory is used, why is swap not used at all?

Would you want to use swap?

yes

swee, I would question if your swap is even working.

is everything actively used? swap is for stuff that is inactive, if you put something into swap just to get it out again shortly after, then it wasn't worth it

Can you show us your /etc/fstab?

CrtxReavr: p.swee.codes/swee/4516007da9b341a9869b0e8ed4e13312

pstat(8), swapinfo maybe...?

swee, what does 'sudo swapctl -l' say?

Device: 1024-blocks Used:

/dev/ada0p3 4194284 0

file -s /dev/ada0p3

/dev/ada0p3: data

swee: You don't want swap being used (it's slow as fuck in comparison to RAM) in normal scenarios. Treat it as a 'backup' memory which is slower than RAM.

regis, that's just not correct.

Things go to shit real fast if you can't swap.

If there is no need to swap, why would it swap?

CrtxReavr: In certain scenarios - yes. In other certain scenarios (routing?) you may want absolutely no swap on your systems.

swee, df -h

lts: yup.

swee, this is for bash, but if you can set similar for your shell, it makes it really easy to pipe output to a paste site: alias tb='nc termbin.com 9999'

df -h | tb

nimaje: maybe if I can look into the machinery of the pkg building pipeline, I can find something valuable

swee, did you get distracted by something shiny?

the official builders use poudriere to build the repo

Should I stop caring?

If I'm being honest, I wish poudriere didn't exist.

I miss the dates of beign able to 'cd /usr/ports/this/that ; make install clean' and have it reliably work.

Constantly dealing with ports that won't build, and getting told I need to fire up poudriere.

That's not how it's supposed to work.

yeah, some ports have problems to build in unclean environments, but that are still bugs in those ports

nimaje, not sure that's always the case.

what part?

I think the project's gotten to pkg-centric and the work doesn't go into building outside of poudriere.

Packages are great, 'til you need to build a port with non-default options.

CrtxReavr: there's no special sauce in poudriere to get ports working. It's just a clean environment. An unclean environment was a problem in portmaster and portupgrade, etc, too

as the maintainer of poudriere I'd never put special sauce into it to force it to be used

bdrewery: ah, so maybe you can help me

if there is such a thing we should fix it

karolyi: what's up?

bdrewery, I'll be sure you ping you next time I can't get a port to build. >=]

bdrewery: do you know a way to get the ports git hash the current pkg database is built from? I want my local ports repo to set to that one so updated packages since the FreeBSD-based binary builds won't get rebuilt and set my production server CPU afire. :) rust is a regular culprit to that

karolyi: there is no _1_ place unfortunately. Each package has metadata in it though.

bdrewery: I've checked that out (suggestion from nimaje), but the hashes change to every package

if a package hash changes every update it means it is getting rebuilt every update

A lot of the rebuilds are just to be safe but are not optimal of course

Is there a way after a patch release to tell poudriere bulk not to try building dependency ports that will soon again be available as pkgs?

well, you could collect them all and try to ask git to give you the newest one, no idea if git has a good way to do that

It would be nice to have `pkg repo` place the top-level git hash into the repo it creates

bdrewery: I would think that a data.pkg is built from a certain ports git hash, so I could set mine to that and only my locally options-changed packages would get rebuilt if their version (or options) are different, otherwise poudriere would use the binaries from the pkg site. am I wrong here?

nimaje: I could put something together in python for that, but I'd rather just use something that's available :) whic doesn't seem to be the case

lts: poudriere will rebuild all the packages if the .jailversion in the package dir does not match. You could hack at that but risk not rebuilding static-bin packages (like go)

karolyi: the poudriere package fetching does consider remote package options and other metadata to try to match your checkout to fetch from. I'm not understanding "set mine to that". We only publish 1 set per branch right?

I see, thank you. I wonder if that status could be detected somehow, and the cronjob for poudriere then cancelled until next day

bdrewery: the problem is having a more recent checkout than the official builders build from

thank you, I started to elaborate more that that's the exact issue

that makes sense

would be nice to have annotations on the pkg-repo

it would be nice to have an extra key in data.pkg/data to point to the git hash the binaries are built from

bdrewery: right now there is a minor rust version change in ports compared to what's in the binaries and my local poudriere wants to rebuild it which churns my CPU for half an hour, only to build clamd later on

painful :)

so if I could set my local ports to exactly that commit (git reset stuff), I could avoid that pain

got it

here comes that extra key in the picture

I'll look into getting the needed metadata and querying into pkg

would make my life tremendously easier :)

I'm fine with putting it into data.pkg/data, I can get, extract and the query it with curl/tar/jq

I already do some local pkgmirror magic to speed up binary installation :)

bdrewery: should I make an issue about it that can be followed up later on?

karolyi: +1

aight, coming right up

seems to be an easy task to me

What's the easiest way to copy a NULL-terminated string from kernel to userland? getcwd looks rather convoluted.

cracauer, I would ask in #bsdcode on EFnet.

secret channel? :-)