there are mbcs-related functions that should allow you to convert back/forth. So a ro w in chars would correspond to a translated number of bytes.

a good start point: man 3 multibyte

so I have to parse it with wcwidth and test for unicode word joiners, no?

yes and no. Unicode is more complicated than that, use a library. With terminals you'll also have the issue that they don't get unicode right anyway.

so here is the deal: what if server and client disagree where the cursor should be when I try and move cursor left through a grapheme cluster?

client supports the grapheme cluster, so it moves three code points, namely 2 emoji code points + 1 word joiner

server does not support the grapheme cluster so it moves one code point and it might stop at the word joiner or goes past it

in this case how would both sides achieve consistency?

and how would client render it on screen if such consistency mandates the cursor sit at the word joiner?

alas, how dearly I miss iso8859-15

terminal stuffs are crazy

Demosthenex: "systemd for x11" Don't give Lennard more ideas. Soon we'll get a systemd-displayd.

Hello, I am trying to install some software in an old version of FreeBSD (v11.2) (... right now I am stuck with 11.2 and can't use any more modern). Ok, I'm trying to use ports and build the software, it is pretty promising but I am running into a problem which stops the build process.

The build process complains about texinfo 6.5 and some files that have size mismatch. "port manually into /usr/ports/distfiles/texinfo/6.5 and try again" ... if I download ftp.gnu.org/gnu/texinfo/texinfo-6.5.tar.xz I can find the files the build complains about, but just placing texinfo-6.5.tar.xz info /usr/ports/distfiles/texinfo/6.5/ doesn't solve the build error

For example, the build complains about size mismatch for the file 'htmlxref.cnf', if I extract that file from the .tar.xz and place it right under /usr/ports/distfiles/texinfo/6.5/ that error goes away... but then it complains about the next file...

Pionat: just a wild guess, TLS certificate database is current enough for https downloads to work normally?

vedranm: I have no problem downloading files to this FreeBSD system (the fetching works)

vedranm: It is probably helpful if I post the printout from the build process, here it is: pastebin.com/yAjk3uxv

the tricky issue seems to be: SHA256 Checksum OK for texinfo/6.5/texinfo-6.5.tar.xz. SHA256 Checksum OK for texinfo/6.5/htmlxref.cnf. SHA256 Checksum mismatch for texinfo/6.5/texi2dvi. SHA256 Checksum mismatch for texinfo/6.5/texinfo.tex.

texi2dvi and texinfo.tex were taken from texinfo-6.5.tar.xz ... so apparently the build system wants some other version of those files

Pionat: it seems that distcache doesn't have the files anymore

unfortunately, outside downloading from upstream, not sure what can I suggest

Pionat: cgit.freebsd.org/ports/commit/print…bd1f9dad2f7dba3b57cdf7161e58a557e2f

seems like the gnu project doesn't know how to release software

I'm trying a different approach by simply downloading the source code for software and building it (the usual ./configure + make procedure), I have built and installed libcrypto (installed into /usr/local), but when I try to build software that requires libcrypto it complains that it cannot be found pastebin.com/BCWh1yTm

"Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix."

nimaje: I have tested adjusting PKG_CONFIG_PATH, it was unset by default, I have set it to "/usr/local/" and I still get this error

I'm pretty sure the .pc files didn't got installed directly to /usr/local/

Should it really be necessary to manually point out that libcrypto is installed in /usr/local ? Shouldn't that be detected automatically?

I have found more programs that have no idea that packages on the BSDs go into /usr/local or /usr/pkg than ones that do

what's /usr/pkg though?

Not defined in hier(7) is what it is. ;)

yuripv: NetBSD

ugh why does this constantly break. Ok so when I first setup wireguard I used the default MTU of 1420 for wireguard... however since yesterday I have been having TLS hello freeze... this is due to an MTU issue... but why has it only occurred now? I haven't touched the networking... to fix it through trail and error I found 1325 is working, anything higher stops working

I must be missing something important

a cert got updated, and is bigger?

remiliascarlet: it'll happen.

remiliascarlet: but his royal highness poetteringfnurt has moved on to M$ to help screw over their malware distribution system, i mean OS further.

looking at telnet rfc 854 which reserves code 240--255 for telnet-specific functions, colliding with utf8 leading byte, does this meab utf8 over telnet is _impossible_?

of course we could have a special parser for IAC, but then what if the terminal stream itself include byte 0xff?

ssh at leasr has IUTF8

s/leasr/least/

has anyone noticed that in 15.0, setting link0 on a tap(4) interface to prevent addresses being removed when the interface comes down doesn't actually work? this is reliably reproducible with vm-bhyve, i'm not sure if that's doing something weird

actually, this might be vm-bhyve's fault, it seems like it removes link0 when the VM boots

jgh: dunno

hi, know anything? pastebin.com/Ehh4rnMQ (bsd.to not working)

so security/openssh-portable is broken without the KERB_GSSAPI patch, and with the KERB_GSSAPI patch it's broken because the patch doesn't exist? am i missing something?

how can such an important port just be randomly broken?

seriously, fucking ports

