00:19:15 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 00:20:31 it kinda seems like the pkgbase builds for 15 broke as soon as it was forked off to stable/15 with main becoming 16 00:22:26 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? 00:28:31 would be nice to see if the build issues with drm-66 is something that has been fixed since this sept 4th pkgbase snapshot 00:35:41 tm512: i poked internally about stable/15 there 00:36:44 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 00:39:13 (and they're indeed not published at all on pkg-status.f.o) 00:40:31 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 00:41:45 I am baffled what could go wrong. my vnode.h matches what's in stable/15, yet it's still throwing compiler errors 00:45:05 "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 00:45:11 but it's just not 00:45:38 tm512: vnode.h isn't the problem, a file generated during the build is 00:46:01 in fact, I'm not seeing any definition of vop_inotify_args anywhere in the /usr/src tree I've got locally on 15 00:47:05 tm512: does your sys/kern/vnode_if.src have vop_inotify? 00:47:59 yeah, starting on line 830 00:48:34 sha256 of vnode_if.src is 009932d2f1d6813181e78b16590cd03a4afcdd886b12ff5e0f131b3002d68982 00:49:02 and this was a clean build of drm-kmod to start with, right? 00:49:12 .oO(is the machine haunted?) 00:49:43 is this in poudriere or not in poudriere? what does `which awk` look like? 00:49:55 presumably 'not in' 00:49:56 * rwp once had a system where over a short period of time every part of the system was changed except for the hostname. I think the hostname was cursed. 00:51:50 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 00:52:47 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 00:53:05 well, you could also `bectl jail` the BE 00:53:10 but it doesn't matter, yeah 00:53:30 I figured I couldn't jail since I'm on a 14 kernel 00:53:31 oh, 14 -> 15 00:53:59 sorry, trying to spit out as much as I can before I have to go wrestle damn-near-2yo into bed 00:54:20 i'd be interested in seeing what the generated vnode_if.h looks like if you can reproduce the failure 00:55:02 where would I find vnode_if.h? 00:55:41 *should* be in dmabuf/ inside the work tree, iirc 00:57:17 theret's probably more than one, it'd maybe also be interesting to know if they're all identical 00:57:28 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 00:57:35 so bbiab 00:59:34 booted into 15 now 01:00:09 fwiw, awk is version 20250804 (and is indeed /usr/bin/awk) 01:01:49 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 " and "could not parse commit " but then a second invocation succeeds 01:03:29 it's not erroring this time. +1 for the machine being haunted 01:03:38 i think you found a build race, actually 01:04:36 https://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 01:05:15 oh hmm. the kmod build does as well, indirectly: https://cgit.freebsd.org/src/tree/sys/conf/kmod.mk#n565 01:05:42 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 01:06:45 kevans_: and that kmod.mk applies to kmods built from the ports tree? 01:06:46 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 01:06:49 yeah 01:07:04 e.g., dmabuf/Makefile includes 01:08:52 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 01:09:15 the package for 15 is 142.0, whereas I was using 143 on 14 01:13:40 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 01:14:17 but just pkg upgrade on its own, reports "your packages are up to date" 01:22:02 https://termbin.com/6kl1 anyone know why a general pkg upgrade wouldn't see these? it clearly claims to be checking the FreeBSD-ports repo 01:24:32 maybe the fact that my firmware kmods are all outdated is why drm-61 was panicking on boot 01:29:09 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 01:32:46 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 01:35:46 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 01:35:59 I've been burned by forcing a profile downgrade in the past 01:36:22 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 01:36:27 brb 01:42:01 tm512: the pkgbase for 15 availability thing is a bug in the automation; should be fixed within a few days or so 01:43:56 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) 01:45:20 hmm, so likelihood that Firefox will still work if I install the 143.0 package for 14 here on 15? 01:52:49 tm512: you need compat14x package at least 01:53:25 feels like dep hell tho 01:56:15 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 01:57:41 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 01:59:56 here on 15 it feels like the defaults for trackpoint and trackpad sensitivity has been cranked up? 02:14:53 so installing compat14x, and then doing add -f on the cached 143.0,2 package, appears to have worked 02:17:37 right on 02:17:42 eventually package builds will stabilize 02:18:17 oh, I guess the 143 update was only committed on September 8th 02:20:59 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 02:22:32 it will reach eventual consistency between versions, at least 02:22:53 the builders just build in a loop completely disconnected from each other, bulk -a to build everything incrementally from the last update 02:23:44 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 02:24:43 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 02:25:08 assuming I stay on 15 anyway. going to have to test the GPU hang issue 02:44:37 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 02:45:58 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 02:48:45 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? 02:54:26 so the GPU hang issue is even worse on drm-66. just going fullscreen with mpv, even without firefox open, causes a hang 04:12:59 tm512: no, I was referring to /usr/src checkout 04:16:41 it wasn't a checkout, it was populated by the FreeBSD-src{,-sys} packages, after completely nuking everything under /usr/src 04:17:50 but whatever, I couldn't reproduce the build failure today 04:18:08 neat, you fixed that 04:19:17 it was all (mostly) for naught, since drm-66 is even worse than 61 04:19:44 https://github.com/freebsd/drm-kmod/issues/366#issuecomment-3283476809 04:20:34 all I really got out of this was another data point, that it's not limited to 14 + drm-61 04:23:36 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 04:26:07 not sure what else 15 has to offer that I actually care about. is 802.11ac support on 15 better? 04:26:53 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 04:41:45 tm512: how long have you been using FreeBSD ? 04:49:11 I am only asking, because I see that you are very enthusiastic about FreeBSD 11:58:02 mzar: Most people who use FreeBSD are fairly enthusiastic about it 11:58:14 that's great 1 11:58:20 ld-elf.so.1: Shared object "libutil.so.9" not found, required by "env" 11:58:48 why I need compat14x-amd64 to build world on stable/15 ? 12:03:42 nevermind, it was unclean environment, leftovers from building stable/15 from stable/14 13:09:33 So which is the #BSD which perormance getting WORSE running in KVM not better over time? 13:09:48 Of course OpenBSD� 13:09:48 Of course OpenBSD�� 13:09:48 Of course OpenBSD�� 13:09:48 Of course OpenBSD� 13:30:26 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? 13:31:34 <[tj]> this isn't really the place for discussion of openbsd 13:32:07 Not that FreeBSD is great for that either. 13:33:04 <[tj]> for continuous performance measurements? 13:33:29 <[tj]> we have public ci, but performance measurements are very difficult to do this way 13:33:43 <[tj]> vpp does a great job of it by employing a team of people to manage the process 13:51:53 no, stuff like pmcstat 15:57:28 tm512: it is believe that https://cgit.freebsd.org/src/commit/?id=c8a4d636af8ac360ce6329c4a029dd8934d904de will fix the package availability Soon(TM) 15:57:32 believed 17:05:20 poudriere stopped working, unhandled error, whatever that means... 17:07:53 Is ports-mgmt/synth still a thing? I've never tried it, not sure if it's still maintained 17:13:02 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 17:20:54 divlamir: Have you tried re-building/re-installing pourdriere? 17:21:06 ... or wiping out the old jail(s) and recreating? 17:21:48 I haven't reinstalled poudriere but I nuked all the jails, and started with a fresh one 14.3, same as host 17:22:42 Did you build poudriere from ports or did you just install via pkg? 17:22:56 bulk -vv gives plenty of output in the prep stage, but nothing before, or after the "unhandled error" 17:23:06 its from pkg 17:23:29 Can you paste the exact error somewhere, please? 17:23:37 Also, how are you creating the jails? 17:25:18 with `poudriere jail -c -j name -v release` 17:25:25 https://bpa.st/7O4Q 17:25:50 What command(s) are you running when the unhandled error appears? 17:26:17 poudriere bulk -f /usr/local/etc/poudriere.d/ports.list -j 143R -v 17:26:36 tried -vv, but nothing 17:28:06 Hrm. This looks almost like it might be a problem with pkg in the jail. 17:28:27 I do recall hearing about issues with the way pkg repo data was being fetched by poudriere. 17:28:35 hm. I've set it to fetch all the dependencies that I don't care about changing options 17:29:21 And why is it installing pkg on each run? Shouldn't it be done just once? 17:30:19 That's why I'm wondering if this is a pkg issue. 17:30:25 What version of poudriere is it? 17:30:32 lemme check 17:30:46 3.4.3 17:31:14 Maybe I should uninstall it and try poudriere-devel in its place 17:32:58 I would suggest that. I'm using -devel. 17:33:24 Ok, thanks, will give it a go. Should work with same config? 17:33:29 I'll check the diff 17:33:36 Can you paste your poudriere.conf (only the useful stuff. Maybe: cat /usr/local/etc/poudriere.conf | grep "^[a-zA-Z0-9+]" ) 17:34:23 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. 17:36:30 Here's the current conf: https://bpa.st/F3KQ 17:36:41 Need to check against the new sample 17:37:13 maybe i'll nuke the ccache too 17:43:21 I don't see much of a difference in the config other than I'm using TMPFS. 17:43:47 And, not using TMPFS certainly should cause any problems. 17:43:56 s/should/should not/ 17:44:42 It started building with pouriere-devel :) Same conf, haven't touched it 17:45:08 Wow, it's not fetching pkgs though, it's building them all.. 17:45:23 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. 17:45:48 divlamir: Yeah. That's the pkg thing I was talking about earlier. 17:46:19 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. 17:46:58 So it's a noop? It will build everything even if I tell it to just fetch it? 17:47:32 It's gonna get sweaty in the room :D 17:50:06 Anyway, thanks for your help, it's building again :) 17:51:09 geez, 95 degrees, need to repaste this thing 17:51:27 There is a patch (sort of). What does "pkg repos" say? 17:51:43 on the host, or in jail? 17:52:36 Host. 17:52:39 Ah! Found it: https://forums.freebsd.org/threads/poudriere-bulk-8-prefetching-binary-packages.80637/ 17:53:01 That links to the poudriere Github "patch" as well. Not sure if it'll fix your issue(s), but it might. 17:54:04 On host: https://bpa.st/ATYA 17:54:22 Wait. That might be the wrong one. Lemme check. 17:54:35 ... not your paste, but the link I provided. 17:55:38 Here's the issue report for your first reported problem (unhandled error): https://github.com/freebsd/poudriere/issues/1238 17:55:40 No, the link seems good, I am looking into it 17:56:20 No, no. It was just the wrong issue. 17:56:34 In fact, the second link I just sent is covering exactly everything we're talking about right now. 17:56:48 Yesss, it's because of the new kmods repo... 17:56:50 non-devel gets unhandled error, -devel won't fetch packages. 17:56:55 Yeah. 17:57:58 Thanks, all clear now 17:58:10 Should be fixed in 3.4.4 17:59:13 Subscribing to the issue 18:02:23 Or I might just revert that commit locally and live with the warning in the daily mail 18:08:00 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. 18:12:08 Actually, can you try reverting the commit mentioned in the thread to see if it works? 18:13:24 Yeah, I can try that 18:14:20 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" 18:14:36 Then, just re-run your poudriere bulk command see if it fetches. 18:15:25 Yep, setting up a new jail 18:15:57 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. 18:15:59 Patience, flakey LTE here 18:16:32 I'm not going anywhere. 18:16:38 Well, it won't build anything beacause all is up to date there 18:17:34 Ah. I gotcha'. I thought you had just started fresh. I figured it was still building your previous bulk run. 18:18:47 Ah, it's still building everything from scratch, even with that line reverted 18:19:06 Bummer. I was hoping that would help. 18:19:15 Or is it... 18:19:24 It's too fast 18:19:28 Like I'd mentioned earlier, it appears to have worked for some, but not others. 18:19:44 Queued: 27 Inspected: 0 Ignored: 0 Built: 0 Failed: 0 Skipped: 0 Fetched: 0 Remaining: 27 18:20:00 0 Fetched. 18:20:23 No, it's a lie!!! 18:20:34 It didn't build python in 10s!!! 18:20:55 Of course, that *MAY* be because those 27 all have updates compared to repo version (doubtful, but possible.) 18:21:36 Something very fishy giong on, it says it's building but I don't beleive it. 18:22:04 Why not? 18:22:30 Cause it seems a bit to fast compared to, a wait... ccache 18:22:52 Yep, whatever, it's not fetching 18:23:22 It just hit the cache, that's ahy the speed differenve 18:24:31 Yeah. ccache will always be helpful. 18:26:26 Have to go, will look into this further later, thanx ek! 18:26:42 Sure thing. 20:00:21 to use lua in haproxy must I both use https://github.com/haproxytech/haproxy-lua-http and install haproxy-lua package? 20:40:41 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 20:43:19 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 20:44:57 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) 20:46:07 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 20:48:57 tm512: it got an expedited MFC, but not quite in time to hit the build earlier today 23:42:10 tm512: Do you have steps to reproduce it? I have that loaded. 23:51:45 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 23:51:51 it's pretty finicky 23:52:24 or not finicky, but it's unclear exactly at what point the GPU is going to give up 23:52:55 when I was testing with 15 + drm-66 last night though, just going fullscreen in mpv on a fresh boot caused a hang 23:53:21 so far this seems to be happening with GCN 5 and GCN 5.1 iGPUs 23:53:48 so like APUs from 2018-2020 23:54:14 https://github.com/freebsd/drm-kmod/issues/366 23:55:48 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? 23:56:51 er I have 515 not 61. 23:57:16 I guess I can use 61 though. 23:58:09 Wonder if I can reproduce it with xrdp and DRI. 23:59:51 so for me, drm-515 does not have this issue, but I can't use it, because it kernel panics after a while