rwp: Emacs!? Bro... (kidding, of course.)

paste.rs/UCGO5 why is the freebsd-base repo not accessible via http?

is there an mirror of that repo that is accessible via http? i would like to do so for caching reasons with squid

emaccin across the universe

ek, I have used Emacs for everything for years. I am using an Emacs IRC to type this in right now! Emacs erc makes a pretty good IRC client.

I mean, emacs being my text weapon of choice and irc being all text this gives me all of the fancy text things like dynamic abbreviation expansion and other things. Spell checking of course but I think all clients do that now.

rwp: Yeah. I have friends that use Emacs. It's like it's own little OS.

I just use tmux+weechat for IRC. For text editing, I decided to go the vi route (only because it was already on everything.) So, neovim with ungodly amounts of plugins for coding, vi/vim for regular editing.

The vi commands are just ingrained after so many years and I don't need to remember other editor commands. Either vi, vim, or nvim is almost always available. So, I just use it.

ek, I started with qed at university. So moving from there to vi was trivial. Play rogue if you want to really learn the movement keys. :-) Then switched to emacs. And stopped there. Never needed to go anywhere else after that.

I am pretty much multi-lingual fluently with the standard editors. I can switch between them without thinking about any of them.

I did try using Emacs for a while. But, I just kept messing things up because I'd default to vi key commands. Again, it just made sense. I'd never really need to install a 3rd party editor to be comfortable.

I don't badmouth anyone's choice. There's a reason we have choices and that's the whole point!

vortexx: iirc you run OpenBSD + bhyve, have you tried running the latest version of EDKII for bhyve-firmware with OpenBSD

I get the following error

this happens on both 7.8 and 7.9

polarian: You're seeing errors using OpenBSD on a FBSD bhyve host?

yes

polarian: Hrm. I don't use bhyve directly, but I do use vm-bhyve and I have no problem installing/running OBSD 7.X.

I just tested a 7.9 install just to be sure I wasn't missing anything.

Using UEFI?

It looks like it based on your provided paste.

this goes out to the poudriere and freshports people.. has anyone tried to compile python311 in the last 2-3 days? I am getting a checksum "issue" but when I look at the changelog.. it says it is fine: freshports.org/lang/python311

i am asking but may put a bug report in as i need python311 to compile llama.cpp

voy4g3r2: I built python311 today via Poudriere. No issues.

hrm.. must has some old files or something

thanks for info ek

voy4g3r2: Sure thing. It could be. I did pull a fresh repo before building. But, it didn't build without any issue on 13.5, 14.4 and 15.0.

s/didn't/did/

No problems on any versions of FBSD (even unsupported versions).

yeah, i am not getting why it is happening to me

everything looks "okay"

and the latest changelog about a diff "issue" i am fixating on, probably improperly

ek, As an emacs user these days I just expect to get abuse! :-) I just own it! :-)

hrm.. so the checksums are not matching the commit

voy4g3r2: What is the error you're seeing?

rwp: Might as well! It is what it is. If you like it, use it.

[00:02:21] [01] [00:00:01] Finished lang/python311 | python311-3.11.15_2: Failed: checksum

haha

failed: checksum

and looking at the distfiles output and comparing to the git commit off freshports.. they are NOT matching

Are you positive that your ports tree is completely up-to-date? What does "sudo git -C /usr/ports log -1" show?

ek: yes using UEFI, that is what EDKII is for :)

Err... -sudo

polarian: Yep. I'm using edk2-bhyve-g202508. Works just fine.

hmmm

welp

I have no clue then

This is an Intel machine, though.

ek: try the following config:

ek: bpa.st/A3OA there you go

if you have EDK2@bhyve installed you should be able to run this no problem

`kldload nmdm` as well

make sure to `set tty com0` in the loader

see if it drops you into the installation media

polarian: Yeah. That's what I do. But, I don't use zvol or some other options.

hmmm

maybe it is an AMD issue then

I have had no issues virtualising on intel

I could make a post to the virtualisation mailing list, but that will likely go ignored lol

bugzilla is prob an option

ek: it shows a commit for openbabel

does anyone have a ryzen based device, and willing to try running the OpenBSD miniroot?

polarian: Have you tried using vm-bhyve at all?

I can give you my config for OBSD 7.9 that I literally just booted to test.

It's just a little CLI front-end to bhyve. But, it's handy.

vm-bhyve is great!

ek: if it doesnt work with bhyve it wont work in vm-bhyve

