I did pkg query -e '%a = 0' '%n' | wc -l the result was 4481. Prob'ly has to do with me building packages from ports, copying them to this machuine from another, then doing 'pkg add *' from the /usr/ports/packages/All' directory

oh 481 not 4481

shbrngdo: Yeah. Doing a "pkg add" will certainly add it to the list of origins.

anyone here who's used gtkpod on FreeBSD? when I try to add AAC (m4a) files to my library, it complains about missing the mp4v2 library, so I installed the mp4v2 package, yet the error remains

basically everything I've got encoded for my iPod is AAC. without using rockbox my only other option is MP3 which sucks, so I kinda need gtkpod to support mp4 containers

it doesn't appear that mp4v2 is a build option, it seems like it's supposed to dynamically load libmp4v2.so at runtime

FreeBSD's gtkpod package is also way way out of date, it's at 1.0.0 which is from 2010 whereas the latest is 2.1.5 from 2015. I might have to just try building the latest from source. it does kinda seem like it does actually detect libmp4v2 at build time, but it's weird that FreeBSD doesn't have that as a build option

seems the latest version of gtkpod wants libanjuta which is deprecated and a port isn't even available anymore. I guess I need to compile 1.0.0 (or whatever the last GTK2 version is) from source or use some alternative, like gnupod's scripts or gpod-utils

trying to install NetBSD under bhyve and am having a bit of bother

hd1 what's the issue?

hello, I have to upgrade a machine from 13.5 to 14.4. I don't remember exactly at what step it is needed to update the bootcode (loader.efi) .. ? the 14.0 release notes is not very clear about that ..

can I do that after the freebsd-update process or is it required before the first reboot / freebsd-update install?

you should be fine to do it anytime after the update is complete, we try hard not to break loader -> kernel handoff

thanks

your main concern is getting it done before you try to do anything like a zpool upgrade

the kernel can handle new features, but the bootloader may not be able to

and can I upgrade directly from 13.5 to 14.4 ?

should be able to

perfect!

as usual, just make sure you're the on the latest patch release before you update just in case

yes I always check that

i think 14.x is safe there, but 15.x would hit an ordering isue if you weren't

and if I remember well 13.5 was looking into efi/boot but 14.x into efi/freebsd

afaik the loader is put in both because some uefi implementations are broken and only look at efi/boot and not at efi/freebsd

nimaje, I have an HP z210 workstation with that UEFI bug you just described. Except for systems booting Coreboot I think all of the UEFI implementations I interact with are very buggy.

kevans: 13.x to 14.x also had the /usr/include/c++ bug in freebsd-update (but that was fixed a couple of releases back)

ah, right, I was mainly thinking the libsys ordering issue

is it expected that if you `pw usermod root -p 01-jan-1970`, and then `su -` to root, that you are *not* prompted to change the password? is there a different way to force a root password change at next login?

i see /etc/pam.d/su does not have "password include system" like /etc/pam.d/login has, which i think explains it.. but i don't know enough about it yet to know if it's a bad idea to add that

I have an esoteric issue with caddyserver. It will occassionally hang. When looking at truss output, I see it receiving timeouts for _umtx_op() calls. The thread then sleep()s and then wakes up and get the _umtx_op() call timeout, and then sleeps. repeats until I kill -9 the process.

deimosBSD: it hangs for me when i restart or reload it (can't recall) it eventually responds, but usually i'm impatent and just kill it and restart it

restart hangs for me, even if I set the config option of 5s grace period

but that's because it's a busy webserver on my end

Does it actually require a kill -9 hammer? Does a normal kill also terminate it? If so then I would use a normal kill first so that it can clean up on the way out.

i've let this restart go on for 18h

i've tried normal kill. i've been running into this for a month now

but just this morning had time to truss the process

lighttpd never had these issues, but that's like saying my oranges don't taste like blueberries.

i seem to recall `service caddy stop` then `service caddy start` doesn't suffer from the same problem

but it's nearly driven me to switch back to nginx and all its boilerplate that caddy doesn't have

that's what my cronjob is doing

mine is not espically busy

mostly, caddy refuses to do something sane like daily log rotation, so i'm using newsyslog to force it daily

except caddy will just hang on stop for endless hours but still serve content for some reason

and drive me crazy that it can't show logs like every other web server out there

who cares that the file format is not perfect

that too

fwiw, this is what the hung process looks like, agglutino.zw.is/txt/q0lyn6jq

just repeats those lines endlessly

on what version of freebsd does it hang? I seem to remember getting annoyed on freebsd 12 and 13-release for that same reason (hanging), but i think caddy has been behaving for me since 14-release

scoobybejesus: 15 for me

15 for me too

fully patched

rwp: does not seem to respond to a normal kill

is there a setting in sysctl for the microphone mute key led?

on linux its /sys/class/sound/ctl-led/mic/mode

trying to figure out what the equivalent on freebsd would be

theres some kernel bug in linux where the led gets stuck on and i can turn it off in linux with the above command but i cant figure out how to do it in freebsd

I can't tell if the caddy issue is freebsd, environment limits, caddy or just the golang compiled code

hopefully I remember to play around with it a bit before i upgrade to 15. hopefully upgrading to 15-release in late April

I happen to use xcaddy to build mine, for the digitalocean DNS validation plugin

in my case, this is caddyserver from pkg

rtprio: After some pondering, it looks like I've gotten it to work from a clean 14.3-RELEASE-p9 and quaterly packages. Now to try the same exercise with a clean build with 15. At least I've been able to observe a functional state, that I hope will give me the edge to sort out the issue. The other really good bit, is that I know my backend isn't the cause. I'm happy about that.

ah good

A fresh 15.0-RELEASE-p4 build looks like it is working as well. The quaterly packages has sssd2-2.9.6_6. I've got 2.12 built here.

Switched to the latest package branch which has 2.12, and the issues came back.