so with X11 I get a lot of "fault errors on pipe A" messages printed out to the console, even though it seems like everything still works properly. should I worry about these messages?

makes dmesg practically unusable

seems it's picom causing the fault errors

also noticing that mesa is using llvmpipe, not iris :/

another issue, I can't seem to get tamzen-font working at all. I've installed it through pkg, I added /usr/local/share/fonts/tamzen-font to my X11 FontPath, ran fc-cache -fv which confirmed the directory was being parsed

but anything that tries to use tamzen gives a "cannot convert string to type FontStruct"

so I notice that while /usr/local/share/fonts/tamzen-font shows up in Xorg.0.log under "FontPath set to:", it does not show up in the font path shown under xset -q

trying to add this directory to the fontpath through xset +fp gives "bad font path element (#0)"

not sure why this is being such a PITA on FreeBSD while the exact same version of X.org on Void Linux handles my addition to FontPath without any hassle

what program is causing "fault errors on pipe a"

rtprio: it seemed like it was picom, because commenting it out in my xinitrc stopped the error messages

though for now I think it's more important that I figure out why everything is using llvmpipe instead of hardware acceleration, because for all I know getting picom off of llvmpipe will fix the issue

Xorg.0.log clearly mentions that it's using iris for DRI but then glxinfo reports that llvmpipe is being used

i've never heard of llvmpipe

i think that's the (newer) software renderer?

yes, it's the successor to swrast for when mesa doesn't have hardware acceleration available for whatever reason

in this case it shouldn't be falling back to it though. I have the Linux 5.15 DRM drivers installed, and i915kms is loaded

like afaict it has everything it should need

hi

hy

So

do i need to compile my own kernel if i want to add my own boot splash these days?

splash(4)

hey. is it normal that pkg(8) in default-yes mode installs packages upon pressing ^C? this is bad and POLA-violating.

sthalik: probably a bug and should be reported

kenrap, thanks. bye.

🙄

Well, to be fair, *ahem*, I can see why the yes-default-mode doesn't get much use... the default no-default-mode is a saner POLA design choice because it prevents the user error of hitting enter by accident when you didn't want to do that. Har de har har.

Is there any archive of older freebsd package repositories? They keep taking down all the packages for anything that is not a fairly new system now days, which is frustrating. I need to install some packages on a freebsd 12.0 AMD64 machine but the oldest packages on pkg.freebsd.org are for version 13-release_2.

i wouldn't bother, use the ports

also, i don't think that there is

Using ports is not an option. Since the system has been maintained with binary packages, nothing ever compiles in ports for me unless every single package on the system was compiled from scratch with the same port tree. They always fail to compile.

well, that might be your only option short of building the packages yourself or upgrading to a more recent version

vstemen: That's an odd issue. Can't say I've ever observed that before.

rtprio, OK. Thanks. Freebsd used to not do that. I would have machines with uptimes in years and could still maintain them. Now, they seem to be behaving like Linux and shoving the latest shiny new releases down your throat, cutting off maintainability on slightly older systems.

A machine with uptimes in years isn't being maintained.

hackfoo, You mean being able to compile from ports? I have been doing this for 20 years and I don't think I have hardly ever had anything significant compile from ports an any system that has been built using binary packages.

I've been doing this for longer than you have, and I've _never_ seen that issue.

So I find it odd.

Not saying you don't have the issue, I just think it's an odd issue.

hackfoo, Yes it is. I still do configurations and periodic package installs, etc. There is a lot of maintenance that is done without installing a new kernel and rebooting.

and even if you had to compile every single port, why is that so bad? you'd then be running the most recent version available

spend a bit of time configuring options and BATCH=true portupgrade -a

vstemen: My previous statement stands. If you're not actually patching the system, you're not properly maintaining it. That includes the kernel.

or vacuuming out the power supply

hackfoo, keeping a production machine, that isn't necessarily exposed to the internet isn't always practical to "properly maintain" as you say. I agree that it is better to "properly maintin" it but that isn't always practical until the time is right. If a machine is doing it's job, we don't always have time to spend days or a week fully re-installing it and getting everything reconfigured to work properly.

