-hey; in man rc.subr, when i see ${name}_env that's a literal ${name}_env not myprogram_env, right?

because of rc magic will substitute it for me

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 . &)

[0x1eef_]: depends on how you're starting the X11 forwarding

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).

There also happens to be an instance of X running on the same machine. Hrm.

Ok using that display doesn't help. It starts on the other computer's screen instead.

[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.

[0x1eef_]: do you test with xeyes first?

i have X11 forwarding enabled on the remote computer as well as X11DisplayOffset to 10

reviews.freebsd.org/D43696 giggity

Title: ⚙ D43696 Jail descriptors

johnjaye: Nice to see you here :) I think I am hitting the timeout described in the man page:

If this option is set to no (the default), remote X11 clients

will be considered untrusted and prevented from stealing or

tampering with data belonging to trusted X11 clients.

Furthermore, the xauth(1) token used for the session will be set

to expire after 20 minutes. Remote clients will be refused

access after this time.

ah i think that is in ssh_config man page

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.

Router and AP are both Fortinet hardware.

xa0z: DNS / Reverse DNS / UDP issues? (or anything in ssh -v)?

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.

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

xa0z: missing timezone settings? missing sysctl settings? (for the adjkerntz)

I exeuted tzsetup on them, and restarted them, still laggy.

Mind you, this issue was non-existant until I swapped the old AP out for the new one. :/

Hello

dovecot:\

:openfiles-cur=1024:\

:openfiles-max=2048:\

:tc=daemon:

will that be working on frebsd?

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,<JObFifl8Y8PAqGR1>): pam_authenticate() failed: Authentication error (/etc/pam.d/dovecot missing?)

what pam.d even is?

V-T60: Pluggable Authentication Modules

Jan 12 16:31:03 generic dovecot[30355]: auth: Fatal: Support not compiled in for passdb driver 'bsdauth'

the one that worked on openbsd doesn't work on freebsd

V-T60: yeah, authentication is usually very system specific

What is the easiest way to substitute bsdauth?

Jan 12 16:31:03 generic dovecot[30355]: auth: Fatal: Support not compiled in for passdb driver 'bsdauth'

that worked on openbsd

but now on freebsd doesn't work

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?

V-T60: i don't think freebsd supports bsdauth? it uses PAM instead

lw: yeah, that is so

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

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

you might want to check system doesn't include any random stuff dovecot shouldn't be using

now i'm struggling with other problem

Title: 274504 – mail/opensmtpd tls fails with FreeBSD 14.0-RC1

and on my architecture i have opensmtpd 6.8, maximum

this is probably related to openssl 3.0 dropping legacy cyphers. shame this patch has been sitting for 2 months with no movement...

V-T60: i suggest mailing the port maintainer to ask if this can be committed

V-T60: also what arch are you on? 7.3 was committed in october, a new package should have built by now

lw: armv7

ah... that is like super deprecated, maybe ports don't build often

i like this architecture and device

(arm64 has 7.3.0)

Allwinner H3 can't work with arm64 somehow, can it?

why would that be *deprecated* though?

amd64 has so many years older devices

like, 2015 against 2006

all 32-bit archs are being deprecated/removed, including i386 and the 32-bit arm platforms

although apparently armv7 is still supported for now in 15.0, unlikely armv6 which is going away

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 pkg.freebsd.org/FreeBSD:14:armv7

Title: Index of /FreeBSD:14:armv7/

is the package in the repo? maybe it failed to build

ah it's still 6.8 on quarterly

freshports.org/mail/opensmtpd that's weird, i386, amd64 and arm64 all have 7.3 in quarterly, i wonder what happened to armv7

Title: FreshPorts -- mail/opensmtpd: Security- and simplicity-focused SMTP server from OpenBSD

yeah, might i wonder? if you don't know...

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

wait i was looking at the wrong thing, armv7 *does* have 7.3 in quarterly, it's just v6 that doesn't

strange thing

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

does pkg upgrade not offer the new version? what's in your pkg repo config?

FreeBSD: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/share/keys/pkg", enabled: yes }

that's only what was found in /etc/pkg

i wonder how ${ABI} expands on arm

in FreeBSD.conf

V-T60: can you run 'pkg -d update'? it should show the specific URL it's fetching for packagesite.pkg

what about links here...

DBG(1)[34401]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:14:armv7/quarterly/meta.conf

DBG(1)[34401]> curl> fetching pkg.FreeBSD.org/FreeBSD:14:armv7/quarterly/meta.conf

oic, 7.3 is in the freebsd 13, but the freebsd 14 repo only has 6.8. ?? that's weird

