00:02:58 I think I I think I figured it out, I did in fact need to adjust my repo file a bit. 00:03:38 I did not realize it was disabled. 00:05:00 Going to reboot and test. 00:09:55 how was your FreeBSD-base repo disabled if you were using pkgbase? 00:13:01 I am so glad I made a boot environment because I broke it horribly :D 01:06:24 how was your FreeBSD-base repo disabled if you were using pkgbase? 10:07:14 using sway on freebsd-15, everything seems to be running smoothly so far but launching firefox specifically it takes AGES 10:07:32 my drive is more than fast enough and the PC as well 10:08:14 im not the only one who has run into this, apparently its a documented thing with GTK+ applications like firefox 10:08:24 "This is due to GTK+ waiting for xdg-desktop-portal to start via D-Bus. This times out because the D-Bus activated service doesn't know what WAYLAND_DISPLAY to connect to." 10:08:35 "Alternatively, set GTK_USE_PORTAL=0 in your environment." 10:09:02 the former alternative was something with systemd which obviously is a nogo, anyway exporting that in .profile or .shrc for my user doesnt solve it 10:10:50 have you installed an appropriate portal service? 10:13:09 SarahMalik: not sure what they would be but i followed the handbook and installed seatd and ran sysrc seatd_enable="YES" \ service seatd start 10:13:40 checking in rc.conf seatd is enabled 10:15:59 seti: have you tried this from your terminal first, that is actually the problem and the env-var is the solution? e.g. `GTK_USE_PORTAL=0 firefox` 10:17:23 ridcully: running that from my terminal and its still slow as molasses 10:17:34 when starting 10:19:25 seti, that's not a portal 10:19:53 have you installed an appropriate portal service, such as xdg-desktop-portal-gtk out of the packages repository? 10:20:08 and, for extra credit: is dbus running 10:24:49 I installed that now, and noticed now that dbus isnt running 10:32:06 So i installed the xdg-portal package (checked that its running), enabled dbus and its also running, im exporting GTK_USE_PORTAL=0 in my .profile and launching from terminal GTK_USE_PORTAL=0 firefox yet no dice 10:32:14 firefox still takes something like 20 seconds to start 10:33:46 https://github.com/swaywm/sway/wiki#gtk-applications-take-20-seconds-to-start 10:34:59 i might have been presumptious in what they list as first solution because they mention that it applies to systemd or dbus activation environments 10:37:17 seti: HTH. i have no portal installed and i'm on linux with x11 and notionwm, but seeing ridcully's suggestion i tried the env var and it reduced the 20s startup time with few seconds. 11:01:25 nedko: I have a fedora install on another identical nvme drive that is also running sway, freebsd is taking 30 seconds to start firefox linux barely took 1 11:01:39 timed it just now 11:02:23 What soft of part of FreeBSD is tcsh? It is there, yet not listed by ``pkg info''. It cannot be uninstalled? 11:09:36 It's part of the base system. 11:14:23 More than one shell in the base system. OK. So, deintalling it legally without the danger of it's beging reinstated upon upgrade is impossible? 11:19:27 If you use pkgbase, tcsh is in the FreeBSD-csh pkg 11:41:34 Correct. however I don't know if any base system scripts actually use it 11:41:37 vkarlsen, I think not: there is not pkgbase on my system, FreeBSD 15. 11:42:01 so a custom build with tcsh disconnected could work, maybe 11:43:28 Perhaps I'll switch to pkgbase if it is at all possible. 13:14:00 I still face my "freeze" problem 13:14:10 and i still don't find any error, any alert 13:14:22 i don't know what to do at all 13:36:33 Pi zero 2w obtained: now the fuckery aroundery can happen on a device that can run FreeBSD 15 :) 13:43:17 anyone know how to fix this when make release https://bpa.st/KYQA 13:43:25 buildworld and buildkernel was executed 13:43:31 maybe I need to build something else too 13:44:20 hmm maybe I need to make update-packages first 13:44:22 lemme do that 14:56:06 eoli3n: do other os work without freeze? 15:20:34 rtprio good test ! lets try to boot ubuntu iso and let it run, it the problem is here, it should freeze in less than 24h 15:21:02 i will try this in next fail 15:21:12 because i suspect my syncthing jail to trigger the bug 15:21:17 can it only run 1 vm at a time ? 15:21:43 nop, but ressources CPU and RAM are very limited 15:21:48 2 cores and 2G ram 15:22:08 i stopped my syncthing jail and waiting for the freeze 15:32:35 yeah, perhaps try 24h without syncthing, also? 15:32:59 ( i did have a router that couldn't handle the number of tcp connections with torrents and would crash) 15:46:31 I have set LogLevel debug in /etc/ssh/sshd_config, and restarted sshd. Now, where do I see the debug output by default? Under /var/log/ messages and auth.log are still rather stingy about ssh... 15:55:57 rtprio: that's what i'm currently doing : 24h with syncthing stopped 15:56:05 "eoli3n i stopped my syncthing jail and waiting for the freeze" 17:48:18 Hi all. Anyone aware of any pf regressions on FreeBSD/15 ? I am getting "Fatal double fault" panics on a fresh installed FreeBSD 15. The fault happens the moment "kldload pf" is done 17:57:25 lt, I am just going to ask some clarifying questions. What architecture? On bare metal or a VM? If bare metal is this a known good system hardware or perhaps freshly assembled? 18:01:57 is a hetzner bare metal server. AMD64/ AMD Ryzen 18:20:04 if you have some spare time left :D https://vermaden.wordpress.com/2026/02/01/150-mb-minimal-freebsd-installation/ 18:44:46 lt, I don't know (I am not running 15 anywhere yet) but I might verify that 14 runs correctly and then bisect into it. Sorry. No help from me. :-( 19:55:31 hi 21:05:55 lt: just ran `kldload pf` on my intel xeon FreeBSD 15 box. Nothing unexpected. No faults. 21:45:19 rwp, wavefunction: I found out and solved. I guess there is indeed a bug in pf. Seems it does not like "groups" on interfaces. does not matter if you use them. especially with wg interfaces. disabling wg made pf work. enabling it again, with my previous conf using groups made it crash again. But as the fault was happening on "kldload pf" I guess something is wrong there. Disabling "group" on my wg interfaces 21:45:25 solved the issue, maybe I should file this bug somewhere? 23:39:48 lt is gone but speaking into the air I think it is always good to file a Problem Report concerning behavior like that and it seemed fairly repeatable too.