Has Steam been tested with FreeBSD 14-current? I'm having errors preventing it from running, and I'm wondering if there is a problem with my configuration or it's just incompatible with 14.

These are my errors: pastebin.com/yjh49Lnd

Title: $ steam-installDownloading Steam...fetch: repo.steampowered.com/steam - Pastebin.com

PaddyMac: have you checked out games/linux-steam-utils ?

Where is the charter for the freebsd-doc mailing list?

where can i talk about freebsd dev talk? including kernel and userland apps

here or in #freebsd-dev

ty

jonusenet: also <discord.com/channels/727023752348434432/783418678279929896>

Title: Discord

– that is, #devguide, with #kernel nearby.

any autofs users around?

i got it working not too long ago

which features are you using?

let me boot that up and see

not much, apparently: "/home auto_home -nobrowse"

I found a fairly nasty bug that happens most obviously if you try and use both -media and -noauto maps

Title: 272446 – automount -c clobbers flags of mounted direct map entries

Speaking of autofs, freshports.org/sysutils/devd-mount landed not too long ago.

Title: FreshPorts -- sysutils/devd-mount: Automount tool utilizing devd notifications

I'm only using autofs for /net so I don't suspect I can be a lot of help.

where is libclang.so on freeBSD?

Somewhere in /usr/lib*?

for the base system? I don't think there is one

applications that use libclang need to use one of the llvm ports

Sorry. As RhodiumToad mentioned, for llvm15 found in /usr/local/llvm15/lib

(applications have to link to a specific llvm version because they're not generally compatible)

RhodiumToad: so I _need_ to get libclang from ports?

if you're building an application that needs libclang, then yes, you need to install one of the devel/llvm* ports

llvm in the base system isn't the complete llvm collection, it's basically just enough for the base system

there are good reasons for this (though right now they escape me)

Is it not possible to build whole & everything llvm+clang by twiddling some knobs?

the main reason is to not make the llvm ABI part of the base system ABI

parv: that's what the ports are for

base clang/llvm is stripped of everything non essential for a compiler, because if it wasn't, we'd have to think about ABI compatibility

i seem to recall a few other reasons, but they're "minor" reasons compared to that major one

rtprio Yes. That is what's failing to start. As t turns out, I emailed the maintainer last night. I had a reply this morning saying that a fix is in the repo and should y in ports in a couple of weeks. So it's a known issue.

AllanJude: hi, do you know if user vdev properties on FreeBSD are not settable (returning EROFS) by choice, or is it a bug?

yuripv, how are you trying to set these ?

assuming via zfs set ...

no, using zpool set, of course

one of the two ;-)

e.g. zpool set com.example:spare=foo data nda1p1

k

ioctl(4,0xc0185a56 { IORW 0x5a('Z'), 86, 24 },0xeef7c98f928) ERR#30 'Read-only file system'

it shouldn't be :)

interesting

have you also tried setting debugflags=16 "allow shooting yourself in the foot mode", have plenty of backups just in case

pre-defined properties (e.g. zpool set comment=foo pool vdev) are ok, it's only the problem with user properties

that sysctl is completely unrelated, this is zfs thing and properties are stored in per-vdev zaps

i was just too lazy to look in the code and thought a quick answer would do :D

yeah was thinking maybe it had something to do with it being a raw vdev

maybe detach the vdev first ? then set ?

it's not how it works...

i know i know shouldn't be that way

just making a few initial guesess

you can't set properties on something that does not exist :)

as i said, predefined properties are ok, the problem is only with user-defined properties, so anything outside of this scope is unrelated

k