well, it's after 00:00 UTC, allegedly a new batch of pkgbase builds should be being made. is there anywhere I can monitor the builds for 15.0? I'm struggling to find my way around pkg-status.freebsd.org. not seeing anything for pkgbase there

it kinda seems like the pkgbase builds for 15 broke as soon as it was forked off to stable/15 with main becoming 16

pkgbase builds are being made for both main (16) and stable/14, so did someone forget to add stable/15 as a new branch to build packages from?

would be nice to see if the build issues with drm-66 is something that has been fixed since this sept 4th pkgbase snapshot

tm512: i poked internally about stable/15 there

he's been quite busy with sme other bits related to the ongoing release, though, so it's maybe not all that surprising if it just slipped

(and they're indeed not published at all on pkg-status.f.o)

got it, I just want to rule out whether the drm-66 build failure is something that got fixed after this pkgbase snapshot was built, or if my upgrade from 14 to 15 was indeed botched

I am baffled what could go wrong. my vnode.h matches what's in stable/15, yet it's still throwing compiler errors

"error: declaration of 'struct vop_inotify_args' will not be visible outside of this function" seems like this struct should be declared/defined elsewhere, and included prior to this function prototype

but it's just not

tm512: vnode.h isn't the problem, a file generated during the build is

in fact, I'm not seeing any definition of vop_inotify_args anywhere in the /usr/src tree I've got locally on 15

tm512: does your sys/kern/vnode_if.src have vop_inotify?

yeah, starting on line 830

sha256 of vnode_if.src is 009932d2f1d6813181e78b16590cd03a4afcdd886b12ff5e0f131b3002d68982

and this was a clean build of drm-kmod to start with, right?

.oO(is the machine haunted?)

is this in poudriere or not in poudriere? what does `which awk` look like?

presumably 'not in'

I was building drm-66-kmod explicitly, not through the drm-kmod metaport, just cd'ing to the dir and running 'make install clean', and it should have been a clean build, pretty sure I ran make clean after resolving the initial problem with my /usr/src tree not being properly managed by pkg

re: awk, I would have to reboot into the 15 BE to see, but here on 14 it's just /usr/bin/awk and I don't expect it to be different, I don't have any awk in /usr/local/bin

well, you could also `bectl jail` the BE

but it doesn't matter, yeah

I figured I couldn't jail since I'm on a 14 kernel

oh, 14 -> 15

sorry, trying to spit out as much as I can before I have to go wrestle damn-near-2yo into bed

i'd be interested in seeing what the generated vnode_if.h looks like if you can reproduce the failure

where would I find vnode_if.h?

*should* be in dmabuf/ inside the work tree, iirc

theret's probably more than one, it'd maybe also be interesting to know if they're all identical

it seems I've cleaned out the work tree since I last made an attempt at this, so I will have to reboot to give that a shot

so bbiab

booted into 15 now

fwiw, awk is version 20250804 (and is indeed /usr/bin/awk)

it's a bit weird, lately when trying to pull the latest ports tree, if I use git pull --depth=1 --rebase, the first invocation fails with "could not read <commit>" and "could not parse commit <commit>" but then a second invocation succeeds

it's not erroring this time. +1 for the machine being haunted

i think you found a build race, actually

cgit.freebsd.org/src/tree/sys/conf/kern.post.mk#n216 in the kernel-proper build, we slap an OBJS_DEPEND_GUESS to serialize absolutely everything on vnode_if.h being generated

oh hmm. the kmod build does as well, indirectly: cgit.freebsd.org/src/tree/sys/conf/kmod.mk#n565

or I wonder if I somehow did overlook cleaning out the entire work tree, and the vnode_if.h was generated based on the outdated/corrupted /usr/src tree, but I just don't know how likely that is

kevans_: and that kmod.mk applies to kmods built from the ports tree?

generally if the build completed the ports framework will be an ass about forcing you to clear out some other flags in the work/ tree to force a rebuild

yeah

e.g., dmabuf/Makefile includes <bsd.kmod.mk>

so assuming this does successfully build all the way, and drm-66 doesn't panic on boot like drm-61, then I'm in the position of dealing with 15 forcing a Firefox downgrade

the package for 15 is 142.0, whereas I was using 143 on 14

another weird thing, even though I did a full upgrade from 14 using pkg-static, running pkg upgrade -r FreeBSD-ports here on 15 shows a bunch of packages that still need to be upgraded and/or reinstalled

but just pkg upgrade on its own, reports "your packages are up to date"

termbin.com/6kl1 anyone know why a general pkg upgrade wouldn't see these? it clearly claims to be checking the FreeBSD-ports repo

maybe the fact that my firmware kmods are all outdated is why drm-61 was panicking on boot

also I thought these packages should be from FreeBSD-ports-kmods, not FreeBSD-ports, and specifying -r for the kmods repo also shows these firmware upgrades

hopefully it's a one-off issue, and not going to be a recurring thing where pkg upgrade fails to see packages. this upgrade process has been very janky

drm-66 built, going to reboot, though I'm not sure what I'm going to do about Firefox now that my profile is tied to 143.0

I've been burned by forcing a profile downgrade in the past

and I don't want to have to start from a fresh profile. it would be nice if I could just use the FreeBSD 14 build of FF

brb

tm512: the pkgbase for 15 availability thing is a bug in the automation; should be fixed within a few days or so

great, looking forward to that (assuming 15 + DRM 6.6 avoids the issues that 6.1 has, otherwise I'm going back to 14 probably)

hmm, so likelihood that Firefox will still work if I install the 143.0 package for 14 here on 15?

tm512: you need compat14x package at least

feels like dep hell tho

I guess I could try a jail, but I'm not sure how to give it access to my X server. generally I don't have any experience with jails

my other options are to chance it with forcing a profile downgrade, build FF from source on this not-very-impressive quad-core laptop, or to give up on 15 until the packages aren't so outdated compared to 14

here on 15 it feels like the defaults for trackpoint and trackpad sensitivity has been cranked up?

so installing compat14x, and then doing add -f on the cached 143.0,2 package, appears to have worked

right on

eventually package builds will stabilize

oh, I guess the 143 update was only committed on September 8th

I guess I don't know what's typical for the latency between commit and a binary being published. I would've thought the amd64 latest repos would be similar between the different releases

it will reach eventual consistency between versions, at least

the builders just build in a loop completely disconnected from each other, bulk -a to build everything incrementally from the last update

depending on where a given builder is at in the cycle, when it restarts to pick up a version of the ports tree with the update, other things that can cause pkg cleansing (src version updates for 15 (currently) and main), etc

I guess now that I'm on 15, it doesn't really matter, the issue is just because I've moved from a branch with a newer package

assuming I stay on 15 anyway. going to have to test the GPU hang issue

alrighty, so drm-66 does not fix the GPU hangs. I guess the additional data point is valuable, but ugh. now I've gotta decide whether to stay on 15, or roll back

the upgrade process was pretty dreadful, and I don't really want to repeat it, but if I go back to 14, maybe by the time I do hop over to 15 (maybe like 15.1 or 15.2) it'll be smoother

so yeah I'm convinced the trackpoint on this laptop has its sensitivity cranked up on 15 vs 14. does anyone know what that's about? how can I revert that?

so the GPU hang issue is even worse on drm-66. just going fullscreen with mpv, even without firefox open, causes a hang

tm512: no, I was referring to /usr/src checkout

it wasn't a checkout, it was populated by the FreeBSD-src{,-sys} packages, after completely nuking everything under /usr/src

but whatever, I couldn't reproduce the build failure today

neat, you fixed that

it was all (mostly) for naught, since drm-66 is even worse than 61

all I really got out of this was another data point, that it's not limited to 14 + drm-61

if 15 isn't giving me access to a more usable set of GPU drivers, I am just leaning towards rolling back to 14 until 15 is more mature. given how much I had to fight to get 15 to install, it gives me the feeling that the setup I've ended up with is perhaps a bit fragile

not sure what else 15 has to offer that I actually care about. is 802.11ac support on 15 better?

when I tried iwlwifi on 14 a month or so ago, I couldn't get it working properly, leaving me stuck with 802.11a using the old iwm driver

tm512: how long have you been using FreeBSD ?

I am only asking, because I see that you are very enthusiastic about FreeBSD

mzar: Most people who use FreeBSD are fairly enthusiastic about it

that's great 1

ld-elf.so.1: Shared object "libutil.so.9" not found, required by "env"

why I need compat14x-amd64 to build world on stable/15 ?

nevermind, it was unclean environment, leftovers from building stable/15 from stable/14

So which is the #BSD which perormance getting WORSE running in KVM not better over time?

Of course OpenBSD�

Of course OpenBSD��

Of course OpenBSD��

Of course OpenBSD�

Does OpenBSD have a decent suite of performance measurement tools? Or has Theo thrown the baby out with the bathwater with his various attempts to increase security?

this isn't really the place for discussion of openbsd

Not that FreeBSD is great for that either.

for continuous performance measurements?

we have public ci, but performance measurements are very difficult to do this way

vpp does a great job of it by employing a team of people to manage the process

no, stuff like pmcstat

tm512: it is believe that cgit.freebsd.org/src/commit/?id=c8a…636af8ac360ce6329c4a029dd8934d904de will fix the package availability Soon(TM)

believed

poudriere stopped working, unhandled error, whatever that means...

Is ports-mgmt/synth still a thing? I've never tried it, not sure if it's still maintained

I am building very few packages locally, only one currently used by the host, and the rest by jails. I think it stopped working after upgrading to 14.3, but I am not 100% sure when exactly

divlamir: Have you tried re-building/re-installing pourdriere?

... or wiping out the old jail(s) and recreating?

I haven't reinstalled poudriere but I nuked all the jails, and started with a fresh one 14.3, same as host

Did you build poudriere from ports or did you just install via pkg?

bulk -vv gives plenty of output in the prep stage, but nothing before, or after the "unhandled error"

its from pkg

Can you paste the exact error somewhere, please?

Also, how are you creating the jails?

with `poudriere jail -c -j name -v release`

What command(s) are you running when the unhandled error appears?

poudriere bulk -f /usr/local/etc/poudriere.d/ports.list -j 143R -v

tried -vv, but nothing

Hrm. This looks almost like it might be a problem with pkg in the jail.

I do recall hearing about issues with the way pkg repo data was being fetched by poudriere.

hm. I've set it to fetch all the dependencies that I don't care about changing options

And why is it installing pkg on each run? Shouldn't it be done just once?

That's why I'm wondering if this is a pkg issue.

What version of poudriere is it?

lemme check

3.4.3

Maybe I should uninstall it and try poudriere-devel in its place

I would suggest that. I'm using -devel.

Ok, thanks, will give it a go. Should work with same config?

I'll check the diff

Can you paste your poudriere.conf (only the useful stuff. Maybe: cat /usr/local/etc/poudriere.conf | grep "^[a-zA-Z0-9+]" )

It should work with the same config, but you might be missing some additional config options in the -devel version. So, yep, I'd check the diff against the new config sample file.

Here's the current conf: bpa.st/F3KQ

Need to check against the new sample

maybe i'll nuke the ccache too

I don't see much of a difference in the config other than I'm using TMPFS.

And, not using TMPFS certainly should cause any problems.

s/should/should not/

It started building with pouriere-devel :) Same conf, haven't touched it

Wow, it's not fetching pkgs though, it's building them all..

Yeah. Conf looks good. I figured -devel would work. Non-devel might work too if you re-install it. Likely just a missing or updated lib somewhere or something.

divlamir: Yeah. That's the pkg thing I was talking about earlier.

I believe it has to do with the way things are being renamed as well as the way pkg handles something differently now? I wish I could find the link.

So it's a noop? It will build everything even if I tell it to just fetch it?

It's gonna get sweaty in the room :D

Anyway, thanks for your help, it's building again :)

geez, 95 degrees, need to repaste this thing

There is a patch (sort of). What does "pkg repos" say?

on the host, or in jail?

Host.

Ah! Found it: forums.freebsd.org/threads/poudrier…8-prefetching-binary-packages.80637

That links to the poudriere Github "patch" as well. Not sure if it'll fix your issue(s), but it might.

On host: bpa.st/ATYA

Wait. That might be the wrong one. Lemme check.

... not your paste, but the link I provided.

Here's the issue report for your first reported problem (unhandled error): freebsd/poudriere #1238

No, the link seems good, I am looking into it

No, no. It was just the wrong issue.

In fact, the second link I just sent is covering exactly everything we're talking about right now.

Yesss, it's because of the new kmods repo...

non-devel gets unhandled error, -devel won't fetch packages.

Yeah.

Thanks, all clear now

Should be fixed in 3.4.4

Subscribing to the issue

Or I might just revert that commit locally and live with the warning in the daily mail

Yeah. With any luck, that fetching issue will be fixed. They did have a little patch to basically manually add the exact repo to use. I think that worked for some, but not all.

Actually, can you try reverting the commit mentioned in the thread to see if it works?

Yeah, I can try that

Pretty simple. Edit /usr/local/share/poudriere/common.sh and on line 4505 change "${pkg_bin} update -f -r FreeBSD; then" to "${pkg_bin} update -f; then"

Then, just re-run your poudriere bulk command see if it fetches.

Yep, setting up a new jail

No need for a new jail or anything (I wouldn't think.) Just re-running poudriere with the new common.sh in place should be fine.

Patience, flakey LTE here

I'm not going anywhere.

Well, it won't build anything beacause all is up to date there

Ah. I gotcha'. I thought you had just started fresh. I figured it was still building your previous bulk run.

Ah, it's still building everything from scratch, even with that line reverted

Bummer. I was hoping that would help.

Or is it...

It's too fast

Like I'd mentioned earlier, it appears to have worked for some, but not others.

Queued: 27 Inspected: 0 Ignored: 0 Built: 0 Failed: 0 Skipped: 0 Fetched: 0 Remaining: 27

0 Fetched.

No, it's a lie!!!

It didn't build python in 10s!!!

Of course, that *MAY* be because those 27 all have updates compared to repo version (doubtful, but possible.)

Something very fishy giong on, it says it's building but I don't beleive it.

Why not?

Cause it seems a bit to fast compared to, a wait... ccache

Yep, whatever, it's not fetching

It just hit the cache, that's ahy the speed differenve

Yeah. ccache will always be helpful.

Have to go, will look into this further later, thanx ek!

Sure thing.

to use lua in haproxy must I both use github.com/haproxytech/haproxy-lua-http and install haproxy-lua package?

kevans: so presumably when it gets MFC'd over to stable/15, and then the next twice-daily builds start up? at this point I'm back on 14 after all, though

would've stayed on 15 if drm-66 was an actual improvement, but if I'm stuck having to be careful to avoid GPU hangs, might as well stay on 14

I ended up discovering that drm-510 is not blocked on >=14.2 due to failure to compile, which really got my hopes up that I could just revert back to that, but it didn't actually work properly (also GPU hangs)

maybe I should finally get around to a bug report about the kernel panics that drm-515 causes, just to cast a wider net that *some* version of drm will become fully usable for me

tm512: it got an expedited MFC, but not quite in time to hit the build earlier today

tm512: Do you have steps to reproduce it? I have that loaded.

skered: have drm-61 or 66 loaded, start up firefox and use it for a while (open up various tabs, I suppose just get GPU resource consumption up?), and then try to go fullscreen playing a video with mpv

it's pretty finicky

or not finicky, but it's unclear exactly at what point the GPU is going to give up

when I was testing with 15 + drm-66 last night though, just going fullscreen in mpv on a fresh boot caused a hang

so far this seems to be happening with GCN 5 and GCN 5.1 iGPUs

so like APUs from 2018-2020

per abishai's latest comment, they claim it's not happening on this Zen2 system with some particular loader.conf tweaks applied. I've asked for clarification on what exact GPU that system is using, but if I wanted to try out those tweaks, could I expect them to have any performance consequences?

er I have 515 not 61.

I guess I can use 61 though.

Wonder if I can reproduce it with xrdp and DRI.

so for me, drm-515 does not have this issue, but I can't use it, because it kernel panics after a while