When can we expect a package for php 8.4.27?

CrtxReavr: which branch/arch/release?

these are still going

14.4-RELEASE-p4

amd64

we need poudriere/pkgs/ports architectural improvements to speed this all up

which is hard to do as a volunteer

yes it is.

But now with IA might speed it up. dont you think?

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.

AI code audits are causing a firestorm.

switching these now to php-only might take 3-4 hours to build instead and be worth putting out the fire

Then will come the AI code audits of AI-vibed "fixes."

but then the current builds will have to start over as this version of poudriere isn't doing resume correctly

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.

I personally don't rely on much PHP. . . I currently have all my php scripts chmod'd 600.

bdrewery, this web page is mesmerizing.

Swift has been building for 17.25 hours. . .

When your programming language is too complex.

crazy question, but in a situation like this, what prevents manual intervention?

Meaning, php builds in minutes, what stops someone from building it... somewhere trusted and putting that pkg into the actual repo?

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...

glad i don't work at a php shop this week

or ever, really, but especially this week

I use a couple apps personally, but nothing critical. . . just waiting on the updated packages.

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.

If it wasn't clear I'm the one driving the freebsd.org builds this week. Doing what I can to get them done.

chromium and electron are the biggest problems here and I can't wrap my head around how to solve it going forward.

Anyone know when the php security fixes will be available?

mcrane: these are the remaining builds (excluding 16-CURRENT):

16-CURRENT is at pkg-status.freebsd.org/beefy24/buil…ult&build=pccd47a9adb03_sda04cf02c9

bdrewery: does that meant is likely to be available in the next 12 to 24 hours?

mean...

yes

+1

Thanks I appreciate it

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.

we can't simply build _just php_ due to how the pkg dependencies work, inability to have multiple versions of dependencies installed

I want to get the update on my website

yeah I can imagine how annoying it is to have sites down waiting on this

I had mine shutdown for 12 hours waiting for the port to be updated and built my own packages from it

the port was updated fast at least

yes that is good

bdrewery: how long does a build world usually take on these servers?

I'm understanding it better now reading the links that were shared

mcrane: buildworld, not sure as it is doing incremental. Last one: >>> World built in 92 seconds, ncpu: 96, make -j96

what state is `connec'? connect?

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?

LxGHTNxNG: define "remote chance". IMHO, if the GPU is forwarded exclusive, why not? also: "work again"? whats the problem?

if i was to reboot the vm

would it be able to use the gpu after rebooting or is that borked

this depends on a lot of unknown factors

right

i guess the only way to find out is to try it.

i hate the idea of having to debug hardware i have roughly zero visibility into

Hello #FreeBSD =]

Why is there no PHP 8.3.36 for 15.1-RELEASE-p5, but it exists for 14.3-RELEASE-p16 ?

i guess its because of build foo. but idk, i asked if there are logs accesible for build foo in #pkg

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.

i moved all php foo to wireguard(VPN) only (on debian though). if this is an option you could do it

i followed docs.freebsd.org/en/books/handbook/…s/#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:...

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

THIMC: wiki.freebsd.org/IRC/Channels i just received several 503 bad gw errors. its working now

trying to build with DISABLE_VULN=yes rn. seems to be working (not done yet_

s/et_/et)/

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

it seems to be waking up but the screen won't turn on

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. :)

specifically just updated packages, not the base system or DRM drivers

tm512: i don't know which specifically src, but did u have a look at logs in /var/log?

s/src/sry/

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

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

meh, I hope this isn't a hardware issue

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?

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

it's pretty annoying

.oO(building php83 on a vm in virtualbox feels like installing gentoo on a rapsberry pi)

to exclude hw issues i suggest booting some live os

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

memtest86

I feel like I'd notice more than the machine failing to resume from suspend if I had faulty RAM in here though

tm512: I agree with qoreQyaS. Boot Mint from memstick and test to see if its hardware.

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

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

linux is not a remotely serious workstation OS...

.oO(its only about testing hw, relax :p )

AFAIK Linux is actually the by-far-most-common OS for HPC workstations :-)

a million flies...

qoreQyaS: services under freebsd.org domain have lately had recurring issues

seemed like something to do with load balancing breaking TLS, but I didn't bother looking more closely