polarian: That is true. But, the options may be different. I can share my OBSD config. Gimme a second.

voy4g3r2: The date of the latest commit on that is what?

I am too tired to do this right now, maybe tomorrow

wed may 27 19:37:15 2026 -0700

voy4g3r2: openbabel should be correct. Sounds up-to-date

hmmm

I will try this in the morning

its 4:30am I need to zzzzzz

poudriere bulk -j 150Ramd64 -p default -c misc/ggml misc/llama-cpp

polarian: Yowza! Get some sleep.

thx for the help

maybe i will tackle making a new jail.. but does not seem to make sense since the jail is created and destroeyd each run

voy4g3r2: A new jail shouldn't matter.

ah ek this is likely the problem

>

0xc0011029 is MSR_DE_CFG, and I suspect that OpenBSD's applying a mitigation for zenbleed. FreeBSD doesn't do this if it detects that it's running as a guest.

thanks for the confirmation, did not seem to be the issue

polarian: Sure thing. I'm quite sure it'll get resolved.

so I bet if I add -w to the flags it will work flawlessly

and thats why intel works without issue

zenbleed is amd based

and OpenBSD obviously doesnt detect its running as a guest

AH! That very well may be!

will see in the morning :)

ek: i know it is the second diff command: cgit.freebsd.org/ports/commit/?id=d…3b3702ace55f1b777c36047101ad0a211c2

gn

Have a great sleep/morning.

because when i look at my local file, it does NOT match that one..

but the brain says.. tackle this tomorrow.. thanks for the help ek

gives me a challenge tomorrow

voy4g3r2: Of course! What isn't matching? The version?

the SHA256 and SIZE for the 2nd entry

wait a secon.. now it does

i swear

voy4g3r2: You're saying your ports doesn't match the 3.11.15 entry for the makesum?

that is what it was..

i have it running again.. if i wake up and this is still being an issue.. ill look at

forgive my ignorance, but does the fact that efibootmgr returns anything indicate im using efi booting? as opposed to the old bios way?

linux install it asked me grub or systemd-boot but freebsd just breezed thru

for some reason getting i have less confidence getting answers from web search about freebsd

i really should read the handbook

ive always assumed its outdated, thats a bad attitude i think

Does anyone know when firefox will be in pkgs again?

It's there for all except 14 latest

It's not unusual for pkgs to fail during a build and then need a fix and build again. It's a little tricky though to decode the build machine status in order to figure out exactly what happened.

polarian: I don't use the edk-bhyve package, not sure what it's for. Looks like you're getting an AMD issue there

hm portsfallout.com/fallout?port=www%2Ffirefox%24 extract/timeout so probably it gets build next time

rwp: nimaje: thanks

elivoncoder: if it shows BootCurrent: then you should be booted via uefi

imm_, freshports didn't have information earlier but the builder has progressed far enough that now freshports has a build matrix on firefox. freshports.org/www/firefox

For 14:latest only aarch64 has a build done. The others are still pending.

rwp: yes, I saw that quarterly has it built, but not latest, so something probably failed

Or is ongoing

my guees from the extract/timeout would be that the system did too much in parallel at that time and on the next bulk it should build fine, but I haven't looked into the log nor have I access to other monitoring of the builders to confirm my guess

polarian: scratch that, I *do* have edk2-bhyve installed

and it just got upgraded too

Hmm, llvm22 seems to be missing C++23 modules support i.e. libc++.modules.json is missing. Thatis mildly annoying.

Actually, llvm22 seems to gave been built to use system libc++

That...sort of defeats the purpose.

There are more modern libc++ in pkgs, but only for wasm. How odd.

elivoncoder: use `sysctl machdep.bootmethod` to see how the system booted

ah, I should have used --ignore-case with sysctl -a | grep efi …

hello everyone, i am experiencing a checksum error with the most current python311 package, based on freshports metdata, and when i run the build I am receiving a checksum error. I looked at distinfo files and says it should match but when the poudriere environment runs i get this: pastebin.com/az8b401G my brain is telling me it NOT a checksum issue but more of a downloading issue. Anyone have

any tips to help confirm/deny this hypothesis

hm, seems like the patches didn't get redownloaded after the re-roll, can you move them out of distdir and try again?

i should be able to, let me see where they are

i did a distclean, lets see if that works.. i honestly thought it would rebuild EVERYTHING from teh ports tree, thanks nimaje

