ArduPilot SITL on FreeBSD 15.0 – successful build and a question about porting

Before testing firmware builds, please install the ARM embedded toolchain and:
Code: 
pkg install gcc-arm-embedded gcc opencv proj rsync git gmake python py311-pip py311-sqlite3
The port uses arm-none-eabi-gcc to build firmware for STM32-based flight controllers (e.g. F405, F7, H7).

SITL can be tested without the ARM toolchain, but hardware firmware builds require gcc-arm-embedded.
Tested on FreeBSD 15.0-RELEASE:
- SITL (ArduCopter)
- SPEDIXF405 firmware build
Code: 
ardupilot-waf configure --board SPEDIXF405
ardupilot-waf copter
codeberg.org

ports-FreeBSD

my test ports FreeBSD Makefile
codeberg.org codeberg.org
 
I was checking out your codeberg repository and I must congratulate you. That is quite a bit of work you have there.
Looking at your science/adrupilot port and the GH Tuples I was back to my same nagging question.
Should some of this be separate ports or a metaport. I am not thoroughly versed. Seeing the ARM EABI needed for the whole port knda makes my point.

It does not look like you will need to drag in 20 new ports for this like I thought. What is your estimation of new ports needed?
Reason I ask is you might want to push the new dependencies first 'In anticipation' of landing the ArduPilot port. Giving people a heads up.

I am pretty sure the setuptools work is there at the PR for v81.0 but it seems some patches are there that are not needed for py-setuptools but are fixes for the upcoming breakage.
Its hard to discern from all those patches what is needed. The unrelated-ports fixes really should be in another PR.

I started with the v78.1 patch and it alone failed. It would satisfy your dependency.

Everything you have done is excellent. Once the ports are finished you might want to add another way to test the port work.
Make an archive file of all the custom ports so testers can extract them straight into a ports tree to test.
jmos did that with his custom SeaMonkey port and I found it a good way to use the software.

pynmeagps Makefile has some extraneous text. Good job fixing the license error.

What can I do to help you? Have you devised a plan ? FreeBSD @python Mailing List RFC or talk to python @ IRC members?
Laying groundwork might help this move along.
 
Previously I would get a successful wheel build. Shown in GREEN text. Now I can't get that far.

