does anyone know why FreeBSD's default mesa package is still so old? evidently the newer mesa versions build and function fine, considering the mesa-devel package isn't also stuck 2 years in the past

sucks that the alternative to an increasingly old release is foregoing having a stable release. I suppose I could branch the ports tree and update the mesa package for myself with 26.0.7

also curious why ScrewDriver1337 hasn't been banned for join/quit spam. it's been ongoing for quite some time

hmm bouncer probably restarted/reconnected, got evicted :)

h3s: the current plan is to remove support for freebsd-update in 16.0-release

When I heard that FreeBSD was making a modernized homepage, I was skeptical (just look at the Debian disaster). But I have to say, bravo! The new page looks clean and modern. Thanks to those who made it!

i still prefer openbsd's website, but the new freebsd one is okay

I can't agree less. What the [censored owing to the language police] is this?

Does someone had any issues with WWAN on FreeBSD? it's not that that LTE is important for me but the features like GPS etc would be nice to work with.

Currently on Debian but i want to to switch to FreeBSD on my T460 (i have good experience with freebsd already)

I did: Driver doesn't exist

Oh, okay, that's unfortunate. Maybe i'll fireup a vm and do pci passtrough.

maybe you can use LTE with github.com/pgj/freebsd-wifibox

I don't believe you can. But yeah that relies on PCIe passthrough

so using a vm and passtrough is the same principle as wifibox

Yes its the same but you have maybe less to config with wifibox

But wifibox doesn't support WWAN devices, only WLAN

sotov1ch: what device do you want to use?

wifi box support what alpine linux supports just change the connection inside wifibox

MelanieUrsidino: Yes, but i'm not interested in getting a WWAN connection. Only for some progs like gpsd or some work with AT Interface. Which should be possible since wifibox is just a vm with pci passthrough where i maybe can use the WWAN instead of the wifi card.

[tj]: i'm using a Qualcomm Sierra EM7455 Snapdragon X7 LTE-A (That's what MM likely said)

currently i only care about GPS-NMEA and GPS-RAW, for now.

Okay, looks like it's not supported. It's a MC7455 but it shouldn't be a big diff between EM7455 and MC7455.

mastodon.social/@ifixcoinops/106086866136488461 re: website redesign

pff "red flags"

#whocaresaboutawebdesign

people being attached to the things they know is not a red flag

it's a natural human phenomenon

"people miss what they always knew, this is the ultimate proof that change is bad"

Change /can/ be good.

Though, change just for sake of change is often not good.

change can be good, I have seen far more bad change than good change

That's very fair

and very subjective :)

Maybe. I think some change can be measured. Some cannot, such as whether one colorscheme is better than another.

However, changing whether the website loads quickly or slowly would be easy to figure out if it is good or bad.

pam_xdg is only xdm and system. That means it's only for local logins?

Appears to apply to anything that's GUIish? Appears you get it with xrdp logins.

Any reason sshd wouldn't have it by default?

i'd guess because sshd isnt a desktop app?

I'm assuming sshd means ssh session. "Why wouldn't you want XDG_RUNTIME_DIR set for ssh session?"

a ssh session is a (ssh) client connection to a daemon (sshd) - and XDG_RUNTIME_DIR may be passed to the daemon from the client, if it is allowed

umm what? I wouldn't expect that sshd would setup XDG_RUNTIME_DIR via pam_xdg on the client setup

Ok so adding that to sshd just works. Wonder if I can get away with a .d file vs editing sshd directly. pam has always confused me.

Why would sshd set a Desktop Environment variable such as XDG_RUNTIME_DIR?

Because it's not just desktop envs?

I think that's the issue. People think XDG is desktop only.

PAM can set XDG and other variables. But sshd should not.

Sorry the sshd pam file. Not sshd directly.

That's what I mean.

In the sshd_config there is also the UsePAM configuration. Which can be UsePAM=no. In which case PAM will not be in the flow and no PAM variables will be set.

If not using alternative login authentication and authorization methods I doubt anyone would even notice.

rwp: it isn't a desktop environment variable, it specifies where programs should put their runtime files, like unix sockets for ipc and if it sometimes isn't set, programs won't find that stuff

Those programs sound like Desktop Environment apps and would not be running over a text terminal serial ssh login.

You don't want to push X11 over a serial console?

why sound they like that to you? and who said that the login is text based? X11 forwarding exists too

btw this is (on the surface) purely text/tui.

'tui' is a curious term. . . and rather new AFAIK.

New? No. Just there's more of them now.

I've done X11 over an RS232 serial line before at 115 kbps. The low throughput only mattered when pushing bigger images - but for all else it was surprisingly snappy. X is chatty and the low latency of RS232 helped a lot.