seems like in the fetch phase it just sees, that a file with the correct file name exists and then skips fetching without checking that the file has the correct checksum and later in the checksum phase it notices the wrong checksum and doesn't try to redownload as poudriere sets a variable do disable redownloading in checksum phase. I would say that is a bug in make fetch as it doesn't verify

files that are already there

hrm.. failed again

i got to be doing some step wrong

as you moved the old file away, it should have been redownloaded now, can you compare the two versions?

voy4g3r2: its a rebuild, nothing major

the update that is

The latest version change was in Jan iirc

I will do some more testing shortly

For the past there days I've had a kernel panic a day. One in the middle of the day (I believe the machine was idle) then the next two I believe during periodic daily. The backtrace is something DRM related but from the cases I seen it might not the real cause but maybe zfs.

Anyone seen something like this before?

I tried to just run daily by hand and it ran without issue this morning.

Scrubing all zfs pools were fine as well.

Nothing interesting leading up to the set of message ~21:00pm ~3am...

What version? Have you run memtest recently?

14.4-p5

boru: I haven't but that's a good idea.

polarian: i am not following? you are the author of this freshports entry?

Ran it when I first got all the RAM for the machine.

Worth ruling that out. It's happened to me before.

Wonder how long a 64G run will be :(

voy4g3r2: sorry, I was meant to ping vortexx, tab completion (your nicks both start with vo)

skered: it will run as long as you let it

rtprio: There's an end.

I've ran it over night on smaller systems and it's "done" the next with (without errors).

But I think in all cases it will be a long time.

voy4g3r2: How are providing the ports to Poudriere? Did you create a separate ports tree for Poudriere or are you using the host's /usr/ports or something?

What does "poudriere ports -l" show?

oi, does anyone use lagg0 to fallback from wifi to wired? and how does that work with a usb wired nic? is there devd secret sauce involved?

ek: I have a host 15.0 -> thick jail -> run poudriere within jail

the ports try is within the main jail and i ahve it under /usr/local/poduriere/ports/default

i manage the port, udpate, through this poudriere ports -u -p default -m git+https -B main

i intentionally isolate the poudriere environment from host, so no conflicts/confusions with my lackluster abilities to manage "issues" running poudriere

the kicker is, it is for one package.. llama.cpp which i need to have special build options because i have an intel i3 and the ports was built defaulting to xeon cpu and freature sets the i3 does not have

rtprio: for a lapto I presume

voy4g3r2: So, Poudriere actually uses jails to do all of its work. So, if you're running Poudriere in a jail, you're running a build jail inside of another jail.

It's not a problem. Just likely an unneeded step as Poudriere keeps everything separate from the host already.

I'm guessing the /usr/local/poudriere/ports/default is in the jail and not on the host?

Unneeded but easier to backup perhaps

skered, Your symptoms seem like a hardware problem to me. Probably failing a RAM DIMM. But also possibly something on the motherboard. I saw that you ran memtest on it.

skered, If it were me I would pull half the ram out and see if the problem persists or not. Either way note the result and swap to the other half of the ram and repeat the experiment. Hopefully it is simply a bad ram dimm. If the problem continues regardless of ram then likely it is a failing cpu or motherboard.

How did you write your second message in five seconds? :-o

I wrote it all at once, realized it was more than 400-some characters the limit of IRC where it would have split the line, split it manually into two messages where each made sense, then posted them one line after the other so that they would post together.

takacs: yep

stupid lenovo only has external/usb NICs so i'm assuming lagg would not care for getting jilted like that

rtprio: I use this, however none of my NIC's are usb. Used example 46 from this section. docs.freebsd.org/en/books/handbook/book/#network-aggregation

rtprio, the Lenovo Thunderbolt docking stations are pretty nifty and have an ethernet port.

rwp: I install a newer drm kmod too

See if I get the same thing tonight or sooner.

Good luck!

Lets hope

I'm getting hundreds of "pkg: getgrnam_r(wheel): Result too large" whenever I upgrade packages on a lot of systems. This also applies to systems running 15 and having quite recent packages installed, so there are only a few packages to upgrade.

Anyone else seeing this?

i ran pkg update/upgrade but dint see anything like that

That would likely be a local system dependent failure. getgrnam_r() searches the passwd/group database. Something corrupted there?

Maybe those databases need to be rebuild? pwd_mkdb?

Could be an out-of-sync world/kernel. Are you using pkgbase?

What does "freebsd-version -kru" show?

No, and I've had this issue for years

On many systems, not just one

I've never seen that error before.

I could easily have a problem on a lot of my systems where I have done the same configuration on all of them causing that systematic failure that only I would ever see.

rwp: We've all been there.

The only thing I can think of is that the 'wheel' group has a lot of members (few dozen)

Run this and see what it says: getent group wheel

But this is only supposed to return an integer

You might have exceeded the number of allowed members for a group. That would be systematic across all of your systems.

What/where is that limit?

Pick one system. Trim the wheel group down to just you. (Don't lock yourself out.) Then update. The error will likely not appear. Add back in members counting the number until it appears again. Then you will know where the limit is experimentally.

forums.freebsd.org/threads/group-file-line-too-long.55909 - "In older implementations, a group cannot have more than 200 members. The

maximum line length of /etc/group is 1024 characters. Longer lines will

be skipped. This limitation disappeared in FreeBSD 3.0."

The "man 5 group" does not list any current limitations.

Perhaps it is one bad user configuration?

There are issues with that group line though, there are duplicate users in it

Wonder how I can fix that -- this is all puppet-managed, not manually

CrtxReavr: sure, they have an ethernet port, but as soon as i pull it out of the docking station the nic dissapears

so what does lagg do when that happens

But yea, number of users seems to be a problem here

Unsure. . . but I don't know why you'd try to use lagg with a single ethernet port.

But yea, number of users seems to be a problem here

~61 users, or ~500 characters, not sure which is triggering

But so far pkg is the only tool reporting it

(gotta go, back in a bit)

What does this say? Errors? Or works normally? getent group wheel

getent returns the user list, complete, with no complaints

And in any other situation it works - these people are able to sudo etc.

I was hoping getent group would report an error which would make it easier to debug. But, oh well, something is going on. Maybe use truss to trace through a pkg ugprade and see what system call fails? Anyway... Later!

And also good luck!

I guess this company just grew too large. ;)

You said there's duplicates in the group line?

rtprio: lagg would need both nics to be present. But using the config I posted earlier, when the master interface loses connectivity lagg will fail over to the addtiional interface.

ok, so then lagg wouldn't work in this case

it sounds like

Sounds like the concern is what happens when the interface just disapears?

which it does when i unplug from the docking station

Yeah, I can't say that I have that scenario

My nic is removeable though, I could test.

i suppose i could try it

I would hope that when lagg loose the active nic, it would just fail over.

ek: not any longer. Didn't help.

Ltning: I wouldn't think 60-ish users in a group would be an issue anyway.

Just as a test, what happens if you remove everyone but you from the wheel group?

rtprio, have you looked at lagg(4)?

I know you said it was Puppet maintained so it'll be replaced at some point, I would assume.

But, a quick test should be doable.

nothing about the interface going missing, just the interface going down

as i recall

Give it a test?

I keep looking for `nvi` walkthroughs or reviews and I get neovim/vim stuff instead.

Sad

nvi isn't that different from vim, beyond vim's auto-formatting & syntax highlighting ability.

I alwys though of nvi has a bug-free version of the original Bill Joy vi, which had its share of quirky issues.

Like crashing if you made your terminal too wide.

ek: It works as long as I don't go past ~61 users or ~500 bytes -- It also works with just me in the list, as one would expect

wavefunction: Like CrtxReavr mentioned, it's basically the same as vi/ex. So, anything that works for those, should work for nvi.

In entirely other news: Holy *crap* the new iwlwifi/linuxkpi stuff in stable/15 is *awesome*

So, you can just follow an ex/vi walkthrough.

Ltning, you mean limitations with the actual /etc/group file?

CrtxReavr: Well - pkg (and the message I pasted above) is the only place it's a problem. The wheel group works fine for all its members for all other purposes - chiefly sudo

Ltning: Maybe request the Puppeteers to clean up the wheel group? I'm not sure why that many people would need to be in wheel, but it may be required.

There used to be a port called vilearn - it had five lession to vi comfort - was actually quite decent. You can prolly find a version of it archived somewhere.

Also, if you can submit a PR to bugzilla regarding this issue, perhaps someone can take a look and update FBSD to fix this as it should be a non-issue at this point.

Could also grand sudo access to groups other than wheel.

CrtxReavr: Yeah. That's kind of my thought. But, it might not be sudo-related at all. I have no idea why they want so many users in the wheel group.

Could be something completely unrelated.

Regardless, a limitation of 61 users in the wheel (or maybe any?) group seems... not right.

Yea it's got nothing to do with sudo per se, it was just the easy way to manage these users. A lot of files/dirs are only accessible to people in the wheel group, and the same users also need sudo access, so ...

I'll happily discuss our choices here, but you bring the beer. ;) Fact is getgrnam_r(wheel) should not fail like this.

Ltning: Makes sense. Personally, I wouldn't use the wheel group for this. But, it is what it is.

Please submit a PR.

I will once I dug a bit more.

Excellent!

Shouldn't truss -f show the actual invocation of getgrnam_r ? Because all I see is a geteuid() followed by opening /etc/spwd.db and /etc/group, after which it write()'s this error message.

wavefunction, I think you can figure out how to make it work: bpa.st/A5YA

wavefunction, it was actually stupidly easy: bpa.st/6ZBQ

Sorry, thank you ek and CrtxReavr -- I _know_ vim and use it regularly. It's just that there are clear vim-isms in my brain. :-D

Where does one get `vilearn`?

wavefunction, the first link I pasted literally shows you how and where I got it.

CrtxReavr: -facepalm- I pulled up your second link first. My bad.

hi everyone, I have an app of mine that freezes completely on my FreeBSD server. Completely stops exporting metrics, the http socket sends back "broken pipe", and then after half an hour or so, it goes back to life.

I have limited knowledge about how to debug such things, and I'm wondering if learning DTrace probes would be good? Or would they not report anyting useful perhaps?

I'm quite lost regarding this, I've been a happy FreeBSD tourist for some years now, but it's my first obscure failure mode that I experience while on the platform :)

If you know it only happens after at least a half hour, start an strace at ~20mins in and write to a file (as a first approximation)?

or maybe the better question is, Hecate, can you still access the machine while the app is frozen?

wavefunction: yes absolutely. ssh, btop, tmux, nginx, postgresql, varnish

everything is A-OK except for this godforsaken application

wavefunction: the freeze happens for 30mn, I have to see a bit more if there is any regularity to it.

but I'll keep strace in mind ok

wavefunction: this is what the metrics look like: i.imgur.com/wk1cQfs.png

ek: sorry for dleay work got the best of me.. yes the /usr/local/poudriere/ports/default is inside the jail and agree it is just another layer of abstraction.. probably not ncessary but helps me focus on the particular focus and not muddy the waters in my brain.. and server

voy4g3r2: No problem. Just trying to get to the bottom of why your Poudriere ports tree seems to differ from what it should be using.

If you're inside the jail (jexec), what does "git -C /usr/local/poudriere/ports/default log -1" show?

the openbabel from wednesday

i have NOT updated the ports tree since we talked yesterday

part of me wonders if i should blow away the whole tree and rebuild it

it makes no sense, especially when i see the commit and shows the "right" thing

made a new tree.. kept default around and lets see what happens :)

