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 +-+ multimedia/video-trimmer| 0.8.2 | 0.10.0 +-+ 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!
Re: lang/rust/Makefile for 1.82.0 has wrong llvm:min= value [I got that incorrect]; more
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) For the example, in essence, LLVM 17's "Reader" was reporting finding LLVM 19 content, which, to LLVM 17, had an example of "Unknown attribute kind (91)". (LLVM 19's "Reader" likely would not have classified it that way.) So rust's internal LLVM 19 toolchain was generating output that LLVM 17's toolchain could not handle but was being told to process. This tends to suggest that using older linkers (or such) to link rust output that internally used a newer LLVM toolchain sometimes fails to be compatible. That leaves 3 basic options (stated for the specfics of the example in question): ) Have everything involved use a LLVM 19 toolchain matching lang/rust 's internal LLVM 19 toolchain, here LLVM 19.1.1 . ) Have lang/rust use the devel/llvm* toolchain that matches the context, here LLVM 17.0.6 . ) Use some other LLVM toolchain vintage for everything involved, say a devel/llvm18 toolchain. (Those are options that avoid doing some sort of detailed compatibility analysis across differing toolchain versions in order to pick some possibly mixed set of versions.) === Mark Millard marklmi at yahoo.com
Re: lang/rust/Makefile for 1.82.0 has wrong llvm:min= value [I got that incorrect]; more
Hello. 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? :) Regards.
Re: lang/rust/Makefile for 1.82.0 has wrong llvm:min= value [I got that incorrect]; more
[Charlie is correct about LLVM 17 being allowed by 1.82.0 of rust.
I had that wrong.]
On Nov 14, 2024, at 14:26, Mark Millard wrote:
>
> On Nov 14, 2024, at 13:21, Charlie Li wrote:
>
>> Mark Millard wrote:
>>> https://github.com/rust-lang/rust/pull/130487 reports . . .
>>> QUOTE
>>> Update the minimum external LLVM to 18 #130487
>>> With this change, we'll have stable support for LLVM 18 and 19.
>>> For reference, the previous increase to LLVM 17 was #122649.
>>> END QUOTE
>>> Note: the internal LLVM is 19 for 1.82.0 .
>
>> This commit is not in the 1.82 releases so the USES=llvm values remain
>> correct. It will be bumped for 1.83 as tagged in the pull request.> It leads
>> me to wonder if lang/rust should be using an external
I see what you were refering to now. I misinterpreted your wording the first
time.
In more detail:
# grep -r "bad LLVM version: {version}, need >="
/wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/
/wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/src/bootstrap/src/core/build_steps/llvm.rs:
panic!("\n\nbad LLVM version: {version}, need >=17.0\n\n")
More fully for the LLVM version check:
fn check_llvm_version(builder: &Builder<'_>, llvm_config: &Path) {
if builder.config.dry_run() {
return;
}
let version =
command(llvm_config).arg("--version").run_capture_stdout(builder).stdout();
let mut parts = version.split('.').take(2).filter_map(|s|
s.parse::().ok());
if let (Some(major), Some(_minor)) = (parts.next(), parts.next()) {
if major >= 17 {
return;
}
}
panic!("\n\nbad LLVM version: {version}, need >=17.0\n\n")
}
Sorry for the noise.
> From using pkg to update to the recent official lang/rust distribution:
>
> # rustc -vV
> rustc 1.82.0 (f6e511eec 2024-10-15) (built from a source tarball)
> binary: rustc
> commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
> commit-date: 2024-10-15
> host: x86_64-unknown-freebsd
> release: 1.82.0
> LLVM version: 19.1.1
>
> So the internal LLVM for lang/rust is LLVM 19.1.1 based as of that
> update.
>
> It is not my build, but is the official FreeBSD one for main [so:
> 15 as stands].
>
> For reference:
>
> # pkg info rust
> rust-1.82.0_1
> Name : rust
> Version: 1.82.0_1
> Installed on : Thu Nov 14 22:09:53 2024 UTC
> Origin : lang/rust
> Architecture : FreeBSD:15:amd64
> Prefix : /usr/local
> Categories : lang
> Licenses : MIT or APACHE20
> Maintainer : r...@freebsd.org
> WWW: https://www.rust-lang.org/
> Comment: Language with a focus on memory safety and concurrency
> Options:
> DOCS : on
> GDB: off
> LTO: off
> PORT_LLVM : off
> SOURCES: on
> WASM : on
> Shared Libs required:
> libcurl.so.4
> Shared Libs provided:
> libstd-d4ce5f4319a0892a.so
> librustc_driver-3dd68610bfbc3827.so
> Annotations:
> FreeBSD_version: 1500026
> build_timestamp: 2024-11-12T01:08:37+
> built_by : poudriere-git-3.4.2
> cpe: cpe:2.3:a:rust-lang:rust:1.82.0:freebsd15:x64:1
> port_checkout_unclean: no
> port_git_hash : b039f2e46b1
> ports_top_checkout_unclean: no
> ports_top_git_hash: ea7acb65556
> repo_type : binary
> repository : FreeBSD
> Flat size : 1.14GiB
> . . .
>
> The only way the internal LLVM for lang/rust ends up being based on
> LLVM 18 for 1.82.0 is via use of PORT_LLVM , which the official
> FreeBSD package builders do not do (at this time).
>
> So lang/rust 1.82.0 builds can potentially have newer, LLVM 19
> specific material if there is such.
>
>>> devel/llvm* by default, set to match a default ports tree
>>> LLVM to be used for major ports that involve lang/rust use.
>> No. Not something upstream encourages by default even if support exists,
>> especially because the default upstream builds use the bundled LLVM which is
>> what most consumers qualify with.
>
> The FreeBSD may at times have to update such that the default
> LLVM is forced to well match the lang/rust default LLVM. That
> might mean not updating lang/rust . (I'm not claiming there
> are always conflicts to deal with when LLVM's mismatch, just
> that there could be such at times.)
===
Mark Millard
marklmi at yahoo.com
security/gnutls: gnutls-3.8.8 requires llvm17 or higher to build
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 🤣 Regards.
Re: lang/rust/Makefile for 1.82.0 has wrong llvm:min= value; more
On Nov 14, 2024, at 13:21, Charlie Li wrote: > Mark Millard wrote: >> https://github.com/rust-lang/rust/pull/130487 reports . . . >> QUOTE >> Update the minimum external LLVM to 18 #130487 >> With this change, we'll have stable support for LLVM 18 and 19. >> For reference, the previous increase to LLVM 17 was #122649. >> END QUOTE >> Note: the internal LLVM is 19 for 1.82.0 . > This commit is not in the 1.82 releases so the USES=llvm values remain > correct. It will be bumped for 1.83 as tagged in the pull request.> It leads > me to wonder if lang/rust should be using an external From using pkg to update to the recent official lang/rust distribution: # rustc -vV rustc 1.82.0 (f6e511eec 2024-10-15) (built from a source tarball) binary: rustc commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14 commit-date: 2024-10-15 host: x86_64-unknown-freebsd release: 1.82.0 LLVM version: 19.1.1 So the internal LLVM for lang/rust is LLVM 19.1.1 based as of that update. It is not my build, but is the official FreeBSD one for main [so: 15 as stands]. For reference: # pkg info rust rust-1.82.0_1 Name : rust Version: 1.82.0_1 Installed on : Thu Nov 14 22:09:53 2024 UTC Origin : lang/rust Architecture : FreeBSD:15:amd64 Prefix : /usr/local Categories : lang Licenses : MIT or APACHE20 Maintainer : r...@freebsd.org WWW: https://www.rust-lang.org/ Comment: Language with a focus on memory safety and concurrency Options: DOCS : on GDB: off LTO: off PORT_LLVM : off SOURCES: on WASM : on Shared Libs required: libcurl.so.4 Shared Libs provided: libstd-d4ce5f4319a0892a.so librustc_driver-3dd68610bfbc3827.so Annotations: FreeBSD_version: 1500026 build_timestamp: 2024-11-12T01:08:37+ built_by : poudriere-git-3.4.2 cpe: cpe:2.3:a:rust-lang:rust:1.82.0:freebsd15:x64:1 port_checkout_unclean: no port_git_hash : b039f2e46b1 ports_top_checkout_unclean: no ports_top_git_hash: ea7acb65556 repo_type : binary repository : FreeBSD Flat size : 1.14GiB . . . The only way the internal LLVM for lang/rust ends up being based on LLVM 18 for 1.82.0 is via use of PORT_LLVM , which the official FreeBSD package builders do not do (at this time). So lang/rust 1.82.0 builds can potentially have newer, LLVM 19 specific material if there is such. >> devel/llvm* by default, set to match a default ports tree >> LLVM to be used for major ports that involve lang/rust use. > No. Not something upstream encourages by default even if support exists, > especially because the default upstream builds use the bundled LLVM which is > what most consumers qualify with. The FreeBSD may at times have to update such that the default LLVM is forced to well match the lang/rust default LLVM. That might mean not updating lang/rust . (I'm not claiming there are always conflicts to deal with when LLVM's mismatch, just that there could be such at times.) === Mark Millard marklmi at yahoo.com
Re: Anybody seeing NextCloud crash?
On 14/11/2024 14: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. I recently learned about another reason and it's an instruction like ud2 on x86 that can be inserted by a compiler for one reason or another (e.g., because of an assert). But not in this case, I think. Kevin correctly identified a (super)set of packages responsible for the problem. The issue is known and it should be fixed in ports already. See: https://cgit.freebsd.org/ports/commit/?id=1876b07e4fcf269a1c57ac401ab57e4337bcf465 https://github.com/aous72/OpenJPH/releases/tag/0.18.0 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. 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? -- Andriy Gapon
Re: lang/rust/Makefile for 1.82.0 has wrong llvm:min= value; more
Mark Millard wrote: https://github.com/rust-lang/rust/pull/130487 reports . . . QUOTE Update the minimum external LLVM to 18 #130487 With this change, we'll have stable support for LLVM 18 and 19. For reference, the previous increase to LLVM 17 was #122649. END QUOTE Note: the internal LLVM is 19 for 1.82.0 . This commit is not in the 1.82 releases so the USES=llvm values remain correct. It will be bumped for 1.83 as tagged in the pull request.> It leads me to wonder if lang/rust should be using an external devel/llvm* by default, set to match a default ports tree LLVM to be used for major ports that involve lang/rust use. No. Not something upstream encourages by default even if support exists, especially because the default upstream builds use the bundled LLVM which is what most consumers qualify with. -- Charlie Li ...nope, still don't have an exit line. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Anybody seeing NextCloud crash?
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?
