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 +-+ devel/ocaml-cfg | 2.2.0 | 2.3.1 +-+ graphics/py-ueberzug| 18.1.8 | 18.3.1 +-+ multimedia/gmmlib | 22.3.18 | intel-gmmlib-22.5.4 +-+ www/tikiwiki| 24.2| 27.1 +-+ 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!
Unable to fetch nextcloud-appointments
Hi, www/nextcloud-appointments fails to fetch : not present in distcache, an size mismatch with upstream [root@numenor ~]# cd /usr/ports/www/nextcloud-appointments/ [root@numenor nextcloud-appointments]# make fetch ===> License AGPLv3 accepted by the user ===> nextcloud-appointments-php82-2.2.0 depends on file: /usr/local/sbin/pkg - found => appointments.tar.gz doesn't seem to exist in /usr/ports/distfiles/nextcloud/appointments-2.2.0. => Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/nextcloud/appointments-2.2.0/appointments.tar.gz fetch: http://distcache.FreeBSD.org/ports-distfiles/nextcloud/appointments-2.2.0/appointments.tar.gz: Not Found => Attempting to fetch https://github.com/SergeyMosin/appointments/raw/v2.2.0a/build/artifacts/appstore/appointments.tar.gz fetch: https://github.com/SergeyMosin/appointments/raw/v2.2.0a/build/artifacts/appstore/appointments.tar.gz: size mismatch: expected 2037372, actual 2037374 => Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/nextcloud/appointments-2.2.0/appointments.tar.gz fetch: http://distcache.FreeBSD.org/ports-distfiles/nextcloud/appointments-2.2.0/appointments.tar.gz: Not Found => Couldn't fetch it - please try to retrieve this => port manually into /usr/ports/distfiles/nextcloud/appointments-2.2.0 and try again. *** Error code 1 Can a maintainer have look at this ? Thanks, Regards, Xavier -- Xavier HUMBERT - Unix/Win/MacOSX Sysadmin/Network Engineer https://www.amdh.fr
Re: port binary dumping core on recent head in poudriere
On 21/11/24 18:33, Guido Falsi wrote: On 21/11/24 18:27, Dimitry Andric wrote: On 21 Nov 2024, at 18:17, Guido Falsi wrote: On 20/11/24 23:50, Guido Falsi wrote: On 20/11/24 22:14, Dimitry Andric wrote: On 20 Nov 2024, at 18:32, Guido Falsi wrote: I've noticed that recently some ports are dumping core during builds of dependencies in head in poudriere. I'm seeing this for example with sassc crashing while trying to build x11-themes/greybird-theme. My first suspect was the llvm upgrade in head, but forcing sassc and libsass to build with older clang via USES=llvm:max=18 is not helping. I did recompile the offending programs with debug and tried a backtrace and got this: ``` (lldb) bt * thread #1, name = 'sassc', stop reason = signal SIGSEGV: invalid permissions for mapped object (fault address: 0x82374a000) * frame #0: 0x00082374a000 libsass.so.1 frame #1: 0x000823865a86 libsass.so.1`_GLOBAL__sub_I_ast.cpp [inlined] double std::__1::__math::acos[abi:se190102](__x=-1) at inverse_trigonometric_functions.h:40:10 frame #2: 0x000823865a81 libsass.so.1`_GLOBAL__sub_I_ast.cpp [inlined] __cxx_global_var_init at units.hpp:11:21 frame #3: 0x000823865a81 libsass.so.1`_GLOBAL__sub_I_ast.cpp at ast.cpp:0 frame #4: 0x1eac6e3f078d ld-elf.so.1 frame #5: 0x1eac6e3ef349 ld-elf.so.1 frame #6: 0x1eac6e3ec099 ld- elf.so.1`___lldb_unnamed_symbol27 + 25 ``` which points me to this upstream line of code: https://github.com/ sass/libsass/blob/7037f03fabeb2b18b5efa84403f5a6d7a990f460/src/ units.hpp#L11 I could change the way it derives PI, but I'm not sure this is the correct fix. At first sight this looks like some sort of initialization order fiasco, but without a full backtrace and some indications on what it is exactly segfaulting on it is hard to say. Is it reproducible? It is fully reproducible here by just compiling the sassc port and trying to run it. It segfaults on startup. I'm following up to myself to note that I'm observing the same issue in textproc/opensp if trying to run anything linked with the library, for example its own binary "osx". I noticed it because it is required by libosp and then by gnucash which I use and maintain. libosp fails during configure due to a test binary compiled by configure script dumping core. I suspect there are more around the ports tree. I cannot reproduce this at all. For me the sassc binary runs fine, and also the x11-themes/greybird-theme port builds fine. Then again, my base system is probably older than yours? Which revision are you running? I'm running cdfd0600dc8882f0a0d0e6d9a1cdcf926edba6d6 from Tue Nov 5 13:35:17 2024 -0800 (cut & paste from git log) I tried upgrading to 07593d13fa2ad6fe4d962b7473c6020aef2a0414 from yesterday, cleaning all ports, forcing a rebuild, but I see the exact same issue. -- Guido Falsi
Re: port binary dumping core on recent head in poudriere
On 23/11/24 15:34, Guido Falsi wrote: On 21/11/24 18:33, Guido Falsi wrote: On 21/11/24 18:27, Dimitry Andric wrote: On 21 Nov 2024, at 18:17, Guido Falsi wrote: On 20/11/24 23:50, Guido Falsi wrote: On 20/11/24 22:14, Dimitry Andric wrote: On 20 Nov 2024, at 18:32, Guido Falsi wrote: I've noticed that recently some ports are dumping core during builds of dependencies in head in poudriere. I'm seeing this for example with sassc crashing while trying to build x11-themes/greybird-theme. My first suspect was the llvm upgrade in head, but forcing sassc and libsass to build with older clang via USES=llvm:max=18 is not helping. I did recompile the offending programs with debug and tried a backtrace and got this: ``` (lldb) bt * thread #1, name = 'sassc', stop reason = signal SIGSEGV: invalid permissions for mapped object (fault address: 0x82374a000) * frame #0: 0x00082374a000 libsass.so.1 frame #1: 0x000823865a86 libsass.so.1`_GLOBAL__sub_I_ast.cpp [inlined] double std::__1::__math::acos[abi:se190102](__x=-1) at inverse_trigonometric_functions.h:40:10 frame #2: 0x000823865a81 libsass.so.1`_GLOBAL__sub_I_ast.cpp [inlined] __cxx_global_var_init at units.hpp:11:21 frame #3: 0x000823865a81 libsass.so.1`_GLOBAL__sub_I_ast.cpp at ast.cpp:0 frame #4: 0x1eac6e3f078d ld-elf.so.1 frame #5: 0x1eac6e3ef349 ld-elf.so.1 frame #6: 0x1eac6e3ec099 ld- elf.so.1`___lldb_unnamed_symbol27 + 25 ``` which points me to this upstream line of code: https:// github.com/ sass/libsass/ blob/7037f03fabeb2b18b5efa84403f5a6d7a990f460/src/ units.hpp#L11 I could change the way it derives PI, but I'm not sure this is the correct fix. At first sight this looks like some sort of initialization order fiasco, but without a full backtrace and some indications on what it is exactly segfaulting on it is hard to say. Is it reproducible? It is fully reproducible here by just compiling the sassc port and trying to run it. It segfaults on startup. I'm following up to myself to note that I'm observing the same issue in textproc/opensp if trying to run anything linked with the library, for example its own binary "osx". I noticed it because it is required by libosp and then by gnucash which I use and maintain. libosp fails during configure due to a test binary compiled by configure script dumping core. I suspect there are more around the ports tree. I cannot reproduce this at all. For me the sassc binary runs fine, and also the x11-themes/greybird-theme port builds fine. Then again, my base system is probably older than yours? Which revision are you running? I'm running cdfd0600dc8882f0a0d0e6d9a1cdcf926edba6d6 from Tue Nov 5 13:35:17 2024 -0800 (cut & paste from git log) I tried upgrading to 07593d13fa2ad6fe4d962b7473c6020aef2a0414 from yesterday, cleaning all ports, forcing a rebuild, but I see the exact same issue. In fact, I noticed, guile2 is also showing this behaviour. -- Guido Falsi
Re: port binary dumping core on recent head in poudriere [WRONG: 1500026 libsass.so.1.0.0 vs. 1500027 one]
I finally looked in a better place for finding a significant difference: The good /usr/local/lib/libsass.so.1.0.0 in my context (the one in the PkgBase based chroot area) has: Contents of section .got.plt: 2bed60 78ba2b00 x.+. 2bed70 86a62a00 ..*. 2bed80 96a62a00 a6a62a00 ..*...*. 2bed90 b6a62a00 c6a62a00 ..*...*. 2beda0 d6a62a00 e6a62a00 ..*...*. 2bedb0 f6a62a00 06a72a00 ..*...*. 2bedc0 16a72a00 26a72a00 ..*.&.*. 2bedd0 36a72a00 46a72a00 6.*.F.*. 2bede0 56a72a00 66a72a00 V.*.f.*. 2bedf0 76a72a00 86a72a00 v.*...*. 2bee00 96a72a00 a6a72a00 ..*...*. 2bee10 b6a72a00 c6a72a00 ..*...*. 2bee20 d6a72a00 e6a72a00 ..*...*. 2bee30 f6a72a00 06a82a00 ..*...*. . . . The bad one built in my personal environment has: Contents of section .got.plt: 2bed60 2bed70 2bed80 2bed90 2beda0 2bedb0 2bedc0 2bedd0 2bede0 2bedf0 2bee00 2bee10 2bee20 2bee30 . . . So a libsass.so.1.0.0 file-generation time issue, not a load-time issue. Not that I've any clue why yet. === Mark Millard marklmi at yahoo.com
