5.0

This release brings several new features.

Experimental support for Anylinux Sharun-based AppImages has been introduced

A NEW-anylinux.sh script has been added, which basically uses JuNest to install the application on Arch Linux, but actually uses Sharun to extract the libraries and build the AppImage.

AnyLinux AppImages are designed to run seamlessly on any Linux distribution, including older distributions and musl-based ones, without the need of a container, on the contrary of my classic Archimages.

To learn more, see https://github.com/pkgforge-dev/Anylinux-AppImages

The script is still in the experimental stage, improvements will be made in the coming months.

To test it, press "2".

Leave blank or press "1" if you want to create an Archimage, as always

Using Sharun to collect libraries

The NEW-junest.sh script now also uses Sharun, but only to compile the Archimages, gathering libraries, launching the app (if necessary) isolated in the script's temporary HOME directory, and locating as many libraries as possible.

The resulting Archimage will, in most cases, be ready to use on the first try. The success rate is higher!

Abiword.Archimage.5.0.mp4

NOTE, the video was shot during early testing, which did not yet include the introduction of archimage-builder.sh, see below.

Reduced Archimage script

The NEW-junest.sh script is now less than 200 lines long.

All core processes run in a dedicated module: archimage-builder.sh

This centralization will allow for the timely maintenance of multiple Archimages simultaneously, should drastic changes to the Arch Linux base be introduced.

During startup, the aforementioned module will also be downloaded, containing the core operations for:

• installing programs in JuNest
• identifying the launcher and icon
• scanning libraries
• streamlining the final product
• creating mounting points.

In the user script appname-junest.sh, you can add:

• the app name
• binary
• dependencies
• keywords to add/remove
• additional mounting paths
• additional mirrors and repositories
• enabling Nvidia support
• additional custom commands after each process
• the final part of the AppRun with custom functions and commands (or leave defaults)
• data related to the reference repository, including update info

The new archimage-builder.sh will be downloaded at start, in the root of the working directory

All in less than 200 lines, without frills.

Each section also has a clear description to guide you if you have any questions about modifying the script.

simplescreenrecorder-2025-10-26_00.28.03.mp4

Conclusions

This release aims to simplify the readability of the scripts, their configuration, and the centrality of its build system.

Arch Linux is subject to changes, sometimes drastic and unexpected, which easily lead to the breaking of some links and libraries necessary for the functioning of an Archimage.

Personally, as of this writing, I have about 40 Archimage packages scattered across my repositories, and many of them have their own repository.

I needed to simplify my life by keeping track of my various repositories, so I decided to separate the main script into a highly configurable part for the user (the NEW-junest.sh script) and a part dedicated to the build (archimage-builder.sh), from which it will be possible to intervene as the most unwelcome changes become apparent.

I hope you enjoy this release. See you next!

4.3

This release brings workflow improvements and more lightweight AppImages created

Create the script and the JuNest environment (part 1)	Create the AppImage (part 2)
part.1.mkv.mp4	part.2.mkv.mp4

Updated archimage-cli

• if you are a user of "AM"/AppMan at https://github.com/ivan-hc/AM, you can use bash/zsh completion for arguments and options
• added two options to use this CLI in "develper mode" , like "AM", options --devmode-enable (lets you use the "dev" branch of this repo) and --devmode-disable
• added a message that warns you in case you have not a XDG directory, files will be saved in your current directory

Updated the script "NEW-junest.sh"

• running the script is now less resource intensive... and it is now really quick, expecially for the part of libraries saved
• replaced all the slow functions to add libraries with only one that quickly selects only the needed libraries of the main package and the dependencies
• the basic JuNest is keept into a dedicated directory "archlinux/.junest", while the AppDir will be created apart, with the same structure of directories and its own patches, not to rsync/remove backups each time
• restarting the process will take care if the variables extraction_count and DEPENDENCES are not changed, if so, there is no need to extract all packages again (see below 👇 )

simplescreenrecorder-2025-01-18_20.10.40.mkv.mp4

• check libraries is more selective, to reduce bloating the final AppImage
• in most cases it is enough to add only keywords to BINSAVED, LIBSAVED and SHARESAVED instead of adding packages in DEPENDENCES, so you don't need to specify what dependencies must be added in DEPENDENCES, using a high value for extraction_count should be enough to create a working (and bloat) AppImage
• empty directories under /usr are removed (eccept the needed mountpoints)

The above can be resumed in a cleaner AppDir with only what the app really needs to work.

Please refer to the tutorial on the README of this repo to start your searches.

If you have already installed archimage-cli, please run

archimage-cli -s

...to use the latest version.

4.2

"NEW" template that merges the previous ones

