Created attachment 257706 [details] [PATCH] math/nlopt: update 2.9.1 => 2.10.0 v2.10.0 Latest New Java bindings (#578). Allow disabling exceptions with set_exceptions_enabled (#580). Configurable tolg tolerance parameter for Luksan gradient stopping condition (#585). Restored LD_LBFGS_NOCEDAL enum value (dropped in 2.9) to ease backwards compatibility for wrappers in other languages (though this algorithm is currently unimplemented) (#587).
Hi Älven, Many thanks, really appreciated! I've been trying to write a suitable patch for some time now alongside my work, but I just haven't got any further. Unfortunately, in Poudriere (15.0-CURRENT amd64) I get the following plist errors with FLAVOR=minimal: ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist Error: Orphaned: include/nlopt.h Error: Orphaned: include/nlopt.hpp Error: Orphaned: lib/cmake/nlopt/NLoptConfig.cmake Error: Orphaned: lib/cmake/nlopt/NLoptConfigVersion.cmake Error: Orphaned: lib/cmake/nlopt/NLoptLibraryDepends-%%CMAKE_BUILD_TYPE%%.cmake Error: Orphaned: lib/cmake/nlopt/NLoptLibraryDepends.cmake Error: Orphaned: lib/libnlopt.so Error: Orphaned: lib/libnlopt.so.1 Error: Orphaned: lib/libnlopt.so.1.0.0 Error: Orphaned: libdata/pkgconfig/nlopt.pc Error: Orphaned: share/man/man3/nlopt.3.gz Error: Orphaned: share/man/man3/nlopt_minimize.3.gz Error: Orphaned: share/man/man3/nlopt_minimize_constrained.3.gz ===> Checking for items in pkg-plist which are not in STAGEDIR ===> Error: Plist issues found. In unclean environment (15.0-CURRENT amd64), I get the following error with FLAVOR=full: -- Configuring done (3.1s) -- Generating done (0.0s) CMake Warning: Manually-specified variables were not used by the project: BOOST_PYTHON_SUFFIX CMAKE_VERBOSE_MAKEFILE FETCHCONTENT_FULLY_DISCONNECTED Python3_EXECUTABLE Python_ADDITIONAL_VERSIONS THREADS_HAVE_PTHREAD_ARG -- Build files have been written to: /poudriere/ports/default/math/nlopt/work-full/.build ===> Building for nlopt-2.10.0 ninja: error: 'src/swig/nlopt_java_swig_compilation', needed by 'src/swig/java_sources.txt', missing and no known rule to make it ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Do you have any idea for the second problem?
Created attachment 257710 [details] [PATCH] math/nlopt: update 2.9.1 => 2.10.0 Always glad to know my work is appreciated! :) This is my first experience with flavours. Fixed flavours. Hope it will help with pkg-plists too. > Do you have any idea for the second problem? Sorry, I know nothing about swig, may just hope this could fix it too. Could you, please, test it once more?
P.S. I'm rather cautious to run CURRENT as my daily driver (afraid of kernel panics and similar), so just had tested it on 14.2, 14.1 and 13.4… What could you tell me about CURRENT? Is it safe enough for run even for a newcomer, like me? I run it 24/7 as my home server+desktop, nothing mission-critical, just afraid of crashes and data loss…
Created attachment 257712 [details] [PATCH] math/nlopt: update 2.9.1 => 2.10.0 Small improvement
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=11c19f031c208fe9e53c4d5953d28fb888962f12 commit 11c19f031c208fe9e53c4d5953d28fb888962f12 Author: Älven <alster@vinterdalen.se> AuthorDate: 2025-03-01 14:51:27 +0000 Commit: Rainer Hurling <rhurlin@FreeBSD.org> CommitDate: 2025-03-01 15:09:11 +0000 math/nlopt: Update from 2.9.1 to 2.10.0 - New Java bindings - Allow disabling exceptions with set_exceptions_enabled - Configurable tolg tolerance parameter for Luksan gradient stopping condition - Restored LD_LBFGS_NOCEDAL enum value (dropped in 2.9) to ease backwards compatibility for wrappers in other languages (though this algorithm is currently unimplemented) Changelog: https://github.com/stevengj/nlopt/blob/master/NEWS.md#nlopt-210 PR: 284934 Reported by: portscout, Repology math/nlopt/Makefile | 37 +++++++++++++------------- math/nlopt/distinfo | 6 ++--- math/nlopt/files/patch-src_swig_CMakeLists.txt | 13 +++++---- math/nlopt/pkg-plist | 4 +-- math/nlopt/pkg-plist.full (new) | 18 +++++++++++++ 5 files changed, 48 insertions(+), 30 deletions(-)
Hi Älven, I have just committed your patch with some minor changes: - Customize guile naming - Add CMAKE_OFF=NLOPT_JAVA to all flavors - Move PLIST to the FLAVOR==full context If a JAVA version is installed when building in an unclean environment, nlopt tries to use it and fails. I have not been able to identify the reason for this. Before moving PLIST, the build looked for pkg-plist.minimal for FLAVOR=minimal. In this case, however, pkg-plist should be used With these changes, there should be no more problems building and installing the port in Poudriere and outside (in unclean environments) ;) Regarding your question about CURRENT: I have been using CURRENT exclusively on several boxes for many years. 'Base' I update once a week, 'ports' I build mostly via Portmaster, if not possible in Poudriere. I do not use pkg directly. In my opinion, CURRENT is very stable and I have never experienced any data loss. Thanks again for the patch!
Thank you for kind and detailed explanation! Glad you have solved the issue with Java. The only thing I still can't understand and may kindly ask you, whether you would like to explain to me in details is this: > Before moving PLIST, the build looked for pkg-plist.minimal for FLAVOR=minimal. > In this case, however, pkg-plist should be used From the principle of least astonishment one may (and likely will) expect that all the flavors are born equal, so are the corresponding named pkg-<flavor> plists. That's why I just wrote PLIST= ${PKGDIR}/pkg-plist.${FLAVOR} out of scope of any conditions, assuming it to be applied just as orthogonal as it was written: every flavor to use their dedicated plist-<flavor>, without any implied default ones: FLAVOR=full => PLIST=pkg-plist.full FLAVOR=minimal => PLIST=pkg-plist.minimal And it all worked well for me. Then you told me the default, unflavored pkg-plist should be used. I just wonder why? Why can't it work without default one? And why it worked for me, but not for you? Thanks in advance
(In reply to Älven from comment #7) >FLAVOR=full => PLIST=pkg-plist.full >FLAVOR=minimal => PLIST=pkg-plist.minimal I think this is the cause of the misunderstanding: There was never a pkg-plist.minimal, only a pkg-plist. With v2.7.1[1] I introduced a mechanism in the Makefile (and corrected it in v2.8.0), which uses pkg-plist for @minimal, and added the entries in 'PLIST+=' to pkg-plist for @full. So my recent commit preserved the (existing aka minimal) pkg-plist and added a pkg-plist.full. Overall, my previous approach of adding missing entries to the Makefile via PLIST would have continued to work. But I decided to follow your suggestion ;) [1] https://cgit.freebsd.org/ports/commit/?id=7c6de6cb9652c5af4852ace681208646b93ed716
(In reply to Rainer Hurling from comment #8) > I think this is the cause of the misunderstanding: There was never a pkg-plist.minimal, only a pkg-plist. I was sure I added this file rename from pkg-plist to pkg-plist.minimal to my patch [0]. Still it may be something went wrong with it. Or likely it was me who may just made the patch wrong way? :) Just tell me it was so and I'll investigate and learn more about Magit and all this: how to deal with file renames properly and how to check they are exported as patch right way. Indeed I see something strange with the patch: --- b/math/nlopt/pkg-plist.minimal +++ b/math/nlopt/pkg-plist.minimal It should be: --- b/math/nlopt/pkg-plist +++ b/math/nlopt/pkg-plist.minimal Sorry if this made my patch confusing to you: it was unintentionally, I was unaware of this before you told me the rename wasn't scheduled when you applied my patch. [0] https://bugs.freebsd.org/bugzilla/attachment.cgi?id=257712&action=diff#b/math/nlopt/pkg-plist.minimal_sec1
P.S. Here is my original working branch for this issue [0]. I clearly see the rename here. So can't guess what may went wrong… > But I decided to follow your suggestion ;) Really? :) Thank you: I was glad to read this from you :) [0] https://git.sr.ht/~alster/freebsd-ports/commit/b011dfd3e212feece235ddfcd19e578e6ca1d0e2
Älven, Yes, I see, in your repo is was a 'rename' with attribute 'R'. No idea, what was going wrong afterwards. I am not a Git specialist and have little experience with it. When I need to rename a file in the repository, I use 'git mv' and then add the file with 'git add' before a commit. There are probably other ways to do this, but it works ;) The current naming is not a problem for me at all. If you agree, we can leave everything as it is.
Rainer, I'm sorry, I'm likely talking about this issue more than you may like. I glad to have you liked and used my humble work for your maintained port. I wouldn't be asking you of anything else. > The current naming is not a problem for me at all. If you agree, we can leave everything as it is. I strongly believe in freedom of self-expression for all. You don't need anyone else (especially mine) agreement for anything you do. I also dream of such freedom for myself and sure won't try to deprive you from it. Please, take my regrets for ever making you feel this way as to ever depend on my agreement. I may be just trying to change too many things around me. I myself likely will feel better playing in my own sandbox than asking other people to discuss their creative efforts with me. I'm all for freedom. For everyone.
I had thought about it and researched it for some time before I decided to use your suggestion for dealing with the plist entries. There are examples in the Ports Tree for my previous approach (adding entries to the plist in the Makefile) and for your suggested change (a separate Makefile for each flavor). Both are relatively equivalent as long as the differences between the plists are not too extensive. So as I said, for me it's fine the way it is now :)