Lüv: a freedesktop icon theme you install by copying directories

A theme delivered as files, not as a package

Lüv is described as an icon theme for freedesktop environments, and it comes from the Nitrux organisation, whose homepage is nxos.org. The repository is primarily Shell, which is a clue about how the artefact is built and shipped: this is not a compiled application but a set of assets plus the scripts that assemble and convert them.

The delivery model is the defining characteristic. There is no package to install from a repository, no dependency to resolve and no configuration step. You clone the repository and copy the assets to a location the desktop already looks in. For a user who wants to try an icon theme on a machine they administer, that is a genuinely short path. For a user who wants the theme to arrive and update with the rest of their system, it is a step they have to own themselves.

The topic tags add a detail worth noting: icons and wallpapers are both in scope, and the repository carries a Wallpapers/ directory alongside the icon set. So a first-time user is installing two things at once, an icon theme and a matching wallpaper set, which is the usual pairing when a designer treats the desktop as one composition rather than as independent pieces.

System-wide install puts the theme in /usr/share/icons

The installation instructions start by getting the files locally:

git clone https://github.com/Nitrux/luv-icon-theme.git
cd luv-icon-theme

The system-wide path is two copy commands:

sudo cp -r Luv /usr/share/icons/
sudo cp -r Wallpapers/* /usr/share/wallpapers/

What this does is worth spelling out, because it determines how the theme is found. The Luv directory is copied into /usr/share/icons/ as a subdirectory, so the theme lives at /usr/share/icons/Luv, which is where the desktop's icon lookup expects a named theme directory. The Wallpapers contents are copied rather than the directory itself, so each wallpaper image lands directly in /usr/share/wallpapers/ and is picked up by name.

Because this is a copy rather than a link, updating the theme later means repeating the copy after a fresh clone or a pull. There is no metadata recording which version you installed, and the directory carries no package manifest that a package manager could track. If you later want to replace the theme, the cleanup is removing that directory by hand.

The per-user install avoids root entirely

The second documented route does the same thing without sudo:

mkdir -p ~/.local/share/icons ~/.local/share/wallpapers
cp -r Luv ~/.local/share/icons/
cp -r Wallpapers/* ~/.local/share/wallpapers/

The structure mirrors the system path under your home directory, with the theme at ~/.local/share/icons/Luv. Two directories are created first because the copy will fail otherwise, and the wallpaper copy again expands the contents rather than nesting a Wallpapers directory.

The practical difference between the two routes is precedence and reach. A per-user install affects only that account and needs no administrator rights, which makes it the sensible first move when you are trying the theme or when the machine is shared. A system-wide install makes the theme available to every account on the machine, which is what you want on a workstation you administer and what you want to avoid on a multi-user system where a theme change would silently alter someone else's desktop.

Either way the change is only visible once the desktop re-reads the icon directories. If the icons do not change after the copy, the cause is a stale icon cache rather than a failed copy, and the copy itself has to be correct for a reload to help.

Vector sources, generated rasters and a Debian directory

The top level of the repository holds .github/, .gitignore, CONTRIBUTORS, CREDITS, LICENSE, README.md, the Luv/ directory, the Wallpapers/ directory, a debian/ directory, and two shell scripts named gh-build.sh and svg-to-png.sh.

Those script names carry the most information in that list. A script called svg-to-png.sh is a converter, and its presence alongside a theme directory implies the artwork is authored as SVG with raster renditions produced from it, which is how a theme can ship both scalable icons and PNG fallbacks for applications and panels that do not render vector art. The second script, gh-build.sh, is named after GitHub, which points to a build step that runs in CI. The debian/ directory then explains the presence of Debian packaging material alongside the raw assets.

The CREDITS and CONTRIBUTORS files matter for a different reason. Both a credits file and a contributors file sit at the top level, and the README carries a bug report template and points to the issue tracker. For an asset project, attribution and a public bug channel are the two things that keep the artwork usable over time, since an icon set ages and every new application needs a matching glyph.

ShareAlike terms shape what you may do with the artwork

The licence is Creative Commons Attribution-ShareAlike 4.0 International, which is what the README states and what the repository licence field records. That choice is normal for icon themes, and it is also a real constraint.

Attribution means credit must be given, and the README records the copyright as 2019 Nitrux Latinoamericana S.C. ShareAlike is the part that decides what happens to derivatives. A modified version of the assets has to be released under the same terms, and the artwork cannot be relicensed as something proprietary. For a desktop theme that most people install as-is, that costs nothing. For a company that wants to adapt a handful of glyphs to match a product, the share-alike obligation is a genuine constraint and the reason to check the terms before starting rather than afterwards.

There is a second practical point about licence and repository. The project has no GitHub releases at all. The canonical artefact is the branch content, so the version you install is whatever commit you happened to clone, and the artwork on your disk has no version marker of its own.

No tagged releases means tracking the branch

The repository is not archived and the last push was on 2026-10-11, so the artwork is still being worked on. The default branch is master, and the recent release list is empty, with no GitHub releases published.

For an asset project that is a defensible choice rather than an oversight. Icons are files, not binaries, and there is no compiled artefact whose compatibility matters. A user pulling master gets the current artwork, and a user who wants a stable snapshot has to record the commit hash themselves.

The consequence for an administrator is that there is no upgrade path to script. You cannot pin a version in a package manifest or a lock file, and there is no changelog of icon changes to review before copying files over an existing installation. Your update procedure is a git pull followed by a repeat of the copy commands, and your rollback procedure is whatever copy you made before, if you made one.

For the same reason, the bug report template mentioned in the project notes is the practical feedback channel. Icon coverage in particular is a completeness question that only shows up on a real desktop, and the repository does not publish a list of which applications the theme covers, so gaps are found by users rather than by a manifest.

Editorial conclusion

Adopt Lüv if you want a consistent icon set and matching wallpapers on a freedesktop system and you are comfortable copying files into an icon path by hand. Skip it if you need the theme delivered and updated by a package manager, if you want a theme you may modify without sharing the changes, or if you need a themed app icon set that includes every application you use, since the repository does not enumerate icon coverage. Verify first that the theme name inside the copied Luv directory matches the icon theme name your desktop settings expect, then reload the icon cache before assuming the install failed.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-SA-4.0
3. Nitrux/luv-icon-theme on GitHub
4. Project website
5. README