well same result.. son of a gun

voy4g3r2: How did you create the new tree?

poudriere ports -c p HEAD

poudriere ports -c -p HEAD

voy4g3r2: So, that new tree should be in /usr/local/poudriere/ports/HEAD, correct?

If you run a "git -C /usr/local/poudriere/ports/HEAD pull" what happens?

Does the port you're trying to work with look correct in that tree?

Hecate: What application is this?

ek: yes that location is correct and when i just did a pull.. i got a few updates: rabbitmq, pluma-plugin, engrampa

Should I save the OS from Ironport devices I just got? It's freebsd with custom software on top

voy4g3r2: So, now, if you run a "poudriere bulk -b latest -j jail-name -p HEAD -f /usr/local/etc/poudriere.d/list-of-ports" what happens?

i do somewhat of a similar command

Obviously changing "jail-name" to the jail you'd like to use and "list-of-ports" to a file with a list of the ports you're trying to build.

i will run poudriere bulk -j 150Ramd64 -p HEAD -c misc/ggml misc/llama-cpp

it is my understanding it will rebuild ALL packages because the -c makes it happen

HEAD is the tree i just made

ohh i did myself a disservice.. -b i do not have that

Sure. That should work. The "-c" just cleans all the previous stuff out. Shouldn't be a problem.

And, yes, "-b latest" helps quite a bit if you don't absolutely have to build everything from ports.

On big builds, it saves me a couple hours.

oh wow.. yeah it just downloaed a bunch of "stuff"

well it is running.. fingers crossed

Ltning, truss traces system calls but getgrnam_r() is a function call. Different layer.

Yeah I realised too