00:26:20 pkgbasify was _very_ easy on my end 01:38:59 i really want to get freebsd running on this rpi3, but i have no idea if there's any remotely feasible workaround for the wifi chip support without being insane and writing my own driver. i mean, it IS a project in and of itself, but man.. i really don't wanna buy an ethernet cable just for this. my router's like 500 meters away :( 01:40:55 half a km away? O.o 01:41:29 im exaggerating but it'd be a pain to lay cable 01:41:37 can you move the pi? 01:41:54 is there such a thing as ethernet to USB where i can use another computer as a hotspot or whatever it's called? 01:41:55 or are you trying to use it as a desktop 01:42:40 i can't move the pi, im limited to this room for my workstation. i really just wanted a BSD system to play with and use as a server for a couple things, and do some coding for. rpi 3 is no longer supported by the debian version of it 01:43:11 i mean i know broadcom chips never had a lot of support but damn it's been decades 01:43:31 rdr - do me a favor, make a quick guess before i head out 01:43:34 yeah it's hit or miss, my intel in my main works on freebsd but the wifi in my secondary doesn't 01:44:03 building a functioning driver for this wifi chip for freebsd - how many months, assuming i have ... i dunno, 2-3 free days a week, about 4-5 hours a day to work on it? 01:44:07 just a rough guestimate 01:44:21 or we talkin years 01:44:57 depends if a driver exists just isn't included i guess 01:45:04 assume none exists 01:46:38 yeah prolly a year or two 01:49:54 Matt|home: Any drivers are pretty decent sized undertaking. Have you emailed freebsd-wireless⊙fo to see if anyone else is already working on this? 01:50:04 I wouldn't surprised. 01:50:40 nope, this would be my first actual OS contribution. but as usual i get to do it because nobody else bothered to, so i'll clean up yer messes for ya -_- 01:51:30 * kevans reads scrollback 01:51:39 oh... broadcom 01:53:35 Matt|home: building this out is going to be a bit rough as a first contribution for more than just 'wifi is hard' 01:53:43 s/more/more reasons/ 01:54:27 SDIO on FreeBSD is basically non-existent; the MMCCAM bits were designed to support exactly this, but we don't have anything today hanging off of SDIO to try and model after 01:55:32 Yeah. Might wanna just grab a USB wifi adapter with a chipset that's supported. 01:55:55 Of course, FBSD would definitely welcome any Broadcom wifi drivers that you can provide. 02:01:43 with pkgbasify, should be I creating a boot environment before conversion? 02:02:10 doesn't hurt 02:02:35 I'm running the script based on the earlier conversations 02:03:59 ok so I noticed that pkgbasify is downloading 32-bit packages, even though I don't use them. I hope it doesn't install them. 02:04:26 i imagine it will 02:04:37 presumably you have /usr/lib32 populated, even if dn't use it? 02:07:06 ahh yes. I did. Its in my jails that I don't have 32-bit. My base does. 02:11:58 alright moment of truth, time to reboot the system. Lets see what happens. Although now with pkgbase I should be able to remove 32-bit stuff from base as I want to run a pure 64-bit system. All of that after the reboot. fingers crossed. 02:16:04 hmm 02:16:16 it'ss been four miutes should they be presumed dead? 02:18:13 phew, not dead after all 02:19:19 lol 02:19:43 i'm a bit paranoid about moving over to pkg too 02:19:51 i'm too used to the freebsd-update life 02:20:23 there's a notion that we'll have something like the freebsd-update frontend to provide a familiar interface 02:21:03 some of the upgrade incantations are kind of awkward and people do have a lot of freebsd-update muscle memorry 02:22:30 yes not dead! 02:22:40 :-) 02:22:43 for context: > 21:16 < kevans> it'ss been four miutes should they be presumed dead? 02:23:09 you made it at the six minute mark 02:24:07 Steps I took: fetch pkgbasify.lua ; ./pkgbasify.lua ; say yes to create a boot environment before conversion; verify three files that pkbasify tells you to; reboot. Done. 02:24:32 oooh six minutes from when I quiet to back? nice 02:25:15 377 packages downloaded, quit out of all tmux windows, rebooted, waited, ssh'd back in ... I did this remotely. 02:25:31 remotely = I'm downstairs, the mini-pc is upstairs lol 02:25:37 bold- oh, hah 02:25:54 still bold depending on what kind of creatures might be between you and the machine, though 02:26:10 I was getting worried and was about to go up, but decided to do one last ssh invocation, third time it worked. 02:26:24 i've made the mistake of crashing a machine on the wrong side of a sleeping baby 02:26:28 very true kevans, you never know when the OS gremlins show up 02:26:59 now let me check pkg.conf in /usr/local 02:29:05 ok so I have this in FreeBSD-base.conf: url: "pkg+https://pkg.FreeBSD.org/${ABI}/base_release_4" and I am presuming that I would need to make that a "_5" when I want to upgrade to 14.5 ? 02:29:35 yesl 02:30:48 and if I want to upgrade to 15.0-STABLE ? 02:31:40 those are maintained outside of re@, you can choose either `base_latest` or `base_weekly` 02:32:21 you also have to swap the fingerprints, stable packages are signedd with the same key as ports 02:33:39 (that's where the 'maintained outside of re@' part comes in- it doesn't really matter outside of different keys) 02:34:47 Is this information on the wiki? 02:35:16 never mind I see it there 02:35:39 (https://wiki.freebsd.org/pkgbase for anyone else following along; there's a table that also describes the build frequency) 02:40:12 That table is outdated now isn't it, since there is a 15.0-RELEASE and a 15.1-RELEASE. What would the pathway be for 14.4 -> 15.1 ? 02:41:50 it's still more or less what the "Major version upgrades" describes, except the advice is terrible 02:42:41 ideally you end up invoking `upgrade` twice with a reboot in between them, the first time being something like `upgrade -x 'FreeBSD-kernel-*'` 02:42:54 s/-x/-g/ 02:44:03 you don't really want to upgrade the running system in one-shot, you want to be on the new kernel to avoid breaking things mid-upgrade as things want to run post-install scripts and the system is a weird 15/14 hybrid on a 14 kernel 02:45:04 Or just state it with the -o ABI options. 02:45:16 Whoops. I didn't scroll down all the way. 02:48:57 well let me clean up base first, get rid of lib32 and see where things are after that 02:53:16 hmmm interesting, valgrind, llvm13, llvm15, gcc13, gcc14, julia, etc. all seem to depend on lib32 being available. 02:55:17 ah, yeah, shlib depends might be problematic 02:55:56 i think there was some work planned in this direction, but i don't recall at the moment 02:57:13 You can always wipe out lib32, then just reinstall whatever you need after again. It'll pull in needed dependencies. 02:57:47 It's just packages so it goes pretty fast. I remember having to do some dancing around as well. But, it was pretty painless. 03:01:17 yeah I think that might because I had initally, years ago, setup things as multi-lib and so had lib32 insatlled. This was with FBSD-9 or FBSD-10. Never changed anything through all the intermittent upgrades 03:05:29 It happens. 03:06:10 There's nothing wrong with keeping lib32 support. Especially now, It's all just packages. Updates are quick. If you're looking to save space and don't need them anymore, feel free to delete them. 03:06:17 It's just a thing. 03:09:35 yeah cleans up about 7GB, including the dependent packages. Lets see how much gets used up when I re-install the removed pacakges. Apparently Julia is not longer available 03:19:13 ok so technically its 1GB of space cleaned up. After re-installing everything back, I loose 6GiB of space. It does install 3 lib32 base packages. 03:20:04 FreeBSD-clibs-lib32, sqlite3-lib32, and runtime-lib32 03:35:17 did lang/julia get removed from pkg? 'pkg search julia' doesn't return the package anymore. 03:37:47 mns: It's still there in ports as far as I can see, but yeah, I don't see the binary package either. 03:37:51 https://cgit.freebsd.org/ports/log/?qt=grep&q=lang%2Fjulia 03:38:14 And in particular https://cgit.freebsd.org/ports/commit/?id=e3e9c93788126855cf21e34f2219ef8d87b3dfd9 03:42:59 yeah I see it in usr/ports/lang/julia just not the binary package. Not that I've been using it much lol 04:01:23 mason: that ports commit basically says that lang/julia was unexpired back in 2025 June, so should be available. I had 1.10.5_1 installed, which is the same version in /usr/ports 04:14:10 mns: you can spelunk through the bomb icons in pkg-status.freebsd.org to try and understand why 04:20:20 not sure what I'm looking at on that page. 04:26:05 Yes, it's a little bit mucb to sort through 04:26:21 you want the "package builds" section 04:27:01 pick a build of interest and click the bomb icon next to it to get build results 04:27:14 then filter through skipped/ignored for julia 04:28:52 * kevans & 04:41:14 thanks 08:21:43 I've got unbound (the ports install) supposedly starting up at boot time on a VPS, but it never starts. I have to manually start it. I tried interface: 0.0.0.0 .. I got unbound_enable="YES" in /etc/rc.conf.. I can see it trying to start at boot up but it never seems to finish. Does it have to start later in the boot process? 08:25:49 how do you manually start it? did you try /usr/local/etc/rc.d/unbound start - did you check if the rc.d script writes a log anywhere, did you try edit the rc.d script so it at least tries to start in the foreground? 08:26:07 service unbound restart 08:26:30 it logs to daemon.log but the logs aren't enough I think 08:26:54 I think it's trying to start unbound before the network interfaces are ready 08:27:13 so it never starts up properly 08:27:23 that's usually solved by the rc.d script and a magic comment, # REQUIRE: network or sth like that, fuzzy memory. 08:27:29 Maybe I should just restart it in /etc/rc.local :D 08:27:40 rc.local runs last doesn't it? 08:27:55 Yep I think so, late in the boot process anyway 08:28:31 rc.d scripts have a mechnaism to wait for network though, via magic comments. 08:28:48 yeah the unbound script starts before 'network' it seems 08:29:48 wait a sec and ill ask my robot 08:30:06 it's # REQUIRE: NETWORKING 08:30:14 you could try that 08:32:17 hmm neither putting '/usr/local/etc/rc.d/unbound restart' in /etc/rc.local nor putting NETWORK on the require line fixes it 08:32:35 thats very strange 08:32:38 ill check the port 08:33:27 it has: # BEFORE: NETWORKING 08:33:34 did you remove that? 08:36:20 yes.. removed that line and tacked NETWORKING onto the end of the REQUIRE: line 08:37:41 hmm doing one more reboot to check.. see, I wanted unbound to just bind to the wireguard interface so I stuck: "NETWORKING wireguard" to the end of the REQUIRE 08:37:49 so hopefully that will do the trick 08:38:23 not sure 08:38:42 yep that worked 08:39:18 cool, but weird, you might want to open a bug for that 08:41:20 I have to wonder.. why does the script set to start BEFORE: NETWORKING if unbound needs to bind to an interface/address in the first place? 08:41:40 exactly, im sure there's reasoning behind it, but i dunno what it is. 08:44:29 alright so I just ran a pkg update -r FreeBSD-base to get 15.1p1, and when I ran the same for the -ports repo, my kmods seem to be downgraded? for example, gpu-firmware-radeon-kmod-r700: 20220511.1501000 -> 20260519.1500068 [FreeBSD-ports] 08:44:45 I know the part after the YYYYMMDD is related to a freebsd release 08:55:03 .1501000 is 15.1-RELEASE I think 08:57:46 I'm trying to understand why it asks me to "downgrade" my kernel modules when I do pkg upgrade -r FreeBSD-ports, but these modules are not candidates for upgrades when I simply run pkg upgrade without specifying a repo 11:16:52 Hi! I want to know more about FreeBSD or (original BSD) philisophy / concept / manifesto 11:19:02 deeppandya: https://cscie2x.dce.harvard.edu/hw/ch01s06.html 11:52:21 pertho: Thanks for the link. I found that it's mostly technicality of the program development. I was just cehcking it BSDs have any philisiohical aspect like GNU has ethical one 11:53:06 Typo: ...checking *if* BSDs have... 12:03:27 Nope not really. 12:04:36 pertho's link best describes it. when you read between the lines even technical documents are built on ideas and concepts you can apply back to the real world, but whether or not that's intended is another thing. 12:09:29 in fact i would say that link is excellent. bookmarked and reflecting. 12:11:17 bsdrobert: yes, I haven't found such excellent description before. Let me save link given by pertho 12:37:42 deeppandya: in a nutshell, OpenBSD focusses on security, NetBSD on portability, and FreeBSD for servers (though, increasingly desktops and laptops now that a lot of wifi work has been done) 12:40:18 got it. 12:42:00 deeppandya: one of the key differences between Linux and the BSDs is that the Linux is just "the kernel". The packaging and system around Linux is all on the distributions. The BSDs come the with a complete kernel AND base user space. On top of that you can of course install packages (or compile ports from source), but a BSD will always have a complete base system on installation. 12:42:25 So you can always be sure the kernel and userspace are properly in sync and maintained together on a BSD. 12:42:57 pertho: Yes, I know that's what caught my interst for BSD which maintains kernel + userland. 12:43:38 In linux, it is GNU and Linux. It can be GNU+Bsd kernel or GNU+Hurd also 12:44:37 pertho: another project gained my interst was Hyperbola which is GNU/FSF endorsed distro who planned to migrated to Hyperbola BSD from GNU/Linux because their developers dissatisfied with Linux kernel developemnt 12:45:21 There's been Linux/BSD crossover projects. I seem to remember Debian had something where it ran the FreeBSD kernel but had GNU userland or something 12:46:23 Oh wow.. it's still around? "Debian GNU/kFReeBSD".. I thought it was discontinued years ago. Anyway.. 12:46:29 pertho: I am leaving IRC at the moment for another work, you may know more about me from deep-pandya.codeberg.page 12:46:50 deeppandya: ok good luck 12:47:16 will meet later. Good-buy! 12:47:24 *good-bye! 13:39:46 I guess a good hint that I'm using pkgbase is that my cron job for 'freebsd-update fetch' says that freebsd-update can't run on a pkgbase system. I'm offically on pkgbase at 14.4p7 15:13:45 hmmm I have lmdb-1.0.0 installed, but pkg wants to replace that with lmdb0-0.9.35 15:14:58 how do I find out which package is causing the downgrade? 15:16:30 I suspect it is neomutt as thats the only other package in the list when I do 'pkg upgrade' 15:21:05 pkg info -r -x lmdb 15:21:25 You should be safe to downgrade most likely though. 15:21:46 switching from newer to legacy? 15:22:33 Yes, and it's very possible that things silently break with 1.x 15:22:41 This is the reason why they dialed back to 0.8 15:22:43 yeah 15:22:44 0.9 even 15:22:47 you want the downgrade 15:23:06 an upgrade broke a bunch of things so it was walked back to lmdb0 to better execute the upgrade 15:27:53 got it 16:19:46 mason: wrt container docs feedback is welcomed let me know what to change or ofc send a patch 16:21:46 dch: I'm going to try to get some time to implement the stuff, which should highlight any rough edges. There were some wording issues, but not with the patch - with the already-extant surrounding text. I'll come up with suggestions once I've run through it in practise. 16:45:17 really appreciated thanks! 17:20:55 As soon as a couple more pieces come in I'm spinning up a new workstation and I can devote it to testing there. Primary goal for the thing will be evaluating FreeBSD as a desktop once more. I try periodically. 17:21:11 Videoconferencing usually nukes it, but I'm feeling inspired. 17:29:40 has anyone ever had to blocklist one of the wifi drivers so a different one successfully attaches? 17:32:09 I'm working on getting my office together after working off a laptop for a few years, and will likely add a PC desktop to the mix... 17:33:28 I've been seeing that you can get some older video cards that still perform OK if you're not asking for a whole lot, but in general for FreeBSD (or even Linux since I guess we kind of depend on Linux stuff?) is the easy direction AMD or Nvidia? 17:35:00 nvidia drops support for older cards with their main driver (which is available on FreeBSD) so often AMD can be a lot less painful 17:38:31 AMD drivers are fully FLOSS so most of the time an old Radeon is mature and reliable. 17:40:43 NVIDIA is still a reverse engineered driver. In my use I was (past tense) running two NVIDIA gpus and it became unstable with kernel panics after an upgrade. I removed them and replaced with an AMD. It's been rock solid since. Meanwhile, I switched desktops to an HP t740 with a built-in Radeon and it has been solid. 17:41:30 yeah i replaced an older NVIDIA with an AMD and have had much less issues on both Linux and FreeBSD :) 17:42:41 spork_css: FWIW, I'm getting an older Radeon for this next workstation I'm spinning up, which will run FreeBSD 15.1. 17:43:02 I've successfully used nVidia in the past, but I'd like to be away from them. 17:44:00 On the Linux side the free software reverse engineered nouveau driver was, past tense, quite good but then a couple of years ago they started rewriting it (or something) and I found it became completely unstable. Panics and crashes. That pushed a lot of people to the proprietary driver. But then you need to find a good version and stick with it. 17:46:48 rwp: Counterpoint, Nouveau fell over every time I'd try it in the past, so I only run nVidia proprietary drivers. Which is part of why I want to move to AMD. 17:47:12 Counterpoint to THAT, though, is that I've had awful luck with AMD cards. 17:48:39 You probably used the nouveau during the later years when it was also falling over for me too. it's just not worth the frustration so I avoid NVIDIA now. 17:50:44 I am a craphound so I am only using old lower power non-gaming AMD GPU cards. I try to stay away from anything that requires a fan. Because fans fail and are noisy and if it needs a fan then it is just going to be wasting power for me. My most stressful use of video is playing videos and these days that's a tame operation for most graphics adaptors. 17:53:51 yeah rwp the proprietary one is pretty decent, but only if your card supports it. amdgpu driver is pretty good (getting better) and like that other person said the radeon driver is still serviceable for old old cards 17:59:17 My current AMD is a Raven Ridge built-in on the t740. I am driving 4x 1920x1200 displays. It handles it with no problem. My previous was a HD 5500 Cedar driving two displays. 17:59:19 I've got a Radeon Pro WX 3100 on the way. It has a fan, but is pretty low-power. 18:02:50 Does anyone know if something changed with the nginx-full package? pkg upgrade wants to remove it (on 14.4) 18:03:19 joemie: i'm not sure, did it install something to replace it? 18:05:59 nope. If I do a pkg search nginx the full-version isn't there (anymore) 18:06:14 That sounds like a build failure. 18:06:39 Meanwhile... I mostly switched to the "freenginx" branch a short while ago. 18:07:43 joemie, Are you on quarterly or latest? 18:07:56 rwp: latest 18:08:14 https://www.freshports.org/www/nginx-full/ 18:09:13 Looks like it is either still building or failed a build. It's just temporary in the grand scheme. But you could switch back to quarterly and have that version available for install now and then switch back after it is installed. 18:12:14 Thanks for the suggestions 18:16:38 If you have installed nginx-full on a similar system then you could look in /var/cache/pkg/ and see if you still have the .pkg files cached there and install the same version on your new system that you have installed on the other system that has this cached. 18:52:11 I'll wait a bit, I didn't let it deinstall, so still up and running atm 19:21:27 joemie: could be extra safe and stick a `pkg lock` on it 21:54:58 if i wanted to renice a service, but that service spawns its own subprocesses (like execve() or whatever), do those child processes inherit the (in this case) lower priority? 21:57:47 does the service have it's own uid? 21:58:21 apt nickname :) it does 21:59:16 you can renice a uid 21:59:20 although it's already in a jail, so perhaps i can just nice the whole jail since it's a dedicated service (https://it-notes.dragas.net/2024/07/11/limiting-process-priority-in-freebsd-jail/) 22:11:08 i wonder if i should nice my jellyfin jail 22:29:55 yeah, this is a sabnzbd jail, and when it's repairing/extracting it just seems to block everything else on the system 22:42:03 huh, can't say i've seen tht happen before 22:47:39 alright anyone here know how to get the geli decryption prompt to be sent via serial? 22:47:55 everything after geli decryption works (the freebsd boot screen) 22:48:10 but I still cant get the geli part to go via serial 22:59:44 i think you've kind of exhausted your options, beyond a custom setup to get options to the earlier stages 23:00:16 /boot.config isn't usable when it's gated behind the passphrase that you need to enter, and the BIOS boot chain doesn't really leave us any other options that I see 23:00:29 (custom setup or converting to UEFI) 23:01:48 kevans: oh so if you uefi boot it works? 23:01:51 right??? :p 23:01:59 if you use uefi boot you can place options on the ESP 23:02:34 hmmm 23:02:43 so probably, yes, it can be made to work without much hassle 23:03:00 well server has uefi support, someone else said it was easier with bios boot iirc 23:03:01 with any luck it might even work out of the box 23:03:12 lemme try switching to uefi boot shortly, see if that works. 23:03:21 not really sure what to stick into the ESP though 23:04:16 firmware might describe the serial connection in ConIn/ConOut so that it all Just Works(TM), but if it doesn't you can use /efi/freebsd/loader.env on the ESP 23:04:31 do you hve an ESP already, or starting from scratch? 23:27:50 ahoy! my nvidia quadro m2000 doesn't work with the proprietary nvidia driver: running X or Wayland makes the kernel suffer a page fault in kernel mode 23:29:22 this is the first time i've tried nvidia proprietary drivers in freebsd. the m2000 requires 580 legacy drivers (boo). i have tried each of the 511, 6something, and 6something else versions of the kmod package 23:29:56 i've decrypted my swap and obtained a crash dump i can inspect 23:31:28 this card was just working in debian so it's not ba... er, well, it's not faulty :) 23:32:06 am i barking up the right trees? 23:34:39 #9 0xffffffff8375bf65 in drm_stub_open () from /boot/modules/drm.ko 23:34:51 to the /usr/src ! 23:37:05 oh that is in a port lol 23:41:45 oh i have not looked in the bugzilla 23:46:46 hum i am using 15.1-RELEASE; i could try CURRENT 23:48:06 read https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290471