i disagree, there should always be time for scheduled maintence

Always.

or your just painting yourself into a corner, like you are now

And I can't help but wonder how much the maintenance issue is contributing to ports not building properly.

how much reconfiguration is there really between minor versions of port upgrades; i've rebuilt all ports on many systems with zero interruption in services

You often run into driver issues, and all kinds of stuff. I have upgraded systems on client sites where, once upgraded, the X windows drivers no longer worked with their video cards, then discovered that nvidia no longer put out a driver for the older card that supports the ABI changes in the newer Xwindows, so then it required hardware upgrades, etc, etc, etc. Often causing down time in the days or a week or more. That's just one example of problems

we have encountered when ugrading. So, if it aint broke, best not to fix it until you know you have the time and it is feasable to have a large down time window. Not to mention configuration files incompatabilitys from the old to the new versions of software, such as mail servers, etc. I could go on and on of the problems than are often encountered when upgrading.

rtprio, also there is no such thing as a minor upgrade from ports. It always wants to reinstall half the libraries on the system to have exact version matches to whaterver application you are upgrading, then that breaks half the other stuff on the system.

and we test all upgrades in production.

I have had the best luck installing from binary ports of the same exact version for the OS release that all other packages were installed for.

HOWEVER... Knowing that you don't properly maintain the system, it's difficult to pinpoint where the issue lies.

As I mentioned, I was hoping to find an archive of the binary ports for the exact release, 12-release_0, in this particular case because that is what all the original packages were installed from.

Anyway, my main gripe was that freebsd does not keep older archives around for thos cases where older installations must be maintained for a while. I would much much prefer to fully upgrade to newer releases, but that is not always practical or possible.

vstemen: that's not true. but it's something to check on your test version of this system

bitching about obsolete packages being deleted here isn't going to solve your problem. it's not openbsd where you can install an old version and all the packages at that moment in time

vstemen: if you have the resources, looks like the solution is to run a poudriere jail/VM for your old version. i build all my packages with poudriere and keep a separate one for a different major version. that way you can be assured to have the packages available and upgrade at your own pace, and the ability to patch your ports if necessary to support an old installation. i think there are even

people running 11 still doing this

jmnbtslsQE, Thanks for the suggestion. I have actually been thinking about looking into poudriere but have not had a chance to yet.

yeah, i'm no expert on ports, but from what i remember years ago working with ports directly, poudriere is generally a huge step up in terms of convenience/productivity

Trust me to stumble across weird behavior: has anyone else noticed that sometimes, chunks of what you type in the X vty get fed to the console vty as well? It manifests as dmesg entries like: "Feb 4 19:55:28 Pusat-Tasek login[51501]: 1 LOGIN FAILURE ON ttyv0, [redacted: the unredacted version has several concatenated chunks of text I typed]"

Happens to me on 13.2. I vaguely remember it may have happened on 12.2 or 12.3 as well.

Bugzilla search for "vty crosstalk" or "vty cross talk" returned no obvious match that I could see.

hmm, so I wonder if I made a mistake going with STABLE, and putting myself in a position of needing to build from source. I recall buildworld && buildkernel not being that painful back in like 2015, but either I'm having some weird lapse in memory or LLVM has ballooned in size, considering I'm seeing reports of these builds taking hours upon hours

I'm still really curious what the issue is with tracking stable through the snapshot sets, like here: download.freebsd.org/snapshots/amd64/14.0-STABLE

Title: Index of /snapshots/amd64/14.0-STABLE/

I'm guessing freebsd-update upgrades the system through the RELEASE version of these sets, though I know it refuses to work on STABLE, but I'm surprised that I can't find anything about how to replicate what freebsd-update does by hand

``llvm |``

^ llvm pipe

I have a host with a PCIe card that has two NICs on it, both are in ppt mode, I'd like to pass one NIC to one guest and the other to another. is that possible?

tm512: maybe look at pkgbase (wiki.freebsd.org/PkgBase) which claims to have stable/14 builds, although i've only used it with 15