01:50:48 <RhodiumToad> anyone recall offhand when close_range was added?
01:57:04 <RhodiumToad> looks like 12.2
01:58:37 <RhodiumToad> mcrane: that doesn't necessarily work given modern printers unfortunately
01:59:13 <RhodiumToad> mcrane: fwiw I have had success with running a linux cups driver under freebsd
04:35:32 <mcrane> RhodiumToad: I’m sure it’s not going to work with every printer but I was happy it worked with the one I had
04:35:53 <rustyaxe> printer-driver-splix seems to be what my Samsung laser users, fwiw.
04:36:02 <RhodiumToad> what model?
04:36:13 <rustyaxe> http://splix.ap2c.org/
04:36:13 <RhodiumToad> I have a samsung ML-1670
04:36:18 <rustyaxe> 25 somthg
04:36:23 <rustyaxe> lemme see if cups knows as im not near it
04:36:41 <rustyaxe> Samsung ML-191x 252x Series
04:36:49 <RhodiumToad> that link gives a cloudflare error page
04:36:50 <rustyaxe> Most samsung ive met use that package
04:36:52 <rustyaxe> ;(
04:36:58 <rustyaxe> sec
04:37:59 <rustyaxe> https://www.openprinting.org/driver/splix seems to be at least some info
04:38:00 <VimDiesel> Title: Driver: splix | OpenPrinting - The Linux Foundation
04:38:07 <RhodiumToad> I looked into splix when I got the printer; it supports ML-1640 but not ML-1670
04:38:20 <mcrane> Mine is a Samsung xpress c410w
04:38:37 <rustyaxe> ah shame
04:39:08 <RhodiumToad> 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)
04:40:22 <RhodiumToad> 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)
04:42:00 <RhodiumToad> (if it had been downloadable still, I'd have submitted a port for it)
04:42:21 <rustyaxe> :( tragic
04:42:48 <RhodiumToad> the linux driver works surprisingly well
04:43:17 <RhodiumToad> (albeit with a long dependency list of linux packages)
04:43:50 <rustyaxe> Ah shit.
04:44:02 <rustyaxe> No aurora to see here :(
06:23:14 <Grabunhold_> 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
06:25:15 <parv> Was the second attempt to install 13.2 from scratch or over existing 13.1?
06:27:08 <Grabunhold_> 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"
06:28:15 <parv> Is "/etc/os-release" a symbolic link there to a file in "/var/run"?
06:28:36 <Grabunhold_> /etc/os-release: symbolic link to ../var/run/os-release
06:29:41 <RhodiumToad> what does freebsd-version -u   output
06:29:59 <Grabunhold_> freebsd-version -u
06:29:59 <Grabunhold_> 13.2-RELEASE
06:30:25 <RhodiumToad> have you rebooted since completing the upgrade?
06:30:35 <RhodiumToad> (since os-release is generated on boot)
06:32:09 <Grabunhold_> 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
06:32:24 <RhodiumToad> or maybe do  service os-release start
06:32:44 <Grabunhold_> that did it!
06:32:57 <Grabunhold_> wonderful
06:33:17 <RhodiumToad> that should run automatically on boot
06:33:41 <parv> Wait. So need to re-boot twice for properly updated files?
06:34:27 <Grabunhold_> this might very well be the boot from that update dance i listed above
06:35:11 <RhodiumToad> as a rule you should reboot after the update is complete
06:35:35 <Grabunhold_> after the second "freebsd-update install"?
06:35:48 <RhodiumToad> after you've finished doing everything
06:36:42 <Grabunhold_> i'll throw in another reboot, thanks! feels great to have that resolved, i'll attempt the next machine in the next few days :)
06:57:04 <tercaL> 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?
06:57:18 <tercaL> ...and revert the modifications back after it's done..
06:58:19 <Grabunhold_> (for the record, none of my machines have any loader.conf modifications)
07:02:59 <rtprio> tercaL: yeah, no shouldn't need to do that at all
07:03:17 <tercaL> "no" to which one? :)
07:03:25 <tercaL> rtprio: I shouldn't need to customize it at all?
07:13:09 <rtprio> not between 13.1 and 13.2
08:18:37 <meena> ah, there's no current-users list, https://lists.freebsd.org/archives/freebsd-current/2023-April/003582.html
08:18:38 <VimDiesel> Title: Fwd: dbus broken?
08:20:04 <meena> I wonder if this was kqueue1
09:25:22 <nerozero> Good day
09:26:51 <nerozero> I have a PHP hanging randomly @100% cpu usage. Is there a way to see at which module the deadlock is occurred ?
09:53:25 <mage> nerozero: nextcloud ..?
09:53:45 <nerozero> mage not only, php / fpm in general
09:54:28 <nerozero> made a trivial script and placed it in gnu-watch, after a day or so found that php running a script eating 100%
09:54:44 <nerozero> pstack utility should do the trick i guess
09:55:05 <nerozero> if not - will try to debug with gdb
09:55:13 <mage> whre you truss the process does it stuck on sched_yield() ?
09:55:22 <mage> (truss -p pid)
09:56:10 <nerozero> accidently killed a process couple minutes ago :( so ... waiting for "next occasion" ...
09:56:42 <nerozero> if you know known thread on a freebsd forum please share, will post there my findings
09:57:02 <nerozero> otherwise will open a new one and will post here
09:57:13 <mage> 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
09:58:17 <nerozero> mage, thanks for note, will look now into my poudriere config
09:58:33 <mage> I just recompiled ImageMagick without OpenMP and problem is solved since
10:00:34 <nerozero> can confirm that, my ImageMagick6-nox11-6.9.12.58,1 has OPTIONS_FILE_SET+=OPENMP
10:00:49 <tercaL> rtprio: Well actually I meant, removing all modifications, customizations inside loader.conf, BEFORE upgrading to 13.2..
10:00:52 <nerozero> but that doesn't explain the issue with simple script
10:03:08 <mage> nerozero: https://github.com/Imagick/imagick/blob/master/README.md#openmp
10:03:09 <VimDiesel> Title: imagick/README.md at master · Imagick/imagick · GitHub
10:03:21 <mage> I would try to disable it and see
10:04:08 <nerozero> mago, thank you, will post the results here after couple of days
10:06:53 <parv> mage, Thanks (for the ImageMagick & OpenMP connection)
10:07:13 <tercaL> I wonder if ImageMagick7-nox11-7.1.0.62_2 has the same issue?
10:07:21 <tercaL> (has OPTIONS_FILE_SET+=OPENMP ?)
10:07:43 <nerozero> I was "lucky" the process hanged right away: truss -p ... -> sched_yield() ...
10:07:55 <nerozero> I guess - this is it
10:15:43 <nerozero> mage, will be nice if you post this solution on a freebsd forum
10:22:47 <mage> nerozero: I don't have an account but feel free :)
10:23:58 <mage> tercaL: I guess so
12:23:22 <Grabunhold_> 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
12:25:44 <Grabunhold_> creating files and folders works fine
12:29:41 <debdrup> How big is your ESP?
12:31:08 <debdrup> You shouldn't have anything but EFI\BOOT\BOOTX64.EFI on your ESP.
12:31:40 <debdrup> Upgrading the bootloader with an ESP consists of copying /boot/loader.efi to EFI\BOOT\BOOTX64.EFI
12:32:23 <Grabunhold_> 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.
12:33:47 <Grabunhold_> 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?
12:34:04 <Grabunhold_> but that's probably irrelevant for the inode question
12:34:42 <meena> might be a bug in our FAT code
12:35:45 <debdrup> I think it's more that inodes just work like that.
12:36:10 <debdrup> They're not dnodes like ZFS uses.
12:37:11 <Grabunhold_> 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?
12:37:43 <debdrup> Hm, yes.
12:38:15 <Grabunhold_> that doesn't seem to be the case. while df -i reports 100% iused and 0 ifree, i can mkdir and touch just fine
12:39:27 <Grabunhold_> so the reported numbers might be wrong somehow
12:39:56 <meena> if i were me, i would open a bug
12:40:05 <debdrup> Yeah, that seems reasonable.
12:40:45 <Grabunhold_> okay. so let's create a bugs.freebsd.org account :)
12:40:50 <Grabunhold_> thanks for your input
12:41:06 <debdrup> https://cgit.freebsd.org/src/log/?qt=grep&q=msdosfs there's still work ongoing
12:41:13 <VimDiesel> Title: src - FreeBSD source tree
12:41:43 <Grabunhold_> https://cgit.freebsd.org/src/commit/?id=c33db74b5323480fba7adef58e8aa88f6091d134
12:41:45 <VimDiesel> Title: src - FreeBSD source tree
12:41:45 <Grabunhold_> hmmmmm
12:41:45 <debdrup> Ah, see the 2nd commit  listed there; https://cgit.freebsd.org/src/commit/?id=c33db74b53234
12:41:46 <VimDiesel> Title: src - FreeBSD source tree
12:41:50 <debdrup> yea :D
12:42:29 <debdrup> doesn't look like it made it into 13.2: https://cgit.freebsd.org/src/log/?qt=grep&q=msdosfs&h=releng%2F13.2
12:42:35 <VimDiesel> Title: src - FreeBSD source tree
12:42:58 <debdrup> it'll be in 14.0-RELEASE
12:43:07 <Grabunhold_> 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
12:43:29 <debdrup> well, it might be in 13.3 too, who knows
12:44:02 <debdrup> https://www.freebsd.org/releases/13.2R/schedule/ here's the schedule for 13.2 as it was planned and practiced
12:44:04 <VimDiesel> Title: FreeBSD 13.2 Release Process | The FreeBSD Project
12:44:15 <Grabunhold_> 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 :)
12:45:27 <debdrup> since the commit postdated the releng branch, i don't know if it could've made it in
12:48:17 <debdrup> https://cgit.freebsd.org/src/commit/?id=da8fa4e37a0c woo!
12:48:20 <VimDiesel> Title: src - FreeBSD source tree
12:50:03 <debdrup> 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
12:50:24 <Grabunhold_> ... stupid EFI with their rotten FAT fs...
12:50:30 <debdrup> i'm assuming copyfree-licensed drivers will go in base, GPL drivers will go in ports.
12:52:36 <meena> Nice
12:57:33 <meena> -	sbp->f_files = pmp->pm_RootDirEnts;	/* XXX */
12:57:33 <meena> -	sbp->f_ffree = 0;	/* what to put in here? */
12:58:36 <debdrup> what indeed
12:58:51 <meena> Grabunhold_: how did this not bug out before 13.2?
13:02:23 <debdrup> I'm sure it did.
13:10:25 <Grabunhold_> 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
13:36:44 <meena> aye
13:37:21 <epony> adding that back in is a system defect
13:39:54 <epony> DOSFI
14:12:22 <Beladona> Cannot solve this. Any clues? https://pastebin.mozilla.org/4BsTybXP
14:12:26 <VimDiesel> Title: Mozilla Community Pastebin/4BsTybXP (Plain Text)
14:16:45 * _xor throws in the towel for today
14:17:57 <_xor> 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'
14:18:27 <_xor> Can't tell exactly where it's bombing and how much of the tail of the trace log is it dumping state and scramming.
14:19:33 <vkarlsen> Oh joy, updating vaultwarden seems to have nuked my config
14:19:54 <_xor> vkarlsen: Where was it before?
14:22:07 <vkarlsen> _xor: /usr/local/etc/vaultwarden/something or /usr/local/etc/vaultwarden/rc.conf.d/something. The dir is still there, but empty.
14:22:49 <_xor> Check the changelog. I want to say I remember seeing something about the config location being changed to something more sensible.
14:23:21 <_xor> 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.
14:27:13 <vkarlsen> I see, thanks, I'll start reading
14:46:37 <meena> Beladona: have you tried setting MAKE_JOBS_UNSAFE=yes  ?
14:47:34 <epony> makejobs sounds awfully obscene
14:48:40 <Beladona> meena no, I thought it was unsafe?
15:15:31 <Beladona> meena is that the reason? should I compile again with MAKE_JOBS_UNSAFE=yes
15:19:52 <meena> Beladona: try it out
15:21:28 <meena> https://docs.freebsd.org/en/books/porters-handbook/special/#building
15:21:29 <VimDiesel> Title: Chapter 6. Special Considerations | FreeBSD Documentation Portal
15:24:08 <Beladona> meena at what step should I do this?
15:26:11 <Beladona> I followed this https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld
15:26:13 <VimDiesel> Title: Chapter 25. Updating and Upgrading FreeBSD | FreeBSD Documentation Portal
15:31:27 <Beladona> meena while  `make buildkernel MAKE_JOBS_UNSAFE=yes` ?
15:32:41 <CrtxReavr> Pretty sure MAKE_JOBS_UNSAFE is supposed to be a ports thing, not applied to a kernel build.
15:32:59 <Beladona> CrtxReavr so at what point should I paste it?
15:33:03 <Beladona> and is it safe?
15:33:09 <Beladona> I hope it wont break anything
15:34:22 <CrtxReavr> Actually, I dont' even think the kernel/world build recognizes that flag.
15:34:35 <Beladona> CrtxReavr ok but what should I do here?
15:40:13 <meena> Beladona: all it does is disable parallelism
15:42:31 <CrtxReavr> Kernel should have no problem building with -jX
15:44:12 <Beladona> CrtxReavr so should I simply do just ` make buildkernel  -jX` ?
15:44:22 <Beladona> and it will solve my problem:
15:44:33 <Beladona>  https://pastebin.mozilla.org/4BsTybXP
15:44:34 <VimDiesel> Title: Mozilla Community Pastebin/4BsTybXP (Plain Text)
15:46:07 <Beladona> actually `make -j4 buildworld buildkernel` ?
15:47:53 * Beladona waits
15:49:00 <CrtxReavr> I can't view your pastebin - company network blocks it.
15:49:05 <CrtxReavr> Can you paste it to bpaste.net?
15:51:40 <Beladona> sure
15:52:34 <Beladona> CrtxReavr https://bpa.st/7MF3I
15:52:36 <VimDiesel> Title: View paste 7MF3I
15:53:18 <Beladona> Also, the obs-studio if tried to be installed, removes neovim. This issue is still not fixed
15:54:02 <CrtxReavr> So this is a port build that's failing?
15:56:14 <Beladona> I upgraded I think but still get the same virtualbox error
15:56:31 <Beladona> CrtxReavr so I don't know if something went wrong ^
15:56:43 <CrtxReavr> So you're trying to build the kernel, so you have the vboxdrv module?
15:57:17 <Beladona> CrtxReavr it was working previously
15:57:31 <Beladona> all the loader stuff etch was working
15:59:32 <CrtxReavr> make[3]: "/usr/share/mk/bsd.sysdir.mk" line 15: Unable to locate the kernel source tree. Set SYSDIR to override.
15:59:44 <CrtxReavr> Did you look at line 15 in that file?
16:04:18 <Beladona> CrtxReavr secondlast line is line 15 :
16:04:19 <Beladona> .if !defined(SYSDIR) || !exists(${SYSDIR}/kern/) || \
16:04:19 <Beladona>     !exists(${SYSDIR}/conf/kmod.mk)
16:04:19 <Beladona> .error Unable to locate the kernel source tree. Set SYSDIR to override.
16:04:20 <Beladona> .endif
16:06:04 <CrtxReavr> Do you have the kernel src tree?
16:06:24 <CrtxReavr>  /usr/src/sys/ is the default location.
16:09:32 <Beladona> ls  /usr/src/sys/  shows about30 or so dirs
16:11:26 <Beladona> USR ones here are pricy and only tolerate near 260kg, the gymholix tolerates near 900kg
16:11:55 <Beladona> not buying, just sharing former 3500 TRY, latter 7500 TRY
16:12:13 <Beladona> so it seems this industry has no logic here.
16:12:32 <Beladona> gymholix in short is pricing like ROUGUE
16:13:08 <Beladona> xx do you still use dumbels?
16:13:21 <Beladona> or the bar just is suffice to you?
16:14:46 <Beladona> sorry, wrong chnnel
16:15:20 <Beladona> CrtxReavr all good?
16:18:13 <CrtxReavr> Does your src tree match your OS version?
16:19:44 <Beladona> CrtxReavr how can I  know?
16:21:19 <CrtxReavr> sigh.
16:23:14 <CrtxReavr> uname -a
16:23:16 <CrtxReavr> grep -A2 ^REVISION /usr/src/sys/conf/newvers.sh
16:36:29 <Beladona> CrtxReavr FreeBSD 5950 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC amd64
16:36:30 <Beladona> REVISION="13.2"
16:36:31 <Beladona> BRANCH="RELEASE"
16:36:31 <Beladona> if [ -n "${BRANCH_OVERRIDE}" ]; then
16:38:41 <CrtxReavr> Not sure why it's failing then.
16:40:41 <CrtxReavr> Try: cd && new_mod/__init__.py & SYSDIR=/usr/src/sys/ make clean all
16:40:55 <CrtxReavr> whoops
16:41:19 <CrtxReavr> Try: cd /usr/ports/emulators/virtualbox-ose-kmod && SYSDIR=/usr/src/sys/ make clean all
16:59:43 <Beladona> CrtxReavr its doing something => VirtualBox-6.1.36.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.
16:59:43 <Beladona> => Attempting to fetch https://download.virtualbox.org/virtualbox/6.1.36/VirtualBox-6.1.36.tar.bz2
17:01:23 <Beladona> CrtxReavr now I install vbox?
17:04:41 <Beladona> CrtxReavr same error
17:06:03 <Beladona> KLD vboxdrv.ko: depends on kernel - not available or version mismatch
17:06:04 <Beladona> linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type
17:20:15 <CrtxReavr> Is your ports tree current?
17:20:40 <CrtxReavr> Wait. .
17:20:53 <CrtxReavr> Are you running FreeBSD as a vbox guest or host?
17:26:11 <meena> CrtxReavr: that path looks like freebsd is the host
17:26:39 <CrtxReavr> Yeah. . .
17:27:25 <CrtxReavr>  /boot/modules/vboxdrv.ko exists though?
17:27:50 <Beladona> CrtxReavr it exists
17:28:05 <Beladona> CrtxReavr freebsd is host
17:29:18 <CrtxReavr> Is it known to support 13.x?
17:29:41 <Beladona> https://forums.freebsd.org/threads/freebsd-13-2-and-virtualbox-ose.88747/page-2
17:29:42 <VimDiesel> Title: Solved - freebsd 13.2 and virtualbox-ose | Page 2 | The FreeBSD Forums
17:31:33 <Beladona> CrtxReavr I think otherwise it should install
17:33:08 <CrtxReavr> 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.
17:33:31 <CrtxReavr> bhyve is a thing.
17:37:16 <devnull> Hi folks! Do you noticed any problem related to certbot x py-cryptography ?
17:37:57 <CrtxReavr> No. . . bit it's kind of a set it and forget it thing.
17:39:42 <angry_vincent> Beladona: do you use custom kernel?
17:44:55 <Onepamopa> Hey guys.. on 13.2-stable, is there a way to downgrade cmake from 3.26.1 to 3.25.1 ?
17:46:07 <Beladona> angry_vincent I just upgraded from 13.1 to 13.2 via https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld
17:46:08 <VimDiesel> Title: Chapter 25. Updating and Upgrading FreeBSD | FreeBSD Documentation Portal
17:52:27 <parv> 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
17:52:31 <RhodiumToad> Onepamopa: you could uninstall the package, then build the port using  make _CMAKE_VERSION=3.25.1
17:52:54 <Beladona> angry_vincent what might be the problem?
17:52:55 <parv> s[If old version in "/var" somewher][If old version is NOT in "/var" somewhere]
17:53:11 <Onepamopa> RhodiumToad it's the freaking jetbrains clion when configuring gdb and cmake it doesn't support the latest versions
17:53:20 <Onepamopa> which makes it somewhat crippled
17:53:29 <RhodiumToad> you'd probably also need to hack devel/cmake-core/distinfo
17:53:50 <Onepamopa> ls
17:53:52 <Onepamopa> off
18:07:52 <Onepamopa> tried switching the ports tree to an older branch where gdb is 12.1 but it fails to compile ..
18:08:09 <Onepamopa> any way of doing this with pkg by specifying the version of the package ?
18:13:42 <Onepamopa> how to specify release_0/1/2 instead of latest or quarterly ?
18:13:48 <Onepamopa> in pkg/FreeBSD.conf
19:35:01 <kevans> 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
19:39:54 <Onepamopa> nevermind, solved aleady ;)