qmc2-0.243.14_1 is failing to build on all releases, and 15-CURRENT: https://pkg-status.freebsd.org/beefy18/build.html?mastername=main-amd64-default&build=p5bf2f841766d_s043d6a24b29 https://pkg-status.freebsd.org/beefy18/data/main-amd64-default/p5bf2f841766d_s043d6a24b29/logs/qmc2-0.243.14_1.log
Relevant snippet from build log: > In file included from src/qmc2main.cpp:38: > In file included from src/qmc2main.h:28: > src/imagewidget.h:13:10: fatal error: 'mz_compat.h' file not found > 13 | #include "mz_compat.h" > | ^~~~~~~~~~~~~ > c++ -c -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -DUSE_FILE32API -O2 -w -pthread -fPIC -DQCHDMAN_RELEASE -DQCHDMAN_VERSION=0.244 -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_SCRIPT_LIB -DQT_SCRIPTTOOLS_LIB -DQT_CORE_LIB -I. -I/usr/local/include/qt5 -I/usr/local/include/qt5/QtWidgets -I/usr/local/include/qt5/QtGui -I/usr/local/include/qt5/QtScript -I/usr/local/include/qt5/QtScriptTools -I/usr/local/include/qt5/QtCore -I. -I/usr/local/include -I. -I/usr/local/include -I/usr/local/lib/qt5/mkspecs/freebsd-clang -o projectwindow.o projectwindow.cpp > 1 error generated. > gmake[1]: *** [Makefile.qmake:16495: build/qmc2main.o] Error 1
*** Bug 285596 has been marked as a duplicate of this bug. ***
(In reply to Alastair Hogge from comment #1) > Split compat layer into different source files: https://github.com/zlib-ng/minizip-ng/pull/809 In 2 words: mz_compat.h replaced with ioapi.h, unzip.h, zip.h. Example of patch: https://github.com/Homebrew/homebrew-core/pull/203623/files#diff-e137f14432a3f2036d056383805cab88987d61c007b0b1a3659a6a0b100b4352L54-R54 Full list of mz_compat.h usage: src/arcade/imageprovider.h:#include "../minizip/mz_compat.h" src/collectionrebuilder.cpp:#include "mz_compat.h" src/filesystemmodel.h:#include "mz_compat.h" src/imagechecker.cpp:#include "mz_compat.h" src/imagechecker.h:#include "mz_compat.h" src/imagewidget.h:#include "mz_compat.h" src/machinelist.cpp:#include "mz_compat.h" src/options.cpp:#include "mz_compat.h" src/qmc2main.cpp:#include "mz_compat.h" src/romalyzer.cpp:#include "mz_compat.h" src/softwarelist.h:#include "mz_compat.h" "Simple" way is to replace every: #include "mz_compat.h" with: #include "ioapi.h" #include "unzip.h" #include "zip.h" The best way to add only those includes that are needed in each specific case. But it is labor-intensive. Hack way - create file emulators/qmc2/files/patch-src_mz__compat.h: --- src/mz_compat.h.orig 1970-01-01 00:00:00 UTC +++ src/mz_compat.h @@ -0,0 +1,3 @@ +#include "ioapi.h" +#include "unzip.h" +#include "zip.h" But I don't have time to build such huge ports as emulators/mame, emulators/qmc2, www/qt5-webengine.
(In reply to Vladimir Druzenko from comment #3) You can't just commit stuff and hope that it works, if you're unable to test commits you need to ask someone.
(In reply to Daniel Engberg from comment #4) You seem to have completely misunderstood me: I am not yet suggesting to commit anything, I am showing the paths that can be taken to create a patch and, since I cannot quickly check, I suggest that this be done by someone who can…
(In reply to Vladimir Druzenko from comment #5) For your memory, we went to exhaustive lengths last time we updated minizip-io, bug #275303. I believe Daniel is suggesting we should have maintained that process, before committing the most recent minizip-io update, https://cgit.freebsd.org/ports/commit/?id=fa698dcc38c78e6a4e3a697df1ad3a5d1b75bd02
(In reply to Vladimir Druzenko from comment #5) Thanks for the suggestion, it will help when I get around to this.
(In reply to Alastair Hogge from comment #6) There was a major version update, that's why everything took so long to test. And here is a patch-level update and even here they managed to break backward compatibility…
Created attachment 258965 [details] emulators/qmc2/files/patch-src_mz__compat.h Save this file to emulators/qmc2/files/patch-src_mz__compat.h. Build fine in poudriere 14.2 amd64. This is copy of mz_compat.h file from minizip-ng 4.0.7.
(In reply to Vladimir Druzenko from comment #8) > There was a major version update, that's why everything took so long to test. That is not an excuse; as was suggested, you could have just asked for assistance. > And here is a patch-level update and even here they managed to break backward compatibility… That is an excuse (a very good one too) to follow the same procedures as was undertaken on the major version update.
I will work an update of qmc2 incorporating vvd@ patch.
(In reply to Alastair Hogge from comment #10) Developers have a shortage of time and computing resources - we cannot test every change so thoroughly unless there is a good reason for it.
(In reply to Vladimir Druzenko from comment #12) But you should test consumers overall, since this breaks consumers I'd suggest that you revert it.
(In reply to Daniel Engberg from comment #13) If I'm not mistaken, last time building this port in poudriere with all dependencies took more than a day. I can't afford that. I can request exp-run next time.
(In reply to Alastair Hogge from comment #11) https://github.com/zlib-ng/minizip-ng/releases/tag/4.0.9 released 10 days ago. Can you test your new version of the emulators/qmc2 with new version of the minizip-ng? Patch is trivial: --- archivers/minizip-ng/Makefile.orig +++ archivers/minizip-ng/Makefile @@ -1,5 +1,5 @@ PORTNAME= minizip-ng -DISTVERSION= 4.0.8 +DISTVERSION= 4.0.9 CATEGORIES= archivers MAINTAINER= vvd@FreeBSD.org --- archivers/minizip-ng/distinfo.orig +++ archivers/minizip-ng/distinfo @@ -1,3 +1,3 @@ -TIMESTAMP = 1736424062 -SHA256 (zlib-ng-minizip-ng-4.0.8_GH0.tar.gz) = c3e9ceab2bec26cb72eba1cf46d0e2c7cad5d2fe3adf5df77e17d6bbfea4ec8f -SIZE (zlib-ng-minizip-ng-4.0.8_GH0.tar.gz) = 770957 +TIMESTAMP = 1744565051 +SHA256 (zlib-ng-minizip-ng-4.0.9_GH0.tar.gz) = 353a9e1c1170c069417c9633cc94ced74f826319d6d0b46d442c2cd7b00161c1 +SIZE (zlib-ng-minizip-ng-4.0.9_GH0.tar.gz) = 772117
(In reply to Vladimir Druzenko from comment #15) Will attempt to test during the weekend, thanks.
(In reply to Vladimir Druzenko from comment #12) > Developers have a shortage of time and computing resources - we cannot test every change so thoroughly unless there is a good reason for it. For fuck sake, comrade, you fucked up. I already tried to explain, many hands make lite work, had you sung out for more computing resources, and requested to share the load, this current situation could have been avoided. I find your explanations...boring, puerile deflections. From a contributor who respects you as a community member, and a committer, I am saddened that you make the efforts to undermine my respect for you, and I begin to ruminate your motive. Fucking sucks, to say the least.
(In reply to Daniel Engberg from comment #13) > But you should test consumers overall, since this breaks consumers I'd suggest that you revert it. Please allow me the weekend to attend to the Port, the less Tree churn the better?