Code: 
===>  License MIT accepted by the user
===>   py311-setuptools-78.1.1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by py311-setuptools-78.1.1 for building
===>  Extracting for py311-setuptools-78.1.1
=> SHA256 Checksum OK for python/setuptools-78.1.1.tar.gz.
===>  Patching for py311-setuptools-78.1.1
===>   py311-setuptools-78.1.1 depends on package: py311-packaging>=24.2 - found
===>   py311-setuptools-78.1.1 depends on package: py311-more-itertools>=8.8 - found
===>   py311-setuptools-78.1.1 depends on package: py311-wheel>=0.43.0 - found
===>   py311-setuptools-78.1.1 depends on file: /usr/local/bin/python3.11 - found
===>   py311-setuptools-78.1.1 depends on package: py311-build>=0 - found
===>   py311-setuptools-78.1.1 depends on package: py311-installer>=0 - found
===>  Configuring for py311-setuptools-78.1.1
===>  Building for py311-setuptools-78.1.1
* Getting build dependencies for wheel...

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pyproject_hooks/_impl.py", line 402, in _call_hook
    raise BackendUnavailable(
pyproject_hooks._impl.BackendUnavailable: Cannot import 'setuptools.build_meta'

ERROR Backend 'setuptools.build_meta' is not available.
*** Error code 1

Stop.
make: stopped making "all" in /usr/ports/devel/py-setuptools78

Using Makefile for 78.1.1 from v81.0 PR
/usr/ports/devel/py-setuptools78/Makefile
Code: 
PORTNAME=    setuptools
DISTVERSION=    78.1.1
CATEGORIES=    devel python
MASTER_SITES=    PYPI
PKGNAMEPREFIX=    ${PYTHON_PKGNAMEPREFIX}
DIST_SUBDIR=    python
 
# note: before committing a new major version, contact portmgr to
# arrange for an experimental ports run. Untested commits may be
# backed out.
MAINTAINER=    python@FreeBSD.org
COMMENT=    Python packages installer
WWW=        https://setuptools.pypa.io/
 
LICENSE=    MIT
LICENSE_FILE=    ${WRKSRC}/LICENSE
 
BUILD_DEPENDS=    ${_CORE_DEPENDS}
RUN_DEPENDS=    ${_CORE_DEPENDS}
 
USES=        cpe python

CPE_VENDOR=    python
USE_PYTHON=    allflavors autoplist concurrent pep517 pytest

_CORE_DEPENDS=    ${PYTHON_PKGNAMEPREFIX}packaging>=24.2:devel/py-packaging@${PY_FLAVOR} \
        ${PYTHON_PKGNAMEPREFIX}more-itertools>=8.8:devel/py-more-itertools@${PY_FLAVOR} \
        ${PY_TOMLI} \
        ${PYTHON_PKGNAMEPREFIX}wheel>=0.43.0:devel/py-wheel@${PY_FLAVOR}

# circular dependencies
#_CORE_DEPENDS=    ${PYTHON_PKGNAMEPREFIX}jaraco.text>=3.7:devel/py-jaraco.text@${PY_FLAVOR} \
#        ${PYTHON_PKGNAMEPREFIX}platformdirs>=4.2.2:devel/py-platformdirs@${PY_FLAVOR} \
#        ${PYTHON_PKGNAMEPREFIX}jaraco.functools>=4:devel/py-jaraco.functools@${PY_FLAVOR}

# remove vendored packages of those already installed via pkg(8)
_DIST_EXCLUDES=    packaging* \
        more_itertools* \
        wheel* \
        tomli* \
        typing_extensions* \
        importlib_metadata* \
        zipp*
EXTRACT_AFTER_ARGS=    ${_DIST_EXCLUDES:S,^,--exclude setuptools/_vendor/,}
 
NO_ARCH=    yes

.include <bsd.port.mk>
 
Python dependencies are being submitted separately:
devel:py-fastcrc, py-pymavlink, py-pynmeagps, py-dronecan
net/py-mavproxy
These ports were not previously available in the FreeBSD Ports Collection. Other dependencies, such as py311-intelhex, already exist in the ports tree.
I currently see ArduPilot as two parts:
  • ArduPilot SITL
  • ArduPilot firmware build support
  • The required ports for firmware builds are listed as dependencies, and gcc-arm-embedded is already available in the Ports Collection.
  • I think QGroundControl should be handled as a separate port: https://github.com/mavlink/qgroundcontrol
The setuptools > 81 issue is not that setuptools itself is unavailable. The problem is that many Python packages need to be checked and tested for compatibility. While testing one version, newer versions are released, and it is difficult to keep up with the repository of tested packages. There are also relatively few people working on porting and testing.


>>> Regarding your question, "What can I do to help?":
Test the ports with:
Code: 
make install clean
and report any build or runtime errors, build firmware for a Matek F405 Wing V2 board, flash the generated firmware onto a Matek F405 Wing V2 and verify that it works correctly.
 
Regarding py-setuptools, it would be worth discussing this with the Python team to understand which direction they are taking and which version they are currently testing.
Building py-setuptools 81 is not the main problem. The real challenge is testing a large number of Python modules and ensuring that nothing breaks across the ports tree or in existing user environments.Any setuptools update has a wide impact, so compatibility testing is likely more important than getting a newer version to build successfully.
 
It does seem like a massive amount of work with the packaging changes. First elimination of setup.py for PEP517 then elimination of PKG-INFO.

I am beginning to understand the term "Technical Debt". FreeBSD Python team has quite a task onhand.
 
Started testing your ports.
/science/ardupilot -- Checks out good
/devel/py-dronecan -- Checks out good
/devel/py-mavlink -- Makefile has bogus text Head and Master. Needs pyfastcrc built first... Depends on it?
/devel/pyfastcrc -- SAME. Bogus Makefile text Head and Master.

make[1]: stopped making "install" in /usr/ports/devel/py-fastcrc
*** Error code 1

Stop.
make: stopped making "all" in /usr/ports/devel/py-pymavlink
Click to expand...

I use this to grab dependencies from packages for each port build:
make build-depends-list | cut -c 12- | xargs pkg install -A -y
 
I can't seem to get /devel/py-fastcrc to build using my installed packaged rust-1.94.

py-fastcrc wants to build from ports RUST v1.96

Just to show you how much I want to see this ported I am letting it build..
 
when I tested, I was going to use rust 1.95.0, now I'm testing
>> /devel/py-mavlink -- Makefile contains fake Head and Master text. First you need to create pyfastcrc... Does it depend on this?
yes, it is written in Makefile RUN_DEPENDS=
Code: 
cd /usr/ports
git branch -vv
 
You must log in or register to reply here.
Back
Top