ah, pkg install cado-nfs, error... port make works now apparently, thanks

Hi, in a FreeBSD 13.1 and a 13.2 I'm trying to install rust, but I get: ld-elf.so.1: /usr/local/bin/../lib/librustc_driver-d829a4d8a572ebe4.so: Undefined symbol "_ZNSt3__122__libcpp_verbose_abortEPKcz", any hint?

How are you installing Rust?

with pkg install rust

I think that is usually caused by a mismatch between the version your base system is and the version of the pkg database such as: forums.freebsd.org/threads/firefox-128-unable-to-start.94239

martinrame: neither 13.1 nor 13.2 are supported, upgrade to 13.3 or 14.1

mzar: yes, I'll do.

erk: it might be because I'm on a jail.

perhaps old rust will install fine

mzar: the older I see in pkg is 1.79

Mmm, freebsd-version -kru gices 13.1-RELEASE-p9, 14.0-RELEASE-p2 and 13.1-RELEASE-p9, I wonder how to revert that 14.0 to 13.1?

s/gices/gives/

I'm trying to upgrade to 13.3 and I get: termbin.com/7336

martinrame have you tried to upgrade and didn't finish?

s2r: some time in the past I tried to upgrade to 14.0 and stopped it.

is there a way to revert the whole system to 13.2 or 13.3?

it seems that you upgraded some parts and some not.

You tried to upgrade using freebsd-update ?

yes that's what this termbin.com/7336

that's what that shows. Fetching 1 metadata files... failed.

And what about upgrading to 14.1

?

s2r: no, because this is a build server and the target is running 13.2

aaah, ok.

the problem is freebsd-upgrade is trying to fetch some 14.0 files, when I need 13.2 or 13.3.

If you can back your data up why not doing a fresh install and restoring it? Wouldn't it be faster?

s2r: yes, as this is a jail I could reinstall everything

can't you set the freebsd version to the jail to the one you need?

s2r: how?

Do you use any jail management system?

no, just the one in the base system

Check this dpaste.org/payTX I use cbsd and it allows to specify different versions. Let me try to find in the doc where does it use it to invoke fbsd base system.

s2r: when I use jls -n it gives plenty of info, and there it shows 14.0-RELEASE-p2

In the end files in a jail are simply files. If it were me and I needed to rescue-reset a jail to an older version I would create a new older version jail and then copy-merge the files from the new one and thereby reset the old one. Manually selecting which files to copy back using rsync selectively.

Also since I am using zfstools zfs-auto-snap I would probably be able to return to a previous snapshot from before when everything was previously in the desired state.

rwp: yes, I'm trying to create a new 13.3 jail, but it always creates an 14.0, I cannot find how to create an older jail. I remember there where some env vars to setup, but I cannot find those...

Then as to the problem of installing rust from ports... That's a much harder problem because AFAIK the best way to install older ports is to create a build environment for that older out of support version and then build the port locally on that older build. Which for Rust might take a couple of days of build time on a fast machine.

How are you trying to build the older jail? (But getting a newer OS instead.)

rwp: sudo freebsd-update -b /datos/jails/buildserver_13_2/ fetch install

rwp: in /datos/jails/buildserver_13_2 I installed fetch download.freebsd.org/ftp/releases/amd64/amd64/13.3-RELEASE/base.txz -o /datos/jails/base_13.3

The download.freebsd.org/releases/amd64/13.3-RELEASE/base.txz path was exactly what I would suggest. So that's good.

If that was unpacked then that result should be exactly 13.3R and not anything newer. At that point how is it getting upgraded beyond that version?

rwp: yes, but when I do a freebsd-update -b /datos/jails/buildserver_13_2/ fetch install

rwp: it installs 14.0

rwp: I wonder why???

Just a small thing but 13.2-RELEASE is not 13.3-RELEASE and there is some mixmatching of the names there.

Why the freebsd-update fetch install? Since the point was to have the previous release already?

rwp: yes, that's because I created the 13_2 directory then figured out that it's never fetcheable

I am pretty sure that when using freebsd-update in a chroot or jail that one needs to use "--currently-running release" in order to tell it what release is in that chroot or jail.

rwp: I'm following the handbook

rwp: there is this: freebsd-update -b /usr/local/jails/containers/classic/ fetch install

rwp: that's why I use fetch install

Otherwise the default for freebsd-update is to use the version from the running system. That's just one of those annoying features of it.

anyway, I have a VM with 13.2 properly installed, and the rustc error happens exactly as in the buildserver

ld-elf.so.1: /usr/local/bin/../lib/librustc_driver-d829a4d8a572ebe4.so: Undefined symbol "_ZNSt3__122__libcpp_verbose_abortEPKcz"

I don't understand the purpose of running freebsd-update after having created the jail of the desired version already. That does not yet make sense to me.

rwp: please, forget the jail issue for a while. I'll be working on the 13.2 VM that's installed correctly.

I am pretty sure you would need to run "--currently-running 13.3-RELEASE" in order to have it behave sanely. I have tripped over that before. I think it is an annoying misfeature that it always defaults to using the host system release.

