Created attachment 186609 [details] patch With the NLS option turned off: ===> rrdtool-1.7.0 depends on shared library: libcairo.so - found (/usr/local/lib/libcairo.so) ===> rrdtool-1.7.0 depends on shared library: libglib-2.0.so - found (/usr/local/lib/libglib-2.0.so) ===> rrdtool-1.7.0 depends on shared library: libintl.so - found (/usr/local/lib/libintl.so) ===> rrdtool-1.7.0 depends on shared library: libxml2.so - found (/usr/local/lib/libxml2.so) ===> rrdtool-1.7.0 depends on shared library: libpango-1.0.so - found (/usr/local/lib/libpango-1.0.so) ===> Checking if rrdtool already installed ===> Registering installation for rrdtool-1.7.0 pkg-static: Unable to access file /usr/obj/usr/ports/databases/rrdtool/work/stage/usr/local/share/locale/hu/LC_MESSAGES/rrdtool.mo:No such file or directory *** Error code 74 Stop. make[1]: stopped in /usr/ports/databases/rrdtool *** Error code 1 Stop. make: stopped in /usr/ports/databases/rrdtool
Here is a patch that supports the NLS options. https://reviews.freebsd.org/D12459
That patch is not correct, as it will only cover Hungarian NLS parlance. The directory containing the /hu/ path element is just a dangling left-over. Actually, the NLS option should be working fine and install all NLS related files automatically. (Did not try it though.)
With the second patch, packaging works and the build finishes when the NLS option is OFF or ON. Did you try building with your patch applied when the NLS options was OFF then ON?
See the subject... Indeed your patch "fixes" it. But in an inappropriate way: It's just covering a special NLS case for the Hungarian language that would be automatically covered by the build framework tied into the NLS option. My trivial "patch" is simple removing that obsolete /hu/ line.
I'm not sure what I am supposed to see in the subject. With the first patch applied, the build fails with the NLS option ON. It's clearly broken. It fails because that Hungarian .mo file *is actually installed* when the NLS option is ON. Look in the stage directory.
A commit references this bug: Author: zeising Date: Fri Sep 22 15:11:16 UTC 2017 New revision: 450381 URL: https://svnweb.freebsd.org/changeset/ports/450381 Log: Fix build without NLS PR: 222507 Reported by: Helge Oldach Changes: head/databases/rrdtool/Makefile head/databases/rrdtool/pkg-plist
Fixed.
It's a trivial patch, but I think it's uncooperative to ignore a submitted patch (Phabricator revision), then apply the identical patch.
Subject says: "install fails with NLS off" - hence: a) I'm reporting a bug during *install*. The *build* works fine for me. If you face a *build* issue I suggest that you separate that from this *install* issue and file a separate bug report. b) I'm reporting about the non-NLS case. Again: Your "fix" indeed works fine for my non-NLS case! Actually I do not care as long as it's fixed for me. (FWIW, I tested the NLS case with my "patch": both *build* and *install* work correct for me.)
(In reply to Helge Oldach from comment #10) > Actually I do not care as long as it's fixed for me. Other people may wish to turn the NLS option ON. With your patch applied, the installation _will_ fail. > (FWIW, I tested the NLS case with my "patch": both *build* and *install* work correct for me.) You are saying you tested with your patch applied and the NLS ON and the installation succeeded? This is simply not correct. Either you did not test properly or you are mistaken. > That patch is not correct, as it will only cover Hungarian NLS parlance. Please check which patch was applied and please temper your arrogance.
(In reply to Joseph Mingrone from comment #9) I was not aware of the patch, since it was not attached to the PR. I looked at the patch here, and since it was not complete, I fixed it myself. Sorry.
(In reply to Helge Oldach from comment #10) Do you still have issues with the port? I committed a change yesterday that at least for me works in both the NLS and the !NLS case. If you still have issues with the port, please provide logs and such so I can investigate. Thanks!
*** Bug 222521 has been marked as a duplicate of this bug. ***
(In reply to Niclas Zeising from comment #12) The second patch was referenced in comment #1, but I apparently jumped to a wrong conclusion about why it was ignored. The problem is fix. All is well. Thanks.