In order for X11 forwarding over ssh to work the remote end would need X11 apps installed. I am using ssh to login over there but unless I am logging into another desktop there won't be an X11 apps installed on any server system I am familiar with admining. Though I know many people today do install a full desktop on headless servers regardless.

But I am going to set UsePAM=no on a desktop here and test the theory out.

I don't think you can run a full X11 session directly over SSH, you have to use something like VNC in the middle of it.

You can run X11 apps over SSH though.

Also, sorry if I missed something. Coming in a bit late to the conversation

We were talking about ssh X11 forwarding.

And whether it needs any XDG variables set to do so.

It might depend on the application, but I wouldn't think so in a lot of cases. I know when I was playing with it, I was able to run Firefox without it.

Experiment results: Set UsePAM=no. Restart sshd. Verify loss of XDG variables. ssh -X otherdesktop. xterm. GUI is forwarded. No errors noted.

PAM is very useful to provide a standard module interface to plug in other authentication and authorization methods. That's a primary feature of it. Corporations make heavy use of it. But if not using those methods then PAM is not needed.

The new hand uses wayland.

I haven't poked my nose into Wayland yet. I don't know what dragons live there.

And in turn all the wayland only apps (and configs). Right now I'm looking at foot, a terminal.

and all this via headless wlroots with wayvnc.

And what does all of this depend on? XDG_RUNTIME_DIR. I got too lazy setting it myself and wanted to know why isn't it just auto set.

I've not played around with wayland at all, and certainly not on *BSD. Main issue for me is finding a good WM that I actually like on it.

fac3: That's pretty much the issue with it right now.

wayland moves to fast to really make it stable unless if you're using GNOME or KDE. Maybe sway and small handful of others.

Yeah, and I don't care much for Gnome or KDE. I haven't used sway, but I have used i3, and it's okay.

rwp: the discussion is that XDG_RUNTIME_DIR should be set by default for ssh logins too, of course it works without it being set as long as you don't run anything that asserts that variable is set, but inconsistently set XDG_RUNTIME_DIR depending on login method could be a problem for some programs, like not finding an ipc socket

nimaje, Let's not be fuzzy about "some programs". Let's say exactly what programs have problems. Otherwise it is just too fuzzy of a concept. I mean sure there is bound to be some program. But I don't really care if some random Github hack is written in some poor way. Let's have a concrete example.

weechat can be remote controlled via a fifo placed in XDG_RUNTIME_DIR for example

fac3: Sway is the i3 of wayland. :-D

I've heard that. i3 is okay, but I'd still rather not move away from DWM or EXWM

At least not right now.

weechat is mature, robust, and well behaved. I would be surprised if it didn't simply use $HOME/.config/weechat for those if XDG_RUNTIME_DIR is not explicitly set.

i still live in a world where it sits in ~/.weechat

The man page will usually say the files it pulls from and in what order

rwp: I think if you're a good XDG app you're not puttig temp files in your config dir. We're not unwashed UNIX users nowadays.

Oh, it falls back to $HOME/.cache/weechat as is reasonable: blog.weechat.org/post/2021/06/12/XD…-directories?utm_source=chatgpt.com

And ~/.weechat if that exists.

So... weechat works fine without XDG_RUNTIME_DIR set. That is not an example that requires it.

rwp: but what if you locally run weechat and have XDG_RUNTIME_DIR set and then later want to login via ssh and want to control it? the problem isn't it no being set at all, the problem is it being set sometimes

That's a valid use case. It's not one of my use cases. But I will give that to you. It's a valid case. In which case I, as in me not you, would probably set the variables in ~/.xsessionrc to $HOME/.cache/weechat so that it was the same for both.

IME the XDG spec is usually a pain to implement and it's easier at first to use ~/.<whatever> then eventually migrate to XDG when enough people complain.

voooiii... utm_source=chatgpt.com

MelanieUrsidino, You caught me! I asked it for a reference. But the reference checked out. Notice I didn't trust the LLM but pushed through to the reference itself.

I figure that if I am paying for it already with all of the pain of trying to keep web sites online in the face of the endless onslaught of millions of AI scraper bots proxies then I should get some use out of it.

Don't be shamed for using AI. It's a tool. Are you ashamed of using a screwdriver, or a hammer? The anti-AI crew are fanatical but don't let them cower you into excuses for using a tool.

Thanks!

I'd probably be ashamed if someone caught me trying to use a hammer to do surgery.

especially if my reply was something like, "Two years ago, this hammer wasn't even sharp enough to cut skin! Imagine what it will be able to do soon!"

The view that something being "a tool" means it is exempt from any discussions of its capabilities, limitations, or the implications of its use is one that admits of a quite fundamental misunderstanding of what tools are and what they do.