DBG(1)[34401]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:14:armv7/quarterly/packagesite.pkg

V-T60: well i will go back to my previous advice that someone on ports@ might know

FreeBSD repository is up to date.

All repositories are up to date.

# pkg upgrade opensmtpd

Your packages are up to date.

version: OpenSMTPD 6.8.0p2

it seems like the build went fine: ampere1.nyi.freebsd.org/data/140rel…2d80/logs/opensmtpd-7.3.0_2%2C1.log

V-T60: can you try changing your FreeBSD.conf to use url 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

Title: Index of /FreeBSD:14:armv7/quarterly/

oh

root@orangepi:/etc/pkg # cp FreeBSD.conf FreeBSD.conf.bak

this way? url: "pkg+http://pkg0.nyi.freebsd.org/FreeBSD:14:armv7/quarterly",

#mirror_type: "srv",

ok, without pkg

Updating FreeBSD repository catalogue...

yeah, just http://

FreeBSD repository update completed. 30452 packages processed.

Your packages are up to date.

and pkg search opensmtpd only shows 6.8?

opensmtpd-6.8.0,1 Security- and simplicity-focused SMTP server from OpenBSD

probably at least a pkg file anywhere out there?

with exactly opensmtpd

Hey all, if anyone can help us with this, I'll be very grateful. lists.freebsd.org/archives/freebsd-…alization/2024-February/001921.html

Title: if_ixl: Admin Queue memory allocation issue hangs the server

how do i build a pkgbase repository from a src checkout?

wiki.freebsd.org/PkgBase does not appear to provide enlightenment

Title: PkgBase - FreeBSD Wiki

lw: make packages

thanks

and make update-packages

what's the difference?

the update-packages updates the packages that need updating

lw: codeberg.org/pkgbase/website/src/branch/main/howto/bootstrap.md

Title: website/howto/bootstrap.md at main - pkgbase/website - Codeberg.org

ah right

might also be helpful

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?

yes, you do. unless you want to rebuild all 503 packages every time

ah ic

so i need to run make packages once, then every subsequent build i can run make updates-packages, unless UPDATING says otherwise?

update-packages

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?

i wish ports had a proper cross-build support

is anyone working on that

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

What is up with "fasm" port? It only comes as a 32-bit executable.

Could we get a x86_64 build, too?

dautor851805: is it only distributed as a binary upstream? or why does the port use a binary?

lang fasm or cad fasm?

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.

paulf: lang

I'll have to install lib32 for that, though... agh...

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.

well, double that - I missed system.inc

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? le-fay.org/tmp/30d/QtTzEN.txt

%b for da0 is consistently higher than all other disks

oh, wait this is user error... da0 is running the SMART self test

I would check smart and have a spare ready in case something fails.

classic :D

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

pid 13980 (rust-installer), jid 146, uid 65534, was killed: failed to reclaim memory

context: poudriere compiling lang/rust

that's not the first time i have this problem

but this time I had the luxury of a machine on which I could reserve 96GiB of RAM for the builder

I have MAKE_JOBS_NUMBER and PARALLEL_JOBS set to 1

What am I doing wrong ?

reclaim memory?

OOM

so is the build using 96gb of memory?

I can't say for sure, but yes, that's my interpretation

what would be the best way to confirm it?

the job only gets killed after 5-6 hours

Rust is a beast ot build.

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?

babz: no, this is normal for rust

rust is routinely the build that gets OOM killed on machines with "low" amounts of RAM

make sure you turn off tmpfs for builds, lower the amount of parallel jobs, etc. all the usual stuff

And people take this language seriously?!?!?!

dautor851805: it's mostly LLVM that is at blame here

but then again, why are you building it yourself to begin with?

why waste CPU and then complain about having to waste CPU?

I forgot modern compilers are awful beasts :(

makes me want to "rewrite in fasm" :P

i can bootstrap the llvm/clang toolchain for base without problem on much less powerful machines

but rustc stands apart

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 ?

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?

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

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?

The spec is to evangelize it

I can feel the appeal to have a performant system language designed for static checking

but that's weird to implement it on llvm, as it's designed to build optimizing compilers taking advantage of C's UBs

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

babz: LLVM is written in C++

C++ what's that ? D ?

Kit_Leopold: I would say yes. You still get really nice ZFS features with a single drive.

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

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

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

dautor851805: Thanks for the answer.

Kit_Leopold: I run it on many machines with single drives. Also, check out sanoid and syncoid - they might be interesting to you.

dautor851805: Thank you again. I've never heard of sanoid and syncoid before.

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.