NOTE: Tested only on Ubuntu 26.04, but the bug is very likely broader
I'm aware Omakub is officially tested on Ubuntu 24.04 LTS and that 26.04 is out of scope for this project. I'm reporting from a 26.04 install because that's where I hit the problem, but I have good reason to believe at least the icon-rendering symptom also
affects 24.04:
Yaru-green, Yaru-orange, Yaru-grey are not present in any version of the yaru-theme-icon package that I could find on packages.ubuntu.com. They appear to be names that have never existed in the official Yaru icon set, so osaka-jade, matte-black
and ristretto would be broken on 24.04 as well.
Yaru-bark does exist in yaru-theme-icon on Noble (24.04) but not on Resolute (26.04), so everforest is the one theme that may regress specifically with the version bump.
- The
accent-color symptom is GNOME 47+ only, so it would not reproduce on 24.04 (which ships GNOME 46) — but it would on any distro shipping GNOME 47 or newer.
A confirmation (or refutation) from someone on a stock 24.04 install for the osaka-jade / matte-black / ristretto icon rendering would help narrow the scope. Either way, the underlying coupling (Omakub assumes every $OMAKUB_THEME_COLOR maps to a real Yaru
variant) is fragile and worth fixing regardless of the target Ubuntu version.
Summary
On Ubuntu 26.04 with GNOME Shell 50.1, several Omakub themes silently fail to apply correctly. They reference Yaru icon/GTK variants that don't exist in the system and accent-color values outside the GNOME enum.
Concretely, 4 of 10 themes break icon rendering (Yaru-green, Yaru-orange, Yaru-grey, Yaru-bark are not packaged), and 5 of 10 themes leave accent-color unchanged between theme switches because the assigned value is rejected by GSettings and the
error is swallowed.
Only 4 of 10 themes (kanagawa, nord, rose-pine, tokyo-night) work end-to-end on a stock Ubuntu 26.04 install.
Environment
- Ubuntu 26.04 LTS (Resolute Raccoon)
- GNOME Shell 50.1
yaru-theme-icon 26.04.5.1ubuntu (from universe)
- Omakub
stable, current HEAD 68a7d00
Symptoms
Missing icons after theme switch
Applications using icons from the active GTK/icon theme render some icons blank or fall back to wrong icons. The most visible case is GNOME Calls, where the navigation tabs (recents / contacts / dialpad) appear empty. Cause: org.gnome.desktop.interface.icon-theme
points to a directory that doesn't exist in /usr/share/icons/, so GTK falls back to hicolor, which doesn't carry most of the symbolic icons apps request.
accent-color stuck on previous value
The top-right Quick Settings panel and the Alt+Esc window selection border keep the color of the previously applied theme. The new accent-color is never applied.
Root cause
themes/set-gnome-theme.sh concatenates $OMAKUB_THEME_COLOR blindly:
gsettings set org.gnome.desktop.interface gtk-theme "Yaru-$OMAKUB_THEME_COLOR-dark"
gsettings set org.gnome.desktop.interface icon-theme "Yaru-$OMAKUB_THEME_COLOR"
gsettings set org.gnome.desktop.interface accent-color "$OMAKUB_THEME_COLOR" 2>/dev/null || true
Two assumptions that don't hold on Ubuntu 26.04:
- Every
$OMAKUB_THEME_COLOR has a corresponding Yaru-<color> directory in /usr/share/icons/ and /usr/share/themes/. Not true for green, orange, grey, bark.
$OMAKUB_THEME_COLOR is a valid value for org.gnome.desktop.interface.accent-color. Not true: GNOME 47+ restricts this key to a closed enum, and the 2>/dev/null || true silently swallows the rejection for any non-conforming value.
Reference: valid values on Ubuntu 26.04
Yaru variants actually installed by yaru-theme-icon / yaru-theme-gtk:
Yaru, Yaru-dark, Yaru-blue(-dark), Yaru-magenta(-dark),
Yaru-olive(-dark), Yaru-prussiangreen(-dark), Yaru-purple(-dark),
Yaru-red(-dark), Yaru-sage(-dark), Yaru-wartybrown(-dark),
Yaru-yellow(-dark)
accent-color enum (from gsettings range org.gnome.desktop.interface accent-color):
blue, teal, green, yellow, orange, red, pink, purple, slate, brown
Per-theme audit
| Theme |
OMAKUB_THEME_COLOR |
Yaru variant exists |
Valid accent-color |
| catppuccin |
magenta |
yes |
no |
| everforest |
bark |
no |
no |
| gruvbox |
sage |
yes |
no |
| kanagawa |
purple |
yes |
yes |
| matte-black |
orange |
no |
yes |
| nord |
blue |
yes |
yes |
| osaka-jade |
green |
no |
yes |
| ristretto |
grey |
no |
no |
| rose-pine |
red |
yes |
yes |
| tokyo-night |
purple |
yes |
yes |
Reproduction
omakub theme set osaka-jade # or any of the affected themes
gsettings get org.gnome.desktop.interface icon-theme
# => 'Yaru-green' ← directory does not exist under /usr/share/icons/
ls /usr/share/icons/Yaru-green
# => No such file or directory
gsettings get org.gnome.desktop.interface accent-color
# => previous theme's accent, unchanged
Proposed fix
Three options, in order of cleanliness:
- Decouple
OMAKUB_THEME_COLOR from the GNOME accent value by introducing a separate OMAKUB_GNOME_ACCENT variable per theme. Each theme's gnome.sh would set both. set-gnome-theme.sh consumes both, applying the Yaru color to gtk-theme/icon-theme and
the GNOME enum value to accent-color. Cleanest separation of concerns; no implicit mapping table.
- Map
OMAKUB_THEME_COLOR to the closest GNOME accent in set-gnome-theme.sh via a small case statement (e.g. magenta → pink, sage → green, prussiangreen → green, wartybrown → brown, olive → green). Less invasive but couples the central script with
a mapping table.
- Per-theme override in each
themes/<theme>/gnome.sh, adding an explicit gsettings set ... accent-color "<value>" after sourcing set-gnome-theme.sh, and updating OMAKUB_THEME_COLOR to an existing Yaru variant. This is the workaround I'm using locally.
Regardless of which option is picked, the 2>/dev/null || true on the accent-color line should be removed once the value is guaranteed to be valid — silent failure is what masked this bug for so long. Validating the target Yaru directory exists before calling
gsettings set for gtk-theme/icon-theme would also surface future drift between Omakub and the Yaru package.
Workaround for users hitting this today
Quick patch using option 3. Edit ~/.local/share/omakub/themes/<theme>/gnome.sh:
| Theme |
OMAKUB_THEME_COLOR → |
Add line accent-color |
| catppuccin |
(unchanged: magenta) |
pink |
| everforest |
olive |
green |
| gruvbox |
(unchanged: sage) |
green |
| matte-black |
yellow |
(already a valid enum value) |
| osaka-jade |
prussiangreen |
green |
| ristretto |
wartybrown |
brown |
Re-apply the theme with omakub theme set <theme> after editing.
Summary
On Ubuntu 26.04 with GNOME Shell 50.1, several Omakub themes silently fail to apply correctly. They reference Yaru icon/GTK variants that don't exist in the system and
accent-colorvalues outside the GNOME enum.Concretely, 4 of 10 themes break icon rendering (
Yaru-green,Yaru-orange,Yaru-grey,Yaru-barkare not packaged), and 5 of 10 themes leaveaccent-colorunchanged between theme switches because the assigned value is rejected by GSettings and theerror is swallowed.
Only 4 of 10 themes (
kanagawa,nord,rose-pine,tokyo-night) work end-to-end on a stock Ubuntu 26.04 install.Environment
yaru-theme-icon26.04.5.1ubuntu (fromuniverse)stable, current HEAD68a7d00Symptoms
Missing icons after theme switch
Applications using icons from the active GTK/icon theme render some icons blank or fall back to wrong icons. The most visible case is GNOME Calls, where the navigation tabs (recents / contacts / dialpad) appear empty. Cause:
org.gnome.desktop.interface.icon-themepoints to a directory that doesn't exist in
/usr/share/icons/, so GTK falls back tohicolor, which doesn't carry most of the symbolic icons apps request.accent-colorstuck on previous valueThe top-right Quick Settings panel and the Alt+Esc window selection border keep the color of the previously applied theme. The new
accent-coloris never applied.Root cause
themes/set-gnome-theme.shconcatenates$OMAKUB_THEME_COLORblindly:Two assumptions that don't hold on Ubuntu 26.04:
$OMAKUB_THEME_COLORhas a correspondingYaru-<color>directory in/usr/share/icons/and/usr/share/themes/. Not true forgreen,orange,grey,bark.$OMAKUB_THEME_COLORis a valid value fororg.gnome.desktop.interface.accent-color. Not true: GNOME 47+ restricts this key to a closed enum, and the2>/dev/null || truesilently swallows the rejection for any non-conforming value.Reference: valid values on Ubuntu 26.04
Yaru variants actually installed by
yaru-theme-icon/yaru-theme-gtk:accent-colorenum (fromgsettings range org.gnome.desktop.interface accent-color):Per-theme audit
OMAKUB_THEME_COLORReproduction
Proposed fix
Three options, in order of cleanliness:
OMAKUB_THEME_COLORfrom the GNOME accent value by introducing a separateOMAKUB_GNOME_ACCENTvariable per theme. Each theme'sgnome.shwould set both.set-gnome-theme.shconsumes both, applying the Yaru color togtk-theme/icon-themeandthe GNOME enum value to
accent-color. Cleanest separation of concerns; no implicit mapping table.OMAKUB_THEME_COLORto the closest GNOME accent inset-gnome-theme.shvia a small case statement (e.g.magenta → pink,sage → green,prussiangreen → green,wartybrown → brown,olive → green). Less invasive but couples the central script witha mapping table.
themes/<theme>/gnome.sh, adding an explicitgsettings set ... accent-color "<value>"after sourcingset-gnome-theme.sh, and updatingOMAKUB_THEME_COLORto an existing Yaru variant. This is the workaround I'm using locally.Regardless of which option is picked, the
2>/dev/null || trueon theaccent-colorline should be removed once the value is guaranteed to be valid — silent failure is what masked this bug for so long. Validating the target Yaru directory exists before callinggsettings setforgtk-theme/icon-themewould also surface future drift between Omakub and the Yaru package.Workaround for users hitting this today
Quick patch using option 3. Edit
~/.local/share/omakub/themes/<theme>/gnome.sh:OMAKUB_THEME_COLOR→accent-colormagenta)pinkolivegreensage)greenyellowprussiangreengreenwartybrownbrownRe-apply the theme with
omakub theme set <theme>after editing.