with the openssl bump, security/openssh-portable is now getting removed by pkg, bugs.freebsd.org/bugzilla/show_bug.cgi?id=273578

Title: 273578 – security/openssh-portable: build fail due to base zlib 1.3 version check fail

cgit.freebsd.org/src/log/sys/contri…openzfs/module/zfs/?h=releng%2F14.0 openzfs will be in 14.0-RELEASE

Hi, I'm running `netstat -rn` and it shows UG1 at some routes

What does UG1 mean?

Specfically the 1

iirc 1..3 are custom flags that routing daemons can set

does freebsd libc support c11 threads?

maybe a question for -dev

hi all

When 14.0 is officially released, is there any reason to upgrade to it immediatly? Or should I just continue on with 13.x? When would I stay with one branch over the other?

RoyalYork: if you have reason to believe your setup might have edge cases, you may wanna test drive an RC, and report any regressions

the py bindings for qt6 are superrr long to generate in poudriere, and they dont spread to more than one core really, are there tips to bulid that nonsense faster?

your clock is behind

why would it be?

i remember setting up timezones accordingly

my timezone is europe/kyiv or something reasonable

though, with none of tried settings it worked as expected

always 3 hours earier than expected.

so I've just figured out an issue with the www/lighttpd port update.

if you have the event handler set to anything but kqueue, it fails a forced assert

introduced only in the new version.

not present in previous version

you can't even tell that it didn't start up---no error really is thrown to the console.

took a while to figure that one out...

I think anyone installing it for the first time is getting kqueue by default, but anyone that's been using it for awhile might have it set to poll or whatever.

Title: Ever wanted to include header files in C using HTTPS? No? Too late : programming

Haha. Web developers trying to infect systems development toolchains.

This is even worse than that actually, I think. I don't see a way of version pinning + verifying integrity (as stated by author, not transport integrity).

a joke?

It frightens me that the repo has 44 stars already and it's only a couple of days old.

intersting to note they opted for docker to build tcc

perhaps the dumbest thing i've seen all month

docker to build tcc?

or a node programmer who decided to learn c and thought "you know what C really needs? to download shit on the fly before i can do anything"

is the goal to build the highest pile of shit?

From the looks of it, it's meant to be a half-hearted joke at an actual implementation. Seems like something he did on a whim.

The goal is for nation states to spread bad development practices via free code so that there are lot more potential opportunities for compromising systems.

It's scary how many app devs I've seen automatically include a public dependency that might only save them a couple of hours, or at the very least without vetting the dependencies more than a couple of minutes.

V-T60, Check the hardware clock time ("dmesg -a | grep clock") is found, which should be set to UTC. Check what date UTC says is the system time in UTC "date -uR" verifying it is correct first. Then look at timezones.

Does "tail -n1 /etc/localtime" look correct? See "man 8 tzsetup".

Note that if a machine dual boots MS-Windows then MS-Windows defaults to setting the hardware clock to local time. Which screws things up.

Ensure that ntpd_enable="YES" and ntpd_sync_on_start="YES" are both set in /etc/rc.conf.

hi

A guy has a zfs question... is this a good place to ask?

if it's zfs running on freebsd, yes, faceface

does freebsd do some suspend kinda thing automatically? asking because if i let my machine stand around for a bit, some time *after* the displays shut off, i'm getting an led blink code from my mainboard that denotes it didn't find the gpu.

and i can't get back into my system. or at least bashing random buttons doesn't do anything. :P

freebsd 14*

phryk, Is it possibly X screen blanking? Look at "xset q".

I intentionally set a 20 minute screen blank and dpms power save "xset s 1800 dpms 1800 1800 1800" for me.

I have seen strange cases where the display driver will not recover after a power down and that makes the system appear locked up.

In those cases I can usually ssh into the system from another system.

rwp: not quite. this happens *after* the screen blanking. when i push a button within a couple minutes (didn't test/measure time), the system doesn't go into the weird "oh no, gpu's gone missing" state, but just switches on the displays again.

but if i leave a fullscreen mpv running so the displays never get blanked, this state won't be reached, so i guess it's somehow connected…

this doesn't happen on windows, so i'm pretty sure it's not a hardware problem, either.

also not quite sure whether to report this at bugs.freebsd.org or the libdrm-kmod github… i reckon i'll first try updating to the latest beta and see if it still happens afterwards…

both and crosslink

phryk: looks like a suspend/resum bug

you could try sysctl hw.acpi.reset_video=1

First, I don't know. But I don't know what would be triggering a suspend. I would check /var/log/messages and see if there is some clue there about it suspending. If it _is_ suspending.