games/flightgear-aircraft: Update to 20260606
Merged into 2026Q2 as the previous version no longer fetches.
Approved by: portmgr (build fix blanket)
(cherry picked from commit 8b778e1558acdd1a3a7a9a3dcf1a6295be477237)
net-im/py-zapzap: Update to 6.5.1.1
- Add a post-patch target to fix the distribution version, otherwise
the building process fails with the error:
===> Generating temporary packing list
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "/usr/local/lib/python3.11/site-packages/installer/__main__.py", line 115, in <module>
_main(sys.argv[1:], "python -m installer")
File "/usr/local/lib/python3.11/site-packages/installer/__main__.py", line 100, in _main
with WheelFile.open(wheel) as source:
File "/usr/local/lib/python3.11/contextlib.py", line 137, in __enter__
return next(self.gen)
^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/installer/sources.py", line 179, in open
with zipfile.ZipFile(path) as f:
^^^^^^^^^^^^^^^^^^^^^
[6 lines not shown]
lang/ruby*: fix coroutines on armv7
Two ports, devel/rubygem-glib2 and graphics/rubygem-cairo, have been
broken on armv7 for a long time. Recently, pkubaj fixed a problem with
Ruby's coroutine code on ppc64* (see 3bb0a9335) affecting the very same
ports. This naturally raises the question if the armv7 problems are
related.
Turns out that due to an oversight, we use the generic ucontext.h-based
coroutine code on armv7. Switching to the assembly-based code fixes
the ports! Further digging suggests that there may be a problem in the
freebsd32 support for these calls on aarch64 causing the observed
issues. We will investigate those separately.
Tested by: fuz
Approved by: portmgr (build fix blanket)
MFH: 2026Q2
(cherry picked from commit b6686e6f886f55b93c73d323d868bc3fdf7f1eac)
lang/ruby*: fix coroutines on armv7
Two ports, devel/rubygem-glib2 and graphics/rubygem-cairo, have been
broken on armv7 for a long time. Recently, pkubaj fixed a problem with
Ruby's coroutine code on ppc64* (see 3bb0a9335) affecting the very same
ports. This naturally raises the question if the armv7 problems are
related.
Turns out that due to an oversight, we use the generic ucontext.h-based
coroutine code on armv7. Switching to the assembly-based code fixes
the ports! Further digging suggests that there may be a problem in the
freebsd32 support for these calls on aarch64 causing the observed
issues. We will investigate those separately.
Tested by: fuz
Approved by: portmgr (build fix blanket)
MFH: 2026Q2
print/publisher: speedata Publisher
speedata Publisher is a professional, non-interactive layout engine for
database publishing. It generates high-quality PDF files from XML data
and XML layout instructions, making it well suited for product catalogs,
price lists, and other documents with demanding layout requirements.
The layout description language allows complex, nearly arbitrary page
designs while keeping the job as straightforward as possible. It can be
thought of as "XSL-FO on steroids" or a server-side alternative to
desktop publishing tools like InDesign. It is production-proven and used
in commercial environments worldwide.
The core typesetting engine is LuaTeX (not included; must be provided
separately via download.speedata.de or the official packages). The Go
front-end binary (sp) drives the build process and handles XML parsing,
resource loading, and orchestration of the LuaTeX process.
WWW: https://www.speedata.de/
PR: 293790