https://github.com/ivan-hc/ArchImage/blob/main/NEW-junest.sh

• all AppImages created are updatable, the footer of the script contains variables for this purpose
• all AppImages can alternate BubbleWrap and PROOT in order to work on all systems with or without restrictions on Namespaces
• dependences and "optdepend" of the base package are all detected and extracted by default
• include the more common coreutils binaries by default, to prevent missing core commands when running the app
• fixed major issues related to links inside the apps, now they can communicate with your local Firefox (and maybe other browsers)... it is recommended to add xapp as a dependency
• all main variables for keywords are now on top of the script, under the main variables APP, BIN and DEPENDENCES, for the sake of your workflow
• you can choose not to add dependencies due to the new "extraction level" system: set 1 (default) to extract only dependencies of the dependencies, 2 to extract the dependencies of the latter... and so on, until you can bundle the whole Arch Linux (please, don't do it 😆 )... seriously, there is also a black list of packages that prevents base-devel related ones and packages like systemd or the kernel to be bundled. You can extend that command according to your needs. The variable name is $extraction_count, you can edit it manually or set it out of the script. NOTE, the higher the number, the more packages will be included, the more successfully the app will work... the bigger the AppImage will be
• the script is separated into blocks with headers indicating what that part of the workflow is dedicated to, making it easier to customize your scripts
• added a new function with variables to set manually for files and directories to remove, conveniently manageable via for loops

For more details, see the updated README with new questions of the wizard and the function to remove explained files in detail.

If you already have archimage-cli installed, run the command

archimage-cli -s

to update.

New "suggestions" have also been added to the end of the wizard.

Here is a video where I build OBS Studio

https://www.youtube.com/watch?v=gMFo9_ykBss

Have fun!

4.1

New core code in the AppRun to use Nvidia drivers from the host

[ -z "$NVIDIA_ON" ] && NVIDIA_ON=1
if [ "$NVIDIA_ON" = 1 ]; then
   DATADIR="${XDG_DATA_HOME:-$HOME/.local/share}"
   CONTY_DIR="${DATADIR}/Conty/overlayfs_shared"
   [ -f /sys/module/nvidia/version ] && nvidia_driver_version="$(cat /sys/module/nvidia/version)"
   if [ -n "$nvidia_driver_version" ]; then
      mkdir -p "${CONTY_DIR}"/nvidia "${CONTY_DIR}"/up/usr/lib "${CONTY_DIR}"/up/usr/share
      nvidia_data_dirs="egl glvnd nvidia vulkan"
      for d in $nvidia_data_dirs; do [ ! -d "${CONTY_DIR}"/up/usr/share/"$d" ] && ln -s /usr/share/"$d" "${CONTY_DIR}"/up/usr/share/ 2>/dev/null; done
      [ ! -f "${CONTY_DIR}"/nvidia/current-nvidia-version ] && echo "${nvidia_driver_version}" > "${CONTY_DIR}"/nvidia/current-nvidia-version
      [ -f "${CONTY_DIR}"/nvidia/current-nvidia-version ] && nvidia_driver_conty=$(cat "${CONTY_DIR}"/nvidia/current-nvidia-version)
      if [ "${nvidia_driver_version}" != "${nvidia_driver_conty}" ]; then
         rm -f "${CONTY_DIR}"/up/usr/lib/*; echo "${nvidia_driver_version}" > "${CONTY_DIR}"/nvidia/current-nvidia-version
      fi
      /sbin/ldconfig -p > "${CONTY_DIR}"/nvidia/host_libs
      grep -i "nvidia\|libcuda" "${CONTY_DIR}"/nvidia/host_libs | cut -d ">" -f 2 > "${CONTY_DIR}"/nvidia/host_nvidia_libs
      libnv_paths=$(grep "libnv" "${CONTY_DIR}"/nvidia/host_libs | cut -d ">" -f 2)
      for f in $libnv_paths; do strings "${f}" | grep -qi -m 1 "nvidia" && echo "${f}" >> "${CONTY_DIR}"/nvidia/host_nvidia_libs; done
      nvidia_libs=$(cat "${CONTY_DIR}"/nvidia/host_nvidia_libs)
      for n in $nvidia_libs; do libname=$(echo "$n" | sed 's:.*/::') && [ ! -f "${CONTY_DIR}"/up/usr/lib/"$libname" ] && cp "$n" "${CONTY_DIR}"/up/usr/lib/; done
      libvdpau_nvidia="${CONTY_DIR}/up/usr/lib/libvdpau_nvidia.so"
      if ! test -f "${libvdpau_nvidia}*"; then cp "$(find /usr/lib -type f -name 'libvdpau_nvidia.so*' -print -quit 2>/dev/null | head -1)" "${CONTY_DIR}"/up/usr/lib/; fi
      [ -f "${libvdpau_nvidia}"."${nvidia_driver_version}" ] && [ ! -f "${libvdpau_nvidia}" ] && ln -s "${libvdpau_nvidia}"."${nvidia_driver_version}" "${libvdpau_nvidia}"
      [ -d "${CONTY_DIR}"/up/usr/lib ] && export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}":"${CONTY_DIR}"/up/usr/lib:"${LD_LIBRARY_PATH}"
      [ -d "${CONTY_DIR}"/up/usr/share ] && export XDG_DATA_DIRS="${XDG_DATA_DIRS}":"${CONTY_DIR}"/up/usr/share:"${XDG_DATA_DIRS}"
   fi
