It's not possible to mfh it, rust is at 1.89.0 in Q4.
It's probably possible to do a direct commit in Q4 but I've never done that. Feel free to do it if you think Q4 needs this patch.

I'll commit your patch prior to landing rust 1.91.0 (to not bump rust too frequently, people will get mad at me otherwise)
I'll drop the version in the file name (it's a pain to maintain in the long run) -> files/patch-vendor_openssl-probe_src_lib.rs

There are 2 version of openssl-probe (openssl-probe-0.1.5/ openssl-probe-0.1.6), only 0.1.6 needs to be patched?

I'm updating rust to 1.91.0, does it apply to this version ?

You have my approval if it doesn't break ports (you can ask for an exp-run)

Are any ports broken without (or with) this patch?
I really have no clue why this patch is (or isn't) necessary.

Personally, I don't like it when a service downloads / installs things at launch, isn't there another way?

Can you sort the options please?

Approved by: samba

Sorry, this was fixed in https://cgit.freebsd.org/ports/commit/net-im/libsignal-node/Makefile?id=858d32fac8f9ab1d211abaa8fed7d3f1c443f7c4 and reintroduce in
https://cgit.freebsd.org/ports/commit/net-im/libsignal-node/Makefile?id=57741b0aa4123a69b1fd223fde4a70ca82283edb.
I forgot to merge this change in https://github.com/MikaelUrankar/signal-desktop

Thanks!

I've put my wip here https://github.com/MikaelUrankar/influxdb2

You can do something like that for lang/influx-flux:

#!/bin/sh
# XXX v0.194.5

Feel free to update the port whenever you like as I don't have time to maintain it. You have my implicit approval.

add missing "-" in PKGNAMESUFFIX

Feel free to commit it under portmgr blanket approval (build fix blanket)

ah right.

LGTM

This port is complex enough, I personally don't want to add so much complexity and deviate from upstream.

Why www/redmine42 was converted to USES= ruby but redmine50 not?
Many ports don't have USE_RUBY or USES=ruby anymore, I fail to understand the logic.

In D37467#852616, @pkubaj wrote:

Then how can you explain the Rust build issue on armv7?

In D37467#852552, @pkubaj wrote:

The error is clearly the same as on powerpc.

In D37467#852172, @pkubaj wrote:

armv7-rust-bootstrap-1.65.0.log14 MBDownload

Fails for me as well.

In D37467#851896, @pkubaj wrote:

Were you able to build rust for armv7 without libatomic?

lang/rust works on armv7 without libatomic

I've done some tests on armv7 and libatomic is not needed.

what does it have to do with qemu?

What's different from the patch in PR 265915 ? https://bz-attachments.freebsd.org/attachment.cgi?id=235976
phabricator is incredibly hard to use...

I'm not sure if src/bootstrap/lib.rs is correctly updated...

In D32654#810083, @evgeniy_khramtsov.org wrote:

Commit message was lost and I have yet to learn to use Phabricator beyond Web frontend:

From: Evgeniy Khramtsov <evgeniy@khramtsov.org>
Date: Tue, 5 Jul 2022 09:32:14 +0000
Subject: [PATCH] lang/rust: allow experimental static linking against
LLVM from ports

Rust bundles vendored LLVM for rarely essential changes,
or features guarded behind LLVM_RUSTLLVM, that may not
be required for a user.
---

Remove another obsolete patch

Remove obsolete patch

regen

Works for me on 12.2 aarch64.

• Mark devel/racer as broken and set an expiration date
• Only build rustc-dev on nightly (per https://rust-lang.github.io/rustup/concepts/components.html)

Here is an update. I still have to test a few things marked with XXX in the Makefile.
The DOC doesn't build but there is a patch available now, we should try to import it.
I'm still not sure if we should install rustc-dev on the stable channel (alpine installs it), it's only usefull to build devel/racer. It adds 120MB to rust-1.60.0.pkg

In D34818#790953, @kfv_kfv.io wrote:

@fernape: Sorry, I didn't know I must take care of all architecture. Could you please guide me on how to ensure it can build fine on 12.3 i386? And if the upstream has no official release for an architecture, should I specify that architecture in the Makefile or is there any specific process to see if we can make it work? And one more question, should I only care about tier 1 platforms of the supported RELEASE versions or do we have another rule? And my sincere apologies for the oversight.

In D34823#790447, @mikael wrote:

The problem with devel/racer is as follows:

• racer 2.1.48 doesn't build with rust 1.60.0
• racer 2.x requires rustc-dev from rust-nightly
• rustc-dev is not "fabricated" on lang/rust-nightly because we use x.py build instead of x.py dist

Probably time to resurrect https://reviews.freebsd.org/D28520

The problem with devel/racer is as follows:

• racer 2.1.48 doesn't build with rust 1.60.0
• racer 2.x requires rustc-dev from rust-nightly
• rustc-dev is not "fabricated" on lang/rust-nightly because we use x.py build instead of x.py dist

We still need COMPAT_FREEBSD11 for rust, don't delete riscv64/patch-vendor_libc-0.2.108_src_unix_bsd_freebsdlike_freebsd_freebsd11_mod.rs please.

https://cgit.freebsd.org/ports/commit/www/onlyoffice-documentserver?id=e6f27356846a36c63bfe394cb9d7c61495e0822b

Delete riscv64 patches.
Import https://github.com/rust-lang/stdarch/pull/1290

veloren issue reported upstream: https://gitlab.com/veloren/veloren/-/issues/1493
aarch64 fails to build, reported upstream: https://github.com/rust-lang/stdarch/issues/1289

In D33190#751745, @tobik wrote:

@mikael Should we disable the backtrace libunwind backend for armv* like in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259799#c40 or do we leave it on?

In D32654#739293, @tobik wrote:

Technical issues aside: Is there a committer who is going to own/support this?

In D32157#725775, @tobik wrote:

LGTM.

Do we need to keep this after @rene commits D32008? If not we could remove it earlier than 1.56.

In D32155#725720, @arrowd wrote:

Looks good, thanks for upstreaming the patch!

Did you upload bootstraps somewhere?