Yes, it's a tool, and you can script / program it too. There's still the right tool for the job, but that doesn't mean it's not a useful tool, especially for pattern recognition and repeating those patterns, an automation machine.

It is critical to understand that it is a token predictor. How all those "thinking" are just filling the context with more probable words to outbalance the vector weights of unwanted words that might be seen during the execution. Once you understand why asking an AI why did it disobey orders is useless, you are experienced enough to use it

It's something you can script and program too. You can extend the capabilities of an LLM with your own tools - either a class of function in your language of choice. You can build your own MCP servers. It's a tool.

port lua54-cqueues is broken on FreeBSD 15 (and 16 supposedly, although I can't test that). The port points at the last official cqueues release, from 2020. There's a fix in the cqueues tree.

What's the right procedure here?

s/last/most recent/ I suppose

Sorry, the port is lua-cqueues (pkg uses the lua version number).

Maybe open an issue/PR on bugs.freebsd.org

Okay, I've requested a bugzilla account.

I the meantime, is there a convienent way to tell ports (via the makefile maybe?) "use this .tgz I'm providing you instead of what you'd normally download"?

Does the port have any patches?

Yeah, you can hack that via the Makefile

If it does then it might just be easier to build it from source rather than go through ports

I've had ports that broke from patches that wouldn't apply after the port was updated.

I don't think it does.

vkarlsen: If the port normally fetches from git, how do I say "use this instead"?

anth: Github?

(Normally I'd just install from source, but I'm nervous about all the other lua things installed from ports/pkg finding it correctly.)

You might be able to just replace the git hash with the hash of the new release.

Yes.

There isn't a new release. :-/

The port uses USE_GITHUB

The fix is in the source tree. I can build the needed artifact.

You can use GH_COMMIT etc

Are we talking about devel/lua-cqueues?

yes

Then you can add GH_TAGNAME= <commit hash> on line 19

You'll have to run `make makesum` after

makesum updates distinfo?

I don't see where the actual URL to download from is defined.

Yes, you don't need the url, that will be generated from the given info

You might have to remove DISTVERSIONPREFIX

Let me try

But I need to provide the .tgz myself, not have it fetch from the repo, where there's no newer build.

Oh, I see how it's building that up with the DIST* bits.

No, seems that's all that's needed. It built fine here from the latest commit (c366149)

All I did was add this line: GH_TAGNAME= c366149, and run make makesum

Oh!

Note that the pkg will be called lua54-cqueues-20200726_1, even though it is much newer

You can change that in the Makefile too if you want

No, that’s fine for me until it’s officially fixed.

I don’t anticipate wanting to go back to the version that won’t run. :-)

:)

spekul: I have played with it

still cant get it to work

(sorry 2 weeks late, been busy)

I am not bios booting, and modified my loader according to what you said

loader is within GELI decryption, but there is no serial output for it

I really wish freebsd documented this behaviour more

thats my loader.conf

if anyone else has any idea how to get freebsd to output via serial during the loader stage please let me know

hmmm according to the man page boot_* are within loader.efi(8)

so they are not bios boot options then?!!?

oh wait

> 2026-05-07 06:55:42 spekul you need to redirect video output to the console in your BIOS/EFI firmware and have the loader enabled to work with the serial console

I thought bios you wouldn't need to, but you still need the firmware to support serial redirect, which consumer hardware doesn't

unless there is a workaround?

> On x86 platforms, if you wish to redirect the loader's output to a serial port when the EFI BIOS doesn't support it, or to a serial port that isn't the one the EFI BIOS redirects its output to, set console to “comconsole”.

from loader.efi(8)

okay so then it is possible, I must have the wrong serial specified

the COMx (windows) ports are mapped to /dev/uartx when the device is /dev/ttyU0 because its a usb serial device

oh shit... that probably wont work will it

it would require the loader to have an understanding of usb

oh wait, but the loader can load a keyfile from a USB stick, so it does have USB logic then... so it should be able to work?

alright I have no clue what to do :/

vkarlsen: back at my computer after my appointment, and that worked perfectly. Thank you very much.

I guess I'm not quite understanding audio here on FreeBSD. on pcm3, monitor is labeled as "rec src" according to mixer, but if I record from /dev/dsp3 using ffmpeg, it ends up recording from the mic, not the system audio, which is what I'm taking "monitor" to mean

mixer isn't showing anything mic related for pcm3, instead the Realtek chip's mic stuff is on pcm4

recording /dev/dsp4 is silent though except for a click at the very beginning of the recording

does OSS just use a completely different definition of "monitor" to other sound systems like pulseaudio? I take it to mean a loopback source, that lets you record the audio playing back through this device

seems I have to either configure a loopback with virtual_oss, or just use pulseaudio

(or sndio, or JACK, but those are arguably less convenient)