In trying to update maxima from 5.44.0_11 to 5.44.0_12. The port builds fine, but I find a failure at the install stage: ===> Registering installation for maxima-5.44.0_12 pkg-static: Unable to access file /usr/ports/math/maxima/work/stage/usr/local/lib/maxima/5.44.0/binary-ecl/maxima:No such file or directory pkg-static: Unable to access file /usr/ports/math/maxima/work/stage/usr/local/libexec/maxima/5.44.0/mgnuplot:No such file or directory *** Error code 1 As it turns out, the staged files are NOT in a "5.44.0" directory in the staging directory where they're expected, they're instead in a directory that looks unrelated to the actual PORTVERSION in the Makefile: # ls work/stage/usr/local/lib/maxima 10_eol_85992_gb8aceeb60194 # ls work/stage/usr/local/libexec/maxima/ 10_eol_85992_gb8aceeb60194 > grep PORTVERSION Makefile PORTVERSION= 5.44.0 MASTER_SITES= SF/maxima/Maxima-source/${PORTVERSION}-source PLIST_SUB+= PORTVERSION=${PORTVERSION} These oddly named directories in the staging area do contain exactly the files that should be getting installed, but the name of the directory they're in is not "5.44.0" so the install fails. This is off of an up-to-date git clone of ports (from https://git.freebsd.org/ports.git). The most recent git commit in my maxima directory is: commit 442edd8bc1e4d7c336d7573bb977bae7419832b3 Author: Kirill Ponomarev <krion@FreeBSD.org> Date: Thu Apr 29 19:51:54 2021 +0200 Bump PORTREVISION on *-sbcl ports after lang/sbcl upgrade. (I should note that my maxima is built with ECL not SBCL, so I didn't really need this update) The most recent commit in my ports tree is: commit b8aceeb60194bcd8f8caf6789193c46271d3480e (HEAD -> main, origin/main, origin/HEAD) Author: Dimitry Andric <dim@FreeBSD.org> Date: Thu May 6 23:29:24 2021 +0200 I note that there is already a bug 247955 open about maxima packaging problems, but that one seems unrelated to this. It appears that for whatever reason, the incorrect portversion is being used to create the staging directories, but I don't even know where to look for how that could be going wrong or where it's getting this "10_eol_85992_gb8aceeb60194" --- the only place that string appears is in the work directory, and it's all over the place. I've cleaned out the port directory and done a "make patch" and grepped the work directory to see if somehow this strange string gets created early in the process, but it's not there this early. The string is all over the place at the end of a "make", though: # grep -r '10_eol' * | head work/maxima-5.44.0/interfaces/xmaxima/Tkmaxima/Header.tcl:# version 10_eol_85992_gb8aceeb60194 was used. work/maxima-5.44.0/interfaces/xmaxima/msgs/Makefile:VERSION = 10_eol_85992_gb8aceeb60194 work/maxima-5.44.0/interfaces/xmaxima/msgs/Makefile:verpkglibdir = $(pkglibdir)/10_eol_85992_gb8aceeb60194 work/maxima-5.44.0/interfaces/xmaxima/msgs/Makefile:verpkglibexecdir = $(libexecdir)/maxima/10_eol_85992_gb8aceeb60194 work/maxima-5.44.0/interfaces/xmaxima/msgs/Makefile:verpkgdatadir = $(pkgdatadir)/10_eol_85992_gb8aceeb60194 ... (it appears over 2700 times)
Note that the odd string in the staging directory name appears to be related to the git SHA-1 of the most recent commit in my ports tree. I don't know how *that* is happening, but it's probably a clue.
Do you still have this problem? I am unable to reproduce this with PORTVERSION= 5.44.0 PORTREVISION= 13 in a clean environment (poudriere).
I have not tried since reporting it, but am firing up an attempt right now. Will let you know the results.
Yes, I am still seeing the same thing: ===> Installing for maxima-5.44.0_12 ===> Checking if maxima is already installed ===> Registering installation for maxima-5.44.0_12 pkg-static: Unable to access file /usr/ports/math/maxima/work/stage/usr/local/lib/maxima/5.44.0/binary-ecl/maxima:No such file or directory pkg-static: Unable to access file /usr/ports/math/maxima/work/stage/usr/local/libexec/maxima/5.44.0/mgnuplot:No such file or directory *** Error code 1 Stop. make[1]: stopped in /usr/ports/math/maxima *** Error code 1 Stop. make: stopped in /usr/ports/math/maxima Looking in the staging directory: # ls work/stage/usr/local/lib/maxima/ 10_eol_89004_g447bf1139fcb The name of the directory is still related to the git HEAD of my ports clone: commit 447bf1139fcbaa3beb5142a88e636c7a56e8d5ea (HEAD -> main, origin/main, origin/HEAD) Author: Greg Fitzgerald <gregf@beastie.tech> Date: Thu Jun 3 16:32:02 2021 -0400 www/gitea: Update to 1.14.2 I have no idea how the ports system is getting the "10_eol_89004" nonsense along with the git SHA-1 for the maxima version, but it clearly is.
I just tried to build maxima on a different BSD system of exactly the same version, but which has never had maxima or ECL installed on it before. I experienced exactly the same problem, with this "10_eol_..." junk all over the place wherever a version was supposed to be.
(In reply to russo from comment #5) That is frustrating. Could you: * make distclean && make * Attach the full log if possible
(In reply to Fernando Apesteguía from comment #6) As far as it being very frustrating, trust me, I feel your pain. I am running the distclean/make process you requested now and will attach the "typescript" of the entire process when it's done.
Created attachment 225719 [details] "typescript" of output of "make distclean && make" and subsequent actions As requested, this is the log of what the build process did when following the direction to "make distclean && make" I also checked for the presence of the string "10_eol" in the work tree after the make finished, and it found more than 2700 lines containing that string. And finally, I show that the git SHA of my ports tree clone HEAD is the hex number that appears in the weird "10_eol_XXXX_gSHA" string. Had to bzip it to get it small enough for bugzilla to accept.
(In reply to russo from comment #8) Thanks a lot for the log. See here: https://cgit.freebsd.org/ports/ and search for "10_eol" in the page. Is it possible that you cloned a specific tag? 10-eol ports-10-eol.tar.gz ports-10-eol.zip Rene Ladan 3 years Cheers
(In reply to Fernando Apesteguía from comment #9) No, I did not clone a tag. I cloned the full repo and checked out the "main" branch with "git clone https://git.freebsd.org/ports.git" It has been kept up-to-date with the remote with periodic "git pull", and I've never checked out any branch other than "main".
(In reply to russo from comment #10) And just for completeness, /usr/src is also a git clone of "https://git.freebsd.org/src.git", and *it* is checked out to the stable/11 branch. So there's nothing that should be referring to 10_eol that I know of.
(In reply to russo from comment #11) And now that I say that, I realize I left out a piece of information that is supposed to be part of all bug reports, my "uname" output: FreeBSD bogodyn.org 11.4-STABLE FreeBSD 11.4-STABLE #0 stable/11-n215696-62607e8680e: Tue Feb 16 19:28:06 MST 2021 xxxxx@yyyyyyy.org:/usr/obj/usr/src/sys/GENERIC amd64 Not that this seems to contain any thing relevant.
(In reply to russo from comment #12) I don't know what the hell is going on. On a clean environment it builds fine (revision _13 now). At the risk of abusing your patience. Would you attach the result of: make -dA Let's see where is that 10_eol coming from with the help of debug info.
(In reply to Fernando Apesteguía from comment #13) Building it again is no skin off my nose, and I'm running a make -dA right now. Will attach the typescript when it's done.
(In reply to russo from comment #14) I would be delighted to attach the typescript of "make -dA" but it is too large for bugzilla, even after bzipping. Not sure how to proceed from here. I do note that the "10_eol" thing does not appear anywhere in the typescript until one of the staging directories gets its "mkdir". It's first appearance in the typescript is here: ``` No need to remake target 'binary-ecl/maxima'. Finished prerequisites of target file 'install-ecllibSCRIPTS'. Must remake target 'install-ecllibSCRIPTS'. Putting child 0x801258660 (install-ecllibSCRIPTS) PID 75317 on the chain. Live child 0x801258660 (install-ecllibSCRIPTS) PID 75317 /bin/mkdir -p '/usr/ports/math/maxima/work/stage/usr/local/lib/maxima/10_eol_90285_g1ebf3e6b99c1/binary-ecl' install -m 555 binary-ecl/maxima '/usr/ports/math/maxima/work/stage/usr/local/lib/maxima/10_eol_90285_g1ebf3e6b99c1/binary-ecl' Reaping winning child 0x801258660 PID 75317 Removing child 0x801258660 PID 75317 from chain. ```
(In reply to russo from comment #15) > the typescript of "make -dA" [...] is too large for bugzilla, even after bzipping. Not sure how to proceed from here. Yes, for something like this, bug databases do not fare well. Perhaps uploading it to one of the pastebin-like sites is better (or somewhere on your own site if you maintain one).
(In reply to Mark Linimon from comment #16) You can find it at: http://pages.swcp.com/~russo/typescript.bz2
I built maxima in a 11.4 amd64 jail and found some differences in out build outputs. I don't have these warnings: /usr/local/share/aclocal/libstroke.m4:29: warning: underquoted definition of smr_ARG_WITHLIB /usr/local/share/aclocal/libstroke.m4:29: run info Automake 'Extending aclocal' /usr/local/share/aclocal/libstroke.m4:29: or see https://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal At some point later during the configure phase: checking for python version... ./configure: dummy: not found checking for python platform... ./configure: dummy: not found checking for python script directory... ./configure: dummy: not found checking for python extension module directory... ./configure: dummy: not found I think there might be something wrong with your python installation. The only two differences between your configure phase and mine are that I do not have emacs or git installed in the jail while you have both. Two more warnings a bit later: Makefile:1041: warning: overriding recipe for target 'rpm' Makefile:949: warning: ignoring old recipe for target 'rpm' Then, there seems to be something really wrong: /bin/sh '/usr/ports/math/maxima/work/maxima-5.44.0/missing' makeinfo \ --split-size=1000000 ./maxima.texi File "make-categories.py", line 3 @anchor{Item: Affine/node/Introduction to Affine}n@node Introduction to Affine, Functions and Variables for Affine, Affine, Affine ^ SyntaxError: invalid syntax ./include-maxima.texi:48: warning: redefining Texinfo language command: @var ./include-maxima.texi:89: warning: @node should only appear at the beginning of a line ./include-maxima.texi:640: warning: @node should only appear at the beginning of a line ./include-maxima.texi:644: warning: @node should only appear at the beginning of a line ./Bugs.texi:6: warning: @node should only appear at the beginning of a line ./include-maxima.texi:648: warning: @node should only appear at the beginning of a line ./Help.texi:7: warning: @node should only appear at the beginning of a line ./Help.texi:46: warning: @node should only appear at the beginning of a line ./include-maxima.texi:652: warning: @node should only appear at the beginning of a line ./Command.texi:8: warning: @node should only appear at the beginning of a line ./Command.texi:15: warning: @node should only appear at the beginning of a line ./Command.texi:1053: warning: @node should only appear at the beginning of a line ./include-maxima.texi:656: warning: @node should only appear at the beginning of a line ./DataTypes.texi:11: warning: @node should only appear at the beginning of a line ... ... there are hundres of messages like those. Then another hundres of messages like these: ./Number.texi:1060: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Number.texi:1097: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Number.texi:1111: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Number.texi:1146: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Number.texi:1226: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Number.texi:1340: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Number.texi:1463: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Number.texi:1522: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Number.texi:1625: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Number.texi:1692: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Number.texi:1706: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Number.texi:1757: @ref reference to nonexistent node `Category: Predicate functions' (possibly involving @category) ./Number.texi:1758: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Number.texi:1777: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Number.texi:1790: @ref reference to nonexistent node `Category: Number theory' (possibly involving @category) ./Symmetries.texi:44: @ref reference to nonexistent node `Category: Group theory' (possibly involving @category) ./Symmetries.texi:45: @ref reference to nonexistent node `Category: Polynomials' (possibly involving @category) ./Symmetries.texi:46: @ref reference to nonexistent node `Category: Share packages' (possibly involving @category) ./Symmetries.texi:47: @ref reference to nonexistent node `Category: Package sym' (possibly involving @category) ./Symmetries.texi:77: @ref reference to nonexistent node `Category: Package sym' (possibly involving @category) ./Symmetries.texi:89: @ref reference to nonexistent node `Category: Package sym' (possibly involving @category) ./Symmetries.texi:101: @ref reference to nonexistent node `Category: Package sym' (possibly involving @category) ./Symmetries.texi:145: @ref reference to nonexistent node `Category: Package sym' (possibly involving @category) ./Symmetries.texi:205: @ref reference to nonexistent node `Category: Package sym' (possibly involving @category) I don't know how these warnings relate to your specific problem, but it might be worth to have a look at them. I also installed emacs and git in the jail and I was able to build math/maxima without problems. I'm running out of ideas here :S
(In reply to Fernando Apesteguía from comment #18) Well, I really don't know where to look for a problem with my python install --- it's just a port install of python3-3_3 and a boatload of py38 packages (almost all automatic installs as dependencies of something else: py38-CommonMark-0.9.1 Python parser for the CommonMark Markdown spec py38-Jinja2-2.11.2_1 Fast and easy to use stand-alone template engine py38-alabaster-0.7.12 Modified Kr Sphinx theme py38-altgraph-0.15 Python graph (network) package py38-asn1crypto-1.4.0 ASN.1 library with a focus on performance and a pythonic API py38-beaker-1.11.0 Session and Caching library with WSGI Middleware py38-beautifulsoup-4.9.3 HTML/XML Parser for Python py38-boost-libs-1.72.0_1 Framework for interfacing Python and C++ py38-cairo-1.18.1_1,1 Python bindings for Cairo py38-cairocffi-1.2.0 CFFI-based Cairo bindings for Python py38-certifi-2021.5.30 Mozilla SSL certificates py38-cffi-1.14.5 Foreign Function Interface for Python calling C code py38-chardet-4.0.0,1 Universal encoding detector for Python 2 and 3 py38-cryptography-3.3.2 Cryptographic recipes and primitives for Python developers py38-cycler-0.10.0 Composable style cycles py38-cython-0.29.23 Compiler for Writing C Extensions for the Python Language py38-dateutil-2.8.1 Extensions to the standard Python datetime module py38-dnspython-1.16.0 DNS toolkit for Python py38-docutils-0.17.1 Python Documentation Utilities py38-evdev-1.4.0 Bindings to the Linux input handling subsystem py38-furo-2021.4.11b34 Clean customizable Sphinx documentation theme py38-future-0.18.2 Clean single-source support for Python 3 and 2 py38-gi-docgen-2021.5 Documentation generator for GObject-based libraries py38-gobject3-3.38.0 Python 3.8 bindings for GObject py38-html5lib-1.0.1 Python based HTML parser based on the HTML5 spec py38-httplib2-0.19.1 Comprehensive HTTP client library py38-idna-2.10 Internationalized Domain Names in Applications (IDNA) py38-imagesize-1.2.0 Get image size from png/jpeg/jpeg2000/gif file py38-importlib-metadata-3.3.0_1 Read metadata from Python packages py38-isodate-0.6.0 ISO 8601 date/time/duration parser and formater py38-kiwisolver-1.1.0,1 Fast implementation of the Cassowary constraint solver py38-libxml2-2.9.10_4 Python interface for XML parser library for GNOME py38-lxml-4.6.3 Pythonic binding for the libxml2 and libxslt libraries py38-mako-1.0.14_1 Super-fast templating language in Python py38-markdown-3.3.4 Python implementation of Markdown py38-markupsafe-1.1.1_1 Implements XML/HTML/XHTML Markup safe string for Python py38-matplotlib-3.4.1 Plotting library uses a syntax familiar to MATLAB users py38-nose-1.3.7_1 Discovery-based unittest extension py38-numpy-1.16.6_1,1 The New Numeric Extension to Python py38-olefile-0.46 Python module to read MS OLE2 files py38-openssl-20.0.1 Python interface to the OpenSSL library py38-packaging-20.9 Core utilities for Python packages py38-pillow-8.2.0 Fork of the Python Imaging Library (PIL) py38-pip-20.3.4 Tool for installing and managing Python packages py38-pluggy-0.13.1 Plugin and hook calling mechanisms for Python py38-ply-3.11 Python Lex-Yacc py38-pybind11-2.6.2 Seamless interoperability between C++11 and Python py38-pycparser-2.20 C parser in Python py38-pygments-2.7.2 Syntax highlighter written in Python py38-pyinstaller-3.5_1 Program to create standalone executables from Python scripts py38-pypa-docs-theme-g20180622 Common base Sphinx theme for PyPA projects py38-pyparsing-2.4.7 General parsing module for Python py38-pyproj-3.1.0 Cython wrapper to provide python interfaces to PROJ.4 functions py38-pyserial-3.5 Serial port encapsulation library for Python py38-pysocks-1.7.1 Python SOCKS module py38-pystemmer-2.0.1 Snowball Stemming Algorithms for Information Retrieval py38-pytest-runner-5.3.1 Test support for pytest runner in setup.py py38-python-docs-theme-2018.2 Sphinx theme for the CPython docs and related projects py38-pytz-2021.1,1 World Timezone Definitions for Python py38-pyudev-0.22.0 Pure Python libudev binding py38-recommonmark-0.5.0_2 CommonMark bridge for docutils and Sphinx py38-requests-2.25.1 HTTP library written in Python for human beings py38-scipy-1.6.0 Scientific tools for Python py38-scour-0.38.1 Scour SVG Optimizer py38-setuptools-57.0.0 Python packages installer py38-setuptools_scm-4.1.2_1 Setuptools plugin to manage your versions by scm tags py38-sip-5.5.0_1,1 Python to C and C++ bindings generator py38-six-1.16.0 Python 2 and 3 compatibility utilities py38-smartypants-2.0.1 Translate plain ASCII punctuation into smart typographic HTML py38-snowballstemmer-2.1.0 Snowball stemming library collection for Python py38-soupsieve-2.0.1 CSS4 selector implementation for BeautifulSoup py38-sparqlwrapper-1.8.5 SPARQL endpoint interface to Python py38-sphinx-3.5.2,1 Python documentation generator py38-sphinx-inline-tabs-2021.4.11b9_1 Add inline tabbed content to your Sphinx documentation py38-sphinx_rtd_theme-0.4.3 Mobile-friendly py-sphinx theme py38-sphinxcontrib-applehelp-1.0.2 Extension which outputs Apple help books py38-sphinxcontrib-devhelp-1.0.2 Sphinx extension which outputs Devhelp document py38-sphinxcontrib-htmlhelp-1.0.3 Sphinx extension which renders HTML help files py38-sphinxcontrib-jsmath-1.0.1 Sphinx extension which renders display math in HTML via JavaScript py38-sphinxcontrib-qthelp-1.0.3 Sphinx extension which outputs QtHelp document py38-sphinxcontrib-serializinghtml-1.1.4 Sphinx extension which outputs serialized HTML files (json and pickle) py38-sphinxcontrib-websupport-1.2.4 Sphinx API for Web Apps py38-sqlite3-3.8.10_7 Standard Python binding to the SQLite3 library (Python 3.8) py38-tkinter-3.8.10_6 Python bindings to the Tk widget set (Python 3.8) py38-toml-0.10.2 Python library for parsing and creating TOML py38-tornado-6.1 Python Web Server from FriendFeed py38-typing-extensions-3.10.0.0 Backported and Experimental Type Hints for Python 3.5+ py38-typogrify-2.0.7 Filters to enhance web typography py38-urllib3-1.25.11,1 HTTP library with thread-safe connection pooling, file post, and more py38-webencodings-0.5.1 Character encoding aliases for legacy web content py38-xcffib-0.9.0 Replacement for xpyb and XCB Python bindings py38-zipp-3.4.0 Backport of pathlib-compatible object wrapper for zip files pybind11-2.6.2 Seamless interoperability between C++11 and Python (cmake part) pydbus-common-1.2.16 Common files for the Python bindings for the D-BUS messaging system pygobject3-common-3.38.0 Common files for the Python bindings for GObject python-3.8_3,2 "meta-port" for the default version of Python interpreter python3-3_3 The "meta-port" for version 3 of the Python interpreter python38-3.8.10 Interpreted object-oriented programming language scons-py38-3.1.2_1 Build tool alternative to make treepy.el-emacs27-0.1.2_1 Generic tree traversing tools for Emacs Lisp xdpyinfo-1.3.2_3 Display information utility for X (this is just "pkg info | grep py" so it picks up a bunch of other stuff that just happens to have py in it). That this same error is happening on two different FreeBSD 11 systems is really puzzling, since I would expect that a broken python install would be hard to have happen accidentally on two unrelated machines. The Texinfo/makeinfo warnings/errors are equally puzzling, since this is just a generic texinfo install, and it's automatic as well: > pkg query -e '%a=1' %o | grep texinfo print/texinfo
Ok, THIS is weird. Looking in the /usr/ports/math/maxima/work/maxima-5.44.0/config.log file, I find that configure was invoked like this: $ ./configure PYTHON=dummy --with-ecl=ecl --with-wish=/usr/local/bin/wish8.6 --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --disable-silent-rules --infodir=/usr/local/share/info/ --build=amd64-portbld-freebsd11.4 That really looks wrong, because it's putting "dummy" there for PYTHON explicitly. But in fact the Makefile in /usr/ports/math/maxima is explicitly putting it there in CONFIGURE_ARGS. I think the python thing might be a red herring.
I do note also that "10_eol" is clearly being introduced in the configure stage, somewhere where it sets VERSION. I'll have to dig more to see what the frak is putting it there. I'm attaching /usr/ports/math/maxima/work/maxima-5.44.0/config.log for good measure. It's pretty small.
Created attachment 225997 [details] The config.log produced during a build attempt of maxima The file does not show where "10_eol_..." is coming from, but somehow VERSION is being set to that right in here. I'll have to check to see if the make process is actually running autoconf/automake/etc. to produce configure or if it's pre-generated. Perhaps this is an autoconf/automake issue that is somehow borked.
Bingo. I see where this is happening now. The configure script for maxima has this: ' if test x"${git_found}" = xtrue; then # Test to see if git describe works (discarding any output). If # it works, use it. Otherwise, keep existing value of VERSION. # (git describe fails if git is executed in a non-Git directory, e.g., # an unpacked tarball. Since the exit codes of git describe are undocumented , # we cannot distinguish that from a missing annotated tag. # Play it safe by refusing to change VERSION.) if git describe > /dev/null 2>&1; then VERSION="`git describe --dirty`" # When building RPMs, hyphens in the version are not allowed, so # replace them with underscores. VERSION=`echo $VERSION | sed 's;-;_;g'` fi fi And guess what "git describe --dirty" outputs: 10-eol-90770-g4226927ef6b6 (this is, of course, a ports tree that has been updated since my last post to this thread). And this little mess is coming from THIS cute little bit of configure.ac: dnl See if git exists. If it does, update VERSION to include a git tag AC_CHECK_PROG(git_found, git, true, false) if test x"${git_found}" = xtrue; then # Test to see if git describe works (discarding any output). If # it works, use it. Otherwise, keep existing value of VERSION. # (git describe fails if git is executed in a non-Git directory, e.g., # an unpacked tarball. Since the exit codes of git describe are undocumented, # we cannot distinguish that from a missing annotated tag. # Play it safe by refusing to change VERSION.) if git describe > /dev/null 2>&1; then VERSION="`git describe --dirty`" # When building RPMs, hyphens in the version are not allowed, so # replace them with underscores. VERSION=`echo $VERSION | sed 's;-;_;g'` fi fi This is deliberately setting VERSION to a string that represents how many commits there have been since the last tag in the history, the name of that tag, and the git sha of the current commit. Somehow, this is not happening for you, but it is *definitely* happening for me. If git were not found, or if "git describe" didn't work, this wouldn't be a problem, as it would not clobber VERSION at all. Now, why VERSION is being used to name staging directories and using git to get the VERSION value is a question I can't answer. But perhaps a patch that took this bit out of configure.ac and configure, so that git is never used to get VERSION during package/port creation would be reasonable?
I will note that for whatever reason, the most recent tagged commit on the main branch happens to be 10-eol, commit 8aa70a974c02 (tag: 10-eol) Mark broken on FreeBSD 12 and 13 because OpenSSL 1.1.1. So "git describe" or "git describe --dirty" will always return 10-eol-<count>-g<sha1>. I think it is just inappropriate that it's being used to set the value of VERSION, *AND* this value of VERSION is being used to name directories. My best suggestion is just to patch away this silliness. It is probably of value to people using unreleased Maxima versions directly out of maxima's git repo, but it is of almost no value to those using only released versions inside a clone of the ports repo (so we're getting the git info from the PORTS versions, not even Maxima's).
I have created a patch for configure.ac that appears to do the trick, but will let my build/install complete to make sure it does everything it is supposed to. The build process *does* regenerate configure from configure.ac, so patching configure.ac seems to be all that's needed. I'll attach the patch that simply needs to be dropped into the "files" directory to make it work as soon as I confirm that it really does.
Yes, indeed by removing that bit of configure.ac (actually, just commenting it out), maxima builds and installs with no problem. I will attach patch-configure.ac shortly. If this is dropped into the "files" directory of math/maxima, this problem goes away.
Created attachment 225999 [details] Patch to disable setting VERSION from "git describe" output Maxima's configure.ac tries to set VERSION to something reflecting its git status instead of its release version if "git" is found and if "git describe" works. This is presumably so that users of maxima directly out of its git repo can have a version number that reflects the exact git commit being built rather than a release version number that might not be accurate. Problem is, "git describe" works even if the working directory is just a subdirectory of FreeBSD's ports tree, and returns something utterly useless for determining the Maxima version anyway. This patch simply comments out the bit of configure.ac that would set VERSION this way, and therefore leaves it at the release version (in this case, 5.44.0). With this patch, all my woes are gone.
(In reply to russo from comment #27) Glad to hear that you crack this!
(In reply to Fernando Apesteguía from comment #28) Yes, it is good to have solved the mystery. It would be great if that patch I attached could be added to the patches in the port, so the problem can go away.
(In reply to russo from comment #29) Sure thing. I'm testing in different FreeBSD versions to check that nothing breaks expect the patch to hit the tree in the next hours. Thanks!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=1b9b7e36375f51b5b1cfc50c46694885f1c63f47 commit 1b9b7e36375f51b5b1cfc50c46694885f1c63f47 Author: Fernando Apesteguía <fernape@FreeBSD.org> AuthorDate: 2021-06-23 06:38:17 +0000 Commit: Fernando Apesteguía <fernape@FreeBSD.org> CommitDate: 2021-06-23 16:32:56 +0000 math/maxima: Fix staging error configure.ac uses the git command if present to populate the VERSION variable. As a consecuence, this produces a dynamically changing installation directory in STAGEDIR that breaks the build in some conditions. Note that on a clean environment (poudriere), this works fine. This patch comments that portion of configure.ac out since it is of no use inside the ports tree. PR: 255683 Reported by: russo@bogodyn.org math/maxima/files/patch-configure.ac (new) | 39 ++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+)
Committed, Thanks!