anyone recall offhand when close_range was added?

looks like 12.2

mcrane: that doesn't necessarily work given modern printers unfortunately

mcrane: fwiw I have had success with running a linux cups driver under freebsd

RhodiumToad: I’m sure it’s not going to work with every printer but I was happy it worked with the one I had

printer-driver-splix seems to be what my Samsung laser users, fwiw.

what model?

I have a samsung ML-1670

25 somthg

lemme see if cups knows as im not near it

Samsung ML-191x 252x Series

that link gives a cloudflare error page

Most samsung ive met use that package

;(

sec

openprinting.org/driver/splix seems to be at least some info

Title: Driver: splix | OpenPrinting - The Linux Foundation

I looked into splix when I got the printer; it supports ML-1640 but not ML-1670

Mine is a Samsung xpress c410w

ah shame

in particular, for whatever reason the 1670 doesn't use SPL but rather something undocumented (and not easily reverse-engineered, I did take a look at that)

annoyingly, the linux driver for mine no longer seems to be downloadable anywhere (there are downloads that claim to be it, but which are older than the one i have)

(if it had been downloadable still, I'd have submitted a port for it)

:( tragic

the linux driver works surprisingly well

(albeit with a long dependency list of linux packages)

Ah shit.

No aurora to see here :(

Hey guys! I'm on the brink of doing my third 13.1 -> 13.2 update. The first one went really bad (let's not get into details here, zfs mount error 6 on boot, had to reinstall in the end). So I was a little anxious about the second one. It all went through without a hitch, but /etc/os-release still says "13.1-RELEASE-p7" while uname -K ; uname -U both say "1302001". I'd like to understand why before I do the third update

Was the second attempt to install 13.2 from scratch or over existing 13.1?

the second one was a separate machine, originally installed with 13.1 and then went through "freebsd-update -r 13.2-RELEASE upgrade; freebsd-update install; reboot; freebsd-update install"

Is "/etc/os-release" a symbolic link there to a file in "/var/run"?

/etc/os-release: symbolic link to ../var/run/os-release

what does freebsd-version -u output

freebsd-version -u

13.2-RELEASE

have you rebooted since completing the upgrade?

(since os-release is generated on boot)

i think so, but i'm not entirely sure. might be the first boot since that initial reboot during upgrade. I'll reboot the machine and report back, might take me an hour or so since it's in use right now

or maybe do service os-release start

that did it!

wonderful

that should run automatically on boot

Wait. So need to re-boot twice for properly updated files?

this might very well be the boot from that update dance i listed above

as a rule you should reboot after the update is complete

after the second "freebsd-update install"?

after you've finished doing everything

i'll throw in another reboot, thanks! feels great to have that resolved, i'll attempt the next machine in the next few days :)

Is it wise to *clean* the /boot/loader.conf from all the customizations, before upgrading to a release? E.g. 13.1 -> 13.2, to not have any external adventure during then?

...and revert the modifications back after it's done..

(for the record, none of my machines have any loader.conf modifications)

tercaL: yeah, no shouldn't need to do that at all

"no" to which one? :)

rtprio: I shouldn't need to customize it at all?

not between 13.1 and 13.2

ah, there's no current-users list, lists.freebsd.org/archives/freebsd-current/2023-April/003582.html

Title: Fwd: dbus broken?

I wonder if this was kqueue1

Good day

I have a PHP hanging randomly @100% cpu usage. Is there a way to see at which module the deadlock is occurred ?

nerozero: nextcloud ..?

mage not only, php / fpm in general

made a trivial script and placed it in gnu-watch, after a day or so found that php running a script eating 100%

pstack utility should do the trick i guess

if not - will try to debug with gdb

whre you truss the process does it stuck on sched_yield() ?

(truss -p pid)

accidently killed a process couple minutes ago :( so ... waiting for "next occasion" ...

if you know known thread on a freebsd forum please share, will post there my findings

otherwise will open a new one and will post here

I has this issue randomly with Nextcloud for months and just discovered that it was because in my case ImageMagick was compiled with OpenMP support and the php module didn't like it

mage, thanks for note, will look now into my poudriere config

I just recompiled ImageMagick without OpenMP and problem is solved since

can confirm that, my ImageMagick6-nox11-6.9.12.58,1 has OPTIONS_FILE_SET+=OPENMP

rtprio: Well actually I meant, removing all modifications, customizations inside loader.conf, BEFORE upgrading to 13.2..

but that doesn't explain the issue with simple script

nerozero: github.com/Imagick/imagick/blob/master/README.md#openmp

Title: imagick/README.md at master · Imagick/imagick · GitHub

I would try to disable it and see

mago, thank you, will post the results here after couple of days

mage, Thanks (for the ImageMagick & OpenMP connection)

I wonder if ImageMagick7-nox11-7.1.0.62_2 has the same issue?

(has OPTIONS_FILE_SET+=OPENMP ?)

I was "lucky" the process hanged right away: truss -p ... -> sched_yield() ...

I guess - this is it

mage, will be nice if you post this solution on a freebsd forum

nerozero: I don't have an account but feel free :)

tercaL: I guess so

my monitoring software reports inode usage at /boot/efi to be 100%, and "df -i" confirms. however, it doesn't seem to be a problem. there is a grand total of 3 directories and 2 files on the FAT filesystem (efi/freebsd/loader.efi and efi/boot/bootx64.efi). i guess i should probably just disable the check, but i'm wondering what's going on

creating files and folders works fine

How big is your ESP?

You shouldn't have anything but EFI\BOOT\BOOTX64.EFI on your ESP.

Upgrading the bootloader with an ESP consists of copying /boot/loader.efi to EFI\BOOT\BOOTX64.EFI

260M, used 1.8M. it's been created by the freebsd installer during a fresh 13.2 install a few days ago. i simply accepted the defaults.

and from my understanding, efi/freebsd/loader.efi existing makes sense, efi/boot/bootx64.efi should merely be a fallback for broken firmware implementations of EFI? the actual efi variable should probably point to EFI\FREEBSD\LOADER.EFI?

but that's probably irrelevant for the inode question

might be a bug in our FAT code

I think it's more that inodes just work like that.

They're not dnodes like ZFS uses.

if my limited understanding of filesystems is correct, i shouldn't be able to create any files or directories when there aren't any free inodes, correct?

Hm, yes.

that doesn't seem to be the case. while df -i reports 100% iused and 0 ifree, i can mkdir and touch just fine

so the reported numbers might be wrong somehow

if i were me, i would open a bug

Yeah, that seems reasonable.

okay. so let's create a bugs.freebsd.org account :)

thanks for your input

cgit.freebsd.org/src/log/?qt=grep&q=msdosfs there's still work ongoing

Title: src - FreeBSD source tree

Title: src - FreeBSD source tree

hmmmmm

Ah, see the 2nd commit listed there; cgit.freebsd.org/src/commit/?id=c33db74b53234

Title: src - FreeBSD source tree

yea :D

doesn't look like it made it into 13.2: cgit.freebsd.org/src/log/?qt=grep&q=msdosfs&h=releng%2F13.2

Title: src - FreeBSD source tree

it'll be in 14.0-RELEASE

i'm not really familiar with the process here, will that commit reach me as an update for 13.2 at some point or will ... okay, 14.0 it is then

well, it might be in 13.3 too, who knows

freebsd.org/releases/13.2R/schedule here's the schedule for 13.2 as it was planned and practiced

Title: FreeBSD 13.2 Release Process | The FreeBSD Project

at least now i'm feeling better about disabling that alarm and have a commit to point to. if the monitoring software will let me limit it to /boot/efi i'm fine now :)

since the commit postdated the releng branch, i don't know if it could've made it in

cgit.freebsd.org/src/commit/?id=da8fa4e37a0c woo!

Title: src - FreeBSD source tree

if i'm undeerstanding the commit right, it's the new series of drivers that use the LKPI so that the drivers can be imported from linux

... stupid EFI with their rotten FAT fs...

i'm assuming copyfree-licensed drivers will go in base, GPL drivers will go in ports.

Nice

- sbp->f_files = pmp->pm_RootDirEnts; /* XXX */

- sbp->f_ffree = 0; /* what to put in here? */

what indeed

Grabunhold_: how did this not bug out before 13.2?

I'm sure it did.

meena: this is the only system that both has FreeBSD, monitoring enabled and boots using EFI. it's also the machine i had to re-install after the botched 13.1 -> 13.2 upgrade. it's possible that 13.1 was installed in "BIOS" mode back then so there simply were no FAT filesystems on the machine

aye

adding that back in is a system defect

DOSFI

Cannot solve this. Any clues? pastebin.mozilla.org/4BsTybXP

Title: Mozilla Community Pastebin/4BsTybXP (Plain Text)

I'm giving up...for now. Still haven't been able to figure out why the new version of this app isn't compiling. I've gone through a bunch of edits to the port Makefile, tried truss, and then ktrace+kdump (a la RhodiumToad), and...nuffin'

Can't tell exactly where it's bombing and how much of the tail of the trace log is it dumping state and scramming.

Oh joy, updating vaultwarden seems to have nuked my config

vkarlsen: Where was it before?

_xor: /usr/local/etc/vaultwarden/something or /usr/local/etc/vaultwarden/rc.conf.d/something. The dir is still there, but empty.

Check the changelog. I want to say I remember seeing something about the config location being changed to something more sensible.

I had mine in /usr/local/etc/rc.conf.d/vaultwarden/... (I think, don't remember off the top of my head), and I believe I had to movei t.

I see, thanks, I'll start reading

Beladona: have you tried setting MAKE_JOBS_UNSAFE=yes ?

makejobs sounds awfully obscene

meena no, I thought it was unsafe?

meena is that the reason? should I compile again with MAKE_JOBS_UNSAFE=yes

Beladona: try it out

Title: Chapter 6. Special Considerations | FreeBSD Documentation Portal

meena at what step should I do this?

I followed this docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld

Title: Chapter 25. Updating and Upgrading FreeBSD | FreeBSD Documentation Portal

meena while  `make buildkernel MAKE_JOBS_UNSAFE=yes` ?

Pretty sure MAKE_JOBS_UNSAFE is supposed to be a ports thing, not applied to a kernel build.

CrtxReavr so at what point should I paste it?

and is it safe?

I hope it wont break anything

Actually, I dont' even think the kernel/world build recognizes that flag.

CrtxReavr ok but what should I do here?

Beladona: all it does is disable parallelism

Kernel should have no problem building with -jX

CrtxReavr so should I simply do just ` make buildkernel -jX` ?

and it will solve my problem:

 pastebin.mozilla.org/4BsTybXP

Title: Mozilla Community Pastebin/4BsTybXP (Plain Text)

actually `make -j4 buildworld buildkernel` ?

I can't view your pastebin - company network blocks it.

Can you paste it to bpaste.net?

sure

CrtxReavr bpa.st/7MF3I

Title: View paste 7MF3I

Also, the obs-studio if tried to be installed, removes neovim. This issue is still not fixed

So this is a port build that's failing?

I upgraded I think but still get the same virtualbox error

CrtxReavr so I don't know if something went wrong ^

So you're trying to build the kernel, so you have the vboxdrv module?

CrtxReavr it was working previously

all the loader stuff etch was working

make[3]: "/usr/share/mk/bsd.sysdir.mk" line 15: Unable to locate the kernel source tree. Set SYSDIR to override.

Did you look at line 15 in that file?

CrtxReavr secondlast line is line 15 :

.if !defined(SYSDIR) || !exists(${SYSDIR}/kern/) || \

    !exists(${SYSDIR}/conf/kmod.mk)

.error Unable to locate the kernel source tree. Set SYSDIR to override.

.endif

Do you have the kernel src tree?

/usr/src/sys/ is the default location.

ls /usr/src/sys/  shows about30 or so dirs

USR ones here are pricy and only tolerate near 260kg, the gymholix tolerates near 900kg

not buying, just sharing former 3500 TRY, latter 7500 TRY

so it seems this industry has no logic here.

gymholix in short is pricing like ROUGUE

xx do you still use dumbels?

or the bar just is suffice to you?

sorry, wrong chnnel

CrtxReavr all good?

Does your src tree match your OS version?

CrtxReavr how can I  know?

sigh.

uname -a

grep -A2 ^REVISION /usr/src/sys/conf/newvers.sh

CrtxReavr FreeBSD 5950 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC amd64

REVISION="13.2"

BRANCH="RELEASE"

if [ -n "${BRANCH_OVERRIDE}" ]; then

Not sure why it's failing then.

Try: cd && new_mod/__init__.py & SYSDIR=/usr/src/sys/ make clean all

whoops

Try: cd /usr/ports/emulators/virtualbox-ose-kmod && SYSDIR=/usr/src/sys/ make clean all

CrtxReavr its doing something => VirtualBox-6.1.36.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.

=> Attempting to fetch download.virtualbox.org/virtualbox/6.1.36/VirtualBox-6.1.36.tar.bz2

CrtxReavr now I install vbox?

CrtxReavr same error

KLD vboxdrv.ko: depends on kernel - not available or version mismatch

linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type

Is your ports tree current?

Wait. .

Are you running FreeBSD as a vbox guest or host?

CrtxReavr: that path looks like freebsd is the host

Yeah. . .

/boot/modules/vboxdrv.ko exists though?

CrtxReavr it exists

CrtxReavr freebsd is host

Is it known to support 13.x?

Title: Solved - freebsd 13.2 and virtualbox-ose | Page 2 | The FreeBSD Forums

CrtxReavr I think otherwise it should install

I dunno. . . that thread is marked solved, but the discussion seems to have gone off the rails and I'm not parsing what (or if) the fix is.

bhyve is a thing.

Hi folks! Do you noticed any problem related to certbot x py-cryptography ?

No. . . bit it's kind of a set it and forget it thing.

Beladona: do you use custom kernel?

Hey guys.. on 13.2-stable, is there a way to downgrade cmake from 3.26.1 to 3.25.1 ?

angry_vincent I just upgraded from 13.1 to 13.2 via docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld

Title: Chapter 25. Updating and Upgrading FreeBSD | FreeBSD Documentation Portal

Onepamopa, If old version in "/var" somewher, track down the old package, fetch, install the locally downloaded one. Or, clone The Ports tree via Git; switch to the commit when 3.25.1 was present; compile & install

Onepamopa: you could uninstall the package, then build the port using make _CMAKE_VERSION=3.25.1

angry_vincent what might be the problem?

s[If old version in "/var" somewher][If old version is NOT in "/var" somewhere]

RhodiumToad it's the freaking jetbrains clion when configuring gdb and cmake it doesn't support the latest versions

which makes it somewhat crippled

you'd probably also need to hack devel/cmake-core/distinfo

ls

off

tried switching the ports tree to an older branch where gdb is 12.1 but it fails to compile ..

any way of doing this with pkg by specifying the version of the package ?

how to specify release_0/1/2 instead of latest or quarterly ?

in pkg/FreeBSD.conf

Onepamopa: i'm not sure i understand the question. you literally replace the word latest or quarterly with release_0/1/2 in FreeBSD.conf

nevermind, solved aleady ;)