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?

In D31872#721168, @tobik wrote:

@mikael Should I update the armv7 bootstrap with the new ones from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257419#c25 ?

Can you change the armv6/7 target triple to this please:

--- a/lang/rust-bootstrap/Makefile
+++ b/lang/rust-bootstrap/Makefile
@@ -112,8 +112,8 @@ _RUST_LLVM_TARGET_powerpc64_elfv2=  PowerPC
 _RUST_LLVM_TARGET_powerpc64le=         PowerPC
 _RUST_LLVM_TARGET_powerpc=             PowerPC
 _RUST_LLVM_TRIPLE=                     ${_RUST_LLVM_TRIPLE_${FLAVOR}:U${_RUST_TARGET}}
-_RUST_LLVM_TRIPLE_armv6=               armv6-gnueabihf-freebsd
-_RUST_LLVM_TRIPLE_armv7=               armv7-gnueabihf-freebsd
+_RUST_LLVM_TRIPLE_armv6=               armv6-unknown-freebsd12.2-gnueabihf
+_RUST_LLVM_TRIPLE_armv7=               armv7-unknown-freebsd12.2-gnueabihf
 _RUST_LLVM_TRIPLE_powerpc=             powerpc-unknown-freebsd13.0 # secure-plt

Can you update patch-src_llvm-project_compiler-rt_lib_builtins_cpu__model.c with what will probably be committed upstream : https://reviews.llvm.org/D109330 . I've put the updated file on freefall.
In lang/rust-bootstrap: we can remove the llvm90 dep for aarch64 with the following patch:

--- a/lang/rust-bootstrap/Makefile
+++ b/lang/rust-bootstrap/Makefile
@@ -34,7 +35,6 @@ FLAVORS=      aarch64 amd64 armv6 armv7 i386 powerpc64_elfv1 powerpc64_elfv2 \
 FLAVOR?=       ${FLAVORS:[1]}

regen

In D31617#713919, @tobik wrote:

Thanks for doing the update.

• I've ran some ref machine builds a couple of weeks ago and they were all fine.

Thanks.

• Do we still need an exp-run? It looks like you already ran your own.

Not sure, I've only tried on 14amd64

• There is an updated LibreSSL patch on the ref machines at ref13-ppc64.freebsd.org:/home/tobik/staging/3995d76b-f848-11eb-abb0-c80aa94ee693/lang/rust/files/patch-vendor_openssl-sys_build_main.rs. Can you add it?

done

Address tobik's comments

Can someone commit this please?
Thanks in advance!

In D28520#675239, @tobik wrote:

@mikael, wondering why you abandoned? I am curious if adding build-stage=2 was already enough.

It's ok on armv7, aarch64

Can you also bump rust version in Mk/bsd.gecko.mk ?

In D28520#657426, @tobik wrote:

Do you know what the underlying issue with x.py build and x.py install is? It has never really been clear to me.

Honestly I don't know, it seems to only be an issue on low core machine (or at -j1). How many cpus do you have on your VM?