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).

I had to install the libselinux package in order to use the Add-On Explorer in Matlab R2016b. https://se.mathworks.com/matlabcentral/answers/309629-cannot-open-add-on-window-on-linux Maybe this package should be added to depends or optdepends?

@daniel_shub I figured out the issue thanks to you by removing &> /dev/null from line 66, turns out I was giving it the wrong fik. I was under the impression that the number I was giving by my school was the fik, turns out it was not and my school gave me the correct fik to install Thanks for the Help

@xcabal what version of MATLAB are you installing? Is there anything in /mnt/f078739e-820f-40da-bf0d-838723a49f50/software/mat/pkg/matlab/opt/tmw/ You could try removing &> /dev/null from line 66 and you might get a more helpful error message.

I'm getting the following message trying to install matlab 2016b ==> Starting package()... -> Starting MATLAB installer -> Installing license install: cannot stat '/mnt/f078739e-820f-40da-bf0d-838723a49f50/software/mat/pkg/matlab/opt/tmw/matlab/license_agreement.txt': No such file or directory ==> ERROR: A failure occurred in package(). Aborting... im am not sure what it whats let alone how to fix it anyone have any idea how to resolve this? thanks

With R2016b, if you get error like "Unable to start MATLABWindow process" with Add-on Explorer, Simulink gallery, Simulation Data Inspector etc, make sure to install this package: https://aur.archlinux.org/packages/libselinux/ MATLABWindow executable is linked with libselinux.so, so you need this.

btw, `/usr/bin/mcc` is in conflict with mathematica, as well. I'm going to try linking just /usr/bin/matlab and nothing else. As it stands, either declare the conflict on texlive/mathematica, or change the links - the worst thing to do is to get the error message only once pacman has spent a full hour decompressing the package, whereas one could have dealt with the issue up-front if they new about the conflict. My vote goes towards *not* linking any binaries, and then documenting this in the wiki AND displaying a post-installation message telling the user where the binaries can be found. I suppose one could also create another package (e.g. `matlab-links`) which packages only the links, but depends on `matlab` (which has no /usr/bin links) and then users now have the option to install matlab with or without symlinks, but I'm pretty sure that's unidiomatic in at least one way.

@greyltc Depending on what you are doing, running hardware based opengl can be much faster ... The texlive-bin conflict is a pain. Having MATLAB conflict with TeX Live seems silly. This means either renaming the MATLAB executables or simply not creating links in /usr/bin. I don't have a good set of tests of mex functionality, so I do not know if changing the name is viable. That said, it is just a link, so I think it should be fine. I am leaning towards not linking anything to /usr/bin. The problem with that is then people need to add /opt/tmw/matlab/bin/ to their path to start MATLAB from the CLI (the PKGBUILD can take care of the desktop launcher). We could then add a link on the Arch MATLAB wiki page to how to change the path. Any thoughts? In the meantime, you can comment out lines 74-78 (or modify them to choose a different name).

@Tallix the MATLAB installer makes use of /tmp during the installation process. On Arch, /tmp is a tmpfs that usually defaults to using up to half of your available RAM. This means the space in your home partition does not matter. When I build from either the PKGBUILD or directly from the MATLAB installer, I get exactly the same files written to /tmp. The only reason I can think of that it works for you with the MATLAB installer and not the PKGBUILD is that maybe you are only installing a subset of the toolboxes with the MATLAB installer. If you install less stuff, you need less space in /tmp. Since the tmpfs filesystem uses RAM it is much faster than filesystems located on a physical hard drive. That said, the Arch way may be to keep everything in ${srcdir}. Let me check. In the mean time you can either mount /tmp as a regular filesystem (https://wiki.archlinux.org/index.php/Tmpfs#Disable_automatic_mount) or edit the PKGBUILD to pass the MATLAB installer '-tmpdir "${srcdir}"'. Basically, you want to change line 66 from "${srcdir}/install" -t -inputFile "${srcdir}/installer_input.txt" -mode silent &> /dev/null to "${srcdir}/install" -t -inputFile "${srcdir}/installer_input.txt" -mode silent -tmpdir "${srcdir}" &> /dev/null

@0tie @daniel_shub @ido I'm having the same problem, even when running makepkg -s while in my home partition, which has 662.7GB of free space. The origin of the issue appears to be the Matlab installer. I modified the PKGBUILD so that the output of the Matlab installer is not redirected to /dev/null and now I'm seeing errors from cp saying that it has no space left on the device when trying to write to /tmp/mathworks_23253/whatever and a final error that says "Error: No classpath definition jar found." I find this strange, because I was able to run the installer by itself just fine earlier... I just wanted to use the AUR package because it integrates everything into Arch nicely.

In case it helps anyone else... MATLAB on my machine was segfaulting a few seconds after I started it and it mostly finished drawing the UI: Segmentation violation detected at Sun Aug 21 16:50:31 2016 ... I've found two solutions. 1. Running matlab -r "opengl('save','software')" solves it (on next startup) 2. Run it with LIBGL_DRI3_DISABLE=1 matlab