Committed in rP449914.

Refresh after the commit of D11574

I refreshed to patch to resolve conflicts and fixed the typo reported by @jilles.

Fix typo in "PATHCED"

The last revision addresses @vaartis_cock.li suggestion.

Add a SOURCES option

I addressed concerns from @jbeich.

Fix a few fatals and warnings from portlint -C

... instead of a regular patch. This way, we don't have to
regenerate any .cargo-checksum.json patches and it works when
WITHOUT_FBSD10_FIX is set.

Ok, I will add an option to keep source code.

Fix extra-ino64 patch on HEAD/i386

It compiles fine on 10.3/amd64 and 11.0/i386. I can't test on aarch64 because pkgconf is not installed on ref12-aarch64.freebsd.org.

Fix port name in BUILD_DEPENDS in multimedia/librespot

Just wanted to let you know I saw this patch. I'm working on further fixes and improvement to the Rust 1.19.0 update. Once this is committed, I'll try your patch.

Someone else committed another update.

This was committed without approval because I was released from mentorship.

This was committed without approval because I was released from mentorship.

3.2.0 was released upstream

Thank you for working on this, this is very helpful!

This patch addresses the following bug:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219842

Rebase onto the 1.18.0 update

Resolve conflict with latest PORTREVISION bump

3.1.1 was released upstream

The port was built successfully on FreeBSD HEAD/aarch64, both pre-ino64 and post-ino64.

Adapt files/extra-patch-ino64 to aarch64

Update after the commit of the ino64 project

I tested the patch successfully on pre-ino64 and post-ino64 systems:

• lang/rust and devel/cargo build fine
• A simple Rust program which reads file stats is returning meaningful data.

Also, the patch doesn't contain that yet, but we should depend on Python 3 to build, not any Python, and certainly not Python 2.

FTR, someone from OpenBSD started a discussion about ABI breakage in various OSes and how to support that in Rust:
https://internals.rust-lang.org/t/pre-rfc-target-extension-dealing-with-breaking-changes-at-os-level/5289

In D10799#225533, @kib wrote:

I only mean that I personally do not intend to submit it upstream. That said, I indeed do not think that the patch (its lib source part) is suitable for inclusion into the upstream source as is, because it breaks structure definitions for pre-ino64 systems, in particular, for stable/10 and 11. It should be conditionalized on the __FreeBSD_version value in rust sources, somehow. I do not know how to do it, and did not investigated. Ports patch conditionally applies the change, checking the version in the ports Makefile.

I accept the patch, though I can't commit it.

In D10799#225180, @kib wrote:

The content of liblibc is a Git submodule initially, making the libc "crate". That crate is used by devel/cargo so we also need to apply the patch to the copy of libc inside the cargo-registry-$VERSION.tar.xz archive. Newer versions of that crate also have FreeBSD/aarch64 support (i.e. there is a src/liblibc/src/unix/bsd/freebsdlike/freebsd/aarch64.rs): lang/rust 1.17.0 has it and the incoming devel/cargo 0.18.0 will do too. See D10857 and D10867 for patches to enable those two ports on FreeBSD/aarch64.

Did you submit anything upstream yet?

No, and I have no intend to. I do not think that this is reasonable to submit this stuff to upstream. Did you read the long message explaining the ino64, which is linked in the review description?

I started to think about this patch and I have some questions.

Here is the related Bugzilla entry:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216143

Crap, I forgot to commit it... Now, it's replaced by D10583.

I agree with @rezny on the usefulness of "kms" in the name. That feature was a huge turn in the graphics drivers, but it remains just one aspect of them nonetheless. Having the words "drm" and "kmod" is important in the name, plus possibly something about the branch if we want to have several ports at the same time in the Ports tree. So drm-kmod or drm-4.9-kmod look like good candidates to me.

Update to 0.17.0

I don't know, I will ask them about that as I have the same concern.

Revert a whitespace change

Thank you!

I agree with @asomers regarding the explicit commands in pkg-message. Yes, it is something the user could learn from the manpages, but it makes it very straightforward and quick to finish the setup. Personnaly, I find that commands stand out in all pkg-messages displayed at the end of a pkg install and it has a better chance of getting my attention.

Forgot to mention: this fixes a staging failure for many people building the port outside of Poudriere, because the filenames depend on the source files location. Here is the Bugzilla report related to this:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217309