Distro Install Script for Arch Linux

[iamkucuk]

Hi all,

Can we have an installation script for distros based on Arch? It would be great.

Cheers!

[jlgreathouse]

Hi @furkan-kucuk

If anyone from the Arch-using community would like to submit a patch to handle this, I would gladly pull it in. However, I have little to no background working with Arch. As such, I'd say that your best bet is to follow the work being done by the community, such as this discussion.

In the end, I'd be really happy if some of the folks working on such projects pushed their build system into Experimental ROC so that any other things we make available here (such as experimental support for not-officially-supported GPUs) would also work with Arch.

[VileLasagna]

I'm actually working on this and was just about to come looking for information on how to contribute.
I know there are some packages in the AUR but it didn't look like I had too much luck with them so I came here to build things from source.
My work so far is commited on a branch on my fork

Everything should be buildable from source, but all the package side is still commented out. My plan is to reach out and leverage the work done by the people who made the packages as, though I've surprisingly got no experience on PKGBUILDs

Some builds are very conservative with the thread limit though, I was surprised

[haasanen]

@VileLasagna

Thanks for the conversion work on the scripts! The scripts built almost perfectly on my arch installation. The ATMI package just needs rsync installed before it builds correctly. I've sent you a small pull request.

With the rsync package installed, the build works flawlessly on my installation.

[VileLasagna]

Thanks for letting me know. I've merged that PR

[jlgreathouse]

Hi @VileLasagna

Thanks a lot for looking into this. As I mentioned, one of my major goals for Experimental_ROC was to use it as a kicking-off point for community interaction. I have no background in working with Arch, so your work is a huge help!

You're right that some of our builds are very conservative with the number of parallel threads. The background there is that one of my test systems has 16 GB of RAM. I found that some of our builds would randomly fail due to out-of-memory issues during large parallel builds. Reserving 4 GB of DRAM per build thread was the only way to prevent these random failures from happening. I would much rather that users have a slower build than for some builds to randomly fail. The latter failures are really hard to reproduce and debug on someone else's system, since they're non-deterministic.

As for how to contribute: please feel free to submit a PR based on your branch into this repo. I may have some comments before accepting the patches, but once we have them, I can also try to make sure I don't break Arch when updating the scripts for ROCm 2.1, 2.2, etc.

Some comments based on what I see in your repo right now:

• I will probably request that the README.md file for the distro_install_scripts directory be updated to mention Arch (with appropriate disclaimer that Arch isn't supported by AMD)
• The README.md for the Arch directory should probably be updated to mention that Arch is not officially supported by AMD (see the README for the Fedora directory, for instance).
• Rather than bringing the source installation scripts up to distro_install_scripts/Arch, it might be better to leave them in distro_install_scripts/Arch/src_install/. Let's imagine that, in the future, we want to make an unofficial "from AUR" installation scripts. Those might then go into distro_install_scripts/Arch/aur_install/.
• Rather than silently skipping the packaging step and performing a local install, it might be nice to instead have your scripts print out "packaging is currently not supported" and error out. I think this follows the principle of least astonishment. If someone requests to package software, but it is instead installed to their system and no package is created, they may be somewhat astonished. :)
• You can probably delete 01_00_rock-dkms.sh and rock_files in the Arch directory. I don't think that the rock-dkms module will ever work on Arch, since the DKMS build system requires a number of distro-specific patches that AMD does not (at this time) plan to port to Arch.

[znmeb]

I also have an Arch system and am going to use this. On the matter of cores, I have 8 and I had to hack /usr/bin/nproc down from 8 to 2 to keep the compiles from locking up my machine. There's a make -j nproc` somewhere in the code IIRC.

Will this end up in the AUR? The ROCm stack used to be there, although it never was fully working and I think it was orphaned.

[VileLasagna]

@jlgreathouse
Hey, thanks for the comments.
I'm going to implement those suggestions and make a PR. I can later iterate from there. Still keen on working the packaging side as well

@znmeb

My first go-to was also the AUR but I couldn't quite get it working either, possibly by not having all the necessary packages (It's a LOT of projects here and I'm pretty sure I installed very few packages).
I do want to make PKGBUILDs for each of these projects, but that will take some time and I still need to get to grips with writing those. Wrote a bunch of SPECfiles for OpenSuSE at work (I also really want to "trick" work into using rocm for something so I can find an excuse to convert the things for that distro as well =P), but never "had to" deal with packaging for Arch.
I guess that once this is all working and smooth I can either get this on the AUR or, maybe later, even try for the standard repositories; Once the adaptation is done, the project's layout is really good in that we can both tell the whole thing to build and package dependencies and meta-packages seem to be all there.

Currently taking this one step at a time tho, but from a perspective of making sure I do it in a way that preserves the care and structure that the original project had and made it easy to work with in the first place.