rwp: sorry, where shuild I run that?

I don't recognize the undefined symbol error. I am not a rust person. But my understanding is that you would need to craft a build environment as it was for 13.3R at that time. And that includes the state of the rust ports at that time.

If we suddenly transported ourselves back in time 6-9 months then at that time presumably rust compiled successfully at that point in time on that release.

And if that system were to be compiled again today then it would still compile successfully again today.

It would be nice if there were an archive of binary pkgs that one could reach into and pull out the compiled pkg files from those previous points in time. But AFAIK those are not archived anywhere.

However if you know of anyone else who is running FreeBSD who has previously installed those pkgs then it is possible they could have them in their local system's cache still and could pass them to you.

Or if you have another of your systems somewhere with them still in the cache on those systems then maybe you would be able to pull them out of those other systems?

I am talking about the cached downloaded pkg files at /var/cache/pkg/*.pkg which are the precompiled binary packages downloaded to the local system before installation.

rwp: do you mean rustc in the cache?, no, this is the fist time I try to install rust.

Then you won't have it yourself. Any friends that might have installed rust previously that could help you out?

And if not then well it was just an idea. If not then the only way is to build it yourself. Which is definitely possible. It's just a long compile run to get there.

rwp: yes, I was thinking about building it my myseld

Sorry but I am not a rust person myself and don't know what the bootstrap process for it will be. I can only wish you good luck with the task as I return to other duties here.

rwp: thanks for your help.

rwp: you would have to be a c++ person for that and then you probably still use some tool to demangle that symbol, my guess is that it is something that got added with the newer llvm version that is in 13.3

What sort of tools do you guys use for automated provisioning? I'm using Ansible right now for my Linux setup but in the process of setting up FreeBSD and was curious if there are any better tools people like

nimaje, That symbol name did look like it was c++ name mangled. And I would guess the error was a result of running a newer compiled executable on an older system without it.

Which is why I think the path to run on that older system would require compiling on the older system.

This is definitely a positive for running a system that is already fully compiled from source all of the time. And using snapshots. Because then one is always already set up for being able to handle and manage such situations as a normal course of routine.

Rather than finding themselves needing to do this and then needing to both climb the learning curve of setting it up and also running through the machine time to get there. Plus potentially needing to debug missteps along the way.

mikewilzn: Ansible is great

puppet's better. though the bsd support is mixed

mikewilzn: You might run into problems with ansible and FreeBSD. I did, and upstream aren't really interested in patches. netizen.se/docs/ansible-chmod

hello I am having issues with freebsd cannot connect via ssh all of a sudden

First I would use ssh with -v to see if the verbose client side messages have any information.

It this server one of yours? Can you access it by any other means? Can you log into it from any other client systems? Can you log into other server systems?

it's my server

I can do it via the vnc from my isp

cloud service provider rather

When you eventually log into by other means look at /var/log/auth.log file and see what is logged there at the same time that you are logging into it and failing.

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

If it comes to deep debug then on the server run as root "/usr/sbin/sshd -d -p 2222" or some other port number allowed through the firewall and then connect using that port. The -d debug messages from the sshd daemon server side will say why the connection is not being authorized.

interesting because it was expecting a certain key exchange

I found this but like the others there don't know why it worked there: unix.stackexchange.com/questions/72…t-expecting-ssh2-msg-kex-ecdh-reply

I did sorry

sory I thought I sent the link

sorry *

Is the server continuously getting a SIGTERM 15 there and that is the problem?

I don't know what that is but sounds like it could be

I can't imagine what might be doing killing sshd and restarting it in a loop. Bizarre! Something for you to find and fix though.

how ?

could it be something with the fact that it's ssh2?

When I had some mystery thing like this not too long ago, it was from when I had upgraded from 13.x to 14.0. I had an rc script i had written that used to call `php` which was implicity calling /usr/local/bin/php. In 13.x, just `php` worked. In 14.0, I had to put the whole path.

During this time, i could not normally stop the jail. I had to manually kill most of the processes before it would stop successfully

Point being, maybe there is an rc script that is trapped in a loop and making the whole thing misbehave.

For my case, it was happening in a jail. Nevertheless, I couldn't make sense of what was happening. I hadn't changed anything. But when I discovered this service that constantly was trying to be restarted by the daemon, and i fixed it, it behaved again

Yes, seems unrelated, but we're rubber ducking here. Something weird is going on.

so what do I do?

this is all of a sudden

bumping LogLevel in your sshd config would be a good start

it's consistently getting a SIGTERM, what was it doing? Presumably handling a connection, but will it give you any more details?

not sure could it be the opendkim that is a problem?

could it be the firewall maybe? pf

better to gather evidence and follow it than blindly speculate

you can see in the log that it's getting a SIGTERM- there's a good chance it's sending it to itself, now ask it for more details (raise the LogLevel in your config)

kevans: sigterm is when your terminal resizes or something similar

er

or is that sigwinch

that's sigwinch

it'll generally send it to itself when shit hits the fan for one reason or another

man signal | grep 15 => 15 SIGTERM terminate process software termination signal