Arch Linux User Repository

Hi, I'm tackling the problem with the add-ons installation, where the installer can't write to /usr/local/MATLAB/R2022b. I think we should avoid manual chmods or chowns, as it would be easy to mess up with the permissions, so I created a matlab group with rwx permissions, which owns the tree starting at /usr/local/MATLAB/R2022b. The PKGBUILD sets up the correct permissions, so after installing MATLAB, you should just add yourself to that group, re-login and then you should be able to install add-ons. So far I'm able to start the installer, download the add-on archive, but when I get to Performing post-installation tasks. This may take a few minutes..., an error occurs, and the installer logs End - Unsuccessful Exception: java.lang.InterruptedException without further information.

If anyone wants to help me resolve this issue, here is the repo: https://github.com/Rubo3/matlab-aur/tree/addons.

I updated the PKGBUILD to MATLAB R2022b. Sorry it took so long. Here are the main changes:

• The dependencies have been updated according to namcap (thanks @sukanka), and are now managed via the matlab-meta meta package, now it's really easy to play around with them, as you don't have to rebuild the entire MATLAB package (thanks @bbaserdem). I still don't know the exact dependencies needed by MATLAB, as I don't use all its toolkits and whatnots. As always, please tell me if you find something.
• The MATLAB installer now outputs its logs in install.log, under the same directory of the PKGBUILD, so that you can check whether something went wrong even if it didn't fail (e.g. when you need a new license or installation key because the major version changed).
• I moved python-matlabengine to its own repo, which is built from upstream and works for the latest MATLAB versions. Currently it supports Python 3.9 and 3.10. If you have other needs, you can find the installation instructions here. Since the source files are still provided in your local MATLAB installation under $_instdir/extern/engines/python, building it and packaging it here was really just a convenience. I would like to know how many users of this PKGBUILD really need to spoof their Python version, so that we can reason about putting back that extra logic in the other PKGBUILD.
• I also removed the Mesa workaround and the optional compilers, are they still needed?

READ THE README FILE IN THE REPO. NO AUR HELPERS SUPPORTED. ONLY ARCHLINUX AS OS IS SUPPORTED. YOU SHOULD BE BUILDING THIS PACKAGE USING MAKEPKG, NOTHING ELSE WILL BE SUPPORTED. Please only post issues here AFTER you followed the README.md. located at the root of this repo: https://aur.archlinux.org/cgit/aur.git/tree/README.md?h=matlab Due to a lot of comments; my spam filter is removing AUR notifications which keeps me from responding timely to issues in packaging, please don't post if you don't do some troubleshooting yourself. If your skill level is not up to troubleshooting (or following simple instructions as laid out by the readme), just install matlab locally, without using this package.

• This PKGBUILD is NOT a minimal installation; as it has (hard) dependencies to gcc8 to force MATLAB to use system libraries. While generally not required; this PKGBUILD is trying to make MATLAB work with the system rather than with the mathworks-provided binaries. Currently it also does the python integration so that jupyter can be used with it.
• This will only work with 2020b version; and will not work with earlier (or later) versions.
• This PKGBUILD DOES NOT DOWNLOAD MATLAB FOR YOU. The EULA prevents redistribution of the software. Read the README.md file contained in the PKGBUILD repo. This is essentially a script to integrate an existing matlab installer with your archlinux system; it does NOT come with any software from Mathworks. You most likely cannot build this package using an AUR helper; you NEED to manually provide files; and to get the files you need a valid MATLAB licence. The process of fetching the files is described in detail in the README.md in the repo. (You can use any valid credentials to install the package using this PKGBUILD; including a licence file that does not match the machine; but you will need to reactivate matlab by using activate_matlab.sh with root privileges.)
• Current users; please help me test and trim the dependencies list, and submit your personal fixes for issues if you have them so they can be added to the PKGBUILD. (Cuda related contributions; if needed would be good as I don't have nvidia GPU's to test compatibility.)
• To use jupyter with matlab; you also need jupyter-matlab_kernel(-git).

@petronny matlab.lic is available in your account center in MathWorks website. If you don't have one, then you could/should not install matlab.

1

For non-network installations, installation from a purchased DVD for example, nowhere will provide this matlab.lic file to users.

Current PKGBUILD requires that users have to run touch matlab.lic to generate a meaningless file before running makepkg.

2

Okay, there are 2 solutions,

1. you could keep them and set gcc6 as a optional dependency.
2. you could remove them and set gcc6 as a dependency.

Now gcc6 is removed from the official repositories.
It makes the current way, which is the solution 1, is acceptable now. So you can keep them.

3

Yes, you should set mex options by the way suggested by the wiki pages.

@hottea I think it is a bad idea to include the license file(s) in the PKGBUILD and perform automated activation. License files are really complicated. You can have per user license files and per machine license files. A single installation of MATLAB can have multiple license files. For network installation, a license file is/was required, but for non-network installations, you don't/didn't need a license file. When I first wrote the PKGBUILD I used the license file for building a network installation, but did not include it in the package.

