Re: Anybody seeing NextCloud crash?
On 15/11/2024 12:08, Alexander Leidinger wrote: Am 2024-11-15 11:14, schrieb Moin Rahman: Just for everyone else in the list, I have gone through some discussion with the original author of the mail and it seems to have some sort of regression with graphics/pecl-imagick. Whenever this php module is loaded php-fpm crashes on at least php82 and maybe later. This module actually may not support php82 and later. Or maybe there was some sort of new regression with some other commits down the line of ImageMagic. I can report that commenting out the imagick extension in LOCALBASE/etc/ php/ext-20-imagick.ini fixes the SIGILL I noticed after an pkg update (in my case I see it with www/piwigo). I am the maintainer of pecl-imagick port but I don't have pecl-imagick under PHP-FPM. I received similar report of crash few days ago privately (with PHP 8.3), but I really don't know what is going on here. There are some problems with recent updates of ImageMagick after which rebuild of pecl-imagick was required (revision bump needed). Can somebody of you test the rebuild of pecl-imagick from ports if it helps or not? Maybe another revision bump is required again. Kind regards Miroslav Lachman
Re: Anybody seeing NextCloud crash?
On 15/11/2024 17:06, Andriy Gapon wrote: On 15/11/2024 17:13, Miroslav Lachman wrote: On 15/11/2024 12:08, Alexander Leidinger wrote: Am 2024-11-15 11:14, schrieb Moin Rahman: Just for everyone else in the list, I have gone through some discussion with the original author of the mail and it seems to have some sort of regression with graphics/pecl-imagick. Whenever this php module is loaded php-fpm crashes on at least php82 and maybe later. This module actually may not support php82 and later. Or maybe there was some sort of new regression with some other commits down the line of ImageMagic. I can report that commenting out the imagick extension in LOCALBASE/ etc/ php/ ext-20-imagick.ini fixes the SIGILL I noticed after an pkg update (in my case I see it with www/piwigo). I am the maintainer of pecl-imagick port but I don't have pecl-imagick under PHP-FPM. I received similar report of crash few days ago privately (with PHP 8.3), but I really don't know what is going on here. There are some problems with recent updates of ImageMagick after which rebuild of pecl-imagick was required (revision bump needed). Can somebody of you test the rebuild of pecl-imagick from ports if it helps or not? Maybe another revision bump is required again. Miroslav, did you notice https://cgit.freebsd.org/ports/commit/? id=1876b07e4fcf269a1c57ac401ab57e4337bcf465 ? No I didn't. Thank you. Did somebody tried if it fixrs the crashes of PHP with Nextcloud? Kind regards Miroslav Lachman
Re: Anybody seeing NextCloud crash?
> On Nov 14, 2024, at 13:29, Ronald Klop wrote: > > Op 04-11-2024 om 05:39 schreef Kevin P. Neal: >> I'm seeing a problem with NextCloud's php-fpm instance crashes when trying >> to handle a request over the web interface. My web server is Apache 2.4 >> if it matters. The MacOS desktop sync client works just fine, and so does >> the app from iOS 16 (I have an iPhone 8 that I'm upgrading soon). >> Apache responds with a "Service Unavailable" error page. >> In my /var/log/php-fpm.log I find this: >> [03-Nov-2024 11:06:45] WARNING: [pool www] child 68236 exited on signal 4 >> (SIGILL) after 5.975134 seconds from start > > > SIGILL means that an instruction was executed that was not understood by the > CPU. > This can be something like the software using SSE2 instructions and your CPU > does not support that. > > I'm not sure if there are other reasons for SIGILL. > > It helps if you could share what FreeBSD version your are running and on what > architecture. > > The output of 'uname -a' gives this. > > /var/run/dmesg.boot gives information about your CPU. This helps in > determining the supported instructions. > Mine gives this: > CPU: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz (2400.14-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x406e3 Family=0x6 Model=0x4e Stepping=3 > > Features=0x1783fbff > > Features2=0xdeda2203 > AMD Features=0x28100800 > AMD Features2=0x121 > Structured Extended > Features=0x842421 > Structured Extended Features3=0x1400 > TSC: P-state invariant > > If php-fpm gives a core dump it is also possible to analyze on what > instruction it is failing. I don't know the command on how to do that by the > top of my head. Maybe somebody else can help. > > If you can find out what package update resulted in the crash then you could > ask the package maintainer to compile it for older CPUs by default. > > Regards, > Ronald. > > > > >> Every time I tried to reload a page on the web site I get a failure like >> that one. The php-fpm processes are dying. >> I use the checkrestart package after every pkg upgrade and I restart >> anything that gets mentioned. This handy utility isn't foolproof, but >> I've had good luck with it. >> Reinstalling all my packages with pkg upgrade -f changed nothing. >> I rolled back my ZFS dataset to October 30's, rebooted (needed, don't know >> why), and I have it back up and running now. >> I did "service php_fpm restart" after the bad update, but I forgot to check >> that everything was still working. That's why I had to rollback so far -- >> I have SMS messages on my phone that imply it was working on that date. >> The problem was introduced with one of these updates: >> The following 11 package(s) will be affected (of 0 checked): >> New packages to be INSTALLED: >> openh264: 2.3.0,2 >> openjph: 0.17.0 >> Installed packages to be UPGRADED: >> ffmpeg: 6.1.2_4,1 -> 6.1.2_5,1 >> glib: 2.80.5,2 -> 2.80.5_1,2 >> libheif: 1.18.2_1 -> 1.19.1 >> libnghttp2: 1.63.0 -> 1.64.0 >> libssh2: 1.11.0_1,3 -> 1.11.1,3 >> libvpx: 1.14.1 -> 1.15.0 >> pciids: 20240920 -> 20241024 >> py311-redis: 5.1.1 -> 5.2.0 >> svt-av1: 2.2.0 -> 2.3.0 >> Number of packages to be installed: 2 >> Number of packages to be upgraded: 9 >> I do have my own poudriere setup, but I don't think I have any custom >> settings at this point. I can doublecheck if anyone is curious, though. >> Anyone else seen this? Or should I file a bug report? > > Just for everyone else in the list, I have gone through some discussion with the original author of the mail and it seems to have some sort of regression with graphics/pecl-imagick. Whenever this php module is loaded php-fpm crashes on at least php82 and maybe later. This module actually may not support php82 and later. Or maybe there was some sort of new regression with some other commits down the line of ImageMagic. Kind regards, Moin signature.asc Description: Message signed with OpenPGP
Re: security/gnutls: gnutls-3.8.8 requires llvm17 or higher to build
On 15 Nov 2024, at 04:54, Tatsuki Makino wrote: > > Hello. > > It seems that it is mandatory to use llvm17 or higher to build gnutls 3.8.8. > If not, the following error cannot be resolved. Changing -std=c11 is > powerless. > > groups.c:93:2: error: initializer element is not a compile-time constant >group_x25519, >^~~~ > > If you are still stuck with the old version, make a modification that uses 17 > or higher of clang 🤣 When you must use an old version, you could add this as a patch for groups.c. It could be conditionalized on COMPILER_VERSION < 17. -Dimitry patch-lib_algorithms_groups.c Description: Binary data
ampere1 crashed?
Hi, Server Ampere1 seems to have stopped. https://pkg-status.freebsd.org/ampere1/build.html?mastername=141releng-armv7-quarterly&build=2e2d801cf977 This log might give a hint: https://pkg-status.freebsd.org/ampere1/data/141releng-armv7-quarterly/2e2d801cf977/logs/lmfit-9.0.log =>> Building math/lmfit make: chdir /usr/ports/math/lmfit: No such file or directory Regards, Ronald.
Re: Anybody seeing NextCloud crash?
Am 2024-11-15 11:14, schrieb Moin Rahman: Just for everyone else in the list, I have gone through some discussion with the original author of the mail and it seems to have some sort of regression with graphics/pecl-imagick. Whenever this php module is loaded php-fpm crashes on at least php82 and maybe later. This module actually may not support php82 and later. Or maybe there was some sort of new regression with some other commits down the line of ImageMagic. I can report that commenting out the imagick extension in LOCALBASE/etc/php/ext-20-imagick.ini fixes the SIGILL I noticed after an pkg update (in my case I see it with www/piwigo). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: lang/rust/Makefile for 1.82.0 has wrong llvm:min= value [I got that incorrect]; more
Mark Millard wrote: On Nov 14, 2024, at 19:30, Tatsuki Makino wrote: Since option PORT_LLVM is not turned on in the official version, it seems that there is no problem with using of the bundle llvm. However, if we want to use llvm instead of a bundle on an architecture where the compiler causes problems, that version is no longer supported and we need to rewrite the version number there. … Is that what you mean? :) When I got into this area it was because someone on discord was getting errors like: ld.lld: error: ../../../x86_64-unknown-freebsd/release/libgkrust.a(ews_xpcom-da5573b2cf91b84e.ews_xpcom.c68a27d7391ba4aa-cgu.0.rcgu.o): Unknown attribute kind (91) (Producer: 'LLVM19.1.1-rust-1.82.0-stable' Reader: 'LLVM 17.0.6') clang++: error: linker command failed with exit code 1 (use -v to see invocation) This looks like an LTO interaction between two different LLVM bitcode versions, which along with the rest of LLVM, do not guarantee compatibility. It goes without saying that the LTO option in gecko@ ports should only be enabled when the LLVM version matches across the clang (gecko@ ports force devel/llvm*) and Rust bits. With LTO disabled this is moot. -- Charlie Li ...nope, still don't have an exit line. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Anybody seeing NextCloud crash?
On 15/11/2024 17:13, Miroslav Lachman wrote: On 15/11/2024 12:08, Alexander Leidinger wrote: Am 2024-11-15 11:14, schrieb Moin Rahman: Just for everyone else in the list, I have gone through some discussion with the original author of the mail and it seems to have some sort of regression with graphics/pecl-imagick. Whenever this php module is loaded php-fpm crashes on at least php82 and maybe later. This module actually may not support php82 and later. Or maybe there was some sort of new regression with some other commits down the line of ImageMagic. I can report that commenting out the imagick extension in LOCALBASE/etc/ php/ ext-20-imagick.ini fixes the SIGILL I noticed after an pkg update (in my case I see it with www/piwigo). I am the maintainer of pecl-imagick port but I don't have pecl-imagick under PHP-FPM. I received similar report of crash few days ago privately (with PHP 8.3), but I really don't know what is going on here. There are some problems with recent updates of ImageMagick after which rebuild of pecl-imagick was required (revision bump needed). Can somebody of you test the rebuild of pecl-imagick from ports if it helps or not? Maybe another revision bump is required again. Miroslav, did you notice https://cgit.freebsd.org/ports/commit/?id=1876b07e4fcf269a1c57ac401ab57e4337bcf465 ? -- Andriy Gapon
Unmaintained FreeBSD ports which are out of date
Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ net/corosync3 | 3.1.8 | 3.1.9 +-+ sysutils/google-compute-engine-oslogin | 20191018.00 | 20241116.00 +-+ sysutils/mcelog | 178 | v201 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout!
