00:21:56 -hey; in man rc.subr, when i see ${name}_env that's a literal ${name}_env not myprogram_env, right? 00:22:10 because of rc magic will substitute it for me 02:06:36 <[0x1eef_]> Anyone know if X11 forwarding can be configured to work past one application that is started and then killed ? When I try to open an application after that, the error is along the lines of: Display localhost:10.0 unavailable, simulating -nw .... (command = emacs . &) 02:14:51 [0x1eef_]: depends on how you're starting the X11 forwarding 02:48:20 <[0x1eef_]> mns: I'm connecting via the command line, and after connecting I usually run: emacs . & ... It works, but I have to start a new SSH session to open a different application (or the same one). 02:49:46 <[0x1eef_]> There also happens to be an instance of X running on the same machine. Hrm. 02:50:34 <[0x1eef_]> Ok using that display doesn't help. It starts on the other computer's screen instead. 03:12:58 [0x1eef_]: the way I recall it, and its been a while since I've done X11 forwarding, but you should be able to start multiple applications. Why do you do 'emacs .' ? just 'emacs &' should work just fine. 04:02:11 [0x1eef_]: do you test with xeyes first? 04:04:16 i have X11 forwarding enabled on the remote computer as well as X11DisplayOffset to 10 04:09:54 https://reviews.freebsd.org/D43696 giggity 04:09:55 Title: ⚙ D43696 Jail descriptors 04:34:55 <[0x1eef_]> johnjaye: Nice to see you here :) I think I am hitting the timeout described in the man page: 04:35:00 <[0x1eef_]> If this option is set to no (the default), remote X11 clients 04:35:02 <[0x1eef_]> will be considered untrusted and prevented from stealing or 04:35:04 <[0x1eef_]> tampering with data belonging to trusted X11 clients. 04:35:06 <[0x1eef_]> Furthermore, the xauth(1) token used for the session will be set 04:35:08 <[0x1eef_]> to expire after 20 minutes. Remote clients will be refused 04:35:10 <[0x1eef_]> access after this time. 04:44:15 ah i think that is in ssh_config man page 04:54:01 I'm really having a hard time figuring out why some of my jails have extremely lagged incoming SSH, and some of them are fast/normal. It only seems to happen when connected to one wireless AP on our network. I've tried running some packet traces but not finding anything to really help me understand what's happening. 04:54:31 Router and AP are both Fortinet hardware. 04:58:39 xa0z: DNS / Reverse DNS / UDP issues? (or anything in ssh -v)? 05:00:05 core-ix: first thing I checked, as that was an issue I had experienced years ago. Everything else seems fine. using -v doesn't really show anything different between the jails. They're all pretty much configured the same way. 05:04:32 core-ix: one thing I just noticed is that the problematic jails have this error, and the others don't... adjkerntz[82692]: sysctl(set: "machdep.wall_cmos_clock"): Operation not permitted 05:16:28 xa0z: missing timezone settings? missing sysctl settings? (for the adjkerntz) 05:18:39 I exeuted tzsetup on them, and restarted them, still laggy. 05:19:59 Mind you, this issue was non-existant until I swapped the old AP out for the new one. :/ 07:26:01 Hello 07:26:10 dovecot:\ 07:26:13 :openfiles-cur=1024:\ 07:26:16 :openfiles-max=2048:\ 07:26:19 :tc=daemon: 07:26:21 will that be working on frebsd? 08:31:00 why might it be so? Jan 12 15:45:07 generic dovecot[29950]: auth-worker(30117): Error: conn unix:auth-worker (uid=143): auth-worker<1>: pam(me,192.168.100.117,): pam_authenticate() failed: Authentication error (/etc/pam.d/dovecot missing?) 08:53:24 what pam.d even is? 09:00:46 V-T60: Pluggable Authentication Modules 09:16:54 Jan 12 16:31:03 generic dovecot[30355]: auth: Fatal: Support not compiled in for passdb driver 'bsdauth' 09:17:03 the one that worked on openbsd doesn't work on freebsd 09:18:18 V-T60: yeah, authentication is usually very system specific 10:38:00 What is the easiest way to substitute bsdauth? 10:38:06 Jan 12 16:31:03 generic dovecot[30355]: auth: Fatal: Support not compiled in for passdb driver 'bsdauth' 10:38:09 that worked on openbsd 10:38:10 but now on freebsd doesn't work 10:59:01 Hi. I need help connecting my ThinkPad to HDMI. It works if I boot with the cable plugged in, but not if I plug it in after the machine is already booted. Any ideas? 11:40:11 V-T60: i don't think freebsd supports bsdauth? it uses PAM instead 14:50:08 lw: yeah, that is so 14:51:20 V-T60: i haven't done dovecot with PAM for a while but from what i remember it works the same as on other systems (Linux etc) so the config from the Dovecot manual should be fine 14:52:08 did you have some error with /etc/pam.d/dovecot missing? you can just copy that from /etc/pam.d/system or something. or look at how /etc/pam.d/su uses 'include' to reference system 14:52:42 you might want to check system doesn't include any random stuff dovecot shouldn't be using 14:56:55 now i'm struggling with other problem 14:57:13 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274504 14:57:16 Title: 274504 – mail/opensmtpd tls fails with FreeBSD 14.0-RC1 14:57:26 and on my architecture i have opensmtpd 6.8, maximum 15:00:54 this is probably related to openssl 3.0 dropping legacy cyphers. shame this patch has been sitting for 2 months with no movement... 15:01:19 V-T60: i suggest mailing the port maintainer to ask if this can be committed 15:03:03 V-T60: also what arch are you on? 7.3 was committed in october, a new package should have built by now 15:05:38 lw: armv7 15:05:54 ah... that is like super deprecated, maybe ports don't build often 15:05:54 i like this architecture and device 15:06:05 (arm64 has 7.3.0) 15:06:55 Allwinner H3 can't work with arm64 somehow, can it? 15:07:10 why would that be *deprecated* though? 15:07:31 amd64 has so many years older devices 15:07:46 like, 2015 against 2006 15:07:48 all 32-bit archs are being deprecated/removed, including i386 and the 32-bit arm platforms 15:08:35 although apparently armv7 is still supported for now in 15.0, unlikely armv6 which is going away 15:10:47 V-T60: it looks like an armv7 pkg build was run in January though so i'm surprised you don't have the newer version http://pkg.freebsd.org/FreeBSD:14:armv7/ 15:10:48 Title: Index of /FreeBSD:14:armv7/ 15:10:53 is the package in the repo? maybe it failed to build 15:11:46 ah it's still 6.8 on quarterly 15:12:26 https://www.freshports.org/mail/opensmtpd/ that's weird, i386, amd64 and arm64 all have 7.3 in quarterly, i wonder what happened to armv7 15:12:27 Title: FreshPorts -- mail/opensmtpd: Security- and simplicity-focused SMTP server from OpenBSD 15:13:20 yeah, might i wonder? if you don't know... 15:13:44 you could ask ports@, there's some way to view the build logs for the packages but i can't remember what it is... maybe someone else here or in #freebsd-ports knows 15:14:37 wait i was looking at the wrong thing, armv7 *does* have 7.3 in quarterly, it's just v6 that doesn't 15:14:59 strange thing 15:15:13 FreeBSD orangepi 14.0-RELEASE FreeBSD 14.0-RELEASE #0 releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 09:03:07 UTC 2023 root⊙rnfo:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm 15:15:46 does pkg upgrade not offer the new version? what's in your pkg repo config? 15:17:08 FreeBSD: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/share/keys/pkg", enabled: yes } 15:17:14 that's only what was found in /etc/pkg 15:17:35 i wonder how ${ABI} expands on arm 15:17:55 in FreeBSD.conf 15:18:07 V-T60: can you run 'pkg -d update'? it should show the specific URL it's fetching for packagesite.pkg 15:19:58 what about links here... 15:19:58 DBG(1)[34401]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:14:armv7/quarterly/meta.conf 15:20:19 DBG(1)[34401]> curl> fetching http://pkg.FreeBSD.org/FreeBSD:14:armv7/quarterly/meta.conf 15:21:49 oic, 7.3 is in the freebsd 13, but the freebsd 14 repo only has 6.8. ?? that's weird 15:22:34 DBG(1)[34401]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:14:armv7/quarterly/packagesite.pkg 15:22:39 V-T60: well i will go back to my previous advice that someone on ports@ might know 15:24:51 FreeBSD repository is up to date. 15:24:52 All repositories are up to date. 15:26:29 # pkg upgrade opensmtpd 15:26:34 Your packages are up to date. 15:26:58 version: OpenSMTPD 6.8.0p2 15:27:27 it seems like the build went fine: http://ampere1.nyi.freebsd.org/data/140releng-armv7-quarterly/72cbe1a32d80/logs/opensmtpd-7.3.0_2%2C1.log 15:29:32 V-T60: can you try changing your FreeBSD.conf to use url http://pkg0.nyi.freebsd.org/FreeBSD:14:armv7/quarterly and remove the mirror_type option? take a backup first in case you need to revert it. i wonder if your mirror is out of date 15:29:33 Title: Index of /FreeBSD:14:armv7/quarterly/ 15:42:13 oh 15:43:06 root@orangepi:/etc/pkg # cp FreeBSD.conf FreeBSD.conf.bak 15:43:52 this way? url: "pkg+http://pkg0.nyi.freebsd.org/FreeBSD:14:armv7/quarterly", 15:44:09 #mirror_type: "srv", 15:44:59 ok, without pkg 15:45:41 Updating FreeBSD repository catalogue... 15:46:24 yeah, just http:// 15:52:17 FreeBSD repository update completed. 30452 packages processed. 15:52:51 Your packages are up to date. 15:53:04 and pkg search opensmtpd only shows 6.8? 15:53:16 opensmtpd-6.8.0,1 Security- and simplicity-focused SMTP server from OpenBSD 15:55:49 probably at least a pkg file anywhere out there? 15:56:29 with exactly opensmtpd 16:09:56 Hey all, if anyone can help us with this, I'll be very grateful. https://lists.freebsd.org/archives/freebsd-virtualization/2024-February/001921.html 16:09:57 Title: if_ixl: Admin Queue memory allocation issue hangs the server 16:18:33 how do i build a pkgbase repository from a src checkout? 16:18:43 https://wiki.freebsd.org/PkgBase does not appear to provide enlightenment 16:18:45 Title: PkgBase - FreeBSD Wiki 16:20:43 lw: make packages 16:20:51 thanks 16:20:54 and make update-packages 16:21:08 what's the difference? 16:24:48 the update-packages updates the packages that need updating 16:25:44 lw: https://codeberg.org/pkgbase/website/src/branch/main/howto/bootstrap.md 16:25:45 Title: website/howto/bootstrap.md at main - pkgbase/website - Codeberg.org 16:25:53 ah right 16:26:00 might also be helpful 16:26:49 well, i don't want to install from packages directly, i want to publish them to http and use them on other machines via pkg... so i guess i don't need update-packages then? 16:28:18 yes, you do. unless you want to rebuild all 503 packages every time 16:28:43 ah ic 16:31:05 so i need to run make packages once, then every subsequent build i can run make updates-packages, unless UPDATING says otherwise? 16:31:13 update-packages 16:35:26 * lw goes to create a builder vm to play with this 16:38:09 unrelatedly, did anyone notice that rust not building under qemu-static has broken ports cross-builds for basically everything since most things eventually depend on rust now? 16:38:19 i wish ports had a proper cross-build support 16:38:56 is anyone working on that 16:40:29 base already builds llvm with a target for every platform so it wouldn't even need a compiler for a lot of ports, although getting things like rust working might be fun 17:13:16 What is up with "fasm" port? It only comes as a 32-bit executable. 17:18:51 Could we get a x86_64 build, too? 17:19:37 * lw wonders if bhyve boot via nfs root works 17:19:54 dautor851805: is it only distributed as a binary upstream? or why does the port use a binary? 17:20:31 lang fasm or cad fasm? 17:22:09 It uses binary because it needs to bootstrap somehow (it is self hosted). IIRC, I compiled it with itself a few years ago as 64 bit after bootstraping 32 bit version and everything worked. I will try it tomorrow if I find some free time. 17:22:13 paulf: lang 17:24:29 I'll have to install lib32 for that, though... agh... 17:38:13 I see... libc platform is only written for x86 and not for amd64. It's only 363 lines though, so I might try to write a 64 bit implementation. 17:40:16 well, double that - I missed system.inc 17:40:24 if you had an 8-disk raidz2, and da[0123] were identical disks (same model number), and you saw this output in iostat, would you think da0 might be about to fail? https://www.le-fay.org/tmp/30d/QtTzEN.txt 17:40:54 %b for da0 is consistently higher than all other disks 17:42:22 oh, wait this is user error... da0 is running the SMART self test 17:42:31 I would check smart and have a spare ready in case something fails. 17:42:38 classic :D 17:43:38 i really need to work out how to do partial self-tests so it's not running in the middle of the day when i'm trying to use the disks 19:49:11 pid 13980 (rust-installer), jid 146, uid 65534, was killed: failed to reclaim memory 19:49:11 context: poudriere compiling lang/rust 19:49:11 that's not the first time i have this problem 19:49:11 but this time I had the luxury of a machine on which I could reserve 96GiB of RAM for the builder 19:49:11 I have MAKE_JOBS_NUMBER and PARALLEL_JOBS set to 1 19:49:11 What am I doing wrong ? 20:15:49 reclaim memory? 20:16:14 OOM 20:16:47 so is the build using 96gb of memory? 20:18:39 I can't say for sure, but yes, that's my interpretation 20:18:40 what would be the best way to confirm it? 20:18:40 the job only gets killed after 5-6 hours 20:19:05 Rust is a beast ot build. 21:19:05 babz: You have to be kidding... I haven't tried compiling the compiler, but that has to be a joke.... I can't imagine it would need 96 gigabytes of RAM... and 5-6 hours... right? 21:19:54 babz: no, this is normal for rust 21:20:11 rust is routinely the build that gets OOM killed on machines with "low" amounts of RAM 21:22:10 make sure you turn off tmpfs for builds, lower the amount of parallel jobs, etc. all the usual stuff 21:22:29 And people take this language seriously?!?!?! 21:24:13 dautor851805: it's mostly LLVM that is at blame here 21:24:37 but then again, why are you building it yourself to begin with? 21:25:02 why waste CPU and then complain about having to waste CPU? 21:25:47 I forgot modern compilers are awful beasts :( 21:26:04 makes me want to "rewrite in fasm" :P 21:32:31 i can bootstrap the llvm/clang toolchain for base without problem on much less powerful machines 21:32:40 but rustc stands apart 21:41:40 also, I don't know shit about compilers, but it seems weird to me, when you claim to avoid undefined behaviors, to have your reference compiler emit LLVM IR for optimization ? 21:44:28 Hello! Please tell me, is it worth using the ZFS file system on a home computer with one hard drive or making do with the UFS file system? 21:48:44 babz: avoiding undefined behaviour in a language means that anything that doesn't match it at runtime is a miscompilation and considered a bug. it isn't realistic to implement a formally verified optimizing compiler with all the platform support needed + you kind of have to consider that many ISA specs are plain text as opposed to being formalized 21:50:07 that being said, i don't think rust has a formal spec. there are a few formal models of rust-like things floating around but nothing official AFAIK? 21:51:09 The spec is to evangelize it 21:55:02 I can feel the appeal to have a performant system language designed for static checking 21:55:02 but that's weird to implement it on llvm, as it's designed to build optimizing compilers taking advantage of C's UBs 21:55:02 like, I've seen poeple surprised that you couldnt, in some version of the compiler use an infinite loop to panic, because LLVM can optimize it out 21:57:44 babz: LLVM is written in C++ 21:59:19 C++ what's that ? D ? 22:01:21 Kit_Leopold: I would say yes. You still get really nice ZFS features with a single drive. 22:03:54 babz: the nature of how you transform your language's semantics to the IR depend on the semantics of both. llvm IR is no different. it has some semantics (i don't think those are formally defined either, though there are some things floating around as well). rust has some semantics. it's up to the rust compiler developers to map those onto each other. if the execution doesn't match what the rust language 22:04:00 people expected, then that's a miscompilation. it could be at the stage where llvm IR is generated and therefore they map the language wrong onto the IR, it could be in llvm itself or it could be in the rust implementation of some stdlib function 22:04:57 the reason rust uses llvm is likely because getting the same kind of optimizations that they want would require reimplementing their own variation of llvm with a different and likely less-tested IR which can cause the same kinds of bugs that llvm can 22:06:49 dautor851805: Thanks for the answer. 22:07:48 Kit_Leopold: I run it on many machines with single drives. Also, check out sanoid and syncoid - they might be interesting to you. 22:14:58 dautor851805: Thank you again. I've never heard of sanoid and syncoid before. 23:05:47 Good evening. Is it possible to build BSD based distributed cluster on arm to run openstack and share computing resources between grid nodes? - Thank you for your answers.