Activation is really stupid, as far as I could determine all it does is download the license file and copy it to the required directory 9it probably tell TMW lots of stuff also).

@petronny emm, you could update the PKGBUILD file. 1. I don't quite understand your point, user just need to provide matlab.lic in the same dir with PKGBUILD, and run makepkg.

2, 3. As for mex, should I remove the unused library files, and set mex opt? According to wiki page, matlab doesn't seem to respect the ${MATLAB}/bin/mexopts.sh customization. Instead it uses ${MATLAB}/bin/glnxa64/mexopts/LANG_glnxa64.xml file.

@hottea

1

You didn't answer me directly. Why matlab.lic is added as source for non-network installations? How could these users even get this file to run makepkg?

2

-  ## See $MATLABROOT/sys/os/glnxa64/README.libstdc++
-  msg2 'Removing unused library files'
-  rm ${pkgdir}/opt/tmw/${pkgname}/sys/os/glnxa64/{libstdc++.so.6.0.20,libstdc++.so.6,libgcc_s.so.1,libgfortran.so.3.0.0,libgfortran.so.3,libquadmath.so.0.0.0,libquadmath.so.0}

See $MATLABROOT/sys/os/glnxa64/README.libstdc++ and you will know why they are removed by @greyltc and me.

3

About mex. See @daniel_shub 's comment.
You should set the recommended compilers since you have listed gcc6 as an optional dependency for mex in PKGBUILD.

4

I guess it's not clear enough for @a36233

@daniel_shub

1

-  msg2 'Creating links for executables'
-  install -d -m755 "${pkgdir}/usr/bin/"
-  for _executable in deploytool matlab mbuild mcc mex; do
-    ln -s "/opt/tmw/${pkgname}/bin/${_executable}" "${pkgdir}/usr/bin/${_executable}"
-  done

He removed the binaries.

2

Some of use are packaging and then distributing via a local (or non-local) repository (MATLAB restrictive EULA be damned)

I agree that including PKGEXT in the PKGBUILD is bad style. But it is acceptable for matlab since it cannot be re-distributed.

@petronny I think including PKGEXT in the PKGBUILD is bad style. It should be left to the user to decide and set via makepkg.conf.

Not all of use package and then install. Some of use are packaging and then distributing via a local (or non-local) repository (MATLAB restrictive EULA be damned). In these cases, the carezy long compression time is worth it to reduce the download bandwidth.

Really wish I had a license for a new version. Trying to get some of the older versions to work is a dependency hell. I would much rather figure out the new dependencies and be done with it.

@hottea in version 9.3.0.713579 release 2 symbolic links were created in /usr/bin which caused the conflict. It looks like Darcy Hu made a modification that fixed the issue.

As for the mex compiler issues. I have been told by TMW that higher versions are not supported. That said, I could never find a test case that failed with a higher version. That said, since it is closed source, when I created the PKGBUILD, I went with the required version and I recommend sticking with that approach.

As for the dependencies, it is a real nightmare. I spent a lot of time starting with a clean chroot and only the base group installed and slowly added dependencies until I could get MATLAB to start. Then I tested things like plotting, sound, the doc viewer, opengl, cuda, etc.

My tests before releasing were matlab_cmd="/bin/matlab -nodesktop -nosplash -r" LC_ALL=C $matlab_cmd "version -java, exit" | grep Java LC_ALL=C $matlab_cmd "opengl info; exit" | grep Software LC_ALL=C $matlab_cmd "x=rand(10, 'single'); g=gpuArray(x); Success=isequal(gather(g), x), exit" | sed -ne '/Success =/,$p' LC_ALL=C $matlab_cmd "doc doc; pause; exit" LC_ALL=C $matlab_cmd "xlabel('BIG FONT', 'FontSize', 42); ylabel('small font', 'FontSize', 12); pause; exit" > /dev/null LC_ALL=C $matlab_cmd "bench, pause; exit" > /dev/null LC_ALL=C $matlab_cmd "load handel; sound(y, Fs); pause(length(y)/Fs); exit" > /dev/null

@petronny 1. You still need a license file from you administrator if you use network installation. For non-network installation, we could automate activate after installation. 2. For mex support with libs issue, you could use higher version of compilers, though it's not officially supported. 3. I think it's clear enough, user need to prepare a tarball matlab.tar from the MATLAB iso image. 4. I don't see such problem. MATLAB is installed in /opt/matlab, so it wouldn't conflict with texlive-bin.

As for deps, since MATLAB is not open source, and there is no deps list provided by MathWorks, I'm not quite sure to keep or remove which deps.

@bbaserdem

Also, is there a specific reason for having non pkg.xz extension?

Because it will take a lot of time to compress the package and then you will extract it just after the compression.