Created attachment 264817 [details] Patch that updates to the latest Fritzing As a note, I removed the pkg-install.in file since it unnecessarily adds a real user (e.g. shows up as a login in SDDM) and is not necessary for anything.
Created attachment 265348 [details] Updated patch to the official 1.0.6 release
Created attachment 265358 [details] Cleaned up and improved patch (V3)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=4489c47e6c3fe87df3964021e33d70d52b549aaa commit 4489c47e6c3fe87df3964021e33d70d52b549aaa Author: Kenneth Raplee <kenrap@kennethraplee.com> AuthorDate: 2025-11-13 05:44:17 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2025-11-13 05:45:21 +0000 cad/fritzing: Update to 1.0.6 PR: 290453 Approved by: maintainer timeout cad/fritzing/Makefile | 54 +- cad/fritzing/distinfo | 10 +- cad/fritzing/files/patch-fritzing.desktop (gone) | 11 - .../patch-org.fritzing.Fritzing.desktop (new) | 11 + cad/fritzing/files/patch-phoenix.pro | 45 +- .../patch-src_connectors_connectoritem.cpp (new) | 28 + .../files/patch-src_fapplication.cpp (new) | 23 + .../files/patch-src_items_itembase.cpp (new) | 20 + .../patch-src_items_paletteitembase.cpp (new) | 20 + .../files/patch-src_items_resistor.cpp (new) | 11 + .../files/patch-src_model_modelbase.cpp (new) | 11 + ...tch-src_simulation_ngspice__simulator.cpp (new) | 11 + .../files/patch-src_sketch_sketchwidget.cpp (new) | 28 + .../files/patch-src_utils_textutils.cpp (new) | 20 + cad/fritzing/files/pkg-install.in (gone) | 15 - cad/fritzing/files/pri_clipper1detect.pri (new) | 4 + cad/fritzing/files/pri_quazipdetect.pri (new) | 7 + cad/fritzing/files/pri_spicedetect.pri (new) | 2 + cad/fritzing/pkg-plist | 10665 ++++++++++++++++++- 19 files changed, 10905 insertions(+), 91 deletions(-)
ports 427211c1e7a2e525fe4cf66e9804a992b3b14143 added this: +IGNORE_FreeBSD_13= Requires OpenSSL >= 3 I assume there was a build error when using 'base' the ssl library option in DEFAULT_VERSIONS. cad/fritzing built fine and the Fritzing application ran successfully on 13.x for me when I had openssl from ports installed. Maybe this... diff --git a/cad/fritzing/Makefile b/cad/fritzing/Makefile index ea917e9c538f..4f5442493304 100644 --- a/cad/fritzing/Makefile +++ b/cad/fritzing/Makefile @@ -8,8 +8,6 @@ WWW= https://fritzing.org/ LICENSE= GPLv2+ -IGNORE_FreeBSD_13= Requires OpenSSL >= 3 - BUILD_DEPENDS= boost-libs>1.52:devel/boost-libs \ svgpp>0:graphics/svgpp @@ -52,4 +50,10 @@ post-install: -f ${STAGEDIR}${DATADIR} \ -platform offscreen -.include <bsd.port.mk> +.include <bsd.port.pre.mk> + +.if ${SSL_DEFAULT} == "base" +IGNORE_FreeBSD_13= Requires OpenSSL >= 3 +.endif + +.include <bsd.port.post.mk>
p.s. during 'make configure', I noticed this: date: illegal option -- - usage: date [-jnRu] [-I[date|hours|minutes|seconds]] [-f input_fmt] [-r filename|seconds] [-v[+|-]val[y|m|w|d|H|M|S]] [[[[[[cc]yy]mm]dd]HH]MM[.SS] | new_date] [+output_fmt] It probably comes from the following in pri/gitversion.pri: !win32:!macx { BUILD_DATE = $$system( date --iso-8601=seconds ) } Looks like it's not important for the FreeBSD ports build, but I just thought I'd mention it.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=991dd07a2ea896cf794a81375140449c4aaf008c commit 991dd07a2ea896cf794a81375140449c4aaf008c Author: John Hein <jcfyecrayz@liamekaens.com> AuthorDate: 2025-11-17 09:52:52 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2025-11-17 09:53:28 +0000 cad/fritzing: Allow building on FreeBSD 13 when SSL_DEFAULT != base PR: 290453 cad/fritzing/Makefile | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
(In reply to commit-hook from comment #6) Thanks.
(In reply to John Hein from comment #5) It's part of the build process from the pri/gitversion.pri file. It's just for fetching and timestamping from the latest git commit in the fritzing-parts repo. It can be safely ignored since we already do our own integration of the part files. :)
(In reply to Kenneth Raplee from comment #8) Thanks for confirming my supposition that the date error is just noise. It might be worth asking upstream to fix that. It looks like they already exclude that bad date command (that uses --iso-8601) for macos. Really, it's not OS-specific but rather whether the date command supports --iso-8601 (which probably only gnu date supports). Their method of using OS designator as a proxy for "supports date --iso-8601" could be improved.