Bug 255683 - math/maxima fails to install due to strange staging error
Summary: math/maxima fails to install due to strange staging error
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
Depends on:
Reported: 2021-05-07 14:28 UTC by russo
Modified: 2021-06-11 15:55 UTC (History)
1 user (show)

See Also:

"typescript" of output of "make distclean && make" and subsequent actions (92.34 KB, application/x-bzip2)
2021-06-10 23:12 UTC, russo
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description russo 2021-05-07 14:28:38 UTC
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

# ls work/stage/usr/local/libexec/maxima/

> grep PORTVERSION Makefile 
PORTVERSION=    5.44.0
MASTER_SITES=   SF/maxima/Maxima-source/${PORTVERSION}-source

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)
Comment 1 russo 2021-05-07 14:30:55 UTC
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.
Comment 2 Fernando Apesteguía freebsd_committer 2021-06-10 14:07:17 UTC
Do you still have this problem?

I am unable to reproduce this with 

PORTVERSION=    5.44.0

in a clean environment (poudriere).
Comment 3 russo 2021-06-10 15:00:59 UTC
I have not tried since reporting it, but am firing up an attempt right now.  Will let you know the results.
Comment 4 russo 2021-06-10 15:16:35 UTC
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

make[1]: stopped in /usr/ports/math/maxima
*** Error code 1

make: stopped in /usr/ports/math/maxima

Looking in the staging directory:
# ls work/stage/usr/local/lib/maxima/

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.
Comment 5 russo 2021-06-10 15:41:50 UTC
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.
Comment 6 Fernando Apesteguía freebsd_committer 2021-06-10 17:59:07 UTC
(In reply to russo from comment #5)
That is frustrating.

Could you:

 * make distclean && make
 * Attach the full log if possible
Comment 7 russo 2021-06-10 22:57:14 UTC
(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.
Comment 8 russo 2021-06-10 23:12:39 UTC
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.
Comment 9 Fernando Apesteguía freebsd_committer 2021-06-11 05:30:49 UTC
(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

Comment 10 russo 2021-06-11 15:46:15 UTC
(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".
Comment 11 russo 2021-06-11 15:54:05 UTC
(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.
Comment 12 russo 2021-06-11 15:55:28 UTC
(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.