fi

...you don't have to wait for the download to finish, download external scripts or compile anything from scratch.

One second or less is enough before you stat using hardware acceleration in your apps.

The above function is inspired by Conty's NVIDIA_HANDLER=2, and is 100% compatible with Conty.

What's Changed

• Archimage 4.1 - use Nvidia drivers from host system by @ivan-hc in #28

Full Changelog: 4.0...4.1

4.0

This release combines the flexibility of JuNest with the power of Conty to support hardware acceleration!

Like JuNest, Conty is also a portable Arch Linux container, and as in the main script, it uses BubbleWrap to interface with the host system.

Its advantage, however, is that it detects the presence of proprietary Nvidia drivers in the system and then locally installs those needed by an Arch Linux system to work.

The drivers are saved in a "Conty" directory, under $HOME/.local/share. Once installed, the JuNest-based Archimage will only have to detect them and then automatically export the path to the libraries and files needed for hardware acceleration to work.

Here is an example of how Nvidia drivers are installed locally

simplescreenrecorder-2024-12-29_01.15.05.mkv.mp4

This only works with Archimages that contain the same piece of code added in this commit a8fae45 or for all new Archimages.

It is recommended not to abuse this feature, not all programs need hardware acceleration.

Added a new question to the CLI:

DO YOU WANT TO ENABLE HARDWARE ACCELERATION FOR NVIDIA USERS?

default is "N".

It will be possible to activate Nvidia support with NVIDIA_ON=1 and deactivate it by setting it to zero or other values ​​different from 1, for example with NVIDIA_ON=0. The function to detect and install/update local Nvidia drivers can then also be activated/deactivated at a later time, or by the user himself who uses the AppImage, by exporting the right value for NVIDIA_ON.

See more at Hardware Acceleration.

What's Changed

• Archimage 4: use hardware acceleration by @ivan-hc in #27

Full Changelog: 3.5...4.0

ArchImage CLI 3.5

Now it is possible to choose between the buld script based on BubbleWrap and the one based on Proot

1. BubbleWrap (default), uses Linux namespaces for greater host compatibility
2. Proot (new), maximum portability, but still experimental

also, full refactoring and a new look.

simplescreenrecorder-2024-12-20_20.58.17.mkv.mp4

---

Curiosity

The first versions of the Archimage scripts were all based on PROOT, this return was driven by the discovery of new implementations, in particular using Archimages on non-Linux systems, such as FreeBSD: AppImages based on PROOT had a better chance of being executed in Linuxlator than those based on Bubblewrap.

The port is still under experimentation.

3.4.4

• Refactoring del codice nella CLI principale e negli script
• Reduced the number of customization steps
• Velocità di costruzione migliorata

Full Changelog: 3.4...3.4.4

3.4

Scripts

• AppImages are now Type3, so you don't need to have libfuse2 installed on the host
• first experimental implementation of "libselinux", if in "$DEPENDENCES" it will be bundled into AppImage and system libraries from the host can be viewed without conflicts (this is a first step towards implementing hardware acceleration)
• various cleanings of the code
• use "BASH" instead of "SH"

CLI

• Just changed the version number

Full Changelog: 3.3...3.4

3.3

Scripts

• Now you can repeat your tests several times without having to download and reinstall everything all over again
• Various bug fixes

CLI

• Just changed the version number

Full Changelog: 3.2...3.3

3.2

CLI

Not big changes, just moved "include dependencies" to the top options.

SCRIPTS

• Unsilenced messages, now you can debug without extracting the package;
• Automatic mounting of "/etc/resolv.conf" for internet connections, single point in "/etc", removing any JuNest related error messages and giving the internal BASH/SHELL full control of the container.

This release aims to broaden user search by enabling debugging by default.

Future releases will see an attempt to implement hardware acceleration, which is still absent in JuNest. If you want to help me, visit fsquillace/junest#344