00:26:57 When can we expect a package for php 8.4.27? 00:43:03 CrtxReavr: which branch/arch/release? 00:44:39 https://pkg-status.freebsd.org/beefy22/build.html?mastername=144amd64-default&build=ccd47a9adb03 00:44:44 https://pkg-status.freebsd.org/beefy21/build.html?mastername=151amd64-quarterly&build=20261022_f655baf70388 00:44:52 these are still going 00:44:59 14.4-RELEASE-p4 00:45:04 amd64 00:45:55 we need poudriere/pkgs/ports architectural improvements to speed this all up 00:46:59 which is hard to do as a volunteer 00:48:50 yes it is. 00:49:15 But now with IA might speed it up. dont you think? 00:49:41 I made a poor call on 144amd64-default and 151amd64-quarterly. I should have done the php-only build first but I skipped them as other security fixes were piling up and these sets were already behind. At the rate they are going it could be another 12 hours. 00:50:15 AI code audits are causing a firestorm. 00:50:36 switching these now to php-only might take 3-4 hours to build instead and be worth putting out the fire 00:50:51 Then will come the AI code audits of AI-vibed "fixes." 00:51:06 but then the current builds will have to start over as this version of poudriere isn't doing resume correctly 00:51:54 I do think AI could help fix some of the resource scheduling problems with poudriere but it won't fix the problems with packages/ports metadata. We would still need to rebuild excessively. 00:51:56 I personally don't rely on much PHP. . . I currently have all my php scripts chmod'd 600. 01:22:15 bdrewery, this web page is mesmerizing. 01:22:25 Swift has been building for 17.25 hours. . . 01:22:41 When your programming language is too complex. 01:54:57 crazy question, but in a situation like this, what prevents manual intervention? 01:55:49 Meaning, php builds in minutes, what stops someone from building it... somewhere trusted and putting that pkg into the actual repo? 01:56:46 Also kind of interesting to see the number of people here and elsewhere noting they don't use much PHP, but man outside the "professional developer" bubble, it is really everywhere... 02:13:34 glad i don't work at a php shop this week 02:13:50 or ever, really, but especially this week 02:16:36 I use a couple apps personally, but nothing critical. . . just waiting on the updated packages. 03:40:17 spork_css_: I did do that exact thing for some of the builds yesterday. It still took 3-8 hours due to how the dependencies work. I opted to not do it for these 2 builds still going as they were still on the Monday build and falling too far behind. Probably a mistake. 03:41:00 If it wasn't clear I'm the one driving the freebsd.org builds this week. Doing what I can to get them done. 03:41:55 chromium and electron are the biggest problems here and I can't wrap my head around how to solve it going forward. 03:42:16 Anyone know when the php security fixes will be available? 03:42:38 mcrane: these are the remaining builds (excluding 16-CURRENT): 03:42:38 https://pkg-status.freebsd.org/beefy21/build.html?mastername=151amd64-quarterly&build=20261022_f655baf70388 03:42:42 https://pkg-status.freebsd.org/beefy22/build.html?mastername=144amd64-default&build=ccd47a9adb03 03:43:06 16-CURRENT is at https://pkg-status.freebsd.org/beefy24/build.html?mastername=main-amd64-default&build=pccd47a9adb03_sda04cf02c9 03:43:58 bdrewery: does that meant is likely to be available in the next 12 to 24 hours? 03:44:05 mean... 03:44:30 yes 03:44:37 +1 03:44:43 Thanks I appreciate it 03:45:08 funny thing is I'm of the mind that the package should have been available within an hour of the patch being released. Too many ports to deal with. 03:45:43 we can't simply build _just php_ due to how the pkg dependencies work, inability to have multiple versions of dependencies installed 03:45:43 I want to get the update on my website 03:45:59 yeah I can imagine how annoying it is to have sites down waiting on this 03:46:17 I had mine shutdown for 12 hours waiting for the port to be updated and built my own packages from it 03:46:25 the port was updated fast at least 03:46:37 yes that is good 03:53:21 bdrewery: how long does a build world usually take on these servers? 03:58:28 I'm understanding it better now reading the links that were shared 04:06:10 mcrane: buildworld, not sure as it is doing incremental. Last one: >>> World built in 92 seconds, ncpu: 96, make -j96 04:34:29 what state is `connec'? connect? 05:15:05 i'm not stupid enough to think what i want to do has a remote chance of working: if i forward a GPU to a VM, can the VM be rebooted and the driver reloaded and have the GPU work again a second time? 05:17:19 LxGHTNxNG: define "remote chance". IMHO, if the GPU is forwarded exclusive, why not? also: "work again"? whats the problem? 05:27:11 if i was to reboot the vm 05:27:43 would it be able to use the gpu after rebooting or is that borked 05:28:32 this depends on a lot of unknown factors 05:37:14 right 05:37:29 i guess the only way to find out is to try it. 05:43:09 i hate the idea of having to debug hardware i have roughly zero visibility into 06:11:45 Hello #FreeBSD =] 06:11:45 Why is there no PHP 8.3.36 for 15.1-RELEASE-p5, but it exists for 14.3-RELEASE-p16 ? 06:32:53 i guess its because of build foo. but idk, i asked if there are logs accesible for build foo in #pkg 06:38:30 Do I wait for a patch for 15.1, or rollback to 14.3 ? I want to patch this PHP thing before it ruins my weekend. 06:39:24 i moved all php foo to wireguard(VPN) only (on debian though). if this is an option you could do it 06:48:26 i followed https://docs.freebsd.org/en/books/handbook/ports/#ports-using-installation-methods and try to build the port. its trying to build 8.3.36. error: py312-setuptools-63.1.0_3 has known vulns:... 06:50:27 at least my important stuff runs on 14.3. I only upgraded an internal machine to 15.1 as a test, so I might be OK. Thanks qoreQyaS 06:55:34 THIMC: https://wiki.freebsd.org/IRC/Channels i just received several 503 bad gw errors. its working now 06:58:20 trying to build with DISABLE_VULN=yes rn. seems to be working (not done yet_ 06:58:32 s/et_/et)/ 06:59:31 recently been noticing an issue where my laptop won't resume from suspend properly, seemingly at random, after running package updates a few days ago 06:59:59 it seems to be waking up but the screen won't turn on 07:01:03 tm512: How is it to run freebsd on a laptop? I last tried that over 5 years ago. The print spooler kept dying so I moved to Mint. Still on Mint. :) 07:01:14 specifically just updated packages, not the base system or DRM drivers 07:01:49 tm512: i don't know which specifically src, but did u have a look at logs in /var/log? 07:01:55 s/src/sry/ 07:02:10 netbilly: it's generally okay. the issues I have run into have been with wifi and GPU drivers which isn't specifically a laptop thing 07:04:29 qoreQyaS: I'm not seeing any signs that the OS actually tried to resume from suspend in /var/log/messages. the next thing after the suspend message is the kernel boot messages 07:04:49 meh, I hope this isn't a hardware issue 07:06:41 hmmm... what happens exactly? you put pc into suspend. then it seems to be in suspend (LED status of hw/power consumption PSU). when u switch it back on it boots direclty into bios->bootloader->fbsd? 07:07:43 it suspends normally, but when it tries to resume, like half of the time the fans just spin up but the screen doesn't come back on. I have to force power off and reboot 07:07:55 it's pretty annoying 07:07:59 .oO(building php83 on a vm in virtualbox feels like installing gentoo on a rapsberry pi) 07:08:44 to exclude hw issues i suggest booting some live os 07:10:18 I hope it's not a RAM issue. setting aside the issue with RAM prices, the majority of the RAM in this machine is soldered to the mobo 07:11:15 memtest86 07:11:36 I feel like I'd notice more than the machine failing to resume from suspend if I had faulty RAM in here though 07:11:44 tm512: I agree with qoreQyaS. Boot Mint from memstick and test to see if its hardware. 07:16:32 yeah, I could try Linux. I've got a ventoy drive laying around that should have a Void Linux liveUSB image on it. it's gonna have to wait until the next time I'm forced to shutdown though 07:17:25 I might also make sure my UEFI is fully up to date in case there's some ACPI bug that's only now getting triggered for some reason 07:17:51 linux is not a remotely serious workstation OS... 07:19:42 .oO(its only about testing hw, relax :p ) 07:22:44 AFAIK Linux is actually the by-far-most-common OS for HPC workstations :-) 07:23:10 a million flies... 08:22:46 qoreQyaS: services under freebsd.org domain have lately had recurring issues 08:24:09 seemed like something to do with load balancing breaking TLS, but I didn't bother looking more closely